How to drive the adoption of design systems

Design systems are not new. Most companies either have one or want to have one. 

The million dollar question is, how do you create a design system when you do not have the luxury of starting from scratch?

Let’s concentrate on this scenario, companies that need to introduce one into their sizeable digital portfolio. We’ll be taking a look at some of the considerations and complications of successfully deploying a design system within an organisation.

Realising you need a design system

It’s quite straightforward to realise that a design system can be beneficial. Some of the early and most obvious signs are inconsistent user experiences. For example, going through a user journey consisting of a series of slightly different looking components that produce inconsistent behaviours when interacted with. Think of a date component that on one screen asks a user to pick a date from a calendar whereas the next usage is a box to type the date manually.

Dig deeper and you will start to spot more serious issues. You may notice designers take longer to create new work, and developers struggle to understand how to build the components you need. Maybe on-boarding new team members takes a long time. Or the same questions and bugs show up again and again. Work takes longer and longer to produce and ship. And the more teams you have the more complicated, inconsistent and expensive things become.

Putting all these thoughts together should spark the realisation that a design system will be beneficial, enabling the reuse of UI designs, UX patterns, interaction design and code, shortening time to market.

How not to approach design systems

Still, the big question remains, how do you approach them?

The conventional way would be to deploy a design team, let them work for anything from three to six months designing everything that could possibly be needed. Then have developers work for another three to six months to build it. At the end of this, we end up with an amazing new design system which everyone should love and use, right?

We could indeed do that, but what we will likely end up with is:

• Some designs, e.g a Figma library - not a design system.

• Some code, e.g some CSS or React components - not a design system.

• The impossible task of convincing each and every team to use the above - a change management problem that a design system cannot fix.

Meanwhile, while the Design System Team spent the last six to twelve months creating a design system, other teams across the organisation have been building their own applications and other digital products. They are now so far down the road that utilising the new coded components from the design system is a complex retrofit. Even if a team or two did adopt them they will soon hit incompatibility issues with how the components are set up, what their respective component interfaces are in the context of the wider product, as well as not having the right validation i.e. in the case of something like UK vs US dates, etc.

These challenges occur because developers build the components for their application based on the designs of their respective teams, which our Design System Team has not necessarily considered. But wait, didn’t our Design System Team start from scratch to make the one true source that other teams should (must?) use?

We now have a number of teams with disparate components plus a design system to maintain too. With a bit of luck, a new team may use the design system, so at least one product will be using it based on the initial investment. As far as our users are concerned though, this is yet another part of their interaction with our products that is just as inconsistent as everything else. 

A better way of approaching design systems

Is there a better way? Let’s start with some assumptions. In any reasonably sized company, the chances are there are a number of teams already designing and building things. You could have five or twenty-five, regardless of the number the fact is that those teams have their own designs and code, with some of that code being in front of users too. 

A better approach would be to work backwards from what there is today. So, let us turn this into three stages, spread over a time period of a few months. A realistic amount of time would be anything from six to twelve months for this exercise, depending on the size of the design system and the number of different platforms it needs to support.

Stage 1: start small, make friends

With products in active development, it’s important that we quickly establish what technology a design system needs to support for our developers, e.g. native mobile applications, websites, web applications, etc. Adoption needs to be driven by developers at this initial stage and adoption by developers will be where the majority of the savings happen.

What we need is both strong design and strong technical leadership within the Design System Team, people who can approach the development teams and find a couple of friendly ones who are willing to give details about their design and build process. The typical starting points, e.g. a button or a checkbox, can provide an excellent look into these processes.

The design system’s Technical Lead can work with the friendly teams to create a common component interface. The Design Lead works with the respective designers to make this happen. By keeping it small, we can quickly build a couple of things that can then easily be integrated into those two teams. These initial components also provide a great opportunity to; prove the Design System Team’s design and build process, setup DevOps pipelines and iron out the internal Design System Team processes while keeping them aligned with what the consuming teams need from the design system.

At this stage, it’s about driving early adoption above all. If this stage is done right, those two friendly teams can start realising the benefits, becoming advocates of the design system.

It’s also worth noting that the Design System Team is currently a cost, no savings are realised, nor should they be expected. The impact of the team is still very small. We managed to replace two simple components in two teams out of a much larger number.

