Design systems result in tangible, often gorgeous outputs like a living style guide or array of design assets. When getting started, it feels like a project, evolving from early concepts to a celebrated (first) release of those assets for other people to use.
<div class="escom-pull-quote escom-pull-quote--light"> <div class="escom-pull-quote__the-quote"> “We did it! We launched a guide. Mission accomplished.” </div> </div>
Celebration is justified, no doubt. You did achieve something, and making useful things for others feels great. However, be careful, because you’ve not yet realized actual business value. An enterprise realizes that value — actual cohesive experiences, realized efficiencies in development — when other teams pick up the system and ship it in their product.
<div class="escom-pull-quote escom-pull-quote--light"> <div class="escom-pull-quote__the-quote"> A design system’s value is realized when products ship features using parts from the system. </div> </div>
In those quieting days following a system launch, a systems team starts to realize “What do we do now?” Worse, they (and those managing their time) think “Now we can go back to doing what we were doing before.” There’s no funded persistence. No ongoing commitment. Questions of “Will it last?” start to emerge in thoughts and conversations.
Focusing on style guide delivery as the climax is the wrong story to tell. A system isn’t a project with an end, it’s the origin story of a living and evolving product that’ll serve other products.
A style guide is an artifact of design process. A design system is a living, funded product with a roadmap & backlog, serving an ecosystem.— Nathan Curtis (@nathanacurtis) October 21, 2015
Thinking as a product changes perspective: it’s now not about us, it’s about serving our customers. How do we do that? Applying well-established approaches for product management and product marketing is a great start. Once recognized, a system team can adopt familiar and predictable tools and terminology to help them succeed.
Additionally, the “system=product” model also helps team composed of product designers and developers to recognize:
<div class="escom-pull-quote escom-pull-quote--light"> <div class="escom-pull-quote__the-quote"> Design systems isn’t just product design and development. There’s product management and marketing too. We’re not good at that, nor do we want to be. </div> </div>
They may lack the talent for “product management stuff” and may not have the taste for it. Now self aware, they can choose to learn and apply such skills to fill the gap or find someone else who can.
When I meet a design system team for the first time, I don’t start with “Can you show me your awesome living style guide?” It is awesome, they are very proud of it, and I love learning about it. But such demos rest in the shadow of a more essential understanding of their system’s – their PRODUCT’s – marketing and management approach.
To have a product means knowing and serving your market:
Imagine what your VP thinks:
<div class="escom-pull-quote escom-pull-quote--light"> <div class="escom-pull-quote__the-quote"> Should I fund 2.5 full time resources to work on a style guide full time if they can’t tell me what they’ll do in the next three months? They can barely muster a coherent definition of what they’ll do in the next two weeks. It seems everyone is doing everything and nobody is responsible for anything. </div> </div>
For a design system to thrive and survive, it needs a sufficient level of management.
Enterprises are waking up to this, forming permanent positions, with titles at Salesforce and hiring product managers specifically for systems teams at companies like Etsy and Google. If you don’t have thoughtful, reasoned answers for the questions above, how can you expect someone to fund your effort?
EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.