18-09-10-Kols-sprint-15 (1)

Hvordan team dataplattform bruker designmetodikk for å lage kick-ass løsninger

De fleste av teamene i Oslo Origo har behov for tilgang på offentlig registerdata. Dataplattform-teamet har arbeidet brukerfokusert for å lage en løsning som gjør hverdagen til teamene enklere.

Dataplattform-teamet har som oppdrag å hjelpe produktteamene i Origo med verktøy og teknisk veiledning for å skaffe, håndtere og dele data på en enkel, sikker og riktig måte.

For å forstå hvilket problem vi i team dataplattform skulle løse, måtte vi undersøke hva brukerne våre faktisk har behov for. Vi gjennomførte derfor en innsiktsrunde hvor vi intervjuet alle produktteamene. Da vi satte oss ned og analyserte innsikten etterpå, så vi tydelig at teamene har behov for tilgang til offentlige registerdata – og at de har behov for å bli tryggere når det kommer til å behandle og dokumentere behandling av data på en lovlig måte. 

Vi har ikke tilstrekkelig kompetanse på juss i teamet, og vi savnet derfor retningslinjer for hva som er greit og hva som ikke er greit.

Teamleder i Oslo Origo

Da vi hadde avdekket behovet, ble vi enige om å arbeide videre med materialet med designmetodikk. Med designmetodikk som tilnærming, fikk vi samhandlet som et team under hele prosessen, samtidig som vi sørget for at brukeren ble satt i fokus. 

Hvordan foregikk designprosessen?

I en “typisk” Google designsprint foregår prosessen over fem dager, med et overordnet formål for hver dag: Map, Sketch, Decide, Prototype og Test. Men i og med at teamet allerede hadde gjort innsiktsarbeidet fra før av – altså Map-steget – gjennomførte vi heller en tre-dagers workshop med Sketch og Decide som tema. Deretter gikk vi gjennom Prototype og Test i form av en arbeidsperiode på to-tre uker, før vi avsluttet designsprinten med en MVP-workshop.

MVP står for “Minimal Viable Product”, som betyr det minst brukbare produktet. En MVP er med andre ord den versjonen av produktet som tillater et team å samle mest mulig sikker informasjon om kunder, med lavest mulig innsats. Kilde: Wikipedia

Untitled_Artwork 12
Team dataplattform sitter rundt et bord og jobber foran laptoper
Team dataplattform i dyp konsentrasjon under workshopen. Her skisserer de ideer til løsningen for å få tilgang til registerdata. Foto: Charlotte Frisk

Hva kom vi fram til?

Vi i dataplattform-teamet landet på en løsning som gir produktteamene lett tilgang til registerdata som de kan bruke for å lage løsninger for Oslos innbyggere.

MVP-en ble til slutt en tredelt løsning: Dokumentasjon, et Slack-”skjema” og en CLI-løsning (Command Line Interface) for teamets eget bruk.

Vi lagde en omfattende dokumentasjon som handlet om hvordan folkeregisterdata brukes i Origo, som nå ligger i GitHub. I dokumentasjonen finner teamene informasjon om hvordan de kan ta kontakt med oss på Slack og definere hva slags tilgang eller “nøkkel” de har behov for.

Etter at vi har fått den informasjonen vi trenger, fyrer vi opp CLI-løsningen vår, og ved bruk av den generer vi en nøkkel for Origo-teamet som trenger tilgang til dataen. Nøkkelen sendes direkte til AWS-kontoen deres og teamet kan raskt og enkelt komme i gang og hente dataene de har behov for.

Command Line Interface (CLI): Et brukergrensesnitt hvor brukeren kommuniserer med et dataprogram eller operativsystem ved å skrive kommandoer på et tastatur, og får tilbakemeldinger i form av tekst på en skjerm. Kilde: Wikipedia

