De aller fleste opplever endringer som plagsomt.

Folk foretrekker en tilstand hvor det er “slik det alltid har vært”. Ved endringer vil de aller fleste føle en frustrasjon over at de ikke lenger kan gjøre det de husker eller har hatt for vane å gjøre. Arbeidsflater er ofte er en stor del av noens arbeidshverdag og kan være i bruk i timesvis hver dag. Brukerne har ofte vent seg til hvordan det ser ut, har faste arbeidsmønster og vet hvor man finner ting. Når ting flytter på seg kan det skape frustrasjon og ødelegge arbeidsrytmen.

Ønsket om “slik det alltid har vært” er om mulig enda sterkere når det kommer til noens arbeidsflate, og kan gjøre motforestillingene mot endringer enda større. Å endre funksjonalitet eller plassering har en kostnad for brukeren, som vi ikke skal ta lett på. Samtidig ser det ut som det er et større antall klager og frustrasjon rundt at ting ikke endres eller at feil ikke ordnes, enn at det gjøres endringer.

Smidig utvikling med kontinuerlige leveranser kan gi grobunn for frustrasjon ved en uforutsigbar arbeidsflate, der nettopp kontinuerlige leveranser er positivt og risikoreduserende for utviklingsteamene som kan lære raskere. 
Denne artikkelen tar for seg noen tilnærminger til å redusere uforutsigbarheten, og gjøre det mer akseptabelt med endringer.

Før du endrer noe:
Hvorfor skal du endre noe?

For å redusere kostnaden ved å gjøre endringer, må du ha en god forståelse av hvorfor du ønsker å endre noe og en forståelse av hvordan det sannsynligvis vil påvirke brukerne dine.

Endringer kan komme av at dere vil gjøre forbedringer fordi dere har identifisert dårlige eller ineffektive arbeidsprosesser, uklar praksis eller har sett at arbeidsflyten ikke er optimal. Endringer kan også komme av at det skal innføres ny funksjonalitet fordi systemet er under utvikling eller fordi lovverket endres.

Motivasjonen for hvorfor endringen skal gjøres, kan gjøre det enklere for brukerne å akseptere endringen. Dersom man kan si noe om den potensielle verdien for de som skal ta i bruk endringen, så bidrar dette også til å gjøre det mer akseptabelt å ta kostnaden ved endringen.

Størrelsen på endringen vil ofte ha noe å si for hvordan man kan kommunisere med brukerne. Er det en liten justering eller er det en endring av praksis? Er det flytting av kjent funksjonalitet eller det ny funksjonalitet som legges til?

Å ha en forståelse av hva slags mental modell brukerne dine har av systemet, hvordan arbeidsflyten er (ulike mønstre) og hvor man vanligvis finner tilsvarende funksjonalitet eller informasjon gjør det mulig å anta noe om hvordan endringen vil påvirke brukerne. Har du et bevisst forhold til hvorfor dere endrer noe, og hvordan det vil påvirke brukerne, er det lettere å informere og kommunisere. Størrelsen på endringene kan også ha noe å si for om du vurderer ulike former for gradvis utrulling.

Hjelp! Det gikk ikke sånn som vi hadde tenkt

Sannsynligheten for at det ikke går slik du hadde tenkt når endringen innføres er stor. Noe av poenget med kontinuerlige leveranser er å lære raskest mulig for å gjøre funksjonaliteten bedre.

Når løsningen tas i bruk av reelle brukere og med reelle data vil det sannsynligvis komme noen overraskelser. Kombinasjonen av brukere, datamengde og datakvalitet kan være så kompleks, at det kan være nyttigere å produksjonssette noe for å lære, enn å prøve og ta høyde for alt ved hjelp av testdata og manuell testing.

Er teamet ditt istand til å fange opp, justere og korrigere feil raskt etter en produksjonssetting, så vil konsekvensen av feil reduseres. Det vil også være risikoreduserende å finne ut om dere kan gjøre gradvis utrulling for å unngå og treffe samtlige brukere med potensielle feil, og ha muligheten til å ha tettere kontakt med noen få brukere for å få raskere tilbakemeldinger og luke ut feil.

For å fange opp justeringer eller feil, kan det være lurt å ha tilbakemeldingssløyfer på plass og overvåke løsningen ved hjelp av metrikker.

