Studentlitteraturs logga inUse logga
  • Dela på Facebook
  • Dela på Twitter
  • Dela på Linkedin
  • Dela på Delicious
  • Dela på Linkedin
 
 

Nyttan med användbarhet

Användbara produkter leder till en värdeökning. Värdeökningen kan vara i form av ”mjuka värden” som exempelvis ökad kunskap, bättre service, eller stärkt känsla för varumärket. Det kan vara i form av ”hårda” värden som ökade intäkter och/eller minskade kostnader.

Ofta (men inte alltid) går också de ”mjuka” värden omvandlas till ”hårda” Eftersom nyttan uppstår när en produkt används gäller det att just denna användning blir så smidig som möjligt. I en riktigt bra produkt är användargränssnittet ”osynligt”, och användaren kan helt och hållet fokusera på det hon vill göra. Om produkten är krånglig måste hon istället ägna tid och uppmärksamhet på det verktyg som hon använder för att få det gjort.

Användbara produkter leder till:

Utöver de som vi skriver om i ovanstående exempel finns det gott om andra som också har räknat på ”return on investment” för användbarhetsområdet. Theo Mandels lista och UPA:s artikel om ROI1 är bra ställen att starta på för den som vill läsa mer.

Konsekvenser av dåliga system

Dålig användbarhet medför onödiga kostnader i användning. I klartext betyder det att den förväntade nyttan ofta blir betydligt mindre än man räknat med, och skälet är att man underlåtit att arbeta med användbarhetsaktiviteter i projektet.

Ibland används produkterna inte alls, eller i alltför låg omfattning. Då talar vi inte längre om dåliga investeringar, utan om bortkastade pengar.

Här i Sverige finns exempel på flera större misslyckade utvecklingsprojekt hos myndigheterna som resulterat i produkter som inte använts2.

Utvecklingen av FMV’s projekt SIRIUS startade 1993 och när projektet lades ned 1999 hade det kostat ca 380 miljoner kronor, utan att det fanns en produkt som kunde användas. Rikspolisstyrelsens projekt Moar resulterade i en produkt som var livsfarlig. Produkten skulle användas i polisbilarna, men monterades så att krockkudden inte kunde lösa ut.

Kostnader som uppstår i användningen med produkter som har dålig användbarhet är exempelvis

  • felhantering - användare gör ofta fel. Ibland leder det till fel som upptäcks långt senare, vilket kan vara mycket kostsamt.
  • låg effektivitet - att vissa uppgifter tar onödigt lång tid att utföra, eller att de ofta leder till fel som måste rättas.
  • kostnader för att användare upplever stress, otrivsel och ohälsa. Vanliga problem är ont i huvudet, musarm eller en känsla av att man måste utföra meningslösa uppgifter.

”Skyddsombudet på Ny Teknik har anmält arbetsgivaren för att de anställda tvingas jobba med ett ergonomiskt dåligt dataprogram. Det är första gången som ett sådant program granskas av Arbetsmiljöverket.

Programmet E-drum, som används för att lägga ut texter på webben, har inga snabbkommandon utan de redigerare som använder det är hänvisade till musen. Klickandet och komplicerade gardinmenyer gör att programmet sliter på armar och axlar.

Enligt Arbetarskyddsstyrelsens regler för arbete vid bildskärm står det bland annat att programvaror och system skall vara lätta att använda och ta hänsyn till ergonomi.” - Journalisten, 18 juni 2001: Dataprogram anmält av skyddsombud3

Kostsamma och onödiga misstag som i fallet med SIRIUS här ovan är vanliga när man inte förstår användnings-situationen tillräckligt väl. Ofta räcker det med att tillverka en enkel prototyp i t.ex. wellpapp, och prova att installera den, för att upptäcka dessa brister.

Vi vet att det också finns massor av exempel på misslyckade projekt i den privata sektorn, men de undslipper oftast granskning utifrån.

Jonas Söderström beskriver för övrigt en lång rad exempel på dåliga system och konsekvenserna av dessa i den utmärkta boken ”Jävla skitsystem”.4

Kostnader för användbarhet

