Bel mij terug > Bel ons: +31 (0) 20 2050333

17 tips voor het schrijven van een software handleiding

 

Een software handleiding schrijven

Vraagt u zich het volgende af:

 

  • Waar moet ik rekening mee houden?
  • Hoe focus ik op relevante informatie?
  • Wat is taakgerichtheid?
  • Hoe kan ik fouten voorkomen?

Het schrijven van uw software handleiding uitbesteden? Vraag direct een offerte aan >


Voor het schrijven van een software handleiding hebben wij een reeks tips voor u samen gesteld:


1. Focus op relevante informatie

 

Voor de ontwikkeling van een software handleiding doet de schrijver er verstandig aan de verstrekte informatie te beperken tot het absolute minimum van noodzakelijke informatie. Alleen de informatie die de gebruiker ‘moet weten’ dient gecommuniceerd te worden om eindeloze hoeveelheden papier en overbodige informatie te voorkomen. Hiermee wordt vanzelfsprekend de begrijpelijkheid van de tekst en het absorptievermogen van de gebruiker bevorderd. Alle informatie die “leuk is om te weten” dient uit een software handleiding gehaald te worden om de aandacht te houden op het leren van de betreffende vaardigheid. (minimalisme principe no. 1a)

 

2. Focus op actie

 

De handleiding dient er op afgestemd te zijn dat de gebruiker direct tot actie aangezet kan worden en in staat is adequaat te handelen. Dit doel kan gerealiseerd worden door minder conceptuele informatie te verschaffen en hiermee een grotere focus op de gebruiker en de oefening met basis procedures. Mensen willen met een product aan de slag en er niet eindeloos over lezen. Een grote uitdaging bij het schrijven van een software handleiding is het vinden van een goede balans tussen het ondersteunen van de acties van de gebruiker en het verstrekken van conceptuele informatie. (minimalisme principe no. 1b)

 

3. Stimuleer ontdekking

 

Gebruikers van de software handleiding dienen regelmatig te worden uitgenodigd om andere functionaliteiten en opties van het programma te ontdekken. Ontdekking en innovatie moeten dus aangemoedigd worden. Dit wordt doorgaans gedaan met behulp van zinnen als “Please try it”, “See what happens”, “Try and see for yourself”. Deze manier van uitdagend communiceren boekt meer resultaat dan uitnodigingen als “Another possibility is…” of “You can also…”. Een juiste formulering kan leiden tot 33% meer verkenningen. Uitnodigingen die ontdekking stimuleren hebben het meeste effect aan het einde van een hoofdstuk of sectie. Echter, de optimale balans tussen het aanmoedigen van verkenning en het vertrekken van informatie varieert aanzienlijk per project. Belangrijk hierbij is dat de gebruiker bij de verkenning te allen tijde een redelijke slagingskans heeft en de weg er naar toe redelijk veilig is. Terug keren naar het vertrekpunt dient in dit traject eenvoudig te zijn. (minimalisme principe no. 1c)

 

4. Kies het juiste moment voor het geven van conceptuele informatie

 

Conceptuele informatie dient alleen verstrekt te worden op het moment dat de gebruiker hier het meest voor open staat. Over het algemeen zijn gebruikers van software handleidingen pas geïnteresseerd in het lezen van conceptuele informatie nadat ze dingen hebben uitgeprobeerd. (minimalisme principe no. 1d)

 

5. Respecteer de integriteit van de gebruiker

 

Houd er rekening mee dat het doel van de gebruiker en die van de ontwerper van een software handleiding uiteen lopen. Waar de ontwerper van de handleiding heel geraffineerd, uitgebreid en vooruitdenkend te werk gaat, is het doel van de gebruiker vaak meer op de korte termijn gericht. Zorg er als ontwerper dus voor dat je de gebruiker niet te veel dingen oplegt waarvan jij denkt dat het (ook) belangrijk is voor de gebruiker om te weten. Indien deze informatie niet direct bijdraagt aan de begrijpelijkheid van de instructies, leidt het namelijk alleen maar af. Een goed voorbeeld hiervan is een passieve helpfunctie, welke door de gebruiker kan worden ingeschakeld op het moment dat het nodig is. (minimalisme principe no. 1e)

 

