Gjennom flere prosjekter har jeg hatt gleden av å se hvor viktig det er å ha interaksjonsdesignere på utviklingsprosjekter. Som utvikler er det givende å ha noen på teamet som kan gi applikasjonen det løftet som skal til for at den får det lille ekstra som imponerer brukerne og kunden og gjør at man virkelig kan være stolt av det man lager!

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.