Husker du de gamle “tykke” applikasjonene vi brukte før? Overraskelse: de finnes enda og nettleseren din er en av dem. Når vi lager nye lettbente webapplikasjoner av de gamle tykke applikasjonene skal disse kjøre inne i en annen tykk applikasjon – nettleseren. De som skal bruke webapplikasjonene vi lager trenger tastaturnavigasjon for å være effektive og unngå skader. Men utviklingen går i feil retning: Før mus ble vanlig var alle applikasjoner styrt med tastatur. Nå er vanlige hurtigtaster som “sitter i fingrene” allerede tatt i bruk til nettleserfunksjoner. Og for å gjøre vondt verre har ikke de ulike nettleserne de samme tastekombinasjoner.

Det lar seg løse, men det krever en innsats: Her finner du våre tips til hvordan lage tastaturnavigasjon i webapplikasjoner.

Money talks
Når økonomisjefen og IT direktøren skal kjøpe regnskapsystem som kjører i nettleseren, eller systemarkitekten skal velge rammeverk er det ett argument de hører på: Penger. Presentér et regnestykke som viser kostnadene ved å velge et rammeverk uten full støtte for hurtigtaster som fører til tregt arbeid og i verste fall sykdom og oppsigelse.

Planlegg tastaturnavigasjon fra starten
Støtte for tastaturnavigasjon må være et krav på et så tidlig tidspunkt at rammeverket som velges har full støtte for dette. Brukerhistorier må ta høyde for det, og det må testes med tastatur i utviklingen.

Må det være en nettleser?
Nettlesere har “tatt” alle de beste hurtigtastene. Det gjelder skifte av faner, lagre, skriv ut osv. slik at det som sitter i fingrene fra de tykke applikasjonene ikke lengre kan brukes. Men kanskje du har mulighet til å bruke et annet kjøretidsmiljø? Et eksempel er rammeverket Flex fra Adobe som kan kjøres i Adobe Air-miljøet.

Gi hint om hurtigtaster i applikasjonen
Understreking av en bokstav viser at en tastekombinasjon aktiverer menyen eller funksjonen. Tooltips i menyer kan gi hint om at tastatursnarveier kan benyttes. Dette støtter gradvis læring og hurtigtaster oppdages lettere uten å pugge brukerveiledningen.

Vær konsekvent
Dersom Alt+bokstav eller Ctrl+bokstav kombinasjonen ikke er tilgjengelig fordi den er lagt beslag på av nettleseren kan du bruke Alt Gr. tasten eller shift som et alternativ. Hvis du gjør dette helt konsekvent vil bruker kunne huske at det er Alt Gr + en bokstav som fungerer. Dersom lagrefunksjonen bruker Ctrl+S i din applikasjon mens alle andre bruker Shift+bokstav vil det trolig være enklere om alle brukte Shift+S.

Pass på Tab-rekkefølgen
Tab-navigasjon gjelder ikke bare innenfor skjema, selv om det er viktig nok. Navigasjon mellom komponenter i skjermbildet skal også fungere. Dersom du på ikke kan bruke standardkombinasjoner for lagre, skriv ut m.fl. er det desto viktigere at Tab-rekkefølgen er effektiv. Det beste er å kunne bruke Tab for å skifte fokus mellom f.eks. to tabeller, og at eksempelvis piltastene lar deg navigere i selve tabellen.

Kast musa
Koble fra musa di og bruk en applikasjon eller webside utelukkende med tastatur. Det er lærerikt og gir god innsikt i hvordan du kan gjøre tastaturnavigasjon enkel og effektiv for brukerne. Først da får du sjekket om samtlige kontroller i applikasjonen er tilgjengelig via tastatur.

Andre tips

