Just another day
Because we only like to reinvent the wheel when we have to
For many, today is just another day. Well, not for me, my team, and all the other people who spent the last six months on version 57 of the browser, the new Firefox Quantum. Today, we’re going into Beta release with the new UI which adheres to the new Photon visual language. If you feel your head spinning, you’re right. Let’s put one thing after another.
Style guide vs. design systems
My name is Emanuela Damiani, and in few days, it will be one year since I began working at Mozilla.
When I joined, I was asked to focus my attention on two products in particular: add-ons and the new design system.
Building a design system is not an easy job. First, what is a Design System? What is it not? What are the differences between a style guide and a pattern library? All those questions were buzzing in my mind like one hundred bees.
Our team is not too big, or too small. It has six members, distributed from Vancouver to Taipei, passing through central Europe, and with just one person able to work 100% on the design system. Since the beginning, we have tried to use Slack as much as is possible to make it easy for anyone to give feedback and fill the gap of not being able to share time together.
When we all met together at the beginning of November last year, there was a zombie Firefox style guide in the wild.
We wanted to learn from that failure. We spent time interviewing anyone who worked on that project. What was the challenge? Why did the few things in the style guide feel so different from everything present in the product?
One main point of failure of the previous style guide was in the process taken by the team. Without a complete inventory, the team was documenting and improving at the same time, ending up with some excellent and delightful insights for future development but nothing truly actionable for the present or representative of the product.
Plus, the style-guide had a strong focus only on the desktop, ignoring the complex ecosystem where Firefox products live.
Photon: from a visual refresh to a visual language
“We started from the existing style guide, we checked if the identified macro areas were still valid, and we analyzed (or looked at) other existing design systems that were around for a while.”
Meanwhile, somewhere else in the organization, a group of people decided it was time to give all the cool improvements on the backend (a.k.a. Quantum) a nice visual refresh. The code name for this project was Photon.
That was the perfect opportunity for us. We started from there. All of the visual changes are expected to be in the product, overruling previous decisions. We had to start somewhere, so we started there.
Our first job was to understand all of the design decisions and be ready to raise our hands if some choices contradicted each other or did not meet accessibility standards. We made them aware of the other projects, products, constraints, and needs of other teams so that the team in charge of the visual refresh would have a more broad understanding of the design and development requirements.
While we were documenting, we ended up actively co-designing what eventually became a real design language that supported multiple platforms and multiple products.
Design for Scale
“The higher the expected visibility on parts of your work, the more important it is to align to Photon. If very limited visibility is expected, full alignment is of lower priority. Use platform components until you have time to align better.”
— Design for Scale, Photon Design System
We wanted to have documentation that combines theory and resources where theories are principles, visual guidelines, and patterns, and resources are everything from visual assets to tokens, from demos to templates, and from tools to code.
But how might we build a successful design language that also able to feel native in all the different platforms? Designing for scale is a challenging, delicate task. We wanted to support people going through this task and provide written content to help them understand this principle and apply it.
Feedback, feedback, feedback
“With every page, we added we learned, step by step — we learned how to structure pages, how to structure the whole system, and we learned how to align differences between individual design teams and how to get people to make decisions that can be structured and documented.”
While we’re building the design system, we never stop collecting feedback by everyone on the Firefox team. In the end, those people are our primary users.
We like to think of the design system as a tool, a tool which enables other people, designers and non-designers, to design. It saves time on digging into Sketch files, trying to find patterns from other designers, and fixing design issues like incoherency, accessibility across platforms, and localization.
During Mozilla’s June 2017 All Hands in San Francisco, we spent hours just talking with different product teams, asking for feedback. How are they using the system? How is the system relevant for them?
Photon Design System: today
First, we gave it a name: Photon — it just makes sense, right?
Three months ago, we had a lot of visual decisions documented on the website, and many of those decisions were already on the Nightly release, but the design of our site didn’t really seem to reflect any of it. So, we applied all the principles documented in the product. The Photon Design System website today reveals how we use it in the wild.
We are working on the components and patterns. Day to day, our job resembles a detective’s. We follow leads in all the products and identify the ones that can bring extra value to the Firefox team. Where we see complexity, we act to simplify.
We want everyone who builds for Firefox to use the design system in their everyday workflow. Using the design system should be not more than easy, it should feel natural. To accomplish that, we’re focusing not only on the content but also on building tools and resources.
For many, today is just another day. For the Photon Design System team, it’s when we see the system’s value realized.
A design system is not built overnight but shaped gradually through our daily practices. It evolves every day — or maybe every week — and most importantly, it’s never done.