Was mir BMAD über Discovery beigebracht hat

Dieses Jahr habe ich ein Dessert-Kochbuch im Selbstverlag veröffentlicht. Es verkauft sich über Amazon, an Leute, die es bereits kennen. Was fehlt, ist ein Zuhause im offenen Web: Der QR-Code auf der Buchrückseite führt ins Leere, und wer den Titel bei Google eingibt, findet nichts.

Also habe ich mich entschieden, eine Landingpage zu bauen - und zwar mit BMAD als Planungswerkzeug.

Das Muster kenne ich zur Genüge: Jemand öffnet Cursor, beschreibt kurz eine Website, und dreißig Minuten später steht ein Prototyp mit Lorem Ipsum, einem Stock-Hero-Bild und lauter Design-Entscheidungen, die das Modell getroffen hat, weil es sich unter "moderne Kochbuch-Website" eben irgendetwas vorgestellt hat. Schnell gebaut, falsch gebaut - und aus zwei Wochen "lass uns das kurz anpassen" wird am Ende ein kompletter Rewrite.

Ich wollte es andersherum versuchen: erst wirklich Zeit investieren, die richtigen Fragen klären, dann erst bauen.

Dieser Beitrag beschreibt, was ich in der Hälfte des Experiments gelernt habe, die vor dem eigentlichen Code passiert - den Teil, den ich sonst am liebsten überspringe. Eine Session war für mich jeweils eine Sitzung am Rechner, meist 45 bis 90 Minuten, kein einzelner Prompt.

Kurz vorab: Das ist keine Schritt-für-Schritt-Anleitung mit Code. Es geht darum, wie sechs Sessions KI-gestützte Discovery in der Praxis tatsächlich aussahen - inklusive der Stellen, an denen es geruckelt hat. Wer gerade überlegt, ob BMAD oder ein ähnlicher agentischer Planungsworkflow etwas taugt, ist hier richtig. Der eigentliche Aufbau kommt in einem eigenen Beitrag, und ich werde dort auch verraten, ob die unten geschätzten zwei Sessions für die Umsetzung tatsächlich gereicht haben.

Was BMAD eigentlich ist

BMAD (Breakthrough Method for Agile AI-Driven Development) ist eine Sammlung von Skills, die man in Claude Code einhängt - oder in eine vergleichbare agentische Umgebung. Statt eines einzigen Allzweck-Assistenten bekommt man benannte Agenten: Mary übernimmt die Business-Analyse, John schreibt das PRD, Sally kümmert sich um UX, Winston um die Architektur, Amelia setzt die Stories um. Jeder hat seine eigene Persona, seine eigene Methode, sein eigenes Ergebnis - und jeder Durchgang schreibt in ein gemeinsames Arbeitsdokument, das BMAD den Design Spine nennt. Spätere Agenten und Reviewer lesen dieses Dokument direkt, statt bei null anzufangen.

Der eigentliche Trick sind nicht die Personas, sondern das, wozu sie einen zwingen, bevor überhaupt etwas gebaut wird. Der UX-Durchgang rendert kein Mockup, ohne vorher nach Barrierefreiheit gefragt zu haben. Der PM-Durchgang schreibt keine User Story, bevor die Ziel-Persona nicht sauber ausdiskutiert ist. Und der Analyst hört nicht auf, "Warum" zu fragen, bis ein klares Problem-Statement steht.

Diese vorgelagerte Phase lief in meiner Karriere meistens in einer Confluence-Seite ab, die ohnehin niemand liest. Mit BMAD passiert sie im Gespräch - und produziert Artefakte, die ich tatsächlich in den nächsten Schritt übernehmen kann.

Ein Punkt, den ich früh erwähnen möchte: Für die Discovery-Hälfte - Analyst, PM, UX - braucht man keinerlei Entwicklungserfahrung. Man führt ein strukturiertes Gespräch und liest, was zurückkommt, man schreibt keinen Code. Ein Product Owner, eine Gründerin, die eine Geschäftsidee schärfen will, bevor daraus überhaupt ein Projekt wird, oder einfach jemand, der einen ernsthaften Sparringspartner fürs Brainstorming sucht, könnte die Durchgänge von Mary, John und Sally genauso gut selbst durchlaufen. Erst bei Architektur und Umsetzung wird technisches Wissen notwendig - die Discovery-Phase selbst ist dafür nicht vorausgesetzt.

Die Prompts, die ich nicht im Kopf hatte

Ich habe bmad-agent-analyst geöffnet und ungefähr getippt: "Ich möchte eine Landingpage für mein Kochbuch." Mary, die Business-Analystin, hat keine gebaut. Stattdessen wollte sie wissen, wer den QR-Code auf der Buchrückseite scannt. Und wer sonst noch. Und was passiert, wenn die Seite überzeugt, Amazon aber gerade ausverkauft ist. Und, etwas unbequem, was meine eigentliche Metrik ist: Seitenbesuche oder verkaufte Bücher.

