Uu-podcasten: Ulik

Introduksjon

Erling: God dag, Anders. Vi skal snakke med Pål Eirik Paulsen. Hvem er det?

Anders: Det er en fyr som leder designgjengen i Sopra Steria i Stavanger. Han er opptatt av universell utforming og har litt engasjement rundt det i Sopra Steria. Han skal forhåpentligvis fortelle oss litt om hvordan de jobber der.

Erling: Nå later du bare som, for vi har jo spilt inn dette etterpå.

Anders: Åkei, hehehe!

Erling: Vi vet jo hvordan de jobber i Sopra Steria.

Anders: Så vi skal ikke fake noe her altså.

Erling: Vi prøver ikke å skjule at vi spiller dette inn etterpå. Dette blir en veldig kjekk samtale. Skal vi bare gå igang?

Anders: Ja, det gjør vi.

Indisk podkast

Anders: Du nevnte innledningsvis, noe vi ikke kan slippe, du har vært med i en indisk podkast?

Pål Eirik: Ja, i fjor vår. En indisk podkaster som heter Tejj. T E J J.

Anders: Dobbel J?

Pål Eirik: Ja, mulig han bare kaller seg det. Han har en podkast som heter Nodes of Design, der han har gjester fra hele verden. Ganske profilerte gjester, av og til. Ikke Mark Zuckerberg, men litt halvkjente. De jobber gjerne i Facebook eller Google.

Anders: Og hvordan havner du inni der?

Pål Eirik: Pure luck. Jeg fikk kontakt med ham via Linkedin, og så begynte det der.

Funksjonell design

Pål Eirik: Jeg er veldig interessert i funksjonell design.

Anders: Hva er det?

Pål Eirik: Det er en hel måte å tenke på som ikke er så opptatt av det estetiske. Mer opptatt av å lage noe som faktisk kan brukes. Det faller veldig inn i dette med uu òg. Det funksjonelle perspektive er det jeg har med tanke på uu. Faktisk få det til å virke, få det til å virke for alle. Det er det kjekke med uu.

Anders: Da er mitt spørsmål. Hva er ikke-funksjonell design? Er det da design?

Pål Eirik: Jeg skiller mellom funksjonell design og estetikk. Funskjonell design hører hjemme i dette med å få empati med sluttbrukeren og faktisk bli kjent med han eller hun. Finne ut hva de skal med løsningen. Hvilken oppgave skal de løse. Hva prøver de å oppnå? Når den delen sitter, når du har laget en god prototype som faktisk løse problemet rent funksjonelt, så er det ikke noe problem etterpå å få det til å se veldig bra ut. Da kommer det estetiske på etterpå, for å løfte det funksjonelle enda mer, til en veldig god brukeropplevelse.

Erling: Jeg liker den distinksjonen, for vi sliter jo med å forklare folk at design inneholder så mye mer enn estetikk. Ved å ha den foran, funksjonell design, så vil vi gjerne ha det spørsmålet – hva er da ikke funksjonell design? Det handler gjerne om estetikk for estetikkens del. Og så må vi annerkjenne rollen til estetikk. Det har en funksjonell rolle det òg, vi må ikke undergrave det helt.

Anders: Det ene utelukker ikke det andre.

Erling: Nei. Funksjonell design inneholder òg estetisk design, men med funksjonelle komponenter.

Pål Eirik: Jeg liker det sitater som sier «Design is art with a job to do». Jeg vet ikke hvem som sa det.

Erling: Det har jeg òg hørt, men jeg husker ikke hvem som sa det.

Anders: Det har ikke jeg hørt, den var fin.

Pål Eirik: Når du lager noe som faktisk skal brukes til å utføre noe.

Indisk podkast

Anders: Hvordan gikk det med den indiske podkasten din?

Pål Eirik: Det gikk ganske bra. Jeg var godt forberedt.

Erling: Fikk du spørsmål på forhånd der, slik som vi nektet deg?

Anders: Hehe!

Pål Eirik: Ja, jeg fikk på forhånd, så det gjorde det litt enklere. Men han er streng på tid, så det måtte være på poenget. Etterpå gjorde han 400 klipp.

Erling: Hva klipper han da?

Pål Eirik: Det er mye små …

Erling: Det jeg kaller forfengelighetsklipp? Små pauser?

Pål Eirik: Ja. Kremting. Ting som ikke var et svar, som bare ikke ble til noe.

Erling: Her beholder vi alle kremtingene, bare så det er sagt.

Anders: Nå er ikke vi en stor produksjon heller, vi skal ikke ut til hele verden.

