Einseitige Produktspezifikation für KI-erstellte Apps: Bildschirme, Felder, Regeln

Warum KI-Builds ohne klares Spec aus dem Ruder laufen

Wenn du einem KI-Builder eine vage Vorgabe gibst, muss er raten. Er füllt fehlende Details mit Mustern, die er vorher gesehen hat — nicht mit dem, was du gemeint hast. Deshalb können KI-erstellte Apps sich zufällig anfühlen, auch wenn die erste Demo gut aussieht.

Dieses „zufällige“ Gefühl zeigt sich meist in kleinen, ärgerlichen Details: Ein Bildschirm fehlt ein Feld, das du für selbstverständlich hieltest; ein Formular akzeptiert Werte, die gesperrt sein sollten; oder ein Button führt an die falsche Stelle, weil das Tool einen anderen Ablauf annahm.

Inkonsequenz ist ein weiteres übliches Symptom. Ein Bildschirm nennt es „Company“, ein anderer „Organization“. Admins können etwas an einer Stelle bearbeiten, aber nicht an einer anderen. Die Datenbank hat am Ende zusätzliche Spalten, fehlende Spalten oder falsche Typen, weil UI und Datenmodell getrennt erfunden wurden.

Eine Einseiten-Spezifikation reduziert dieses Raten. Sie gibt dem Tool eine enge Menge an Entscheidungen, die es nicht treffen muss, sodass du weniger Nachbauten und weniger Hin-und-Her bekommst. Wenn etwas falsch ist, kannst du auf einen einzigen Satz zeigen und ihn korrigieren, statt darüber zu diskutieren, was die Vorgabe „wirklich gemeint“ hat.

Ohne klares Spec siehst du häufig:

• Zusätzliche Bildschirme, die du nicht wolltest, während zentrale fehlen
• Pflichtfelder, die optional werden (oder umgekehrt)
• Inkonsistente Berechtigungen (wer kann ansehen, erstellen, bearbeiten, löschen)
• Fehlende Validierungsregeln, sodass schlechte Daten durchrutschen
• Mehrere Versionen desselben Ablaufs (zwei Wege, eine Aufgabe zu erledigen)

Dieser Ansatz passt zu Gründer:innen, PMs, Designer:innen und Agenturen, die Tools wie Lovable, Bolt, v0, Cursor oder Replit nutzen und Builds wollen, die sich vorhersehbar verhalten. Er hilft auch, wenn du KI-generierten Code geerbt hast und die nächste Iteration weniger chaotisch und einfacher zu reparieren sein soll.

Was „Einseiten-Spec“ in der Praxis bedeutet

Eine Einseiten-Produktspezifikation ist eine kurze, strukturierte Notiz, die das Raten entfernt, bevor du ein KI-Tool bittest zu bauen. Sie versucht nicht, deine ganze Vision zu erfassen. Sie hält die Entscheidungen fest, die Builder dazu neigen, „einzufüllen“ — dort entstehen zufällige Features und gebrochene Logik.

Denk daran wie an einen Vertrag: Das sind die Bildschirme, das sind die Felder, und das sind die Regeln. Wenn ein Detail das Verhalten der App ändert, gehört es auf die Seite. Wenn es nur um Text oder Styling geht, normalerweise nicht.

Praktisch enthält eine Einseiten-Spezifikation:

• Eine Bildschirmliste mit einem Satz pro Bildschirm (was der Nutzer dort tun kann)
• Die Datenfelder, die existieren müssen (Name, Typ, erforderlich/optional)
• Die Regeln, die das Verhalten steuern (Validierung, Berechtigungen, Statuswechsel)
• Ein paar Einschränkungen, die schlechte Defaults verhindern (Auth-Methode, Rollen, grundlegende Sicherheitslimits)

Sie enthält kein vollständiges UI-Design, lange User Stories oder Seiten voller Edge Cases. Mockups kannst du später hinzufügen, aber das Spec sollte für sich allein Sinn ergeben.