• Plassér automatisk markøren i første felt i skjemaet og spar bruker for et klikk
• Validér skjema etterhvert som bruker fyller ut. Det gir mer effektiv tastaturnavigasjon
• Ikke glem feilmeldingene – Flytter de markørens fokus uten at bruker vil det? Kan de lukkes med Esc-tasten?
• Lær deg rammeverket – det kan ha innebygget støtte for tastaturnavigasjon. Finn ut hvilke taster det er som brukes
• Bruk standarder! Brukerne forventer spesiell oppførsel fra Enter, Tab, Mellomrom, PgUp, PgDn osv.

Allment tilgjengelige apps med tastaturnavigasjon:

• Google Reader
• Gmail
• Remember the milk

Mer om tastaturnavigasjon

• W3 validatorens hurtigtaster
• Navigasjon og tilgjengelighet (Engelsk)
• UK Government access keys standard (Engelsk)
• Wikipedia om Access keys (Engelsk)
• Microsoft GUI-standard for tastaturnavigasjon (Anbefales)

Kjenner du til flere applikasjoner som har tatt i bruk tastaturnavigasjon? Del dem med oss i kommentarfeltet. (NB: Fler enn to linker i en kommentar blir tatt av spam-filteret, si i så fall fra dersom den ikke dukker opp så vi kan godkjenne den manuelt).

Må webredaktøren bli en webdiktator for å stoppe publisering av uinteressant innhold? Foto: Flickr by mpldesign

I følge Gerry McGovern bør vi kutte kraftig ned på antall sider
som publiseres på et nettsted fordi kun et fåtall faktisk blir lest. Uinteressant innhold gjør det vanskelig for brukerne å finne det de trenger. Webredaktører som har forstått dette må være strenge. Å bestemme hva som skal få plass en webside for en stor organisasjon er som å pakke til langtur i en litt for liten koffert. Det er ikke plass til alt.

Avslag og sletting kan føles urettferdig for flittige innholdsprodusenter som ikke får sine publiseringsønsker oppfylt. Det er likevel strengt nødvendig. Litt til og litt til blir ganske mye til sammen. Selv etter en grundig opprydning er fort gjort å komme i en ny kaossituasjon der det blir vanskelig å finne frem og umulig å holde kontrollen.

10 gode grunner til å gi avslag
1. Informasjonen er ikke beregnet for noen av målgruppene
2. Informasjonen hjelper ikke målgruppene å ta beslutninger eller å nå sine mål
3. Kvaliteten på teksten er ikke god nok (følger ikke retningslinjene)
4. Teksten er for lang
5. Informasjonen finnes allerede på et annet sted i strukturen
6. Erfaringstall viser at denne typen informasjon ikke blir lest
7. Den nye informasjonen vil bryte med logikken og prinsippene for hvordan forsiden spesielt og websiden generelt er bygget opp. (f.eks. vi skal ikke ha bannerannonser)
8. Informasjonen er konfidensiell
9. Informasjonen er gått ut på dato
10. Den totale mengden informasjon på websiden må holdes nede, vi kan ikke få plass til alt.

En webredaktør må med andre ord tørre å si nei til innhold. Som interaksjonsdesignere er vi også med å påvirke den totale informasjonsmengden gjennom kartlegging og informasjonsstrukturering. Kanskje det vi trenger egentlig er webdiktatorer?

Vil du dele din erfaring eller synspunkter?  Skriv gjerne en kommentar.

Flere artikler fra brukskvalitet.no
5 tips for brukertesting av innhold
Slik skaper du en god brukeropplevelse
Redd miljøet med bedre informasjonsdesign

Relevante lenker
Work accessibility into your content strategy (26.05.2010)
Hata information. Att skriva för webben är att skriva för effekt. (26.05.2010)
What is the Long Neck and why should you care? (26.05.2010)

Dette er en enkel instruksjonsvideo som viser de mest grunnleggende trinnene i det å planlegge en brukertest.

For tilgjengelighetens skyld er filmscriptet gjengitt her:

Stein på stein – hvorfor rekkefølgen av tingene som må planlegges er viktig

