All work

UX Design Manager · Leeroy

Leading the design team for the overall user experience for diners, restaurant staff and owners, from discovery and service journeys to ways of working, UI components and interaction patterns

At Leeroy, I managed the UX design team, combining team leadership with hands-on discovery and user research. Together, we drove design direction and consistency across the platform, shaping the end-to-end user experience. Working closely with customers, users and product owners, we identified needs, pain points and opportunities across the service journey, informing product priorities and roadmaps.

My role
UX design manager, responsible for the overall user experience across all products
Year
2017–2021
User groups and products
Diners: the mobile ordering and loyalty app, and the self-service ordering kiosks. Restaurant staff: the POS and the kitchen apps. Restaurant owners and administrators: the POS back office
Team
User experience designers, one in each cross-functional product team, working as one design team
Company
Leeroy Group
Methods
User research, service mapping and service blueprint, opportunity mapping, human-centred design process, design critique, design principles, interaction patterns and a UI component library
Tools
Sketch
The human-centred design process in five steps, from understanding users’ needs and pains to validating with real users and learning after release, above the products for all three user groups: the ordering app on a phone and tablet, the POS and the self-service kiosk
01

Leading one design team

Designers in separate product teams easily drift apart. My role as UX design manager was to manage and lead the user experience designers as one design team. Each of them worked as the designer in their own cross-functional product team, and together we were responsible for what no single team owned: the overall user experience across the products, the shared interaction patterns and UI component library, and the design thinking process.

As UX design manager, I set the direction and the way of working, coached the designers, made room for critique, and made sure the products felt like one platform for all three user groups: diners, restaurant staff and restaurant owners, across many restaurant brands. I also stayed in the craft, and worked alongside the designers on the shared parts.

How I managed and led the designers

Direction

Design principles for each user group, so the designers could make good decisions without asking every time.

One way of working

One human-centred design process, from discovery to delivery, so designers could understand each other’s work and step in for each other.

Work in the open

Regular design critique, where designers showed their work early, while there was still time to change direction.

Coaching

Feedback on both the craft and the collaboration with product owners and developers in each designer’s own product team.

The right capacity

Design needs aligned with each product owner: shifting our own designers when priorities changed, and recruiting when the need lasted.

Close to the craft

Hands-on in discovery and UX/UI design, especially on the parts shared between products.

And we worked design-led. Product decisions started with customers and users, not with features: their needs and pain points, mapped onto one service journey, became the input to every team’s roadmap.

Shared across teams User experience designers I both led and took part in the craft
  • Design process
  • Way of working
  • UI component library
  • Consistency between products
  • Design critique
  • Design principles
  • UX discovery
Product development team Restaurant staff team POS, table service and back office In the team, the designer
  • UX/UI design of the team’s product
  • User flows and prototypes
  • Testing with users
  • Working with the product owner and developers in sprints
Product development team Consumer ordering team Ordering and loyalty app In the team, the designer
  • UX/UI design of the team’s product
  • User flows and prototypes
  • Testing with users
  • Working with the product owner and developers in sprints

Here I was also Product Lead: discovery, roadmap, priorities and sprint goals

Product development team Kitchen staff team Kitchen display In the team, the designer
  • UX/UI design of the team’s product
  • User flows and prototypes
  • Testing with users
  • Working with the product owner and developers in sprints
Shared responsibilities across the teams, and responsibilities inside each cross-functional product development team. Simplified for this case.
02

Designers where the priorities are

I was also responsible for aligning the need for designers with the product owner of each team. Together, we looked at the roadmap and the work ahead, and decided how much design each team needed.

When one product was prioritised over another, we could shift our own designers between products, since everyone worked by the same process, patterns and UI components. When a team needed more design over time, I recruited.

With the product owner of each team What design does the team need ahead?
  • Roadmap priorities
  • Upcoming discovery and design work
  • Design capacity in the team today
