Taming the Chaos of Hypergrowth: Our Lean Approach to Building a Design System, Part — 1
Design systems often represent an aspirational milestone for product design teams. But they’re often seen as an all-or-nothing project — something that takes months of planning and effort, while day-to-day product delivery suffers. When everything is moving at breakneck speed, it feels risky to divert resources into building a design system. But is it really?
In 2022, Jiva was deep in the throes of hyper-growth, onboarding new team members almost every week. The chaos hit every part of the company, and the design team wasn’t immune. Work was being duplicated across pods, our user experience was inconsistent, accessibility needs were being overlooked, and our app’s performance was lagging behind.
At the time, we had a Figma-style guide, but it simply wasn’t enough. We needed more than a set of visual guidelines — we needed a comprehensive design system that could help us keep up with the rapid growth without adding friction to the process. And yet, we faced a tough constraint: our design team was tiny (and growing), so we had to approach this in a lean way.
How We Brought Order to the Chaos
We started by establishing tokens — the building blocks of our design system. Colour and type tokens became the quarks that would hold our design system universe together.
We chose only these tokens because they gave the team the autonomy to move fast while giving us the flexibility to maintain consistency where it mattered. All without locking us into a rigid design expression. These tokens could be used to create design “atoms” and “molecules” across different platforms, allowing our components to adapt naturally to each platform’s native constraints. This flexibility was crucial. It allowed teams to move faster, design for different use cases, and scale without sacrificing brand coherence.
For example, in 2024, when we built react native apps by adopting Paper, our tokens could easily be ported to make Paper-based apps feel like a Jiva product. In tools like Retool, we only ported over colour tokens because that’s all we needed to ensure visual consistency. This token-driven flexibility became the key to scaling design without getting bogged down by unnecessary rigidity.
For Typography, we decided to lean on system defaults. On Android, by switching from Mr. Eaves to Roboto, we addressed the legibility issues we had previously faced, particularly on budget Android devices. However, this wasn’t a simple swap. We had to design a type scale that ensured our transition was seamless and consistent across various text elements, from headings to body text.
Colour, on the other hand, posed a different challenge. Our original primary colour (#0AB858), vibrant as it was, didn’t meet WCAG contrast requirements, especially for text on white or green backgrounds in smaller font sizes. We knew this was a dealbreaker for accessibility.
Achieving the right contrast was tough — white on green rarely provides the necessary legibility, particularly on low-resolution displays. Finally with the help of Envoy’s post on building an accessible colour scheme, Stark’s handy plugin and Tailwind Color Generator plugin, we found a modified shade of green(#006E25) that worked visually and was AA compliant. But colour wasn’t just about picking a new shade; we also had to write detailed guidelines for how and where it should be used to maintain consistency and accessibility across our products.
You might think that once we had solved these core problems, building out the Android design system would be straightforward. Spoiler alert: it wasn’t. In Part 2, Setyono Dwi will dive deeper into the design challenges we encountered and share how we navigated those obstacles — from naming tokens to navigating Material 3’s strange colour decisions.
