At one of India’s unicorn startups, the engineering team didn’t ship a new feature for a whole year. Why? They realised they needed a design system and they dedicated engineering capital towards building and integrating it. But not all design system teams can do that. The more common story is this: most teams don’t have the luxury of halting feature delivery. 

If design systems have to be built “on the go”, a smarter and more modular approach is needed. I believe building a design system doesn’t have to be an extensive or expensive process. You could start with just an MVP. Here’s how you can do that: 

‍

Step 1: Audit your product 

‍

Time needed: 1 week

Before building a design system, the team should know why it’s important.

An audit of your design files and your codebase will help identify what you’re trying to solve by implementing a design system. It could be one of the following or a combination of multiple: 

• Consistency within the product
• Consistency across multiple products
• Consistency across platforms 
• Faster feature design and development 

‍

To audit your design files:

1. Bring all product screens in a single Figma file
2. Use Style Organizer, a Figma plugin, to identify all colour styles and all type styles used in your screens.
3. Identify standard or core components that have maximum reuse across the app. For a food delivery app, it could be an Add button. For a fintech app, maybe an input field is reused a lot. You can use this sheet to map component usage. 

‍

To audit your codebase, do a static code analysis using linting. This will tell you: 

1. Which components already exist in the codebase 
2. How many hardcoded values exist in the codebase 

‍

The audit enables your team to: 

1. Prioritise short-term and long term goals for your design system
2. Identify if tokens, components and variations of components exist across Figma and code 

‍

Step 2: Run a pilot 

‍

Time needed: 3 weeks

After the audit, the next step is to learn what kind of design system your organisation needs.

If the bottleneck for your organisation is consistency, build an exhaustive set of tokens and just a few standard components. If the bottleneck is speed of feature delivery, build more components and just a few colour and type tokens.

From all flows in your app, identify one for a pilot. This flow should utilise 3-4 components which are reused and use colour and type tokens. It should be technically feasible to implement the design system for this flow. In the component sheet, add an estimate of how much time implementation requires and pick the pilot flow. Dan Mall has a detailed guide about how to select pilot candidates that you could refer to.

For the pilot, the team that is building the design system needs to work closely with designers and engineers who own the pilot flow.

‍

Foundation 

To build the foundation: 

1. Define a basic colour palette and a typescale. 
2. Create tokens for colour and type. Our team created Weaver to automate token generation in code.  
3. Setup library across frontend platforms by using a combination of CI checks and a clear versioning strategy (refer SemVer) for releasing. 

This should take 4 days. 

‍

Components

To build components:

1. Define the anatomy, behaviour and a few variations of three components. (Note: all variations of a component are not needed for the pilot. For example, for a button, build only the full width button in all states. You don’t need to build a medium or small button.) 
2. Build components in code. If the codebase has some components and it is good, you can also extract code.
3. Test and quick review components in a playground/showcase app. 

Building one component should take 2-3 days. 

‍

Integration  

To integrate the design system in the pilot flow: 

1. Update the flow’s design with these components and tokens.  
2. Introduce theming and the design system library in the app’s code.
3. Integrate these tokens and components in the pilot flow. 
4. And finally, release the app to users! 

Integration should take 7 days. 

The pilot gives the team an early win and they can now create a roadmap for the design system. That means identifying: 

1. The components that can be used to build 80% of the app 
2. The technical approach to integrating the design system with the app codebase 

‍

Step 3: Build the MVP 

Time needed: 4 weeks

Thanks to the pilot, your team has a shallow version of the design system and knows how to use it and integrate it across design and engineering. It is time to build the MVP. 

Along with 3 components from the pilot, pick another 2 or 3 components that have high reusability and can build 80% of the app. 

For the pilot, designers defined just anatomy, behaviour and a few variations. For the MVP, that isn’t enough. Each component should have: 

1. Anatomy 
2. Behaviour 
3. All variations 
4. Usage guidelines on when to use which variation 
5. Component specs 

Engineers build components in the library incrementally by 

1. putting in a base component
2. adding style specifications to create variants
3. testing and releasing for integration. 

Build the rest of the components incrementally. A first, working version of your design system is ready! 

‍

Using the “MVP” design system

As your team starts using the design system, take the product or feature roadmap into consideration. Let your product or feature roadmap dictate where you’ll start using the design system. Ideally, you’ll begin with high-priority features and designers and engineers should use components and tokens to build those flows. Continue to integrate with more pilot teams to see the impact of your design system.