Legg ikke ut på langtur uten trening. Du bør heller ikke kjøre din første brukertest uten å trene på forhånd. Foto: CC Flickr by tricky

Fjellvettreglene sier at du ikke skal legge ut på langtur uten trening. Slik er det også med brukertesting. Likevel må en gang være den første. Et godt tips er å begynne i det små og lære mens du går. Høyest læringskurve og best resultat får du ved å kjøre de første rundene ved hjelp av eller sammen med erfarne folk.

Du jobber kanskje på et sted der det ikke er tradisjon for å kjøre brukertester? Det er mest sannsynlig at det blir noe av hvis du gjør det selv eller i det minste sørger for å sette brukertesting på planen.

Brukertestvettreglene:

1. Kjør ikke brukertester uten trening

2. Planlegg testen grundig

3. Vis respekt for brukerne

4. Ha en plan B i tilfelle systemet du skal teste på ikke fungerer

5. Lytt til erfarne folk – be noen som har kjørt brukertester før om å være veileder for deg.

6. Skaff det utstyret du trenger for å gjennomføre testen

7. Litt testing er bedre enn ingen testing

8. Det er ingen skam å snu – vær villig til å innse at konseptet er helt feil for brukerne

9. Ta initativ – vent ikke til noen andre setter brukertester på prosjektplanen

Setter du i gang med brukertesting uten de nødvendige forberedelsene og forkunnskapene blir du brukertesterens svar på Severin Suveren. Ikke forvent å bli verdensmester første gang.

Har du flere tips til folk som vil begynne med brukertesting? Skriv gjerne en kommentar.

Relaterte artikler
Slik planlegger du en brukertest
Slik får du skikk på observatørene
5 tips for brukertesting av innhold
Hvordan lære bort interaksjonsdesign til 50 ungdommer på en halv dag
Få mer ut av brukertesting med barnepsykologi

Bildet er lisensiert med Creative Commons og er hentet fra Flickr: Hiking av tricky

Under Yggdrasil 2009 møttes fagfolk fra næringsliv/forvaltning og representanter fra utdanningsinstitusjonene for sammen å finne ut hva som bør kreves av morgendagens interaksjonsdesignere, informasjonsarkitekter og brukervennlighetseksperter. Sammen fant vi ut hvilke egenskaper den perfekte interaksjonsdesigner bør besitte.

Bakgrunnen for workshopen

Det er i dag en rekke forskjellige utdanningsinstitusjoner i Norge som gir utdannelser innen disse områdene. Det er viktig at disse utdannelsene til enhver tid er målrettet i forhold til det konkrete behov for kompetanse som finnes i norsk næringsliv og forvaltning. For å kunne gjøre utdannelsene oppdaterte og relevante, så er det nødvendig med kontinuerlig tilbakemelding på studietilbudene fra studentenes framtidige arbeidsgivere. Dag Svanæs og Ole Andreas Alsos inviterte derfor erfarne personer fra næringsliv og forvaltning til å gi sine anbefalinger om hva norske utdanningsinstitusjoner bør undervise sine studenter i framtiden. Til å lytte ble sentrale undervisere fra norske utdanningsinstitusjoner invitert.

Et av flere viktige bidrag som kom frem i denne debatten var egenskapene til den perfekte interaksjonsdesigner, informasjonsarkitekt og brukervennlighetsekspert.

Med bidrag fra blant annet Thor Fredrik Eie og Jostein Magnussen (Netlife Research) (se bildet øverst) beskrev workshopdeltakerne den perfekte kollega slik:

• De brenner for brukervennlighet: De har et stort bankende hjerte for brukervennlighet og et høyt nivå av usabilityhormon i kroppen. Det er en egenskap som kan være vanskelig å lære, men likevel svært viktig for en interaksjonsdesigner.
• De kan tegne: Den perfekte kollega behersker kunsten å skisse på papir. De tør å bruke penn, og tør å skrible litt på arket for å utforske løsninger. De trenger ikke være noen picasso (det trenger ikke være pent) men det er viktig å være trygg med penn og papir. Interaksjonsdesign er et håndverk og en interaksjonsdesigner må ha det i fingrene.
• De kan blogge: En interaksjonsdesigner bør vite hva en publiseringsløsning er. De må ha kjennskap til det som fines av kommersielle verktøy som brukes av norske bedrifter (for eksempel WordPress, EPIserver). Det er også en fordel å ha sett baksiden av et publiseringssystem.
• De kan presentere: De har holdt presentasjoner og er komfortabel med snakke foran folk. De er flinke å få fram et budskap (som konsulent gjør du det hele dagen) og powerpoint er deres beste venn.
• De kan konseptutvikling: De forstår viktigheten av prototyping og konseptutvikling. De har laget noe som har vært testet.
• De kan brukeranalyse: Knut Rolland (Avenir) mener at de må ha en stor verktøykasse med et bredt spekter av metoder for å innhente kunnskap om brukerne og deres behov, samt foretningsprosessene i organisasjonen . Det gjelder ikke bare klassiske metoder som brukertester og intervju, men de har vært ute å gjort observasjoner og etnografiske studier. De forstår også hva de ulike metodene ikke fanger, deres styrker og svakheter.
• De kan planlegge og kjøre brukertester: De kjenner brukertestingsmetoden i detalj og har vært med å planlegge, gjennomføre og analysere brukertester.
• De kan grunnleggende programmering: De kan grunnleggende HTML, CSS og Flash. De trenger ikke være noen topprogrammerer, men må kunne se på kode som noe mer meningsfullt enn en tilfeldig samling tegn og mellomrom.
• De er kreative: De er meget kreative – innen de rammer som prosjektet, teknologien eller organisasjonen setter.
• De har erfaring fra næringslivet: De har vært ute i den virkelige verden og har blitt “skitten på fingrene” gjennom sommerjobber eller ”internships” ute i bedrifter. Masteroppgaver og tilsvarende er forankret i reelle prosjekter – ikke dype, smale og teoretiske tema.
• De kan samarbeide: Ram Yoga (Steria) mener at de må kunne samarbeide med alle i prosjektorganisasjonen, særlig med utviklere.
• De kan selge inn brukervennlighet: Interaksjonsdesignere må være flinke til å synliggjøre sitt eget behov. Bjørn Tennøe (Fast) trekker frem viktigheten av å kunne selge seg selv. Han peker på at den norske industrien i stor grad produserer råstoff og er ikke trent til å kjøpe designekspertise. Industrien trenger utdanning i hvorfor de trenger interasjonsdesignere og hvordan de kan bruke dem. Ram Yoga (Steria) mener at interaksjonsdesignere må tenne en brukervennlighetsgnist hos utviklerne – de må evangelisere fagområdet. Dessuten må interaksjonsdesign komme som en naturlig del av utviklernes utdannelse.
• De har spisskompetanse på brukervennlighet: Gautam Ghosh (Skatteetaten) peker på at interaksjonsdesignere må være “spisse”. De oppfattes ofte som generalister som kan brukes over alt. Det kan fort undergrave deres stilling og deres entusiasme når de ikke får brukt deres kompetanse annet enn når det er rom for det. Det er alltid rom i starten av et prosjekt, så fjernes behovet på grunn av ressursmangler. Det kan være frustrerende for mange og de gir opp å sloss. Gautam ønsker seg sterkere profesjonalisering og sterkere synliggjøring av kunnskapen
• De er generalister: Knut Rolland mener på en annen side at de må ikke være for smale, da graver man sin egen grav. Man må være generalister. Trude Hole (Bouvet) peker på at industrien ansetter generalister, de vil ha ”poteter” som kan brukes til alt og tør ikke ansette ”spesialverktøy” som interaksjonsdesignere.
• De er ikke redd for teknologi: Knut Rolland mener at mange er redd for å ta i teknologi. Det skaper et kunstig skille; interaksjonsdesigneren overleverer sitt arbeid til utvikleren  og sier ”vær så god, nå kan du starte kodingen”, for deretter å nekte all nærkontakt med utvikleren og teknologien.

Men sukk - å ha en slik interaksjonsdesigner med på laget vil være en drøm for de fleste organisasjoner og bedrifter. Dessverre finnes det alt for få slike personer. Høyskoler og universiteter bør derfor ta disse ønskene inn over seg når de planlegger studieløp.

I forbindelse med en studiereise til Stanford University og Silicon Valley deltok jeg på en konferanse ved forskningssenteret til IBM i Almaden, San Jose, CA. Her hadde de en orginal og brukervennlig løsning på problemet: En trådløs mikrofon var satt inn i en lett og myk tøyball. Arrangøren kastet denne raskt til den som ønsket å stille spørsmål til foredragsholderen. Når hun var ferdig, kastet hun den videre til nestemann som hadde noe på hjertet.

