Fogg of not war

Nedenståene indlægs pointe minder meget om bagtanken i iterative udvillingsforløb. Det minder også om den måde fx 37 Signals beskriver den bedste måde at udvikle webapps – eller, (for ham lyttede jeg til idag), det minder om den måde B.J. Fogg beskriver hvordan man udvikler overbevisende (persuasive) appliktioner til online sociale service. Han siger, “lad vær med at tænke for dybe tanker, bare kom igang. Få nogle erfaringer, smid ud eller forbedre, prøv igen”. Dejligt at høre at den tanke, særligt når det gælder web, er ved at vinde udbredelse mange steder. Det er også nogenlunde den pointe Bill Buxton har med sine “skecthing the UX”: Du skal kunne smide tingene ud, ellers har du allerede brugt for meget krudt på dem (altså på det tidlige udviklingstrin naturligvis). Så den tanke skal derfor også indtænkes i den måde vi arbejder med usability, hvilket er indlysende, da forholdet mellem design og evaluering fordrer det.

Du skal evaluere for at kunne designe. Its seeing-moving-seeing baby. Derfor er det nærmest selvforklarende dumt det jeg skriver nedenfor, men vel derfor også korrekt. Den må jeg arbejder lidt videre på…

Check BJ Fogg ud, manden mener seriøst at persuasive technology er måden til at opnå fred på jorden. FRED PÅ JORDEN! Så har man sgu’da ikke sat sit projekt under en skæppe. Mandens tanke fortjener en chance. Jeg vil meget gerne overbevises, særligt af en amerikaner.

Olür

Usabilitymål: Start et sted og kvantificér siden

Det er bare en tilføjelse til indlægget herunder, nogle tanker som kom til mig i en forelæsning om usabilitykriterier. Her præsenterede jeg eksempler på kvalitative og kvantitative mål der kan opfylde kriterierne og fik (som altid) spørgsmålet om hvordan man ligesom starter. “Hvor mange ud af hvor mange skal kunne udføre en opgave på hvor kort tid? Hvad er typisk, hvad er standard?”. Svaret i første omgang var “Man må starte et sted”. Men det var faktisk et overraskende fornuftigt svar, på trods af de smil det medførte.

Der er to ting man kan udlede:

1) Man er nødt til at starte kvalitativt og derefter arbejde sig ind på kvantitative mål. 2) Man kan ikke starte med at definere sine mål, men må etablere den iterativt – uha, ligesom alt andet i IT-udvikling.

Look at it this way: Man starter med at opstille nogle kriterier. Det kan man godt. Hvad er vigtigt for os. Lad os sige effektivitet. Godt så. I designfasen går man så igang med at kvalificere sin designproces, igennem evalueringer af de valg der foretages. Det kan være kortsortering eller måske papirprototyper. Man kan ikke opstille kvantitative mål i disse tests. Det giver ikke megen mening at sige – ok, så er der papirprototype og vi tæller antal tastetryk og tager tid på skidtet. I stedet vil man nok interessere sig for forståelsen af de design der er lavet. Kan man bruge det? Kan man løse opgaven? Passer det til domænet og brugssituationen?

Langsomt arbejder man sig frem mod en funktionel prototype, det bliver måske langsomt digitalt – samtidigt giver det mere mening at kvantificere – og måske derved også øge presset på – kriterierne. Gøre dem sværere at opnå. Løfte kvaliteten, stramme garnet. Det betyder ikke at de kvalitative smides væk, de kvantitative kommer bare mere på banen. Nu vil vi ikke bare vide om du fatter det vi har designet, vi vil faktisk også gerne have at du kan udføre opgaverne hurtigere end i den gamle løsning.

Sådan kan man blive ved. Første gang man tester er det 6 ud af 8 brugere der skal løses opgaven indenfor 10 minutter, næste gang er det 7 ud af 8 på 7 minutter  – og så fremdeles.

Voila: Nu er vi ved at være fremme der hvor vi troede vi startede, nemlig med målbare, realistiske og flotte usabilitymål, som er er ægte bud på produktets kvalitet i brugen og samtidigt er dybt forankrede i både usabilitykriterier og den udviklingsproces vi har været igennem. Nu er det ikke længere nogle flotte ord på hjemmesiden, nu er det et mål der er opnået (hvis man altså også har presset sig selv lidt undervejs – ellers er det bare crap).

Så start et sted. Læg pres på kvaliteten. Gå fra udelukkende kvalitativt til både kvalitativt og kvantitativt. Få sat en standard for produktet, som danner udgangspunkt for kommende produkter og udviklingen fremover. Do it once and you will never have to do it again – eller i det mindste kun får at øge kvaliteten.

Ole

Hvordan har dine usabilitykriterier det?

