Hello Dojo

Problem statement#

Hello Dojo operates three distinct surfaces — a customer ordering app, a driver delivery app, and a vendor management portal. Each had been designed independently over two years. The result was three products that felt like strangers: inconsistent components, conflicting interaction patterns, and a design debt backlog that was slowing every sprint.

The challenge: unify without rebuilding from scratch, while shipping new features in parallel.

Three-surface fragmentation — before

My role and constraints#

As Lead Product Designer, I owned the design system architecture, component library, and the surface-level redesigns across all three products.

Constraints:

• Three separate engineering teams with different tech stacks (React Native, React, Vue)
• No shared design infrastructure existed
• Could not pause feature development during the consolidation

Process#

Audit and mapping#

Before designing anything new, I audited every existing component across the three surfaces.

The audit became the case for a shared design system. Numbers are more persuasive than design principles.

Component audit map

System architecture#

Designed a three-layer token architecture:

Layer 1: Primitives    — raw values (colors, spacing, type sizes)
Layer 2: Semantic      — purpose-based tokens (primary, surface, on-surface)
Layer 3: Component     — component-specific tokens (button-bg, input-border)

This structure allowed each app to consume the same semantic tokens while maintaining platform-appropriate visual expression. The vendor portal looks more "enterprise"; the customer app feels more "consumer" — but they share the same foundation.

Token architecture diagram

Component library build#

Prioritised components by frequency of use × inconsistency score. Built the top 40 components first, covering approximately 78% of all UI surface area across the three products.

Each component shipped with:

• Light and dark mode variants
• All interactive states (default, hover, pressed, focused, disabled, loading)
• Accessibility annotations
• Engineering handoff tokens in a format each stack could consume

Component library overview

Integration and rollout#

Rather than a big-bang migration, I designed a parallel track strategy:

• New features always use system components
• Legacy screens are refactored in order of user frequency
• No screen is refactored just for consistency — it must have a feature trigger

This eliminated the "design debt sprint that goes nowhere" pattern.

Parallel track migration strategy

Key decisions and trade-offs#

Token-first, not component-first. The temptation is to start building components. I started with tokens. This meant engineering could begin consuming the system before a single component was finished, and it gave us a forcing function for design decisions that might otherwise stay informal.

One icon set, three visual personalities. Using a single icon library (Lucide) with consistent stroke weight across all surfaces, but allowing the surrounding context — spacing, color, typography — to carry the brand differentiation. This saved approximately six weeks of icon design work.

Results and impact#

Three surfaces — after

Learnings#

A design system is a product, not a deliverable. The most important moment was treating the system as something that needed its own roadmap, its own acceptance criteria, and its own users (the engineers and designers who would consume it).

I also learned that the governance model matters as much as the components. We defined clear rules for who could extend the system, under what conditions, and how proposals were reviewed. That structure prevented the fragmentation that had created the problem in the first place.