Posts Tagged ‘brugervenlighedstest’

Brugertest nu?

torsdag, december 9th, 2010

Usertesting.com har fået en dansk pendant, som jeg synes skal have et par ord med på vejen.

Velkommen til brugertest.nu
 - der tilbyder at man kan stille testopgaver, som så formidles til "brugere", der løser de testopgaverne og kvitterer med en video med testerens stemme og optagelse af hvad der foregik på dennes skærm. I realiteten samme data som man ville få hvis man selv lavede en brugertest. Det primære i produktet er, at brugertest.nu formidler opgaverne og har fast tilknyttede testere de kan trække på.

Det gøres efter eget udsagn både billigere og nemmere end hvis man selv gøre det.

Brugertest.nu tilbyder også at gøre mere af det beskidte arbejde med at lave testopgaver og fortolke på resultaterne – hvilket er nok så interessant.

Prisen er fornuftig, man kan godt gøre det billigere selv, men skal de jo også betale husleje, udstyr og lave lidt profit, så passer det nok meget godt.

Det umiddelbare indtryk
Jeg synes afgjort det har sin berettigelse, hvis man er opmærksom på hvad man får og hvad man ikke får. Jeg synes det placerer sig et godt sted mellem den professionelle kommercielle brugertest (hvad enten den er intern eller pr- konsulent) og så den helt hjemmegjorte test, som fx Steve Krug eller jeg selv agiterer for i vores bøger. Til gengæld synes jeg ikke der er tale om et reelt alternativ til den brugertest, hvor en usabilitykompetence (fx mig selv), udfører en test in-house eller for andre. Det skal jeg prøve begrunde:

Lad os først kigge lidt på selve testen. Det er værd at huske på, at det afgjort største arbejde ved en brugertest er forarbejde og efterbehandling af testene. Selve testen, altså afviklingen, er den mindste del. Det kører som regel bare på skinner og kan gøres meget billigere (Jeg plejer at "betale" testere 400,- for 1.5 time, mens brugertest.nu skal have 500,- for 20 minutter).

Er det pengene værd?
Brugertest.nu tilbyder at lave for/efter-arbejde – uden at jeg ikke rigtigt kan gennemskue kvaliteten af denne og ikke har noget reelt at hænge den op på – for 10.000. Altså kan jeg få hele testen for 12.500. Det er da en fin pris. Men jeg har set nogle af de store kanoner, tilbyde noget lignende for 25.000. For den lille biks er de ekstra 12.500 sikkert mange penge, for større forretninger er det pebernødder, i relation til vigtigheden af at resultaterne – og særligt de re-designs de kan medføre – og for den betydning de kan have for omsætningen.

Med andre ord: Vil du føle dig mere sikker på at få en testleder med 200+ brugertests under huden til at fortælle dig hvor problemerne ligger end nogle relativt ubeskrevne blade der tester med nogle brugere du ikke rigtig kender?

Handling, ikke holdning
De test-eksempler brugertest.nu viser på deres hjemmeside emmer af  holdninger fra testerens side. Hvis man studerer lidt usability-teori, eller blot læser Jakob Nielsen, vil man se at holdning ikke har meget værdi. Det handler om handling. Hvis brugerne sidder og ævler om hvad de synes, så lærer du ikke noget. Tager du det for gode varer, så er du ikke blot inkompetent til at tolke resultaterne, men du skyder dig også i foden. Derudover har du ingen mulighed for at spørge ind til det der sker, hvormed du bliver mindre klog på det meget vigtige: Hvorfor?  – med mindre du er heldig at testpersonen selv begrunder.

Nuvel, man kan se at testeren rent faktisk er blevet bedt om at fortælle om sitet, men det tager lang tid og til 500,- pr. 20 minut, så er det nogle dyre minutter. Problemet er altså at de der laver opgaverne, skal vide hvad de gør: Der er stor fare for crap-in/crap/out.

Og hvad gør du hvis testeren ikke rigtigt får løst opgaven eller løser den på en måde du ikke kan bruge til noget. Betaler man så? Du kan ikke moderere undervejs, så du må bare håbe på det bedste.

Umodereret tænkt-højt
Så er det bare problemet omkring at tænke-højt i almindelighed. Forsøg viser tydeligt at brugerens opgaveløsning bliver mærkbart forandret af at der samtidigt skal tænkes højt. Det tager længere tid og testerne har en tendens til at rationalisere, altså logisk begrunde det de gør. Der er totalt say/do konflikt i spil. Netop derfor er fx eyetracking blevet populært, hvor testeren efterfølgende begrunder sine handlinger retrospektivt.

