Hubees — Design System for a mobility tech
Overview
Senior Product Designer — led the design system initiative as sole designer
- Problem
- Every handoff needed a conversation. Designers redrew the same patterns each sprint, and a rebrand was coming with a deadline.
- What I did
- Audited every component, trimmed the excess and rebuilt the system from the three launch journeys backwards.
- Result
- Live in 6 months, alongside the rebrand. Design delivery 40% faster, and developers started prototyping on their own.
Problem_
Hubees is a subscription-based parking startup with first-mover advantage but our design infrastructure was quietly working against that.
Designers were redrawing the same patterns sprint after sprint. Developers received deliverables with inconsistent spacing, conflicting components, and small variations that were unclear they were intentional or not. Every handoff required a conversation that shouldn’t have been necessary.
Then a new brand identity landed on the roadmap.
The rebrand gave us the opportunity to fix the foundation and came with a deadline.
The real question was how much to lock down, enough structure to speed us up, not so much that it became a ceiling.
Foundation_
Auditing what already existed
I inventoried every component across every product, categorised by use case, frequency, and context. What emerged was a map of duplication, dozens of components doing the same job in slightly different ways.
The first major decision was collapsing those variations: fewer components, each with a clearer semantic purpose.
Textfields audition
- And a dozen variations of each one
Reduced to 4 variants + states
| Name | States | Optional properties |
|---|---|---|
| Textfield |
|
|
| Textfield search |
|
|
| Textarea |
|
|
| Textfield code |
|
|
Building the foundation without over-specifying
Color, typography, spacing, shadows and opacity were anchored to the new brand studies but defined with room to evolve.
I’ve worked inside design systems that were locked down too early and became too much of a constraint rather than a tool. Systems that are over-specified at launch don’t survive contact with real product decisions.
Designing journeys first, components second
To pressure-test the system against real problems, I flipped the usual order. Instead of designing components and applying them to journeys, I designed each journey as if the design system didn’t exist. Focused entirely on the best solution for the user.
Only then did I work backwards to build components that could support those decisions and simplify where needed. It kept the system grounded in real product work keeping us from chasing hypothetical flexibility.
Component shortlist
Text style shortlist
We scoped the initial launch to the three highest-priority journeys — User Registration, Stay Check-in, and Stay Check-out — and timed it to coincide with the brand rollout.
Results_
Six months from kickoff to production launch, delivered in parallel with the rebrand campaign.
Beyond the 40% cut in design delivery time, the system changed how the team worked. Documented use cases made component decisions self-explanatory, and in many cases the alignment conversation stopped being necessary at all.
Finally, a happy surprise. With clear guidance on when and how to use the system, developers started prototyping improvements on their own, validating direction before pulling anyone else in. It only happened because the system was trustworthy enough to build on.