Making Design Systems Work in the Real World

Many of us have been there before: at some point, somebody in the company suggests we build a design system. It sounds pretty straightforward: the team creates a group of reusable components that everybody can mix and match to build reliable, consistent interfaces faster. In fact, it also sounds like a great tool to improve the workflow: the team stops wasting time reinventing the wheel with every new feature. Instead, everybody can use previously tested code with baked-in accessibility, visual language, functionality, and naming conventions — we all can focus on the bigger picture.

It’s no wonder that according to UXPin’s 2017–2018 Enterprise UX Industry Report¹, 69% of enterprise companies either actively use a design system or are currently working on one.

Why, then, are we still struggling to make a design system stick? What seems to be the main problem? Is it that working with a component-driven workflow is too difficult, or that maintaining the design system feels like too much work? I wanted to find the answers. I spoke to many different companies, large and small, and a few key reasons kept cropping up:

1. The team didn’t use it.
2. Management didn’t support it.
3. After a while, the system stalled and it never recovered.

The interesting thing to note here is that none of these are technical issues. Many people I spoke to during my research for this chapter did articulate issues with the tech, but as it turned out, the tech wasn’t really the problem. As we’ll find out in this chapter, despite their robotic name, design systems are predominantly about one thing: people.

Roadblock #1: The Team Isn’t Using the Design System

If you go to any conference or meet-up about design systems, I guarantee this question will come up at least once: “How do I convince other people in my organization to use the pattern library we created?”

It’s an important question because no matter how grand your design system is (whether it’s a pattern library with shareable components, editorial style guides, and so on), if people don’t use it, there’s not much point to it being there.

What stands in the way of people using a design system? I spoke to a developer who has been working on a small system in his spare time to help him and his team members produce website templates with already tested and quality-assured components. He felt like he was solving a real pain, not only for himself but also for his team. Working quickly with untested code is hard, not to mention risky, so he offered a solution to help. But he met with resistance:

“I thought the team would pick it up instantly. But I found there were a lot of roadblocks stopping people from using it, like needing to switch to different naming conventions. People were used to doing things a certain way, and didn’t want to spend time changing their process, which, for all intents and purposes, works perfectly fine.”

It turned out he needed a way to make the design system easier for his team members to adopt. As it stands, they don’t have much of an incentive to use it. As far as they’re concerned, their process is fine, albeit a little inefficient.

This is something they’re still working on, but to understand why people don’t use your design system, you first need to understand people and their motivations. Una Kravets argues that we need to be more empathetic to what people are being judged on at work.

“We’re all being judged on different things. Most people aren’t being judged on clean code. The engineers we’re building this for are being judged on their ability to build the product and ship features quickly.”

This can be applied to other disciplines, too. Designers aren’t being judged on their articulation of design principles, or the use of symbols or smart objects in their tools. They’re being judged on making great-looking products that are easy to use and increase conversions.

Ultimately, if your design system doesn’t help your team meet their goals, you’re going to have a hard time convincing them to use it.

Why Are You Doing This?

The first question you need to ask yourself is why you even want a design system in the first place. Or, more accurately, how will a design system help your company and its team members?

You could argue that every company would benefit from a design system. And there’s truth in that. If we could flick a switch and suddenly have a design system, it would no doubt be beneficial.

But you don’t make a design system by flicking a switch or pressing a button. A design system often takes an extraordinary amount of work, effort and time.

The benefits, or at least the promise of benefits, need to be worth the headaches of systemizing your website. It needs to be worth the change in process and workflow that your team will go through.

So how can you find out whether a design system is really something your team needs? Nathan Curtis from EightShapes recommends starting every design system with a phase of discovery:

“A design system doesn’t start with choosing a first color. Instead, ground a system in a strategy that discerns customer needs, sets objectives, explores and converges on a design direction, pitches a strategy, and obtain an organization’s commitment.”— Nathan Curtis, “ Starting a Design System ” ²

Before you even begin putting together your design system (or even if you’ve already started), you need to understand how your team currently works and what the biggest struggles are.

You can do this by talking to people directly, or sending out an anonymous survey. I find keeping questions fairly broad and open yields the best results. We’re not trying to steer their answers in any way; we just want to find out how they work and what they’d like to change.

We can ask questions like:

1. What is your favorite part of your job?
2. What is the most frustrating thing about your day-to-day work?
3. If you could get rid of one aspect of your job, what would that be?
4. What are the main inefficiencies in your design/development process?
5. How can your company improve in terms of enabling people to get their work done more effectively?

