När vi pratar om att höja kvaliteten i system pratar vi ofta stora åtgärder såsom utökad (eller påbörjad) testautomatisering, nya buggrapporteringssystem eller förändrat arbetssätt. Men det finns tekniker som inte behöver vara så övergripande eller svåra som också ger stora kvalitetsvinster. I två artiklar kommer Ulrika Malmgren att presentera två olika tekniker för detta.
Den första tekniken jag kommer presentera hjälper oss att undgå missförstånd och skapar ett diskussionsunderlag. Den andra hjälper oss att undvika grundläggande misstag.
Post-its för snabb återkoppling
På ett uppdrag brottades vi med att försöka förstå hur en feature skulle se ut när den var implementerad. Beskrivningen från verksamheten lämnade oss med ganska fria händer, teamet fick försöka lösa problemet på det sätt som vi tyckte fungerade bäst.
Den fria beskrivningen gjorde att vi alla fick olika bilder i huvudet av hur systemet skulle bete sig när vi var färdiga och diskussionen blev svår att greppa.
Till slut plockade vi fram ett papper och ett gäng post-its. Vi ritade, klippte, klistrade, ritade om och klistrade på nytt. Varje post-it fick bli en vy i applikationen, mindre post-its blev popups och mellan vyerna ritade vi pilar. Vi försökte visualisera hur de olika flöderna i applikationen skulle påverkas. När vi var överens tejpade vi upp våra mockups på väggen.
Dagen efter visade vi produktägaren och frågade om dennes åsikt. Det blev snabbt tydligt att en varningsdialog behövde visas tidigare i flödet än där den var inklistrad på vår pappersprototyp. Då flyttade vi helt enkelt den post-iten och ritade om pilarna. Tillsammans med produktägaren kunde vi dessutom, baserat på de flöden som vi i teamet hade hittat, också identifiera ett par undantagsfall som teamet inte hade tänkt på.
Varför är det en bra teknik?
Vinsterna med att använda mockups är många. Det är lätt att se att i vårt fall blev kostnaden för att flytta varningen i princip noll eftersom att det enda vi behövde göra var att flytta en post-it.
Dessutom hade vi ett bra underlag att diskutera kring. Det som tidigare var luddigt förklarat och tog olika skepnader i våra huvuden kunde vi visualisera. Eftersom att bilderna hängde kvar på väggen medan vi arbetade på featuren kunde vi gå fram till dem och diskutera specialfall eller förklara för någon annan intressent hur det var tänkt att det skulle bli.
Att featuren visualiserades och blev mer konkret ledde även till att vi tidigt kunde prata undantagsfall och se scenarios som vi inte hade tänkt på. Antagligen hade dessa dykt upp under testningen, men kostnaden för att hitta dem och ändra implementationen hade varit större.
Dialogen som vi hade medan vi tog fram bilderna var även den väldigt värdefull. Att vi tog oss tiden, programmerare och testare tillsammans, att diskutera på detta sätt gjorde att vi hade en gemensam bild av vad vi ville designa. Vi behövde ingen kunskapsöverföring och vi kunde alla svara på frågorna från vår produktägare lika väl.
Varför just post-its?
En intressant fördel med post-its över andra verktyg för mockups (Photoshop t.ex) är att post-its bjuder in till att ändras. När andra typer av designer är mer statiska, är post-its gjorda för att flyttas runt. Vi behöver inte vara rädda för omedvetet motstånd till att begära en förändring i något som ser färdigt ut eller för att någon ska tro att designen är slutgiltig.
Våra post-it mockups var alltså ett billigt sätt framkalla en värdefull dialog och visualisera ett flöde utan att skriva en enda rad kod. Med hjälp av papper och penna kunde vi:
– få snabb återkoppling till en låg kostnad
– undvika missförstånd
– skapa ett diskussionsunderlag
– ha en viktig dialog tillsammans
För att införa denna teknik krävdes inga planerade möten, ingen omvälvande processförändring och tidsåtgången var liten.
I nästa artikel beskriver jag en enkel, beprövad men något bortglömd metod för undvika misstag.
