Multi-brand design system

The gist

Lots of folks doubted we could build this and maintain the spirit of each brand's visual design language. We proved them wrong. We showed them a design system is about making big ass workflow gains, all with no compromises to brand integrity.

Especially proud of
  • Our response time
  • Component quality
  • Rapport and trust with engineering
My role

Figma component architect and librarian

Speed

8 months from 0 to v1

How it came together

The business had its “oh crap, everyone’s reinventing the wheel” realization moment. I partnered up with a lead engineer, John Benavides, to create a 100+ component library that would serve 4 brands.

John and I were really concerned about designers perceptions of the project, so we tried to get them deeply involved early. Really early. Like, before John and I had processes for efficient execution figured out. The designers, understandably, did not love this.

We went back to the drawing board. We figured out our build process and how we'd prioritize the order of execution. After a few rounds of tweaking our workflow, we arrived at a solid process that got us to v1. Now we’re maintaining and enhancing it, and with more experience we're better positioned to get consumers more engaged than ever before.

Rather than tell you every step in the process, I'll outline some takes I developed that I'd likely apply to future systems:

We should not expect component libraries to contain every component designers need.

Nathan Curtis would agree with me.

It’s just not realistic. The system and its stewards (who are often, and ought to be, outnumbered by the number of consumers) cannot be responsible for predicting the future.

The most fundamental parts should be available. For us that was about 26 individual pieces of interface:

Foundational components from the multi brand library in the brand theme of "Capterra"
  1. Accordion
  2. Alert
  3. Avatar
  4. Badge
  5. Button
  6. Card
  7. Dropdown
  8. Focus ring (in Figma this should be a component, not a drop shadow Style)
  9. Text input
  10. Text area
  11. Checkbox
  12. Radio
  13. Toggle
  14. Select
  15. Link
  16. List - unordered
  17. List - ordered
  18. List - undecorated
  19. Form element (this introduced things like<span class="inline-code">label</span> and <span class="inline-code">validation message</span> to the <span class="inline-code">inputs</span> from earlier)
  20. Modal
  21. Progress bar
  22. Horizontal rule
  23. Loading spinner
  24. Tab
  25. Tag
  26. Tooltip

In atomic design terms, the majority of these might be considered “atoms” or small molecules. And for our 4 products, these 26 elements were not only present but used in the same ways. That met our criteria for housing in our multi-brand library.

Anything larger or more complex (like a <span class="figma-component">❖ Global navigation</span>, or <span class="figma-component">❖ Card</span> with tons of metadata) was deemed out of scope and it was destined for a brand-specific library.

But even then, our system of libraries won't have everything. Designers will always be coming up with new components in their local files. My job was to watch out for these to understand how they'd be used and if/when they'd be ready to graduate into our library ecosystem.

Besides, there's an "escape hatch." You might know them as "slots", I prefer to call them placeholders. More on this in a point below about optimizing for composition over configuration.

Designers should be encouraged to override freely.

Part of a designers job is to push the product forward. One way they achieve that is by tweaking and adjusting our components to fit their vision of a better experience. The overrides Figma allows generally cover this pretty well, but not always. Some overrides we're missing are:

  • Auto layout direction
  • Absolute VS relative positioning of nested elements

Again, just like with new components, my job on the DS team is to keep an eye out for these and understand if/when they should be absorbed into our main components. Generally, the criteria I look for is "is this a sensible default for the majority consumers"

Status emojis in page names are a bad idea.

I wrote a blog post about this. Status-emojis in component library page names fuck up your publication panel... ask me how I know haha.

Image
Bike fall meme communicating that status emojis on component library page names are a bad idea.

This happens because Pages in Figma act as "folders" for components. When you change the Page name, it counts as a modification to the component.

Figma ain’t a project management tool. We’re already tracking work in Jira or somewhere. I'm sympathetic to designers wanting to not context switch, but I believe there are better, more sustainable ways to achieve this (eg. plugins).

Composition over configuration.

I am very bullish on componentizing most nested elements. Doing unlocks massive flexibility for designers. Of course the default should suit them for most use cases, but being able to inject custom content lets them stay in the zone and explore new compositions while being hooked into the system (no need to detach).

This compliments the point above about "designers are expected to make overrides." It also protects us from variant explosion, trying to account for every possible circumstance under the sun. If you want more of my thoughts on placeholders, I wrote a blog post about them.

Override loss is unacceptable.

The number of times designers should inject content into any component is exactly once. Any more than that is a waste of their time.

I have a blog post that explains one of the signs that you're working with a high quality component is its construction. If it offers users protection from override loss on common swaps, it's good quality.

GIF showing override protection between all 4 brands' button components

What influenced the build order.

Honestly, at the start my engineer and I just picked buttons and jammed on those until they were done.

Following that were form elements, like <span class="figma-component">❖ text input</span>, <span class="figma-component">❖ Select</span>, and <span class="figma-component">❖ Text areas</span>. This was really just us getting our sea legs and testing our workflow for the first time.

But once we had a feel for our process we wanted to get more strategic. We used these to influence how we sorted the backlog:

  1. Consumer need. Luckily we had a legacy system with all the components on our build-list. We used that inserts from that library as a proxy for "need." The more inserts, the greater the need. I also would just ask designers what work they had coming up and if there was a component that was top-of-mind for them that they wanted a better version of from the new system.
  2. Atomic size. Smaller elements first. Bigger elements tend to need the small ones, so this factor felt pretty natural.

There's more to this story

🔒 But it's reserved for interviews 🔒

Invite me for an interview