Tanker om usability

En blogpost hos Adaptive Path lægger op til flere forskellige diskussioner. Det primære er, at nogle begreber og forståelser indenfor design og User Experience, er ved at blive så almindelige, at nogle oplever det som et faresignal. Noget man skal være påpasselig overfor.

En af kommentarerne til dette indlæg nævner, at mange virksomheder taler om innovation og bruger-centreret tilgang i iterative designprocesser, hvor der skal tænkes ud af boksen (ja, måske kan jeg godt fornemme ,at det er noget vi hører igen og igen) – men at meget få, helhjertet, også har disse tilgange implementeret.

Jeg er enig. Men det er nok naturlig at smøre lidt rigeligt på. Tidligere har jeg gjort mig klog på, at “brugervenlighed” har sejret sig selv ihjel. Det er blevet et gratis, udhulet, helt overordnet og flertydigt begreb, noget alle forventer og fejlagtigt tror er implicit i alle digitale produkter. Men jeg tror også, at forholdet mellem det der siges i reklameøjemed og det er foregår i udviklingsprocessen, stikker dybere end som så.

Indenfor usability (og andre fagområder) taler man om say-do konflikter: At brugerne siger en ting, men gør en anden. Hvilket også er grunden til, at vi gerne vil se dem in action når vi brugervenligheds-tester. Det samme gør sig gældende når vi snakker om usability i udviklingsprocesser. Vi kan allesammen nikke og være enige. “Ja, naturligvis laver vi det brugervenligt”. Men når det kommer til stykket, så er det nemmere sagt end gjort. Af mange grunde.

En grund kunne være, at vi simpelthen ikke er vant til at lade et brugscentreret designprincip overskygge andre traditionelt fremherskende opfattelser af, hvad der er rigtigt og forkert – og som dermed styrer vores overordnede prioritering og beslutningsproces. Hvis vi er tekniske specialister, så forventer vi at være vidende om hvordan tingene laves bedst, ikke være flæbende fjolser, der hele tiden skal have de besværlige brugere til at kvalificere det for os. Hvis vi er projektledere, så vil vi tage hurtige og effektive beslutninger – eller hvad ved jeg. På den måde kræver det en samlet og eksplicit forståelse af et brugscentreret princip, før at alle designbeslutninger tages på et brugerkvalificeret grundlag. Og en sådan forståelse kommer ikke af sig selv…

Det kræver en hvis styrke som organisation – hvorfor det også er en sjældenhed – at være helt skarp på hvornår og hvorfor man laver usability, mens det er ligeså vigtigt at være skarp på hvor man ikke gør det og hvorfor ikke. Men hvis det ikke et tydeligt i et projekt, så er det næsten umuligt at håndtere en usability-proces kvalificeret og systematisk. Så falder de gode intentioner på stribe og vi fik alligevel ikke helt arbejdet med produktet som vi fik lovet hinanden og omverdenen.

Hvad kan vi lære at det? At vi skal gøre hinanden en tjeneste og blive meget præcise, når vi i vores projekter, taler om brugervenlighed eller andre lignende buzzwords. Vi skal tage diskussionen om hvad formålet er, hvilken værdi det skaber og hvordan det skal implementeres og følges til dørs.

Se, allerede der bliver det til en række begreber og tanker, som er nemme og sidde halvsløvt tilbage og nikke til. Ikke desto mindre.

Det er derfor det er svært. Det er derfor opgaven ikke er at sige, men at gøre. Og blive ved med at gøre.

Start her:
http://www.danskebank.dk/da-dk/mening/documents/mening.html – se blandt andet klippet med Simon Sten Petersen, der fortæller, om nogle af de ting han har lært, ved at høre på nogle af de 3000 indlæg fra Danske Banks kunder.

Se også www.danskebank.dk/bedrebank – især handling nummer 17. (På en for øvrigt ganske uoverskuelig oversigt).

Danske Bank vil bruge en milliard kroner på brugervenlighed. Det fremgår kun kort, at banken “forbedrer Danske Banks netbank og bankens øvrige selvbetjeningssystemer” og at du som kunde “hurtigt og nemt kan få overblik over din økonomi”. Det bliver spændende fra et usability-fagligt synspunkt, at se hvad de mange penge skal gå til. Det virker som et svimlende beløb, når man tænker hvor billigt det kan være, at lave selv meget indflydelsesrigt usability-arbejde. Måske indgår udvikling også, måske dækker det over alle bankens produkter, måske er det over de næste 10 år. Det er indtil videre ukendt.