Finns det några kostnader med ett mer effektstyrt och användarorienterat angreppssätt?

Om man inte vet hur man ska ta hand om resultatet av användbarhetstester, målgruppsanalyser eller intervjuer med beställare och ledare så blir det självfallet extra kostnader. Att genomföra ett användbarhetstest utan att avsätta tid och resurser för att ta hand om resultatet är inte att rekommendera.

Om man är rädd för att genomföra användbarhetsinsatser för att man riskerar att få veta något som förändrar lösningen eller kräver omarbetningar, så bör man göra dessa aktiviteter så tidigt som möjligt. Ju senare i projektet ändringar genomförs desto dyrare är det. Om kostnader för ändringar uppskattas till 1 enhet under analysfasen så kostar ändringar 1,5 till 6 enheter under utvecklingsfasen och 60 till 100 enheter under underhållsfasen.5

För ett projekt som genomför användbarhetsaktiviteter på ett strukturerat sätt så är den reella kostnaden snarast engagemang – och därmed tid – från beställare och användare.

Vår erfarenhet är dock att både beställare och användare mer än gärna vill bidra. Det viktigaste är att skapa ett arbetsstat så att de upplever att de bidrar på ett meningsfullt sätt.

Därför förbises användbarhet

Om det nu är så viktigt och så bra, vad är det då som hindrar oss från att utveckla bättre produkter? Vi ser framför allt tre hinder.

  1. Myter om användbarhet. Det finns massor av myter kring användbarhetsområdet. Alltifrån att det skulle vara dyrt och omständligt, till att det skulle räcka med att fråga användarna om hur de skulle vilja ha det.
  2. Brister i arbetssätt. De etablerade utvecklingsmetoderna fokuserar inte tillräckligt på produktens användning och därmed saknas ofta både aktiviteter, utpekat ansvar och kontrollpunkter för att säkerställa hög användbarhet.
  3. Bristande kunskap. Beställare och projektmedlemmar saknar ofta kunskap som skulle hjälpa dem förbi myterna och bristerna i arbetssätt.

Myter om användbarhet

Det finns en hel del felaktiga föreställningar som står i vägen för att integrera användbarhet i utvecklingsprojekt på ett effektivt sätt.6

Du som arbetar för att säkerställa IT-produkters användbarhet kommer att träffa på dessa myter i ditt arbete.

I många fall är det just dessa myter som är det huvudsakliga skälet till varför aktiviteter för att säkra produkters användbarhet inte genomförs, eller till att resultat från genomförda användbarhetsaktiviteter inte tas på allvar.

Vår förhoppning är att beskrivningen av myterna ska öka dina chanser att känna igen dem, och därmed underlätta för dig att bemöta dem.

Om du vill läsa fler myter så rekommenderar vi webbplatsen UX Myths, som kontinuerligt publicerar nya myter som man kan skratta åt eller gråta över. :-)

Brister i arbetssätt

Traditionellt har projekt där man skall utforma nya (eller upphandla) interaktiva produkter ett begränsat fokus på att åstadkomma en användbar produkt (med vår definition).

De traditionella, funktionsbaserade utvecklings- och projektstyrningsmetoderna, men också nyare projektstyrningmodeller som Scrum saknar hjälpmedel för att styra mot nytta; det överlåts till projekt- och styrgruppen.

Användarcentrerade aktiviteter pekas ibland ut som lösningen, eftersom de sätter fokus på användarnas behov. Det är sant i den mening att - för att kunna bygga bra lösningar - är det nödvändigt att ha kunskap om användarnas behov. Problemet är att resultatet från användarcentrerade aktiviteter saknar koppling till förväntade affärsvärden och verksamhetsnytta. När man skall presentera och använda resultatet från användarcentrerade aktiviteter kommer frågor om prioriteringar som ett brev på posten och de blir svåra att reda ut. Därför uppfattas ibland dessa aktiviteter som tillägg till projektarbetet, som stör det vanliga projektflödet. De blir svåra att motivera och det blir också svårt i projektet att veta hur man skall använda all information om användarmönster och användarbehov.

