Case study
Access Evo
The platform design system unifying a portfolio of hospitality products into one coherent, scalable language.
- Client
- Access Group
- Role
- Hospitality UX Lead
- Timeframe
- 2024–2026
- Sector
- Hospitality technology
- products unified
- 20+
- features
- 300+
- design team, UK and Brazil
- 1 → 5
- booking conversion uplift, Collins Evo
- 24%
When Access Group acquired QikServe, my design remit widened from one product family to a portfolio: twenty-plus products and three hundred-plus features, built in different eras by different companies with different assumptions, suddenly expected to feel like one platform. Evo is the design system that made that expectation honest. It occupied most of my final two years at Access, and it's the project where design leadership and organisational politics became the same discipline.
A portfolio pretending to be a platform
Acquisition decks say unified platform long before anything is unified. In reality, every product carried its own navigation logic, its own form patterns, its own colour decisions, each made sensibly in isolation, sometimes a decade apart. Customers who bought two Access hospitality products could tell instantly that they'd been built by strangers. Across a portfolio that size, that sort of incoherence costs sales, demos and onboarding time.
A design system for one product is a component library. A design system for an acquired portfolio is a negotiation between twenty teams, each with its own debt, deadlines and pride of authorship. None of them could stop shipping while the language unified, so the system had to be adopted in motion, like changing tyres at speed.
The politics of convergence
The hardest decisions weren't visual. They were about whose pattern wins. When two products solve the same problem differently, one team's work becomes the standard and another team's becomes migration backlog. Handle that carelessly and you breed the resentment that kills design systems faster than any technical flaw does.
So we made losing cheap. Every convergence decision shipped with a documented rationale, a migration path and tokens that did most of the mechanical work. We picked battles in order of guest and operator impact, not in order of which inconsistency annoyed designers most. And we let teams keep local patterns where genuine product difference justified them, which made the mandatory parts far easier to enforce.
The forcing function was always the person at the end. When two patterns argued to a draw, we asked which one a tired operator at the end of a shift would understand faster, and that question settled more disputes than any style principle did.
A platform design system is an alignment exercise with a UI attached.
How adoption actually worked
Adoption was designed as deliberately as the components were. Nobody adopts a design system because it's beautiful. They adopt it because it's cheaper than not adopting it, and we engineered for exactly that.
- Tokens first, so products could inherit colour, type and spacing without rebuilding screens
- Components released with documentation and Figma libraries in the same week, never one without the other
- A contribution model, so product teams could propose patterns rather than only receive them
- Governance light enough to move at product speed, firm enough that exceptions needed a written reason
- Accessibility standards inherited from the kiosk work and applied portfolio-wide as a baseline rather than a feature
Growing the team inside the system
Evo and the design team grew up together. I'd started as the only product designer and built the team to five across the UK and Brazil, and the system became our shared ground. New designers were productive in their first week because the decisions that normally take months to absorb were written down, tokenised and enforced in the libraries.
The geography turned out to be an asset. Work handed between the UK and Brazil kept moving, and the system absorbed the difference in context. If a pattern was clear enough to survive a handover across time zones, it was clear enough for a product team we'd never met. We treated that as a quality bar.
Team and credits
Evo belonged to a lot of people, which was rather the point.
- The product design team, who built, documented and defended the system daily
- Engineering leads across the Access hospitality portfolio, who turned tokens and components into shipped product
- Product owners on twenty-plus products, who made roadmap room for migration work that never wins applause
- Platform engineering, who kept the system honest against 300+ features and 100+ integrations
- Customer-facing teams, whose reports of inconsistency were the original business case
What I'd do differently
I'd start the governance conversations earlier. We led with tokens and components because they're tangible, then retrofitted contribution rules once adoption created pressure. The reverse order would have saved a quarter of negotiation, because teams commit harder to rules they helped write before the rules applied to them.
I'd also write the case for the system in commercial language from day one. Consistency and craft never moved budget. What moved it was the argument that a coherent platform sells better, demos better and onboards faster than twenty products in a trench coat. I learnt to make that argument fluently on Evo, and I've used it in every systems conversation since.