Etikettarkiv: användningstest

Testa till döds?

Beslut ska baseras på fakta, inte på förutfattade meningar, och därför gillar jag trenden just nu där allt mer studier av olika slag görs. Men. Man måste också förstå NÄR det är lämpligt att genomföra en studie och när man inte ska göra det… och ibland kanske man inte ska använda den metod man tänkt sig.

Precis som med resten av det samhälle vi just nu har så är det för många bara siffrorna som räknas – allt ska vara hypereffektivt och människor hinner inte ens andas och tänka efter, utom när det gäller att rädda sitt eget skinn. Så även inom User Experience, där klick-statistik och kvantitativa användningstester fått stort genomslag medan mer explorativa och kvalitativa metoder inte alls får samma fokus, trots allt prat om Service Design.

Jag brukar säga att människan är herre på täppan på denhär planeten av en anledning – nämligen vår enastående förmåga att anpassa oss. Måste vi använda dåliga eller undermåliga verktyg så anpassar vi oss efter det. När vi sedan får ändamålsenliga verktyg är motståndet först mycket stort, innan vi vänjer oss vid det nya sättet med.

Är det då alltid lämpligt att mäta mitt i förändring? Eller ska man kanske låta förändringskurvan slå i botten innan man testar om ändringen fick önskad effekt? För mig är det enbart en retoriskt fråga. Har man med återkommande användare att göra, som exempelvis på intranät och på många av de tjänster som finns där ute, som Facebook, Tumblr och din internetbank, så litar man alltid till invanda mönster/etablerade beteenden. Ändra, och användaren upplever att allt är helt galet. Testa just då och du kommer få ändra tillbaka till det gamla.

Jag har testat intranät där folk sitter med sökvägar nedskrivna på PostIt-lappar. När man sedan efter noggranna kortsorteringar ändrar strukturen blir användarna tokiga. PostIt-lapparna fungerar inte längre! Då ska det till en modig person som äger pengarna och makten. Annars beställs snabbt en återgång till det gamla… (och det är då man måste ha en bra strategi i botten, där alla beslut som fattas bottnar i verksamhetens affärsplan eller regeringsuppdrag, men det är ett ämne för ett annat inlägg!)

Därför tycker jag att det känns skönt att någon tar bladet från munnen och säger det jag också tycker, nämligen att kvantitativa inkrementella tester visserligen har en viktig plats men att den platsen både är väldigt specifik och behöver kompletteras med kvalitativa metoder. För ofta när man testar, och låter ett oreflekterat testresultat styra – då kanske den egentliga effekten är att man cementerar dåliga men väl inlärda mönster?

Läs och fundera. Hur tycker du?

Threats of A/B tests and UX research: adoption time and incrementalism (på engelska, hoppar ut till annan plats).

Annonser

Recension: Rocket Surgery Made Easy, av Steve Krug

Med Don’t Make Me Think! gjorde Steve Krug världskänd i användbarhetskretsar så jag bestämde mej för att läsa Rocket Surgery Made Easy, en guide till gör det själv-användbarhetstestning, även om jag inte tillhör den primära målgruppen. Om inte annat, tänkte jag, så bör jag läsa den innan jag rekommenderar den till andra.

Boken är uppdelad i två huvudsakliga delar – när, var och hur man genomför själva testerna, och hur man går tillväga för att åtgärda de problem som testerna påvisade. Metoden han presenterar bygger på insikten att det är svårt att få till resurser för användbarhetsarbete. Hans medicin är att ha korta testsessioner med få deltagare och med samtliga intressenter delaktiga som observatörer, i ett annat rum. Tesen är att alla som fått se hur vanliga användare använda webbplatsen (han skriver från ett webbplatsperspektiv) inser att något måste göras och att användbarhetstestning är ett omistligt verktyg; det är något jag tror de flesta som jobbat på det viset kan skriva under på.

Eftersom boken är riktad till de som inte normalt jobbar med användbarhetsarbete är Krug noga med att poängtera att testerna han beskriver är kvalitativa och endast syftar till att identifiera och prioritera de användningsproblem som är mycket allvarliga och som utvecklingsteamet kommer kunna åtgärda under den närmsta månaden (innan det är dags för nästa testgenomgång).

Trots att jag inte håller med honom i alla detaljer och trots att vissa råd och insikter inte har giltighet i ett svenskt sammanhang rekommenderar jag boken. Krug skriver enkelt och tillgängligt, med enkla praktiska tips, ner på checkliste- och talmanusnivå.

