Stefan Pettersson

Hyperiterativ prototypning med Google Spreadsheets

Vid utveckling av komplex funktionalitet som involverar många olika roller och intressenter krävs det att alla kan röra sig framåt snabbt. Så här hyperitererade vi produktutveckling med hjälp av Google Spreadsheets.

Google Spreadsheet i raketfart

Som del av vårt arbete med Förenade Liv stod vi inför utmaningen att digitalisera processen med skadeanmälningar. Det vill säga när en försäkringstagare ansöker om ersättning i samband med sjukdom, olycksfall, dödsfall eller arbetslöshet. Totalt närmare 40 stycken flersidiga pappersblanketter som skulle bli ett enda smidigt flöde.

Efter en inledande kartläggning med intervjuer i organisationen och bland kunder började det handgripliga arbetet. Vi var en UX-expert, en designer, en copywriter, en utvecklare och en testansvarig som jobbade med kundtjänst, skadebedömare, produktägare så väl som projektbeställare och jurist. Många intressenter med minst lika många behov.

Till detta kommer själva formulären som har många olika frågor och villkor där ett, eller en kombination av svar, kan leda till följdfrågor. Dessutom behövde vi självklart ta hänsyn till den utsatta position som användaren befinner sig i. Hur påverkas gränssnitt och formuleringar av att användaren nyss mist sin närmaste och nu ska redogöra för det?

Här räckte det inte med konventionella prototyper och iterativ utveckling. Med så många intressenter och komplexa flöden behövde vi alla kunna jobba både samtidigt och iterativt. Att till exempel feedback från juristen kring formulärets flödeslogik skulle behövas tas med hem, planeras in i en sprint, genomföras och sedan få godkännande fungerade inte tidsmässigt. Det skulle ta flera år att bli klar med alla intressenter.

Hur löste vi det då?

Att manuellt skapa ett formulär, med hundratals frågor, olika valideringsregler och logik som styr visning av efterföljande frågor, skulle bli för tidskrävande med så många ändringar. I stället tog vi fram ett regelverk för att beskriva en fråga med dess logik för att avgöra om den visas eller är dold beroende på andra frågor.

Ett JavaScript läste in regelfilen som var i JSON-format och skapade hela formuläret dynamiskt i webbläsaren.

Att lägga till eller ändra en fråga gick nu att göra direkt i datafilen – inga ändringar i HTML eller jonglerande med eventlisteners i JavaScript som skulle visa eller gömma specifika fält. Det skedde nu automatiskt enligt regelverket.

Att ändra direkt i en JSON-fil är inte det smidigaste när det görs av fler personer som arbetar samtidigt på olika håll, som dessutom behöver vara säkra på att de alltid har den mest aktuella versionen.

Det är här Google Spreadsheets som datadrivet prototypverktyg gör entré.

Varje fråga i datafilen representeras av en rad i ett kalkylark. Tack vare Google Apps samarbetsfunktioner kan flera personer arbeta samtidig och på köpet får vi stöd för både historik av ändringar så väl som kommentarer, färgmarkeringar och annat behändigt.

Med hjälp av Google Sheets API automatiserade vi hämtning och konverteringen från kalkylark till datafil i JSON-format.

Genom ett litet script kunde hela denna process utföras av vem som helst i teamet på några få sekunder. Detta medförde att vår UX-expert kunde gå igenom flödet med kundtjänst och göra ändringar direkt baserat på deras feedback.

Formuläret genereras om och ändringen kan utvärderas direkt. Nu kunde vi iterera på en minut, alla samtidigt – hyperiterativt!

Här är en kort film som visar flödet i ett tidigt skede när formuläret inte hade fått så mycket design.

A video posted by Rebel & Bird (@rebelandbird) on

Av detta kan vi dra några lärdomar. För bästa resultat ska vi alltid sträva efter att ha ett arbetssätt som möjliggör att:

  • Iterera snabbt. Ju snabbare cykeln ändring-test-utvärdering är desto effektivare kan vi jobba och desto snabbare kan vi agera på nya lärdomar.
  • Undvik beroenden. Kan personer i olika roller och med olika kompetens själva genomföra och testa sina ändringar frigör vi både tid och rör oss snabbare framåt.
  • Prototyp först. Desto tidigare vi kan gå från hypoteser till att omsätta och testa något i praktiken, desto mindre är risken att oväntade komplikationer dyker upp sen.

Avslutningsvis, för den lite mer tekniskt intresserade som är nyfiken på hur detta gjordes så kan jag berätta att själva scriptet kördes med Grunt. Där användes en egenutvecklad task, grunt-gss-to-json, som hämtar data via Googles API och transformerade den till JSON.

Därefter startades antingen en lokal webbserver för att formuläret skulle kunna testas direkt, eller så laddades det nya formuläret upp på Amazon S3 som en impromptu testmiljö som gick att nå publikt.

Image credit: Matt Biddulph CC BY-SA 2.0