HiveGrid-Wireframes/01 Regeln/Wireframing Playbook.md

kind, project, area, status

kind	project	area	status
rule	HiveGrid Screen Project	Wireframing	active

Wireframing Playbook

Stand: 2026-06-24

Dieses Playbook definiert, wie Wireframe-Pakete fuer HiveGrid in Obsidian vorbereitet, validiert und als Markdown/Canvas abgelegt werden. Subframe wird nur nach expliziter Freigabe genutzt.

Ziel: Nicht jeden Spezialzustand einzeln bauen, sondern nur die Screens bauen, die Struktur, Aufgabe, Entscheidung oder Risiko sichtbar machen.

---

1. Grundprinzip

Ein Wireframe klaert:

• was der Nutzer auf diesem Screen tun soll
• welche Daten sichtbar sind
• welche Aktionen moeglich sind
• welche Entscheidungen oder Blocker existieren
• welche Komponenten/Archetypen wiederverwendet werden

Subframe wird erst nach expliziter Freigabe genutzt. Mikro-Zustaende werden dokumentiert, aber nicht jedes Mal als eigener Frame gebaut.

Wichtig: Der Assistant bereitet Flows, Screen-Dateien und Canvas in Obsidian vor. David validiert und kann die Screens selbst in Subframe bauen. Bestehende Subframe-Screens werden nicht automatisch bearbeitet, ueberschrieben oder geloescht, auch wenn sie gleich heissen.

---

2. Arbeitsablauf pro Wireframe-Paket

Kein Flow wird direkt gebaut. Vorher gibt es immer ein kurzes Brainstorming und eine Validierung.

Es wird immer nur ein kleines Paket nach dem anderen bearbeitet. Nicht mehrere Flows gleichzeitig finalisieren.

Grundregel:

Ein Flow -> Varianten brainstormen -> Entscheidung treffen -> Screen-Kandidaten sammeln -> jeden Screen validieren -> erst dann bauen/ablegen.

Screen-Listen entstehen aus dem Brainstorming. Sie werden nicht vorab automatisch festgelegt.

0. Intent Check: Was ist ueberhaupt gewollt?

   • Welches Ticket oder Modul ist betroffen?
   • Was soll der Nutzer am Ende schaffen?
   • Geht es um einen echten Flow, einen einzelnen Screen, einen Zustand oder nur Dokumentation?
   • Welche Planning-Quellen muessen gelesen werden?
   • Welche Annahmen sind noch unsicher?
   • Was ist ausdruecklich nicht Teil dieses Pakets?

1. Scope sammeln

   • Ticket/Modul
   • Ziel des Flows
   • Nutzerrolle
   • Rollenunterschiede: normale Rolle vs. Admin
   • Startpunkt
   • wichtige Daten
   • wichtige Aktionen
   • bekannte Constraints aus Planning/Specs

2. Mini-Brainstorming

   • Was ist der Happy Path?
   • Wo verzweigt der Flow?
   • Wo kann der Nutzer blockiert sein?
   • Welche Fehler, Warnungen, Success-Zustaende und Hinweise koennen auftreten?
   • Welche davon sind Inline, Banner, Toast, Modal oder eigener Screen?
   • Welche UX-Varianten sind denkbar?
   • Was spricht fuer oder gegen jede Variante?
   • Welche Variante empfiehlt der Assistant?
   • Welche Variante entscheidet David?
   • Erst danach: Welche Screens/Zustaende koennten daraus entstehen?

3. Entscheidungsschritt

   • David entscheidet die UX-Richtung.
   • Offene Fragen werden markiert.
   • Wenn keine Entscheidung moeglich ist, wird das Paket nicht gebaut.
   • Erst nach der Entscheidung entsteht eine Screen-Kandidatenliste.