Um kurz, aber eindeutig zu bleiben, schreibe in „muss“- und „wenn/dann“-Aussagen. „Nur Admins dürfen ein Projekt löschen“ ist besser als „Admins verwalten Projekte“. „E-Mail ist erforderlich und muss eindeutig sein“ ist besser als „Benutzer melden sich per E-Mail an“.

Eine schnelle Realitätstestfrage: Wenn du diese Seite jemand anderem gibst, könnte diese Person das Verhalten bauen, das du erwartest, ohne 20 Fragen zu stellen? Wenn nein, braucht die Seite klarere Regeln oder fehlende Felder.

Schritt für Schritt: Aus einer Idee ein Einseiten-Spec machen

Ein gutes Einseiten-Spec ist kein Roman. Es ist eine Reihe klarer Anweisungen, die eine KI am Raten hindern. Wenn du es ausdrucken könntest und jemand anderes deine App in eigenen Worten erklären kann, erfüllt es seinen Zweck.

Beginne mit einem einfachen Satz, der die Aufgabe der App beschreibt. Vermeide Buzzwords. Beispiel: „Hilf einem kleinen Team, Kundenanfragen vom Posteingang bis zur Erledigung nachzuverfolgen.“

Nenne als Nächstes die Benutzertypen. Halte es eng (2 bis 4). Für jeden schreibe, was sie tun dürfen, mit einfachen Verben: view, create, edit, approve, delete. Das verhindert später Berechtigungschaos.

Eine verlässliche Reihenfolge, die das Spec fest im Boden verankert:

1. Schreibe den Ein-Satz-Job (wie sieht Erfolg aus).
2. Definiere Benutzertypen und Berechtigungen (wer darf was).
3. Schreibe den Happy-Path in 5–8 Schritten (die Reise, die immer funktionieren sollte).
4. Liste Bildschirme vor Features (welche Seiten existieren und was jeder Bildschirm tun muss).
5. Füge Datenfelder und Regeln zuletzt hinzu (wenn die Bildschirme stabil sind).

Für den Happy Path bleib konkret. Für eine Request-Tracker-App: Nutzer meldet sich an, erstellt eine Anfrage, weist einen Besitzer zu, der Besitzer ändert den Status, der Anfragende wird benachrichtigt, ein Manager sieht eine wöchentliche Zusammenfassung.

Nachdem die Bildschirmliste klar ist, füge die Datenfelder hinzu, die jeder Bildschirm braucht (title, description, status, owner, timestamps) und die Regeln (erforderliche Felder, erlaubte Statuswechsel, wer nach Genehmigung noch bearbeiten darf). Hier brechen KI-generierte Prototypen oft: Regeln wurden impliziert statt aufgeschrieben.

Bildschirme so definieren, dass ein KI-Tool sie ausführen kann

Wenn du einen vorhersehbaren Build willst, muss deine Bildschirmliste wie Anweisungen lesen, nicht wie ein Moodboard. Eine einfache Namensregel hilft: Verwende Verb + Nomen, sodass jeder Bildschirm impliziert, was dort passiert.

Beispiele: „View Orders“, „Create Invoice“, „Edit Profile“, „Reset Password“. Vermeide vage Namen wie „Dashboard“, es sei denn, du sagst, was darauf ist.

Behandle jeden Bildschirm wie eine kleine Karte mit denselben Feldern:

• Purpose: ein Satz, der beschreibt, was „Erfolg" auf diesem Bildschirm ist.
• Who can access: Rollen (Guest, Signed-in user, Admin) plus besondere Einschränkungen.
• Main actions: 2 bis 4 Aktionen, geschrieben wie Buttons.
• Data shown/edited: die wichtigen Objekte, die beteiligt sind.
• Outputs: was sich nach der Aktion ändert (Datensatz erstellt, E-Mail gesendet, Status aktualisiert).

Benenne Eintrittspunkte, damit Navigation nicht erfunden wird. Zum Beispiel: Onboarding beim ersten Start, Login vom „Sign in“-Button, ein Einladungslink zu „Accept Invite" oder ein Deep Link zu einem bestimmten Element.

