Jeg leste en artikkel på Medium av Sheri Byrne-Haber som jeg syns var interessant og har lyst til å oppsummere noen av punktene hun skrev. Der diskuterer hun:

Hva er forskjellen mellom god (good) universell uforming og bra (great) universell utforming?
På norsk er ikke ordene like gode som på engelsk, men jeg håper forskjellen kommer frem.



1. God universell utforming handler om å oppfylle kravene. Bra universell utforming handler om empati

Hvis man skal lage systemer som har skikkelig bra UU så stopper man ikke får minimumskravene er oppfylt. Man gjør en ekstra innsats på å oppfylle enda strengere krav eller brukerteste med faktiske brukere, ikke bare en checkmark på en side. For eksempel er kontraktberegningen i WCAG 2 mangelfull. Bra universell utforming ville da vært å ta hensyn til flere faktorer som fargeblindhet, ikoner, fokus-states osv.Noe annet å tenke på er å ta like mye hensyn til internsider som eksterne. Ofte blir internsider nedprioritert siden det er færre brukere, men da kan man fort ekskludere arbedere i bedriften.



2. God universell utforming ser på produktet. Bra universell utforming ser på brukeropplevelsen

Brukeropplevelse er noe som er veldig viktig for at noen skal få lyst til å bruke ett produkt eller tjeneste igjen. En app kan oppfylle krav på papiret men likevel være vanskelig å bruke for noen med funksjonsnedsettelse. Bra universell utforming handler opp å teste hele brukeropplevelsen for flere typer brukergrupper. Og ikke bare kjernefunksjonalitet, men også mindre brukte funksjoner som ofte blir nedprioritert til slutten.



3. Bra universell utforming benytter også innsiktsarbeid fra brukere med funksjonsnedsettelse

Her ble det brukt et sitat fra USA som ble brukt for å få gjennom "Americans with Disabilities Act" som jeg syns var bra: Nothing about us, without us, is for us. Man skal aldri anta at man forstår behovene til andre, selv om man har egen erfaring. Skal man få til bra brukeropplevelse for folk med funksjonsnedsettelser må man spørre mange forskjellige type brukere under innsiktsarbeidet.



4. Spre ordet utenfor UU-sfæren

Det å delta/bidra på UU events eller konferanser kan være veldig lærerikt og givende, men man er allerede litt spesielt interessert hvis man først er på noe slik. Det er når vi tar opp emnet om bra universell utforming på andre typer konferanser og events at man potensielt får større spredning og konverer flere til formålet om bra universell utforming.

Hva er forskjellen mellom god og bra universell utforming

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk snakker om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips.

Hvem er jeg?

Helt siden videregående har jeg likt å lage nettsider. Det gøyeste var å snakke med kunden og finne ut av hva de egentlig trengte for så å lage skisser! Da ble valget om hva jeg skulle bli veldig enkelt med en gang jeg skjønte at det fantes et yrke som jobbet med akkurat dette. 

Hva gjør jeg (og hvordan)?

I dag jobber jeg med digital eksamen hos Utdanningsdirektoratet. Vi jobber blant annet med hvordan elever kan vise frem kunnskapen sin på best mulig måte gitt digitale rammer. Noe av det mest spennende vi holder på med er å lage et designsystem som nå brukes av mange andre team på Utdanningsdirektoratet, med mål om å gjøre det enklere å lage gode og universelt utformede løsninger. Planen var egentlig å lage noe som vårt team kunne bruke selv, men resultatet ble såpass bra at andre team begynte å spørre om det og ville bruke det.

Noe jeg derimot synes er vanskelig på prosjektet er Jira-boardet vårt. Som sikkert mange andre som jobber på store prosjekt som har eksistert lenge, har vi et board med veldig mange gamle brukerhistorier, bugs og tekniske oppgaver som vi ikke får prioritert. Det går en del tid i å rydde og holde oversikt over hva som finnes der, noe jeg synes er viktig å gjøre for at alle på teamet skal være enige om hva som er prioritert og ha muligheten til å se fremover. Vi har snakket litt om hvordan vi kan rydde opp i Jira-boardet og jeg tror ikke vi kommer unna å sette oss ned og gå gjennom alle de 300 tasks/bugs/stories og rydde opp. Vi har jo så mye annet å gjøre, så å prioritere å sette av tid til å rydde synes jeg er vanskelig.

Hvilket tips ville jeg gitt meg selv i starten av prosjektet?

Når du starter på et nytt team, husk å notér ned alt du ser som virker rart eller som du tenker kan forbedres! Det er så lett å bli blind for dette etterhvert, så det perspektivet du som ny har i starten er veldig nyttig å dokumentere.

Dagens designtips

Lar du ferdige IT-prosjekter ligge og råtne fordi du ikke har råd til vedlikehold? Det kommer til å koste deg.

I forrige artikkel snakket vi om sikkerhetsgjeld og hvordan man unngår å bli en gjeldsslave. Å betale ned økende gjeld hindrer gjelden i å løpe løpsk, men den langsiktige løsningen for å håndtere sikkerhetsgjeld mener vi er å jobbe mer bærekraftig.

