First the product, then the design system
The story of building a design system, the startup way
This article is part 1 of a 2 part series on our experiences creating our Retailer design system at Trouva. Read Part 2, “From Zero to Design System — A step by step guide to launching a design system at a startup”.
When a product is built without a design system, the idea of retrospectively adding one in can be daunting. A design system can seem like an abstract beast at this stage, a set of rules and guidelines that do not yet exist in theory, let alone in code. The challenge of picking apart a product to its most essential components, and finding inherent structure in what may feel like chaos, can make even the most methodical product team break out in sweat.
Design systems: to build or not to build
Design systems have become accepted as a standard for product design and engineering, and larger organisations will have entire teams dedicated to their maintenance and growth. The benefits of building out a design system are countless:
- For designers and engineers, a design system creates a common, shared language, which aids decision making and prevents snowflake design.
- For the user, it helps to creates a more consistent experience, with fewer patterns to learn.
- In the long term, it helps to establish a more scalable and holistic mindset, and enables products teams to work more efficiently.
To name just a few.
But for startups, it can be unrealistic to build a product with a design system from the beginning. For a start, resources are low and reaching product-market fit quickly is critical to survival — priorities need to be made. And secondly, a product changes so much in its early years that being able to adapt quickly is essential — a design system may be too restrictive.
Building a product without a design system — a necessary evil
At Trouva, we launched our Retailer product — a tool used by hundreds of independent boutiques to manage their orders, listings and inventory for our consumer marketplace — without a design system for these exact reasons. Our goal was to create a functional B2B tool, first and foremost, which we could quickly iterate on as the business grows. Making the time to build a design system alongside our product was unrealistic, and the right strategy for us at the time.
But the effects of this have inevitably begun to surface over the years:
- Design inconsistencies are aplenty… who needs one shade of grey when you can have 50?
- Components have been designed and built from scratch that needn’t have been.
- Interactions vary from one page to another; it can feel like two products stitched together at times.
- Our code gets refactored out of necessity more than we would like.
- Precious time is spent repeatedly solving the same problems or making decisions that a design system would address for you.
That’s not to say that we haven’t built a great product or that we’re not proud of what we’ve achieved. But it was becoming clear that our lack of design system was beginning to impact our ability to work efficiently and learn fast, and that as our product grew these problems would be exacerbated.
We had an ever-growing pile of design and tech debt staring us in the face that was distracting us from more worthwhile tasks, and this was no longer something we could sweep under the carpet with another code refactor. At some point, building a design system becomes a necessity and not a luxury; as the business grows and matures, your products must do the same.
Design systems begin with buy-in
Once we had reached the realisation that we needed to start building a design system, there came the question of how to actually do this. A huge amount of planning, organisation, research and technical setup is required before you begin to see anything manifest itself in your end product. (I go over the practical steps we took to start designing and building out our design system in my follow up article, “From Zero to Design System — A step by step guide to launching a design system at a startup”.)
But before you get to the point where you can begin to define and document your design system, and commit this in code, you need buy-in. A design system is a shared tool that changes how designers and developers work both individually and together. It requires us to all adopt a new shared language, and this only works is everyone is on the same page.
Some may not understand how this differs from using brand guidelines, whilst others may worry it’ll restrain their individual creativity and freedom. Higher up the organisation, there may be concern about how this work will contribute to core business goals. It’s certainly not uncommon to hear these concerns; design systems prefer to lurk behind the scenes and you don’t often understand their true value until you’ve worked with one yourself.
It’s useful to take some time to talk about design systems with the wider team, to educate others about the benefits, and to create an open space to talk and listen. This process should be collaborative, educational, and focus on what you’re trying to achieve for the team and the business.
Justifying resource
We justified allocating resource to our design system by the positive impact that it would have on our product, the team and ultimately the business — but we also needed to make sure this wouldn’t impact our short-term output.
Emphasise efficiency. From the outset, a design system allows both design and development to work more efficiently and achieve a more reliable and consistent result. Each new addition to the design system, no matter how small, reduces superfluous decision-making and prevents the buildup of unnecessary design and tech debt. And with time, this allows us to focus more time and energy on building higher quality, scalable and future-proofed products, and therefore have a greater impact on business growth.
Once we get past the tedium of building the same thing over and over again we can focus our energy on more worthwhile tasks like accessibility, performance, and iteration. — Micah Godbolt
Balance workload. We knew that dedicating entire sprints to our design system was unrealistic, and we needed to find a way to balance our workload so that we could continue to deliver on business goals. We allocate a small percent of our weekly sprints to design and tech debt, which allows us to make weekly, incremental progress and keep momentum up, without disrupting our key projects.
Find the right timing. For us, timing was key to getting the ball rolling. As a retail organisation there’s natural peaks and downtime, and trying to approach this work in the peak of pre-Christmas trading would have been a non-starter. Come December, we tend to shift focus towards longer-term vision work and addressing our debt, so this was a key opportunity for us to begin planning our design system work.
Conclusion
For any product built without a design system, there will come an inevitable point where it’s no longer possible to continue working efficiently without one. But setting one up is not a simple task and requires:
- Buy-in from the team.
- An ability to balance long-term vision with realistic, short-term goals.
- Collaboration and dedication.
Design systems are never finished and are easy to neglect. They also won’t change your product overnight. But, if nurtured, they can transform the quality of a product and the way teams work together.
This article is part 1 of a 2 part series on our experiences creating our Retailer design system at Trouva. Read Part 2, “From Zero to Design System — A step by step guide to launching a design system at a startup”.
