Du hast dich verwirrt über etwas gemeldet, das sich wie ein Fehler anfühlte: Du hast eine Restaurant-Website für den neuen Laden generiert, sie gefiel dir nicht, du hast sie neu generiert und etwas erhalten, das verdächtig nach derselben Website mit ausgetauschtem Schild aussah. Terrakottawände, cremefarbene Karten, ein serifenbetontes Logo, das zu jedem Bistro von Portland bis Prag passen könnte. Du hast zu Recht gefragt, ob das Tool im Hintergrund einfach nur eine Vorlage wiederverwertet.
Tut es nicht, und ich möchte die Frage tatsächlich beantworten, statt dich nur zu beruhigen.
Was dir passiert ist, ist real, und es ist nicht spezifisch für deinen Build — es ist ein bekanntes Fehlerbild bei allem, was aus einer großen Trainingsverteilung generiert, ohne dazu angewiesen zu werden, es anders zu machen. Bittet man ein Modell ohne weitere Vorgaben, eine Restaurant-Website zu gestalten, greift es zur statistischen Mitte aller Restaurant-Websites, die es je gesehen hat, und diese Mitte ist Terrakotta und Creme, weil das die Verteilung dominiert. Dieselbe Geschichte bei SaaS-Landingpages (zentrierter Gradient-Hero, drei abgerundete Feature-Icons) oder Krypto-Dashboards (der eine Indigo-zu-Violett-Verlauf, auf den sich jedes Modell zu einigen scheint). Es ist nicht so, dass das Modell nichts anderes kann — bittet man es, wie eine Ski-Resort-Broschüre der 1970er oder eine sowjetische U-Bahn-Karte zu gestalten, gelingt ihm das meist, oft sogar gut. Es ist vielmehr so, dass nichts es zu einer Entscheidung gezwungen hat, also fiel es auf den Durchschnitt zurück.
Was sich tatsächlich für dich geändert hat
Der Grund, warum dein zweiter Versuch anders hätte aussehen sollen — und wenn er es nicht tat, ist das genau der Teil, den wir direkt beheben sollten, statt dass du drum herumarbeitest — ist ein Durchgang, den wir Design Director nennen. Er läuft, bevor der Builder überhaupt Markup schreibt, und seine einzige Aufgabe ist es, Entscheidungen zu treffen, denen sich der Builder später nicht mehr entziehen kann: eine Palette mit Haltung, eine bestimmte Typografie, eine Stimmung, klar genug formuliert, um überprüfbar zu sein. Konkret bedeutet das:
- Fünf bis sieben benannte Farben mit zugewiesenen Rollen — nicht „primär/sekundär“, sondern „die Farbe, die für Fehlerzustände reserviert ist“, „die Farbe, die nur bei Hover erscheint“
- Zwei Schriftarten, jede mit einem Grund für ihre Verwendung
- Zwei bis drei Sätze Stimmungssprache, wie sie ein echter Art Director an ein Moodboard heften würde
Der Test, an dem wir ein Briefing messen, ist, ob man ihm zuwiderhandeln kann. „Warm und einladend“ kann man nicht verletzen — es gibt keine Möglichkeit, dagegen zu verstoßen, was bedeutet, es lässt sich auch nicht durchsetzen, und der Builder driftet trotz des Briefings direkt zurück zu Terrakotta und Creme. „Warme, handgezeichnete Herbstpalette, Tuschekonturen auf cremefarbenem Papier, nichts Glänzendes, keine Schlagschatten“ ist eine echte Festlegung, und eine glasige Verlaufskarte, die diesem Briefing widerspricht, ist erkennbar falsch — genau das macht sie nützlich.
Wenn dein Build generisch ausfiel, liegt die ehrliche Möglichkeit darin, dass dein Prompt-Briefing zu unbestimmt war, als dass der Director sich auf etwas Festes hätte festlegen können. Eine Referenz zu nennen — einen Ort, eine Epoche, ein Material, auch nur „kein Beige“ — gibt ihm etwas, wogegen es sich abgrenzen kann.
Warum ich dem vertraue, und nicht nur den Screenshots
Ich sage dir, was mich überzeugt hat, denn es war nicht das nebeneinander gestellte Betrachten von drei hübschen Beispielen — so redet man sich einen Erfolg ein, der gar nicht da ist. Wir haben mehrere hundert Builds pro Kategorie durchgeführt, vor und nach Einführung des Directors, und den paarweisen Farbabstand zwischen Builds derselben Kategorie mittels Delta-E im Lab-Farbraum gemessen statt in rohem RGB, weil RGB darauf besteht, dass zwei ähnlich gesättigte Blautöne weit auseinanderliegen, obwohl sie am Bildschirm identisch wirken. Restaurant-Websites waren vor dem Director die schlimmsten Übeltäter — die übergroße Mehrheit clusterte innerhalb eines engen Delta-E-Bands, alle strebten demselben Terrakotta zu.
Ich werde es dir auch nicht schönreden. Farbabstand misst „sieht unterschiedlich aus“, nicht „sieht gut aus“, und sagt bislang nichts über Layout- oder Typografievielfalt aus, die wir längst nicht so sorgfältig erfasst haben. Eine Palette kann maximal unterschiedlich zu ihren Nachbarn und trotzdem hässlich sein. Wir denken, unterschiedlich-und-gelegentlich-eigenwillig schlägt sicher-und-einheitlich für das, was du baust — aber das ist eine Wertung, kein Beweis.
Worauf du selbst achten solltest
Es gibt ein Fehlerbild, das in die andere Richtung läuft, und es lohnt sich, das anzusprechen, bevor du darauf stößt: Manchmal ist „clean und modern“ keine Unterspezifizierung, sondern die tatsächliche Anfrage. Wer ein Enterprise-SaaS-Dashboard baut, möchte oft absichtlich das unauffällige Muster, weil die Nutzer es erwarten und ein Abweichen davon Support-Tickets erzeugt, keine Begeisterung. Ein Director, der zu sehr auf Differenzierung aus ist, liefert gelegentlich etwas künstlerisch Anspruchsvolleres zurück, als du wolltest. Wir gewichten deine expliziten Vorgaben höher als den Differenzierungsinstinkt des Directors, sodass „langweilig und Enterprise“ geschmackvoll langweilig ergeben sollte statt eine Rebellion gegen dein eigenes Briefing — aber wenn du bereits Markenfarben, ein Logo, Referenzfotos des Standorts hast, füge sie dem Prompt hinzu oder hänge sie direkt an. Fest vorgegebene Inputs schlagen immer eine vom Director selbst erfundene Richtung, und er behandelt sie als Vorgaben, nicht als Vorschläge.
Das gilt übrigens noch mehr, wenn du statt einer Website eines unserer Spiele baust — ein Spiel bietet weit mehr unregulierte Fläche für einen Director als eine Landingpage, da das Briefing dort Sprite-Stil, Animationsgefühl, UI-Chrome und Audio-Palette in einem Durchgang zusammenschließen muss (mehr zur Audioseite im Speziellen in Sound that isn't beeps), weil Inkonsistenz innerhalb eines Builds als unfertig wirkt — auf eine Weise, wie es Inkonsistenz zwischen zwei unabhängigen Builds nie tut.