Vi skal i denne artikkelen se nærmere på hvordan bærekraftig produktutvikling kan se ut og til slutt gi 4 konkrete tips til hvordan man unngår uansvarlig produktutvikling.

Et autonomt og tverrfaglig team må ligge til bunns

Vi fortsetter å melde at man må slutte med IT-prosjekter hvor det går i store leveranser, urealistiske og rigide tidsplaner, detaljert ressursplanlegging og tids- og kostnadsestimater. Vi må bli smidigere nå!

Her har man dårlige forutsetninger for å raskt omstille seg dersom det måtte komme endringer i prioriteringer og omstendighetene rundt det man lager. Å jobbe produktfokusert i et tverrfaglig autonomt team gir derimot teamet fart, fokus og rask omstillingsevne.

Økende grad av sikkerhetshendelser og sikkerhetsgjeld er enda flere argumenter for at vi må jobbe smidigere med sikkerhet og takle raske omprioriteringer med fokus og spisskompetanse.

Bærekraft handler om å finne den rette balansen

På prioriteringsvektskålen hvor man allerede har teknisk gjeld og ny funksjonalitet, må man nå i tillegg plassere sikkerhetsgjeld og balansere dette opp mot hverandre.

– Derfor har omstillingsevnen aldri vært viktigere enn nå.

Bente Hoff, avdelingsdirektør i NSM, sa januar 2022 til NRK:

Vi hadde en tredobling i alvorlige dataangrep fra 2019 til 2020. Den utviklingen fortsatte med en økning også i 2021.

En kraftig økning i cyberangrep de siste årene tilsier at uansvarlig produktutvikling er et høyrisikospill.

Når vi jobber bærekraftig med produktutvikling i autonome og tverrfaglige team, hvor teamet kontinuerlig jobber med teknisk gjeld, sikkerhetsgjeld og ny funksjonalitet, får vi den balansen i vedlikehold og den omstillingsevnen som disse tider krever.

Fra uansvarlig til bærekraftig produktutvikling

Hvordan vet du at ditt produkt har for høy sikkerhetsgjeld? Hvilke symptomer kan man se etter? Hvilke tiltak kan man innføre for å betale ned gjelden?

Og klarer vi å sikte mot bærekraftig produktutvikling?

1. Du holder fortsatt på med IT-prosjekter

Leveransefokus skaper falske frister som fører til stress for å nå fristene. IT-prosjektet leverer funksjonalitet i henhold til det som er bestilt og prosjektteamet legger fra seg arbeidet når leveransen er ferdig overlevert, puster ut og starter på nye oppgaver.

Bygg heller tverrfaglige og autonome produktteam!

En gruppe tverrfaglige personer samlet rundt et produkt eller domene, får autonomitet via et tydelig mandat og fokus. Ved å jevnlig prioritere oppgaver sammen med en produkteier som ivaretar forretningsperspektivet, så vil man raskere kunne svare på behov, prioritere og levere verdi.

Tips: spill teamene gode ved å bygge DevOps-verktøystøtte for kontinuerlige leveranser, og sørg for at de leverer mange små endringer jevnlig enn få og store. Teknikker som f.eks. funksjonsbrytere lar deg lansere uferdig funksjonalitet, og man kan dermed innhente tilbakemeldinger med ekte brukere når bryteren er påslått. Slik vil man risikostyre bedre både risiko for, og konsekvenser av, at feil skjer. I tillegg leverer man verdi mer målrettet og behovsprøvd!

2. Vedlikehold overlates til andre (forvaltning/linja)

Interne overleveringskultur til egne forvaltere skaper skille mellom de som utvikler og de som driver vedlikehold. Vedlikehold i seg selv er ofte ikke spennende nok, dermed jobber utviklerteamet heller med spennende nyutvikling enn å prioritere vedlikehold som gjerne overlates til egne forvalterne.

Bygg en kultur med eierskap til det man lager!

Unngå overleveringer mellom personer og team — sørg istedet for at produktteamet har en overlapp i kalendertid med personen som besitter kompetansen man ønsker å tilegne seg.

Dyrk derfor heller en kultur hvor produktteamet har et tydelig ansvar og eierskap til det de lager og jobber på en bærekraftig måte. Når man selv må stå opp på natten for å fikse den litt for raske endringen på tampen av arbeidsdagen, så reflekterer man litt ekstra neste gangen man “skal bare”. Nå er det ditt problem i stedet for de på forvaltning.

Tips: ha en vedlikeholdsdag i uken der man jobber med teknisk gjeld (Kaizen-dag! Hack-day!).

Men ikke glem sikkerhetsgjeld også da. Kanskje arrangere en hack-deg-selv-dag i ny og ne?

3. Man kaller digitale produkter for “ferdig levert” og skifter fokus

Det nye stjerneproduktet får all oppmerksomhet og nye sårbarheter i eksisterende produktportefølje går uoppdaget hen fordi ingen overvåker eller kjenner ansvar for produktet som tidligere ble erklært for “ferdig” og som det ikke skal jobbes mer med. Alle pengene er investert i det nye stjerneproduktet.

