Faire design system
Bringing a juvenile design system to maturity
Context
I got hired at Faire in 2022 as their first senior design system manager. My primary mandate was to grow the team and double its size, following the company’s growth plan. The previous year, they started to build a design system team of three designers and three developers, each including a lead. They needed some guidance to get passed their system’s infancy to a better place where they could support the hyper-growth of the product team.
When I joined, the team already had a few of the essential elements of a design system:
- A Figma library
- A documentation portal leveraging Zeroheight
- A coded component library (React)
- and a permanent team, as stated before
In my time there, I led the team around many initiatives, including:
- Rebranding the design system: we needed a more identifiable brand, as it was previously called Foundations, which was problematic because of its vagueness, and the term was used in different contexts across the company
- Introducing design tokens and implementing them with Style dictionary to support different themes and platforms
- Introducing the concept of sublibraries in Figma for the 2 primary pillars of the company: brands and retailers
- Implement reliable metrics to monitor progress and report back to leadership
- Improving the operations and communication of the team, leveraging Notion templates
- Advocating for the need for UX Engineering practice in the design organization and hiring their first accessibility specialist
Notable bits
Influence on the product designer ladder
In an organization of Faire’s size, mini-teams are often formed in triads between product, engineering, and design, with rarely more than one designer. That can draw blurry lines between the different levels of the product designer ladder. All the designers, independently of their levels, are essentially doing the same work with the same responsibilities.
We discovered that one way to differentiate the more senior designers in the organization was to integrate them into the design system contribution model, giving them more responsibilities in defining design language elements across their team’s pillar. It didn’t mean that we were discouraging contributions from more junior designers, but rather that it was expected of higher levels to actively participate in discussions impacting the entire team and gain a horizontal vision across the different groups.
Creating ladders for Platform designers and UX engineers
It appeared pretty quickly that in the design system team, we had 2 groups of designers: one was more focused on the tools available to our teammates and the execution of design artifacts (including creating and maintaining the Figma libraries). The other group focused on defining the design language and supporting the product teams in their needs and design decisions.
This second group was closer to the Product design ladder, but it felt inadequate to calibrate the first one with the same ladder. Hence the need to create a new ladder with those main differences:
- Platform knowledge: the ability to partner with developers, appreciate the technical specificities of each platform (Web, iOS, Android, etc.), and understand development and code.
- Design Tools expertise: the ability to fully utilize the possibilities of your design tools to the highest standards of execution and deliver work that simplifies your users’ workflow.
- Documentation and Education: the ability to formulate and explain the specifications of design elements and teach others.
For UX Engineers — and I’ve been one myself as well as a UX Engineer manager — I best describe it as a developer focused on front-front-end development (see The Great Divide by Chris Coyer) and who has some design foundations. Because I introduced the need for them at Faire, I also had to create a ladder that is differentiated from other front-end developers by:
- Expertise in UI front-end development domains: semantic HTML, CSS, presentational Javascript, accessibility, localization, motion, etc.
- Partner on component design lifecycle: the ability to partner with designers, appreciate design principles and patterns, and understand design processes.
- Cross-functional advocacy: the ability to define ways and methods to facilitate collaboration across disciplines and product areas.
Use of Notion to “run the business.”
It’s part of the company’s culture to use Notion.
At first, I was not a fan, mainly because it was almost always impossible to find the content I was looking for as an employee and a manager. The search feature is only somewhat effective in retrieving a page you’ve already seen, so you need to rely on an efficient information architecture to get what you want.
That said, Notion has proven to be a great ally in managing the operations of the team once I created:
- A view of our work, from OKRs to initiatives, down to tickets handled in Jira (for engineers and designers)
- A simple Customer Relationship Management tool to keep track of our numerous communications and give templates to follow to the team
- An Elements tracker to communicate transparently to our stakeholders the status of our different foundations and components across platforms
If you want to know more about this, I’ve written an extensive article on the topic.
Evolving the documentation framework
When I joined the company, the team used Zeroheight to publish their system documentation (and a proprietary Storybook-like tool for engineers). Although efficient, especially when you jumpstart your process, user research showed that it wasn’t consulted nor utilized enough.
A few limitations were problematic:
- Engineering and design documentation were siloed
- We were not using our design language or our component libraries on our own documentation portal
- Most importantly, we were not where our users were: going to a website to find the answer to your question can be disruptive and break your flow as an individual contributor
To remedy those problems, I pivoted the team to create a new documentation framework based on a headless Content Management System associated with other content sources, like our design tokens management system. Here are the main benefits:
- Simplify the message with a single identified URL for everybody and reinforce the notion of community and overlap.
- Surface the content in places other than a website by creating plugins or extensions for design tools like Figma or Integrated Development Environments like VS Code.
- Being able to optimize the experience for each individual while giving them the possibility to explore all the available content.
- Other teams could also easily leverage that framework to host their documentation content.
Adoption metrics strategy
I believe everybody can quickly understand the benefits of a design system on principle. But after a certain grace period, it’s necessary to build tools to monitor the progress and value of your design system and be able to report back to leadership. The challenging part resides in the difficulty — and potential cost — of answering simple questions like: “how much of our product is coming directly from our design system?” and “how much cost savings are we getting by using it?”
Adding this to Goodhart’s law that “when a measure becomes a target, it ceases to be a good measure.”, I think it’s more efficient to get a trend with a proxy of a couple of metrics:
- The percentage of your coverage per platform against an ideal state where you’re meeting all of your product teams’ requests. This metric will probably never be at 100% because there will always be the need for something new or an update, and you need to educate your stakeholders about it.
- The percentage of components currently in your product that should be superseded by one coming from your component library.
The second metric is an interesting one to consider, especially its technical feasibility. Although more and more solutions are now rising in the design system space, like Omlet.dev, we had to come up with our solution at the time. We decided to add meta tags in our various codebases to start tracking the potential obsolete components and where they were still used.
It resulted in a dashboard where we could see the following:
- The adoption for each component as well as the entire library
- The number of individual UI components, and the number of their instances, that should be superseded
- Which teams or sections of the application were falling behind
That said, the main caveats were:
- It’s a tedious manual but necessary work to cruise your different codebases to track down all UI components. In our case, not all React components are UI elements. Therefore it was deemed impossible to automate the task.
- You need to re-audit your codebases regularly to see if there aren’t new components that you need to add to your list. Otherwise, if you allow me this Jurassic Park analogy, you might end up with more dinosaurs than you accounted for.
Outcomes
In the end, and after a bit over a year, the Faire design system, which is now named Slate with a brilliant rebranding, has now all the necessary parts for a successful mature design system:
- On the design side, several Figma libraries and sub-libraries are optimized for the different organization’s pillars
- A robust architecture of design tokens that will be able to evolve and support new themes and markets
- A nascent documentation framework that will be able to support its users where they are and in different ways
- A complete suite of metrics monitoring the health of the design system
- Operational tools to keep track of the projects and communication strategy for the team
- A recently launched new contribution model to follow the rapid scale of the product team’s needs