1. Hva er formålet med brukertesten?
Er det å skaffe innsikt i faktisk bruk, eller vil vi vite om systemet er lett å lære for nye brukere? Det er viktig at formålet med testen er forankret hos alle beslutningstagere.

2. Hvilken funksjonalitet skal testes?
Vi kan ikke teste alt. Ut fra hvilket formål vi har med testen, må vi bestemme hvilke funksjoner i systemet som skal testes.

3. Hva slags system skal du teste på?
Hvor er den funksjonaliteten som skal testes tilgjengelig? Er det en spesiell versjon av systemet, er det test eller produksjonsdata, eller kanskje en prototype?

4. Hva slags brukere skal få komme og teste?
Hvem er den funksjonalitet som skal testes tiltenkt? Definér målgruppen og andre kriterier for utvelgelse av brukere, og hvor du skal få tak i dem.

5. Hva slags testutstyr skal brukerne benytte?
For å gjøre testen så realistisk som mulig for målgruppen må du gjenskape faktisk bruk. Det er ikke sikkert alle har en 24-tommer skjerm og bredbånd slik som du har.

6. Hvilke oppgaver skal brukerne få?
Lag realistiske oppgaver som dekker den funksjonaliteten som skal testes. Du må også definere hva som er sukesskriteriene for disse oppgavene.

Som du ser er planlegging en sekvensiell prosess. Valgene du tar underveis påvirker de neste og hjelper deg å holde fokus. Dersom det ikke er tydelig hva formålet med testen er, vil du ha store vanskeligheter med å beslutte de neste trinnene.

Slik planlegger vi en brukertest. Lykke til.

Som systemeier ønsker man å vite hva som er de mest vellykkede og de mest problematiske funksjonene til et system i forhold til oppgavene det er tenkt å løse:

• Hjelper systemet den tiltenkte målgruppen?
• Hva slags problemer har brukerne?
• Hvem bruker egentlig systemet?
• Hvorfor blir ikke systemet brukt slik vi ønsker?
• Hva slags spørsmål får superbrukerne våre?
• Hva kan gjøres for å korte ned opplæringen?
• Finnes det funksjonalitet som ikke brukes og kan fjernes?
• Har vi nådd målene for effektivitet/brukskvalitet/saksbehandlingstid?
• Kan innspill fra brukerne systematiseres på noen måte?

Vanligvis har den forutseende systemeier sørget for at viktige metrikker logges når systemet brukes. Men logganalyser kan bare fortelle deg halve historien – dvs. du ser hva som blir brukt, men aldri hvordan eller hvorfor. Med undersøkelser som brukerintervjuer og brukertester får du innsikt i hvilke områder av systemet som trenger forbedring. Da kan du bruke forvaltningsbudsjettet på å videreutvikle det som er viktig for at systemet forblir en suksess.

Brukerintervjuer med representanter fra målgruppen er en enkel og positiv måte å få innsikt i hvordan systemet ble mottatt og hva brukerne sliter med og de setter pris på å få dele sine erfaringer.

Brukertester gir stor innsikt i hvordan systemet egentlig brukes og kan for de som observerer for første gang bli en åpenbaring. Innsikten gjør at man enklere kan prioritere hva som skal utvikles.

Brukerdagbøker systematiserer tilbakemeldingene fra brukerne. Man kan velge ut enkelte brukere som fører dagbok over sin bruk av systemet, eller man kan be superbrukerne skrive en logg over alle spørsmål de får – når informasjonen er samlet inn og systematisert har du et godt bilde av hva brukerne trenger.

Konklusjon
Forvaltning er mer enn bare oppetid, det handler også om å forvalte brukeropplevelsen. Hvordan vet du hvilken funksjonalitet som er mest brukt, hvilken funksjonalitet folk sliter med og hva du kan fjerne? La brukerne medvirke slik at forvaltningsbudsjettet kommer dem til gode.

Ikke alle kan komme