It’s important to note that we haven’t mentioned design systems at all. We’re not asking “Would you find a design system helpful?” or “Do you wish you were more efficient?” because most people want to be more efficient. What we want to find out is whether efficiency is the problem that’s keeping them up at night.

With this exercise, we’re looking for any commonalities that people are struggling with. What do people want to fix in their jobs? What will make them happier, more effective people?

Once you’ve collected the data, whether it’s a survey or a transcript of conversations, you can start to normalize the data. I usually do this by creating a spreadsheet with different category headings based on feedback. So maybe “lack of efficiency” is one, or “difficulty in collaborating.”

Beneath these you can paste the exact words people have used.

For example, a developer’s problem might be that they’re under pressure to keep building new features, but they’re getting complex and inconsistent styling from the designers for each new component. The codebase is becoming messy and they’re struggling to meet the deadlines.

Then you could have a product manager who is frustrated because they feel like they’re waiting too long to launch new features. They also think that these features end up nothing like they had envisioned or talked about at the start.

And then you have designers; maybe they’re frustrated because developers never seem happy with what they give them but they don’t understand how they can be more helpful to them.

These could be problems that are cropping up over and over in your company.

From these issues we can categorize them: whether it’s creating core styles so developers don’t have to code new styles for every new feature; or saving time by being able to launch faster using previously tested components; or even just creating a shared vocabulary so people can talk to one another and work together more effectively.

This will give you a good overview of the current problems in your company. The idea is that you’ll use this to decide whether a design system is really what your company needs right now, or if there’s something else you need to fix first.

If the answers show you could benefit from a design system, it’ll also give you reasons why. Some companies might feel pretty efficient in their work, but team members struggle to collaborate with one another. Maybe testing is a big roadblock for your company — you’re having to spend too long testing every component, which means you can’t push out features fast enough.

This will help you build your design system because you’ll have a better understanding of why you’re doing it. You’ll be working towards what’s best for your team, making the design system work for them and their needs, which will help with adoption.

Getting Your Team to Adopt the Design System

Unfortunately, it’s all too easy for us to declare “Our process is inefficient. We’re solving a real problem” and expect that alone to be enough to ensure the survival of our design system. In her book Thinking in Systems, Donella Meadows states that “information about the existence of a problem may be necessary but not sufficient to trigger action — information about resources, incentives, and consequences is necessary too.”

Let’s look at these one by one.

Resources

People are busy. No matter how much technology advances to make our lives more efficient, we always find ways to fill that time. Most people aren’t sitting around at work, twiddling their thumbs, looking for projects to work on. We have deadlines, meetings, and the allure of Twitter vying for our immediate attention.

How can you demonstrate to your team members that you have the resources available to put this into action without adding to their already full plates?

The developer I mentioned earlier in the chapter tried to convince his coworkers to stay behind after hours so he could run a workshop on how to use the design system he was working on. But because management hadn’t provided any additional resources to do this during the day, he had a very low turnout: “I found it tough getting people to stay after hours. If management allowed a workshop in working hours I think I’d be more successful in showing people how a design system could help them.”

Expecting people to spend their already limited free time learning about design systems sets the wrong precedent. You’re already selling the design system as extra work from the get-go. It’s important to make sure your team has the resources needed for a design system without putting the burden on your teammates.

Incentives

We’ve already identified key problems a design system could solve in your company, and hopefully you’ve got a clear idea of what your coworkers desperately want fixed. In most cases, promising these pains will be solved is enough incentive.

When it doesn’t work, the most likely cause is that you’re not solving a problem painful enough for them. Sure, your coworkers want to be efficient, but is that enough? After all, they’re getting paid the same amount each month no matter how efficient they are.

People are typically resistant to extra work. As Scott Berkun points out³:

“Designers love to draft design principles, rules for their coworkers to follow to ‘do good design’ — this rarely works. […] The principles always create more work, or at least demand more thinking. But humans avoid work. […] There is little motivation for anyone to change their own behavior.”

If you’re finding team members still aren’t motivated, you may need to dig deeper. James Ferguson from Skyscanner knew that different teams had each spent weeks or months creating various date pickers for their website. He knew these were a massive pain for people to create, and that it was unnecessary to create so many different variations when one would do.

If James could take away the need for all these teams to create their own date pickers and have a single, tested component that would solve a huge problem for them:

“Our job is to be a pain killer, if you like. A lot of stuff we do isn’t sexy work. It’s a total pain in the ass, but we’re doing it so that other people don’t have to do that multiple times.”

James wasn’t selling being more efficient. He was selling no longer needing to recreate a date picker over and over again. It may sound trivial to some, but for his team this was a huge incentive to get some kind of system in place.

Find out what people are really struggling with, the kind of thing they’d pay someone to solve for them. Solve that first.

Consequences

The last element mentioned is consequences. What will happen if a team doesn’t get behind a design system?

Often, this is just a reverse of the incentives plus one additional caveat: the longer you wait before starting to systemize your website, the bigger the job is going to be.

Building a working system around your website isn’t something that happens overnight. For many people, it’s like organizing your home: you know you’re going to have to tackle it at some point; but the longer you leave it, the more you’re going to have to clean up.

Getting Your Team to Adopt the System Organically

When we talk about incentivizing your team to get behind a design system, often there’s an obvious question in the back of people’s minds: Why not just impose a design system top-down?

It’s a valid question. But if there’s one theme that’s cropped up again and again with companies that are successfully using a design system it’s that you can’t police a design system. What this means is, you can’t create a library of reusable components, for example, and expect everyone to use and contribute it because you said so. Any type of design system is only as good as the people using it; if the people using it do so out of obligation, your design system is not going to be as stable.

This is something Brent Hardinge understood and took measures to curb during the creation of the design system for the Seventh-day Adventist Church.

“We always knew organic growth was going to be better than having forced growth. We spent a lot of time building relationships with people who would benefit from the system. We’d meet them in person, talk to them and try to get to a certain level of trust before moving forward.”

Brent admits that this is a slower process, but he’s found it to be far more lasting because through meeting people and talking to them, he’s been able to create a deeper understanding of what a design system is and why it will benefit them.

Getting your team to use and contribute to a design system may not happen quickly, but as long as you’re making their lives easier it will happen. Instead of taking a top-down approach and requiring every team member to use the design system, try taking a more collaborative approach — show them the benefits and let them decide whether this is something they want to get involved in.

Roadblock #2: Management Doesn’t Support Your Design System

In our industry, we talk a lot about whether designers should learn to code, or whether developers need to learn design principles. One subject which doesn’t get spoken about enough is business. One way or another, we’re all invested in business. Whether you work in-house at a company, at a web agency, or you’re a freelancer, we’re all hired for the same reason: to make a company more profitable.

Yes, on the face of it we’ve been hired to improve the user experience, or to build out new features. But the end goal is still to make a profit. It doesn’t have to be in a cutthroat, “we will make more money, no matter the cost” way. Increasing revenue means creating more jobs (and thus, supporting more families), better equipment and facilities, higher paychecks, and so on.

Those who immediately understand that make themselves more valuable to their employers. Not only that, they’ll know exactly how to ask for what they want and get a positive response. This is important when talking about design systems because, as we mentioned earlier, we rely on getting support and resources from management to help us do the best jobs we can without sacrificing our personal time.

Ryan Rumsey wrote a great article about how he managed to get buy-in for his design system at Electronic Arts. With previous projects he had struggled with this, so he understood the value of putting together a case for a design system up front:

“I’ve learned first-hand, through my experience, friends, and the design community at large, that asking for up-front buy-in on many projects is difficult. There’s a certain amount of research and analysis needed to be done to get a good proposal together. It’s made an even more difficult if data to evaluate the potential gains on efficiency is not available.”— Ryan Rumsey, “ Selling a Design System before asking for buy-in ” ⁴

He found that asking for additional time or resources, without anything tangible in terms of what the business will see for it, meant the conversations often turned into subjective opinions, which is something management will struggle to sign off.

So how can we get them on board? From my research, I’ve seen two approaches:

1. Create a small, working pattern library or style guide, then use the results from that to ask for support later
2. Ask for permission to start systemizing your website upfront before you do any work on it

Create a Small System First and Ask for Support Later

Many teams have had great success creating a working design system, using that to prove it’s value, and then asking for additional resources later. Wolf Brüning from the German online retailer OTTO went down this route when his UX lead brought together a small team of three (himself, a front-end developer, and an external UX consultant) to start researching the best way to put together a design system.

They ended up bringing on one front-end developer from each of their product teams and ran a tightly scoped workshop, which resulted in a small, but working, pattern library. Adoption of the pattern library happened slowly, but organically. By simply referencing the pattern library instead of giving detailed specifications when asked about a component, they encouraged their team members to use it. And as their team members started to see the benefits, they began using it independently. This had a knock-on effect with management. Wolf noted: “As management saw the benefits of saving time, cleaner code, better UI quality, and reducing complexity, we also got buy-in from there.”

