Annonsebestilling på FINN. De ulike kategoriene listes opp, og oppgaven til bruker er kun én ting – finne rett kategori. Å bruke tid på å fortelle fordelene med de ulike valgene er meningsløst, fordi ingen har noen grunn til å velge å selge leiligheten fremfor bilen. Dette er ikke-reelle valg.

Når jeg senere arrangerte en brukertest av abonnementsbestillingen til Aftenposten, dukket problemet opp igjen. Noe forenklet, så er Aftenposten tilgjengelig som både morgen og kveldsavis, eller som en av delene. (Den oppvakte leser oppdager umiddelbart at dette er et reellt valg). Pga. at Aftenposten lages i Oslo, er distribusjonskostnadene ulike i forskjellige deler av landet, dvs. dyrere på vestlandet enn i Oslo. For å spare et steg i bestillingsprosessen kan det være fristende å slå sammen stegene, slik at kunden kan velge mellom ulike “pakker”: morgen + kveldsutgave på østlandet, ditto for vestlandet, sørlandet, osv., og gjenta for alle kombinasjoner av morgen, aften og helg-utgaver. Problemet er åpenbart: Du kan velge om du vil ha morgen eller kveldsutgave, men du kan ikke velge hvor du bor. Å gjøre det på denne måten øker antall valg bruker må ta stilling til, noe som gir økt risiko for at bestillingen ikke fullføres, og at kunden blir usikker på om de har valgt rett.

For å bestille abonnement hos Aftenposten må du først bestemme deg for hvor du bor, deretter for hvilke aviser du vil ha, og deretter hvilken abonnementsperiode du ønsker. Valget om hvilken landsdel du tilhører kunne med fordel være flyttet til en egen side, slik at du slipper å se valg du i praksis ikke kan ta. For de som bor i Oslo er halve siden irrelevant, og for de som bor på vestlander er det enda mer de ikke kan velge.

Følg denne enkle regelen – skill alltid mellom ikke-reelle og reelle valg. Ha dem gjerne på egne sider i en kjøpsprosess, som vist i figuren under:

Brukere klikker seg gjennom ikke-reelle valg svært raskt fordi de allerede har svaret. Resten av prosessen vil oppleves som enklere, fordi alle ikke-reelle valg er tatt.

Se selv:
Sett inn annonse på finn.no
Aftenposten abonnementsbestilling
Hicks lov

Skilt-bilde lånt på Flickr, fra JMC Photos, CC-lisens

Fra kritisk til stolt og glad
Når det første suset har lagt seg, er det nesten umulig å ikke lese igjennom egen bok med kritisk blikk og tenke “dette kunne vært litt mer presist”, “nei, her er det en skrivefeil” eller “vi skulle også tatt med noe om…”.
Vi bestemte oss imidlertid for å si at Praktisk brukertesting er den beste boken om brukervennlighet som er utgitt i Norge på mange, mange år. Boken er uendelig mye bedre enn alle de bøkene som har blitt påtenkt, men enda ikke har blitt skrevet. Vi er stolte og glade for å ha fått dette til.

Hvorfor på norsk?
Det er mange ting folk lurer på angående boken vår. Et av spørsmålene vi har fått flere ganger er hvorfor vi valgte å skrive på norsk. Det er flere grunner til dette. For det første er norsk morsmålet vårt, og selv om vi er vant til å snakke og skrive om faget vårt på engelsk, er det mange som skriver bedre på engelsk enn oss. Det finnes flere dusin med brøker om brukertesting på engelsk, men ingen på norsk. Vi har lagt vekt på å hente eksempler fra norsk og europeisk arbeidsliv, sånn at vi ikke bare siterer de gode gamle verdensberømte brukervennlighetsekspertene, men trekker frem folk som jobber med brukertesting i dag.

Vi håper også at boken vil komme inn på pensumlistene på flere høyskoler og universiteter. Vi mener studentene trenger lærebøker på sitt eget morsmål for å kunne kommunisere godt om faget sitt både til fagfolk og til andre nordmenn.