En vanlig problemstilling blant designere har vært at det er vanskelig å få prioritert og få ordnet feil eller gjøre justeringer i grensesnittet etter at noe er produksjonssatt. Hvis hele teamet har vært involvert i innsiktsarbeid, brukertesting og/eller prioritering og har forståelse for hvordan en endring har påvirket brukerne, kan det være lettere å få prioritert og fikset grensesnittet i etterkant. Det kan også være lurt å ha jevnlig dialog med ledelsen for din løsning og/eller område, for å passe på at alle er innforstått med at utviklingsmetodikken tilsier at det vil komme endringer og at man må ha tid til å følge opp og videreutvikle funksjonalitet.

Oppleves det problematisk å få gjort prioriteringer i grensesnittet, er det mulig å få hjelp på Slack-kanalen #design-interneflater for å få tips fra andre som har gjort lignende erfaringer.

Opprett tilbakemeldingssløyfer

Det kan være lurt å finne ut hvordan din del av organisasjonen er organisert med tanke på innføring av nye rutiner og praksisendringer. Det er ofte andre som kan hjelpe til med innføringsløpet eller kan hjelpe til med å få informasjon ut. Den beste måten å finne ut hva som passer best for ditt team, er å snakke med noen som har oversikt over din del av organisasjonen. Tenk også over antall brukere som blir berørt av din løsning og hva slags kapasitet teamet ditt har til å følge opp ulike kanaler. 

Tilbakemeldingssløyfene bør gjøre det mulig å stille spørsmål og få svar, hvis noe er uklart. Generelle tilbakemeldinger rundt bekymringer eller utfordringer skal kunne sendes inn. Er det noe spesielt dere vet det er knyttet usikkerhet rundt, kan det også være lurt å sette søkelyset mot denne delen for å få konkrete tilbakemeldinger på hva som kunne vært gjort annerledes. Vær åpen for at noe du har tenkt at skal fungere kjempebra, viser seg å ikke treffe så bra. Ta brukerne dine på alvor - det er de som kjenner sin arbeidshverdag best.

Pass på at teamet setter av tid etter en produksjonssetting til å følge opp og gå gjennom tilbakemeldingene som kommer inn. Det kan være vanskelig å skille mellom negative tilbakemeldinger for at noe endres fra slik det alltid har vært, og negative tilbakemeldinger fordi det er endret til noe som faktisk er en dårligere løsning. Bruk gjerne en triangulering av tilbakemeldinger, metrikker og egen kunnskap for å avgjøre om tilbakemeldingene skal følges opp med en endring eller om man skal avvente situasjonen.

Etter to til tre uker har brukerne kanskje vendt seg til nye arbeidsflyter, men det kan også være at brukerne gir opp, hvis de ikke er vant til å bli hørt eller ikke opplever at det de sier blir tatt imot og gjort noe med. Gir du brukerne dine opplevelsen av å bli hørt, så vil du også bygge ned terskelen for å delta i aktiviteter knyttet til samarbeid og læring, og kan kanskje redusere tid brukt på rekruttering og oppsøkende innsiktsarbeid.

Informer om endringer

Når større endringer skal settes ut i produksjon bør brukerne informeres på forhånd - eller når de møter endringen for første gang. Informasjonen bør tilgjengeliggjøres slik at brukerne rekker å lese den eller raskt kan finne fram til den. Bruk gjerne skjermbilder eller animasjoner for å bedre forklare hva endringen er og hvordan den brukes.

Det kan også være lurt å informere om hvorfor endringen gjøres, slik at brukerne forstår formålet. Forstår man hvorfor endringen er nødvendig eller hva som er årsaken til endringen, har man ofte høyere aksept for at noe endres. Det gjelder særlig ved innføring av ny funksjonalitet eller endringer som gjøres, som vil endre etablerte arbeidsmønster.

Den potensielle verdien for de som skal ta i bruk endringen, kan også bidra til å gjøre det mer akseptabelt å ta kostnaden ved endringen.

Innebygget “Hva er nytt”-funksjonalitet

Noen team har bygget “Hva er nytt”-funksjonalitet direkte inn i løsningen, for å kontinuerlig informere og veilede der funksjonaliteten skal tas i bruk.