An die Hälfte davon hatte ich nicht gedacht - nicht aus Nachlässigkeit, sondern weil man als die Person, die das Buch schreibt, die Kartons packt, die Anzeigen schaltet und nebenbei ans Mittagessen denken muss, strategische Fragen fast automatisch auf "später" verschiebt.

Das Nützlichste, was eine Stimme von außen tut - egal ob menschlich oder Modell -, ist, genau die Fragen zu stellen, die man sich selbst nie stellt.

Am Ende des Analyst-Durchgangs stand ein schriftliches Brief, das unmissverständlich sagte:

"Die Website hat genau einen Job: warmen QR-Code-Traffic und Titel-Suchtraffic in Amazon-Klicks zu verwandeln. Sie ist kein Shop. Sie ist kein Blog. Sie ist keine Discovery-Engine. Discovery ist Amazons Job."

Ich habe schon viele Bücher über Fokus gelesen. Diesen einen Satz zu formulieren hat mich mehr gelehrt als alle zusammen - weil ich ihn zwanzig Minuten lang gegen Marys "Warum" verteidigen musste.

Personas, die keine Marketing-Personas sind

Jeder Artikel zum Thema "Personas schreiben", den ich je gelesen habe, rät dazu, Demografie und Pain Points der Zielgruppe zu beschreiben. Für eine Landingpage fand ich das immer etwas übertrieben.

Der UX-Durchgang sieht das anders. Sally wollte, dass ich eine ganz bestimmte Person beschreibe, in einem ganz bestimmten Moment, bei einer ganz bestimmten Handlung auf meiner Seite. Nicht "Mütter zwischen 25 und 45, die gesunde Desserts wollen" - sondern einen Namen, eine Szene, eine Uhrzeit.

Am Ende hatte ich Anna: 34, zwei Kinder, Kollegin einer meiner ersten Käuferinnen. Sie steht um 15:20 Uhr in der Büroküche, das Buch in der linken Hand, Kaffee in der rechten, drei Minuten bis zum nächsten Meeting. Sie hat den QR-Code gescannt, weil sie zwanzig Minuten vorher durch die Rezepte geblättert hat, und jetzt will sie wissen, wer dahintersteckt, bevor sie sich ihr eigenes Exemplar bestellt.

Ab dem Moment, in dem Anna existierte, hatte jede Design-Entscheidung eine echte Instanz, die darüber urteilen konnte.

• Sollte der Amazon-CTA sticky sein? Würde Anna ihn in Sekunde 42 finden, ohne zurückzuscrollen?
• Sollte der About-Bereich vor oder nach dem Buch-Vorschau-Teaser stehen? Was beantwortet Annas Frage schneller?
• Braucht es ein Burger-Menü? Anna hat drei Minuten. Ein Menü ist eine Sache mehr zum Wegklicken. Die Empfehlung im Brief lautete ohnehin schon "kein Burger-Menü". Aber erst Anna hat es wirklich offensichtlich gemacht.

Anna blieb die einzige Persona, für die das Design gebaut wurde. Was danach kam, war ein Stresstest, keine zweite Persona: Elena, sonntagabends auf dem Sofa, hat zwanzig Minuten Zeit; Peter, der bei Google nach einem Geschenk für seine Frau sucht, hat fünfundzwanzig Sekunden. Für keinen von beiden gab es eigene Design-Entscheidungen - Annas Zeitfenster war einfach das engste, und was für sie funktionierte, funktionierte automatisch auch für die beiden anderen.

SEO- und Marketing-Entscheidungen, die ich sonst übersprungen hätte

Als John, der Product Manager, mich durchs Brief geführt hat, sind wir bei Dingen gelandet, die ich normalerweise unter "klären wir später" abgelegt hätte:

• Was genau in den <title>-Tag gehört und was ins <h1>.
• Ob die Seite JSON-LD-Book-Schema ausliefert, damit Google ein Rich Result anzeigen kann.
• Ob ich Meta Pixel einbaue (nein - dafür bräuchte es einen Cookie-Banner, der die Seite verlangsamt und den QR-Scan-Moment stört).
• Ob ich Plausible oder Umami für Analytics nutze (beides funktioniert, beides ohne Cookies).
• Ob amazon_click die einzige Conversion-Metrik ist, oder ob ich zusätzlich die Scroll-Tiefe messe (eine einzige Metrik - alles andere ist nur Rauschen).

