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.
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
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.
