Etter hvert fikk plattformen flere funksjoner, statuser og dokumentversjoner. Informasjonen ble samlet, men jeg begynte igjen å bruke tid på koordinering.

Jeg hadde bygget inn deler av kompleksiteten jeg forsøkte å bli kvitt.

Fristene var lagret, men ikke synlige der jeg trengte dem. Tekster som ventet på omskriving, var vanskelige å finne igjen. Opplysningene fantes, men arbeidet med å finne neste handling lå fortsatt hos meg.

Dette endret retningen for brukeropplevelsen.

Jeg arbeidet videre med et felles, oppdatert datagrunnlag og en enklere inngang: «Min dag». I stedet for å begynne med alt systemet inneholdt, skulle jeg se det som faktisk krevde oppmerksomhet: hva jeg måtte lese, avklare eller følge opp.

Jeg gikk fra å organisere løsningen rundt informasjonen den lagret, til å organisere den rundt situasjonen jeg sto i som bruker.

Det ga meg også et tydeligere kriterium for nye funksjoner. Hjalp de meg videre, eller skapte de enda noe jeg måtte holde styr på?

Det er et spørsmål jeg kjenner igjen fra arbeid med kundeopplevelse og tjenester. Det er lett å gjøre et system mer omfattende. Det er vanskeligere å gjøre det enklere å bruke.

Å bygge ble en måte å undersøke problemet på

Utviklingen fulgte ingen ryddig, lineær prosess.

Jeg vekslet mellom å undersøke behovet, avgrense oppgaven, utvikle og teste. Noen ganger førte en ny funksjon til en forbedring. Andre ganger viste bruken at jeg hadde definert problemet feil.

Design Councils Double Diamond gir et godt språk for denne bevegelsen mellom å forstå problemet og utvikle løsningen. Men i praksis gikk jeg frem og tilbake mellom fasene.

Double Diamond-diagram fra Jason Carlins gratis Figma-mal via UIKit Free, basert på Design Councils Double Diamond.

Også Learning Spiral, som jeg kjenner fra Hyper Island, beskriver noe sentralt ved arbeidet: Vi prøver, reflekterer, trekker innsikt og bruker den i neste forsøk.

Illustrasjon bearbeidet etter Hyper Islands Learning Spiral.

For meg fikk dette en ganske praktisk betydning.

Da fristene var lagret, men fortsatt vanskelige å finne, måtte jeg revurdere hva «oversikt» egentlig skulle bety. Det holdt ikke å gjøre informasjon tilgjengelig. Løsningen måtte også hjelpe meg å handle på den.

AI forkortet veien fra idé til noe jeg kunne undersøke. Min egen erfaring med strategi, design og UX hjalp meg å forstå hvorfor noe ikke fungerte, og hva som burde endres.

Erfaringen ga meg retning. Bruken ga meg motstand og ny innsikt.

Å ha ansvaret er ikke det samme som å ha kontroll

Fra starten var én grense tydelig: AI kunne undersøke og foreslå. Jeg skulle vurdere, godkjenne og sende.

Likevel oppdaget jeg at det ikke var nok å legge inn et godkjenningspunkt på slutten.

Et overbevisende forslag er vanskelig å vurdere hvis jeg ikke kan se hva det bygger på, eller hvis tidligere avklaringer har falt ut underveis.

Jeg oppdaget blant annet at korrigeringer kunne forsvinne mellom arbeidsøkter, og at dokumenter kunne avvike fra godkjente visuelle referanser. En generell beskrivelse av språk, farger og stil ga for stort tolkningsrom.

Dette kjente jeg igjen fra merkevareimplementering. En kreativ retning får ikke verdi bare fordi den er formulert godt. Den må kunne følges gjennom mange små beslutninger om språk, hierarki, uttrykk og detaljer.

Jeg måtte derfor bli mer presis på hvordan dokumentert erfaring, avklaringer, faktiske referanser og tilbakemeldinger skulle følge oppgavene videre mellom AI-assistenter og arbeidsøkter.

Forskeren Madeleine Clare Elish beskriver i Moral Crumple Zones hvordan mennesker kan bli tillagt ansvar for automatiserte systemer de har hatt begrenset kontroll over. Forskningen gjelder andre og langt mer alvorlige situasjoner enn min plattform, men forskjellen mellom ansvar og faktisk innflytelse er relevant.

Mica Endsley og Esin Kiris undersøkte i en studie fra 1995 utfordringer som kan oppstå når mennesker må overta kontrollen etter automatisering. Studien gjelder en annen teknologi, men understreker betydningen av situasjonsforståelse.

