ICARE – one design system for an insurer in 12+ markets

In brief

ICARE was moving its insurance products from vendor software to its own cloud platform. Every screen was being designed again, fast, with no shared design language underneath.

1. My part: designing the design system was my task from my first day. I set its direction with the design lead and designed the tokens, components, rules and the way new components got in. A graphic designer and two software engineers worked with me, and a colleague who specialised in Arabic typography designed the Arabic part.
2. Built it alongside live product design, not before it. The system caught up with the screens week by week until every new screen was built from it.
3. Chose structure over speed: a strict naming hierarchy for every token and component, so the system would stay usable after me.

50% Less duplicated design work, measured in Jira before and after the system was adopted.

01 · Overview

ICARE is a digital insurance company serving 12+ markets across West Asia, with a focus on the Gulf. Between 2019 and 2023 it moved off vendor insurance software and onto its own cloud platform, which meant designing every product again. Designing its first design system was my task from the day I joined. The visuals here are a reconstruction made for this portfolio, because the original files belong to ICARE. The structure, decisions and results are real.

Context

A digital insurer in 12+ markets

West Asia, with a focus on the Gulf

A move from vendor software to an own cloud platform

Scope

Token architecture

Brand themes and light and dark mode

150+ components

Accessibility, motion and content rules

Contribution process

Products

Customer mobile app

Customer website

Internal agent tools

Platform for independent insurance sellers

Signature idea

Structure before speed

One library, many themes

A system that catches up with live design

02 · The challenge

The products were being rebuilt fast, screen by screen, starting with dashboards. With no system underneath them, each new screen solved the same problems again.

Duplication

The same buttons, forms, cards and tables were redrawn for each product and each brand.

Drift

Colours, type and spacing were set by hand, so screens drifted apart over time.

Handoff

Engineers rebuilt components from screenshots, and handoff turned into long back-and-forth.

03 · Setting the direction

Structure before speed

I set the system's direction in direct collaboration with the design lead. The key decision was to build it to outlive any one designer, including me. Every token and component got a name in a strict family hierarchy, from bg/brand and text/secondary to Button by variant, size and state. It took longer at the start than drawing components freely, but anyone joining later could find, reuse and extend a component without asking who made it.

Clarity is care

Plain words over policy wording. Insurance terms are explained where they appear.

Show the money

Cover, excess, price and renewal are visible wherever a policy appears.

One system, many markets

Markets differ by tokens, not by copies of the library.

Calm under stress

Claims happen on bad days: fewer fields, honest timelines, one clear next step.

04 · Three token layers

Components never touch a raw value

Primitives hold the raw values: colour ramps, spacing on a 4px base, radius and type. Brand themes map each product line to its own identity colour. Semantic tokens such as bg/surface, text/secondary and border/focus resolve per light and dark mode. Components use only the semantic layer, so changing a brand or a theme never means touching a component.

05 · Themes for every brand

One component, every product line, light and dark

Instead of a library per brand, one library carries brand and theme modes. The same policy card switches identity colour per product line and flips to dark mode without a single change to the component. Price and amount components take their currency and format from the market, so one component works for every local currency.

06 · Components

150+ parts, named the same in Figma and in code

The library grew to more than 150 reusable components shared by the customer app, the website, the agent tools and the seller platform. Every interactive component documents its anatomy, sizes, states and use, so design and engineering read the same spec.

07 · Rules built in

Quality that does not depend on who designs the screen

The system set rules as well as shapes. Colour pairs were checked against WCAG 2.1 AA contrast, with focus states, touch targets and visible labels in every interactive component. Animation durations and easing were tokens, so movement felt the same everywhere and could be reduced. Writing rules and a word list replaced insurance jargon with plain words.

08 · How components got in

Nothing without a real screen that needed it

A component entered the library only when a real screen needed it. It was proposed with the gap it filled, reviewed with the design lead and engineers, built tokens first, documented, and then released to the team. The hardest part was not designing components but getting people to use them. A system only counts when designers and engineers choose it over their own versions, so showing that it saved them time mattered as much as the components themselves.

09 · Four products, one system

Customers, agents and sellers on the same components

The same components served policyholders in the mobile app, new and existing customers on the website, ICARE staff in the agent tools and independent insurance sellers on their own platform. One status vocabulary meant a customer and an agent always described a claim the same way.

10 · Impact

The system cut repeated design work by about half and made handoff about a third faster. Both figures compare the same team's work in Jira, before and after the system was adopted.

Less repeated work, faster handoff

50% Less duplicated design work. The same team's Jira work, before and after the system was adopted.

30% Faster developer handoff.

150+ Reusable components across four products.

11 · Reflection

The biggest lesson: a design system can be built while the product keeps shipping, but only with discipline every single week. New screens arrived faster than the system could absorb them, and strict naming is what let a small team of five close that gap until the system owned the design. Today I carry three habits from ICARE into my own products, SynchroShift, GATH3R and SEDERAN: tokens and a component library first, names and structure agreed before anything is drawn, and components aligned with engineers from the very first version.

The system was finished the day nobody asked where a component lived.