Sell— ing a Design System?

Designers romanticise design systems in countless articles online, and we make it sound so easy in our case studies. But the reality is:

• They’re time-consuming to build and establish.
• They take up a lot of development resources.
• They distract from working on any roadmaps of features.
• They’re tricky to maintain.
• Designers can see them as a threat to their creativity.
• And, they require a lot of stakeholder support to succeed.

Honestly, selling a design system could well be the hardest part of the process!

You need to convince a wide range of people — from the bottom to the top of the chain of command — that it’s worth it. And it is, but I just listed a lot of legitimate reasons not to create a design system! And these are just some of the reasons why you’ll be told: “No”.

To avoid being told ‘No’, you need to learn how to teach the value of design systems — and to earn the support and trust of stakeholders — or your design system is going to go nowhere.

Find your partner(s)

To illustrate this process, I’ll share an example from my real-life experience of selling design systems at a company.

At this company, I had a partner in crime called Nick Stamas. Nick had already started selling the idea of a design system before I came onboard. He had a smart approach: rather than lead with: “let’s create a design system!”, he gave presentations to a number of engineers from different product teams about the advantages of a centralised code base, and promoted better collaboration between designers and developers.

I was only an observer at these meetings. As a fellow design lead at the same company, I had a vested interest in this presentation going well, and I was gauging the response from the attendees. I recognised that this was the type of support and interest we’d need — to inspire, and to build — from a range of stakeholders.

In essence, Nick was sowing the seed of the idea of a design system by simply highlighting common problems most developers can identify with and tailoring his presentation to different teams. He was getting developers excited about things they care about!

To quote from an article Nick wrote about this process:

“Sell a vision that everyone can buy in to. Selling is a process, probably more than a single meeting. Look for teaching moments. Use your storytelling skills. Show your team that a better way is possible. Come up with a memorable name and say it a lot. Get people excited with a splashy presentation.”

Aside from these presentations, Nick had made a start on a design system which he called Plasma.

Nick’s early approach was to begin with code — not to mock up anything in design software. He was building the bones of a code base in React by documenting basic system components like buttons and form inputs. He didn’t focus on design or style. Instead, he focussed on getting the basics right, building strong foundations, and creating a semantic system for naming conventions.

Over time, he shared his progress with developers, one-by-one, getting them excited about it. He started inviting other developers to contribute. His intent was to prove that a simple, consistent, shared code base could be integrated and maintained effectively and efficiently within his team and product, and ultimately across different teams and in different products.

Note: Nick’s advantage was his diverse development and design skillset. He spoke the same language as engineers, which helped him pitch to them. Everyone has their strengths. Play to yours, and your team’s. You don’t have to start a design system in code. The important message here is to get people who will be involved in the system excited about it! That often means proving your point, or earning people’s trust.

More than design and engineering

It’s important to note: in these early stages, Nick was also working with his larger product team — including product managers and designers — to identify problem areas in their products and processes that the design system would address.

Solving problems is a big part of the value proposition of a design system. The more powerful stakeholders won’t care about what the product looks like, or your code base. They will care about solving problems, or more specifically, the business success these solutions lead to.

‘Finding your partners’ involves gaining support from all stakeholders, not just designers and developers. We’ll come back to Nick’s story, and this process of forging partnerships, throughout this book.

Laying the foundations

In parallel to Nick’s story so far — as Nick was highlighting the need for a design system — I was working on what I called the ‘Digital Foundations’, which we’ll cover in the next chapter [of this book]. For now, think of these as ‘digital brand guidelines’.

These Digital Foundations were intended to act as a source of truth for our values and to guide the design, content, and build of all of the company’s digital products. I based this work on the company’s existing brand book*, which had been created with print and physical spaces in mind. After extrapolating what could successfully be applied to digital, I went on to greatly expand it to cover digital product requirements.

* Big brands commonly create — or commission an external agency to create — a ‘brand book’, which acts as a ‘manual’ for everything created for that brand.

It’s important for a large company to have brand guidelines to prevent everyone from doing their own thing, and to keep products from spiraling out of control. With the creation of these ‘Digital Foundations,’ our guidelines now existed, but we hadn’t put them to work yet. Brand guidelines are of no use on their own. They need to be practically implemented and adhered to, and design systems give us the perfect opportunity to do so.

So naturally, after a period of shadowing each other’s work, there came a point where Nick and I teamed up to collaborate on a design system. Nick directed the engineering and planning, and I led the design and creative direction. We combined the Digital Foundations with the product needs that Nick’s team had brainstormed, and the code Nick had written. Working with these strong foundations, it didn’t take long for an on-brand, problem-solving, and product- focussed design system to take shape.

