Gebruiksvriendelijke softwaredocumentatie creëren (2023)

Software beheerst ons leven. We worden er volledig door omringd: we gebruiken software om de snelste weg naar de sportschool te vinden, onze boekhouding te doen of om de verkeerslichten aan te sturen. Een software handleiding beschrijft de gebruikerstaken voor de eindgebruiker om met de software te kunnen werken. Het is de informatie die de gebruiker nodig heeft om een bepaald doel te bereiken. Een goede software handleiding schrijven vraagt om een andere aanpak dan de handleiding voor een hardware product. Lees verder en leer wat de stappen zijn voor het ontwikkelen van goede sofwaredocumentatie. 

#1 Bepaal de eisen voor de softwarehandleiding
#2 Bepaal de doelgroep en de gebruikerstaken 
#3 Gebruik een actiegerichte benadering
#4 Leg de tool vast in het taakdomein
#5 Ondersteun probleemoplossing
#6 Ondersteun lezen om te doen, studeren en lokaliseren
#7 Geef contextuele informatie
#8 Maak informatie vindbaar
#9 Formuleer betekenisvolle headings
#10 Gebruik modulaire bouwstenen
#11 Gebruik heldere stappen
#12 Selecteer actieve werkwoorden
#13 Zorg voor consistentie
#14 Vermijd jargon
#15 Gebruik een stijlgids
#16 Kies de juiste outputvorm
#17 Maak informatie context sensitive
#18 Wees selectief met de informatie die je laat zien
#19 Maak indrukwekkende visuals
#20 Gebruik een template
#21 Voer een gebruiksonderzoek uit
#22 Manage de content
#23 Manage de vertalingen
#24 Pas een agile proces toe
#25 Kies je informatieleverancier zorgvuldig uit

Goede softwaredocumentatie

We gebruiken software van Google om de snelste weg naar de sportschool te vinden, om de betekenis van het woord 'glabella' op te zoeken of om ons advertentiebudget op te hogen.

Tekstverwerkers, boekhoudprogramma's en grafische tools worden ingezet om ons in al onze taken te ondersteunen. Maar ook processen die we nauwelijks nog opmerken, zoals het aansturen van verkeerslichten of het verwerken van de betaling bij een parkeerautomaat worden door software ondersteund. 

En door ontwikkelingen als Industry 4.0, AI, meta products, Robotics, Big Data, Internet of Things, zijn software en hardware tegenwoordig volledig geïntegreerd.

En dan hebben we het nog niet gehad over de razendsnelle ontwikkeling van apps.

En bij goede software horen natuurlijk goede gebruiksaanwijzingen. 

Om die reden houden wij ons dagelijks bezig met het schrijven en ontwikkelen van softwarehandleidingen, online help en andere soorten softwaredocumentatie voor een breed scala aan klanten en ontwikkelaars.

Zoals de online help van Madcap Software:

Of de gebruiksdocumentatie van machinefabrikant COGNEX:

Wat is softwaredocumentatie?

Onder softwaredocumentatie wordt alle documentatie verstaan die bij de computersoftware wordt geleverd. Hieronder vallen geschreven materialen, afbeeldingen en video-instructies.

In de softwaredocumentatie wordt uitgelegd hoe een programma of service gebruikt moet worden.

Er zijn verschillende soorten softwaredocumentatie, afhankelijk van de doelgroep waarvoor deze is gemaakt. Enkele voorbeelden zijn technische documentatie en eindgebruikersdocumentatie.

• Technische documentatie omvat documentatie van de softwarecode, algoritmen en API's. Dit type softwaredocumentatie is geschreven voor gebruikers met een technische achtergrond, zoals softwareontwikkelaars.
• Eindgebruikersdocumentatie beschrijft de gebruikerstaken voor de eindgebruiker. Het is de informatie die de gebruiker nodig heeft om een bepaald doel te bereiken.

De documentatie wordt vaak aangeboden in de vorm van een online help, als context sensitive help, als on-device informatie of als een downloadbare pdf.

Een softwarehandleiding ontwikkelen

