Sabi Market Design System (SANDs)

The same interaction looked different depending on which product you opened. Designers were recreating patterns that already existed somewhere else. Developers were rebuilding components that had already been built.

New designers spent their first weeks working out which patterns were current, because nothing in the files said so. That's not just a visual problem. It shows up as wasted engineering time and a support queue that keeps repeating itself.

Before proposing anything, I audited three areas of the product and compared them directly against each other:

• B2B marketplace: the mobile app and the web experience, which had drifted apart from each other despite sharing a name.
• B2C PaaS tools: the embeddable catalog and checkout modules other businesses were putting in front of their own customers.
• Internal admin dashboards: the operational tools nobody outside Sabi ever saw, and which had received the least design attention of the three.

Alongside cataloguing patterns, I interviewed designers and developers about where the friction actually sat, and pulled in user feedback tied to interface confusion. I wasn't just mapping where things looked different. I wanted to know where the inconsistency was actually costing the team time.

73% of components carried visual inconsistencies across platforms

2-3 weeks for a new designer to learn the existing patterns

3-4 times development teams had rebuilt similar components

42% of support tickets mentioned interface confusion

The last two numbers are what actually moved the conversation. This wasn't just screens that didn't match. It was engineering time and support volume, paid out over and over for the same problem.

A component library on its own would have been designed around within a year. What teams needed was something they built through: foundations, components, patterns, templates, documentation, and enough governance to keep it current after launch.

Partway in, Sabi introduced a new brand identity: logo, colors, typography, a new visual direction. That gave the system something it usually has to earn slowly, which is a reason to become the new source of truth, instead of asking teams to patch the old one a little at a time.

I structured the rebuild around atomic design, starting from the smallest pieces so nothing above them had to be patched later. Reusable components are only as consistent as the rules underneath them, so foundations came first, then components, then everything built on top.

Brand colors, neutrals and semantic tokens for system states. A type hierarchy with defined weights and consistent line-height ratios. An 8pt spacing grid. A stroke-based icon set that grew past 200 icons at a single visual weight.

Working directly with the front-end team, we built components against real product needs rather than a generic checklist: buttons, inputs, dropdowns, tags and badges at the smaller end, then product cards, navigation bars, modals and forms.

The bar wasn't visual consistency on its own. Each component had to survive being dropped into the marketplace, the PaaS tools and an internal dashboard without anyone needing to fork it.

Components alone still left every new feature starting from an empty canvas, so we built page-level templates on top of them: product listing and detail pages, multi-step checkout, onboarding sequences, and the embeddable catalog modules.

We didn't treat the system as finished the moment the components were published. Internally, that meant checking whether designers could actually assemble things faster, whether components held up against real product requirements, and where engineers still hit friction.

We also tracked component reuse, interface-related support tickets, and task completion in key flows, to confirm the system was solving the original problem and not just tidying it.

Every component shipped with usage guidelines, do and don't examples, responsive behaviour, accessibility considerations and implementation notes, plus onboarding material.

The goal was for someone who wasn't in the room when a component was built to still be able to pick the system up on their own.

73% to under 10% component visual inconsistency

60% increase in component reuse across teams

35% fewer interface related support tickets

2-3 weeks to 3-5 days for a new designer to ramp up

The bigger change was that teams finally had a shared language for building products.

• Timing is leverage. The rebrand gave this work buy-in that a design system initiative usually has to earn slowly, and we spent it while we had it.
• Foundations outlast the library. Components get replaced. Tokens, spacing and type rules are what keep the replacements consistent with everything around them.
• Engineers belong in it from day one. Every implementation problem we avoided came from a developer being in the room while a component was still a decision, not a handoff.
• A design system is a product. It has users, a support load, a roadmap and a maintenance cost. Adoption followed the moment we stopped treating it as a deliverable and started treating it as something we owned.