Fokuser heller på bærekraftig produktutvikling i hele produktporteføljen!

En portefølje med digitale produkter og tjenester trenger jevnlig prioritering av vedlikehold opp mot ny funksjonalitet på tvers av hele porteføljen. Alle produktteamene i porteføljen må jobbe bærekraftig.

Tips: sørg for gjøre jevnlig sårbarhetsskanning på kode slik at man kan raskt oppdatere de produktene man har ansvaret for. Dermed holder man det svakeste leddet i porteføljen “i sjakk” og gir trusselaktørene en dør mindre å komme inn igjennom.

4. Det som bare “er der” og som ingen tør å ta i

Bitrot er et begrep for data som råtner over tid. Det samme kan sies om tekniske løsninger som har ligget så lenge at de har råtnet på rot. Verktøy for å kompilere, testmiljø, integrasjoner, utviklingsverktøy osv. har sluttet å fungere fordi ingen har vedlikeholdt verdikjeden til løsningen man lagde

Med andre ord er den tekniske gjelden direkte synlig. Man har antageligvis høy sikkerhetsgjeld attpåtil.

Hold verdikjeden “varm” (nok)!

Forsøk en data-drevet tilnærming hvor en måler tid siden forrige produksjonssetting eller hvor lang tid man har hatt kjente sårbarheter i produksjon, og sett grenseverdier som trigger handling av teamet.

Uansett om man måler eller ikke bør man holde hele verdikjeden varm ved å gjøre flere små og ufarlige endringer jevnlig. Ved å jevnlig oppdatere produktet sørger man for å holde hele verdikjeden i bruk samt beholde kompetansen i teamet for å jobbe med produktet. Det kommer godt med den dagen en kritisk sårbarhet blir oppdaget og man må handle raskt.

log4shell-sårbarheten som ble kjent i november 2021 traff bredt og rammet mange da det biblioteket var en avhengighet både direkte og indirekte hos mange, og da merket man hvor lett eller vanskelig det var å oppdatere produktene sine. Det ble en viktig vekker.

Tips: “vedlikeholdsdagen” er en fin dag i uken å gjøre gjøre oppdateringer på. Bruk verktøy som varsler om oppdateringer, som f.eks. Dependabot.

Oppsummering

Sørg for at teamet balanserer teknisk gjeld og sikkerhetsgjeld opp mot ny funksjonalitet, og kan gjøre dette på en bærekraftig måte hvor man unngår å brenne lyset i begge ender.

Unngå uansvarlig produktutvikling ved å avdekke sikkerhetsgjelden du har, og håndter sikkerhetsgjelden du har igjen på en bærekraftig og smidig måte.

I neste artikkel skal vi se nærmere på hvorfor man bør ha en sikkerhetsutvikler i teamet, og hvorfor vi mener denne rollen er essensiell i hvordan man bør jobbe tverrfaglig og smidig med sikkerhet.

Uansvarlig produktutvikling vil straffe seg

Denne boka gir deg tips om større og mindre grep du som designer og utvikler kan ta for å påvirke miljøregnskapet i positiv retning.

Sustainable Web Design gir et godt innblikk i hvor mange måter vi kan påvirke miljøregnskapet i positiv retning, for både oss og kunde, - samt samfunnet og miljøet. Boka handler om alt fra det å ha blury edge på bilder som krever mindre byte og hvilken energi datasentre drives på, til hvordan skrive effektiv kode og velge farge som krever mindre skjermlys. Om man ikke ønsker å lese den fra perm til perm, er den også fin å bare skumme gjennom som en inspirasjonskilde.

Her er hva A Book Apart skriver om boka:

THIS BOOK EXPLORES:
* How to measure—and reduce—a website’s environmental impact
* Designing low-carbon design choices around imagery, content, color, and more
* Development processes that optimize for energy efficiency
* Hosting and data transfer costs and considerations
* What you need to sell sustainable practices in your team or organization

Boka kan blant annet bestilles her (både som Ebook og paperback).

Boktips: Sustainable Web Design

Want to be really, really type safe, both on the front and back ends? With Remix, that's the default!

Remix has become one of the very best frameworks for developing full-stack web applications in React. It's quick, easy to set up, and is based off of web standards.It's just a delight.

Today I'll show you a neat trick to keep type safety between your data loaders and your frontend code!

First, if you're not familiar with Remix' way of loading data, this is how you fetch data on the backend, and serve it up to the frontend:

This works well in a frivolous JavaScript world, but with TypeScript, this will generate more red lines than a New York City subway map. So let's fix that - with a single line of code.

See that typeof loader type argument to the useLoader hook? That will give us the correct type definition to the back end. So if you change what your API function returns, this will automatically fail in your frontend code. 

A super quick tip, that revolutionized how I write my code.

For even better runtime type safety, make sure to add a parsing step for your API layer. I'm a huge fan of zag, which you'll read more about in a later post.

4-Dec

Today's posts

Hva er forskjellen mellom god og bra universell utforming

Dagens designtips

Uansvarlig produktutvikling vil straffe seg

Boktips: Sustainable Web Design

Type safe all the way with Remix