Dedicating a set amount of time to try out a small style guide or pattern library and measuring its effects across your team is the simplest way to get buy-in. If you’ve already created something and it’s proving to be effective, you’ll be hard-pressed to find a manager who isn’t willing to help sustain the efforts.

What If You Don’t Have the Resources Just Yet?

Creating even a small pattern library can be a time-intensive process. Sometimes you simply don’t have the resources at your disposal to be able to assemble a team, put the pattern library together and stay on top of your workload.

Not only that, involving a small portion of your team can actually impede adoption by alienating other people from the system. This is what Donna Chan and Isaak Hayes from AppDirect found during their early attempts at a design system:

“Upon completion, many of the style guides were basically put in the trash and not adopted, in the sense that they were unusable for the intended users. We heard comments like ‘They were a waste of time’ and ‘All these resources were put in and what came of it?’”

They learned that by trying to implement a design system on their own, they weren’t helping the very people who were meant to be using it. Without support from management to work with everyone on the team, they were creating a system useful to only a handful of people.

In these cases, it’s more effective to spend some up-front time ensuring you get buy-in from management so you get the resources you need to create something useful for your team. Which leads us to…

Asking for Permission Up Front

The second option is asking for permission in advance, before you do any work on a design system. This has some obvious advantages, mainly that you can get the time and resources you need to work on the system; you don’t need to try to fit it around your current workload.

But getting permission for such a mammoth task is notoriously difficult. Many stakeholders won’t necessarily know what a design system is, so there’s an educational element. Then we have the problem of a design system sounding simple (“We’re just making our website reusable — like Lego!”); stakeholders may find it difficult to understand why you need a whole team just to work on the design system.

And when we try to talk about metrics, we usually want to see either an increase in efficiency, saving money, or making a profit. In other words, we want to see a return on our investment (ROI). Is the time and money that we need to put in to create a design system going to be less than what we get out of it? Not necessarily, says Alla Kholmatova in her book Design Systems⁵: “Some teams struggle for a while to see a return on investment in a modular system, which makes it hard to justify the investment in the first place.”

An ROI assumes that the design system is adopted by the team, used consistently, and enables them to get results faster. None of this can be truly guaranteed but, as we’ll see later in the chapter, there are things we can do to dramatically increase its chances of success.

When approaching management, it’s best not to go in with a full five-year roadmap for a design system. Instead, it’s easier to get approval if you start small and low-risk. Remember, at this stage you’re still researching whether a design system is the best option for right now. For some teams, a style guide and basic pattern library might be enough. A full-fledged design system might be too much work for too little reward right now. And if that’s the case, don’t force it until your company is ready.

What exactly does management need to see in order to invest in the project? At a minimum, you’ll need to answer questions like:

• What is a design system and why would your company benefit from one?
• What kinds of results have similar companies had from implementing a design system?
• What resources do you need?
• What do you hope to achieve with a design system?
• What’s your roadmap for getting one off the ground?
• How will you measure results and stay on track?

The first three points are pretty straightforward to get together. It’s the last three I’d like to focus on now.

Setting Goals, Coming Up with a Roadmap, and Measuring Results

When it comes to goals, our last exercise gave us a start. The pains we identified are what we are aiming to eliminate. Now we need to go a bit deeper and turn those problems into something we can work toward solving.

One goal-setting solution gaining popularity is objectives and key results (OKRs). What I really like about OKRs is that they’re used with team members, not just management. They empower every team with tasks that contribute to the higher-level business goals of an organization. A study by Sears Holding Company in 2013 found that OKRs have been shown to improve staff efficiency⁶ and the bottom line with their sales teams.

“For the group who used OKRs we saw an increase in their average sales per hour from $14.44 per hour to $15.67, or an average increase of 8.5%. This increase is not only statistically significant, but practically significant.”— Chris Mason, Senior Director, Strategic Talent Solutions at Sears Holding Company

An OKR is essentially a framework of defining and tracking objectives and their outcomes. Honestly, it seems pretty similar to most goal-setting techniques, but I think OKRs just give a really simple, no-fluff framework, which is:

1. Where do I want to go? (the objective)
2. How will I know if I’ve got there? (the key results)

