Tanker om usability

Meta-information til brugeren: Dette er et tekst under forandring (current version: 4). Det er mit bud på en “tale”, der understøtter princippet om, og argumenterer for brugen af, usability i softwareudvikling. Forhåbentligt er du enig, men forhåbentligt sætter det også nogle tanker igang i dit hovede.

Teksten er min, men jeg vil gerne have du bruger den (når den har fået lidt hår på). Så er du måske bare sød at fortælle mig det. Sådan at vi vidensdeler, hvis du eller tør det (og tror på at det skaber mere viden). Never the less:

Et udgangspunkt: Vi designer (bygger, konstruerer, planlægger, gør) IT-produkter fordi deskal bruges.
Præmis: IT-produkter bliver lavet for at blive brugt!

(Der kommer flere præmisser undervejs. Et præmis i denne sammenhæng er et go/no-go. Accepterer du ikke præmisserne, så er du principielt uenig og kan ikke længere følge min argumentation).

Det er igennem brugen at produktets værdi skabes. Hvis ingen bruger det, har det ingen værdi.
Retorisk spørgsmål: Kan vi designe IT-produkter uden at interessere os for hvordan de bliver brugt?

(Der kommer også flere retoriske spørgsmål undervejs. Igen, de har et typisk svar, ofte ja eller nej. Den ene mulighed er langt at foretrække. I eksemplet ovenfor er det fx formåltjenstligt at svare nej – primært fordi det passer godt med præmissen ovenfor. Svarer du ja, opstår der problemer i argumentationen senere).

Note: Vi kan godt designe produkter uden interessere os for brugen. Det sker mange steder hver dag. I så fald er det oftest styret af forretningsinteresser, ressourcebegrænseninger eller generel uvidenhed. Nogle steder handler det om noget så simpelt som software-udviklings-tradition. At man ikke er vant til at tænke så meget i den slags, det handler mest om at få udviklet produktet og ingen brokker sig over den proces.

Men alligevel: Vi interesserer os altså for produktets brug. Derfor må vi forstå hvordan (ja og inden da sikkert også hvorfor) det bliver brugt. Hvordan gør vi det? Som udgangspunkt er “brug” jo noget der foregår i samspil mellem brugere og produktet. (Allerede her er vi på hjemmebane når vi arbejder med usability. Det er noget vi kan genkende. Bruger over for IT-produkt. Det lugter af menneske-maskine interaktion).

Så vi har brugere og vi har deres brug. Hvad kan vi sige om det? Vi kan sige, at vi må kende til disse brugere. Det er ikke tilfældigt hvem de er. De kan være dumme eller meget kloge. De kan være unge eller meget gamle. De kan være nybegyndere eller meget erfarne. De kan være dig eller din mormor – kan du se forskellen?

Vi må også kende grunden til at de er brugere. Hvorfor bruger de overhovedet produktet. Hvad vil de opnå – hvad er deres mål?  – mål er mange ting: Det er fx arbejdsmål og personlige mål. Målene motiveres og udtrykkes i behov eller (arbejds)opgaver eller handlinger. Er de motiverede af lyst eller pr. ordre? Du kan med garanti hurtigt stille mange flere relevante spørgsmål om dine brugere.

(Tilføjelse: ‘Goals and tasks’, udgør traditionelt udgangspunktet for forståelse af hvad brugeren vil, men i takt med at User Experience vinder udbredelse, er det ikke nok at forstå mål og opgaver, men i stedet spørge, hvad det er for en oplevelse brugeren ønsker og hvordan kan vi skabe den – men vi skal naturligvis stadig lave alt usability-arbejdet).

Og så må vi også kende til konteksten for brugen. Der plejer jeg at pege på to kontekster.
Den ene: Om vi snakker mobile enheder eller kontorarbejde. Om brugeren sidder stille og rolig og gør en opgave færdig ad gangen, eller vælter rundt og zapper mellem opgaver og IT-systemer.
Den anden: Om de vælter rundt på internettet eller arbejder med et specialist-værktøj, altså den teknologiske kontekst om man vil. Ja, for den sags skyld om det handler om displayet på en video eller på en touch-smart HP.

Tilsammen vælger jeg at kalde det brugssituationen. Eller  hvem, hvad, hvor:

• Hvem – er brugeren?
• Hvad – Vil brugeren opnå?
• Hvor – foregår brugen?

Det er da til at huske. Man skal altid have tjek på sin hvem, hvad, hvor når man designer IT-produkter.  Det må være et fornuftigt udgangspunkt, vil jeg mene.

