In plain English a Design System is a library of styles, components and patterns that can be reused to build websites and services. Components are the reusable parts of the user interface such as a button, that have been made to support a variety of applications. Patterns are often made up of a combination of components and styles.
The GOV.UK Design System allows teams across government and the wider public sector to create services that are efficient, using accessible components and patterns. We are a user focused team that collaborates with our community to bring together research, design and development and make sure it’s representative and relevant for our users.
We provide users with guidance. This ranges from style guidance to ensure that websites look like GOV.UK, to much more detailed information about our components and patterns. We explain when each component and pattern should and shouldn’t be used, an explanation of how the component or pattern works, any research we have, including known issues or gaps, or accessibility failures and links for users to help us improve the content.
Overall we want to make it easy for service teams to:
Which will allow teams to spend time doing what they need to, such as tackling design challenges or working on content.
By creating consistency. By having an established Design System, it eradicates the need for duplication of work. Teams are able to spend time working on the issue rather than having to construct components and patterns from scratch.
By having a Design System, we do not run the risk of creating inconsistencies through interpretations of what a component or pattern should include or look like. Uniformity is key to helping create successful Design Systems. By doing these things you will make your Design System efficient.
Finally, you have the ability to make your Design System really functional. By providing snippets of code for prototyping and detailed guidance, you can give users with less technical experience the ability to prototype, allowing them to bring their vision into reality.
There can sometimes be an overreliance on Design Systems as rather than comprehending that service teams are best placed to understand the needs of their users and of the services they provide. Although patterns especially can be incredibly usual for designing a service, they are not prescriptive.
Service teams will have done specific user research to understand their users. They will have created personas that will help them to identify pain points within a service. They will be able to explain in detail as to why they have chosen to either include or exclude a component or pattern that may seem ideal based on these findings.
Go for quick wins first. Explain that having a Design System means that everything is in one place. This means only one set of documentation to maintain, one system to keep updated, reducing the number of time spent when making changes. It also reduces the risk of documentation being out of sync with each other.
Explain that having a Design System usually makes it easier to build websites and services. Within the GOV.UK Design System, the styles, components and patterns are designed to be easy to use. They have also been tested to make sure that they are compliant with accessibility regulations, increasing inclusivity of all users, including those with disabilities.
Finally, explain that having a Design System is a time effective and cost saving measure. Less time is wasted on repeating the process of creating a component or pattern from scratch, meaning that this time can be used on the project.
Getting investment from senior management can be difficult. Often there will be internal politics at play that can be a driving force for or against the project. Even with those who are supporting the project, constraints such as technology, headcount and budget all need to be considered.
A Design System should not be made up of just one person, rather it should be a blend of people from user centred design disciplines. We cannot expect someone who is an expert in writing content to also be writing the code, as these are two very different, individual jobs. However, in smaller organisations we often find that a developer is given the task of cataloguing their components and patterns, which then ends up being called a Design System.
Design Systems are also living documents. Changes to accessibility regulations can require full scale reviews to ensure compliance. Additional user research findings or research can result in changes to the documentation or even the component or pattern itself. All of this requires dedication to a product, rather than a one and done approach. In smaller teams this can reduce the number of people who are able to work on other projects or business as usual. This living status can be off putting, and can be difficult to determine who should be responsible for it. The person or persons responsible also need to have the right level of access to technical products. For example, if a change to a page needs to be made, a person must be able to do this, or have a way of getting someone to do this.
It can also be difficult to get the correct balance between building and maintaining your Design System and shipping it. This can be made more difficult when you have a small service team and tight deadlines. Managing this balance can be a steep learning curve for even experienced teams, therefore it is important to make sure that you have buy-in from management. Having some ability to be flexible with deadlines and an understanding senior management team can go a long way to making sure your team does not experience poor performance due to stress.
A Design System team is not prescriptive and should be based on your organisation’s size, any goals you may have and how mature your Design System is. Some organisations may only be able to have one person dedicated to a Design System due to constraints they experience. However, most organisations aim to have at least a full time designer and a developer as a starting point.
Ideally you will want the following people in your Design System team, based on what I’ve worked with:
Designers - within GDS we currently have Interaction Designers working on the GOV.UK Design System, however there is crossover knowledge of service design as well.
Developers - these are the people who bring the ideas to life, taking designs and turning them into real working products.
User researcher - we have a user researcher working on the team who lends their expertise to help us make sure our components and patterns meet user needs.
Content Designer - we have an expert content writer and a technical writer who make sure our content is written in a way that can be understood by everyone.
Accessibility specialist - designing for people with accessible needs is something that needs to be baked in from the beginning of the process. By having an accessibility specialist on your team this becomes a lot easier.
Delivery manager - by having a specific person who is accountable for the performance of the team, you will find that overall day to day running of the team is smoother. It also gives you someone who can ‘fight your corner’.
Product manager - this is someone who takes overall responsibility for the product, in case, a Design System. They collaborate with the business and with all members of the team to ensure you have an excellent quality product.
Firstly, ask people why they don’t use the Design System and action the outcomes of their responses. You may need to provide people with an anonymous feedback mechanism for this so that they feel comfortable giving you genuine feedback. This is the best way to find out where the ‘faults’ are in your Design System, department or even organisation.
You need to make it easy for people to use it, which means reducing blockers wherever possible. Examples of this can include giving staff the software needed to develop the Design System such as a code editor. Outside of specific roles such as developers, it can be a real challenge to get use of this sort of software approved. There is sometimes a fear of giving someone access to something that gives them ‘freedom’. Advocating against this sort of siloing and control can break down these barriers.
You also need to help people to understand the Design System. All too often things are presented on a superficial level in an effort to tick a checkbox. It’s hard to get people to be interested in new things, especially if they aren’t going to be directly involved in the day-to-day use of it. Running sessions on what the Design System is and making the guidance easy to understand are two ways you can change this. By using plain English and providing examples that are relevant, people within your organisation can begin to contextualise the Design System, and thus it will feel less out of their world.
Having a defined purpose and shared values within your organisation. You need to know what you want your Design System to do and what your values are as a Design System team.
You need to make sure that you have clear, easy to understand documentation. Some organisations like to have a copy of this both internally and externally, however this gives you extra work to keep in sync. Consider having a front facing and developer facing environment and using tools such as Github which allow you to make an off location copy of your Design System.
Components, patterns and to some extent, styles are core to a Design System. These are the building bricks that allow a person to build a service or website using your specific code. These should be published as guidance, explaining their use cases and giving the user the opportunity to give feedback to you.
You also need to build a community around your Design System. The size of the community is irrelevant, they are the people who will provide you with feedback allowing you to iterate your designs. In the case of the GOV.UK Design System, our users help to shape our future work, by contributing to our backlog. Without this community we wouldn’t be fully representative of the latest research, design and development coming from across government.
Other designers, community members and the wider public sector. We know that the GOV.UK Design System is used by the private sector too. We have designed it to be open source so that anyone can use it.
Having a Design System makes teams more productive because they have out of the box components and patterns that they can reuse. They can onboard new team members much faster because they've got documented patterns and components and tools that can be used by said team members. Teams that are on the same system can also share their work much more easily, which reduces duplication of effort and encourages contribution and collaboration.
As a result the services themselves improve, they are easier to maintain due to the single unified codebase which they don’t have to be responsible for. They are often more accessible because there is a centralised team who do the extra work to make sure it meets accessibility regulations, rather than relying on individual service teams. They are more consistent due to the reusable nature of the components and patterns, and as a result they become more usable due to good practice being baked into the community.
Overall having a Design System is a cost and time saving measure, however it’s really difficult to workout the exact figures. Often in GDS we found that people gave us estimates of the amount of time or resource they felt they saved as a result of having a Design System. In terms of cost, in 2020 we made conservative estimates that the GOV.UK Design System saved the government over £17 million a year.
It depends. There’s no one-size-fits-all answer, but you want a Design System team to be very close to their users, the teams using the Design System.
It can be difficult to balance especially when the driving force can often be adding new things to your Design System. However you need to make sure that you keep your existing components and patterns updated. If you are fortunate enough to have multiple designers and developers, you can work on lots of smaller pieces of work to improve current components and patterns.
One suggestion is to work on the easy wins first, however this comes with risks, and will need to be made on a judgement call. Remember that iteration often comes from within your organisation or community suggestions. For us at GDS, new components and patterns come from a combination of community projects and commitments to senior management, however, we determine what we are working on.