You can use OKRs in any aspect of an organization (like the sales team example above), including your design system. The reason OKRs are great for design systems is because you’re treating the system as a means to an end. In other words, the result isn’t having a design system. The result is improving efficiency, or shipping more products.

This works well for management because instead of saying “This design system will absolutely make us more efficient, which will enable us to release more products and features, which will save us money,” you’re saying “We think this will help us do the former, and here’s how we’re going to test that hypothesis. We’ll keep you in the loop the whole way and will only ask for more budget if we can prove to you that this is effective.”

In doing this, you’re reducing the risk for management. Instead of asking for half the team to create something which may or may not ever be adopted, you’re asking for a few people in a limited time frame to test something that could drastically improve the company.

Let’s look at an example of a company which has used OKRs successfully with a design system. Brent Hardinge from the Seventh-day Adventist Church worked with Dan Mall from SuperFriendly on their design system (Adventist Living Pattern System: ALPS⁷), and they outlined exactly what they wanted to get out of it, and how they would measure whether it had been successful or not.

Their primary goal was to create a pattern library team members could use to envision what they wanted to build. It also needed to contain the code that could help their developers quickly bring their ideas to life.

That was their why. This will be different for every company. What’s important is that they clearly defined what the goal was.

They then split this into three objectives that helped them achieve this goal and laid out exactly how they’d measure it⁸:

1. “Create a foundational, deeply-rooted pattern library.”
   • 1,800 Adventist websites (15% of the 12,000 sites) make obvious use of ALPS.
   • 57 websites made by the General Conference (50% of the 114 sites produced by the GC) make obvious use of ALPS.
   • The first Adventist websites built for certain languages report 0 issues when building.
2. “Allow for customization and individuality in the new pattern library.”
   • A trained person can build a site with the new design system in two days.
   • 2,400 Adventist sites (20% of the 12,000 websites) use one of the color preset options.
3. “Involve the community in the creation and adoption of the pattern library.”
   • 18 unions (30%) register in a feedback program.
   • 3 ideas originating from the community not included in the initial delivery of the design system have been adopted.
   • Design system adopted by 3 customers that weren’t part of the initial interviews or any feedback program.

They kept track of each goal as they progressed with their design system, and it gave them the motivation to keep going and get the results they hoped for. Some they achieved, others they didn’t, but OKRs are meant to be adapted as you learn more about what’s achievable. This means if you set the bar too low or high, or are tracking the wrong metrics, you can change them.

On reflection, Brent found the OKRs essential: “The project is so broad, so the OKRs really helped us narrow down on what we were building and doing.” When the time came to review their goals, they could celebrate the ones they achieved and, more importantly, review the ones they hadn’t before setting new goals.

How to Measure When the Data Is Subjective

A design system’s effectiveness is notoriously difficult to measure. When I first started selling a systemized solution (like a pattern library) to clients, I tried to focus on the financial benefits; the reason being, if you can prove something will either make more money or save money, it becomes the easiest thing to sell.

However, just saying a pattern library would save money wasn’t enough. I always felt a bit icky making a claim I didn’t know was true. So I decided to go out and look for evidence.

A Twitter poll drew over 1,200 responses, a whopping 80% said they think style guides and pattern libraries save money; 9% said it made no difference; and 11% said they probably lose money.

But when I tried to dig deeper I found that nobody seemed to have any proof that money was saved. Their answers were based on intelligent reasoning, but not evidence.

The issue is that a design system is always interconnected with other projects and improvements. A company doesn’t shut down to build a pattern library. This makes it nearly impossible to define exactly which figures the design system is responsible for, and which were from an entirely different change.

But there are other benefits to a design system, including some that would appeal directly to management. Here are four benefits that will get your managers or stakeholders on board:

1. Getting new features or services into production much faster.

   Management like to see movement. They like to see their company progressing and feel like they’re keeping up with their competitors. Getting new features shipped faster would be a great incentive for most managers.

2. Makes their company more attractive when hiring.

   Managers deeply understand the importance of hiring the right people for a job. They put a lot of stock into making sure their company is attractive for potential employees. The benefit of a more systemized way of working has been gaining traction in the last few years, and many designers and developers are looking specifically for roles in companies that prioritize this. If a systemized way of working makes their company more attractive to exceptional employees, they’ll more than likely listen.

