Chrome Redesign

💁🏻‍♂️ Overview

Project Title:
Proposed Google Chrome Redesign

None, self-initiated

5 days, 0 budget

“Tidy users” with < 8 tabs open, “Power users” with >30 tabs open

Problem statement
How do we keep the current browsing experience for “Tidy Users”, while improving the navigation for “Power Users”?


  1. Only keep the most frequently visited 8 tabs at regular size, all other tabs will be half the size
  2. Categorize all tabs by domain name
  3. Arrange categories in alphabetical order

Total number of people interviewed:

Preliminary findings suggest a decrease in navigation time by 30-40%. Calculated by comparing the time taken for participants to find 10 tabs in a given order. Sample Size of 25. It will, ceteris paribus, also increase the tabs before we begin to see dead screens by 71%.

Note: Without access to Google’s data, it is incredibly difficult to fully understand the design decisions made. The problems are identified based on a small sample of 45 people I have interviewed. I immensely appreciate the work of the Chrome team. I think this project is more about designing a new browsing experience using Chrome as a benchmark, more than a specific proposition to Chrome.

💭 Introduction

I was a bit shocked when I first saw the updated iOS Chrome browser. I have always been a huge fan of Chrome, but had mixed feelings when I used the new browser. Considering the incredible talent at Google, I questioned my judgement. Is this Pinterest-looking layout the future of mobile web browsing? Am I the only one who does not like the new design? I turned to the App Store reviews for answers.

Seeing consecutive 1 star reviews made me realize that I am not the only person against the new design.

Pain points

  • No difference between Safari and Chrome
  • No alternate layout options
  • Webpages freeze due to the increased memory consumption of the screen previews
  • The screen previews take up too much screen space
  • Increased load time

With that in mind, I felt there was a strong enough reason to launch a discovery.

🚋 Discovery


🤸🏻 Users

There are 2 groups of users, people who open < 10 tabs, and people who open > 50 tabs.

To test the hypothesis, I interviewed 10 people about their browsing behaviour.


Note: while I relied on the number 8 for some of the design decisions, it can be replaced with any number of tabs “Tidy Users” normally have open. This will have to be verified through a much larger (1000+) sample size. The key here is to recognize the two separate personas. There is in fact a third persona with >50 tabs, but the problems they have are identical to “Power Users” with >30 tabs open. It did not seem necessary to define the third persona.

❗ Problem

“I lose track of what I’m doing very often and tasks pile up. After that I will give up and close all my tabs.”

This is one of the answers I have received during the more open ended part of the interview. It best encapsulates the problem more people faced. I also finally understood why there is a “close all” button - the browsing equivalent of “self-destruct” easily accessible. It also explained why quick access to recently closed tabs (toggle right) is necessary. They both seem to be accommodations to a bigger problem of confusing navigation.

⚠️ Problem Statement

How do we keep the current browsing experience for “Tidy Users”, while improving the navigation for “Power Users”?

We need to acknowledge the strengths of Chrome’s new design

  1. Contrary to the opinion expressed in the App Store reviews, the new experience actually helps differentiate Safari and Chrome on the iOS platform. The two interface only look alike in Safari’s horizontal browsing mode. When comparing the two layout in vertical mode - the more common mobile browsing orientation, they are actually quite different. While Safari has a header-based navigation system, Chrome has a screen-preview-based navigation.
  2. The current Chrome redesign works well for “Tidy Users”. Most of the problems identified are exclusive to “Power Users”. During this redesign project, we need to make sure that the experience of “Tidy Users” is not affected.

📝 Wireframing

1) Categorize the tabs by their domain names

For example, all Medium tabs will be grouped together, and the more frequently users click on a tab, the closer the group is to the top of the page. This method of arranging is based on the Pyramid Principle.

The more frequently a group of tabs is accessed, the more frequently a user has to find a particular branch name eg. “C”. Branch “C” is going to be looked up the most, even if “B” has a constituent page “B2” with more views than “A1” or “A2”. Branch A is obviously looked up the last, and therefore should be at the bottom of the page. This assumes that the homepage opens at the top of the page each time, thereby reducing the amount you need to scroll.

2) Make tabs you use less frequently half the size of normal tabs.

Specificially, only the 8 most frequently visited tabs will be full size. For “Tidy Users” - their experience will remain the same. For “Power Users” - the more tabs you open, the more space you will save. This also dramatically increases the maximum number of tabs possible before you get empty preview screens.

Quick Estimates

The maximum space saved is theoretically 50% when T approaches infinity, but realistically, it is closer to 43% at T=50, 44% at T=70, and 46% at T=100 - the absolute maximum amount of tabs Chrome supports.

Dead Screens

What we are really concerned with however, is the number of tabs a user can open before we begin to see dead screens. Below is the basic estimate for the percentage increase in the screens possible before dead screens appear, with other conditions remaining the same.

🎤 Feedback

Positive! The 10 interviewees unanimously agreed on the potential of both ideas.

The only concern is that when frequency is detected and screens automatically shuffle, one person felt that

  1. It is invasive
  2. Not ideal for building muscle memory

Both concerns are valid, but not mission-critical. So they stayed at the back of my mind. I had the opportunity to address them in the fourth iteration.

✏️ First Iteration

These are the changes I have made

  1. The headers are now bigger, and 2x the original length
  2. To differentiate the black at the bottom of the screen and the backdrop, I have changed the background to white. The white is taken from Gmail’s screen so that it still feels “Googley”. This has the additional benefit of differentiating the normal screens from the incognito screens.
  3. As mentioned previously, the tabs used less frequently are now half the size of regular tabs. Pages have also been organized by domain name. Medium is at the top because it is presumeably the site most accessed by the imaginary user.