Voor het creëren van gebruik(er)svriendelijke, efficiënte en goed vormgegeven softwaredocumentatie zijn diverse skills nodig en moet een gestructureerd proces worden gevolgd. Het gaat dan meestal om een proces dat aansluit bij de agile processen waar softwareontwikkelaars mee werken.

Waarvoor is een goede softwarehandleiding nodig?

Effectieve, goed ontworpen en correct geleverde gebruikersinformatie verhoogt het rendement op investeringen in de ontwikkeling van software. Het helpt de opleidingskosten verlagen en zorgt voor ondersteuning zodat gebruikers de software snel productief kunnen gebruiken. Als zodanig verbetert goede softwaredocumentatie de reputatie van het product, zijn maker en zijn leveranciers.

Goede softwaredocumentatie gaat niet alleen over het schrijven van teksten. Ook het communiceren met softwareontwikkelaars, het begrijpen van functionaliteiten en gebruikerstaken, het organiseren en structureren van informatie, het managen van content, het publiceren en het plegen van onderhoud zijn essentiële vaardigheden.

Hierna wordt een aantal belangrijke uitgangspunten beschreven die in acht moeten worden genomen bij het ontwikkelen van goede softwarehandleidingen.

#1  Bepaal de eisen voor de softwaredocumentatie 

Voordat wordt gestart met het documenteren van software, is het verstandig een projectplan op te stellen. In het projectplan worden de eisen aan het project vastgelegd.

De volgende elementen worden in het projectplan beschreven:

• Informatiedoelen: Wat moet er worden bereikt? Welke informatie moet worden overgebracht? Wat zijn de leerdoelen? Wat zijn de kwaliteitseisen? Wat zijn de eisen ten aanzien van efficiëntie en effectiviteit van de informatie? Hoe draagt de informatie bij aan de doelen van de organisatie?
• Project scope: Voor welke software wordt de documentatie ontwikkeld? Hoe ziet de verdere roadmap eruit? Wat zijn de prioriteiten?
• Gebruikersprofiel: Door wie wordt de software gebruikt? Wat zijn hun kenmerken? Wat zijn hun behoeften? Wat zijn hun gebruikersrechten? Wat zijn de belangrijkste gebruikerstaken en - scenario's? In welke omgeving werken ze? Wat zijn verdere gebruikersvereisten?
• Overzicht van de content die moet worden ontwikkeld: Welke topics moeten uitgewerkt worden? Welke content is nodig voor de klant en eventuele andere gebruikers? Is er onderscheid tussen concepten, taken en referenties?
• Eisen aan de toegankelijkheid van de informatie: Via welke media moet de informatie beschikbaar zijn: online, print, video? Is de informatie voor iedereen toegankelijk? Worden W3C (World Wide Web Consortium) en ergonomiestandaarden toegepast?
• Eisen met betrekking tot vertalen en lokaliseren: In welke landen wordt de software gebruikt? Naar welke talen moet er worden vertaald? Welke delen moeten gelokaliseerd worden?
• Tussentijdse opleveringen en eindoplevering: Wat zijn belangrijke mijlpalen? Wordt de documentatie geprint opgeleverd of elektronisch?
• Eisen aan de te gebruiken tools (CMS/CCMS): Hoe wordt de informatie gemanaged? Wie moet er met de managementsystemen werken? Hoe wordt informatie uitgewisseld? Hoe gaan we om met updates, nieuwe releases, GUI-aanpassingen? Is DITA XML vereist?
• Strategie met betrekking tot hergebruik van informatie: Wordt er een CMS gebruikt? Wordt er een vertaalgeheugen (TM) gebruikt? Wordt er een global project ingericht?
• Risicobeoordeling: Wat zijn eventuele eisen met betrekking tot een veilig gebruik en compliance?
• Projectplanning: Wanneer moet het project afgerond zijn? Wat zijn belangrijke mijlpalen? Moet er agile ontwikkeld worden?
• Inschatting van de projectgrootte: Hoeveel uren zijn er nodig?
• Inschatting van het projectbudget: Wat is het geschatte budget? Welke afhankelijkheden zijn er?
• Teamleden en betrokkenen: Wie zijn de betrokken personen? Wat zijn hun verantwoordelijkheden?
• Project reviewers en personen die de content moeten goedkeuren: Wie zijn verantwoordelijk voor de reviews? Hoe ziet het reviewproces eruit? Wie is verantwoordelijk voor het goedkeuren van de content? Hoe wordt gebruikersinformatie verzameld?
• Design-, marketing- en overige eisen: Wat zijn eisen van andere stakeholders? Welke eisen worden aan de marketing en het design gesteld?

 

 