Med mikrofonballen ble spørsmålsrunden aldri skjemmet av langvarige spørsmålssesjoner – på et øyeblikk hadde alle som ville fått stilt spørsmål til foredragsholderen.

1. Lær deg stammespråket. Smidige metoder inneholder begreper, artefakter og seremonier som du bør sette deg inn i
Skal du inn i et smidigprosjekt, må du forstå begrepene som brukes og finne de foraene som gjør at du får formidlet designforslag og endringer. Du vil nok kjenne igjen problemstillingene som oppstår, men de kommer gjerne i en annen rekkefølge og heter andre ting enn det du er vant til.

 
2. Bli med på de seremoniene som er nyttig for ditt arbeid og for teamfølelsen
“Du står midt i standup-en vår”, fikk jeg beskjed om en av de første dagene i prosjektet. Seremonier som ståoppmøter, scrum of scrums og retrospektiver er en del av arbeidshverdagen for medarbeidere i et smidigprosjekt. Om du skal delta på alt, får du ikke gjort stort annet, særlig hvis du skal jobbe for flere team samtidig. Her er det nyttig å prøve seg frem, slik at du får med deg det som skjer, uten at du trenger å overhøre alle tekniske eller forretningsmessige avveininger som gjøres underveis. Det er viktig at designere er med på diskusjoner rundt produktkøen for å få frem gui-relaterte oppgaver. Hvis du har en dedikert plass i et av teamene, kan det være greit å følge seremoniene til det teamet, slik at du føler at du er ordentlig med. Det er aldri gøy å føle seg utenfor.
 
3. Tolk brukerhistorier ved å tegne ut skjermbilder
I smidigprosjekter er kravene til systemet utformet som brukerhistorier. Brukerhistoriene er korte og inneholder en begrunnelse for hvorfor kravet skal gjennomføres. I foredraget GUI-prototyper er Gode på Smidig2008  snakket jeg om at enhver tekstlig beskrivelse kan tolkes på mange forskjellige måter. Det er en stor fordel å tegne ut brukerhistoriene i form av skjermbilder som kan brukes i kommunikasjon med både utviklere og forretningssiden. Skjermbildene kan også synliggjøre behovet for nye brukerhistorier som må til for å få ting til å henge sammen.

4. Lær deg å formulere nye brukerhistorier
De første gangene jeg viste nye skjermbilder fikk jeg stadig høre: “men, det er en annen brukerhistorie”. “Javel”, tenkte jeg, ”da får jeg skrive en ny historie.”
Brukerhistoriene har en enkel form, og det er lett å lære seg å skrive nye
Eksempel på mal:
Som en <bruker>
ønsker jeg <funksjon>
 slik at <verdi>
Brukerhistoriene legges inn i en produktkø som brukes til å prioritere oppgavene. Det er produkteier på forretningssiden som prioriterer, så her gjelder det å bruke sin påvirkningskraft.

5. Heng oppdaterte skjermbildeskisser opp på veggen
Fra jeg hang de første skissene opp på veggen til utviklere og arkitekter uoppfordret stod rundt dem å diskuterte GUI tok det under fem minutter. Skjermbildeskisser som blir liggende på en filserver kommuniserer ikke så bra. Det gjør heller ikke designforslag som kun finnes inne i ditt hode. Det er noe med å få skissene opp på veggen, se sammenhenger mellom dem og tegne endringsforslag rett på papiret som gir en stor ekstraverdi.

6. Utnevn en “stylist” i hvert utviklingsteam som har ansvar for GUI og stilark
Det er fornuftig at noen holder orden i stilarket og sørger for å formidle GUI-ting videre til resten av teamet. Hvis prosjektet er stort, er det viktig at dette ansvaret ikke ligger på en person alene, men at alle teamene som jobber med GUI har minst én person som kjenner stilarket og GUI-komponentene spesielt godt.

7. Bedre kommunikasjon ved avholde ståoppmøter for designere og stylister 1-2 ganger i uken
Ståoppmøter er godt egnet for kjappe avklaringer og statusoppdateringer. Å avholde ståoppmøter for alle som jobber med GUI-relaterte oppgaver, gjør informasjonsflyten bedre.
 
