Nu har SAP oppet sig og tilbyder en ny browserbaseret og meget website-agtig brugergrænseflade. Det bliver den ikke nødvendigvis mere brugervenlig af, selvom SAP ynder at kalde den “intuitiv” (hvilket virkeligt er et definitions-spørgsmål). Uanset, så ville denne kollega gerne se giraffen. Så vi kiggede lidt på den:

Så vi (du og jeg) skal huske dette mantra: “Brugen, den skal kvalificeres af brugerne!”

Det er sket at folk har brokket sig (!) og sagt: “Skal vi nu ikke holde op med at pege fingre og finde problemer”. Svaret er umiddelbart nej, men vi skal til gengæld også huske at påpege de gode ting. De positive oplevelser. Her er to små interaktions-slagser af den slags:

TDC's lille formular til feedback nederst på siden

Den første er den lille formular, hvor man på TDC’s hjemmeside, kan give den aktuelle side lidt feedback med på vejen. Jeg synes den er overskueligt lavet og sender et signal om at TDC arbejder på flytte support-opgaver fra deres telefoner over på deres hjemmeside. Det koncept kunne man sagtens udvise til at indeholde andre spørgsmål. (Selvom man i princippet ikke kan besvare det nederste spørgsmål med et klik).

Nummer to, er denne lille applikation i applikationen på Google Analytics. Jeg glæder mig over de mange muligheder der efterhånden er, for at lave funktionalitet/interaktion/design på nettet:

Periodevælger i Google Analytics (klik for at se billede i 100%)

Den slags positive interaktive oplevelser, gør en mand som mig glad. Jeg tror mit næste job skal være indenfor web-applikationer

Afslutningvis skal jeg lige have den her med. Ventetiden visualialiseret på Telia Erhvervs side. Da jeg skulle ringe, var kl. 12 – hvilket ikek ser så godt ud. Interessant service, som jeg fik gavn af (men jeg ringede alligevel ):

Ventetiden visualiseret på Telia.dk (klik på billede for 100% størrelse)

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