DOWNLOAD ONZE TEMPLATE VOOR HET PROJECTPLAN

#2 Bepaal de doelgroep en de gebruikerstaken om de informatiebehoeften te bevredigen

Een softwaregebruiker heeft informatiebehoeften die worden bepaald door de gebruikerstaken die deze persoon moet uitvoeren. Om die reden is het belangrijk om de behoeften van de gebruiker te kennen en vast te leggen. Als onderdeel van het ontwikkelen van een behoefteanalyse moet het volgende worden gedefinieerd:

• gebruikersprofiel;
• gebruikersomgeving;
• use case en gebruikersscenario;
• gebruiker- en taakanalyse.

Na deze analyse kan een lijst met topics worden opgesteld. Deze lijst bevat een overzicht van de belangrijkste taken die moeten worden uitgewerkt.

Hoewel het onwaarschijnlijk is dat alle taken aan het begin van het project grondig zijn gedefinieerd, helpt een eerste lijst van belangrijke taken bij het vastleggen van de projectomvang en het inschatten van de benodigde personeels-, tijd- en budgettoewijzingen.

#3 Gebruik een actiegerichte benadering zodat gebruikers worden ondersteund in het vervullen van hun taak

Gebruikers raadplegen documentatie omdat ze een bepaalde taak met de software willen uitvoeren of een probleem willen oplossen. De software-industrie probeert het product vaak te verkopen als een intuïtieve interface waarvoor je geen gebruiksondersteuning nodig hebt. Uit onderzoek blijkt echter dat mensen altijd een of andere vorm van ondersteuning willen of nodig hebben.

Gebruikers willen om hun doel te bereiken zo snel mogelijk overgaan tot actie. Het verstrekken van informatie om hen bij dat doel te ondersteunen, wordt een gebruiksgerichte benadering genoemd. Het is de kern van de principles of minimalism in technical communication en het eerste en belangrijkste idee van het minimalisme.

Genummerde stappen zijn een voorbeeld van een actiegerichte benadering.

#4 Leg de tool vast in het taakdomein 

Verschillende typen gebruikers hebben andere behoeften. Een leraar wil andere dingen met Microsoft Word doen dan een onderzoeker, en een financieel medewerker gebruikt een CRM-pakket voor andere doeleinden dan een manager. Daarom is het belangrijk dat, wanneer een bepaalde software- of gebruikerstaak wordt uitgelegd, deze betekenis heeft voor het werk en doel van de persoon die de documentatie raadpleegt.

Sommige benaderingen leggen slechts de droge functionaliteit van de software uit. Het gaat er echter om dat de functionaliteit in relatie tot iemands werk wordt uitgelegd. Pas dan zal iemand de functies van de software beter begrijpen en efficiënter en effectiever kunnen inzetten bij de uitvoering van een taak.

Zo gebruikt een high-ticket coach Facebook Ads op een andere manier …

...dan een e-commercespecialist.

#5 Ondersteun foutherkenning en probleemoplossing om de gebruiker frustratie te besparen

Elke softwaregebruiker kan iets foust doen of een bepaalde actie niet tot het gewenste resultaat brengen. Fouten zijn menselijk en geen enkel product kan dit voorkomen. Volgens onderzoek [1] besteden gebruikers gemiddeld 25% tot 50% van hun tijd aan het corrigeren van fouten. Accepteer daarom dat er fouten worden gemaakt en ondersteun de gebruiker bij het oplossen van veelvoorkomende fouten.