3. Saves the headache (and cost) of a redesign every other year.

   Redesigns or rebrands are always going to happen. But if you have a large website, a redesign is not only going to be incredibly time-consuming, but it’ll also cost the company an awful lot of money. To make matters worse, giant overhauls can have a negative impact on both SEO and user experience. In my mind, a redesign is far more risky than a design system!When you have a design system, you’ll still be able to rebrand, optimize for conversions, and improve the UX, but you’ll be doing it in a more sustainable and more effective way. You can work on and test small chunks of the website over time, rather than trying to overhaul the entire thing. Unlike a redesign, which decreases in value over time, a design system has the opposite effect: it continuously increases in value.

4. Everyone else is doing it!

   Yes, managers experience FOMO too. Often, just knowing that this is something a handful of their competitors have bought into is enough to get them to listen and take your request seriously.

This all goes back to what we talked about earlier. Ask yourself, “What is my manager being judged on?” Are they being judged on how well designers and developers work together? Not exactly. They’re being judged on how they fare next to their competitors; they’re being judged on profit, jobs being created, growth.

Now we know the outcomes we’re looking for, we can get a better idea of how to measure those effects. We can split these into two categories: measuring based on shipping, and measuring based on time saved. Let’s look at two case studies that have made these work.

Amazon Web Services Increased Shipped Features by 98% in a Year

Thomas Lobinger leads the team responsible for the design system at Amazon Web Services (AWS). Thomas noticed that since launching they went from releasing 722 new services and features in 2015 to a whopping 1,430 (around 4 per day) in 2017: an increase of 89%. Today AWS offers over 100 services with thousands of features. Each service team develops its own service’s UI, so having a central system where everybody could use previously tested and approved components and user flows was a huge factor in releasing so much, so quickly.

Not only that, they found that with the design system they were continuously improving the UX, accessibility, and conversion rates throughout the AWS suite. When something worked, they could apply it elsewhere and dramatically improve their services in a fraction of the time.

When talking about the success of the system, Thomas said:

“We were able to sell and grow the team because of the already apparent side effects from the simple UI components that we developed in first weeks. From the very beginning, there was already customer value created. I would advise teams to start even if they don’t feel like all the conditions are met. A small team and system can already provide huge benefits.”

FutureLearn’s Component Reuse Rapidly Becomes Net Positive

At FutureLearn, Alla Kholmatova and her team did some experiments to measure the effect systemizing their components had on staff efficiency. She found that on average a reusable component took around two to three times longer to create than a one-off alternative — but the time was made up when they reused a component twice or more. This provided a good baseline as to when it would make sense for the team to create a reusable component or a custom one.

There is one small caveat to measuring a design system based on saving time: you can inadvertently have a negative effect on the user. As Alla and her team discovered, the increase in productivity they enjoyed led them to proactively try to reuse a component as many times as possible. After all, the more they used it, the more cost-effective it became. However, this didn’t always give the best results:

“We then found we were reusing components for the sake of it, to fit it into our pattern library, even if it wasn’t the best solution for the user. Now we’re spending time redoing components to make them more usable.”

By all means, encourage and celebrate efficiency with your design system; just make sure you do what FutureLearn did and keep an eye on your users. Make sure your reusable components aren’t detrimental to their experience.

Now we’ve managed to get management on board, and we’re clued up on how to encourage your team to use the design system, what happens after the initial rush wears off? What happens if (or more likely when) you stall?

Roadblock #3: Your Design System Stalls

Pretty much every design system stalls at some point. No matter how motivated you are at the start, progress is going to feel slow and frustrating at times. It’s simply part of creating a design system.

When you first start work on the system, there will probably be a ton of excitement. People will be motivated, and you’ll feel like things are going to move very quickly. Then you’ll get hit with roadblock after roadblock. You’ll end up in these long, drawn out discussions about naming conventions, or trying to work out some problem you hadn’t foreseen.

Before you know it, weeks have passed and your boss is asking to see progress on the design system. You don’t have anything and you’re essentially just spinning your wheels and the program risks getting axed.

This is a pretty pessimistic outlook but not uncommon. Fortunately, there’s a fix. The problem isn’t that you’re not cut out for systemizing your website. It’s not that your company is too complex to make a design system work. It’s usually just a misalignment between strategy and implementation. These are two very different but equally important tasks, and it’s important to understand and recognize the difference.

What tends to happen is that we mix up these two tasks. We’re implementing something and the conversation turns to strategy. We get on tangents, we find new issues that we hadn’t considered before, and then at the end of the day, week, or month, we realize we’re no farther along. We’ve made virtually no measurable progress, aside from a lot of conversations.

