All work

Line Manager for Designers · Leeroy

Managing the design team through the shift from UX Designers to Product Designers, crafting the design and leading the product development

As UX Design Manager at Leeroy, I was the line manager for the design team: the UX designers who, during my time, became Product Designers. Once the core of the platform was in place and our products were used by several customers, the focus moved to improving them and adding new functionality, driven by product discovery with customers and users. The designers took over the Product Owner responsibilities: they ran UX discovery, framed the problem for new or improved user experiences, owned the backlog planning and prioritisation in their product teams, and delivered development-ready design for the developers to build. They worked closely with the Product Managers, who were responsible for product discovery and the roadmap themes. I contributed to the shift, and as line manager I gave the designers what they needed: shared product design work, time to improve the design system, one design process, design critique, retros, skills development and hiring.

My role
UX Design Manager, line manager for the design team, responsible for the overall user experience across all products
Year
2017–2021
Line manager for
The UX designers, after the shift called Product Designers
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
Product designers, one in each cross-functional product team, working as one design team
Company
Leeroy Group
Methods
User research, service blueprint, opportunity mapping, human-centred design process, design critique, design principles, interaction patterns and a UI component library
Tools
Sketch
The design team’s shift from UX/UI designers to Product Designers, and my line manager responsibilities: design system, design process, design critique, retros, skills and hiring, above the products for all three user groups: the ordering app on a phone and tablet, the POS and the self-service kiosk
01

From UX Designers to Product Designers

At Leeroy, I was the line manager for the design team: one designer in each cross-functional product team, working together as one design team.

While the core of the product platform was being built, the designers had typical UX/UI design responsibilities. Once the core was in place, and our products were out and used by several customers, the important work became improving them and adding new functionality, driven by product discovery with customers and users.

Before: building the core platformUX/UI designers
  • Typical design craft, from ideas to development-ready design
  • Designing the core products, while the platform was built
  • Product Owners owned the backlog
After: improving products in useProduct Designers
  • Running UX discovery, and framing the problem for new or improved user experiences
  • Development-ready design for the developers to build
  • Owning the backlog planning and prioritisation with the team
What changed for the designers once the core of the platform was in place. Simplified for this case.

A new split of responsibilities

The UX/UI designers became Product Designers, taking over the Product Owner responsibilities. They ran UX discovery and framed the problem for new or improved user experiences, owned the backlog planning and prioritisation together with their product team, and delivered development-ready design for the developers to build. They worked closely with the Product Managers, who were responsible for product discovery and the roadmap themes.

I contributed to the shift. My core responsibility was to be the line manager for the designers, before and after it, and to make sure they could grow into the new role.

Discovery and the roadmapProduct Manager
  • Product discovery with customers and users
  • The roadmap and its themes
  • Align user and business needs
User needs, the backlog and the craftProduct Designer
  • Run UX discovery and frame the problem
  • Backlog planning and prioritisation with the team
  • Development-ready design for the developers
  • Work closely with the product manager
Line manager for the designersUX Design Manager
  • Shared product design work
  • The design system and the design process
  • Skills, retros and design critique
  • Hiring, and the everyday line manager work
How responsibilities were shared in the cross-functional product teams after the shift. Simplified for this case.
02

Leading the design team as line manager

Each product designer was part of a cross-functional product team, and was responsible for customer and user needs, and the backlog planning and prioritisation together with the team. As their line manager, I made sure that apart from the product development, they had time to continuously improve the design system, and that we kept following our design process. I also handled hiring and the other everyday responsibilities of a line manager.

Shared across teams Product 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 product designer
  • UX discovery, and framing the problem
  • Backlog planning and prioritisation with the team
  • User flows, prototypes and testing with users
  • Development-ready design for the developers
Product development team Consumer ordering team Ordering and loyalty app In the team, the product designer
  • UX discovery, and framing the problem
  • Backlog planning and prioritisation with the team
  • User flows, prototypes and testing with users
  • Development-ready design for the developers

Here I was also the Product Manager: discovery, roadmap and priorities

Product development team Kitchen staff team Kitchen display In the team, the product designer
  • UX discovery, and framing the problem
  • Backlog planning and prioritisation with the team
  • User flows, prototypes and testing with users
  • Development-ready design for the developers
Shared responsibilities across the teams, and responsibilities inside each cross-functional product development team. Simplified for this case.

My responsibilities as line manager

Shared product design work

The work no single product team owned: the overall experience, and the parts shared between products.

Design system

Time for the designers to continuously improve the design system, alongside the product development.

Design process

Making sure we kept following one design process, from discovery to delivery.

Skills and coaching

Developing each designer’s craft, and supporting them in their new responsibilities for user needs and the backlog.

Retros and design critique

Regular retros, and design critique where designers showed their work early and learned from each other.

Hiring and capacity

Recruiting designers, and aligning design capacity with the product managers when priorities shifted.

03

Creating a shared view of the experience

With decisions made inside each product team, the teams needed a shared view of the whole service. We made one service 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.

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. With the blueprint in front of them, the product teams could make better decisions together, also about the parts they did not own.

Finding pains and needs with insights from research

  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

Connecting discovery to product direction

The product managers were responsible for product discovery and the roadmap themes. The pains, needs and opportunities on the service blueprint, from the designers’ work with customer and user needs, fed the product roadmaps ahead, for every product team.

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 managers, 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 managers 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

Scaling design quality across teams

With more decisions made inside each product team, shared standards kept the experience connected. Instead of approving every design, I made sure the designers had what they needed to decide well on their own.

One design process, and design critique

Every product team worked by the same design process, from discovery to delivery, so designers could understand each other’s work and step in for each other. Regular design critique was where they saw each other’s work, kept the products consistent and learned from each other.

  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.

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.

Design principles for every product

From the research, we developed design principles for every product together: the designers, the product teams and I. Each product had its own users and context, so each got its own principles. They gave the product designers the confidence to make decisions within their teams, 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.

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 interaction patterns and a common UI component library gave them one consistent experience, and each product adapted them to its users. The apps were built on the native iOS and Android components, and our library added the shared patterns on top, with each restaurant brand bringing its own theme.

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.
06

Outcomes and learnings

The shift changed how product development worked at Leeroy, for the designers, the product teams and the experience across the platform.

What changed

Designers who frame the problem and own the backlog

Product designers ran UX discovery, framed the problem for new or improved experiences, owned the backlog planning and prioritisation in their teams, and delivered development-ready design.

Product managers focused on discovery and the roadmap

With the backlog owned by the product designers, the product managers could focus on product discovery and the roadmap themes.

Decisions closer to the work

Decisions about the experience were made inside each product team, guided by shared design principles instead of approvals.

One connected experience

One service blueprint, one design process and one UI component library kept the products consistent for diners, restaurant staff and owners.

Learnings

Looking back, five things stay with me from leading the design team, and the shift to Product Designers, at Leeroy.

1

Role clarity comes before autonomy

Moving responsibility from product owners to product designers only worked when everyone knew who decided what. Making the split explicit, with product discovery and the roadmap themes for the product managers, and user needs and the backlog for the product designers, made it easier for the designers to step up.

2

A bigger role needs support

Owning a backlog and its priorities is a stretch for a designer. As line manager, coaching the designers in their new responsibilities, not only in the craft, mattered as much as the new model itself.

3

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.

4

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.

5

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 in their teams, 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 · Design Leadership · LeeroyLeading the product development of 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 · Design Leadership · Leeroy Leading the product development of a mobile ordering and loyalty app for restaurant brands