Erling: Hva var spørsmålene? Hva snakket dere om?

Pål Eirik: Han spurte om metoder som jeg har når jeg jobber med funksjonell design. Hva det er. Det handler om å gjøre en god empatijobb i starten, å jobbe med brukerhistorier og user story mapping. Prototyping. Testing. Sørge for at du faktisk jobber funksjonelt med det du holder på med.

Erling: Så kan vi dra det inn på emnet her, hvordan ivaretar du uu i funksjonell design?

Funksjonell design og universell utforming

Pål Eirik: Det er dét jeg har tenkt, å virkelig ha empati er jo uu. Det å prøve å sette seg ned i stolen til én som gjerne ikke ser så godt, hører så godt, eller har andre funksjonsnedsettelser. Prøve å tenke hvordan han eller hun vil oppleve denne løsningen. Det er den optimale testen på empati, egentlig. Hvis du ikke har tenkt på det, så kan du ikke si at du jobber så veldig godt med empati. Da har du laget en løsning som ikke passer for mange mennesker. Det er litt dumt.

Erling: Når du sier «empati», hva legger du i det?

Pål Eirik: Det er jo det å stå i situasjonen som brukeren står i. Ha skoene til brukeren på. Brillene eventuelt.

Anders: Hatten òg kanskje?

Pål Eirik: Hatten òg! Nå har jeg akkurat fått meg briller. Jeg ser jo ikke så godt lenger. Hvis jeg skal teste noe, så kan jeg ta på meg veldig sterke briller. Da vil jeg se, hva er det jeg designer da. Det kan være en måte å teste et design på. Eller du kan teste ved å si at du kun kan bruke tastatur. Da får du tester noen aspekter som du ikke vanligvis tester. Det er spennende med uu.

Anders: Det har jo vi gjort mye, brukt tastatur når vi har laget disse poddene våre. Det skal så lite til. Det er fort gjort. Du kan få mye ut av 10 sekunder med «tabbing».

Erling: Den første, enkleste testen i verden.

Anders: Det er én av grunntestene.

Design og UX i Sopra Steria

Anders: Du jobber jo, du er jo en designer. Du har en flott tittel og jobber i et flott selskap – Sopra Steria. Ikke et selskap jeg kjenner så godt til, egentlig. Selv om jeg opplever at dere er ganske synlige. Hvem er dere? Designavdelingen, fortell litt om den?

Pål Eirik: Vi er ganske små her i Stavanger. Vi ble jo til for bare tre år siden. På landsbasis er vi over 70 designere. Innenfor et bredt spekter av design, fra tjenestedesign til funksjonell design. Vi har faktisk noen som jobber helt spesifikt med språk, språkdesign. Alle kommer inn i denne viften vi kalle for UX, egentlig. Det er òg industridesign i Sopra Steria, men det går mer og mer mot tjenestedesign.

Erling: Du nevnte UX. Er det en designavdeling, eller UX-avdeling? Hva kaller de den store paraplyen i Sopra Steria?

Anders: Eller viften.

Pål Eirik: UX og design, det er det vi kaller det for.

Anders: Kjært barn har mange navn.

Erling: Tro meg, denne diskusjonen har vært åpen mange ganger uten konklusjon.

Pål Eirik: Når vi sier kun design, så tenker folk kun på det visuelle uttrykket. Med UX tar du mye mer av skalaen. Sier du tjenestedesign i tillegg, får du enda mer av skalaen.

Anders: Det at folk tenker kun estetikk når vi snakker om design, det er litt kulturelt norsk. Det er ikke like vanlig i utlandet.

Frontend og UX

Anders: Ligger frontendkoding inn under design, eller en annen avdeling?

Pål Eirik: Det ligger i grenselandet. Det som skjer nå er at vi involverer stadig mer frontendkodere i designdelen av vårt spekter. Den siste delen av designspekteret vårt handler om frontendkoding. Så det er veldig bra dersom designere kan den delen òg. Det jeg gjør nå, er å få frontendere litt over på UX og design, prøver å jobbe folk inn på vårt domene, fra den kanten. Internt i Sopra Speria. Vi har mange flinke folk, som egentlig kan mye UX, som faller utenfor. Jeg prøver å få de med på show and tell, og få de til å bli flinkere på design.

Anders: Det synes jeg er kjempebra at du gjør. Det noen erkjenner, og mange bør erkjenne, er at det en koder produserer, er veldig viktig for brukeropplevelse. Du kan ikke distansere deg fra det. Hvordan det fungerer, hvor raskt det er, ytelse – det er veldig mye. Vi burde hatt en tittel som heter UX-utvikler.