We’ll delve more into the process of creating a design system later [in this book], but for now, you can read a design case study article about the Plasma design system described here.

Start small, and adjust your pitch accordingly

Continuing our story: in parallel to the design and build work, we continued to present to different stakeholders. Selling a design system never really stops, no matter where you are in the process. We started small, working our way up the chain of command, gaining support and momentum as we went.

It’s impossible to say whether pitching the design system from top-to-bottom or bottom-to-top will work best at your company. It depends on the intricacies of different work culture, politics, personalities, and hierarchies. Have a think about which will be more effective at your company. And remember, the point is to tailor your pitch to your audience. You want to excite as many people as possible with all the ways a design system will benefit them.

From junior designers to design leads, from front-end developers to engineering leads, and from product managers to heads of departments: we spoke to a wide range of stakeholders, adjusting our pitch depending on who we were talking to. Presentations were either broad, or focussed on design and code, but they all emphasised the value of design systems. For example:

Product managers, leaders, and heads of departments...

...care about how fast the team can ship products, and the impact the work has on business goals, sales, reports, and analytics.

Sell them on how a well-established design system allows for a faster, more efficient shipping cycle. Convince them of how taking the time to create a design system now will enable faster product releases and iteration, as well as a better user experience going forward. In a ‘perfect world’, this increases the potential for growth, sales, and analytics trending in the right direction.

And remember, a really successful system will also unify the teams working with it, creating a healthier work culture, staff retention, and tool for recruiting talent. The leaders in your company should care about these things!

Engineers...

...care about a unified code base, version control, consistency, performance, organisation, efficiency, and naming conventions.

Sell them on how design systems will help bridge the gap between designers and developers, and their positive impact on all the engineering factors they care about. If you’re not comfortable speaking their language; work with a developer on these engineering pitches.

Designers...

...care about aesthetics, brand, typography, colour, user experience, and shipping beautiful products, which stay true to their original vision.

Get them excited about how great the end product will look! Anything relating to the front-end being a ‘pixel perfect’ reproduction of their designs will be music to their ears. Be careful not to scare the more visual designers on your team, as some will view design systems as a threat to their creativity. Instead, focus on how quickly and efficiently they can design with pre-defined system components in their design tools of choice. The system will curb the introduction of rogue elements like buttons and form inputs, freeing them to focus on more interesting tasks like problem solving, layout, and user experience. The best designers on your team will be excited about this, and it will be a valuable learning experience for everyone else.

We’re all in this together

For all parties, be sure to pitch the importance of this being a collaborative team effort. Some may worry their voice won’t be heard, or that the system will go against how they like to work. A good design system won’t be designed and built by only a few people, then closed to changes from everyone. It will evolve. It requires everyone’s input and support, over time, in different capacities.

It will help everyone, and it will help the business. It’s something everyone should be proud of.

The following screenshot is from a deck I used to present to an executive when I was the System Design Lead at a previous employer. This executive was not a designer or a developer, but a powerful individual with significant influence and connections. A fellow design lead at the company told me this person would be interested in the digital brand guidelines I was working on, and could be a powerful ally for our design system initiatives. With their advice, I contacted the executive, set a date/time/place for a meeting, and started preparing this presentation.

This particular stakeholder didn’t know or care about what designers were doing in Sketch, or how developers were refactoring code. The way to reach this person was to pitch:

• What is the value of a design system to our company?
• The design system saves us time and money because _____ (e.g. we can ship updates faster, as engineers won’t have to write as much new code).
• The design system makes us/you look good because _____ (e.g. we can ship more updates per quarter, which could have a positive impact on sales).
• The design system sets us apart from our competition because _____ (e.g. our competition doesn’t have a consistent brand across their digital platforms, so we can stand out from the crowd with a stronger brand and user experience).
• Our competitors are doing _____, which helps them because _____. (e.g. They are publicly sharing their design system, which helps them recruit a higher-caliber of designer and engineer).
• How can you help us achieve this? (e.g. We need your endorsement. And who else do you recommend we talk to, to make this happen?).

Prove to them how what you’re pitching helps the company, and makes us (i.e. the stakeholder and the company at large) look good in the process! It’s hard for managers and executives to turn down something that makes them look good, when often all they have to do is say “Yes” and grant you an endorsement and a few connections. It’s a win-win for everyone.

At what stage do you sell?

In terms of the process, ‘selling a design system’ doesn’t belong at the end — because you don’t want to put in a lot of work only to be told “No” by someone higher up the chain of command. And it doesn’t belong at the start, because you don’t know yet what you’re selling. You first need to understand what a design system is, why it’s valuable, and what problems you’re solving in order to build and present your case.

The key thing to understand is:

Selling a design system isn’t a stage of the process. It’s ongoing.

