The problem

Cambridge managed a wide range of digital products, most with their own design system but no common layer between them. In practice that meant similar components looking and behaving differently across products, inconsistent color, spacing, and typography, and the same decisions being solved in parallel by different teams.

The goal wasn't to force everything into one rigid system. It was to build a shared foundation flexible enough to respect real product differences while still bringing them under one visual and semantic language.

Setup and scope

As the sole designer I owned every layer: the architecture, the components, and the standards other teams would build on. Development was handled by internal teams, so I designed the system to be self-serve, documented and structured clearly enough that they could implement without me in the loop. Accessibility was a hard requirement from day one and shaped most token, contrast, and interaction decisions.

The decision that made everything else possible: a 3-tier token architecture

The single biggest call in this project was going with a 3-tier token architecture instead of the more common 2-tier setup.

In a 2-tier system, components reference semantic tokens directly. It's simpler, but it locks visual decisions at the semantic level. Over time components either inherit changes they shouldn't, or break when semantics shift.

I introduced a third tier, component tokens, sitting between the semantic layer and the components themselves. That gave the system a clear home for component-specific visual decisions without polluting the semantic layer, safer changes (a button can change without touching every component that shares its semantic), and room to grow as new brands and themes get added.

To keep component tokens from sprawling, I grouped components with similar visual intent under shared token sets. Feedback components like alerts, toasts, and badges share a colour.feedback.* set, for example, and other families are grouped the same way. The system stays scalable without multiplying tokens for no reason.

From client system to reusable foundation

The system shipped across three Figma libraries: Foundations (all tokens and foundational docs), Core components, and Iconography. Each of the 31 components came with full documentation covering usage, anatomy, variants, properties, motion, spacing, do and don't, and accessibility, so an internal team could implement without back-and-forth with me.

I also wrote designer guidelines for safely adapting the system to a new brand: how to duplicate files, edit tokens, set up variable scopes, and publish libraries. The point was to make myself unnecessary, so another designer could take the system to a new brand without me in the loop. The goal was controlled customization, not redesign.

After the Cambridge delivery, the system was adapted as a white-label foundation. It needed no architectural changes, because the multi-brand structure was already there. A new color palette as the starting point was enough. Today the same foundation serves multiple products, and the ITML system has since grown beyond the original 31 components.

Iterating on the real workflow: removing Tokens Studio

I originally ran all tokens through Tokens Studio as a single source of truth, synced to Figma Variables for designers and to GitHub as JSON for engineers. On paper it was ideal. In practice, it added friction for designers who weren't familiar with it, and that friction slowed the exact people the system was meant to help.

So I made Figma Variables the single source of truth and dropped Tokens Studio. Losing the live GitHub sync sounds like a step back, but when I looked at what the developers actually needed, it wasn't a running sync, it was token JSON they could pull when they wanted it. So I built them an export for exactly that: a zip of token JSON files, generated on demand from the source of truth. The developers got exactly the handoff they used, and the designers got a workflow they could actually move in.

The theoretically best architecture lost to the setup the team uses well. A system only works if the people using it every day can move quickly in it.

Building a tool to solve the slowest part: Accord

Adapting the system to a new brand had one genuinely slow, error-prone step: building the color system. When we adapted the system to ITML's own brand, generating even, accessible color scales by hand, mapping every semantic role across light and dark, wiring the aliases, and re-checking contrast everywhere a value was used took us one to two days. Worse, we thought we were finished, then found a few contrast issues in some components we'd missed.

So I built Accord, a Figma plugin, with Claude, as a designer rather than an engineer, to stop those contrast misses at the source. You input your brand colors and get a complete, contrast-ready token system:

• Accessible color scales generated from each of your brand colors
• Semantic roles (text, surface, border, icon, interaction) mapped correctly across light and dark modes
• Everything connected through token aliases, so a core change flows through the whole system
• Tokens written straight into Figma variables instead of edited one by one
• Developer-ready tokens exported directly from the file