Definiere auch die langweiligen Zustände, die leicht übersprungen werden, aber später teuer sind. Für jeden Bildschirm füge einzeilige Hinweise hinzu für:

• Empty state: was der Nutzer sieht, wenn noch keine Daten vorhanden sind.
• Error state: was der Nutzer sieht, wenn etwas fehlschlägt, plus wie er sich erholen kann.

Verhindere Scope Creep, indem du Bildschirme nennst, die nicht existieren dürfen. Beispiel: „Darf nicht existieren: Admin-Analytics, öffentliche Benutzerprofile, In-App-Chat.“ Ein simpler Satz, der zusätzliche Daten, Berechtigungen und Bugs vermeidet.

Benutzerflüsse vorhersehbar machen, nicht fantasievoll

KI-Tools sind gut darin, Lücken zu füllen — genau das ist das Problem. Wenn du die Hauptflüsse nicht buchstabierst, erfindet das Tool Schritte, Bildschirme und Navigation, die plausibel wirken, aber nicht dem entsprechen, was du gemeint hast.

Wähle 2–3 Kernflüsse und schreibe sie Ende-zu-Ende als einfache Schritte. Halte die erste Version linear und füge nur die Verzweigungen hinzu, die kaputte UX und gebrochene Logik verhindern.

Eine einfache Art, Flows zu schreiben

Schreibe jeden Flow als nummerierten Pfad mit klarem Start und Ende. Verwende die exakten Bildschirmnamen, die du anderswo gelistet hast, und nenne, was nach jeder Aktion passiert.

• Flow 1: Sign up -> Verify email -> Create profile -> Land on Dashboard
• Flow 2: Create item -> Save -> See item detail -> Return to list with a success message
• Flow 3: Checkout -> Pay -> Confirmation -> Land on Orders (not back to the cart)

Dann füge ein paar kritische Verzweigungen hinzu:

• Cancel: wenn der Nutzer mitten drin abbrechen will, wo landet er?
• Retry: was passiert nach fehlgeschlagener Zahlung oder fehlgeschlagenem Upload?
• Permission denied: was sieht der Nutzer und wohin kann er als Nächstes gehen?
• Delete: Bestätigungsschritt und wo landet der Nutzer nach dem Löschen?

Sei explizit in der Navigation. Wenn die App Tabs nutzt, nenne sie. Wenn sie eine Sidebar hat, liste die Sektionen. Wenn es ein linearer Flow ist, sag das. Notiere auch „return to“-Erwartungen wie „nach dem Bearbeiten zurück zur Detailansicht" oder „nach dem Speichern Einstellungen auf der gleichen Seite bleiben".

Datenfelder auflisten, damit DB und UI übereinstimmen

Wenn du Felder nicht aufschreibst, erfindet ein KI-Tool sie. So entsteht eine UI, die nach einer Sache fragt, und eine DB, die etwas anderes speichert.

Eine kleine Feldtabelle reicht oft aus, um den Build konsistent zu halten.

Nutze eine kompakte Feldtabelle

Wähle die Hauptobjekte (z. B. User, Project, Item) und liste die Felder für jedes. Halte es knapp: name, type, required und ein Beispiel.

Unter der Tabelle eine Zeile hinzufügen: welche Felder nutzereingaben sind vs. systemgeneriert. Beispiel: title und due_date sind vom Nutzer eingegeben; status defaultet auf draft; owner_user_id wird aus dem angemeldeten Benutzer gesetzt; created_at ist automatisch.

Beziehungen sind wichtig, weil sie Bildschirme und Berechtigungen antreiben. Schreibe sie klar: „A user owns many projects. A project has many items. An item belongs to one project."

Defaults und Timestamps verhindern „warum ist das leer?"-Bugs. Gib sie an: status = draft, role = member, updated_at ändert sich bei Bearbeitung, deleted_at wird für Soft Deletes verwendet (wenn gewünscht).

Sensibelere Felder brauchen explizite Behandlung:

