Det siste året har jeg jobbet med et prosjekt som ved første øyekast ikke høres spesielt innovativt ut: utvikler-dokumentasjon i en stor, kompleks, statlig organisasjon.

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 det store spørsmålet meldte seg tidlig: Hvordan viser man vei i noe man ikke selv kan hele veien inn i?

Et rammeverk som åpnet rom for form

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 kunne jeg bidra på en komplementær måte: å gi dokumentasjonen struktur og tydelig vei, 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.

Fra artikler til en faktisk vei

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.

Det fantes allerede mye relevant innhold, men uten rekkefølge. Det manglet en tydelig 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 testet jeg løpende. Viste fram skisser, justerte, og hadde alltid med en utvikler som kunne fange opp det konkrete, mens jeg holdt blikket litt høyere.

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.

Innsikt gjennom å vise, ikke spørre

Jeg gjennomførte intervjuer med brukere, men lærte raskt at det ikke alltid er enkelt å spørre folk i et teknisk og komplekst domene hva de trenger. Ofte vet de det ikke selv. Det er mye lettere å gi tilbakemelding når man ser noe konkret.

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 også læringen bedre.

Universelle prinsipper gjelder også her

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.

En redaksjon, ikke en enkeltforfatter

Før prosjektet leste jeg Content Design av Sarah Winters nøye, og tok særlig med meg prinsippene rundt content review og eierskap. 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 egentlig ikke dokumentasjonen selv. Det var utviklerne som var skribentene. Jeg så på meg selv som en redaktør – en lyttende redaktør. 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.

Fra teknisk presisjon til menneskelig formidling

Mye av arbeidet handlet også om å stille spørsmål. 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, branding av produktområdet, navn, språk, begrepsbruk, ordlister, historiefortelling, idéutvikling og workshops.

Når man først begynner å jobbe systematisk med innhold, stopper det sjelden på én flate.

Effekt

Effekten av arbeidet var tydelig over tid. Interessen for plattformen økte, dokumentasjonen fikk flere besøk, og jeg holdt foredrag om arbeidet på en intern konferanse i 2025. Jeg ble også kontaktet av andre team utenfor produktteamet for tips og råd.

Kanskje viktigst av alt: det oppsto en økt bevissthet rundt innholdstyper, brukerfokus og mulighetene som ligger i teknisk dokumentasjon – også i et ingeniørtungt miljø.

Så – har roller egentlig noe å si?

Dette prosjektet har bekreftet noe jeg har kjent lenge. Når man jobber med innhold på alvor, blir skillet mellom design, utvikling, kommunikasjon og strategi mindre viktig.

Det som betyr noe, er om noen tar ansvar for helheten. For strukturen. For formen. For opplevelsen.

Og kanskje er det nettopp der kombinasjonen av innholdsdesign og frontend-utvikling har sin styrke.