What is a user-focused design system?

A design system is often presented in the form of styles, patterns, guidelines and principles. In this article Owen Lord, UX Designer, looks in more detail at what a design system is and how to build one.

What do we mean by a design system?

A design system can be used to bring a team together around a common visual language. Often presented in the form of styles, patterns, guidelines and principles, a design system is usually best placed digitally where stakeholders and practitioners can easily access and update it accordingly. Companies like Airbnb, Uber and Shopify have built large and often complex systems of components and patterns in order to help achieve a level of digital consistency.

As teams change and grow it is common for them to focus on a particular area; be it a website, product or app. This can lead to confused and fragmented visual language. With no shared approach that unites the visual language, the user experience and design process begins to fall apart.

A standardised, consistent set of styles and patterns allows us to create a predictable and ultimately more trustworthy experience. Standardised patterns also allow us to develop prototypes and iterate faster and more efficiently, freeing up designers and developers to focus on the core user experience.

How to build a user focused design system

As with the design of any product, when building a design system it is important to think about who the end user will be. Who will be using the design system and how will it form a part of their workflow? This research phase is key to producing a design system that solves the problems of individual practitioners, while addressing any particular strategic aims that the company has.

Research usually comes in the form of stakeholder interviews, but shadowing practitioners to discover their current workflow can be useful as well. When conducting interviews it is important to consider asking:

• What problems are we trying to solve with the style guide?
• What would a style guide enable us to achieve?
• What information do we need and how would it best be presented?

By probing around the problems and frustrations that practitioners find in their day-to-day, we can help offer up solutions that improve workflow and mitigate these frustrations.

Conducting a Visual Audit

Visual audits can be carried out in a multitude of ways. The job can be quite daunting, but it’s really just a case of looking at what you have and being a little pragmatic about different styles and approaches to component patterns.

Governance and Principles:

• How is the team going to work moving forward?
• Federated vs centralised
• Principles based on stakeholder interviews
• Knowledge sharing articles

One of the major risks to the lifespan of any design system is neglect. In order to try and mitigate this risk it is important for us to develop an environment of governance to ensure that the design system is being appropriately implemented and consistently updated.

Broadly speaking, there are two options for governance:

Centralised model:

This works by having a single practitioner “dictator”, or group of practitioners, who form a governance team. Should a new requirement for the design system come in, for example a new update to the functionality of a particular component, it is the job of this team to see that that component follows the appropriate standards for accessibility and overall design.

De-Centralised model:

The de-centralised model works by having a cross-disciplinary governance team consisting of product owners, designers, developers and brand guardians. They are all responsible for enabling teams access to the design system, in addition to ensuring that they understand its value. The de-centralised team should schedule regular meetings in order to openly discuss new requirements and improvements to existing elements, such as brand or design patterns.

It is important to remember that there is no immediate right or wrong governance model; organisations will need to feel their way to whichever type of model works best for them. So long as there is a point of contact or multiple contacts for practitioners and people using the design system to chat and make suggestions for improvements, then that is the most useful.

Once final UI patterns and styles have been established and gathered into a single repository – whether it’s a Sketch design kit or library – it is important to consider how the content hierarchy of the populated pages can meet the needs of the end user. From previously conducted stakeholder interviews, we should have a good idea of what information is important to particular groups of users. From this we can establish an appropriate content hierarchy. The content hierarchy is important because it keeps the pages consistent, a suggested hierarchy might be:

• Introduction
• How the component works
• How the component is made
• Rules
• Accessibility
• Resources/downloads

While writing component guidelines, it’s worth considering if you require copywriters up front or would rather write copy and then allow content authors to check for tone of voice etc. Consider also how you might be able to utilise code snippets and whether to not they would prove useful to developers.

It’s important to use a human-centric approach when developing a design system. This article helps to form a brief introduction into how you might consider building one.

Think of who will be using your design system and how information will be presented. Conduct interviews with practitioners to discover their frustrations, and work out how principles and standards can help address them.