(Opdatering: Udviklingsdirektør Carsten Smith kommer på besøg på usabilitykurset på IT-Universitetet og fortæller om initiativet)

Indtil da, synes jeg det er påfaldende, men måske også karakteristisk for hele bedrebank-kampagnen, hvor reaktivt problematikken beskrives. Som om man siger “vi vidste slet ikke det stod skidt til, det kommer som en stor overraskelse for os”. Så det kan ikke være meget opsøgende bruger-research der har været lavet på det seneste. Havde man spurgt og testet løbende, så man sandsynligvis slet ikke stå i den situation. Men den forståelse synes også at ligge implicit i hele Danske Banks tilgang.

Jeg har tidligere hørt præsenteret, arbejdet med Nordea’s netbank og brugervenlighed – og jeg var mildt sagt ikke imponeret. Det kunne ligne en trend hos de store banker. Jeg får næsten lyst til at åbne en konto i Danske Bank, blot for at følge med i den proces. Hvis jeg tager et skærmbillede nu og et igen om et år – ser det så en milliard federe ud ?

(Opdatering: Nu har jeg oprettet kontoen i Danske Bank, jeg må simpelthen komme tættere på projektet)

Fortsættelse følger, om ikke andet fra Danske Bank, som med et profetisk “på vej”, antyder at milliarden ikke er placeret endnu.

(Fraskrivelse: Jeg arbejder ikke for danske Bank, og i mit daglige arbejde har jeg ingen relation til Danske Bank).

Siden sidst:

Mere viden her -
http://www.danskebank.dk/da-dk/bedrebank/Documents/bedrebank.html?page=posts&category_id=1&post_id=18

Og de er også på twitter: http://twitter.com/bedrebank

Så blev vi lidt klogere…

De af jer, der arbejder med at stille krav til en IT-løsning (som er alle?)

- stiller måske endda også kvalitetskrav (som alle burde gøre?)

- kunne måske blive inspireret af at stille negative krav (hvis I må det?)

Især når man bruger standard-ramme systemer, så får man tit en masse, som der ikke er stillet krav til. Alene af den grund, kunne det være fristende at stille “modkrav”. Men der kan også være god mening med at stille negative krav i en kvalitetssammenhæng. Grunden er at det er farligt svært at stille gode målbare kvalitetskrav til en løsning. Af mange grunde.

Der er måske slet ikke noget direkte målbart ved brugergrænsefladen: Brugeren må bruge al den tid hun ønsker, alle de klik vedkommende orker osv. Det kan også være at der ikke er noget reelt at sammenligne med: Ingen konkurrenter, ingen tidligere version – eller måske bare noget der ligger tilpas tæt på det man ønsker. I de situationer (og mange andre) bliver kvalitetskrav til brugervenligheden ofte meget bløde. Det bliver hensigtserklæringer. Og de er de første ved skafottet når der skal estimeres, justeres, prioriteres.

I stedet kan man udtrykke det man vil undgå (ligesom man også kan lave negativ brainstorm og negative personas). Det giver større rum til det man vil opnå. Det kan være man vil sige at, brugeren i hvert fald ikke må få et bestemt resultat, men at flere andre resultater kan godtages. Det giver de der udvikler løsningen, større mulighed for at se på hvordan den teknologi eller standard-løsning som de tilbyder, kan løfte kravene.

Jeg bliver så glad når nogen snakker om brugervenlighed i medierne. Idag i radioavisen, blev  det nævnt at Forbrugerstyrelsen har lavet test af digitale modtagerbokse, deri indgik blandt andet at de var vurderet for brugervenlighed. Den er god nok. Se selv deres testresultater. De taler endda om “brugervenlige vindere”. Der er ikke et øje tørt! Interessant er det også at de enkelte modtageres samlede vurdering, stort set følder deres brugervenlighedsvurdering – men at prisen ikke gør det.

Det er da stof til eftertanke…

Metodisk er det foregået således:

“Fire studerende i brugervenlighed (DTU Design og Innovation) har været udpeget til at udgøre testens erfarne brugerpanel. De har bedømt boksene på en række scenarier som installation og dagligt brug. ” [sakset fra forbrug.dk]

Repræsentative brugere – næ, men der er måske mere tale om en ekspert-evaluering

Uanset, så glæder det mig at brugervenlighed indgår som parameter, ligesom det burde gøre i alle situationer, fordi:

Det er i brugen, at produktets værdi skabes

Mit politiske budskab her er, at vi skal have meget mere fokus på brugen af produkter omkring os. Særligt IT-produkter. Vi er generelt alt for sløve til at stille krav til disse, både i privaten og i det offentlige rum.

Ole-out

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