8. Kjør brukertester
Smidig gir deg ingen unnskyldninger for å la være.

9. Lag GUI-retningslinjer i form av sjekklister underveis
Ved å utforme GUI-retningslinjer som en sjekkliste, er det lettere å bruke denne til gjennomgang av (nesten) ferdigutviklede skjermbilder. Å få utviklere og testere til å pugge retningslinjene kan være en utfordring. Vi arrangerte kurs med quiz. Husk premier!
 
10. Sørg for at GUI-retningslinjene blir en del av Definition of Done
I store prosjekter er det ofte vanskelig å få til et konsistent grensesnitt. Smidigprosjekter er intet unntak. “Definition of Done” er en sjekkliste som brukes til å definere hva som skal til for at en utviklingsoppgave skal kunne sees på som ferdig. Som designer kan du sørge for at GUI-retningslinjene blir en del av denne definisjonen.

Tipsene er basert på arbeid i et stort smidigprosjekt med totalt 11  utviklingsteam og 3-4 dedikerte Gui-ressurser. Tusen takk til mine kolleger Ram, Johannes og Trond for verdifulle innspill til innlegget. Har du andre tips, råd eller andre erfaringer du ønsker å dele? Skriv gjerne en kommentar.

Lær mer:
Tre modeller for organisering av designere  i smidige prosjekter
3-minutters guide: Dette er Scrum (pdf)

Da jeg for første gang skulle logge meg på nettbanken med kodekalkulatoren (og ved flere senere anledninger) fikk jeg feilmelding om at jeg hadde tastet feil sikkerhetskode hele tiden. Igjen tastet jeg inn koden sakte, tall for tall, for deretter å få sleng feilmeldingen i ansiktet gang på gang. Hva var galt? Etter 7-8 forsøk, rett før jeg ringte support, prøvde jeg å snu kodekalkulatoren å taste inn nummeret som åpenbarte seg når man leste tallene opp ned. Noen sekunder åpenbarte både saldo og disponibelt seg på skjermen foran meg.

På bildet til venstre ser dere feil bruk av kodekalkulatoren. Taster du inn koden som viser seg kommer du ikke inn i nettbanken. Til høyre ser dere riktig bruk av kalkulatoren. Men hvordan i all verden kan man vite det?

Med en så enkel dings med en knapp og en funksjon skal det i utgangspunktet være umulig å gjøre feil. Men designerne av kodekalkulatoren har gjort to åpenbare feil.

• Venstrejusterte tall: Bryter designkonvensjon om høyrejusterte tall
• Symmetrisk design: Ingen tydelig indikasjon på hva som er opp og ned.

Når en tallkombinasjon med tallene 0, 1, 2, 5, 6, 8 eller 9 vises på skjermen gir de mening også opp ned. Nummerrekken 025689 blir for eksempel 689250 opp ned. I tillegg kan tallene for nybegynnere lett tolkes som bokstaver hvis man leser dem opp ned (f.eks. 7 = L, 4 = h, 3 = E og 0 = O). Sikkerhetskoden 033874 kan tolkes som hL8EEO.
Løsningen er enkel: Indiker hva som er opp på kodekalkulatoren.
Og ikke minst: Test enhver løsning på brukere før de rulles ut.

Har du noen gang ønsket å finne en lang bok som er ganske nydelig, men samtid relativ jordnær? Eller hva med en bok som har en hovedperson mellom 30 og 50 der handlingen foregår i Afrika? Nettbokhandler og bibliotekskataloger lar deg søke på genre, forfattere og tittel, men det er vanskeligere å finne bøker som tilfredsstiller kriteriene ovenfor.

Målet for nettstedene www.onskebok.no og den engelske versjonen www.whichbook.net er å øke leseglede. Ved å lete frem bøker etter sinnsstemning eller hva slags handling du ønsker, kan du ende opp med helt andre bøker enn dem du normalt ville falt for i en bokhandel eller på biblioteket. Når du har funnet en bok, kan du trykke på ”lån” for å finne ut om boken er finnes på et bibliotek i nærheten av deg.  

Nettstedene er universelt uformet og kan også brukes med leselist av bilde eller svaksynte på utkikk etter lydbøker. Tidligere har eneste var eneste mulighet for denne gruppen å spørre en bibliotekar eller lese sammendrag av forskjellige bøker.