Stage 2: build more, educate and market to internal teams

In stage 2, we continue the process from stage 1. We keep working with the two friendly teams and we keep our Design System Team in there, helping them to adopt more and more components. In fact, we get some of the design system developers to work on the integration work for those teams.

We do not want the design system to be perceived as an expensive retrofit. This would kill adoption. We could easily fall into the trap of saying “we mandate that the design system will be used” and assuming all will be well. However, unless the organisation is aligned to using a design system from top to bottom, this will never happen.

Explaining this further, consider the funding model of a team. They receive funding to produce an application, anything that accelerates this is good, anything that slows them down is bad. We can shout from the rooftops about how amazing the design system is and the benefits of it to our end users. Yet, when the Delivery Manager is under pressure to get things done, the only thing that matters is how quickly those tickets move through the Jira board.

Meanwhile, the Design System Team’s Technical and Design leads are always on the lookout for other teams to spread our work to. We now have a way to demonstrate how integration works by showing new teams how it was done for our first two consumers of it. As a result, we find a couple more teams and help them through the process in the same way. We also do this from the perspective of design. The design assets must be pushed to the teams for their Designers to use (unless there is a central Design Team model in use).

In tandem, we run a continuous education programme on what the design system is becoming, how teams can benefit from it and how inconsistencies can, and should, be spotted and rectified early on.

One of the best ways to drive adoption is convincing developers to check the design system components first and not accepting designs that do not match. This can be a difficult task, changing the mentality of “The design system looks wrong, I’ll hack my own component” to “this design doesn’t match the design system, I’ll send it back to design”. Once this discipline is created, it only takes a handful of components to be available in the design system to speed up the development process.

By the end of this stage, we expect the design system to be populated with a reasonable amount of components, providing actual value to end users as they have a more consistent experience. For consumer teams, bugs get fixed “for free”. Components may even be “free”, if a team is just starting out on a project and suddenly finds this trove of components ready to be used, allowing them to concentrate on the real user problems their application needs to solve.

Stage 3: scale success, build preemptively and evolve

The next stage is to keep building while driving adoption. However, the more an application team uses the design system, the more natural it becomes to look at what the design system contains. Once we have enough components to service the basic needs, the task for the Design System Team is to pre-emptively build what the consumer teams need.

To achieve this, we need to have discussions with the teams about what new features and components they need in the future. To achieve that, we start looking at the consumer teams’ backlogs and prioritisation. Their backlogs feed the design system backlog.

This is where the real monetary benefit starts appearing. If you spend £500,000 on a design team to build twenty five components (these are just random numbers, please do not take them as a guide for actual costs), that is £20,000 per component. If you didn’t have those components and had ten teams creating the components themselves, you would be looking at anything from five to ten times the cost (the assumption being that a Design System Team needs to build things at a higher standard, so it’s not a simple ten times). In sum, the sooner we can start building preemptively, the sooner we stop wasting design and development time, and this can be multiplied by the number of teams that need it.

There is also one hidden saving in our iterative approach to design systems vs the all-upfront approach. We only build what is actually needed. If we spend six months or a year building everything upfront, we risk building components that are not needed.

Requirements change. Designs change. User needs change.

Remember, it only takes a component or two to be wasted before costs start to quickly add up. It’s also worth keeping in mind that if a component is needed, but the execution of it is wrong, the following unwanted scenarios are more likely to occur:

• The design system team spends a lot of time reworking the component.

• Consumer teams spend a lot of time changing their applications to consume the component.

• Consumer teams simply hack the component, creating uncontrolled variations.

• Consumer teams will build their own component and start creeping away from the design system.

Take an iterative approach to design systems

The point we’d like to drive home is that an iterative approach is a much better option than building everything upfront. It helps drive design system adoption earlier, which in turn helps realise the benefits sooner.

Design Systems are all about adoption, if nobody is using them they are just something nice to look at built by people sitting in ivory towers. They become a cost, they become stale, they die.

If, however, you get in there early and work with teams to help them use even just a few components upfront, the benefits quickly become visible for all to see. This helps design systems to thrive and an organisation to build quicker and better.