Du må håndplukke de du vil ha: Systemeier, prosjektleder og andre beslutningstagere er viktigst. Ofte må du ha med en utvikler eller to. Ved å få utviklere til å observere bruken av systemer de har laget vil de bli motivert for oppgaver som kan være komplisert å utvikle men som vil gi økt brukskvalitet. Utviklere er i min erfaring svært dyktige til å se løsninger på problemene de observerer.

Book folk tidlig

Dersom beslutningstagere ikke observerer testen, vil de alltid trekke i tvil dine konklusjoner når du presenterer dine funn. Har de vært der selv, blir de ambassadører for brukskvalitet. Hold aldri en brukertest uten å forsikre deg om at beslutningstagere får være med.

Observatørene må ta del i planleggingen

En god testplan er arbeidet frem av flere. Det nytter ikke å planlegge testen på egenhånd og deretter invitere observatører. Beslutningstagerne for ditt system eller prosjekt må være enige i hva som skal testes, hvem som er målgruppen og at oppgavene er realistiske. Hvis ikke, vil de trekke dine konklusjoner i tvil etterpå.

En sann historie til skrekk og advarsel:

I en brukertest gjennomført at meg og en annen erfaren brukervennlighetsekspert hadde vi med produkteier for å bistå som observatør. Vårt formål var å teste om nye søk og filtreringsmuligheter ville gjøre det enklere for bruker å finne frem til varer i ulike kategorier. Mens to av oss til vår store frustrasjon observerte at brukerne ikke klarte å finne en naturlig strategi for å finne fram fordi vi hadde laget for mange muligheter i brukergrensesnittet så var produkteier lykkelig – hun hadde observert at folk snublet over ting de ikke var på jakt etter og anså det som en fin feature som ville føre til flere sidevisninger og økt respons…
Så galt kan det gå og det skyldes utelukkende misoppfatninger om testens formål. Ved å ta med produkteier i utarbeidelse av testplanen ville ulikt syn på formålet med endringene i systemet blitt avklart på forhånd, lenge før brukerne fikk slippe til.

Slik briefer du observatørene

Når du kaller inn folk:

• Sørg for at de vet hvor de skal møte, og når. De må minst møte 15 minutter før testen starter og de må informeres om at de blir avvist om de kommer for sent.
• Sørg for at de vet hva de takker ja til. Brukertestobservasjon er ikke en forestilling, de må arbeide hele tiden med notater, og de må dele sine observasjoner.
• Sørg for at de selv er ansvarlige for å kalle inn en stedfortreder dersom de selv blir forhindret fra å stille
• Gi klar beskjed om at de må observere minst to tester. En observatør som kun observerer én test vil bli farget av om testen gikk bra eller dårlig. Det kan være vanskelig å overbevise en som har observert én dårlig test om at systemet er bra, hvis de 7 andre brukerne klarte alle oppgavene. (Takk til @elitatt for dette punktet)
• Pek ut én person som er hovedobservatør. Denne personen må observere samtlige testbrukere

Før testen starter:

• Observatørene skal være kjent med testplanen. Ikke regn med at de har med en kopi, ha en klar til dem. Hele testplanen er ikke nødvendig å dele ut i alle tilfeller, men observatørene skal ha dokumentasjon som minst inneholder oppgavene som skal utføres, timeplan og oversikt over brukerne.
• Sørg for at det finnes penner, papir og evt. observatørskjema i observatørrommet
• Avklar ansvarsfordeling mellom deg og hovedobservatør. Hvem er ansvarlig for å holde rede på scoring av oppgaver iht. testkriteriene? Andre ting som hovedobservatør kan ta ansvar for er innsamling av notater, ta kopier av testplan og observatørskjema, forfriskninger til andre observatører osv.

Regler for observatører
Det er mange ting en observatør bør forstå, og dersom det er vedkommendes første test er det på sin plass med en liten prat om hvordan testen skal gjennomføres (ikke anta at observatørene har lest alt du har skrevet i testplanen).

Uansett observatør og situasjon, sørg for at de minst forstår følgende:

• Ikke snakk under testen uten tillatelse fra testleder
• Ikke svar på direkte spørsmål fra brukeren

Et bra (engelsk) sett med skriftlige instrukser til observatører finnes her.

Det kan være at observatørene har ekstremt viktig informasjon, eller at de tror de har det og er nødt til å dele det med testleder underveis i testen. Dersom de ønsker kontakt med deg, avtal et signal slik at du på et passende tidspunkt kan avbryte testen og høre hva de vil. De må uansett henvende seg til deg og aldri direkte til brukeren, med mindre du som testleder gir tillatelse til det. Med observatører i samme rom kan de for eksempel rekke opp hånda. Dersom de sitter i rommet ved siden av kan SMS være et alternativ for å få din oppmerksomhet.

Opplæring i notering
To hovedregler skal følges:

• Notere hva brukeren gjør, anta ikke hennes intensjoner
• Sitér brukeren nøyaktig, ikke skriv om

Det er viktig at observatørene noterer riktig slik at de i etterkant ikke trekker feil konklusjoner om hva de har observert. De skal kun notere faktiske hendelser og sitere bruker så nøyaktig som mulig.

Riktig:
Fritekstsøk ”hund og katt”, får 0 treff. Ser lenge på siden uten å klikke på noe før han spør ”Hvorfor er det så få treff her?

Feil:
Bruker får veldig få treff og skjønner ikke hvorfor basen ikke gir alle resultater, burde ha skrevet ”hund OR katt” det ville løst problemet

Observasjonsskjema
Et observatørskjema er en fin metode for å styre notatene i riktig retning. En variant er å lage faste skjemaer som er tilpasset oppgaven, med avkrysningsbokser for hvilke funksjoner eller sider som bruker er innom. Dersom du tester søkefunksjon, lag felter der observatørene kan notere søkekriteriene til brukeren. Her er et generisk eksempel på et observatørskjema, komplett med instruksjoner til bruker osv. En annen måte å gjøre dette på er å lage notatark med skjermbilder av systemet du tester. Lag ett ark pr. skjermbilde og sett av plass nederst på arket til notater. Observatør kan tegne piler til de ulike delene av skjermbildene, sette kryss ved funksjonalitet som ble brukt osv. og slipper å skrive like mye.

Et generisk observatørskjema du kan laste ned og bruke finnes på nedlastingsiden for maler

Suksesskriterie for oppgaver
Observatørene må forklares hva som er kriteriene for fullførelse av oppgavene som bruker skal utføre. Dersom det er en skala (Lett, vanskelig, ikke fullført, osv) må det forklares hva slags kriterier som skal legges til grunn for score på de ulike oppgavene. Dersom det skal noteres tider for start/stopp av oppgavene, må du bli enig om formatet (f.eks 02:50, ikke “ca 2 min”)

Involvering av observatører i testrommet

Før testen kan det være hyggelig å ta med brukeren innom observatørrommet for å si hei. Det er i min erfaring mindre skummelt for brukeren når han vet hvem som sitter på andre siden av glassveggen.
Dersom observatørene sitter i samme rom, sørg for at de sitter langt unna deg og testbruker. Plassér observatørene slik at det ikke er naturlig for bruker å henvende seg direkte til dem. Før testen starter lar du bruker hilse på observatørene og forklarer kort deres rolle. Husk å fortelle at de ikke skal si noe før etter at testen er ferdig slik at bruker ikke henvender seg direkte til dem under testen.

Etter endt test, før du avslutter med brukeren, spør observatørene om de har spørsmål til brukeren. Det har de nesten alltid. Det kan være klargjøring av observasjoner, ting de er nysgjerrige på osv. Sitter alle i samme rom, må du være svært tydelig på når du er ferdig med dine spørsmål og observatørene kan slippe til. Vær ordstyrer, og sørg for at diskusjonen avsluttes før testen går på overtid.

Debrifing – synkronisering av observasjoner