Pål Eirik: Jeg er helt enig. En økende del av vår designspesifikasjon, som går på det området som heter frontend. Vi jobber felles om et designsystem. Da er det en del av vår spesifikasjon, som de trenger. Det å få det semantisk. At vi definerer noen regioner for hvor innholdet er, hvor navigasjonen er. At du jobber med semantikken i klasser. Alt fra h1 til h6. P og alle disse klassene, eller HTML-en som vi må forholde oss til. Det er viktig at vi leverer fra oss en spesifikasjon som inneholder de tingene. Det jobber jeg med å få inn i et rammeverk i Sopra Steria. Vi er ikke ferdige. Vi har noen ildsjeler, blant annet en som heter Glenn Husom, som jobber med å få det inn under huden til designerne. Inn i ryggraden.

Erling: For kodedelen eller uu-delen?

Pål Eirik: Nå var det mest designerne jeg tenkte på.

Erling: Hva var det de skulle få inn under huden, var det uu?

Pål Eirik: Ja, uu. At du leverer en spesifikasjon som faktisk tar høyde for tabsekvensen. Når du tabber, hvordan ser det ut på skjermen? Hvordan ser markøren ut? Dette kom inn når vi begynte med designsystemer for noen år siden. Da vi begynte å snakke om mobilvennlig design. Plutselig ser du DOM-en, du ser hvilken rekkefølge alt er i. Det kunne bli utydelig, det kunne ha noen kolonner, du kunne ikke se rekkefølgen. Med én gang du skviser det ned på mobil, så blir DOM-en nesten umulig å skjule, fordi alt vi falle under hverandre. Bokser og sånn. For meg har det vært en naturlig del å jobbe med designsystem, det å tenke på uu. Vi har holdt hverandre i hånden. Jeg må berømme dere to, dere har antent en interesse hos mange designere.

Erling: Veldig kjekt å høre!

Anders: Det er derfor vi gjør det, og det er derfor du er her. Vi var på en felles IxDA-samling, der du skrøt av oss. Da tenkte jeg …

Pål Eirik: Jeg tror dette må inn under hjernebarken til veldig mange designere. Det må jobbes inn skikkelig. For noen år siden, eller enda, så var uu mer en ettertanke, noe du gjorde før du skulle release, der vi tenkte om vi har sørget for ditt og datt. Nå har det kommet mer opp i stakken. Når er det vi jobber med uu? Det er mer relevant nå, enn før. Hvis du kan ta uu-problemer i starten, helst i designfasen, så har du gjort utviklingen bedre òg.

Metode og atomer

Erling: Kan du fortelle litt mer om metodeverket i Sopra Steria? Hvem er ildsjelene uten om han du nevnte. Er du én av ildsjelene?

Pål Eirik: Han Glenn Husom har hatt en del kursing internt i Sopra Steria. Han er definitivt én av ildsjelene.

Erling: Er han en utvikler?

Pål Eirik: Han er interaksjonsdesigner. Han har skapt en åpenbaringsbølge internt i Sopra Steria, som handler om å jobbe mer med uu. Å sørge for at det er kvalitet på uu-fronten helt ned i hver minste detalj. Når vi jobber med komponenter i et designsystem, så er det uu helt ned i atomene. En knapp, en lenke, et bilde med alt-tekst. Hvis du kan gjøre det bra med uu helt ned i atomene, så vil det vises når du begynner å bygge med disse legoklossene i tillegg.

Erling: Nå er jeg litt nysgjerrig. Han Glenn, han har jobbet internt. Kan du si noe om faktiske og praktiske ting han har gjort? Snakket om det?

Pål Eirik: Han har drevet kursing og laget en sjekkliste som vi kan gå gjennom, for å sørge for at vi har tenkt på alle disse uu-sakene. Den er fortsatt under utarbeidelse, men den har en god start.

Erling: Kjempekult.

Sjekklister

Anders: Nå tror jeg lytterne tenker det samme som meg. Hva står i denne sjekklisten?

Pål Eirik: Det er jo de punktene dere har gått gjennom. 78, er det det?

Anders: Mange. 78 suksesskriterier på 26 episoder.

Pål Eirik: Det er jo ikke så mange emner. Men han har gruppert de inn, med utgangspunkt i WCAG.

Erling: Han har ikke tatt de én til én? De er jo litt uforståelige de WCAG-ene. Han har skrevet de i et litt mer menneskelig språk?

Pål Eirik: Det er lett tilgjengelig, det rammeverket.

Anders: Hvor bor sjekklistene? Altså, hvilket format? Er det en plakat på veggen eller er det et dokument på Sharepoint?

