Provo vs. provo

Idag indtraf en situation ,der med et lærte mig noget nyt om usability og mig selv, på hele tre måder: Personligt, praktisk og metodisk.

Se, jeg havde lavet en variation over en persona og givet den en teknisk betegnelse, som jeg havde afluret hos nogle udviklere. Vores persona hedder normalt Ellen, men jeg havde i stedet skrevet: “Mød ZARB_CASEMAT”. Det sidste er det tekniske navn på rollen i det CRM vi bruger. Jeg følte et behov for at beskrive nogle af de ting som brugerne er frustrerede over i de standardopsætninger der findes af dette CRM. Så under titlen stod fx. at ZARB_CASEMAT “Kun arbejder med tid i timer og minutter, hun forstår ikke hvad kl. 10,72 er” – eller at “Hun interesserer sig ikke for ID numre som 6000000354, men i stedet for CPR-numre”. Begge beskrivelser, dækker funktionalitet der er typiske for dette CRM, hvor tid skal omregnes og hvor alle objekter har et langt ligegyldigt systemisk ID-nummer.

Jeg viste denne visualisering til min nærmeste leder. Hun mente den var provokerende, hvilken hun sagde sådan lidt lavmælt. Det kan jeg som sådan godt følge, jeg havde grint i skægget over indholdet. Det var lavet for at sætte tingene lidt på spidsen, men ikke desto mindre er det empirisk korrekte antagelser. Det ved jeg, fordi jeg har spurgt brugerne.

Men da hun sagde det, fik jeg tre interessante tanker:

1) En slags skam, over at have provokeret nogen, måske ennda uretmæssigt. Jeg fik lyst til at sige undskyld og forestillede mig straks, at nogle ville blive oprigtigt sure. Det var den personlige, følelsemæssige respons. Den er så nu, mindre relevant og interessant.

2) Et modsvar i mig der sagde: Ja, det er skam også meningen. Vi skal provokere hinanden til at “tænke ud af boksen” (som det hedder når det er helt moderne og røv-irriterende, men hvor vi ikke kan sætte ord på det). Vi skal rykke ved hinanden og ændre på de ting vi gør dårligt. Det er en vigtig funktion at kunne provokere, eller i det mindste at udfordre. Hvorfor skal udviklerne på projektet ikke have det råt for usødet: Vores brugere forstår simpelthen ikke de ting I leverer, lær det og lav det om næste gang. Hold op med at lave midlertidige løsninger med ID-numre og beregninger, begyndt at tænke helhedsorienteret og brugs-relateret. I er fortidslævn fra IT-stenalderen når I opfører jer sådan.

3) Og måske mest interessant. Så det er mig der provokerer? Næ, hov. Vent lige en gang. Jeg bliver jo dagligt provokeret af de ting der kommer fra denne standard CRM løsning. Provokeret over hvor menneskefjendsk IT kan laves stadigvæk. Provokeret over, at det er mig der evig og altid skal råbe op og gøre opmærksom på at de ting skal ændres eller helt fjernes – jeg skal endda begrunde det!

Her kan jeg synge min gamle traver om, at det altid er usabilityfolket der skal prædike, skal være bannerførere, skal hænge ting op og skabe dialog, skal visualisere. Jeg plejer at sige: Vis mig den virksomhed hvor udviklerne mødes og diskuterer hvordan de kan tilpasse deres metoder, så det er lettere for usabilitykompetencer at bidrage til deres processer. Hvor de arbejder metodisk på at finde en måde at inddrage usability i deres arbejde. Vis mig en lærebog om udvikling eller et programmeringssprog, der starter med to kapitler om hvilke udfordringer der er, ved at kommunikere med alle de humanistiske kompetencer med deres kvalitative beskrivelser. Vis mig det!

Men ingen har ondt af lille mig. Ingen bekymrer sig om ham der “UI-manden”, der blot vil sikre at de endelige brugere kan forstå, hvad helvede der står på skærmen. Det må han selv klare, men han skal ikke komme og provokere os i vores hellige haller. ID numre er vigtige i vores arbejde og de skal være lange, så vi kan mange af dem og de skal blande bogstaver og tal godt og grundigt, så man aldrig nogensinde kan skille dem fra hinanden, selvom de aldrig er ens.

Så det var, på mange måder, en god og brugbar provokation. Og heldigvis fik jeg flere email-svar fra udviklerne, der faktisk tog det med et smil og godt forstod hentydningen.

ZARB_CASEMAT lever og har det godt med hendes provokerende rolle. Men hun giver ikke op. Hun forstår ikke hvorfor hun skal regne ting i hovedet, når hun sidder foran en kæmpe regnemaskine. Hun forstår stadigvæk ikke hvorfor ting er blevet lavet til objekter og hvorfor tre sammenhængende objekter på samme tid kan have statusser, der hedder henholdvis “Opstået”, “frigivet” og “afsluttet”. Det gør jeg heller ikke. Og det provokerer mig. Så jeg prøver blot at sende aben videre…

Så nemt skal ‘de’ ikke slippe 🙂

Olhan

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