Går det att höja nivån på användbarheten i ett system utan att satsa mycket tid och resurser på aktiviteter som inte ganska omgående leder till utveckling av körbar kod? I andra delen av vår artikelserie om användbarhet delar Maria Wikforss med sig av sina erfarenheter av att arbeta med användbarhet som gemensamt åtagande i ett agilt utvecklingsteam.
Utmaningen
I ett av de projekt som jag deltar i så testade vi nyligen ett lite annorlunda sätt att jobba med användbarhetsfrågor som en del av det agila utvecklingsarbetet. Utgångspunkten var att försöka höja nivån på användbarheten i systemet och jobba mer användarcentrerat, utan att det fanns möjlighet att satsa mycket tid och resurser på aktiviteter som inte ganska omgående leder till utveckling av körbar kod.
En oemotståndlig utmaning för en kombinerad utvecklare och användbarhetskonsult med agil metodik på hjärnan.
Bakgrund – kodkvalitet som gemensamt åtagande
Ett tämligen utbrett upplägg för att jobba med kodkvalitet idag är att utvecklingsteamet gemensamt gör ett åtagande om hur de vill att koden de tar fram ska se ut när de lämnar den. Lite grann i linje med Robert Martins välkända tankar kring ”Clean Code” och god utvecklarpraxis. Det kan handla om att koden man lämnar efter sig ska vara testbar, läsbar, väl namngiven, följa vissa konventioner och så vidare. Genom det gemensamma åtagandet är tanken att kvalitetsaspekterna hos koden blir en naturlig del av teamets målbild och klarkriterium för att släppa nya features. Kodkvalitet blir på detta sätt inte något som ska göras på slutet eller ”när vi får tid”, utan del av det dagliga arbetet att utveckla mjukvara.
Vår approach – användbarhet som gemensamt åtagande
Motsvarande tanke om ett gemensamt kvalitetsåtagande fast gällande användbarheten i systemet, försökte vi oss på i vårt projekt. Detta genom att välja ut och försöka följa ett gäng etablerade och relevanta designprinciper för användbarhet i utvecklingsarbetet. Tanken var att på så sätt få in användbarhet i vår ”Definition of Done” och att det därmed, likt kodkvalitetsarbete beskrivet ovan, skulle bli en naturlig del av att ta fram eller vidareutveckla mjukvara.
Designprinciper för användbarhet låter kanske lite mossigt som koncept, men kunskapen de representerar är ändå resultatet av årtionden av samlad erfarenhet och visdom från designers och forskare inom MDI, HFE, ergonomi, med mera och baserar sig på en djup kunskap om människans fysiologiska och psykologiska förutsättningar. De är naturligtvis inte svaret på allt, men utgör ofta en bra grund att stå på, om inte annat för att göra en första ”sanity-check” av ett systems användbarhet.
Vårt fokus i projektet låg främst på designprinciper med syfte att minska den kognitiva lasten för användarna, följa deras kontextuella tankebanor och konnotationer samt att skapa intern och extern designkonsistens i systemet.
En bra början
Som en kickstart på vår användbarhetssatsning så sammanställde jag mot bakgrund av detta några användbarhetsriktlinjer för projektet, att ha till grund för vårt åtagande. I riktlinjerna beskrev jag kortfattat de utvalda designprinciperna och varför de är viktiga samt vad man enkelt kan göra och tänka på för att följa dem. Baserat på våra nya riktlinjer gjorde jag sedan en ”här är vi nu”-utvärdering av det befintliga systemet. Helt sonika så klickade jag mig igenom varje vy och dokumenterade var systemet bröt mot riktlinjerna.
När utvärderingen väl var gjord och presenterad så estimerade vi i teamet tillsammans de små och stora förändringar som kunde göras för att leva upp till principerna. Med dokumentationen och designprinciperna i ryggen så var en del lösningar ganska uppenbara och konkreta medan andra blev mer konceptuella och övergripande. Med hjälp av detta underlag skrev vi sedan user stories som kunde prioriteras in i backloggen som vanligt vid planeringen.
Hur vi arbetade
Därefter fortsatte utvecklingen i princip som vanligt men med skillnaden att åtagandet och riktlinjerna kring användbarhet fanns i medvetandet och att några nya user stories låg i backloggen. När en user story blev aktuell att ta tag i, så skissade och diskuterade vi snabbt fram olika lösningsförslag baserat på riktlinjerna. Därpå pratade vi med produktägare och användare (om det fanns möjlighet) utifrån våra idéer, skissade igen och utvecklade sedan körbar kod.
På detta sätt behöll vi det intensiva och korta utvecklingsflödet, och fick snabbt ut mjukvara som kunde köras på riktigt, utvärderas och därmed skapa reaktioner. Återkopplingen kunde vi sedan använda för att förfina, förtydliga eller ta bort funktionalitet tätt inpå att den utvecklats.
Reflektioner om arbetssättet
Genom att snabbt gå från identifierat behov till lösningsförslag baserat på designprinciper vidare till skisser och slutligen körbar kod, så var vi hela tiden flexibla att agera på användarnas och andras feedback. Genom att också hela tiden behålla fokus på designprinciperna, och åtagandet att följa dem när vi utvecklar, så kunde vi trots rörligheten i målbilden (genom just mycket feedback och kontinuerlig utvärdering) hålla ihop användargränssnittet över tid. I rollen som användbarhetskonsult var just detta min kanske viktigaste uppgift – att hålla ihop användargränssnittet så att inte bristen på specifikationer och detaljerade prototyper bara ledde till kaos. En annan viktig förutsättning för detta arbetssätt var att vi hade en kort och effektiv deployment-cykel för mjukvaran, så att utvecklad kod snabbt kunde komma ut i produktion och därmed till användarna.
Visst blev det inte alltid rätt direkt men genom att få kontinuerlig feedback blev vi hela tiden lite klokare. Riktlinjerna, och åtagandet att följa dem, gav oss också en ledstång i att hantera och agera på feedbacken på ett vettigt sätt. Vissa saker behöver tid för att mogna och en del feedback tar inte hänsyn till helheten och bör vägas mot andra kvalitetsaspekter innan man vidtar några åtgärder.
Jag tror verkligen på teamets gemensamma kreativitet och att skissa och utveckla ”JIT”, men att samtidigt ha riktlinjer och/eller ett gemensamt kvalitetsåtagande gällande användbarheten för att bevara en röd tråd i utvecklingen.
Detta arbetssätt är inte revolutionerade eller ens nytänkande. Jag tänker bland annat på Jakob Nielsens idéer om ”Discount Usability” som snart är två decennier gamla (kolla in den här artikeln http://www.nngroup.com/articles/web-discount-usability/ från 1997!). Men faktum är att det fungerade väldigt bra för oss att göra en vettig användbarhetssatsning med en relativt liten insats, här och nu 2013. Systemet lever i högre grad upp till designprinciper för användbarhet och blir kontinuerlig bättre och bättre. Självklart kan man naturligtvis göra mycket mer i form av djupgående användarstudier och gediget UX-hantverk, men ibland så finns det kanske inte tid och resurser nog för att göra stora satsningar och då är denna approach faktiskt inte så tokig. Den är i alla fall definitivt bättre än att inte göra något alls, plus att när nivån på användbarheten väl är höjd ett par snäpp så blir det lättare att se vilka eventuella större satsningar som är värda att göra i framtiden.