Iksir Design System
A token-first design foundation (consistent, accessible, and trilingual), that Datamaster's web and mobile products build on.
A growing product suite with no shared language
Datamaster builds a modular ERP and a family of mobile apps under its Iksir product brand. As the suite grew, every screen was solving the same UI problems from scratch.
Inconsistency slowed everything
Colours, spacing, buttons, and form validation were rebuilt per screen and behaved differently across the products, costing development time and creating avoidable UI bugs.
Two stacks, no lock-in
The web is moving from Ant Design to Shadcn, with Flutter on mobile. The system had to feed them all the same decisions through tokens, while staying library-agnostic, so the team keeps the freedom to build beyond any single framework.
Built for three languages
The products are expanding to French, English, and Arabic (the task app first), so true right-to-left support and dual-script typography had to live in the foundation from the start, not be bolted on later.
A two-person team: I set the direction
We were two product designers. I led the project end to end: the strategy, the client relationship, and every foundational decision the system is built on. This case study is my side of that work.
Led by me
- Strategy, discovery, and the stakeholder relationship with the client
- The full design-token strategy and three-layer architecture
- The trilingual & right-to-left (LTR/RTL) foundation
- The accessibility framework, baked into the tokens
- The entire mobile layer, platform rules and mobile components
- All documentation, guides, and the governance model
- Structuring the project and shipping V1, and the rollout strategy now
My design partner
- Audit of the existing web product
- Figma production of the web/desktop components
- Building the documentation website
- The later polished visual pass on the public library
The full team story lives in a separate studio case study, this page focuses on the decisions and craft I owned.
From audit to a shipped V1
I structured the work into phases, though in practice they overlapped and looped back as we learned, not a straight line. Each one still closed with a decision the next could build on.
Audit & alignment
I ran stakeholder discovery to understand the business, then wrote the vision and success criteria. I audited the mobile task app and found it ran on a completely standalone, hard-coded system, disconnected from any shared foundation.
My call → reframe those hundreds of validated mobile screens as the blueprint for the system's mobile layer, instead of treating them as a problem to clean up.
Foundations
I defined the token architecture (a strict naming convention (category · property · concept · state) sitting on a three-layer chain of primitives → semantics → components), so developers would never hard-code a value again. Alongside it I authored the trilingual/RTL architecture (logical properties, dual-script type, icon-mirroring rules) and an accessibility framework expressed directly as tokens.
The decision that mattered → make light/dark and LTR/RTL properties of the tokens themselves, so a single source of truth adapts automatically rather than being maintained twice.
Components, mobile layer & documentation
As the library scaled to 24 components and 5 patterns, I designed the entire mobile layer (platform rules and the mobile-native components (bottom sheets, tab bars, numeric keypad, scanner overlay, task cards)), in both Figma and the documentation site. Then I structured the project and shipped V1.
The principle I held → treat the documentation as a product in its own right, the single spec both designers and developers work from.
Not a straight line: the mobile layer is the clearest example. What Phase 1 flagged as a hard-coded, disconnected task app became, by Phase 3, the system's mobile component library, through several passes, not one. I designed the layer, my design partner reviewed each round and pushed it further, every loop tightened the components until they held up as a system.
Three layers, one source of truth
Each layer consumes only the one below it. Skip a layer and you break the single-source-of-truth guarantee, so components never touch raw values.
Raw values, named by value
Hex codes, pixel sizes, durations. The only place a literal value is ever written.
Named by intent: the only layer components use
Maps primitives to meaning, and carries both light/dark and LTR/RTL values automatically.
Consume semantics only
Every component is built from semantic tokens (never a hard-coded value), so it adapts to any mode or language for free.
What that buys: change a decision once and every product inherits it: one source of truth across two engineering stacks, light/dark and RTL resolved automatically, and WCAG AA enforced at the token level.
Colour, type, space: all tokenised
191 colour tokens across brand, content, background, border, and status groups, each with a light and a dark value. Type pairs a Latin family with an Arabic one at matching optical weight.
Tip: click any swatch to copy its hex, the same tokens the products read from.
Underneath: a 22-step spacing scale on a 4-pt grid, 8 semantic radius aliases, 4 elevation levels, and 86 Lucide icons at a 1.5 px stroke in three sizes, each with RTL mirroring rules.
24 components: every state, documented
From Button (450 variants because every hierarchy × size × icon position × state is accounted for, not padding for its own sake), to the mobile-native pieces I designed for the task app. Each one is built and documented, ready to drop in.
Core components
Mobile-native: the layer I designed
Patterns
A note on what's shown: Iksir is live client work under NDA, so I'm showing only a selection of the design system (a sample of its tokens, components, and patterns, not the full library), and none of the client's production screens or real data. What you see here is a curated slice that's safe to share, the complete system and the products it powers stay private.
WCAG 2.1 AA, built into the foundation
Accessibility was one of the areas I owned. I didn't just document WCAG 2.1 AA, I turned it into tokens, reusable Figma checks (a contrast matrix and a 44×44 touch-target component), and a testing workflow the whole team designs and builds against.
Contrast as a contract
4.5:1 for text, 3:1 for large text and UI, verified across light and dark, with unsafe combinations corrected at the token level.
Never colour alone
ERP statuses always pair colour with an icon and a text label, so meaning survives colour-blindness and greyscale.
Touch & focus tokens
A 44×44 pt minimum touch target and a 2 px offset focus ring are tokenised, keyboard and mobile users are covered by default.
Trilingual screen readers
Dynamic lang/dir, logical reading order, and localised labels so assistive tech reads French, English, and Arabic correctly.
Testable, not just documented
I set up a checking workflow across every surface (contrast plugins in Figma, axe and Lighthouse on web, VoiceOver and TalkBack on mobile), so accessibility is verified at each handoff, not assumed.
Dual-script sizing
Arabic body text is bumped 1–2 px above the Latin baseline, with line-height tokens tuned so complex ligatures never clip in dense data tables.
Shipped, and still evolving
V1 released
Foundations, 24 components, 5 patterns, and the documentation platform, all live as the official V1.
Adoption & polish
The library is in use and improving. My partner led a polished public version of the site on top of the shared V1.
Integration strategy
I'm defining how the system rolls into the real products, and keeping governance open until it's fully stable.
Rules that keep it coherent as it grows
Always use semantic tokens
Components reference intent (brand/primary), never raw values, this is what makes the system maintainable and mode-switchable.
Respect the three-layer chain
Primitives → semantics → components. Never skip a layer, it breaks the single source of truth.
Light + dark, RTL + LTR, built in
Every semantic token carries both, no parallel colour sets, no manual mirroring.
The docs are the spec
Token references, states, and do/don't guidance are requirements, with a workflow that lets a non-coder publish updates safely.
Leading a system means designing the decisions, not just the screens.
The hardest (and most rewarding), part wasn't drawing components. It was making choices that had to hold up across two engineering stacks, three languages, two colour modes, and a second designer's hands. Getting the architecture and the accessibility right early is what let the library scale without collapsing into exceptions.
It also reshaped how I work: treating documentation as a product, writing rules that other people can follow without me in the room, and staying accountable for a system long after its first release.
Have a system like this in mind?
I design systems, products, and the foundations under them. Tell me what you're building, and let's make it consistent, accessible, and fast to ship.
Let's build something like this