Voorbeeld van een foutoplossing direct na de instructie.

#6 Ondersteun lezen om te doen, studeren en lokaliseren

Soms raadplegen gebruikers documentatie om te studeren, soms om gericht informatie te vinden. Maar meestal gebruiken ze softwaredocumentatie om problemen op te lossen of om ondersteuning te krijgen bij het uitvoeren van hun taken.

Een softwarehandleiding zou deze leesstrategieën op de een of andere manier moeten ondersteunen. Door aan het einde van een procedure naar een referentietekst te verwijzen of meer informatie te geven, stimuleer je het leerproces van de gebruiker.

In dit voorbeeld wordt de gebruiker gestimuleerd om verder te leren.

#7 Geef voldoende contextuele informatie voor het begrijpen van de instructies

Soms is het nodig om gebruikers contextuele informatie te geven voordat ze een bepaalde procedure doorlopen. Contextuele informatie kan de volgende functies hebben:

• aangeven wat de gebruiker aan kennis en achtergrond nodig heeft om de instructies te begrijpen;
• aangeven wat het algemene uitgangspunt is van de procedure en wat ermee wordt bereikt;
• aangeven onder welke voorwaarden de instructies wel of niet moeten worden gebruikt;
• een overzicht geven van de inhoud van de instructies.

In deze procedure volgen de instructies na de contextuele achtergrondinformatie.

#8 Zorg ervoor dat gebruikers gemakkelijk kunnen vinden wat ze zoeken

Gebruiksinformatie moet functies bevatten die eenvoudig toegang tot informatie geven, zoals een inhoudsopgave, een index en andere zoekmogelijkheden.

Dergelijke zoek- en navigatiefuncties tonen de locatie, zoals de naam van de topic of het paginanummer, waar gebruikers naartoe kunnen gaan vanaf hun huidige locatie.

Online help met een zoekfunctie en een inhoudsopgave.

#9 Formuleer betekenisvolle headings en help gebruikers te vinden wat ze zoeken

Het is belangrijk om headings zorgvuldig te formuleren. Een consistente stijl, opmaak en formulering zorgen ervoor dat gebruikers eenvoudig de informatie kunnen vinden waarnaar ze op zoek zijn.

Headings worden vermeld in de inhoudsopgave/menustructuur. Lezers raadplegen de inhoudsopgave/het menu om zo snel mogelijk naar het onderdeel te gaan dat de informatie bevat waar ze naar op zoek zijn. Een duidelijke naam die het vermoeden creëert dat de gewenste informatie binnen die topic gevonden kan worden, is essentieel. Zorg er dus voor dat de headings betekenisvol zijn. De heading Hoe bak ik pannenkoeken? is veel meer gebruikersgericht dan Functies van de MagicMix2000.

#10 Gebruik modulaire bouwstenen

In de wereld van de technische communicatie is topic-based schrijven dé standaard. Topic-based schrijven is een modulaire benadering van contentcreatie waarbij content is gestructureerd rondom topics die kunnen worden hergebruikt in verschillende contexten.

Een contentmanagementsysteem (CMS) of componentcontentmanagementsysteem (CCMS) maakt gebruik van een modulaire structuur. Hoewel modulaire documentatie niet noodzakelijk op XML is gebaseerd, is dit meestal wel het geval. Standaarden die XML gebruiken zijn onder meer DITA en S1000D.

Voordelen van het beheren van inhoud op componentniveau zijn een hogere consistentie en nauwkeurigheid, lagere onderhoudskosten, lagere vertaalkosten en traceerbaarheid.

#11 Gebruik heldere stappen voor het schrijven van de instructies

Een voorbeeld:

Om Nederlands te selecteren als uw standaardtaal: 

1. Ga naar Bestand>Taal.
2. Selecteer Nederlands.

...is veel gebruiksvriendelijker dan…

Om Nederlands in te stellen als uw standaardtaal, selecteert u Nederlands wanneer u klikt op Taal in het menu Bestand.