The key shift is that accessible contrast is generated, not retrofitted. Every scale's defined token combinations are validated against WCAG 2.2 contrast thresholds across all interaction states (default, hover, pressed, focus) and in both modes. What used to be a manual step that could slip under deadline is now automated. The day or two of specialist color work, plus the contrast checks where a few could still slip through, now happens in minutes, which removes most of the manual checking rather than all of it.

The plugin doesn't replace design judgment, it accelerates it. It handles the repetitive non-negotiables (validated contrast combinations, correctly connected tokens) while designers keep the calls that need a human: hierarchy, emphasis, and brand expression.

What I learned

Designing for reuse is theory until the moment you actually have to reuse. When the system needed to become white-label, the tradeoffs I'd defended early (the third tier, the strict separation of concerns, the discipline around naming) paid off with no rework. And when the workflow met real designers, I learned to let the ideal architecture lose to the one people actually use.

It changed how I argue for scale decisions. Early tradeoffs often look like over-engineering until they prove themselves. I now make the long-term payoff visible upfront, so the conversation with stakeholders is about evidence, not preference.

The problem

COSMOTE Insurance (now Magenta Insurance) is a major insurance aggregator in Greece. The portal had been redesigned six months before I joined, and the Results Page, where users compare quotes and decide to buy, was the highest-priority friction point in the flow I owned.

To understand what was going wrong, I combined three sources: a journey-based survey through the COSMOTE Ambassadors program, Hotjar heatmaps and session recordings to see where users actually struggled, and product metrics and session analysis.

Five issues stood out:

• 15 or more seconds of loading before any result appeared, the biggest driver of drop-off
• No comparison on mobile, even though around 85% of visits were on mobile
• Hidden comparison on desktop, behind unlabeled checkboxes
• Unclear packages, so users couldn't tell what was included versus optional
• Insurance jargon with no explanation, which made users hesitate

01Fixing the wait

The 15-second load came from waiting for every insurance provider to respond before showing anything. Backend latency couldn't be reduced in the short term.

I proposed a different approach to engineering: progressive results loading. Instead of waiting for all providers, stream each quote card in the moment its data arrives, show skeleton loaders for the rest, and re-sort as more come in. The team weighed the cost and benefit (it needed significant backend work) and decided to build it.

This was the moment that shaped the rest of the project. The fix wasn't faster code, it was a different way of showing progress: surfaced by the research, proposed by me, and weighed and built by engineering.

02Comparison that works on mobile

Comparison was the results page's reason to exist, and the page was failing at it. On mobile it didn't exist at all. On desktop it was a bare, unlabeled checkbox on each card, and the strip confirming "you've selected these to compare" only appeared after the second selection. So the first click did nothing visible, and most people never made the second.

I rebuilt it mobile-first, then adapted it to desktop, aiming the fixes squarely at that feed-forward gap:

• A clear label next to every checkbox, instead of a checkbox hanging on its own
• The selection strip now appears on the first checkbox, not the second, so the very first click shows what is happening and what to do next
• A dedicated comparison view designed for small screens
• The ability to add or remove quotes from inside the comparison

On mobile, where comparison hadn't existed at all, it became a core behavior fast. 18% of results-page users now use it.

On desktop, where the checkbox already existed, the label and earlier strip moved the numbers. Relative to users who clicked Buy, the share who also compared went from about 37% to 46%.

Selecting quotes opens a dedicated side-by-side comparison. Among desktop users who used it, the share who then bought straight from the comparison view roughly doubled, from about 8.5% to 19%.

03Less jargon, more confidence

Insurance terminology overwhelms people, so I applied progressive disclosure across all devices:

• "Includes X coverages" links that reveal details on the spot
• A desktop side drawer for quick review without losing context
• A mobile full-screen bottom sheet for a focused, app-like experience
• Tooltips and info icons that explain jargon exactly when it's needed

This was designed to reduce cognitive load, revealing detail on demand while keeping users inside the funnel.

What I learned