When priorities shift Move our own designers If one product was prioritised over another for a period, a designer could shift to that product, or support it alongside their own team. Possible because of the shared design process, patterns and UI components
When the need lasts Recruit If a team needed more design over time, we defined the role together with the product owner, and I recruited the designer. A new designer joins one shared way of working from day one
How design capacity followed the priorities of the product teams. Simplified for this case.
03

The service blueprint

Mapping the service blueprint was on our table as user experience designers. We made one blueprint for all users and all products on the restaurant platform, front stage and backstage, from the moment a diner decides where to eat, through the visit, to coming back. I led the work and mapped it hands-on together with the designers.

The blueprint was broad, because the platform supported several ways to order: in the app or at a self-service kiosk, to go or to eat in; at the till, to go or to eat in; and at the table, with a waiter. We mapped each of them as a variation of the same blueprint.

It made the dependencies visible to every team. Points promised in the app only work if the till recognises the member. A “ready” notification only works if the kitchen marks the order on its display.

How we mapped it

  1. Six phases of one visitFrom deciding where to eat, through ordering, paying, preparing and getting the food, to coming back.
  2. One blueprint for every sales channelOrdering in the app or at a self-service kiosk, to go or to eat in; ordering at the till, to go or to eat in; and ordering at the table. Each channel as a variation of the same blueprint, so we could see what changed front stage and what stayed the same backstage.
  3. Front stage, per user groupWhat diners and staff at the counter do and see in each phase.
  4. Backstage and systemsWhat the kitchen, the owners’ back office and the systems behind them must do for each step to work.
  5. The lines between themLines of interaction, visibility and internal interaction show where one user group or product hands over to the next.
  6. Walked through togetherWith the user experience designers and the product owners, so that every team recognised its part of the service.

Finding pains and needs with insights from research

The blueprint became our way of finding what to solve. We added the insights from the research to it, step by step.

  1. Insights placed where they happenedInsights from the interviews, observations and co-creation workshops with the three restaurant chains were placed on the phase and the user group they belonged to.
  2. Marked as pains or needs, big and smallEach insight was marked as a pain or a need, so we could see where the service worked and where it broke down for someone. Some were big gaps between products. Many were smaller UX pains inside one step, that the product team could solve in its own flow.
  3. Gaps between front stage and backstageMany pains were not inside one product, but between two: a promise in the app that the till or the kitchen could not keep.
  4. From pains to an opportunity mapBig gaps between products became roadmap opportunities, prioritised with the product owners of the teams they touched. Small UX pains became improvements in each team’s own flow and backlog.
  5. Patterns across productsSmall pains that came back in several channels or products were clustered into patterns, such as speed and clarity in the rush. They became shared solutions in the design principles, interaction patterns and UI component library, instead of being solved once per product.

Scroll sideways to see the whole blueprint.