4. Screen Validation Gate

   • Jeder Screen-Kandidat wird einzeln entschieden.
   • Kein Screen wird in Subframe gebaut, bevor er validiert ist.
   • Kein Screen wird in den Flow eingebaut, nur weil er "vielleicht gebraucht" wird.
   • Fehler-/Meldungszustaende werden einzeln entschieden: Inline, Banner, Toast, Modal, eigener Screen oder nur Dokumentation.
   • Ein Screen bekommt erst danach eine Umsetzung: Bauen, Wiederverwenden, Nur dokumentieren, Spaeter oder Raus.

5. Validierung vor dem Bau

   • Screen-Liste steht
   • Reuse-vs-Bauen ist entschieden
   • offene Fragen sind markiert
   • Hauptflow und Varianten sind verstanden
   • jeder Screen wurde einzeln geprueft

6. Screen-Dateien/Canvas vorbereiten

   • nur die validierten Screens
   • Canvas nur fuer den validierten Flow anlegen
   • vorhandene D0-Komponenten und Archetypen dokumentieren
   • keine unnoetigen Sonderkomponenten erfinden
   • kein Subframe-Bau ohne ausdrueckliche Freigabe von David

7. Markdown-Paket schreiben

   • Screen-Liste
   • Subframe-Links
   • Daten je Screen
   • Aktionen je Screen
   • Banner, Toasts und Inline-Meldungen
   • Zustaende
   • offene Fragen

8. Handoff-Check

   • jedes sichtbare Feld hat eine Datenquelle
   • jeder Button hat eine Aktion
   • die relevanten Zustaende sind beschrieben
   • der Screen ist als Bauen, Wiederverwenden, Nur dokumentieren, Spaeter oder Raus markiert

---

2a. Brainstorming-Regeln

Brainstorming ist Pflicht, bevor Screens festgelegt werden.

Der Assistant darf nicht direkt eine finale Screen-Liste erzeugen. Er arbeitet zuerst mit Optionen.

Ablauf

1. Flow-Frage formulieren

   • Worum geht es in diesem Flow?
   • Welches Nutzerproblem wird geloest?
   • Was ist der Startpunkt und was ist das Ziel?

2. Varianten anbieten

   • mindestens 2 sinnvolle Varianten, wenn es echte UX-Entscheidungen gibt
   • pro Variante kurz: Vorteil, Nachteil, Aufwand, Risiko
   • keine Scheingenauigkeit, wenn eine Variante offensichtlich falsch ist

3. Empfehlung geben

   • der Assistant darf eine Empfehlung geben
   • die Empfehlung ist nicht automatisch die Entscheidung

4. David entscheidet

   • Entscheidung markieren als genommen, spaeter, raus oder unklar
   • bei unklar wird nicht gebaut

5. Screen-Kandidaten ableiten

   • erst nach Davids Entscheidung
   • Kandidaten sind noch nicht final
   • Meldungs-/Error-State-Kandidaten werden separat gesammelt

6. Screen Validation Gate

   • jeder Kandidat wird einzeln geprueft
   • danach erst finale Liste
   • jeder relevante Fehler-/Meldungszustand bekommt eine UI-Form

Entscheidungsformat

Fuer Brainstorming wird dieses Format genutzt:

Option	Beschreibung	Vorteil	Nachteil	Empfehlung
A	-	-	-	-
B	-	-	-	-

Danach:

Entscheidung	Status	Notiz
-	genommen / spaeter / raus / unklar	-

Meldungs-/Error-State-Check im Brainstorming

Bei jedem Flow wird waehrend des Brainstormings abgefragt:

• Was kann erfolgreich passieren?
• Was kann fehlschlagen?
• Was kann den Nutzer blockieren?
• Was muss der Nutzer sofort korrigieren koennen?
• Was darf nicht verschwinden?
• Was ist copy-kritisch oder sicherheitskritisch?
• Welche Meldungen duerfen nicht dem Developer ueberlassen werden?

Diese Matrix wird fuer jedes Paket genutzt:

Ereignis	UI-Form	Blockiert?	Bauen?	Copy/Notiz
-	Inline / Banner / Toast / Modal / Screen	ja / nein	ja / nein	-

Regel: Ein Fehler wird nicht danach entschieden, ob er technisch ein Error ist, sondern danach, was der Nutzer als Naechstes tun muss.

