What we don’t talk about when we talk about design systems
Moving the conversation beyond how-to’s
Ever since the conception of atomic design by Brad Frost in 2013, design systems have become a first-class citizen in the design community, given the considerable advantages these resources provide for teams to ship better products faster.
However, the vast majority of articles and stories underscoring design systems revolve around the implementation aspect:
- How to use design tools such as sketch or figma to build design systems
- How to create, label, and organize components
- What to consider when choosing colors, icons, typefaces
- Differences between design systems, style guides, and brand books
Although this pool of knowledge empower designers to improve the quality of the output, the amount of information is so much that it does not leave room for other important design system matters, such as:
- How can we get stakeholder buy-in and support to invest in design systems?
- How can we connect the dots between the company objectives and the system?
- When it does not make sense to leverage a design system?
- What other systems we need to implement in addition to design systems in order to be successful?
Why are these questions not explored at length in the design community? My argument: they are not that interesting/visually appealing, and more importantly, they are not monetizable.
I can sell you a design system manager so you can organize your components, or a UI kit you can use for inspiration, but I cannot sell you a way for you to convince your stakeholders to invest in design systems. That is harder, and that is precisely why we need to build more collective knowledge around it.
In an attempt to contribute to such collective knowledge, following is a synthesis of my research and experience around the topics we don’t talk about (enough) when we talk about design systems.
Start with a purpose, not an inventory
One of the main questions designers ask themselves and their teams when working on design systems is: where do we start?
Answers might gravitate towards conducting UI inventories, doing research of different touchpoints, or even translating the brand book into style guides.
To yield better results, the first step is starting with a strong purpose and principles — the foundations––, which the design system will be build upon.
In her book Expressive Design Systems, Yesenia Perez-Cruz writes:
In order to create products that feel cohesive, you need to align teams around a shared definition of how your brand should look, feel, and behave. That’s why it’s important to set a purpose and establish principles.
There are several ways you can ground your team into a purpose and principles. You can define goals of the design system through Simon Sinek’s golden circle, or you can run a principles workshop. What is important is to answer fundamental questions such as:
- What are the underlying reasons we are building a design system?
- Why are those reasons important for the organization?
- How will we measure success?
By bringing shared understanding over the design system’s goals, the team will be able to better navigate the most difficult conversations: gaining the confidence of the stakeholders and decision makers.
Managing up. Getting stakeholders buy-in
Building a design system is not a set-and-forget type of endeavor; in fact, it should be a living product that is constantly maintained and updated by product teams. This means that, ideally, you should allocate a significant percentage of time during sprints to work on the system. Product managers and executives might have a hard time grasping this at the beginning: what do you mean by not being able to work on the features?
To ease such conversations it comes handy to showcase the value of design systems upfront to the decision makers, and to do so you need to understand their motivations, fears, and anxieties. In other words, it is a selling process.
In his stellar article “Selling a Design System at your company” Nick Stamas states:
Sell a vision that everyone can buy in to. Selling is a process, probably more than a single meeting. Look for teaching moments. Use your storytelling skills. Show your team that a better way is possible.
To better sell design system’s value, you will likely need to adapt your narrative to the different audiences, focusing on what is important for every area: consistency and brand alignment for designers, efficiency for developers, time-to-market for product managers, to mention a few.
A design system should not be the only system
In her talk Organization as Designed System, Kim Goodwin poses a strong question: how do we know a design system is the best investment?
At the end of the day, design systems are meant to help teams make better decisions. The types of decisions are mostly about the user interface, which is an important layer of the user experience, but not the only one.
It does not matter if you have a design system in place but your company is struggling with being human-centered, prioritizing features, or undermining the user experience because of a poorly designed business model.
The impact of the decisions based on the design system will be rendered obsolete in comparison to the other issues your company is facing.
What Kim Goodwin proposes in her talk is enabling a decision system, which allows not only designers and developers to make better decisions, but the whole organization.
The main takeaway: the next time you find yourself excited about the idea of starting a design system, first ask yourself:
- How do I know a design system, considering the amount of effort it takes, is what my company needs most?
- What decisions are the most important my company should be better at, and what type of system could improve them?
Final Thoughts
This essay is not comprehensive in the many overlooked conversations the design community is not having about design systems. In addition, my intention is not to discredit the designers and writers who’re putting great effort and enthusiasm in sharing about the implementation aspect of design systems. However, I do believe we need to find a healthier balance in the information we share, so we not only benefit from the community about how to design systems, but why building them in the first place.
Special thanks to Tanner Christensen for inspiring me with his article What we don’t talk about when we talk about design tools, as well as Fabricio Teixeira, Caio Braga, and the UX Collective community to move the design systems conversation forward.
