How to get your company's first design system off the ground.

Design systems can be a great enabler for product teams to boost their efficiency and productivity. The question of when to create one is interesting; for smaller teams needing to work fast, the time investment required might not be worth it if your current process is working. Design systems should add value and not be created solely for the sake of having one.

However, as product teams grow, some common pain points often emerge: velocity slows, developers struggle to find designs and teams also see the first signs of design and technical debt. Is it the right time to introduce a design system? Or is it a big ask and just too much for a busy team?

Creating a design system is a journey, not a destination. It's a living, evolving entity that will grow and adapt with your team and product, as small first steps gradually build alongside evolving needs.

In this article, we’ll explain why it’s easier to start a design system than you may think, and give you a few tips to kick off.

‍

What is a design system?

There is no hard definition of what a ‘design system’ is. But we think there are a few essential elements:

• A design system is more than a UI kit in Figma. It's a set of standards for both UI design and application code, along with components that unify both practices.
  

• Design systems exist (and are used) across departments, from design and development to product marketing.
  

• As a design system grows, it applies a tight process from design to code, including governance around rules and documentation.
  

• There are dedicated contributors and editors who grow and maintain the design system.
  

• The design system is a living document that is constantly changing as part of your product, with metrics and KPIs to track usage and success.

‍

That does imply lots of moving parts, which can seem overwhelming when you get started. It’s also a concept that can be challenging to explain to stakeholders. 

And that’s what we often see: teams initiate a design system as a large project with difficult-to-quantify benefits requiring broad input from a multifunctional team that’s already busy to the hilt. Throw in “Atoms”, “Molecules” and “Organisms” and you just don’t stand a chance.

But what if you can make useful progress with a practical design system that contributes to project execution – without kicking off a huge project?

Starting softly

Creating a design system is like creating a product, it's a spectrum where you start small and build and iterate as you grow. Product designers will know how this works: faced with an endless list of possibilities, progress depends on focusing on a more limited set of priorities. Starting your design system is just like that.

Design systems occupy a specialist niche, serving internal users who then assist external users. This concept can be abstract and challenging for many to grasp. And as always, when stakeholders do not grasp what you’re trying to do, the answer quickly becomes no. 

So when you kick it off, don't overcomplicate what you’re trying to achieve, instead make it easy for contributors to get on board. Try broaching the topic as a simple project, just a quick set of core components – starting with the design elements used on most screens, for example.

Explain how a bit of work now will make the entire team ship way more efficiently. After all, cross-team buy-in is a huge factor in making your design system successful, and overcomplicating matters can block buy-in.

Key first steps

Make a start by focusing on your team's immediate needs without getting bogged down in the complexities of a full-fledged system. 

There are several design system management tools available, choose a tool that fits your needs and provides a good user experience for your designers and engineers. Think about the following:

1. Consider what a minimum viable design system looks like and what documentation you really need.
   
2. Clearly communicate the value, such as consistency and shipping faster, which results in less time spent in QA.
   
3. Get point people on board without overburdening their time.
   
4. Begin with something manageable, like a Figma UI kit and a process for component approval.
   
5. Approach it like a product - who are your users? Designers? Developers? Both?
   
6. Just as with a product, have a rough plan to scale – a pathway into the future.
   
7. Have some loose metrics to measure success (these can be very basic, but they’ll show stakeholders progress).

On the Journey