Our static box with 2,000 permutations then multiplies to over 20,000 with all the interactions included.

Seem like a bit much? Not really.

Because we want to make sure that everyone has full access to the web–regardless of where they’re accessing it from.

4. Ninety-five shades of grey

Even within our team, no one knew how many variations of text styles lived inside this box. Because Chrome was built over 10 years, we had a scattered set of incomplete or outdated source files.

So, in due diligence (but mostly to make sure I didn’t break our UI for billions of people) we crawled through every line of code for every text style and mapped out hundreds of variations in size, weight, color and transparency.

Sure, we had “Materialized” our UI a few years ago, but we didn’t have any guidelines for how and when to use those specs, resulting in over 14 shades of Material grey for just 14sp Roboto Regular text.

We were using over 95 different shades of grey total.

It was impossible to decide which ones to replace without looking at the context. Even the smallest change could break accessibility standards. But I wanted to know the minimum number of colors we actually needed.

The answer came nearly half a year later: 8.

We then did the same for every icon across our UI. All 115 of them* — carefully selecting which ones were Material (menu icons), which ones were Chrome specific (like Incognito), and which ones were platform specific (like copy/paste)– not including the selected, pressed, and disabled states for all of them.

*In addition, some of our icons are flipped for right-to-left languages, so the total number is actually closer to 400+

5. Design is never (un)done

After months of staring at grey boxes, I would be lying if I said that the mountain of work left ahead didn’t seem daunting.

With the misguided confidence of someone who had just beat the game Getting Over It, I honestly thought I could do it all by myself. But the harder I tried, the more obvious it became that this problem wasn’t going away with a simple redesign.

We needed to overhaul our entire design process to ensure that our existing and future UI would remain consistent.

This was difficult because Chrome is in a constant balancing act between Google specs (account sign-in flows), Material specs (buttons and icons), Native UI (keyboards), and Chrome brand elements (the offline dino game).

So, I asked our Engineers for help and amazingly, they welcomed the scope creep. This issue also made it difficult for them to review code, as platform constraints and feature changes meant a waterfall of regressions and inconsistencies. In fact, our Eng lead, Ted Choc* even hired someone to support our efforts. (My literal wish come true!)

*To give you an idea of how amazing our Eng team is, Ted’s mission statement literally says “Chrome Mobile Awesomification.”

With newfound support, we set out to build a visual spec of shared components based on a code library. Material components that other apps get “for free” had to be customized to meet all of Chrome’s (2,000) permutations to the point where it was nearly built from scratch. So we needed to find a scalable way to map out all these differences.

The result was our first ever Chrome sticker sheet:

Our v1 (M54) sticker sheet — mapping every color, text, icon and component in our UI

6. Designing for speed

For months, we were merely removing things. Cleaning up years of accumulated design and engineering debt. Now that we had a squeaky clean surface and a system of building blocks, we were ready to start designing.

Let’s return to the box we first met in chapter 1. Box No. 1 lives in a larger grey box we call the “toolbar.”

Box No. 2

The toolbar separates our UI from the content and the system UI. When you tap on the white box, it fills the grey box, and reveals another grey box below. (Confusing right?)

Box No. 3

This is where we get to show everything we’re doing behind the curtain to try to make Chrome as helpful as it can be. But why have all these boxes resize and change from one state to the next?

The many faces of Box No. 1

When something changes from screen to screen, it becomes difficult to recognize or become familiar with.

If UI changes as users interact with it, they process that change as information that may be useful later. For example, if an image disappears into an icon, you may need to remember that icon in case you want to open that image again.

This adds to the split-second cognitive load of understanding a user interface and trying to decide what information is necessary to retain.

We removed every pixel of visual noise to make it faster for you to cognitively process — not just to make it aesthetically pleasing.

Even if that saved 1 person in every city just 1 second, that’s approximately 2,000,000 seconds or 23.14 days of time. Think what people could do with 23 extra days!

To demonstrate, let’s look at our toolbar with just the text and icons removed:

Do you notice how much your eye darts around the screen to process the different elements?

Now let’s take a look at the same screen with just the colors and shadows removed:

The exercise of starting from nothing, or what we call “building from white,” meant that every element had to be considered. Including this box that quietly sat above our UI all these years:

Box No. 4

Fortunately, we knew the creators of Box No. 4 and had a lot of support from the Android team to change the color based on the content (another 6 month journey which deserves its own post).

But let’s move on to the other inhabitants of Box No. 2: the icons. These icons each came with 2 other invisible boxes:

1. The “bounding box” which outlined the shape of the image asset.

Invisible Box No. 5

2. The “touch target” which outlined the area you could tap.

Invisible Box No. 6

Because the “3 dot menu” icon was skinnier, it had a smaller touch target. But merely making box larger, made it visually unbalanced, creating uneven gaps between the icons.

So we had to compromise and slightly break from the Material spec to make it easier to tap and visually balanced.

Yes, I spent an entire week staring at invisible boxes. Will anyone notice? Most likely not. Was it worth it? 2,000,000 times yes.

7. One box to rule them all

After I built up enough confidence by going through every text, color, and icon in our UI, I was ready to tackle the omnibox.

We wanted to find a way to subtly reinforce Chrome’s brand — a challenge considering our logo rarely appears in our UI. I created dozens of designs that seemed promising, only to realize that none of them worked, because they all lacked meaning.

So, I went back to our brand pillars and took a good hard look at our logo. The first thing I noticed was the lowercase “c.”

This speaks to the informal nature of our brand, so finding a shape that was friendly was important. We also share the same 4 colors as the Google logo to show our heritage. In fact, Android, Google and Chrome all had one recurring shape across their logos:

The circle.

Circles are naturally occurring shapes, unlike rectangles. So they have a smaller visual cognitive load. This shape was also still fresh in my mind from a two-year stint living in London.

When the Underground station names were first displayed in rectangular signs, it was difficult for moving train passengers to distinguish them from poster ads. So, in 1912, they added red circles behind them to make it easier to find. Frank Pick then incorporated the circle into the now-famous logo.

Image sourced from the London Transport Museum

This struck me as a better metaphor for our omnibox.

It shouldn’t just show you where you were, it should help you get from one place to the next.

Taking a deeper look at our logo, the shape that stuck out to me in particular was this one: