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