Instructies kun je het best presenteren in de vorm van genummerde stappen. Een reeks opeenvolgende stappen beschrijft het proces dat moet worden doorlopen om een bepaalde taak uit te voeren. Een serie stappen heeft een duidelijk doel dat altijd taakgericht en relevant moet zijn.

Zorg ervoor dat stappen kort zijn. Eenvoudige zinnen met niet meer dan één instructie, of in sommige gevallen een klein aantal nauw verwante instructies, werken het best. Aan het eind van de stappen moet een taak voltooid zijn. Een dood spoor is uit den boze; zorg er dus voor dat de gebruiker, na het doorlopen van de stappen, het probleem heeft opgelost.

#12 Selecteer actieve werkwoorden en zelfstandig naamwoorden zorgvuldig

Door het gebruik van de actieve vorm worden instructies duidelijker, korter en directer. Schrijf instructies in de tegenwoordige tijd en gebruik sterke werkwoorden. Instructies die in de actieve vorm zijn geschreven, zijn gemakkelijker te lezen en te begrijpen omdat het onderwerp en het werkwoord altijd duidelijk zijn.

De zin ‘Sluit een toetsenbord aan op een USB-poort van het externe apparaat.’ is duidelijker dan ‘Er moet een toetsenbord op een USB-poort van het externe apparaat aangesloten worden.’

In de eerste zin is aansluiten het actieve werkwoord en zijn toetsenbord, USB-poort en externe apparaat allemaal onderwerpen. De tweede zin is in de passieve vorm geschreven. Het is in de actieve vorm veel duidelijker dat de lezer degene is die de beschreven actie moet uitvoeren.

#13 Zorg voor consistentie

Het is van cruciaal belang dat termen, productelementen (zoals knoppen, vensters, enz.) en eenheden op een consistente manier worden gebruikt. Dit voorkomt dubbelzinnigheid en daardoor verwarring en frustratie bij de gebruiker.

Bestaand materiaal is meestal niet altijd even duidelijk: er is een gebrek aan structuur, consistentie of heldere instructies. Het is de taak van de technisch schrijver om op een consistente manier over de gebruiksinformatie te communiceren. Dat kan onder andere door een consistent gebruik van de terminologie.

Daarnaast is het belangrijk dat de verschillende informatietypen, zoals waarschuwingen, stappen, foutherkenning en tips een consistente opmaak hebben en steeds op dezelfde manier worden gepresenteerd. Een consistente opmaak voor verschillende informatietypen zorgt ervoor dat de lezer deze bewust of onbewust herkent en koppelt aan de functie van dat informatietype.

In het volgende voorbeeld zijn de heading, instructies, productelementen en tipkaders allemaal informatietypen die in de gehele softwarehandleiding een consistente opmaak hebben.

#14 Vermijd jargon

Softwaredocumentatie moet geschreven zijn voor het doelpubliek en zo min mogelijk jargon bevatten. Vaak wordt productinformatie aangeleverd door subject matter experts (SMEs), zoals softwareontwikkelaars. De meeste ontwikkelaars houden zich liever bezig met het voor elkaar krijgen van bepaalde zaken en het behalen van resultaten dan met het schrijven erover.

Vaak gebruiken ze veel jargon. Als technisch schrijver is het belangrijk de juiste vragen te stellen over de betekenis van bepaalde termen en om te beslissen welke informatie moet worden gebruikt in de softwaredocumentatie, zodat het begrijpelijk is voor de uiteindelijke gebruiker.

#15 Gebruik een stijlgids voor consistente instructies

Een stijlgids bevat een reeks standaarden en regels voor het schrijven en ontwerpen van content. Een stijlgids voor technisch schrijven definieert de stijl die moet worden gebruikt in de technische communicatie, zoals in gebruikershandleidingen en online help. Een stijlgids helpt om softwaredocumentatie op een duidelijke manier te schrijven en om een ​​consistente toon en stijl te behouden.

