EmDash CMS – Nutzerdokumentation aus echten Gesprächen synthetisiert
Zuordnung wiederkehrender Nutzerfragen zu Langform-Dokumenten und FAQ-Einträgen, mit Veröffentlichungsprioritäten und redaktionellen Standards.
Warum diese Seite existiert
Sie dokumentiert, wie wiederholte Support-Gespräche in dauerhafte Dokumentations-Assets überführt wurden.
So bleibt die Docs-Strategie an beobachteter Nutzerreibung gekoppelt, nicht an internen Annahmen.
Schmerzpunkte und Dokumentenplatzierung
Schmerzpunkt 1: „Wie starte ich von einem leeren EmDash-Projekt?“
Beobachtetes Muster: Nutzer fragen nach Ordnerplanung vor dem ersten Code und brauchen Architektur-Trade-offs von Anfang an.
Platzierung: Langform in docs/docs, weil die Antwort Reihenfolge, Begründung und Anti-Pattern-Analyse braucht.
Zugeordnete Seite:
docs/docs/emdash-cms-project-bootstrap-and-directory-layout.mdx
Schmerzpunkt 2: „Kann ich auf Cloudflare Free deployen und was bricht genau?“
Beobachtetes Muster: Teil-Deployments gelingen, scheitern aber an Funktionsgrenzen und Interpretation von Abrechnungstexten.
Platzierung: Aufteilung zwischen docs/docs und docs/faq:
- Deployment-Runbook gehört in Langform-Docs
- Abrechnung und Grenzklärungen in die FAQ
Zugeordnete Seiten:
docs/docs/emdash-cms-cloudflare-free-tier-production-playbook.mdxdocs/faq/emdash-cms-cloudflare-pricing-and-billing-faq.mdxdocs/faq/emdash-cms-cloudflare-free-plan-limitations-faq.mdx
Schmerzpunkt 3: „Wo soll ich diese Befehle ausführen?“
Beobachtetes Muster: Befehle sind oft korrekt, das Arbeitsverzeichnis nicht.
Platzierung: FAQ – schnelle Diagnose und kurze Entscheidungsregeln.
Zugeordnete Seite:
docs/faq/emdash-cms-deployment-command-context-faq.mdx
Schmerzpunkt 4: „Wie prüfe ich, ob das Deployment wirklich fertig ist?“
Beobachtetes Muster: Nutzer stoppen bei Routen-Erreichbarkeit und verpassen Admin-/Datenpfad-Validierung.
Platzierung: FAQ im Checklistenformat mit schneller Triage-Reihenfolge.
Zugeordnete Seite:
docs/faq/emdash-cms-deployment-verification-and-first-login-faq.mdx
Schmerzpunkt 5: „Wofür ist Dynamic Workers eigentlich?“
Beobachtetes Muster: Der Name ist bekannt, Sicherheitsgrenzen nicht.
Platzierung: Architektur-Leitfaden in docs/docs – Modellerklärung, kein Einzeiler.
Zugeordnete Seite:
docs/docs/emdash-cms-plugin-runtime-and-security-model.mdx
Veröffentlichungsreihenfolge und Begründung
Empfohlene Reihenfolge:
docs/faq/emdash-cms-cloudflare-pricing-and-billing-faq.mdxdocs/docs/emdash-cms-cloudflare-free-tier-production-playbook.mdxdocs/faq/emdash-cms-cloudflare-free-plan-limitations-faq.mdxdocs/docs/emdash-cms-project-bootstrap-and-directory-layout.mdx- übrige Architektur- und Self-Hosted-Referenzen
Prinzip:
- zuerst Themen mit höchster Verwirrung und Support-Last
- dann vollständige Ausführungsleitfäden
- dann tiefe Architekturreferenzen
Redaktionsregeln für glaubwürdige Dokumentation
Standards für künftige Ergänzungen:
- mit Entscheidung und Grenze beginnen, dann Mechanismus
- Erfolgs- und Fehlersignale pro Operation angeben
- Rollback oder Fallback bei jedem hochriskanten Schritt
- keine abstrakten Adjektive ohne messbare Kriterien
- für Operateure unter Zeitdruck schreiben, nicht im Marketing-Ton
Pflege-Routine
Diese Zuordnung monatlich prüfen mit drei Inputs:
- häufigste wiederholte Support-Fragen
- fehlgeschlagene Deployments aus Nutzerberichten
- Doc-Seiten mit hohen Abbrüchen und wenig Abschluss-Feedback
Erscheint eine Frage im Support mehr als zweimal in einem Monat: bestehende Diagnostik verbessern oder gezielten FAQ-Eintrag ergänzen.