Bakgrund
Kungliga Operan är Sveriges nationalscen för opera och balett och det har den varit sedan 18 januari 1773. Verksamheten har i dag ca 552 anställda och bedrivs i Operahuset i Stockholm samt i Gäddviken där man har alla verkstäder.
Det är en stor och komplex operation att planera verksamheten på Operan med mycket information som ska hanteras över lång tid – en planeringshorisont på 5 år med många inblandade i flera steg av planerings- och produktionsprocessen.
När Operan hade fattat beslutet att gå över från manuella och spridda planeringsverktyg utan gemensamma lagringsutrymmen som såg olika ut på olika avdelningar till ett standardsystem så tog Camilla Högström, IT chef på Operan rodret som projektledare för upphandlingen av det nya systemet. Camilla kontaktade mig under sportlovet för att höra om jag trodde att det var möjligt att kravställa utifrån verksamhetens -och användarnas behov och vara klara med kravställningen innan semestern. “Självklart!” svarade jag och undrade lite varför det skulle behöva ta så lång tid.
Effekter och KPIer
Vi startade med att tillsammans med styrgruppen sätta vilka effekter man ville uppnå med implementeringen av det nya systemet. Det resulterade i ett antal effektmål med mätbara KPIer. Därefter tog vi gemensamt fram vilka de olika målgrupperna för planeringssystemet är och en hypotes om vilka deras största behov skulle kunna vara. När allt detta var prioriterat och klart fick vi ett godkännande av styrelsen och kunde fortsätta vårt kravarbete.
Tillsammans planerade vi in ett antal stora och mindre workshops där alla delar av verksamheten skulle finnas representerad för att vi inte skulle missa några perspektiv. På dessa workshops ville vi få fram nuläget, vilka är de största hindren i dag – för att sedan gå över till hur skulle man vilja att ett nytt system skulle fungera för att ge stöd i det dagliga arbetet.
För mig som UX-konsult var det här ett annorlunda och roligt uppdrag, vi använde bra snabba lean UX-metoder vilket jag tycker var fantastiskt modigt och bra av Operan. Men det var inte bara det som gjorde det så annorlunda, utan vart vi gjorde det och med vilka människor. Det var väldigt roligt att få träffa dessa kreatörer, artister och administratörer på Operan och upplevelsen att få hålla workshop med 35 personer i stora balsalen, med stretchande ballerinor i korridoren utanför. Det är något jag kommer att minnas.
Kravställning tillsammans med användarna
Tillsammans med användarna skapade vi enkla personas där de fick specificera vilka de grundläggande behoven och användarmålen var. En av målgrupperna var en blandning av artister och hantverkare vilket visade sig vara en ganska spretig grupp utifrån behoven vilket snabbt resulterade i två personas. Allt detta gjordes gemensamt i en stor workshop.
Kontextuellt och typiskt användande
En av grundstenarna i det arbete vi gjorde var User Story Mapping. Deltagarna som var indelade i målgrupper fick först tillsammans skapa sin bild av vilka problem var i dag, för att sedan gå över till vilka användarmål de har i systemet. De fick sedan gå över till att tänka kontextuellt och intervjua varandra två och två, där dom fick berätta hur de använde systemet i en typisk situation för att uppfylla respektive användarmål. Den ena personen berättade för den andra som skrev ner scenariot och ställde följdfrågor. Varje målgrupp täckte upp alla sina prioriterade användarmål med scenarios. Detta gjordes i en workshop där vi hade tid att gå igenom och verifiera scenarios som var osäkra, men vi fick också gå igenom dessa i efterhand för att säkerställa att scenariot låg på rätt nivå och inte var för detaljerat i tex gränssnittsdetaljer. Det är ju alltid svårt att säga hur man kommer att använda ett system som inte finns och det är lätt att gå ner lite för djupt i detaljer.
Alla har fått bidra och ta fram kravspecen
Nästa steg var att plocka ut alla interaktioner med systemet från respektive scenario och skapa User Story Mapen. Detta kräver förståelse för vad en interaktion är och vad som är viktigt att ta med för att sedan kunna skriva bra user stories. Det var i vissa fall lite svårt för användarna att göra detta, vilket krävde flera iterationer av genomgångar för att få det bra. Men vinsten är stor – alla har fått bidra och ta fram kravspecen, den är väl förankrad i användarnas behov och processer.
Bra diskussioner vid prioritering
För att hålla isär respektive personas i User Story Mappen så använde vi strikt färgkodning för respektive persona, vilket skapade en tydlig bild av vilka användare som använde vilka funktioner och innehåll mest. Användarna fick tillsammans skapa kartan med kluster av aktiviteter och prioritera och sortera bort dubbletter. Bra diskussioner uppstod där man kunde diskutera vilket behov som egentligen låg bakom viss funktionalitet “Behöver vi verkligen ha en utskriftsfunktion, export till Word och Excell när vi redan har standardfunktionen för utskrift och skapa PDF i browsern – vad är grundbehovet egentligen?”. Mycket kunde rensas bort och prioiteras ner. En prioriterad karta började ta form där skall-krav ligger överst med sådant som måste finnas på plats för att kunna leverera värde kopplat till effektmålen – och resterande som behövs men inte är lika viktigt längre ner som bör-krav.
Själva skapandet av kartan (User Story Mapp) går ofta ganska fort och är ett moment man nästan enklast gör under tystnad, men sedan behöver man rensa och prioritera vilket är ett mycket givande arbete att göra tillsammans både med användarna, produktägare och ur ett tekniskt perspektiv. Kartan kräver dock mycket plats, vår karta var ca 7 meter lång, på den stora User Story Mapping-workshopen hade snickarna byggt ett jättefint långbord som den fick ligga på, men det var lite svårare att få in i de små mötesrum som finns på Operan för senare prioriteringsarbete 🙂
Leverabler
Leverabler från mitt arbete var en prioriterad effektkarta med effektmål, KPIer, personas och behov. Personas för respektive målgrupp, scenarios för de viktigaste användarmålen från respektive personas samt en prioriterad backlog med skall- och bör-nivå i excellformat.
Den stora vinsten i det här arbetssättet är det gemensamma arbete med slutanvändarna som skapar validerade och prioriterade krav och samtidigt en djup förankring i verksamheten. Inget är viktigare än att systemet uppfyller behoven och stödjer processen för att skapa ett system som ger önskvärda effekter.
