Produkt- & designledarskap · Leeroy
På Leeroy hade jag två roller samtidigt. Som Product Manager ledde jag en white label-app för beställning och lojalitet som användes av 30 restaurangvarumärken, från discovery till utveckling. Som UX Design Manager var jag chef för designteamet över hela plattformen och hjälpte designerna att växa till produktdesigners som drev discovery och ägde sin backlog.
Restaurangvarumärken ville ha en egen app, och gästerna ville snabbt få mat från ett favoritställe. Men det tog för lång tid att komma igång, väntan på maten var osäker, och lojalitetspoäng försvann när gästerna betalade i kassan.
Som Product Manager ledde jag discovery och utveckling av appen med dess tvärfunktionella team. Som UX Design Manager var jag chef för tre produktdesigners, en i varje produktteam, och satte en gemensam designprocess, designkritik och gemensamma designprinciper, så att designerna kunde fatta bra beslut på egen hand och produkterna höll ihop.
30 restaurangvarumärken använde appen, var och en med sitt eget varumärke. Ordervärdet var i genomsnitt 30 % högre genom appen och Express Check-out, och lojalitetsprogrammet ökade försäljningen med 39 % i genomsnitt. Designerna ramade in problemen och ägde backloggen i sina team.
Restaurangvarumärkena ville ha en egen app, och deras gäster ville snabbt få mat från ett favoritställe. Som Product Manager ledde och gjorde jag själv product discovery för att förstå vad som gjorde beställning, betalning, upphämtning och lojalitet svårt för gästerna, och vad vi behövde lära oss för att fatta välgrundade beslut om vad vi skulle bygga.
Product discoveryn kombinerade fyra typer av research:
Tillsammans gav de oss de tre insikter som formade appen.
Gästerna ville snabbt få mat från ett favoritställe, men behövde registrera sig innan de kunde se något, och tillval och allergener var svåra att hitta.
När beställningen var betald visste gästerna inte när de skulle hämta den, eller om den var klar. Så de stod och väntade vid disken, eller frågade personalen.
Poäng försvann när gästerna betalade i kassan i stället för i appen. Gäster tänker inte i kanaler, och poäng som saknades fick dem att tappa förtroendet.
Jag kartlade insikterna längs kundresan för mobilbeställning, från att öppna appen till att hämta beställningen och få poängen. Den visade var gästerna fastnade, och var de största möjligheterna fanns.
Scrolla i sidled för att se hela kundresan.
Varje smärtpunkt blev en möjlighet, och varje möjlighet kopplades till det vi byggde. Kartan höll teamets backlog kopplad till verkliga behov, och till effekten vi ville nå: gäster som beställer oftare och kommer tillbaka.
Utifrån insikterna från product discovery utvecklade vi även designprinciper för appens beställnings- och lojalitetsupplevelse. Principerna utgick från användarnas behov och gav designers och utvecklare en gemensam grund för att fatta konsekventa designbeslut genom hela användarresan. De vägledde utformningen av appens flöden och interaktioner och låg även till grund för designsystemet, som hjälpte oss att hålla produktupplevelsen enhetlig.
Varumärket först: appen är restaurangens, inte vår
Beställ med några tryck
Vet alltid beställningens status
Ett medlemskap i appen och i kassan
Principerna var länken mellan det vi lärde oss och det vi byggde. Så här löpte tre av insikterna hela vägen: från principen de gav oss, till designbeslutet, temat på roadmapen och hur vi skulle veta att det fungerade.
Här är några av skärmarna från appen. Det var en white label-app som släpptes för varje restaurangvarumärke med egen logotyp, egna färger, bilder och egen meny.
1Menyn
Restaurangens kategorier som flikar, och varje produkt med bild, pris och pris i poäng. Den valda restaurangen syns överst, och varukorgen finns alltid nära till hands.
2Ett varumärkes startsida
Varumärkets egen bild och beställningsknapp, med genvägar till beställning, erbjudanden, mina beställningar och närmaste restaurang.
3Sidomenyn
Allt annat på ett ställe: beställning, skanna medlemskortet, erbjudanden, beställningar och kvitton, inställningar, restauranger och support.
4Ett annat varumärke, samma app
En kampanj överst, beställning för utkörning eller menyn för att äta på plats, och medlemmens erbjudanden längre ner.
5Lojalitetspoäng och nivåer
Medlemmens poäng och nivå, och hur lojalitetsprogrammet fungerar, i ett ark över startsidan.
Nästan varje steg i appen var beroende av en annan produkt. Tillsammans med designerna kartlade jag användarflödet på scen och bakom scen: vad gästen gör, vad personalen vid disken och i köket gör, och vad systemen bakom dem måste göra. Varje steg stämde jag av med Product Managern för kassan (POS) och köksskärmen.
Skrolla i sidled för att se hela flödet.
Roadmapen byggdes av teman, inte funktioner. Varje tema skrevs utifrån gästens perspektiv, som ett resultat hen skulle märka. Sedan bröt vi ner det i vad det innehåller och kopplade det till de KPI:er det skulle påverka.
Temana höll teamet fokuserat på varför något var viktigt, och lämnade utrymme att hitta det bästa sättet att nå dit. När prioriteringarna ändrades var det lättare att flytta ett helt tema än att flytta om enskilda funktioner.
Tema 1Gäster
Beställ i förväg eller vid bordet, betala i appen, och beställningen går direkt till köket.
Vad det innehåller
KPI:er det ska påverka
Tema 2Gäster
Inget behov av att fråga personalen, eller stå och vänta vid disken.
Vad det innehåller
KPI:er det ska påverka
Tema 3Medlemmar
Poäng och belöningar följer gästen, i appen och i kassan.
Vad det innehåller
KPI:er det ska påverka
Tema 4Medlemmar och varumärken
Stämpelkort och erbjudanden, som varje restaurangvarumärke ställer in själv.
Vad det innehåller
KPI:er det ska påverka
Tema 5Gäster
Ändra eller lägg till i beställningen efter att den är lagd, så länge köket inte har börjat med den.
Vad det innehåller
KPI:er det ska påverka
Appen laddades ner som mest när vi införde kampanjer och erbjudanden i den. Att beställa i appen var bekvämt, men det som fick gästerna att ladda ner den och börja använda den var att lösa in ett erbjudande. Återköpen var i sin tur starkt kopplade till lojalitetsprogrammet, vilket vi kunde se när vi mätte lojaliteten genom tokens från betalkort.
Nästan varje tema var beroende av kassan (POS) och köksskärmen, som ägdes av ett annat produktteam med en egen Product Manager. Mitt team byggde också delar av kassans back office. Jag stämde av våra teman med deras Product Manager, så att ändringarna vi behövde också planerades in i deras roadmap.
Och i kassans back office
Varje tema pekade på de KPI:er det skulle påverka, mot en och samma effekt: gäster som beställer oftare och kommer tillbaka, och restaurangvarumärken som stannar.
Det gjorde varje prioriteringsdiskussion konkret: vilken KPI kommer det här att påverka? Och när ett tema var live visade samma KPI:er om det hade fungerat, och vad vi skulle förbättra härnäst.
Påverkas av
Påverkas av
Påverkas av
PrenumerationerBetaltransaktioner
Varje KPI hade ett mål, så att teamet visste vad som var bra nog, och kunde se när ett tema hade gjort sitt jobb.
Varje tema på roadmapen kom med de KPI:er det skulle påverka. Tillsammans med det tvärfunktionella teamet gjorde jag om temana till sprintmål: vad vi ville ha uppnått i slutet av sprinten, och varför det spelade roll för gästerna och restaurangerna. Teamet planerade sedan hur vi skulle nå dit.
Appen byggde på två intäktsströmmar: prenumerationer, där restaurangvarumärken betalar för sin egen app, och transaktioner på beställningarna som betalas i den. Varje tema vägdes utifrån användarvärde, affärspotential och komplexitet, och en effektmatris gjorde avvägningarna lätta att diskutera i teamet och med de andra produktägarna.
På Leeroy var jag linjechef för designteamet: en designer i varje tvärfunktionellt produktteam, som arbetade tillsammans som ett designteam.
Medan kärnan i produktplattformen byggdes hade designerna ett typiskt UX/UI-designansvar. När kärnan var på plats, och våra produkter var ute och användes av flera kunder, blev det viktiga arbetet att förbättra dem och lägga till ny funktionalitet, utifrån det vi lärde oss i product discovery med kunder och användare.
UX/UI-designerna blev produktdesigners och tog över Product Owners ansvar. De drev UX-discovery och formulerade problemet för nya eller förbättrade användarupplevelser, ägde planering och prioritering av backloggen tillsammans med sitt produktteam, och tog fram utvecklingsklar design som utvecklarna kunde bygga från. De arbetade nära Product Managers, som ansvarade för product discovery och temana på roadmapen.
Jag bidrog till skiftet. Mitt huvudansvar var att vara linjechef för designerna, före och efter det, och se till att de kunde växa in i den nya rollen.
Varje produktdesigner var en del av ett tvärfunktionellt produktteam, och ansvarade för kund- och användarbehov och för planering och prioritering av backloggen tillsammans med teamet. Som deras linjechef såg jag till att de, vid sidan av produktutvecklingen, hade tid att löpande förbättra designsystemet, och att vi fortsatte följa vår designprocess. Jag skötte också rekrytering och det övriga vardagliga ansvaret som linjechef.
Här var jag också Product Manager: discovery, roadmap och prioriteringar
Arbetet som inget enskilt produktteam ägde: den övergripande upplevelsen, och delarna som delades mellan produkterna.
Tid för designerna att löpande förbättra designsystemet, vid sidan av produktutvecklingen.
Att se till att vi fortsatte följa en designprocess, från discovery till leverans.
Att utveckla varje designers hantverk, och stötta dem i deras nya ansvar för användarbehov och backloggen.
Regelbundna retros, och designkritik där designerna visade sitt arbete tidigt och lärde av varandra.
Att rekrytera designers, och stämma av designkapaciteten med product managers när prioriteringarna ändrades.
När fler beslut fattades i varje produktteam höll gemensamma standarder ihop upplevelsen. I stället för att godkänna varje design såg jag till att designerna hade det de behövde för att fatta bra beslut själva.
Varje produktteam arbetade efter samma designprocess, från discovery till leverans, så att designerna kunde förstå varandras arbete och kliva in för varandra. På den regelbundna designkritiken såg de varandras arbete, höll produkterna enhetliga och lärde av varandra.
Utifrån researchen tog vi fram designprinciper för varje produkt tillsammans: designerna, produktteamen och jag. Varje produkt hade sina egna användare och sitt eget sammanhang, så varje produkt fick sina egna principer. De gav produktdesignerna tryggheten att fatta beslut i sina team, utan att behöva fråga varje gång.
Designerna tog med skisser och prototyper, inte färdiga skärmar, medan det fortfarande fanns tid att byta riktning.
Feedbacken började med vem designen var till för och vad den skulle uppnå, inte med smak.
Konkret, respektfull feedback som designern kunde agera på.
Designers från de andra produktteamen såg var ett flöde bröt ett mönster, eller berörde deras produkt.
Produkterna hade väldigt olika användare och sammanhang: en gäst i mobilen, en ägare vid skrivbordet, personal i en fullsatt kassa, en servitör vid bordet, ett kök mitt i rusningen. Gemensamma interaktionsmönster och ett gemensamt UI-komponentbibliotek gav dem en enhetlig upplevelse, och varje produkt anpassade dem till sina användare. Apparna byggdes på de inbyggda komponenterna i iOS och Android, och vårt bibliotek lade de gemensamma mönstren ovanpå, där varje restaurangvarumärke tog med sitt eget tema.
Så här blev resultatet. Jag håller isär det som levererades och de mål vi styrde mot.
Mätt med KPI:erna i kapitel 3. Det här var målen vi styrde mot.
restaurangvarumärken använde white label-appen, var och en med sitt eget varumärke.
högre ordervärde i genomsnitt genom appen och Express Check-out.
ökad försäljning i genomsnitt med lojalitetsprogrammet.
Produktdesignerna drev UX-discovery, formulerade problemet för nya eller förbättrade upplevelser, ägde planering och prioritering av backloggen i sina team och levererade utvecklingsklar design.
När produktdesignerna ägde backloggen kunde product managers fokusera på product discovery och temana på roadmapen.
Beslut om upplevelsen fattades i varje produktteam, vägledda av gemensamma designprinciper i stället för godkännanden.
En service blueprint, en designprocess och ett UI-komponentbibliotek höll produkterna enhetliga för gäster, restaurangpersonal och ägare.
När jag ser tillbaka är det här sakerna som stannat kvar hos mig från att leda appen för beställning och lojalitet och designteamet på Leeroy.
Att skriva temana som något gästen skulle säga, som ”Jag vet när min mat är klar”, förändrade samtalen. I stället för att diskutera funktioner pratade vi om vad gästen skulle märka och varför det spelade roll. När prioriteringarna ändrades flyttade vi hela teman i stället för att kasta om enskilda funktioner. Nästa gång skulle jag börja med teman från dag ett, inte gå över till dem längs vägen.
Det bästa beställningsflödet i appen fungerar ändå inte om beställningen inte når köket, eller om ingen markerar den som klar. Nästan varje flöde var beroende av kassan, köksskärmen eller lojalitetsmotorn. Att leda appen innebar att leda över produktteamen: att tidigt stämma av med de andra produktägarna och äga upplevelsen från början till slut, inte bara skärmarna.
Att flytta ansvar från product owners till produktdesigners fungerade bara när alla visste vem som bestämde vad. Att göra fördelningen tydlig, med product discovery och temana på roadmapen hos product managers, och användarbehov och backloggen hos produktdesignerna, gjorde det lättare för designerna att kliva fram.
När produkterna och teamet växte kunde jag inte titta på varje designbeslut själv, och det skulle jag inte heller behöva. Designprinciper för varje användargrupp, gemensamma interaktionsmönster och ett gemensamt UI-komponentbibliotek gjorde att designerna kunde fatta bra beslut på egen hand. Att leda designteamet handlade mer om att sätta riktning och göra resonemangen synliga än om att godkänna.
Att koppla varje tema till de KPI:er det skulle påverka gjorde prioriteringarna konkreta. Den större lärdomen handlar om tajming. Om vi kommer överens om KPI:erna, och vet var de ligger i dag, innan ett tema börjar, kan vi i efterhand säga om det fungerade. Att mäta först efter lansering visar vad som hände, men inte varför.
Varje beslut behövde fungera både för restaurangvarumärket som betalade för appen och för gästen som använde den. ”Varumärket först” gav varje varumärke sitt eget utseende, medan gemensamma komponenter och mönster höll ihop en produkt som vi kunde bygga och underhålla. Den balansen mellan varumärkets frihet och en skalbar produkt var en stor del av jobbet.
Gäster tänker inte i kanaler. Om poängen saknades när de betalade i kassan tappade de förtroendet för hela programmet. Att utforma lojalitet för var gästen än betalar, i appen och i kassan, var svårare och berodde på fler team, men det var det som gjorde gäster till stamgäster.
”Jag arbetade nära Mikaela i flera år. Det som imponerade mest på mig var hennes förmåga att leda product discovery, omsätta kund- och användarinsikter till produktens riktning och driva produktutvecklingen genom sitt ledarskap för designteamet – alltid med smittande passion och driv!”