• Passwörter: nur Hash speichern, niemals Klartext
• Tokens/Keys: verschlüsselt speichern, nie den vollen Wert in der UI anzeigen
• Secrets: nicht in der Client-App oder in Logs ablegen

Regeln schreiben, die gebrochene Logik stoppen

Eine Bildschirmliste und Feldliste sagen einer KI, was gebaut werden soll. Regeln sagen, wie sich die App verhalten soll, wenn echte Menschen sie nutzen. Ohne Regeln erhältst du „funktioniert größtenteils"-Code: Formulare akzeptieren falsche Daten, Nutzer sehen Dinge, die sie nicht sehen sollten, und Statusänderungen erfolgen in falscher Reihenfolge.

Schreibe Regeln in einfacher Sprache, aber mach sie testbar. Jemand sollte eine Regel lesen und mit „besteht/nicht besteht“ antworten können.

Die drei Regeltypen, die du einbauen solltest

• Validierung: erforderlich vs optional, Min/Max-Länge, erlaubte Formate, Bedingungen über mehrere Felder
• Berechtigungen: wer darf ansehen, erstellen, bearbeiten, löschen und was passiert, wenn er es trotzdem versucht
• Geschäftslogik: wie sich Datensätze über Zeit verändern (Statuses), Limits, Einzigartigkeit, Zusammenführungen

Beispiel: Ein „Request a quote“-Formular.

Validierungsregeln: E-Mail muss einem normalen Format entsprechen; Firmenname 2 bis 80 Zeichen; Budget ist nur erforderlich, wenn Project type = Full rebuild.

Berechtigungsregeln: Jeder kann eine Anfrage erstellen; nur Admins können den Status ändern; der Anfragende kann seine Anfrage nur über einen Magic Link sehen.

Geschäftsregeln: Status kann Draft -> Submitted -> Approved/Rejected, aber niemals rückwärts; eine aktive Anfrage pro E-Mail und Tag; doppelte Einsendungen führen zur Zusammenführung von Notizen statt einem zweiten Datensatz.

Entscheide, was passiert, wenn etwas schiefläuft

Halt nicht beim „zeige einen Fehler“ an. Lege Verhalten fest, damit UI und API übereinstimmen.

Halte es einfach:

• Die Meldung ist kurz und spezifisch (keine technischen Begriffe).
• Sie erscheint an einem konsistenten Ort (inline unter dem Feld oder als Top-Banner).
• Die Eingabe des Nutzers bleibt erhalten.
• Berechtigungsfehler werden standardmäßig verweigert.
• Fehler werden mit einem Grund geloggt, den Admins prüfen können.

Edge Cases, die es wert sind, genannt zu werden: abgelaufene Links, gelöschte Benutzer, auf die alte Datensätze verweisen, und Doppel-Klicks, die dieselbe Anfrage zweimal absenden.

Einige Nicht-Verhandelbare (Sicherheit, Auth, Skalierung)

Ein Einseiten-Spec ist nicht vollständig, bis du die Dinge nennst, die beim Build auf keinen Fall schiefgehen dürfen. Diese Schutzmaßnahmen verhindern kurzfristige Nachbauten.

Sicherheit und Authentifizierung (wähle, nicht impliziere)

Sei explizit, wie sich Leute anmelden. Wenn du nicht auswählst, wählt die KI.

Entscheide:

• Auth-Methode: E-Mail + Passwort, Magic Link, OAuth (Google etc.) oder kein Login
• Rollen: wer was sehen darf (z. B. Admin vs. regulärer Nutzer)
• Session-Regeln: Auto-Logout-Zeit, „remember me“ an/aus

Schreibe außerdem zwei Grundsätze in einfachen Worten: „Keine Geheimnisse im Code oder Client“ und „Alle Nutzereingaben müssen validiert und sicher sein." Das hilft, exponierte API-Keys, SQL-Injection und Formulare, die beliebigen Input akzeptieren, zu verhindern.

Skalierung, Logs und Deployment-Erwartungen