Det är en stor utmaning att bygga ”bra” produkter – d.v.s. produkter som används och ger avsedd effekt. För att lyckas med det måste man;

  • Bygga rätt produkt – d.v.s. bygga en produkt som ger avsedda effekter. Detta kräver förmåga att hjälpa beställaren formulera önskade effekter och att styra utvecklingsprocessen så att dessa effekter uppstår. På vägen görs många strategiska vägval och en mängd designbeslut fattas. För att göra rätt val behöver man en förståelse för produktens sammanhang och effektiva arbetssätt för att skapa förslag och utvärdera dem.
  • Bygga produkten rätt – säkerställa att produkten är byggd på ett sätt som gör att den fungerar på avsett sätt i drift och förvaltning.

Dagens utvecklingsmodeller och metoder fokuserar främst på att bygga produkten rätt, trots att det redan 19857 fanns riktlinjer för hur utvecklingsprocessen ska bedrivas för att säkra produkter med hög användbarhet. Riktlinjerna är:

  • Tidigt fokus på användare och deras uppgifter.
  • Utvärdera prototyper med riktiga användare.
  • Utvecklingen bör vara iterativ.

Utöver dessa tidiga riktlinjer har senare en ISO-standard formulerats, som beskriver beskriver förutsättningarna för att en utvecklingsprocess ska kunna säkerställa användbarhet: ISO 134078.

”Human-centred design is characterised by: the active involvement of users and a clear understanding of user and task requirements; an appropriate allocation of function between users and technology; the iteration of design solutions; multi-disciplinary design.”

Om man ser över hur väl befintliga utvecklingsmetoder uppfyller kraven i ISO 13407, så finner man att det finns många brister. Ett gemensamt mönster för bristerna visar att:

Användningen beskrivs inte alls eller slarvigt

Användningen är det som händer när människor av kött och blod nyttjar produkten om och om igen. För att bygga (eller upphandla) en interaktiv produkt behöver vi förstå användningen, då behöver vi skapa en modell som beskriver

  • vilka som använder produkten
  • när de använder produkten
  • vilka mål och förväntningar de har
  • hur den interaktiva produkten kan tillgodose deras behov

Under 80-talet och början av 90-talet beskrevs användningen i några få meningar där man adresserade ”avnämarna” eller ”användarna”. Det viktiga var att så fort som möjligt klarlägga vilka funktioner som IT-lösningen skulle omfatta.

Under 90-talet växte insikten att olika grupper av användare hade olika behov och förväntningar. Det blev viktigt att mer utförligt beskriva målgrupper och deras olika behov. Teknikutvecklingen möjliggjorde användning i nya miljöer och på nya sätt skyndade på. Internet och mobilutvecklingen har varit de två största påskyndarna.

Förvånande nog är det än idag vanligt att målgrupperna och deras behov i olika situationer beskrivs slarvigt eller inte alls. I värsta fall görs beskrivningen helt och hållet som en skrivbordskonstruktion - ingen har analyserat användarbeteenden och än mindre träffat användare i konkreta användningssituationer.

Det är också vanligt att utgå från de demografiska målgrupper som används för marknadsföring och kommunikation. Man hoppar då över hela analysen för användningen av denna specifika interaktiva produkt, och får sedan följaktligen problem att styra produktutvecklingen och designprocessen.

Det kan tyckas vara chockerande att man lämnar grunden till en lyckad utveckling åt slumpen, medan mycket tid och kraft ägnas åt att verifiera att alla krav är tillgodosedda. Detta är dock helt logiskt, med tanke på att IT-projekt främst utvärderas på tid, kostnad och funktionsuppfyllnad.

Lösningen är att utgå från verkliga behov, förväntningar och användningssituationer när målgrupperna skapas, samt att prioritera dem med utgångspunkt från hur viktiga de är ur ett verksamhetsperspektiv.

