14-Dec

Accessibility, UX, Design and Methodology

Hvordan får vi universell utforming til å bli en del av teamhverdagen?

Universell utforming. Vi vet alle hva det er, vi vet alle at det er superviktig - og riktig! - å få til, og vi snakker om det hele tiden. Og den aller vanligste måten å jobbe med det på, er fremdeles som tunge skippertak en gang i mellom. Hvordan får universell utforming til å bli en del av teamhverdagen?

3 min read

·

By Linda Christin Halvorsen

·

December 14, 2022

Det åpenbare svaret - som jeg også hører fra designere og utviklere når jeg spør om hvordan de håndterer uu i løsningen sin i hverdagen - er at "de må tenke på det på hver oppgave, og hver gang de slipper noe ut i prod: har vi sikret uu på dette?"

Og det høres så såre enkelt ut. Men hadde det vært så enkelt, så hadde vel ikke løsninger likevel vært så mangelfulle på når det kom til universell utforming? Så hva er det som kommer i veien for at vi faktisk sikrer det løpende?

Jeg har to hypoteser:

1. Tverrfaglighet smerrfaglighet
Det jeg synes jeg hører absolutt oftest fra designere når vi snakker om uu, er: "...men det er liksom utviklerne som må gjøre det". Og så vaskes det hender overalt ut i fra det. Og ja - opprettholdelsen av uu krever riktig koding. Men hva ved brukeropplevelse gjør vel ikke det?

Og så er jo tverrfaglighet i seg selv fremdeles vanskelig i mange team. Jeg ser fortsatt boards hvor design basically har sin egen kolonne, eller egne "brukerhistorier", og designere som sukker over at de blir sittende uten så mye å gjøre "fordi utviklerne utvikler". Det er ordentlig vanskelig å spenne over faggapet - eller egentlig å fylle det, sånn at det ikke oppleves som et gap. Måten man snakker sammen på, og deler ansvar og utfører ting sammen på, krever konstant øvelse. Og når det er vanskelig for oss i de fagene vi er så godt kjent med - da er det ikke så rart, kanskje, at det blir vanskelig med uu, som vi vel alle er ganske usikre på, alle sammen.

2. Universell utforming er et "sjekkpunkt"
Jeg tror uu er litt som måling: i et halvmodent team, så snakker vi om det, og minner oss selv på at "det må vi gjøre" - men så er det forbanna vanskelig å likevel gjøre det. Det blir stående som en egen oppgave eller aktivitet - og dermed kan den også prioriteres opp eller ned.

I et team som er modent på måling, er måling helt integrert i teamets hverdag. Da er det ikke et eget punkt på en liste, og hvert fall ikke en egen kolonne i et board - for teamet prater om det hele tiden, det er selvsagt at ting måles, og hver funksjonalitet bygges med målingsbehovet i tankene. Det blir en del av flyten. Det kan fortsatt prioriteres opp eller ned, men det prioriteres integrert med funksjonalitesprioriteringen. Jeg tenker at uu er litt det samme. I ordentlig modne team på uu, er ikke "uu" på et område en oppgave som må assignes noen. Det er ikke noe som må stå på en liste som må krysses av. Det er mer som måling eller sikkerhet - når du utformer løsningen som designer, er det en integrert del av arbeidet du gjør, og når det implementeres i kode, er det en integrert del av tankene du gjør deg. Og det diskuteres sømløst som en del av utforming og utvikling av funksjonaliteten - ikke som en separat greie.

Hva tror dere?
Stemmer hypotesene? Eller er det noe helt annet som kommer i veien?