Een stijlgids beschrijft bijvoorbeeld hoe wordt omgegaan met afkortingen, headings, voorzetsels, figuurnummering, illustraties, afmetingen, eenheden, interpunctie, definities, kruisverwijzingen, zelfstandig naamwoorden, inspringen, opsommingen, tabellen, enzovoort. Een stijlgids stimuleert om alle details zorgvuldig te overwegen en dwingt om elke afzonderlijke zin nog eens goed te bekijken. Een stijlgids verbetert hierdoor de begrijpelijkheid van de softwaredocumentatie.

Wij hebben onze eigen stijlgids ontwikkeld.

In deze stijlgids is alles tot in detail vastgelegd.

Elke topic uit de stijlgids bestaat uit een set schrijfregels.

#16 Kies de outputvorm zorgvuldig (print, online)

Gebruikers willen over informatie beschikken op het moment dat zij deze nodig hebben. Voor desktopsoftware of een app volstaat een pdf of geprinte handleiding vaak niet. On-screen of on-device informatie heeft de voorkeur en het liefst is deze context sensitive.

Een bijkomend voordeel van een elektronisch medium is dat de informatie gemakkelijk te updaten en te doorzoeken is. Door de te gebruiken technical authoring tool of het CMS weloverwogen te kiezen, kun je met dezelfde single-sourced content zowel online als geprinte softwarehandleidingen creëren.

#17 Maak informatie context sensitive

Context sensitive help is een vorm van online help die wordt verkregen vanaf een specifiek punt in de staat van de software. Context sensitive help biedt ondersteuning voor de specifieke situatie die verband houdt met die staat.

Context sensitive help hoeft, in tegenstelling tot algemene online help of online handleidingen, niet als geheel toegankelijk te zijn om te lezen. Elke topic wordt verondersteld een toestand, situatie of kenmerk van de software uitgebreid te beschrijven.

De topics die wij ontwikkelen in ons CMS zijn XML- of HTML-files die met elke software kunnen worden geïntegreerd als context sensitive help.

#18 Wees selectief met de informatie die je laat zien: pas de hoeveelheid  informatie aan op de behoefte van de gebruiker

Soms heeft een gebruiker niet direct alle informatie nodig of is bepaalde informatie niet relevant. Een beginnend gebruiker heeft in veelvoorkomende gevallen meer informatie nodig dan een geoefend gebruiker. Je kunt er dan voor kiezen om bepaalde informatiedelen te verbergen en op afroep tevoorschijn te laten komen. Je laat de gebruiker dan zelf kiezen of hij iets nodig heeft en voorkomt daarmee een informatie-overload.

In het volgende voorbeeld is ervoor gekozen om een deel van de inhoudsopgave te verbergen.

In dit voorbeeld is de informatie voor verschillende gebruiksscenario's verborgen, waarbij de gebruiker dat scenario kiest wat voor hem relevant is.

#19 Maak indrukwekkende visuals

Visuals kunnen bestaan uit lijntekeningen, foto's, screenshots, symbolen, tabellen, grafieken en infographics. Screenshots, video’s en gif-animaties kunnen in softwaredocumentatie een overzicht geven van functionaliteiten, de tekst versterken, laten zien wat er moet gebeuren of het resultaat van een bepaalde actie presenteren.

#20 Gebruik een template en zorg voor een mooie vormgeving

Ondanks dat vrijwel alles mogelijk is als het om de vormgeving gaat, het werkt efficiënt om een template te gebruiken. Wij hebben onder andere de volgende templates ter beschikking:

 

#21 Voer een gebruiksonderzoek uit

Zelfs ervaren technisch schrijvers kunnen niet altijd even goed voorspellen welke problemen zich voordoen bij het gebruik van hun documentatie. De beste manier om erachter te komen wat gebruikers fout doen, is door het uitvoeren van een gebruiksonderzoek. Verzamel feedback van gebruikers en voer regelmatig updates van de documentatie door.

#22 Manage de content

