Posts Tagged ‘usabilitymål’

Skal I også i gang med at måle på usability?

lørdag, april 23rd, 2011

Der er en klar trend i tiden synes jeg, omkring at måle på usability. Måle i den forstand, at få fingre i nogle tal, der kan give indblik i hvordan vores brugere handler. Og her taler vi ikke bare om at se besøgstal i Google Analytics, men også om at få nogle kvantitative svar på forskellige brugs-relaterede spørgsmål i forskellige brugs-relaterede kontekster. Hele tiden med ønske om mere konkret at få indblik i 'kvalitet i brugen' af vores produkt. Lad mig give et eksempel:

Usability KPI i en kommune

En kommune i hovedstadsområdet ønsker helt overordnet at sætte sig en række mål for brugen af kommunens digitale services – alt fra antal henvendelser i borgerservice om barsel til antallet af downloads af bestemmelser omkring sygefraværsregler. Behovet udspringer primært fra tankegang (tror jeg) omkring at styre fremdrift igennem måling – altså en form for ledelsesstrategi. Det betyder at kommunens afdelinger skal definere en række KPI'er – målepunkter på deres ydelser – og på et mere systematisk niveau kunne afgøre om der sker fremdrift på baggrund af de aktiviteter og initiativer/projekter der sættes i søen. Det giver sikkert alt sammen udmærket mening.

Webafdelingen i pågældende kommune står nu overfor en udfordring, om ikke andet, så som kompetence på det digitale område og ansvarlig for at hjælpe resten af organisationen på vej: Hvilke målepunkter skal der opstilles (på vegne af hele kommunens online servicestruktur) og hvordan skal disse måles?

Jeg blev inviteret til at give lidt input, gennemgå et par måder at måle på usability og tage en diskussion med nogle af medarbejderne omkring hvordan de skulle bevæge sig fremad i den proces. Her er i korte træk hvad vi talte om:

Første trin er at beslutte hvad der skal måles på. De enkelte afdelinger har nogle svagt definerede ønsker og forskellige politiske prioriteter, men trænger til at kigge på to ting: Den ene er at få defineret hvad der skaber værdi for kommunen (eller afdelingerne) og den anden er at undersøge hvad der skaber værdi for brugerne. Værdi kan være at have færre borgere der ringer til kommunen og i stedet selvbetjener sig til svar/løsninger. For begge parter er dette en nemmere og hurtigere løsning = værdi. Målet er selvsagt at skabe mere af den værdi for kommunen, ved at forøge værdien for borgerne (det er jo en slags essens af det arbejde med usability).

Hvordan kan den værdi så måles? Det kan være gennem helt almindelig statistik, altså besøgstal eller lignende. Både på den online del, men også på presset på telefoner og email. Uanset hvordan vi skaber den viden, så vil den blive et udgangspunkt, det vi med fint kan kalde for et benchmark. Der vil også blive behov for nogle tilgange til at teste/måle, hvordan brugen udvikler sig, efterhånden som vi re-designer vores digitale services.

Fra den viden kan man også forsøge at skabe nogle usabilitymål. Et usabilitymål kan indeholde en beskrivelse af hvem der skal kunne hvad og i hvilken grad, samt naturligvis et niveau der skal opnås. Så kan kommunen fra test til test, vurdere om der er fremdrift.
En begrundelse for at tale om usabilitymål og for at se på andre tilgang en at kigge på brugs-relateret statistik, er at fx besøgstal og bouncerate%, ikke siger noget om hvor svært brugerne har ved fx at forstå regler eller love. Der skal andre metoder til.

Tre måder at måle på brugen

Den typiske tilgang er at lave brugertests. At stille repræsentative brugere repræsentative opgaver og tage bestik af hvordan det går. Det giver masser af input til at forbedre de digitale services, men der kan være en udfordring omkring at måle på disse tests. Uden måling kan vi ikke arbejde med målepunkter. Men til en start kan man sagtens få tal ud af brugertests, fx den procentvise gennemførelse af testopgaver, antal klik eller den tid det tager at løse opgaven (alt efter typen af test).

En anden tilgang kan være at gå mere digitalt til værks. Her kommer kommunen lidt til kort, fordi der ligger en række tekniske begrænsninger for hvilke værktøjer der må implementeres på kommunale hjemmesider (hvilket jeg personligt synes er bullocks). Men hvis vi lige ser bort fra det, så kunne en tilgang være hændelses-sporing.

I Google Analytics hedder det også Event Tracking. Det er et spændende og relativt nyt fænomen. Fordelen er at der kan opstilles hele specifikke handlinger online, som tælles og opsummeres i Googles Analytics interfacet. Det kan være klik på bestemte elementer, udfyldning af felter, downloads eller alt muligt andet. Det giver mulighed for at komme lidt mere i detaljen end blot sidevisninger og besøg. Det giver også mulighed for at måle på handlinger der foregår på den enkelte side eller opsamle sammensatte handlinger, som man fokuseret ønsker at tælle.

Denne metode giver ikke indblik i hvorfor brugerne handler som de gør, men prøver i stedet at fokusere på at tælle ønskede handlinger, som et symptom (eller målepunkt) på kvaliteten af brugen.

En tredie tilgang kan være at lave A/B eller multivariant test, hvor forskellige variationer af en hjemmeside, eller dens elementer testes live op mod hinanden. Det er også et område under stor udvikling, som har en vis iboende evidensbaseret styrke, fordi man direkte kan måle hvordan forskellige designs klarer sig.

Det kan gøre på mange måder, fra at teste en enkel sides evne til at skabe flere most-wanted-actions, til at vurdere om en hele sekvens af sider får flere brugere til at gennemføre et bestemt forløb. Om det bruges til e-handel eller til regler for sygedagpenge er som sådan underordnet.

Hvad skal vi måle på?

Så lang så godt. Tre forskellige tilgange som har hver deres styrker og svagheder, som til dels kan minimeres ved at afvikle dem sideløbende. Men også tre tilgange som alle har som forudsætning, at man ved hvad man vil måle på.

Så den største opgave, også for omtalte kommune, er at definere: Hvad vil vi måle på og hvilke mål skal vi sætte for brugen?

Kommunen valgte at starte med at indsamle viden. Lave brugertest og spørgeskemaer, for at få et indtryk af den nuværende brugs-situation(er).

Men kommunen er blot et eksempel. Samme behov opstår i denne tid naturligt i mange andre virksomheder, hvor ledelsen meget gerne vil have bedre styre på fremdrift og værdi af alle de digitale services. Men ikke bare værdi som besøgstal eller antal klik – også værdi som kvalitet i brugen – fordi den kvalitet i stigende grad er en afgørende faktor i virksomhedens strategi.

 

/Ole Gregersen

Tags:, , , , , , , , ,
Posted in Usability | Comments Closed

At bage – en kvalitets-kage

onsdag, maj 27th, 2009

Dette indlæg er primært et link til en anden artikel: “Follow the Recipe” på UXmatters.com. Er din tid knap, så stop med at læse her og læs der i stedet.

Mit take er, at artiklen arbejder med at forstå hvorfor vi skal have beskrevne processer for arbejdet med usability, hvorfor det giver mening at følge dem og – som er artiklens omdrejningspunkt – hvorfor man kunne tænkes at fravige disse processer. Det er nogle gode overvejelser, der sætter mine tanker på to spor.

1) De mest interessante begrundelser i artiklen, er efter min mening ikke mangel på ressourcer. Mere relevant tror jeg det er, at se på det bevidste valg (som også kan være på baggrund af mangel på ressourcer) eller at se på den manglende erfaring.  Jeg tror dog at det i endnu højere grad handler om det ubevidste valg (som trods alt også er en slags mangel på erfaring), et ubevidst valg der (ikke) fortages, fordi der ikke er forståelse for hvilken betydning processerne har og hvorfor den kvalitet der kommer ud af det er vigtig.

2) Og netop kvalitet synes jeg er et meget interessant begreb. Usability er en kvalitetsegenskab, men kvalitet er en svær og underlig størrelse. Jeg ved meget om usability som kvalitet, men ikke så meget om kvalitet som grundlæggende idé. Men umiddelbart tænker jeg at kvalitet er svært, fordi det er en samlet, tværgående størrelse, noget der både ligger hos den enkelte, men som også opstår af helheden. Det er noget der ikke opstår af sig selv, men som skal passes (selvom alt har en kvalitet). Det skal passes fra start til slut (og også bagefter..), med evaluering og justering undervejs. Det handler om styring, om motivation og alt muligt andet.

Så overordnet mener jeg vi skal lære at forstå kvaliteten. Vi skal forstå hvad den koster og hvad den er værd. Vi skal forstå hvordan den passes igennem en række processer og hvordan den enkelte bidrager til det.

OLe

Tags:, , , , ,
Posted in Usability | Comments Closed

Sig CISU-R til dit Projekt-ür (bedre titel søges…)

onsdag, maj 20th, 2009

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

Tags:, , , , , , ,
Posted in Usability | Comments Closed

Ressourcer omkring usability-kriterier

fredag, februar 20th, 2009

To ressourcer som jeg gerne vil henvise til:

1) UXmatters.com – Har spalten AskUX, hvor man kan stille nogle UX-specialister spørgsmål om hvad-som-helst indenfor faget. Jeg spurgte hvordan jeg kommer igang med at skrive metriske og målbare ikke-funktionelle kvalitetskrav til usability, for det produkt til sociale ydelser, som jeg arbejder på til dagligt. Svaret er meget fornuftigt.

2) I det svar kan man finde link til NIST, hvor der kan hentes en rapport om Common Industry Specification for Usability–Requirements(CISU-R). Dem har jeg ikke kigget grundigere på endnu, men titlen ser absolut lovende ud.

Ok, tænker du, det har ikke så meget med web at gøre (for langt de fleste arbejder da alligevel med web nuomdags), men det har det så alligevel. Nemlig den relevans, at alt for mange, ikke har nogle retning i deres arbejde med usability. Retning i form at klare visioner, strategier eller blot nogle konkrete mål, som kan opnås igennem et undersøgelsesdesign og som skaber værdi i forhold til virksomhedens forretningsmål. Så man kan sikkert skæve til hvordan det gøres indenfor software-udvikling og så tilpasse til web-brug.

Det foreslår jeg, fordi jeg kan høre web-folket slå sig i tøjret, når de ser hårde, metriske, målbare krav beskrevet, som de kan være beskrevet i nogle kravspecifikationer. Det kan blandt andet være, fordi webfolkets arbejdsproces, er langt mere konstant eller vedvarende, men jeg har alligevel fornemmelsen af, at der ofte mangler lidt retning og fokus i arbejdet med fx usability i det miljø.

Den største udfordring har vi dog alle til fælles. Det er et stort og svært stykke arbejde at gennemføre analyse og design af sådanne usability-krav og at sikre deres konkrete brug. Men ligesom alt andet i den sammenhæng, så er det et valg man har, hvis man vil opnå en bestemt kvalitet. De fleste vælger det fra, fordi de ikke har kompetencen, opbakningen eller ressourcerne, men så er deres (og mine) trængsler, til dels selvforskyldt.

Jeg hører gerne fra erfaringer på det område.

Olpu.

Tags:, , , ,
Posted in Usability | 1 Comment »

At spise sin egen medicin

tirsdag, december 9th, 2008

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

Tags:, , , , , , , , ,
Posted in Usability | Comments Closed

Google’s Usability Varefakta

tirsdag, oktober 7th, 2008

I relation til mine tidligere poster om usability-kriterier, glæder det mig at opdage at Google har lavet disse Google User Experience aspirations: http://www.google.com/intl/en/corporate/ux.html

Der er flere grunde til at det er interessant: For det første er det helt rigtigt at Google sådan officielt definerer user experience, så alle kan se det (andre har nok gjort det før dem, men alligevel). Det sender signaler af flere slags, især til omverdenen, men reelt også indadtil. Et signal der siger: Kære medarbejdere, det her er hvad vi står for. Og siger: Kære omverden, det her er hvad I kan forvente. Og i særlig grad siger: Kære konkurrenter, det her er vores udgangspunkt, det er her vi vil være bedst.

Min holdning er at alle virksomheder på samme måde burde fremsætte sådanne aspirationer, sådan at medarbejdere, ledelse og konkurrenter kan se hvad niveauet er. Ligesom HR-afdelingen typisk har travlt med at lave værdier for medarbejderne, så er det her noget lignende for user experience.

Jeg har tidligere præsenteret forskellige usability-kriterier: Let at lære, fejltolerant, effektivt osv, som jeg mener kan danne udgangspunkt for en usability målsætning for en organisation.

Google laver også kriterier, når de siger at de vil lave:

[ designs that are useful, fast, simple, engaging, innovative, universal, profitable, beautiful, trustworthy, and personable. ]

De enkelte kriterier bliver så uddybet, med en overskrift (Fast = Every millisecond counts – hvilket nærmest er målbart), og en beskrivende tekst. Som en heuristik kunne man sige.
Man kan ikke direkte aflæse hvordan Google sikrer at disse målsætninger opretholdes, selvom de kommer med anvisninger som: “Our products ask for feedback, and Google acts on that feedback.”

Vi ved ikke hvordan og hvor meget, men vi kan håbe at Google har styr på det. Hvis man selv laver sådanne kriterier, så anbefaler jeg trods alt at man gør det færdigt og klistrer nogle processer, metoder og ressourcer på. Ellers er det bare varmt luft – hvilket det godt kan være fra Google’s side.

Der udover har Google deres 10 Things filosofi, der starter med:

Ten things Google has found to be true:
1. Focus on the user and all else will follow.

Det lækre er, at det er noget de siger er baseret på erfaring. Det er da glædeligt.

Det inspirerer mig – om ikke andet. Jeg vil begynde at lede efter andre virksomheders kriterier, det ikke noget jeg har gjort før, men mon ikke det også findes for andre store virksomheder. Det kan være der kan siges noget generelt her…

OLe

Tags:, , , , ,
Posted in Usability | Comments Closed

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

torsdag, september 18th, 2008

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

Tags:, ,
Posted in Usability | Comments Closed