Nichts davon sind technische Entscheidungen. Es sind strategische Entscheidungen, die den Code später prägen - und genau die Entscheidungen, die implizit getroffen werden, wenn man Discovery überspringt. Man landet bei Google Analytics, weil es der Standard ist, braucht dann einen Cookie-Banner, weil Google Analytics einen verlangt, verliert dadurch an Core Web Vitals - und Anna springt ab, bevor der Hero-Bereich überhaupt fertig geladen ist.

User Journeys als Design-Lineal

Annas Journey ist kein nettes Extra. Sie ist der Maßstab, an dem jede weitere Seiten-Entscheidung gemessen wird.

Der UX-Durchgang hat sie als Tabelle mit einer Sekunden-Spalte festgehalten. Sekunde 0-2: Seite lädt. Sekunde 2-5: Cover-Wiedererkennung. Sekunde 25-45: der Vertrauensmoment - Anna sieht mein Küchenfoto, liest die Entstehungsgeschichte, entscheidet, dass ich echt bin. Sekunde 55-60: Amazon-Klick.

Jeder Bereich der Startseite ist auf eine Sekunde in dieser Tabelle gemappt. Was sich seinen Platz nicht verdienen konnte, ist rausgeflogen. Der About-Bereich ist keine drei Absätze Biografie, sondern ein Foto, drei Sätze, ein Link - weil Anna keine Zeit für mehr hat und Elena ohnehin ihre eigene Detailseite besucht.

Genau hier habe ich die größte Verschiebung gespürt. In einem normalen Projekt hätte ich die Startseite geschrieben nach dem Motto "hier ist alles, was ich sagen will". Mit Anna im Kopf habe ich stattdessen geschrieben: "Was muss wahr sein, damit sie klickt?"

Kompromisslos. Und irgendwie befreiend.

Farben, Schriften und Layout festlegen, ohne zu raten

Bei Farben und Typografie fallen bei KI-gestütztem Design meistens die ersten Räder ab. Man bittet um "warm und minimalistisch" - und bekommt jedes warm-minimalistische Tailwind-Theme, das je generiert wurde. Sprich: ein beiges Rechteck.

Hier hat mich das Standardverhalten des UX-Durchgangs überrascht. Bevor überhaupt eine Entscheidung fiel, wurde eine eigenständige HTML-Datei mit vier Theme-Varianten nebeneinander gerendert - mit echten Farbmustern, Token-Namen, berechneten WCAG-Kontrastwerten und einem kleinen Mockup, das statt Lorem Ipsum oder Stockfotos meine tatsächlichen Inhalte verwendete: meinen echten Buchtitel, meinen Entstehungsgeschichte-Satz, den CTA-Text, den ich gewählt hatte. Auch die Paletten selbst waren nicht frei erfunden: Alle vier Varianten wurden aus Farben aufgebaut, die direkt vom tatsächlichen Cover stammten, das ich hochgeladen hatte - jede Option passte also von Anfang an zum Buch, statt nur irgendwie dazu zu passen.

Ich habe die Variante angeklickt, die ich wollte. Kein Hin und Her über Hex-Werte, kein Versuch, "ein Rosé, das nicht zu pink, aber auch nicht zu rot ist" in Worte zu fassen. Ich habe die Paletten gesehen, mich entschieden, weitergemacht.

Genauso bei der Typografie: Ich habe die Schriften selbst benannt, statt sie raten zu lassen - Courgette für Wortmarke und Hero, Libre Baskerville für den Rest. Das war keine willkürliche Wahl: Beide Schriften stecken bereits im Buchcover und im Innenteil, sodass die Website wie dasselbe Objekt wirkt wie das Buch - und nicht wie etwas Fremdes, das nur seinen Namen trägt.

Das Mockup folgte derselben Logik. Sobald Palette und Schriften standen, wurde es als eine einzige HTML-Datei mit iPhone-Frame links und MacBook-Frame rechts gerendert, beide unabhängig scrollbar, beide mit derselben Seite - gebaut aus echten Assets: dem Cover aus meiner Druck-PDF, meinem Küchenfoto, drei Ausschnitten einer echten Rezeptdoppelseite.

Zwei Dinge sind mir besonders hängengeblieben. Erstens: Mobile und Desktop gleichzeitig zu sehen - nicht "hier ist Desktop, stell dir Mobile dazu vor", sondern echtes Mobile direkt daneben - wirkt im Nachhinein selbstverständlich, aber ich hatte noch nie ein Design-Tool erlebt, das das von sich aus anbietet. Zweitens: Jede Layout-Entscheidung an echten Inhalten zu prüfen, bis hin zu dem Ausschnitt, in dem mein Gesicht im runden Foto landet, deckt Probleme auf, die Lorem Ipsum einfach verschleiert.

Wie eine Markenrechtsverletzung und ein H1-Konflikt aufgeflogen sind

Am Ende der UX-Phase habe ich das eingebaute Reviewer Gate laufen lassen - mehrere Agenten, die den fertigen Design Spine jeweils mit einer anderen Fragestellung noch einmal durchgehen.