Boken alle brukervennlighetsinteresserte burde ha i hyllen
Dette er en bok alle interaksjonsdesignere og brukervennlighetsinteresserte burde ha i hyllen sin, og bruke flittig under planlegging og oppfølging av brukertester. Vi skulle selv ønske at vi hadde hatt denne boken tilgjengelig da vi begynte med brukertesting for 11 år siden.
Vi har samlet alt stoff om Praktisk brukertesting på en egen side. Vi hører gjerne fra deg som har lest boken eller som har spørsmål i forbindelse med utgivelsen.

Ønsker du å høre mer om boken og få din utgave signert, er du velkommen på boklansering, 28. april kl 16.00 hos Cappelen Damm. Påmeldingskjema  og mer info vil bli lagt ut på Dataforeningen.no.

Denne innledningen er en smakebit fra boken Praktisk brukertesting som snart er i salg. Her kan du lese noe som ikke kom med i boken, om hvordan du i praksis kan prioritere hva som må fikses etter at du er ferdig med brukertesten.

I forrige artikkel argumenterte jeg for at trivielle feil kan være viktige å fikse, dersom mange brukere blir utsatt for samme feil. Dessuten har små feil ofte fordelen at de er enkle å gjøre noe med, så du kan gjøre nettstedet eller systemet enklere å bruke med én gang. Men hvordan bestemmer du dette i praksis?

En måte å gjøre det på, er å sette opp alle feil i en slik tabell:

Dette forenklede eksempelet viser fire feil med hver sin alvorlighetsgrad. Du kan gi alvorlighetsgraden en faktor fra 1-4, hvor 4 er mest alvorlig, også ganger du med hvor mange brukere som opplevde denne feilen. Da får du en kritikalitetsfaktor¹, hvor høyest score betyr “viktigst å få fikset”.

Da kan du plassere feilene i en slik matrise:

Figuren illustrerer poenget fra forrige artikkel, men den har en potensiell fallgruve: Hva om det som ligger i “må fikses”-kvadratet faktisk ikke er enkelt å utbedre? Hva om det skyldes samhandling med andre systemer du ikke har innflytelse på? Det er ikke noe vits i å bruke tid på noe du ikke kan gjøre noe med.

Du kan få best effekt av brukertesten dersom du setter i gang med å utbedre det du faktisk kan gjøre noe med, og som vil påvirke en høy andel av brukerne. Dersom du tar resultatet fra forrige tabell og regner med en tilgjengelighetsfaktor, vil du kunne prioritere på denne måten:

Her har jeg gitt feilene poeng på en skala fra 1-10, hvor 10 er enkelt å fikse og 1 er håpløst. Hvis du legger sammen kritikalitetscore og tilgjengelighetspoengene på løsningen, vil du se enkelte forandringer i prioriteringen.

Dette er langt fra vitenskapelig, og det fritar deg ikke fra å bruke hodet. Poengskalaene har jeg bare funnet på, og vær obs på at du ikke kan bruke slike utregninger for å bevise noe som helst. Denne måten å prioritere på fungerer derimot utmerket når en gruppe skal bli enige om hva som er viktigst.

Har du erfaringer med slike måter å prioritere på, eller andre tips om brukertestanalyse? Legg gjerne igjen en kommentar.

¹: I Handbook of usability testing (Rubin & Chisnell, 2010) brukes en antatt prosent av hvor mange brukere som vil bli utsatt for samme feil, som faktor for hvordan man skal regne ut “Criticality”.

Vanlig praksis i analyse av brukertester er å liste alle feil og gi dem en alvorlighetsgrad, for eksempel kritisk, alvorlig, og triviell. Tanken bak klassifisering på denne måten er å se på hva som faktisk hindret brukerne i å gjøre viktige oppgaver. Hvis et regnskapssystem krasjer hver gang du forsøker å betale ut lønn, så er det selvsagt kritisk. Det er åpenbart for alle at det må fikses med en gang. Alvorlige feil kan for eksempel være tap av data, men at bruker til tross for store problemer kan jobbe videre eller omgå problemet. Trivielle feil kan være tvetydige navn på knapper, eller banale skrivefeil.