Fasettert søk regnes vanligvis som en god og brukervennlig måte å presentere innhold i en søkedatabase på. I dette tilfellet synes jeg det gir en god brukeropplevelse å søke seg frem til et resultat, uten å vite på forhånd hvilke kategorier og kombinasjoner som gir flest treff. I følge de som driver siden, ser de fleste på de øverste treffene, men det er kanskje ikke så rart med den utformingen av scrollbarene som er valgt.

For å unngå at du ikke får treff når du søker, kan du søke på maks tre kriterier om gangen på i den norske varianten og fire i den engelske. Den norske siden inneholder ca 1700 bøker, hovedsakelig utgitt etter 2001, mens den engelske inneholder 3000. Dette kan synes som et lave tall med tanke på hvor mange bøker som finnes totalt, men det er nok flere enn du kommer igjennom i løpet av sommeren uansett. Er du leseglad, er det vel verd å ta en titt.

Ofte seg jeg nettsider som har enten tomme sider (…Her kommer snart innhold om våre produkter og tjenester…) eller sider som har fylt to menynivåer med bare svada – fordi man har valgt minste motstands vei når IT har installert nytt CMS system og gått for en innholdsstrategi basert på forslaget fra leverandøren. Jeg kaller det ”mal-syken” når malen får diktere informasjonsarkitekturen.

Som regel tilbyr CMS systemer to menynivåer, en toppnivå meny øverst på siden, med tilhørende undermeny som ofte finnes på venstre side. Det kan se slik ut:

Figur 1

Forsiden er som oftest lik alle andre sidemaler. Hva skal man så fylle forsiden med? Istedenfor å pumpe ut meningsløse nyheter (som CMS-systemer er gode til) kan man fylle forsiden med noe spennende. Men hva er spennende for kundene dine? Hvis du har et søkefelt på din side er du heldig, da finner du svaret i søkeloggen. Søkefrasene i loggen inneholder ord som forsiden din bør inneholde. Har du ikke tilgang på søkeloggen kan du for eksempel ta for deg ulike målgrupper for nettsidene dine. Så må du prioritere hvilke målgrupper som er viktigst for deg, deretter kan du analysere hvilke oppgaver de vil ha svar på når de besøker dine sider.

For en nettbutikk er sannsynligvis konkrete navn på produkter en fin plass å starte. Ikke vær fristet til å kategorisere. Selger du TV’er eller ”lyd & bilde”? Sannsynligheten er stor for at brukere som ser ordet TV forstår at du også selger scartkabler og videokameraer, men det er ikke sikkert de ville ha forstått det samme dersom du hadde fokusert på kategorien ”lyd & bilde”. Ikke ta mitt ord på det, men spør 5 personer om hva de mener “lyd & bilde” vil si.

Så hva gjør man? Du kan jo f.eks. våge å være annerledes.

Det er ingen grunn til at forsiden din behøver å inneholde særlig mer enn det her:

Figur 2

Når man ser på produkter kan den tradisjonelle modellen med nivå 1 på toppen og undermenyer på venstre side være et godt alternativ:

Figur 3

Ett av de mest populære publiseringsverktøyene er Microsoft Sharepoint. Vil du vite mer om skreddersøm av publiseringsverktøy og hvordan du kan sette sharepoint på plass til å jobbe for deg og ikke omvendt bør du ta en titt på Eli Toftøy Andersens foredrag på Yggdrasilkonferansen i Oktober. Det vil også være en workshop om venstremeny er gammeldags, og flere foredrag om publiseringsløsninger.

En av arrangørene, Netlife Research skrev “live” på sin blogg on utvalgte foredrag og har fylt på med flere referat etter konferansens slutt. Tenketing.net har beskrevet fenomenet live-blogging.

Liveblogging forekom også på kuttisme.no, hvor b.l.a. ansatte hos webdagene-arrangør IXD blogger.

Ett av de mer profilerte foredragene var Øivind Solstad fra NRK Beta. Slides fra foredraget finnes her, og referat her.

Ellers er det verdt å nevne Digi.no som har referater fra flere av foredragene, b.l.a. mitt eget FINN – kjip med vilje.

Bilder fra konferansen finnes på Flickr

Her er slides fra mitt foredrag på Webdagene 2008. Et flott referat fra fordraget finnes på I all enkelhet. Flott med så mange oppmøtte og så mye engasjerte spørsmål. om det er andre ting folk lurer på kan de kommentere her.