Pål Eirik: Det jeg har sett foreløpig er et dokument på intranett. Jeg tror det er noe så kjedelig som et Excel-ark. Det må jo begynne et sted.

Anders: Jaja.

Erling: Hvis alle vet at det ligger der, og vet hvordan de får tak i det, så spiller det ikke rolle hvilket format det er i.

Anders: Dette synes jeg er interessant. Mange spør meg om å lage slike sjekklister. Og jeg har hatt lite suksess med dem. Hvor skal de bo? Én ting er å produsere dem, og gjøre dem lettleselige. Men hvordan får du dem inn i arbeidsprosessene? Hvordan bruker folk dem når de faktisk trenger dem? Det har vært vanskelig. Har dere hatt suksess? Er du trygg på at de ikke havner i en digital skuff?

Pål Eirik: Jeg vet ikke. Jeg kan ikke snakke for alle i Oslo. Når det gjelder oss i Stavanger, så har vi uu som en del av definition of ready. Det skal være et dokument som sier hva som skal lages, og der skal det være et punkt som sier at det må være i overenstemmelse med uu. Det er en kvalitetserklæring. Det går gjennom uu.

Figma

Anders: Noe jeg tenkte på da du sa at du ville få dette litt mer inn hos designerne. Mulig jeg nevnte det sist. Jeg har et ganske fint tillegg til Figma, der designerne kan spesifisere de ulike tabstoppene, eller de interaktive stoppene. Det legges da et lag over, og du kan definere hvilken rolle de ulike elementene skal ha. Det som er så bra med å gjøre det allerede i designfasen, at da synliggjør du utrolig bra hvor effektivt grensesnittet ditt er. Hva er kjernefunksjonen i dette grensesnittet? Er dette nummer to eller 15 i tabrekkefølgen. Dersom det er 15, kanskje vi bør omstrukturere fordi det ikke er effektivt nok. Å visuelt synliggjør tabrekkefølgen, for eksempel i Figma, eller et annet tegneprogram. Jeg kaller det tegneprogram.

Pål Eirik: Jeg er glad i Figma selv.

Datovelger

Anders: Jeg er enig med deg om at vi bør få uu godt inn i et designsystem eller et komponentbibliotek – kjært barn har mange navn. Men så må vi ikke glemme situasjon eller kontekst. Det er kanskje svakhetene med det designsystem. Jeg er midt i en problemstilling med en datovelger.

Erling: Fortsatt friskt i minne? Jeg snakket med deg om det for et halvt år siden.

Anders: Denne uken her er det mye datovelgere det går i. Det er jo et komponent som du fint kan legge inn i et designsystem, som nok bør bo der. Det kan du jobbe ganske hardt med å gjøre tilgjengelig. Det er så mange fallgruver å gå i. Med et designsystem så tvinger du deg ikke til å tenke universell utforming, i form av, kanskje er ikke datovelger det beste komponentet i denne situasjonen. For eksempel fødselsdato. Hvis du er like gammel som meg, så er det ganskje mange klikk å bestemme fødselsdato. Først må du finne en select inne i datovelger, om du er heldig. Eller trykke deg 40 ganger tilbake på pilen. Det som jeg savner i den store designverdenen er å stille disse spørsmålene. Ja, vi har en komponent for datovelger, da er det lett å bruke den i alle feltene vi skal ha en dato. Det er jo en datovelger. Men kanskje i dette bursdagsfeltet, så bør vi kanskje velge tre nedtrekksmenyer.

Erling: Jeg har lyst å supplere, for du nevner designsystem og komponentbibliotek. Som med design, så varierer definisjonene. I et designsystem så har du en beskrivelse av komponentene. Retningslinjer for hvordan du skal bruke dem. Der ville det vært naturlig ved et datofelt, å skrive en dokumentasjon på hvordan du skal bruke det. Når skal du bruke det, når skal du ikke bruke det. Her ville fødselsdato vært et godt eksempel. Det handler om modenheten til designsystemet, om dette er med eller ikke. Det å ha universell utforming som en del av dokumentasjonen til komponentene, det er kjempeviktig og nyttig.

Anders: Da går vi jo litt tilbake til det du startet med, da du snakket om funksjonell design. For eksempel en datovelger. I den situasjonen jeg er i nå, handler om betaling av regninger med mobilbank. Da må du sette deg inn i brukerens situasjon. Er det viktig å velge den spesifikke datoen? Eller kan vi si pluss én uke, pluss to uker, kunne det vært valg? Er det noen som legger inn en regning til forfall tre måneder frem i tid? Kanskje, kanskje ikke. jeg vet ikke, for jeg har ikke snakket med brukerne om det. Det å forstå, bør denne datoen være standard to uker frem i tid? Er det et godt hjelpemiddel.

