Hva bør en designer kunne?

For en drøy måned siden satt jeg i kantina vår i Skur 39 og hørte Fredrik Matheson rante om faget vårt – ux-faget – fra scenen på Fryd. Det er ungt, det er udefinert – og han slengte ut en påstand jeg tok som en utfordring: «vi vet ikke en gang hva vi bør kunne som ux’ere – i hvilket annet fag er det sånn?»

Hm, tenkte jeg. Er det sånn? Vet jeg virkelig ikke hva en ux’er bør kunne? Jeg som ikke så sjelden vurderer folk på intervju, jeg er med på å ta i mot nye kull designere hver høst og gir dem en innføring i jobben deres før de sendes ut til kunder – vet ikke jeg hva en ux’er bør kunne? Og mens jeg satt der og tenkte, sank det i meg. For det er sant, som Fredrik sier (som det jo ofte er), at vi har ingen klare parametere å vurdere kandidatene etter, ingen sjekkliste å krysse av på av de ulike evnene og kunnskapene som trengs i jobben vår, ingen liste vi går igjennom når vi setter opp oppstartsopplegget vårt hver høst for å passe på at alle får den faglige inputen vi mener de trenger for å kunne gjøre jobben sin. Ingen liste i Bekk, og ingen i bransjen vår. Hekk, vi er jo knapt enige om hva ux egentlig innebærer, eller hva som er riktig tittel på oss.

Men, tenkte jeg. Det er jo ikke helt fritt vilt heller. Det er jo ikke hva som helst eller ingenting som definerer oss. Og jeg har jo en følelse, om ikke en distinkt bevissthet, av hva en god ux-designer gjør og er god på. Og typisk nok, når jeg hører Fredrik rumle om fag og filosofi, får jeg en idé.

Jeg burde jo kunne beskrive litt mer eksplisitt, den «følelsen» av hva en designer bør kunne.

Åpenbart ikke som noe forsøk på en objektiv fasit – siden problemet er at vi nettopp mangler det. Men som en subjektiv formening, i en rolle hvor jeg ansetter og oppdrar designere – det bør jeg jo rett og slett ha. Om ikke annet for å bli mer bevisst hva som skal til for å levere det vi trenger å levere. Og som en god designer, har jeg ingen problem med å ta en idé og la den leve litt før jeg låser meg til en løsning! Så her begynner jeg bare på noe, tenker jeg, og så skal jeg la det få småkoke en god stund, og foredles over tid. Nå er tankeprosessen i det minste i gang. Takk, Fredrik!

Min foreløpige liste over de grunnleggende tingene jeg mener en designer* må kunne:

Uten å forstå eller å kunne jobbe med brukeradferd, stopper nesten alt en ux-designer gjør, opp. Det er kjernen i brukersentrering: å kunne kartlegge og tolke brukerbehov, beskrive behov og adferd, og så kunne designe for å dekke behovene og påvirke adferden.

Planlegge, gjennomføre og oppsummere brukerintervjuer og brukerobservasjon. Både av folk som bruker tjenesten du jobber med og ikke, som utviser adferden du skal påvirke og ikke. Når du oppsummerer funn, øv deg på å syntetisere, ikke analysere – øv deg på å sette enkeltdelene du finner sammen til et helhet, heller enn å liste ut enkeltfunn.

Det mangler vel et godt norsk ord for det, men altså et objekts uttrykk for hvordan det kan bli brukt. Som et dørhåndtak som tydelig viser om du skal dra eller dytte på døra for å åpne den. For alle oss som jobber digitalt, blir det jo spesielt to-dimensjonal visuell affordance vi må være gode på. Og tatt helt ut i det ekstreme kunne man kanskje sagt at på en nettside med perfekt affordance ville man aldri trengt å ha en ledetekst eller label på noenting. Det blir selvfølgelig tullete å si – det er jo ikke som om vi hverken kan eller skal fjerne tekst fra nettsider og digitale løsninger. Men jeg tror det er et symptom på designet ditt at det ikke har god nok affordance, om du tar deg selv i å designe inn mye tekstlig forklaring på elementene en bruker skal interagere med.

