A design system without a clear vision and shared ways of working is just a trash heap of forgotten components

Sharing design across development projects can save money and improve the user experience, but a mere component library is not enough. The term “design system” refers to not only a collection of building blocks but also ways of working together that have been established on the organization’s terms.

Many organizations develop multiple online services or applications for different stakeholders and target audiences. Meanwhile the user experience bar is continually rising due to increasing customer expectations. This creates pressure to produce high-quality solutions very quickly. At the same time, organizations have come to realize that high-quality design doesn’t scale simply by increasing the number of designers. Offering a solid user experience becomes more difficult as more services are created and as development teams grow. Over time, teams come up with varying solutions to the same problems. This increases complexity and service upkeep costs.

A great deal of organizations have, indeed, identified the need to share solutions and practices between projects and teams. A typical way of trying to ensure a consistent user experience is by creating a shared library of the service’s visual and functional basic elements, such as colors, fonts, form elements and navigation components. The aim is to save both costs and time by ensuring that teams don’t need to reinvent the wheel for every development project. Instead, teams leverage a common set of building blocks. A collection like this might be called a component library, or more fashionably, a design system.

Image of design system built on atomic thinking
Component libraries are often built on atomic thinking, where standardized basic elements are combined in different ways to create more complicated solutions.

 

Depending on the size of the organization, the cost savings created by a successful design system can be tens or hundreds of thousands of euros a year. However, many design systems lack the most important elements in terms of quality and success: Clear ownership, ways of working, and a clear vision for what kind of service development the design system actually serves.

The hobby of the few?

Perhaps a development team has a designer or a front-end developer who is enthusiastic about the systematization of design solutions. Maybe this eager team member volunteers to build and maintain a design system. Initially, things might look good. Over time however, this person becomes a massive bottleneck to insight and implementation. Development work slows down to a crawl.

It’s not enough to create a library of components if there isn’t a shared understanding of how those components work or why their design is the way it is. If only a handful of people in the organization have this understanding, the library components will rot as teams come up with new, alternative solutions that they do understand and have control over.

For a design system to be more than just a hobby of the few, it needs to be supported by standardized ways of sharing a common understanding between different roles in the organization. A design system should define how design is created and how it’s governed in the organization.

Usability of the design system itself should also be considered: if using the design system requires technical skills or tools that not everyone in the development organization has, it’s easier for many to keep working with their familiar tools and outdated working files.

The tail wagging the dog?

Of course, it’s essential that the design system is easy to use from the development team’s perspective, and that the library produces value for the design workflow. In order to make the sharing and systematization of design into an established way of working, service development needs to be easier using a design system than without it. Moreover, all organizations are different. Design management models that work in one organization aren’t suitable for all. It’s important to engage the design system’s internal and external user groups to identify the most relevant pain points that a design can resolve in the organization.

Perhaps the biggest danger with adopting a design system workflow is that solving new problems with existing components becomes more important than creating solutions that best support the business. If the creation of a new design solution is a bureaucratic and slow process, and the goal becomes slavishly minimizing the number of new solutions, the design system will turn on itself. The development organization might have problems seeing why they couldn’t, for example, reuse a web component library for a mobile app, even though customer insight would make the need for a use-case specific solution self-evident.

People don’t enjoy fighting against processes in their daily work. If improving the design system becomes a fight, customer needs and business objectives suffer. You’ll have ended up with an academic exercise instead of user experience improvement. In the worst case scenario, solutions that previously would have been suggested as new additions to the design system are made under the radar as one-off solutions that bypass the process. This increases costs and makes it more difficult to understand the big picture of the organization’s design.

A compact and elegant component library that minimizes overlap but is not developed or used by anyone isn’t valuable. A sprawling design system might not be optimal. But seamless adoption into the culture of making things is what counts.

In service of great design systems… or great services?

Even when a component library or design system is comprehensible and easy for everyone to use, it can be hard to see the wood for the trees. Designing individual parts in a vacuum without grasping the big picture produces visionless design. It might be enough to address a development ticket but it doesn’t move the business forwards.

When building component libraries, many organizations focus too much on individual pieces. What’s more important is demonstrating how those pieces can be made into efficient wholes that serve business needs. A component library should not offer a mere catalogue of components. What’s really needed is concrete examples of practical applications. And perhaps more importantly, a clear vision for why precisely the applications described work best from a service concept perspective.

Creating elegant components can’t be an end in itself, or the ultimate goal of service development. Harmony and efficiency should not be more important than serving customer goals and business objectives. A design system is ultimately just a tool enabling a good user experience and good service.

Recommended reading