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


New call-to-action

Building blocks of business design

For us, business design is a hybrid approach of two disciplines: top-level management consulting blended together with design tools and thinking. We work on similar issues as any business developer or strategy consultant and do not limit ourselves to strict project types.

Business design is a practice that is only finding its place among its more established peers. Traditional business consultancies that rely on the shoulders of scientific management and hypothesis-based thinking have been around since the 1920s. Similarly the traces of design thinking can be followed to as early as 1960s and cooperative design in Scandinavia.

What then, is business design? We follow David Schmidt’s thoughts and see that business design at its core is the science and art of creating and validating business models. However, we’re not content with that. This definition works in design context when a business designer is complemented with other designers and experts, but we look at business design work within a broader scope.

For us, business design is a hybrid approach from the aforementioned two disciplines: top-level management consulting blended together with design tools and thinking. We work on similar issues as any business developer or strategy consultant and do not limit ourselves to strict project types.

To make this more concrete, we have put together building blocks for successful business design. These are theses that we as business designers believe in and stand for:

Ways of thinking

1. Strategy as actions

First and foremost, to have a major impact business designers need to live and breathe strategy. Simultaneously – as designers – we are doers and see that any strategy has to be realised through concrete actions. Design tradition arms us with tools such as co-creation and experiments to complement conceptual thinking.

2. Understanding change, focus on defense or offense

We look to understand what is changing, and only then decide whether it is time to strengthen the core business or to frantically build new. The increasing speed of change is just another buzzword, if we don’t seek to understand how it really impacts business.

3. Sustainability as core business

We strive to have a real impact in all we do, and marketing stunts – especially when it comes to being sustainable – are not our kind of business. We believe time is ripe for business models that have a positive net impact

4. Holistic, systemic approach

In line with great traditions of design thinking, we scratch deep below the surface; we want to understand the underlying implications and connections. Modern business problems are too large and complex for a single organisation to tackle. Ecosystem views and network models are our day-to-day methods of analysis.

Ways of working

5. Not solution-driven, but problem-driven

We don’t believe in best practices or ready-made solutions, but aim to uncover and understand the problem or issue at hand and only then we take a look outwards: can we get inspiration from some other case or business? We explore what’s possible together with our colleagues from a wide range of disciplines

6. Scalability of everything

There is a growing fear that transformational endeavours don’t scale, create new business or even business value. As business designers we need not only to strive to build scalable services and business models, but also to make business development and implementation scalable.

7. Sustainable business models instead of one-off wins

Buzzwords are not good business. We desire to build business models and services that are lasting and large enough to matter. We investigate and prioritise actions by evaluating business impact in order to make value tangible and support decision making. 

8. Fighting biases and intuitions through being truly customer and data-driven

Leadership and their organisations – even us designers – typically  have ‘proven’ truths or conventions that guide their thinking and actions. We want to challenge this with data-driven insights and decision making, using experimentation and analytics to feed and validate.


Sometimes we win the lottery. Profitable businesses don’t emerge by accident. Designing them increases the odds significantly.

Our mission is to help you make things happen.

During the coming months we’ll continue sharing our thoughts through a mini blog-series. Feel free to comment, challenge our thinking and have an open discussion with us.

New call-to-action