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
Repeating architectural grid structure
products unified
20+
features
300+
design team, UK and Brazil
1 → 5
booking conversion uplift, Collins Evo
24%

Access Group acquired QikServe in 2024, and my design remit went from one product family to twenty-plus products and three hundred-plus features. They had been built in different eras by different companies, and they were now expected to feel like one platform. Evo is the design system we built to make that expectation survive contact with the products.

A portfolio pretending to be a platform

Every product carried its own navigation logic, its own form patterns and its own colour decisions, each made sensibly in isolation and sometimes a decade apart. A customer who bought two Access hospitality products could tell straight away that they had been built by strangers, and across a portfolio that size the incoherence showed up in sales calls and onboarding time rather than in design reviews. None of the teams could stop shipping while the language unified. So the system had to be adopted in motion.

The single-UI ambition

The ambition inside Access was one interface approach across everything, guest-facing product and internal tooling alike. I argued against it. Access is genuinely strong at internal tools, and that strength is the reason the approach does not transfer: software a trained employee opens every day for three years can ask things of a person that a guest ordering a coffee once a month cannot. Convergence was right. Convergence to one interface was not.

Whose pattern wins

The hardest decisions were never visual. When two products solve the same problem differently, one team's work becomes the standard and the other team's becomes migration backlog, and handled carelessly that breeds the resentment that kills a design system long before any technical flaw does.

So we made losing cheap. Every convergence decision shipped with a written rationale, a migration path and tokens that did most of the mechanical work. We picked battles in the order that mattered to guests and operators rather than the order that annoyed designers, and we let teams keep local patterns where a real product difference justified them, which made the mandatory parts far easier to enforce. When two patterns argued to a draw we asked which one a tired operator would understand faster at the end of a shift. That question settled more disputes than any style principle.

How adoption actually worked

Teams adopt a design system when it is cheaper than not adopting it, so adoption was designed as deliberately as the components were.

  • 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 an exception needed a written reason
  • Accessibility standards inherited from the kiosk work, applied portfolio-wide as a baseline rather than a feature

Growing the team inside the system

I started as the only product designer and built the team to five across the UK and Brazil, and Evo became the shared ground that let them work apart. 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. I began using the handover as the quality bar: a pattern clear enough to survive being passed to Brazil overnight was clear enough for a product team I had never met.

DesignMyNight shows what that looked like on one product. The engagement was never a root-and-branch redesign. What changed was that it had a whole professional design team behind it for the first time, with Hannah Walker, from my team, embedded as its designer, bringing everything we had built for online ordering and the kiosk. A light redesign made the information hierarchy clear page by page: where is it, what is it, when is it on, what does it cost, is it available. We kept cognitive load low, and trained their product team on those principles until they owned and championed them. Accessibility was core, because I had a distinct responsibility for accessibility across the hospitality division, starting with simple things such as contrast. All of it without a lot of budget or time.

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 the feature and integration count
  • Customer-facing teams, whose reports of inconsistency were the original business case

What I would do differently

I would start the governance conversations earlier. We led with tokens and components because they are tangible, then retrofitted the contribution rules once adoption created pressure, and the reverse order would have saved a quarter of negotiation because teams commit harder to rules they helped write before those rules applied to them.

I would also make the commercial case from day one. Consistency and craft never moved budget. What moved it was that a coherent platform sells better, demos better and onboards faster, and I have used that argument in every systems conversation since.