Technisches Schreiben, dem man wirklich folgen kann
Gjethe schreibt technische Dokumentation für Software, Produkte und interne Prozesse: Benutzerhandbücher, Hilfecenter-Artikel, API-Referenzen und Entwicklerleitfäden, Onboarding-Dokumentation, Release Notes, Standardarbeitsanweisungen und Wissensdatenbanken. Unsere Autoren arbeiten mit Entwicklern zusammen, testen, was sie dokumentieren, und veröffentlichen in Tools wie GitBook, Docusaurus, Mintlify, Notion, Confluence oder Ihrem Helpdesk, auf Englisch, Albanisch oder Deutsch.
- Kostenlose Erstberatung
- Schriftliches Angebot für Ihr Projekt
- Flexible Zahlungsmeilensteine
Auf einen Blick
- Typen
- Benutzerhandbücher, API-Doku, Help-Center, SOPs
- Plattformen
- GitBook, Docusaurus, Mintlify, Notion, Confluence
- Formate
- Markdown, MDX, OpenAPI, HTML
- Sprachen
- Englisch, Albanisch, Deutsch
Definition
Was ist technische Dokumentation?
Technische Dokumentation ist die Kunst, klar und genau zu erklären, wie etwas funktioniert oder wie man etwas tut, für einen bestimmten Leser wie einen Kunden, einen Entwickler oder einen Mitarbeitenden.
Dokumentation ist Teil des Produkts. Fehlt sie oder ist sie falsch, öffnen Kunden Support-Tickets, Entwickler geben Ihre API auf, und neue Mitarbeitende stellen jede Woche dieselben Fragen. Gute Dokumentation wird für je einen Leser geschrieben, am echten Produkt getestet und aktuell gehalten, wenn sich das Produkt ändert.
Für wen ist es geeignet?
SaaS-Unternehmen
Help-Center und Onboarding-Guides, die Support-Tickets senken und die Einführung beschleunigen.
API- und Entwicklerprodukte
Referenzen und Anleitungen, mit denen Entwickler integrieren können, ohne Ihnen zu mailen.
Hardware- und Industrieunternehmen
Handbücher, Einrichtungsanleitungen und Wartungsverfahren, die sicher zu befolgen sind.
Wachsende Teams
Interne Verfahren und Onboarding-Dokumente, die bewahren, wie Arbeit erledigt wird.
Was enthalten ist und was Sie behalten
Was enthalten ist
- Dokumentationsaudit und Lückenanalyse
- Informationsarchitektur und Navigation
- Benutzerhandbücher und How-to-Artikel
- Help-Center-Artikel
- API-Referenz aus Ihrer OpenAPI oder Ihrem Code
- Developer-Quickstarts und Tutorials
- Release Notes und Changelogs
- Standardarbeitsanweisungen
- Screenshots, annotierte Bilder und einfache Diagramme
- Styleguide und Vorlagen für künftige Dokumente
Was Sie erhalten
Wird am Ende übergeben. Gehört Ihnen.
- Veröffentlichte Dokumentation in Ihrer Plattform
- Quelldateien in Markdown oder MDX in Ihrem Repository
- Ein Styleguide für die Dokumentation
- Vorlagen für neue Artikel
- Eine Wartungs-Checkliste, verknüpft mit Ihrem Release-Prozess
Welche Dokumentation brauchen Sie?
| Leser | Was sie brauchen | Typisches Format |
|---|---|---|
| Neuer Kunde | Einrichten und das erste Ergebnis erreichen | Einstiegsleitfaden |
| Bestehender Kunde | Eine bestimmte Aufgabe erledigen | Aufgabenbasierte Hilfeartikel |
| Entwickler | Schnell integrieren und Fehler behandeln | API-Referenz und Quickstart |
| Administrator | Konfigurieren, absichern und verwalten | Admin-Handbuch |
| Mitarbeitende | Einen Prozess jedes Mal gleich durchführen | Standardarbeitsanweisung |
Wir testen, was wir dokumentieren
Der schnellste Weg, Lücken in der Dokumentation zu finden, ist, ihr zu folgen. Unsere Autoren arbeiten jede Anleitung in einem Testkonto oder einer Sandbox durch, notieren, wo Produkt und Anweisungen abweichen, und klären Fragen mit Ihren Entwicklern vor der Veröffentlichung.
Bei APIs rufen wir die Endpunkte auf, prüfen die Beispielanfragen und -antworten und stellen sicher, dass Fehlermeldungen erklärt sind. Beispiele, die nicht laufen, gehören zu den Hauptgründen, warum Entwickler eine Integration abbrechen.
Docs as Code
Bei Entwicklerprodukten lebt Dokumentation oft am besten neben dem Code: Markdown oder MDX in Ihrem Repository, in Pull Requests geprüft und automatisch mit Tools wie Docusaurus, Mintlify oder GitBook veröffentlicht. So bleibt die Doku mit dem Produkt versioniert, und Updates werden Teil jedes Releases.
Bei Help-Centern für Kunden ist meist die Helpdesk-Plattform selbst das richtige Zuhause, damit Artikel aus Support-Antworten verlinkt und aus dem Produkt durchsucht werden können.
Dokumentation, die KI-Assistenten lesen können
Kunden fragen zunehmend ChatGPT, Claude oder Ihren eigenen Support-Bot, wie man Ihr Produkt nutzt. Klare Überschriften, eine Aufgabe pro Artikel, ausdrückliche Voraussetzungen und korrekte Beispiele erleichtern diesen Tools das korrekte Zitieren Ihrer Dokumentation. Wir können außerdem einen llms.txt-Index Ihrer Doku veröffentlichen, damit KI-Tools die richtigen Seiten finden.
Anzeichen, dass Ihre Dokumentation Arbeit braucht
- Der Support beantwortet jede Woche dieselben How-to-Fragen
- Screenshots zeigen eine alte Version des Produkts
- Entwickler fragen in Verkaufsgesprächen nach Beispielen
- Neue Mitarbeitende lernen Prozesse durch Herumfragen
- Niemand ist dafür zuständig, die Doku nach einem Release zu aktualisieren
- Die Suche im Help-Center findet selten die Antwort
Release Notes, die Kunden lesen
Release Notes werden oft für das Team geschrieben, das die Funktion gebaut hat. Kunden wollen wissen, was sich für sie geändert hat, ob sie etwas tun müssen und wo sie mehr erfahren. Wir schreiben Release Notes, die mit dem Nutzen beginnen, jede nötige Handlung erklären und auf den aktualisierten Hilfeartikel verlinken.
Für Entwicklerprodukte führen wir zusätzlich einen präzisen Changelog: Versionen, Breaking Changes, Deprecations und Migrationsschritte, damit Integratoren ohne Überraschungen upgraden können.
So funktioniert technisches Schreiben, Schritt für Schritt
Jeder Schritt hat ein klares Ergebnis, das Sie prüfen können. Der Zeitrahmen wird in Ihrem Angebot vereinbart.
- 1
Audit
Wir prüfen bestehende Dokumentation, Support-Tickets und Analytics, um Lücken zu finden.
- 2
Struktur
Leser, Themen und Navigation vor dem Schreiben abgestimmt.
- 3
Schreiben und testen
Entwürfe, geschrieben, während jeder Schritt im Produkt nachvollzogen wird.
- 4
Prüfung
Technische Prüfung durch Ihr Team, dann Lektorat auf Klarheit.
- 5
Veröffentlichen
In Ihrer Plattform veröffentlicht, mit Vorlagen für künftige Artikel.
- 6
Pflegen
Optionale Updates, verknüpft mit Ihrem Release-Prozess.
Tools und was Ihr Angebot beeinflusst
Die Preisgestaltung richtet sich nach Ihrem Projekt und wird in Ihrem Angebot vereinbart. Diese Faktoren bestimmen es.
| Faktor | Warum er wichtig ist |
|---|---|
| Anzahl der Artikel oder Seiten | Mehr Themen bedeuten mehr Recherche, Schreiben und Review. |
| Technische Tiefe | API- und Entwicklerdokumentation braucht mehr Tests als Benutzerhandbücher. |
| Zugang zu Experten | Schnelle Antworten Ihres Teams halten die Arbeit effizient. |
| Visuals | Screenshots, annotierte Bilder und Diagramme erhöhen den Produktionsaufwand. |
| Sprachen | Jede weitere Sprache braucht Übersetzung und Review. |
| Plattform-Einrichtung | Die Einrichtung einer neuen Doku-Plattform bedeutet anfänglichen Mehraufwand. |
| Bereich | Tools |
|---|---|
| Doku-Plattformen | GitBook, Docusaurus, Mintlify, ReadMe, Confluence, Notion |
| Help-Center | Zendesk Guide, Intercom Articles, Help Scout Docs, HubSpot Knowledge Base |
| API | OpenAPI, Postman, Swagger UI, Redoc |
| Visuals | Snagit, Figma, Excalidraw, Mermaid |
Häufige Fehler, die Sie vermeiden sollten
Was bei uns am häufigsten schiefgeht und wie ein gutes Projekt es vermeidet.
Für alle gleichzeitig schreiben
Eine Seite für Anfänger und Experten dient keinem von beiden. Schreiben Sie pro Seite für einen Leser.
Funktionen statt Aufgaben dokumentieren
Menschen kommen mit einer Aufgabe. Organisieren Sie nach dem, was sie erreichen wollen.
Beispiele, die nicht laufen
Kaputte Codebeispiele zerstören Vertrauen schneller als fehlende Dokumentation.
Kein Verantwortlicher nach dem Launch
Dokumentation veraltet nach wenigen Releases, sofern ihre Aktualisierung nicht Teil des Releases ist.
Häufig gestellte Fragen
Verstehen Ihre Autoren technische Produkte?
Ja. Unsere Autoren arbeiten täglich mit Entwicklern, lesen Code und APIs und testen, was sie dokumentieren, im Produkt selbst.
Können Sie API-Dokumentation aus unserer OpenAPI-Datei schreiben?
Ja. Wir nutzen Ihre OpenAPI-Spezifikation als Quelle für die Referenz und ergänzen Anleitungen, Beispiele und Fehlererklärungen darum.
Auf welchen Plattformen veröffentlichen Sie?
GitBook, Docusaurus, Mintlify, ReadMe, Confluence, Notion und Wissensdatenbanken von Helpdesks oder reines Markdown in Ihrem Repository.
Können Sie interne Prozesse dokumentieren?
Ja. Wir schreiben Standardarbeitsanweisungen und Onboarding-Guides, indem wir die Menschen befragen, die die Arbeit tun, und die Schritte testen.
Übersetzen Sie Dokumentation?
Wir schreiben auf Englisch, Albanisch und Deutsch und können weitere Sprachen über professionelle Übersetzer liefern.
Können Sie unsere Doku nach jedem Release aktuell halten?
Ja. Wir können Release Notes prüfen und betroffene Seiten im Rahmen einer laufenden Vereinbarung aktualisieren.
Nutzen Sie KI zum Schreiben von Dokumentation?
Wir können KI für erste Gliederungen oder Zusammenfassungen einsetzen, aber jede Seite wird von einem Menschen am echten Produkt geschrieben, getestet und geprüft.
Wie wird technische Dokumentation kalkuliert?
Sie wird nach Seitenzahl, technischer Tiefe, Visuals und Sprachen angeboten, nachdem wir prüfen, was existiert.
Können Sie mit Bildschirmaufnahmen und Gesprächen mit unseren Entwicklern arbeiten?
Ja. Kurze Aufnahmen oder Gespräche mit den Menschen, die eine Funktion gebaut haben, sind oft der schnellste Einstieg, und wir verwandeln sie in strukturierte, getestete Anleitungen.
Schreiben Sie Texte im Produkt wie Tooltips und Fehlermeldungen?
Ja. Microcopy hängt eng mit der Dokumentation zusammen, und einheitliche Formulierungen in Produkt und Doku helfen den Nutzern.
Können Sie unsere Doku auf eine neue Plattform migrieren?
Ja. Wir verschieben und restrukturieren bestehende Inhalte, beheben defekte Links und richten Weiterleitungen ein, damit alte URLs weiter funktionieren.
Verwandte Leistungen
Content-Erstellung
Website-Texte, Artikel und Beschreibungen, von Menschen geschrieben.
Individuelle API-Entwicklung
Dokumentierte REST-, GraphQL- und WebSocket-APIs.
Übersetzung & Lokalisierung
Für jede Sprache und jeden Markt angepasste Inhalte.
Kundensupport
E-Mail-, Chat- und Helpdesk-Support für Ihre Kunden.
Technisches Schreiben nach Branche
Machen Sie Ihr Produkt leichter nutzbar.
Sagen Sie uns, was Sie brauchen. Sie erhalten eine ehrliche Einschätzung, einen klaren Plan und ein schriftliches Angebot. Die erste Beratung ist immer kostenlos.
- Wie es weitergeht
- 1Sie sagen uns, was Sie brauchen
- 2Wir melden uns möglichst innerhalb von 24 Stunden mit Rückfragen
- 3Sie erhalten ein schriftliches Angebot für Ihr Projekt