Du brauchst keine exakten Zahlen, nur grobe Ziele. Beispiel: „Launch mit etwa 200 Nutzern, kann bis 10.000 wachsen; typisches Konto hat 50 bis 5.000 Datensätze."

Füge hinzu, was geloggt werden muss für Audits und Debugging: Logins, fehlgeschlagene Logins, Berechtigungsänderungen und Löschungen.

Schließlich, wo soll es laufen: „Wir brauchen Staging und Produktion" reicht. Notiere, dass Secrets als Environment-Variablen gespeichert werden müssen (nicht hard-coded), und liste die wenigen, die du schon kennst (Datenbank-URL, E-Mail-Provider-Key).

Grenzen setzen, damit der Build fokussiert bleibt

KI-Tools sind schnell, aber sie „helfen" auch gern durch das Hinzufügen extra Features, die du nicht angefragt hast. Ein Einseiten-Spec braucht Leitplanken, damit v1 klein, testbar und versandbereit bleibt.

Beginne mit einer einfachen Trennung: Must-have vs Nice-to-have. Must-haves sind die kleinste Menge, die das Produkt Ende-zu-Ende nutzbar macht. Nice-to-haves sind echte Ideen, dürfen v1 aber nicht blockieren.

Definiere in einfachen Worten, was „done" für v1 bedeutet. Hier gibst du dir die Erlaubnis, häufige Scope-Explosionen zu ignorieren: individuelles Designpolish, erweiterte Filter, Rollen, die du noch nicht brauchst, Mehrsprachigkeit, tiefe Analytics.

Um das Build objektiv zu halten, füge pro Bildschirm ein paar Abnahmechecks hinzu:

• Bildschirm lädt ohne Fehler und zeigt den richtigen Empty State
• Nutzer kann die Hauptaktion in 3 Schritten oder weniger abschließen
• Validierungsfehler erscheinen neben dem Feld und blockieren das Speichern
• Erfolgsmeldung erscheint und Daten sind nach Refresh sichtbar
• Berechtigungsregeln werden durchgesetzt (gesperrte Nutzer können nicht sehen oder bearbeiten)

Entscheide außerdem, was in v1 gemockt werden kann vs. was echt sein muss. Mocks sind ok, wenn sie klar gekennzeichnet und sicher sind. Beispiel: Fake-Zahlung (keine echte Abbuchung), E-Mails ins Log statt Senden, Platzhalter-Upload-URLs, feste Beispielantworten für externe APIs.

Beispiel-Einseiten-Spec (einfaches, realistisches Szenario)

Hier ein Einseiten-Spec, das du einem KI-Builder für eine kleine Klinik-Termin-App geben könntest.

App: „BrightClinic Booking"

Nutzer: Patienten und Klinik-Admins.

