Vi er to nyutdannede interaksjonsdesignere fra UiO som startet å jobbe hos Bekk i august. Fra tiden på skolebenken hadde vi lite erfaring med smidige team, og vi gikk derfor inn i arbeidslivet med nysgjerrighet for hvordan det å jobbe smidig fungerer i praksis. I denne artikkelen prøver vi å svare på noen spørsmål vi hadde før vi startet.
I Bekk bruker vi begrepet “kontinuerlig design” for å omtale en designers rolle i smidige team. Dette begrepet viste seg å innebære en ganske stor omveltning fra den tradisjonelle designprosessen, slik vi kjente den fra skolen. Den klassiske designprosessen består gjerne av flere steg man kan følge i en viss rekkefølge. For eksempel kan en typisk design thinking-prosess bestå av fem faser; samle innsikt, definere, idégenerere, prototype og til slutt teste. Stegene skal så klart itereres, men fungerer likevel som tydelige, definerbare faser. Det er trygt og godt. Sånn er ikke kontinuerlig design. I kontinuerlig design er mange baller i luften samtidig uten en helt åpenbar oppskrift å følge. Det er fordi omstendighetene kan endre seg så fort at det ikke er hensiktsmessig med en detaljert oppskrift. Raske endringer kan være utfordrende for hvem som helst, men kanskje spesielt for en som er ny i arbeidslivet og ikke har mange års erfaring å lene seg på.
Etter snart 5 måneder i arbeidslivet er vi mange erfaringer rikere og ønsker å dele våre tanker rundt noen store spørsmål vi hadde i begynnelsen. Kanskje det er nyttig for deg som student eller for deg som ikke er helt fortrolig med designrollen i et smidig team?
Er dette døden for detaljerte skisser?
Det tar lang tid å lage detaljerte skisser. Noen ganger er det ikke verdt det, og i et smidig team er det kanskje ikke nødvendig. Vi tror det er lurt å tenke aktivt på hva skissene skal brukes til. Enkle skisser kan være nyttige ved brukertester for å demonstrere et konsept. Av og til er detaljerte skisser nødvendige for at du som designer skal kunne se hvordan sluttresultatet blir – eller for å brukerteste detaljer. Dessverre har vi også erfart at detaljerte skisser kan få uheldige konsekvenser hvis det benyttes i feil situasjon. En veldig detaljert skisse ser gjerne ut som “ekte” vare og kan fort sette forventningene til ulike stakeholders for høyt. Det er verken kult for deg eller ditt team å ikke kunne møte disse forventningene. Vi har opplevd at ved å tenke aktivt på hva skissen skal brukes til, går vi ikke i den fellen.
PS: Siden penn og papir er litt vrient å dele digitalt anbefaler vi Sketchy Wireframes for Figma for å lage enkle skisser digitalt.
Har man tid til å lage kule brukeropplevelser?
Fokuset i smidige team er å få funksjonalitet fort ut til brukeren, slik at man kan begynne å måle og lære av reell bruk. Slike kontinuerlige leveranser skal gi verdi til både brukere og kunden. Ovenfor teamet og stakeholders kan det være vanskelig å argumentere for å bruke tid på det som tilsynelatende “bare” er en liten animasjon. Hvordan kan man da prioritere å designe for kule brukeropplevelser?
Dette synes vi er en vanskelig problemstilling som vi på ingen måte har funnet et fullstendig svar på. Men vi har forsøkt å stille oss selv spørsmålet “Hva kan jeg gjøre her med den tiden jeg har for at brukeropplevelsen kan løftes?”. Om du er alene som designer i et smidig team kan dette spørsmålet havne i bakhodet av og til. Da kan det være nyttig å hente inspirasjon fra andre designere. Det skal ikke mer enn en kjapp videosamtale til for å få innspill som kan løfte brukeropplevelsen. Har man ikke andre designere til rådighet kan man også invitere andre på teamet til en liten idégenereringsrunde. Vi har begge opplevd at det aller viktigste er å få et annet perspektiv enn ditt eget når man står fast og har dårlig tid. Det er også mulig å sette av en viss mengde av prosjekt-tiden til “hackaton” hvor du sammen med utviklerne kan bruke tid på å for eksempel lage kule animasjoner eller finpusse tekstene.
Hvordan kan man være så mye nedi “grøten” og se det store perspektivet samtidig?
Å være en designer i et smidig team betyr blant annet å følge oppgaver som utviklerne jobber med, samtidig som man planlegger hva som skal gjøres i neste sprint. Dette gjør at man blir sittende mye med enkeltoppgaver og små funksjoner i produktet. Vår opplevelse har vært at vi av og til glemmer å løfte blikket opp og se det store bildet av hvor produktet er på vei.
Hvordan tar man seg tid til å løfte blikket i en stressende hverdag? For å gjøre det har vi sett oss nødt til å ta en fot i bakken innimellom for å vurdere om det vi lager nå ivaretar målet til teamet. Sett gjerne av en halvtime med produkteier, utviklere eller noen andre på teamet kan være til hjelp for å forsikre seg om at du er på riktig vei.
Kort oppsummert kan vi si at å være designer i et smidig team betyr å være på forskudd, og se både detaljene og det store målbildet samtidig. Slike ferdigheter krever erfaring og det vil også variere hvordan man håndterer dette i ulike team, kunder og domener. Det er viktig å være tilpasningsdyktig, jobbe raskt og samtidig klare å sette av tid til å designe for gode brukeropplevelser.
Planen var egentlig å skrive noe om designsystem i smidige team, men i kjent studentstil er denne artikkelen produkt av et skikkelig skippertak. Kanskje vi er kvitt studentvanene neste år? God jul!🎅
Takk Anna og Live for gjennomlesning og støtte!