The reality is often a bit more stark. However, building a design system, and then having it collapse, is both a costly and frustrating failure. How to avoid the most obvious pitfalls you can encounter on your journey towards a well-oiled, highly beneficial design system?
1. Get support from organisation early on
Does the organisation possess the time, the urge, and the resources needed for building the design system in the first place?
Many systems fall at the first hurdle simply because they rely on a single designer or developer doing the DS as a side gig, along with their regular product development job. The system is worked on only during idle hours – and will be stampeded when the first epic crunch happens. A single person's or a team's effort is a fine initial starting point for a DS, but very soon some buy-in and resourcing from the organisation is needed, if the project is to advance any further.
Individual endeavour only goes so far (we all have those unfinished hobby projects cluttering our workspace). Sure, getting support from the organization can sometimes be hard, especially if you have nothing to show for it yet. Try to get like-minded colleagues to join in on the effort and use every opportunity to highlight the benefits, especially if you can tie them into metrics that reflect the organization's objectives and business KPIs. That way you're speaking a language that even not so technically-minded people understand. They'll want to be convinced that there will be a return for the investment!
2. You need a Product Owner
The faster you appoint a PO for your design system, the faster you break out from the single product enclosure and start thinking the design system as an organisational entity – a way of doing things, rather than a singular rulebook. This "leveling up" is built on communicating with a lot of different individuals and reaching out to people. The responsibilites of a DS PO (sounds a bit like Star Wars, doesn't it?) include mapping out the potential for growth in the organization, selling the idea of a design system to product teams and the management – in general, evangelizing the whole notion and its obvious benefits. Ideally, this happens when the design system effort still has a strong momentum: active development is going on and new things are added daily.
A clear vision with the ability to seize the moment is the key to success. There are both external and internal design system product owners, but having one from the inside of an organization has its advantages. Since the PO needs to have an understanding of the organizational dynamics and the roles of people involved, it is beneficial to have in-house experience and a general grasp on how things are done around here. The PO has to know about the state of various product backlogs – when is the exact right time to pitch the design system to a team – and establish a mode of constant communication between the teams. This can take a significant amount of time, if you've just walked in the door.
3. Cultivate the design system culture
You need to reach a critical mass in design system adoption among the product teams for it to succeed. (Hint: forcing things won't probably work.) Especially if the design system is built into an existing ecosystem of multiple products, things are probably way out of sync right from the start – everybody has done things their own way. And getting people to jump on a bandwagon can sometimes be very tricky.
Designers, developers and product owners need to see the benefits of building and adopting a DS clearly and from their own viewpoint. Just as crucial is to recognize their roles in the system: are they potential customers, or contributors, or both? Naturally, there can be a lot of variances in readiness to adopt: some are the early birds, others follow suit a bit later. The important thing is to realize the needs and concerns of every type of user – many UX methods can be very helpful in this regard. Communicating the design system isn't something you do once, and then rest on your laurels, but an ongoing process that never really ends. Keep your ears open and be ready to spread the gospel on every elevator trip you take.
4. Adopt the architecture
Scaling a design system from a single product to an organisation-wide ecosystem can be very challenging, unless the DS matches with organisation's architecture. Deployments and communication become difficult – resulting in an inability to follow the DS definitions comprehensively. This is especially the case with technical implementation but rings true for design as well. If the brand-new shiny Figma design system library doesn't take the existing designs and ways of working into account in any way, it becomes too hard to implement and will essentially be abandoned, especially when you're in a hurry. Developing a well-functioning design system for an organization is a complex task, and every system is unique in its process, tooling and outcomes.
If the organization has established a fluid technical architecture between digital products, serving them from the perspective of the design system is a hugely different task than establishing a system in an environment with decades of technical legacy - and the future of design system has a large stake in architectural discussions. While there are tools to help adoption with diverse architectures (such as Design tokens), the more detailed bits and pieces tend to be more cumbersome and labor-intensive to be made available for each platform, so you may end up prioritizing more widely-used technologies early on. Besides incompatible technologies, organizational structure also plays a role: who is responsible of the DS development and its resourcing, can product teams input the process. In short, who's in charge of what. Because understanding the organizational structures is so critical, design systems that are developed from the outside rarely end up widely adopted.
5. Let's work together
Driving a design system forward successfully involves a lot of customer service. It's also about creating an atmosphere where contributions for the common good are valued. A centralized DS team is an ideal solution, because it does not only develop the actual system, but also encourages contributions from other teams and acts as a source of enlightenment, bringing about the idea that the DS in part of the organization and evolves concurrently with it.
Design system, while usually seen as something technical, is more of an organizational orchestration of solving the design problems in scale. That’s why when building a design system, while the outcomes may look like a technical solution, the process itself is a discovery journey of working together more efficiently, establishing a shared language and nudging the organization towards direction where a design system could live and thrive.
Written by:
Teemu Kumpulainen, Senior Product Designer at Siili
Tomi Sjöblom, Lead UX Engineer at Siili