Her forleden dag talte jeg til et gå-hjem-møde i en IT-virksomhed. Emnet var naturligvis usability. Det handlede mest om noget definition og hvordan man ligesom kommer igang, når man nu er blevet enige om at det er vigtigt og relevant.

Min sædvanlige svanesang kan læses her på bloggen, og indeholder den opgave at en virksomhed skal definere sine egne kvalitetsmål for produkternes brugbarhed – naturligvis. Sådanne mål tager udgangspunkt i nogle usabilitykriterier. De kan se forskellige ud, men et sted at starte er disse fem:

  • Funktionelt, Effektivt, Engagerende, Let at lære, Fejltolerant

De er lånt et sted fra, men når det nu er en blog, så orker jeg ikke lige at bringe referencen. Er det vigtigt, finder du nok selv ud af det. De tre af dem kender du jo fra ISO standarden for usability, men learnability og error tolerant lige presser noget menneske med ind i den ramme.

Uanset, så er det interessante her, at jeg retorisk spurgte forsamlingen – som man kun tør når man kender svaret: “Ville I være klar til at foretage en afsluttende usabilitytest for at vurdere hvorvidt produktets usabilitykriterier er opfyldt  – og, hvilken er det afgørende – forkaste produktet hvis det ikke levede op til kravene”.

Svaret er naturligvis nej. Af flere grunde. For det første er det meget for virksomheder der har velformulerede, velbegrundede og velfunderede usabilitykrav til deres egne produkter. Hvilket egentligt er underligt. Hvorfor ikke sætte ord og handling bag ønsket om at levere brugbare produkter? For det andet tør langt de fleste virksomheder ikke dumpe et produkt på brugervenligheden.

Hvis den virksomed jeg besøgte faktisk får etableret et usability-manifest, med kriterier og måske endda faktiske kvantitative mål, så er jeg meget stolt og vil beundre dem for evigt. Sgu også selvom de ikke får dem forankret, indbygget i metodeværktøjerne og alt det andet svære halløj – jeg vil alligevel synes det er sejt.

Så nu giver jeg udfordringen videre. Vis mig dine usabilitykriterier. Vis mig hvor det er formuleret hvad jeres produkt skal leve op til før det forlader produktionslinjen. Vis mig, at I laver det om hvis ikke “6 ud af 8 brugere kan gennemføre typiske arbejdsopgaver inden for 10 minutter” – eller hvad det nu er. Vis mig at det er ligeså vigtigt for jer som oppetid, driftsikkerhed og alle de andre kvalitetsparametre I godt tør sætte tal og ord på.

Giv mig et offentligt udbud hvor de ting er hugget i sten, ja giv mig en udbud hvor virksomheden skal leve op til Usability Maturity Model, level E. In your dreams pal…

(Offentlige udbud idag er vist noget med tastaturgenveje og generel brugervenlighed – come on, det kan alle levere i søvne)

Hvordan kan man arbejde professionelt med usability i en virksomhed, hvis ikke målet er formuleret og gjort bare nogenlunde målbart? Hvad kan man slå hvem i hovedet med? Ingenting! Tværtimod stiller man i stedet op med alt muligt humanistisk bullshit og User Experience oplevelsescrap, men det behøver ikke udløse nogen konsekvens. De stakkels mennesker, der mener det er vigtigt, leder så med lys og lygte efter eksempler på hvor skidt det står til med løsningen, nu hvor den reelt set stinker i brugssituationen. “Se selv”, råber de. “Der kan I selv se”. Men de har reelt ikke noget at komme efter. Toget er kørt og med mindre det kører totalt af sporet, så kan det køre i mange år.

Det er vel et spørgsmål om ærlighed i sidste ende. De fleste skal bare se i øjnene, at det er meget lavt prioriteret der hvor de arbejder. Kunsten er umuligvis at få ledelsen til at acceptere det åbenlyst. At sige til dem, “hvis det ikke er beskrevet og har konsekvens, så mener vi det ikke alvorligt og så må vi leve med de problemer det giver”. Men sådan går det sjældent. Det fejes ind under bordet.  “Jo jo, vi laver skam brugervenlige løsninger” – Dokumenter det for mig!

In even more of your wet dreams pal!

Nå, men mens vi venter på det, så er idéen måske slet ikke så dum. At tage stilling til kvalitetsegenskaben usability for det produkt man udvikler. Skrive det ned og op. Sætte tal på, der hvor der kan sættes tal på det. Skrive på hjemmesiden og være stolt at det. Teste konkurrenternes produkt og stramme skruen lidt på ens eget. Skabe fælles forståelse i organisationen omkring hvorfor og hvordan, få forståelse for hvad det betyder for produktet og gøre det til en fælles ambition. Can it be done?

På genlæselyst en anden gang.

Ole