Ein Datensatz, jede Fläche.
Ein Termin-Plugin für kleine Studios: Eine Stunde wird einmal eingetragen und speist Stundenplan, Trainer-Karten, Kurspanel, Anmeldungen und strukturierte Daten. Gebaut, damit die Inhaberin einer Münchner Tanzschule ihre Website selbst betreiben kann, ohne eine Seite anzufassen.
- Gebaut
- Vier Datensatztypen, vier öffentliche Oberflächen, Anmeldungen mit eigenem Weg für Probestunden, Absage-Mail, Course-, Event- und Person-JSON-LD aus denselben Datensätzen wie die Anzeige.
- Methode
- Participatory Design: ein klickbares Mockup pro Oberfläche vor jeder Spec, getestet von der Inhaberin. KI schrieb den Code nach meinen Specs, ein zweites Modell prüfte ihn, ich habe jede Version auf Staging verifiziert.
- Einmal bewiesen
- Am Launch-Tag hat die Inhaberin jede Stunde selbst für Anmeldungen geöffnet und die Kapazitäten gesetzt. Seitdem sind die Versionen 1.11.18 bis 1.14.0 live gegangen. Stundenplan und Anmeldungen betreibt sie die ganze Zeit allein; ich liefere Versionen aus. Neun Wünsche von ihr bisher: acht live, einer mit Begründung abgelehnt.
Kernergebnis
- Erste Version
- Regel: erst Mockup
- Live; ihre ersten Änderungen ohne mich
- Ihre ersten Wünsche live
- Sechs Wochen: sie betreibt es allein
Kapitel
Trainer:in, Kurs und Zeit stehen im Datensatz, nie auf einer Seite.
Das ist die Grundregel, wörtlich. Die alte Website hatte ihren Stundenplan als ein einziges Bild und ihre Trainer:innen als von Hand getippte Seiten. Jede Änderung hieß drei Bearbeitungen und die Chance, eine zu vergessen. Das Plugin hält vier Datensatztypen (Kurs, Stunde, Trainer:in, Ort) und rendert daraus alles, was Besucher:innen sehen. Die Seite selbst enthält keine Fakten.
Ein Datensatz, vier Oberflächen
- Stundenplan-BlockWochenraster oder Tagesliste, je Kurs, Trainer:in und Ort
- Trainer-GridUnd Kurs-Trainer-Karten
- KurspanelPreise, Anmeldung, Probestunde, Warteliste
- JSON-LDCourse-, Event- und Person-Schema aus denselben Datensätzen
Eine Kurszeit oder eine Adresse steht im Stundenplan, auf einer Trainer-Karte, im Kurspanel und im JSON-LD. Von Hand gepflegte Kopien laufen auseinander; hier werden alle vier aus einem Datensatz erzeugt, es gibt also nichts, das auseinanderlaufen kann. Was die Datensätze für die Suche ausgeben, steht unter der Aufgabentabelle.
Dreizehn Aufgaben, die das Plugin jetzt für sie erledigt.
Ein Stundenplan, der sich selbst rendert, ist nur die halbe Sache. Die andere Hälfte ist die Arbeit rund um eine Stunde, die die Inhaberin bisher von Hand erledigt hat: Familien sagen, dass ein Platz frei ist, allen sagen, dass ein Termin ausfällt, zählen, wer kommt, löschen, was sie nicht behalten soll. Das sind die Aufgaben, die das Plugin heute auf kayjays.de erledigt, in der Reihenfolge, in der sie live gingen. Aufgeführt ist nur, was live ist.
| Ihre Aufgabe | Was das Plugin tut | Was es ihr bringt | Live seit |
|---|---|---|---|
| In einer vollen Stunde wird ein Platz frei | Alle auf der Warteliste dieses Termins bekommen sofort eine Mail; wer zuerst bucht, bekommt den Platz | Kein Herumtelefonieren mit der Warteliste | Zum Launch · |
| Eine Lehrkraft ist krank | Ein Klick sagt den Termin ab und schreibt allen, die gebucht haben. Wird der Termin zurückgenommen, folgt eine „Findet doch statt“-Mail. Kommt eine Mail nicht an, nennt der Bildschirm die Person, damit sie anrufen kann | Ein Klick, statt alle Gebuchten anzurufen | Zum Launch · |
| Eine Stunde füllt sich | Plätze werden pro Termin gezählt. „Nur noch wenige Plätze“, „Ausgebucht“ und der Anmeldeschluss schalten sich auf jeder Seite von selbst | Keine Überbuchung, keine Anrufe „Ist noch Platz?“ | Zum Launch · |
| Daten, die sie nicht behalten soll | Namen, E-Mail-Adressen und Telefonnummern löschen sich 90 Tage nach dem Termin von selbst, spätestens nach 97; nur die Zahl bleibt | Gelöscht wird, ohne dass sie daran denken muss | Zum Launch · |
| Ein Preis ändert sich | Eine Preistabelle. Jede Seite und jeder Satz mit einem Preis folgt ihr | Eine Änderung setzt den Preis auf allen 37 Seiten, die ihn zeigen | Zum Launch · |
| Ferien und Schließtage | Eine Schließzeit sperrt Buchungen an diesen Tagen und markiert die schon gemachten. Ein Hinweisbanner erscheint und verschwindet an den Tagen, die sie einträgt | Keine Buchungen an Schließtagen, nichts zu erstatten | 1.11.19 · |
| Anmeldungen in ihre Kundensoftware | Eine Liste aller Anmeldungen, neueste zuerst, und ein Tabellen-Export von allem seit dem letzten Export. Ihr Wunsch, entschieden am 25. Sep. | Export statt Namen abtippen | 1.11.23 · |
| Zu viele Probestunden in einer Stunde | Eine eigene Grenze für Probestunden pro Termin. Ist sie erreicht, bietet die Stunde stattdessen die normale Anmeldung an. Ihr Wunsch, entschieden am 30. Sep. | Die Stammkundschaft behält ihre Plätze | 1.11.25 · |
| Eine Anmeldung aus Versehen entfernt | Entfernen braucht in der Liste eine Bestätigung; der Eintrag wartet 14 Tage unter „Zuletzt gelöscht“ und lässt sich wiederherstellen, außer der Platz ist inzwischen vergeben | Wiederherstellen, statt die Eltern neu buchen zu lassen | 1.11.34 · |
| Eltern wollen erst eine Stunde ausprobieren | Die Probestunden-Seite bietet pro Stunde einen Knopf für die Probestunde zu 9 € und sonst nichts; eine volle Stunde zeigt „Ausgebucht“ und keinen Knopf. Entschieden am 2. und 3. Okt. anhand eines Mockups | Ein Knopf, ein Preis, nichts zu erklären | 1.11.35 · |
| Ein einmaliger Workshop | Ein Workshop mit Datum steht im Stundenplan und auf der Kursseite seines Stils, nimmt Buchungen an wie eine Stunde und steht auf einer gemeinsamen Workshop-Seite. Jeder ist in den strukturierten Daten ein Event. Ihr Wunsch, entschieden am 7. und 11. Okt. anhand von Mockups | Derselbe Buchungsweg wie bei Stunden, kein eigenes Formular | 1.11.47 · |
| Anmeldezahlen des letzten Monats | Monatliche Zahlen zu Anmeldungen, Probestunden, Workshops und Absagen pro Stunde, als Zahlen behalten, wenn die Namen gelöscht sind, mit Tabellen-Export. Keine Namen verlassen das Plugin. Entschieden am 15. Okt. | Trends überstehen das Löschen der Namen | 1.11.52 · |
| Wo Personendaten liegen | Ein Bildschirm, nur zum Lesen, listet jede Stelle, an der die Website personenbezogene Daten speichert: Anmeldungen, Warteliste, Formulare, Mail-Log, Newsletter, Server-Backups, jeweils mit der Angabe, wer sie wann löscht. Ein Backup, das älter als 30 Tage ist, wird rot. Entschieden am 21. Okt. anhand eines Mockups | Ein Bildschirm beantwortet „Was speichert ihr über mein Kind?“ | 1.11.53 · |
„Besonders praktisch ist, dass ich Inhalte wie den Stundenplan, Änderungen oder neue Kurse jederzeit selbst und ganz unkompliziert aktualisieren kann. Meine Kunden können sich direkt über die Website selbst für die gewünschten Kurse anmelden. Das spart mir unglaublich viel Zeit und vor allem jede Menge E-Mail-Schreiberei.“
Jessy, Inhaberin, KayJays
Was es für Suche und KI-Antworten tut.
Dieselben Datensätze, die das Studio betreiben, speisen auch Suchmaschinen und Assistenten. Nichts hier wird bisher als Effekt auf Ranking oder Zitate behauptet; diese Messung steht in Abschnitt 08.
| Funktion | Was sie tut | Warum es zählt | Live seit |
|---|---|---|---|
| Eine Quelle für Text und Schema | Fakten zu Kurs, Stunde, Workshop und Trainer:in erzeugen die sichtbare Seite und das JSON-LD aus demselben Datensatz. Eine geänderte Uhrzeit oder Lehrkraft ändert beides zugleich | Schema, das der Seite widerspricht, ist der häufigste Grund, Rich Results zu verlieren und einer KI-Antwort einen falschen Fakt zu liefern. Hier kann nichts auseinanderlaufen | Zum Launch · |
| Preise in Antworten | Eine Preistabelle; jeder FAQ-Eintrag „Was kostet …?“ und jede Erwähnung im Text wird aus ihr erzeugt | Die Frage mit der höchsten Kaufabsicht auf einer Kursseite bekommt eine genaue, aktuelle Antwort statt „ab …“ oder einer veralteten Zahl. 37 Seiten tragen sie | Zum Launch · |
| Live-Verfügbarkeit im Text | „Ausgebucht“, „Nur noch wenige Plätze“ und der Anmeldeschluss schalten sich von selbst | Frische, konkrete Zustandssignale; nirgends auf der Seite steht „Verfügbarkeit bitte anfragen“ | Zum Launch · |
| Buchungen als Messwert | Ist die Einstellung an, sendet jede Anmeldung, Probestunde und Wartelisten-Eintragung ein eigenes GA4-Ereignis mit Stunde, Termin und Standort; keine Namen, keine E-Mail-Adressen, keine Kurs-Nr. Standardmäßig aus. Der Bildschirm „Zahlen“ behält monatliche Zahlen pro Stunde (1.11.52, 21. Okt.) | Organischer Traffic lässt sich Buchungen pro Stunde zuordnen, nicht Sitzungen; so wird die SEO-Arbeit an Anmeldungen gemessen | 1.11.25 · |
| Workshops als Events | Ein Workshop mit Datum gibt ein EducationEvent mit Beginn, Ende und Ort aus und erscheint im Stundenplan und auf der Seite seines Stils | Termingebundene Events sind das eine Schema, das Google für kleine lokale Betriebe noch als Rich Result zeigt; das Plugin schreibt es aus dem Datensatz, niemand tippt Termine von Hand | 1.11.47 · |
| Level und Alter als Daten | Level am Kurs, Altersspanne an der Stunde, beides in CourseInstance | Die Zielgruppe ist der Filter, den Menschen und Assistenten nutzen; „ab 10 Jahren“ als Daten schlägt „Teens“ im Titel | 1.12.0 · |
| Faktenleiste mit der Antwort zuerst | Eine Kursseite beginnt mit bis zu sechs beschrifteten Fakten wie Wann / Für wen / Dauer / Preis, gepflegt als Felder am Kurs-Datensatz und vom Plugin ausgegeben. Live auf einer Kursseite (Dancehall) als Pilot; die anderen Kurse ziehen um, sobald er geprüft ist | Die vier Fakten, die eine Suche nach „hip hop kurs münchen erwachsene“ will, stehen im ersten Bildschirm als eine beschriftete Liste, genau das, was KI-Übersichten und Assistenten übernehmen | 1.14.0 · |
Die Oberfläche wird gezeichnet, bevor die Spec geschrieben wird.
Ab dem 8. September ging nichts mehr in den Build ohne ein klickbares Mockup der ganzen Oberfläche, die es betrifft, gezeichnet mit echten Staging-Daten und allen offenen Anfragen gleichzeitig. Das Mockup misst sich selbst (Breiten, Tipphöhen, Zeilenumbrüche), und die Entscheidung fällt auf der Seite. Erst dann wird die Spec geschrieben.
Getestet mit der Person, die es benutzen wird.
Die Mockups entscheiden, wie eine Oberfläche aussieht; die Inhaberin entscheidet, ob sie funktioniert. Ich saß neben ihr, während sie das Backend ohne Anleitung benutzt hat, habe notiert, wo sie gezögert und wonach sie gegriffen hat, und gefragt, was es als Nächstes können soll. Ihre Wünsche stehen im Backlog in ihren Worten, nicht in meinen.
Die Inhaberin der Tanzschule, auf Staging · 18. Sep. 2026
Sie hat jede Aufgabe ohne Hilfe erledigt. Dann fragte sie, was passiert, wenn eine Trainerin krank ist: Der Termin ließ sich absagen, aber niemand, der gebucht hatte, wurde informiert. Die Mail stand seit Anfang September auf einer To-do-Liste und war nie gebaut worden. Sie hat es bemerkt; daraus wurde die Absage-Mail, gebaut als 1.11.17 und live zur Umstellung.
Die Inhaberin der Kunstschule, bei der Backend-Tour · 18. Sep. 2026
Ihre Kurse laufen semesterweise, eine Warteliste gilt dort also einem Platz im Kurs, nicht einem Termin. Die Speicherung der Warteliste wurde vor der Auslieferung so geändert, dass sie einen Eintrag ohne Datum annimmt, mit einem Test als Beleg. Ihre übrigen Wünsche (wer nicht mehr kommt, ob es 700 Schüler:innen trägt, ein Raster für fünf Standorte) wurden mit Begründung in den Umfang aufgenommen oder ausgeschlossen und für ihren Rollout vorgemerkt.
Im Detail: was ein Mockup tragen muss und was es ablehnt
Eins pro Oberfläche, nie eins pro Anfrage. Eine Oberfläche sammelt jede offene Anfrage, die sie betrifft (die Stundenplanzeile trug sechs), sodass eine Entscheidung im Wissen um die anderen fällt. Die Seitenleiste ist so gezeichnet, wie Gutenberg sie zeichnet, mit denselben Bedienelementen und denselben deutschen Bezeichnungen, damit die Inhaberin Mockup und Editor unterscheiden kann.
Echte Daten, auf der Seite gemessen. Kursnamen, Zeiten, Trainer:innen und Buchungsstände werden aus Staging gelesen, nicht abgetippt. Breiten, Höhen und Zeilenzahlen werden live im Mockup berechnet, sodass ein Urteil „passt / bricht um“ eine Messung ist, keine Meinung.
Eine Liste „nicht auf dieser Oberfläche“. Jedes Mockup sagt, was es bewusst weglässt und warum: Das Kurskürzel bleibt in wp-admin, Absagen bleiben aus der Wochenzeile heraus, das mobile Akkordeon ist nach dem Launch eine eigene Oberfläche. Die Liste verhindert, dass eine Spec auf dem Weg zum Build wächst.
Geprüft, bevor es gezeigt wird. Jedes Mockup bekommt vor der Veröffentlichung ein Design-Audit (Barrierefreiheit, Responsivität, Theming, Umsetzungstreue); der Prüfbericht reist mit. Das CSS des Mockups ist eine Entscheidungshilfe. Bei jedem nicht entschiedenen Wert gewinnt die Spec und hält den Unterschied fest.
KI hat das PHP geschrieben. Alles, woraus es geschrieben wurde, verantworte ich.
Der Code wurde von KI-Modellen nach meinen Specs erzeugt, in fester Reihenfolge der Rollen: Architektur, Plan-Review, Gegenprüfung, Build, Review. Build und Review sind immer verschiedene Modelle, und jede Korrekturrunde bekommt ein unabhängiges Review.
Mein Teil
Die Datensatztypen und was jedes Feld bedeutet · jede Entscheidung, mit Datum festgehalten · die Mockups · die Liste „bewusst nicht gebaut“ · die Abnahmetests · was als fertig gilt · die Staging-Verifikation jeder Version · die Umstellung.
Der Teil der Modelle
Das PHP, JS und CSS · Migrationen unter einer Versionsnummer, die ich vergebe · das Plan-Review und die Gegenprüfung jeder Spec · das Code-Review jedes Builds · die Testsuite, rund 1.400 Tests, vor jeder Version auf PHP 7.4 und 8.3 ausgeführt · eine erneute Sicherheitsprüfung durch ein externes Modell im Oktober, die Korrekturen ausgeliefert als 1.11.51.
Die Schleuse, die jede Version passiert
In dieser Reihenfolge, jede Version. Gefüllte Schritte sind meine.
- Spec mit Entscheidungen
- Build
- Unabhängiges Review
- Zip
- Design-Audit
- Datenbank-Backup
- Installation auf Staging
- Meine Prüfung jeder geänderten Ansicht
- Live
Im Detail: die Fehler, die den Prozess geformt haben
Der stille Datenverlust. Quick Edit bei einer Trainerin schrieb deren ID als 0, und die Stunde verlor ihre Trainerin ohne Fehlermeldung. Der Fix berührte genau den Codepfad, der versagt hatte, deshalb ging er nicht in der Nacht raus, in der er geschrieben wurde: Am nächsten Morgen liefen zuerst alle Abnahmetests erneut.
Die falsche Review-Behauptung. Ein Review meldete, die Anmeldetabellen der Testseite fehlten. Es hatte Tabellennamen im Plural geprüft; die des Plugins stehen im Singular. Seitdem wird eine Aussage über die Datenbank mit einer Abfrage geprüft, bevor sie in eine Spec geht, und das Review macht nie das Modell, das gebaut hat.
Die Entscheidung, die nicht umgesetzt wurde. Ein mobiles Layout für den Stundenplan wurde am 12. September entschieden, bekam eine Versionsnummer und blieb zwölf Tage ungebaut; die Entscheidung stand in einem Dokument, das niemand wieder las. Ausgeliefert als 1.11.21 am 24. September. Regel seitdem: Eine reservierte Version mit geparkter Spec bekommt am selben Tag eine Zeile im aktiven Backlog.
Code-Kompetenz, noch im Aufbau. Ich spezifiziere, verifiziere und betreibe das Plugin; sein PHP flüssig zu lesen ist eine Fähigkeit, die ich an meiner eigenen Codebasis aufbaue, statt sie vorauszusetzen. Bis dahin muss sich der Bericht jeder Version auf dem Bildschirm beweisen, was ohnehin die bessere Regel ist.
Das Plugin erzeugt Fakten, nie Fließtext.
Es wird ebenso an dem gemessen, was es ablehnt, wie an dem, was es tut. Jeder dieser Punkte wurde mit Begründung ausgeschlossen, sodass eine künftige Anfrage auf eine Entscheidung trifft statt auf eine Lücke.
- Zahlungen, SEPA, Mitgliedsverträge. Haftung, die die Inhaberin nicht auf ihrer Website haben will. Verträge kommen vielleicht später; Geld nie.
- Teilnehmerakten, Anwesenheit, Audit-Log. Ein Mitgliedersystem ist ein anderes Produkt. Anmeldungen werden 90 Tage aufbewahrt und dann vollständig gelöscht.
- Newsletter-Versand. Das Plugin füllt die Liste des Mail-Anbieters; es verschickt keine Kampagnen. Eine Sache weniger, die abgesichert werden muss.
- Ein eigenes Admin-Design. Die Inhaberin kennt WordPress schon. Die Admin-Ansichten sehen aus wie WordPress; die öffentliche Seite überschreibt nie Schrift, Farbe oder Abstände des Themes.
- Automatischer Neuversand bei fehlgeschlagener Mail. Stattdessen nennt eine unzustellbare Absage-Mail die Person. Sie ruft dort an. Einfacher, und es scheitert sichtbar.
Eingebaut, weil die meisten Schüler:innen Kinder sind.
So wenig wie möglich erheben, nicht länger als nötig aufbewahren und jeden Schritt, der personenbezogene Daten berührt, zu einer sichtbaren Handlung machen statt zu einem Nebeneffekt.
- Namen und Adressen aus Anmeldungen löschen sich eine festgelegte Zahl von Tagen nach dem Termin selbst; nur die Anzahl bleibt.
- Die Anwesenheitsliste, die im Studio liegt, druckt gekürzte Namen, keine Liste mit den vollen Namen der Kinder.
- Keine externen Schriften oder Anfragen aus einem Block, außer die Website-Inhaberin schaltet sie ein.
- „Daten einer Person löschen“ entfernt jede Anmeldung zu einer Adresse, in einem Schritt.
- Trainer:innen bekommen einen signierten Link, kein Konto; ein neuer Schlüssel macht alle Links auf einmal ungültig.
Mechanismen, keine Rechtskonformität. Rechtsgrundlage, Datenschutzerklärung und Auftragsverarbeitungsverträge bleiben bei der Schule.
Was zum Launch gilt.
Gemessen am 23. September 2026. Das Versprechen des Plugins ist, dass eine Studio-Inhaberin eine Stunde, eine Trainerin oder einen Preis ändern kann, ohne eine Seite zu bearbeiten. An diesem Tag hat die Inhaberin jede Stunde selbst für Anmeldungen geöffnet und die Kapazitäten gesetzt, ohne mich im Raum, und dann die Eltern gebeten, als Test über die öffentlichen Formulare zu buchen. Was sie danach wollte (eine Absagefunktion, eine Telefonnummer bei Probestunden-Buchungen), kam als Zeilen in den Backlog, nicht als Chat. Eine Entfernen-Funktion für Anmeldungen wurde als 1.11.30 gebaut (2. Oktober) und ist seit 3. Oktober live.
Die letzte Zahl ist die, auf die es ankommt. Suchergebnisse zum Relaunch stehen in der Fallstudie kayjays.de, mit der Baseline von 2025 und Auswertungen am 4. November und 16. Dezember. Für das Plugin wird nichts über Traffic behauptet. Was das Plugin allein bewirkt, wird gesondert getestet: Sein Stundenplan-Block kommt auf die Websites anderer Tanzschulen, eine Änderung nach der anderen; kayjays.de bleibt als Referenz unberührt.
Was ich ändern würde, und was als Nächstes kommt.
- Mockups ab dem ersten Tag. Die ersten elf Versionen wurden aus Text spezifiziert. Die Regel „erst Mockup“ kam am 8. September, und die Fehlerquote pro Version sank danach; ohne sie würde ich nicht wieder bauen.
- Trainerseiten aus dem Datensatz. Zwölf Trainerseiten wurden für den Launch von Hand gebaut, weil der Generator nicht fertig war. Sie sind die letzten von Hand getippten Fakten auf der Website und das Erste, was diese Woche umzieht.
- Kursseiten aus dem Datensatz. Neun Kursseiten tragen noch von Hand getippten Text: Einleitung, was der Stil ist, FAQ. Dieser Text zieht als Nächstes in Kursfelder um, damit auch der letzte Fließtext auf der Website nur eine Quelle hat. Entschieden am 2. November anhand eines Mockups der Live-Seite.
- Das Plugin allein messen. Relaunch und Plugin gingen am selben Tag live, darum kann kayjays.de nicht zeigen, was das Plugin allein für die Suche bewirkt hat. Der Test ist ein gestaffelter Rollout auf den Websites anderer Schulen, drei Änderungen im Abstand von sechs Wochen: Stundenplan-Block, Kursseiten mit der Antwort zuerst, generierte Trainerseiten.
Quellen und Grenzen.
Die Messungen in dieser Fallstudie stammen aus den Release-Protokollen des Plugins, den Staging-Verifikationsprotokollen und dem Umstellungsprotokoll vom 23. September 2026. Die Zählungen (27 Stunden, 12 Trainer:innen, 45 Seiten, 26 Redirects) wurden an den genannten Tagen auf der Website abgelesen. Die Zahl der Anmeldungen stammt aus der Anmeldungen-Ansicht des Plugins am Abend des 24. September. Die Zahl zu gleichzeitigen Anfragen stammt aus dem Abnahmetest des Plugins. Versionen und Live-Daten im Zeitverlauf und in der Tabelle stammen aus den Release-Protokollen und dem Ideen-Board, am Veröffentlichungstag neu gezählt. Als Mockup gekennzeichnete Screenshots verwenden erfundene Namen. Nichts hier ist geschätzt.