Pressemelding 18.06.2007
- Vi skal være det selskapet i Norge som leverer de mest brukervennlige løsningene. Derfor går vi nå ut og garanterer ovenfor våre kunder at løsningene vi leverer er oversiktlige, effektive og lette å bruke, sier seniorrådgiver Ketil Storvik, som leder fagområdet brukervennlighet og design i Steria.
En forutsetning for at det gis garanti er at kunde og leverandør på forhånd blir enige om klare og kvantifiserbare mål i prosjektet, noe som ifølge Storvik uansett må være på plass for å få til et vellykket it-prosjekt. Dersom resultatene avviker fra målene som er satt, utfører Steria forbedringer til redusert timepris.
Setter brukerne først
Brukervennlig design er avgjørende for om en løsning blir en suksess eller ikke.
Seniorrådgiver Ketil Storvik forteller at Steria har valgt en metodisk, analytisk tilnærming til dette arbeidet med brukervennlighet.
Modellen er utviklet av en av guruene på området, Jesse James Garrett fra firmaet Adaptive Path. Storvik forteller at prosjektet går igjennom flere faser, fra strategi og målgruppeanalyse, via utforming av informasjonsstruktur, interaksjonsdesign, prototyping og brukertesting, og så til slutt den grafiske designen. Resultatet i hver fase blir input i den neste, og det sier seg selv at det er viktig å gjøre ting grundig fra starten av.
At definisjonen på hva som er brukervennlig varierer fra prosjekt til prosjekt og løsning til løsning, blir en ekstra utfordring når Storvik og kollegaene hans setter i gang.
Fleksibel utelukker enkel
- Noen programmer brukes daglig, og kan godt være ganske avanserte og fleksible, rett og slett fordi brukerne lærer seg funksjonaliteten gjennom stadige repetisjoner. Andre løsninger må være enkle, fordi de benyttes sporadisk.
På dette stadiet er det viktig å definere hva man mener med brukervennlighet i en spesifikk løsning. Kravene til løsningen kan inneholde motsetninger som det blir umulig å løse senere.
- Noen ber for eksempel om funksjonalitet som er både fleksibel og enkel. Da glemmer man at fleksibilitet innebærer mange valg, noe som vanskeliggjør den enkle varianten. Selvangivelsen på internett er et godt eksempel på en løsning som har prioritert enkelhet til tross for et komplisert regelverk, sier Storvik.
Informasjonshierarki
Han mener at metodisk arbeid med informasjonsstrukturering vil hjelpe brukerne å finne fram i løsningen.
- Jo dypere informasjonshierarkiet er, desto større fare er det for at folk går seg vill, fastslår Storvik. Kategorinavn må være logiske og gjensidig utelukkende, og valgene bør ikke være for mange. Erfaring tilsier at du ikke skal mer enn et par klikk ned i lagene, før du glemmer hvor du kom fra - og i noen tilfeller også hvor du skal. Går du deg vill er det viktig at den visuelle designen ikke bare underbygger avsenderens profil og verdier, men også presenterer enkle valg for hvordan man navigerer videre..
Gule lapper
Prosessen starter ofte med en kombinasjon av kundens forhåndsdefinerte krav og målsettinger og en noe løsere kreativ prosess, der målet er å kartlegge brukernes behov. Ganske raskt begynner man imidlertid å forholde seg til problemstillinger som handler om forståelige begreper og å utarbeide en struktur.
- Card sorting kaller vi det når en gruppe mennesker skriver behov og ønsker ned på gule lapper, sorterer dem etter informasjonstype og kategori, og på den måten bygger en struktur nedenfra, forteller Storvik.
- Noen ganger kan vi også la forskjellige grupper strukturere de samme lappene, for så å la dem diskutere seg fram til en løsning som kanskje må ha flere forskjellige innganger eller parallelle informasjonshierarkier, sier Storvik. Brukerne tenker forskjellig. Skal du for eksempel finne et bestemt skjema, vil noen brukere velge tema-veien, mens andre ser etter «alle skjema».
Tidlig testing
- Jo tidligere vi kan starte brukertestingen, jo bedre er det. Det er ikke noe i veien for å sette testbrukere foran skjermen mens løsningen fortsatt er en prototype, med navigerbare «wireframes» (skjematiske sider) og struktur uten grafisk design på plass. Så kan vi gjenta prosessen utover i prosjektet, men luke ut problemene fortløpende underveis, sier Storvik.
Testingen foregår ved at brukere blir plassert foran skjermen og foret med konkrete oppgaver som skal løses. I noen situasjoner er observatører til stede i rommet, noen ganger sitter de i et annet rom eller observerer i etterkant, ved at lyd, bilde og bevegelser blir tatt opp og analysert.
- Vi jakter spesielt på de stedene der brukerne faller av eller går seg vill, og vi ber dem eksplisitt om å tenke høyt mens de jobber. På den måten kan vi forstå problemene de møter. Og går alt etter planen, og vi gjør jobben vår skikkelig, skal det altså være mulig å gi en garanti for at løsningen er brukervennlig når prosjektet avsluttes, sier Storvik.
(Kløkt)
10 bud for brukervennlighet
- Du skal lage samsvar mellom systemet og den virkelige verden
Systemet skal snakke brukerens språk ved å bruke ord og uttrykk som er kjent for brukeren. Ikke bruk systemorienterte uttrykk. Følg konvensjoner fra dagliglivet, slik at informasjon vises i logisk rekkefølge. - Du skal gi brukeren kontroll og frihet
La brukeren beholde kontrollen, og gi han frihet til å bevege seg. Brukere gjør ofte feil valg i systemet ved uhell og vil trenge tydelig markerte "nødutganger", slik at de kan komme seg ut av en uønsket situasjon. Gjør det mulig å "angre" og "gjenta" handlinger. - Du skal alltid være konsistent og følge standarder
Brukeren skal ikke måtte lure på om forskjellige ord, situasjoner eller handlinger gir forskjellige resultater. Vær konsistent! Hvis de finnes, følg plattformkonvensjoner - dette gir konsistens og sikrer gjenkjennelse fra andre systemer. - Du skal tilby fleksibilitet og effektiv bruk for ekspertbrukeren
Lag systemer som kan håndtere både erfarne og uerfarne brukere. Handlinger som gjøres ofte bør ha muligheter til å skreddersys etter brukerens ønsker. - Du skal la brukeren benytte gjenkjennelse fremfor erindring
Gjør handlinger og valg synlige. Brukeren skal ikke måtte huske informasjon fra én del av systemet til en annen. Instruksjoner for bruk av systemet burde være synlige eller lett å finne når det er nødvendig. - Du skal alltid tenke estetikk og minimalistisk design
Dialoger skal ikke inneholde informasjon som er irrelevant eller som sjelden trengs. All informasjon som puttes inn i en dialog vil konkurrere med resten om oppmerksomhet fra brukeren. - Du skal alltid hjelpe brukere til å kjenne igjen og komme seg ut av feilsituasjoner
Feilmeldinger skal uttrykkes i vanlig språk uten kryptiske koder. De skal så tydelig som mulig angi hva som er problemet, og foreslå en konstruktiv løsning for at brukeren kan komme seg videre. - Du skal ikke la brukeren gjøre feil
Enda bedre enn gode feilmeldinger er systemer som ikke lar problemet oppstå i det hele tatt. Fjern situasjoner som skaper problemer, eller håndter feilsituasjoner før brukeren har mulighet til å gjøre feil. - Du skal alltid vise status
Systemet skal alltid holde brukerne informert om hva som skjer gjennom passende tilbakemeldinger innen rimelig tid. - Du skal ikke slurve med hjelp og dokumentasjon
All hjelp og dokumentasjon skal være lett å søke i og være fokusert på brukerens oppgave. List opp konkrete trinn som må gjøres og hold dokumentasjonen kort!
(Kilde: Kløkt/Steria)

![English [icon_flagg]](gfx/eng.gif)


