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.
Figma component architect and librarian
8 months from 0 to v1
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:
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:
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.
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:
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"
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.
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).
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.
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.
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:
