Building a UI Design System: The Investment That Saves Dubai Companies Millions

What a design system is (and what it is not)

The term "design system" gets used to describe everything from a shared Figma file to a full-stack component infrastructure. This imprecision costs companies money, because they end up either over-investing in what they need or under-investing in what they actually require.

A design system is three things working together:

A component library. This is the collection of reusable UI elements — buttons, inputs, cards, modals, navigation patterns, data tables, form fields — designed once and used everywhere. Each component has defined states (default, hover, active, disabled, error), defined sizes (small, medium, large), and defined variants (primary, secondary, ghost, destructive). The component library lives in Figma for designers and in code for engineers. When a designer drags a button component onto a screen, it should look and behave identically to the button a developer renders from the code library.

Design tokens. These are the atomic decisions that define your visual language — colours, typography scales, spacing units, border radii, shadow values, animation durations. Tokens are named abstractions: instead of using the hex value #1A73E8 directly, you use a token called color.primary.default that resolves to #1A73E8. This abstraction layer is what makes theming, dark mode, and multi-brand support possible. Change the token value once, and every component that references it updates automatically. For companies building SaaS products in Dubai, tokens are the foundation that makes white-labelling practical rather than painful.

Documentation and governance. Components and tokens without documentation are just files. The documentation layer explains when to use each component, how to combine them, what the accessibility requirements are, and how the system handles edge cases. Governance defines who can add new components, how changes get approved, and how deprecation works. Without governance, the system drifts — individual teams start creating local variants that undermine the consistency the system was built to enforce.

What a design system is not: a style guide (that is just the visual documentation layer), a component kit you downloaded from the Figma community (that is a starting point, not a system), or a brand guidelines document (that covers identity, not interface). A design system is infrastructure. It requires ongoing investment, maintenance, and ownership — just like any other piece of your technology stack.

When you actually need one

Not every company needs a design system. A startup with one designer building a single product with ten screens does not need a formalised system — they need speed and iteration. The overhead of building, documenting, and maintaining a system at that scale slows you down more than it helps.

A design system becomes necessary when the cost of not having one exceeds the cost of building one. Here are the concrete indicators:

• Your designers are re-creating the same components. If two designers on the same product are building their own versions of a dropdown menu, you are paying for the same work twice. Multiply this across every component and every sprint, and the waste compounds fast. A design system eliminates the duplication
• Your product looks inconsistent. Open ten screens of your product side by side. Do the buttons all look the same? Do the form fields have the same height, padding, and label placement? Do the headers use the same typography? If the answer is no — and it usually is once you look honestly — you have a consistency problem that grows with every new feature shipped. Users notice. It erodes trust in ways that are hard to measure but real
• Design-to-engineering handoff is slow and error-prone. If your engineers are spending time measuring pixels, guessing at padding values, or asking designers "is this the right shade of blue?" — a design system eliminates that entire class of conversation. Components have defined specs, tokens have defined values, and the handoff becomes a reference to the system rather than a redline document
• You are scaling your team. Every new designer or engineer who joins needs to learn how your product looks and works. Without a design system, they learn by osmosis — looking at existing screens, copying patterns, and hoping they got it right. With a system, they reference the documentation, use the components, and produce consistent work from their first sprint. The difference in onboarding time is typically two to three weeks versus two to three days
• You operate in Arabic and English. Bilingual LTR/RTL support is the strongest forcing function for a design system in the GCC. Without a system, every screen needs manual RTL adaptation — text alignment, icon direction, layout mirroring. With a properly built system, RTL support is baked into the components. A button that works in English works in Arabic without additional design effort. Multiply this across your entire product, and the time savings are massive

Component architecture: how to structure it

A design system's component library is not a flat list of elements. It is a layered architecture, and getting the layers right determines whether the system scales or collapses under its own weight.

Layer 1: Primitives. These are the atomic elements — the smallest building blocks. A text element with defined type styles. A colour swatch. A spacing unit. An icon. These are not used directly in product design — they are the raw materials that compose into higher-level components. In Figma, these live as styles and variables. In code, they live as design tokens.

Layer 2: Core components. These are the foundational UI elements built from primitives. Buttons (with all their variants and states), text inputs, checkboxes, radio buttons, toggles, badges, avatars, tooltips. Each core component is self-contained, fully documented, and handles its own responsive behaviour. A well-designed core component library typically contains 20-30 components. Resist the urge to build more — every component you add is a component you must maintain.

Layer 3: Composite components. These are combinations of core components assembled into larger patterns. A form group (label + input + help text + error message). A card (image + title + description + action buttons). A navigation bar (logo + links + search + profile). A data table (headers + rows + pagination + sorting controls). Composite components encode layout decisions and interaction patterns. They are where most of the product-specific design decisions live.

Layer 4: Templates and patterns. These are page-level compositions — a settings page layout, a dashboard grid, a checkout flow, an onboarding sequence. Templates combine composite components with layout rules and content guidelines. They are not rigid — they define the structural framework that individual pages follow while allowing content flexibility within that structure.

The discipline is in the layering. When a product designer needs a new pattern, they should first check whether existing core and composite components can be combined to create it. Only when existing components genuinely cannot solve the problem should a new component be proposed. This gatekeeper function — built into the governance process — prevents the system from bloating with one-off components that get used once and maintained forever.

Design tokens: the layer most teams skip

Design tokens are where most design systems fail silently. A team builds beautiful components in Figma, hands them to engineering, and the engineers hard-code colour values, spacing pixels, and font sizes into the CSS. Everything looks correct — until someone needs to change the primary brand colour, add a dark mode, or create a white-label version of the product.

Without tokens, those changes require touching every component file, every page, and every CSS rule that references the old values. With tokens, you change one value in the token definition and the change propagates everywhere automatically.

Token categories for a GCC-market design system:

• Colour tokens. Organised in three tiers: global palette (the raw colour values — blue-500, grey-200), semantic tokens (what the colours mean — color.primary, color.error, color.surface), and component tokens (how specific components use the semantic tokens — button.primary.background, input.border.default). This three-tier structure makes theming practical. To support dark mode, you swap the semantic layer's value mapping without touching the component layer
• Typography tokens. Font family, font weight, font size, line height, and letter spacing — all tokenised. For bilingual systems, you need separate typography tokens for Latin and Arabic scripts because they have different optimal line heights and letter spacing. A heading that uses 1.2 line height in English may need 1.4 in Arabic for comfortable reading. Tokenising these separately means the component does not need to know which language is active — the token resolves to the correct value
• Spacing tokens. A defined scale — 4px, 8px, 12px, 16px, 24px, 32px, 48px, 64px — that every margin, padding, and gap references. Using a spacing scale prevents the "3px here, 7px there, 11px somewhere else" entropy that makes interfaces look unpolished. The scale enforces rhythm and proportion without designers thinking about individual pixel values
• Elevation tokens. Shadow values defined as tokens — shadow.sm, shadow.md, shadow.lg — so that depth and layering are consistent across all components. This matters more than most teams realise: inconsistent shadows make an interface look like it was assembled from parts of different products
• Motion tokens. Duration, easing curve, and delay values for animations and transitions. Tokenising motion ensures that all animations across the product feel like they belong to the same system — the same easing curve, proportional durations, consistent behaviour. Components that animate at 200ms with ease-out alongside components that animate at 400ms with linear feel disjointed

Tools for managing tokens: Figma Variables (introduced in 2023 and now mature enough for production use) handle the design side. For design-to-code sync, Style Dictionary, Tokens Studio, or custom build pipelines transform Figma token definitions into CSS custom properties, iOS Swift values, or Android XML resources. The goal is a single source of truth — tokens defined once, consumed everywhere. Read more about applying these principles in our guide to design system benefits.

The bilingual challenge: building for LTR and RTL

This is where design systems for GCC companies diverge fundamentally from Western design system practice. Every component, every layout, and every interaction needs to work in both left-to-right (English) and right-to-left (Arabic) orientations. This is not a CSS property you toggle at the end — it is a structural requirement that influences every design decision from the start.

What needs to mirror in RTL:

• Layout direction. Sidebars move from left to right. Navigation flows right-to-left. Content sections reverse their order. Grids maintain the same structure but the reading direction changes
• Icon direction. Arrows, progress indicators, navigation chevrons, and any icon that implies direction must be mirrored. A "forward" arrow points left in RTL. A "reply" icon curves the opposite direction. But not all icons mirror — a clock still goes clockwise, a phone icon stays the same, a search magnifying glass does not flip. The system needs to categorise every icon as "directional" (mirrors) or "universal" (does not)
• Text alignment. All text right-aligns in RTL. But mixed-content fields — an Arabic label with an English value, for example — need bidirectional text handling. A price shown as "AED 150" stays left-to-right within the field even when the surrounding layout is RTL. This is handled with Unicode bidirectional algorithm markers, but the design system needs to define these rules explicitly
• Component internals. A text input with an icon on the left and a clear button on the right reverses in RTL — icon on the right, clear button on the left. A stepper component that progresses left-to-right in LTR progresses right-to-left in RTL. A table of contents sidebar that sits on the left in LTR moves to the right in RTL. Every composite component needs RTL review

What does not mirror:

• Media controls. Play, pause, rewind, fast-forward buttons follow universal conventions and do not reverse
• Mathematical and musical notation. Numbers, formulas, and sheet music read left-to-right regardless of the surrounding text direction
• Brand marks and logos. These stay in their original orientation. Never mirror a logo for RTL
• Specific charts and graphs. Time-series charts with a horizontal x-axis typically maintain left-to-right chronological flow even in RTL contexts, though the axis labels should be in Arabic

The technical implementation: CSS logical properties (margin-inline-start instead of margin-left, padding-inline-end instead of padding-right) handle most layout mirroring automatically when the document direction is set to RTL. The design system's code components should use logical properties exclusively — never physical directional properties. This single architectural decision eliminates 80% of the manual RTL work. For UX design in Dubai apps, building RTL-first (or at least RTL-equal) is a competitive requirement.

The ROI case: why the numbers work

Design systems are expensive to build. The ROI case needs to be concrete, not theoretical. Here is how the maths works for a typical Dubai tech company with three designers and eight engineers working on a single product:

Without a design system: Each designer spends roughly 30% of their time on component-level decisions — choosing colours, adjusting spacing, ensuring consistency with existing screens. That is approximately 50 hours per designer per month, or 150 hours total across the team. Engineers spend approximately 15% of their time on design interpretation — asking questions, measuring specs, fixing inconsistencies flagged in QA. That is approximately 50 hours per month across the engineering team. Total: 200 hours per month spent on work that a design system would automate.

With a design system: Component-level design decisions drop by 40-60%. Designers spend their time on product decisions, not component decisions. Engineering interpretation time drops by 70-80% because components have defined specs. Conservative estimate: the system saves 100-120 hours per month. At typical GCC blended rates for design and engineering talent (AED 150-250 per hour fully loaded), that is AED 15,000-30,000 per month in recovered productivity. A design system costing AED 100,000 to build pays for itself in four to seven months.

The compounding effect: as the team grows, the ROI accelerates. Adding a fourth designer without a system adds another 50 hours of component-level overhead per month. Adding a fourth designer with a system adds near-zero overhead — they use the existing components and produce consistent work immediately. The system scales linearly with the team while the cost of inconsistency scales exponentially.

Secondary ROI factors that are harder to quantify but real: faster feature delivery (designers skip component design and go straight to product design), fewer QA bugs related to visual inconsistency, reduced design debt, and faster onboarding for new hires. Companies we work with in Dubai typically report that designers new to the team produce their first production-ready screen within their first week when a design system exists — versus three to four weeks without one.

Build versus buy versus adapt

Three options for getting a design system, each with different cost and control profiles:

Build from scratch. Full custom design system built specifically for your product, brand, and technical stack. Highest cost (AED 80,000-200,000), longest timeline (8-16 weeks), but maximum control and brand alignment. This is the right choice for companies with strong brand requirements, complex bilingual needs, or technical stacks that do not fit standard component libraries. Most enterprise-scale GCC companies — banks, government platforms, large e-commerce operations — end up here because their requirements are too specific for off-the-shelf solutions.