I ett sådant målgruppsarbete får man ovärderlig kunskap som direkt påverkar lösningens utformning. Några exempel:

  • målgruppens förståelse för begrepp och skeenden är grunden för deras förmåga att interagera med produkten. Det är alltför vanligt att utvecklingen baseras på begrepp som är kända i verksamheten, men inte för användarna som står utanför verksamheten. De är kunder, medborgare eller leverantörer och saknar helt motiv och intresse att lära nya begrepp. Många skeenden är på samma sätt ointressanta för användarna, de är framförallt intresserade av resultatet.
  • kunskapen om hur motiverade användarna är att utföra uppgiften kan vara avgörande. När en användare vill betala för en enklare produkt blir det ett onödigt steg att skapa inloggningsuppgifter samtidigt.9
  • sammanhanget då produkten ska användas är ibland helt avgörande för utformningen.10

Med andra ord kan många krav härledas till målgruppernas kunskap, värderingar och förväntningar samt till användningssituationen. Dock är de inte "krav" i den traditionella betydelsen.

Ett bra sätt att göra detta på är att hantera målgruppernas och beställarens krav tillsammans, och visualisera dessa i en s.k. konceptdesign. Denna typ av specifikation ska ses som ett tillägg till den typ av kravspecifikationer som vanligtvis görs, som oftast främst innehåller funktionella och tekniska krav.

Interaktionsdesign är ingen projektaktivitet

Design av användargränssnittet antas göras samtidigt som funktioner utvecklas. Ibland saknas också rollen interaktionsdesigner, design av användargränssnittet förväntas göras av den som programmerar.

Resultatet blir då att användargränssnittet växer fram organiskt under projektets gång. Risken är då överhängande att gränssnittet speglar funktionsbeskrivningar, datalagring, utvecklarnas antaganden om användarna och deras användningssituation, samt vad projektmedlemmarna själva tycker är snyggt och bra.

Istället bör man se designen av användargränssnittet som grunden för att lyckas med att skapa en produkt som är användbar. Det är viktigt att

  • så snart som möjligt adressera möjliga koncept och principer för interaktionen mellan användare och produkt. Vilka utformningar är det som kan göra att produkten blir framgångsrik? På samma sätt som man tidigt tar fram en arkitektur för den tekniska lösningen är det nödvändigt att ta fram en arkitektur för användargränssnittet
  • så snart som möjligt designa interaktionen för de viktigaste flödena för att validera att de mönster man tänkt håller och hitta viktiga egenskaper på detaljnivå
  • först därefter utforma användargränssnittets fulla funktionalitet

Produktens användbarhet utvärderas inte

Etablerade utvecklingsmetoder innehåller alltid aktiviteter för att göra olika typer av funktionella tester; funktionstester, integrationstester, belastningstester, prestandatester etc.

Dessa tester är nödvändiga för att visa om produkten motsvarar de funktionella och tekniska kraven. På samma sätt behöver man visa att produkten fungerar för användare i praktiken.

I de fall utvecklingsprocessen helt baserats på funktionella krav och om man saknar kunskaper om målgruppernas behov och än mindre har formulerat vilka värden som produkten skall bidra till för verksamheten - så är det naturligt att inte utvärdera användbarheten.

Sådana utvecklingsmodeller bygger på antagandet att funktionen självklart också utformas så att den är lätt att använda. Man bortser från att en funktion kan ha många utformningar och att endast ett fåtal av dem bidrar till hög användbarhet.

I de flesta projekt har man god insikt om nödvändigheten att skapa en produkt som fungerar bra i användningen, men även då är det vanligt att man saknar ett systematiskt sätt att testa användbarheten.

Ibland saknas kunskaperna om att det går att validera produktens användningskvalitet, och det är vanligt att man tror att det är något dyrt och omständligt att genomföra.

Användbarhetsutvärderingar kan med fördel göras i integrerat i utvecklingsprocessen. Ju tidigare man kan testa viktiga delar i verklig användning, desto bättre. Att finna problem i användningen tidigt reducerar kostnaderna för rättningar och omgörningar i projektet, samt minskar kostnaderna för support och underhåll.

Oklart vem som ansvarar för användbarhet

I traditionella metoder och modeller för projektstyrning och systemutveckling lämnas ansvaret för att bygga rätt produkt främst till beställare, verksamhets-/affärsutvecklare och projektledare. Detta visar sig ofta i att man på styrgruppsmöten ägnar tid åt att diskutera färger, ikoner, rundade eller fyrkantiga hörn etc.

