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?

A design system success is not connected with the launch of style-guide or a UI-kit. The real success happens when your design system is adopted in your products.

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

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

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?