Att jag rekommenderar boken beror också på en annan sak, nämligen den att jag delar hans åsikt att om alla dessa webbar (och IT-system, och appar, och…) verkligen ska bli lättare att använda räcker inte all världens professionella användbarhets- och UX-specialister till. Medicinen, enligt Krug, är att genom en enkel utbildningsinsats göra det möjligt för fler att genomföra enklare användningstester och att därigenom också höja den allmänna medvetenheten om vikten av att ha användarfokus.
En strategi så god som någon.

Workshop som metod: alternativen

I ett tidigare inlägg har jag smutskastat workshopen som verktyg. Syftet nu är att följa upp med alternativen.

Workshopen används vanligen i tre olika syften – för att definiera och avgränsa systemet; för att specificera innehåll och funkationalitet; eller som ett rent PR-verktyg.

Definiera och avgränsa systemet
Här handlar det om flera nivåer, där jag tänker beröra två av dem – konceptuellt/övergripande samt systemtekniskt/specifikt.

Med konceptuellt avser jag den typ av avgränsning som görs i och med att man definierar mål och syfte. Nyckelkunskap här är verksamhetens –

  • Kärnverksamhet
  • Kultur
  • Förhållande till omvärlden
  • Mål och strategier

Problemet med workshop i detta läge är att de olika verksamhetsrepresentanterna gärna undviker att visa interna konflikter och sprickor – man vill ge en enad bild till den inhyrda konsulten. För att undvika det brukar jag be att få allt material de har, hur irrelevant eller perifert uppdragsgivaren än anser att det är. Detta kompletteras med intervjuer med representanter för de olika verksamheterna, inklusive verkställande ledning. Intervjuerna är konfidentiella och dokumenteras för eget bruk men lämnas inte ut till uppdragsgivaren. Tillvägagångssättet innebär att konflikter och skilda uppfattningar synliggörs utan att de inblandade behöver hamna i en konfliktsituation, och kunskapen om vilka konfliktpunkterna är är till stor hjälp när man ska ta fram själva systemdesignen.

Andra bra verktyg är att intervjua användare, göra användningstester på befintliga system, ta en promenad genom korridorerna/besök en produktionsanläggning (eller två), och fokusgrupper med användare. Allt med syfte att förstå verksamhet och kultur.

Med specifik definiering och avgränsning menar jag den fas då man fastställer det faktiska systemets omfattning, matchat mot specifika mål och syften. Här är en av de få tillfällen då det är viktigt att vara överens om vad vill man uppnå och med vilka medel. Men inte heller här är workshopen att föredra. Istället bör utföraren presentera förslag som sedan diskuteras, och där de slutgiltiga besluten fattas av uppdragsgivarens ledning. Skälen till det är två – dels är det ytterst sällan en projektgrupp har mandat att fatta denna typ av beslut – det ligger istället hos verksamhetsledningen, dels för att konsulten då kan fungera som extern måltavla för interna konflikter och eventuellt kontroversiella förslag.
Den konsult som underskattar de politiska kvaliteterna kommer inte bara missa måltavlan – man riskerar att skjuta sej själv. Vilket måste betraktas som icke önskvärt. 😉

Specificera innehåll och funktionalitet
Även här handlar det om flera nivåer. I vissa fall måste man genomföra utredningar, exempelvis avseende roller och rättigheter, eller avseende migrering (eller inte) av befintligt innehåll – vad ska med, hur ser databaserna ut… och utredningarna består huvudsakligen i att kartlägga fakta och om att intervjua rätt personer, samt om att sätta ihop ett beslutsunderlag.
Alltså inte läge för workshop, om man vill ha resultat.

I andra fall handlar det om namngivning, hierarkier och flöden. Här är vi inne på frågor som bäst hanteras med interaktionsdesign och användningstester; jobbar man här med samförståndsprincipen, och hoppas att användarna ska jämka/hitta lösningar åt en, är man mer eller mindre dömd att misslyckas och som en konsekvens går workhop bort.
(Det är lite snett vid sidan om, men i sammanhanget kan man inte nog understryka vikten av att inte speca innehåll och funktionalitet utan att ha bra koll på mål, syften och kultur /förutom de klassiska sakerna som användningssituationer och scenarios/.)

