Prototyping som suksessfaktor 2

skbn
Noen av versjonene av prototypen under arbeidet med Skandiabanken sin nettbankløsning


Prototyping av design i HTML og CSS begynner å bli en selvfølgelig arbeidsform for mange designere. Men hvor godt står denne metoden seg når prosessen strekker seg over flere år og det som designes er en komplett nettbank? Vi har gjennom hele prosessen jobbet tett sammen både designere fra Skandiabanken og Netlife Research, samt representater fra de ulike avdelingene i banken. Dette er erfaringene vi har gjort sammen gjennom dette arbeidet.

Hvordan har prototypen hjulpet oss?

Skandiabanken hadde én nettbank for desktop, én for mobilbank og én for app. Målet med prosjektet var å samle alt i én kodebase – én responsive nettbank for alle platformer. Valget om å designe i en prototype, og ikke levere flate designskisser til utviklerne, var selvsagt. Det var rett og slett nødvendig for å være sikker på at vi designet en nettbank som fungerte for alle formål og som kunne testes regelmessig uten å vente på releaser fra utviklerne.

Prototypen gjør det først og fremst lettere for oss å teste ut idéer. Vi får også umiddelbart se hvordan løsningen vil fungere på ulike enheter, og implementasjonen er realistisk siden designet foregår i det materialet den ferdige løsningen skal bygges i. Det er klikkbart og vi kan jobbe med interaksjon og animasjoner som en del av designet.

Prototypen har spart utviklerne for en del dobbeltarbeid. Den lanserte nettbanken og prototypen deler stilsett, så veien er kort fra visuelle endringer i prototypen ut til kundene.

Prototypen gjør det lettere for banken. Designprosesser kan til tider være forvirrende. Hva driver disse designerne med nå? Hvor langt har de kommet? Er de på rett spor? Ved å gjøre prototypen tilgjengelig internt i banken kunne medarbeidere som ikke var med i prosjektet på daglig basis følge med på utviklingen innen design, interaksjon og innhold uten å måtte sette opp møter for å få innsyn.

Prototypen har også vært en del av dokumentasjonen til utviklerne, og sammen med user stories har det beskrevet hvordan sider og elementer skal fungere og se ut. Produkteiere og andre ansatte i banken bruker også prototypen jevnlig for å diskutere fremtidige løsninger og justeringer.

Sist, men ikke minst, prototypen sikrer en bedre opplevelse for kundene. Med en klikkbar prototype fra dag én i prosjektet, har det vært enkelt å teste den nye nettbanken på brukere og justere fortløpende gjennom hele prosessen. Minst 80 kunder og potensielle kunder har testet ut prototypen underveis. Dette har gjort at vi har avdekket problemer og bekreftet det som fungerer før noe kommer i produksjon. For å få disse brukertestene enda mer realistisk har vi også bygget inn støtte for flere brukere og kontoer i prototypen, slik at testpersonene ser sine egne kontoer og saldoer (med testpersonenes samtykke, så klart), noe som gjorde at de umiddelbart følte seg mer hjemme i den nye banken.

Men er alt gull og grønne skoger med prototyper?

Det er vanskelig å være uenig i at design i en prototype er en god idé i et prosjekt som dette, men det kan ha sine ulemper på noen områder også.

Når er en side ferdig?

Et viktig prinsipp for HTML og CSS er at elementer henger sammen. Det vil si at om en stil blir endret et sted kan det få konsekvenser for et helt annet sted. Det gjør det lettere å få en konsekvent stil på tvers, men det er samtidig en utfordring å vite hva som er ferdig og hva som er en skisse.

Når en side godkjennes og den plutselig en uke etter ser annerledes ut pga endringer som er gjort andre steder i prototypen, kan det være forvirrende for de involverte. Det har vært tilfeller der en godkjent side har ramlet fullstendig sammen, og vi måtte lete i tidligere versjoner av prototypen for å finne ut hvordan det egentlig skulle være.

Men egentlig synliggjør denne siden ved HTML-prototyping bare et problem som uansett ville vært der. Når stiler endres ett sted, skal det få konsekvenser andre steder. Det å tenke på hver side som sitt eget univers er uansett dårlig designpraksis. Så selv om dette kan oppleves som en utfordring, er det egentlig mer et verktøy for å skape sammenheng i den ferdige løsningen.

Skal prototypen være lik nettbanken?

Som nevnt deler den lanserte banken og prototypen samme stilsett. Dette har forenklet mye av arbeidet med å løfte design fra prototypen ut til kundene. Men det er ikke alltid effektivt å prototype alle justeringer før det implementeres. Noen designjusteringer har skjedd direkte i nettbanken og det er også enkelte funksjoner det ikke har vært behov for å prototype, der utviklerne har tatt utgangspunkt i eksisterende designelementer og kodet direkte fra en teknisk beskrivelse.

Spørsmålet er hva som skjer når vi prototyper videre etter slike endringer. Skal prototypen oppdateres for å gjenspeile det som har skjedd i produksjonsmiljøet? Er det verdt innsatsen? Hva skjer når brukertestene gjennomføres med «utdatert» innhold? Har testene like stor verdi?