Ofte blir det satt opp en timeplan uten skikkelige pauser. I min erfaring gir det bedre resultater dersom du setter av minst en halv time mellom hver bruker, og at du bruker den tiden til å gjennomgå og ”synkronisere” notater med observatørene. Som testleder må du gå gjennom testoppgavene punkt for punkt og sammenligne notater. Observatørene vil få en større forståelse for sine observasjoner og du får samlet sammen og notert informasjon som de kanskje ikke har hatt tid til å skrive ned.
Dersom du hopper over denne debrifingen mellom hver bruker vil du risikere at observatørene har en annen oppfatning av hva som faktisk skjedde og du kan banne på at de i etterkant vil bestride dine påstander om systemets brukskvalitet.
Husk også å samle inn alle observatørene sine notater og skjemaer. Det er du som testleder som er ansvarlig for rapporten og til det trenger du alle observatørenes notater.

Kort oppsummert

• Book viktige folk tidlig
• Sørg for at dere på forhånd er enige om regler
• Ha en felles strategi for notering av observasjoner og scoring av oppgaver
• Bruk observatørskjema
• Slipp observatørene til på slutten
• Foreta en debrifing etter hver test for å synkronisere notater og score på oppgaver

Sist men ikke minst – enhver brukertest går bedre med sukker. Husk Bamsemums til både deg selv og observatørene, men servér brukeren først.

En stappfull markedsplass – som flokkdyr forstår vi at dette er attraktivt fordi mange andre mennesker er der. Blide av Sanctu, Flickr.com, CC-lisens

Så hva har dette med brukskvalitet å gjøre? Det ligger i vår natur som flokkdyr å følge andre. Dersom ditt nettsted viser at det finnes liv der, blir vi tryggere på det vi gjør. Om du selger noe, vil jeg vite hva andre har kjøpt. Se bare her på Amazon.com:

På amazon er det mye tegn til liv. Produktsidene handler mye om andre ting som folk kjøper og hva andre mener om produktet.

Gode gamle tuben kan brukes som eksempel på alt. Her ser vi hvordan forsiden i stor grad handler om hva andre ser på akkurat nå. Det er viktig å vite at andre bruker det, og for å føle tilhørighet vil vi gjerne oppleve det samme som andre.

Et norsk eksempel hvor man må lete litt for å finne liv er nettbutikken komplett.no. Det finnes kundeanbefalinger, produktomtaler og rating av produktene men størsteparten av forsiden er tom for liv. Er det noen hjemme?

Er det noe liv her? Det er ikke godt å vite.

Om man ikke kjenner nettstedet og vareutvalget er det vanskelig å vite om det er populært. Og det er viktig å være populær, ettersom vi alltid hermer etter andre. Vi handler der andre handler, vi kjøper til og med  samme varer. Om du har mange kunder, så skriv gjerne det. Det viser meg at her er jeg ikke alene om å handle. At andre har gjort det samme gjør meg trygg på at jeg ikke blir lurt, at prisene er greie og at varene holder det de lover.

Joda – Komplett.no har mye tegn til liv men det er ikke gitt en god plassering. De kunne med fordel vist bedre frem hvor populære de er for å fjerne tvil hos skeptiske nye kunder.

En variant av tegn til liv er det jeg kaller suksesshistorier. En god læremester fortalte meg om dette fenomenet mens vi jobbet med internasjonale nettsider for kjøp og salg. Eksempelet han brukte var Shaadi.com – Et av de største nettsidene for å finne en partner å gifte seg med i India. Se bare her:

Shaadi.com bruker mye plass på å vise deg sine suksesshistorier. De oppfordrer brukerne til å sende inn sine suksesshistorier fordi de vet hvor viktig det er å vise at dette er stedet andre folk bruker for å treffe en ektefelle.

Men det beste eksempelet jeg har funnet er Svensk-norske Møteplassen. Der kombineres suksesshistorier med bilder av faktiske medlemmer. Dette gir en fin kombinasjon som viser at det finnes yrende liv der.