Beställaren, verksamhets- och affärsutvecklarens roll bör vara att finna nya eller förbättrade sätt att bedriva verksamheten på affärsnivå, inte för att värdera detaljer i produkten.

Projektledaren hamnar ofta i kläm, för att hon förväntas leda arbetet och därför blir involverad i diskussioner om produktens utformning. Om det finns designfrågor där det saknas underlag för beslut, eller där projektmedlemmarna bråkar, så blir projektledaren tvungen att gå in.

I projekt som saknar interaktionsdesigner blir ofta användbarhet ett gemensamt ansvar och som alla gemensamma ansvar faller det mellan stolarna. Det är inte ovanligt att viktiga principer beslutas utan eftertanke, en detalj i designen blir föremål för segdragna diskussioner.

I projekt som har en interaktionsdesigner anses hon ansvara för produktens användbarhet. Det vanligaste är dock att hon saknar befogenheter för att driva och ansvara för användbarheten, hennes roll är vanligen först och främst att ta fram design.

För att det skall bli möjligt att ansvara för användbarheten ställs också krav på tydlighet i beställningen. Vilka nyttor vill man åstadkomma med lösningen? Vilka målgrupper prioriteras? Så länge projektet saknar denna tydlighet är det svårt att ha ett reellt ansvar för produktens användbarhet.

Bristande kunskap

Den allvarligaste kunskapsbristen är att projektmedlemmar (inklusive projektledare, beställare och andra ledningsfunktioner) tillåter att utformningen av produkten bygger på gissningar och kompromisser. Det sker för att de saknar kunskaper om hur man kan arbeta systematiskt med användbarhet.

Vanans makt är också stark. Många projektmedlemmar har deltagit i IT-projekt där just detta; att tillsammans gissa sig till användarnas behov har varit en av huvudingredienserna. Att istället beskriva målgrupper och fånga deras verkliga behov genom kombinerad observation och intervju i ett antal möten är för dem ett okänt, tråkigt och delvis obekvämt arbetssätt;

  • Det okända ligger i att det finns arbetssätt och tekniker för att fånga framtida användares behov och att det krävs kunskap och träning för att genomföra detta.
  • Det tråkiga ligger i att de tror att de kreativa momenten i projektet kommer att försvinna.
  • Det obekväma ligger i tanken att de produkter de varit med om att bygga faktiskt inte baserats på användares verkliga behov, utan på gissningar.

Det bästa sättet att överbrygga kunskapsgap och vanans makt är att vara delaktig i ett projekt där man till fullo genomför målgruppsanalys och använder resultatet i designarbetet. De som deltagit i en sådan process upptäcker också att vissa designbeslut alltid kommer att vara gissningar, men det är bättre om dessa gissningar baseras på kunskap om användarnas reella behov. De kreativa momenten försvinner alltså inte, istället blir de mer spännande eftersom man har ökad förståelse för behoven. De som inte deltagit i ett sådant projekt behöver få exempel som de kan binda upp sina tankar på.

Brist på kunskap hos beställare, program- och produktansvariga och andra ledningsfunktioner leder dessutom till att de aldrig eller sällan kräver att produktens användningskvalitet skall säkras i projektet. Istället anser de ofta att åtgärder för att säkerställa användbarhet är ”onödiga”. Det finns flera orsaker till detta:

  • VD och högre chefer vet inte att många kostnader, som uppstår efter driftsättning av produkten kan undvikas om fokus sätts på användningen under utvecklingen. Det handlar om kostnader för felhantering, dålig ergonomi, omständlig hantering, utbildning etc. De känner dessutom sällan till att det i utvecklingsprojekt oftast inte finns någon som ansvarar för användningskvaliteten.
  • Den som agerar beställare är sällan den som sedan ansvarar för användningen och effekterna i verksamheten. Den som beställer produkten belastas sällan för kostnader som uppstår för felhantering, utbildning, support etc. Dessutom är dessa kostnader ofta osynliga, de mäts helt enkelt inte.
  • Man har fallit för en eller flera av myterna som tidigare presenterades, kanske främst att ”användbarhet är sunt förnuft”.
  • Beställare och projektledare har inte insett att det finns många sätt att utforma interaktiva produkter. De som är bra bidrar till verksamhetsnyttan och nyttan för användarna. De som är dåliga skapar en mängd problem.