---

2b. Rollen- und Permission-Regel

Bei jedem Flow wird kurz geprueft, ob sich die UX fuer Admin und normale Nutzer unterscheidet.

Standardannahme:

• Normale Rolle = hoechste Rolle unter Admin.
• Admin = eigene Variante nur dann, wenn Ziel, Rechte, Daten oder Weiterleitung sichtbar anders sind.

Regeln:

• Wenn Admin nur nach erfolgreichem Login woanders landet, wird das als Outcome dokumentiert, nicht automatisch als eigener Screen gebaut.
• Wenn Admin andere Daten, andere Aktionen oder andere Risiken sieht, wird eine eigene Variante geprueft.
• Tenant-/Workspace-/Profil-Auswahl fuer Admin wird als eigener Flow behandelt, wenn sie mehr ist als eine reine Weiterleitung.
• Permission-Denied, gesperrte Funktionen und sichtbare Rechte-Unterschiede werden im Screen-Paket dokumentiert.

Beispiel Login:

Rolle	Nach erfolgreichem Login
Normale Rolle	Home/Dashboard
Admin	Tenant-/Workspace-Auswahl oder Admin-Startpunkt

---

2c. Zentrale Auth-Core-Flows

Manche Auth-Flows sind zentrale Sicherheitsbausteine und werden von mehreren anderen Flows angesteuert.

Aktuelle Produktentscheidung:

Set Password wird als zentraler Flow behandelt.

Er kann aus mehreren Zubringer-Flows gestartet werden:

• Passwort Reset
• Einladung / initialer Mitarbeiterzugang
• Passwort aendern
• Admin-Reset
• Sicherheitsmassnahme nach Incident

Regeln:

• Der zentrale Flow wird als eigenes Paket gebrainstormt und validiert.
• Zubringer-Flows dokumentieren nur, wie der Nutzer in den zentralen Flow kommt.
• Sonderregeln des Zubringer-Flows werden nicht im zentralen Flow versteckt, sondern im jeweiligen Paket dokumentiert.
• Auth-Core-Flows brauchen eine dokumentierte Zurueck-/Abbrechen-Aktion, wenn ein Nutzer den Einstieg versehentlich geoeffnet haben kann, z. B. bei Passwort Reset.
• Die Zurueck-Aktion ist normalerweise kein eigener Screen, sondern eine sekundare Navigation im jeweiligen Auth-Screen.
• 2FA wird im Set-Password-Flow grundsaetzlich angeboten.
• Wenn 2FA fuer den konkreten Einstieg verpflichtend ist, wird das im Zubringerpaket oder als Regel im Set-Password-Paket markiert.
• Admin-Reset kann bestimmen, ob 2FA verpflichtend oder freiwillig ist.
• Neukunden-Signup ist eine bewusste Ausnahme: Das Passwort wird direkt im Signup-Flow gesetzt, damit der Einstieg moeglichst wenig Reibung hat.

Wichtig: Diese Entscheidung weicht bewusst von der einfachen D-P2-Planung ab und ist eine UX-/Produktentscheidung nach Abstimmung mit Development.

---

2e. Subframe-Schutzregel

Subframe ist kein automatischer naechster Schritt.

Regeln:

• Kein bestehender Subframe-Screen wird ohne ausdrueckliche Freigabe bearbeitet.
• Kein bestehender Subframe-Screen wird geloescht oder ueberschrieben.
• Gleichnamige vorhandene Subframe-Screens sind nur Kontext, keine Arbeitsanweisung.
• Neue Subframe-Screens werden nur angelegt, wenn David den konkreten Flow und den Subframe-Bau freigibt.
• Bis zur Freigabe arbeitet der Assistant ausschliesslich in Obsidian: Paket-MD, Screen-MD, Canvas und Tracker.
• Wenn Subframe spaeter genutzt wird, werden neue Screens eindeutig verlinkt und im Tracker dokumentiert.

---

2d. Screen Validation Gate

Bevor ein Screen in einen Flow eingebaut wird, muss er einzeln validiert werden.