Pål Eirik: Hva er mest effektivt i en gitt situasjon. Det som irriterer meg når jeg skal betale en regning er at jeg får datoen, og jeg får dagen, og jeg får måneden. Men jeg får ikke nødvendigvis hvilken ukedag det er. Av og til velger jeg en lørdag eller søndag, og så får jeg feil om at det ikke går. De burde klare å angi hva som er bankdager. Å hvorfor ikke bare gi hvilken ukedag det er i tillegg? I stedet for å ha slike dropdowns, gi en dato, kan det ikke være åpent? La folk trykke? Du ser kalenderen, trykk, så blir det valgt. Må du alltid gjøre det … Jeg tror det er viktig å tenke effektivitet når det gjelder å løse oppgaver, hvilken kontekst og situasjon det er.

Anders: Morsomt at du nevner det med helg. Én av diskusjonene vi hadde denne uken. I en kalendervisning, så har du syv kolonner, fordi det er syv dager i en uke. Du skal ha en god klikkflate for å gjøre det mobilvennlig, og du skal akseptere at brukeren har forstørret teksten. Veldig vanskelig å få til. Så kommer det en fyr, en utvikler, som sier at vi bare kan fjerne lørdag og søndag, det går ikke ann å betale regninger da? Alle bare, halleluja! Så kommer det en annen luring som sier at du kan jo overføre penger på lørdag og søndag. Først et eureka-øyeblikk der vi tenkte å bare fjerne lørdag og søndag, som du kanskje ville likt.

Pål Eirik: Jeg ville gjort de ikke valgbare, for å slippe den feilmeldingen.

Anders: Men da tar de opp den plassen som vi prøvde å spare oss for. Det ble kanskje litt mye datovelger, men det var kjekt å få det ut.

Pål Eirik: Det er gøy å prøve noen nye mønster for å se om det funker. Tenke litt nytt, det må være lov. Kanskje alle datoer ved siden av hverandre kan funke i noen sammenhenger. Hvem vet? Må det alltid være den boksen?

Erling: Hvor langt frem i tid betaler du en regning? Som du var inne på, er det to måneder frem i tid? Som regel er det maks 30 dager.

Anders: Maks.

Erling: Jeg likte litt ideen din, kanskje kunne det vært en horisontal scroll. 30 dager frem i tid, hvor du klikker på den datoen det skal være. Igjen, det bryter en konvensjon som kan være en utfordring for de med kognitive utfordringer. Så det å teste det på folk som har slike nedsettelser er kjempeviktig.

Anders: Kanskje jeg skal skrive en bok om datovelgere en gang. Det er faktisk veldig komplisert.

Pål Eirik: Hvordan vil du skrive en dato hvis du bare skal skrive på et ark, det er det jeg tenker på. Jeg må få lov å skrive det rett ut. Er det 18. i tredje? Så skriver jeg 18.3, og det bør være greit.

Erling: Og det er òg et suksesskriterie, at du skal tillate … jeg husker ikke. At brukeren skal skrive inn, og du skal ta byrden med å vaske dataene på systemet, ikke legge det over på brukeren.

Anders: Det er ikke et direkte suksesskriterie, men det er et godt prinsipp. Jeg vet ikke om det står slik i WCAG. Men det å ta jobben med å få god datakvalitet på produksjonssiden, ikke konsumentsiden, er et godt prinsipp.

Erling: Når du spør hvordan jeg skriver dato, så tenker jeg om jeg skal bruke punktum, skråstrek, skrive måned med ord eller forkortelse og så videre.

Anders: Alt dette bør aksepteres.

Testing og tastatur

Erling: Generell status for universell utforming for designere og bevisstheten rundt det? Hvordan har det utviklet seg de siste årene?

Pål Eirik: Jeg skulle ønske at vi snakket mer om det. Men det er nok et stykke mellom liv og lære, enda. Jeg føler at det er noe på gang, en modning på gang. Vi tenker mye mer på det nå enn før.

Erling: Hvorfor tror du det?

Pål Eirik: Jeg har lyst å integrere det i testing. Softwaretesting. Når du går gjennom noe du har laget. At du skal teste det med kun tastatur, for eksempel. Du skal bruke en skjermleser, for å se hvordan det fungerer. Så kan du bugge det òg. Du kan si at det er feil i tabrekkefølgen …

Anders: Det er jo en feil.