Eerder bespraken we al de modulaire opbouw van informatie en dat een contentmanagementsysteem (CMS) hierbij kan helpen. Een CMS is een softwaresysteem dat het verzamelen, creëren, beheren en publiceren van informatie automatiseert. De inhoud, het ontwerp en de structuur kunnen gescheiden worden gehouden met een contentmanagementsysteem. Op deze manier kan het CMS de gewenste content vanuit een single source in elke gewenste vorm publiceren. De content kan worden hergebruikt doordat hij op zichzelf staat, waardoor er efficiënt met informatie kan worden omgegaan en er kosten worden bespaard.

De voordelen van contentmanagementsystemen zijn het kunnen publiceren naar verschillende outputformaten met dezelfde inhoud (print en online), maximaal hergebruik van content, meertalige integratie en efficiëntere samenstelling van nieuwe documenten.

#23 Manage de vertalingen

Als de softwaredocumentatie moet worden vertaald naar meerdere talen, kan ook hier het gebruik van een CMS of CCMS een groot voordeel zijn. De meeste van deze tools zijn gebaseerd op industriestandaarden, zoals XLIFF en TMX. Vertalingen worden beheerd in het Translation Memory en alleen die delen die nog niet vertaald zijn, worden naar het vertaalbureau verzonden.

#24 Pas een agile proces toe dat aansluit bij het softwareontwikkelingsproces

Bij softwareontwikkeling wordt vaak gebruikgemaakt van agile ontwikkelmethoden. Deze trajecten zijn gericht op het snel en frequent opleveren van hoogwaardige software en omvatten vaak een gedetailleerde planning voor de korte termijn.

Hoewel agile ontwikkelmethoden vaak pleiten voor minder levenscyclusdocumentatie, verwachten de gebruikers van een softwareproduct nog steeds dat er kwaliteitsinformatie bij de software wordt geleverd. Hoewel het eindresultaat bij het ontwikkelen van softwarehandleidingen hetzelfde is, is de methode in een agile omgeving beduidend anders.

Agile ontwikkelmethoden volgen meestal korte, iteratieve ontwikkelingscycli op basis van klantspecificaties en feedback. Ontwikkelaars van de softwaredocumentatie moeten op de hoogte zijn van de agile processen en methoden die binnen een organisatie worden gebruikt, om hierop te kunnen aansluiten.

#25 Kies je informatieleverancier zorgvuldig uit 

Informatie voor gebruikers wordt vaak gezien als iets dat nog gedaan moet worden nadat het systeem is geïmplementeerd. Echter, voor informatie van hoge kwaliteit moet de ontwikkeling van softwaredocumentatie worden beschouwd als een integraal onderdeel van de software zelf. Het ontwikkelen van informatie van hoge kwaliteit vereist specifieke planning. Vaak is er een speciaal team in een bedrijf dat zich bezighoudt met technisch schrijven: het documentatieteam.

Een andere optie is outsourcing. Veel organisaties kiezen ervoor om het schrijven van de documentatie uit te besteden. Zorg er bij het uitbesteden voor dat de eisen voor het project duidelijk zijn door een projectplan op te stellen. Dit kan vaak samen met de mogelijke partner. Het projectplan beschrijft onder andere de eisen aan de planning, usability, veiligheid, vertalingen, kwaliteit, standaarden, enzovoort. Selecteer de informatieleverancier die het best in staat is de eisen in het projectplan te vervullen.

Tools om softwaredocumentatie te ontwikkelen

Er zijn diverse goede softwarepakketten en tools om online help en andere softwaredocumentatie te creëren.

Wij werken bijvoorbeeld met MadCap Flare, Author-it, SCHEMA ST4 en Adobe Framemaker. Andere tools zijn Fischer, Paligo, easyDITA, DITAToo etc. 

Enthousiast geworden om de mogelijkheden voor het ontwikkelen van uw online help of andere softwaredocumentatie? Neem dan eens contact met ons op. 

 NEEM CONTACT MET ONS OP

Ferry Vermeulen is technisch communicatie expert en directeur bij INSTRKTIV. Het is Ferry's missie om digitale gebruikersinstructies te maken voor alle producten ter wereld. Luister naar de INSTRKTIV podcast op Spotify of lees een van zijn laatste blogartikelen.  Linkedin I Spotify I YouTube I Facebook I Twitter