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:
Bring all product screens in a single Figma file
Use Style Organizer, a Figma plugin, to identify all colour styles and all type styles used in your screens.
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:
Which components already exist in the codebase
How many hardcoded values exist in the codebase
The audit enables your team to:
Prioritise short-term and long term goals for your design system
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.
To build the foundation:
Define a basic colour palette and a typescale.
Create tokens for colour and type.
Set up the 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.
To build components:
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.)
Build components in code. If the codebase has some components and it is good, you can also extract code.
Test and quick review components in a playground/showcase app.
Building one component should take 2-3 days.
To integrate the design system in the pilot flow:
Update the flow’s design with these components and tokens.
Introduce theming and the design system library in the app’s code.
Integrate these tokens and components in the pilot flow.
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:
The components that can be used to build 80% of the app
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 be used to build 80% of your app.
For the pilot, designers defined just anatomy, behaviour and a few variations. For the MVP, that isn’t enough. Each component should have:
Usage guidelines on when to use which variation
Engineers build components in the library incrementally by:
Putting in a base component
Adding style specifications to create variants
Testing and releasing for integration.
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.
Curious about our approach to building design systems? Book a call with Sanchita to learn more!