Target state vs. adoption of a design system
Like with any product, it’s the audience’s success and growth that define success of what you’re building.
Over the past two years, I’ve thought about the moment when I’d be able to tell that, yes, we did it, the design system is successful now. This moment never came, but what I’ve learned is to think simple and approach things without putting a lot of expectations in front of people who are involved in making them work. Part of that realization was finding a reasonable way to define success of a design system at different stages of its growth.
It started with defining a target state of the design system, basically a structured wish list, in an attempt to describe what a really good design system is, — because, hey, always be planning. Defining the target state helped define a few other important artifacts, such as tasks and roles on the team, job descriptions, and even a year-long strategic plan. But it also led me, over time, to believe that the more refined the strategic plan is, the more effort, in fact, it takes to change it.
Working on an early-stage design system really does force you to think on your feet, especially if you’re a manager and need to make sure that all the people on the team have a challenging but fulfilling work ahead of them. Even the most opportunistic and resilient people need clarity on what they’re doing and what’s next. So having a plan helps, but then the reality steps in.
Contrary to the long-term bet, at least for my team and me, no amount of perfectly thought-through plan helped overcome one very simple obstacle: the consumers of the design system, designers and engineers in the org, needed results right now, not in a few years. They wanted to get their job done, they wanted to take the least expensive route, and they really wanted to prefer (and rightfully so) to use the design system and UI library to get their job done.
The more teams used the design system and library of UI components, the more feedback they provided. The more feedback, the more we corrected our course. As a side-quest, I went on to learn from and with the team how to architect a UI library (see note about it).
Curiously, the more feedback we got, the less relevant the target state was. We went full on product-led.
Target state is engineering brain, adoption is product brain. If people are satisfied, why not give them more of that? And that’s how, I came to realize, every early-stage design system should operate: assume nothing, know nothing, rapidly iterate towards a state that fits best. It makes sense to turn up the volume on the engineering side of the brain, gradually, as the design system gains strong presence in the organization and audience of consumers and contributors.
So, to summarize, for an early-stage design system, it makes sense to push for adoption and getting people to use it more and more frequently, despite it being incomplete and/or imperfect. For later-stage design systems, however, it’s going to get more and more important to have a stance, to have a vision, to communicate this vision to the teams, and to make it a priority for the team to work towards that vision.
This is something like a linear spectrum, and it takes a few “jumps” before you really find the best spot on this spectrum. Don’t be surprised if you and your team completely redefine success a few times over the first couple months of the design system team’s existence (or, in fact, of any team’s existence), — this sort of self-discovery is a healthy part of the process.