För en beställare är det rimligt att förutsätta att mjukvaran man köper ska vara användbar när den är klar, utan att det måste specificeras i kraven. Hos utvecklarna finns dock ofta en förväntan att det som ska levereras är kravställt explicit. Var ligger då ansvaret för användbarheten?
Användare har idag höga förväntningar på den mjukvara de väljer. Utbudet och tillgängligheten av smidiga och användbara appar till mobiler och plattor, tillsammans med ökande datorvana och allt smidigare självadministration via webbtjänster för myndigheter, banker, butiker och liknande, gör oss mer erfarna och kräsna som teknik- och IT-konsumenter än någonsin tidigare.
För att vara konkurrenskraftig idag behöver teknik och mjukvara inte bara fungera, utan vara ändamålsenlig, intuitiv, snygg, prisvärd och till och med rolig. Vi måste utgå från såväl behov och förutsättningar, som förväntningar och preferenser hos människorna som ska använda systemen när vi bygger mjukvara.
Om detta handlar området användbarhet.
Intresset och uppmärksamheten för användbarhet växer i branschen, inte minst i samband med framgångssagor för teknikföretag som tack vare sina satsningar på nytänkande, innovativ och användarfokuserad design har blivit ledande på marknaden. Trots att förväntningarna på användbar mjukvara verkar öka, och att intresset för att jobba med detta blir alltmer utbrett, så finns fortfarande en risk att frågor som behandlar användbarhet faller mellan stolarna vid mjukvaruutveckling.
För beställaren av mjukvara är det rimligt att förutsätta att produkten eller tjänsten man köper ska vara användbar när den är klar – det behöver man väl inte specificera i kraven? Hos utvecklarna av mjukvara kan det däremot finnas en förväntan på att det som ska levereras är kravställt explicit. Även detta ett rimligt synsätt – det är inte trivialt att utveckla system och man måste kunna fokusera och avgränsa sitt scope för att komma framåt. Frågan är dock om det idag är rimligt att ansvaret för användbarheten bara ska ligga på beställaren? Som konkurrenskraftig leverantör av mjukvara tror inte jag att det går att förutsätta – här behöver man ligga steget före och erbjuda användbarhetstjänster som en del av utvecklingsinsatsen.
Det finns ibland dock en bild av att användbarhetsarbete inte går att integrera i det agila utvecklingsarbetet, utan att det kräver någon form av strikt sekventiell process för att skapa nytta och att det måste ske vid sidan av, eller innan utvecklarna kommer in i projektet – något som jag inte tycker stämmer. Det kan handla om en mer eller mindre uttalad förväntan om att användbarhetsexperternas arbete ska vara ”färdigt” innan någon utveckling alls drar igång. Att designbesluten redan ska vara fattade och att en detaljerad specifikation baserad på förstudier i princip bara ska lämnas över, färdig att utvecklas till punkt och pricka – av ett agilt utvecklingsteam. Hmprf… Något känns väldigt fel här.
Detta synsätt står ju i skarp kontrast till hur övrigt arbete går till i ett agilt projekt. För hur bra och detaljerad en specifikation än är innan man börjat utveckla, så kommer den att utsättas för en mängd kompromisser och förändrade förutsättningar på resan mot färdig produkt. I det agila arbetssättet har vi korta iterationer just för att kunna testa, tänka om och anpassa snabbt istället för att specificera allt från början och inte våga ändra på något trots att förutsättningar förändras – så varför inte också göra detta när det gäller användbarhetsaspekter av mjukvaran?
Vidare läsning
Det finns mängder av intressanta artiklar och reflektioner på nätet om agilt användbarhetsarbete. Att söka runt på begreppet ”Agile Usability” ger många intressanta träffar på artiklar såväl som diskussionsgrupper. Ett tips är att kolla in Nielsen Norman Group, där några riktigt tunga användbarhetsgurus huserar.
Inom kort delar Maria med sig på Citerus.se av hur hon praktiskt arbetat agilt med användbarhet.