Pål Eirik: Det er jo det. Definitivt. Hvis tabrekkefølgen i et skjema er feil, så er det definitivt en feil. Der vil jo alle bruke tab. Eller veldig mange. Av oss gode, gamle i det minste.

Anders: Det er bra du sier. Dette med tabrekkefølge, det er lett å tenke at det er for de som er ekspertbrukere eller de som krever det, de som ikke har andre muligheter. Men som du sier, det er ganske mange som har brukt tab i et skjema uten å se på seg selv som en tastaturbruker.

Pål Eirik: Det er jo tastatur du bruker når du fyller ut et skjema, og da er det naturlig å tabbe mellom feltene. Ellers må du ned på musen hele tiden.

Erling: En liten digresjon der, i noen skjema er det satt et maks antall tegn, for eksempel kredittkortnummer, så skal de hjelpe deg. Når du har skrevet inn det antallet, så hopper den automatisk til neste felt, og da feiler jeg ofte. Jeg skriver inn nummeret og trykker tab. Da havner jeg jo i neste felt igjen. God intensjon, men det feiler.

Anders: Og det er et brudd på WCAG.

Erling: Det er det.

Pål Eirik: Du kunne faktisk laget en regel som sier at dersom dette ikke er utfylt, så kan du ikke tabbe deg videre. Det er jo en ren programmeringsregel.

Erling: Men det er viktig å følge konvensjonene. Ikke gjør noe som brukeren ikke forventer.

Pål Eirik: Jeg liker den Apple-feilmeldingen der den rister litt.

Anders: Hehe.

Pål Eirik: Den rister på hodet hvis du gjør noe som ikke stemmer. Hvis du prøver å tabbe når du skulle ha fyllt ut noe, så kunne den stått og ristet litt.

Anders: Det er jo et godt eksempel på å tenke litt annerledes, og spille på flere strenger. Ikke bare en stor, stygg feilmelding.

Ansvar for universell utforming

Anders: Jeg er ikke helt ferdig med Sopra Steria.

Erling: Du er ikke helt ferdig med datovelgeren?

Anders: Det blir jeg aldri. Jeg kommer til å gå i graven med bekymringer om datovelger.

Pål Eirik: Jeg tror vi må ha en designworkshop rundt datovelger. For å gå i alle retninger.

Anders: Det jeg lurer på er hvor ansvaret ligger. Vi lager tjenester for alle. Hvorfor er ikke dette en del av et testløp. I større prosjekter, så har dere kanskje dedikerte … Heter det dedikerte? Det ordet har jeg brukt feil før.

Erling: Dedisert.

Anders: Heter det dedisert?

Erling: Litt usikker nå. Nei, du dediserer noe til noen andre. Når noe er dedikert til noe, så er det dedikert.

Pål Eirik: Minner om Flisespikkeriet dette.

Erling: Gramaspikken.

Anders: Jeg skal forenkle litt. I noen store prosjekter og selskaper så har vi egne testledere. Jeg opplever at tilgjengelighet faller mellom to stoler, det blir lett ansvarspulverisering. Er det testleder, er det produktsjef, er det du som UX-leder – er det ditt overordnede ansvar? Er det teknisk ansvarlig? Mye handler jo om den tekniske delen av det? Hvor ligger ansvaret. Hos dere. Hva tenker du?

Pål Eirik: Jeg tror IT-bransjen har et stykke å gå, for å få implementert uu på en god måte. Egentlig handler det om kodekvalitet og designkvalitet. Kvalitet fra mange vinkler. Det handler om at alle bør omfavne det, fordi det har så mange positive konsekvenser i tillegg. Tenk bare på hvor mye raskere det går når du gjør det riktig. Det får bedre score på Google. Det er mer effektivt i bruk, rett og slett. Du får løst oppgaven raskere. Det er ingen grunn til at man ikke skal jobbe med uu på en veldig kontret måte, og fra mange vinkler.

Erling: Det er irriterende, det er så mange fordeler, likevel er det så lite fokus på det.

Loven

Pål Eirik: Vi kan jo ta loven i hånd. Det er faktisk et lovverk som gjør at vi må gjøre dette.

Erling: True med loven.

Pål Eirik: Da får det med én gang mer fokus. Se på SAS, de fikk jo dagbøter.

Anders: De fikk aldri dagbøter. De ble truet med. Og nå har jo NAV akkurat blitt truet med dagbøter. 50000 kroner dagen. Det er superaktuelt. Så det er tredje tilfelle der noen har blitt truet.