Two things stuck with me. First, do the research up front, then measure honestly once it is live, and let the data change your mind. I went in expecting a conversion lift and didn't get one at the top line. What the funnel showed instead was that the redesign's real win was behavioral, mobile users finally comparing quotes, and that the biggest remaining leak was a step I hadn't touched. Some effects only show at scale, and I would rather learn from them honestly than defend the original plan.

Second, the fix was as much about framing as design. I proposed progressive results loading, but what got it built was framing the 15-second wait as a perception and trust problem rather than a "make it faster" request, so engineering could weigh the backend effort against the real goal and agree it was worth building. Bringing engineers a concrete proposal along with the problem behind it, early, is one of the highest-leverage things I do.

Context

Opening a bank account online is high-friction by nature. Users hand over sensitive information, complete identity verification, and have to stay engaged through a long, multi-step flow. The existing experience made each of those harder than it needed to be, especially at the identification step, where users could get stuck with no way forward.

This is regulated territory: banking constraints, KYC requirements, and accessibility expectations including the EAA, which has applied across the EU since June 2025. The redesign had to respect all of it while still feeling clear and trustworthy.

Audit approach

I ran a structured audit of the existing flow across three dimensions: usability (clarity of steps, feedback, progress awareness, cognitive load), dead ends (points where users couldn't continue or recover), and accessibility (WCAG compliance and inclusive interaction patterns). The accessibility pass combined manual keyboard testing, screen-reader inspection, code inspection, automated checks, and design review. This audit became the foundation for every redesign decision.

Key problems

Usability gaps. Too many steps with unclear instructions, no indication of progress or effort remaining, and demanding steps appearing too early without context. The result was frustration, lost orientation, and early abandonment.

Dead ends with no recovery. Users could reach points with no way forward: a device without a camera during identity verification, or a missing identification document. They were simply blocked, which meant avoidable drop-offs and lost trust.

UI and hierarchy. Overuse of the primary brand color, weak hierarchy between primary and secondary actions, and dense, crowded screens made it hard to tell what mattered on each step.

Accessibility. The audit surfaced critical and moderate issues: missing ARIA labels and form-field associations, insufficient contrast, missing or unclear focus states, keyboard traps and confusing focus order, and missing landmarks, headings, and skip links. These affect users with permanent disabilities and anyone facing a temporary or situational limitation.

Proposed solutions

A streamlined, transparent flow. Steps reduced, reordered, and grouped into a more logical sequence, with a clear progress bar showing sub-steps and time estimates, and explicit copy explaining why sensitive information is requested. The aim was to reduce uncertainty and make the process feel manageable.

Recovery instead of dead ends. The redesigned flow turns hard blockers into recoverable moments: device switching (move from desktop to mobile via QR or SMS when a camera is needed), progress preserved across the switch, and contextual guidance explaining what went wrong and how to continue.

Clearer structure and hierarchy. Unified layouts across steps, a clear split between primary and secondary actions, and more intentional use of color to guide attention. The goal was clarity and confidence, not visual polish.

Accessibility by design. Designed against WCAG 2.2 AA and EAA requirements: improved contrast using correct brand color combinations, clear and consistent focus states, context-aware alt text that supports the user's goal rather than just describing the image, and design-level recommendations for logical focus order and assistive-technology support.

Outcome

Although this was proposal work, it included a fully interactive Figma prototype for desktop and mobile that let stakeholders experience the redesigned flow end to end. It was used to demonstrate the new flow logic and recovery paths, review clarity and step sequencing with stakeholders, and support discussions on feasibility and next steps. The proposal identified likely sources of friction, inaccessible interactions, and recovery failures that could drive abandonment, and showed how a redesigned flow could improve completion and confidence. Because it didn't proceed to implementation, I don't claim a post-launch outcome; the next step would be moderated usability testing and accessibility validation in the built product.

What I learned

This project reinforced a few things I now carry into every complex flow: treat audits as a design tool, not just an evaluation exercise; design recovery paths instead of blocking flows; address accessibility early, especially in regulated environments; and use UX clarity as the foundation for trust in high-stakes products.