När jag var liten (60-tal) fanns inom verkstadsindustrierna en av industriarbetarna ofta illa ansedd yrkesgrupp benämnd tidsstudiemän. Deras attribut var ofta den grå lagerrocken med Pocket protector, skrivplatta med stoppur och deras lära var Taylorism. En av tidsstudiemän vanligt använd metod var MTM (Methods-Time Measurement) vars mål var att optimera repetitiva arbetsprocesser inom industrin. Man bröt ner processerna i korta men mätbara moment och mätte tid för dessa. Momenten kunde vara; hämta skruv från låda A, passa in skruv i hål B på arbetsstycke C o.s.v. Under tiden kontrollerades om det fanns några onödiga rörelser som t.ex. kunde elimineras genom att t.ex. ändra placeringen av låda A. Att tidsstudiemännen ofta var illa sedda var förmodligen kopplat till att de störde yrkesstoltheten hos de "studerade" och att dessa blev lättare utbytbara när processerna blev nedtecknade.
Nog om historia nu. Jag kom att tänka på detta i samband med användbarhetstester av IT-system. Ofta sker användbarhetstester mot enstaka IT-system för att validera systemets specifikationer, sällan kopplat till de arbetsprocesser som systemen kan vara en del av. Min idé (som kanske finns förverkligad som metod men som jag i så fall är okunnig om) är att tänka lite MTM vid krav och tester av IT-system som är del i arbetsprocesser bland flera andra IT-system och alla icke-IT delar i arbetsprocessen. Det enskilda IT-systemet kanske inte uppvisar några hinder för att användaren skall kunna göra ett bra arbete men i den totala arbetssituationen kan systemet upplevas som mycket ovänligt. T.ex. upprepade in och utloggningar i olika system, möjligheter att klippa/klistra mellan systemen, olika GUI och kortkommandon m.m. påverkar arbetssituationen påtagligt.
Idéerna med MTM och Taylorismen skulle här inte användas för att ifrågasätta användarna utan för att kunna ställa rätt krav vid upphandling och utveckling av IT-system som ingår i större arbetsprocesser och för validering/användbarhetstester av hela processer.
Användbarhetstester bör utgå från användarens arbetsdag och arbetssituation, inte det enskilda IT-systemet "användbarhet"
Det borde vara så att egenskapen "användbarhet" alltid kopplas till systemets ändamål, dvs till den process som systemet stöder. Det finns en processlogik som ska följas, t ex ett säljsamtals normala upplägg eller en granskningsprocess normala förlopp, och brister systemets logik i relation till processen är all läsbarhet och all följsamhet till inmatningsstandarder inte ens vatten värd.
SvaraRaderaAtt se "användbarhet" som en neutral systemegenskap med värdet X där X ≥ Y alltid ska accepteras är lika galet som att se "kvalitet", "säkerhet" eller "lönsamhet" som egenskaper med generella tröskelvärden som det alltid räcker att precis överträffa, bortkopplat från den verklighet som systemet verkar i.
Om det saknas konkreta användbarhetskrav är risken att ett användbarhetstest med hög precision ger ett resultat utan noggrannhet, dvs att resultatet är irrelevant. Då kan man lika väl låta bli att testa.