Når du utvikler interaktive tjenester ønsker du at de ulike egenskapene du designer inn i tjenestene skal bidra til at de som bruker tjenesten blir fornøyde. Med en Kano-undersøkelse kan du finne ut i hvor mye de ulike egenskapene bidrar til nettopp dette. Du vil få svar på om egenskapene bidrar positivt, negativt eller ikke i det hele tatt. Du vil også kunne få en forståelse av hvor godt implementert de ulike egenskapene må være for å skape begeistrelse hos kundene dine.

Denne innsikten gir deg muligheten til å prioritere hvilke egenskaper du skal legge ned ekstra innsats i, hvilke egenskaper du kan designe som alle andre i bransjen og hvilke du rett og slett burde vurdere å fjerne.

Kano-undersøkelsen bygger på Noriaki Kano sin modell for kundetilfredshet. Kano sin modell klassifiserer produktegenskaper i en av 5 grupper:

• Basisegenskaper
• Forventede egenskaper
• Attraktive egenskaper
• Egenskaper uten betydning
• Omvendte egenskaper

Basis-egenskaper

Dette er egenskaper kunden forventer at er tilstede i produktet. Derfor medfører det liten eller ingen økning av kundetilfredsheten å at de fins inkludert. Dersom disse egenskapene ikke er inkludert i produktet vil det derimot virke kraftig negativt på kundetilfredsheten. Basisegenskaper er oppfattes ofte som selvfølgeligheter av kundene og vil derfor ofte ikke bli nevnt dersom du spør en kunde om hans forventninger til produktet.

Eksempel: Det er mulig å sende SMS fra min mobiltelefon.

Forventede egenskaper (lineære egenskaper)

Egenskaper som øker kundetilfredsheten når de er implementert, og som minsker kundetilfredsheten dersom de ikke er tilstede, klassifiseres som forventede egenskaper. Det finnes en lineær sammenheng mellom kundens tilfredshet og hvor godt egenskapen er implementert. Dette innebærer at økt innsats bidrar til økt kundetilfredshet.

Kunder har som regel en bevissthet rundt disse egenskapene, og når du snakker med kunder blir disse egenskapene ofte uttrykt som problemer med en eksisterende løsning.

Attraktive egenskaper (exciters)

Dette en gruppe egenskaper som ikke vil påvirke kundetilfredsheten negativt dersom de er fraværende. Men, dersom de er tilstede vil de påvirke kundetilfredsheten kraftig i positiv retning. Disse egenskapene er som regel nyvinninger, og det er disse du skal satse på dersom en vil overgå kundens forventninger. Egenskaper i denne klassen kan være viktige dersom du ønsker å differensiere ditt produkt fra konkurrerende produkter i markedet.

Krav uten betydning

Dette er produktegenskaper som hverken påvirker positivt eller negativt om de fins eller ikke. Dette er krav en bør legge liten eller ingen vekt på.

Omvendte egenskaper

Dette er egenskaper som bidrar negativt dersom de implementeres i produktet og som bidrar positivt dersom de utelates. Dette gjenspeiler at kunder har ulike preferanser. Dette kan f.eks. kanskje være attributter som oppfattes som irriterende og meningsløse av noen, men som kule og meningsfulle av andre.

Vil du prøve?

Verktøy for å gjennomføre Kano-undersøkelser finner du på kanosurvey.com, du kan også laste ned kildekoden fra github.

Min erfaring er at mange interaksjonsdesignere synes det er vanskelig å finne sin plass i en smidig hverdag, hvor krav og retning kan endre seg raskt. Der metodikken tidligere har vært å designe en helhetlig brukeropplevelse før utviklingen begynner, må interaksjonsdesignere nå ha flere fokus samtidig. I et landskap som oppfordrer til endring og avvik fra plan, må man forsøke å ligge et hestehode foran utviklerne til enhver tid – samtidig som det er forventet at man greier å løfte blikket og lage en langsiktig plan for applikasjonen.

En interaksjonsdesigners oppgaver

Under følger en beskrivelse av de forskjellige oppgavene til en interaksjonsdesigner. Jeg har forsøkt å prioritere oppgavene med de viktigste først. Merk at jeg har valgt å fokusere på noen få oppgaver; de mest sentrale sett fra mitt daglige virke som utvikler. I realiteten gjør interaksjonsdesignere uendelig mye mer, og har en enorm verktøykasse.

Daglig oppfølging

Den viktigste jobben en interaksjonsdesigner gjør er å følge opp utviklingen fra dag til dag. Det vil si å «henge over» utviklerne og passe på at all funksjonalitet som lages er god nok. Helst bør dette gjøres som en fast del av utviklingsprosessen – gjerne som et akseptansekriterium innenfor hver iterasjon. Ethvert krav som toucher frontend bør først diskuteres med en interaksjonsdesigner – gjerne resulterende i omtrentlige papirskisser for løsningen. Deretter skal den ferdige implementasjonen finpusses og godkjennes før kravet kan sies å være ferdig. Skal dette fungere er det viktig at utviklerne også fokuserer på å involvere og imøtekomme interaksjonsdesigneren, slik at det ikke blir en «vi mot dem»-holdning.

Dersom man ikke har nok ressurser til å ligge i forkant innenfor hver enkelt iterasjon, kan man legge inn i prosessen at ingen krav er klare til utvikling før interaksjonsdesignet er ferdig. Dette vil redusere behovet for daglig oppfølging og gjøre det lettere å prioritere i hvor stor grad hvert enkelt krav skal detaljeres.

Skissere målbilde for applikasjonen

Den neste viktige jobben er å skissere et målbilde for hele applikasjonen. Målbildet er et ideal for hvordan applikasjonen kan bli seende ut når den er ferdig, og bør brukes til å bygge og prioritere backlog. Det er viktig å styre forventningene, slik at man ikke kommer i en posisjon der man ikke får satt noe i produksjon før målbildet er nådd og alt er implementert. Å balansere mellom målbilde og daglig oppfølging kan være vanskelig; man bør være i stand til å produksjonssette deler av løsningen ofte, mens man fortsatt sikter mot idealbildet for hele applikasjonen.

Skissering av målbilde bør også inneholde utprøving av enkeltkomponenter, for eksempel ved hjelp av papirskisser eller prototyper, slik at man unngår ubehagelige overraskelser sent i utviklingen.

Brukertester

For å sikre at man er på rett spor kan det være nyttig å hente inn feedback ved å gjennomføre brukertester av løsningen. Dette bør ikke utsettes til man anser hele applikasjonen som ferdig, men heller gjentas flere ganger under utviklingen dersom ressursene tillater det. Hvis man får produksjonssatt løsningen tidlig, bør man selvsagt også følge opp de tidlige brukerne.

Avslutning

Denne introduksjonen til hvordan interaksjonsdesign kan passe inn i smidig utvikling kan kanskje best avsluttes med et fritt gjengitt sitat av Mary Poppendieck: «Maybe we shouldn’t be thinking about how we fit usability into agile, but how we can fit agile into usability». Å skape verdi handler ikke om domenemodeller, rammeverk eller programmeringsspråk. Verdi dreier seg om å tilfredsstille og begeistre kundene dine! Dette må vi som programmere innse at det er andre som kan bedre enn oss.