All work with Leeroy Group

Design Leadership · Leeroy

A design team of four that could decide well on their own, with one way of working from research to final design

As Design Manager at Leeroy, I was line manager for four product designers who worked together and supported the different products: the ordering and loyalty app, the POS and table service, the back office and the kitchen display. I set one design process from research to final design, design critique, design principles for every product and a shared UI component library, and helped the designers grow into product designers who ran discovery and owned their backlog.

My role
Design Manager, line manager for four product designers
Year
2019–2021
Team
Four product designers, one in each product team, working together as one design team
Industry
Restaurant tech, SaaS and fintech
Products
Ordering and loyalty app, POS and table service, back office and kitchen display
Company
Leeroy Group
Tools
Sketch, Jira and Miro

The short version

The problem

Once the core platform was built and used by several customers, the work became improving the products from what we learned. The designers needed to move from mostly designing to owning what to do, and to ensure UX quality and business impact before and after launch, while the products stayed consistent as more decisions were made inside each team.

What I did

As line manager, I made the new split of responsibilities clear, set one design process from research to final design, design critique and design principles for every product, and made time for the shared UI component library.

What it led to

Product designers who owned what to do in their teams and answered for UX quality and business impact, before and after launch. Decisions closer to the work, guided by principles instead of approvals, and one connected experience across the products.

01

Leading the design team

At Leeroy, I was Design Manager and line manager for the design team: four product designers, one in each of the four cross-functional product teams, working together as one design team.

While the core of the product platform was being built, the designers mostly designed. 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 features, based on what we learned from customers and users. So the designers’ role shifted: from mostly designing, to owning what we should do and ensuring UX quality and business impact for their products, before and after launch.

Before: building the core platformUX/UI designers
  • Mostly designing: from ideas to development-ready design
  • Designing the core products, while the platform was built
  • The backlog was a shared team responsibility
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
  • Driving what to do: the backlog planning and prioritisation with the team
  • Ensuring UX quality and business impact, before and after launch
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. We had no product owners: the backlog was a team responsibility, and the product designer now drove it. 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.

Not everyone agreed at first about who should drive the backlog. The solution was to let the designer drive it together with the team, as a Product Designer. In a larger company, the role combines what a product owner and a designer do.

I proposed the shift, drove it with management and the product teams, and made it work in practice: as line manager, I made sure each designer 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 designersDesign 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.

How I helped the designers grow

  1. One-to-ones and personal goalsRegular one-to-ones, with development goals for each designer in the new role.
  2. Coaching in discoveryWorking alongside the designers as they framed problems, prioritised and followed up on UX quality and business impact.
  3. A role descriptionA written description of the product designer role, so everyone knew what the designers owned and what the product managers owned.
  4. Workshops and trainingWorkshops and training in the new parts of the role, such as research, prioritisation and business impact.

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 alongside product development, they had time to keep improving the design system, and that we stuck to 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 and table service 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 Back office team Back office for restaurant owners 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.

02

One way of working

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. In regular design critique, 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.

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.
More detail: how design critique worked, and shared patterns

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.

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

The overall journey, from insight to roadmaps

The products only worked for diners and staff when they worked together. So the design team didn’t only design screens in each product: we mapped the overall journey across all four products, and used it to bring insights into each team’s roadmap.

Mapping the journey across the products

Almost every step depended on more than one product. Together with the designers, I mapped the journey front stage and backstage: what the diner does, what the staff at the till, at the counter and in the kitchen do, and what the back office and the systems behind them must do. I agreed each step with the Product Managers for the products involved.

Scroll sideways to see the whole flow.

BeforeThe visitAfter
DiscoverOrderPayPreparePick upReturn
DinerDecides where to eat and opens the restaurant’s appChooses dishes and orders, ahead or at the restaurantPays in the app and earns pointsFollows the order statusGets a notification, picks up and eatsGets rewards and offers, and comes back
Staff at the counterScans the member card at the tillHands 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 POSPayment provider and loyalty engineOrder routed to the POS and the kitchenPush notification to the dinerCampaigns and loyalty rules, set by the owner
The user flow for online ordering in the app, front stage and backstage. Simplified and redrawn for this case.

From insight to the product roadmaps

  1. Insights on the mapPain points and opportunities from research were placed on the step in the journey where they happened.
  2. Linked to a teamEach insight was linked to the product team that owned that step, so it was clear who should act on it.
  3. Into the roadmapsThe product designers brought the insights into their team’s roadmap, written as outcomes the users would notice and tied to the KPIs they should move.
  4. Planned in every team it touchedWhen an insight touched more than one product, it was planned in each of their roadmaps. Points that went missing when diners paid at the till, for example, needed both the app and the POS.
04

Outcomes and learnings

What changed in the way the design team worked, and what stays with me.

What changed in the design team

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

1

Role clarity comes before autonomy

Letting the product designers drive the backlog 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

Principles scale better than approvals

As the products and the team grew, I couldn’t look at every design decision myself, and I shouldn’t have had 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

Design the whole journey, not one product

A flow in one product fails if the next product in the journey doesn’t follow. Mapping the journey across all four products made the dependencies visible, and gave each team’s roadmap insights from the whole service, not only from its own screens.

“I worked closely with Mikaela for several years. What impressed me most was her ability to lead product discovery, turn customer and user insights into product direction, and drive product development through her leadership of the design team — always with contagious passion and drive!”
Anders Hären · CEO/CTO at Leeroy

More of my work at Leeroy

Product Leadership · UX Research · LeeroyOne loyalty programme that rewards diners wherever they pay, in the app and at the tillCustomer, market and user research, two loyalty programmes decided with our customers, and the product roadmap.See the case