Pål Eirik: Det er jo et tilsynssystem etter hvert. Difi går jo gjennom en del løsninger nå, for å teste uu. Litt på samme måte som Ptil tester oljeindustrien, så kan Difi gå inn og teste kvaliteten på «bygg», for å sjekke om dette bygget er bygget på riktig måte og støtter funksjonsnedsettelser.

Anders: Det har vært litt «ulv ulv», mener jeg, for det har jo ikke fått noen konsekvenser enda. Nå vet vi ikke utfallet fra Nav-saken, eller, vi vet det kanskje når denne episoden er publisert.

Erling: I SAS-saken så ble det løftet frem noen veldig spesifikke ting som de hadde feilet på, enkle ting, som at inputfelt må ha label.

Anders: Stemmer det.

Erling: De fikk beskjed om å rette det. Ikke alt. Ikke et generelt krav om at hele løsningen må bli tilgjengelig.

Anders: Sånn må det jo være? De har jo sin metode for tilsyn, og de må jo bruke det som blir avdekket i den metoden.

Erling: Mitt inntrykk var at det var ganske få ting, når det sannsynligvis var mange ting de feilet på. Jeg vet ikke noe om metodikken til Digdir, heller.

Anders: Den er veldig åpen, ikke hemmelig.

Pål Eirik: Det hadde kanskje hjulpet dersom de hadde vært litt mer ute med bøteblokken. Vi ser jo på GDPR, når folk fikk vite hvor alvorlig et brudd på det var, da tror jeg mange skalv i buksene. Hvis vi kunne hatt noe som lignet på det.

Pisk eller gulrot

Anders: Er det veien å gå? Jeg tenker at loven er fungerer dårlig som et argument, fordi det har ikke hatt noen konsekvenser, og den er så uoverkommelig. Hvis du skal følge loven i dag, så koster det mye mer enn det smaker. Det å få en løsning i henhold til forskriften, som faktisk er i tråd med WCAG, er en enorm oppgave. Og for mange en umulig oppgave, for du har så mange avhengigheter. Det er rett og slett ikke gjennomførbart. Jeg har jo mer tro på den menneskelige tilnærmingen, for å få folk, som du snakket om, få folk til å kjenne litt på det. Hva er dette? Inkludering. Bruke virkemidler som å tenke seg at dersom du våkner i morgen med hjerneslag og ikke kan bruke armene dine, hva hadde du tenkt da om at dine egne løsninger ikke var anvendelige. Spille på de strengene, i stedet for å dra det jusskortet.

Pål Eirik: Eller klassisk betinging, å gi belønning er jo mye bedre enn å gi straff. Kanskje en belønningsmodell i stedet for en straffmodell?

Anders: Belønning, ja. Hvordan kan vi belønne? Er det Digdir som burde gjort det? Jeg er enig. Slik som nå, Nav er ute i dårlig lys. Og de gjør veldig mye rett. De har flinke folk på dette.

Erling: Vet du hva de er tatt på?

Anders: Ja, det er foreldrepengesøknaden? Et av de skjemaene.

Erling: Som de jo har jobbet med de siste årene.

Anders: Nå har jeg ikke lest den tilsynsrapporten. Det er kanskje ikke deres oppgave, å si noe positivt?

Erling: Jeg synes det var et godt perspektiv.

Pål Eirik: Det er jo variasjoner i hvor alvorlige bruddene er. Hvis du ikke får gjort oppgaven din ved hjelp av tastatur, for eksempel, så er det ganske alvorlig. Kanskje kunne vi ha gradert det litt. Ved alvorlige brudd kunne du fått en bot. Eller så kunne vi sagt at hvis dere lager en løsning som er kjempebra, da utløser det en premiering.

Anders: Støtteordninger.

Pål Eirik: Og det gjør at du kan få inn noen ekstra timer til å gjøre uu, gjerne fra et statlig subsidie. Få inn kvalitet i alle ledd i produksjonssystemet. Om du kan ha det i praksis vet jeg ikke.

Anders: Veldig god idé. Jeg liker det. Du nevnte at ikke alle brudd er like alvorlige. Det er jo én av de store kritikkene mot WCAG, at det er alt eller ingenting. WCAG skiller ikke på om den store knappen midt i løsningen din, som er alt du trenger, har et tilgjengelig navn, eller om den Facebook-logoen i bunnteksten din har et tilgjengelig navn. Det samme type brudd. I kommende WCAG 3, der har de fornyet veldig mye, og der har de gjort det som du sier nå, at du graderer funn. De blir gradert fra 1 til 4. Så kan du ha så og så mange 1-er feil og så og så mange 4-er feil, for å kalle deg i tråd med WCAG. Dette gir mye mening. Det er jo langt frem i tid.

