Posts Tagged ‘SAP’

Husk dit mantra: “Det skal brugerne kvalificere”

tirsdag, november 17th, 2009

Idag præsenterede jeg en ny brugergrænseflade for en kollega. Det var SAP CRM Webclient UI. Til forhistorien hører, at vi over frokostbordet havde talt om hvor forfærdelig brugergrænsefladen er i de ældre SAP systemer. Blandt andet det der hedder SAP GUI og som jeg roligt kan karakterisere som menneskefjendsk.

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:

sap_crm_eksempel
Eksempel på SAP CRM Webclient UI – se SapDesignGuild.org for mere onformation.

Her kommer så dette indlægs pointe. Kollegaen siger: Der er ikke meget plads med den brede venstremenu. Jeg siger: Nej, men SAP bruger en website-analogi og derfor kan man scrolle nedad, så der er på mange måder rigeligt med plads. Kollegaen siger: Hmmm, det er ikke godt med det der scroll-noget.

Mit første indskud er: Jamen, det er da ikke noget problem med scroll, din sure udvikler, hvad ved du om det. Men pointen her er ikke om kollegaen har ret eller ej. Det har han muligvis. Pointen er at jeg skulle have svaret: Spørgsmålet er om brugerne kan løse deres arbejdsopgaver effektivt.
Det ved hverken jeg eller kollegaen nemlig ift. til det kommende produkt. Vi har aldrig set vores brugere løse netop deres opgaver i denne nye brugergrænseflade.
Men endnu vigtigere. Vi må aldrig glemme, alt selvom vi eller andre nogengange mener eller føler at noget ikke er optimalt, så ved vi det ikke før vi har fået det kvalificeret. Det er grundlaget for meget af det arbejde jeg laver. Principielt kunne jeg altid sige. Det ved vi når vores brugere har testet det.
Så vi (du og jeg) skal huske dette mantra: “Brugen, den skal kvalificeres af brugerne!”
Det er også det jeg kalder designudfordringen. Den fordrer at vi ikke kan forudsige brugen af vores design og at vores brugere skal kvalificere det.
Det er et løsen og svar på mange diskussioner, som også giver rum for at vi som usability-specialister ikke altid skal kende svaret – og at andre heller ikke kender det.
Svaret ligger i brugen.

Designprincipper

mandag, oktober 13th, 2008

Like love, great design requires no explanation.

Sådan afslutter Microsoft deres mission statement på siden www.microsoft.com/design. En flot men ikke så særligt overskueligt afsnit, hvor det er sævrt at finde helt konkrete beskrivelser af hvad Microsoft gør eller vil.

This is easier said than done.

-Siger Microsoft om hvordan de vil skabe magi og ånd i deres produkter. Ja, det skal nok passe, men I kunne da godt prøve.

I den modsatte ende af skalaen (jeg kommer nok med en skala længere nede i teksten), kan man placere IBM’s beskrivelse af deres designprincipper, som nærmest er nogle heuristikker. De kunne være taget fra en almindelig interface-designbog og har slet ikke det samme højtidelige præg som Googles (se tidligere indlæg), selvom der er en del overlap. Faktisk har IBM lagt hele deres deres beskrivelse af User-centered design på nettet, sådan at beskrivelsen både kan bruges som intern vejledning og som indsigt (læs: Reklame) til omverdenen.

Ok, der er forskel på designprincipper og så på beskrivelser af bruger-centreret design – og så alligevel, nu om dage vil mange gerne sætte lighedstegn mellem de to.

På samme måde som SAP – så fik vi også lige rundet de tre største software-virksomheder i verden. Ikke ikke et dumt sted at starte.  For øvrigt har jeg tidligere skrevet om usability-kriterier og glædeligt er det da også at SAP beskriver deres UDC-proces med:

UCD results in more usable and satisfying systems, making SAP software more effective, efficient, easy to learn, pleasant to use, and predictable

Så kan man til gengæld også høre, at usability-folket i SAP måske også selv kæmper med ledelsens erkendelse eller prioritering af usability:

 - in essence, a high-quality user experience, contributing to high-quality products, and ultimately, more sales, market share, and revenue for SAP.

Man kan bemærke at virksomhedens navn indgår hos SAP, ligesom den gør hos Google, mens IBM’s meget omfattende beskrivelser af design, slet ikke indeholder noget med IBM eller “IBM vil”. (Rettelse: Det gør der faktisk, få steder og det er faktisk spændende, men stadig alt for lidt). Spørgsmålet er om det er implicit eller netop understreger at, det mest er tale om formålserklæringer. På den anden side, hvorfor skrive det, hvis det ikke er noget man selv mener er “rigtigste”.

De fleste virksomheder – særligt når de laver software (ikke-web), tåler faktisk ikke at man graver for meget i hvornår design-principper og UCD-processert reelt er afgørende for prioritering af ressourcer i udviklingsprocessen. I de fleste virksomheder er det andre faktorer der sætter dagsordenen, men det er jo heller ikke usabilityfolk der sidder i alle ledelseslagene.

Uanset, så er der masser af inspiration at hente. Ingen undskyldning her for ikke at have sine egne usability-kriterier, sine egne design-principper og mission statement i den organisation man arbejder i. Man kan sådan set bare låne IBM’s eller SAP’s. De bliver ikke meget bedre. Problemet er mere at implementeret dem. Det er jo også derfor de ligger online for alle at læse. De er ikke noget i sig selv. De skal operationaliseres. Samme banale erfaring gør sig gældende når jeg underviser i usability. Fortæl os ikke hvad en kortsortering er – vis og det og lad os prøve det – det er grundlæggende tilbagemeldingen.

Her får jeg lyst til at skrive om Usability Maturity Model – som netop kigger på hvad “best practice” eller bedste praksis, er. Et godt udtryk, fordi der deri ligger, at det ikke handler om hvad man vil, men hvad man gør.

Den må vi vende tilbage til – den er god at spille spørgsmål med.

Olhe