PIE Design System

In 2025, PIE was shortlisted for the Design System Awards Best Adoption category — run by zeroheight, the leading platform for design system documentation. Past winners include Pinterest, Wise, Eventbrite, and Schneider Electric. The nomination recognises systems that have demonstrated exceptional adoption strategies, not just technical quality.

This nomination matters personally because it validates the approach I work within every day. The award isn't recognising a finished artefact — it's recognising a living culture of adoption, and that culture is one I've actively contributed to and benefited from.

Just Eat Takeaway operates across 17 countries, serving customers, restaurant partners, and courier networks through a suite of apps and platforms that span iOS, Android, and web. Before PIE, growth through mergers had introduced multiple design languages, legacy systems, and inconsistent UI patterns across regions — a common consequence of acquisition-led scale.

PIE — Principles for Interfaces and Experiences — was built to unify this. But building a design system is the easier half of the problem. Getting hundreds of designers and engineers across a global organisation to actually use it, trust it, and build with it over their own instincts — that's the hard part. That's what the Best Adoption nomination recognises.

PIE's design decisions — from component architecture to documentation tone — are grounded in four principles that apply equally to how the system is built and how it treats the teams using it:

My position within PIE is dual: I contribute directly to the system itself alongside the core PIE team, and I embed that system into the Logistics product area — designing tools for the courier and partner networks that power Just Eat Takeaway's fulfilment operations.

This dual role is an advantage. Working in Logistics means I encounter the real friction of adoption — the edge cases components don't cover, the documentation that isn't clear enough, the tokens that need extending for specific contexts. Those findings feed directly back into PIE, making me both a consumer and a shaper of the system.

I work closely with the PIE design team: Molly Nye, Ting Ting Lau, Talitha Ferreira, and Philip Lackmaker.

My work within PIE spans the full spectrum of design system practice — from foundational token work to hands-on adoption support for engineers and designers who are new to the system.

The Design System Awards jury specifically called out PIE's approach to adoption as emotionally intelligent, not just technically sound. Understanding why adoption succeeded at this scale is as important as the technical work itself.

PIE is not a component library with a colour palette. It's a complete design and engineering infrastructure — foundations, components, patterns, platform support, and tooling — that scales from a single button to a full product experience across five platforms simultaneously.

Adoption is a design problem, not a communication problem. The systems that fail don't fail because people weren't told about them. They fail because using them was harder than not using them. Every contribution I make to PIE is evaluated through that lens first: does this make the right choice easier?

Working in both Logistics and PIE core creates a feedback loop that pure system designers don't have. I encounter real adoption friction daily — edge cases, missing tokens, documentation gaps — and I'm positioned to fix them rather than just report them.

Scale changes everything about how you design components. A component used by 500 engineers on five platforms can't have ambiguous specs. The discipline of designing for that scale has permanently changed how I approach component work, even on smaller systems.

Accessibility built in is categorically different from accessibility retrofitted. Working on a system where accessibility is a founding principle rather than a compliance checklist has given me a completely different relationship with inclusive design — it becomes a design constraint that produces better work, not a restriction that limits it.

The best design system culture is one where people are proud to use it. Systems that feel like infrastructure get circumvented. Systems that feel like craft get championed.