Ofta fyllda med jargong, akronymer och riktningar som kräver en doktorand att förstå, programvaruanvändarhandböcker är ibland skrivna ur en utvecklares synvinkel snarare än en användare. Som ett resultat kan guiden göra antaganden om läsarens färdighetsnivå som ofta är felaktiga. Det första steget i att skriva en bra användarmanual är att få den faktiska skrivprocessen så långt borta från ingenjörerna som möjligt.
Programvaruutvecklaren vet mer än vad som gör att programvaran fungerar, men det betyder inte att utvecklaren ska skriva guiden. Tvärtom är det en distinkt nackdel. Viktigare än en djup förståelse för mjukvarans inre arbete är en förståelse för vem slutanvändaren kommer att vara, vad hans utbildningsnivå är och hur den slutanvändaren ska använda programvaran. I de flesta fall behöver slutanvändare inte känna till de finaste punkterna i programmeringen och mjukvarans bakåtvända funktioner - de behöver bara veta hur man använder den för att göra jobbet enklare.
Användarprovning
Användarhandboken bör i stor utsträckning vara uppgiftsinriktad, snarare än tungt beskrivande. Eftersom handboken är skriven för att hjälpa användarna att förstå hur man utför specifika uppgifter måste författaren också ha en förståelse för dessa uppgifter, och som ett resultat är det absolut nödvändigt att gå igenom varje enskilt steg i varje funktion. Det är inte nödvändigt för författaren att nödvändigtvis veta hur programmet skapades ur en design- eller utvecklingssynpunkt, men det är viktigt att ha en stark kunskap om alla funktioner. När du utför varje uppgift tar du tid att skriva ner varje steg, inklusive klick, rullgardinsmenyer och andra åtgärder.
Intervjuprocessen
Även om utvecklaren inte borde vara den som skriver handboken, kommer hon fortfarande att vara en värdefull resurs till författaren, och innan det börjar skriva, planera ett kickoff-möte mellan författaren, utvecklaren och ingenjörerna och potentiella slutanvändare att hjälpa till att informera författarens arbete från början. Intervjuer med ämnesexperter och ingenjörer bör registreras, med transkript gjorda för senare referens.
Bilder
En användarmanual bör inte vara för text-tung. Innehålla snarare liberal användning av grafik och skärmklipp. Beskrivning av en åtgärd är mycket tydligare med textbaserade anvisningar tillsammans med ett skärmklipp som tydligt illustrerar den riktningen. Inkludera både före och efter visningar, för att visa hur skärmen ser ut innan du tar varje åtgärd, och vad som händer efter att åtgärden har tagits. Ett enkelt skärmupptagningsverktyg som det snittverktyg som ingår i Microsoft Windows fungerar bra för att fånga dessa bilder. Var noga med att numrera varje bild och inkludera en bildtext som kortfattat beskriver den. Centrera det direkt under stycket som först introducerar konceptet som avbildas i bilden.
formatering
Att kommunicera tydligt i ett tekniskt dokument kräver planering och noggrann överensstämmelse med standarder i hela guiden. Standarder i både presentation, språk och nomenklatur hjälper till att undvika förvirring. Mallar är tillgängliga och kan vara en bra utgångspunkt för enhetlighet, även om dessa säkert kan anpassas för att passa varje situation. Att använda en tum med en enda kolumn passar bäst för att lägga till grafik. en inställning med två kolumner kan visas för trångt och kan göra placeringen av bilder förvirrad.
Versioning och spårning
Mer än någon annan typ av dokument, en mjukvaruanvändarguide kommer sannolikt att gå igenom flera iterationer innan den är klar, och det är troligt att det går igenom en granskningsprocess av flera intressenter. Använda funktionen Spårändringar på Microsoft Word är ett enkelt sätt att hålla reda på varandras kommentarer och ändringar. Att skapa flera versioner efter varje granskningscykel, var och en med ett annat filnamn, hjälper också processen med och säkerställer att alla intressenter är nöjda med slutresultatet.