6. Taakgerichtheid

 

Instructies dienen geschreven te worden als echte taken. De gebruiker van software handleidingen streeft het liefst activiteiten en doelen na die als ‘echt zijnde’ worden herkend. Voorbeelden hiervan zijn “How to customize my telephone” of “How to save and print a document”. (minimalisme principe no. 2a)

 

7. Aandacht voor de headings

 

De structuur van de taak dient gereflecteerd te worden door de opbouw van de handleiding. Hierbij is het de bedoeling dat de headings duidelijk maken welke informatie op de betreffende pagina kan worden gevonden. Bij het lezen van de heading moet de gebruiker weten waarom hij of zij tijd gaat investeren in het lezen van dat bepaalde onderdeel van de handleiding. Werk ‘topic-based’ door in ieder hoofdstuk of sectie een antwoord op slechts één vraag te geven. In plaats van “Tips for use of Microsoft Word” kan beter gekozen worden voor “Saving your work” en “Printing your document”. Vanuit die zelfde gedachte is “Check the time around the world” beter dan “World clock view”. Tracht in de headings van een software handleiding ook altijd naar het onderwerp te refereren. Zie hiervoor onderstaand voorbeeld.

 

voorbeeld headings

 

8. Reduceer de kans op fouten

 

Zorg er bij het schrijven van een software handleiding voor dat de kans op fouten zo klein mogelijk is. (minimalisme principe no. 3a) Over het algemeen maken gebruikers veel fouten en zijn zij vaak 25-50% van de tijd bezig met het herstellen van die fouten. De software zelf door en door testen is de beste manier om fouten te voorkomen. Ook kan het de overweging waard zijn om een trainingsmodus in te stellen waarbij op bepaalde functies geen beroep kan worden gedaan tijdens de trainingsperiode. Ook schrijfstijl en formulering van de tekst kan ten grondslag liggen aan gemaakte fouten door de gebruiker. Om deze reden zijn er basisregels en richtlijnen die kunnen worden toegepast bij het schrijven van goede teksten, zoals:

  • Het gebruik van korte en simpele zinnen
  • Gebruik van actieve en sterke werkwoorden
  • Het geven van veilige activiteiten
  • Minimaliseren van jargon (zie punt 15 voor nuance hierin)
  • Het geven van signaal-actie informative
  • Het geven van hints

 

9. Gebruikerstest

 

De ontwerper van de software handleiding dient uitgebreid de tijd te nemen om de handleiding te testen met een controlegroep gebruikers. Aan de hand van de bevindingen van een dergelijk experiment kan de software handleiding namelijk verbeterd en geoptimaliseerd worden. Er kan extra informatie verstrekt worden wanneer de beoogde uit te voeren actie conflicteert met de ‘real world’ ervaring van de gebruiker of wanneer correctie van de actie moeilijk te realiseren is. (minimalisme principe no. 3b)

 

10. Het oplossen van fouten

 

Gebruik consistent een stapsgewijs model te behoeve van het oplossen van problemen en/of fouten. De stappen in dit model zijn als volgt:

  1. Detecteren van de fout
  2. Vaststellen van de fout
  3. Herstellen van de fout

Waar detecteren en herstellen van fouten te allen tijde noodzakelijk zijn, is vaststelling niet altijd nodig om de fout daadwerkelijk op te lossen. Informatie over fouten is waardevolle conceptuele informatie. (minimalisme principe no. 3c)

 

11. Wees kort en bondig

 

