A List Apart
Krystal website hosting

Human-Readable JavaScript: A Tale of Two Experts

Everyone wants to be an expert. But what does that even mean? Over the years I’ve seen two types of people who are referred to as “experts.” Expert 1 is someone who knows every tool in the language and makes sure to use every bit of it, whether it helps or not. Expert 2 also knows every piece of syntax, but they’re pickier about what they employ to solve problems, considering a number of factors, both code-related and not. 

Can you take a guess at which expert we want working on our team? If you said Expert 2, you’d be right. They’re a developer focused on delivering readable code—lines of JavaScript others can understand and maintain. Someone who can make the complex simple. But “readable” is rarely definitive—in fact, it’s largely based on the eyes of the beholder. So where does that leave us? What should experts aim for when writing readable code? Are there clear right and wrong choices? The answer is, it depends.

The obvious choice

In order to improve developer experience, TC39 has been adding lots of new features to ECMAScript in recent years, including many proven patterns borrowed from other languages. One such addition, added in ES2019, is Array.prototype.flat() It takes an argument of depth or Infinity, and flattens an array. If no argument is given, the depth defaults to 1.

Prior to this addition, we needed the following syntax to flatten an array to a single level.

let arr = [1, 2, [3, 4]];

[].concat.apply([], arr);
// [1, 2, 3, 4]

When we added flat(), that same functionality could be expressed using a single, descriptive function.

// [1, 2, 3, 4]

Is the second line of code more readable? The answer is emphatically yes. In fact, both experts would agree.

Not every developer is going to be aware that flat() exists. But they don’t need to because flat() is a descriptive verb that conveys the meaning of what is happening. It’s a lot more intuitive than concat.apply().

This is the rare case where there is a definitive answer to the question of whether new syntax is better than old. Both experts, each of whom is familiar with the two syntax options, will choose the second. They’ll choose the shorter, clearer, more easily maintained line of code.

But choices and trade-offs aren’t always so decisive.

The gut check

The wonder of JavaScript is that it’s incredibly versatile. There is a reason it’s all over the web. Whether you think that’s a good or bad thing is another story.

But with that versatility comes the paradox of choice. You can write the same code in many different ways. How do you determine which way is “right”? You can’t even begin to make a decision unless you understand the available options and their limitations.

Let’s use functional programming with map() as the example. I’ll walk through various iterations that all yield the same result.

This is the tersest version of our map() examples. It uses the fewest characters, all fit into one line. This is our baseline.

const arr = [1, 2, 3];
let multipliedByTwo = arr.map(el => el * 2);
// multipliedByTwo is [2, 4, 6]

This next example adds only two characters: parentheses. Is anything lost? How about gained? Does it make a difference that a function with more than one parameter will always need to use the parentheses? I’d argue that it does. There is little to no detriment  in adding them here, and it improves consistency when you inevitably write a function with multiple parameters. In fact, when I wrote this, Prettier enforced that constraint; it didn’t want me to create an arrow function without the parentheses.

let multipliedByTwo = arr.map((el) => el * 2);

Let’s take it a step further. We’ve added curly braces and a return. Now this is starting to look more like a traditional function definition. Right now, it may seem like overkill to have a keyword as long as the function logic. Yet, if the function is more than one line, this extra syntax is again required. Do we presume that we will not have any other functions that go beyond a single line? That seems dubious.