Pål Eirik: Jeg mener at i offentlige løsninger, der bør folk med funksjonsnedsettelser teste det. Da får du en ekspert. Gjerne én som nettopp har fått det og én som har vært blind hele livet. De har forskjellige bruksmønster vil jeg tro. Bare det at de kan bruke alle disse snarveiene som de pleier, får opp alle headeren i en meny, det er visse ting som bare skal være på plass.

Erling: Bare for å spinne litt videre på det, det kan bidra til sysselsettning blant folk med funksjonsnedsettelser. Og litt som Apple har med App Store. De kommer gjennom en godkjennelsesprosess før det kommer ut i App Store. Sånn skulle vi hatt på offentlige tjenster. Når du lanserer noe nytt, så måtte du gjennom godkjennelsesprosess i denne komiteen, som sjekker om dette er universelt utformet nok.

Pål Eirik: Det som òg er interessant er dersom du har en god header-struktur, det kan du bruke til å lage en meny, på siden. Jeg vil hoppe raskt ned til punkt x, kanskje jeg ikke ser det punktet i utgangspunktet. Så med én gang du får uu på plass, så får du automatisk muligheter med det, for eksempel en hoppemeny.

Anders: En god hoppemeny. Et godt navn det. Skal vi runde av? Jeg kunne sittet til i morgen, jeg. Er det noe du har lyst å nevne til våre kjære lyttere? Du kan si alt her.

Avslutning

Pål Eirik: Jeg tror bare jeg skal love at vi i Sopra Steria skal gjøre alt for at dette kommer på agendaen, og mot våre kunder. Vi har mange offentlige kunder. Jeg kommer til å ri denne hesten for alt den er verdt. Dette har med kvalitet ned på hvert minste element å gjøre. Det er ingen gode argumenter for å ikke gjøre det skikkelig. Det er budskapet jeg har lyst å sende, vi skal jobbe med det. Og så vil jeg berømme dere for å løfte dette opp i vår bevissthet. Dette handler ikke om å kun hjelpe den svaksynte. Dette handler om mange andre ting, og skape gode brukeropplevelser for alle.

Anders: Det synes jeg var en utrolig god avslutning. Ingen gode grunner til å ikke tenke inkludering.

Erling: Du snakker til menigheten. Amen.

Pål Eirik: Jeg vil se det inn i definition of ready, rett og slett.

Oppsummering

Erling: Det var en kjekk samtale.

Anders: Tiden flyr, Erling.

Erling: Ja, han hadde noen interessante perspektiv som jeg bet meg merke i. Dette med å gi belønning i stedet for straff. Litt usikker på hvordan det praktisk kan gjennomføres, men jeg liker perspektivet. Hvordan kan vi se på det på en litt annen måte enn bøter og lovgivning. Det var det ene. Det andre var det med denne kvalitetssjekken. At folk med funksjonsnedsettelser må teste. Gjerne en tjeneste det er mulig å kjøpe for private aktører. Det er en god idé.

Anders: Det er jo bare en brukertest der du inkluderer et bredere spekter?

Erling: Ja, men i disse lovene bør det være et krav om at disse skal klare å utføre oppgavene.

Anders: Det er faktisk veldig i tråd med WCAG 3, der brukertesting blir en faktor.

Erling: Kult! Du da?

Anders: Jeg må faktisk nevne noe han sa etter at vi hadde skrudd av opptaket. Litt flåsete, men han sa at den første podsesongen vår hadde vært så god å jogge til. Han hadde flere ganger jogget en runde, uten at episoden hadde vært ferdig, så han hadde tatt en runde til. Så vi har faktisk hjulpet Pål Eirik i bedre form med en uu-podkast. Det var morsomt. Så er det kjekt å høre at de har fokus på det, har det under huden, men at det er et evigvarende arbeid, som aldri tar slutt.

Erling: En måte jeg har sett på det i det siste er at ingen tjenester er perfekte. Det handler ikke om å lage noe perfekt. Det å strebe etter å bli bedre er det viktige.

Anders: Neste uke, neste måned, neste år, skal vi bli bedre. Vi skal ikke bli perfekte. Neste episode skal vi bli enda bedre. For å bli bedre så trenger vi tilbakemeldinger om hva som fungerer og ikke fungerer i vår produksjon.

Erling: Da kan dere sende det til hei@ulik.fm.

Anders: Premiere på ny e-post!

Erling: I neste episode skal vi snakke med noen med funksjonsnedsettelser. Det blir spennende! Snakkes!