Brukertesting. Helt standard, formelle brukertester, hvor du lager et testoppsett med oppgaver, observerer opp i mot 10 forskjellige brukere prøve å løse oppgavene, hører hva de sier når du ber dem tenke høyt, og ser hva de sliter med og ikke. På både dine egne og andres løsninger. Sitter du ikke selv og designer på noen løsninger akkurat nå? Velg en hvilken som helst løsning, klikk deg igjennom, gjør deg opp en formening om hva som virker som viktige oppgaver å få løst gjennom løsningen, og kjøre en brukertest. Du kommer til å lære så mye!

Og når jeg først er inne på det med brukertesting: ikke glem å brukerteste for universell utforming. Å krysse av for kravene er en ting…og mange av oss outsourcer det rett til frontend-utviklerne om vi kan. Men du vet like godt som meg at den rampa arkitekten overlot til entreprenøren å fikse, for å etterleve kravene helt i siste liten…den gjør ikke helheten noen tjeneste. Om noen få uker begynner i uu-faggruppa her i Bekk, og det skal være min misjon gjennom 2022 å få brukertestet mer på uu, sånn at jeg virkelig kan lære meg hva som er en godt universelt utformet løsning og ikke.

Ja – du må være god på prosess. Det er sjelden vi jobber med utfordringer som er så enkle at du bare kan se på det, tenke deg litt om, og komme opp med svaret – ferdig. Enkeltproblemer i en løsning eller landskap du kjenner godt, kan helt klart løses gjennom å trekke frem svar fra erfaringsbanken…men tjenestene vi jobber med som helhet – de må vi kunne følge opp prosessuelt. Hva er riktig prosess? Det kommer selvfølgelig an på hva du skal levere, og teamet du jobber med. Men helt generelt vil jeg si, at som designer, må du kunne vite når det er riktig å utvide perspektivet og scopet, og når det er riktig å snevre det inn. Du må ha koll på din egen «double diamond» (som i den kontinuerlige leveranse-verdenen jeg lever i, egentlig er en rekke med ruter som aldri slutter) – du må vite når du skal åpne opp, og når du skal trekke sammen. Og så må du kunne involvere andre i denne rytmen. Dermed blir også fasilitering en del av det å kunne prosess. Igjen – det er sjelden jeg og mine kolleger jobber med oppgaver som er så enkle å løse at det holder at jeg setter meg alene og tenker og designer i vei, og kommer ut med svaret og kan be andre implementere det. Så å få til å få med seg andre på prosess er helt vesentlig for å kunne bidra godt som designer.

Tja. Jeg vet faktisk ikke. Vi lærer jo vår isolerte design-prosess på skolen, mange av oss – og den har mye fundamentalt bygd inn i seg som vi får bruk for videre. Men så møter vi jo ofte en utviklingsprosess vi ikke helt har fått innsyn, der noen andres håndverk må styre i vel så stor grad som vårt. Og hva kan vi gjøre da, for å bli flinkere?

Jeg har veldig stor tro på refleksjonens kraft. Å tenke gjennom hva jeg gjør – og burde gjøre. Når jeg møter et team, en utfordring, et selskap, et domene, en oppgave…å tenke gjennom hvordan jeg vil levere på det, og finne frem til en løsning eller et svar, det hjelper meg. Å forestille meg hva jeg skal gjøre – både på kort og lang sikt, det er en slags øving.

Og – jeg tror jeg har fått øvd på prosess gjennom å skrive tilbud på konkrete oppdrag. Når jeg må telle antall folk jeg tror vi må være, liste opp aktiviteter jeg mener vi bør gjøre, og telle uker jeg tror det tar…ja, da får jeg tatt en ny runde på å bli bevisst hva jeg gjør, og hvorfor.

