Brukerdokumentasjon er altfor ofte skrevet av programmerere for programmerere. Det har en tendens til å fokusere på produktets funksjoner, i stedet for brukerens oppgaver. Generelt, programmerere er ikke er ideelt plassert skal skrive brukerdokumentasjonen. De er også nær bit og byte, og de er for langt fra brukeren. Til dem, hva produktet kan gjøre tendens til å være langt viktigere enn hva brukeren kan gjøre med produktet.
Det er en subtil – men avgjørende – skille. Forskning viser at nøkkelen til effektiv brukerdokumentasjonen skriver oppgaveorienterte hjelp. Enda bedre, skrive din hjelp i henhold til minimalistisk teorien. I dokumentasjonen verden er "minimalisme" et fancy ord for en commonsense praksis. I grunnleggende begreper, betyr det at skrive for leserne og holde det enkelt.
Teorien selv har en rekke vendinger og svinger. Hvis du vil lese en stor – men litt wordy – bok om emnet, kan du sjekke ut boken "Minimalisme utover the Nurnberg trakt", 1998, redigert av John Carroll.
I mellomtiden, hvis du kan sjekke av hvert element i følgende Kontrolliste, vil du være godt på vei til brukbare skjermhjelpen som både leserne og din ledere vil takke deg for.
Nyttig Hjelp Sjekkliste
1. Base hjelp på ekte oppgaver (eller realistiske eksempler)
2. Strukturere hjelp basert på aktivitetenes rekkefølge – kapitteloverskriftene bør være mål og emner bør være aktiviteter.
3. Respekter leserens aktivitet-dette er vanligvis mer om hva du ikke gjøre enn hva du gjør. Ikke avfall leserens tid ved dykking i tangentene.
4. Utnytte forutgående kunnskap og erfaring-trekker leserens oppmerksomhet til foregående aktiviteter, opplevelser, suksesser og feil.
5. Unngå feil-"kontrollere du gjør x før du gjør y"
6. Oppdage og finne feil - "Hvis dette mislykkes, du kan være inn banen feil"
7. Fest feil - "Angi banen på nytt"
8. Gi feil info på slutten av aktiviteter der det er nødvendig (tommelfingerregel, én feil info Merk per tre oppgaver er et godt gjennomsnitt).
9. Ikke bryte opp instruksjoner med merknader, forsiktighetsregler, advarsler og eksepsjonelle tilfeller - sette disse ting på slutten av instruksjonen, der det er mulig.
10. Være kort, ikke stave alt ut, spesielt ting som kan tas for gitt
11. Utelater konseptuell og Merk informasjon der det er mulig, eller koble til den. Kanskje gi utvidelse informasjon på slutten av emnet, i tillegg til kanskje en Merk at det er andre måter å utføre oppgaven/målet, men dette er den enkleste.
12. Delene skal se kort og Les kort
13. Angi nedleggelse for inndelinger (f.eks, tilbake til opprinnelige skjermen/mål)
14. Gi en umiddelbar mulighet til å handle og oppmuntre lete- og innovasjon (Bruk aktive invitasjoner til å fungere som "Se for deg selv..." eller "Prøve denne..." i stedet for passiv invitasjoner, for eksempel, "kan du...")
15. Få brukere raskt i gang
16. Tillate for lesing i hvilken som helst rekkefølge - make hver inndeling modulære, spesielt mål, men kanskje oppgaver (definitivt hvis de kan utføres i en annen rekkefølge)
17. Marker ting som ikke er typiske
18. Bruk active voice i stedet for passiv form
19. Prøv å gjøre rede for brukerens miljø i å skrive
20. Før du skriver noe, spør deg selv "Vil dette hjelpe min leser?"
Ved å bygge disse fremgangsmåtene i dokumentasjon-prosessen, vil du at dine elektronisk hjelp blir lettere å skrive kortere og langt mer brukbare for din leser. Dessuten, vil sjefen din elske du!
No comments:
Post a Comment