Brittiskt försäkringsbolag

En produkt för försäljning av reseförsäkringar i ett Call-center hade lämnats för acceptanstest. Många användare klagade på att det var svårt att använda och man kallade därför in en användbarhetsexpert. Efter diskussioner med de ansvariga visade det sig att ingen från utvecklingsgruppen hade suttit med användarna när de bokade reseförsäkringar. Användbarhetsexperten använde en dag till detta och fann snart att begrepp som familj och grupp var centrala begrepp som inte stöddes alls av produkten. En snabb skiss visade att införande av familjebegreppet skulle minska antalet steg i bokningsprocessen från 9 till 5.

 

Noter

1 UPA står för Usability Professional's Association, och är en amerikansk intresseorganisation för alla som jobbar inom användbarhetsområdet
2 Computer Sweden, 1 juni 2000: Kompetensbrist kostar myndigheterna miljarder.
3 Se också Computer Sweden, 27 juni 2001: Användare revolterar mot webbprogram. Faktiskt kom redan 1996 rapporter från nyhetsindustrin i USA där man uppmärksammat just journalisters problem med dåligt utformade IT-stöd, se www.upassoc.org/outreach/real.world.ex.html#Newsrooms
5 Bias, R. & Mayhew, D., Cost-Justifying Usability, Acade­mic Press inc., 1994.
6 Flera av de myter som vi tar upp här är hämtade från en artikel av Marc Crusch; Seven Great Myths of Usability, Interactions, september 2000.
7 Gould & Lewis. Designing for usability: Key principles and what designers think. Communications of the ACM, 1985, 28.
8 Human Centered Design Process for Interactive Systems, ISO 1999.
9 Se t.ex. Jareds Spools exempel med The $300 Million Button
10 På ett läkemedelsföretag som vi arbetat åt gjorde kulturen det omöjligt för användarna att avslöja att de faktiskt behövde lathundar för de vanligaste kommandona. Efter att vi upptäckt detta vid en enkel observationsstudie kunde vi bygga in denna avgörande funktionalitet i systemet. Läs mer om detta i artikel Missledande kultur på bloggen inUseful.
 
 

Kommentera

Författare

Bild på författareb Johan BerndtssonBild på författareb Ingrid DominguesBild på medförfattaren HelenaBild på medförfattaren BjörnBild på medförfattaren EmelieBild på medförfattaren fredric landqvistBild på medförfattaren Maria KareliussonBild på medförfattaren gustavjonssonBild på medförfattaren Malin FabbriBild på medförfattaren Rolf greenBild på medförfattaren Johan LiljegrenBild på medförfattaren Angelica SvanerBild på medförfattaren HenrikBild på medförfattaren Wilaiwan TraphromBild på medförfattaren Anne RostedBild på medförfattaren suzana susecBild på medförfattaren EmmaBild på medförfattaren Marcus RehnBild på medförfattaren Nina LBild på medförfattaren peter erhardBild på medförfattaren Peter KråikBild på medförfattaren Terrell SherriffBild på medförfattaren Monika AnderssonBild på medförfattaren Jens FredholmBild på medförfattaren Julia LagerstedtBild på medförfattaren Lotta UlfströmBild på medförfattaren Peter JantzenBild på medförfattaren Jonas EngkvistBild på medförfattaren Maria SjödinBild på medförfattaren Helene CarlsonBild på medförfattaren Karin HanssonBild på medförfattaren Johannes Karlsson

Senaste ändringar

Facebook

Twitter (@anvandbarhet)

 
Creative Commons-licens

Användbarhet i praktiken - wiki by Ingrid Dominques/Johan Berndtsson is licensed under a Creative Commons Erkännande-IckeKommersiell 3.0 Unported License. Based on a work at anvandbarhet.se.