Retroer kan også hjelpe. Mange team-retroer handler fort om enkeltpunkter som har fungert bra og dårlig – men de kan også være tid vi tar oss for å snakke mer helhetlig om hvordan vi jobber. Hvordan flyter egentlig en brukerhistorie gjennom boardet vårt? Hva er egentlig ruter-rytmen vår? Diskuterer vi nok, diskuterer vi for mye? Kvalitetssikrer vi? Når og hvordan måler vi effekt?

Snakke om det, og så gjøre det, og så tenke over det. Det tror jeg er viktig.

Å! Og hold workshops! En workshop kan representere en mini-prosess; det finnes en eller annen utfordring som skal løses, det er noen aktiviteter vi må gjøre, og det er et eller annet resultat vi skal ha ut. Øv deg på prosess gjennom å planlegge workshoper – tenke igjennom hvilket resultat vi trenger, kvalitetssikre at det er riktig. Tenk på og test ut hvilke aktiviteter som kan bidra til det resultatet, og hvilke folk som må være med. Planlegg tidsbruk – og reflekter etterpå om det ble riktig, eller hvordan du bør justere det til neste gang. Og kjenn etter, når workshopen er over, og du har levert resultatet av den, om den funka, eller hva du kunne gjort bedre.

Du må kunne følge opp løsningen eller tjenesten din når den er tatt i bruk, og se om den faktisk gir det resultatet du trenger. Nei, jeg snakker ikke om brukervennlighet her – jeg mener faktisk endring i folks adferd eller forretning eller resultat. Det er mer konkret enn «folk er mer fornøyd nå enn før», men ikke nødvendigvis å peke på et resultat på en bunnlinje et sted heller. Det handler om å før du går i gang med å designe noe, å vite hvorfor en tjeneste eller løsning skal lages overhodet. Om svaret ikke finnes allerede, må du hjelpe til med å finne frem til det selv. Du må kunne definere hva en løsning skal gjøre – sånn at du kan sjekke etterpå om det gjør det. Et bra design er et design som løser et problem – på en god måte. Så du må ha koll på problemet, og du må kunne sjekke om problemet er løst etterpå, for å vite om du har gjort jobben eller ikke.

I det vi holder på med, er ikke nødvendigvis «problemet løst» ved første prodsetting. Oftere er vi på vei mot god problemløsning (forhåpentligvis), og må jobbe kontinuerlig for å stadig nærme oss et mål langt fremme. Det er for enkelt å «digitalisere» - lage en digital løsning der det før bare var papir, peke på løsningen når den er ferdig og si seg fornøyd. Den faktiske digitaliseringen har skjedd når en kritisk masse faktisk får gjort den effektiviseringen eller kvalitetsheving løsningen skal bidra til – det holder ikke at det bare «finnes en app for det». Er det ingen som bruker appen, er vi like langt.

Å sette effektmål som er relevante, som lar seg måle, og som vi kan styre etter er vanskelig. Det krever øving. Som designer bør du som minimum være bevisst betydningen av effektmåling, og klar over at jobben ikke er gjort før effekten er vist (men det er også bra å vite når det er på tide å gå videre). Du bør sette deg inn i hvert fall ett av de vanligste verktøyene for måling av adferd på nett, og kunne gjøre noen analyser på de viktigste tallene. Hva er de viktigste tallene? Det er her det hjelper å ha satt seg inn i hvilket problem det du lager egentlig skal løse. Svaret ligger der et sted.

Les litt teori om det. Jeg er egentlig ikke en forkjemper for veldig teoretiske øvelser når det kommer til design – jeg definerer design aller mest som et håndverk som må praktiseres. Men i alle håndverk er det noe teori – og hvordan konverteringsmålinger fungerer, og hvordan trafikk på en digital løsningen måles i de vanligste verktøyene…jupp, det er noe teoretisk kunnskap der du kan lese deg opp på, enkelt og greit.