PR-verktyg
För det första bör man fråga sig varför man behöver göra PR för det nya eller förändrade systemet. Är det för att man är angelägen om att ha användarna med sig? Då finns det andra sätt, exempelvis att kontinuerligt arbeta med användningstester under själva specnings- och utvecklings-/konfigureringsfaserna. På så sätt får användarna konkret vara med och påverka saker som ordval, flöden och liknande.

Är det för att man vill sprida kännedom om att saker är på gång? Då spelar man falskt om man informerar bakom masken av en workshop eftersom man då förespeglar användarna att de får möjlighet att påverka. Vill man bara sprida vetskap finns det många andra verktyg att tillgå. Vilka man väljer är i första hand ett val relevanta informations- eller marknadsavdelningar får hantera.
Workshop går i alla fall bort.

Jag har avsiktligt hållit detta på en övergripande nivå, och utan att gå in på leverabler – ska man gå in på detaljer blir det boklängd på det hela och detta är ett blogginlägg som redan överskridit gränsen. 😉 Trots det hoppas jag att jag gett en provkarta på metoder och verktyg som är mer relevanta än workshopen.

Finns det då tillfällen när workshopen kan vara relevant? Det är en fråga jag själv ställt mej, och jag har för avsikt att återkomma i frågan.

Visuell kommunikation och interaktionsdesign – en konflikt?

För inte så länge sedan hamnade Google i hetluften, anklagade för att testa för mycket, vilket påstods påverka designen menligt.

Vad, hur och varför vi mäter är en ofta återkommande fråga. I sitt blogginlägg Measuring the user interface skriver Lukas Mathis om detta, och om hur god design är design som går att använda.

Själv har jag ofta hävdat att i vår branch är vi hantverkare, inte artister, och att en god hantverkare är tekniskt minst lika skicklig som en artist… men med skillnaden att resultatet av hantverkarens arbete ska gå att använda praktiskt medan artisten kan ha andra mål, som att estetiskt tillfredsställa, eller att provocera.

Hur man än ser på detta – jag ser sällan saker som svarta eller vita – är det en intressant frågeställning, och artikeln är läsvärd.

Gör vi rätt som försöker mäta användbarhet?

Besökte idag ett intressant seminarium om Eye trackning som Inuse höll i. Jag blir alltid väldigt intresserad så fort jag hör talas om en metod där man kan mäta användbarhet och få resultatet i siffor.

Men tänker vi rätt då vi försöker få vårt mätresultat presenterat i siffror? De gånger jag försökt använda någon mätmetod som ger siffror som resultat så har det i slutändan iallafall varit de kvalitativa observationsintervjuerna som varit intressanta och gett upphov till mest diskussioner.

Vi kanske underskattar beslutsfattare då vi tror att vi måste presentera färdiga siffror istället för intelligent argumentation?

Jag vet inte? Jag törs iallafall ännu inte avfärda nyttan med att presentera användningstester i siffror eller annat tydligt mätbart resultat. Är en kombination det bästa eller räcker det med de kvalitativa intervjuerna?

Den otestade dörren

För några veckor sedan installerade vi två nya ytterdörrar – säkerhetsdörrar, klass 3. Familjen och jag bor i lägenhet, men den har två ingångar – den ena går till ett ‘extrarum’ som vi använder som arbetsrum.

Nå. Låset har kärvat en del; det har varit svårt att öppna den dörr vi huvudsakligen använder. Vi har trott att det har berott på vår gamla låscylinder.

I helgen gick dörren i baklås. Turligt nog gick det att använda den andra dörren, och på måndagen kontaktades låssmed.

Låssmeden kom. Låssmeden meckade. Låssmeden svor. Låssmeden ringde kolleger. Låssmeden plockade isär det fungerande låset för att se hur det satt ihop – det visade sig att vår sprillans nya dörr hade ett sprillans nytt (och oprövat) låssystem! Till slut fick han ge sig, och borrade upp låset. 90 minuter senare hade han fått dit ett nytt lås.

Innan han gav sig av fick jag tydliga instruktioner om att ALDRIG känna efter om ifall dörren var låst eller inte. Istället skulle jag lita på att den var det – hade jag vridit om nyckeln var dörren i lås…
Rycket i dörren gjorde nämligen att lås och ram kom i osynk, och med vanlig kolv är det inga problem men dehär supersäkra kolvarna som är som krokar fastnar i ramen.