Selv den mest minimalistiske GUI trenger tegn til liv. Har du lagt merke til Google suggest som foreslår søkekriterier? De er satt sammen av søkebegreper som andre skriver. Å vite hva andre søker etter gjør det enkelt å formulere sine søk og det gir trygghet å vite hva andre søker etter:

Ja DET skulle du likt å vite det tenker jeg

(Som vanlig) mangler jeg empirisk grunnlag for mine påstander men det er all grunn til å tro at tegn til liv, eller mangel på liv påvirker vår trygghet når vi søker informasjon eller kjøper varer fra ditt nettsted. Som flokkdyr søker vi dit andre folk er, gjør det de gjør og begjærer samme ting som de har.  Hvordan fremstår ditt nettsted for brukerne? Tomt, eller fullt av liv?

I motsetning til informasjonsnettsider og webshops er fagsystemer vanskelige å evaluere. Men slike fagsystemer er ofte ryggraden i en virksomhet og brukere er avhengige av det for å gjøre jobben sin. Derfor er arbeid med brukervennlighet desto viktigere men pga alle vanskelighetene, og at det er vanskelig å dokumentere en økonomisk gevinst ved å øke brukskvaliteten forblir de ofte tungvinte og vanskelige å bruke.

Løsningen kan være like enkel som den er genial – for å få en kontinuerlig strøm av feedback til systemeier, prosjektleder eller leverandør kan brukerdagbøker være løsningen. Kort fortalt går det ut på at utvalgte brukere (ikke ulikt et brukerpanel) fører en logg over hva de gjør i systemet. Når slike rapporter sendes inn regelmessig vil det danne seg mønstre over hva systemet brukes til, og man vil kunne se hvor folk får problemer osv.

En variant som ville gjøre det enda enklere er at man utstyrer alle superbrukere med en dagbok der de kan føre en logg over alle henvendelser de får fra sine kollegaer. Ja nemlig! Tenk om du i dette øyeblikk satt med en liste over samtlige ting noen har spurt en superbruker om det siste året. I ditt arbeid med brukervennlighet vil du få vite hvem du skal snakke med, hva de har problemer med, hvor hyppig problemer oppstår, hva slags mål brukerne har og hva slags oppgaver de utfører som gir dem vanskeligheter. Dessuten har du ikke løftet en finger for å få det til, og det er helt gratis. For godt til å være sant? Hvem vet, for jeg har ikke forsøkt det tidligere. Har du?

Som et rekrutteringstiltak for å få opp andelen jenter på IT-studier i Trondheim, arrangerte Jenter og Data ved prosjektleder Nina Kotte, NTNU, en IT-camp i Trondheim hvor 50 jenter fra videregåendeskoler rundt omkring i landet ble invitert. Jeg, professor Dag Svanæs og student Lars K. Flem arrangerte øvelsen.

Siden iPhone fortsatt er rimelig hot blandt unge mennesker i dag, baserte vi oss på den som basis for prototypen som ble bruk. Vi skrev ut 50 bilder av en iPhone, monterte de på capafix (en 5 mm tykk pappplate med lim for montering av bilder), og skar ut formen til en iPhone ved hjelp av en skarp tapetkniv. Det resulterte i 50 papptelefoner som i form og tykkelse ikke ligner så aller verst på den “ekte” saken. I tillegg skar vi til post-it lapper slik at de passet rimelig nøyaktig inn på skjermen til en papirtelefonen, heretter kalt pappPhone.

Hver av deltakerne fikk utdelt en pappPhone, en bunke tilpassede post-it-notes, og en blyant. Så ble de instruert til å dra ned til Trondheim Torg (et kjøpesenter midt i Trondheim sentrum) perfekt for shoppeglade unge damer. Her ble instruert til å lage et mobilt system som skulle forbedre shoppingopplevelsen deres ved hjelp av pappPhonen og. De fikk oppgitt at iPhonen hadde GPS (som for anledningen også fungerte innendørs), Bluetooth og RFID-leser.