Der Rubric Walker (ein Agent, der die im Brief festgelegten Regeln gegen das tatsächliche Design prüft) hat einen echten Widerspruch gefunden: Die SEO-Regel verlangte, dass der Buchtitel im <h1> steht - aber das H1, das ich gewählt hatte, war der Verkaufsslogan. Am Ende sind wir bei einem zweizeiligen H1 gelandet: Buchtitel in Courgette-Schrift, Slogan darunter in kursiver Serif, aber ein einziges <h1>-Element im DOM.

Derselbe Durchgang lag aber auch einmal daneben. Im Brief steht eine Regel, dass die Seite nicht wie ein Shop funktionieren soll - kein Warenkorb, keine Produktliste, kein Checkout. Der Rubric Walker hat diese Regel fälschlicherweise auf einen einzelnen Button angewendet: Er hat den CTA-Text "View on Amazon" als Verstoß markiert, weil er die Worte selbst als shophaft interpretiert hat. Dabei ging es in der Regel um die Funktion der Seite, nicht um die Formulierung eines Links zu einem Händler. Ich musste den Unterschied erklären und die Markierung aufheben - rund zehn Minuten, die ich nicht eingeplant hatte. Gut zu wissen, bevor man anfängt: Nicht jede Markierung stimmt, und die Entscheidung muss man am Ende selbst treffen.

Der Legal Reviewer - weil diese Seite in einem regulierten Lebensmittelbereich liegt - hat jeden nutzersichtbaren deutschen Text gegen die Rot-Gelb-Grün-Wortliste aus dem Brief geprüft. Keine Verstöße gegen die Health-Claims-Verordnung, aber einen Punkt, den ich übersehen hatte: Ein Rezeptname im Mockup referenzierte eine eingetragene Marke und wurde deshalb vor dem Launch umbenannt. Eine Regel, die sich auf jedes zukünftige Rezept mit Markennamen übertragen lässt.

Keiner der echten Treffer wäre bei einem "sieht das gut aus?"-Review aufgefallen. Dafür brauchte es unabhängige Blickwinkel, die gezielt nach bestimmten Fehlerklassen suchen - aber es brauchte auch mich, der jede Markierung liest und entscheidet, welche davon stimmt. Jeder Agenten-Durchgang liefert immer noch Text, den man wirklich lesen muss, Zeile für Zeile, nicht überfliegen. Die Reviewer finden echte Fehler, aber eben nur die Fehlerklassen, für die sie gebaut sind, und gelegentlich markieren sie auch etwas, das gar nicht falsch ist. Man steuert immer noch selbst. Worin BMAD wirklich verlässlich gut ist: Constraints zu benennen, die man vergessen hatte, und Fragen zu stellen, die so präzise sind, dass eine schlechte Antwort sofort als schlechte Antwort auffällt. Das ist ein echter Mehrwert. Es ist nur nicht dasselbe wie "es hat für mich gedacht".

Fazit: Discovery hat länger gedauert als die eigentliche Seite

Hier das ehrliche Verhältnis: Discovery - Brief, Personas, UX-Design, Mockups, parallele Reviews, Überarbeitungen - hat rund sechs Sessions gebraucht. Die eigentliche Seite, sobald ich sie an Winston und danach an Amelia übergebe, ist auf zwei Sessions geschätzt.

Das klingt verkehrt herum. Die Wette dahinter: Ist es nicht - wenn DESIGN.md und EXPERIENCE.md fertig sind, muss ein Entwickler oder eine Entwicklerin nicht mehr fragen, welche Farbe der CTA-Button hat, nicht raten, ob das Hero-Bild eager oder lazy geladen wird, und sich keine Alt-Text-Policy spontan ausdenken. Im Idealfall ist alles entschieden, begründbar, und - weil bereits ein Reviewer drübergegangen ist - in sich konsistent.

Discovery ist kein Overhead. Sie ist die tragende Struktur für alles, was danach kommt - oder zumindest ist das die These, die dieses Projekt gerade testet. Erfunden hat BMAD diese Idee nicht: Gute Produkt- und UX-Praxis kennt sie seit Jahrzehnten, wenn sie richtig gemacht wird. Was BMAD stattdessen geschafft hat: sie auf ein Projekt in einer Größenordnung durchzusetzen, bei der ich sie sonst übersprungen hätte - schließlich ist es "doch nur eine Landingpage, wie schwer kann das schon sein".

Der eigentliche Test ist nicht, ob sich die Discovery-Phase gründlich angefühlt hat - sondern ob der Aufbau tatsächlich in zwei Sessions passt, wie ich erwarte, oder sich zu fünf auswächst, sobald die echten Constraints im Code auftauchen. Die Zahl liefere ich nach, so oder so.