Many organisations 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, organisations have come to realise 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 organisations 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.
Component libraries are often built on atomic thinking, where standardised basic elements are combined in different ways to create more complicated solutions.
Depending on the size of the organisation, 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 systematisation 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 organisation 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 standardised ways of sharing a common understanding between different roles in the organisation. A design system should define how design is created and how it’s governed in the organisation.
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 organisation 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 systematisation of design into an established way of working, service development needs to be easier using a design system than without it. Moreover, all organisations are different. Design management models that work in one organisation 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 organisation.
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 minimising the number of new solutions, the design system will turn on itself. The development organisation 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 organisation’s design.
A compact and elegant component library that minimises 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 organisations 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
- Atomic Design, an e-book by Brad Frost
- A comprehensive guide to design systems, Will Fanguy, InVision
- The Salesforce Team Model for Scaling a Design System, Jina Bolton
- Measuring Design System Success, Nathan Curtis