Man må vurdere hvor ofte man skal gi notifikasjon av dette slaget, for det utgjør også en kostnad for brukerne. Det kan være hensiktsmessig å samle flere mindre endringer i én melding, istedenfor å informere om hver endring. Å fortelle hvorfor man gjør endringen, kan gjøre det lettere å akseptere at endringen er nødvendig.

Denne formen for informasjon forutsetter også at man har kapasitet i teamet til å følge opp og bruke funksjonaliteten.

Sørg for at budskapet er det samme i etablerte innføringskanaler, for eksempel Rutinebeskrivelser på Navet. Det er ikke alle som leser notifikasjoner om endringer i løsningen (anslag basert på måling sier under 50%), og det kan også være personer som ikke selv er brukere som har nytte av å vite om endringene.

I noen av “Hva er nytt”-funksjonene er det mulig å “tvinge” brukerne til å se informasjon om spesielt viktige endringer når de logger seg inn, og på den måten sikre at ihvertfall de som faktisk bruker løsningene er informert.

Du bør forhåndsvarsle endringer som får større konsekvenser for arbeidsflyten, det kan man også gjøre i en notifikasjon i en type “Hva er nytt”-funksjonalitet, si fra om kommende endringer, før endringen faktisk gjøres. Da er det viktig å ikke bare si hva, og omtrent når, men å si hvorfor man gjøre endringer, og hvilke positive effekter (forhåpentligvis) endringen kan gi.

“Hva er nytt”-informasjon via digitale kanaler

Noen team har valgt å ha brukerne inne på Slack eller ha felles Teams-kanaler for å dele informasjon og veiledning direkte i kanalene før produksjonssetting.

Om informasjonen er innebygget eller foregår i andre digitale kanaler, bør man fortsatt tenke over forhåndsvarsling, informasjon før store endringer og oppsamling av flere små endringer. Digitale kanaler gjør det i tillegg mulig å enkelt få umiddelbare tilbakemeldinger fra brukerne. Det forutsetter at antallet brukere er håndterbart i forhold til teamstørrelsen, og at man har gode rutiner for oppfølging.

Noen team har også brukt forhåndsvarslende informasjon for å få tilbakemeldinger som lander endelige tekstforslag eller velge mellom ulike alternativer før produksjonssetting.

Rutinebeskrivelser på Navet

Noen team har valgt å bruke eksisterende rutinebeskrivelser for å forklare ny arbeidsflyt, fordi det allerede er en etablert kommunikasjonsform og et sted som blir benyttet jevnlig for systemstøtte.

Noe av argumentasjonen har vært å holde rutinebeskrivelsene på ett sted og at det bare er én kilde til informasjon, istedenfor å duplisere og eventuelt forenkle beskrivelsene flere steder som kunne gi avvik mellom beskrivelsene eller rutinene. Dette er særlig aktuelt ved innføring av nye systemer, hvor det kan være at arbeidet utføres i parallell i to løsninger samtidig.

Enkelte team har valgt å lenke til relevante rutinebeskrivelser istedenfor å ha hjelpetekster inne i grensesnittet, fordi duplisering av informasjon kan være en kilde til potensielle feil eller mindre presise forklaringer som kunne medføre feil.

Lenker til rutinebeskrivelser bør også brukes enten man informerer i egen “hva er nytt”-funksjonalitet eller i andre digitale kanaler.

Uavhengig om man bruker rutinebeskrivelsene til å informere om ny funksjonalitet, må man passe på at nye arbeidsflyter kan påvirke eksisterende rutinebeskrivelser. Finn ut hvem som er ansvarlige for rutinebeskrivelsene og pass på at de er oppdatert når endringene er klare, slik at rutinebeskrivelsene publiseres samtidig.

Åpen dag

Flere team har også prøvd “Åpen dag på Teams” i forbindelse med lansering av ny funksjonalitet, eller for generell opplæring, tips og triks i løsninger. Da er teamet tilgjengelig for spørsmål og tilbakemeldinger, og det senker terskelen for å ta kontakt hvis det er noe brukerne lurer på eller synes er vanskelig. Det gir også en kort tilbakemeldingssløyfe for teamet og gjør det mulig å nå en bredere andel av brukerne.