For meg ble spørsmålet: Hva må jeg kunne forstå underveis for å gripe inn før et forslag blir til en beslutning?

Det endret hvordan jeg tenkte om kvalitet. Kontroll er ikke bare noe som skjer til slutt. Den må være mulig gjennom hele arbeidsflyten.

Hva er automatiseringen egentlig verdt?

Det er fristende å måle verdien av AI i hvor raskt noe kan produseres.

Men et utkast som blir ferdig på få minutter, sparer mindre tid hvis jeg må gjøre researchen om igjen for å kunne stole på det. Og en ny funksjon skaper ikke nødvendigvis verdi hvis den krever mer registrering, oppfølging eller vedlikehold enn den sparer.

Jeg begynte derfor å se på arbeidet rundt automatiseringen, ikke bare det som ble automatisert.

Et konkret eksempel var hvor ofte systemet skulle undersøke behovet for nye kontakter. Hyppigere kontroller var teknisk mulig, men ga meg ikke tilsvarende nytte. Jeg reduserte derfor frekvensen.

At noe kan automatiseres, er ikke i seg selv et argument for å gjøre mer av det.

Dette er ikke en ny problemstilling. I Ironies of Automation fra 1983 beskrev Lisanne Bainbridge hvordan automatisering også kan skape nye utfordringer for menneskene som skal håndtere arbeidet som gjenstår.

Det perspektivet gir meg et strengere mål på nytte: Hvilket arbeid sitter brukeren igjen med?

Jeg har ennå ikke målt den samlede tidsbesparelsen ved å bruke plattformen. Kontroll, korrigeringer, vedlikehold og ressursbruk må også med i regnestykket.

Å bygge raskere er interessant. Å skape en bedre arbeidsprosess er målet.

Når andre skal forstå det jeg har bygget

Plattformen er i egen bruk. Interesse fra andre har også ført til brukertesting og en tilpasset versjon.

Det introduserer en ny type utfordring.

Jeg kjenner historikken, vurderingene og logikken i løsningen. Andre kan ikke forventes å forstå alt dette uten videre.

Nå undersøker jeg hva som er selvforklarende, hvor det trengs støtte, og hvilke behov vi faktisk deler.

Dette handler ikke lenger bare om produktets funksjoner. Det handler også om hvordan en ny arbeidsmåte tas i bruk.

En løsning som fungerer godt for personen som utviklet den, er ikke nødvendigvis enkel å forstå eller verdifull for andre. Den må passe inn i menneskers arbeidsmåter, gi dem nødvendig trygghet og være verdt innsatsen det tar å lære den.

Jeg har gått fra å teste om jeg kunne bygge løsningen, til å undersøke om den fungerer uten at jeg sitter ved siden av.

Et annet grunnlag for å investere i ideer

Det mest interessante prosjektet har gitt meg, er ikke en ny metode for å produsere mer på kortere tid.

Det er en annen mulighet til å arbeide med usikkerhet.

Jeg kunne kombinere forretningsforståelse, kreativ utvikling, UX og teknologi i samme utviklingsløp. Jeg kunne prøve konsekvensene av strategiske valg direkte i produktet, oppdage svakheter tidligere og endre retning før mer arbeid ble bygget på de samme antakelsene.

I en virksomhet ville jeg begynt med oppgaver som stadig må løses på nytt, informasjon som må settes sammen manuelt, eller beslutninger som blir utsatt fordi grunnlaget er vanskelig å få oversikt over.

Deretter ville jeg undersøkt om en avgrenset løsning faktisk forbedret arbeidet, før det ble investert mer.

Når terskelen for å bygge blir lavere, åpner det for å undersøke flere muligheter. Men det gjør ikke strategiske valg mindre viktige. Tvert imot.

Prosjektet har gitt meg større ambisjoner for hva jeg kan være med på å utvikle. Det har også gitt meg strengere kriterier for hva som fortjener å bli videreført.

Når det blir lettere å bygge, får valget av hva vi bruker tid på, enda større betydning.

Forskning og faglige referanser

Madeleine Clare Elish (2019): Moral Crumple Zones: Cautionary Tales in Human-Robot Interaction.

Mica R. Endsley og Esin O. Kiris (1995): The Out-of-the-Loop Performance Problem and Level of Control in Automation.

Lisanne Bainbridge (1983): Ironies of Automation.

Design Council: The Double Diamond.

Hyper Island: Experiential Learning and the Learning Spiral.