Det siste året har jeg jobbet med et prosjekt som ved første øyekast ikke høres spesielt innovativt ut: utvikler-dokumentasjon for en dataplattform i en stor, kompleks, statlig organisasjon. Det startet med å rydde og strukturere innhold, men åpnet etter hvert for noe mer – et bredere blikk på produktområdet dokumentasjonen tilhørte, og på hvordan et fagfelt som innsikt, analyse og dataplattform beskrives, introduseres og forstås, også som en del av en større helhet, kommunikasjonskonsept og merkevare.

Dokumentasjonen var likevel utgangspunktet for alt. Og teknisk dokumentasjon har ofte et rykte på seg for å være tørt, tungt og utilgjengelig. Men i bunn og grunn handler det om det samme som alt annet design: å hjelpe folk, vise vei, gjøre det lettere å forstå noe som er komplisert.

Utfordringen var ikke mangel på innhold. Dokumentasjonen hadde vokst over tid, men manglet en tydelig retning. Det fantes ingen klar vei gjennom stoffet. Ingen kronologi. Ingen felles forståelse av hva man burde lese først, eller når man egentlig var “ferdig”. Dokumentasjonen visste rett og slett ikke hvor den skulle. Og her fikk jeg stor frihet og ansvar for å forme retning. Men hvordan viser man egentlig vei i noe man ikke selv kan hele veien inn i?

1. Rammeverket

Dokumentasjonssystemet som allerede var i bruk, var Docsaurus – et MDX-basert frontend-rammeverk som bygger statiske sider. For plattform-utviklerne betydde det at de kunne skrive dokumentasjon direkte i kodeeditoren de allerede brukte. Innhold ble delt via pull requests, med versjonshåndtering og godkjenning, uten ekstra verktøy, lisenser eller nettbaserte editorer. Alt var lokalt. Oversiktlig. Og sikkert.

Som frontend-utvikler og designer ga det meg et uvanlig stort handlingsrom. Jeg kunne jobbe direkte med struktur og form, introdusere nye komponenter for formatering, og teste små endringer raskt. Plattform-utviklerne kjente den tekniske kjernen best, mens jeg jobbet med hvordan innholdet ble formidlet, strukturert og visuelt tilgjengelig.

Små endringer i frontend kunne testes raskt. En justering, en pull request, en godkjenning – og endringen var ute. Det gjorde det mulig å prøve og feile. Og la oss være ærlige: det er ofte der læringen skjer. Hele organisasjonen hadde sin utviklerdokumentasjon samlet her, og som designer i et produktteam fikk jeg ansvar for vårt område. Noe av det første jeg tok tak i, var en Getting started-guide.

2. En vei

Det fantes allerede mye relevant innhold, men uten rekkefølge. Det manglet en tydelig vei, sekvens, progresjon. Jeg startet derfor med å lage en to-be-brukerreise, i tett dialog med plattform-utviklerne. De satt på den tekniske kunnskapen og erfaringen, jeg kunne fokusere på form, struktur og formidling.

Underveis brukertestet jeg løpende. Viste fram skisser, justerte, og hadde alltid med en plattform-utvikler som kunne fange opp det jeg ikke alltid klarte å fange opp selv.

Et viktig grep var å kartlegge ulike innholdstyper. Alt kunne se ut som «artikler», men intensjonen var forskjellig. Noe var praktiske steg – guider. Annet var dypere forklaringer av hvordan ting fungerte – referanser. Bare det å gi disse forskjellene navn, gjorde det lettere å strukturere og gruppere innholdet.

3. Eksperimenter

Jeg gjennomførte intervjuer med brukere, men erfarte raskt at innsiktsarbeid i et teknisk og komplekst domene ikke bare handler om å stille spørsmål. Det krevde også teknisk forståelse å vite hvilke spørsmål som var relevante, og hvordan svarene kunne tolkes.

Derfor jobbet jeg hypotesedrevet. Jeg laget små løsninger og eksperimenter, viste dem fram og hentet inn små drypp av innsikt. Justerte form, struktur og prioriteringer underveis. Når terskelen for å endre er lav, blir det raskere og lettere å lære, produsere og komme seg videre.

4. Designprinsipper

Selv om domenet var teknisk, lente jeg meg tungt på universelle designprinsipper. White space gir fortsatt oversikt. Hierarki er fortsatt viktig. Det handler fortsatt om å fremheve det viktigste og våge å fjerne det som er mindre viktig.

I stedet for å sette meg inn i alle tekniske detaljer, stilte jeg andre spørsmål: Hva er det viktigste her? Hva trenger brukeren først? Hva kan vente – eller kanskje fjernes helt?

Mye av rollen min handlet om å være en pådriver for å ta valg. Å ta valg uten å være helt sikker. Organisasjonen hadde masse kunnskap, men trengte noen som kunne foreslå nye retninger, lage eksperimenter og vise hvordan noe kan være – slik at folk faktisk fikk se og føle på det.

Se foredraget «Hvordan kan dokumentasjon forbedre brukeropplevelsen?» (TechDay)

5. Eierskap og templates

