When asked in the past how to start a new design system, my response has usuallybeen some variation on “start anywhere”: the point being that if you’re at anorganisation large enough to merit an official design system, there’s likelydozens of patterns already in use by your teams that simply need better guidanceand documentation.
As I’ve worked on and observed design systems evolve over the last 8 years of mywork, I’ve been able to see this tactic for starting design systems succeed timeand time again, but I’ve also been able to see more general phases of life fordesign systems.
Design systems can be an intimidating undertaking: how can we create somethingthat is robust and supports so many different needs? I’m here to tell you thatthe path you’re on is years long, but well worth it. Broadly speaking, yourdesign system will undergo three phases of life: reflection, anticipation, andinfluence. It’s futile to try and rearrange these phases or skip the initialones, and each comes with its own benefits.
Reflection
The primary goal of a fledgling design system is to reflect the world in whichit exists, acting as a mirror or map of the product it serves. This metaphor isuseful for a handful of reasons.
First, it sets an achievable goal for the first components and patterns in thesystem. You’re not trying to do anything more complicated than simply reflectingthe components and patterns that people intuitively already know exist.
Second, it humbles your ambitions: the map is not the territory. Designsystems can inspire new directions and design sensibilities, but you’re a longway from doing this. First comes the work of building a reputation as a reliablesource of authority, and that comes by first reflecting the world as it is.
Third, it leaves room for change. Maps are constantly updated based on changesto the landscapes or municipalities they represent. You need to get comfortablewith the notion that the design system is always eventually wrong. Listen tothe needs of the teams you support, help them get to good results faster, and beprepared to be proven wrong.
The other important thing to remember is that in the minds of your customers—andthe teams within your organisation—the design system already exists. It’swhatever the product is made up of, regardless of whether there’s a teamactually trying to make it more cohesive or consistent. Reflect this existingworld, reducing redundancies and simplifying complexity, and you’ll have adesign system in no time.
Anticipation
After a while, the design system will accurately reflect the best parts of theproduct. Documentation becomes more robust, and your team better understands whycertain components and patterns are the way they are. Once your design systemreaches this point, you can begin to be able to anticipate the emerging needsof the teams you support.
This might happen because you start to hear the same kinds of feedback about thedesign system from different teams, or you might see teams naturally gravitatingtowards new design styles or interaction patterns. However it happens, you canstart to use the good credit you’ve established as a reliable source of truth tobring those teams together and co-create solutions.
This makes reflection—the core responsibility of a component library—easier,since you’re in the room as product design solutions are being developed. Youcan challenge any solutions with the same kinds of questions of scale that youhave to ask when adding new components to the library.
Anticipation takes practice, and a useful tool for any design systemrepresentative to employ in their daily practice is theReference Interview. FromWikipedia:
A reference interview is a conversation between a librarian and a libraryuser, usually at a reference desk, in which the librarian responds to theuser’s initial explanation of his or her information need by first attemptingto clarify that need and then by directing the user to appropriate informationresources.
In that same Wikipedia article is a fantastic summary of a Librarian’s role1(emphasis mine): “Our core skills are the skills and competencies required toimprove the quality of the question.”
I see the responsibility of design systems representatives in much the same way:helping other product teams more deeply understand the problems they’re tryingto solve at scale—improving the quality of the questions they ask.
Influence
After successfully anticipating the needs of teams you support and working withthem to extend the design system, you begin to take on more of a role ofinfluence in the organisation.
I almost called this phase “Innovation”, since there’s a lot of it at thislevel. You might be innovating new design and interaction patterns, or exploringtechnical advances to set new standards for how components get built.
But innovation is only successful if it persuades bigger change—if itinfluences people around it to shift their thinking.
All the good credit and reputation you’ve been accruing through reflecting theproduct and anticipating the needs of others is exercised here. On Meta’s Adsand Business Design Systems team, we had a snappy mission: “Make every designera systems designer”. This spoke directly to the kind of behavioural shift we sawas the end-goal of our work.
Because the design system is always eventually wrong, how do we scale ourselves?By helping others develop and use the same mental tools we use to audit,reflect, and evolve a design system. All the artefacts you develop for a designsystem—components, patterns, documentation, APIs, quality enforcement tools—areproxies for ways of thinking about product design and development at scale. Bybeing transparent about your process for developing a system, you help othersdevelop the same ways of thinking, and begin to think about more lateralshifts—such as big rebrands, or tech stack changes—in similar terms.
In my experience so far, Influence is the peak of design system maturity, andrepresents a design system that is federated across the organisation in such away that all product teams feel empowered to shift the system to meet emergentproblems. Even so, it’s crucial for design systems teams to remain nimble andmindful of the fact that the system is always eventually wrong. Your first jobas a service team is to be responsive to the needs of the organisation: even ifit means redrawing the map.