To ensure that the scope is narrow enough to be addressed in the 5 days timeframe, and that the test is focused specifically on the change in layout, everything else has remained the same.

🌡️ Test design

To compare the efficiency of the original and new navigation system

Time taken to find 10 tabs

Means of comparison:
% difference for 1 participant to find 10 tabs on the two designs

Participants are given my iPhone to test both designs.first on the original Chrome design, and later on the new design through an Origami mockup

Fair test

  • I have, after the first iteration revised the test. Participants after the first round of tests have to look for 2 sets of 10 different tabs, rather than the same set of 10. While I originally thought looking for the same list of 10 made the test fairer, it was in fact the opposite. Participants told me that they were able to memorize some of the headers.
  • I have also manipulated the Chrome screens so that participants can see the relevant screen previews. This pits the new design against the best case scenario of the original design.

Length of test
Since none of the participants are paid, I have tried my best to keep the test under 10 minutes. I have found finding 10 tabs within a selection of 31 to be about 5 minutes. 31 since "Power Users" are defined to have >30 tabs opened. I anticipate that the more tabs there are, the more time it saves, but that is not testable given the constraints in time and budget. It is also worth noting that for such a small sample size, the qualitative part of the participants' answers are much more meaningful. Having the quantitative part of the test too long will take away time on qualitative feedback.

Anybody at the 6th floor common area at the New School who would agree to test - primarily liberal art and design students, M/F, 18-24

Sample Size
Aimed to test each iteration with 10 people


  1. Ask for consent
  2. Explain the project goals
  3. Explain the test
  4. Test
  5. Results (% difference)
  6. Open-ended questions focusing on their experience, preference, and possible improvements

Document shown to participants
They are shown separately in different parts of the test

📏 Second Iteration

“I’m so embarrassed”
- said a participant, as she misidentifies a tab for the fourth time on the original design

The first 10 results were incredibly encouraging. Average time saved is about 40%

With the input of the participants, I made the headers more readable by darkening the black gradient underneath the text

📐 Third Iteration

Results from the second iteration surprised me because for the first time, the % change dropped below 20%. Test 1 was 3%, and test 7 was 5%. When the difference is only 2-5 seconds apart, results are inconclusive. Bottomline is that the new design did not perform worse than the original design.

The two participants revealed that both experiences was not particularly pleasant. They much prefer Safari’s header-based navigation over Chrome’s. In this case, I think it is necessary to realize that people who strongly prefer header-based navigation will not see a significant change in % time saved. If I were to conduct this test in a much larger scale, I would also collect users’ browser preference.

Things to iterate

  1. Make the spacing between categories more pronounced. Doing so would make the groups easier to identify.

⏱️ Fourth Iteration

Results are as expected during the third iteration - no % change dropped below 20%.

I stopped testing after the 5th test firstly because time was running out, and secondly because I felt like there was a significant enough breakthrough.

One of the participants reflected that she found the new layout to be confusing, since frequency was being expressed in 2 different ways.

  1. Size of tabs
  2. Position on page

Because there are normal and half-sized tabs in each group

  1. The design became messy, and to return to the problems identified in the wire framing stage
  2. The changing position is not good for muscle memory
  3. The automatically changing layout makes the experience feel invasive

The solution was obvious - to keep using the size of tabs as a means of differentiating frequency, and order the tabs on the page differently. One of the suggestions is to order the tabs alphabetically. This is what I did.

😇 Fifth/ Final Iteration

With the project coming to a close, I looked up Google’s material design guideline. This is the final redesign. With shadows beneath each card, and a translucent card on top of the tabs to show depth.

👨🏻‍💻 Last thoughts

Given the opportunity, I would test the design much more rigorously - with videos, without moderation, and with a significantly larger sample size. With the redesign of the main interface, it also leaves a lot of opportunities open.

Something to think about

  1. Instead of toggling between incognito-normal-history, users can toggle between grouped-recents. Grouped is how the new interface is like, and recents would show the tabs according to the time it was last accessed. Tabs will be organized by "Today", "Yesterday", "Two days ago", etc. I would imagine the feature would benefit “Tidy Users” the most.
  2. Adding a search bar, as suggested by quite a few users.

The numbers and statistics aside, I think the redesign is successful in the way that it keeps the screen-preview-based navigation as well as the experience of “Tidy Users” - the goals of the task, while resolving the problem with navigation for “Power Users” such as myself.

What do you think about this project? Email me your thoughts!

About me

Hi, thank you for visiting! I am Marvin, a UX designer from Parsons School of Design.

I believe in Product development - because I love making things, the business value of design - because the things I build should have an impact, and data - because there needs to be a way to evaluate the impact. To pursue the direction, I am partaking in “Applications of Digital Analytics and Product Management Strategies in UX Processes”, a 5 week workshop (Nov-Dec) privately organized by Daniel James, who previously held positions at BCG (Consultant), Goldman Sachs (Analyst), and Capital One Labs (Director of Product Management). Using analytics to drive UX processes, and focuing on metric interpretation helped quantify the impact of design immensely.

In my last three years as a college student, I spent a lot of time exploring different fields, honing my design capabilities along the way. I learnt to manage semester-long projects (HKU Architecture 2016-2018) - to handle photography professionally (New York Fashion Week 2018 F/W Workshop) - the conventions of branding (Constant, Creative Intern Summer 2018) - as well as the fundamentals of UX (General Assembly UX Design Circuit Summer 2018). My major in illustration at Parsons School of Design supports my experimentation in visual communication.

Get in touch, or see CV