Så hva er problemet? Alle fokuserer på de kritiske feilene, uten å ta hensyn til frekvens. Det er ikke rart, for hele rapporten er lagt opp til det, hvis du har tilegnet feilene ulike alvorlighetsgrader. Men hvis du tar høyde for frekvens, kan listen plutselig endre seg.

Da vi i finn.no rapporterte fra brukertester, pleide vi å se på hvor mange brukere som gjorde en feil. Det var fordi vi ønsket å se frekvens som en faktor for hvor alvorlig en feil var. Dersom alle brukerne opplevde det samme trivielle brukervennlighetsproblemet, kunne det eskaleres til en høyere alvorlighetsgrad (eller prioritet på to-do lista).

Med andre ord, en triviell feil er ikke triviell dersom alle brukerne i testen ble utsatt for problemet, og en alvorlig feil er ikke nødvendigvis det viktigste å fikse dersom kun én av brukerne kom borti det. Det er ikke dermed slik at du kan avfeie en alvorlig feil, men det kan være grunn til å flytte den ett hakk ned på to-do lista.

Hvis en brukertest har gått fullstendig galt, er det naturlig å tenke at et komplett redesign eller et nytt navigasjonskonsept er nødvendig. Steve Krug hevder i sin bok Rocket Surgery Made Easy at det er mer effektivt å ta tak i de små tingene, fordi du kan gjøre en forskjell raskt. Flytt knappen, kall den noe annet, og ikke minst – rydd opp. På nettsteder og intranett kan du slette unødvendig informasjon, navigasjon og dekorasjon. I større systemer kan du flytte på ting, rydde i begrepene, skjule kompleksitet, og fokusere på de mange små bekkene som til sammen blir en stor å av ubrukelighet. Store problemer tar lang tid å fikse, koster mye penger og det kan ta lang tid å bli enige om løsningen.

Oppdatert: Les mer om hvordan du prioriterer etter endt brukertest

Les mer:
STCSIG sitt klassifiseringskjema for alvorlighetsgrader (.doc)

Norsk versjon, oversatt av Jon Gunnar Wold

Flott blogpost om “Criticality”, som er et produkt av alvorlighetsgrad vs. frekvens:
Do severe problems affect more users than trivial ones?

Rocket Surgery Made Easy, boka til Steve Krug

Hvordan klassifisere brukervennlighetsproblemer, med et fint flytskjema for å fastsette alvorlighetsgrad

Alle artikler om brukertesting: http://www.brukskvalitet.no/?s=brukertest

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.

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?

På Flybussen sine sider blir jeg møtt av blide ansikter-  hele 10 tilsammen og mange er animerte. Søkefeltet som drukner i dette visuellet orgiet av ansikter er også et syn for seg. Under de 10px store dropdown-kontrollene finnes en vannrett gradestokk av enorme dimensjoner. Er det 11 grader kvikksølvet viser?

Nei, det er en slider for å velge klokkeslett. Og hvor er søkeknappen? Så grundig som dette er det sjelden jeg står fast på noe nettsted. Jeg VET at det går en buss til og fra Sonsveien, men Son er ikke noe sted å finne. Så i dette skjemaet velger jeg som følger:

Se så. Der kom det et resultat, det bare skled ned fra den hengepuppen som tidligere ble vist under gradestokken. I listen vises alle ruter på valgte tidspunkt (ca 16 grader) fra Gardermoen – til gardermoen, med reisetid på 0 minutter. Fantastisk! Dropdown-kontrollen “til flyplass” lar deg i steden velge “fra flyplass”. Det gjorde jeg, i den tro at jeg fikk se avganger fra Gardermoen når det var ca. 16 grader. Den gang ei, da fikk jeg samme resultat en gang til. Stedslisten viser bare de store byene så jeg har nå forstått av flybussen.no er en merkevare som ikke favner alle busser som går fra Gardermoen. Litt googling avslører at det er Flybussekspressen som går til Son. Men nå er jeg nysgjerrig på hva slags tilbud flybussen.no har og leter videre for å se hva mer flybussen.no har å tilby.