Gebruikers gaan doorgaans niet systematisch door een software handleiding heen. Meestal lezen ze om direct actie te ondernemen, maar soms ook om te studeren of gericht informatie op te zoeken. Om alle leesstrategieën en doeleinden te ondersteunen en te vergemakkelijken is het van enorm belang om kort en bondig te zijn. Met behulp van korte zinnen, taken, topics, hoofdstukken etc. geef je de gebruiker het idee dat het niet heel veel inspanning kost om tot het gewenste resultaat te komen. Langdradige stukken tekst schrikken de gebruiker af. Door niet alle informatie te verstrekken, wordt de gebruiker gestimuleerd om zelf op onderzoek uit te gaan en na te denken. Informatie die de gebruiker af zou kunnen leiden, dient weg gelaten te worden. Tip van Manualise: zet bij iedere taak de geschatte tijd die de gebruiker nodig heeft deze taak te voltooien. Vuistregel is dat geen enkele taak langer dan 20 minuten mag duren. (minimalisme principe no. 4a)

 

12. Sluit een hoofdstuk af

 

Een hoofdstuk dat afgesloten is, oftewel een modulair hoofdstuk, zorgt ervoor dat de gebruiker alleen die hoofdstukken hoeft te raadplegen waar zijn interesse naar uit gaat. Volledige modulariteit is echter niet altijd mogelijk. (minimalisme principe no. 4b)

 

13. Presentatievorm

 

Ook de presentatie van de software handleiding verdient veel aandacht om onder andere te voorkomen dat de handleiding er uit komt te zien als een telefoonboek. Neem voldoende tijd om de gebruiker de interface uit te leggen (vergelijkbaar met de quick start). Gebruik daarnaast voldoende witruimte in de kantlijn, rondom de afbeeldingen en tussen de regels. Dit om de begrijpelijkheid van de tekst en leesprestatie te bevorderen. Besteed ook voldoende aandacht aan het uitkiezen van het lettertype. Houd hierbij in gedachten dat voor online publicatie een schreefloos lettertype de beste optie, terwijl voor publicatie op papier juist letters met schreef beter zijn.

 

14. Consistentie van informatie

 

De informatie architectuur van de inhoudsopgave en die van de productinterface dienen complementair te zijn. De software handleiding structureert informatie thematisch, terwijl de interface dit visueel doet. Wanneer de visuele structuur niet consistent is met de thematische structuur kan dit tot gevolg hebben dat de gebruiker in de war raakt. Een voorbeeld is te vinden op UX Magazine.

 

15. Vermijd jargon

 

Jargon is een ander woord voor vaktaal en deze taal verschilt dus per vakgebied, waardoor niet iedere lezer jargon zal begrijpen. Vermijd jargon dus zoveel mogelijk, maar doe dit genuanceerd. Bepaalde termen kunnen wel genoemd worden, zolang er maar een toelichting te vinden is. In de meeste gevallen wordt er voor gekozen om jargon te vermijden en louter simpele woorden en zinnen in te zetten. Echter, in andere gevallen bevat de interface al vakspecifieke terminologie. Om de consistentie te waarborgen kan de gebruikte terminologie het best in een verklarende woordenlijst van de software handleiding worden uitgelegd.

 

16. Volgorde van software handelingen

 

Een gebruiker wil het liefst handelen in dezelfde chronologische volgorde als de tekst. Besteed dus voldoende aandacht aan het consistent maken van deze volgorde. Gebruik in plaats van “Druk op print in het file menu” juist de zin “Ga naar file en klik op print”.

 

17.Gebruik bouwstenen

 

Bij het schrijven van een software handleiding is het gebruik van bouwstenen voor verschillende informatievormen per topic tevens het overwegen waard. Bouwstenen zorgen voor herkenning en consistentie. Hieronder een opsomming van de min of meer standaard bouwstenen.

  • Het geven van hints
  • Uitleg over het gebruik van de software / vervullen van de taak
  • Het herkennen en herstellen van fouten
  • Het geven van conceptuele informatie

 


Wilt u ook uw software handleiding door ons laten maken? Vraag direct een offerte aan >


Bel mij terug > Bel ons: +31 (0) 20 2050333

Heeft u vragen omtrent onze diensten? Wij beantwoorden uw vragen graag persoonlijk.