Lassen Sie mich Sie durch ein tatsächliches Konto führen, von Anfang bis Ende, statt die Seitenleiste Punkt für Punkt zu beschreiben. Nehmen wir an, es ist eine freiberufliche Person, erste Woche auf der Plattform, die eine Habit-Tracking-App für einen kleinen Kunden baut. So durchläuft dieser Build das Dashboard, in der Reihenfolge, in der es tatsächlich passiert – und wo jede Station entweder geholfen oder fünf Minuten verschwendet hat.
Der Prompt
Sie öffnen den AI Builder und tippen etwas in der Art von „Baue mir einen Habit-Tracker.“ Das ist ein vernünftiger erster Satz und ein schlechter finaler Prompt. Was zurückkommt, ist kein Code – es ist ein Plan, in Klartext geschrieben, und hört man beim „sieht gut aus“ auf zu lesen und klickt auf Genehmigen, bekommt man etwas, das technisch auf das Wort „Habit-Tracker“ reagiert und in jeder Hinsicht, die zählt, generisch ist. Der Kunde der freiberuflichen Person wollte keine Social-Features, nur lokalen Speicher, Dunkelmodus standardmäßig. Nichts davon stand im ersten Prompt. Es fließt stattdessen als drei Änderungen vor der Genehmigung in den Plan ein: das „Teile deine Serie“-Feature streichen, das sich der Plan selbst ausgedacht hat, die Speicherzeile austauschen, das Standardthema umschalten. Dreißig Sekunden Bearbeitung. Der Build, der am Ende herauskommt, entspricht dem Briefing statt nur dem Wort „Habit-Tracker“.
Der Planungsschritt, den man überspringt
Ich habe genau diesen Moment bei anderen Nutzern schiefgehen sehen – den ersten Plan ohne Lesen genehmigen, drei Iterationen später stecken und anfangen, Einschränkungen erneut zu erklären, die schon in der Planungsphase hätten festgelegt werden sollen. Der Planungsschritt existiert genau dafür, dass einem das nicht passiert. Er kostet fast nichts und ist der einzige Punkt im Ablauf, an dem man mit dem Agenten in der eigenen Sprache verhandelt, statt dessen Output im Code zu debuggen.
Wo der Build tatsächlich landet
Sobald er generiert ist, erscheint der Habit-Tracker als Karte in Meine Builds – der Bibliotheksseite, filterbar nach Typ, und der Seite, die diese freiberufliche Person bis Woche drei öfter öffnen wird als jede andere, sobald fünf oder sechs Builds sich angesammelt haben. Er erscheint nicht in Showcase; diese Seite ist kuratiert, nicht automatisch, und ein Kundenbuild, das dort unbeworben liegt, ist der richtige Standard. Er erscheint auch nicht in Vorlagen, es sei denn, die freiberufliche Person denkt daran, ihn als Vorlage zu speichern – hier tatsächlich sinnvoll, da ein Habit-Tracker-Skelett genau die Art von Sache ist, die eine freiberufliche Person für den nächsten Kunden mit anderem Branding wiederaufbaut. Die meisten entdecken „Als Vorlage speichern“ erst bei Build Nummer sechs und wünschten, sie hätten es bei Build Nummer eins getan.
Veröffentlicht, oder etwas Umfangreicheres
Jetzt die Verteilungsfrage. Drei echte Optionen, nicht eine Option mit drei Namen. Veröffentlicht liefert eine kostenlose Subdomain, live in Sekunden, ohne Einrichtungsaufwand – die richtige Wahl, solange der Kunde den Build noch prüft und eventuell ein Redesign wünscht. Domainverwaltung ist gedacht für den Moment, in dem die eigene Domain des Kunden bereit ist, darauf zu zeigen, und dieser Schritt erfüllt eine Doppelfunktion: Eine Domain hier zu verbinden ist nicht nur eine URL-Änderung, sondern auch das, was den Analyseseiten weiter unten in der Seitenleiste überhaupt erst etwas gibt, woran sie andocken können. Bereitstellen, unter den Einstellungen, ist der SFTP-Weg für den Fall, dass der Kunde darauf besteht, dass der Build auf einer Infrastruktur läuft, die er selbst kontrolliert – mehr Einrichtungsaufwand, und die freiberufliche Person trägt keinerlei Verantwortung für die Verfügbarkeit mehr, ein echter Kompromiss, den man besser explizit eingeht, als ihn zufällig zu entdecken.
Für diesen Build zuerst Veröffentlicht. Später von Subdomain zu eigener Domain zu wechseln, ist ein Nicht-Ereignis. Eine Bereitstellung mit eigener Domain bei einem stornierten Kundenprojekt rückgängig zu machen, verursacht mehr Aufräumarbeit, als es wert ist – und der freiberuflichen Person ist genau das bei einem früheren Projekt tatsächlich passiert, was der ganze Grund für die Gewohnheit „standardmäßig Veröffentlicht“ ist.
Der Abstecher in den App-Store
Dieser Kunde wollte außerdem einen App-Store-Eintrag, also durchläuft der Build stattdessen Shipped, statt bei Veröffentlicht stehen zu bleiben – eine Seite, die es gibt, weil Store-Reviews auf eine Art asynchron ablaufen, wie es bei Web-Deployments einfach nicht der Fall ist. Bei einem Store eingereicht, liegt es zwei Tage; bei einem anderen eingereicht, ist es in zwanzig Minuten durch. Shipped ist der Ort, an dem man das verfolgt, ohne fünf Browser-Tabs mit fünf verschiedenen Store-Konsolen offen zu haben, jede mit eigenem Login und eigenem Status-Vokabular.
Die leere Seite, vor der niemand gewarnt hat
Eine Woche nachdem die Domain verbunden ist, öffnet die freiberufliche Person Search Performance, um nachzusehen. Leer. Sogar etwas traurig anzusehen – kein Diagramm, keine Zahl, nur die Aufforderung, ein Konto zu verbinden. Das ist kein Fehler, sondern ehrlich: Es gibt noch keine Daten, weil Search Performance, Google Analytics und Store Analytics alle von derselben Google-Kontoverbindung unter den Einstellungen abhängen, und keine davon rechnet rückwirkend nach. Die Synchronisierung läuft ab dem Moment der Verbindung, nur vorwärts. Verbindet man die Domain am Tag eins, hat man bis Woche zwei eine Woche Historie; verbindet man sie an Tag zehn, weil man es vergessen hat, fängt man an Tag zehn bei null an. Die freiberufliche Person hatte die Domain verbunden, aber nicht das Google-Konto – zwei getrennte Schritte, die aussehen, als sollten sie einer sein.
Das eigentlich Kostspielige hier ist nicht das fehlende Diagramm. Es ist, dass die Optimierungsagenten dieselben Daten auslesen, und ein Agent, der gebeten wird, das Ranking einer Seite ohne jegliche Search-Performance-Historie zu verbessern, arbeitet mit allgemeinen Best Practices statt mit den tatsächlichen Zahlen dieser Seite. Die Verbindung auszulassen, lässt nicht nur eine Dashboard-Seite leer – es begrenzt, was die Agenten leisten können.
Das Briefing, das ungefragt auftaucht
Zwei Wochen später erscheint eine Karte in Discovery: ein Chancen-Briefing, das eine Inhaltslücke auf der Kundenseite anzeigt, mit einer „Jetzt bauen“-Schaltfläche. Wirklich nützlich, wenn es auf etwas trifft, das man ohnehin angehen würde. Aber Discovery neigt konstruktionsbedingt eher zu Menge statt Präzision – mehr Briefings, als jemand tatsächlich umsetzt – also ist die richtige Haltung ein Vorschlags-Posteingang, keine abzuarbeitende Warteschlange. Die freiberufliche Person überfliegt es alle paar Tage und ignoriert das meiste, was der beabsichtigte Gebrauch ist, kein Rückstand.
Die Einstellungen, die eigentlich am ersten Tag hätten erledigt werden sollen
Bis zu diesem Punkt hat die freiberufliche Person vier Einstellungsseiten berührt, ohne je absichtlich das Einstellungsmenü geöffnet zu haben – jede davon entdeckt, weil irgendetwas anderes leer war.
| Seite | Was sich herausstellte, dass es steuerte |
|---|---|
| Google-Konten | Search Performance, Google Analytics und die Grundlagendaten der Agenten – eine Verbindung, drei Oberflächen |
| Deployen | SFTP-Ziele, nur nötig für den Weg mit kundenseitig kontrolliertem Server |
| AI-Medien | Standardeinstellungen für Bildgenerierung innerhalb von Builds |
| Tarife & Credits | Nutzungskontingent, Guthabenpakete, Belege |
Google-Konten ist der Punkt, den man vorab erledigen sollte. Es ist ein einzelner Verbindungspunkt hinter drei getrennten Dashboard-Oberflächen, und das auf die harte Tour herauszufinden – drei verschiedene leere Seiten, drei verschiedene Momente des „oh, das muss ich noch verbinden“ – ist genau die Reibung, die ein fünfminütiger Einrichtungsdurchgang am ersten Tag vermeidet.
Die zwei Dinge, die die ganze Zeit schon da waren
Die schwebende Ask-AI-Schaltfläche war die ganze Zeit auf jeder dieser Seiten vorhanden, und sie ist kein eingeschränkter FAQ-Bot – sie kann in Ihrem Namen ein Konto verbinden, einen Build starten oder erklären, warum eine Seite leer ist. Der Kunde der freiberuflichen Person, nicht englischsprachig, brauchte für einen Review-Call die gesamte Oberfläche in einer anderen Sprache; der Globus in der Navigation wechselt zwischen allen zwanzig Sprachen, mitten in der Sitzung, ohne den laufenden Build zu verlieren. Keines von beidem musste durch Ausprobieren entdeckt werden, wie alles andere in dieser Tour. Es war einfach da.
Das ist die ehrliche Zusammenfassung der ersten zwei Wochen dieses gesamten Kontos – nicht „erst die Dokumentation lesen, dann bauen“, sondern umgekehrt. Meine Builds war eine Abstraktion, bis dort eine Karte lag. Search Performance war ein Leerzustand, bis eine Domain Daten lieferte. Den Grundriss vor dem ersten Build zu lesen, ist als Hintergrundwissen in Ordnung, aber der Grundriss ergibt erst Sinn, sobald irgendwo darin ein echter Habit-Tracker steht.
