Figma to Production: Design Systems for Qatar in 2026

Qatar's digital transformation push — from the Qatar National Vision 2030 agenda to the rush of fintech launches in Lusail and the smart-city ambitions of Msheireb Downtown Doha — has produced an explosion of Figma files. Banks are redesigning mobile banking apps for open banking compliance, telecom operators are rebuilding self-service portals, and government entities are unifying citizen services under initiatives like Hukoomi. Yet in project after project, we see the same failure pattern: a beautifully organized Figma library that never survives contact with production. Developers rebuild components from scratch. Arabic and English versions drift apart. Six months later, three teams have three slightly different 'primary buttons.' This article is the playbook we use at FOCUS POINT to close that gap — tokens, governance and adoption, in that order.

The Real Problem: Your Figma File Isn't Your Design System

A design system is not a set of pretty components in a shared library — it's a product with a roadmap, an owner, release notes and a feedback loop. When teams in Doha treat Figma as the finish line, three symptoms appear almost immediately: duplicate components with subtle inconsistencies (spacing off by 2px, four shades of the same 'brand blue'), a widening gap between what designers ship and what developers actually build because there's no reliable handoff mechanism, and — specific to the Qatari market — Arabic typography that was never properly tokenized, forcing developers to hardcode font sizes and line-heights for RTL layouts on every single project. The fix starts upstream, with tokens.

Design Tokens: The Source of Truth That Survives Every Handoff

Design tokens are the atomic decisions of your brand and product — color, spacing, radius, typography, elevation, motion duration — expressed as named variables rather than hardcoded values. Structured correctly (ideally following the W3C Design Tokens Community Group format), tokens become platform-agnostic: the same source feeds your web app, iOS app, Android app and even your Flutter kiosk experience at a bank branch in West Bay.

• Global tokens: raw values (hex codes, pixel scales, font families) that rarely change.
• Alias/semantic tokens: purpose-driven names like 'color.background.critical' or 'spacing.card.padding' that reference global tokens.
• Component tokens: the most granular layer, scoped to a specific component (e.g. 'button.primary.background.hover').
• Use Figma Variables with modes to manage Light/Dark and LTR/RTL simultaneously, instead of duplicating frames.
• Export tokens via Tokens Studio or Figma's native API, then transform them with Style Dictionary into CSS custom properties, Swift, Kotlin, or Tailwind config.

Governance: Turning a Kit of Parts into a Living Product

Governance is what keeps a design system coherent as dozens of contributors — designers at headquarters, developers in an outsourced squad, a marketing team producing a campaign microsite — pull it in different directions. The model that works best for Qatari organizations we've supported, whether a Doha-based bank or a ministry digital unit, is a hybrid: a small core team (2-4 people) owns the architecture, tokens and release cadence, while feature teams contribute new components through a lightweight RFC (request for comment) process. Every proposed component needs a documented use case, an accessibility review, and Arabic/English content examples before it's merged. Semantic versioning (major.minor.patch) and a public changelog stop the classic 'nobody knows if it's safe to update' paralysis.

• Define a RACI: who is Responsible, Accountable, Consulted, Informed for each token category and component family.
• Publish contribution guidelines in both Arabic and English — this alone removes a major adoption barrier in Qatar's multicultural teams.
• Set a deprecation policy: minimum 2 release cycles' notice before removing a component, with automated codemods where possible.
• Hold a monthly design system council with representatives from each business unit (retail banking, corporate, digital channels) to arbitrate conflicts.

Adoption in Qatari Organizations: From Mandate to Habit

We've seen well-funded design system initiatives in Doha fail not because the components were poor, but because adoption was treated as a one-time announcement rather than an ongoing program. Mandating usage from leadership gets initial compliance; it never produces genuine adoption. What works is making the design system the path of least resistance: faster than building from scratch, better documented than the old Sketch files, and visibly maintained.

• Appoint 'design system champions' inside each squad — often the fastest way to spread bilingual best practices across distributed teams.
• Run weekly office hours (in person in Doha offices or via Teams) where any designer or developer can bring a blocker.
• Track Figma library analytics and component usage in code (via ESLint rules or import scanning) to identify which teams have adopted and which haven't.
• Bundle onboarding into new-hire training — critical in a market like Qatar where teams often mix local, regional and international talent with different design tooling habits.

RTL and Bilingual by Design: Qatar's Non-Negotiable

Any digital product launching in Qatar — whether a banking app, a telecom self-care portal or a government e-service — must handle Arabic RTL and English LTR flawlessly, often within the same session as users switch languages. Building this in at the component level, rather than patching it after launch, is where design systems earn their value. Use CSS logical properties (margin-inline-start instead of margin-left) so components automatically flip without a separate RTL codebase. Icons that convey directionality (arrows, back buttons, chevrons) need a mirrored variant token, while icons that don't (a search magnifier, a checkmark) should never be flipped — a mistake we still see in production apps across the region. Numerals are another subtlety: decide early whether your product uses Western Arabic numerals (0-9) or Eastern Arabic-Indic numerals, and encode that choice as a token so it's consistent across every screen.

From Figma to Code: The Pipeline That Actually Ships

The technical pipeline we implement for clients typically looks like this: designers manage tokens as Figma Variables, synced to a Git repository through Tokens Studio's plugin. A GitHub Actions workflow runs Style Dictionary on every merge to transform tokens into platform-specific outputs — CSS custom properties for the web app, XML/Kotlin for Android, Swift for iOS. Components are documented and visually tested in Storybook, which becomes the shared source of truth for both designers and developers (far more reliable than a Figma comment thread). Visual regression testing tools like Chromatic catch unintended changes before they reach staging. Crucially, a design QA step — a designer reviewing the built component against the Figma spec — happens before every release, not after user complaints roll in.

Measuring What Matters: KPIs for Executives in Doha

• Component adoption rate: % of production screens built with system components vs. custom one-offs.
• Time-to-ship: average time from design handoff to production release, before and after system implementation.
• Accessibility compliance rate: % of components passing WCAG 2.2 AA, especially important for government digital services in Qatar.
• Design-dev consistency score: visual diff rate between Figma spec and shipped UI, tracked via automated screenshot comparison.
• Support ticket reduction related to UI inconsistency across bilingual (AR/EN) versions of the product.

A Doha Fintech Scenario: What Success Looks Like

Picture a digital-first financial services team in Doha launching a new savings product across web, iOS and Android, in Arabic and English, within a tight regulatory timeline tied to open banking requirements. With tokens as the source of truth, the brand refresh (a new primary color and updated type scale) propagates to all three platforms in a single pull request instead of three separate manual updates. With governance in place, a marketing-led promotional banner component goes through a two-day RFC instead of being hardcoded outside the system and breaking on the next redesign. With adoption embedded, new joiners onboard using system documentation instead of reverse-engineering old screens. The result isn't just a faster launch — it's a product that stays consistent as the organization scales its digital ambitions through 2030.