Validierungsfragen

• Ist das ein eigener Arbeitsmoment fuer den Nutzer?
• Wird hier eine neue Struktur gebraucht?
• Gibt es eine neue Entscheidung oder einen Risiko-Moment?
• Reicht ein vorhandener Archetyp?
• Ist es nur ein Zustand, Banner, Toast oder Inline-Hinweis?
• Muss dieser Screen jetzt gebaut werden, oder reicht Spaeter?
• Welche Daten und Aktionen sind wirklich noetig?

Ergebnis

Jeder Screen-Kandidat bekommt eine klare Entscheidung:

Entscheidung	Bedeutung
Bauen	wird als eigener Subframe-Frame gebaut
Wiederverwenden	vorhandener Archetyp reicht
Nur dokumentieren	im MD festhalten, kein Frame
Spaeter	relevant, aber nicht fuer dieses Paket
Raus	bewusst nicht Teil des Scopes

Erst nach dieser Entscheidung darf der Screen in die finale Screen-Liste.

Copy-kritische Zustaende

Manche Zustaende sind technisch nur Banner, Inline-Meldung oder Erfolgsscreen, muessen aber trotzdem gebaut werden.

Grund: Der Text, die Tonalitaet und die naechste Handlung sollen vom Design entschieden werden, nicht spaeter zufaellig vom Developer.

Ein Zustand wird eher gebaut, wenn:

• er sehr haeufig vorkommt
• der Nutzer danach wissen muss, was als Naechstes passiert
• Sicherheit, Vertrauen oder Zugang betroffen ist
• der Text sensibel ist
• die Meldung ein eigener mentaler Schritt im Flow ist
• die Entscheidung nicht dem Developer ueberlassen werden soll

Beispiele:

• Magic-Link gesendet
• Passwort geaendert
• E-Mail nicht gefunden / neutraler Sicherheitstext
• falsche Login-Daten
• 2FA gesperrt
• Link abgelaufen
• Account gesperrt

Field-Validierungen wie "Passwort zu schwach", "Pflichtfeld fehlt" oder "ungueltige Telefonnummer" werden normalerweise nicht einzeln gebaut, wenn sie durch das Form/Input-Kit abgedeckt sind. Ausnahme: Der Zustand ist fachlich oder rechtlich wichtig.

---

3. Was gilt als Screen?

Ein Screen ist ein eigener Arbeitsmoment fuer den Nutzer.

Ein Screen liegt vor, wenn der Nutzer:

• auf einer eigenen Seite landet
• eine Entscheidung trifft
• Daten prueft
• etwas erstellt oder bearbeitet
• einen Flow startet, fortsetzt oder beendet
• blockiert ist und eine Loesung braucht

Beispiele: Login, 2FA, Profil-Auswahl, Kontaktliste, Projekt-Detail, Flow-Editor, Loeschbestaetigung, Reassign-Workflow.

---

4. Wann wird ein Screen in Subframe gebaut?

Ein Screen wird gebaut, wenn mindestens eine Regel zutrifft:

1. Neue Struktur

   • Das Layout unterscheidet sich sichtbar von den bekannten Archetypen.

2. Neue Aufgabe

   • Der Nutzer macht hier etwas Eigenes, nicht nur dieselbe Liste mit anderen Daten.

3. Neue Entscheidung

   • Der Nutzer muss auswaehlen, bestaetigen, abbrechen, wechseln oder fortfahren.

4. Risiko-Moment

   • Loeschen, sperren, Rechte fehlen, Zahlung offen, Datenverlust, irreversible Aktion.

5. Bespoke UI

   • Kanban, Kalender, Plantafel, Flow-Editor, Form-Builder, Chat, Cmd+K, Public Booking.

6. Auth oder Public

   • Screens ohne normale App-Shell oder mit hoher Aussenwirkung.

---

5. Was wird nicht als eigener Subframe-Screen gebaut?

Diese Dinge werden meistens dokumentiert, aber nicht als eigener Frame gebaut:

• normaler Error-Banner auf einer bestehenden Seite
• Toast nach Speichern, Loeschen oder Export
• Field-Error in einem Standardformular
• Empty-State einer normalen Liste, wenn A7 schon greift
• Loading-Skeleton einer normalen Seite
• Permission-State, wenn er nur Standard-A7 ist
• zweite oder dritte Liste mit gleicher Struktur
• Standard-Confirm-Modal ohne besondere Logik
• Hover, Focus, Disabled, Pressed

Ausnahme: Wenn der Zustand die Bedienung oder Struktur veraendert, wird er gebaut.

Beispiel: Account gesperrt und alle Aktionen sind deaktiviert, nur "Zahlung aktualisieren" bleibt moeglich.

---

6. Banner, Toasts und Inline-Meldungen

Banner und Meldungen gehoeren immer zum Screen-Paket, auch wenn sie nicht als eigener Frame gebaut werden.

Entscheidungs-Hierarchie

UI-Form	Wann verwenden?	Typische Beispiele	Meist bauen?
Inline	betrifft genau ein Feld und kann direkt dort korrigiert werden	Pflichtfeld fehlt, E-Mail ungueltig, Passwort zu kurz, 2FA-Code falsch	nein
Screen-Banner	betrifft den aktuellen Screen oder das aktuelle Formular	Login-Daten falsch, Captcha erforderlich, Formular konnte nicht gespeichert werden	nur wenn optisch/fachlich wichtig
Globaler Banner	betrifft App/Shell oder Tenant/Account allgemein	Zahlung offen, Tenant gesperrt, Wartung	D0/App-Shell
Toast	kurze Rueckmeldung nach Aktion, nicht blockierend	gespeichert, kopiert, Einladung versendet, Export gestartet	nein
Modal/Dialog	Nutzer muss bestaetigen oder kurz entscheiden, bleibt aber im Kontext	loeschen bestaetigen, Rolle wechseln, Reassign bestaetigen	falls eigener Entscheidmoment
Eigener Screen	Nutzer ist blockiert, in neuem Flow-Status oder braucht klare naechste Schritte	Link abgelaufen, Magic-Link gesendet, 2FA nicht verfuegbar, Account gesperrt	ja

Entscheidungsfragen

• Kann der Nutzer direkt im Feld korrigieren? Dann Inline.
• Bleibt der Nutzer im selben Screen und kann dort weiterarbeiten? Dann Banner.
• Ist es nur eine kurze Rueckmeldung nach einer Aktion? Dann Toast.
• Muss der Nutzer bestaetigen oder eine kleine Entscheidung treffen, ohne den Screen zu verlassen? Dann Modal/Dialog.
• Ist der Nutzer blockiert oder in einem neuen Flow-Zustand? Dann eigener Screen.
• Ist Sicherheit, Zugang, Vertrauen oder rechtlicher Kontext betroffen? Eher Banner oder Screen, nicht Toast.
• Darf die Meldung verschwinden? Wenn nein, kein Toast.

Blockierende Error States

Blockierende Error States muessen im Screen-Paket genauer beschrieben werden.

Pflichtangaben:

• sichtbarer Titel oder Kernaussage
• Ursache in Nutzersprache
• naechste Primaeraktion
• sekundare Aktion, z. B. zurueck oder Support/Admin kontaktieren
• ob der Nutzer im aktuellen Screen bleiben kann oder einen eigenen Screen braucht

Beispiel:

Ereignis	UI-Form	Bauen?	Inhalt
2FA nicht verfuegbar	Eigener Screen	ja	2FA kann nicht uebersprungen werden, Admin kontaktieren
Reset-Link abgelaufen	Eigener Screen	ja	Link ist nicht mehr gueltig, neuen Link anfordern
2FA-Code falsch	Inline	nein	Code pruefen und erneut eingeben

Globale Banner

Gehoeren zur App-Shell/D0 und koennen ueberall auftauchen.

Beispiele:

• Zahlung offen
• Tenant gesperrt
• Account frozen
• Loeschung vorgemerkt
• Systemwartung

