Strengthening Westpac's RED design system

RED is Westpac New Zealand’s design system. When its core team left, the reasons behind many of its decisions left with them. For about a year, anyone could publish a component to RED, and nobody checked it. Issues were building up, and Brand was asking questions the team couldn’t answer.

I put my hand up to take it on. There was no dedicated design system designer. I spent almost seven months focused on the system while I was between product projects, then kept going alongside product work, from December 2023 to April 2026.

The visuals on this page are reconstructed to explain my part. Original internal documents are not reproduced.

Two developers were funded to work on the system, but there was no design role for it. I owned the design side.

• I owned the design backlog, the token definitions, the colour and type scales, the review standards and the file template.
• I worked with the development lead and mobile developers through planning and stand-ups. They owned the code and the pipeline into it.
• I worked with Brand and design leadership on colour, and with the mobile design lead on reviews.

Without an owner, three problems had built up.

• No quality control. Anyone could publish components, and issues were building up.
• Lost knowledge. Designers didn’t understand how the tokens were meant to work.
• Ageing components. Many were built in 2020 and 2021, before newer Figma features existed.

At the same time, two new needs arrived.

• A new theme. Westpac Australia had updated its brand, so RED needed a new theme, Together Greater.
• Dark mode. The apps needed dark mode, so every colour and token had to work in both light and dark.

My first move was to stop the problem growing. I told the team in advance, removed general publishing access, and set a rule that shared components needed review before release. Then I gathered issues from designers, developers and Brand, and put them on a design system Kanban board.

That last decision shaped everything after it. The libraries needed work, and the team needed clearer ways to use and look after them.

Tokens and Figma variables

The tokens had three layers: global values, contextual tokens and component tokens. Designers often picked a token because its colour looked right, even when it was meant for something else. A divider token might end up on a button border.

I audited the libraries and worked with the development lead to see how tokens were used in code. I removed unused tokens, added missing ones, and wrote down how each layer should be used. Then I moved the tokens into Figma variables, with light and dark modes for Together Greater, the updated theme. Developers built a pipeline that took published variables into the code libraries.

One colour scale across platforms

The colour work started with Brand. They asked why our products weren’t using the brand shades, and they had a point. Some shades had drifted from the brand colours. Some colours had more than 20 shades, others only four. Each mobile platform had its own greys, added without a shared method.

Developers had fair concerns about effort, testing and breaking existing screens, so we weighed consistency against cost and risk. Over several conversations and trials, we agreed on:

• one method for creating shades, adjusted for brand, contrast and platform needs
• one grey scale for text and backgrounds across web, iOS and Android
• platform-specific treatments kept where they were needed.

The revised tokens were released into the existing apps. We checked contrast as part of this work. It wasn’t a full accessibility audit, and older screens with hardcoded colours went on the backlog.

Type and components

I simplified the type scale around a 4px baseline, with clearer names, following iOS and Material Design guidance for mobile. I rebuilt older components with auto layout and on/off options, so fewer separate versions were needed for each screen size.

Review for every shared component

I set review standards covering tokens, colour, type, spacing and documentation. If a contribution didn’t meet them, I sent it back before it was published. At first I ran reviews with the mobile design lead. Later we set up a review team, with weekly updates and monthly question sessions for designers.

A shared workspace and file template

Five years of Figma files had piled up, each with its own structure and naming. Copying screens from old files brought old components back into new work. After several rounds of discovery with designers and developers, we co-designed a new workspace structure in online workshops.

The shared template gave every project the same pages, following the design process. The “Ready for dev” page sat near the top, so developers always knew where to look. We also agreed naming conventions, so files and frames were easier to search and reuse.

I brought all of this together in a workbook called Ways of Working in Figma. We agreed a cutover date, and every project starting after it used the new template. For existing projects, I met designers one-to-one with a checklist to decide whether to move across. Most active projects did.

The biggest change was clarity. Designers knew which tokens to use and what good looked like. Developers knew where to find work that was ready to build. Developers responded well to the consistent page structure, especially the “Ready for dev” page. I also saw more consistent component use and fewer repeated questions. These are things I observed myself. The one measured figure came from the development lead, who estimated that design-to-development time dropped by about 30%. It was shared with executives as part of regular reporting.

By the time I handed over, we had:

• moved tokens into Figma variables, with a pipeline that took them into code
• brought colours back in line with brand, with one grey scale across all platforms
• updated components across web, iOS and Android
• set up a review team, weekly updates and monthly sessions
• rolled out a shared template used by every new project and most active ones
• handed a roadmap and backlog to another senior designer.

Some work was still open. The next-generation app was in progress, and legacy screens with hardcoded colours sat in the backlog. The next owner had a clear record of both.

Ownership needs time set aside. Almost seven months of focused work built momentum. Keeping it going alongside product work was harder. We had asked for dedicated people, and people leaders looked for funding. Looking after a system is ongoing work, and it needs real capacity.

Knowledge has to outlast people. RED struggled because its reasons left with its team. That’s why I wrote down the token layers, the decisions and the backlog, and handed over a roadmap, not just the files.