What we need to do is give ourselves dedicated time for each task. Save up all the big-picture conversations for a strategy day, when you get together the key decision-makers in your design system team and iron out all the high-level details that have cropped up. It also gives you a chance to reassess your goals and make any adjustments before the next strategy day.

Conversations could include things like:

• Should our components all follow naming conventions based on a particular theme?
• Should we open-source or build a marketing website around our design system?
• How should we accept contributions to the design system? Can anybody contribute or should we have an application process?

These are questions that are probably going to require a lot of discussion. Saving them up for when you have time to address them is going to be a huge help for you and your team. It leaves you free to work on making measurable progress with the design system, without being held back by too many roadblocks. When you’re working on your day-to-day stuff, if you find a conversation turns to strategy, you can simply delay talking about it until your next strategy session.

This is simply an exercise in learning to identify the difference between strategy and implementation, noticing it, and being able to compartmentalize it. If you do this, you’ll find your design system makes progress and you’ll be far less likely to give up out of frustration.

If you still find yourself stalling and your team lacks motivation, Alan Wilson, a designer at Adobe, suggests getting past a stall is often as simple as taking a break:

“I find that I need occasional breaks — sometimes just an hour or a day, sometimes longer, like a week — to work on other (non-design system) things. For instance, it’s nice to design a product using your design system, which means you come back to design systems with more empathy for your customer.”

He finds that switching from working on a design system to working with a design system can be enough to step back, see it with fresh eyes, and understand what you needs to be done next to keep it progressing.

Above all, we need to remember that stalls are natural, and they don’t necessarily mean your system is broken. But they can also indicate that there’s something wrong with the direction you’re going in. Some companies find they can’t move forward until they change how the system is governed. Others find they can’t progress until they change how components are organized.

It doesn’t mean you’ve failed, but it does mean that you need to take a step back and try to figure out why your system is stalling. Is it because the effort you’re putting in isn’t equal to the benefits? (And if so, why?) Or is it just because you haven’t seen tangible progress for a few weeks?

A Roadmap for a Successful Design System

Now we’ve gone over the three main roadblocks to making a design system stick (team members didn’t adopt it, management didn’t support it, and it stalled and never recovered), let’s look at a roadmap for how you can start a design system and give yours the best chance of succeeding.

1. Find Your Purpose

The first thing is to find your motivation for having a design system. Why do you want one? What will that do for your fellow team members? How will this serve your users? And how will it help grow your company?

It’s important not to gloss over this stage and come up with vague principles. Dig deep into your company’s culture and find out whether a design system is what’s needed right now. (If it’s not, don’t do it yet.) As you’ll come to realize, if you haven’t already, a design system is not about technology. It’s about people. A big part of this journey is going to be spent talking to people and helping solve their problems.

2. Start Small, with an Experiment

There’s a lot of risk in creating a design system. What if nobody uses it? What if we put in all this work and we don’t see any benefits? I wouldn’t recommend anyone going all in on systemizing all your flagship projects at once.

It’s much safer to test the waters with something small. Maybe there’s a new feature you can test your system on? Perhaps there’s a particular flow that (if you did nothing else) would benefit a large amount of people. Even a simple style guide is a good exercise to start seeing how this could help your company.

When starting a design system, look for something small you can test the system and its adoption on. The goal is to help people do their jobs better and more efficiently. If you do that, you won’t get any backlash. If you encounter resistance or people aren’t interested, you may need to go back and assess why.

3. Get Past the Stall (and Have Regular Check-Ins)

Setting up regular check-ins to focus on the goals and strategy of a design system will help reduce the likelihood of a stall halting work on it. Spend at least one day at regular intervals (say, every four to six weeks) taking a high-level look at your design system and reassessing your goals. This frees up your day-to-day work and enables you to focus on getting things done, as opposed to being stuck in long conversations about the overall strategy.

4. Don’t Focus on what Everyone Else Is Doing

It’s easy to get caught up in what other companies are doing with their design systems. Every day, it seems, better, shinier design systems are unveiled. Focusing too much on this can end up crippling your efforts to create a useful design system. You’ll see things other companies are doing and think, “We need to do that too!” But remember that a design system’s success is measured by how many people it helps, not how many claps you get on Medium.

A great example of a team who did their own thing despite everyone else doing it another way is WeWork. When they built their design system, Plasma, they assumed they would create a dedicated website to show the system, specs, examples, and guidelines because it was the done thing. They started a Google doc to get all their components documented before pushing it to a live website, but over time they realized the doc had everything they need to document a design system. It has built-in navigation, the ability to add comments and collaborate, it’s accessible to everyone on their team, and doesn’t need any special skills to update it.

