Files
HiveGrid-Wireframes/02 Wireframes/_Templates/Wireframe Paket Template.md
T
2026-06-24 23:36:10 +02:00

3.9 KiB

kind, project, ticket, package, typ, status, subframe, canvas
kind project ticket package typ status subframe canvas
wireframe-package HiveGrid Screen Project Flow Idee

WF-[Ticket] [Paketname]

Status: Idee
Subframe-Link: -
Canvas: -
Stand: YYYY-MM-DD


1. Kurzfassung

Was klaert dieses Wireframe-Paket?


2. Intent Check

Erst klaeren, was ueberhaupt gewollt ist.

Frage Antwort
Welches Ticket/Modul ist betroffen? -
Was soll der Nutzer am Ende schaffen? -
Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? -
Welche Planning-Quellen wurden geprueft? -
Was ist sicher im Scope? -
Was ist sicher nicht im Scope? -
Gibt es Admin/Normalrolle-Unterschiede? -
Welche Annahmen sind noch unsicher? -

3. Scope

Punkt Inhalt
Ticket/Modul -
Nutzerrolle -
Admin-Variante -
Normale Rolle hoechste Rolle unter Admin
Startpunkt -
Ziel -
Haupt-Archetyp -
Bespoke-Anteil -
Out of scope -

4. Brainstorming

Screen-Listen entstehen erst nach dem Brainstorming. Hier noch keine finale Screen-Liste festlegen.

Flow-Frage

Worum geht es in diesem Flow?

UX-Varianten

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

Entscheidung

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

Happy Path

Varianten / Branches

Roadblocks

Meldungs-/Error-State-Brainstorming

Welche Fehler, Warnungen, Success-Zustaende und Hinweise koennen auftreten?

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

Regel: Wenn der Nutzer blockiert ist, Sicherheit/Zugang betroffen ist oder der Zustand eine klare naechste Handlung braucht, wird ein eigener Screen geprueft.

Offene Fragen


5. Screen-Kandidaten nach Entscheidung

Diese Liste ist noch nicht final. Hier wird erstmal gesammelt.

Kandidat Warum eventuell noetig? Erste Einschaetzung
- - -

6. Screen Validation Gate

Jeder Kandidat wird einzeln entschieden, bevor er in den Flow kommt.

ID Screen/Zustand Ist eigener Arbeitsmoment? Neue Struktur/Entscheidung/Risiko? Entscheidung Begruendung
S01 - - - - -

Entscheidung: Bauen, Wiederverwenden, Nur dokumentieren, Spaeter, Raus

Copy-kritische Zustaende

Diese Zustaende koennen gebaut werden, auch wenn sie technisch nur Meldungen sind.

Zustand Bauen? Warum / Copy-Entscheidung
- - -

Blockierende Error States

Diese Zustaende muessen genauer definiert werden, wenn sie den Nutzer stoppen.

Zustand UI-Form Primaeraktion Sekundare Aktion Inhalt/Copy-Richtung
- Screen / Banner / Modal - - -

7. Validierte Screen-Liste

ID Screen/Zustand Typ Umsetzung Ort Status
S01 - - Bauen - Idee

Umsetzung: Bauen, Wiederverwenden, Nur dokumentieren, Spaeter, Raus


8. Subframe-Grid

Hauptflow:

S01 -> S02 -> S03

Branches:

S02
 |
 v
B01 -> B02

9. Screen-Pakete

Verlinke hier auf einzelne Screen-Dateien:


10. Handoff-Check

  • Jeder Screen ist mit Umsetzung markiert.
  • Jedes sichtbare Feld hat eine Datenquelle.
  • Jeder Button hat eine Aktion.
  • Banner/Inline-Meldungen sind dokumentiert.
  • Toasts/Action-Feedback sind dokumentiert.
  • Meldungs-/Error-State-Matrix ist ausgefuellt.
  • Blockierende Error States sind mit naechster Aktion definiert.
  • Relevante Zustaende sind beschrieben.
  • Offene Fragen sind sichtbar.
  • Subframe-Link ist eingetragen.