Disse problemstillingene er unike for et prosjekt av denne lengden. Vanligvis bygges prototypen for en kortere tidshorisont, og det ligger i kortene at prototypens levetid ikke strekker seg lenger enn lanseringsdato for løsningen. Vi har valgt en pragmatisk tilnærming der vi ikke bruker tid på å holde alt oppdatert i prototypen, men henter over det som trengs for videre designarbeid. Vi gjenskape funksjoner som er laget rett i nettbanken kun når disse skal brukertestes eller videreutvikles. Det å holde prototypen og nettbanken helt identiske ville vært bortkastet tid.

Designer eller utvikler?

Når du jobber med prototyper er det alltid en utfordring å holde blikket på rett sted. Det er lett å henge seg opp i teknisk implementering og hvordan markupen på løsningen skal være, fremfor å ta et skritt tilbake og se hva som fungerer eller ikke. Noen ganger er det smartere å raskt skissere ut ulike løsninger i Sketch og så kode opp den beste løsningen i prototypen.

På enhver ny side som lages må vi ta stilling til hvilket nivå det skal prototypes på. Trengs det logikk slik at data hentes inn fra en bruker, eller holder det å lage ren HTML som et eksempel? Hvor langt skal vi gå for å etterligne innlogging med tanke på brukertester, og når har vi gått så langt at prototypen nesten er en egen nettbank?

Det finnes ikke ett svar her, men et godt prinsipp er å gjøre det enklest mulig til å begynne med, og så heller legge på logikk først når behovet er der. På den andre siden bør man heller ikke vente for lenge med å legge inn hjelpefunksjoner i prototypen eller skille ut elementer som selvstendige komponenter når det er tydelig at kommer til å bli behov for å bruke noe på tvers av løsningen. Det kan ta lenger tid å gå tilbake å rydde enn å innføre et godt prinsipp fra starten, men en opprydning i ny og ne kan også være verdt innsatsen.

Prototyping som suksessfaktor?

Den nye nettbanken til Skandiabanken blir brukt 3 ganger så mye på mobil som den gamle mobilbanken, samtidig som innlogginger via desktop også har økt. I en undersøkelse av mobilbanker i Norge gjort for nettstedet penger.no stakk Skandiabanken av med det lengste strået, til tross for at Skandiabanken var den eneste banken som bare hadde innlogging til sin vanlige nettbank.

Prototypen kan selvfølgelig ikke ta all æren for denne suksessen, men det er ingen tvil om at det har vært svært verdifullt i denne prosessen. Det har gjort at designere har kunnet samarbeide tett med både produkteiere, kanalansvarlige og utviklere hele veien, og at vi har kunnet kontinuerlig brukerteste løsningen.

Av Janniche Øyen og Andreas Øye, Skandiabanken,
Robin Sandborg, Kjell-Morten Bratsberg Thorsen og Marius Hauken, Netlife Research

Marius Hauken

Marius Hauken er en Bergen-basert designer. Han elsker smarte konsepter, nettløsninger og brukergrensesnitt for skjerm.

Flere artikler av Marius CV

2 kommentarer

  1. Hei Marius.

    Takk for at du deler erfaring med prototyping av Skandiabanken. Jeg er selv Skandiabankenkunde og synes mobilgrensesnittet har blitt veldig bra. Bra grensesnittdesign på alle måter, interaksjon, grafikk og struktur. Bra jobba!

    Jeg har en kommentar til blogginnlegget ditt. På spørsmålet ‘Men er alt gull og grønne skoger med prototyper?’ så skriver du at prototyping har ulemper også, for så å avslutte det samme avsnittet med å si at; prototyping bare avslører et problem som uansett ville vært der. Jeg forstår ikke helt hva du mener her, kan du utdype det litt? Hva i så tilfelle er ulempen?

    Jeg synes ditt blogginnlegg er interessant for det tar for seg et spesifikt case som jeg selv er sluttbruker av. Jeg har også skrevet litt om prototyping generelt, og hvorfor jeg tror det fungerer for design av digital produkter – http://blog.makingwaves.no/design/prototype/

    God Jul!

    Håkon

  2. Hei, Håkon!
    Det var kjekt å høre!

    Jeg var kanskje litt utydelig på det området, men poenget er at om vi endrer på et stilsett et sted i prototypen kan dette få konsekvenser, og kanskje brekke designet andre steder. Om dette skjer i produksjon er ikke dette heldig. Dette er nok kanskje litt unikt i vårt tilfelle siden prototype og produksjon faktisk deler CSS.

    Dette problemet kunne nok vært unngått om vi ikke bare delte CSS med produksjon men også templates som f.eks. med React, Angular, Handlebars eller lignende. Dagens prototype er basert på et enkelt php-rammeverk, men om vi skulle begynt på nytt hadde vi nok valgt noe annet her. Nå er jo dette et svært spesielt prosjekt siden prototypen har levd i snart 3 år og templating-teknologien ikke hadde kommet så langt da vi begynte.

Skriv en kommentar

  • *

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>