Bildschirme: Landing (was die Klinik anbietet + „Book"), Sign up / Log in, Book appointment, My bookings, Admin schedule.

Auf Book appointment wählt der Nutzer ein Datum, sieht verfügbare Zeiten, wählt eine Zeit, fügt optional eine Notiz hinzu und bestätigt. Auf My bookings sieht der Nutzer kommende Termine und kann umbuchen oder stornieren.

Datenfelder (Appointment): Patient name (text), phone (text), appointment time (date/time), status (scheduled, cancelled), notes (optional text). Halte das Patientenprofil für v1 minimal: name und phone.

Regeln (die Logik, die nicht kaputtgehen darf)

• Keine Doppelbuchung: pro Zeitfenster nur ein Termin.
• Stornofrist: Patienten können bis 24 Stunden vor dem Termin stornieren.
• Admin-only Änderungen: nur Admins können Status ändern, Buchungen verschieben oder Notizen nach Bestätigung bearbeiten.
• Patienten sehen und verwalten nur ihre eigenen Buchungen.

Schnelle Abnahmechecks:

1. Ein Patient kann sich registrieren, einen Slot buchen und ihn in My bookings sehen.
2. Umbuchen gibt den alten Slot frei und reserviert den neuen.
3. Stornieren innerhalb von 24 Stunden ist gesperrt mit klarer Meldung.
4. Admin Schedule zeigt alle Termine inklusive Status.
5. Ein Patient kann nicht auf den Admin-Bildschirm zugreifen.

Häufige Fehler, die KI-generierten Code unordentlich machen

Die meisten chaotischen KI-Projekte starten mit einem Spec, das komplett klingt, aber die Details auslässt, die eine KI braucht, um konsistente Entscheidungen zu treffen. Das Ergebnis sind zufällige Bildschirme, nicht übereinstimmende Daten und Logik, die an einer Stelle funktioniert und an einer anderen bricht.

Die Muster, die am meisten Schaden anrichten:

• Nur Feature-Notizen ohne Bildschirme. „Users can manage invoices" reicht nicht. Ohne Bildschirme (List, Create, Detail, Edit) überspringt der Build oft Basics wie Empty States und Bestätigungsschritte.
• Fehlende Rollen und Berechtigungen. Wenn du nicht sagst, wer was darf, wird Standard oft „jeder kann alles".
• Keine Feldbeispiele. Sagst du nur „phone number" oder „status" ohne Beispielwerte, rät die KI Formate und Benennungen. Am Ende hast du phone, phoneNumber und mobile in verschiedenen Dateien plus konkurrierende Statuswerte.
• Keine Fehlerbehandlung. Viele Builds beschreiben nur den Happy Path. Ein fehlgeschlagener Login oder eine leere Liste führt dann zu leeren Bildschirmen oder endlosem Laden.
• v1 und „später" mischen. Wenn zukünftige Ideen im gleichen Spec vorkommen, versucht der Build, alles einzubauen. Du bekommst halb gebaute Einstellungen, ungenutzte Tabellen und verwirrende Navigation.

Ein weiterer Realitätstest: Wenn du dein Spec einem neuen Teammitglied gibst, könnte es genau sagen, was morgen gebaut werden soll und was später ignoriert werden kann? Wenn nicht, füllt die KI die Lücken aus.

Kurze Checkliste und nächste Schritte

Bevor du auf „build" drückst, mache einen Schnellcheck deines Einseiten-Specs. Wenn du die Punkte ohne Raten beantworten kannst, ist dein KI-Tool deutlich eher in der Lage, etwas Konsistentes zu produzieren.

Bestätige, dass du hast:

• Klare Bildschirmabgrenzungen (was auf jedem Bildschirm möglich ist, nicht nur Titel)
• Rollen und Berechtigungen, plus die Hauptflüsse Ende-zu-Ende geschrieben
• Datenfelder gelistet (Name, Typ, erforderlich/optional, Default, Beispielwert)
• Validierung, Berechtigungen und Fehlerverhalten (welche Fehlermeldung wo, was passiert danach)
• Grenzen für v1 (Must-have vs Nice-to-have)

Wenn sich etwas unklar anfühlt, korrigiere es jetzt. „Users can edit a profile" ist vage. „User kann Name und Telefon bearbeiten; E-Mail ist read-only; Telefon muss 10–15 Ziffern haben; Fehler unter dem Feld anzeigen; Speichern bleibt deaktiviert bis gültig" ist etwas, dem ein Tool folgen kann.

Nächste Schritte:

1. Füge das Spec in dein KI-Builder-Tool ein und fordere ein funktionierendes v1 an, nicht ein komplettes Produkt.
2. Teste den Happy Path und ein paar Fehlerfälle (falsches Passwort, fehlendes Pflichtfeld, keine Berechtigung, Empty State, Netzwerkfehler).
3. Wenn du seltsames Verhalten siehst, aktualisiere zuerst das Spec und baue oder regeneriere dann nur den betroffenen Teil neu.

Wenn du bereits einen KI-generierten Prototypen hast, der kaputt oder unsicher ist (Auth-Probleme, exponierte Geheimnisse, inkonsistente Logik), ist FixMyMess (fixmymess.ai) genau für diese Übergabe gemacht: Diagnose, Reparatur und Härtung des Codes und Vorbereitung für die Bereitstellung, wenn der Prototyp produktionsreif werden muss.