Usikkerheter og metrikker

I tillegg til å la brukerne komme med tilbakemeldinger, kan det være lurt å bruke målinger for å finne ut hvordan endringer tas i bruk - eller hvordan endringer påvirker bruken av løsningen.

Ved produksjonssetting av ny funksjonalitet kan man ta ned usikkerhet og redusere risiko ved å måle ting man er usikker på, eller sette på målinger for å lære mer om hvordan funksjonaliteten brukes. Det er også flere som bruker A:B-testing for å finne ut hvilken alternativ løsning som ser ut til å fungere best. 

Teamet kan for eksempel være interessert i å finne ut om brukerne har tatt i bruk den nye knappen, om tid brukt i et skjermbilde endrer seg, hvordan brukerne beveger seg mellom ulike skjermbilder eller hvor ofte en oppgave oppstår - og hvilke valg brukerne benytter når de utfører en oppgave. Team har også brukt målinger som datagrunnlag for å si at funksjonalitet er overflødig og sjelden brukes, eller at noe funksjonalitet er helt sentral og må være det første som flyttes over til ny løsning - eller at oppgaver kan automatiseres.

Amplitude, TaskAnalytics, Grafana eller NADA (NAVs dataplattform) med Metabase og datafortellinger er verktøy som kan brukes for å følge opp hvordan ny funksjonalitet tas i bruk eller hvordan løsningen brukes.

For å kunne skille ut hva man lærer ved hjelp av målinger, kan det være lurt å ha en form for nullpunktsmålinger eller forståelse for hvordan dataen ser ut før en endring. Det gjør det lettere å tolke og adressere eventuelle avvik eller problemer i løsningen etter endringen.

Det kan være flere ulike forklaringer bak hvorfor målinger endrer seg, så det er alltid lurt å ha supplerende informasjon i form av å kommunisere med brukerne, for å bekrefte hypotesene man har om årsaken til endringer. Målinger og metrikker kan være hjelpsomt for å overvåke og raskt kunne reagere ved produksjonssettinger, hvis man ser at ting ikke blir brukt som tiltenkt. Tenk nøye gjennom hva og hvordan man måler, så man kan fange opp usikkerheten teamet har.

Gradvis utrulling

Gradvis utrulling til et mindre antall brukere gjør at teamet kan lære noe om hvordan endringene treffer før man slipper det ut til alle. Det reduserer risikoen for at feil eller dårlige valg påvirker mange, og man kan lære og fikse før man slipper alle løs.

Det er ulike måter å gjøre det på, men å velge ut en gruppe brukere som får egen tilgang eller bruke andre filter for utrulling i form av prosentandel eller geografisk plassering er blant de vanligste. Noen team har også en fast gruppe brukere med ulik geografisk plassering som har egne tilganger for å ta i bruk funksjonalitet før andre. Geografisk tilhørighet eller personlige relasjoner kan påvirke preferanser og rutiner, så vær bevisst på hvordan brukerne velges ut og hvordan det kan påvirke tilbakemeldingene.

Feil på interne løsninger kan i verste fall føre til at man ikke får utført arbeidsoppgavene sine og ødelegge for brukermøter. Man må ha et bevisst forhold til hva slags risiko ulike endringer kan medføre, og vurdere hvor mange som skal ta den i bruk samtidig.

Det anbefales også å teste ut innføringsinformasjonen ved pilotering, slik at man kan få innspill på om informasjonen er forståelig eller om det er tips og triks som burde tas med.

Noen team har også latt pilotbrukerne lage informasjonen selv, for at språket og innholdet i størst mulig grad skal være gjenkjennelig for brukerne og svare ut de spørsmålene man har eller forklare endringene ved å ta utgangspunkt i hvordan man har gjort det tidligere.

Ha på plass gode metrikker og gode kommunikasjonskanaler til pilotbrukerne, så du fanger opp hvis noe uforutsett skulle dukke opp.

Er det noe mer du lurer på så er det alltid hjelp å få på Slack kanalen #design-interneflater

Hvis du har noen erfaringer å dele, som burde vært beskrevet i denne artikkelen så ta gjerne kontakt med Chris Atherton (redaktør, interne flater).