How we think of design systems at Rangle

A design system is a systematic and modular approach to product design and development, complete with guidelines, principles and philosophies. At Rangle, we break this down into two parts: systems and operations.

• Systems include design kits, component libraries and documentation sites.
• Operations include automated workflow, team collaborations, and adoption.

Together, systems and operations empower teams to deliver new and innovative digital products for customers.

Design systems are essential for digital-first businesses at scale. There is no good alternative.

What is the Design System Death Spiral?

The Design System Death Spiral is a common pattern we see among companies which seek help with their design systems.

There is initial excitement and planning early on, loads of components are built, but things stall. No one is using the components. Adoption is flat and remains in one team; other teams start choosing alternatives to the design system. Funding and interest dry up; perhaps there are layoffs, and the cycle starts over.

Like any product or start up, adoption is key to survival.

Why does this happen?

As companies start to scale and the number of teams increases, two things happen: (1) productivity declines; and (2) customer experience suffers.

Productivity decreases because of:

• Time-consuming specs: To communicate design expectations, more and more detailed user stories are written to capture possible UI behaviours.
• Duplication of work: Different teams aren’t talking to each other, so they end up building the same UI components.
• Increased design QA work: The only opportunity to verify UI behaviours occurs at the end of build cycles, resulting in consistently high QA load.

This decrease in productivity compounds over time and is unavoidable, unless you have a design system.

Customer experience also suffers because of:

• Design fragmentation: Consistency tends to decrease with more designers and developers solving the same problem in different ways without reusability of that solution.
• Lack of specialized skills: As your company scales, it is difficult to maintain the bar on talent as high as it needs to be in the early stages. Skills like the ability to design and build performant and accessible UIs are rare and tend to be poorly represented in individual teams.
• Lack of cohesion:  With an increasing number of people working on different parts of the experience in isolation, the integrated experience often shows gaps. This lack of cohesion starts to show in customer feedback, and executives wondering why there are so many different ways to do something in their applications.

Three Truths about Design Systems

Truth 1: Design system initiatives have a limited time to create an ROI

Successful design systems are backed by their organizations.

The size of funding should match the stage of the design system’s evolution. Too much too soon can be just as detrimental as no funding. Why? Because the design system gets crushed by the weight of expectation and communication overhead.

It is helpful to think of a design system as a product within a startup that is funded in stages. If the team building the product doesn’t show progress at any stage, they don’t move forward and funding moves to another initiative.

The team building the design system should show value, show it fast, and have an MVP mindset.

Truth 2: The value of a design system is realized when consuming teams ship to production using its components

Design systems are only valuable if it helps teams ship things to production. It has to be part of a live product to realize its value.

Consistency, branding and UX are not valuable in themselves and are difficult to link to ROI on the design system funding. Design systems need to make teams go faster by avoiding rework. In this way, design systems are really communication tools, getting teams which don’t normally talk to each other to build products in the same way.

A common flag we see is that teams think they need to build a complete design system before it can be used. It’s more important to build just enough infrastructure, processes and foundational items to deliver what the pilot team needs.

Truth 3: Getting teams to ship using a design system is an exercise in change management and requires an adoption strategy

The most challenging aspect of design systems is the human aspect. It doesn’t matter how good your design system is if no one uses it. Design systems are designed to change the way people work; they are a new way of designing and developing products.

This is why it is really important to identify which teams to partner with early on. A useful analogy is the technology adoption life cycle. The first challenge is finding the innovators (or early adopters) who are willing to take a risk on immature technology (your pilot team). The second challenge is being able to bridge the chasm between early adopters and the early majority.

Avoiding the Death System Death Spiral

The death spiral happens when the design system doesn’t get sufficient traction; it becomes irrelevant, closes down, only to be restarted in a second attempt. Again and again, the cycle may repeat itself to no avail.

In order to overcome the two challenges, it is important to (1) start right; and (2) scale right.

Start Right: The Pilot Team

Focus on adoption at all costs

Identify your early adopters, your pilot team, the ones who are enthusiastic about the design system. You need to build exactly what they need at exactly the right time to maximize impact and the probability of that team’s success.

In order to do that, you need to understand the problem they are trying to solve, who they’re trying to solve it for, and what their plans are in order to anticipate what they need. Trust builds traction.

Treat your design system like a product

When you treat your design system like a product, you build enough to ship the component the team needs. This allows you to build working software and get real feedback after delivery.

Do the “shake out:” select the thing you want to build, figure out exactly what you need to build that component and build just that. For the next component, you will have to build only what you don’t already have. This process repeats, and eventually you will need to build fewer and fewer things. Your design system starts to grow organically around this concept of value.

Move from pushing to pulling

In a brand new design system, you are pushing your pilot team to use the components. Embed yourself with the consuming team’s roadmaps, and establish trust by shipping what they need in time without blocking their ability to deliver.

The goal is to move to a pull process where people trust you enough that they start requesting things from you. This frees your capacity to run the prediction game on another team.

This is an exercise in building trust that you can deliver the quality and the thing needed, which is a critical aspect of design system success.

Scale Right

Establish a Beachhead

The struggle we see often comes when trying to scale the design system after the pilot, i.e. crossing the chasm. The early adopters and their needs are very different from the early majority and you really have to think about that when scaling. Think small, think compounding interest over time. By doing that shake out process, your design system grows organically around the concept of value. This is the beachhead mentality.

To scale, you repeat the same process with the next team. You embed with the next team, predict what they need and supply it. At this point, you have some components already, so ideally you are getting faster at building the right thing.

The teams you’re scaling to are likely not the most enthusiastic about design systems and they will have more technical challenges.  Focus on getting a stable product, and onboarding just the right number of teams you can continually support.

Do not overstaff your team beyond the roadmap that is populated by the pull process and the prediction game. This is a waste of budget. Building for the sake of building is not efficient.

Prioritize stability

The early majority has a significantly lower tolerance for issues than the early adopters. Breaking changes decrease confidence, damage reputation, and divert the design system team’s effort to supporting existing consumers instead of scaling to new ones. Once you scale, you can’t get away with manually maintaining your processes anymore.

You have to spend time carefully crafting APIs, because changing APIs is expensive. Keep in mind backwards compatibility. Once someone starts using something, you can’t easily change it. If you do have to change APIs, make sure you have a duplication process.

Ship at high quality and avoid alienating the consuming teams.

Drive adoption

Make the design system easy to use, offer coaching and support, and keep marketing what you’re doing.

• Use the “least astonishment principle.” People should be able to guess how to use another design system component based on the previous ones they’ve interacted with. This reduces support needs.
• When it comes to support, documentation is not the goal; supporting consuming teams is the goal. Keep humans available for questions, and documentation to address frequently asked questions.
• Keep reminding people of the achievements and cool things you’re doing to maintain momentum to expand to other teams.

Key Takeaways

Design systems are essential for digital-first businesses at scale. There is no good alternative.

Like any product or start up, adoption of the design system is key to survival. The death spiral happens when adoption lags.

Start right by treating your design system like a product and focusing on adoption at all costs. Adopt a MVP mindset; ship right and ship fast. To scale right by repeating the process with other teams. Focus on getting a stable product, and onboarding just the right number of teams you can continually support.

Change management is hard. Approach it deliberately and focus on supporting the teams you onboard.