Designing one language for an entire Product team

Design System
Design Tokens
Localisation
Light & Dark themes

The Bliq design system: colour ramps for blue, pink, red, green, yellow and grey, the primitive-to-semantic token mapping beside them, and components drawn from them — list tiles, status icons, chips, inputs, toasts, the pickup and destination card, the tip selector and the ride-comparison list, each shown in both light and dark.

Status: Launched
Milestones: Supports 2 mobile apps, passenger and driver!

The beginning: A system that couldn’t scale

When I joined Bliq, a design system already existed. However, as the product evolved, the system had grown organically. Components, styles, and patterns had been added over time without a clear scalable structure.

The biggest challenge wasn’t the lack of components—it was that the system had become difficult to navigate, maintain, and extend. The library was split across multiple Figma files, with separate files for each element. This made finding, updating, and reusing components time-consuming. Designers often had to search across different files to find the right asset, while developers had to deal with inconsistencies between similar patterns.

Researching scalable design systems

Before rebuilding the system, I researched how mature product organisations manage design at scale. Having previously worked at Careem (subsidiary of UBER) and collaborated closely with their design system team, I gained exposure to how large platforms maintain consistency across multiple products, teams, and markets. I also studied patterns from companies in the mobility space, such as Uber and Bolt, to understand how scalable systems use foundations like tokens, reusable components, and clear structures.

A design system is not a UI library. It is a shared language — and a team that has one spends its time on the product instead of on the pixels.

From Building Blocks to Product Experiences

From the very beginning, I worked closely with engineers to ensure the design system addressed both design and development needs. Their feedback helped shape a system that was practical to implement, easy to adopt, and built to scale. Rather than expanding the existing library, I rebuilt the system around reusable, flexible components. Existing UI elements—including lists, cards, buttons, and form controls—were redesigned using Auto Layout, variants, and scalable patterns to support multiple states, configurations, and real product scenarios.

The new foundation included:

Design tokens and semantic colour system
Variables for Light & Dark themes
Typography, spacing, and elevation scales
Atomic architecture (primitives, atoms, molecules, organisms)
Reusable components with variants and Auto Layout
Localisation support across five languages
Page templates for rapid ideation

One library behind both the passenger and driver apps, with one place to change anything in it.

The system was structured to support different levels of complexity. Starting from the smallest elements:

Primitives

Core foundations like colours, spacing, typography

Atoms

Atoms are the least complex elements of the buckets, the base of our system. Like buttons, icons, inputs and basic controls etc.

Molecules

Molecules combine multiple atoms into reusable UI patterns that solve specific user interactions. Each component was designed with different variants, states, and edge cases in mind, ensuring consistency across the product. Beyond supporting designers, these components became a reliable reference for developers, making implementation more predictable and reducing back-and-forth during development. Cards, search components, form patterns

Organisms

Larger reusable sections and complex interactions

Templates

Product teams could use templates to quickly explore ideas and communicate concepts in brainstorming sessions. The result was fewer alignment meetings, less back-and-forth, and faster execution. Complete layouts and product flows

Automating the system: themes, languages and states

Once the components existed, the work moved from drawing them to teaching them to adapt. A token knows what it becomes in each theme, a string knows its value in each language, and a component carries every state it can be found in — so a screen that has to work in German, in dark mode, with an error showing, is assembled from the library rather than drawn again.

Colour tokens — Light and dark themes

Every semantic token resolves to a primitive on each side of the theme, so a component is written once and follows whichever theme it finds itself in.

The two token sheets side by side: the same semantic names — $mainBg, $surface, $text, $border, $primary and the rest — resolving to one set of grey and blue primitives in the light theme and another in the dark.

Because the theme lives in the tokens, the whole app turns over at once — nothing is restyled screen by screen.

Localisation-ready patterns using Variables

Every string is a variable with a value per language, so switching locale reflows the interface rather than breaking it — German runs a third longer than English, and the layouts were built for that.

Every state a component can be in

Each component was drawn for every scenario it would meet in the product — empty, loading, filled, selected, disabled, error, and the combinations of those — so a screen could be assembled from the library rather than patched around it.

Designing for more than designers

The goal was never just to make designers faster. The system became a shared tool across the organisation. Developers had clearer implementation patterns and fewer questions. Designers could move faster without recreating existing solutions. The result was a single source of truth that reduced repetitive work, minimised design–development back-and-forth, and helped two designers and 15+ engineers build consistent experiences across the passenger and driver platforms.