User stories ger dig strategi och struktur (del 3)

Hitta rätt strategi och struktut med user stories

Genom att utgå från user stories får du en strategi som ger dig struktur när du skriver teknisk dokumentation. Det gör att det blir lättare att arbeta agilt med din dokumentation, eftersom du kan börja i liten skala och sedan iterera fram mer innehåll med tiden.

Det här är tredje delen i min bloggserie om varför det är smart att utgå från user stories när du skriver mjukvarudokumentation. Vill du först läsa de tidigare delarna? Här hittar du del 1 och del 2 i bloggserien om user stories.

Hitta din tidigaste användbara dokumentation

Du kanske redan är van att tänka kring vad som utgör er ”minimum viable product”, er MVP. Vissa tänker istället i termer av tidigaste testbara produkt, eller någon annan mental modell. Henrik Kniberg reder ut de olika begreppen bra i det här blogginlägget.

Så när det kommer till dokumentation, vad är er “tidigaste användbara dokumentation”? Om du bara hinner publicera litegrann, vad skulle då vara mest värdefullt?

Strategier för itererbar struktur

Jag ser i alla fall två strategier för att bryta ner uppgiften i mindre delar, så att du kan iterera fram din dokumentation:

Strategi 1: Dela upp produkten i logiska bitar och börja med dokumentation för en bit, och fortsätt sedan med resten.

Strategi 2: Börja med den mest centrala user storyn, och fortsätt sedan med resterade user stories.

Låt mig visa konkreta exempel på vad dessa strategier får för konsekvenser för din dokumentation.

Exempel på strategi 1: Dela upp produkten

Låt oss anta att du har fått i uppgift att skriva en manual för powerpoint.

Ett sätt att bryta ner den stora uppgiften i mindre delar kan vara att exempelvis ta en meny i taget och beskriva funktionaliteten där. 

Strategi och struktur för dokumentation med user stories

Det här är, utifrån min erfarenhet, ett rätt vanligt sätt att ta sig an problemet. Har jag gjort så själv? Jajamän! Brukar det bli bra? Nej.

Som skribent målar du in dig i ett hörn, det bli väldigt begränsande. Samtidigt är det svårt att avgränsa. För hur långt in i respektive funktion ska du beskriva? Och hur ska du beskriva alla alternativ som snabbt kommer upp och förgrenar instruktionerna till ett enda stort trassel?

För användaren blir det inte heller bra, eftersom det inte är så användaren närmar sig produkten. Användaren tänker inte ”idag ska jag lära mig powerpoint, så jag börjar med att lära mig alla funktioner på den första menyfliken”. 

Att skriva manualen enligt strategi 1 kommer alltså troligen inte motsvara användarens behov. Dessutom kommer det med tiden att försvåra jobbet för dig som skribent.

Varför skriver vi så ofta så här då, om det inte är bra? Jag tror att det är för att den här uppdelningen i logiska delar ger oss skribenter en känsla av struktur. Så var det i alla fall för mig. Jag ville åt den där systematiken!

Exempel på strategi 2: Utgå från user stories

Låt oss nu istället anta att du har user stories för powerpoint. Och har du inte det så kan du göra en lista över vad du tror är rimligt att en ny användare vill göra i powerpoint. Det kan till exempel vara:

  • Skapa en ny presentation
  • Lägga till sidor
  • Skriva text och justera textstorlek
  • Spara presentationen
  • Presentera på helskärm
Strategi och struktur för dokumentation

Därefter kan du lägga till alltmer funktionalitet:

  • Lägga in bilder
  • Lägga in former
  • Animera objekt
  • Osv

Lager för lager kan du då bygga på din manual med alltmer avancerade funktioner.

Börja där det gör mest ont

I verkliga livet kan den här insikten om ”tidigaste användbara dokumentation” innebära att det viktigaste inte är att ha en komplett manual till produkten. Det kanske inte ens ska vara ett långsiktigt mål? Det kanske räcker med en kom igång-guide till att börja med?

Jag brukar ofta råda mina kunder att börja där det i nuläget gör som mest ont, där det finns mest frustration. Om inte annat brukar det föra med sig betydande motivation till förändring. 

Ibland kan det handla om en installationsanvisning för en viss miljö som alltid krånglar. Eller det kan innebära en lathund för en specifik yrkeskategori som behöver hjälp att brygga över en osmidig integration mellan två system.

På det sättet behöver inte ”ta tag i dokumentationen” bli en gigantisk uppgift.

Och lugn, om ni redan råkar ha dokumentation som bygger på strategi 1, så är den inte alls värdelös. Den typen av dokumentation funkar bra som referensinformation för mer erfarna användare som vill kolla upp en viss detalj. Men komplettera gärna med användarflöden som har ett tydligt mål.

Så, nu är den här serien klar. Leta nu upp dina user stories och sätt igång!

Vill du veta mer?

Vill du lära dig mer kring systematiska metoder att skriva manualer? Spana gärna in min webbkurs!

Om dina user stories och din frustration säger dig att du behöver skriva en lathund, så kanske du vill få några råd på vägen? Läs då Tips till dig som skriver lathund i affekt.

Har du frågor? Kontakta mig via e-post eller via LinkedIn.

Dela på facebook
Dela på twitter
Dela på linkedin
Dela på email

Jag hjälper dig med metoder, kunskap och erfarenheter kring produktdokumentation så att den blir både effektiv och användbar.

Fler inlägg

Buffe med mat

Därför ska du skriva manualen som en buffé

Jag är en förespråkare av modulär teknisk dokumentation. Varför? För att det gör dokumentationen lättare att använda, lättare att skriva och framför allt lättare att uppdatera. Hur då? Modulärt julbord

Instruktioner för att laga soppa

User stories ger dig rätt instruktioner (del 2)

User stories visar vad er produkt faktiskt ska uträtta åt användaren. Eller snarare vad användaren vill göra. Du kan nu enkelt förstå vilka instruktioner som du behöver skriva. Välkommen till

Läsare av teknisk dokumentation

Fixa dokumentationen med user stories (del 1)

User stories kan ge dig en flygande start när du ska skriva teknisk dokumentation, särskilt manualer av olika slag. Det gäller oavsett om det är grundläggande manualer till slutanvändare, integrationsinstruktioner

Musfälla

Trick för att locka information ur utvecklare

Att få fram underlag till teknisk dokumentation är verkligen en utmaning. Själv har jag provat allt. Jag har mutat utvecklare med kakor. Intervjuat stressade projektledare. Filtrerat ofantliga mängder med utvecklingsärenden

Tips till dig som skriver lathund i affekt

Behöver dina kunder en lathund för er produkt? Eller behöver ni själva en intern lathund på kontoret för att komma tillrätta med reseräkningarna? Lathundar kan vara många olika saker. Allt

Gunilla Svanfeldt Omslag

Samtycke till marknadsföring

Vi lagrar informationen som du anger i formuläret för att kunna kontakta dig med nyhetsbrev, om uppdateringar och med erbjudanden. 

Markera kryssrutan i formuläret för att ge ditt samtycke till att vi skickar e-post till dig.

We use MailerLite as our marketing automation platform. By clicking below to submit this form, you acknowledge that the information you provide will be transferred to MailerLite for processing in accordance with their Privacy Policy and Terms of Service.