Amazon Web Services (AWS): En sky-plattform som benyttes til å drifte og videreutvikle bedrifters og organisasjoners  infrastruktur og applikasjoner. Kilde: Amazon

Det var smertefritt å bruke løsningen. Stegene virket fornuftige og forståelige, og var enkle å følge.

Utvikler i Oslo Origo
Skjermdump av den web-baserte prototypen
Team dataplattform ønsket å teste to ulike prototyper: En web- og en CLI-basert løsning. Her er et skjermbilde av den web-baserte løsningen.
Skjermbilde av den CLI-baserte prototypen
Skjermbilde av den CLI-baserte prototypen.

Hva lærte vi? 

Veien til løsningen har ikke vært rett frem, men vi har lært masse! Teamet sitter igjen med masse verdifull innsikt om brukerne våre, og en rekke læringspunkter som vi gjerne vil dele videre:

  • Brukerorientert arbeid er en viktig forutsetning for gode løsninger. Vi startet innsikten hos brukeren: Hva er teamets behov? Hva slags utfordringer møter de i utviklingsarbeidet sitt? Vi reflekterte over disse spørsmålene gjennom hele designprosessen. Brukerorientert fokus er en ny måte for Dataplattform-teamet å arbeide på, og det har gjort det lettere for oss å adressere de “riktige problemene”.
     
  • Nøye planlegging av workshopene for å sikre god fremdrift. Det var fremdeles nedstenging da designsprinten fant sted, så her var vi nødt til å ta høyde for hybridmøter. Vi rigget derfor workshopene tilgjennom det nettbaserte samhandlingsverktøyet Miro. Her var det helt avgjørende å planlegge øvelsene minutt for minutt, og utforme øvelsene så strukturert og enkelt som mulig for å sikre god fremdrift og effektive diskusjoner. Et forbedringspunkt her er å inkludere tech lead i planleggingen i enda større grad, for å sikre at oppsettet og øvelsene på workshopene treffer enda bedre og skaper mest mulig verdi for produktteamet.
     
  • Tett tverrfaglig samarbeid er dynamitt! Produktteamene bestod av team lead, tech lead, utviklere og designere. Det var avgjørende å ha alle til stede under workshopene for å få til gode diskusjoner og refleksjoner. I tillegg skapte samarbeidet en felles forståelse og motivasjon for arbeidet. 
     
  • Teste og feile raskt. I begynnelsen oppstod det en del usikkerhet rundt løsningsforslagene og hvorvidt dette faktisk traff problemet. Denne usikkerheten ble raskt snudd om til at teamet ble enige om å jobbe iterativt. Vi skulle teste prototypene raskt, og se på om funnene bekreftet eller avkreftet våre hypoteser. Det iterative arbeidet var en god øving for oss i Dataplattform-teamet i å være tilpasningsdyktige og ikke låse oss fast til ideer vi i utgangspunktet hadde – noe som bringer oss over til neste læringspunkt.
     
  • Kill your darlings. Det å gi slipp på våre “darlings”, er kanskje det aller viktigste vi i teamet lærte gjennom denne designprosessen. Etter Prototype-workshopen satt vi igjen med to selvbetjente prototyper, en som var web-basert og en som var CLI-basert. Funnene fra brukertestene tok vi med oss inn i MVP-workshopen. Der forsøkte vi å tenke nytt og å gå vekk fra prototypene, og heller se på de aller viktigste featurene vi ville ha med i vår MVP. Dette resulterte i at vi gikk for en enkel CLI-basert løsning som ikke var selvbetjent. Læringen her er derfor å kunne gi slipp på de mer “fancy” løsningene, og heller fokusere på hva som er det viktigste for brukeren å ha på plass. 
  • Om forfatteren
    Thy Nguyen

    Tjenestedesigner Datadeling og -gjenbruk

    Thy Nguyen (29) bistår produktområdet Datadeling og -gjenbruk og dataplattform-teamet med tjenestedesign.

    Portrett av Thy Nguyen