Tilbage til brugen. Som softwareudvikler (i bred forstand) er jeg altså i gang med at interessere mig for, hvordan mit produkt bliver (eller vil blive) brugt. Nu har jeg undersøgt brugssituationen og jeg har besluttet mig for hvad mit produkt skal kunne. Men hvornår er det så brugbart? Det svar fås i brugssituationen. Det er der det skal være brugbart. Men i forhold til hvad? Det siger slet ikke noget målbart, forretningsmæssigt værdiskabende eller planlægningsorienteret håndgribeligt.

Note (læs: sidespring): Så der tegner sig to “tidspunkter” i brugssituationen, et før og et efter dit produkt rammer brugeren. Man kan også sige, at der er to tilgange til brugssituationen, en analyserende og en evaluerende. Ja, de overlapper nok eller er samtidige…

Det er her usability kommer ind i billedet. “Brugbarhed“. Se på ordet. Det siger noget om at et-eller-andet er brugbart. Om hvor brugbart det er. Så hvornår er noget brugbart? Det kommer an på!

Note: En klog kone (tak Pernille E.) har en gang lært mig at splitte sammensatte ord og bytte rundt på deres dele. Brugervenlighed= Venlighed overfor brugeren. Det kan da ikke siges meget tydeligere. Resultat: Hvem er brugeren, hvad er venlighed: Vær’sgo at finde ud af.

Svaret er: I forhold til den kvalitet man ønsker produktet har i brugen. Altså må vi selv definere, hvad det vil sige at produktet er brugbart (for brugerne i brugssituationen vel at mærke – hvis den ikke skulle være feset ind endnu).

Her er lige en kunstpause. Det er nemlig vigtigt lige at blive enige om, at produktets brugbarhed, er en egenskab produktet har. Et produkt er altid mere eller mindre brugbart. Vi må forudsætte (endda i en sådan grad, at det ikke engang kan tillades at være en præmis), at vi produktet ønskes så brugbart som muligt. Så høj brugbarhed er altså en mål for en kvalitet produktet har. Usability er altså en kvalitetsegenskab som alle produkter har. Det kan ikke fratages produktet. Ser man bort fra det, så ser man bort fra en kvalitetsegenskab produktet har.

Note (hold kæft hvor er det irriterende med alle de noter): Men jeg bliver nødt til at introducere en global og en lokal kvalitetsegenskab. Den globale er den kvalitet alle digitale produkter har/skal have, i virkeligheden de-facto standarden, det man som bruger forventer eller er afhængig af for overhovedet at kunne gå til produktet. Den lokale er det specifikke produkts specifikke kvalitet. Begge dele er vigtigt, men de tilgås lidt forskelligt.

Tilbage på sporet: Vi vil altså gerne definere produktets kvalitet i brugen. På den måde kan vi vurdere, om det er lykkedes os at lave et brugbart produkt. Til det formål kan vi opstille nogle kriterier produktet skal leve op til for at vi kan sige “Hurra, vores produkt er brugervenligt (ift. til vores egne kriterier, vel at mærke )”.

IT-produkter bliver i hvert fald ikke brugervenlige af sig selv!

Vi er nu ved at være fremme ved et lækkert øjeblik. Et IT-produkts usability kan beskrives som en situation, hvor produktet i brugssituationen lever op til nogle usabilitykriterier (og kriterierne er udtryk for et forretningsmæssigt mål).

Der er ikke et øje tørt – og grunden er (uden at snyde faktisk), at det nærmest er identisk med den mest benyttede definition på usability. Nemlig denne ISO standard:

” The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” (ISO DIS 9241)

Herover er, udover brugssituationens elementer, nævnt tre kriterier, som kan oversættes til at produktet skal være funktionelt (formåltjenstligt, skabe effekt, have nytteværdi), effektivt og tilfredsstillende (som minimum). Fint nok, det er bare at gå i gang…

Ok, det er nogle meget bredt definerede kriterier i definitionen herover, nærmest en slags “alle usabilitykriteriers moder” af en paraply af generalisering. Men ok, det skal jo være en standard der kan indpasses alle steder, så de tre er måske ikke helt dårlige: Produktet skal tjene et formål, vi skal ville bruge det til at løse opgaven med. Produktet skal være effektivt, vi vil faktisk helst kunne løse opgaven på den bedst mulige måde (med mindst muligt “energi”) - og produktet skal være tilfredsstillende at bruge. Fordi vi, brugerne, sjovt nok, oplever produktet som mest brugbart hvis vi faktisk samtidigt bliver subjektivt tilfredsstillet (fact of life tror jeg at mene).