I kjøpesenteret gikk elevene rundt (med fotograf Kai T. Dragland på slep) og “brainstormet” seg frem til nyttige (og unyttige) funksjoner på telefonen ved hjelp av pappPhonen som prototyp. Mange gikk rundt på egen hånd fra butikk til butikk og brukte pappPhonen til å komme på ideer, noen intervjuet butikkpersonalet, andre snakket med kunder.

Elevene trakk seg deretter tilbake til flere grupperom der de fikk beskjed om å lage en poster der de presenterte den beste av ideene de kom frem til.

Det kom frem flere gode ideer under posterfremvisningen:

Trendråd: Flere av gruppene kom frem til applikasjoner som hjelper deg med å finne frem klesplagg som passer deg i forhold til dine vitale mål, øyefarge, hårfarge. Noen baserte seg på trendråd basert på informasjon som du selv oppgir. Andre og mer avanserte varianter kan du gjøre en “virtuell” prøving av klærne uten å ta det på; du tar bare bilde av klesplagget på kleshegeren, så lager applikasjonen et bilde av deg med klesplagget på slik at du ser hvordan det kommer til å ta seg ut.

Karttjeneste: Telefonen tilbyr en innendørs karttjeneste som for eksempel hjelper deg med å finne veien og menyen til restauranter i kjøpesenteret

Kølapp: På telefonen kan du trekke kølapp til apoteket på mobiltelefonen mens du fortsatt shopper i en annen butikk.  Underveis i shoppingen får du se hvilket kølappnummer som ekspederes på apoteket, slik at du kan gjøre andre innkjøp i mellomtiden. Alarmen går når ditt klølappnummer nærmer seg og du må løpe til apoteket (se detaljert poster ved å trykke på bildet under).

Budsjetthjelp: Hold styr med hvor mye du shopper for. Systemet kommuniserer med kassasystemene og holder styr med hvor mye du har shoppet for og hvor mye du har igjen på budsjettet. Du får klar beskjed når du har oversteget budsjettet.

Til slutt gjennomførte elevene selv en kåring av beste poster og beste detalj i posteren. Vinnerne (dødt løp) ble en av trendrådløsningene samt det mobile kølappsystemet. På en halv dag lærte altså 50 unge mennesker seg kunsten å prototype gode designløsninger.

På Software 2009 var spesialisten Steve Mulder invitert fra USA for å avholde et seminar om personas. I løpet av seminaret presenterte han mange nyttige teknikker vi kan bruke for å gjøre personaser bedre. Han viste blant annet til forskjeller på kvantitative og kvalitative personaser og til hva vi kan gjøre  for å “holde liv” i personasene utover i prosjektet.

I  norske prosjekter er det ofte ikke anledning til å bruke fullt så mye tid på å skape gode personaser som noen av disse teknikkene krever.  Jeg synes derfor det var fint å få anledning til å presentere personaser fra et prosjekt som gikk ut på å utvikle et intranett for organisasjonen SOS-barnebyer. I presentasjonen viste jeg hvordan man kan lage personaser på svært kort tid og likevel lære noe nyttig om brukerne av det fremtidige systemet. I dette tilfellet var målgruppen begrenset til de omlag 50 ansatte i SOS-barnebyer og målgruppen var velkjent for prosjektgruppen. Jeg mener at dette er en av årsakene til at den enkle teknikken fungerte i dette tilfellet.

Nyttige lenker
Om personas: http://en.wikipedia.org/wiki/Personas
Mer info om seminaret: http://dataforeningen.no/-mwJLK5J.ips
Steve Mulder sin blogg: www.PracticalPersonas.com
Side med flere maler for brukervennlighetsarbeid, deriblant mal for å lage personaser:
http://www.zefamedia.co.nz/blog/2008/11/21/free-ux-templates.html

Var du på foredraget uten å få stilt dine spørsmål eller har du erfaringer med bruk av personaser som du ønsker å dele med andre? Skriv gjerne en kommentar.