Andrew Couldwell, the design lead on Plasma, said about the success of the Google doc:

“As the document grew, I realized it did exactly what we needed it to — the only reason to create a public, branded website for this would be as a ‘pride project’ for WeWork Digital, or as a resource if we open-source the system.”— Andrew Couldwell, “ Plasma design system ” ⁹

There are many benefits to creating a public design system (accountability, PR, education) but WeWork’s ability to look past what everyone else was doing and make a judgement on whether this was the best solution for them, right now, ended up paying off. So don’t worry about what you feel like you should be doing, just work on what’s going to be most effective for your company.

5. Become an Evangelist…

Having at least one person in charge of keeping the design system front-of-mind is going to be a huge help when working on a design system. When you’re starting out, it’s not likely that you’re going to have a full-time role for a design systems lead (though as you grow, this becomes a necessity), but you will benefit from somebody who will act as an evangelist for the system.

The evangelist’s job is to be in charge of the design system, acting as a go-between for everybody using it. For that reason, it’s important to have someone who can easily speak to designers, developers, marketers, editors, and so on. You’re looking for a people person who’s incredibly enthusiastic about systems — yet not necessarily the most technical.

These people are also in charge of educating the team about design systems and keeping everyone updated with progress. Alan Lindsay from Experian organized an entire conference called One UX for their team members around the world to learn about design systems and get excited about using them.

Even though Experian has incredible design talent and has always been a very innovative company, prior to the conference they operated in disparate design teams that sometimes didn’t even know of one another’s existence. Alan ended up becoming “chief evangelist.” He uncovered pockets of amazing talent all across the globe, and organized a community to discuss challenges. They eventually met together at One UX to work out solutions, including creating the global design system they enjoy today. Considering so many people contribute to the design system, they found having at least one person in charge of evangelism a huge help:

“Given our current situation, evangelism was absolutely essential — someone had to dedicate time and back this vision to make it real and it was my privilege to start a conversation and gather these incredible people in the same room so we could elevate the company together. Now we’re in the process of formalizing several roles that naturally emerged through this journey because the business recognizes how valuable managing this collaboration is. It’s not always easy — there are challenges with evangelism like every other area of business — but the payoff is completely worth it!”

To have a successful design system, at least one person must be in charge of keeping it in people’s minds, making sure everyone is happy with it, collating feedback, and educating others.

6. …But Don’t Mandate

Perhaps the most important thing to remember if you want a successful design system is that no matter how much you believe in it, don’t force anyone to use it. You shouldn’t have to persuade anyone to use a design system. The benefits should be so clear that people will want to use it. As Wolf Brüning said, “The most evangelizing is done by our library itself, as it provides a great way to save time and build better product by not reinventing the wheel again and again.”

If getting people to use your design system is like pulling teeth, it’s not doing its job.

A Design System Is About People

Design systems are often presented as a technical challenge. What tech stacks should we use? How do we make it a “living system”? Is this a molecule or an organism? These are certainly valid questions but they’re not the most important ones. Design systems that succeed are not the ones with the best tech — they’re the ones that help the most people.

As James Ferguson puts it:

“It’s not about your design skills, it’s not about your engineering skills, it’s about your problem and people skills. Trying to find that level of people skills and engineering is difficult. You need to get out there and speak to people, help people out and be really proactive. That’s the biggest thing I think, that’s the hardest problem, is people. It’s always people.”

So remember, if your design system improves efficiency, team collaboration, gives your website a better user experience, and even impacts the bottom line, you’re onto a winner. But at the same time, no design system is perfect. Striving for perfection is admirable but unrealistic. Perhaps we need to learn to be OK with imperfection because the most successful systems are the ones that can embrace those imperfections, adapt quickly, and have a clear purpose that benefits not just businesses, but people.

About the Author

Laura Elizabeth is a designer turned product creator. She predominantly helps developers conquer their fear of design and runs designacademy.io, a training platform where developers can learn how to design.

—

1. http://smashed.by/uxpinreport
2. http://smashed.by/startds
3. http://smashed.by/designprinciples
4. http://smashed.by/askbuyin
5. http://designsystemsbook.com/
6. http://smashed.by/sears
7. https://alps.adventist.io/
8. http://smashed.by/adventist
9. http://smashed.by/plasma