Technisch schrijven dat mensen echt kunnen volgen
Gjethe schrijft technische documentatie voor software, producten en interne processen: gebruikershandleidingen, artikelen voor helpcentra, API-referenties en ontwikkelaarsgidsen, onboardingdocumentatie, release notes, standaardwerkprocedures en kennisbanken. Onze schrijvers werken samen met ontwikkelaars, testen wat ze documenteren en publiceren in tools als GitBook, Docusaurus, Mintlify, Notion, Confluence of uw helpdesk, in het Engels, Albanees of Duits.
- Gratis eerste adviesgesprek
- Schriftelijke offerte voor uw project
- Flexibele betaalmijlpalen
In één oogopslag
- Types
- Gebruikershandleidingen, API-documentatie, helpcentra, SOP's
- Platforms
- GitBook, Docusaurus, Mintlify, Notion, Confluence
- Formats
- Markdown, MDX, OpenAPI, HTML
- Talen
- Engels, Albanees, Duits
Definition
Wat is technisch schrijven?
Technisch schrijven is het vak om helder en nauwkeurig uit te leggen hoe iets werkt of hoe iets te doen, voor een specifieke lezer zoals een klant, een ontwikkelaar of een medewerker.
Documentatie is onderdeel van het product. Wanneer ze ontbreekt of fout is, openen klanten supporttickets, geven ontwikkelaars uw API op en stellen nieuwe medewerkers elke week dezelfde vragen. Goede documentatie is geschreven voor één lezer tegelijk, getest tegen het echte product en bijgehouden naarmate het product verandert.
Voor wie is het?
SaaS-bedrijven
Helpcentra en onboardinggidsen die supporttickets verminderen en adoptie versnellen.
API- en ontwikkelaarsproducten
Referenties en gidsen waarmee ontwikkelaars kunnen integreren zonder u te mailen.
Hardware- en industriële bedrijven
Handleidingen, installatiegidsen en onderhoudsprocedures die veilig te volgen zijn.
Groeiende teams
Interne procedures en onboardingdocumenten die bewaren hoe het werk wordt gedaan.
Wat is inbegrepen en wat u houdt
Wat is inbegrepen
- Audit van documentatie en hiaatanalyse
- Informatiearchitectuur en navigatie
- Gebruikershandleidingen en how-toartikelen
- Artikelen voor het helpcentrum
- API-referentie uit uw OpenAPI of code
- Quick-starts en tutorials voor ontwikkelaars
- Release notes en changelogs
- Standaardwerkprocedures
- Screenshots, geannoteerde afbeeldingen en eenvoudige diagrammen
- Stijlgids en sjablonen voor toekomstige documenten
Wat u ontvangt
Aan het einde overgedragen. Van u om te houden.
- Gepubliceerde documentatie in uw platform
- Bronbestanden in Markdown of MDX in uw repository
- Een stijlgids voor documentatie
- Sjablonen voor nieuwe artikelen
- Een onderhoudschecklist gekoppeld aan uw releaseproces
Welke documentatie hebt u nodig?
| Lezer | Wat ze nodig hebben | Typisch formaat |
|---|---|---|
| Nieuwe klant | Aan de slag en het eerste resultaat bereiken | Aan-de-slag-gids |
| Bestaande klant | Eén specifieke taak uitvoeren | Taakgerichte helpartikelen |
| Ontwikkelaar | Snel integreren en fouten afhandelen | API-referentie en quick-start |
| Administrator | Configureren, beveiligen en beheren | Beheerdersgids |
| Medewerker | Een proces telkens op dezelfde manier uitvoeren | Standaardwerkprocedure |
We testen wat we documenteren
De snelste manier om hiaten in documentatie te vinden is haar te volgen. Onze schrijvers doorlopen elke gids in een testaccount of sandbox, noteren waar het product en de instructies verschillen en leggen vragen aan uw ontwikkelaars voor vóór publicatie.
Voor API's roepen we de endpoints aan, controleren we de voorbeeldverzoeken en -antwoorden en zorgen we dat foutmeldingen worden uitgelegd. Voorbeelden die niet werken zijn een van de belangrijkste redenen waarom ontwikkelaars een integratie opgeven.
Docs as code
Voor ontwikkelaarsproducten staat documentatie vaak het best naast de code: Markdown of MDX in uw repository, beoordeeld in pull requests en automatisch gepubliceerd met tools als Docusaurus, Mintlify of GitBook. Dat houdt documentatie versiegebonden aan het product en maakt updates onderdeel van elke release.
Voor helpcentra voor klanten is het helpdeskplatform zelf meestal de juiste plek, zodat artikelen vanuit supportantwoorden kunnen worden gelinkt en vanuit het product doorzocht.
Documentatie die AI-assistenten kunnen lezen
Klanten vragen steeds vaker aan ChatGPT, Claude of uw eigen supportbot hoe ze uw product gebruiken. Duidelijke koppen, één taak per artikel, expliciete vereisten en nauwkeurige voorbeelden maken documentatie makkelijker correct te citeren voor deze tools. We kunnen ook een llms.txt-index van uw documentatie publiceren zodat AI-tools de juiste pagina's vinden.
Tekenen dat uw documentatie aandacht nodig heeft
- Support beantwoordt elke week dezelfde how-tovragen
- Screenshots tonen een oude versie van het product
- Ontwikkelaars vragen in verkoopgesprekken om voorbeelden
- Nieuwe medewerkers leren processen door rond te vragen
- Niemand is eigenaar van het bijwerken van de documentatie na een release
- Zoeken in uw helpcentrum vindt zelden het antwoord
Release notes die klanten lezen
Release notes worden vaak geschreven voor het team dat de functie bouwde. Klanten willen weten wat er voor hen veranderd is, of ze iets moeten doen en waar ze meer kunnen leren. We schrijven release notes die met het voordeel openen, vereiste acties uitleggen en linken naar het bijgewerkte helpartikel.
Voor ontwikkelaarsproducten houden we daarnaast een nauwkeurige changelog bij: versies, brekende wijzigingen, deprecaties en migratiestappen, zodat integrators zonder verrassingen kunnen upgraden.
Hoe technisch schrijven werkt, stap voor stap
Elke stap heeft een duidelijk resultaat dat u kunt beoordelen. De planning wordt afgesproken in uw offerte.
- 1
Audit
We beoordelen bestaande documentatie, supporttickets en analyses om hiaten te vinden.
- 2
Structuur
Lezers, onderwerpen en navigatie afgestemd vóór het schrijven.
- 3
Schrijven en testen
Concepten geschreven terwijl elke stap in het product wordt gevolgd.
- 4
Beoordeling
Technische beoordeling door uw team, daarna redactie voor helderheid.
- 5
Publiceren
Gepubliceerd in uw platform met sjablonen voor toekomstige artikelen.
- 6
Onderhouden
Optionele updates gekoppeld aan uw releaseproces.
Tools, en wat uw offerte bepaalt
De prijs hangt af van uw project en wordt afgesproken in uw offerte. Dit zijn de zaken die hem beïnvloeden.
| Factor | Waarom het ertoe doet |
|---|---|
| Aantal artikelen of pagina's | Meer onderwerpen betekenen meer onderzoek, schrijven en beoordeling. |
| Technische diepgang | API- en ontwikkelaarsdocumentatie vragen meer testen dan gebruikershandleidingen. |
| Toegang tot experts | Snelle antwoorden van uw team houden het werk efficiënt. |
| Visuals | Screenshots, geannoteerde afbeeldingen en diagrammen voegen productietijd toe. |
| Talen | Elke extra taal vraagt vertaling en beoordeling. |
| Platforminrichting | Een nieuw documentatieplatform opzetten voegt aanvankelijk werk toe. |
| Gebied | Tools |
|---|---|
| Documentatieplatforms | GitBook, Docusaurus, Mintlify, ReadMe, Confluence, Notion |
| Helpcentra | Zendesk Guide, Intercom Articles, Help Scout Docs, HubSpot Knowledge Base |
| API | OpenAPI, Postman, Swagger UI, Redoc |
| Visuals | Snagit, Figma, Excalidraw, Mermaid |
Veelgemaakte fouten die u moet vermijden
Wat we het vaakst mis zien gaan, en hoe een goed project dat voorkomt.
Voor iedereen tegelijk schrijven
Een pagina voor beginners én experts dient geen van beiden. Schrijf voor één lezer per pagina.
Functies documenteren in plaats van taken
Mensen komen met een klus. Organiseer rond wat ze willen bereiken.
Voorbeelden die niet werken
Kapotte codevoorbeelden vernietigen vertrouwen sneller dan ontbrekende documentatie.
Geen eigenaar na de lancering
Documentatie veroudert binnen een paar releases tenzij bijwerken deel van de release is.
Veelgestelde vragen
Begrijpen jullie schrijvers technische producten?
Ja. Onze schrijvers werken dagelijks met ontwikkelaars, lezen code en API's en testen wat ze documenteren in het product zelf.
Kunt u API-documentatie schrijven op basis van ons OpenAPI-bestand?
Ja. We gebruiken uw OpenAPI-specificatie als bron voor de referentie en voegen er gidsen, voorbeelden en foutuitleg omheen toe.
Naar welke platforms publiceren jullie?
GitBook, Docusaurus, Mintlify, ReadMe, Confluence, Notion en kennisbanken van helpdesks of gewone Markdown in uw repository.
Kunt u interne processen documenteren?
Ja. We schrijven standaardwerkprocedures en onboardinggidsen door de mensen die het werk doen te interviewen en de stappen te testen.
Vertalen jullie documentatie?
We schrijven in het Engels, Albanees en Duits en kunnen andere talen leveren via professionele vertalers.
Kunt u onze documentatie na elke release bijwerken?
Ja. We kunnen release notes beoordelen en getroffen pagina's bijwerken als onderdeel van een doorlopende afspraak.
Gebruiken jullie AI om documentatie te schrijven?
We kunnen AI gebruiken voor eerste outlines of samenvattingen, maar elke pagina wordt door een persoon geschreven, getest en gecontroleerd tegen het echte product.
Hoe wordt technisch schrijven geprijsd?
Het wordt geoffreerd op basis van het aantal pagina's, de technische diepgang, visuals en talen, nadat we hebben bekeken wat er bestaat.
Kunt u werken met schermopnamen en gesprekken met onze ontwikkelaars?
Ja. Korte opnamen of gesprekken met de mensen die een functie hebben gebouwd zijn vaak de snelste manier om te beginnen en we zetten ze om in gestructureerde, geteste gidsen.
Schrijven jullie ook tekst in het product, zoals tooltips en foutmeldingen?
Ja. Microcopy hangt nauw samen met documentatie en consistente formuleringen tussen product en documentatie helpen gebruikers.
Kunt u onze documentatie migreren naar een nieuw platform?
Ja. We verplaatsen en herstructureren bestaande content, herstellen kapotte links en zetten redirects op zodat oude URL's blijven werken.
Gerelateerde diensten
Contentschrijven
Websiteteksten, artikelen en beschrijvingen, geschreven door mensen.
API-ontwikkeling op maat
Gedocumenteerde REST-, GraphQL- en WebSocket-API's.
Vertaling en lokalisatie
Content aangepast aan elke taal en elke markt.
Klantenservice
Ondersteuning per e-mail, chat en helpdesk voor uw klanten.
Technisch schrijven per sector
Maak uw product makkelijker in gebruik.
Vertel ons wat u nodig hebt. U krijgt een eerlijke beoordeling, een duidelijk plan en een schriftelijke offerte. Het eerste adviesgesprek is altijd gratis.
- Wat er daarna gebeurt
- 1U vertelt ons wat u nodig hebt
- 2We streven ernaar binnen 24 uur te reageren met vragen
- 3U ontvangt een schriftelijke offerte voor uw project