Til dagligt er vi nok nødt til at skære kagen lidt mere skarpt, hvis vi skal bruge det til noget. Vi skal operationalisere disse kriterier, gøre det til noget vi vil opnå for vores produkt. Vi må bestemme, hvornår vi mener vores produkt er funktionelt, hvornår det er effektivt og hvornår vores brugere rent faktisk bliver tilfredsstillede i brugen. Og der kan sagtens være andre og flere kriterier. Nogle bruger hele 5, hvor også let at lære og fejl-tolerant indgår. Man kunne da også tilføje, learnability eller guessability, det kommer bare an på hvad der er produktets ønskede kvalitet i brugen.

Ok, men de skal altså operationaliseres de kære kriterier. De er ikke lige vigtige, så de skal først vægtes. Det kan være i procenter: 50% Fejltolerant, 20% effektivt, 10% engagerende og 20% let at lære.

Det er kun et fattigt skridt. Vi skal også have sat ord på, hvad det kræver at opfylde disse procentsatser. (Det har jeg skrevet om i selve bloggen).  Nu nærmer vi os noget, der både kan hænges op på væggen, skrives på hjemmesiden og hviskes i korridorerne hos konkurrenterne. Vi nærmer os noget der kan stå i et udbud eller en kravspecifikation. Vi nærmer os måske et fælles mål? Ikke bare fælles internt, men også fælles eksternt. Det er win-win-win, for kunde, producent, bruger.

Note: Et at mine favorit ord, udover værdi, kvalitet og forankring er: Explicit! – Get it out in the open, bliv enige om en fælles forståelse, få de små selvbestaltede forståelses-skeletter ud af skabet og støv det af i en fælles facilliteret proces med masser af stolthed.

Designudfordringen. Den skal jeg også have med. Hvorfor kan man ikke blot designe produkter der er 100% brugervenlige, blot med en forståelse for hvad brugervenlighed er? Som altid er det nok i detaljen at den skal placeres (djævlen eller aben, vælg selv efter præference). Her er nogle bud, på det jeg tilsammen kalder for designudfordringen:

1) IT-produkter er ofte uendeligt komplekse, med tusindvis af valg i designprocessen fra start til slut. Selvom man tænker på brugerne i alle disse valg, så vil selve antallet af dem, gøre den proces så kompleks at det reelt er umuligt at forudsige resultatet af deres samlede betydning.

2) En klassiker indenfor projektledelse går på at: Mængden af informationer, der danner baggrund for valg ved projektets, start er relativt er relativt lille, mens de samme tidlige valg har uendeligt stor betydning for projektet. Derfor skal valgene løbende kvalificeres, det gælder særligt valg angående brugen af produktet, som ikke kan bestemmes før der er noget at bruge, hvilket jo som regel ikke er tidligt i udviklingsprocessen.

Disse to ting tilsammen, betyder at brug af produktet er nærmset umuligt at forudsige, fordi brugen er et resultat af interaktionen mellem et menneske og en løsning – hvor førstnævnte er en underlige dynamisk, følelsespåvirket biologisk mekaniske, og hvor den anden (udover at være alt det modsatte) er resultatet af alle de mange valg og udfordringer der findes i udviklingsprocessen.

Med andre ord, vi kan ikke i vores design ikke forudsige brugen af produktet og vores designvalg er derfor potentielt forkerte indtil vi har fået dem kvalificeret. Gør vi ikke det løbende, kan vi risikere at direkte at modarbejde en brugbar brugssituation.

Design er valg. Hele tiden. Over det hele. Hvert valg har betydning for produktet brug. Udfordringen er at vi ikke kan forudsige disse valgs betydning. Hvilket vi så skal have en måde at håndtere.

Derfor snakkes der meget om iterative forløb, agile metoder og alt det. Kun med det enkle formål at kunne justere undevejs, fordi vi ellers bliver fanget i valgenes kompleksitet, omverdenens forandringer, projektet dynamisk og udvikling og mange andre faktorer.

Her slutter festen for nu (26. august 2009) – jeg kommer nok til at vende tilbage med noget mere alternativ tilgang til usability i det hele taget, nemlig ROI, eller “cost-justifying”. Kroner og ører! For vi skal have argumenterne cementeret her. Vi gider ikke høre på nogen der siger at det ikke kan betale sig (uanset, hvad der betales med). Det er en af opgaven, om man vil have den eller ej…