Som jeg kan se det, har vi som kunder ingen måde at vide hvem der tester vores website. Pudsigt nok lægger brugertest.nu op til at kunder efterfølgende graduerer (rater) testerne. Det er interessant nok. Hvad er en god tester? Den der fandt flest problemer? Den er kommer igennem flest ting? Den du bedst kan lide at høre på? Jeg har aldrig før hørt om at man på den måde eksplicit vurderede testernes kvalitet, men jeg lærer gerne hvorfor.

Konstruktivt kritisk
Heldigvis synes jeg (næsten) ikke de lover mere end de tilbyder. Vi ved alle at det er fornuftigt at teste, vi ved også at det kan være et stort arbejde at sætte op og vi ved hvad det er vi bliver tilbudt af denne service. Jeg har ikke rigtigt behovet selv, men som jeg sagde ovenfor, så har produktet som sådan sin berettigelse – jeg vil dog mene at man skal købe analysen med før at det giver mening.

Ps. skulle du i stedet være interesseret i at få en erfaren usability-specialist til at lave en times identifikation af dit websites problemer, med grundlag i rigtigt mange test og års erfaring som både underviser, tester, specialist og interaktionsdesigner, så skriver du bare en mail til mig ;-)

Disclaimer: Jeg er blevet gjort opmærksom på, at det ser lidt "underligt" ud at jeg kritiserer en service og så afslutter med reklamere for mig selv som produkt. Lad mig starte med at sige at det egentligt var ment som drillerier/provokation. Jeg er ikke en modydelse til brugertest.nu, jeg er ikke usabilitykonsulent, jeg lever ikke af at lave ekspertvurderinger og tage kunder fra brugertest.nu.

Jeg har nogle meninger om brugertest.nu som går meget på metoden, på hvad brugertest.nu "lover" sine kunder og på værdien af produktet. Hvad jeg selv går og roder med at projekter og hvad jeg ellers tjener penge på, er irrelevant i den sammenhæng og bør ikke (eller kan ikke med fordel) læses ind i den kontekst.

Jeg er også blevet beskyldt (indirekte) for at bruge grimme metoder, fordi jeg har kontaktet brugertest.nu's kunder og spurgt om jeg må se deres testvideoer. Det måtte jeg af ubegribelige årsager ikke. Det er så faldet brugertest.nu lidt for brystet. Jeg synes nu det er reelt nok, det er jo ikke statshemmeligheder, men blot almindelige brugere der fortæller om deres oplevelse på sitet – jeg kunne jo bare spørge min mor…

Kunderne sladrede så til brugertest.nu – og brugertest inviterede i stedet til at jeg prøvede produktet selv (sådan næsten gratis). Det vil jeg så blogge om i nærmeste fremtid. Men lad mig sige det således: Jeg blev ikke skuffet :-)

/Ole

At spise sin egen medicin

tirsdag, december 9th, 2008

Der er ikke noget der kvalificerer ens viden, som erfaringer. Altså erfaringer med den praksis, der trods alt er en vital del, af alle de teorier, beskrivelser og tanker, jeg og andre gør os om arbejdet med usability. På denne blog har jeg beskrevet hvor man “bør” arbejde med usability-kriterier. Det var mest skrivebordsarbejde. Det erkender jeg. But now shit comes to showel!

Jeg er gået igang med at arbejde med usability-kriterier, i kravspecificeringen af en de af en ny løsning i KMD, til det der hedder KMD Opus. Ikke fordi jeg skal, men netop fordi jeg mener man bør.

Ganske kort er pointen, at jeg mener at KMD med fordel kan bruge usability-kriterierne til at sikre en “kvalitet i brugen” i den endelige fremtidige løsning. Det er forholdet mellem kravspecifikationen og det faktiske design af brugergrænsefladen der handler om. Helt principielt kan man i brugen af standard-ramme systemer (som vi bruger), ikke vide hvordan grænsefladen kommer til at se ud, udelukkende på baggrund af kravene i specifikationen. Den designproces (eller justering) ligger nemlig efter at kravene er skrevet – i hvert fald i første omgang. Derfor kan usability-kriterierne – på papiret – bruges til at sikre, at krav til den endelige løsnings brugervenlighed, kan fastsættes i specifikationen, i stedet for at blive til på “tilfældig” vis i designfasen.