BeforeThe visitAfter
DiscoverOrderPayPrepareGet the foodReturn
DinerDecides where to eat, and opens the restaurant’s app or walks up to a self-service kioskChooses dishes and orders, to go or to eat inPays in the app or at the kiosk, and earns pointsFollows the order statusGets a notification, picks up, and eats there or takes it awayGets rewards and offers, and comes back
Staff at the counterHands over the orderRedeems rewards at the till
KitchenThe order appears on the kitchen displayMarks the order ready
Owners, back office and systemsMenu, offers and opening hours, set by the restaurantMenu and prices synced with the POS, the app and the kioskPayment provider and loyalty engineOrder routed to the POS and the kitchenNotification to the diner that the order is readyCampaigns and loyalty rules, set by the owner
Pains and needsUX pain · DinersHard to see if the restaurant takes orders right nowPain · OwnersChanging the menu in several placesUX pain · DinersHard to change an extra or a side once it is in the basketPain · DinersPoints in the app did not follow to the tillUX pain · DinersToo many steps to pay, and the card details asked for againPain · KitchenApp orders not seen together with the other orders in the rushUX pain · DinersUnclear how long the order will takeNeed · DinersKnow when the order is ready, without askingUX pain · DinersHard to find where to pick up the orderNeed · OwnersBring diners back with offers and rewardsUX pain · DinersHard to see how many points are left to the next reward
OpportunitiesImprovement in the team’s flowShow if the restaurant is open and taking ordersRoadmap opportunityOne menu in the back office, for every sales channelImprovement in the team’s flowEdit extras and sides directly in the basketRoadmap opportunityOne membership, recognised in the app, at the kiosk and at the tillImprovement in the team’s flowA saved card and fewer steps to payRoadmap opportunityOrders from every channel on one kitchen displayImprovement in the team’s flowShow the estimated time and the order statusPattern · Knowing where my order isRoadmap opportunityA ready notification as soon as the kitchen marks the orderImprovement in the team’s flowShow where to pick up, with the order numberPattern · Knowing where my order isRoadmap opportunityOffers and rewards that the owner sets once, for every channelImprovement in the team’s flowShow the points left to the next rewardPattern · Loyalty you can see
Patterns across products Speed and clarity in the rush Knowing where my order is Loyalty you can see
A simplified version of the service blueprint in three variations, one for each way to order, with examples of pains and needs from the research placed on it, from big gaps between products to smaller UX pains in a single step, and what they became: roadmap opportunities, improvements in each team’s flow, and patterns across products. Redrawn for this case.
04

From opportunities to the product roadmaps

Across all products, design led the UX discovery. The pains, needs and opportunities on the service blueprint fed the product roadmaps ahead, for every product team, not only the one I led myself.

They were never the only input. Sales brought what restaurant chains asked for. Technology brought the integrations, platform work and quality that had to be in place. Leaders at Leeroy brought the business goals and the direction for the platform. Together with the product owners, we weighed it all against each other: user value, business value and technical effort.

My part was to keep customers and users visible in that balance. An opportunity with a clear pain behind it, placed where it happened in the service, was easier to prioritise than an opinion, and it often answered a sales or business need at the same time.

Needs fromCustomers and usersPains, needs and opportunities from the service blueprint and the research
Needs fromSalesWhat restaurant chains asked for, and what it took to win and keep them as customers
Needs fromTechnologyIntegrations, platform work and quality that had to be in place
Needs fromLeaders at LeeroyBusiness goals and the direction for the platform
Weighed together with the product owners What should each team build next, and why?
  • User value
  • Business value
  • Technical effort
Product roadmap aheadRestaurant staff teamNowNextLater
Product roadmap aheadConsumer ordering teamNowNextLater
Product roadmap aheadKitchen staff teamNowNextLater
Pains, needs and opportunities fed the product roadmaps, side by side with needs from sales, technology and leaders at Leeroy. Simplified for this case.
05

One design process

The design process was a shared responsibility of the user experience designers, and I both led it and worked in it. Every product team worked by the same process, from discovery to delivery. That made it possible for designers to understand each other’s work, step in for each other, and give each other useful feedback.

  1. 1DiscoverResearch with customers and users, and their needs and pains.
  2. 2DefineOpportunities, user flows and what to solve first.
  3. 3DesignConcepts and prototypes, shared early.
  4. 4TestWith users, before anything is built.
  5. 5DeliverDevelopment-ready UI, followed up with the team.
The design process every product team worked by. Simplified for this case.
06

Design critique

I made room for regular design critique between the designers. Each of them worked in their own product team, so critique was also where we saw each other’s work, kept the products consistent, and learned from each other.

Show work early

Designers brought sketches and prototypes, not finished screens, while there was still time to change direction.

Start from the user and the goal

Feedback began with who the design was for and what it should achieve, not with taste.

Specific and kind

Concrete, respectful feedback that the designer could act on.

Eyes from other products

Designers from the other product teams spotted where a flow broke a pattern, or touched their product.

07

Design principles for every product

