5 tips til samarbeid mellom utviklere og designere

Vi er Jesper (designer) og Solveig (utvikler). 

For to år siden var vi med å starte opp et tverrfaglig produktteam, med både utviklere og designere, som skulle jobbe med Læremiddelkatalogen – en oversikt over digitale læremidler for grunnopplæringen.

Gjennom disse to årene har vi funnet ut av hva som får samarbeidet mellom utviklere og designere til å fungere best mulig. 

Her er fem ting vi skulle ønske vi visste da vi startet opp teamarbeidet vårt.

#1: Involver hverandre tidlig i prosessen 

Det finnes mange ulike metoder for å jobbe med prosjekter på. 

Du har den klassiske fossefallmetoden, som ofte fungerer slik: lederen setter mål, designeren leverer skisser, og til slutt implementerer utvikleren det designeren har laget. Du har også den litt mer smidigere varianten, med de samme tre fasene som i fossefall i tillegg til en justeringsfase på slutten. 

Felles for disse metodene er at de er veldig oppstykket, og gjør samarbeid vanskelig.

I vårt team har vi valgt å jobbe sammen i alle steg av prosessen. 

En designer, utvikler og produktleder setter mål, vurderer brukerbehov og ser på tekniske muligheter sammen – før vi begynner.

Derfor fungerer det:

• Man kan ta opp problemer og utfordringer før man starter arbeidet 

• Man får eierskap til det man skal jobbe med, og føler seg som en viktig del av arbeidet fra start 

Ting å tenke på:

• Det kan være tidkrevende å være med på alt, så vi løser det med å bytte på hvilken utvikler og designer som er med i de ulike stegene i prosessen.

#2: Design stopper ikke når kodingen starter 

Vi har tråkket rett i overleveringsfellen der Jesper har designet store, fine og detaljerte skisser som han sendte til Solveig. Så oppdaget Solveig tekniske hindre som gjorde at skissene ikke kunne implementeres. 

Da måtte designet justeres på nytt, og kodingen ble satt på vent frem til designet var klart. Dette tok lang tid, og var lite smidig. 

Nå jobber vi mye mer iterativt. Når vi har identifisert et brukerbehov, jobber vi tett sammen for å raskt finne en løsning. 

For eksempel da vi skulle lage filterfunksjonalitet i Læremiddelkatalogen. Vi visste at lærere ville filtrere på ulike ting når de leter etter digitale læremidler til bruk i undervisningen, men vi visste ikke helt hva de ville filtrere på.

I stedet for å lage en komplett ferdig prototype, startet vi med en skisse av et søkefelt og filtrering på fag. Deretter startet Solveig å kode, selv om bare en del av løsningen var ferdig designet. Samtidig jobbet Jesper videre på designet.

Derfor fungerer det:

• Vi kan teste deler av løsningen raskt.

• Designeren får innsikt i det tekniske tidlig, og kan dermed lage skisser som faktisk er mulig å implementere. 

• Utvikleren slipper å vente på at designet skal være ferdig før de kan starte på sin jobb. 

Ting å tenke på:

• Det kan være vanskelig å se helheten av det man lager og hvordan ting påvirker hverandre når man jobber på denne måten.

Lar team bestemme selv, «uten estimering, planning, retros»

– Slik frihet krever mye tillit, men fostrer eierskap, engasjement og innovasjon, skriver Runar Halse i Conta, om å jobbe i selvorganiserende team.

 #3: Parprogrammering er ikke bare for utviklere 

Parprogrammering forbindes ofte med at to utviklere sitter sammen og skriver kode. 

Vi har testet samme metode mellom utvikler og designer, og det har fungert veldig bra for oss. 

Det betyr ikke at designeren skriver kode, men det betyr at vi sitter sammen når vi lager funksjoner og grensesnitt.

Solveig forklarer hva hun gjør og hvorfor ting må gjøres på en bestemt måte. Da kan Jesper se hvordan designet fungerer responsivt og foreslår justeringer der og da.

