As my involvement in the Chrome browser is ending with this Core UI project, I’m excited to see what the Chrome team has for the future of Chrome on desktop and mobile.

Lessons learned and initial release feedback

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.

1. Engineers are great designers

We talk a lot in our design circles about if and why a designer should code. There are a lot of diverging opinions on the matter and it comes from the fact that there is no simple definition of the role of a designer.

However, we talk less of the opposite: Should engineer design?

In the end, they are the makers and to a certain extent, the “designers” of your product, the ones who make it become a real thing. Sometimes, as a designer, I feel like all that we do is trying to “fake” or “mimick” the end result. Cutting to the chase as fast as possible to try things in the real environment, in real code, is essential.

In this project, a lot of my assumptions were broken by engineers who not only brought better solutions to the table but executed and iterated on the design better that I could ever do. I’m thinking more specifically of programmatic rendering (an effort championed by Peter Kasting) and motion design (lead by Ben Ruthig). Their code knowledge was crucial in getting the design right and more than only changing the design it changed the nature of the project, from a visual revamp of the UI to a core rewriting.

Everybody is a designer. Ideas are not limited to a role. 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.

2. Involve engineers early

In the present case, they were involved right away and were an integral of the design and conception process. As I mentioned earlier, their 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.

You don’t necessarily need to understand how to code, it’s more important to understand the people who do.

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

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.

4. Beware of change aversion

When you are redesigning a product, especially if it has been around for a while, you will run into what a lot of us have encountered: change aversion. Now be careful, sometimes your design might actually be bad but in a lot of cases, the simple act of changing something is sufficient to trigger moderate to extreme reaction from your users.

It can be extremely hard to receive and extremely hard to fight. For this redesign, adding a few pixel triggered lengthy discussions or debate.

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:

Communicate with your audience. Always have a deck ready to explain your vision to who might want to hear it, especially if they are your stakeholders.

Stay the course. It is very beneficial to strongly believe in the choices you made. Don’t get stubborn but stay confident.

Be prepared. When somebody wants to discuss some of your design decisions, be prepared to back these up with facts, studies (when possible) or past experiences. If you find yourself in a situation where you cannot answer back, you might find that their feedback is worth considering.

Understand some things take time. Probably the most frustrating and the one I’m having the most trouble dealing with, some things just take time to change. The bigger the product, the longer it might take. Find happiness in the small victories and understand that your product is never done.

5. Manage your expectation

When the update started to roll out, the hardest feedback I received was: “That’s it?”. It’s a fair feedback in my opinion. The project took time and it’s not a visual revolution. I like to think that if you look into the details, you might start to see how much attention and care we put into it.

The biggest improvements brought by this redesign project are under the hood. It is an engineering achievement most and foremost.

I do hope that the benefit will be felt over time, both in our team and with our users, as Chrome has never been so flexible and consistent across our supported platforms.

Finding satisfaction in your work and the result of it through your own eyes is more important than seeking validation through others’. If you are truly and honestly satisfied with what you have done. You’re good.

Closing notes

Thanks for reading so far. If you want to reach out, feel free to connect on Twitter or anywhere else.

If you want to connect with the Chrome design team, these are cool people to follow on Twitter: Alex Ainslie, Chris Lee, Max Walker, Rachel Ilan Simpson, Peter Schaffner, Hannah Lee, Glen Murphy.

The awesome engineering team behind this work:

Peter Kasting, Ben Ruthig, Evan Stade, Terry Anderson, Valery Arkhangorosky, Jayson Adams.