Hvad er det så, jeg drømmer om at skrive. Et konkret eksempel kunne i sidste instans være noget á la:

“8 ud af 10 brugere skal ved en brugervenlighedstest, kunne gennemføre 80% af typiske arbejdsopgaver, uden ekstern hjælp”. (Typiske opgaver kan være beskrevet i use cases eller task-beskrivelser).

Se også en beskrivelse på usability goals fra Usability.gov

Tilbage til min egen medicin. Jeg har altså her på min blog, og på usability-kurset på IT-Universitetet for den sags skyld, advokeret for (igen med udgangspunkt i teorien) at etablere usability-mål, igennem brugen af usability-kriterier. Den del af stadig god nok. Udfordringen er blot – ikke overraskende – at det ser ud til at blive langt sværere end først antaget. Ikke bare for mig, men for hele organisationen.

Ok, den erkendelse er jeg ikke alene om (jeg opdaterer dette indlæg med eksempler fra litteraturen, på et senere tidspunkt). I projektets indbyggede ‘kontekstuelle usikkerhed’, er det en nærmest umulig udfordring at etablere målbare usability-krav, tidligt i et projektforløb. For hvad skal de baseres på? Hvordan ved man, at det skal være “8 ud af 10 brugere”, og hvordan definerer man de “80%”. Mit eget bud har jeg givet tidligere: Der skrev jeg, at man må starte et sted og forfine og kvalificere (og kvantificere) målene løbende.

Den tilgang synes at være en mulighed. En anden er at skrive målene langt blødere. Det kunne være igennem nogle bredere beskrivelser, der søger at uddybe indholdet af de valgte usability-kriterier. Altså fx en beskrivelse af hvad “forståelighed”, “effektivitet” og lignende betyder i løsningens eller designets sammenhæng.

Det er nok en måde at starte på, men i mit projekt, er der behov for de “hårde” målbare krav til kvalitets-egenskaben usability, for det er netop formålet med at have dem: De skal bruges til at “måle” hvorvidt den løsning vi får stillet til rådighed, på baggrund af vores krav, nu også er brugervenlig (meget generelt sagt).

En anden ønskelig konsekvens af disse usability-krav er, at de der designer løsningen (som ikke er de der stiller krav), på en eller anden måde er nødt til at sikre at disse krav opfyldes. Det kræver i første omgang en brugertvenlighedstest, hvilket i sig selv er en sejr at få introduceret i et udviklingsforløb (for de fleste software virksomheder, tro mig).

Derudover vil enhver der har bare en anelse kendskab til softwaredesign, vide at hvis man først tester brugen til sidst, så kan det nærmest være ligemeget. Der er løbet kørt, det er for dyrt og for svært at lave om. Derfor skal der være løbende tests, hvilket jo reelt betyder løbende brugerinddragelse, hvilket jo er brugercentreret design.

Et Voilá! – Pludselig har man skabt en udviklingsproces der er blevet brugercentreret.

Jeg forbeholder mig dog retten til masiv skepsis. Faktisk forventer jeg, at mine usabilitykrav i en eller anden form bliver syltet, nedstemt, overhørt, misforstået, glemt, latterliggjort eller bare bliver tilgået med en uvidende og lidt bøvet mangel på egentligt forståelse, for hvad fanden man skal gøre ved dem.

Selvom man skulle have lyst til at arbejde brugercentreret, så kan en sådan proces ikke trylles frem hen over natten. Det kræver organisering, planlægning, ressourcer, kompetencer og alt det man nu har behov for i en professionel arbejdssituation. Så hvis man blot gemmer disse krav til sidst, så får man sig naturligt en overraskelse, som man så ikke kan håndtere – og så er vi tilbage til syltet, glemt, etc.

Igen. Det er også på papiret. Hvordan det bliver i praksis kan jeg ikke sige noget om. Men indtil videre skriver jeg på mine usability-krav med usability-mål. Så tager vi den derfra. Og jer derude kan være med i erfaringsdannelsen efterhånden som den formes.

Hvis du har læst ovenstående og er enig, uenig eller har erfaringer med noget tilsvarende, så vil jeg meget gerne høre fra dig. Ikke bare sådan hvis du har tid, nej – kontakt mig med det samme! (venligst…)

“Denne artikel er god hvis 8 ud af 10 læsere i en test, synes at den er 50% vedkommende i deres usability-arbejde – ellers skal den slettes igen efter en uge”.

Ja, det er sgu hårde odds…

Olhurt