Archive for oktober, 2008

Du kan noget Google ikke kan

fredag, oktober 24th, 2008

Ved UX Intensive, et arrangement afholdt af Adaptive Path i København, hørte jeg en interessant pointe, som ændrede min opfattelse af nogle ting. Lad mig starte et andet sted. Se, Steve Krug, der jo nærmest er blevet berømt for at skrive bogen “Don’t make me think”, har beskrevet sin ‘Trunk test’, en simpel test der sikrer at udvalgte informations-arkitektur-elementer er til stede i et hjemmeside-design. I bogen, og i testen, anbefaler han at der skal være et enkelt, overordnet søgefelt, der altid bør sidde i øverste (højre) del af hver side. Så man altid kan finde søgefeltet og skifte strategi fra navigation til søgning. Udemærket pointe. Et problem med søgninger er dog at de ofte fungerer skidt. Af flere grunde. Enten er den motor der driver søgningen ikke god nok, eller den er ikke konfigureret ordentligt. En anden mulighed er at indolholdet ikke er meta-beskrevet godt nok, sådan at søgemaskinen reelt ikke kan finde indholdet.

Men en mere interessant ændring, siden Krug skrev sin bog, er også at mange brugere har vænnet sig til at bruge (primært) Google til deres generelle søgninger. At man altså vender sig mod Google, i stedet for at bruge den integrerede søgning. Nogle steder bruger folk en integreret Google søgning, så det kan måske opfattes som en mellemvare.

Uanset, så efterlader det en integrerede søgning i et dilemma. Nemlig at den ikke er ligeså god som Google og derfor opleves som dårlig eller utilstrækkelig. Men det betyder også at det måske er tid til at se på den integrerede søgning i et andet lys. Efterhånden som informationsarkitekter, webmastere og lignende informationsmedarbejdere der skriver til en hjemmeside, bliver dygtigere til at arbejde med information som produkter – altså lærer at lave meta-information, styrede vokabularier og lignende systematisk håndterering af information – så opstår der også nye muligheder for den integrerede søgning.

Den bliver nemlig specialiseret, noget Google søgningen ikke er – tværtimod. Den specialiserede, domænespecifikke, tilpassede, avancerede og altså også integrerede søgning, er unik for det enkelte website. Derfor bør den også håndteres på den måde – og ikke som et ekstra Google-felt der giver søgning på hvad-som-helst. Den er netop ikke søgning på hvad-som-helst.

Derfor opstår der gammelkendte begreber som facetteret-søgning, som er en slags hierarkisk taxonomi, med flere sidestillede startpunkter – nemlig facetter – som giver en styret indgang til siden informationer. Det kunne også være den gammelkendte “avancerede” søgning, med mulighed for at søge i bestemte emne-grupper eller andre opdelinger.

Så det var den pointe jeg fik præsenteret, ved det ellers lidt ligegyldige arrangemente fra Adaptive Path. Ligegyldigt – i hvert fald den dag med informationsarkitektur – fordi det igen bare var en gennemgang af noget vi kan læse i en bog. Men det tyder nok på at denne fagområde stadig er lidt nyt for mange i web-branchen og at det indeholder en dybde, der langsomt lukker op for nye erkendelser og nye muligheder, så har en styrke mange endnu ikke har fået opdaget.

Men brugerne opdager det. De opdager at Google kan bedre, nu skal vi så lære dem at vi kan noget Google ikke kan.

Ol-urt

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

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

Provo vs. provo

torsdag, oktober 2nd, 2008

Idag indtraf en situation ,der med et lærte mig noget nyt om usability og mig selv, på hele tre måder: Personligt, praktisk og metodisk.

Se, jeg havde lavet en variation over en persona og givet den en teknisk betegnelse, som jeg havde afluret hos nogle udviklere. Vores persona hedder normalt Ellen, men jeg havde i stedet skrevet: “Mød ZARB_CASEMAT”. Det sidste er det tekniske navn på rollen i det CRM vi bruger. Jeg følte et behov for at beskrive nogle af de ting som brugerne er frustrerede over i de standardopsætninger der findes af dette CRM. Så under titlen stod fx. at ZARB_CASEMAT “Kun arbejder med tid i timer og minutter, hun forstår ikke hvad kl. 10,72 er” – eller at “Hun interesserer sig ikke for ID numre som 6000000354, men i stedet for CPR-numre”. Begge beskrivelser, dækker funktionalitet der er typiske for dette CRM, hvor tid skal omregnes og hvor alle objekter har et langt ligegyldigt systemisk ID-nummer.

Jeg viste denne visualisering til min nærmeste leder. Hun mente den var provokerende, hvilken hun sagde sådan lidt lavmælt. Det kan jeg som sådan godt følge, jeg havde grint i skægget over indholdet. Det var lavet for at sætte tingene lidt på spidsen, men ikke desto mindre er det empirisk korrekte antagelser. Det ved jeg, fordi jeg har spurgt brugerne.

Men da hun sagde det, fik jeg tre interessante tanker:

1) En slags skam, over at have provokeret nogen, måske ennda uretmæssigt. Jeg fik lyst til at sige undskyld og forestillede mig straks, at nogle ville blive oprigtigt sure. Det var den personlige, følelsemæssige respons. Den er så nu, mindre relevant og interessant.

2) Et modsvar i mig der sagde: Ja, det er skam også meningen. Vi skal provokere hinanden til at “tænke ud af boksen” (som det hedder når det er helt moderne og røv-irriterende, men hvor vi ikke kan sætte ord på det). Vi skal rykke ved hinanden og ændre på de ting vi gør dårligt. Det er en vigtig funktion at kunne provokere, eller i det mindste at udfordre. Hvorfor skal udviklerne på projektet ikke have det råt for usødet: Vores brugere forstår simpelthen ikke de ting I leverer, lær det og lav det om næste gang. Hold op med at lave midlertidige løsninger med ID-numre og beregninger, begyndt at tænke helhedsorienteret og brugs-relateret. I er fortidslævn fra IT-stenalderen når I opfører jer sådan.

3) Og måske mest interessant. Så det er mig der provokerer? Næ, hov. Vent lige en gang. Jeg bliver jo dagligt provokeret af de ting der kommer fra denne standard CRM løsning. Provokeret over hvor menneskefjendsk IT kan laves stadigvæk. Provokeret over, at det er mig der evig og altid skal råbe op og gøre opmærksom på at de ting skal ændres eller helt fjernes – jeg skal endda begrunde det!

Her kan jeg synge min gamle traver om, at det altid er usabilityfolket der skal prædike, skal være bannerførere, skal hænge ting op og skabe dialog, skal visualisere. Jeg plejer at sige: Vis mig den virksomhed hvor udviklerne mødes og diskuterer hvordan de kan tilpasse deres metoder, så det er lettere for usabilitykompetencer at bidrage til deres processer. Hvor de arbejder metodisk på at finde en måde at inddrage usability i deres arbejde. Vis mig en lærebog om udvikling eller et programmeringssprog, der starter med to kapitler om hvilke udfordringer der er, ved at kommunikere med alle de humanistiske kompetencer med deres kvalitative beskrivelser. Vis mig det!

Men ingen har ondt af lille mig. Ingen bekymrer sig om ham der “UI-manden”, der blot vil sikre at de endelige brugere kan forstå, hvad helvede der står på skærmen. Det må han selv klare, men han skal ikke komme og provokere os i vores hellige haller. ID numre er vigtige i vores arbejde og de skal være lange, så vi kan mange af dem og de skal blande bogstaver og tal godt og grundigt, så man aldrig nogensinde kan skille dem fra hinanden, selvom de aldrig er ens.

Så det var, på mange måder, en god og brugbar provokation. Og heldigvis fik jeg flere email-svar fra udviklerne, der faktisk tog det med et smil og godt forstod hentydningen.

ZARB_CASEMAT lever og har det godt med hendes provokerende rolle. Men hun giver ikke op. Hun forstår ikke hvorfor hun skal regne ting i hovedet, når hun sidder foran en kæmpe regnemaskine. Hun forstår stadigvæk ikke hvorfor ting er blevet lavet til objekter og hvorfor tre sammenhængende objekter på samme tid kan have statusser, der hedder henholdvis “Opstået”, “frigivet” og “afsluttet”. Det gør jeg heller ikke. Og det provokerer mig. Så jeg prøver blot at sende aben videre…

Så nemt skal ‘de’ ikke slippe :-)

Olhan