From an engineering perspective Chrome is spread across 4 Frameworks/Codebases: views, cocoa on Macos, Java for Android, and Obj-C/Swift for iOS.To keep our sanity and to enable better long term asset management, we try to share as much design resources as possible across platforms. For example Windows, Chrome OS and Mac share a lot of common visuals.&nbsp;If you launch Chrome on an iPad or an Android tablet, they will look very similar.

The Hybrid layout type

To do so, we needed two things:&nbsp;<ul><li>Regular mode was initially going to be deployed on the overwhelmingly largest portion of our user base.</li><li>A way to create, export and implement our assets that would gracefully scale in the broad layout type and PPI landscape of desktop.&nbsp;</li></ul>

New layout type, new process

At the beginning of 2013, Chrome was yet to become the default Browser on Android, it didn’t have a tablet version and has just been release on iOS.&nbsp;Mobile became the primary focus in the years separating the beginning of 2013 and the Chrome Android material design revamp of 2015.&nbsp;We started seeing the desktop/laptop landscape shift into a state where touchscreen were no longer the exclusive attribute of mobile but also the one of more productive platforms such as laptops.

Timing and planning

<ul><li>Bring the new tab shapes to life on desktop&nbsp;</li><li>Bring a new set of icons, derived from MD using desktop sizes&nbsp;</li><li>Align and simplify our color palette and our theming system. Bonus: Bring the new “dark” incognito to desktop&nbsp;</li><li>Start the revamp of secondary UI elements such as buttons, toolbars, bubbles, etc…&nbsp;</li><li>Create a more touchable version of Chrome for convertible devices&nbsp;</li><li>Come up with a set of rules for Third party OS consistency&nbsp;</li><li>Implement MD motion when possible&nbsp;</li></ul>

Visual consistency and design details

As part of this big update cycle, Chrome received a revamp of its mobile properties, iOs and Android.&nbsp;The desktop UI future was slowly taking shape and clearer opinions on the matter were forming. It is at that time, almost two years from now, that the chrome desktop redesign process started. It is at that time, almost two years from now, that the chrome desktop redesign process started.&nbsp;

The Flat Design Era

The native frame on windows is taller than its Chrome OS and Mac OS counterparts.It makes the frame easier to click and grab at the cost of a bigger footprint.&nbsp;To achieve balance, we split the UI in half: tabs+ Window frame/ Toolbar. Tabs are 28pt, equal to the Omnibox height. We leave an 8pt top padding between the tabs and the top of the frame.

General layout and UI footprint

We used 16X16pt based icons to match our new normal and hybrid UI. We reduced the container from 24pt to 16pt and added some flexibility around the initial internal padding: 2pt change to 1pt to 2pt depending on the icon.&nbsp;We also made the icon line weight slightly thinner (2Px on 100% and 3Px one 200% from the initial 2Px in 100% and 4Px in 200%) this way, they are more elegant and balanced within our UI.

Iconography

In normal mode, we went for 28X28pt touch targets, holding 16X16pt icons. While icons kept their 28X28pt touch targets, we increased their surrounding margin to 8pt, giving the UI more space and reducing user touch errors.&nbsp;We use 16X16pt iconography throughout. This minimizes the amount of design asset requiring maintenance, making long term scalability as well as feature iteration. Easier to maintain.

Touch targets and layout

There are two tenants to our omnibox and dropdown layout design: <ul><li>Give a strong emphasis on security states. </li><li>Fast access to the information or URL you need to go to. </li></ul>

Omnibox, results dropdown and security indicators

The Core UI is formed of three key elements:&nbsp;<ul><li>The frame, created by the OS itself, changing on a per platform basis&nbsp;</li><li>The Active tab and toolbar. Which includes the selected tab attached to the ommibox and controls&nbsp;</li><li>The inactive tab(s).&nbsp;</li></ul>

Colors and accessibility

<ul><li>Hover state&nbsp;</li><li>Active state&nbsp;</li><li>Single click/tap (onClick-release)&nbsp;</li><li>Single click/tap to active&nbsp;</li><li>Long click/tap to active&nbsp;</li></ul>

Motion

After the completion of the Implementation-Ready Specs and Mocks for the core UI, I dabbled a bit in chrome’s secondary UI.&nbsp;We include in that category every chrome element not directly visible such as menus, Dialogs, bubbles, buttons, Info-Bars, Find-In-Page and Download shelf.

What’s next

As a closing note, I’d like to share some of the lessons I learned during this project as well as some release reaction, both internal and external, hoping that these will be helpful to you, in your projects.

Lessons learned and initial release feedback

Programmatic rendering and motion design were crucial in getting the design right.&nbsp;If you are lucky enough to be working with motivated and engaged engineer, you might realize that they can sometimes be a better designer than you.

1. Engineers are great designers

In the present case, they were involved right away and were an integral of the design and conception process. Engineers' motivation to deliver better design through better engineering solution made the product what it is today. Maintaining constant communication was key to bring the right design to life.

2. Involve engineers early

Delivering extremely precise spec work is necessary, however, in some cases, leaving your preliminary work open for feedback and new ideas can bring your design to another level. As long as your end design stays true to its original goal or intent, let others enter your process and improve on your design.

3. Know when to be precise, learn when to be loose

The biggest improvements brought by this redesign project are under the hood. Finding satisfaction in your work and the result through your own eyes is more important than seeking validation through others.&nbsp;If you are truly and honestly satisfied with what you have done. You’re good.

5. Manage your expectation

I won’t lie, I do not have the miracle solution to it but there are things that you can do to minimize change aversion: <ul><li>Always have a deck ready to explain your vision to your audience.</li><li>Stay the course. It is very beneficial to strongly believe in the choices you made. Don’t get stubborn but stay confident. </li><li>Be prepared to back up your design decisions with facts, studies or past experiences. If you cannot answer back, you might find that their feedback is worth considering.</li><li>The bigger the product, the longer it might take.</li></ul>

4. Beware of change aversion

In the beginning of September 2016, the new Chrome Core UI redesign, or so called “Chrome MD” (for Material design), rolled out on Windows as part of our 53rd update. It is the last step of a three…

Lessons learned and initial release feedback

Similar ideas to Lessons learned and initial release feedback

52 Simple Lessons That Will Make Your Life 1,000X Easier

Types of people

How to study 📚🦋💻📑

Get organized

Pay attention in class