Three Phases of Life for Design Systems

When asked in the past how to start a new design system, my response has usually been some variation on “start anywhere”: the point being that if you’re at an organisation large enough to merit an official design system, there’s likely dozens of patterns already in use by your teams that simply need better guidance and documentation.

As I’ve worked on and observed design systems evolve over the last 8 years of my work, I’ve been able to see this tactic for starting design systems succeed time and time again, but I’ve also been able to see more general phases of life for design systems.

Design systems can be an intimidating undertaking: how can we create something that is robust and supports so many different needs? I’m here to tell you that the path you’re on is years long, but well worth it. Broadly speaking, your design system will undergo three phases of life: reflection, anticipation, and influence. It’s futile to try and rearrange these phases or skip the initial ones, and each comes with its own benefits.

Reflection

The primary goal of a fledgling design system is to reflect the world in which it exists, acting as a mirror or map of the product it serves. This metaphor is useful for a handful of reasons.

First, it sets an achievable goal for the first components and patterns in the system. You’re not trying to do anything more complicated than simply reflecting the components and patterns that people intuitively already know exist.

Second, it humbles your ambitions: the map is not the territory. Design systems can inspire new directions and design sensibilities, but you’re a long way from doing this. First comes the work of building a reputation as a reliable source 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 changes to the landscapes or municipalities they represent. You need to get comfortable with the notion that the design system is always eventually wrong. Listen to the needs of the teams you support, help them get to good results faster, and be prepared to be proven wrong.

The other important thing to remember is that in the minds of your customers—and the teams within your organisation—the design system already exists. It’s whatever the product is made up of, regardless of whether there’s a team actually trying to make it more cohesive or consistent. Reflect this existing world, reducing redundancies and simplifying complexity, and you’ll have a design system in no time.

Anticipation

After a while, the design system will accurately reflect the best parts of the product. Documentation becomes more robust, and your team better understands why certain components and patterns are the way they are. Once your design system reaches this point, you can begin to be able to anticipate the emerging needs of the teams you support.

This might happen because you start to hear the same kinds of feedback about the design system from different teams, or you might see teams naturally gravitating towards new design styles or interaction patterns. However it happens, you can start to use the good credit you’ve established as a reliable source of truth to bring 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. You can challenge any solutions with the same kinds of questions of scale that you have to ask when adding new components to the library.

Anticipation takes practice, and a useful tool for any design system representative to employ in their daily practice is the Reference Interview. From Wikipedia:

A reference interview is a conversation between a librarian and a library user, usually at a reference desk, in which the librarian responds to the user’s initial explanation of his or her information need by first attempting to clarify that need and then by directing the user to appropriate information resources.

In that same Wikipedia article is a fantastic summary of a Librarian’s role¹ (emphasis mine): “Our core skills are the skills and competencies required to improve 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 trying to solve at scale—improving the quality of the questions they ask.

Influence

After successfully anticipating the needs of teams you support and working with them to extend the design system, you begin to take on more of a role of influence in the organisation.

I almost called this phase “Innovation”, since there’s a lot of it at this level. You might be innovating new design and interaction patterns, or exploring technical advances to set new standards for how components get built.

But innovation is only successful if it persuades bigger change—if it influences people around it to shift their thinking.

All the good credit and reputation you’ve been accruing through reflecting the product and anticipating the needs of others is exercised here. On Meta’s Ads and Business Design Systems team, we had a snappy mission: “Make every designer a systems designer”. This spoke directly to the kind of behavioural shift we saw as 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 design system—components, patterns, documentation, APIs, quality enforcement tools—are proxies for ways of thinking about product design and development at scale. By being transparent about your process for developing a system, you help others develop the same ways of thinking, and begin to think about more lateral shifts—such as big rebrands, or tech stack changes—in similar terms.

In my experience so far, Influence is the peak of design system maturity, and represents a design system that is federated across the organisation in such a way that all product teams feel empowered to shift the system to meet emergent problems. Even so, it’s crucial for design systems teams to remain nimble and mindful of the fact that the system is always eventually wrong. Your first job as a service team is to be responsive to the needs of the organisation: even if it means redrawing the map.