2022-2025 | Snr. Product Designer | Post Office

THE CHALLENGE

A system nobody trusted enough to use

When Post Office began replatforming to a new CMS, the design system underneath it was already broken. Components were detached, inconsistently applied, and undocumented. CMS editors were improvising layouts because the system gave them no authority to do otherwise. Dev teams were flagging visual, spacing, and interaction inconsistencies across every major journey - Travel Money, Insurance, Mails, and Banking. The replatform was the opportunity. The design system needed to be rebuilt alongside it.

PROBLEM DISCOVERY

The cracks weren't cosmetic

The inconsistency wasn't just a visual problem - it was a delivery problem and a conversion problem. QA rounds were long because nobody had defined what correct looked like. CMS editors couldn't justify component choices to product owners, so pages launched misaligned. High-traffic revenue journeys like card top-ups, insurance quotes, and parcel ordering were running on components that had been stretched, reformatted, and detached from any shared standard.

The system wasn't scaling because it was never built to. It had grown by accident, not design.

THE DEAD END

Updating components wasn't enough

The initial scope was to refresh the existing component library - tidy it up, improve responsiveness, align it to the brand refresh. Work started, and it became clear quickly that refreshing broken foundations just produced better-looking broken foundations. Components without documentation got misused. Updated modules without usage guidance got ignored. The system needed authority, not just aesthetics.

SOLUTION

Build the system people actually use

I owned the design system's evolution from day one of the replatform through to my final day at Post Office - three years of continuous iteration across Figma, the component library, the illustration library, and the handover process.

The rebuild started with the components that touched the most revenue - homepage heroes, dynamic content cards, CTAs, product tiles, and help modules. Each was rebuilt with set variables, consistent spacing, and responsive logic. Each shipped with inline documentation: interaction behaviour, padding logic, variant rules, and usage guidance embedded directly in the working file so editors didn't need to ask.

A new Parcels Online module was designed from a brief to drive homepage conversions - using user data and testing to build a personalised postage quote tool that simplified a previously multi-step journey into a single homepage interaction. It improved task completion and CTR, though I flagged formally that it pushed Insurance and Travel Money further down the page - sparking a round of homepage IA testing to rebalance visibility across core journeys.

Alongside components, I built a scalable illustration and iconography library aligned to Post Office's updated branding, covering 20+ product journeys and campaigns. Walkthrough sessions with CMS editors and product owners replaced one-to-one training, and master guidelines gave teams a reference they could use independently.

The handover process evolved throughout - from ad hoc Figma files to a structured, documented system that dev teams, CMS editors, and product owners all worked from as a single source of truth.

THE TECHNICAL LAYER

Systems thinking at component level

The design system wasn't a pattern library - it was a technical product with its own logic, constraints, and dependencies. The decisions that shaped it were architectural as much as visual.

Component tokens were structured to support multiple product contexts - the same spacing, colour, and type variables needed to work across Travel Money transactional funnels, Insurance quote flows, Mails campaign pages, and Banking product tiles simultaneously. Each had different third-party integration constraints, meaning components had to be built with fallback logic and edge case documentation baked in rather than assumed.

Responsive behaviour was defined at component level, not page level - meaning a CMS editor building a new product page inherited correct mobile behaviour without needing a designer to specify it. Interaction states, focus logic, and screen reader behaviour were documented as functional specs, not visual guidelines.

The result was a system other teams could use to make technically sound decisions independently - which is what reduced QA rounds and CMS build time at scale.

IMPACT

One system. Every team. Measurable results.

+40% Component reuse across core revenue journeys - less duplication, faster decisions

↓30% Fewer QA rounds - cleaner specs and stakeholder walkthroughs reduced visual inconsistencies before launch

+50% Faster CMS build time - editors shipped pages independently with fewer blockers and less UX intervention

+23% Module engagement uplift on updated homepage and Parcels Online components

£4.5k saved per quarter in reduced UX dependency across CMS and product owner workflows

REFLECTION

A design system is never finished

Three years on the same system taught me that the work is never done - it evolves as the product evolves. The most important thing I built wasn't a component or a library. It was the process that let other teams move without waiting for a designer. The Parcels Online tension - where a high-performing new module displaced existing high-value journeys - was a reminder that system decisions have page-level consequences. Flagging it early and pushing for IA testing was the right call. Catching those second-order effects is part of owning a system at scale.