let multipliedByTwo = arr.map((el) => {
  return el * 2;

Next we’ve removed the arrow function altogether. We’re using the same syntax as before, but we’ve swapped out for the function keyword. This is interesting because there is no scenario in which this syntax won’t work; no number of parameters or lines will cause problems, so consistency is on our side. It’s more verbose than our initial definition, but is that a bad thing? How does this hit a new coder, or someone who is well versed in something other than JavaScript? Is someone who knows JavaScript well going to be frustrated by this syntax in comparison?

let multipliedByTwo = arr.map(function(el) {
  return el * 2;

Finally we get to the last option: passing just the function. And timesTwo can be written using any syntax we like. Again, there is no scenario in which passing the function name causes a problem. But step back for a moment and think about whether or not this could be confusing. If you’re new to this codebase, is it clear that timesTwo is a function and not an object? Sure, map() is there to give you a hint, but it’s not unreasonable to miss that detail. How about the location of where timesTwo is declared and initialized? Is it easy to find? Is it clear what it’s doing and how it’s affecting this result? All of these are important considerations.

const timesTwo = (el) => el * 2;
let multipliedByTwo = arr.map(timesTwo);

As you can see, there is no obvious answer here. But making the right choice for your codebase means understanding all the options and their limitations. And knowing that consistency requires parentheses and curly braces and return keywords.

There are a number of questions you have to ask yourself when writing code. Questions of performance are typically the most common. But when you’re looking at code that is functionally identical, your determination should be based on humans—how humans consume code.

Maybe newer isn’t always better

So far we’ve found a clear-cut example of where both experts would reach for the newest syntax, even if it’s not universally known. We’ve also looked at an example that poses a lot of questions but not as many answers.

Now it’s time to dive into code that I’ve written before...and removed. This is code that made me the first expert, using a little-known piece of syntax to solve a problem to the detriment of my colleagues and the maintainability of our codebase.

Destructuring assignment lets you unpack values from objects (or arrays). It typically looks something like this.

const {node} = exampleObject;

It initializes a variable and assigns it a value all in one line. But it doesn’t have to.

let node
;({node} = exampleObject)

The last line of code assigns a variable to a value using destructuring, but the variable declaration takes place one line before it. It’s not an uncommon thing to want to do, but many people don’t realize you can do it.

But look at that code closely. It forces an awkward semicolon for code that doesn’t use semicolons to terminate lines. It wraps the command in parentheses and adds the curly braces; it’s entirely unclear what this is doing. It’s not easy to read, and, as an expert, it shouldn’t be in code that I write.

let node
node = exampleObject.node

This code solves the problem. It works, it’s clear what it does, and my colleagues will understand it without having to look it up. With the destructuring syntax, just because I can doesn’t mean I should.

Code isn’t everything

As we’ve seen, the Expert 2 solution is rarely obvious based on code alone; yet there are still clear distinctions between which code each expert would write. That’s because code is for machines to read and humans to interpret. So there are non-code factors to consider!

The syntax choices you make for a team of JavaScript developers is different than those you should make for a team of polyglots who aren’t steeped in the minutiae. 

Let’s take spread vs. concat() as an example.

Spread was added to ECMAScript a few years ago, and it’s enjoyed wide adoption. It’s sort of a utility syntax in that it can do a lot of different things. One of them is concatenating a number of arrays.

const arr1 = [1, 2, 3];
const arr2 = [9, 11, 13];
const nums = [...arr1, ...arr2];

As powerful as spread is, it isn’t a very intuitive symbol. So unless you already know what it does, it’s not super helpful. While both experts may safely assume a team of JavaScript specialists are familiar with this syntax, Expert 2 will probably question whether that’s true of a team of polyglot programmers. Instead, Expert 2 may select the concat() method instead, as it’s a descriptive verb that you can probably understand from the context of the code.

This code snippet gives us the same nums result as the spread example above.

const arr1 = [1, 2, 3];
const arr2 = [9, 11, 13];
const nums = arr1.concat(arr2);

And that’s but one example of how human factors influence code choices. A codebase that’s touched by a lot of different teams, for example, may have to hold more stringent standards that don’t necessarily keep up with the latest and greatest syntax. Then you move beyond the main source code and consider other factors in your tooling chain that make life easier, or harder, for the humans who work on that code. There is code that can be structured in a way that’s hostile to testing. There is code that backs you into a corner for future scaling or feature addition. There is code that’s less performant, doesn’t handle different browsers, or isn’t accessible. All of these factor into the recommendations Expert 2 makes.

Expert 2 also considers the impact of naming. But let’s be honest, even they can’t get that right most of the time.


Experts don’t prove themselves by using every piece of the spec; they prove themselves by knowing the spec well enough to deploy syntax judiciously and make well-reasoned decisions. This is how experts become multipliers—how they make new experts.

So what does this mean for those of us who consider ourselves experts or aspiring experts? It means that writing code involves asking yourself a lot of questions. It means considering your developer audience in a real way. The best code you can write is code that accomplishes something complex, but is inherently understood by those who examine your codebase.

And no, it’s not easy. And there often isn’t a clear-cut answer. But it’s something you should consider with every function you write.

Now THAT’S What I Call Service Worker!

The Service Worker API is the Dremel of the web platform. It offers incredibly broad utility while also yielding resiliency and better performance. If you’ve not used Service Worker yet—and you couldn’t be blamed if so, as it hasn’t seen wide adoption as of 2020—it goes something like this:

  1. On the initial visit to a website, the browser registers what amounts to a client-side proxy powered by a comparably paltry amount of JavaScript that—like a Web Worker—runs on its own thread.
  2. After the Service Worker’s registration, you can intercept requests and decide how to respond to them in the Service Worker’s fetch() event.

What you decide to do with requests you intercept is a) your call and b) depends on your website. You can rewrite requests, precache static assets during install, provide offline functionality, and—as will be our eventual focus—deliver smaller HTML payloads and better performance for repeat visitors.

Getting out of the woods

Weekly Timber is a client of mine that provides logging services in central Wisconsin. For them, a fast website is vital. Their business is located in Waushara County, and like many rural stretches in the United States, network quality and reliability isn’t great.

A screenshot of a wireless coverage map for Waushara County, Wisconsin with a color overlay. Most of the overlay is colored tan, which represents areas of the county which have downlink speeds between 3 and 9.99 megabits per second. There are sparse light blue and dark blue areas which indicate faster service, but are far from being the majority of the county.
Figure 1. A wireless coverage map of Waushara County, Wisconsin. The tan areas of the map indicate downlink speeds between 3 and 9.99 Mbps. Red areas are even slower, while the pale and dark blue areas are faster.

Wisconsin has farmland for days, but it also has plenty of forests. When you need a company that cuts logs, Google is probably your first stop. How fast a given logging company’s website is might be enough to get you looking elsewhere if you’re left waiting too long on a crappy network connection.

I initially didn’t believe a Service Worker was necessary for Weekly Timber’s website. After all, if things were plenty fast to start with, why complicate things? On the other hand, knowing that my client services not just Waushara County, but much of central Wisconsin, even a barebones Service Worker could be the kind of progressive enhancement that adds resilience in the places it might be needed most.

The first Service Worker I wrote for my client’s website—which I’ll refer to henceforth as the “standard” Service Worker—used three well-documented caching strategies:

  1. Precache CSS and JavaScript assets for all pages when the Service Worker is installed when the window’s load event fires.
  2. Serve static assets out of CacheStorage if available. If a static asset isn’t in CacheStorage, retrieve it from the network, then cache it for future visits.
  3. For HTML assets, hit the network first and place the HTML response into CacheStorage. If the network is unavailable the next time the visitor arrives, serve the cached markup from CacheStorage.

These are neither new nor special strategies, but they provide two benefits:

  • Offline capability, which is handy when network conditions are spotty.
  • A performance boost for loading static assets.

That performance boost translated to a 42% and 48% decrease in the median time to First Contentful Paint (FCP) and Largest Contentful Paint (LCP), respectively. Better yet, these insights are based on Real User Monitoring (RUM). That means these gains aren’t just theoretical, but a real improvement for real people.

A screenshot of request/response timings in Chrome's developer tools. It depicts a service worker on a page serving a static asset from CacheStorage in roughly 23 milliseconds.
Figure 2. A breakdown of request/response timings depicted in Chrome’s developer tools. The request is for a static asset from CacheStorage. Because the Service Worker doesn’t need to access the network, it takes about 23 milliseconds to “download” the asset from CacheStorage.

This performance boost is from bypassing the network entirely for static assets already in CacheStorage—particularly render-blocking stylesheets. A similar benefit is realized when we rely on the HTTP cache, only the FCP and LCP improvements I just described are in comparison to pages with a primed HTTP cache without an installed Service Worker.

If you’re wondering why CacheStorage and the HTTP cache aren’t equal, it’s because the HTTP cache—at least in some cases—may still involve a trip to the server to verify asset freshness. Cache-Control’s immutable flag gets around this, but immutable doesn’t have great support yet. A long max-age value works, too, but the combination of Service Worker API and CacheStorage gives you a lot more flexibility.

Details aside, the takeaway is that the simplest and most well-established Service Worker caching practices can improve performance. Potentially more than what well-configured Cache-Control headers can provide. Even so, Service Worker is an incredible technology with far more possibilities. It’s possible to go farther, and I’ll show you how.

A better, faster Service Worker

The web loves itself some “innovation,” which is a word we equally love to throw around. To me, true innovation isn’t when we create new frameworks or patterns solely for the benefit of developers, but whether those inventions benefit people who end up using whatever it is we slap up on the web. The priority of constituencies is a thing we ought to respect. Users above all else, always.

The Service Worker API’s innovation space is considerable. How you work within that space can have a big effect on how the web is experienced. Things like navigation preload and ReadableStream have taken Service Worker from great to killer. We can do the following with these new capabilities, respectively:

  • Reduce Service Worker latency by parallelizing Service Worker startup time and navigation requests.
  • Stream content in from CacheStorage and the network.

Moreover, we’re going to combine these capabilities and pull out one more trick: precache header and footer partials, then combine them with content partials from the network. This not only reduces how much data we download from the network, but it also improves perceptual performance for repeat visits. That’s innovation that helps everyone.

Grizzled, I turn to you and say “let’s do this.”

Laying the groundwork

If the idea of combining precached header and footer partials with network content on the fly seems like a Single Page Application (SPA), you’re not far off. Like an SPA, you’ll need to apply the “app shell” model to your website. Only instead of a client-side router plowing content into one piece of minimal markup, you have to think of your website as three separate parts:

  • The header.
  • The content.
  • The footer.

For my client’s website, that looks like this:

A screenshot of the Weekly Timber website color coded to delineate each partial that makes up the page. The header is color coded as blue, the footer as red, and the main content in between as yellow.
Figure 3. A color coding of the Weekly Timber website’s different partials. The Footer and Header partials are stored in CacheStorage, while the Content partial is retrieved from the network unless the user is offline.

The thing to remember here is that the individual partials don’t have to be valid markup in the sense that all tags need to be closed within each partial. The only thing that counts in the final sense is that the combination of these partials must be valid markup.

To start, you’ll need to precache separate header and footer partials when the Service Worker is installed. For my client’s website, these partials are served from the /partial-header and /partial-footer pathnames:

self.addEventListener("install", event => {
  const cacheName = "fancy_cache_name_here";
  const precachedAssets = [
    "/partial-header",  // The header partial
    "/partial-footer",  // The footer partial
    // Other assets worth precaching

  event.waitUntil(caches.open(cacheName).then(cache => {
    return cache.addAll(precachedAssets);
  }).then(() => {
    return self.skipWaiting();

Every page must be fetchable as a content partial minus the header and footer, as well as a full page with the header and footer. This is key because the initial visit to a page won’t be controlled by a Service Worker. Once the Service Worker takes over, then you serve content partials and assemble them into complete responses with the header and footer partials from CacheStorage.

If your site is static, this means generating a whole other mess of markup partials that you can rewrite requests to in the Service Worker’s fetch() event. If your website has a back end—as is the case with my client—you can use an HTTP request header to instruct the server to deliver full pages or content partials.

The hard part is putting all the pieces together—but we’ll do just that.

Putting it all together

Writing even a basic Service Worker can be challenging, but things get real complicated real fast when assembling multiple responses into one. One reason for this is that in order to avoid the Service Worker startup penalty, we’ll need to set up navigation preload.

Implementing navigation preload

Navigation preload addresses the problem of Service Worker startup time, which delays navigation requests to the network. The last thing you want to do with a Service Worker is hold up the show.

Navigation preload must be explicitly enabled. Once enabled, the Service Worker won’t hold up navigation requests during startup. Navigation preload is enabled in the Service Worker’s activate event:

self.addEventListener("activate", event => {
  const cacheName = "fancy_cache_name_here";
  const preloadAvailable = "navigationPreload" in self.registration;

  event.waitUntil(caches.keys().then(keys => {
    return Promise.all([
      keys.filter(key => {
        return key !== cacheName;
      }).map(key => {
        return caches.delete(key);
      preloadAvailable ? self.registration.navigationPreload.enable() : true

Because navigation preload isn’t supported everywhere, we have to do the usual feature check, which we store in the above example in the preloadAvailable variable.

Additionally, we need to use Promise.all() to resolve multiple asynchronous operations before the Service Worker activates. This includes pruning those old caches, as well as waiting for both clients.claim() (which tells the Service Worker to assert control immediately rather than waiting until the next navigation) and navigation preload to be enabled.

A ternary operator is used to enable navigation preload in supporting browsers and avoid throwing errors in browsers that don’t. If preloadAvailable is true, we enable navigation preload. If it isn’t, we pass a Boolean that won’t affect how Promise.all() resolves.

With navigation preload enabled, we need to write code in our Service Worker’s fetch() event handler to make use of the preloaded response:

self.addEventListener("fetch", event => {
  const { request } = event;

  // Static asset handling code omitted for brevity
  // ...

  // Check if this is a request for a document
  if (request.mode === "navigate") {
    const networkContent = Promise.resolve(event.preloadResponse).then(response => {
      if (response) {
        addResponseToCache(request, response.clone());

        return response;

      return fetch(request.url, {
        headers: {
          "X-Content-Mode": "partial"
      }).then(response => {
        addResponseToCache(request, response.clone());

        return response;
    }).catch(() => {
      return caches.match(request.url);

    // More to come...

Though this isn’t the entirety of the Service Worker’s fetch() event code, there’s a lot that needs explaining:

  1. The preloaded response is available in event.preloadResponse. However, as Jake Archibald notes, the value of event.preloadResponse will be undefined in browsers that don’t support navigation preload. Therefore, we must pass event.preloadResponse to Promise.resolve() to avoid compatibility issues.
  2. We adapt in the resulting then callback. If event.preloadResponse is supported, we use the preloaded response and add it to CacheStorage via an addResponseToCache() helper function. If not, we send a fetch() request to the network to get the content partial using a custom X-Content-Mode header with a value of partial.
  3. Should the network be unavailable, we fall back to the most recently accessed content partial in CacheStorage.
  4. The response—regardless of where it was procured from—is then returned to a variable named networkContent that we use later.

How the content partial is retrieved is tricky. With navigation preload enabled, a special Service-Worker-Navigation-Preload header with a value of true is added to navigation requests. We then work with that header on the back end to ensure the response is a content partial rather than the full page markup.

However, because navigation preload isn’t available in all browsers, we send a different header in those scenarios. In Weekly Timber’s case, we fall back to a custom X-Content-Mode header. In my client’s PHP back end, I’ve created some handy constants:


// Is this a navigation preload request?

// Is this an explicit request for a content partial?
define("PARTIAL_MODE", isset($_SERVER["HTTP_X_CONTENT_MODE"]) && stristr($_SERVER["HTTP_X_CONTENT_MODE"], "partial") !== false);

// If either is true, this is a request for a content partial
define("USE_PARTIAL", NAVIGATION_PRELOAD === true || PARTIAL_MODE === true);


From there, the USE_PARTIAL constant is used to adapt the response:


if (USE_PARTIAL === false) {


if (USE_PARTIAL === false) {


The thing to be hip to here is that you should specify a Vary header for HTML responses to take the Service-Worker-Navigation-Preload (and in this case, the X-Content-Mode header) into account for HTTP caching purposes—assuming you’re caching HTML at all, which may not be the case for you.

With our handling of navigation preloads complete, we can then move onto the work of streaming content partials from the network and stitching them together with the header and footer partials from CacheStorage into a single response that the Service Worker will provide.

Streaming partial content and stitching together responses

While the header and footer partials will be available almost instantaneously because they’ve been in CacheStorage since the Service Worker’s installation, it’s the content partial we retrieve from the network that will be the bottleneck. It’s therefore vital that we stream responses so we can start pushing markup to the browser as quickly as possible. ReadableStream can do this for us.

This ReadableStream business is a mind-bender. Anyone who tells you it’s “easy” is whispering sweet nothings to you. It’s hard. After I wrote my own function to merge streamed responses and messed up a critical step—which ended up not improving page performance, mind you—I modified Jake Archibald’s mergeResponses() function to suit my needs:

async function mergeResponses (responsePromises) {
  const readers = responsePromises.map(responsePromise => {
    return Promise.resolve(responsePromise).then(response => {
      return response.body.getReader();

  let doneResolve,

  const done = new Promise((resolve, reject) => {
    doneResolve = resolve;
    doneReject = reject;

  const readable = new ReadableStream({
    async pull (controller) {
      const reader = await readers[0];

      try {
        const { done, value } = await reader.read();

        if (done) {

          if (!readers[0]) {


          return this.pull(controller);

      } catch (err) {
        throw err;
    cancel () {

  const headers = new Headers();
  headers.append("Content-Type", "text/html");

  return {
    response: new Response(readable, {

As usual, there’s a lot going on:

  1. mergeResponses() accepts an argument named responsePromises, which is an array of Response objects returned from either a navigation preload, fetch(), or caches.match(). Assuming the network is available, this will always contain three responses: two from caches.match() and (hopefully) one from the network.
  2. Before we can stream the responses in the responsePromises array, we must map responsePromises to an array containing one reader for each response. Each reader is used later in a ReadableStream() constructor to stream each response’s contents.
  3. A promise named done is created. In it, we assign the promise’s resolve() and reject() functions to the external variables doneResolve and doneReject, respectively. These will be used in the ReadableStream() to signal whether the stream is finished or has hit a snag.
  4. The new ReadableStream() instance is created with a name of readable. As responses stream in from CacheStorage and the network, their contents will be appended to readable.
  5. The stream’s pull() method streams the contents of the first response in the array. If the stream isn’t canceled somehow, the reader for each response is discarded by calling the readers array’s shift() method when the response is fully streamed. This repeats until there are no more readers to process.
  6. When all is done, the merged stream of responses is returned as a single response, and we return it with a Content-Type header value of text/html.

This is much simpler if you use TransformStream, but depending on when you read this, that may not be an option for every browser. For now, we’ll have to stick with this approach.

Now let’s revisit the Service Worker’s fetch() event from earlier, and apply the mergeResponses() function:

self.addEventListener("fetch", event => {
  const { request } = event;

  // Static asset handling code omitted for brevity
  // ...

  // Check if this is a request for a document
  if (request.mode === "navigate") {
    // Navigation preload/fetch() fallback code omitted.
    // ...

    const { done, response } = await mergeResponses([


At the end of the fetch() event handler, we pass the header and footer partials from CacheStorage to the mergeResponses() function, and pass the result to the fetch() event’s respondWith() method, which serves the merged response on behalf of the Service Worker.

Are the results worth the hassle?

This is a lot of stuff to do, and it’s complicated! You might mess something up, or maybe your website’s architecture isn’t well-suited to this exact approach. So it’s important to ask: are the performance benefits worth the work? In my view? Yes! The synthetic performance gains aren’t bad at all:

A bar graph comparing First Contentful Paint and Largest Contentful Paint performance for the Weekly Timber website for scenarios in which there is no service worker, a "standard" service worker, and a streaming service worker that stitches together content partials from CacheStorage and the network. The first two scenarios are basically the same, while the streaming service worker delivers measurably better performance for both FCP and LCP—especially for FCP!
Figure 4. A bar chart of median FCP and LCP synthetic performance data across various Service Worker types for the Weekly Timber website.

Synthetic tests don’t measure performance for anything except the specific device and internet connection they’re performed on. Even so, these tests were conducted on a staging version of my client’s website with a low-end Nokia 2 Android phone on a throttled “Fast 3G” connection in Chrome’s developer tools. Each category was tested ten times on the homepage. The takeaways here are:

  • No Service Worker at all is slightly faster than the “standard” Service Worker with simpler caching patterns than the streaming variant. Like, ever so slightly faster. This may be due to the delay introduced by Service Worker startup, however, the RUM data I’ll go over shows a different case.
  • Both LCP and FCP are tightly coupled in scenarios where there’s no Service Worker or when the “standard” Service Worker is used. This is because the content of the page is pretty simple and the CSS is fairly small. The Largest Contentful Paint is usually the opening paragraph on a page.
  • However, the streaming Service Worker decouples FCP and LCP because the header content partial streams in right away from CacheStorage.
  • Both FCP and LCP are lower in the streaming Service Worker than in other cases.
A bar chart comparing the RUM median FCP and LCP performance of no service worker, a "standard" service worker, and a streaming service worker. Both the "standard" and streaming service worker offer better FCP and LCP performance over no service worker, but the streaming service worker excels at FCP performance, while only being slightly slower at LCP than the "standard" service worker.
Figure 5. A bar chart of median FCP and LCP RUM performance data across various Service Worker types for the Weekly Timber website.

The benefits of the streaming Service Worker for real users is pronounced. For FCP, we receive an 79% improvement over no Service Worker at all, and a 63% improvement over the “standard” Service Worker. The benefits for LCP are more subtle. Compared to no Service Worker at all, we realize a 41% improvement in LCP—which is incredible! However, compared to the “standard” Service Worker, LCP is a touch slower.

Because the long tail of performance is important, let’s look at the 95th percentile of FCP and LCP performance:

A bar chart comparing the RUM median FCP and LCP performance of no service worker, a "standard" service worker, and a streaming service worker. Both the "standard" and streaming service workers are faster than no service worker at all, but the streaming service worker beats out the "standard" service worker for both FCP and LCP.
Figure 6. A bar chart of 95th percentile FCP and LCP RUM performance data across various Service Worker types for the Weekly Timber website.

The 95th percentile of RUM data is a great place to assess the slowest experiences. In this case, we see that the streaming Service Worker confers a 40% and 51% improvement in FCP and LCP, respectively, over no Service Worker at all. Compared to the “standard” Service Worker, we see a reduction in FCP and LCP by 19% and 43%, respectively. If these results seem a bit squirrely compared to synthetic metrics, remember: that’s RUM data for you! You never know who’s going to visit your website on which device on what network.

While both FCP and LCP are boosted by the myriad benefits of streaming, navigation preload (in Chrome’s case), and sending less markup by stitching together partials from both CacheStorage and the network, FCP is the clear winner. Perceptually speaking, the benefit is pronounced, as this video would suggest:

Figure 7. Three WebPageTest videos of a repeat view of the Weekly Timber homepage. On the left is the page not controlled by a Service Worker, with a primed HTTP cache. On the right is the same page controlled by a streaming Service Worker, with CacheStorage primed.

Now ask yourself this: If this is the kind of improvement we can expect on such a small and simple website, what might we expect on a website with larger header and footer markup payloads?

Caveats and conclusions

Are there trade-offs with this on the development side? Oh yeah.

As Philip Walton has noted, a cached header partial means the document title must be updated in JavaScript on each navigation by changing the value of document.title. It also means you’ll need to update the navigation state in JavaScript to reflect the current page if that’s something you do on your website. Note that this shouldn’t cause indexing issues, as Googlebot crawls pages with an unprimed cache.

There may also be some challenges on sites with authentication. For example, if your site’s header displays the current authenticated user on log in, you may have to update the header partial markup provided by CacheStorage in JavaScript on each navigation to reflect who is authenticated. You may be able to do this by storing basic user data in localStorage and updating the UI from there.

There are certainly other challenges, but it’ll be up to you to weigh the user-facing benefits versus the development costs. In my opinion, this approach has broad applicability in applications such as blogs, marketing websites, news websites, ecommerce, and other typical use cases.

All in all, though, it’s akin to the performance improvements and efficiency gains that you’d get from an SPA. Only the difference is that you’re not replacing time-tested navigation mechanisms and grappling with all the messiness that entails, but enhancing them. That’s the part I think is really important to consider in a world where client-side routing is all the rage.

“What about Workbox?,” you might ask—and you’d be right to. Workbox simplifies a lot when it comes to using the Service Worker API, and you’re not wrong to reach for it. Personally, I prefer to work as close to the metal as I can so I can gain a better understanding of what lies beneath abstractions like Workbox. Even so, Service Worker is hard. Use Workbox if it suits you. As far as frameworks go, its abstraction cost is very low.

Regardless of this approach, I think there’s incredible utility and power in using the Service Worker API to reduce the amount of markup you send. It benefits my client and all the people that use their website. Because of Service Worker and the innovation around its use, my client’s website is faster in the far-flung parts of Wisconsin. That’s something I feel good about.

Special thanks to Jake Archibald for his valuable editorial advice, which, to put it mildly, considerably improved the quality of this article.

Keeping Your Design Mind New and Fresh

“Only a fool knows everything.”

African Proverb

Since March 2020, most of us have been working from home, and the days blend into each other and look the same. This is not the first time I have experienced this type of feeling. 

My commute — New York to New Jersey — is what folks in my area call the reverse commute.While going to the office, my days began to look the same: riding the subway to a bus to a shuttle to get to my job. Have you ever arrived at a destination and not even realized how you got there? This is how I began to experience the world everyday. I stopped paying attention to my surroundings.

Because I worked a lot, the only time I would take off was for the holidays. During this time, I was a consultant and was coming to the end of an existing contract. For six years straight, I did this, until I decided to take six weeks off work to travel to Europe and visit places I had not seen before.

A family friend let me stay with her in Munich, Germany; I did not speak German, and so began my adventure. I was in a new place, where I did not know anyone, and I got lost every single day. My eyes were opened to the fact that every day is an opportunity. It just took me going on a trip and traveling halfway around the world to realize it. There are new things to experience each and every day.

When I returned to the U.S. and went back to work, I made a conscious decision to make each day different. Sometimes I would walk a new route. Some days I would take another train. Each change meant I saw something new: new clothing, new buildings, and new faces. It really impacted the way I viewed myself in the world.

But what do you do when you cannot travel? Seeing a situation with new eyes takes practice, and you can still create the opportunity to see something by not taking your surroundings for granted.

How do we do this? For me, I adopted a new philosophy of being WOQE: watching, observing, questioning, and exploring.

Two people sit on a bench, one in a suit with arms crossed and the other wearing a backpack while looking through a camera. The letters WOQE surround them.


Let go of assumptions to open up your mind. This takes looking at yourself and understanding your beliefs.

When I am looking to design something, I always have to tell myself that I am not the user. I don’t know where they come from, and I don’t know their reason for making the decisions they do. I begin the work to understand where they are coming from. It all starts with why.


View the situation from different angles. Architects think about the details of a building and look at different viewpoints and perspectives (i.e., outside the building, different sides of the building, etc.)

How can you apply this approach to your designs? Here’s an example. I sketched something once as part of an augmented reality experience. Using my mobile device, I was able to walk around the sketch and see it from all sides, including the top and bottom. As a UX Designer, I have had to view items from both a user’s perspective and the business’ perspective. If I am giving a talk at a conference, I look at the talk from an audience perspective and my own.


Use the “5 Why Technique” to get to the root of the problem. This involves asking “why” 5 times.

You know how kids keep asking “why” when you answer a question from them? This approach is how you can get to the root of problems. For example, a friend of mine who is blind expressed interest in playing a popular augmented reality game. This intrigued me and I used a whiteboard as I worked through the 5 Whys with my friend. Here is the process we took:

“Why can’t someone who is blind play Pokémon Go?” I asked.

“Because the game is visual and requires someone to see what is on the screen.”

“Why is the game only a visual perspective?”

“Because this is the way it was designed.”

“Why was it designed this way?”

“Because frequently designers are creating for themselves and may not think about who they might be excluding.”

“Why are designers excluding people?”

“Because they were never taught to include them.”

“Why were they never taught?”

“Design programs often do not include an inclusive and accessible curriculum.”

This may not be a scientific way of approaching a problem, but it is a starting point. My friend could not play this augmented reality game because designers were not taught to make this game for someone who is blind. After this exercise, I was able to work with a group of students who worked with my friend to create an augmented reality concept and ultimately a game using audio and haptic feedback.

It all started with why.


Collaborate with others to learn from others and teach others what you know. Let your friends and colleagues know what you are working on, and perhaps talk it through with them.

When I was a freelance designer, I worked on my own and found it challenging when I would get stuck on a design. I searched online and found a group of designers who would come and share their work with each other for feedback. Through this group, I was able to get some insightful comments on my designs and explain some of my decisions. I began to collaborate with the folks in the group and found it very helpful. When talking to clients, this made me feel more confident explaining my designs because I had already been through the process with my online group.

With all of our days blending into each other in this pandemic, we as designers have an unprecedented opportunity to really shake things up. Furthermore, we are problem solvers. As you move forward with your design practice, consider being WOQE to design with a fresh mind.

How to Get a Dysfunctional Team Back on Track

Maybe you’ve been part of a team that you’ve seen slowly slide into a rut. You didn’t notice it happen, but you’re now not shipping anything, no one’s talking to each other, and the management’s Eye of Sauron has cast its gaze upon you.

Maybe you’ve just joined a team that’s in the doldrums.

Maybe the people who used to oil the wheels that kept everyone together have moved on and you’re having to face facts—you all hate each other.

However you’ve ended up in this situation, the fact is that you’re now here and it’s up to someone to do something about it. And that person might be you.

You’re not alone

The first thing to understand is that you’re not the only person to ever encounter problems. Things like this happen all the time at work, but there are simple steps you can take and habits you can form to ease the situation and even dig yourself (and your team) out of the hole. I’ll share some techniques that have helped me, and maybe they can work for you, too.

So let me tell you a story about a hot mess I found myself in and how we turned it around. Names and details have been changed to protect the innocent.

It always starts out great

An engineer called Jen was working with me on a new feature on our product that lets people create new meal recipes themselves. I was the Project Manager. We were working in six-week cycles.

She had to rely on an API that was managed by Tom (who was in another team) to allow her to get and set the new recipe information on a central database. Before we kicked off, everyone knew the overall objective and everyone was all smiles and ready to go.

The system architecture was a legacy mishmash of different parts of local databases and API endpoints. And, no prizes for guessing what’s coming next, the API documentation was like Swiss cheese.

Two weeks into a six-week cycle, Jen hit Tom up with a list of her dream API calls that she wanted to use to build her feature. She asked him to confirm or deny they would work—or even if they existed at all—because once she started digging into the docs, it wasn’t clear to her if the API could support her plans.

However, Tom had form for sticking his head in the sand and not responding to requests he didn’t like. Tom went to ground and didn’t respond. Tom’s manager, Frankie, was stretched too thin, and hence wasn’t paying attention to this until I was persistently asking about it, in increasingly fraught tones.

In the meantime, Jen tried to do as much as she could. Every day she built a bit more based on her as-yet unapproved design, hoping it would all work out.

With two weeks left to go, Tom eventually responded with a short answer—which boiled down to “The API doesn’t support these calls and I don’t see why I should build something that does. Why don’t you get the data from the other part of the system? And by the way, if I’m forced to do this, it will take at least six weeks.”

And as we know, six weeks into two weeks doesn’t go. Problem.

How did we sort it?

Step 1 — Accept

When things go south, what do you do?

Accept it.

Acknowledge whatever has happened to get you into this predicament. Take some notes about it to use in team appraisals and retrospectives. Take a long hard look at yourself, too.

Write a concise, impersonal summary of where you are. Try not to write it from your point of view. Imagine that you’re in your boss’ seat and just give them the facts as they are. Don’t dress things up to make them sound better. Don’t over-exaggerate the bad. Leave the emotions to the side.

When you can see your situation clearly, you’ll make better decisions.

Now, pointing out the importance of taking some time to cool down and gather your thoughts seems obvious, but it’s based on the study of some of the most basic circuitry in our brains. Daniel Goleman’s 1995 book, Emotional Intelligence: Why It Can Matter More Than IQ, introduces the concept of emotional hijacking; the idea that the part of our brain that deals with emotion—the limbic system—can biologically interrupt rational thinking when it is overstimulated. For instance, experiments show that the angrier men get, the poorer are the decisions they make at the casino. And another study found that people in a negative emotional state are more likely to deviate from logical norms. To put it another way, if you’re pissed off, you can’t think straight.

So when you are facing up to the facts, avoid the temptation to keep it off-the-record and only discuss it on the telephone or in person with your colleagues. There’s nothing to be scared of by writing it down. If it turns out that you’re wrong about something, you can always admit it and update your notes. If you don’t write it down, then there’s always scope for misunderstanding or misremembering in future.

In our case, we summarized how we’d ended up at that juncture; the salient points were:

  • I hadn’t checked to ensure we had scoped it properly before committing to the work. It wasn’t a surprise that the API coverage was patchy, but I turned a blind eye because we were excited about the new feature.
  • Jen should have looked for the hard problem first rather than do a couple of weeks’ worth of nice, easy work around the edges. That’s why we lost two weeks off the top.
  • Tom and Frankie’s communication was poor. The reasons for that don’t form part of this discussion, but something wasn’t right in that team.

And that’s step one.

Step 2 — Rejoice

Few people like to make mistakes, but everyone will make one at some point in their life. Big ones, small ones, important ones, silly ones—we all do it. Don’t beat yourself up.

A Venn diagram with one circle showing the set of people who make mistakes. In a smaller circle completely inside the first is the set of people who think they don't make mistakes.

At the start of my career, I worked on a team whose manager had a very high opinion of himself. He was good, but what I learned from him was that he spread that confidence around the team. If something was looking shaky, he insisted that if we could “smell smoke,” that he had to be the first to know so he could do something about it. If we made a mistake, there was no hiding from it. We learned how to face up to it and accept responsibility, but what was more important was learning from him the feeling we were the best people to fix it.

There was no holding of grudges. What was done, was done. It was all about putting it behind us.

He would tell us that we were only in this team because he had handpicked us because we were the best and he only wanted the best around him. Now, that might all have been manipulative nonsense, but it worked.

The only thing you can control is what you do now, so try not to fret about what happened in the past or get anxious about what might happen in the future.

With that in mind, once you’ve written the summary of your sticky situation, set it aside!

I’ll let you in on a secret. No one else is interested in how you got here. They might be asking you about it (probably because they are scared that someone will ask them), but they’re always going to be more interested in how you’re going to sort the problem out.

So don’t waste time pointing fingers. Don’t prepare slide decks to throw someone under the bus. Tag that advice with a more general “don’t be an asshole” rule.

If you’re getting consistent heat about the past, it’s because you’re not doing a good enough job filling the bandwidth with a solid, robust, and realistic plan for getting out of the mess.

So focus on the future.

Sometimes it’s not easy to do that, but remember that none of this is permanent. Trust in the fact that if you pull it together, you’ll be in a much more powerful position to decide what to do next.

Maybe the team will hold together with a new culture or, if it is irretrievably broken, once you’re out of the hole then you can do something about it and switch teams or even switch jobs. But be the person who sorted it out, or at the very least, be part of the gang who sorted it out. That will be obvious to outsiders and makes for a much better interview question response.

In our story with Jen, we had a short ten-minute call with everyone involved on the line. We read out the summary and asked if anyone had anything to add.

Tom spoke up and said that he never gets time to update the API documentation because he always has to work on emergencies. We added that to our summary:

  • Tom has an ongoing time management problem. He doesn’t have enough time allocated to maintain and improve the API documentation.

After that was added, everyone agreed that the summary was accurate.

I explained that the worst thing that could now happen was that we had to report back to the wider business that we’d messed up and couldn’t hit our deadline.

If we did that, we’d lose face. There would be real financial consequences. It would show up on our appraisals. It wouldn’t be good. It wouldn’t be the end of the world, but it wasn’t something that we wanted. Everyone probably knew all that already, but there’s a power in saying it out loud. Suddenly, it doesn’t seem so scary.

Jen spoke up to say that she was new here and really didn’t want to start out like this. There was some murmuring in general support. I wrapped up that part of the discussion.

I purposefully didn’t enter into a discussion about the solution yet. We had all come together to admit the circumstances we were in. We’d done that. It was enough for now.

Step 3 — Move on

Stepping back for a second, as the person who is going to lead the team out of the wilderness, you may want to start getting in everyone’s face. You’ll be tempted to rely on your unlimited reserves of personal charm or enthusiasm to vibe everyone up. Resist the urge! Don’t do it!

Your job is to give people the space to let them do their best work.

I learned this the hard way. I’m lucky enough that I can bounce back quickly, but when someone is under pressure, funnily enough, a super-positive person who wants to throw the curtains open and talk about what a wonderful day it is might not be the most motivational person to be around. I’ve unwittingly walked into some short-tempered conversations that way.

Don’t micromanage. In fact, scrap all of your management tricks. Your job is to listen to what people are telling you—even if they’re telling you things by not talking.

Reframe the current problem. Break it up into manageable chunks.

The first task to add to your list of things to do is simply to “Decide what we’re going to do about [the thing].”

It’s likely that there’s a nasty old JIRA ticket that everyone has been avoiding or has been bounced back and forth between different team members. Set that aside. There’s too much emotional content invested in that ticket now.

Create a new task that’s entirely centered on making a decision. Now, break it down into subtasks for each member of the team, like “Submit a proposal for what to do next.” Put your own suggestions in the mix but do your best to dissociate yourself from them.

Once you start getting some suggestions back and can tick those tasks off the list, you start to generate positive momentum. Nurture that.

If a plan emerges, champion it. Be wary of naysayers. Challenge them respectfully with “How do you think we should…?” questions. If they have a better idea, champion that instead; if they don’t respond at all, then gently suggest “Maybe we should go with this if no one else has a better idea.”

Avoid words like “need,” “just,” “one,” or “small.” Basically, anything that imposes a view of other people’s work. It seems trivial, but try to see it from the other side.

Saying, “I just need you to change that one small thing” hits the morale-killing jackpot. It unthinkingly diminishes someone else’s efforts. An engineer or a designer could reasonably react by thinking “What do you know about how to do this?!” Your job is to help everyone drop their guard and feel safe enough to contribute.

Instead, try “We’re all looking at you here because you’re good at this and this is a nasty problem. Maybe you know a way to make this part work?”

More often than not, people want to help.

So I asked Jen, Tom, and Frankie to submit their proposals for a way through the mess.

It wasn’t straightforward. Just because we’d all agreed how we got here didn’t just magically make all the problems disappear. Tom was still digging his heels in about not wanting to write more code, and kept pushing back on Jen.

There was a certain amount of back and forth. Although, with some constant reminders that we should maybe focus on what will move us forward, we eventually settled on a plan.

Like most compromises, it wasn’t pretty or simple. Jen was going to have to rely on using the local database for a certain amount of the lower-priority features. Tom was going to have to create some additional API functions and would end up with some unnecessary traffic that might create too much load on the API.

And even with the compromise, Tom wouldn’t be finished in time. He’d need another couple of weeks.

But it was a plan!

N.B. Estimating is a whole other subject that I won’t cover here. Check out the Shape Up process for some great advice on that.

Step 4 — Spread the word

Once you’ve got a plan, commit to it and tell everyone affected what’s going on.

When communicating with people who are depending on you, take the last line of your email, which usually contains the summary or the “ask,” and put it at the top. When your recipient reads the message, the opener is the meat. Good news or bad news, that’s what they’re interested in. They’ll read on if they want more.

If it’s bad news, set someone up for it with a simple “I’m sorry to say I’ve got bad news” before you break it to them. No matter who they are, kindly framing the conversation will help them digest it.

When discussing it with the team, put the plan somewhere everyone can see it. Transparency is key.

Don’t pull any moves—like publishing deadline dates to the team that are two weeks earlier than the date you’ve told the business. Teams aren’t stupid. They’ll know that’s what you do.

Publish the new deadlines in a place where everyone on the team can see them, and say we’re aiming for this date but we’re telling the business that we’ll definitely be done by that date.

In our case, I posted an update to the rest of the business as part of our normal weekly reporting cycle to announce we’d hit a bump that was going to affect our end date.

Here’s an extract:

Hi everyone,

Here’s the update for the week. I’m afraid there’s a bit of bad news to start but there is some good news too.


We uncovered a misunderstanding between Jen and Tom this week. The outcome is that Tom has more API work to do than he anticipated. This affects the delivery date and means we’re now planning to finish 10 working days later on November 22.

**Expected completion date ** CHANGED ****
Original estimate: November 8
Current estimate: November 22


We successfully released version 1.3 of the app into the App Store 🎉.

And so on...

That post was available for everyone within the team to see. Everyone knew what was to be done and what the target was.

I had to field some questions from above, but I was ready with my summary of what went wrong and what we’d all agreed to do as a course of action. All I had to do was refer to it. Then I could focus on sharing the plan.

And all manner of things shall be well

Now, I’d like to say that we then had tea and scones every day for the next month and it was all rather spiffing. But that would be a lie.

There was some more wailing and gnashing of teeth, but we all got through it and—even though we tried to finish early but failed—we did manage to finish by the November 22 date.

And then, after a bit of a tidy up, we all moved on to the next project, a bit older and a bit wiser. I hope that helps you if you’re in a similar scenario. Send me a tweet or email me at liam.nugent@hey.com with any questions or comments. I’d love to hear about your techniques and advice.

The Future of Web Software Is HTML-over-WebSockets

The future of web-based software architectures is already taking form, and this time it’s server-rendered (again). Papa’s got a brand new bag: HTML-over-WebSockets and broadcast everything all the time.

The dual approach of marrying a Single Page App with an API service has left many dev teams mired in endless JSON wrangling and state discrepancy bugs across two layers. This costs dev time, slows release cycles, and saps the bandwidth for innovation.

But a new WebSockets-driven approach is catching web developers’ attention. One that reaffirms the promises of classic server-rendered frameworks: fast prototyping, server-side state management, solid rendering performance, rapid feature development, and straightforward SEO. One that enables multi-user collaboration and reactive, responsive designs without building two separate apps. The end result is a single-repo application that feels to users just as responsive as a client-side all-JavaScript affair, but with straightforward templating and far fewer loading spinners, and no state misalignments, since state only lives in one place. All of this sets us up for a considerably easier (and faster!) development path. 

Reclaiming all of that time spent addressing architecture difficulties grants you a pool of surplus hours that you can use to do awesome. Spend your dev budget, and your company’s salary budget, happily building full-stack features yourself, and innovating on things that benefit your company and customers. 

And in my opinion, there’s no better app framework for reclaiming tedious development time than Ruby on Rails. Take another look at the underappreciated Stimulus. Beef up the View in your MVC with ViewComponents. Add in the CableReady and StimulusReflex libraries for that Reactive Rails (as it has been dubbed) new car smell, and you’re off to the races. But we’ll get back to Rails in a bit...

This all started with web frameworks...

Web frameworks burst onto the scene around 2005 amidst a sea of mostly figure-it-out-for-yourself scripting language libraries glued together and thrown onto hand-maintained Apache servers. This new architecture promised developers a more holistic approach that wrapped up all the fiddly stuff in no-touch conventions, freeing developers to focus on programming ergonomics, code readability, and fast-to-market features. All a developer had to do was learn the framework’s core language, get up to speed on the framework itself and its conventions, and then start churning out sophisticated web apps while their friends were still writing XML configuration files for all those other approaches.

Despite the early criticisms that always plague new approaches, these server-rendered frameworks became tools of choice, especially for fast-moving startups—strapped for resources—that needed an attractive, feature-rich app up yesterday.

But then the JavaScript everything notion took hold...

As the web development world pushed deeper into the 2010s, the tides began to turn, and server-rendered frameworks took something of a backseat to the Single Page Application, wholly built in JavaScript and run entirely on the client’s computer. At many companies, the “server” became relegated to hosting an API data service only, with most of the business logic and all of the HTML rendering happening on the client, courtesy of the big ’ol package of JavaScript that visitors were forced to download when they first hit the site. 

This is where things started to get ugly.

Fast-forward to 2020 and the web isn’t getting any faster, as we were promised it would with SPAs. Shoving megabytes of JavaScript down an iPhone 4’s throat doesn’t make for a great user experience. And if you thought building a professional web app took serious resources, what about building a web app and an API service and a communication layer between them? Do we really believe that every one of our users is going to have a device capable of digesting 100 kB of JSON and rendering a complicated HTML table faster than a server-side app could on even a mid-grade server?

Developing and hosting these JavaScript-forward apps didn’t get any cheaper either. In many cases we’re now doing twice the work, and maybe even paying twice the developers, to achieve the same results we had before with server-side app development.

In 2005, app frameworks blew everyone’s minds with “build a blog app in 15 minutes” videos. Fifteen years later, doing the same thing with an SPA approach can require two codebases, a JSON serialization layer, and dozens of spinners all over the place so we can still claim a 50ms First Contentful Paint. Meanwhile, the user watches some blank gray boxes, hoping for HTML to finally render from all the JSON their browser is requesting and digesting. 

How did we get here? This is not my beautiful house! Were we smart in giving up all of that server-rendered developer happiness and doubling down on staff and the time to implement in order to chase the promise of providing our users some fancier user interfaces?

Well. Yes. Sort of.

We’re not building web software for us. We’re building it for them. The users of our software have expectations of how it’s going to work for them. We have to meet them where they are. Our users are no longer excited about full-page refreshes and ugly Rube Goldberg-ian multi-form workflows. The SPA approach was the next logical leap from piles of unorganized spaghetti JavaScript living on the server. The problem, though: it was a 5% improvement, not a 500% improvement. 

Is 5% better worth twice the work? What about the developer cost?

Bedazzling the web app certainly makes things fancier from the user’s perspective. Done well, it can make the app feel slicker and more interactive, and it opens up a wealth of new non-native interaction elements. Canonizing those elements as components was the next natural evolution. Gone are the days of thinking through how an entire HTML document could be mutated to give the illusion of the user interacting with an atomic widget on the page—now, that can be implemented directly, and we can think about our UX in terms of component breakdowns. But, alas, the costs begin to bite us almost immediately.

Go ahead, write that slick little rating stars component. Add some cool animations, make the mouseover and click area feel good, give some endorphin-generating feedback when a selection is made. But now what? In a real app, we need to persist that change, right? The database has to be changed to reflect this new state, and the app in front of the user’s eyes needs to reflect that new reality too. 

In the old days, we’d give the user a couple star GIFs, each a link that hit the same server endpoint with a different param value. Server-side, we’d save that change to the database, then send back a whole new HTML page for their browser to re-render; maybe we’d even get fancy and use AJAX to do it behind the scenes, obviating the need for the full HTML and render. Let’s say the former costs x in developer time and salary (and we won’t even talk about lost opportunity cost for features rolled out too late for the market). In that case, the fancy AJAX-based approach costs x + n (you know, some “extra JavaScript sprinkles”), but the cost of lots and lots of n grows as our app becomes more and more of a JavaScript spaghetti sprinkles mess.

Over in the SPA world, we’re now writing JavaScript in the client-side app and using JSX or Handlebars templates to render the component, then code to persist that change to the front-end data store, then a PUT request to the API, where we’re also writing an API endpoint to handle the request, a JSON serializer (probably with its own pseudo-template) to package up our successful response, and then front-end code to ensure we re-render the component (and some branching logic to maybe rollback and re-render the client-side state change if the backend failed on us). This costs a lot more than even x + n in developer time and salary. And if you’ve split your team into “front-end” and “back-end” people, you might as well go ahead and double that cost (both time and money) for many non-trivial components where you need two different people to finish the implementation. Sure, the SPA mitigates some of the ever-growing spaghetti problem, but at what cost for a business racing to be relevant in the market or get something important out to the people who need it?

One of the other arguments we hear in support of the SPA is the reduction in cost of cyber infrastructure. As if pushing that hosting burden onto the client (without their consent, for the most part, but that’s another topic) is somehow saving us on our cloud bills. But that’s ridiculous. For any non-trivial application, you’re still paying for a server to host the API and maybe another for the database, not to mention load balancers, DNS, etc. And here’s the thing: none of that cost even comes close to what a software company pays its developers! Seriously, think about it. I’ve yet to work at any business where our technical infrastructure was anything more than a fraction of our salary overhead. And good developers expect raises. Cloud servers generally just get cheaper over time.

If you want to be efficient with your money—especially as a cash-strapped startup—you don’t need to cheap out on cloud servers; you need to get more features faster out of your existing high-performance team.

In the old, old days, before the web frameworks, you’d pay a developer for six weeks to finally unveil…the log-in page. Cue the sad trombone. Then frameworks made that log-in page an hour of work, total, and people were launching web startups overnight. The trumpets sound! Now, with our SPA approach, we’re back to a bunch of extra work. It’s costing us more money because we’re writing two apps at once. There’s that trombone again...

We’re paying a lot of money for that 5% user experience improvement.

But what if we could take the best client-side JavaScript ideas and libraries from that 5% improvement and reconnect them with the developer ergonomics and salary savings of a single codebase? What if components and organized JavaScript could all live in one rock-solid app framework optimized for server-side rendering? What if there is a path to a 500% jump?

Sound impossible? It’s not. I’ve seen it, like C-beams glittering in the dark near the Tannhäuser Gate. I’ve built that 500% app, in my free time, with my kids running around behind me barking like dogs. Push broadcasts to logged-in users. Instant updates to the client-side DOM in milliseconds. JavaScript-driven 3D animations that interact with real-time chat windows. All in a single codebase, running on the same server hardware I’d use for a “classic” server-rendered app (and maybe I can even scale that hardware down since I’m rendering HTML fragments more often than full-page documents). No separate front-end app. Clean, componentized JavaScript and server-side code, married like peanut butter and jelly. It’s real, I tell you!

Socket to me! (Get it? Get it? Ah, nevermind...)

Finalized in 2011, support for WebSockets in modern browsers ramped up throughout the 2010s and is now fully supported in all modern browsers. With the help of a small bit of client-side JavaScript, you get a full-duplex socket connection between browser and server. Data can pass both ways, and can be pushed from either side at any time, no user-initiated request needed.

Like the game industry’s ever-expanding moves into cloud-based gaming, the future of web apps is not going to be about pushing even heavier obligations onto the user/client, but rather the opposite: let the client act as a thin terminal that renders the state of things for the human. WebSockets provide the communication layer, seamless and fast; a direct shot from the server to the human.

But this wasn’t terribly easy for many developers to grok at first. I sure didn’t. And the benefits weren’t exactly clear either. After years (decades, even) of wrapping our heads around the HTTP request cycle, to which all server-handled features must conform, adopting this WebSocket tech layer required a lot of head scratching. As with many clever new technologies or protocols, we needed a higher-level abstraction that provided something really effective for getting a new feature in front of a user, fast.

Enter HTML-over-WebSockets...

Want a hyper-responsive datalist typeahead that is perfectly synced with the database? On every keystroke, send a query down the WebSocket and get back precisely the changed set of option tags, nothing more, nothing less.

How about client-side validations? Easy. On every input change, round up the form values and send ’em down the WebSocket. Let your server framework validate and send back changes to the HTML of the form, including any errors that need to be rendered. No need for JSON or complicated error objects.

User presence indicators? Dead simple. Just check who has an active socket connection.

What about multi-user chat? Or document collaboration? In classic frameworks and SPAs, these are the features we put off because of their difficulty and the code acrobatics needed to keep everyone’s states aligned. With HTML-over-the-wire, we’re just pushing tiny bits of HTML based on one user’s changes to every other user currently subscribed to the channel. They’ll see exactly the same thing as if they hit refresh and asked the server for the entire HTML page anew. And you can get those bits to every user in under 30ms.

We’re not throwing away the promise of components either. Where this WebSockets-based approach can be seen as a thick server/thin client, so too can our components. It’s fractal, baby! Make that component do delightful things for the user with smart JavaScript, and then just ask the server for updated HTML, and mutate the DOM. No need for a client-side data store to manage the component’s state since it’ll render itself to look exactly like what the server knows it should look like now. The HTML comes from the server, so no need for JSX or Handlebars or <insert other JavaScript templating library here>. The server is always in control: rendering the initial component’s appearance and updating it in response to any state change, all through the socket. 

And there’s nothing saying you have to use those socket channels to send only HTML. Send a tiny bit of text, and have the client do something smart. Send a chat message from one user to every other user, and have their individual clients render that message in whatever app theme they’re currently using. Imagine the possibilities!

But it’s complex/expensive/requires a bunch of new infrastructure, right?

Nope. Prominent open-source web servers support it natively, generally without needing any kind of extra configuration or setup. Many server-side frameworks will automatically ship the JS code to the client for native support in communicating over the socket. In Rails, for example, setting up your app to use WebSockets is as easy as configuring the built-in ActionCable and then deploying as usual on the same hardware you would have used otherwise. Anecdotally, the typical single Rails server process seems to be perfectly happy supporting nearly 4,000 active connections. And you can easily swap in the excellent AnyCable to bump that up to around 10,000+ connections per node by not relying on the built-in Ruby WebSocket server. Again, this is on the usual hardware you’d be running your web server on in the first place. You don’t need to set up any extra hardware or increase your cloud infrastructure.

This new approach is quickly appearing as extensions, libraries, or alternative configurations in a variety of languages and web frameworks, from Django’s Sockpuppet to Phoenix’s LiveView and beyond. Seriously, go dig around for WebSockets-based libraries for your favorite app framework and then step into a new way of thinking about your app architectures. Build something amazing and marvel at the glorious HTML bits zipping along on the socket, like jet fighters passing in the night. It’s more than a new technical approach; it’s a new mindset, and maybe even a new wellspring of key app features that will drive your startup success.

But I’d be remiss if I didn’t highlight for the reader my contender for Best Framework in a Leading Role. Sure, any app framework can adopt this approach, but for my money, there’s a strong case to be made that the vanguard could be Ruby on Rails. 

So we come back around to Rails, 15 years on from its launch...

Set up a Rails 6 app with the latest versions of Turbolinks, Stimulus, StimulusReflex, CableReady, and GitHub’s ViewComponent gem, and you can be working with Reactive Rails in a way that simultaneously feels like building a classic Rails app and like building a modern, componentized SPA, in a single codebase, with all the benefits of server-side rendering, HTML fragment caching, easy SEO, rock-solid security, and the like. You’ll suddenly find your toolbelt bursting with straightforward tools to solve previously daunting challenges.

Oh, and with Turbolinks, you also get wrappers allowing for hybrid native/HTML UIs in the same codebase. Use a quick deploy solution like Heroku or Hatchbox, and one developer can build a responsive, reactive, multi-platform app in their spare time. Just see this Twitter clone if you don’t believe me. 

OK, that all sounds exciting, but why Rails specifically? Isn’t it old and boring? You already said any framework can benefit from this new WebSocket, DOM-morphing approach, right? 

Sure. But where Rails has always shined is in its ability to make rapid prototyping, well…rapid, and in its deep ecosystem of well-polished gems. Rails also hasn’t stopped pushing the envelope forward, with the latest version 6.1.3 of the framework boasting a ton of cool features. 

If you’ve got a small, resource-strapped team, Rails (and Ruby outside of the framework) still serves as a potent force multiplier that lets you punch way above your weight, which probably explains the $92 billion in revenue it’s helped drive over the years. With this new approach, there’s a ton more weight behind that punch. While your competitors are fiddling with their JSON serializers and struggling to optimize away all the loading spinners, you’re rolling out a new multi-user collaborative feature every week…or every day

You win. Your fellow developers win. Your business wins. And, most importantly, your users win.

That’s what Rails promised from the day it was released to the community. That’s why Rails spawned so many imitators in other languages, and why it saw such explosive growth in the startup world for years. And that same old rapid prototyping spirit, married to this new HTML-over-the-wire approach, positions Rails for a powerful resurgence. 

Ruby luminary and author of The Ruby Way, Obie Fernandez, seems to think so.

Heck, even Russ Hanneman thinks this approach with StimulusReflex is the new hotness.

And the good folks over at Basecamp (creators of Rails in the first place), dropped their own take on the concept, Hotwire, just in time for the 2020 holidays, so your options for tackling this new and exciting technique continue to expand.

Don’t call it a comeback, because Rails has been here for years. With this new architectural approach, brimming with HTML-over-WebSockets and full-duplex JavaScript interactions, Rails becomes something new, something beautiful, something that demands attention (again). 

Reactive Rails, with StimulusReflex and friends, is a must-look for anyone exhausted from toiling with JSON endpoints or JSX, and I’m super excited to see the new crop of apps that it enables.

Designing Inclusive Content Models

In the 1920s, Robert Moses designed a system of parkways surrounding New York City. His designs, which included overpasses too low for public buses, have become an often-cited example of exclusionary design and are argued by biographer Robert A. Caro to represent a purposeful barrier between the city’s Black and Puerto Rican residents and nearby beaches. 

Regardless of the details of Moses’s parkway project, it’s a particularly memorable reminder of the political power of design and the ways that choices can exclude various groups based on abilities and resources. The growing interest in inclusive design highlights questions of who can participate, and in relation to the web, this has often meant a focus on accessibility and user experience, as well as on questions related to team diversity and governance. 

But principles of inclusive design should also play a role early in the design and development process, during content modeling. Modeling defines what content objects consist of and, by extension, who will be able to create them. So if web professionals are interested in inclusion, we need to go beyond asking who can access content and also think about how the design of content can install barriers that make it difficult for some people to participate in creation. 

Currently, content models are primarily seen as mirrors that reflect inherent structures in the world. But if the world is biased or exclusionary, this means our content models will be too. Instead, we need to approach content modeling as an opportunity to filter out harmful structures and create systems in which more people can participate in making the web. Content models designed for inclusivity welcome a variety of voices and can ultimately increase products’ diversity and reach.

Content models as mirrors

Content models are tools for describing the objects that will make up a project, their attributes, and the possible relations between them. A content model for an art museum, for example, would typically describe, among other things, artists (including attributes such as name, nationality, and perhaps styles or schools), and artists could then be associated with artworks, exhibitions, etc. (The content model would also likely include objects like blog posts, but in this article we’re interested in how we model and represent objects that are “out there” in the real world, rather than content objects like articles and quizzes that live natively on websites and in apps.)

The common wisdom when designing content models is to go out and research the project’s subject domain by talking with subject matter experts and project stakeholders. As Mike Atherton and Carrie Hane describe the process in Designing Connected Content, talking with the people who know the most about a subject domain (like art in the museum example above) helps to reveal an “inherent” structure, and discovering or revealing that structure ensures that your content is complete and comprehensible.

Additional research might go on to investigate how a project’s end users understand a domain, but Atherton and Hane describe this stage as mostly about terminology and level of detail. End users might use a different word than experts do or care less about the nuanced distinctions between Fauvism and neo-Expressionism, but ultimately, everybody is talking about the same thing. A good content model is just a mirror that reflects the structure you find.  

Cracks in the mirrors

The mirror approach works well in many cases, but there are times when the structures that subject matter experts perceive as inherent are actually the products of biased systems that quietly exclude. Like machine learning algorithms trained on past school admissions or hiring decisions, existing structures tend to work for some people and harm others. Rather than recreating these structures, content modelers should consider ways to improve them. 

A basic example is LinkedIn’s choice to require users to specify a company when creating a new work experience. Modeling experience in this way is obvious to HR managers, recruiters, and most people who participate in conventional career paths, but it assumes that valuable experience is only obtained through companies, and could potentially discourage people from entering other types of experiences that would allow them to represent alternative career paths and shape their own stories.

Figure 1. LinkedIn’s current model for experience includes Company as a required attribute.

These kinds of mismatches between required content attributes and people’s experiences either create explicit barriers (“I can’t participate because I don’t know how to fill in this field”) or increase the labor required to participate (“It’s not obvious what I should put here, so I’ll have to spend time thinking of a workaround”). 

Setting as optional fields that might not apply to everyone is one inclusive solution, as is increasing the available options for responses requiring a selection. However, while gender-inclusive choices provide an inclusive way to handle form inputs, it’s also worth considering when business objectives would be met just as well by providing open text inputs that allow users to describe themselves in their own terms. 

Instead of LinkedIn’s highly prescribed content, for example, Twitter bios’ lack of structure lets people describe themselves in more inclusive ways. Some people use the space to list formal credentials, while others provide alternate forms of identification (e.g., mother, cyclist, or coffee enthusiast) or jokes. Because the content is unstructured, there are fewer expectations about its use, taking pressure off those who don’t have formal credentials and giving more flexibility to those who do. 

Browsing the Twitter bios of designers, for example, reveals a range of identification strategies, from listing credentials and affiliations to providing broad descriptions. 

Figure 2. Veerle Pieters’s Twitter bio uses credentials, affiliations, and personal interests. 
Figure 3. Jason Santa Maria’s Twitter bio uses a broad description. 
Figure 4. Erik Spiekermann’s Twitter bio uses a single word.

In addition to considering where structured content might exclude, content modelers should also consider how length guidelines can implicitly create barriers for content creators. In the following section, we look at a project in which we chose to reduce the length of contributor bios as a way to ensure that our content model didn’t leave anyone out. 

Live in America

Live in America is a performing arts festival scheduled to take place in October 2021 in Bentonville, Arkansas. The goal of the project is to survey the diversity of live performance from across the United States, its territories, and Mexico, and bring together groups of artists that represent distinct local traditions. Groups of performers will come from Alabama, Las Vegas, Detroit, and the border city of El PasoJuárez. Indigineous performers from Albuquerque are scheduled to put on a queer powwow. Performers from Puerto Rico will organize a cabaret. 

An important part of the festival’s mission is that many of the performers involved aren’t integrated into the world of large art institutions, with their substantial fiscal resources and social connections. Indeed, the project’s purpose is to locate and showcase examples of live performance that fly under curators’ radars and that, as a result of their lack of exposure, reveal what makes different communities truly unique. 

As we began to think about content modeling for the festival’s website, these goals had two immediate consequences:

First, the idea of exploring the subject domain of live performance doesn’t exactly work for this project because the experts we might have approached would have told us about a version of the performing arts world that festival organizers were specifically trying to avoid. Experts’ mental models of performers, for example, might include attributes like residencies, fellowships and grants, curricula vitae and awards, artist statements and long, detailed bios. All of these attributes might be perceived as inherent or natural within one, homogenous community—but outside that community they’re not only a sign of misalignment, they represent barriers to participation.

Second, the purposeful diversity of festival participants meant that locating a shared mental model wasn’t the goal. Festival organizers want to preserve the diversity of the communities involved, not bring them all together or show how they’re the same. It’s important that people in Las Vegas think about performance differently than people in Alabama and that they structure their projects and working relationships in distinct ways. 

Content modeling for Live in America involved defining what a community is, what a project is, and how these are related. But one of the most interesting challenges we faced was how to model a person—what attributes would stand in for the people that would make the event possible. 

It was important that we model participants in a way that preserved and highlighted diversity and also in a way that included everyone—that let everyone take part in their own way and that didn’t overburden some people or ask them to experience undue anxiety or perform extra work to make themselves fit within a model of performance that didn’t match their own. 

Designing an inclusive content model for Live in America meant thinking hard about what a bio would look like. Some participants come from the institutionalized art world, where bios are long and detailed and often engage in intricate and esoteric forms of credentialing. Other participants create art but don’t have the same resources. Others are just people who were chosen to speak for and about their communities: writers, chefs, teachers, and musicians. 

The point of the project is to highlight both performance that has not been recognized and the people who have not been recognized for making it. Asking for a written form that has historically been built around institutional recognition would only highlight the hierarchies that festival organizers want to leave behind.

The first time we brought up the idea of limiting bios to five words, our immediate response was, “Can we get away with that?” Would some artists balk at not being allowed the space to list their awards? It’s a ridiculously simple idea, but it also gets at the heart of content modeling: what are the things and how do we describe them? What are the formats and limitations that we put on the content that would be submitted to us? What are we asking of the people who will write the content? How can we configure the rules so that everyone can participate?

Five-word bios place everyone on the same ground. They ask everyone to create something new but also manageable. They’re comparable. They set well-known artists next to small-town poets, and let them play together. They let in diverse languages, but keep out the historical structures that set people apart. They’re also fun:

  • Byron F. Aspaas of Albuquerque is “Diné. Táchii'nii nishłį́ Tódichii'nii bashishchiin.”
  • Danny R.W. Baskin of Northwest Arkansas is “Baroque AF but eating well.”
  • Brandi Dobney of New Orleans is “Small boobs, big dreams.”
  • Imani Mixon of Detroit is “best dresser, dream catcher, storyteller.”
  • Erika P. Rodríguez of Puerto Rico is “Anti-Colonialist Photographer. Caribeña. ♡ Ice Cream.”
  • David Dorado Romo of El PasoJuárez is “Fonterizo historian wordsmith saxophonist glossolalian.”
  • Mikayla Whitmore of Las Vegas is “hold the mayo, thank you.”
  • Mary Zeno of Alabama is “a down home folk poet.”

Modeling for inclusion

We tend to think of inclusive design in terms of removing barriers to access, but content modeling also has an important role to play in ensuring that the web is a place where there are fewer barriers to creating content, especially for people with diverse and underrepresented backgrounds. This might involve rethinking the use of structured content or asking how length guidelines might create burdens for some people. But regardless of the tactics, designing inclusive content models begins by acknowledging the political work that these models perform and asking whom they include or exclude from participation. 

All modeling is, after all, the creation of a world. Modelers establish what things exist and how they relate to each other. They make some things impossible and others so difficult that they might as well be. They let some people in and keep others out. Like overpasses that prevent public buses from reaching the beach, exclusionary models can quietly shape the landscape of the web, exacerbating the existing lack of diversity and making it harder for those who are already underrepresented to gain entry.

As discussions of inclusive design continue to gain momentum, content modeling should play a role precisely because of the world-building that is core to the process. If we’re building worlds, we should build worlds that let in as many people as possible. To do this, our discussions of content modeling need to include an expanded range of metaphors that go beyond just mirroring what we find in the world. We should also, when needed, filter out structures that are harmful or exclusionary. We should create spaces that ask the same of everyone and that use the generativity of everyone’s responses to create web products that emerge out of more diverse voices.

The Never-Ending Job of Selling Design Systems

I’m willing to bet that you probably didn’t start your web career because you wanted to be a politician or a salesperson. But here’s the cold, hard truth, friend: if you want to work on design systems, you don’t have a choice. Someone has to pay for your time, and that means someone has to sell what you do to an audience that speaks value in an entirely different language. 

It’s not exactly easy to connect the benefits of a design system directly to revenue. With an ecomm site, you can add a feature and measure the impact. With other conversion-based digital experiences, if your work is good, your customers will convert more. But because a design system is (usually) an internal tool, it’s just harder to connect those dots. 

This article boils down the methods I’ve put into practice convincing executives not just to fund the initial push of design system work, but to keep funding it. I’ll share how I’ve adjusted the language I use to describe common design system benefits, allowing me to more clearly communicate with decision makers.

Know your audience

In my experience, design systems can be owned by information technology teams, marketing and communications departments, or (best case scenario) cross-disciplinary teams that bring many specialists together. The first thing you need to do is determine where the system lives, as in which department owns and cares for it. 

If it’s part of IT, for example, you need to think like a CIO or an IT Director and speak to their objectives and values. These leaders are typically more internally focused; they’ll filter the value of the design system in terms of the employees of the company. In contrast, if the system belongs to Marketing, put on your CMO or Marketing Director hat. Marketing teams are often externally focused; they think in terms of B2B audiences and end users. 

The way organizations structure the ownership of a design system can be more complex, but let’s use these two paths (internal vs external) as frameworks for building a persuasive case for those owners.

Internal-orientation motivators

Based on the research we’ve done since 2018, there are three very specific internal motivators for having a design system:

  • Efficiency
  • Onboarding
  • Scale.

Efficiency benefit

Design systems allow for the rapid prototyping of new ideas using existing, production-ready components. They allow teams to reuse design and code, and they allow individuals to focus their creative energy on new problems instead of wasting it on old ones. Executives and decision-makers may abstractly understand all that, but you need to be able to tell them what it will take to realize the efficiency benefit. 

There’s a theoretical maximum to how productive a team can be. When you talk about a design system creating more efficiency in your processes, you’re really talking about raising the ceiling on that max. As happens with so many things in life, though, that comes with a trade-off. Early on, while a team is actually building the system, they won’t be as productive on the rest of their work.

The efficiency curve looks like this:

The Design System Efficiency Curve. Line graph illustrating the curvilinear relationship of productivity over time in terms of overall efficiency, in situations of transition from having no design system in place through in-process set up of the system, to eventually having an established design system. Productivity is represented on the y-axis and Time on the x-axis. Starting at 0,0 productivity dips down as the team diverts resources to set up the system, but eventually surpasses standard productivity once the system is in place.
Figure 1. With Productivity on the y-axis and Time on the x-axis, the Design System Efficiency Curve dips down at the start as the team ramps up on the system, but eventually surpasses standard productivity once the system is in place.

If you’re talking to an executive, it’s important to acknowledge this dip in productivity. 

Spend some time working out these specific calculations for your organization. For example, you might need four team members for three months to reach a point where the system will save everyone on the team approximately two hours per week. You’re candidly acknowledging the necessary investment while demonstrating the eventual benefits. And make sure to mention that the productivity benefits will continue indefinitely! The math will almost always end up on your side. 

Another critical point to raise is that simply having a design system has a cumulative effect on the efficiency of your teams. Since the system is an internal tool that can be used 1) across multiple products or experiences, 2) by many teams throughout the organization, and 3) in many phases of the product design and development process, you are gaining efficiencies on many levels. 

The team working on in-store kiosks can build their interface with a well-tested set of components. Your UX people can use the system to prototype and test with production-ready code. The people responsible for grooming the backlog know there is a stable pattern library upon which they are building new features or fixing old ones. Anyone looking for answers to what, why, or how your organization designs and builds products will find those answers in the living system.

The efficiency at each of these (and many other) decision points is how we can raise the ceiling on our total possible efficiency. How this plays out is very different in each organization. I’m here to tell you that part of the work is thinking about how a design system will impact every part of your process—not just design or development.

What to measure

Action: Measure the cost of productivity with and without a design system.

If you aren’t already, start measuring how productive your team is now. The easiest way to do this is to break your team’s work down into measurable cycles. Once you have a rough idea of how much you can get done in a cycle of work, you’ll be able to compare your efficiency before the system was in place with your efficiency after. This kind of measurable benefit will speak volumes to your executive team.

Onboarding benefits

Growth is expensive. When you hire a new team member, you don’t just supply a salary and benefits. You need a computer, a desk, a chair, accounts to all the software/services…the list goes on. And all these expenses hit before your new employee is a fully contributing member of the team. You won’t start to recoup your investment for a few months, at least. 

Design systems can reduce the time it takes your new hire to become a productive contributor. Once you have a healthy design system in place, you’re able to provide an employee with a clearly-defined and effective toolset that is well-documented and can be applied across multiple initiatives. More specifically, assigning new hires to start out working on the design system team will allow them to quickly learn how your organization designs and builds digital products.

Onboarding Model. Diagram illustrating the movement and eventual cycling (depicted by arrows pointing to the right) of individuals in a "Hiring Pool"(represented by a cluster of dots on the left of the graphic) into the DS Team (design system team), represented by a diamond shape in the center of the graphic, then exiting the DS Team to join Other Teams (smaller diamond shapes on the right of the graphic), and finally, back into the DS Team (dashed-line arrow looping below and to the left, back into the DS Team diamond shape).
Figure 2. A Model for Onboarding. As you bring people into your organization from your hiring pool, consider having them start on your design system team and then rotate out onto other teams. As you grow, folks who haven’t had a turn on the system team can rotate in as well.

On the left in Fig. 2, you have a pool of potential employees. As you hire individuals, you can bring them into the design system team, where they’ll gain a deep understanding of how your organization builds digital products. Once they’re up to speed, you can seamlessly move them to another product, discipline, or feature-based team where they’ll take this knowledge and hit the ground running. Additionally, your organization can benefit from having all team members (even those who have been around for a while) periodically work a rotation with the design system team. This continuously spreads the design system expertise around the organization and makes it part of the fabric of how you work.

And don’t think this approach is only valuable for designers or developers. A healthy design system team comprises people from many disciplines. In addition to team member rotation, building in time to mentor folks from many different disciplines can prove tremendously valuable in the long run. A highly functional design system team can serve as an ideal model of workflow and can educate many team members dispersed throughout the organization about how to approach their work.

Believe me, executives’ eyes will light up when you share how a design system can ensure high productivity in record time. As a caution, though, rotating people in and out of any team too often can leave them feeling exhausted and can make it hard for them to be productive. Remember, you have the flexibility to scale this to a level that makes sense for your team. Be smart and use this approach as it works in your context.

What to measure

Action: Measure the time it takes for teams to become productive.

As new people are added, a team typically returns to the “forming” stage of Tuckman’s stages of group development. This is part of the reason that growth is expensive. But with a design system in place and a healthy culture, you can reduce the time it takes the team to get back to “performing.”

Scale benefits

Traditionally, you have to hire more people to scale productivity. A design system enables a team to accomplish more with less. Reusability is a major reason teams choose to work in a more systematic way. Small teams with an effective system can design, build, and maintain hundreds of sites each year. They’d never come close without a design system to work with. 

UX Pin has a design system guide that starts by acknowledging something that most of us ignore.

Scaling design through hiring, without putting standards in place, is a myth. With every new hire, new ideas for color palettes, typography and patterns appear in the product, growing the inconsistency and increasing the maintenance cost. Every new hire increases the design entropy.

A well-executed system allows a team to scale while keeping design entropy at bay.

What to measure

Action: Compare the amount of people on your team to the amount of work they are accomplishing.

Adding people to a team doesn’t necessarily mean they’ll get more work done faster. This is well-documented in historical software books like Fred Brooks’ The Mythical Man-Month. Eventually, you will have to investigate changing other factors (besides just adding more people) to increase productivity. A good design system can be one of these factors that increases the productivity of the team members you already have. It’s this change in productivity over scale that you need to measure and compare in order to prove value for this benefit.

External-orientation motivators

Let’s shift to thinking about the benefits that a design system offers to end-users. The four primary external motivators are:

  • Consistency
  • Trust
  • Accessibility
  • Usability.

Consistency and Trust benefits

Consistency is widely assumed to be the primary benefit of a design system. We identify dozens of button designs, color variations, and inconsistent typefaces in hopes of convincing higher-ups to allow us to build a system to bring it all in line. After working on design systems for the last five or six years, I can say with confidence that a design system will not make your product more consistent. 

You see, us web designers and developers are very scrappy. We can create the most inconsistent experiences within even the most rigid systems. It’s not the system itself that creates consistency, it’s the culture of an organization. It’s all of the unspoken expectations—the filters through which we make decisions—that give us the confidence to pause and ask if the work we’re doing fits culturally with the product we’re building. A good CMO knows this, and they won’t buy the oversimplified idea that a design system will solve the rampant inconsistencies in our work. 

Because of this, these executives often have a different (and easier to measure) question: “Does it convert?” This perspective and line of conversation is not an ideal approach. Believe me, we can create experiences that convert but are not good for our users or our brands. Given this, a conversation with your CMO might go better if you shift the language to talk about trust instead.

With inconsistent experiences, your users subconsciously lose trust in your brand. They’ve been conditioned to expect a certain kind of user experience, and that’s what they should be given, even across multiple websites or products. Vanessa Mitchell wrote about why brand trust is more vital to survival now than it’s ever been:

“Brand trust as an ‘“insurance policy”’ against future issues is not a new concept. Most organizations know trust bestowed by the consumer can not only make or break a business, it can also ensure you survive a problem in the future. But few achieve brand trust adequately, preferring to pay lip service rather than delve into what it really means: Authentically caring about customers and their needs.”

When your customer is using your product to accomplish a very specific task, that one task is the only thing that matters to them. Creating a consistent experience that works for everyone and allows them to accomplish their goals is building trust. CMOs need to understand how design systems empower trusted relationships so those relationships contribute to your bottom line.

What to measure

Action: Measure the engagement of your customers.

Customer engagement can be measured with web analytics platforms. What you’re looking for will vary depending on the context for your organization, but trends in things like time on site, visit frequency, subscription rates, and bounce rates will give you meaningful data to work with. It’s also very common to track customer engagement with metrics like Net Promoter Score (NPS) by asking simple questions of customers repeatedly over time. There are so many ways to structure tests of the usability of your work, so I’d encourage you to loop in the UX team to help you find tests that will demonstrate the user engagement success of the design system effort.

Accessibility benefits

Accessibility can be a tremendous benefit of a design system. Do the work properly the first time, then allow that beautifully accessible component to serve your customers each time it is used. Certainly, it’s not a fail-safe measure—there is still integration-level testing to ensure component accessibility translates to the larger experience—but ensuring the accessibility of individual components will result in more accessible experiences. And integrating good accessibility practices into your system means more folks within your organization are aligned with this important work. 

You might find at first that marketers aren’t all that interested in accessibility, but they should be. Did you know that there were 814 web accessibility related lawsuits (just in the US!) in 2017? Did you know that there were almost 2,300 in 2018? That’s a 181% increase. This must be a priority. First, because it’s the right thing to do. Second, because it’s important to the sustainability of the business. A design system can help you address this issue, and it can help you maintain compliance as you grow. This is the kind of message that resonates with leadership.

What to Measure

Action: Measure your compliance to accessibility guidelines over time.

Many organizations have a regular cadence of accessibility audits across their digital properties. While some of this can be automated, there’s always a manual aspect needed to truly evaluate the accessibility of a site or application. Tracking how often regressions occur in the properties served by your design system can be a great way to demonstrate the value that system is bringing to the organization.

Usability benefits

As with so many aspects of a design system, usability benefits come from repetition. Design system pros often hope to focus energy on solving a usability challenge only once before moving on to the next problem. This absolutely is a benefit of a well-constructed system. It’s also very true that “familiarity breeds usability.” Your customers will learn to use your products and begin to subconsciously rely on that familiarity with the experience to lower their cognitive load. This should be just as important to our executive leadership as it is to those of us who are practitioners. 

You can also reframe this benefit in the context of conversion. Helping our users accomplish their goals is helping them convert. They are there to use your product. So make it easy to do, and they’ll do it more. This is what businesses need and what executives want to see—improving the business by helping customers. As mentioned above, we want to make sure we’re doing this in healthy ways for both our users and our brands.

What to Measure

Action: This might be the easiest one—measure conversion!

Running usability studies will help to validate and measure the success of your work with the system, which many organizations are already doing. Your goal should be to validate that components are usable, which will allow you to build a culture of user-centered design. Setting the bar for what it takes to evolve the system—such as requiring that changes are tested with real users—introduces this idea into the core of all your processes, where it should be.

Sell investment, not cost

Knowing how and which internal and external motivators to touch on during conversations is significant, but there’s one last thing I’d like to mention, and it has to do with your way of thinking. A major factor in many of these conversations lies simply in how we frame things: move the conversation about the cost of building a design system into a conversation about the present and residual benefits of the investment you’re making. It’s easy to view the time and effort required to build a system as an investment in ultimately delivering high-quality digital products. But leadership will be more willing to consider realistic budgets and timelines if you talk about it like a long-term investment that has benefits on multiple levels throughout the business. This also leaves you with the ability to regularly remind them that this product will never be done—it will require ongoing funding and support.

A design system project will not succeed if you don’t convince others that it’s the right thing to do. Successful, sustainable design systems start with the people, so you have to begin by building consensus. Building a design system means you’re asking everyone to change how they work—everyone has to be on board.

This concept of collaboration is so core to the work of design systems that it led all of us here at Sparkbox to look for opportunities to better understand how teams around the world are designing, building, and using a more systematic approach to digital product design. For the last three years, we’ve been gathering and sharing data in the form of the Design Systems Survey and the Design System Calendar. If you are considering a design system for your organization, or if you work with a design system team, the survey and calendar may be helpful in your quest to build better products.

Navigating the Awkward: A Framework for Design Conversations

We’ve all been there. A client or coworker shows us this amazing thing they (and maybe their entire team) have worked on for hours or weeks. They are so proud of it. It’s new or maybe it just looks new. They may or may not ask you what you think—but you’re there to experience it. And your brain quietly screams.

As an experienced designer, you often have an intuitive reaction and can quickly spot bad designs; they may be visually incongruent, poorly structured, confusing, lack social awareness, or look like they are trying too hard.

If your initial response is so negative that it slips through into your expression or voice or body language, it can completely sabotage any possibility of buy-in. And, far more seriously, it can ruin the relationship of trust and collaboration you’re building with that person. 

Reflecting on my own successes and failures—and the experiences of others—I’ve put together a conversational framework for navigating these all-too-frequent design interactions, whether you’re an in-house designer, a consultant, or an agency employee. 

Be a relationship steward

“Getting things done” is often accomplished at the expense of relationships and sustainable design solutions. As in, the “We need to manage this situation” approach (emphasis on the “manage”) quite often looks more immediately effective on paper than the “We need to be productive while stewarding this project for this partner” mindset.  

The thing is, a design stewardship mindset to working with clients/partners is a better bet; thinking beyond buy-in or proving your point or getting your own way pays off in both an immediate situation, and long-term, for both sides.

I’ve had plenty of those “design conversations gone wrong” over the years, and have noticed a common set of whys and hows behind the scenes. To help me consciously factor them in and stay focused, I’ve developed this simple conversational framework:

Element 1: Move from selling to helping.

Element 2: Question your triggers and explore the problem.

Element 3: Map the problem to the client’s values.

Element 4: Formulate questions for the client based on values.

Element 5: Listen and be prepared to challenge your assumptions.

Element 6: Reflect back on the problem and share recommendations with the client.

We’re going to explore all that below, but here’s a quick reference version of conversational frameworks you can look at as we go.

Healthy self-talk

When confronted with a bad design, there are some common reactions a designer might have—what we often catch ourselves saying in our head (hopefully!) or directly to our clients. (I need to preface by saying I borrowed some of these from a viral “Hi, I’m a ...you might know me from my greatest hits...” on Twitter.)

  • You are not your users!
  • Blindly following another organization’s best practices is not going to guarantee successful conversion for your business.
  • Have they ever heard there’s such a thing as Calls to Action?
  • Really, you couldn’t have bothered to tell the user ahead of time how many steps this process involves?
  • No, a chatbot won’t magically fix your horrible content!
  • Is this clipart?!!
  • Don’t use your org chart for navigation...not even on your intranet.
  • You can’t mix apples and oranges.
  • Views do not equal engagement metrics!
  • Stop celebrating outputs instead of outcomes!
  • Diversity is more than just white women.
  • You’re talking about implementation details, but I still don’t even know what problem we’re trying to solve.
  • Not another FAQ!
  • Does accessibility mean anything to these folks?
  • We don’t need 15 unique designs for this button. There is a style guide for that!
  • Good luck with your SEO efforts; keyword stuffing won’t get you ranking!
  • Can we start designing experiences instead of pages and features?

I am sure you can relate. While there’s nothing inherently wrong about these statements—and there are times when it is worth being upfront and saying them as-is—we also know they might be ineffective, or worse yet, perceived as confrontational. 

Someone worked hard on this. They put a lot of thought into it. They love it. They want this to be the solution. 

So, how can we avoid defensiveness? How do we engage the other person in a meaningful conversation that comes from a place of empathy instead of arrogant expertise? 

In describing “How Shifting Your Mindset Can Ignite Transformation,” Keith Yamashita points out that “each of us comes into the world curious, open, wanting to bond and wanting to have great connections with other people,” yet “our training, societal norms, school, and early jobs beat all of that out of us.” Self-awareness and inner reflection are essential to helping us reconnect with other humans. Practicing mindfulness is a great way to develop and enhance these skills.

It’s not me, it’s you (Element 1)

First step to getting your message across is shifting your position from “How do I share my perspective” to “How can I help my (clients/partners/coworkers) improve their current product?” 

Make room for the needs of others and create some distance from your ego and. In particular, try to refrain from saying what you find so intuitive, as well as delay providing your opinion. 

Blair Enns, who writes about the importance of being a vulnerable expert, says it beautifully (emphasis is mine):

  • You can be slick or the client can be slick. It’s better if it’s the client.
  • You can fumble and be awkward in the conversation or the client can fumble and be awkward. It’s better you are the awkward one.
  • You can have all the answers to the client’s questions or the client can have all the answers to your questions. It’s better to ask the questions. (Nobody has all the answers.)
  • Those who are not trained in selling often think of the cliches and think they must be seen to be in control, to have the answers, to have the polish. The opposite however is better. You can still be the expert by showing vulnerability. You don’t need to manufacture answers you do not have. It’s okay to say “let me think about that.”

Allowing others to be in the spotlight may take some practice and requires you to be self-aware. When you find yourself triggered and itching to comment or to disagree with something, try the following exercise:

  1. Pause.
  2. Acknowledge that you are frustrated and want to jump in.
  3. Invite yourself to be curious about the trigger instead of judging yourself or others. 

The more you practice this kind of self-awareness, the more you’ll notice your triggers and change how you respond to them. This quick mental exercise gives you the space to make an intentional choice. For similar practical strategies, take a look at “How to Turn Empathy into Your Secret Strength.”

Winning the moment isn’t a win (Element 2)

One potential trigger may be rooted in your mindset: are you more focused on trying to get “buy-in,” or on building positive, lasting relationships to support ongoing collaboration and stewardship?

To do this, you need to first ask yourself some questions to get to the bottom of what your impulse is trying to communicate. You then need to do some slow thinking and identify a question that will engage your partner in a conversation.

Here’s a hypothetical situation to explore what this might look like.

You’re shown a very clunky, centralized system designed so users can register for recreational activities around the city. The client wants your team to create a chatbot to support it. 

Your internal reaction: “Instead of pages and features, can we start designing experiences?”

Analyzing your reaction:


When we focus on pages and features like chatbot solutions, we typically aren’t seeing the whole picture.


Organizations can get distracted by a shiny opportunity or single perceived problem in a product, but these can frequently overshadow where real impact can be made. 


The 80/20 Pareto principle has a strong pull for many organizations.


Organizations want solutions that take minimal perceived time and effort.


Organizations want to save money/go with the cheaper option. 

So what?

As a result, organizations risk prioritizing what seems to be the easy thing at the expense of other, more user-friendly and profitable solutions. 

This example is simplistic, but notice that by asking a few sets of questions, we were able to move from a reactive statement to a reason why something may not be working—a reason that’s a lot less emotional and more factual. You could use a modified 5 Whys approach like this, or some other questioning method that suits the situation. 

If you dissect our example more closely, you’ll see that unlike the initial reaction, which speaks more to design elements like pages and features, we are now talking about more broadly relatable topics across business lines, such as cost savings or risk assessment. Structuring your conversation around topics most familiar to the other person and reflecting their core values can help us be more successful in improving their product.

Ask with values in mind, close with opportunities (Element 3)

I recently attended an excellent event on “Speaking Truth to Power,” presented by the Canada School of Public Service. The keynote speaker, Taki Sarantakis, shared his strategies for how to be an effective expert and advisor, such as:

  • Be credible and build trust
  • Have humility and empathy
  • Make sure that the person you are advising understands that the advice they do not want to hear is for their benefit.

He also broke down a few concepts that could be a barrier to implementing this advice. If we see ourselves as “speaking truth to power” we are likely making a values judgement. We believe and project to others that we have all truth and no power, while the person on the other end has all the power, and no truth. It’s an arrogant position that weakens our ability to make any productive progress. Framing our interactions as a battle will likely result in a lose-lose situation.  

Sarantakis then presents an example conversation that is rooted in credibility and humility, and comes from a place of care. He underscores that any advice you choose to share has to absolutely come from a place of concern for the person making a final decision, and not from a desire to show off and say so on record. It roughly looks like this:

  • Here is what you need to know...
  • You know X, but you may not know Y and Z.
  • I know this is something you may not want to hear, but I need to say it because it is important that you know this.

As part of the panel discussion that followed the keynote, Kym Shumsky, who has lots of experience advising senior leaders, reinforced Sarantakis points by stating that valuing truth, knowledge, and accuracy over relationship-building can be detrimental. Thinking back on my personal experiences, I fully agree. 

So how do we build trust, credibility, and share from a place of care? Steve Bryant, Head of Content at Article Group, has some thought-provoking words on this in his article “Make relationships, not things”:

Relationships are based on trust. Trust takes time and honesty. You can’t just create a pile of content and be done with it. You can’t “thing” your way to people trusting you.

Which is to say: the question isn’t what content to create.

The question isn’t how to create that content.

The question is why do you care about the people you’re creating the content for? What makes them special? What kind of relationship do you want to have?

How do you want them to feel?

Translating core values into specific needs (Element 4)

Going back to the exercises we just explored and what we think could be the source of the problem, it’s time to start moving backward from the core values to specific design characteristics that need to be addressed.  

You have to always start the conversation as a set of questions. Beginning with questions allows you to set aside the expert hat, be curious, and let the client share their experiences. It shows them you care and are there to listen generously

Build rapport, be present, and be there to listen (Element 5)

Erika Hall offers timeless advice about the need to build rapport and understand our partners in her article “Everyday Empathy”:

And as social science shows, trying to bridge the gap with facts will never change anyone’s mind. The key is to value — truly value — and reflect the perspective of the people you want to influence. [...] Attention is a gift beyond measure.

A great bit of advice on “being present” rather than “presenting” on a topic is offered by Blair Enns (author of The Win Without Pitching Manifesto) in the episode “Replacing Presentations with Conversations.” Being present also means being vulnerable and open to discovering something new that might change your initial reaction. 

And then be prepared to truly listen, not convince. Sarah Richards points out how important it is to understand the different mental models that partners bring to the table and work together to form new ones to accomplish common goals:

How many times have you said you are going to talk to someone who is blocking you? Now count how many times have you said you are going to listen to someone who is blocking you? When we have someone in our organisation who disagrees with us, we go to see if we can convince someone that our way of thinking, our way of doing things, is the best way of doing it.

Here is what a conversation relating to “Can we start designing experiences instead of pages and features?” might look like, if we follow this approach:

You: What do you hope to accomplish with a chatbot?

Partner: We want people to get answers to their questions as quickly as possible, so they can register and pay for local recreation activities of their choice faster. We live in a beautiful city and it’s a pity when residents and visitors can’t take advantage of everything it has to offer. 

You: What have you heard from the people who experienced barriers to quickly registering and paying?

Partner: They complain that they can’t easily find activities in community centers closest to them or that there is no way for them to see all current and upcoming classes around the city at a glance, or that additional information about different activities is not provided within the system and they often have to look up events or class instructors separately to find more information on other websites. They also are not able to browse all activities by type of recreation, like “nature” activities, which might include hiking, city tours, birdwatching, garden events, and festivals. They often do not know what terminology to use to search for events and activities, so they say it is difficult to find things they already do not know about.

You: How do you think this makes them feel?

Partner: They say this frustrates them, as information on other websites might differ from the information in our system and they end up wasting their time guessing which one is correct and up-to-date. They then end up having to call the community center or organization providing an event for more information, to figure out if it is a good fit, before registering and paying; which significantly delays the process. 

I think you see where this is going. 

Here are a few more follow-up questions:

  • Have you tried registering for an activity using the system? How did you feel/what did you experience? 
  • What would you like people using your system to feel/experience?
  • You’ve mentioned a number of barriers that people experience. How well do you think a chatbot will be able to remove these barriers now?
  • What are some of the risks you foresee in trying to solve these problems?

At this point, if you hear something that makes you pause and question your assumptions, ask further questions and consider going back to the drawing board. Maybe you need to ask yourself: What are my lenses?

Respond with care and invite collaboration (Element 6)

If what you’ve heard confirms your assumptions, you could offer a few concise, summative statements and a recommendation. Whatever you say needs to integrate the vocabulary used by the client (mirroring), to show them that you were listening and critically reflecting on the situation. 

Let’s see how that might look:

“Based on what you’ve shared, it seems that you want to make it quick and easy for anyone in the city to discover, decide on, and pay for a local recreation activity. The experience of the people using the system is very important to you, as you want them to enjoy the city they live in, as well as support the vibrancy of the city economically by registering and paying for local activities.

If we want to help people enjoy and experience the city through events and activities, we need to make it simple and frictionless for them. The barriers they experience cannot be solved with a chatbot solution because the information people are looking for is often missing and not integrated into the current system in a meaningful way. So the chatbot would not give them the answers they need, creating further frustration. 

Adding a chatbot also creates an extra layer of complexity. It does not solve the underlying cause of frustration stemming from lack of relevant and integrated information. Instead, it leaves the current experience broken and creates yet another place people need to go to for possible answers.

It would also be a huge risk and time investment to design a chatbot, as your current content is not structured in a way that would allow us to have useful information extracted.

Given your time and resource constraints, I would suggest we explore some other solutions together.” 

Framing and reinforcing the conversation

To recap, here are the six essential elements of the conversational framework:

Element 1: Mentally move from how you can share and sell your perspective to how you can help your partner.

Element 2: Ask yourself probing questions to better understand your reaction to the “bad design” trigger and what is at the core of the problem.

Element 3: Map the core of the problem to value(s) you can use to begin the conversation with a partner.

Element 4: Use value(s) identified to formulate and ask questions.

Element 5: Get ready to truly listen to your partner and be prepared to challenge your assumptions.

Element 6: Review your responses to probing questions and identify recommendations you can share back with the partner.

This conversational framework starts with us as individuals, forces us to critically deconstruct our own reactions, then asks us to reframe what we find from a perspective of what matters and is known to our clients. It reminds us that we should learn something in the process by having intentional yet open conversations.

Future of design leadership is stewardship

The work we do in the web industry touches people—so we need to be people. We need to be human, build trust, and sustain relationships with our clients and partners. If we aren’t doing a good job there, can we really claim it’s not impinging on our designs and end users?

Our growth as web professionals can’t be limited to technical expertise; design leadership is stewardship. It’s rooted in listen, then respond, in learning how to pause, create space, and get to the root of the problem in a productive and respectful way. We need to learn how to intercept our reactions, so that we can shift how we approach triggering situations, stay still and listen, and open up conversations rife with possibilities, not progress suppressors. Guide clients toward better design choices by meeting them in the moment and partnering with them.

In design work, being a steward does not mean that you should push to get your way. Neither does it mean you should indulge clients and create broken or unethical products. Rather, it proposes an attuned way of approaching potentially contentious conversations to arrive at a solid, ethical design. It is about framing the conversation positively and ushering it as a steward, rather than stalling discussion by being the gatekeeper. 


The Web is obese

In 1994, there were 3,000 websites. In 2019, there were estimated to be 1.7 billion, almost one website for every three people on the planet. Not only has the number of websites exploded, the weight of each page has also skyrocketed. Between 2003 and 2019, the average webpage weight grew from about 100 KB to about 4 MB. The results?

“In our analysis of 5.2 million pages,” Brian Dean reported for Backlinko in October 2019, “the average time it takes to fully load a webpage is 10.3 seconds on desktop and 27.3 seconds on mobile.” In 2013, Radware calculated that the average load time for a webpage on mobile was 4.3 seconds.

Study after study shows that people absolutely hate slow webpages. In 2018, Google research found that 53% of mobile site visitors left a page that took longer than three seconds to load. A 2015 study by Radware found that “a site that loads in 3 seconds experiences 22% fewer page views, a 50% higher bounce rate, and a 22% fewer conversions than a site that loads in 1 second, while a site that loads in 5 seconds experiences 35% fewer page views, a 105% higher bounce rate, and 38% fewer conversions.”

The causes of webpage bloat? Images and videos are mainly to blame. By 2022, it’s estimated that online videos will make up more than 82% of all consumer Internet traffic—15 times more than in 2017. However, from the code to the content, everything about Web design has become super-bloated and super-polluting. Consider that if a typical webpage that weighs 4 MB is downloaded 600,000 times, one tree will need to be planted in order to deal with the resulting pollution.

They say a picture paints a thousand words. Well, 1,000 words of text takes up roughly two A4 (210 mm wide and 297 mm long) pages and weighs about 6 KB. You’d place about four images that are 9 cm x 16 cm on two A4 pages. Let’s say these images are well optimized and weigh 40 KB each. (A poorly optimized image could weigh several megabytes.) Even with such high optimization, two A4 pages of images will weigh around 160 KB. That’s 27 times more than the two A4 pages of text. A 30-second video, on the other hand, could easily weigh 3 MB. Videos create massively more pollution than text. Text is the ultimate compression technique. It is by far the most environmentally friendly way to communicate. If you want to save the planet, use more text. Think about digital weight.

From an energy point of view, it’s not simply about page weight. Some pages may have very heavy processing demands once they are downloaded. Other pages, particularly those that are ad-driven, will download with lots of third-party websites hanging off them, either feeding them content, or else demanding to be fed data, often personal data on the site’s visitor. It’s like a type of Trojan Horse. You think you’re accessing one website or app, but then all these other third parties start accessing you. According to Trent Walton, the top 50 most visited websites had an average of 22 third-party websites hanging off them. The New York Times had 64, while Washington Post had 63. All these third-party websites create pollution and invade privacy.

There is a tremendous amount of out-of-date content on websites. I have worked with hundreds of websites where we had to delete up to 90% of the pages in order to start seeing improvements. Poorly written, out-of-date code is also a major problem. By cleaning up its JavaScript code, Wikipedia estimated that they saved 4.3 terabytes a day of data bandwidth for their visitors. By saving those terabytes, we saved having to plant almost 700 trees to deal with the yearly pollution that would have been caused.

If you want to help save the planet, reduce digital weight. Clean up your website. Before you add an image, make sure that it does something useful and it’s the most optimized image possible. Every time you add code, make sure it does something useful and it’s the leanest code possible. Always be on the lookout for waste images, waste code, waste content. Get into the habit of removing something every time you add something.

Publishing is an addiction. Giving a website to an organization is like giving a pub to an alcoholic. You remember the saying, “There’s a book inside everyone”? Well, the Web let the book out. It’s happy days for a while as we all publish, publish, publish. Then…

“Hi, I’m Gerry. I have a 5,000-page website.”

“Hi, Gerry.”

“I used to have a 500-page website, but I had no self-control. It was one more page, one more page… What harm could one more page do?”

Redesign is rehab for websites. Every two to three years some manager either gets bored with the design or some other manager meets a customer who tells them about how horrible it is to find anything on the website. The design team rounds up a new bunch of fake images and fake content for the top-level pages, while carefully avoiding going near the heaving mess at the lower levels. After the launch, everyone is happy for a while (except the customers, of course) because in many organizations what is important is to be seen to be doing things and producing and launching things, rather than to do something useful.

If you must do something, do something useful. That often means not doing, removing, minimizing, cleaning up.

Beware the tiny tasks. We’ve used the Top Tasks method to identify what matters and what doesn’t matter to people, whether they’re buying a car, choosing a university, looking after their health, buying some sort of technology product, or whatever. In any environment we’ve carried it out in—and we’ve done it more than 500 times—there are no more than 100 things that could potentially matter.

In a health environment, these might include symptoms, treatment, prevention, costs, waiting times, etc. When buying a car they might include price, engine type, warranties, service costs, etc. We’ve carried out Top Tasks surveys in some 40 countries and 30 languages, with upwards of 400,000 people voting. In every single survey the same patterns emerge. Let’s say there are 100 potential tasks. People are asked to vote on the tasks that are most important to them. When the results come in, we will find that five of the tasks will get the first 25% of the vote. 50 tasks will get the final 25% of the vote. The top five tasks get as much of the vote as the bottom 50. It’s the same pattern in Norway, New Zealand, Israel, USA, Canada, UK, Brazil, wherever.

The bottom 50 are what I call the tiny tasks. When a tiny task goes to sleep at night it dreams of being a top task. These tiny tasks—the true waste generators—are highly ambitious and enthusiastic. They will do everything they can to draw attention to themselves, and one of the best ways of doing that is to produce lots of content, design, code.

Once we get the Top Tasks results, we sometimes analyze how much organizational effort is going into each task. Invariably, there is an inverse relationship between the importance of the task to the customer and the effort that the organization is making in relation to these tasks. The more important it is to the customer, the less is being done; the less important it is to the customer, the more is being done.

Beware of focusing too much energy, time and resources on the tiny tasks. Reducing the tiny tasks is the number one way you can reduce the number of pages and features. Save the planet. Delete the tiny tasks.

A plague of useless images

I was giving a talk at an international government digital conference once, and I asked people to send me examples of where digital government was working well. One suggestion was for a website in a language I don’t speak. When I visited it, I saw one of those typical big images that you see on so many websites. I thought to myself: I’m going to try and understand this website based on its images.

The big image was of a well-dressed, middle-aged woman walking down the street while talking on her phone. I put on my Sherlock Holmes hat. Hmm… Something to do with telecommunications, perhaps? Why would they choose a woman instead of a man, or a group of women and men? She’s married, I deduced by looking at the ring on her finger. What is that telling me? And what about her age? Why isn’t she younger or older? And why is she alone? Questions, questions, but I’m no Sherlock Holmes. I couldn’t figure out anything useful from this image.

I scrolled down the page. Ah, three more images. The first one is a cartoon-like image of a family on vacation. Hmm… The next one is of two men and one woman in a room. One of them has reached their hand out and placed it on something, but I can’t see what that something is, because the other two have placed their hands on top of that hand. It’s a type of pledge or something, a secret society, perhaps? Two of them are smiling and the third is trying to smile. What could that mean? And then the final picture is of a middle-aged man staring into the camera, neither smiling nor unsmiling, with a somewhat kind, thoughtful look. What is happening?

I must admit that after examining all the visual evidence I had absolutely no clue what this government website was about. So, I translated it. It was about the employment conditions and legal status of government employees. Now, why didn’t I deduce that from the images?

The Web is smothering us in useless images that create lots of pollution. These clichéd, stock images communicate absolutely nothing of value, interest or use. They are one of the worst forms of digital pollution and waste, as they cause page bloat, making it slower for pages to download, while pumping out wholly unnecessary pollution. They take up space on the page, forcing more useful content out of sight, making people scroll for no good reason.

Interpublic is a very large global advertising agency. As with all advertising agencies they stress how “creative” they are, which means they love huge, meaningless, happy-clappy polluting images. When I tested their homepage, it emitted almost 8 grams of CO2 as it downloaded, putting Interpublic in the worst 10% of website polluters, according to the Website Carbon Calculator. (For comparison, the Google homepage emits 0.23 grams.) One single image on its homepage weighed 3.2 MB. This image could easily have been 10 times smaller, while losing nothing in visual appeal. The Interpublic website is like a filthy, rusty 25-year-old diesel truck, belching fumes as it trundles down the Web.

Instead of optimizing images so that they’ll download faster, the opposite is often happening. High-resolution images are a major cost to the environment. If, for example, you move from a 4K resolution image to an 8K one, the file size doesn’t double, it trebles. For example, I saved an image at 4K and it was 6.9 MB. At 8K it was 18 MB.

Digital “progress” and “innovation” often means an increasing stress on the environment. Everything is more. Everything is higher. Everything is faster. And everything is exponentially more demanding of the environment. Digital is greedy for energy and the more it grows the greedier it gets. We need digital innovation that reduces environmental stress, that reduces the digital footprint. We need digital designers who think about the weight of every design decision they make.

We must start by trying to use the option that damages the environment least, and that is text. Don’t assume that images are automatically more powerful than text. Sometimes, text does the job better.

  • In a test with an insurance company, it was found that a promotion for a retirement product was deemed less accurate when an image of a face was used than when text only was used.
  • An initiative by the UK government to get people to sign up to become potential organ donors tested eight approaches. The approaches that used images were least effective. Text-only worked best.


“Hello. Is that the Department of Useless Images?”


“We have this contact form and we need a useless image for it.”

“How about a family cavorting in a field of spring flowers with butterflies dancing in the background?”


There are indeed many situations where images are genuinely useful, particularly when it comes to helping people better understand how a product works or looks. Airbnb, for example, found that its growth only began to accelerate after it invested in getting quality images of the rental properties on offer.

If you need to use images, optimize them and consider using real ones of real people doing real things.

They say a picture paints a thousand words but sometimes it’s a thousand words of crap.

Connecting the Dots

Two plans: one for design, one for culture.

What I’ve found is that the DNA between both dynamics must be inextricable from one another. Creating with compassion in an environment fueled by compassion means we never lose sight of what it’s all about: people. Beyond functioning in this manner because “it’s the right thing to do,” quality of work, loyalty internally (team) and externally (users), and product innovation are all benefits to reap.

Earlier we talked through the concept of “simplicity” and its application to creation and environment. Now, let’s revisit a few other examples of healthy benchmarks from a creative culture as we’ve discussed in this book:

  • Slowing down / pausing with intent
  • Everyone has a seat at the table
  • The New Day One

In taking a focused look at these facets, their correlation to HCD is readily apparent:

Culture: Slowing down / pausing with intent
Design: Discovery / observation

The Swedish concept of fika transcends a mere “coffee break.” It’s about slowing down, the act of pausing during a typical day and making time to have a dialogue with someone (though a good cup of coffee is a vital part). I ensure this time is not only a known quantity within my team’s creative culture, but that it’s protected and actively utilized.

Instead of getting a product manager’s Powerpoint wireframe in your inbox with a request to “make it look nice” or a client’s request to crank out a design for their approval by EOD, we must slow down to understand the people who will be interacting with our design (and the design’s potential impact on others, the environment and community in which it will be used, and so on). Rushing to get something done to tick an account manager’s client-appeasement box at the expense of the human experience is to sacrifice empathy, quality, and any prospect of innovation.

Culture: Everyone has a seat at the table
Design: Inclusion

As the very definition of cultural transparency, Nick Sarillo’s pizza parlors tack their full financial statements to a wall, daily, for all employees to see. Everyone’s hourly wage is listed on a nearby whiteboard, with the means to make more money articulated in tandem (training in more areas of business = increased hourly wage). Many managers have worked their way up in this manner, and offer training to other employees who wish to advance by taking on more responsibility. This is about collaboration yielding success to both the employee and the business, the sharing of information, and access for all; key dynamics of an inclusive culture.

Inclusion in the design process enables us, as creators, to recognize our own personal biases. By identifying the exclusion in our work, we humbly set aside our assumptions; connecting with people from diverse communities, building empathy, will expand our product’s reach (access). Via engaging humans throughout our design process, listening to them, and usability testing iteratively, objective solutions that yield innovation follow suit.

Culture: The New Day One
Design: Ethnography

The New Day One concept evolves an employee’s first day from formulaic and sterile into directly personal and custom. Via the “Inspiration” portion of the day and venturing away from the office, we gain insight into a new team member as an individual that transcends what folio work can yield. What physical aspects of their selected location have impacted who they are? How did it inspire their way of creating, or approaching problems? Understanding the impact of spatial dynamics on an individual is vital toward an individualistic, yet ultimately holistic, view.

Ethnographic research provides an environmental context to human interaction that a video-conference interview could never yield. Through direct observation, ethnography is the qualitative study of human beings in their native environment. Is the individual sitting in a high-traffic area in an office, causing frequent distraction from their work? Are they a field worker primarily utilizing a mobile device in direct sunlight, yielding paramountcolor contrast needs? By making research truly human, we gain an understanding of how those we observe see the world and how they ultimately engage with it.

For the Greater Good

Greater Good Studio (GGS) is a social impact-focused human- centered design firm co-founded by Sara Cantor Aye and George Aye. Their business is located within the Logan Share, a co- working space they also founded in Chicago’s Logan Square neighborhood.

I reached out to the Studio to ask if I could stop by their space and observe a “morning in the life” view of their process: culture and design, organically, as both unfolded. Without hesitation, Sara (a former Northwestern University instructor) extended me an offer to join the team for observation. After signing a non- disclosure agreement, we agreed on a date for my visit.

When I arrived on a Monday morning, George (formerly of IDEO) greeted me with a cup of coffee and walked me up the stairs into the naturally well-lit Logan Share space. I noticed the open seating in the co-working section was already nearly full, as he gave me a tour of the “configuration by human need and intent”-based layout and active-project areas. On long single sheets of cardboard suspended by custom-built fasteners, entire lifecycles of project- centric human-centered design artifacts were on display. Once a project is deployed, George explained, the cardboard is detached and saved for forthcoming iteration, with fresh sheets re-fastened to form the partitions of a new project space thereafter.

The six core steps of the Studio’s HCD process manifest themselves in the following way:

  1. Framing
    Defining questions to answer and people to engage
  2. Research
    Learning from people about their needs and values
  3. Synthesis
    Finding patterns of behavior and areas of opportunity
  4. Concepting
    Creating a high volume of new ideas
  5. Prototyping
    Making tangible mock-ups and gathering feedback
  6. Piloting
    Testing solutions in real time with real people

As a team, GGS functions via a working method called ROWE (Results Only Work Environment), a concept leveraged from Cali Ressler and Jody Thompson’s book Why Work Sucks and How to Fix It: The Results-Only Revolution. Taken from an article on the Studio’s blog, they describe the practice within GGS like this:

“The basic principle behind ROWE is that staff doesn’t need to be supervised, when given the tools, clear expectations, and deadlines people will not only do their work, but do it better than if they were trying to fit into a mold. Within GGS, this practice is exercised by very diligent calendar management, clear deadlines, expectations on deliverables, and Cookie Rewards (little treats we give each other if we have to move something on the calendar).”

Once a month the entire team pauses for a five-hour, non-client project block of time called “internal day.” This time is reserved for studio-centric things: team members sharing learnings from conferences they’ve attended, how to improve internal practices, past project debriefs, etc. It’s the act of pausing with intent, in full effect.

Sara arrived a few minutes into my tour of the space, and the GGS team’s “BD charrette” was the first employee gathering (remote and in-person) of the morning. “BD” stands for “business development,” and in a cozy seating area, everyone had a seat at the table in all senses of the phrase. Sara and George ran through the status of a current request for proposal, then each team member had the opportunity to voice their opinion about whether the RFP should be pursued based on how it aligned with GGS’s (and their employees’) personal, values. Everyone was heard; every voice was respected.

The dialogue eventually shifted to another potential new client, this time with GGS at the presentation stage. Again, everyone at the table gave their feedback on Sara and George’s presentation plan of attack and, again, every team member’s voice carried equal value and weight. The studio-wide inclusion in the business owners’ decision making was genuine, effortless, and natural.

Forty-five minutes later, the group made a physical transition to a few nearby couches; less than a three-foot walk, as I eyed it. I inquired about the very minor spatial change for this next leg of the meeting and was told, “There’s a difference in purpose, so we transition to a different space.” Each member of the team then took their turn describing their weekend in three words:

“Sunshine, beach, baking.”

I got my turn as well. Changing the energy on those couches, from new business to being focused on the individual, made for a palpable climate change. In a few words everyone had a sense of what their teammates got up to over the weekend, eliciting smiles and planting the seeds for future dialogues throughout the pauses- with-intent over the rest of the day.

Next: “validations.” In this final portion of the meeting (pre- project status), anyone who wanted to articulate their appreciation for a team member over the previous week did so. One person recognized their co-worker for their selfless collaboration, taking time from their own project work to help theirs get client-ready on time. Similar-but-unique “thanks” emerged from varied people; no one was required to speak up, but everyone did.

After project updates I sat with Sara for a one-on-one to chat over coffee. I asked her about the synergies between their HCD process and how she interacts with her team in the office:

“I think where it’s actually become more intentional and obvious has been with our staff who are not trained designers. Operations folks, or our community manager, etc. I’ve had to say, ‘I want you to be a designer about this’ (whatever ‘this’ is). ‘We are your users, you’re trying to get us to do our timesheets, or clean up the kitchen, etc. Observe. Talk to people. Figure out our motivations. Summarize everything you’ve learned, and then have ideas.’

As a designer, I am constantly designing at every level. I’m designing deliverables in many cases for clients, or coaching our teams to design deliverables. I’m also designing process by which we work by writing proposals, scoping, etc. And at the highest level, I’m designing our company. I’m designing our culture based on our customs and traditions and policies (the hard and the soft) every day. My users are not hypothetical, they’re actual people.”

When All is Not Good

Sara went on to cite how her previous work experience shaped the leader she is today:

“I think a lot of my design choices are based in (unhealthy dynamics) with prior employers. Where decisions were not made transparently, everything financial was completely opaque. Lots of lack of trust with other employees. It’s been so critical that I’ve had bad experiences so I can now clearly say: let’s not do that.”

The tactics, mindsets, organizational shifts, and operational flexibility discussed in this book are predicated upon a simple truth: a company presently supports and operates as a creative culture, or it’s genuinely willing to evolve to become one. Along the way, I’ve been primarily speaking to those who are in a position to help implement change; even at a small scale. But what about when you’re not in a position to be heard, or the position to help facilitate change?

Reality isn’t always unicorns and rainbows. Bad experiences can impact us all. For example, the fabric of a company’s creative culture can become irreparably frayed thanks to management changes, acquisition, or it can lack sustainability. Whether these circumstances reveal themselves over years or overnight, your passion and evolution should never be their casualty.

Sometimes, creating within an environment that’s the best fit for your growth and passions means finding a new opportunity.

Mr. Roboto: Connecting with Technology

People don’t always need another human being to experience a sense of connection. The deep emotional bonds many people have with their pets proves this. (So might the popularity of the Pet Rock in the 1970s but that’s just speculation.) Even Link in The Legend of Zelda had an inanimate companion: his trusty sword (see Figure 9.1).

A screen from The Legend of Zelda where Link receives his sword from an old man saying 'It's Dangerous To Go Alone! Take This.'
Fig 9.1 Even the company of a wooden sword is better than venturing into Hyrule alone.

It’s also possible for people to feel that sense of connection in the context of behavior change without having direct relationships with others. By building your product in a way that mimics some of the characteristics of a person-to-person relationship, you can make it possible for your users to feel connected to it. It is possible to coax your users to fall at least a little bit in love with your products; if you don’t believe me, try to get an iPhone user to switch operating systems.

It’s not just about really liking a product (although you definitely want users to really like your product). With the right design elements, your users might embark on a meaningful bond with your technology, where they feel engaged in an ongoing, two-way relationship with an entity that understands something important about them, yet is recognizably non-human. This is a true emotional attachment that supplies at least some of the benefits of a human-to-human relationship. This type of connection can help your users engage more deeply and for a longer period of time with your product. And that should ultimately help them get closer to their behavior change goals.

Amp Up the Anthropomorphization

People can forge relationships with non-humans easily because of a process called anthropomorphization. To anthropomorphize something means to impose human characteristics on it. It’s what happens when you see a face in the array of shapes on the right side in Figure 9.2, or when you carry on an extended conversation with your cat.[1]

An assortment of the same four shapes side by side. The grouping on the right looks like a face based on the shape positions.
Fig 9.2 The brain is built to seek and recognize human characteristics whenever a pattern suggests they might be there. That means people interpret the array of shapes on the right as face-like, but not the one on the left.

People will find the human qualities in shapes that slightly resemble a face, but you can help speed that process along by deliberately imbuing your product with physical or personality features that resemble people. Voice assistants like Siri, Cortana, and Alexa, for example, are easily perceived as human-like by users thanks to their ability to carry on a conversation much like a (somewhat single-minded) person.

Granted, almost nobody would mistake Alexa for a real person, but her human characteristics are pretty convincing. Some research suggests that children who grow up around these voice assistants may be less polite when asking for help, because they hear adults make demands of their devices without saying please or thank you. If you’re asking Siri for the weather report and there are little ones in earshot, consider adding the other magic words to your request.

So, if you want people to anthropomorphize your product, give it some human characteristics. Think names, avatars, a voice, or even something like a catchphrase. These details will put your users’ natural anthropomorphization tendencies into hyperdrive.

Everything Is Personal

One thing humans do well is personalization. You don’t treat your parent the same way you treat your spouse the same way you treat your boss. Each interaction is different based on the identity of the person you’re interacting with and the history you have with them. Technology can offer that same kind of individualized experience as another way to mimic people, with lots of other benefits.

Personalization is the Swiss Army Knife of the behavior change design toolkit. It can help you craft appropriate goals and milestones, deliver the right feedback at the right time, and offer users meaningful choices in context. It can also help forge an emotional connection between users and technology when it’s applied in a way that helps users feel seen and understood.

Some apps have lovely interfaces that let users select colors or background images or button placements for a “personalized” experience. While these types of features are nice, they don’t scratch the itch of belonging that true personalization does. When personalization works, it’s because it reflects something essential about the user back to them. That doesn’t mean it has to be incredibly deep, but it does need to be somewhat more meaningful than whether the user has a pink or green background on their home screen.

Personalized Preferences

During onboarding or early in your users’ product experience, allow them to personalize preferences that will shape their experiences in meaningful ways (not just color schemes and dashboard configurations). For example, Fitbit asks people their preferred names, and then greets them periodically using their selection. Similarly, LoseIt asks users during setup if they enjoy using data and technology as part of their weight loss process (Figure 9.3). Users who say yes are given an opportunity to integrate trackers and other devices with the app; users who say no are funneled to a manual entry experience. The user experience changes to honor something individual about the user.

Screenshots of the LoseIt app showing it asking whether a user enjoys looking at data and using technology then acknowledging their choice.
Fig 9.3 LoseIt gives users an opportunity to share their technology preferences during onboarding and then uses that choice to shape their future experience.

If you can, recall back to ancient times when Facebook introduced an algorithmic sort of posts in the newsfeed. Facebook users tend to be upset anytime there’s a dramatic change to the interface, but their frustration with this one has persisted, for one core reason: Facebook to this day reverts to its own sorting algorithm as a default, even if a user has selected to organize content by date instead. This repeated insistence on their preference over users’ makes it less likely that users will feel “seen” by Facebook.[2]

Personalized Recommendations

If you’ve ever shopped online, you’ve probably received personalized recommendations. Amazon is the quintessential example of a recommendation engine. Other commonly encountered personalized recommendations include Facebook’s “People You May Know” and Netflix’s “Top Picks for [Your Name Here].” These tools use algorithms that suggest new items based on data about what people have done in the past.

Recommendation engines can follow two basic models of personalization. The first one is based on products or items. Each item is tagged with certain attributes. For example, if you were building a workout recommendation engine, you might tag the item of “bicep curls” with “arm exercise,” “upper arm,” and “uses weights.” An algorithm might then select “triceps pulldowns” as a similar item to recommend, since it matches on those attributes. This type of recommendation algorithm says, “If you liked this item, you will like this similar item.”

The second personalization model is based on people. People who have attributes in common are identified by a similarity index. These similarity indices can include tens or hundreds of variables to precisely match people to others who are like them in key ways. Then the algorithm makes recommendations based on items that lookalike users have chosen. This recommendation algorithm says, “People like you liked these items.”

In reality, many of the more sophisticated recommendation engines (like Amazon’s) blend the two types of algorithms in a hybrid approach. And they’re effective. McKinsey estimates that 35% of what Amazon sells and 75% of what Netflix users watch are recommended by these engines.

Don’t Overwhelm

Sometimes what appear to be personalized recommendations can come from a much simpler sort of algorithm that doesn’t take an individual user’s preferences into account at all. These algorithms might just surface the suggestions that are most popular among all users, which isn’t always a terrible strategy. Some things are popular for a reason. Or recommendations could be made in a set order that doesn’t depend on user characteristics at all. This appears to be the case with the Fabulous behavior change app that offers users a series of challenges like “drink water,” “eat a healthy breakfast,” and “get morning exercise,” regardless of whether these behaviors are already part of their routine or not.

When recommendation algorithms work well, they can help people on the receiving end feel like their preferences and needs are understood. When I browse the playlists Spotify creates for me, I see several aspects of myself reflected. There’s a playlist with my favorite 90s alt-rock, one with current artists I like, and a third with some of my favorite 80s music (Figure 9.4). Amazon has a similar ability to successfully extrapolate what a person might like from their browsing and purchasing history. I was always amazed that even though I didn’t buy any of my kitchen utensils from Amazon, they somehow figured out that I have the red KitchenAid line.

Spotify's Daily Mixes showcasing three distinct sets of musical styles based on the user's listening habits.
Fig 9.4 Spotify picks up on the details of users’ musical selections to construct playlists that reflect multiple aspects of their tastes.

A risk to this approach is that recommendations might become redundant as the database of items grows. Retail products are an easy example; for many items, once people have bought one, they likely don’t need another, but algorithms aren’t always smart enough to stop recommending similar purchases (see Figure 9.5). The same sort of repetition can happen with behavior change programs. There are only so many different ways to set reminders, for example, so at some point it’s a good idea to stop bombarding a user with suggestions on the topic.

A tweet from Andy Richter saying 'I ordered a toilet seat from Amazon and now based on the ads I see they must think I have an insatiable toilet seat addiction'
Fig 9.5 When a user only needs a finite number of something, or has already satisfied a need, it’s easy for recommendations to become redundant.

Don’t Be Afraid to Learn

Data-driven personalization comes with another set of risks. The more you know about users, the more they expect you to provide relevant and accurate suggestions. Even the smartest technology will get things wrong sometimes. Give your users opportunities to point out if your product is off-base, and adjust accordingly. Not only will this improve your accuracy over time, but it will also reinforce your users’ feelings of being cared for.

Alfred was a recommendation app developed by Clever Sense to help people find new restaurants based on their own preferences, as well as input from their social networks. One of Alfred’s mechanisms for gathering data was to ask users to confirm which restaurants they liked from a list of possibilities (see Figure 9.6). Explicitly including training in the experience helped Alfred make better and better recommendations while also giving users the opportunity to chalk errors up to a need for more training.[3]

The Alfred app takes a guess at places the user might enjoy for dinner and asks if any of them are right.
Fig 9.6 Alfred included a learning mode where users would indicate places they already enjoyed eating. That data helped improve Alfred’s subsequent recommendations.

Having a mechanism for users to exclude some of their data from an algorithm can also be helpful. Amazon allows users to indicate which items in their purchase history should be ignored when making recommendations—a feature that comes in handy if you buy gifts for loved ones whose tastes are very different from yours.

On the flip side, deliberately throwing users a curve ball is a great way to learn more about their tastes and preferences. Over time, algorithms are likely to become more consistent as they get better at pattern matching. Adding the occasional mold-breaking suggestion can prevent boredom and better account for users’ quirks. Just because someone loves meditative yoga doesn’t mean they don’t also like going mountain biking once in a while, but most recommendation engines won’t learn that because they’ll be too busy recommending yoga videos and mindfulness exercises. Every now and then add something into the mix that users won’t expect. They’ll either reject it or give it a whirl; either way, your recommendation engine gets smarter.

Personalized Coaching

At some point, recommendations in the context of behavior change may become something more robust: an actual personalized plan of action. When recommendations grow out of the “you might also like” phase into “here’s a series of steps that should work for you,” they become a little more complicated. Once a group of personalized recommendations have some sort of cohesiveness to systematically guide a person toward a goal, it becomes coaching.

More deeply personalized coaching leads to more effective behavior change. One study by Dr. Vic Strecher, whom you met in Chapter 3, showed that the more a smoking cessation coaching plan was personalized, the more likely people were to successfully quit smoking. A follow-up study by Dr. Strecher’s team used fMRI technology to discover that when people read personalized information, it activates areas of their brain associated with the self (see Figure 9.7). That is, people perceive personalized information as self-relevant on a neurological level.

A front and side scan from an MRI showing activation (in yellow) in the prefrontal cortex.
Fig 9.7 This is an fMRI image showing activation in a person’s medial prefrontal cortex (mPFC), an area of the brain associated with the self. The brain activity was recorded after showing people personalized health information.

This is important because people are more likely to remember and act on relevant information. If you want people to do something, personalize the experience that shows them how.

From a practical perspective, personalized coaching also helps overcome a common barrier: People do not want to spend a lot of time reading content. If your program can provide only the most relevant items while leaving the generic stuff on the cutting room floor, you’ll offer more concise content that people may actually read.

Color Craft & Counterpoint: A Designer’s Life with Color Vision Deficiency

So, what is it like to be color blind and also work in the web design and development industry? I'll answer that question throughout this article, but it's something that's always factored into my thoughts, given my passion for design and now my career. I wonder if having “normal” vision would have made me a better artist growing up. Would it make me better at my job now? Would I have pursued a more design-oriented career, as opposed to one that’s more dev-focused? These are just some of the things that pop into my head.

As to my job and my color vision, no, colorblindness doesn’t affect my work as much as you’d think. During design meetings, I can quickly point out areas where we need to reconsider our color palette. While reviewing layouts, I’m able to explain why we need to evaluate how—and if—we’re only conveying information with color. I like that I can bring a singular perspective to the table and a voice for others like me; I am able to offer insights that others don’t necessarily have.

When you can see a larger set of colors, it’s easy to gloss over those issues because they’re functionally invisible in the moment. If a design team doesn’t have a member who sees color differently, it’s important they find a way to test with actual users who do. There is no substitute for the real thing. 

Between workarounds anyone can use when color-sensitive situations crop up, and knowing how to separate myth from actual, smart usability practices for vision differences (and which design tools to use)—I want to set the record straight on a few things about designing with color and designing for color accessibility.

What it means to be color blind

The term color vision deficiency, or CVD, more accurately reflects the type of impairment I have.

When someone hears that I’m color blind, most immediately think that I can’t see colors whatsoever—that my entire field of vision is in grayscale, that I’m truly color blind. The term is very misleading and confusing because most people living with CVD are able to see many colors. (There are people who have a type of CVD called “monochromacy,” which is complete color blindness. About 1 in 30,000 people are affected, and they see the world in shades of gray.)  

Red-green color blindness is the most culturally-familiar type, but CVD is a lot more interesting and varies far more in definition.

So what colors can’t you see?

I have been asked this question more times than I can count. My answer is always the same: it’s practically impossible for me to say. For me personally, colors become harder to distinguish the less bold they are. I can attest with absolute certainty that the sky is blue, a stop sign is red, the grass is green, and Big Bird is yellow. I can see those colors because—whether by design or by mother nature—they’re bold. But start placing certain colors adjacent to each other, and it becomes more difficult for me. There are no colors that I can’t see, rather, certain colors become muddied and start blending together. It’s not the same for everyone; that’s just my version of CVD.

As light sensors go, humans don’t have the best eyes for color. Truth be told, they’re subpar compared to most species. WE are dismally color blind—as a species. 

On top of that, normal, “accurate” color vision varies from person to person; only minor anatomical differences determine whether your eyes are normal, “color blind,” or have extra (!) color vision powers. Let’s unpack all of that.

Without getting too technical, what I can tell you is that our retinas are responsible for our color vision. Retinas have two main types of cells: rods and cones. Rods are primarily responsible for reading brightness/intensity levels, while cones are more specialized for detail and for picking up a particular range of light wavelengths. A person considered to have normal color vision has three types of cones, one each for bandwidths of short, medium, and long wavelengths of light. The bandwidth each cone can perceive is shaped like a bell curve and is unique to that cone inside your eye, and there are overlaps between cones. Cones also don’t actually correspond to specific colors, but because long wavelengths fall more toward the red part of the spectrum, medium wavelengths hover closer to green, and short wavelengths tend toward blue, you’ll hear them called red, green, and blue cones, due to sheer convenience (Fig. 1).

Spectral diagram of three bell curves (one each for short-, medium-, and long-wavelength cones), indicating their typical ranges and peak response points.

Fig. 1. Normalized cone response spectra in humans for short (S), medium (M), and long (L) wavelengths. Notice the overlapping nature of the bell curves, and that the peak sensitivity for each cone doesn’t neatly match up with red, green, and blue.

Color vision deficiencies occur because one or more of these cones is missing or has limited sensitivity (such as a narrow range), or when color perception in the brain is influenced by various other phenomena. This means that those colors in the spectrum effectively “drop out,” but since the light is still there, the brain translates it into a color based on peripheral data picked up by the other cones, combined with its brightness level.

Since color vision is based on how our eyes and brain perceive light, and since our eyes have different genetic sensitivities to light, we can say that “accurate” color vision is somewhat subjective. Even people with “accurate” color vision don’t see things exactly the same way. 

Some people even have a fourth cone cell in their retinas; "tetrachromats" have enhanced color differentiation due to extra sensitivity between red and green. The extra cone actually came standard for most mammals in the past, but ongoing studies have suggested that 12% of the world's women might still have this fourth type of cone.

There are some colors and wavelengths we can’t see because our eyes don’t have the right sensors, but for others, it’s due to anatomical make-up. The lens and cornea physically block very short wavelengths; it's why we can’t see ultraviolet light directly, even though we have the sensor capability. For people with aphakia (lack of a lens in one or both eyes, whether congenital or due to surgical removal), that’s not a problem; they see the color variations in near ultraviolet light naturally.

Inside look at living with CVDs

I think each person who has a CVD has their own set of challenges. There are also a lot of commonly-experienced situations, social and professional obstacles, and forms of discrimination and bullying we’re expected to just quietly put up with. 

Vision disabilities and color vision differences are often treated as quirky, entertaining phenomena on some mysterious map between normal vision and “blind.” People with CVDs encounter condescending remarks and dismissive treatment as part of daily life. It’s an invisible and misunderstood struggle that doesn’t have to be that way. I want to make a difference, and it fuels my desire to educate people on this topic.

Insults and passive-aggressive comments

I’ve heard my fair share of passive-aggressive comments about my career choice. Also about my passion for art and design. Because how could I possibly be a designer if I can’t see colors? 

A question like that is condescending on two levels. One, it’s as if no one should be allowed to be an artist unless they can see colors accurately. And two, it shows a complete insularity or misconstrued awareness about color vision deficiencies.

Nowadays, I work primarily as a front-end developer, but early on in my career, I designed web layouts in Photoshop. I didn’t code anything. I didn’t even write HTML. I never had an issue with colors because I was typically starting with a client’s corporate branding guidelines, so I was able to take those colors and use color palette generators to help me build out the look of my designs. I was never called out for making poor color choices, so I felt like I was doing a good job. It wasn’t until I was having a conversation with my boss, a man I looked up to as a professional, when I dropped my guard and mentioned that I was color blind. He then proceeded to question my entire decision to pursue the career I love. For a new professional, it was a pretty rough and demoralizing encounter to sit through and try to process, to say the least. 

Justifying my skill set

It feels as though I have had to justify my career decisions and my skill set on a regular basis over the years—as if CVD prevents me from being good at my job. By and large, it’s truthfully not something that comes up most of the time in my day-to-day work. 

At this point, most coworkers only find out that I have a CVD if I talk about it. Sometimes I even get a kick out of seeing how many months can stretch out before a situation comes along where I can mention it. It’s become an increasingly minor issue over the years, what with updated software and web technologies I can put to use when needed.

Life via form factor (or winging it)

Think for a moment about ways that color is used to convey information in the world around you. One thing that comes to my mind would be traffic lights. Color is used to let drivers know how they should proceed. No additional information is provided in case a driver is color blind. Traffic lights also use two of the colors most commonly associated with color blindness: red and green. Thankfully, most traffic lights have a common form factor. The top light is red, the middle light is yellow, and the bottom light is green. Even if I couldn’t tell the color, as long as I can tell which light is lit, then I’m able to get the necessary information.

Unfortunately, not all designs are created equal; there may be no secondary or supplemental indicator to go by. When something is only conveyed with color, that’s a gap where information can get lost on a large group of people.

Everyday social interactions

Exchanging stories with others who grew up color blind sounds unfailingly familiar. Most of us have had similar experiences when it comes to people first finding out. As in part Q&A, part dog and pony show.

We’re constantly asked, “What color is this?” (points to a nearby object) and “What color does this look like?” Then we watch as the person who asked us the question has their MIND BLOWN because we can’t see the correct color. Meanwhile, getting the color correct can sometimes be worse. First, there’s a look of confusion on the asker’s face. They can’t comprehend how we can both be color blind and see color at the same time, which leads to even more questions and “tests.” It turns what could have been a brief exchange into a lengthy and technical conversation, maybe at a bad time or inconvenient location.

What I ended up learning is that these encounters will never go away, since most people I come into contact with have no knowledge about color blindness. I can either get annoyed by getting asked so many questions, or I can use it as an opportunity to educate.

Getting passed over for jobs

The first time I was passed over for a job specifically due to my CVD was when I was a teenager. It was a part-time job after school, and I was told—point-blank—it was because I’m color blind. A position had opened up in the frame shop at a big-box crafts store I’d been working at for over a year. After having been told I was getting the position, my boss somehow found out I’m color blind, then informed me that I wasn’t qualified to work in the frames department for that very reason. That was it, no discussion. I had to watch the position go to one of my coworkers. 

That may have been a minor blip on my teenage radar at the time, but little did I realize it was the first of many. Between the discrimination and frustration I dealt with at various jobs over the years, I eventually convinced myself to not tell new employers or coworkers about my color vision deficiency. I wasn’t going to lie about it if I got asked, but I wasn’t going to offer up that information unsolicited.

After working in the web industry for many years, I eventually transitioned to a new approach. At this point, I have successfully proven to myself that my color vision deficiency doesn’t negatively impact my job, and that bringing it up via the lens of accessibility makes it more of a natural thing I can discuss with coworkers so we can put it to constructive use on projects.

Inside look at how I do my job

Relying on tools for help

Being a professional front-end developer and designer with a CVD is easier than ever because there are so many tools and resources out there. Professionally, I have relied on color picker tools, websites that offer predefined color combinations, image editing software, and the mere fact that all colors can be represented by a hexadecimal value. 

In front-end tasks, I’m able to modify my code editor to suit my needs, for instance. I can use light or dark mode and a wide variety of color themes. I often use high-contrast themes that have been thoughtfully designed for developers with color vision deficiencies.

Tools and resources I use regularly:

  • Trello — Trello has a nice item labelling feature that takes CVDs into consideration. Not only can users label cards based on color, they can also use stripes, zigzags, polka dots, squiggly lines, and other shapes.
  • VSCode — Visual Studio Code is my preferred code editor. I’m able to customize the interface with pre-built themes, and I can further modify those themes if I need to. I’m currently using one called Vue Theme, which I feel works really well for me. I choose themes based on what feels like the appropriate color contrast for my specific color vision deficiency. I lean toward dark backgrounds with brighter, higher-contrasting text colors that stand out against the background color. Another one of my favorites is Sarah Drasners Night Owl theme.
  • Dev Tools — Whether it’s Chrome, Firefox, or Safari, I am constantly in the browser’s dev tools. There’s an ever-increasing number of features in dev tools that I can use to get the color information I need. Something I find handy is being able to Shift + click on a color value to cycle through various color formats (3 digit and 6 digit hexadecimal, RGB, HSL, and color name).
  • Color Pickers — I installed a color picker Chrome browser extension called Eye Dropper to help me quickly grab colors from web pages. It allows me to sample colors from any web page, and provides me with the color in every format. This provides me with a secondary reassurance that the color I wrote in my CSS is truly being rendered. I wish I could trust the code as I see it in dev tools, but occasionally my eyes play tricks on me—I would swear that the color I’m seeing rendered on the screen isn’t the color value in dev tools. When I think that’s the issue, I can just grab the eye dropper and triple-check.
  • Contrast Checker — I use the WebAIM Contrast Checker to make sure that the colors I’m using are in compliance with the guidelines.

Accessibility and inclusion

Statistically, 1 out of every 12 men and 1 out of every 200 women have a color vision deficiency. Across the world, approximately 300 million people are color blind. Those are significant numbers to factor in, especially if all those users are hampered by usability issues. Color alone can prevent them from completing interactions, receiving pertinent information, and from having the same experience as users with better color vision. That last fact alone is reason enough to pay attention to the concerns outlined here.

Color disabilities and the Web Content Accessibility Guidelines

The ADA doesn’t specifically call out color blindness; it simply refers to visual disabilities. However, the Web Content Accessibility Guidelines (WCAG) does specifically mention color. Compliance with the WCAG helps as a first step toward ensuring your site is usable by everyone, regardless of disabilities, but keep in mind that there could be additional factors at play with your site which may be “compliant” but still create difficulties for users.

Color contrast

For those of us who have a CVD, one of the more prevalent issues is a site’s color contrast; trouble with specific colors doesn’t necessarily mean we’ll have trouble with the site. 

If a site doesn’t have the proper color contrast ratio (text color on top of background color), then the site’s information may be more difficult to see or understand. WebAIM, a non-profit organization, published reports in 2019 and 2020 outlining accessibility issues in the top one million home pages. As of February 2020, 86.3% of home pages tested had insufficient contrast.

So, what does that mean? It means that the information on those sites is not being conveyed equally, to everyone. That’s 863,000 of the most influential and high-traffic sites on the web delivering an unequal user experience to billions of users worldwide on a daily basis.

Data visualization

Color contrast is not the only issue when it comes to color blindness and accessibility. Data visualization is one area in particular that often relies heavily on color to convey information. It is also a prime example of what the WCAG mentions in their success criteria: 

Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.

– Web Content Accessibility Guidelines 2.1 - Success Criterion 1.4.1 Use of Color

I follow a few accounts on Twitter that bring attention to improper use of color in data visualizations. I would recommend getting started with these—they provide a lot of useful information and raise awareness surrounding issues that those of us with a CVD face:

Thankfully, making charts, graphs, and other visual aids color accessible isn’t that difficult. There is no need to remove colors altogether. Just try to use colorblind-friendly color palettes and don’t use problematic color combinations. Make sure all the data in your charts is labeled appropriately so that your readers can get the information in multiple ways. Our World in Data—a scientific online publication that focuses on large global problems such as poverty, disease, climate change, war, and inequality—has great examples of data visualizations of all types that I would consider to be colorblind-friendly.

Whenever possible, I try to provide feedback from the perspective of someone who has a CVD, but I don’t make recommendations for specific color changes; I leave the color choices to those who aren’t color blind. Instead, I describe which elements I find difficult to interpret, and why. I tell them which information is getting lost on someone like me. The hope is that my feedback informs other designers of the need to make charts, tables, graphs, and maps more inclusive.

Adding people with a CVD to your team

As far as those of us who do have a CVD and work in the web industry: we are just as skilled and knowledgeable about our professions as anyone else, and there are plenty of ways that we can contribute to the visual aspects of projects—especially regarding color. We have the ability to review designs and report back whether any information is getting lost due to poor color contrast. We can inform designers if the chosen color palette is problematic. We can be the test subjects for our fellow UX designers during their usability research.

There is also another point I’d like to get across here. There is a common misconception that a designer with a CVD doesn’t have the ability to do their job effectively. Hiring managers and other coworkers often make this assumption. Much to the contrary, people with CVDs have ways they work smart to work around their limitations. I mentioned earlier about the different tools I personally use to help me in my job. There are plenty of web industry professionals like me who use features in the tools at their disposal, getting the job done right, and so seamlessly that no one would guess they are color blind.

That brings me to a broader point—the importance of hiring people with disabilities. I won’t go into the many, many, many reasons why companies should do that. Rather, I’ll mention some of the benefits from a design perspective. 

First and foremost, if you don’t have a disability, then how can you say conclusively that you know your product will work for those who do? 

The answer is, you can’t. Not without proper testing. Sure, there are companies out there that can help designers and developers conduct usability tests. But how amazing would it be if you had team members who could provide you with that invaluable feedback throughout the duration of each project? Think about all the knowledge you’ve accumulated about your profession. Think about all of the wisdom you can teach others. Now think about all the knowledge and wisdom that could be passed on to you by teammates living with a disability. Together, you can make your products truly inclusive. Trying to do it separately will always produce and reinforce limitations.

Critical CVD tips for your projects

Color can enhance the message, but shouldn’t be the messenger. UX and UI designers have within their power the ability to take color blindness into consideration—or to ignore it. You can make sure information is conveyed to everyone, not just people who see color “normally.” That is a great responsibility, with real life-or-death repercussions at stake for many users.

For those of us in the web industry, there are specific action items I’d like you to take away from all this.

Design color palettes for “everyone”

Carefully plan your color palette—not for those who are color blind, but for everyone. Always keep in mind that ALL the information you provide in your product needs to be easy to recognize and easy to understand by anyone who touches it. We can get too familiar with what we’re doing and forget that information is delivered in multifaceted ways, so we need to be mindful of what’s specifically being conveyed by color. 

I highly recommend Geri Coady’s book, Color Accessibility Workflows; it’s a fantastic resource. In it, she discusses color blindness, choosing appropriate color, compliance and testing, implementation, providing alternatives, and she includes some tips and tricks.

Don’t assume, and be careful what you ask 

Do not assume which colors are difficult to see—actually do the research and testing. At minimum, please check the color contrast in your layout.

The reason I say that is because although the ADA doesn’t call out color blindness specifically, it does call out visual disabilities. In the U.S., it is illegal in the workplace (not to mention insulting and unwise) to ask people if they have a disability. In my book, that also applies to color blindness, and while it may not be illegal to ask in non-work contexts, it is definitely personally intrusive. 

However, if people volunteer to help you with your testing and they offer up that information about themselves, that’s a different matter. It may also be a good idea to reach out to some companies that specialize in user testing with people with disabilities. 

Companies such as Level Access help organizations incorporate accessibility into their daily workflows. They offer tailored training, auditing services, document remediation, and other services to help organizations achieve—and maintain—compliance with Section 508 and the WCAG.

Test with colorblind simulators AND colorblind users

Don’t rely on colorblind simulators alone. I could write an essay about this topic. Those simulators are not accurate enough to give you a proper understanding of color vision deficiencies.

Seek out first-hand perspectives 

Actually speak to someone who has a color vision deficiency to get their perspective, and listen with an open mind. I can’t recommend this enough. There is no better way to get an understanding of what it’s like to live with a CVD than to hear about it first hand.

Stand up for coworkers and users

Don’t make light of color vision deficiencies. It’s difficult enough living with it, let alone being an artist with it or trying to make sense of information you literally can’t see.

Tools and further reading

Accounts on Twitter 

Usability and UX

Organizational resources

Color perception and the brain

Continuing to make progress

Loving design is something that has always come naturally to me; I didn’t have to force myself down this path. Growing up, I didn’t know that I wanted the exact job that I have, but by the time I graduated high school in 2000, I knew that I wanted to combine my passions for art and computers. 

I’m thankful to have been around long enough to have watched the web community evolve into what it is today. I’m thankful for all the tools that exist to help me do what I love in spite of my color vision deficiency. I’m thankful that color blindness is recognized by the WCAG, and that considerations are made for people living with color vision differences.

There is a lot of information out there, and I recommend that people go out and read as much as they can on the topic. If you’re on Twitter, then follow people who have a CVD, or the organizations that deal with it in various ways. There is so much knowledge that can be gained by doing some simple research and adding it into your workflow.

Building the Woke Web: Web Accessibility, Inclusion & Social Justice

What would your life be like without the internet? Not if it didn’t exist at all, but if you were locked out of it? Would your days be different? Unrecognizable, even? Keeping your answers to that in mind, do you think access to the internet is a human right? Do we need to be able to access it to fully participate in modern society? To answer “yes” to these questions would have been unthinkable 20 years ago.

Living without internet

Globally, over 40% of people still do not have access to the internet. That lack of access and the issues it creates have helped motivate digital equity initiatives like Tech Goes Home and the Good Things Foundation.

Having no access to the internet creates problems in many parts of modern life. In the UK, bank branches are closing, forcing many to do their banking online. Many utilities now require internet access to request or amend services, or get better deals. Civil services, such as registering to vote, are increasingly online. As this continues, people who have no access to broadband or who have limited access to mobile data fall behind—this often includes homeless people, elderly people, and those on low incomes who are already operating at a disadvantage.

In the UK, only 37% of people living in social housing are online. Approximately 1 in 5 adults with a disability in the UK have not used the internet recently, and they make up half of the people who have not accessed the internet in the last three months. Globally, the UN target for affordable mobile data is 2% of monthly income for 1GB data, and yet many countries are still nowhere near reaching this goal. Not having access to the internet is expensive, locking you out of essential services and a surfeit of helpful information. Giving people full access to the splendors and knowledge of the online world should be imperative for everyone who works on it.

Digital exclusion is when someone is unable or unwilling to access information and services online. In the UK, 10% of the adult population was digitally excluded in 2018. The number of people in the UK lacking basic digital skills is decreasing, but in 2018, 8% of adults in the UK (4.3 million people) were estimated to have zero basic digital skills, which means they are unable to do things like buy items online, verify information, or send an email. Women are more likely to have no basic digital skills. 

Being unable to send an email, submit an application online, or use a government site is a huge barrier to civic and societal engagement. Shopping in person, rather than online, can mean you are consistently overcharged for your purchase by as much as 13%. Not knowing how to use computers can mean you earn less in the first place. Not being able to use the internet can mean that you spend more time doing tasks such as registering to vote, paying council tax in the UK, or researching your next holiday

Being able to access the internet has social and psychological ramifications too. Loneliness is well documented as a risk factor for a number of health issues, as well as early death. Being online can help you feel less alone. Half of all people with disabilities surveyed report feeling lonely in the UK, and a quarter of them are lonely every day. People with disabilities are more likely to be a captive audience to apps and websites using their data inappropriately or engaging in other unethical practices. This may be because they rely on a particular site to interact with other people with disabilities, because they lack the tools to visit other sites, or lack other suitable websites or apps to use.

Richer households are more likely to have full basic digital skills. The UK Office for National Statistics found that people without basic digital skills are three times as likely to be in low-income bands. In 2018, 12% of 11-to-18-year-olds had no broadband access on a tablet or computer, which 68% of them said made it difficult to do homework. Further, households in which one or more of their members have a disability make up half of those living in poverty in the UK.

Provide non-online options for vital services

If you work in government, food supply, healthcare, or utilities, there is no excuse for not providing offline options. In doing so you are excluding some of the most marginalized people. The internet is amazing, but it is not the only way to share information.

A non-exhaustive list of other barriers

Having access to the internet in the first place is one issue, and feeling welcome, or even safe is quite another. Even when your broadband connection is as good as can be hoped for, there are many other ways you can be discouraged or stopped from using the internet.

Trolling and threats

Online harassment is one of many barriers stopping people from accessing the internet. Diane Abbott, the first black woman Member of Parliament (MPs) in the UK, received almost half (45.14%) of all abusive tweets sent to female MPs in the run-up to the 2017 General Election that decided how voters would be represented in Parliament and which party would govern. Black and Asian women MPs got 35% more abusive tweets than white women MPs. The abuse directed at Dianne Abott amounted to 10 times as much as was received by any other female MP, according to an Amnesty International study.

Mermaids is a charity that supports transgender children and their parents in the UK. Their CEO Susie Green—herself the parent of a transgender child—has been targeted with abuse and threats. The rise in abusive and threatening comments led to Mermaids’ Twitter account having to block up to 20 accounts a day.

Trolling isn’t an easy problem to fix. Allowing users to block certain words and hide certain replies on Twitter is a start, but listening to people from marginalized backgrounds and their complaints and ideas would be another critical place to begin. 

We need to think long and hard about what good moderation looks like and what guidelines work in online spaces to ensure those accessing them don’t have to wade through a tide of bigotry.

Sidelining and hiding certain groups

Information and support online are vital for at-risk LGBT people, whether to help them escape dangerous situations, access support, or find community. Yet in schools, words relating to LGBT issues are often blocked. On YouTube, videos relating to LGBT issues are demonetized, age-restricted, or even removed. This isn’t because the content is sexually explicit or not safe for work. It’s just discrimination. TikTok recently admitted it actively discriminates against certain kinds of users—namely the fat, queer, disabled, low-income, and “ugly”—in certain feeds, under the guise of paternalistic protection from bullying.

Exclusionary design

People with disabilities are the original life hackers because our motivation is so high. If we don’t hack we often go without.

Liz Jackson, “Designing for Inclusivity

Many people with disabilities rely on screen readers and screen reader compatible sites to use the internet. Screen readers can be prohibitively expensive; while there are free options, one of the most popular screen readers at the time of writing costs nearly $1200 for a professional license. Even with incredible innovation coming from within the disabled community, there’s more that everyone else can do. In their February 2020 evaluation, WebAIM found that 98.1% of the top million websites had detectable WCAG (Web Content Accessibility Guidelines) 2 errors.

The most common WCAG 2 failures—such as missing alt text for images, having empty links, and missing form labels—would be relatively simple to fix. Because they’re shared among most websites, concentrating on fixing them would have a huge overall benefit for the internet. But as long as web accessibility standards are applied without rigor, aspects of a vast number of sites remain inaccessible even once users have a screen reader or other assistive technology.

Hostile conditions

Inclusion is just as pertinent as accessibility, and tackling only one side of the equation will leave some people just as locked out. Accessibility without inclusion is not real accessibility. The curb cut effect, wherein improving access for people with disabilities improves access for all, isn’t the only reason to increase web accessibility. We have a moral responsibility as tech workers to use any privilege we may have to facilitate, respond to, and support the efforts of marginalized people who are working to carve out accessible spaces for themselves.

Hostile conditions, created or reinforced by engineering and design choices, make being on the internet harder for people who are queer, of color, or disabled. They make it more difficult to access life-saving spaces, social spaces, and civic spaces—both on and offline. Thorough accessibility and real inclusion are the solutions to these problems. To survive, marginalized people must work both against and through the abuse and accessibility issues they face on online platforms, whereas everyone else gets to use the internet as they wish. This replicates the injustices of offline in the online world.

An incomplete list of solutions

Center the voices and experiences of the marginalized

There isn’t one easy solution but to start finding the solutions that are possible we need to center the voices and experiences of the marginalized. Marginalized people with insights to share aren’t hard to find when you start listening. They are your next users, your future developers, your fledgling marketing team. Excluding them reduces your options, your appeal, and your breadth of ideas.

Hire teams that are diverse on every axis

Hiring inclusively creates teams full of people who aren’t like you or each other. And those kinds of teams build better products, bring better ideas to the table, and better reflect the user base of the majority of products. It is important to remember that diversity isn’t just about race or hiring women; there are neurodiverse people, people with physical disabilities, people of other genders, people from various backgrounds, and many other marginalizations than could be listed here.

Proactively promote inclusion and harness your team’s diversity

Help disabled and otherwise marginalized people both develop and enforce policies and practices that protect them and allow them to thrive. If there are no disabled people, or otherwise marginalized or underrepresented people on your team, take a hard look at your hiring practices, your work culture, even the layout of your office. If you can’t find these problems, hire experts. Pay specialist consultants and recruiters to root out the problems. This is an investment that makes moral, logical, and business sense. The inclusive team you build will be able to spot potential issues in a way that a squad of people who pattern match to narrow ideas of what a tech worker should look and behave like never would. Create a culture where the marginalized members of your team feel supported, feel heard, and are buoyed through their work with a sense of safety in their workplace.

Avoid legal issues preemptively

Beyonce and Domino’s Pizza were both sued under the Americans with Disabilities Act, which contains provisions to force the companies involved to change their websites. Beyonce’s case is still in progress, but Domino’s both lost their suit and had their appeal tossed out. Both cases were about visually impaired people being unable to access their sites and complete purchases. Accessibility is often seen as a costly detour from the “real work” of building projects, but that has never and will never be true. You want users, and users of all stripes want to use your products.

The banks HSBC, Metro Bank, and Halifax made it hard for visually impaired users to access all of their services online. When HSBC was told they had made it difficult for a user with visual impairments to access bank statements, they replied, “don’t worry, we’ll send you a video.” The Equality Act 2010 in the UK means that these users can sue. In addition to serving the far more important goal of providing people with disabilities equal access, embracing inclusive design from the outset would have saved these companies time while enhancing their trust among the public rather than putting it at risk. Fixing the content is usually much cheaper for the organization than fighting the matter in court.

Advocate for accessibility and inclusivity in any way you can, be it big or small

Caption your videos, Instagram content, Facebook photos, Twitter photos, conference and meetup talks, etc. Make information needed to access your product or service available in multiple formats. Speak up against problems in your workplace; if an internal hiring tool is hard for you to use, it is hard for others. If one of your websites has errors from WCAG 2’s list, advocate for taking time to fix it. If the gender options available on forms are “man,” “woman,” and “other,” speak up yourself, tell your manager, question whether you need to collect gender information at all. Don’t stay silent.

Test your website with tools, devices, and real end users

Run tools like axe, ChromeLens, and Lighthouse during your build processes. Do manual testing with the actual devices that are used by your end-users, and test with real users with access requirements. If you’re a team of one or a few, ensure that you run these tools from MVP to finished product—the errors that are the easiest to catch and fix will mostly be caught by automated tools, and they are a great start for learning more about accessibility. Websites such as The A11y Project compile resources, and there are other websites, Slack groups, Twitter accounts, and newsletters that are also incredibly helpful for answering any questions. The automated tools will give you the keywords to search for.

Working towards an accessible, inclusive internet

Web accessibility is not an optional extra. What inclusion looks like in practice will depend on your products, your users, and what you intend to achieve, but for it to be real and meaningful in any context, it cannot be an afterthought. Engineering that makes inclusion an afterthought is engineering that operates without morality and in doing so actively enacts harm. The fact that this kind of engineering is commonplace on the internet doesn’t make it OK. It just highlights that the way we have built the web is fundamentally broken. We can do better.

“Wokeness,” at least as conceived by those divorced from the black experience and AAVE, isn’t a great concept. The way it is used in popular culture makes it sound as if being a good person is a switch you flip on and off; you’re woke or ’sleep. But wokeness is not the end state, it’s the beginning of a journey. All the tenets of intersectional feminism, web accessibility, and diversity and inclusion are inextricably tied up in making the web a better place, for all and by all. Access to the internet is essential. Staying woke, and acting on that wokeness, is what will lead us to a better internet for everyone.

Figure It Out

Color is, without a doubt, the visual element most often misunderstood and misused.

As mentioned earlier, when designing visual representations, color is often the first visual encoding that people use. It’s also quite limited to about a dozen, distinguishable colors. It’s a potent visual element, but one fraught with accessibility and perceptual problems. A general rule of thumb: Save color for things you want to draw people’s attention to. Start with grayscale representations. Add in color only later, where it might be really, really useful. That’s it. We can move along.


We need to dispel some popular beliefs about colors, beliefs that are often held up as truth, when, in fact, this is not the case. What’s presented in this short chapter is more foundational knowledge than tips for immediate application. But also, this understanding of color is—we found in retrospect—a powerful lens for understanding the concepts shared throughout this book. We see in our exploration of color this pattern: while many of the absolutes we cling to are social constructs (varying across cultures and over time), behind these changing constructs we also find some universal human constants.

How Many Colors Are in the Rainbow?

Let’s begin by unpacking the statement above, suggesting that we only see about a dozen colors. Actually, the human eye can perceive many more colors, perhaps a million or so. Of this million, it’s estimated that each of us—individually—can distinguish somewhere between 130 to 300 colors.[1] But within a cultural group, we can only share about a dozen such colors. These limitations have little to do with personal visual acuity, but rather with language: a group’s ability to see and perceive a specific color is determined by language. Do we—as a society—share the same named color value associations?

We can talk about something being “red” and feel confident in what we all see. From both a developmental perspective and an anthropological perspective, red is the first color (after white and black) that most cultures are aware of. But if I describe something as magenta, do we have a shared agreement as to what that named concept refers to? Perhaps you see hot pink where I see a vibrant, purply-reddish color? Another example of this language-color dependency: the Russian language has a specific word for the color that we (English speakers) perceive as light blue.

To put this shared vocabulary into perspective, let’s start with something that is constant and beyond our language: the visible spectrum of light that is a rainbow.

When Colors Are Constant

Around the world, the meteorological phenomenon we describe as a rainbow is a constant thing. Light refracts across water droplets to create a spectrum visible to humans. What we see as colors are the wavelengths of light visible to the human eye (see Figure 8.1). On either end of this visible spectrum are ultraviolet and infrared waves, which while invisible to human eyes, we know they are visible—that is, seen—by cameras and some nonhuman creatures (cats can see certain infrared frequencies, for example). Beyond this visible spectrum, we have things like gamma rays, X-rays, and radio waves, which all make up the entire spectrum of white light from the sun.

A diagram showing the spectrum of light
Figure 8.1 The visible light spectrum is a small part of the broader electromagnetic spectrum. Starting from this perspective helps us recognize the subjectivity of what is “seen” and how this might vary with different creatures and devices.

But let’s stay focused on the portion of this light spectrum that is visible to humans, the part that allows us to see. Within this spectrum, the rainbow possesses millions of color combinations, as there are no clearly defined boundaries between the colors.

Why then, should diverse cultures over thousands of years arrive at the same set of color language definitions? Are colors an absolute thing? Not exactly.

The Subjectivity of Color Identification

Consider “ROYGBIV,” which is the acronym we all learned to name the colors of the rainbow. How did we conclude, at least in Western cultures, that a rainbow has seven colors? Why not five, or six, or eleven? We have Sir Isaac Newton to thank for this.

These seven colors—red, orange, yellow, green, blue, indigo, and violet—were not the result of any serious scientific inquiry. Rather, Newton was fond of the number seven. Just as there are seven musical notes in a scale, Newton believed that colors should follow a similar pattern. He might have connected this with seven days in the week or the seven known planets (at the time) in our universe. In other words, ROYGBIV was an arbitrary choice based on mystical superstition.

Understanding how we arrived at these seven colors sheds light on the subjective nature of color identification. This may also explain a bit about the challenge that so many people have with indigo—that odd color that sits somewhere between blue and violet—as a separate color!

But here is where we have to be careful, as we are stepping into a decades old debate: Do the number of basic color terms and the location of color category boundaries vary across languages? Or might there be a universal pattern to the color naming systems of all cultures?

This Wikipedia entry sums up the debate rather nicely:

There are two formal sides to the color debate, the universalist and the relativist. The universalist side claims that the biology of all human beings is all the same, so the development of color terminology has absolute universal constraints. The relativist side claims that the variability of color terms cross-linguistically (from language to language) points to more culture-specific phenomena. Because color exhibits both biological and linguistic aspects, it has become a deeply studied domain that addresses the relationship between language and thought. [2]

An Argument for Relative Linguistics

We can characterize what Newton did as imposing an arbitrary number of colors upon the color spectrum. And we might conclude the same thing has happened throughout history as different people groups formed words to describe the world around them.

Indeed, various studies of diverse cultures reveal that “although the physiological basis of color vision is essentially the same for all humans with normal trichromatic color vision, there is considerable diversity in the way that different languages segment the continuum of visible colors.”[3] In other words, the rainbow has no natural boundaries; how we slice it up into colors is a subjective thing that varies across different cultures and time. (See Figure 8.2 for an illustration of this concept.) From one research paper, we learned that “some languages have been reported to use as few as two terms to describe all visible colors (Rosch Heider, 1972). Others have been reported to use between three and eleven (Berlin & Kay, 1969), while some (e.g., Russian; Davies and Corbett, 1997) may have twelve.”[4]

Specific examples in support of this argument:

  •  In Russian culture, there is no generic concept of blue. Rather, Russian makes an obligatory distinction between lighter blues (goluboy) and darker blues (siniy).
  • The Japanese language (before the modern period) had just one word, Ao, for both blue and green. It wouldn’t be until the year 1,000 that the word midori would be introduced to distinguish a greenish shade of blue
  • The Himba tribe from Namibia recognizes five basic colors.
  • The Berinmo of Papua New Guinea has also reached a different conclusion as to the number of colors they recognize. While they draw no distinction between blue and green, they do “draw a distinction within what English speakers would consider yellow, with the word nol on one side and wor on the other.”

From this, we might conclude that the colors of the rainbow do seem to be arbitrary and dependent upon language. (Connect this with earlier points we made about thoughts and cognition as layers upon layers of prior associations.)

A webcomic from XKCD, reading 'This chart shows the dominant color names over the three fully-saturated faces of the RGB cube (colors where one of the RGB values is zero)
Figure 8.2 This comic from Randall Munroe of xkcd nicely illustrates the subjectivity of the shared color language for English speakers.[5]

But surely, you may be thinking, color identification isn’t entirely subjective? Here’s where the research gets interesting: despite these regional differences, a fascinating and consistent pattern begins to emerge.

An Argument for the Universal

In the late 1960s, after studying color terms across many different languages, researchers Berlin and Kay introduced the idea that there were eleven possible basic color categories: white, black, red, green, yellow, blue, brown, purple, pink, orange, and gray. They argued a universalist theory: that color cognition is an innate, physiological process rather than a cultural one.

While their research has been challenged on different grounds, what has since followed is some agreement that for all noted language differences, there is a fixed order in which color names arise. The ways in which color language evolves across cultures suggest maybe there is a universal pattern governing the direction of patterns in the evolution of colors. All cultures start with the ability to distinguish dark things from light things. This is followed by the recognition of red. After that, it might be the addition of yellow or green. And blue always seems to come last. Not every language follows the exact same path, but they adhere to this same general pattern.

While the broader debate is not necessarily concluded, the general consensus seems to be that “in color, relativism appears to overlay a universalist foundation.”

Why All the Fuss over Color?

While this is certainly fascinating, how is this useful? We include this as a mirror to challenge assumptions. If we turn a critical eye to the commonly accepted color wheel, this was likely influenced by Newton’s original color wheel sketch. But is this the “right” way to think about colors? Primary colors combine to make secondary colors, which in turn allow us to describe tertiary colors. We learn this from an early age and accept this way of thinking about color as absolute. But this is just one frame. This is just a way of thinking about visible light. And this singular perspective has limitations, especially when used in medical, scientific, and engineering visualizations. Research papers such as “Rainbow Color Map (Still) Considered Harmful”[6] question the value of the rainbow color spectrum in data visualization applications. The point is simple: there are other ways we might think about color. We can look at alternatives such as perceptually ordered color spectrums, an isoluminant color map, or simply use representations of color that aren’t derived from a wheel. Tools such as ColorBrewer 2.0[7] or the NASA Ames Color Tool[8] are incredibly useful for choosing a palette more suitable for visualizing data.

Since this book is concerned with how human creatures understand information, and because we so often use color to clarify, we felt it worth calling out that color and color recognition are not necessarily universal things, but are dependent on cognition, language, and biology. Understanding this allows us to challenge common assumptions about what is “true” about color and perception.

Which leads us to…

Color, Cultures, and Universal Associations

Red means stop. Green means go. These concepts are universal, right? Not so fast. Across cultures, colors do not necessarily convey the same concept. And where we may have the same ability to identify a color, the associated meaning is just that—a learned association. Concluding that red means passion, vitality, or energy, because blood and fire are red things is not a universal idea. Neither is associating green with growth, just because nature involves so much green. (In some Chinese cultures, green can be associated with death.) At this point, please throw away those blog posts and posters about colors to choose for different cultures. While we’re keen to seek out human universals, color has proven to be something that does not have consistent meaning across cultures, or even within a culture group. Rather, the concepts we associate with particular colors are highly contextual and local, not just to a particular culture, but sometimes to smaller social groups. The meanings we point to—blue as a safe, corporate color, for example—are highly generalized assumptions, highly contextual, and mostly learned associations.

The Color Purple

Let’s take purple, as an example. For many centuries, purple dye was expensive and rare. Procuring purple dye was labor intensive and required collecting a secretion from sea snails. Historian David Jacoby remarked that “twelve thousand snails of Murex brandaris yield no more than 1.4 g of pure dye, enough to colour only the trim of a single garment.”[9] As a result of this laborious process, the high cost of producing purple clothing made this color a status symbol among kings, queens, and other rulers. If you could afford to wear purple, you were quite wealthy. The conceptual association then is one of scarcity (in this case of a particular dye), signaling something to be valued above other things. While we may still see the lingering effects of this history (the Purple Heart is among the highest honors awarded for U.S. military service), the constraint of purple as a scarce color is no longer true. As such, this color is able to take on new meanings.

“Pink Is for Girls, Blue Is for Boys”

To put this into perspective, let’s investigate the idea that “pink is for girls, blue is for boys.” From clothing choices to marketing toys to how we decorate bedrooms, most of us grow up believing there’s some inherent gender association built into the colors pink and blue. But, were we to travel back in time—just over 100 years—we’d find no such distinction. Or we might find the opposite association.

According to University of Maryland historian Jo B. Paoletti, author of Pink and Blue: Telling the Girls from the Boys in America, pink and blue weren't always gender-specific colors. For centuries, young children mostly wore a functional white dress, and then in the early 20th century, things began to change. Consider this quote, pulled from the June 1918 issue of Earnshaw's Infants’ Department, a trade publication:

The generally accepted rule is pink for the boys, and blue for the girls. The reason is that pink, being a more decided and stronger color, is more suitable for the boy, while blue, which is more delicate and dainty, is prettier for the girl.

A Smithsonian review of Paoletti’s book,[10] goes on to add:

Other sources said blue was flattering for blonds, pink for brunettes; or blue was for blue-eyed babies, pink for brown-eyed babies, according to Paoletti.

In 1927, Time magazine printed a chart showing sex-appropriate colors for girls and boys according to leading U.S. stores. In Boston, Filene's told parents to dress boys in pink. So did Best & Co. in New York City, Halle's in Cleveland, and Marshall Field in Chicago.

By the 1940s, this association had flipped. Manufacturers had settled on pink for girls and blue for boys (see Figure 8.3 as an example of this association). Baby Boomers were raised with wearing the two colors. The point of this narrative? Color associations are learned things and can change over time. Even something as seemingly strong as the pink/blue binary was a manufactured association. To be clear, this doesn’t mean a color association is any less powerful in the moment, at a particular point in history, but these color associations do not represent any universal truths.

A box of 'It's a boy!' baby announcement candy cigars in blue
A box of 'It's a girl!' baby announcement candy cigars in pink
Figure 8.3 - The “blue is for boys and pink is for girls” concept was a manufactured one, originating in the first half of the 20th century.

Accordingly, it’s good to be wary of generalizations such as “blue is a safe, corporate color.” In the case of corporate associations, one generation’s “safe” may—depending on the media and actions—signal stuffy, inauthentic, or distrustful to the next generation. It all depends on the learned associations embraced—for a time—by a particular culture.

Not All Colors Are Created Equal

We tend to treat our color palettes like interchangeable parts. Just pick a color. Or pick some colors we all find pleasing. Consider how many of us use the default color palettes built into software tools like Excel or PowerPoint. We usually choose a pleasing color palette, with the sentiment being “as long as you can distinguish one color from another, it’s okay, right?”

Not exactly. Not all colors are created equal. In terms of visual perception, some colors jump out at you while others recede into the background (see Figure 8.4). This is because of variances in hue and saturation.

A series of four charts, each with an increasing number of colors
Figure 8.4 The range of colors perceived by humans is uneven.
(Equiluminant colors from the NASA Ames Color Tool)

A very bright color is going to draw more visual attention than a more desaturated color. This makes sense if we consider how things farther away from us tend to be hazier and desaturated. If something in the distance is noticed, it’s likely because it’s moving or contrasts with the surroundings.

This same disparity applies to color hues. We tend to look at color charts like this one and assume that the extreme ends of red, green, and blue are on equal footing.

Two gradients, one going from black to red, one going from black to gray
Two gradients, one going from black to green, one going from black to gray
Two gradients, one going from black to blue, one going from black to gray

However, because of the wavelengths of these colors and how our eyes perceive color, we see green as brighter than red, which itself is brighter than blue.

How Is This Knowledge Useful?

While it’s nice to think that precise color values are interchangeable (setting aside any cultural associations), your perception doesn’t work that way. In the same way that certain frequencies on the radio come in clearer than others, certain colors do the same. You need to account for, or at least consider, the unevenness of color perception.

In the example in Figure 8.5, you see the same eight-segment pie chart. The example on the right uses all high-saturation colors while the example on the left mixes high- and low- saturation colors.

Two equal pie charts with differing levels of saturation in the colors
Figure 8.5 Two pie charts showing identical information. The chart on the left uses colors of mixed saturation, meaning some colors will naturally stand out more than others, making this an uneven representation.

Functionally, these both communicate the same thing. But consider how you perceive each. With the example on the right, use of high saturation is consistent; no color should be more prominent than another. But when you mix high and low saturation, as with the example on the left, the higher saturation colors tend to “pop” more—drawing you to these segments. While this chart is more aesthetically pleasing (as it uses half as many colors), it’s also a bit misleading—notice how your eye is drawn to the orange segment in the upper right. The lesson? Assuming the goal is objectivity and truthfulness, you’d want to avoid mixing saturations and hues that are unevenly perceived. If the goal were the opposite, to draw attention away from or toward a particular bit of data, you could manipulate perception by adjusting saturation and hue (not that this is being recommended!). This ability to direct attention by using bolder colors is something that everyone should be aware of and intentional about.

Jobs To Be Done

In this chapter, you’ll learn about these plays:

  • How to create a jobs-driven roadmap
  • Using job stories to solve specific design problems
  • How to architect the structure of a solution
  • Testing assumptions directed by JTBD

A software company I once worked for held what were called “hackweeks” once a quarter. This was a time for developers to work on “whatever they wanted,” as it was framed. Give engineers time to play around with technology, and they’re bound to find the next innovation, or so the theory went.

Hackweek was a big deal for us. Dozens of people organized it, and every developer in the company stopped work to contribute to the effort. It was costly, but we were committed to hackweek. After all, new software offerings come from new development, right?

Here’s how it went: small teams formed to cobble together starter projects representing the use of some new technology. At the end of the week, a panel judged the dozens of concepts that emerged, and the winning “solutions” were rewarded.

But in our case, hackweek was like shooting a shotgun in the wrong direction while blindfolded and hoping to hit the target. The result was inevitably a collection of concepts looking for a problem to solve. It was innovation theater at its best.

To be fair, not all hackathons are bad. Some organizations coordinate hackathons with strategic imperatives or with customer needs. And sure, it’s also good to flex creative muscles and practice collaboration across teams. But given their cost and imprecision, hackathons are often largely ineffective in producing usable concepts.

The problem is not a lack of ideas—companies are usually swimming in them. Like ours, many organizations have a Darwinistic outlook on innovation: generate more and more ideas, and the best will surely rise to the top. Said another way, when looking for a needle in a haystack, the best approach is rarely to add more hay.

The problem is knowing which ideas to pursue. The goal of innovation activities shouldn’t be to collect as many ideas as possible, but instead to get to the right ideas—the ones that matter most to the people you serve.

But more than that, the real challenge is in overcoming the natural forces in organizations that keep good ideas down. Chief among these is uncertainty, a leading deterrent to innovation. New ideas are a gamble for risk-averse managers, even if well-expressed in a high-fidelity prototype.

JTBD provides a way to increase your chances of success by first identifying the right problem to solve. Then JTBD gives you decision-making criteria for moving forward: bet on solutions that address unmet needs to create profitable differentiation.

Focus first on getting the main job done for the individual and fulfilling their needs in relation to the job. From this perspective, hackathons and other idea-generating efforts can be framed by JTBD as both inputs and outputs in terms of how concepts are evaluated.

After understanding the job landscape and defining the value you’re going after, you can continue using JTBD thinking to align teams around the design of your solution. Create a roadmap based on your JTBD landscape to set a common direction. Then use job stories to get everyone on the same page and tie local design efforts to the big picture and to architect the solution structure. JTBD can also guide the experiments you conduct to test your team’s assumptions.

Create a Development Roadmap

At its highest level, a roadmap is a sequence of development events—the relative chronological order in which features and capabilities will be built. Roadmaps serve as a central point of reference for teams to align their efforts. They show the path forward without defining individual tasks.

In the age of Agile and Lean efforts, roadmaps have gotten a bad reputation. People are quick to point out—and rightfully so—that long-term plans inevitably fail: priorities change, unforeseen challenges arise, and timelines slip. The solution, they might argue, is to have no long-term plans and to work on short initiatives with the flexibility to change as needed.

But while providing decision-making power to local development teams makes sense, overall alignment is still needed. An alternative way of viewing roadmaps is to see them not as a definitive project plan, but as a vision of how you’ll create an offering that customers will value. Roadmaps are not unchanging predictions of future activity, but a way to provide transparency for the sequence of steps your team will take to design solutions.

The information in a roadmap helps the entire organization get aligned, not just developers. It’s a strategic communication tool reflecting intention and direction. More importantly, road mapping isn’t just about the artifact: it’s about getting a common understanding of where you’re headed. In this sense, the roadmap occupies the space between the vision and detailed project planning.

JTBD can help create roadmaps that focus on the value that the organization intends to create and deliver for customers. The trick is to get the right problem to solve. Use the insights from your JTBD investigation to formulate roadmaps that are grounded in real customer need.

Mapping the Road Ahead

For a concrete approach to road mapping, I recommend the book Product Roadmaps Relaunched by C. Todd Lombardo, Bruce McCarthy, Evan Ryan, and Michael Conners.[1] In it, the authors clearly articulate the steps to creating meaningful product roadmaps.

JTBD plays a key role in aligning to customer needs, as the authors write: “We recommend starting with the chunks of value you intend to deliver that will build up over time to accomplish your visions. Often this is a set of high-level customer needs, problems, or jobs to be done.”

Their approach breaks down the four key elements of a good product roadmap:

  • Product vision: The vision outlines how your customers will benefit from your offering. How will the job performer benefit from the solution? What will getting the job done look like after the solution is in place?
  • Business objectives: A roadmap must be aligned with the organization’s strategy and objectives. The goals of the business are important for measuring progress.
  • Timefames: Rather than committing to specific dates, good roadmaps sequence work and set broad timelines for completion.
  • Themes: These are the key problems that customers face when completing a job, or clusters of needs that align to the overall solution to be created. JTBD helps frame the themes of your roadmap in particular.

Figure 5.1 shows an example from their book of a basic roadmap overview for a fictional company, The Wombatter Hose, illustrating these main components. Note the disclaimer, as well, indicating that the roadmap is subject to change.

Figure 5.1: An example of the main components of a roadmap from the book Product Roadmaps Relaunched.2

Putting it all together, the process for creating a JTBD-driven roadmap can be broken down into four phases.

Step 1: Define the solution direction.

Define the various elements of your overall product strategy to get agreement on how you’ll be using them. In addition to your solution vision, also define the following together with the team:

  • Mission: What are your business intentions? The mission is about what your organization wants to ultimately achieve.
  • Values: What are your beliefs and ideals? What is the philosophy of your organization and solution? Values define the philosophy of the team and what it believes.
  • Business objectives: What are the specific goals your offerings will accomplish for the organization? Frame these in terms of outcomes, not outputs.

Step 2: Determine customer needs to pursue.

Next, decide on the customer needs to pursue. Here, the authors of Product Roadmaps Relaunched stress the importance of grounding the roadmap in actual customer need. JTBD is central to this step. They write:

“Identifying customer needs is the most important aspect of your roadmapping process. Roadmaps should be about expressing those customer needs. Therefore, most items on your roadmap will derive from a job the customer needs to accomplish or a problem the customer must solve.”

As outlined in Chapter 2, “Core Concepts of JTBD,” needs are hierarchical—from high-level aspirations to main jobs and sub-jobs to micro-jobs. Figure out the top-level jobs to explore and then drill down into the specific themes to target.

The “value themes,” as they are called, might come right from the job map. Locate the areas of highest underserved needs and use those stages as the categories of your roadmap themes. Or you can cluster needs to form themes that don’t necessarily follow the chronology of the job map. The important point is to ground the division of the roadmap in real-world observations of the customer’s job to be done and align the timeline to it.

Step 3: Set a timeline.

Next, create a sequence of value themes that your team will work toward. Timelines can be absolute, relative, or a mix of both. Absolute timelines with specific dates carry the risk of changing, which, in turn, can cause confusion or missed expectations.

Relative timelines give more flexibility but still provide insight into what’s coming and why. There are various terms to use, but the timeline is often broken into three phases for near-term, mid-term, and long-term. Examples include “now, later, future” or “going, next, later” or something similar. Find what works best for you.

Step 4: Align development effort to the roadmap.

Finally, conceptualize specific solutions to design and create. Use job stories to tie the overall project intent to customer needs, outlined in the next section. Then conceptualize solutions around getting the entire job done or the parts of it determined to be most strategically relevant to your business.

After a roadmap is created, you may then need detailed project plans to track progress. A simple Kanban board can serve that purpose in many cases. Or, for more complex software development efforts, tracking software may be needed. In Agile efforts, epic planning and then sprint planning come after you have an overall roadmap.

Tying the overall plan to customer needs gives the design and development teams the feeling that they are building something that matters to customers. Staying focused on customer needs helps avoid building things your customers don’t want. The nature of a job stays the same, even as features may shift. Grounding the roadmap in JTBD ensures that both its longevity and ability to absorb will change.

Learn More About This Play

Lombardo, C. Todd, Bruce McCarthy, Evan Ryan, and Michael Conners.[3] Product Roadmaps Relaunched. Sebastopol, CA:O’Reilly, 2018.

This book distills a wealth of practical information into a compact guide on roadmapping. The authors go to great lengths to provide numerous examples and stories from real-world cases. They use a realistic, modern approach for creating a roadmap that is driven, in part, by JTBD.

Align Teams to Job Stories

Agile development enables teams and organizations to work in a flexible way. The approach started in software development, but has spread to other domains, including government and the military. The principles of Agile development can apply to just about any field.

A key part of Agile is to break down efforts into individual units of work. User stories are short descriptions of features and functionality written from the perspective of the end user. Teams can focus on only a small part of the whole and make progress in a controlled way.

User stories are commonly written in a three-part format. The first element indicates a user’s role in the system. The second points to a capability that enables the person to get a task done. The last part often describes a benefit or reason for using the capability.

Although specific styles can vary, a typical user story resembles something like the following:

As a <role> I can <capability>, so that <benefit>

Examples of use stories in this format include:

  • As a system admin, I can specify files or folders to back up based on file size, date created, and date modified.
  • As a user, I can indicate folders not to back up so that my drive isn't filled up with things I don't need to be saved.
  • As a user, I want to update the name of a document so that I can categorize it.

For any given system, there may be hundreds of user stories. Some can be quite granular, such as describing a single button and why a user would click it. Stories are then organized into a backlog or repository of functionality to be built. Teams break off logical groups of user stories in sprints or two- to four-week cycles of work.

Job Stories

Although user stories are good for breaking down work, they typically fail to connect the solution being built with user needs. They lack an indication of why someone would behave in a certain way and what they need to get a job done. In fact, often user stories are derived from the capability being built, not from observing actual behavior.

Job stories are an alternative to user stories. They follow the tradition of breaking down efforts into smaller pieces, but through the JTBD lens. The technique was first pioneered by the product development team at Intercom, a leading marketing communications solution. They wanted to avoid leading designers with a preconceived solution, as well as tying development to the company vision and strategy.

Paul Adams, an Intercom product manager, wrote about job stories for the first time, saying: “We frame every design problem in a Job, focusing on the triggering event or situation, the motivation and goal, and the intended outcome.”[4]

As a result, their job story format also has three parts. But instead of focusing on a generic role, like a “user” or an “admin,” job stories begin with a highlight on the situation and context, not the individual:

When [situation], I want to [motivation], so I can [expected outcome].

Examples of job stories include:

  • When an important new customer signs up, I want to be notified so that I can start a conversation with that person.
  • When I visit someone’s profile page, I want to see how many posts they have in each topic so that I have an understanding of where they have the most knowledge.
  • When I have used the application multiple times, I get nudged to contribute so that I am encouraged to participate.

JTBD author and leader Alan Klement has done the most work refining the job story format.[5] He believes that adding more information about the circumstances shows causality better. Focusing on the context shifts attention from a persona to the situation. Klement advises that you avoid writing vague situations, but instead be as specific as possible.

For instance, consider these three possible situations for the first element of job stories:

  • When I’m hungry…
  • When I’m lost…
  • When I want to check my email…

Instead, Klement recommends describing the circumstances in rich detail:

  • When I’m hungry, running late to get somewhere, not sure when I’m going to eat again, and worried that I’ll soon be tired and irritable from hunger…
  • When I’m lost in a city that I’ve never been to, don’t know the local language, and am worried that I’ll be wasting my time in places I don’t want to be in…
  • When I want to check my email, but don’t want anyone around me to know I’m checking my email because they’ll think I’m being rude…

Each of these example situations provides more context for designing an appropriate solution.

Working with Job Stories

Job stories are modular, giving designers and developers the flexibility to solve problems in alternative ways. Job stories are grounded in real-world insight, and they are more powerful than user stories in guiding solutions. But creating job stories is more free-form than other JTBD techniques. Still, there are patterns that you can follow. Using the elements from Chapter 2, I suggest the following structure for job stories:

When I [circumstance + job stage/step], I want to [micro-job], so I can [need].


  • When I am one of the top posters while updating my social media feeds daily, I want it to show on my profile so that I can increase recognition as an expert on the subject.
  • When I run out of materials needed while completing an art project, I want to find alternative materials so that I can maximize the number of uses of my current supplies.
  • When preparing for my commute and running late, I want to know the current weather along my journey so that I can minimize the chance of arriving wet.

Consider the last example. The first element combines information about the circumstances (running late) of getting the main job done (commute to work) within a stage of the process (prepare for commute).

The second element points to an even smaller step or micro-job (check forecast). It should be formulated without reference to specific technology, but should be specific enough for designers and developers to create a specific capability.

Finally, the last element can be taken right from your list of needs. In this case, the job performer (commuter) wants to avoid showing up to the office wet (minimize the chance of arriving at work wet). You can leverage the elements your JTBD landscape already uncovered in research directly in the formulation of the job story statements.

In researching this book, I’ve come across various alternative approaches to formulating job stories. Andrea Hill, a prominent advocate of JTBD on social media, suggests a slightly different approach. She sees the middle element pointing directly to a feature or solution of some kind, thus explicitly crossing from the problem space into the solution space. Her basic format is as follows:

When I [circumstance], I want to [solution capability], so I can [need].

A job story for the previous example of commuting to work might then look like this:

When I’m preparing to commute to work, I want to have weather forecast notifications pushed to my phone, so I can minimize the chance of arriving wet.

Steph Troeph, research and JTBD instructor in the UK, approaches job stories in yet another way. She thinks of them with this formula:

When I [circumstance], I want to [job], so that [benefit a solution offers].

Regardless of your interpretation, the key is to find a consistent structure and stick with it. The form you end up with needs to be appropriate to your team and your situation.

Jobs Stories in Action

Ultimately, job stories tie a local design and development effort to a broader JTBD framework. Because the format of job stories includes contextual details, they are portable. In other words, a job story should make sense without having to know the larger JTBD landscape or job map. As a result, job stories have a more “plug-and-play” versatility that is often required for Agile designs and development teams.

For instance, Agile planners can manage a backlog of job stories much in the same way that they would manage user stories. If a given sprint gets slowed down or changes direction, stories not addressed can be carried over to the next sprint. Having a smaller, self-contained description of the smaller job to be done has advantages during the design and development phases.

But to be clear: I have found that job stories typically do not replace user stories for development completely. Instead, job stories guide and frame the conceptualization of a solution rather than track implementation. They serve best as a design tool to create or determine concept direction and design. Developers and engineers will likely still need user stories to measure the burndown rate and overall progress.

Your job map provides an overall orientation to your JTBD landscape and allows you to zero in on a specific area for design and development. A roadmap gives you a high-level sequence of development with the rationale for planning activities. Job stories are more specific and guide the local design and development of features and capabilities.

Follow these steps to create job stories based on your JTBD research:

Step 1: Understand job stages and circumstances.

Base the relevant jobs and circumstances on previous interviews and observations. For each area of development in your solution, consider the steps in the main job. Then drill down and list the smaller and smaller steps as micro-jobs, using the rules of formulating JTBD. Also identify the circumstances that apply to that part of the main job in particular.

Depending on the depth of your prior research and how well you and your team understand the job, you may not need to do more research to create and validate job stories. It’s never a bad idea to speak with people again and drill down on specific problems and objectives they have. During additional interviews, ask “how?” until you get more granular in understanding of subgoals and objectives.

Step 2: Formulate job stories.

As a team, write job stories that are specific to your design and development effort. Decide on a consistent format for the job stories and stick to it.

Strive to come up with unique, mutually exclusive stories that target specific jobs and circumstances. Avoid redundancy. For instance, in the previous example, you probably don’t need separate stories for commuting by train versus commuting by car. Develop the job stories that matter the most and focus on a limited set. You may end up with anywhere from three to eight job stories per project or sprint.

Step 3: Solve for the job stories.

Make job stories visible and transparent to the entire team to solve for the job stories. For instance, post a relevant list of job stories in a brainstorming session for everyone to see. Or list job stories at the beginning of a design critique so that the team has context for making comments. Use JTBD to guide design and development decisions.

It’s also possible to then use the job stories to review the appropriateness of your solutions. First, the design team can use the job stories relevant to a project as heuristics. They should constantly ask if their designs are meeting the user’s goals set out in the job stories.

Then you can test solutions with users against the job stories. Show users your solutions (e.g., as a mock-up or prototype) and ask them how well each addresses the job stories. This can be done in an interview-style fashion or with a survey. The job stories ultimately become a measure for success of the designs before anything is built.

Job stories let you take a step back and look at the context of the job while designing a product or service. In this respect, job stories fill an important gap between the observations of customers and solution development, connecting insights into customer needs to individual features and development efforts.

Related Approaches: Needs Statements

Design thinking is a broad framework for creative problem solving. It is rooted in human-centered methods that seek to develop deep empathy for people and then to devise solutions that meet their needs. In design thinking, it is important to define the problem to solve before generating options for solutions.

One technique to encapsulate insights from research is to generate need statements, greatly resembling job stories in form. But these statements differ from “needs,” as defined in Chapter 2, in that need statements in design thinking are not specifically limited to the outcomes of a getting a main job done, and they can be aspirational in nature.

Need statements in design thinking also tend to be much more focused on a persona or an individual rather than the circumstances. For instance, writing for the Norman Nielsen Group, Sarah Gibbons refers to need statements representing a point-of-view for the user of a system:[6] “A user need statement is an actionable problem statement used to summarize who a particular user is, the user’s need, and why the need is important to that user.”

Like job stories, need statements have three components: a user, a need, and a goal. The user corresponds to a goal-based persona based on research (as outlined in Chapter 4, “Defining Value”). A need is expressed independent of a feature or technology. The goal is the result of meeting the need. Gibbons provides an example:

Alieda, a multitasking, tech-savvy mother of two, needs to quickly and confidently compare options without leaving her comfort zone in order to spend more time doing the things that really matter.

Note that the insight at the end of this statement, “doing the things that really matter,” is very broad and hard to measure. Job stories, on the other hand, favor a more specific context and outcome. For instance, rewriting the above example through the lens of job stories might yield something like the following:

When I’m multitasking and in a rush, I need a familiar way to quickly and confidently compare options so that I can minimize the time spent on finding a solution.

Like need statements in design thinking, job stories also avoid the mention of features or technology. Yet, they are much more specific to a given job and its context. While both a need statement from design thinking and a job story can feed into the creative generation of solutions, job stories will provide more direct guidance without prescribing a solution.

But the definition of a need in design thinking can vary greatly. For instance, IBM’s Enterprise Design Thinking approach also includes guidelines for generating statements.[7] Not surprisingly, there are three parts: a user, a need, and a benefit. Here’s an example from the IBM site:

A developer needs a way to make sense of minimal design so that they can prototype faster.

This example is much more specific than Gibbon’s approach, yet still avoids mentioning a specific solution. There are no aspirational elements, such as “pursuing lifelong dreams,” sometimes found elsewhere in design thinking. IBM’s approach to need statements is closer to the job story approach, but is also light on describing the circumstances of use.

In some sense, the differences between job stories—even with the variations in format—and need statements points to a key distinction between JTBD and design thinking. The former focuses much more on the circumstances than the person’s state of mind or psychology. Where design thinking seeks to gain empathy for the individual as a starting point, JTBD seeks to understand the circumstances of accomplishing an objective before factoring in emotional and personal aspects.

Learn More About This Play

Klement, Alan. “Replacing the User Story with the Job Story.” JTBD.info (2013); “5 Tips for Writing a Job Story,” JTBD.info (2013); “Designing Features Using Job Stories,” Inside Intercom (2015).

Klement has done the most extensive work to develop the job story technique. These three articles outline the basis for creating them. The technique has evolved slightly, but Klement points clearly to how he’s updated his approach. Klement and others have posted widely about their use for development efforts, but start with these resources.

van de Keuken, Maxim. “Using Job Stories and Jobs-to-be-Done in Software Requirements Engineering.” Thesis, Utrecht University, 2017.

This thesis project offers a detailed investigation of how job stories are applied to date. After illustrating the history of job stories, Van de Keuken presents the results of his original research variations in application of job stories as seen in practice. This work contributes greatly to making job stories a more formal part of software requirements engineering.

Usability Testing for Voice Content

It’s an important time to be in voice design. Many of us are turning to voice assistants in these times, whether for comfort, recreation, or staying informed. As the interest in interfaces driven by voice continues to reach new heights around the world, so too will users’ expectations and the best practices that guide their design.

Voice interfaces (also known as voice user interfaces or VUIs) have been reinventing how we approach, evaluate, and interact with user interfaces. The impact of conscious efforts to reduce close contact between people will continue to increase users’ expectations for the availability of a voice component on all devices, whether that entails a microphone icon indicating voice-enabled search or a full-fledged voice assistant waiting patiently in the wings for an invocation.

But voice interfaces present inherent challenges and surprises. In this relatively new realm of design, the intrinsic twists and turns in spoken language can make things difficult for even the most carefully considered voice interfaces. After all, spoken language is littered with fillers (in the linguistic sense of utterances like hmm and um), hesitations and pauses, and other interruptions and speech disfluencies that present puzzling problems for designers and implementers alike.

Once you’ve built a voice interface that introduces information or permits transactions in a rich way for spoken language users, the easy part is done. Nonetheless, voice interfaces also surface unique challenges when it comes to usability testing and robust evaluation of your end result. But there are advantages, too, especially when it comes to accessibility and cross-channel content strategy. The fact that voice-driven content lies on the opposite extreme of the spectrum from the traditional website confers it an additional benefit: it’s an effective way to analyze and stress-test just how channel-agnostic your content truly is.

The quandary of voice usability

Several years ago, I led a talented team at Acquia Labs to design and build a voice interface for Digital Services Georgia called Ask GeorgiaGov, which allowed citizens of the state of Georgia to access content about key civic tasks, like registering to vote, renewing a driver’s license, and filing complaints against businesses. Based on copy drawn directly from the frequently asked questions section of the Georgia.gov website, it was the first Amazon Alexa interface integrated with the Drupal content management system ever built for public consumption. Built by my former colleague Chris Hamper, it also offered a host of impressive features, like allowing users to request the phone number of individual government agencies for each query on a topic.

Designing and building web experiences for the public sector is a uniquely challenging endeavor due to requirements surrounding accessibility and frequent budgetary challenges. Out of necessity, governments need to be exacting and methodical not only in how they engage their citizens and spend money on projects but also how they incorporate new technologies into the mix. For most government entities, voice is a completely different world, with many potential pitfalls.

At the outset of the project, the Digital Services Georgia team, led by Nikhil Deshpande, expressed their most important need: a single content model across all their content irrespective of delivery channel, as they only had resources to maintain a single rendition of each content item. Despite this editorial challenge, Georgia saw Alexa as an exciting opportunity to open new doors to accessible solutions for citizens with disabilities. And finally, because there were relatively few examples of voice usability testing at the time, we knew we would have to learn on the fly and experiment to find the right solution.

Eventually, we discovered that all the traditional approaches to usability testing that we’d executed for other projects were ill-suited to the unique problems of voice usability. And this was only the beginning of our problems.

How voice interfaces improve accessibility outcomes

Any discussion of voice usability must consider some of the most experienced voice interface users: people who use assistive devices. After all, accessibility has long been a bastion of web experiences, but it has only recently become a focus of those implementing voice interfaces. In a world where refreshable Braille displays and screen readers prize the rendering of web-based content into synthesized speech above all, the voice interface seems like an anomaly. But in fact, the exciting potential of Amazon Alexa for disabled citizens represented one of the primary motivations for Georgia’s interest in making their content available through a voice assistant.

Questions surrounding accessibility with voice have surfaced in recent years due to the perceived user experience benefits that voice interfaces can offer over more established assistive devices. Because screen readers make no exceptions when they recite the contents of a page, they can occasionally present superfluous information and force the user to wait longer than they’re willing. In addition, with an effective content schema, it can often be the case that voice interfaces facilitate pointed interactions with content at a more granular level than the page itself.

Though it can be difficult to convince even the most forward-looking clients of accessibility’s value, Georgia has been not only a trailblazer but also a committed proponent of content accessibility beyond the web. The state was among the first jurisdictions to offer a text-to-speech (TTS) phone hotline that read web pages aloud. After all, state governments must serve all citizens equally—no ifs, ands, or buts. And while these are still early days, I can see voice assistants becoming new conduits, and perhaps more efficient channels, by which disabled users can access the content they need.

Managing content destined for discrete channels

Whereas voice can improve accessibility of content, it’s seldom the case that web and voice are the only channels through which we must expose information. For this reason, one piece of advice I often give to content strategists and architects at organizations interested in pursuing voice-driven content is to never think of voice content in isolation. Siloing it is the same misguided approach that has led to mobile applications and other discrete experiences delivering orphaned or outdated content to a user expecting that all content on the website should be up-to-date and accessible through other channels as well.

After all, we’ve trained ourselves for many years to think of content in the web-only context rather than across channels. Our closely held assumptions about links, file downloads, images, and other web-based marginalia and miscellany are all aspects of web content that translate poorly to the conversational context—and particularly the voice context. Increasingly, we all need to concern ourselves with an omnichannel content strategy that straddles all those channels in existence today and others that will doubtlessly surface over the horizon.

With the advantages of structured content in Drupal 7, Georgia.gov already had a content model amenable to interlocution in the form of frequently asked questions (FAQs). While question-and-answer formats are convenient for voice assistants because queries for content tend to come in the form of questions, the returned responses likewise need to be as voice-optimized as possible.

For Georgia.gov, the need to preserve a single rendition of all content across all channels led us to perform a conversational content audit, in which we read aloud all of the FAQ pages, putting ourselves in the shoes of a voice user, and identified key differences between how a user would interpret the written form and how they would parse the spoken form of that same content. After some discussion with the editorial team at Georgia, we opted to limit calls to action (e.g., “Read more”), links lacking clear context in surrounding text, and other situations confusing to voice users who cannot visualize the content they are listening to.

Here’s a table containing examples of how we converted certain text on FAQ pages to counterparts more appropriate for voice. Reading each sentence aloud, one by one, helped us identify cases where users might scratch their heads and say “Huh?” in a voice context.

Before After
Learn how to change your name on your Social Security card. The Social Security Administration can help you change your name on your Social Security card.
You can receive payments through either a debit card or direct deposit. Learn more about payments. You can receive payments through either a debit card or direct deposit.
Read more about this. In Georgia, the Family Support Registry typically pulls payments directly from your paycheck. However, you can send your own payments online through your bank account, your credit card, or Western Union. You may also send your payments by mail to the address provided in your court order.

In areas like content strategy and content governance, content audits have long been key to understanding the full picture of your content, but it doesn’t end there. Successful content audits can run the gamut from automated checks for orphaned content or overly wordy articles to more qualitative analyses of how content adheres to a specific brand voice or certain design standards. For a content strategy truly prepared for channels both here and still to come, a holistic understanding of how users will interact with your content in a variety of situations is a baseline requirement today.

Other conversational interfaces have it easier

Spoken language is inherently hard. Even the most gifted orators can have trouble with it. It’s littered with mistakes, starts and stops, interruptions, hesitations, and a vertiginous range of other uniquely human transgressions. The written word, because it’s committed instantly to a mostly permanent record, is tame, staid, and carefully considered in comparison.

When we talk about conversational interfaces, we need to draw a clear distinction between the range of user experiences that traffic in written language rather than spoken language. As we know from the relative solidity of written language and literature versus the comparative transience of spoken language and oral traditions, in many ways the two couldn’t be more different from one another. The implications for designers are significant because spoken language, from the user’s perspective, lacks a graphical equivalent to which those scratching their head can readily refer. We’re dealing with the spoken word and aural affordances, not pixels, written help text, or visual affordances.

Why written conversational interfaces are easier to evaluate

One of the privileges that chatbots and textbots enjoy over voice interfaces is the fact that by design, they can’t hide the previous steps users have taken. Any conversational interface user working in the written medium has access to their previous history of interactions, which can stretch back days, weeks, or months: the so-called backscroll. A flight passenger communicating with an airline through Facebook Messenger, for example, knows that they can merely scroll up in the chat history to confirm that they’ve already provided the company with their e-ticket number or frequent flyer account information.

This has outsize implications for information architecture and conversational wayfinding. Since chatbot users can consult their own written record, it’s much harder for things to go completely awry when they make a move they didn’t intend. Recollection is much more difficult when you have to remember what you said a few minutes ago off the top of your head rather than scrolling up to the information you provided a few hours or weeks ago. An effective chatbot interface may, for example, enable a user to jump back to a much earlier, specific place in a conversation’s history.An effective chatbot interface may, for example, enable a user to jump back to a much earlier, specific place in a conversation’s history. Voice interfaces that live perpetually in the moment have no such luxury.

Eye tracking only works for visual components

In many cases, those who work with chatbots and messaging bots (especially those leveraging text messages or other messaging services like Facebook Messenger, Slack, or WhatsApp) have the unique privilege of benefiting from a visual component. Some conversational interfaces now insert other elements into the conversational flow between a machine and a person, such as embedded conversational forms (like SPACE10’s Conversational Form) that allow users to enter rich input or select from a range of possible responses.

The success of eye tracking in more traditional usability testing scenarios highlights its appropriateness for visual interfaces such as websites, mobile applications, and others. However, from the standpoint of evaluating voice interfaces that are entirely aural, eye tracking serves only the limited (but still interesting from a research perspective) purpose of assessing where the test subject is looking while speaking with an invisible interlocutor—not whether they are able to use the interface successfully. Indeed, eye tracking is only a viable option for voice interfaces that have some visual component, like the Amazon Echo Show.

Think-aloud and concurrent probing interrupt the conversational flow

A well-worn approach for usability testing is think-aloud, which allows for users working with interfaces to present their frequently qualitative impressions of interfaces verbally while interacting with the user experience in question. Paired with eye tracking, think-aloud adds considerable dimension to a usability test for visual interfaces such as websites and web applications, as well as other visually or physically oriented devices.

Another is concurrent probing (CP). Probing involves the use of questions to gather insights about the interface from users, and Usability.gov describes two types: concurrent, in which the researcher asks questions during interactions, and retrospective, in which questions only come once the interaction is complete.

Conversational interfaces that utilize written language rather than spoken language can still be well-suited to think-aloud and concurrent probing approaches, especially for the components in the interface that require manual input, like conversational forms and other traditional UI elements interspersed throughout the conversation itself.

But for voice interfaces, think-aloud and concurrent probing are highly questionable approaches and can catalyze a variety of unintended consequences, including accidental invocations of trigger words (such as Alexa mishearing “selected” as “Alexa”) and introduction of bad data (such as speech transcription registering both the voice interface and test subject). After all, in a hypothetical think-aloud or CP test of a voice interface, the user would be responsible for conversing with the chatbot while simultaneously offering up their impressions to the evaluator overseeing the test.

Voice usability tests with retrospective probing

Retrospective probing (RP), a lesser-known approach for usability testing, is seldom seen in web usability testing due to its chief weakness: the fact that we have awful memories and rarely remember what occurred mere moments earlier with anything that approaches total accuracy. (This might explain why the backscroll has joined the pantheon of rigid recordkeeping currently occupied by cuneiform, the printing press, and other means of concretizing information.)

For users of voice assistants lacking scrollable chat histories, retrospective probing introduces the potential for subjects to include false recollections in their assessments or to misinterpret the conclusion of their conversations. That said, retrospective probing permits the participant to take some time to form their impressions of an interface rather than dole out incremental tidbits in a stream of consciousness, as would more likely occur in concurrent probing.

What makes voice usability tests unique

Voice usability tests have several unique characteristics that distinguish them from web usability tests or other conversational usability tests, but some of the same principles unify both visual interfaces and their aural counterparts. As always, “test early, test often” is a mantra that applies here, as the earlier you can begin testing, the more robust your results will be. Having an individual to administer a test and another to transcribe results or watch for signs of trouble is also an effective best practice in settings beyond just voice usability.

Interference from poor soundproofing or external disruptions can derail a voice usability test even before it begins. Many large organizations will have soundproof rooms or recording studios available for voice usability researchers. For the vast majority of others, a mostly silent room will suffice, though absolute silence is optimal. In addition, many subjects, even those well-versed in web usability tests, may be unaccustomed to voice usability tests in which long periods of silence are the norm to establish a baseline for data.

How we used retrospective probing to test Ask GeorgiaGov

For Ask GeorgiaGov, we used the retrospective probing approach almost exclusively to gather a range of insights about how our users were interacting with voice-driven content. We endeavored to evaluate interactions with the interface early and diachronically. In the process, we asked each of our subjects to complete two distinct tasks that would require them to traverse the entirety of the interface by asking questions (conducting a search), drilling down into further questions, and requesting the phone number for a related agency. Though this would be a significant ask of any user working with a visual interface, the unidirectional focus of voice interface flows, by contrast, reduced the likelihood of lengthy accidental detours.

Here are a couple of example scenarios:

You have a business license in Georgia, but you’re not sure if you have to register on an annual basis. Talk with Alexa to find out the information you need. At the end, ask for a phone number for more information.

You’ve just moved to Georgia and you know you need to transfer your driver’s license, but you’re not sure what to do. Talk with Alexa to find out the information you need. At the end, ask for a phone number for more information.

We also peppered users with questions after the test concluded to learn about their impressions through retrospective probing:

  • “On a scale of 1–5, based on the scenario, was the information you received helpful? Why or why not?”
  • “On a scale of 1–5, based on the scenario, was the content presented clear and easy to follow? Why or why not?”
  • “What’s the answer to the question that you were tasked with asking?”

Because state governments also routinely deal with citizen questions having to do with potentially traumatic issues such as divorce and sexual harassment, we also offered the choice for participants to opt out of certain categories of tasks.

While this testing procedure yielded compelling results that indicated our voice interface was performing at the level it needed to despite its experimental nature, we also ran into considerable challenges during the usability testing process. Restoring Amazon Alexa to its initial state and troubleshooting issues on the fly proved difficult during the initial stages of the implementation, when bugs were still common.

In the end, we found that many of the same lessons that apply to more storied examples of usability testing were also relevant to Ask GeorgiaGov: the importance of testing early and testing often, the need for faithful yet efficient transcription, and the surprising staying power of bugs when integrating disparate technologies. Despite Ask GeorgiaGov’s many similarities to other interface implementations in terms of technical debt and the role of usability testing, we were overjoyed to hear from real Georgians whose engagement with their state government could not be more different from before.


Many of us may be building interfaces for voice content to experiment with newfangled channels, or to build for disabled people and people newer to the web. Now, they are necessities for many others, especially as social distancing practices continue to take hold worldwide. Nonetheless, it’s crucial to keep in mind that voice should be only one component of a channel-agnostic strategy equipped for content ripped away from its usual contexts. Building usable voice-driven content experiences can teach us a great deal about how we should envisage our milieu of content and its future in the first place.

Gone are the days when we could write a page in HTML and call it a day; content now needs to be rendered through synthesized speech, augmented reality overlays, digital signage, and other environments where users will never even touch a personal computer. By focusing on structured content first and foremost with an eye toward moving past our web-based biases in developing our content for voice and others, we can better ensure the effectiveness of our content on any device and in any form factor.

Eight months after we finished building Ask GeorgiaGov in 2017, we conducted a retrospective to inspect the logs amassed over the past year. The results were striking. Vehicle registration, driver’s licenses, and the state sales tax comprised the most commonly searched topics. 79.2% of all interactions were successful, an achievement for one of the first content-driven Alexa skills in production, and 71.2% of all interactions led to the issuance of a phone number that users could call for further information.

But deep in the logs we implemented for the Georgia team’s convenience, we found a number of perplexing 404 Not Found errors related to a search term that kept being recorded over and over again as “Lawson’s.” After some digging and consulting the native Georgians in the room, we discovered that one of our dear users with a particularly strong drawl was repeatedly pronouncing “license” in her native dialect to no avail.

As this anecdote highlights, just as no user experience can be truly perfect for everyone, voice content is an environment where imperfections can highlight considerations we missed in developing cross-channel content. And just as we have much to learn when it comes to the new shapes content can take as it jumps off the screen and out the window, it seems our voice interfaces still have a ways to go before they take over the world too.

Special thanks to Nikhil Deshpande for his feedback during the writing process.

Cross-Cultural Design

When I first traveled to Japan as an exchange student in 2001, I lived in northern Kyoto, a block from the Kitayama subway station.

My first time using the train to get to my university was almost a disaster, even though it was only two subway stops away. I thought I had everything I needed to successfully make the trip. I double- and triple-checked that I had the correct change in one pocket and a computer printout of where I was supposed to go in the other. I was able to make it down into the station, but then I just stood at a ticket machine, dumbfounded, looking at all the flashing lights, buttons, and maps above my head (Fig 5.1). Everything was so impenetrable. I was overwhelmed by the architecture, the sounds, the signs, and the language.

Photo of two subway ticket machines with complex maps above them
Fig 5.1: Kyoto subway ticket machines—with many line maps and bilingual station names—can seem complicated, especially to newcomers.

My eyes craved something familiar—and there it was. The ticket machine had a small button that said English! I pushed it but became even more lost: the instructions were poorly translated, and anyway, they explained a system that I couldn’t use in the first place.

Guess what saved me? Two little old Japanese ladies. As they bought tickets, I casually looked over their shoulders to see how they were using the machines. First, they looked up at the map to find their desired destination. Then, they noted the fare written next to the station. Finally, they put some money into the machine, pushed the button that lit up with their correct fare, and out popped the tickets! Wow! I tried it myself after they left. And after a few tense moments, I got my ticket and headed through the gates to the train platform.

I pride myself on being a third-culture kid, meaning I was raised in a culture other than the country named on my passport. But even with a cultural upbringing in both Nigeria and the US, it was one of the first times I ever had to guess my way through a task with no previous reference points. And I did it!

Unfortunately, the same guesswork happens online a million times a day. People visit sites that offer them no cultural mental models or visual framework to fall back on, and they end up stumbling through links and pages. Effective visual systems can help eliminate that guesswork and uncertainty by creating layered sets of cues in the design and interface. Let’s look at a few core parts of these design systems and tease out how we can make them more culturally responsive and multifaceted.


If you work on the web, you deal with typography all the time. This isn’t a book about typography—others have written far more eloquently and technically on the subject. What I would like to do, however, is examine some of the ways culture and identity influence our perception of type and what typographic choices designers can make to help create rich cross-cultural experiences.


I came across the word stereotypography a few years ago. Being African, I’m well aware of the way my continent is portrayed in Western media—a dirt-poor, rural monoculture with little in the way of technology, education, or urbanization. In the West, one of the most recognizable graphic markers for things African, tribal, or uncivilized (and no, they are not the same thing) is the typeface Neuland. Rob Giampietro calls it “the New Black Face,” a clever play on words. In an essay, he asks an important question:

How did [Neuland and Lithos] come to signify Africans and African-Americans, regardless of how a designer uses them, and regardless of the purpose for which their creators originally intended them? (http://bkaprt.com/ccd/05-01/)

From its release in 1923 and continued use through the 1940s in African-American-focused advertising, Neuland has carried heavy connotations and stereotypes of cheapness, ugliness, tribalism, and roughness. You see this even today. Neuland is used in posters for movies like Tarzan, Jurassic Park, and Jumanji—movies that are about jungles, wildness, and scary beasts lurking in the bush, all Western symbolism for the continent of Africa. Even MyFonts’ download page for Neuland (Fig 5.2) includes tags for “Africa,” “jungle fever,” and “primitive”—tags unconnected to anything else in the product besides that racist history.

Fig 5.2: On MyFonts, the Neuland typeface is tagged with “Africa”, “jungle fever”, and “primitive”, perpetuating an old and irrelevant typographic stereotype (http://bkaprt.com/ccd/05-02/).

Don’t make, use, or sell fonts this way. Here are some tips on how to avoid stereotypography when defining your digital experiences:

  • Be immediately suspicious of any typeface that “looks like” a culture or country. For example, so-called “wonton” or “chop-suey” fonts, whose visual style is thought to express “Asianness” or to suggest Chinese calligraphy, have long appeared on food cartons, signs, campaign websites, and even Abercrombie & Fitch T-shirts with racist caricatures of Asians (http://bkaprt.com/ccd/05-03/). Monotype’s website, where you can buy a version called Mandarin Regular (US$35), cringingly describes the typeface’s story as “an interpretation of artistically drawn Asian brush calligraphy” (Fig 5.3). Whether or not you immediately know its history, run away from any typeface that purports to represent an entire culture.
A font called "Mandarin" with a stereotypical Asian aesthetic
Fig 5.3: Fonts.com sells a typeface called Mandarin Regular with the following description: “The stylized Asian atmosphere is not created only by the forms of the figures but also by the very name of the typeface. A mandarin was a high official of the ancient Chinese empire” (http://bkaprt.com/ccd/05-04/).
  • Support type designers who are from the culture you are designing for. This might seem like it’s a difficult task, but the internet is a big place. I have found that, for clients who are sensitive to cultural issues, the inclusion of type designers’ names and backgrounds can be a powerful differentiator, even making its way into their branding packages as a point of pride.

The world wide webfont

Another common design tool you should consider is webfonts—fonts specifically designed for use on websites and apps. One of the main selling points of webfonts is that instead of putting text in images, clients can use live text on their sites, which is better for SEO and accessibility. They are simple to implement these days, a matter of adding a line of code or checking a box on a templating engine. The easiest way to get them on your site is by using a service like Google Fonts, Fontstand, or Adobe Fonts.

Or is it? That assumes those services are actually available to your users.

Google Fonts (and every other service using Google’s Developer API) is blocked in mainland China, which means that any of those nice free fonts you chose would simply not load (http://bkaprt.com/ccd/05-05/). You can work around this, but it also helps to have a fallback font—that’s what they’re for.

When you’re building your design system, why not take a few extra steps to define some webfonts that are visible in places with content blocks? Justfont is one of the first services focused on offering a wide range of Chinese webfonts (http://bkaprt.com/ccd/05-06/). They have both free and paid tiers of service, similar to Western font services. After setting up an account, you can grab whatever CSS and font-family information you need.

Multiple script systems

When your design work requires more than one script—for instance, a Korean typeface and a Latin typeface—your choices get much more difficult. Designs that incorporate more than one are called multiple script systems (multiscript systems for short). Combining them is an interesting design challenge, one that requires extra typographic sensitivity. Luckily, your multiscript choices will rarely appear on the same page together; you will usually be choosing fonts that work across the brand, not that work well next to one another visually.

Let’s take a look at an example of effective multiscript use. SurveyMonkey, an online survey and questionnaire tool, has their site localized into a variety of different languages (Fig 5.4). Take note of the headers, the structure of the text in the menu and buttons, and how both fonts feel like part of the same brand.

A SurveyMonkey page in Korean with a simple aesthetic A SurveyMonkey page in English with a simple and similar aesthetic
Fig 5.4: Compare the typographic choices in the Korean (http://bkaprt.com/ccd/05-07/) and US English (http://bkaprt.com/ccd/05-08/) versions of SurveyMonkey’s Take a Tour page. Do the header type and spacing retain the spirit of the brand while still accounting for typographic needs?

Some tips as you attempt to choose multiscript fonts for your project:

  • Inspect the overall weight and contrast level of the scripts. Take the time to examine how weight and contrast are used in the scripts you’re using. Find weights and sizes that give you a similar feel and give the page the right balance, regardless of the script.
  • Keep an eye on awkward script features. Character x-heights, descenders, ascenders, and spacing can throw off the overall brand effect. For instance, Japanese characters are always positioned within a grid with all characters designed to fit in squares of equal height and width. Standard Japanese typefaces also contain Latin characters, called romaji. Those Latin characters will, by default, be kerned according to that same grid pattern, often leaving their spacing awkward and ill-formed. Take the extra time to find a typeface that doesn’t have features that are awkward to work with.
  • Don’t automatically choose scripts based on superficial similarity. Initial impressions don’t always mean a typeface is the right one for your project. In an interview in the book Bi-Scriptual, Jeongmin Kwon, a typeface designer based in France, offers an example (http://bkaprt.com/ccd/05-09/). Nanum Myeongjo, a contemporary Hangul typeface, might at first glance look really similar to a seventeenth-century Latin old-style typeface—for instance, they both have angled serifs. However, Nanum Myeongjo was designed in 2008 with refined, modern strokes, whereas old-style typefaces were originally created centuries ago and echo handwritten letterforms (http://bkaprt.com/ccd/05-10/). Looking at the Google Fonts page for Nanum Myeongjo, though, none of that is clear (Fig 5.5). The page automatically generates a Latin Nn glyph in the top left of the page, instead of a more representative Hangul character sample. If I based my multiscript font choices on my initial reactions to that page, my pairings wouldn’t accurately capture the history and design of each typeface.
A font with a large sample character in Latin text rather than a more representative Hangul character
Fig 5.5: The Google Fonts page for Nanum Myeongjo shows a Latin character sample in the top left, rather than a more representative character sample.

Visual density

CSS can help you control visual density—how much text, image, and other content there is relative to the negative space on your page. As you read on, keep cultural variables in mind: different cultures value different levels of visual density.

Let’s compare what are commonly called CJK (Chinese, Japanese, Korean) alphabets and Latin (English, French, Italian, etc.) alphabets. CJK alphabets have more complex characters, with shapes that are generally squarer than Latin letterforms. The glyphs also tend to be more detailed than Latin ones, resulting in a higher visual density.

Your instinct might be to create custom type sizes and line heights for each of your localized pages. That is a perfectly acceptable option, and if you are a typophile, it may drive you crazy not to do it. But I’m here to tell you that­ when adding CJK languages to a design system, you can update it to account for their visual density without ripping out a lot of your original CSS:

  1. Choose a font size that is slightly larger for CJK characters, because of their density.
  2. Choose a line height that gives you ample vertical space between each line of text (referred to as line-height in CSS).
  3. Look at your Latin text in the same sizes and see if it still works.
  4. Tweak them together to find a size that works well with both scripts.

The 2017 site for Typojanchi, the Korean Typography Biennale, follows this methodology (Fig 5.6). Both the English and Korean texts have a font-size of 1.25em, and a line-height of 1.5. The result? The English text takes up more space vertically, and the block of Korean text is visually denser, but both are readable and sit comfortably within the overall page design. It is useful to compare translated websites like this to see how CSS styling can be standardized across Latin and CJK pages.

A basic layout with English textA basic layout with Korean text
Fig 5.6: The 2017 site for Typojanchi, the Korean Typography Biennale, shows differing visual density in action. It is useful to compare translated websites like this to see how CSS styling can be standardized across Latin and CJK pages (http://bkaprt.com/ccd/05-11/).

Text expansion factors

Expansion factors calculate how long strings of text will be in different languages. They use either a decimal (1.8) or a percentage (180%) to calculate the length of a text string in English versus a different language. Of course, letter-spacing depends on the actual word or phrase, but think of them as a very rough way to anticipate space for text when it gets translated.

Using expansion factors is best when planning for microcopy, calls to action, and menus, rather than long-form content like articles or blog posts that can freely expand down the page. The Salesforce Lightning Design System offers a detailed expansion-factor table to help designers roughly calculate space requirements for other languages in a UI (Fig 5.7).

A chart showing how a different piece of content lays out in different languages
Fig 5.7: This expansion-factor table from Salesforce lets designers and developers estimate the amount of text that will exist in different languages. Though dependent on the actual words, such calculations can give you a benchmark to design with content in mind (http://bkaprt.com/ccd/05-12/).

But wait! Like everything in cross-cultural design, nothing is ever that simple. Japanese, for example, has three scripts: Kanji, for characters of Chinese origin, hiragana, for words and sounds that are not represented in kanji, and katakana, for words borrowed from other languages.

The follow button is a core part of the Twitter experience. It has six characters in English (“Follow”) and four in Japanese (フォロー), but the Japanese version is twenty percent longer because it is in katakana, and those characters take up more space than kanji (Fig 5.8). Expansion tables can struggle to accommodate the complex diversity of human scripts and languages, so don’t look to them as a one-stop or infallible solution.

The Twitter UI in JapaneseThe Twitter UI in English
Fig 5.8: On Twitter, expansion is clearly visible: the English “Follow” button text comes in at about 47 pixels wide, while the Japanese text comes in at 60 pixels wide.

Here are a few things you can do keep expansion factors in mind as you design:

  • Generate dummy text in different languages for your design comps. Of course, you should make sure your text doesn’t contain any unintentional swearwords or improper language, but tools like Foreign Ipsum are a good place to start getting your head around expansion factors (http://bkaprt.com/ccd/05-13/).
  • Leave extra space around buttons, menu items, and other microcopy. As well as being general good practice in responsive design, this allows you to account for how text in your target languages expands.
  • Make sure your components are expandable. Stay away from assigning a fixed width to your UI elements unless it’s unavoidable.
  • Let longer text strings wrap to a second line. Just ensure that text is aligned correctly and is easy to scan.

Standards for Writing Accessibly

Writing to meet WCAG2 standards can be a challenge, but it’s worthwhile. Albert Einstein, the archetypical genius and physicist, once said, “Any fool can make things bigger, more complex, and more violent. It takes a touch of genius—and a lot of courage—to move in the opposite direction.”

Hopefully, this entire book will help you better write for accessibility. So far, you’ve learned:

  • Why clarity is important
  • How to structure messages for error states and stress cases
  • How to test the effectiveness of the words you write

All that should help your writing be better for screen readers, give additional context to users who may need it, and be easier to parse.

But there are a few specific points that you may not otherwise think about, even after reading these pages.

Writing for Screen Readers

People with little or no sight interact with apps and websites in a much different way than sighted people do. Screen readers parse the elements on the screen (to the best of their abilities) and read it back to the user. And along the way, there are many ways this could go wrong. As the interface writer, your role is perhaps most important in giving screen reader users the best context.

Here are a few things to keep in mind about screen readers:

  • The average reading time for sighted readers is two to five words per second. Screen-reader users can comprehend text being read at an average of 35 syllables per second, which is significantly faster. Don’t be afraid to sacrifice brevity for clarity, especially when extra context is needed or useful.
  • People want to be able to skim long blocks of text, regardless of sight or audio, so it’s extremely important to structure your longform writing with headers, short paragraphs, and other content design best practices.

Write Chronologically, Not Spatially

Writing chronologically is about describing the order of things, rather than where they appear spatially in the interface. There are so many good reasons to do this (devices and browsers will render interfaces differently), but screen readers show you the most valuable reason. You’ll often be faced with writing tooltips or onboarding elements that say something like, “Click the OK button below to continue.” Or “See the instructions above to save your document.”

Screen readers will do their job and read those instructions aloud to someone who can’t see the spatial relationships between words and objects. While many times, they can cope with that, they shouldn’t have to. Consider screen reader users in your language. Embrace the universal experience shared by humans and rely on their intrinsic understanding of the top is first, bottom is last paradigm. Write chronologically, as in Figure 5.5.

FIGURE 5.5 Password hint microcopy below the password field won’t help someone using a screen reader who hasn’t made it there yet.

Rather than saying:

  • Click the OK button below to continue.
  • (A button that scrolls you to the top of a page): Go to top.

Instead, say:

  • Next, select OK to continue.
  • Go to beginning.

Write Left to Right, Top to Bottom

While you don’t want to convey spatial meaning in your writing, you still want to keep that spatial order in mind.

Have you ever purchased a service or a product, only to find out later that there were conditions you didn’t know about before you paid for it? Maybe you didn’t realize batteries weren’t included in that gadget, or that signing up for that social network, you were implicitly agreeing to provide data to third-party advertisers.

People who use screen readers face this all the time.

Most screen readers will parse information from left to write, from top to bottom.1 Think about a few things when reviewing the order and placement of your words. Is there information critical to performing an action, or making a decision, that appears after (to the right or below) an action item, like in Figure 5.5? If so, consider moving it up in the interface.

Instead, if there’s information critical to an action (rules around setting a password, for example, or accepting terms of service before proceeding), place it before the text field or action button. Even if it’s hidden in a tooltip or info button, it should be presented before a user arrives at a decision point.

Don’t Use Colors and Icons Alone

If you are a sighted American user of digital products, there’s a pretty good chance that if you see a message in red, you’ll interpret it as a warning message or think something’s wrong. And if you see a message in green, you’ll likely associate that with success. But while colors aid in conveying meaning to this type of user, they don’t necessarily mean the same thing to those from other cultures.

For example, although red might indicate excitement, or danger in the U.S. (broadly speaking), in other cultures it means something entirely different:

  • In China, it represents good luck.
  • In some former-Soviet, eastern European countries it’s the color strongly associated with Communism.
  • In India, it represents purity.

Yellow, which we in the U.S. often use to mean “caution” (because we’re borrowing a mental model from traffic lights), might convey another meaning for people in other cultures:

  • In Latin America, yellow is associated with death.
  • In Eastern and Asian cultures, it’s a royal color—sacred and often imperial.

And what about users with color-blindness or low to no vision? And what about screen readers? Intrinsic meaning from the interface color means nothing for them. Be sure to add words that bear context so that if you heard the message being read aloud, you would understand what was being said, as in Figure 5.6.

FIGURE 5.6 While a simple in-app message warning a user to save their work before proceeding is more effective, visually, if it is red and has a warning icon, as seen on the left, you should provide more context when possible. The example on the right explicitly says that a user won’t be able to proceed to the next step before saving their work.

Describe the Action, Not the Behavior

Touch-first interfaces have been steadily growing and replacing keyboard/mouse interfaces for years, so no longer are users “clicking” a link or a button. But they’re not necessarily “tapping” it either, especially if they’re using a voice interface or an adaptive device.

Instead of microcopy that includes behavioral actions like:

  • Click
  • Tap
  • Press
  • See

Try device-agnostic words that describe the action, irrespective of the interface, like:

  • Choose
  • Select
  • View

There are plenty of exceptions to this rule. If your interface requires a certain action to execute a particular function, and you need to teach the user how their gesture affects the interface (“Pinch to zoom out,” for example), then of course you need to describe the behavior. But generally, the copy you’re writing will be simpler and more consistent if you stick with the action in the context of the interface itself.

Making Room for Variation

Making a brand feel unified, cohesive, and harmonious while also leaving room for experimentation is a tough balancing act. It’s one of the most challenging aspects of a design system.

Graphic designer and Pentagram partner Paula Scher faced this challenge with the visual identity for the Public Theater in New York. As she explained in a talk at Beyond Tellerrand:

I began to realize that if you made everything the same, it was boring after the first year. If you changed it individually for each play, the theater lost recognizability. The thing to do, which I totally got for the first time after working there at this point for 17 years, is what they needed to have were seasons.

You could take the typography and the color system for the summer festival, the Shakespeare in the Park Festival, and you could begin to translate it into posters by flopping the colors, but using some of the same motifs, and you could create entire seasons out of the graphics. That would become its own standards manual where I have about six different people making these all year (http://bkaprt.com/eds/04-01/).

Scher’s strategy was to retain the Public Theater’s visual language every year, but to vary some of its elements (Fig 4.1–2). Colors would be swapped. Text would skew in different directions. New visual motifs would be introduced. The result is that each season coheres in its own way, but so does the identity of the Public Theater as a whole.

Sixteen Public Theater posters in black, white, and yellow, with slanted wood type letterforms and high-contrast images of people.
Fig 4.1: The posters for the 2014/15 season featured the wood type style the Public Theater is known for, but the typography was skewed. The color palette was restrained to yellow, black, and white, which led to a dynamic look when coupled with the skewed type (http://bkaprt.com/eds/04-02/).
Twelve Public Theater posters using black, white, and pastel colors with wood type letterforms and softer images of people.
Fig 4.2: For the 2018 season, the wood type letterforms were extended on a field of gradated color. The grayscale cut-out photos we saw in the 2014/15 season persisted, but this time in lower contrast to fit better with the softer color tones (http://bkaprt.com/eds/04-03/).

Even the most robust or thoroughly planned systems will need to account for variation at some point. As soon as you release a design system, people will ask you how to deviate from it, and you’ll want to be armed with persuasive answers. In this chapter, I’m going to talk about what variation means for a design system, how to know when you need it, and how to manage it in a scalable way.

What Is Variation?

We’ve spent most of this book talking about the importance of unity, cohesion, and harmony in a design system. So why are we talking about variation? Isn’t that at odds with all of the goals we’ve set until now?

Variation is a deviation from established patterns, and it can exist at every level of the system. At the component level, for instance, a team may discover that they need a component to behave in a slightly different way; maybe this particular component needs to appear without a photo, for example. At a design-language level, you may have a team that has a different audience, so they want to adjust their brand identity to serve that audience better. You can even have variation at the level of design principles: if a team is working on a product that is functionally different from your core product, they may need to adjust their principles to suit that context.

There are three kinds of deviations that come up in a design system:

  • Unintentional divergence typically happens when designers can’t find the information they’re looking for. They may not know that a certain solution exists within a system, so they create their own style. Clear, easy-to-find documentation and usage guidelines can help your team avoid unintentional variation.
  • Intentional but unnecessary divergence usually results from designers not wanting to feel constrained by the system, or believing they have a better solution. Making sure your team knows how to push back on and contribute to the system can help mitigate this kind of variation.
  • Intentional, meaningful divergence is the goal of an expressive design system. In this case, the divergence is meaningful because it solves a very specific user problem that no existing pattern solves.

We want to enable intentional, meaningful variation. To do this, we need to understand the needs and contexts for variation.

Contexts for Variation

Every variation we add makes our design system more complicated. Therefore, we need to take care to find the right moments for variation. Three big contextual changes are served by variation: brand, audience, and environment.


If you’re creating a system for multiple brands, each with its own brand language, then your system needs to support variations to reflect those brands.

The key here is to find the common core elements and then set some criteria for how you should deviate. When we were creating the design system for our websites at Vox Media, we constantly debated which elements should feel more expressive. Should a footer be standardized, or should we allow for tons of customization? We went back to our core goals: our users were ultimately visiting our websites to consume editorial content. So the variations should be in service of the content, writing style, and tone of voice for each brand.

The newsletter modules across Vox Media brands were an example of unnecessary variation. They were consistent in functionality and layout, but had variations in type, color, and visual treatments like borders (Fig 4.3). There was quite a bit of custom design within a very small area: Curbed’s newsletter component had a skewed background, for example, while Eater’s had a background image. Because these modules were so consistent in their user goals, we decided to unify their design and create less variation (Fig 4.4).

Fig 4.3: Older versions of Vox Media’s newsletter modules contained lots of unnecessary visual variation.
Three examples of newsletter modules, showing the same colors, fonts, and spacing.
Fig 4.4: The new, unified newsletter modules.

The unified design cleaned up some technical debt. In the previous design, each newsletter module had CSS overrides to achieve distinct styling. Some modules even had overrides on the primary button color so it would work better with the background color. Little CSS overrides like this add up over time. Whenever we released a new change, we’d have to manually update the spots containing CSS overrides.

The streamlined design also placed a more appropriate emphasis on the newsletter module. While important, this module isn’t the star of the page. It doesn’t need loud backgrounds or fancy shapes to command attention, especially since it’s placed around article content. Variation in this module wasn’t necessary for expressing the brands.

On the other hand, consider the variation in Vox Media’s global header components. When we were redesigning the Verge, its editorial teams were vocal about wanting more latitude to art-direct the page, guide attention toward big features, and showcase custom illustrations. We addressed this by creating a masthead component (Fig 4.5) that sits on top of the global header on homepages. It contains a logo, tagline, date, and customizable background image. Though at the time this was a one-off component, we felt that the variation was valuable because it would strengthen the Verge’s brand voice.

Example of the Verge’s masthead component with magenta and blue abstractions. Example of the Verge’s masthead component with a city skyline in orange tones. Example of the Verge’s masthead component in pixelated black and white.
Fig 4.5: Examples of the Verge's masthead component

The Verge team commissions or makes original art that changes throughout the day. The most exciting part is that they can use the masthead and a one-up hero when they drop a big feature and use these flexible components to art-direct the page (Fig 4.6). Soon after launch, the Verge masthead even got a Twitter fan account (@VergeTaglines) that tweets every time the image changes.

Comparison of the Verge’s homepage, changing based on the masthead design and hero photography. Comparison of the Verge’s homepage, changing based on the masthead design and hero photography.
Fig 4.6: The Verge uses two generic components, the masthead and one-up hero, to art-direct its homepages.

Though this component was built specifically for the Verge, it soon gained broader application with other brands that share Vox’s publishing platform, Chorus. The McElroy Family website, for example, needed to convey its sense of humor and Appalachian roots; the masthead component shines with an original illustration featuring an adorable squirrel (Fig 4.7).

The masthead component for the McElroy Family, showing a blue navigation bar and a pastel illustration of a forest.
Fig 4.7: The McElroy Family site uses the same masthead component as the Verge to display a custom illustration.
The masthead component for the Chicago Sun-Times, showing a white background, stark black text, and a red Subscribe button.
Fig 4.8: The same masthead component on the Chicago Sun-Times site.

The Chicago Sun-Times—another Chorus platform site—is very different in content, tone, and audience from The McElroy Family, but the masthead component is just as valuable in conveying the tone of the organization’s high-quality investigative journalism and breaking news coverage (Fig 4.8).

Why did the masthead variation work well while the newsletter variation didn’t? The variations on the newsletter design were purely visual. When we created them, we didn’t have a strategy for how variation should work; instead, we were looking for any opportunity to make the brands feel distinct. The masthead variation, by contrast, tied directly into the brand strategy. Even though it began as a one-off for the Verge, it was flexible and purposeful enough to migrate to other brands.


The next contextual variation comes from audience. If your products serve different audiences who all need different things, then your system may need to adapt to fit those needs.

A good example of this is Airbnb’s listing pages. In addition to their standard listings, they also have Airbnb Plus—one-of-a-kind, high quality rentals at higher price points. Audiences booking a Plus listing are probably looking for exceptional quality and attention to detail.

Both Airbnb’s standard listing page and Plus listing page are immediately recognizable as belonging to the same family because they use many consistent elements (Fig 4.9). They both use Airbnb’s custom font, Cereal. They both highlight photography. They both use many of the same components, like the date picker. The iconography is the same.

Screenshot of AirBnB's standard listing Screenshot of AirBnB's Plus listing
Fig 4.9: The same brand elements in Airbnb’s standard listings (above) are used in their Plus listings (below), but with variations that make the listing styles distinct.

However, some of the design choices convey a different attitude. Airbnb Plus uses larger typography, airier vertical space, and a lighter weight of Cereal. It has a more understated color palette, with a deeper color on the call to action. These choices make Airbnb Plus feel like a more premium experience. You can see they’ve adjusted the density, weight, and scale levers to achieve a more elegant and sophisticated aesthetic.

The standard listing page, on the other hand, is more functional, with the booking module front and center. The Plus design pulls the density and weight levers in a lighter, airier direction. The standard listing page has less size contrast between elements, making it feel more functional.

Because they use the same core building blocks—the same typography, iconography, and components—both experiences feel like Airbnb. However, the variations in spacing, typographic weights, and color help distinguish the standard listing from the premium listing.


I’ve mainly been talking about adding variation to a system to allow for a range of content tones, but you may also need your system to scale based on environmental contexts. “Environment” in this context asks: Where will your products be used? Will that have an impact on the experience? Environments are the various constraints and pressures that surround and inform an experience. That can include lighting, ambient noise, passive or active engagement, expected focus level, or devices.

Shopify’s Polaris design system initially grew out of Shopify’s Store Management product. When the Shopify Retail team kicked off a project to design the next generation point-of-sale (POS) system, they realized that the patterns in Polaris didn’t exactly fit their needs. The POS system needed to work well in a retail space, often under bright lighting. The app needed to be used at arm’s length, twenty-four to thirty-six inches away from the merchant. And unlike the core admin, where the primary interaction is between the merchant and the UI, merchants using the POS system needed to prioritize their interactions with their customers instead of the UI. The Retail team wanted merchants to achieve an “eyes-closed” level of mastery over the UI so they could maintain eye contact with their customers.

The Retail team decided that the existing color palette, which only worked on a light background, would not be clear enough under the bright lights of a retail shop. The type scale was also too small to be used at arm’s length. And in order for merchants to use the POS system without breaking eye contact with customers, the buttons and other UI elements would need to be much larger.

The Retail team recognized that the current design system didn’t support a variety of environmental scenarios. But after talking with the Polaris team, they realized that other teams would benefit from the solutions they created. The Warehouse team, for example, was also developing an app that needed to be used at arm’s length under bright lights. This work inspired the Polaris team to create a dark mode for the system (Fig 4.10).

Comparison of light and dark modes for navigation menus in the Polaris design system.
Fig 4.10: Polaris light mode (left) and dark mode (right).

This feedback loop between product team and design system team is a great example of how to build the right variation into your system. Build your system around helping your users navigate your product more clearly and serving content needs and you’ll unlock scalable expression.

Request with Intent: Caching Strategies in the Age of PWAs

Once upon a time, we relied on browsers to handle caching for us; as developers in those days, we had very little control. But then came Progressive Web Apps (PWAs), Service Workers, and the Cache API—and suddenly we have expansive power over what gets put in the cache and how it gets put there. We can now cache everything we want to… and therein lies a potential problem.

Media files—especially images—make up the bulk of average page weight these days, and it’s getting worse. In order to improve performance, it’s tempting to cache as much of this content as possible, but should we? In most cases, no. Even with all this newfangled technology at our fingertips, great performance still hinges on a simple rule: request only what you need and make each request as small as possible.

To provide the best possible experience for our users without abusing their network connection or their hard drive, it’s time to put a spin on some classic best practices, experiment with media caching strategies, and play around with a few Cache API tricks that Service Workers have hidden up their sleeves.

Best intentions

All those lessons we learned optimizing web pages for dial-up became super-useful again when mobile took off, and they continue to be applicable in the work we do for a global audience today. Unreliable or high latency network connections are still the norm in many parts of the world, reminding us that it’s never safe to assume a technical baseline lifts evenly or in sync with its corresponding cutting edge. And that’s the thing about performance best practices: history has borne out that approaches that are good for performance now will continue being good for performance in the future.

Before the advent of Service Workers, we could provide some instructions to browsers with respect to how long they should cache a particular resource, but that was about it. Documents and assets downloaded to a user’s machine would be dropped into a directory on their hard drive. When the browser assembled a request for a particular document or asset, it would peek in the cache first to see if it already had what it needed to possibly avoid hitting the network.

We have considerably more control over network requests and the cache these days, but that doesn’t excuse us from being thoughtful about the resources on our web pages.

Request only what you need

As I mentioned, the web today is lousy with media. Images and videos have become a dominant means of communication. They may convert well when it comes to sales and marketing, but they are hardly performant when it comes to download and rendering speed. With this in mind, each and every image (and video, etc.) should have to fight for its place on the page. 

A few years back, a recipe of mine was included in a newspaper story on cooking with spirits (alcohol, not ghosts). I don’t subscribe to the print version of that paper, so when the article came out I went to the site to take a look at how it turned out. During a recent redesign, the site had decided to load all articles into a nearly full-screen modal viewbox layered on top of their homepage. This meant requesting the article required requests for all of the assets associated with the article page plus all the contents and assets for the homepage. Oh, and the homepage had video ads—plural. And, yes, they auto-played.

I popped open DevTools and discovered the page had blown past 15 MB in page weight. Tim Kadlec had recently launched What Does My Site Cost?, so I decided to check out the damage. Turns out that the actual cost to view that page for the average US-based user was more than the cost of the print version of that day’s newspaper. That’s just messed up.

Sure, I could blame the folks who built the site for doing their readers such a disservice, but the reality is that none of us go to work with the goal of worsening our users’ experiences. This could happen to any of us. We could spend days scrutinizing the performance of a page only to have some committee decide to set that carefully crafted page atop a Times Square of auto-playing video ads. Imagine how much worse things would be if we were stacking two abysmally-performing pages on top of each other!

Media can be great for drawing attention when competition is high (e.g., on the homepage of a newspaper), but when you want readers to focus on a single task (e.g., reading the actual article), its value can drop from important to “nice to have.” Yes, studies have shown that images excel at drawing eyeballs, but once a visitor is on the article page, no one cares; we’re just making it take longer to download and more expensive to access. The situation only gets worse as we shove more media into the page. 

We must do everything in our power to reduce the weight of our pages, so avoid requests for things that don’t add value. For starters, if you’re writing an article about a data breach, resist the urge to include that ridiculous stock photo of some random dude in a hoodie typing on a computer in a very dark room.

Request the smallest file you can

Now that we’ve taken stock of what we do need to include, we must ask ourselves a critical question: How can we deliver it in the fastest way possible? This can be as simple as choosing the most appropriate image format for the content presented (and optimizing the heck out of it) or as complex as recreating assets entirely (for example, if switching from raster to vector imagery would be more efficient).

Offer alternate formats

When it comes to image formats, we don’t have to choose between performance and reach anymore. We can provide multiple options and let the browser decide which one to use, based on what it can handle.

You can accomplish this by offering multiple sources within a picture or video element. Start by creating multiple formats of the media asset. For example, with WebP and JPG, it’s likely that the WebP will have a smaller file size than the JPG (but check to make sure). With those alternate sources, you can drop them into a picture like this:

  <source srcset="my.webp" type="image/webp">
  <img src="my.jpg" alt="Descriptive text about the picture.">

Browsers that recognize the picture element will check the source element before making a decision about which image to request. If the browser supports the MIME type “image/webp,” it will kick off a request for the WebP format image. If not (or if the browser doesn’t recognize picture), it will request the JPG. 

The nice thing about this approach is that you’re serving the smallest image possible to the user without having to resort to any sort of JavaScript hackery.

You can take the same approach with video files:

<video controls>
  <source src="my.webm" type="video/webm">
  <source src="my.mp4" type="video/mp4">
  <p>Your browser doesn’t support native video playback,
    but you can <a href="my.mp4" download>download</a>
    this video instead.</p>

Browsers that support WebM will request the first source, whereas browsers that don’t—but do understand MP4 videos—will request the second one. Browsers that don’t support the video element will fall back to the paragraph about downloading the file.

The order of your source elements matters. Browsers will choose the first usable source, so if you specify an optimized alternative format after a more widely compatible one, the alternative format may never get picked up.  

Depending on your situation, you might consider bypassing this markup-based approach and handle things on the server instead. For example, if a JPG is being requested and the browser supports WebP (which is indicated in the Accept header), there’s nothing stopping you from replying with a WebP version of the resource. In fact, some CDN services—Cloudinary, for instance—come with this sort of functionality right out of the box.

Offer different sizes

Formats aside, you may want to deliver alternate image sizes optimized for the current size of the browser’s viewport. After all, there’s no point loading an image that’s 3–4 times larger than the screen rendering it; that’s just wasting bandwidth. This is where responsive images come in.

Here’s an example:

<img src="medium.jpg"
  srcset="small.jpg 256w,
    medium.jpg 512w,
    large.jpg 1024w"
  sizes="(min-width: 30em) 30em, 100vw"
  alt="Descriptive text about the picture.">

There’s a lot going on in this super-charged img element, so I’ll break it down:

  • This img offers three size options for a given JPG: 256 px wide (small.jpg), 512 px wide (medium.jpg), and 1024 px wide (large.jpg). These are provided in the srcset attribute with corresponding width descriptors.
  • The src defines a default image source, which acts as a fallback for browsers that don’t support srcset. Your choice for the default image will likely depend on the context and general usage patterns. Often I’d recommend the smallest image be the default, but if the majority of your traffic is on older desktop browsers, you might want to go with the medium-sized image.
  • The sizes attribute is a presentational hint that informs the browser how the image will be rendered in different scenarios (its extrinsic size) once CSS has been applied. This particular example says that the image will be the full width of the viewport (100vw) until the viewport reaches 30 em in width (min-width: 30em), at which point the image will be 30 em wide. You can make the sizes value as complicated or as simple as you want; omitting it causes browsers to use the default value of 100vw.

You can even combine this approach with alternate formats and crops within a single picture. 🤯

All of this is to say that you have a number of tools at your disposal for delivering fast-loading media, so use them!

Defer requests (when possible)

Years ago, Internet Explorer 11 introduced a new attribute that enabled developers to de-prioritize specific img elements to speed up page rendering: lazyload. That attribute never went anywhere, standards-wise, but it was a solid attempt to defer image loading until images are in view (or close to it) without having to involve JavaScript.

There have been countless JavaScript-based implementations of lazy loading images since then, but recently Google also took a stab at a more declarative approach, using a different attribute: loading.

The loading attribute supports three values (“auto,” “lazy,” and “eager”) to define how a resource should be brought in. For our purposes, the “lazy” value is the most interesting because it defers loading the resource until it reaches a calculated distance from the viewport.

Adding that into the mix…

<img src="medium.jpg"
  srcset="small.jpg 256w,
    medium.jpg 512w,
    large.jpg 1024w"
  sizes="(min-width: 30em) 30em, 100vw"
  alt="Descriptive text about the picture.">

This attribute offers a bit of a performance boost in Chromium-based browsers. Hopefully it will become a standard and get picked up by other browsers in the future, but in the meantime there’s no harm in including it because browsers that don’t understand the attribute will simply ignore it.

This approach complements a media prioritization strategy really well, but before I get to that, I want to take a closer look at Service Workers.

Manipulate requests in a Service Worker

Service Workers are a special type of Web Worker with the ability to intercept, modify, and respond to all network requests via the Fetch API. They also have access to the Cache API, as well as other asynchronous client-side data stores like IndexedDB for resource storage.

When a Service Worker is installed, you can hook into that event and prime the cache with resources you want to use later. Many folks use this opportunity to squirrel away copies of global assets, including styles, scripts, logos, and the like, but you can also use it to cache images for use when network requests fail.

Keep a fallback image in your back pocket

Assuming you want to use a fallback in more than one networking recipe, you can set up a named function that will respond with that resource:

function respondWithFallbackImage() {
  return caches.match( "/i/fallbacks/offline.svg" );

Then, within a fetch event handler, you can use that function to provide that fallback image when requests for images fail at the network:

self.addEventListener( "fetch", event => {
  const request = event.request;
  if ( request.headers.get("Accept").includes("image") ) {
      return fetch( request, { mode: 'no-cors' } )
        .then( response => {
          return response;

When the network is available, users get the expected behavior:

Screenshot of a component showing a series of user profile images of users who have liked something
Social media avatars are rendered as expected when the network is available.

But when the network is interrupted, images will be swapped automatically for a fallback, and the user experience is still acceptable:

Screenshot showing a series of identical generic user images in place of the individual ones which have not loaded
A generic fallback avatar is rendered when the network is unavailable.

On the surface, this approach may not seem all that helpful in terms of performance since you’ve essentially added an additional image download into the mix. With this system in place, however, some pretty amazing opportunities open up to you.

Respect a user’s choice to save data

Some users reduce their data consumption by entering a “lite” mode or turning on a “data saver” feature. When this happens, browsers will often send a Save-Data header with their network requests. 

Within your Service Worker, you can look for this header and adjust your responses accordingly. First, you look for the header:

let save_data = false;
if ( 'connection' in navigator ) {
  save_data = navigator.connection.saveData;

Then, within your fetch handler for images, you might choose to preemptively respond with the fallback image instead of going to the network at all:

self.addEventListener( "fetch", event => {
  const request = event.request;
  if ( request.headers.get("Accept").includes("image") ) {
      if ( save_data ) {
        return respondWithFallbackImage();
      // code you saw previously

You could even take this a step further and tune respondWithFallbackImage() to provide alternate images based on what the original request was for. To do that you’d define several fallbacks globally in the Service Worker:

const fallback_avatar = "/i/fallbacks/avatar.svg",
      fallback_image = "/i/fallbacks/image.svg";

Both of those files should then be cached during the Service Worker install event:

return cache.addAll( [

Finally, within respondWithFallbackImage() you could serve up the appropriate image based on the URL being fetched. In my site, the avatars are pulled from Webmention.io, so I test for that.

function respondWithFallbackImage( url ) {
  const image = avatars.test( /webmention\.io/ ) ? fallback_avatar
                                                 : fallback_image;
  return caches.match( image );

With that change, I’ll need to update the fetch handler to pass in request.url as an argument to respondWithFallbackImage(). Once that’s done, when the network gets interrupted I end up seeing something like this:

Screenshot showing a blog comment with a generic user profile image and image placeholder where the network could not load the actual images
A webmention that contains both an avatar and an embedded image will render with two different fallbacks when the Save-Data header is present.

Next, we need to establish some general guidelines for handling media assets—based on the situation, of course.

The caching strategy: prioritize certain media

In my experience, media—especially images—on the web tend to fall into three categories of necessity. At one end of the spectrum are elements that don’t add meaningful value. At the other end of the spectrum are critical assets that do add value, such as charts and graphs that are essential to understanding the surrounding content. Somewhere in the middle are what I would call “nice-to-have” media. They do add value to the core experience of a page but are not critical to understanding the content.

If you consider your media with this division in mind, you can establish some general guidelines for handling each, based on the situation. In other words, a caching strategy.

Media loading strategy, broken down by how critical an asset is to understanding an interface
Media category Fast connection Save-Data Slow connection No network
Critical Load media Replace with placeholder
Nice-to-have Load media Replace with placeholder
Non-critical Remove from content entirely

When it comes to disambiguating the critical from the nice-to-have, it’s helpful to have those resources organized into separate directories (or similar). That way we can add some logic into the Service Worker that can help it decide which is which. For example, on my own personal site, critical images are either self-hosted or come from the website for my book. Knowing that, I can write regular expressions that match those domains:

const high_priority = [

With that high_priority variable defined, I can create a function that will let me know if a given image request (for example) is a high priority request or not:

function isHighPriority( url ) {
  // how many high priority links are we dealing with?
  let i = high_priority.length;
  // loop through each
  while ( i-- ) {
    // does the request URL match this regular expression?
    if ( high_priority[i].test( url ) ) {
      // yes, it’s a high priority request
      return true;
  // no matches, not high priority
  return false;

Adding support for prioritizing media requests only requires adding a new conditional into the fetch event handler, like we did with Save-Data. Your specific recipe for network and cache handling will likely differ, but here was how I chose to mix in this logic within image requests:

// Check the cache first
  // Return the cached image if we have one
  // If the image is not in the cache, continue

// Is this image high priority?
if ( isHighPriority( url ) ) {

  // Fetch the image
    // If the fetch succeeds, save a copy in the cache
    // If not, respond with an "offline" placeholder

// Not high priority
} else {

  // Should I save data?
  if ( save_data ) {

    // Respond with a "saving data" placeholder

  // Not saving data
  } else {

    // Fetch the image
      // If the fetch succeeds, save a copy in the cache
      // If not, respond with an "offline" placeholder

We can apply this prioritized approach to many kinds of assets. We could even use it to control which pages are served cache-first vs. network-first.

Keep the cache tidy

The  ability to control which resources are cached to disk is a huge opportunity, but it also carries with it an equally huge responsibility not to abuse it.

Every caching strategy is likely to differ, at least a little bit. If we’re publishing a book online, for instance, it might make sense to cache all of the chapters, images, etc. for offline viewing. There’s a fixed amount of content and—assuming there aren’t a ton of heavy images and videos—users will benefit from not having to download each chapter separately.

On a news site, however, caching every article and photo will quickly fill up our users’ hard drives. If a site offers an indeterminate number of pages and assets, it’s critical to have a caching strategy that puts hard limits on how many resources we’re caching to disk. 

One way to do this is to create several different blocks associated with caching different forms of content. The more ephemeral content caches can have strict limits around how many items can be stored. Sure, we’ll still be bound to the storage limits of the device, but do we really want our website to take up 2 GB of someone’s hard drive?

Here’s an example, again from my own site:

const sw_caches = {
  static: {
    name: `${version}static`
  images: {
    name: `${version}images`,
    limit: 75
  pages: {
    name: `${version}pages`,
    limit: 5
  other: {
    name: `${version}other`,
    limit: 50

Here I’ve defined several caches, each with a name used for addressing it in the Cache API and a version prefix. The version is defined elsewhere in the Service Worker, and allows me to purge all caches at once if necessary.

With the exception of the static cache, which is used for static assets, every cache has a limit to the number of items that may be stored. I only cache the most recent 5 pages someone has visited, for instance. Images are limited to the most recent 75, and so on. This is an approach that Jeremy Keith outlines in his fantastic book Going Offline (which you should really read if you haven’t already—here’s a sample).

With these cache definitions in place, I can clean up my caches periodically and prune the oldest items. Here’s Jeremy’s recommended code for this approach:

function trimCache(cacheName, maxItems) {
  // Open the cache
  .then( cache => {
    // Get the keys and count them
    .then(keys => {
      // Do we have more than we should?
      if (keys.length > maxItems) {
        // Delete the oldest item and run trim again
        .then( () => {
          trimCache(cacheName, maxItems)

We can trigger this code to run whenever a new page loads. By running it in the Service Worker, it runs in a separate thread and won’t drag down the site’s responsiveness. We trigger it by posting a message (using postMessage()) to the Service Worker from the main JavaScript thread:

// First check to see if you have an active service worker
if ( navigator.serviceWorker.controller ) {
  // Then add an event listener
  window.addEventListener( "load", function(){
    // Tell the service worker to clean up
    navigator.serviceWorker.controller.postMessage( "clean up" );

The final step in wiring it all up is setting up the Service Worker to receive the message:

addEventListener("message", messageEvent => {
  if (messageEvent.data == "clean up") {
    // loop though the caches
    for ( let key in sw_caches ) {
      // if the cache has a limit
      if ( sw_caches[key].limit !== undefined ) {
        // trim it to that limit
        trimCache( sw_caches[key].name, sw_caches[key].limit );

Here, the Service Worker listens for inbound messages and responds to the “clean up” request by running trimCache() on each of the cache buckets with a defined limit.

This approach is by no means elegant, but it works. It would be far better to make decisions about purging cached responses based on how frequently each item is accessed and/or how much room it takes up on disk. (Removing cached items based purely on when they were cached isn’t nearly as useful.) Sadly, we don’t have that level of detail when it comes to inspecting the caches…yet. I’m actually working to address this limitation in the Cache API right now.

Your users always come first

The technologies underlying Progressive Web Apps are continuing to mature, but even if you aren’t interested in turning your site into a PWA, there’s so much you can do today to improve your users’ experiences when it comes to media. And, as with every other form of inclusive design, it starts with centering on your users who are most at risk of having an awful experience.

Draw distinctions between critical, nice-to-have, and superfluous media. Remove the cruft, then optimize the bejeezus out of each remaining asset. Serve your media in multiple formats and sizes, prioritizing the smallest versions first to make the most of high latency and slow connections. If your users say they want to save data, respect that and have a fallback plan in place. Cache wisely and with the utmost respect for your users’ disk space. And, finally, audit your caching strategies regularly—especially when it comes to large media files.Follow these guidelines, and every one of your users—from folks rocking a JioPhone on a rural mobile network in India to people on a high-end gaming laptop wired to a 10 Gbps fiber line in Silicon Valley—will thank you.

Reliable hosting, great service, personal attention.


Keep in touch with Graphicz Ltd website design and share

Graphicz on Social Media

01323 872296. 07836 551000.

Website by Graphicz