From zero to design system
A step by step guide to launching a design system at a startup
This article is part 2 of a 2 part series on our experiences creating our Retailer design system at Trouva. Read Part 1, “First the Product, then the Design System — The story of building a design system, the startup way”.
Design systems don’t emerge overnight. They require a lot of planning, team buy-in, and constant nurturing. For many startups, it’s not realistic to build a product with a design system from the beginning — something we experienced with our Retailer product at Trouva (which you can read about in more detail in Part 1 of this article series.) But there will inevitably come the point when it’s no longer possible to work efficiently or build scalable products without one.
Adding a design system into an existing product is a difficult process. Unpicking the inconsistencies and years of ad-hoc design iterations to emerge with structure, logic and rules can feel at times impossible, but rewarding when done well.
This article takes you through the practical steps we went through at Trouva to design and implement a design system in our Retailer product, a B2B tool used by hundreds of independent boutiques to manage their orders, listings and inventory for our consumer marketplace.
Phase 1: From inventory to blueprint
Before we were ready to jump in and start building our design system in code, we began by creating a blueprint vision for where we wanted to get to.
When it came to figuring out what our design system would include, we initially assumed that we needed to begin small — define the rules for a single foundation style or component, build it into our product, then move onto the next. This is the startup way, after all — start small, figure out what works, and continue to iterate. It’s a philosophy that underpins all our design and development work, as it allows us to release changes and get feedback from our users more quickly.
The trouble with this approach is that a design system has so many inter-dependencies. Sure, you can start small — pick a component, design the rules, then build it into your product. But what happens when you move to your next artefact, and you realise the rules you defined for that first component won’t translate to the next? When you are dealing with an existing product, there’s an entire ecosystem to think about; so many existing UX patterns and components at play that need to be broken down, scrutinised, and stress-tested against one another.
We realised that whilst this ‘start small and iterate’ approach would work well for building our design system out in code, we needed to pause, take a step back and allow ourselves to think broad. We needed to create a blueprint for where we wanted to get to, before we could begin development.
Step 1: Create an inventory of your existing styles and components
We worked in Figma, our design tool of choice, to gather all existing styles and components that lived in our product. With everything laid out in front of us, we were able to understand what we were dealing with; how many colours we were using, how many different patterns, how many small variations of the same component.
Step 2: Question, reduce and streamline
The next step was to scrutinise that inventory, with the aim of boiling it down to its core essentials. Take these colours — we could find an instance of every single one in our codebase, each being used for no particular reason other than there weren’t colour guidelines set in stone to deter random variation.
We questioned what each was being used for and tried to understand if there were multiple colours all doing the same job. Slowly but surely, we began to reduce the numbers of colours we were using, remove minor and needless variation, and boiled this down into a more logical and manageable palette.
By asking ourselves the following questions, we can decide which variations to remove or combine, in order to bring consistency to our product and simplify our design process:
- What is this style or component used for?
- If you were to describe what this style or component does to a colleague, would they understand it easily?
- Is it doing a similar job to another style or component?
- Do we really need this style or component?
- How many variables or states of a component do we need?
- If we reduce our styles and components, will it limit the UX or functionality in any way?
- Are our interactions consistent across components?
- And, are we applying responsive guidelines consistently?
The aim is only build components you actually need and remove needless variation.
Step 3: Stress-test your inventory
Once we were happy with a component or style, it was time to stress-test it in-situ, alongside our other design system artefacts. At this point, we could begin to understand if our design decisions made sense within our wider ecosystem.
We made a lightweight prototype of our product using only design system artefacts to get a feel for how they co-exist and where there were areas of friction. We made sure that we were using spacing, colour, type, elevation and shape consistently across all components and layouts, and that these rules were not only logical and memorable but reflected our brand personality.
We realised that some of our rules were either too restrictive or not restrictive enough, and needed to go back to the drawing board to establish rules that worked universally. For example:
- Our strict 8px spacing rule didn’t work when stress-tested with densely packed table layouts and smaller components. We needed to adapt it and allow for more flexibility.
- Our colour palette included brand colours that were very close to our error, warning and success colours, which created confusion when used together in a layout. Colour was being used both as a communication device as well as a brand tool — we needed to question what we were using colour for, and define a palette that was clear and easy to use.
- Our hover, active, focus and disabled states were inconsistent across our form and button components, which prompted us to go back and re-assess our rules.
When we began to stress-test our design system we were able to identify areas of friction — styles or components that didn’t work well together, and guidelines that were overly complicated. This stage allowed us to simplify, streamline and bring clarity to our design system. It gave us confidence that each individual artefact worked in harmony with one another and could be committed in code without having to back-pedal at a later date.
Phase 2: From blueprint to code
Now we had our blueprint for where we wanted to get to, it was time to start thinking about the road to implementation, and to go back to our ‘start small and iterate’ mantra.
Setting expectations
At this stage, it’s important to be realistic with what you can achieve. Whilst we can aspire to build a sophisticated site like Lightning, Material or Carbon, design systems aren’t born this way and take time and effort to evolve. Starting out by trying to build this final product will surely overwhelm the team and paralyse any progress.
In its infancy, a design system may certainly live purely as code, and over time it can grow in sophistication. It’s important to separate the end vision from what’s possible now, and plan the small steps you need to get things underway. At Trouva, we use Storybook to document our live design system, and keep our future iterations and more detailed documentation in Figma.
Figure out your implementation plan
When adding a design system into an existing product, you have to think about the strategy for cleaning up your code and replacing what you have with new design system artefacts. At Trouva we debated two different strategies:
Strategy 1: Adopt new design system henceforth
With this approach we would simply begin using our new design system in all new pages or feature created from now on.
- This may add additional time to the workload, as it’ll require the creation of components and style variables.
- Each new page or feature will feel inconsistent with the rest of the product for a while.
- This approach doesn’t work as well if you’re iterating on an existing page or component, as it may mean rebuilding that page or component from scratch.
Strategy 2: Cleanup artefact-by-artefact
With this approach we would create standalone tasks for cleaning up specific styles or components across the product.
- This separates design system work from project-specific work.
- Avoids inconsistencies within a component, e.g. you won’t have new and old button components co-existing within a product.
- Involves a lot of manual cleanup, hunting down rogue styles or components.
- May be more suitable for a larger project that has more extensive cleanup.
- May create some inconsistencies between design and development, especially if design is working to the new design system styles and component. Communication is key here.
At Trouva we opted for the second approach, as it allowed us to separate our design system work from our other projects and balance our workload.
Nominate your first candidate. Implement. Repeat.
Since we chose to launch our design system artefact-by-artefact, we started by reviewing our styles and components and made a shortlist of candidates for development.
We wanted to begin with something that we perceived as relatively simple in order to help build our confidence and stress-test the development process, so we decided to prioritise components that aren’t used extensively or in key flows, to allow us to keep initial development and QA time to a minimum.
Once we release a design system change to production, we repeat the cycle, selecting our next candidate to define, build and clean up. In this way we can see results sooner and keep momentum up. Over time, we’ve been able to advance to more complex or critical components with greater confidence.
Conclusion
Adding a design system into an existing product is certainly not a quick win. At Trouva, 90% of the time spent on this project to date was planning, and only 10% on execution. But taking the time to create your vision, align on your goals and get the team on the same page is vital if the design system is going to stand the test of time and evolve into something indispensable.
Our biggest learning was understanding when to think big versus when to start small. We allowed ourselves the chance to create a blueprint and a long-term vision for where we wanted to get to, but when it came to building our design system into our product, understood that we needed to switch gears, make small and incremental changes, and focus on the short-term wins that would propel us forward.
This article is part 2 of a 2 part series on our experiences creating our Retailer design system at Trouva. Read Part 1, “First the Product, then the Design System — The story of building a design system, the startup way”.