You need to always be advocating for the system, or it will fail. Even — and perhaps especially — after you’ve successfully designed, built, and integrated the system.

All it takes is a powerful stakeholder to come on board and decide they don’t like a systematic approach to design, and the whole thing comes crashing down. Believe me, I’ve seen this happen. However, if you’ve been gathering support throughout the conception and creation phases, the design system will have a better chance of weathering organisational changes and individuals who oppose it.

The importance and quality of ‘the sell’

You need a convincing pitch to sell your vision, and you need to present it passionately and concisely — as some stakeholders’ time and attention can be limited.

At large companies with more complex hierarchies (and the politics that come with that), I like to think of it as being well armed before going into battle. You stand a much better chance of being taken seriously if you build up an arsenal of data, problem statements, and industry examples to demonstrate your points, as well as having the backing of a small army of supporters all champing at the bit to get started.

If you believe in design systems and want to see one thrive at your company, you need a compelling case that’s tailored to your business, team, and user needs.

It’s easy for higher-ups to say no. Very easy. As I mentioned earlier, creating design systems can be involved, and therefore expensive to the company.

Sometimes, projects like design systems are rejected with good reason. The more experience you get in the tech industry, the more you understand the importance of saying no. Creating new things just for the sake of having something new often leads businesses down the wrong path. Just as we shouldn’t create new product features because one person ‘thinks it would be cool’, we also shouldn’t create a design system ‘because everyone else is doing it’.

So, if you believe in design systems and want to see one thrive at your company, you need a compelling case that’s tailored to your business, team, and user needs. This helps your stakeholders to make informed decisions.

In the “Getting Started” chapter [of this book] we’ll cover how to build a compelling case by investigating what problems exist in your product and team processes, and communicating how a design system can help to solve those problems. Matching problems to a potential roadmap of solutions can be a compelling way to gain stakeholder support and turn “No” into “Yes”.

A word on office politics

Every stakeholder wants something different. Some focus purely on the business needs. Some care most about customer happiness.

And — let’s be honest — others may be driven by a selfish motivation. I’ve seen employees driven by something as trivial as taking credit, winning an award, or gaining a portfolio piece. Others have more toxic incentives, and will make poor decisions to ‘earn’ a promotion at the expense of their team. Unfortunately, you have to navigate these people and work around them, or find a way to make their goals fit with your broader goal of creating better products.

Here’s my advice on office politics: try to understand what’s really driving everyone involved in your product.

Your primary goal should be to rally those with pure motivations to join your cause.

• For stakeholders who care about business needs; play up the speed of iteration that comes with design systems.
• For designers who want to make something beautiful for your users; advocate for the quality output that comes with a well-crafted library of elements.
• For developers who want well-performing code; celebrate the efficiency of a consistently designed interface.

If you are passionate and well-informed, you’ll build a team of like-minded advocates that can defeat any of the self-involved office politicians who might try to stand in your way.

It may also be possible to convince those who have selfish motivations that a design system will make them look good, help them win an award, or gain them the promotion they’re after — in which case they could become its biggest champion. The point is to understand what’s driving your stakeholders, and work with them accordingly.

Creating a design system is a process. It’s a long-haul — and often expensive — project that takes up a lot of time and resources which involves more people in your organisation than just designers and developers.

It stands to reason that design systems are easier to implement at smaller organisations. A smaller design team will create less rogue design elements, and a smaller engineering team means less friction in the code base. There are also fewer people with the word ‘manager’ in their title, which often means there are fewer opportunities for things to go wrong. There’s less need for buy-in or permission, which means there’s greater potential for faster progress.

Larger organisations are a different animal. More hierarchy means more channels for decisions to go through to be approved and implemented. Think about what happens when there are dozens — even hundreds — of designers, engineers, and managers split across multiple teams, all working on the same family of products. Some of those teams may even be remote, nationwide, or international.

It gets complicated.

This isn’t intended to scare you, but rather to provide a dose of reality from the trenches of my real-world experience. As I said in the beginning of this chapter, we romanticise about design systems, and we make it sound so easy. Hopefully, now that we’ve explored some of the challenges of creating a design system, you’ll be better armed to deal with them as they arise.

I admit selling a design system is hard work, and it’s not the sexy part that gets shared on Dribbble or Medium, but it’s important.

In summary

• Start small.
• Be prepared.
• Identify the problems you’re trying to solve.
• Do some (enough) impressive design and build work to get people talking.
• Make friends and build a team of people excited to work with you.
• Come up with a cool name, and create a sexy presentation.
• Tailor your pitch according to your audience.
• Earn trust and support.
• Be an advocate and a guardian for the system, and inspire others to do the same.

Interested to read more? Buy the book here