Ofte fylt med jargong, akronymer og retninger som krever at en doktorgradsstudent forstår, programvare brukerhåndbøker blir noen ganger skrevet ut fra et utviklingsperspektiv i stedet for en bruker. Som et resultat kan guiden gjøre forutsetninger om leserens ferdighetsnivå som ofte er feil. Det første trinnet i å skrive en god brukerhåndbok er å få den faktiske skriveprosessen så langt unna ingeniører som mulig.
Programvareutvikleren vet mer enn noen som gjør at programvaren fungerer, men det betyr ikke at utvikleren skal skrive veiledningen. Tvert imot er det en klar ulempe. Viktigere enn en dyp forståelse av programvarens indre arbeid er en forståelse av hvem sluttbrukeren vil være, hva hans utdanningsnivå er, og hvordan sluttbrukeren skal bruke programvaren. I de fleste tilfeller trenger sluttbrukerne ikke å kjenne de fineste programmeringspunktene og programvarens back-end-funksjoner - de trenger bare å bruke hvordan de skal gjøre jobben enklere.
Brukertesting
Brukerhåndboken bør i stor grad være oppgaveorientert, snarere enn tungt beskrivende. Fordi håndboken er skrevet for å hjelpe brukerne med å forstå hvordan de skal utføre bestemte oppgaver, må forfatteren også ha en forståelse for disse oppgavene, og som et resultat er det helt nødvendig å gå gjennom hvert enkelt trinn i hver funksjon. Det er ikke nødvendig for forfatteren å nødvendigvis vite hvordan programmet ble opprettet fra et design- eller utviklingsperspektiv, men det er viktig å ha en sterk arbeidskunnskap om alle dens funksjoner. Mens du utfører hver oppgave, ta deg tid til å skrive ned hvert trinn, inkludert klikk, rullegardinmenyer og andre handlinger.
Intervju prosessen
Selv om utvikleren ikke bør være den som skriver håndboken, vil hun fortsatt være en verdifull ressurs for forfatteren, og før du begynner å skrive, planlegger du et kickoff-møte mellom forfatteren, utvikleren og ingeniører og potensielle sluttbrukere for å informere forfatterens arbeid fra begynnelsen. Intervjuer med fageksperter og ingeniører bør registreres, med transkripsjoner laget for senere referanse.
Imagery
En brukerhåndbok bør ikke være for tekst-tung. Snarere innlemme liberal bruk av grafikk og skjermklipp. Beskrivelse av en handling er mye klarere med tekstbaserte retninger, ledsaget av et skjermklipp som tydelig illustrerer den retningen. Inkluder både før og etter visninger, for å vise hvordan skjermen ser ut før du tar hver handling, og hva som skjer etter at handlingen er tatt. Et enkelt skjermopptaksverktøy, for eksempel Snipping Tool inkludert i Microsoft Windows, fungerer bra for å fange disse bildene. Pass på å nummerere hvert bilde, og ta med et bildetekst som kort beskriver det. Senter den umiddelbart under avsnittet som først introduserer konseptet som er avbildet i bildet.
formatering
Å kommunisere tydelig i et teknisk dokument krever planlegging og nøye overholdelse av standarder gjennom hele veilederen. Standarder i både presentasjon, språk og nomenklatur bidrar til å unngå forvirring. Maler er tilgjengelige og kan være et godt utgangspunkt for enhetlighet, selv om disse sikkert kan tilpasses for å passe hver situasjon. Bruk av en-tommers margin med en enkelt kolonne passer best til behovet for å legge til grafikk; en to-kolonne innstilling kan virke for overfylt, og kan gjøre plassering av bilder forvirrende.
Versjonering og sporing
Mer enn noen annen type dokument, vil en programvare brukerveiledning trolig gå gjennom flere iterasjoner før den er fullført, og det vil trolig gå gjennom en gjennomgangsprosess av flere interessenter. Bruke funksjonen Sporendringer på Microsoft Word er en enkel måte å holde oversikt over hver enkelt persons kommentarer og endringer. Å lage flere versjoner etter hver gjennomgangssyklus, hver med et annet filnavn, hjelper også prosessen sammen og sørger for at alle interessenter er fornøyd med sluttresultatet.
