When Tangerine's design system stopped working—and what we did about it

The Challenge

Tangerine's design and code were fragmented. 3 makeshift “design systems”. Components weren't accessible, design debt was piling up, and teams were rebuilding the same patterns repeatedly. Customer feedback conveyed our experience as "slow," "confusing," and "old."

Through stakeholder and team interviews, we aligned on this question:

How might we centralize design and development to preserve quality, increase velocity, and deliver an exceptional tangerine experiences to all clients?

The Approach

Building the Business Case

Before designing anything, I needed organizational buy-in. I framed the system around clear business value:

• Efficiency: Reuse components instead of rebuilding from scratch

• Scale: Give teams the assets they need, when they need them

• Cost reduction: Less duplication, refactoring, and unnecessary testing

• Coherence: Shared principles for consistent experiences

• Customer expectations: Address feedback on usability and performance

• Accessibility: Remedy AA violations and prevent future issues

Establishing Governance

A design system without governance doesn't scale. We adopted a hybrid model—a central team (accessibility specialist, systems architect, developers, and myself) overseeing the system, with external teams contributing.

Tools and Foundation:

• Material Design as our foundation (tried, tested, flexible)

• Open source components for speed

• Centralized code library for developers

• Centralized design guidelines and UI kit for designers

This pragmatic approach let us move faster than building 100% custom components while still crafting a unique Tangerine experience.

Key User Journeys

We mapped journeys for designers and developers using the system:

• Find a component

• Get an icon

• Contribute an asset

• Find a pattern

• Test compliance

• Create a layout

• Write content

• Visualize data

The system grew beyond components—it became infrastructure for future-proofing Tangerine across any platform: web, mobile, wearables, ATMs, voice, in-person.

Content Model and Component Types

We created a content model to create a taxonomy (shared understanding of definitions) of our entire business. ThThis naturally created 3 levels of components.

Basic Components
The smallest, indivisible UI elements that can't be broken down further while remaining functional.
(i.e. buttons, toggles, badge)

Compound Components
Combinations of basic components that work together as a cohesive unit to perform a specific function.
(i.e. tables, cards, form field)

Entity Components
Complex components that represent actual business entities or concepts. They are the visual manifestations of real-world objects, data structures, or business logic within the Tangerine business.
(i.e. account, payee, contact)

Results

70+ components designed and documented

30+ components codified and production-ready

50% decrease in design time

8 client journeys built entirely from system components

AA accessibility compliance across all components

Early user research showed strong positive feedback on usability, performance, and consistency.

What I Learned

Align on principles first. Get key players in the room early. Clarity on the true problem keeps decision-making focused and prevents scope creep.

Build a cross-functional team. Without developers, accessibility specialists, QA, and writers, you miss opportunities to get things right at the beginning. The insights from diverse skills pay off later.

Design for the long term. A design system is a product. It serves users and adapts with them. Make decisions based on long-term goals, not short-term satisfaction.