Dokumentation und Wissensdatenbank

Was diese Kategorie abdeckt

Orte, um Dinge aufzuschreiben, damit andere sie finden: Hilfecenter für Kunden, interne Handbücher, Entwicklerdokumentation und die Suche, die all das nutzbar macht.

Entscheidend ist die Zielgruppe. Dokumentation für Kunden braucht eine öffentliche Adresse, einen Review-Prozess und Sprache für jemanden, der schon feststeckt. Dokumentation für Mitarbeiter darf unordentlicher sein und braucht stattdessen Berechtigungen.

Persönliches und Wissen kleiner Teams gehört zu Notizen und Wiki. Die Ticket-Warteschlange, in der unbeantwortete Fragen ankommen, ist Kundensupport.

Die Struktur entscheidet, ob etwas gefunden wird

Jedes Dokumentationsprojekt beginnt geordnet und endet als Haufen. Das Tooling bremst das entweder oder beschleunigt es.

Sehen Sie sich an, wie die Hierarchie funktioniert: Kategorien, Unterseiten, Querverweise und ob eine Seite an zwei Orten stehen kann, ohne dupliziert zu werden. Sehen Sie dann, was bei dreihundert Seiten passiert, wo eine für dreißig gedachte Navigation zusammenbricht.

Die Suche ist der ehrliche Test. Probieren Sie eine Anfrage mit den Wörtern, die ein Kunde benutzen würde, statt mit Ihrem internen Vokabular. Produkte, die nur Titel abgleichen, fallen durch, und die Leser landen stattdessen in Ihrer Support-Warteschlange.

Tags und Vorschläge verwandter Artikel helfen, wenn sie gepflegt werden. Von Hand pflegt sie niemand lange, bevorzugen Sie also Produkte, die Verbindungen aus dem Inhalt erzeugen.

Schreiben, Review und Seiten wahr halten

Dokumentation verrottet still. Eine Seite, die im März stimmte, ist im September ein Support-Ticket, und nichts an ihr sieht falsch aus.

Brauchbare Produkte tragen Verantwortliche, Prüfdaten und einen Zuletzt-geprüft-Stempel, den der Leser sieht. Entwurfsstatus und Review-Workflow zählen, sobald mehr als zwei Personen schreiben, und der Versionsverlauf zählt beim ersten Mal, dass jemand fragt, was eine Seite vor der Änderung sagte.

Wiederverwendung ist ebenfalls prüfenswert. Ein Limit, ein Preis oder eine Liste unterstützter Versionen sollte einmal existieren und überall eingebunden werden, wo sie erscheint, statt in elf Seiten kopiert zu sein, die bis zum nächsten Quartal widersprüchlich sind.

Veröffentlichung und die Suchfrage

Ein öffentliches Hilfecenter ist eine Website und sollte sich wie eine verhalten.

• Saubere URLs, die eine Umorganisation überstehen, mit Weiterleitungen, wo sie es nicht tun.
• Bearbeitbare Titel und Beschreibungen pro Artikel, nicht aus der ersten Zeile erzeugt.
• Schnelle Seiten, ohne dass erst eine schwere Anwendung lädt, bevor der Text erscheint.
• Sitemaps, die sich bei der Veröffentlichung aktualisieren und nicht nach einem Zeitplan, an den sich niemand erinnert.
• Eine eigene Domain, damit das Material Autorität für Ihre eigene Website aufbaut statt für die des Anbieters.

Den letzten Punkt sollten Sie intern vertreten. Dokumentation ist oft der leistungsstärkste Inhalt, den ein Softwareunternehmen hat, und sie auf einer Subdomain des Anbieters zu hosten, verschenkt diesen Traffic.

Messung und die einzige Kennzahl, die zählt

Seitenaufrufe sagen fast nichts. Zwei Zahlen sagen viel.

Die erste sind Suchen, die kein brauchbares Ergebnis lieferten, eine geschriebene Liste dessen, was als Nächstes zu erstellen ist. Die zweite ist, ob Leser, die einen Artikel geöffnet haben, danach trotzdem den Support kontaktierten, wofür das Hilfecenter mit Ihrem Ticketsystem verbunden sein muss.

Überarbeiten Sie nach dieser Liste statt nach Meinung. Die fünf Artikel, die am häufigsten scheitern, sind mehr Aufmerksamkeit wert als fünfzig, die niemand besucht.

Wie diese Produkte berechnet werden

Nutzerplätze für Autoren, manchmal kostenloses Lesen für alle, manchmal pro registriertem internem Leser. Öffentliche Hilfecenter berechnen meist nach Autoren und Artikelmenge, interne Wikis nach Nutzern.

Achten Sie auf drei Grenzen. Eigene Domains, Versionierung und Single Sign-on liegen tendenziell jeweils eine Stufe über dem Einstiegstarif. Die Tiefe der Analytics ist eine vierte. Anbieter, die ein Hilfecenter mit einem Support-Produkt bündeln, bepreisen es oft als Zusatz statt es einzuschließen, eine der Gewohnheiten aus was Preisseiten verschweigen.

Exportieren Sie vor der Entscheidung alles und lesen Sie das Ergebnis. Markdown oder sauberes Markup heißt, dass Sie gehen können. Ein proprietäres Format heißt, dass das Archiv eine Geisel ist.

Ein Hilfecenter aus dem Nichts starten

Die erste Version sollte peinlich klein sein.

Nehmen Sie die zwanzig Fragen, die Ihre Support-Warteschlange am häufigsten erreichen, und beantworten Sie sie ordentlich. Das deckt den Großteil der Kontakte ab und dauert eine Woche, während die Planung einer vollständigen Struktur zuerst ein Quartal braucht und in der Zwischenzeit nichts beantwortet.

Schreiben Sie jeden Artikel für jemanden, der schon feststeckt, das heißt, erst die Antwort und danach die Erklärung. Screenshots altern schlecht, nutzen Sie sie also dort, wo sie wirklich helfen, und rechnen Sie damit, sie zu ersetzen.

Lassen Sie dann die Struktur entstehen. Nach dreißig Artikeln werden die Kategorien offensichtlich, und sie bei Artikel fünf aufzuzwingen heißt, ohnehin umzuorganisieren.

Veröffentlichen Sie die Suchbegriffe ohne Treffer als Ihre Schreibwarteschlange. Es ist der einzige Inhaltsplan in dieser Kategorie, der nie ausgeht und sich nie irrt.