Les deg også opp på OKR. Bare gjør det. Gjør det sånn at du skjønner hva det er snakk om når produkteieren din sier at de har fått beskjed om at nå skal alle følge det. Gjør det sånn at du har et utgangspunkt for å diskutere hva OKR’ene kunne vært for løsningen eller tjenesten du og teamet ditt jobber med nå. Og ikke gift deg med det konkrete rammeverket OKR. Husk på at det handler om målstyring, som generelt er bra, for det definerer hensikten med det vi gjør – og det trenger du som designer, og at det handler om å måle effekten av det vi gjør – som forteller deg om vi er på vei mot den hensikten.

I tillegg til å utøve det! For det er jo et håndverk. Sett deg noen mål, bittesmå, men konkrete, og begynn å måle dem allerede nå.

Det er et fryktelig dårlig ord. Forferdelig. Det er så lite presist. Så her må du virkelig bare være med på at denne listen bare er en idé i startgropen, om du skal greie å bli med videre. Det jeg mener, er:

Lær deg å forstå hva markedsdriverne er, for den bransjen selskapet du skal hjelpe. Om du jobber hos en virksomhet i det offentlige: forstå den grunnleggende forvaltningen av den etaten du jobber hos – hva styrer prioriteringene der? Hvordan påvirker politikken din etat? Lær deg å kartlegge – helt overordnet – hva som er de største truslene eller utfordringene for selskapet (uten å glemme at det finnes folk kan det veldig mye bedre enn deg). Ha et (forenklet og overordnet) bilde av hva som driver kostnadene der, og hva som representerer inntjening eller måloppnåelse. Dette vil hjelpe deg å velge ut de ideene som gir mest verdi. Å vurdere hvilke forslag som vil bidra best til det mandatet eller strategien virksomheten styrer etter.

En enkel swot-analyse er ofte veldig opplysende. Om du kan – gjør den med en fra forretningssiden, sånn at du får utvidet perspektivet på hvilke potensielle styrker og svakheter, muligheter og trusler som kan finnes. Dra opp verdikjeden for det du jobber med – og i stedet for å fokusere mest på hva sluttbrukeren ønsker seg, ta innover deg hva det krever av virksomheten å levere. Og ikke minst: snakk med folk i lederroller der du er om det de holder på med og er opptatt av. Ikke hva de ønsker seg av digitale løsninger – men hva de holder øye med, hva de rapporterer på, hva de bekymrer seg over, og hva de feirer.

Som ux’er må du kunne gjenkjenne helt enkle komposisjonsregler. Gjenkjenne balanse, gjenkjenne proporsjonalitet, gjenkjenne visuelt støy. Og huske på at det er et eget fagfelt. Vi gjør oss selv en bjørnetjeneste som designere når vi prøver å dekke for bredt i stedet for å be om at flere kommer til for bidra med det de kan.

Diskutér det visuelle med en grafisk designer/visuell designer - ofte! Få dem til å beskrive hva de ser, og legg merke til hvilke ting de fokuserer på og kommenterer. Å jobbe med flinke grafiske designere er det som aller mest har hjulpet meg.

Åkei - her er det altså. Mitt første utkast på hva jeg mener en ux-designer bør kunne. Den må itereres på. Det vet jeg. Det må ideer alltid. Men det har hjulpet masse å bare begynne å tenke på det! Og det neste jeg vet jeg kommer til å trenge nå, er å diskutere det og få innspill. Så: hva tenker du? Hva mener du er kjernekompetanse vi ux-designere må ha?

*Designere kommer i mange ulike varianter – innen for mange ulike fagfelt. De jeg tenker på i denne artikkelen er de som glir mellom rollene tjenestedesignere, ux-designere, strategiske designere, business designere, interaksjonsdesignere og design researchere…du vet, de på det brede spekteret der, som ofte ikke helt vet hva de er.