Buy a commercial system. Adopt an existing design system like Ant Design, Chakra UI, or Material Design and customise it to your brand. Lower cost (AED 20,000-50,000 for the customisation layer), faster timeline (3-6 weeks), but less control and potential brand dilution. The risk: your product looks like every other product built on the same system. For B2B SaaS products where brand distinction matters less than functional quality, this is often the pragmatic choice.

Adapt and extend. Start with an open-source foundation (Radix UI primitives, Headless UI, or Shadcn) and build a custom design layer on top. Mid-range cost (AED 40,000-100,000), mid-range timeline (5-10 weeks), and a good balance of control and speed. You get production-tested accessibility and interaction patterns from the open-source base, with full visual control through your custom token and styling layer. This is increasingly the approach we recommend for mid-stage Dubai startups — you get the robustness of a mature component library with the flexibility to build a distinctive visual identity. See our breakdown of web design trends in Dubai for 2026 for how this approach is evolving.

Governance: the part everyone forgets

A design system without governance degrades within six months. Without clear rules for how the system evolves, individual teams start creating local variants — "we needed a slightly different card component for our feature" — and the system fragments into a collection of loosely related component libraries that no longer enforce consistency.

Governance covers four areas:

• Contribution process. How does a new component get proposed, designed, reviewed, and added to the system? Who approves it? What criteria must it meet (used in three or more places, accessible, documented, RTL-tested)? Without a defined process, components get added informally, documentation falls behind, and the system becomes a dumping ground
• Deprecation process. How do old components get retired? When a component is replaced by a better version, how long do teams have to migrate? What support is available during the transition? Deprecation without a managed process leads to zombie components — technically still in the system, technically still used in some screens, technically nobody's responsibility
• Version control. The design system needs versioning — major and minor releases with changelogs. When a component's API changes, teams consuming the system need to know what changed and why. Figma's branching and merging features handle the design side. For the code side, semantic versioning with published changelogs is the standard
• Ownership. Someone needs to own the design system as a product. In teams of 5-15 designers, this is typically a senior designer who allocates 30-50% of their time to system maintenance. In larger organisations, it is a dedicated design systems team. The owner is responsible for quality, consistency, documentation, and the contribution process. Without a clear owner, the system becomes everyone's concern and nobody's priority

The governance overhead is real — plan for 10-20% of the initial build cost as ongoing quarterly maintenance. But the alternative — a system that decays into irrelevance within a year — is more expensive, because you have to build it again.

Common mistakes in design system projects

• Building everything before shipping anything. Teams spend six months designing 80 components, documenting every edge case, and perfecting the token structure — then discover that the product team needs different components than the ones they built. Start with 15-20 core components that cover 80% of your current product. Ship those, get feedback, and expand based on real demand. A design system built in isolation from product work is a design system built on assumptions
• Designing without engineering input. A component that looks perfect in Figma but cannot be built performantly in React (or SwiftUI, or Flutter) is not a component — it is a concept. Engineers should be involved in system design from day one. Component APIs, state management patterns, and accessibility implementations need to be co-designed, not thrown over the wall
• Ignoring accessibility. Colour contrast ratios, keyboard navigation, screen reader labels, focus management, and ARIA attributes need to be baked into every component. Retrofitting accessibility into an existing system is three to five times more expensive than building it in from the start. In the UAE, government entities and large enterprises increasingly require WCAG 2.1 AA compliance — and the regulations are tightening
• Treating RTL as an afterthought. "We will add Arabic support later" is a statement that guarantees the Arabic support will be painful and expensive. If your product will serve Arabic users — and in the GCC, it will — build RTL support into the system from the initial architecture. The cost difference between building RTL-first and retrofitting RTL is roughly 3x
• No adoption strategy. Building the system and publishing it on a Notion page does not mean teams will use it. Adoption requires training sessions, migration support, integration into existing workflows, and visible leadership endorsement. The best design system in the world is worthless if the product teams continue building components from scratch because they do not know the system exists or do not trust it