Dokumentationsseite ohne Code erstellen: Anleitung mit KI
Dokumentationsseite ohne Code erstellen: Anleitung mit KI
Eine Dokumentationsseite entsteht in Zugo aus einer Beschreibung des Produkts und einer Gliederung: Sie nennen die Kapitel, der Builder erstellt Navigation, Inhaltsseiten, Suche und Startseite. Vor der Übergabe läuft das Ergebnis in einer Sandbox. Eine mehrseitige Dokumentation braucht einige Minuten, eine einzelne Seite etwa eine Minute.
Der Aufwand liegt danach nicht mehr in der Technik, sondern in der Gliederung. Eine Dokumentation mit sauberer Struktur und mittelmäßigen Texten wird benutzt. Eine mit guten Texten und wirrer Navigation wird verlassen.
Wofür ist eine eigene Doku-Seite besser als ein PDF?
Viele Teams verschicken Handbücher weiterhin als PDF, und für einen Vertrag oder ein Datenblatt ist das genau richtig. Bei einer Produktdokumentation kippt die Rechnung aus vier Gründen.
Ein PDF wird nicht durchsucht, sondern durchgeblättert. Wer eine bestimmte Fehlermeldung sucht, findet sie in einer Webdoku über Suchfeld und Ankerlink in Sekunden. Im PDF öffnet er die Volltextsuche des Readers und landet bei Treffer vier von siebzehn.
Ein PDF hat kein Datum, das jemand sieht. Sobald zwei Versionen im Umlauf sind, arbeitet die Hälfte Ihrer Kunden mit der falschen, und Sie merken es erst im Support. Eine Webseite hat genau einen Stand.
Ein PDF lässt sich nicht verlinken. Support, Onboarding-Mails und Fehlermeldungen im Produkt zeigen bei einer Webdoku direkt auf den Absatz, um den es geht. Das ist der größte Zeitgewinn im Alltag.
Und ein PDF taucht in Suchmaschinen selten dort auf, wo gesucht wird. Wer Ihr Produkt noch nicht kennt, stößt über eine Doku-Seite darauf, weil sie exakt die Formulierung enthält, die er eingetippt hat.
Wie muss die Navigation aufgebaut sein?
Die Navigation ist die Doku. Alles andere ist Text, den man erst findet, wenn die Navigation stimmt. Sortieren Sie nicht nach Ihrer inneren Produktstruktur, sondern nach der Situation des Lesers.
In der Praxis fallen Doku-Texte in vier Sorten, und sie vertragen sich schlecht auf derselben Seite:
| Textsorte | Situation des Lesers | Typische Überschrift |
|---|---|---|
| Einstieg | kennt das Produkt noch nicht, will einen ersten Erfolg | „In zehn Minuten zum ersten Bericht“ |
| Anleitung | hat eine konkrete Aufgabe, kennt die Grundlagen | „Rechnung stornieren“ |
| Referenz | sucht eine exakte Angabe, liest nichts drumherum | „Felder im Exportformat“ |
| Hintergrund | will verstehen, warum etwas so funktioniert | „Wie die Rechteverwaltung gedacht ist“ |
Der häufigste Fehler ist die Vermischung von Anleitung und Hintergrund. Jemand will einen Nutzer anlegen und liest zuerst drei Absätze über das Rollenkonzept. Trennen Sie beides, und verlinken Sie den Hintergrund am Ende der Anleitung.
Der zweite häufige Fehler ist eine dritte Gliederungsebene. Sobald die Seitenleiste aufklappbare Unterunterpunkte hat, findet niemand mehr zurück. Zwei Ebenen genügen für erstaunlich große Dokumentationen.
Wie lautet der Prompt für eine Dokumentationsseite?
Geben Sie die Gliederung mit, statt sie erfinden zu lassen. Der Builder baut Struktur und Layout gut, aber er kennt Ihr Produkt nicht.
Baue eine Dokumentationsseite für eine Software zur Werkstattverwaltung. Linke Seitenleiste mit zwei Ebenen, oben ein Suchfeld, rechts eine Sprungliste zu den Überschriften der aktuellen Seite. Kapitel: Erste Schritte, Aufträge, Kunden und Fahrzeuge, Rechnungen, Schnittstellen, Häufige Fragen. Jede Inhaltsseite mit Überschriften, Codeblöcken, Hinweiskästen und Kopierschaltfläche. Sachlicher Ton, deutsche Sprache, helles Design, gut lesbar auch am Telefon.
Drei Angaben in diesem Prompt tragen weit. Die Sprungliste rechts, weil lange Referenzseiten sonst unbenutzbar werden. Die Hinweiskästen, weil Warnungen sich optisch vom Fließtext abheben müssen. Und die Kopierschaltfläche bei Codeblöcken, weil sie den häufigsten Handgriff in jeder technischen Doku spart.
Nicht in den ersten Prompt gehören die eigentlichen Texte. Lassen Sie das Gerüst mit Platzhaltern bauen, prüfen Sie die Navigation und füllen Sie erst dann. Sonst werfen Sie beim ersten Umbau geschriebene Inhalte weg.
Was kostet eine Dokumentation in Credits?
Eine Doku ist immer eine mehrseitige Plattform. Der Preis hängt an der Zahl der Seiten, nicht an der Textmenge.
| Aktion | Credits | Im Hi-Fi-Modus |
|---|---|---|
| Mehrseitige Plattform, erste drei Seiten | 12 | doppelt |
| Jede weitere Seite | 3 | doppelt |
| Spätere Änderung | 3 | 6 |
| Einzelner Build | 6 | 12 |
Eine Dokumentation mit sechs Kapitelseiten liegt im ersten Durchgang bei rund zwanzig Credits, eine mit zwölf Seiten bei knapp vierzig. Deshalb lohnt sich die Überlegung, ob wirklich jedes Kapitel eine eigene Seite braucht: Vier gut gegliederte Seiten mit Sprungmarken sind oft besser zu benutzen als zwölf kurze.
Die Tarife: Free gibt 5 Credits, Pro kostet 25 $ im Monat und enthält 200 Credits, Business kostet 99 $ im Monat und enthält 800. Zweihundert Credits sind etwa 16 mehrseitige Plattformen oder 33 Builds oder 66 Änderungen. Da 5 Credits unter den 6 für einen Build liegen, ist der kostenlose Tarif ein Rundgang und keine fertige Doku. Abgerechnet wird in US-Dollar. Wie mehrseitige Projekte generell entstehen, steht in kann KI eine mehrseitige Website bauen.
Wie kommen spätere Änderungen in die Dokumentation?
Hier liegt der eigentliche Unterschied zwischen einer Doku, die gepflegt wird, und einer, die nach vier Monaten falsch ist. Es gibt zwei Wege, und die Wahl hängt daran, wer schreibt.
Schreiben Sie selbst oder ein kleines Team ohne Entwickler, bleiben Sie im Builder. Jede Ergänzung ist eine Änderung, kostet 3 Credits und ist in Minuten erledigt. Kein Werkzeugwechsel, kein Freigabeprozess.
Schreiben mehrere Personen mit technischem Hintergrund, ist der Export nach GitHub der sauberere Weg. Dann liegen die Quellen in einem Repository, Änderungen laufen über die gewohnten Abläufe, und das Deployment kann über Vercel in Ihrem eigenen Konto stattfinden. Der Builder erzeugt in diesem Fall das Gerüst, und die Pflege wandert dorthin, wo ohnehin gearbeitet wird.
Was in beiden Fällen hilft: ein sichtbares Datum der letzten Änderung auf jeder Seite. Es kostet einen Satz im Prompt und beantwortet die Frage, die Leser bei jeder Doku im Hinterkopf haben. Für Versionshinweise und Neuerungen ist eine eigene Seite besser geeignet, siehe Changelog-Seite mit KI erstellen.
Wird eine Dokumentationsseite in Suchmaschinen gefunden?
Häufig besser als die Produktseite, und das überrascht viele. Der Grund ist die Sprache: Eine Doku enthält die Wörter, die Nutzer tatsächlich eingeben, also Fehlermeldungen, Feldnamen und konkrete Aufgaben. Marketingseiten enthalten die Wörter, die das Unternehmen benutzt.
Drei Dinge helfen dabei spürbar. Sprechende Adressen, in denen der Seitentitel steht, statt durchnummerierter Seiten. Eine Überschrift je Seite, die eine echte Frage oder Aufgabe benennt. Und interne Verlinkung zwischen verwandten Seiten, damit Suchmaschinen und Leser den Zusammenhang sehen.
Was Sie sich sparen können, ist das Aufblähen der Texte. Eine Referenzseite darf kurz sein. Eine Doku wird nicht dadurch besser gefunden, dass sie mehr Wörter hat, sondern dadurch, dass sie die richtige Frage präzise beantwortet. Wie Suchmaschinen mit KI-erstellten Seiten umgehen, behandelt ist eine KI-Website gut für SEO.
Ein Detail mit großer Wirkung: Wenn Ihr Produkt Fehlermeldungen ausgibt, geben Sie jedem Fehler einen eigenen Abschnitt mit dem exakten Wortlaut. Genau diesen Wortlaut kopieren Nutzer in die Suche.
Was leistet der Builder bei einer Dokumentation nicht?
Drei ehrliche Grenzen.
Er schreibt Ihre Inhalte nicht. Struktur, Navigation, Suchfeld und Layout entstehen aus dem Prompt, aber welche Schritte Ihr Produkt tatsächlich verlangt, weiß nur Ihr Team. Die Doku ist zu neunzig Prozent Textarbeit.
Automatische Referenzen aus dem Quellcode gibt es nicht. Wer eine API-Dokumentation aus Kommentaren oder einer Spezifikation erzeugen lassen will, braucht dafür ein eigenes Werkzeug. Der Builder erstellt Seiten, keine Generatoren.
Sehr spezielle Funktionen entstehen über mehrere Änderungen. Versionsumschalter für drei parallele Produktstände, mehrsprachige Fassungen mit Gleichlauf zwischen den Sprachen oder eine Suche, die nach Kapiteln gewichtet: Das ist erreichbar, aber schrittweise. Jeder Build läuft vor der Übergabe durch die Sandbox, und was nicht geöffnet hat, wird nicht ausgeliefert. Diese Prüfung sagt, dass die Seite startet, nicht dass Ihre Gliederung stimmt.
Welcher erste Schritt lohnt sich?
Schreiben Sie die Gliederung auf Papier, bevor Sie den Builder öffnen. Zwei Ebenen, höchstens acht Punkte auf der ersten Ebene, und zu jedem Punkt ein Satz, der die Situation des Lesers beschreibt. Diese halbe Stunde spart drei Umbauten.
Bauen Sie danach das Gerüst mit Platzhaltertexten und klicken Sie es durch, als suchten Sie etwas Bestimmtes. Erst wenn Sie in drei Klicks ankommen, füllen Sie die Texte. Für den Start gibt es 25 Vorlagen, davon 5 für Spiele, falls Sie lieber an etwas Fertigem ändern.
Legen Sie los auf zugo.dev, veröffentlichen Sie zunächst unter der Adresse auf zugo.run und geben Sie den Link Ihrem Support-Team. Die Rückmeldung nach einer Woche ist mehr wert als jede Planung vorher.