Jeg har tidligere skrevet om ressourcer (dokumenter) til usability-kriterier. Mere præcist har jeg henvist til Common Industry Specification for Usability – Requirements – eller CISU-R. Ganske fortinligt dokument viser det sig (ved granskning). Faktisk understøtter det en af mine kæpheste (eller darlings (don’t kill it!)), nemlig det at opstille usability-mål for det projekt eller produkt man arbejder med. Idéen er helt rationel og logisk: Hvis man ikke sætter et mål for hvor brugbart noget er, så kan man heller ikke vurdere om man har opnået det niveau.
Jeg har gjort mig en del tanker og etableret mig en forståelse omkring brugen af usability-kriterier og -mål. En forståelse jeg så prædker, primært på IT-Universitetet: På samme måde som de fleste af mine andre mentale modeller, så ender formidlingen ofte i noget tre-punkts-form. Usability-kriterierne har jeg passet ind i en model med: Brugssituation (brugere, mål, brugskontekst), Usabilitymål (kvalitet) og Produkt (adgang til ressourcer og kompetencer). Den opstilling synes jeg er frugtbar. Grunden til, at jeg nævner den her er, at CISU-R præsenterer en anden og tilsvarende tre-punkts-liste, som på mange måder er relateret. I den indgår: Context of Use, Performance and Satisfaction Criteria og Test Method and Context for Test. De to opstillinger vil lidt det samme, jeg har blot taget teknologien mere direkte med, mens CISU-R holder lidt mere fast i sammenhængen mellem kriterier og test til vudering af deres opnåelse.
CISU-R er en ramme, en mængde informationer der skal tilvejebringes, en bunke beslutninger der skal tages. Dertil er dokumentet fyldt med eksempler og skabeloner, så det er også ret handlingsanvisende.
Uanset. Jeg synes CISU-R er superfedt, fordi det også passer ind i en problematik jeg gerne arbejder med: Hvad er det der mangler i udviklingsprojekter, for at sikre, at der bliver arbejdet seriøst, professionelt og kompetent med usability. Svaret ligger i CISU-R. Og det er: Specificering af usabilitykrav!
Det er ikke krav til brugergrænsefladen. Det er ikke funktionelle krav til interaktion (der måske, måske ikke er brugervenlig). Nej, det er specifikke usabilitykrav, som understøtter og komplimenterer de øvrige funktionelle, processuelle og kvalitetsorienterede krav.
Det er såre simpelt. I kan ikke arbejde med usability, hvis ikke I stiller krav til det. Det giver ikke mening at slås om ressourcer, testmetoder eller udviklingsproces, hvis ikke der er enighed om, at der skal opnås en bestemt kvalitet i brugen af produktet. Den kvalitet fordrer processen, metoderne og behovet for kompetencer – eller skulle det i bedste fald.
Jeg arbejder selv til daglig i en virksomhed som ikke direkte stiller krav til usability. Der stilles mange andre krav, hvoraf flere er relaterede. Men også derfor er arbejdsprocessen omkring håndtering af usability ikke fastlagt. Den er beskrevet, men bliver – som mange mange andre steder – hånderet lidt lemfældigt (og det er pænt sagt).
Det lækre ved CISU-R, er at den tager opgaven meget alvorligt, hvilket jeg også tror er måden gøre det på, i den moderne, dokumentations-fikserede, modenheds- og certificerings-fokuserede, styringsliderlige softwareudviklings-verden. Der henvises til ISO-standarder i flæng og det beskrives hvordan CISU-R passer ind i alle mulige seriøse og gennemdokumenterede proces- og metode-beskrivelser.
Men igen. Kunsten er at få etableret usabilitymål i den organisation man indgår i. Som en del af den fælles strategi, som et eksplicit kvalitetsniveau produktet skal opnå.
Tilbage er kun at argumentere for værdien af denne proces (i rigtige penge). Det findes der med garanti også et godt, praksis-orienteret svar på derude…
Lad os komme igang med at specificere vore usability-krav.
Ohür
