Design är krav - och kraven skall vara klara innan sprinten startar!

Vi får ofta frågor om hur man får det att fungera med UX i Agila projekt i allmänhet och Scrum i synnerhet. UX designers upplever att det är väldigt stressigt: “Hur ska man hinna med att designa samtidigt som man bygger”. Vi brukar fråga vilken typ av projekt de jobbar med, om det är

• a) projekt där det man gör tillägg till något som man vet fungerar bra i användning och som alltså har en fungerande infrastruktur. Typ Amazon.
• b) projekt där man bygger något nytt. Det saknas helt eller delvis infrastruktur. Och man har en klar tanke om vilket värde man vill åstadkomma för användarna. Typ “nya sj.se”
• c) projekt där man inte är så klar över värdet och vill utforska vad som kan fungera och där det också finns pengar och beslutsförmåga.

Visst kan man göra detaljdesign i sprinten! I fallet a ovan finns redan ett användargränssnitt som man vet fungerar helt OK som inte behöver göras om från grunden. Har man dessutom duktiga gränssnittsprogrammerare i teamet så kan man koncentrera sig på detaljerna. Och då finns dessutom pengar att bygga om ifall det inte blev bra. Man kan till och med testa med en liten skara användare först.

Det som är betydligt vanligare är att man arbetar i projekt av typen b ovan. Eller i värsta fall c, förutom att det saknas pengar och/eller beslutsförmåga. Då ska man inte göra detaljdesign i sprinten. Det skapar onödig friktion. UX-designers blir stressade och utvecklarna får dåligt stöd. Och framför allt får beställarsidan inte den support de behöver. I värsta fall bygger man dåliga lösningar.

Vi vet alla att utformningen spelar roll. En funktion eller ett flöde kan skapa wow-känsla hos användaren om det är rätt utformat. Fel utformat kan det kosta miljoner i tappade intäkter, frustration och supportkostnader. Design är alltså krav.

En viktig princip i Scrum är att skapa goda förutsättningar för teamet. Att de kan förstå, diskutera, förbättra och estimera kraven. Och eftersom utformningen är en del av kraven så bör den självfallet vara klar vid estimeringstillfället. Inte nödvändigtvis in i minsta detalj, men så pass att teamet kan förstå hur det skulle kunna byggas. Och göra estimat som håller.

Fallet b är vanligt. För att inte bli bakbunden så behöver man först utforma lösning de viktigaste flödena och funktionerna och testa i användning. Och ibland behöver man bygga och testa flera prototyper för att veta att man hamnat rätt - att utformningen är enkel att använda och skapar värde. När du är klar så finns en mönsterdesign, en arkitektur för användargränssnittet om du vill. Som ska detaljeras med alla funktioner och flöden. Och allt det här behöver man göra innan sprintandet börjar. När det inte görs blir det garanterat stressigt.

I alla fall a-c ska du som UX-designer arbeta med sprintarna längre fram i backloggen. Finns ingen mönsterdesign, så får du gissa dig fram till en sådan. De viktigaste är att du tar fram och kommunicerar den. Och det gör du inte på sprintplaneringsmötet, utan långt tidigare. Mötet backlog refiement kan du använda för att prata med teamet om stories som kommer långt fram, och testa dina idéer. När du jobbar så minskar stressen, kommunikationen med teamet blir bättre och Product Owner brukar bli aktivare.

Vill du veta mer om hur du kan jobba effektivt med UX i ett Scrum-projekt? Detta och mycket mer berättar vi mer om på vår kurs Effektstyrd SCRUM. Häng med du också!