Slutt med pixelpushing på skisser — design mer med kode
Litt avhengig av utdanning og erfaring, har vi som designere gjerne spisset oss på noen deler av designprosessen. Noen trives best med å jobbe med brukerinnsikt, andre elsker å nerde i Figma med utformingen av grensesnittet. Alle mener noe om design, og andre fagfelt påvirker også i stor grad brukeropplevelsen. Alt fra responstid i back-end til transisjoner i front-end er viktig for opplevelsen. Dette er noe av grunnen til at de fleste virksomheter har innsett at tverrfaglige team med kontinuerlig produktutvikling i mange tilfeller er en bedre tilnærming, enn et prosjekt med en start og slutt-dato.
Som designer mener jeg det er en stor fordel å kjenne til grunnleggende kode. Da forstår du de viktigste forutsetningene som er nødvendig for å bygge et digitalt produkt. Du må ikke nødvendigvis kunne koding, men ha en grunnforståelse slik at du kan ha gode samtaler om brukeropplevelse i teamet. Vis interesse for andres fagfelt — og invitér de inn i diskusjoner som går utover det som står i rollebeskrivelsen din!
Den trygge overleveringen
Alle snakker om at vi må vekk fra overleveringer. Men fortsatt tror jeg mange havner i den fella at folka i teamet fokuserer mest på seg og sitt. Alle har egne arbeidsoppgaver som handler om å gjøre noe klart til noen andre i teamet. For mange designere er det kanskje tryggest å bruke masse tid i Figma for å lage perfekte skisser som er klare til implementering. En skisse er i seg selv en overlevering, da en utvikler uansett må bygge alt på nytt. Design handler først og fremst om prosessen, ikke resultatet. Bruk derfor mer tid på å få til en god prosess, slik at dere er sikre på at dere løser det riktige problemet. Det betyr ikke at skisser ikke har et formål, men bruk det på riktig måte. Den store fordelen med skisser er at det går raskt, og ikke minst gir det oss en mulighet til å teste og å få feedback fra brukere tidlig: Lager vi det riktige produktet? Er det enkelt å bruke? Bør vi justere kursen?
Design handler først og fremst om prosessen, ikke resultatet!
Fremfor å bruke skisser som en mal for implementering, bruk skisser som et verktøy for kommunikasjon, eksperimentering og samhandling. Dette gjør det i tillegg enklere for andre i teamet å ta eierskap til sluttproduktet.
Universell utforming i hele designprosessen
Som min kollega, William, snakket om i bloggposten “5 raske tips for bedre skjermleseropplevelse” — selv om du tilfredsstiller WCAG kravene, så er det ikke gitt at det er en god brukeropplevelse for alle. For å lage gode brukeropplevelser uavhengig av folks evner eller funksjonsnedsettelser må vi jobbe med mye av designet på kode-nivå. F.eks. vil både semantikk og kode-struktur i stor grad påvirke brukeropplevelsen til de som bruker skjermlesere. Dette er det viktig at vi som designere forstår.
Får skjermleserbrukere tilstrekkelig informasjon og feedback på handlinger brukeren utfører? Er tastaturnavigasjon rask og effektiv? Er overskrifter riktig kodet i henhold til det visuelle? Alt dette er mye lettere å jobbe med i et testmiljø hvor du kan prøve seg frem med ulike løsninger.
Jo tidligere du får opp et skall med kode, jo raskere kan du ta tak i disse tingene — som fort kan bli tidkrevende hvis du jobber med det helt til slutt i prosessen.
Og du, ikke fraskriv deg ansvaret og tenk at kode er en utviklers ansvar. Se heller på det som en mulighet til å utnytte hverandres fagområder for å lage bedre løsninger.
Rutine for å designe med kode
I teamet jeg jobber i nå har vi etablert en enkel mekanisme som gjør at vi enklere kan jobbe med løsningen på kode-nivå. Denne rutinen bruker vi når løsningen begynner å bli mer håndfast. Prototyping og testing er fortsatt noe vi gjør i tidlig fase hvis det er hensiktsmessig. Rutinen gjør meg i stand til å teste løsningen på egen hånd i et reelt miljø, før jeg bruker tid sammen med utvikler direkte i koden. Designskissene i Figma er først og fremst for å kommunisere flyt og interaksjon, ikke en bestilling til utvikleren.
Her er stegene i den enkle rutinen vi har etablert:
1. Designer som reviewer i BitBucket: Når noe er utviklet nok til at du kan begynne å ta det i bruk, lager utvikleren et bygg (en pull request) i Bitbucket. Her blir designer, utvikler og tester satt som “reviewer”. Dette gir meg som designer en e-post som sier at nå finnes det noe håndfast som vi kan begynne å jobbe videre med.
2. Dytte bygg ut i testmiljø: For at dette skal fungere uten for mange avhengigheter, har jeg som designer tilgang til verktøyet som gjør at jeg kan få dette bygget ut i et testmiljø (Middlearth). Jeg pusher derfor bygget ut selv, når det passer for meg å se på det.
3. Design og testing: Det er her mye av samhandlingen og utformingen av løsningen skjer sammen med utvikler. Jeg kan bruke tid på se hvordan det oppfører seg på ulike flater og nettlesere. Vi kan begynne å jobbe med brukeropplevelsen for skjermlesere, og med visuelle detaljer. Evt justeringer gjør vi sammen foran skjermen til utvikleren.
4. Godkjenner pull request: Når vi har jobbet oss frem til en løsning vi er fornøyd med, “godkjenner” alle pull request i BitBucket.
Hele poenget med dette er å etablere en rutine som inviterer til samhandling, ikke innføre en potensiell flaskehals.
Bruk mindre tid på å gnikke på detaljer i skisser — og mer tid på å designe løsningen med kode. Da får dere utnyttet tverrfagligheten bedre til problemløsning, alle får et større eierskap til løsningen, og universell utforming blir en mer naturlig del av hele designprosessen!
PS: Vi trenger flere engasjerte designere til å bygge et skikkelig bra fagmiljø i vårt konsulentselskap som er 100% eid av våre ansatte.
