{"id":21080,"date":"2021-03-17T13:25:29","date_gmt":"2021-03-17T13:25:29","guid":{"rendered":"https:\/\/shopjessicabuckley.com\/blog\/?p=21080"},"modified":"2021-03-17T13:35:20","modified_gmt":"2021-03-17T13:35:20","slug":"maintaining-your-design-system-for-success","status":"publish","type":"post","link":"https:\/\/shopjessicabuckley.com\/blog\/maintaining-your-design-system-for-success\/","title":{"rendered":"Maintaining your design system for success"},"content":{"rendered":"

In this second article in our series on design systems<\/a>, we\u2019re looking at the different ways that teams can develop their own design system. We\u2019ll explore how to go about understanding the pain points, defining the aspirations, then getting buy-in and finally maintaining the design system. We will also explore why starting a design system now will mean that you are well placed for the future.<\/p>\n

A design system is not only a set of guidelines, libraries and a slick website of documentation. It is also important to focus on processes that address the problems people in your particular organisation face when designing at scale.<\/p>\n

Laying the groundwork<\/h2>\n

Running an audit of what your organisation already has<\/strong><\/h3>\n

The first stage of developing a design system is understanding the state of your products along with the people and processes that support them. If you started by replicating another design system, the list of what you would need to include could be endless and wouldn\u2019t be targeted at solving your organisation\u2019s problems. <\/p>\n

Review your products<\/strong><\/p>\n

Record as much of what you use in your product, the good, the bad and the ugly. Note down how frequently something like a particular button is used, what it looks like and how it behaves. It is also useful to record the context; ask yourself whether there are any common patterns of components being used together.<\/p>\n

You will probably notice inconsistencies as you audit your products and it is natural to want to start fixing the problems you see. Remind yourself that you are still in the research phase and that it is better to work on a solution once you have a full view.<\/p>\n

Understand your existing processes<\/strong><\/p>\n

Run sessions with your design function and anyone who works closely with them to work out the main pain points in their workflow. Approach this stage as though you are a user researcher. Ask lots of questions and watch how people do their work. <\/p>\n

Look for what goes wrong, what takes the most time and where there is the chance for errors to help you prioritise what will bring the most benefit. You might be surprised just how many ad-hoc processes your team have developed.<\/p>\n

Designers will make their own artefacts and documentation like libraries to make their work easier. Developers also create their own ways of working to help them interpret your designs, like reusable frontend libraries and test sheets.<\/p>\n

Without a shared design system, these stop-gap measures can create short-term efficiencies, but can be the cause of longer term issues. After speaking with your team and conducting your review, you will now have a clearer idea of the time spent on duplicated and disjointed work.<\/p>\n

Get buy-in before building your system<\/strong><\/p>\n

It is great to foster champions for your design system, but it can be even more important to get buy-in from those who resist it. The integrity of the design system will suffer if even a few people don't adopt and contribute to its evolution. This can lead those people initially onboard with the design system to no longer be able to rely on it as a source of truth.<\/p>\n

It is important that the dialogue starts during the review phase because when the team has been involved from the early stages, they will see their design system as a product of their discussions. It is also important to set out an ongoing dialogue beyond the initial stages so that your design system can be effectively maintained and evolve, which we will discuss later. <\/p>\n

Establish your baseline<\/strong><\/p>\n

Using your findings from the review stage, work with your teams to define the aspirations of your product and brand. Set out the design principles you would like to guide your teams moving forward, then define your styles, colours, typography and overall identity. Usually, this will build on the best parts of the visual language identified in your review by making it more coherent and aligned with how you would like your products to be experienced in the future. <\/p>\n

With a strong knowledge of how your team is working and your aspirations, you can now establish the baseline components of your design system. These are the components that are most used in your products, as well as those which will have the most immediate benefit to your team.<\/p>\n

It\u2019s helpful to apply the Pareto principle, which says that 20 per cent of effort bring 80 per cent of the benefit. For example, buttons and text inputs are commonplace and would be useful for your team from the outset. However, if you aren\u2019t already using more complex components like accordions, then your resources are better used elsewhere.<\/p>\n