Du kommer hvertfall ikke frem med flybussen.no
Du er ikke fremme før du er fremme, skryter de på sine nettsider. Denne noe kryptiske påstand underbygges av deres nye nettløsning, lansert 29. september i fjor iflg. nevnte nettside. Siden som informerer om lanseringen nevner bl.a.:

“Hurtigsøket gir deg anledning til å finne rutetider for Flybussen med noen få tastetrykk”

Hva slags hurtighet de har målt det til vites ikke, erfaring fra brukertester viser at dropdown-kontrollere er notorisk vanskelige å bruke og dersom du måler antall klikk, så er de noe av det mest klikk-krevende jeg vet om. Dessuten foregår hurtigsøket HELT uten tastetrykk.

“Sist men ikke minst, har du også mulighet til å bruke vår karttjeneste. Denne finner du øverst til høyre på hver enkelt avdeling sin underside. Dersom du skal på et møte kan du skrive inn adressen, så vil vi vise deg hvilke holdeplasser som er nærmest. Du kan også planlegge hvilken bussavgang du skal benytte med kartløsningen”

Dette høres nyttig ut. Men si meg en ting,  hvor er “øverst til høyre på hver enkelt avdeling sin underside” om jeg tør spørre? Jeg ser et grønt kart på forsiden, det kalles “detaljert søk” og gjør følgende: Du kan velge et sted, og deretter får du det samme skjema som for hurtigsøk, men da kun for det stedet du valgte i kartet.

Er det pinlig nok, eller skal jeg fortsette?
Jeg kunne latt godt nok få være godt nok og slippe flybussen.no ut av gapestokken. Jeg er tross alt ikke ond, så jeg kunne vendt det andre kinnet til som vanlig. Men det var helt til jeg klikket på en link og oppdaget at den åpnet samme side, men da inne i et frameset:

Det var dråpen. Nå er det fengselsregler som gjelder. Flybussen, kjære snille Flybussen, fortell meg hvorfor dere lar meg oppleve alt dette, i 2009:

Tomme sider
Menyvalget “Flybussene i Norge” inneholder kun et gigantisk banner med reklame for Flybussen, med teksten “Du er ikke fremme før du er fremme”

Elendig informasjonsarkitektur
“Kontakt” og “selskapene” i hovedmenyen er samme ting, men splittet opp og ikke linket mellom hverandre. Det finnes også en tredje side som heter “kontaktinfo”. Se om du klarer å finne den, den har nemlig et annet innhold…

STORE BOKSTAVER og floskler
I venstremenyen, som jeg ikke helt har forstått hvor og når dukker opp, BRUKES UTELUKKENDE STORE BOKSTAVER. Se f.eks. menyvalget “BEFORDRINGSVEDTEKTER” som ikke har noe innhold, men som henviser til et sted (ikke linket) hvor disse kan leses.

Under menypunktet “VELKOMMEN TIL VÅRE NYE NETTSIDER” finner man enda mer informasjon om de tidligere omtalte “web sidene” (overlagt ord delings feil, red. anm)

SAS Flybussen har sammen med flybusser i 14 norske byer etablert nye nettsider. Dette for at du som kunde skal oppleve våre sider som mer brukervennlig og informative.

Nei kjære dere, men jeg finner det hele svært interessant rent faglig… Tanken er god, men akk så brukerfiendtlig gjennomførst. Her er det de beste intensjoner om å skape gode opplevelser, de er til og med uttalt på nettstedet – Brukervennlige og informative skal de være. Så hva med å la brukerne medvirke neste gang? Se for øvrig mine 10 bud for gode brukeropplevelser.

Døde linker
Sist, men ikke minst: under “KJØP BUSSBILLETTEN PÅ NETT” kan man klikke på linken “Klikk her for kjøp” og få følgende beskjed:

“Siden er ute av drift.
Billetter kan kjøpes på bussen.”

Og med det får flybussen i Oslo siste ord i denne omgang.