Det intressanta är att låset är så ‘mjukt’ så att man inte känner att låset går i – man får ingen feedback på att handlingen lyckades.
När man går ut är det en sak. Man låser, och vet att det är låst. teoretiskt sett, i alla fall.
Från insidan är det en annan sak. Man vrider om vredet och hoppas att dörren är låst. Eftersom man kan vrida åt två håll och bara ett är rätt är det lite gambling…

Dörrfirman borde helt klart ha testat dörrarna innan de sattes i produktion.

Vad händer om nån rycker i dörren? Tjuvar känner på dörrar, barn känner på dörrar… Varför gör man en dörr som inte går att känna på?

Tack och lov gick allt utom den nya cylindern på garantin.
Men ändå.

Hur trovärdigt är resultatet?

De flesta av oss blir stressade när vi känner oss övervakade; många är de som presterar sämre under hård press. Jag kan se det i flera sammanhang, inte minst i det fotbollslag jag tränar där målgörarna och kreativiteten sprutar på träning men inte på match.

Hur påverkas testresultaten i användningstesten av detta?

Jag har vid ett flertal tillfällen observerat hur användare gör på ett sätt under test för att sedan kommentera att ”så skulle jag inte ha gjort i verkligheten”, och andelen ”så skulle jag inte ha gjort i verkligheten” verkar öka med stressen i testsituationen.
Vi som agerar testledare kan göra mycket för att minska den stressen, men inte desto mindre påverkas många testpersoner av att veta att deras röst och aktiviteter spelas in – ännu värre är det om man dessutom spelar in deras ansiktsuttryck. Så – hur trovärdiga är resultaten?

När vi undersöker enskilda funktioner och dialoger – exempelvis en specifik sökfunktion som undersöks med syfte att identifiera precisa användninsgproblem – är trovärdigheten sannolikt relativt hög, men ett flertal tester måste genomföras för att verkligen etablera sanningshalten i resultaten.

När vi försöker fånga beteenden – när sökfunktionen undersöks med syfte att identifiera förväntningar och kringaktiviteter, eller när en omfattande tjänst undersöks med syfte att fånga generella problem – är trovärdigheten förmodligen lägre, och kvantitativt fler tester måste genomföras för att sanningshalten ska etableras.

Vi kan inte backa för att våra metoder för att fånga respons och aktivitet ligger som ett filter mellan användaren och det använda objektet. Många användbarhetsexperter eftersträvar det perfekt vetenskapliga resultatet.
Det är bara att inse att det inte är möjligt och att individens erfarenhet, referensramar och kreativitet spelar en mer avgörande roll än vad någon av oss skulle vilja.

Låtsas inte som om att vi någonsin levererar sanningar.
Den som gör det ljuger.

Reflektion från testbänken

Att göra användningstester är sällan roligt. Man sitter timme efter timme och observerar vanliga människor misslyckas med att använda (i mitt fall, vanligen) webbplatser.
Människor som misslyckas reagerar på olika sätt, och jag har haft (den tvivelaktiga?) förmånen att se så många av dem att det börjar bli möjligt att förutse vem som reagerar hur…
Kvinnor som inte är i chefsställning reagerar ofta med att lägga ansvaret för misslyckandet på sig själva.
Män, och kvinnor som är vana att ha explicit makt, tycker att webbplatsen är dåligt utformad och kommer med förslag om hur den kan förändras.
Men gemensamt för alla är en frustration som eskalerar allt eftersom testet fortgår, och ibland tror jag att det påverkar testresultatet negativt – man blir blind och grottar ner sig, kan inte lösa uppgifter som man annats skulle ha klarat.
Eller är det bara önsketänkande?

På senare tid har jag också noterat att frustrationen resulterar i överdriven envishet. Förr om åren gav folk upp när de misslyckades; nu envisas de in absurdum, och man kan få sitta och titta på när de efter 10 minuter fortfarande försöker hitta dokument B. Man får verkligen bita sig i tungan för att inte säga ”OK, skit i det här nu, jag har vad jag behöver, nu går vi vidare”.

Har vi så vant oss vid att det ska vara svårt, att det ska ta tid? Eller är det ett uttryck för att man under inga omständigheter vill misslyckas?

Hur det än är med den saken så blir misslyckandena inte mindre deprimerande att bevittna.

Andra bloggar om: