<aside> 📌

A system where there had been a patchwork. 5 loyalty features had shipped independently and stopped working together. I mapped every combination an operator could enable and designed a modular structure the UI adapts to.

A decision I can defend. Operators wanted every loyalty feature visible at checkout. I prioritised the entry point instead, keeping the last screen before payment clear and the rest one tap away.

Handoff developers could build from. 6 variables and 90+ copy states resolved before the build started rather than discovered during it.

</aside>

<aside> 🧭

</aside>

Context

A banner that grew into 5 loyalty features

At the start, one banner on the basket screen and one discount code per order. Over the next few years it grew.

• Sign-in - user ID, then phone, email and face scan, plus a branded loyalty screen
• Discounts - multiple vouchers at once, managed in a discount hub I designed
• Redemption - keyboard, keypad or a reward list
• Automation - a wallet applying rewards on its own, stamp cards planned next

The original loyalty flow. A single banner with one manually entered code per order. Every feature that followed was added on top of this.

5 loyalty features live at once, each shipped on its own. Nothing defined how they should sit together, so every new one made the basket screen harder to manage.

<aside> 🔒

The business cost was real. Every new loyalty integration required design work from scratch and weeks adapting the existing system to fit it in. What should have been straightforward feature additions became extended projects, with scope, timelines and costs growing each time.

</aside>

My role

I led the design from scoping to handoff

• Owned UX structure, component architecture and visual direction, from scoping to handoff
• Supported by a second designer on flows and documentation
• Worked with my manager on direction, developers on handoff, and the Product team on framing the modular approach as product strategy