Derfor fungerer det:

• Designer og utvikler slipper å sende oppgaver fram og tilbake mellom seg. 

• Designeren kan enkelt forklare skissen, og hvilke problemer den skal løse. 

Ting å tenke på:

• Det kan være høy terskel for å starte å parprogrammere, men det er absolutt verdt det.

• Ikke alle oppgaver egner seg for denne måten å jobbe på. De tunge backend-oppgavene kan utvikleren ta uten designeren. 

Demoer, fagdager og hackathon holdt ikke – dette ble løsningen

Demoer, fagdager og hackathon var ikke nok for Fremtind. Sercan Leylek forklarer hvorfor de heller begynte med hospiteringsdager.

#4: Det meste er mulig, men alt har en kostnad

Ofte kan designere ønske seg store, kompliserte løsninger. Noen ganger lønner det seg, andre ganger koster det mer enn det smaker.

For eksempel da Jesper ville ha filterknapper med tall på søkesiden for læremidler i Læremiddelkatalogen. De skulle vise antall treff per filter, og oppdatere seg etter hvilke filtre som var aktive. Pent, men veldig kostbart. Solveig sa derfor nei, og foreslo at dette kunne vente, ettersom det ville kostet mer enn det ville gi av nytte akkurat nå.

Men noen ganger er det verdt å lage de kompliserte løsningene, nettopp fordi de gir mye verdi til brukeren. Da er det viktig at designere utfordrer utviklere som sier nei. 

For eksempel da vi diskuterte sidevisning versus vis mer-knapp. Solveig ville bruke sidevisning, fordi det var mye enklere å løse teknisk, og fortsatt en god løsning. Men Jesper mente at en vis mer-knapp var bedre for lærerne som skulle bruke katalogen og behovene deres. Dermed lagde Solveig en vis mer-knapp i Læremiddelkatalogen.

Ting å tenke på:

• Det er viktig å snakke om kostnader tidlig, da unngår dere å forelske dere i løsninger som ikke lønner seg. 

• Noen ganger er brukerbehovet viktigere enn hva det koster å lage funksjonalitet. Da er det viktig at designere tør å utfordre, og at utviklere kan være åpne for å gjøre ting på en annen måte. 

– Har du sittet i et møte og lurt på hvorfor du er der?

– Men hva om vi kunne gjøre møter til effektive verktøy for samarbeid og fremgang? spør Maria Kamara, og har en metode.

#5. God kommunikasjon er viktig 

Til syvende og sist handler et godt samarbeid om å kommunisere godt sammen.

Det er viktig at designere og utviklere lett kan prate sammen. Vi sitter faktisk rett ved siden av hverandre, og trenger bare snu oss for å ha en samtale. Akkurat det er kanskje ikke mulig for alle, men da er det viktig å bygge en kultur der man prater med hverandre.

Hos oss er for eksempel designerne med i standups for utviklere. Der prøver vi å gi designerne et innblikk i hva det er utviklerne driver med, på en så forståelig måte som mulig.

Designerne tar også med seg utviklere i design-aktiviteter. 

For eksempel er det alltid med en utvikler på brukertester og brukersamtaler. 

På denne måten får også de med seg brukerperspektivet inn i arbeidet.

Et godt samarbeid kommer ikke av seg selv 

Et knirkefritt samarbeid mellom utviklere og designere kommer ikke av seg selv. 

Involver hverandre tidlig, jobb iterativt, parprogrammer når det passer, snakk om kost versus nytte, og prat sammen. Da har du et solid fundament for et godt samarbeid.

Velg ett av tipsene og test det i neste sprint. Evaluer, juster og behold det som gir mest verdi for deg og teamet. 

Så håper vi erfaringene våre fra Læremiddelkatalogen kan hjelpe dere i gang! 

Mange norske utviklere snakker aldri med designere

– Ledere må forstå verdien av å inkludere designere i teamene, skriver Ligia Rekkedal og Anna Steinsund, etter å ha samla inn overraskende tall.