Cari was growing fast. The design foundation had to keep up.

Cari started as a food delivery app within The Taken Seat’s venture-building environment, but it quickly grew into a platform with 13+ verticals, vendor tools, internal operations, and support for English and Arabic.

I led the design system direction and maintained the foundation while the product was moving, with support from another product designer. The goal was simple: stop the same decisions being made again and again across different screens, teams, and product surfaces.

Lead Product Designer Design system direction Consumer app, vendor tools, internal tools

Design Systems
Multi-vertical Platform
Design Tokens
Component States
Marketplace Patterns
Checkout Behaviour
Bilingual UI
English · Arabic · RTL

Cari design system cover showing product screens, token structure, reusable components, bilingual typography, and shared product patterns.

Context

As Cari expanded, I needed one place for the decisions that kept repeating across screens, tools, teams, and languages.

13+ Verticals, including food, grocery, pharmacy, flowers, gifts, electronics, and more

4+ Consumer app, vendor tools, campaign tools, internal operations, and related support surfaces

2 English and Arabic, including RTL layout and language-specific type behaviour

500K+ Android downloads while the product surface area continued to grow

Core system decision

Brand updates needed one place to flow from.

Cari’s brand was still being shaped while product screens were already moving. Marketing and the founders were testing colours and typography across app screens, outdoor placements, and other media.

After a few colour tweaks created screen-by-screen rework, I moved brand decisions into the system layer so later updates could flow through tokens, components, and product screens from one place.

Proof 01

Component states were defined before handoff.

Buttons, inputs, chips, and controls carried their key states in the shared library, not inside individual screens.

Engineers could inspect the expected behaviour in Figma before implementation, including default, focus, loading, error, and disabled states.

Cari design system component state matrix showing button, input, chip, and control states prepared before engineering handoff. — A cropped component-state matrix from the design system, showing reusable interaction states prepared before handoff.

Proof 02

The store card became a shared marketplace pattern.

The store card appeared across the homepage, category pages, search, reorder, offer placements, and Arabic surfaces.

I turned it into a flexible system component so repeated marketplace states could be handled once and reused across surfaces.

Cari design system store card component showing default, pre-order, discount, Arabic, and skeleton loading states. — A reusable store-card component showing how the same pattern handled default, pre-order, discount, Arabic, and skeleton loading states.

Proof 03

Checkout states were treated as one reusable behaviour pattern.

Checkout touched several high-risk states: item options, basket changes, offers, wallet balance, payment methods, delivery timing, and final confirmation.

I documented these as one reusable transaction pattern so future checkout improvements could reuse the same behaviour instead of redesigning each step from scratch.

Cari checkout pattern showing item detail, cart, and checkout screens as part of a reusable transaction flow. — A reusable transaction pattern covering item customisation, basket review, offers, payment, wallet, and final order confirmation.

How the team used it

The system worked because each file had a clear job.

Active product design did not happen in the same file used for stakeholder review or engineering handoff. I kept the work split across clear Figma files so each audience had the right level of detail.

Designers worked in the main design file, product managers and founders reviewed cleaned-up work in a review file, engineers received finalised flows through a handoff file, and the design system file stayed linked as the shared source for components, tokens, and patterns.

Cari design system Figma file structure showing the main design file, review file, handoff file, and linked design system file. — Separate files kept active design, review, handoff, and system components from being mixed together.

Validation

Dukkan later proved the system could support another brand.

Dukkan was another product under the same venture-building environment. It had its own grocery and food delivery positioning, separate brand, and different product needs.

The product had started from a white-label setup with weak file structure and limited handover, so the team was often working from screenshots instead of a clean design foundation.

Because the Cari system had been built around modular roles rather than fixed brand values, I saw that the same structure could support Dukkan too. The brand layer changed, but the component logic, token hierarchy, and reusable patterns did not need to be rebuilt from scratch.

Dukkan reused the same underlying system structure through a brand-layer swap, validating the modular setup after Cari had scaled.

Impact

What the system changed.

The value was not having more components. It was reducing repeated decisions across a growing product ecosystem.

Cari could scale across verticals, product surfaces, and languages without every team solving the same UI problems again.

13+ Verticals supported by one shared design foundation.

4+ surfaces Consumer app, vendor tools, campaign tools, and internal operations used the same product language.

2 languages English and Arabic styles were handled inside the system instead of being fixed screen by screen.

Faster handoff Engineers could inspect component states, properties, and usage directly in Figma.

2 products Cari and Dukkan used different brand layers while keeping the same underlying structure.

Less UI drift Patterns were reviewed, systemised, and reused instead of recreated across new surfaces.

← Back to work