Før prosjektet leste jeg Content Design av Sarah Winters nøye, og tok særlig med meg prinsippene rundt content review og eierskap. Alt innhold må ha en eier. Jeg inviterte plattform-utviklerne til jevnlige møter der vi snakket om innhold: hva som fungerte, hva som kunne forbedres, og hvordan vi skrev dokumentasjon. Noen ganger gjorde vi konkrete review-øvelser. Andre ganger diskuterte vi strukturer, maler og hvordan vi kunne sikre en felles stemme.

Jeg skrev ikke dokumentasjon, det var utviklerne som var skribentene. Jeg så på oss som en slags redaksjon. Sammen hadde vi hvert vårt avsvar: De satt på den dype fagkunnskapen og kjente brukernes språk. Jeg prøvde å zoome ut, se helheten og stille spørsmål: Hvordan bør dette struktureres? Hvilke skriveråd kan hjelpe? Hvilke krav må vi ha for at dokumentasjon skrevet av mange, skal fremstå med en felles stemme?

Jeg laget maler for tekst, et lite ikonbibliotek for illustrasjoner, og enkle visuelle prinsipper. Ikke for å låse, men for å gjøre det lettere å komme i gang – og for at helheten skulle henge sammen. Alt var alltid work in progress. Jeg laget noe jeg trodde var riktig, viste det fram og justerte underveis.

6. Merkevare

Mye av arbeidet handlet om å stille spørsmål, finne konsepter og forenkle. Hvorfor fungerer dette slik? Hva betyr det egentlig? Hvordan kan vi forenkle uten å miste presisjon? Ofte forsøkte jeg å flytte fokus litt: fra det teknisk korrekte til det interessante og relevante for brukeren. Fra løsning til behov. Fra system til menneske.

Dette stoppet heller ikke ved dokumentasjonen. Jeg bidro også til å forme og formulere visjon for produktet, jobbet med onboarding, merkevare og identitet for produktområdet, navn, språk, begrepsbruk, ordlister, historiefortelling, idéutvikling og workshops.

For det er ikke bare brukerne som går gjennom en læringskurve. Min oppgave var å komme med nye perspektiver: Å stille nye spørsmål og se ting utenfra. I et komplekst miljø med fullt av abstrakte konsepter og ulike perspektiver var det en rød tråd som samlet det hele: dataene. Dataene var felles for alt. Jeg prøvde å se det fra dataenes perspektiv. Fortelle dataenes historie og opplevelse av prosessen med å bli lagret, transformert, prosessert, analysert. Selve dataene går gjennom sin egen prosess. Jeg skrev den lille historien «Jeg er data», som jeg lagde til en liten 1-minutters animasjons-og-tekst-film om hvordan data beveger seg gjennom systemet, til bruk i kommunikasjon og visjon, motivasjon og felles forståelse.

«Jeg er data. Jeg er ikke alltid så lett å forstå. Men jeg er ekte, ærlig, virkelig. Lagre meg. / Nå går jeg gjennom datamodellen. Jeg får navn, relasjoner, retning. Jeg blir til et punkt på kartet. Nå er jeg et dataprodukt. Det er fortsatt meg, bare tryggere, ryddigere, lettere å finne, forbedre, automatisere. / Se på meg nå. Jeg er ikke bare data. Jeg er visuell, sammensatt, sett. Fra kunskap til handling. Jeg er fremsyn, stabilitet, trygghet. Jeg er data.»

7. GNIST

Gjennom arbeidet med onboarding avdekket jeg et behov for et felles rammeverk for hvordan plattformen kunne kommunisere med omverdenen. Jeg utviklet derfor et kommunikasjonskonsept kalt GNIST – et akronym for:

• Gjenbruk
• Nøyaktig
• Intuitivt
• Selvbetjent
• Trygt

Gjennom brukerinnsikt, møter og tidligere eksperimenter hadde jeg flere ganger sett at det var disse tingene folk faktisk snakket om og jobbet for. Nå kom det også tydelig fram i et felles kommunikasjonskonsept for onboarding. GNIST var ment å være en enkel, lett gjenkjennelig måte å forklare hva plattformen gjorde, og hvorfor den var viktig. Sammen med navnet fikk den visuelle elementer, figurer med komplekse konsepter nå enkelt forklart, i tekst og illustrasjoner, steg for steg. Resultatet var en felles forståelse og retning for hvordan plattformen skulle kommunisere med brukerne, markere seg i organisasjonen og vekke interesse, både for fulltids-kodere og ikke-kodende forretningsanalytikere.

8. Resultatet

Fra teknisk dokumentasjon til markedsføring og kommunikasjon. Dette oppdraget dekket flere aspekter av innholdsarbeid. Resultatet var en økende interesse for plattformen. Det oppsto en økt bevissthet rundt innholdstyper, brukerfokus og mulighetene som ligger i innhold, formidling og historiefortelling – også i et ingeniørtungt miljø. Jeg holdt foredrag om arbeidet på en intern konferanse i 2025, og ble også kontaktet av andre team utenfor produktteamet for tips og råd.

Dette prosjektet har gjort det tydelig for meg at når man jobber med innhold over tid, blir skillet mellom design, utvikling, kommunikasjon og strategi visket ut. Det handler om innhold og mennesker. Det handler også om å ta valg, sette retning, og ta ansvar for helheten, slik at innholdet blir enkelt å forstå, lett å bruke og holde levende over tid.