In honor of Chrome’s 10th birthday in September 2018, we launched a complete redesign of our UI which involved an overhaul of our design process. And while Chrome has always been open source, I wanted to share more of our design stories in the hopes that others can learn from it.

1. Meet our box

I often get questions like “Why does Chrome need a designer?” My colleague, Sebastien, described it beautifully in his Medium post when he said,

“The hardest feedback I received was, ‘That’s it?’”

Buried deep within that question was an assumption that browsers were supposed to look like this:

It’s familiar because it looks just like the box on my PC, and with 2 billion users, it seemed to work. So why redesign it?

Because hidden inside this box was the world’s most sophisticated, secure, search and rendering engine for the web.

And we wanted to give it a design that changed the way the world saw browsers.

2. A short history of boxes

To understand how we got here, let’s take a closer look:

This 0.5dp gradient outlined, double 22% opacity drop shadowed box and its hot little 1dp corner radius says one thing: I can type into it.

Why? Because back when computers were just keyboards attached to monitors, the whole screen was essentially just text.

But when the mouse was invented, there was a need to show what area was clickable. Because monitors then could only draw square pixels, the “text entry box” was born.

As browsers were introduced, this box had the dual purpose of showing your location or “Uniform Resource Locator (URL)” — hence the name “address bar.”

In 2008, when Chrome first launched, our primary design principle was to reduce cognitive overhead. So we merged Google’s search box with the address bar and added a hairline dropdown menu with a 4dp drop shadow to make suggestions easier to scan — hence the name “omnibox.”

When browsers first came to mobile, screen real estate was precious so we crafted every pixel to take up as little space as possible. We used a 1 dp inner drop shadow instead, and made it grey blend in.

Since then, the web has gotten more complicated and devices, smarter. We started caring about what happens when a site gets hacked and compromises your identity. Or when you suddenly lose your internet connection. Or want to go back to a page you visited a week ago but can’t remember the address for.

Over the past 10 years, thousands of engineers around the world (and at Google) thought about these types of questions, and poured their heart and soul into finding solutions to help users navigate this exponentially changing web.

The miracle of mobile browsing also brought with it a flood of people that were coming online for the first time on their phones. They had never seen this box before; they didn’t know all the things we learned from desktop browsing.

I have to admit, I didn’t know half of Chrome’s features until I started working here. For example, you can swipe the toolbar left or right to switch between tabs. Or swipe down to view all your tabs.

Features like this were seemingly hidden because we never wanted to spam our users. In fact, our omnibox was designed to be invisible to honor our core value, “content, not chrome.” A principle I liked so much, it’s actually one of the reasons I joined.

As an introvert, there was an appeal to designing for something that also tries to be invisible. The product itself seemed to mirror my view of design:

to protect the sacred space between the user and the content — not to seek attention.

Much like Beatrice Warde’s view of typography as a “crystal goblet” I saw Chrome merely as a “crystal display.”

I was so wrong.

As the web changed, other third parties started to pretend to be Chrome to steal information, or were intentionally deceptive.

Whereas before, we didn’t mind if anyone could pick out Chrome from other browsers, it was starting to affect the security of our users.

So for the first time, we started to question our need to be less invisible.

3. A box with 2,000 sides

When I first sat with our engineers to get a better idea of how our omnibox was built, nothing could have prepared me for what was to follow.

This was like nothing I had ever designed in my 15 years of experience.

We support over 6 versions of Android across 40 languages — including ones that Roboto Medium doesn’t support — for which we have a graceful fallback. We also allow developers to change the color of our toolbar to virtually anything, all while maintaining accessibility contrast ratios to support the web app ecosystem.

Our UI also adapts so that high and low pixel-density devices have similar touch targets and runs smoothly regardless of your device’s memory capacity or manufacturer.

That’s over 2,000 permutations for this box — before you even interact with it.

As soon as you tap, type, scroll, swipe, or talk to it, our omnibox morphs into thousands of other permutations.

When you type, we make sure that the keyboard you see is the one you’re familiar with. When you share a site, we show the same options you normally have on your phone.

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:

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.”

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?)

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?

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:

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.

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

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.

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:

It was literally the shape of our brand.

It expressed our character, while demonstrating that this wasn’t just a “search box” or “address bar” but something new, and friendly.

As the introduction of the mouse led to the shape of the text box, we needed something new for the input device mobile phones introduced — our fingers. Which this shape also reinforced.

By chance, we also had a team outing to a Frank Stella exhibit at the de Young Museum. Stella’s use of curve shaped canvases broke out of the standard rectangular frame. Like me, he also loved race cars and in his painting Deauville, part of his “race track series,” he used a similar shape to imply speed –one of Chrome’s core pillars.

I echoed the Modernist sentiment that traditional forms of art were becoming irrelevant and outdated for our tasks. So we named our new visual design direction “Modern.”

We then explored thousands of designs.

At first, I took the same approach we originally took on mobile. Using a 1 dp hairline seemed to make sense. But in execution, it was easily lost in a sea of white sites with search bars on top. The hairline also didn’t work as well in Incognito mode and was difficult to balance against the thick outlined icons.

One of our designers literally thought it was just a wireframe.

Using the Material drop shadow also didn’t feel quite appropriate as it didn’t solve our original problem of seeming like just a “search box.” And the bottom drop shadow added an additional 4dp which was heavy and vertically off centered.

We even tried removing the box altogether but the elements now seemed randomly placed, and a change like centering the URL had significant Eng costs.

As it turned out, our colleagues were also working on making our URL appear cleaner, and Material 2 just started rolling out. It brought richer color palettes that gave more life to our shape.

And as it turned out, having a consistent shape also made our code less complex with fewer transition animations — the perfect balance of design and efficiency.

Now, we were ready to put it to the test. Thousands of users, months of experimentation and usability studies, and fingers crossed, when compared to our previous design, it was rated as being more “friendly,” “innovative,” and “intelligent” without seeming any less “fast” or “trustworthy.”

And while I only have time to write about this one box, there are a dozen other stories just like it for every other inch of our UI.

Is it perfect? Not yet, but that’s not what makes me proud of what we’ve done. It’s the fact that we made Chrome smaller, and less costly to download while doing it — making sure that every pixel we built paved the way for the next designer who comes along with something even better.

Personally, I knew we had done something right when one participant in our user study said,

“This gives me a better sense of calm and might actually help me throughout my day.”

Not because they liked the design. But because that was how I viewed Chrome, too.

We spent nearly a year poring over every pixel in our UI because we wanted the wrapping to match the quality of the gift inside — just on the off chance that maybe this time, you might notice that this isn’t an ordinary box.