Screen-Banner

Gehoeren direkt zum jeweiligen Screen.

Beispiele:

• Projekt ist abgeschlossen
• Lead hat keine Weiterverarbeitungsfreigabe
• Dieses Formular ist unveroeffentlicht
• Verbindung zu Integration fehlgeschlagen

Action-Feedback

Wird bei der jeweiligen Aktion dokumentiert.

Beispiele:

• gespeichert
• geloescht
• Export gestartet
• Export fehlgeschlagen
• Einladung versendet

Regel: Banner, Toast oder Inline-Meldung nur bauen, wenn sie den Screen optisch oder funktional wesentlich veraendert. Sonst im Markdown dokumentieren.

---

7. Subframe-Grid-Regeln

Subframe wird wie ein Flow-Board genutzt.

Hauptflow

• Der Hauptflow laeuft von links nach rechts.
• Jeder naechste Hauptschritt liegt eine Spalte weiter rechts.
• Der Happy Path bleibt in einer horizontalen Linie.

Varianten und Branches

• Eine Variante geht eine Reihe nach unten.
• Zwei Varianten gehen zwei Reihen nach unten.
• Drei Varianten gehen drei Reihen nach unten.
• Jede Variante laeuft danach wieder nach rechts weiter.

Beispiel:

S01 Login -> S02 2FA -> S03 Profil-Auswahl -> S04 Dashboard
              |
              v
           B01 2FA gesperrt -> B02 Wiederherstellungscode

Wann wird ein neuer Flow gebaut?

Ein neuer Flow wird gebaut, wenn:

• die Variante mehr als 2-3 eigene Screens braucht
• die Variante eine eigene Nutzeraufgabe ist
• eine andere Rolle betroffen ist
• die Grid-Ansicht unuebersichtlich wird
• ein Screen sehr spezifisch oder bespoke wird
• ein anderer Modulbereich beginnt

Regel: Lieber ein sauberer kleiner Flow als ein riesiges unlesbares Board.

Canvas-Qualitaetsregeln

Jede Canvas-Datei muss vor Abschluss lesbar geprueft werden.

Pflichtregeln:

• Nodes gross genug anlegen, damit Titel und Inhalt lesbar bleiben.
• Gruppen brauchen genug Padding; Gruppenlabels duerfen keine Nodes oder Kanten verdecken.
• Kanten duerfen nicht durch andere Nodes laufen.
• Lange Kantenlabels vermeiden.
• Kantenlabels sind erlaubt, wenn genug Abstand zwischen den Karten ist.
• Labels kurz halten, z. B. Magic-Link, falsch, Captcha, gesperrt, 2FA, ok.
• Wenn Labels ueber Nodes oder Gruppen liegen, Karten weiter auseinanderziehen statt die Labels direkt zu entfernen.
• Keine direkte Kante bauen, wenn sie durch einen anderen wichtigen Schritt laeuft.
• Outcomes duerfen als Text-Node dokumentiert werden, wenn sie keine eigenen Screens sind.
• Nach dem Schreiben der Canvas muss JSON validiert werden.

Richtwerte:

Element	Mindestgroesse
File-Node	360 x 170
Text-Node	420 x 170
Gruppe	mindestens 80 px Padding um Nodes

---

8. Umsetzung und Status

Umsetzung

Umsetzung beschreibt, was mit dem Screen oder Zustand gemacht wird.

Wert	Bedeutung
Bauen	Eigener Screen/Frame in Subframe
Wiederverwenden	vorhandenes Pattern/Archetyp reicht
Nur dokumentieren	kein Frame, aber im Markdown beschreiben
Spaeter	bewusst noch nicht jetzt
Raus	nicht im Scope

Status

Status beschreibt, wie weit der Eintrag gerade ist.

Wert	Bedeutung
Idee	noch nicht entschieden
Brainstormed	grob besprochen
Validiert	entschieden, kann gebaut/dokumentiert werden
In Subframe	wird gerade gebaut
Review	gebaut, muss geprueft werden
Fertig	bereit zur Uebergabe