From the research, we set design principles for every product on the platform. Each product had its own users and context, so each got its own principles. They gave the designers and the product teams a shared way to decide, without having to ask every time.

  1. The mobile ordering and loyalty app, and the self-service ordering kiosksDiners
    • The brand comes first: the app is the restaurant’s, not ours
    • Order in a few taps
    • Always know the status of the order
    • One membership in the app and at the till
  2. The POS and the kitchen appsRestaurant staff
    • Fast in the rush: the most common orders in the fewest taps
    • Large touch targets, readable at a glance and from a distance
    • Orders from every channel in one place, in the right order
    • One tap to mark an order ready
  3. The POS back officeRestaurant owners and administrators
    • Set it once, use it everywhere: products, prices and menus for the POS, the app and self-service ordering
    • See every venue and sales channel at a glance
    • Safe to change, with a clear view of what goes live where
Design principles for each of the three main user groups and their products. Simplified for this case.

How we came up with them

  1. Started from the researchThe needs and pains of each user group, from the interviews, observations and co-creation workshops with the restaurant chains.
  2. Looked at each product in its real contextA phone in a queue, a desk in the back office, a busy till, a table in a full room, a hot kitchen.
  3. Drafted them togetherIn workshops with the designers and the product owners, we turned the insights into a few principles per product.
  4. Tested them on real decisionsWe used the principles in design critique and on real design choices, and sharpened the ones that did not help us decide.
08

Shared patterns and one UI component library

The products had very different users and contexts: a diner on a phone, an owner at a desk, staff at a busy till, a waiter at the table, a kitchen in the rush. Shared design principles, interaction patterns and a common UI component library gave them one consistent experience, and each product adapted them to its users. In the white-label app, each restaurant brand added its own theme on top.

The apps were built on the native iOS and Android components. Our UI component library added the shared interaction patterns on top, and let each restaurant brand bring its own theme to the same components. Here are some of them, as they appeared in the apps.

DinersMobile app and kiosks, with one theme per restaurant brand Restaurant staffThe POS and the kitchen apps Owners and administratorsThe POS back office
Common UI component libraryShared interaction patterns, components, colours, typography and icons
Shared interaction patterns and one UI component library for three user groups. Each product adapts them to its users and context. Simplified for this case.

Hero with a call to action

Each brand’s own image, message and order button.

List rows for navigation

Icons and arrows that lead to ordering, offers, orders and restaurants.

Category tabs and product cards

The brand’s own categories, with image, name and price.

Loyalty card and points

The member’s points and level, in each brand’s own style.

Membership card to scan

A barcode to scan at the till, so the points follow the member.

Offer details

A sheet with the offer, the terms and who it is for.

Self-service ordering

Category chips, quantity stepper, total and a pay button on the kiosk.

UI components cropped from screens of the apps for different restaurant brands, and from the self-service kiosk. The same components, each with the brand’s own theme.
09

Learnings

Looking back, three things stay with me from leading the design team at Leeroy.

1

Designers need two homes

Each designer belonged to a cross-functional product team, and that is where they felt ownership. But designers in separate teams easily drift apart. Shared critique, one design process, and shared interaction patterns and UI components gave them a second home in the design team. Both homes mattered: one for owning a product, the other for growing in the craft and keeping the platform consistent.

2

Principles scale better than approvals

As the products and the team grew, I could not look at every design decision myself, and I should not have to. Design principles for each user group, shared interaction patterns and a common UI component library let the designers decide well on their own. Leading the design team became more about setting direction and making the reasoning visible than about signing off.

3

The service blueprint gives everyone the helicopter view

One service blueprint for the whole platform helped the designers see how their product connected to the till, the kitchen and the back office. It also gave them a strong way to argue for user needs with their product owners, because a pain point placed in the service is hard to ignore.

More of my responsibilities at Leeroy

At Leeroy, I had several responsibilities. Each one is its own case.

Product Leadership · LeeroyLeading a mobile ordering and loyalty app for restaurant brandsProduct discovery, end-to-end flows, business model, roadmap, sprints and the KPIs for the ordering and loyalty app.See the case
Next case · Product Leadership · Leeroy Leading a mobile ordering and loyalty app for restaurant brands