0 Fork 0

Files

T

david d953a79e95 chore(repo): sync wireframe structure and references

2026-08-08 03:09:06 +02:00

9.4 KiB

Raw Permalink Blame History

kind, project, ticket, package, typ, status, subframe, canvas

kind	project	ticket	package	typ	status	subframe	canvas
wireframe-package	HiveGrid Screen Project	D-P2 / Auth-Core	WF-P2 Set Password	Auth-Core Flow	In Subframe	https://app.subframe.com/f023064a5ca0/flow/534bffc2-b7d3-423b-b9b6-da424980dcf3/edit	02 Wireframes/P2 Set Password/WF-P2 Set Password/WF-P2 Set Password.canvas

WF-P2 Set Password

Status: In Subframe
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/534bffc2-b7d3-423b-b9b6-da424980dcf3/edit
Canvas: WF-P2 Set Password.canvas
Stand: 2026-06-23

1. Kurzfassung

Set Password ist ein zentraler Auth-Core-Flow fuer wiederverwendbare Passwort-Trigger. Er wird von mehreren Zubringerflows genutzt, z. B. Passwort Reset, Einladung, Passwort aendern, Admin-Reset und Security-Incident.

Ausnahme: Der Neukunden-Signup setzt das Passwort direkt im Signup-Flow, um Reibung im Self-Service-Signup zu reduzieren. Signup ist deshalb kein normaler Zubringer zu diesem Core-Flow.

Der Nutzer setzt ein neues Passwort und bekommt 2FA entweder freiwillig angeboten oder muss 2FA verpflichtend einrichten.

2. Intent Check

Frage	Antwort
Welches Ticket/Modul ist betroffen?	D-P2 / Auth-Core
Was soll der Nutzer am Ende schaffen?	gueltiges Passwort setzen und 2FA-Status klaeren
Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation?	zentraler Auth-Core-Flow
Welche Planning-Quellen wurden geprueft?	D-P2, UX-Entscheidung mit Head Development
Was ist sicher im Scope?	Passwort setzen, 2FA freiwillig, 2FA Pflicht, 2FA Setup, Recovery-Hinweis, Abschluss
Was ist sicher nicht im Scope?	E-Mail anfordern, Reset-Link gesendet, Neukunden-Signup-Daten, Admin-Ausloeser
Gibt es Admin/Normalrolle-Unterschiede?	Nicht im Core selbst; Pflicht/Freiwillig kommt vom Zubringerflow
Welche Annahmen sind noch unsicher?	genaue 2FA-Methode/Provider, genaue Recovery-Code-Logik

3. Scope

Punkt	Inhalt
Ticket/Modul	D-P2 / Auth-Core
Nutzerrolle	Nutzer, der zu einem Passwort-Setzen gezwungen oder eingeladen wurde
Admin-Variante	Admin-Reset kann bestimmen, ob 2FA Pflicht oder freiwillig ist
Normale Rolle	hoechste Rolle unter Admin; Core bleibt gleich
Startpunkt	wird von Zubringerflow gesetzt
Ziel	neues Passwort + 2FA-Entscheidung/Setup abgeschlossen
Haupt-Archetyp	A4 Form + A5 Auth-Step
Bespoke-Anteil	nein
Out of scope	Reset-Anforderung, Signup-Formular, Admin-Trigger

4. Brainstorming

Screen-Listen entstehen erst nach dem Brainstorming. Hier wurde entschieden, ob Set Password nur ein Passwort-Screen oder ein gefuehrter Sicherheits-Setup-Flow ist.

Flow-Frage

Soll Set Password nur ein Passwort-Screen sein oder ein zentraler Sicherheitsflow mit Passwort + 2FA + Abschluss?

UX-Varianten

Option	Beschreibung	Vorteil	Nachteil	Empfehlung
A	Nur Passwort setzen	sehr einfach	2FA wird nicht gefuehrt	raus
B	Passwort setzen + 2FA anbieten	flexibel	Pflicht-2FA braucht Sonderlogik	teilweise
C	Gefuehrter Security-Setup: Passwort + 2FA + Recovery + Abschluss	B2B-sicher, klar, wiederverwendbar	mehr Screens	genommen
D	Eigener Set-Password-Flow pro Einstieg	maximal spezifisch	unuebersichtlich, viel Dopplung	raus

Entscheidung

Entscheidung	Status	Notiz
Option C	genommen	zentraler B2B-Security-Flow
2FA immer sichtbar machen	genommen	mindestens anbieten
2FA freiwillig und 2FA Pflicht trennen	genommen	zwei verschiedene UX-Momente
Pflicht/Freiwillig kommt vom Zubringerflow	genommen	z. B. Reset, Einladung, Admin-Reset
Neukunden-Signup ist Ausnahme	genommen	Passwort wird dort direkt im Signup gesetzt
Recovery-Hinweis bauen	genommen	sicherheitskritisch
Zurueck-Button bei versehentlichem Einstieg	genommen	sekundare Navigation zurueck zum vorherigen Auth-Schritt, z. B. Reset Password

Happy Path

Nutzer kommt aus einem Zubringerflow.
Nutzer setzt ein neues Passwort.
Flow prueft, ob 2FA Pflicht oder freiwillig ist.
Nutzer richtet 2FA ein oder ueberspringt, falls erlaubt.
Nutzer sieht Recovery-/Sicherheitshinweis.
Nutzer erreicht Abschluss und wird weitergeleitet.

Der Nutzer kann den Flow ueber eine sekundare Zurueck-/Abbrechen-Aktion verlassen, solange noch keine sicherheitskritische Aktion abgeschlossen wurde und der Zubringerflow es erlaubt.

Varianten / Branches

2FA freiwillig: Nutzer kann einrichten oder ueberspringen.
2FA Pflicht: Nutzer kann nicht ueberspringen.
Zurueck/Abbrechen: Nutzer kann bei versehentlichem Einstieg zum vorherigen Auth-Schritt zurueck.
2FA Setup wird nach zu vielen Versuchen gesperrt.

Roadblocks

Passwort zu schwach
2FA-Code falsch
2FA Setup gesperrt
Recovery-Hinweis nicht bestaetigt, falls Pflicht

Offene Fragen

Welche 2FA-Methode ist v1 final? TOTP/Authenticator ist wahrscheinlich.
Muss Recovery-Code aktiv bestaetigt werden oder reicht Hinweis?
Welche Zubringerflows setzen 2FA auf Pflicht?

5. Screen-Kandidaten nach Entscheidung

Kandidat	Warum eventuell noetig?	Erste Einschaetzung
Neues Passwort setzen	Hauptschritt	Bauen
2FA freiwillig anbieten	Nutzer darf ueberspringen	Bauen
2FA erforderlich	Pflichtzustand, kein Skip	Bauen
2FA einrichten	QR/Code/Bestaetigung	Bauen
Recovery-Code / Sicherheitshinweis	wichtig nach 2FA Setup	Bauen
Abschluss	klares Ende + Weiterleitung	Bauen
Zurueck/Abbrechen	wichtig bei versehentlichem Reset-Einstieg	Als Aktion dokumentieren
Passwort zu schwach	Formularzustand	Nur dokumentieren
2FA-Code falsch	Formularzustand	Nur dokumentieren
2FA Setup gesperrt	sicherheitskritischer Blocker	Bauen
2FA uebersprungen	Ergebniszustand	in Abschluss integrieren

6. Screen Validation Gate

ID	Screen/Zustand	Ist eigener Arbeitsmoment?	Neue Struktur/Entscheidung/Risiko?	Entscheidung	Begruendung
S01	Screens/S01 Neues Passwort setzen	ja	ja, Hauptschritt	Bauen	zentraler Einstieg in Core
S02	Screens/S02 2FA freiwillig anbieten	ja	ja, freiwillige Entscheidung	Bauen	anderer UX-Moment als Pflicht
S03	Screens/S03 2FA erforderlich	ja	ja, Pflicht ohne Skip	Bauen	klarer Sicherheitszwang
S04	Screens/S04 2FA einrichten	ja	ja, Setup mit Code	Bauen	eigener Setup-Schritt
S05	Screens/S05 Recovery Hinweis	ja	ja, sicherheitskritisch	Bauen	Recovery muss verstanden werden
S06	Screens/S06 Abschluss	ja	ja, Ende und Weiterleitung	Bauen	klares Abschlussfeedback
V01	Passwort zu schwach	nein	nein	Nur dokumentieren	A4 Formularzustand
V02	2FA-Code falsch	nein	nein	Nur dokumentieren	Inline-Fehler in S04
V03	Varianten/V03 2FA Setup gesperrt	ja	ja, Blocker	Bauen	Nutzer braucht Loesung
D01	2FA uebersprungen	nein	Ergebniszustand	Wiederverwenden	anderer Text in S06
D02	Zurueck/Abbrechen	nein	Aktion je Zubringerflow	Nur dokumentieren	kein eigener Screen

Copy-kritische Zustaende

Zustand	Bauen?	Warum / Copy-Entscheidung
2FA erforderlich	ja	Pflicht darf nicht wie Empfehlung wirken
2FA freiwillig	ja	Angebot muss klar, aber nicht noetigend sein
Recovery-Hinweis	ja	sicherheitskritisch
Abschluss	ja	Weiterleitung und Status muessen klar sein
2FA Setup gesperrt	ja	starker Blocker

7. Validierte Screen-Liste

ID	Screen/Zustand	Typ	Umsetzung	Ort	Status
S01	Screens/S01 Neues Passwort setzen	Auth Form	Bauen	Core Start	Validiert
S02	Screens/S02 2FA freiwillig anbieten	Auth Decision	Bauen	nach S01	Validiert
S03	Screens/S03 2FA erforderlich	Auth Decision	Bauen	nach S01	Validiert
S04	Screens/S04 2FA einrichten	Auth Security	Bauen	nach S02/S03	Validiert
S05	Screens/S05 Recovery Hinweis	Auth Security	Bauen	nach S04	Validiert
S06	Screens/S06 Abschluss	Auth Feedback	Bauen	Flow-Ende	Validiert
V03	Varianten/V03 2FA Setup gesperrt	Auth Blocker	Bauen	Variante von S04	Validiert

8. Subframe-Grid

Hauptflow mit 2FA freiwillig:

S01 Neues Passwort setzen -> S02 2FA freiwillig anbieten -> S04 2FA einrichten -> S05 Recovery Hinweis -> S06 Abschluss

Freiwillig ueberspringen:

S02 2FA freiwillig anbieten -> S06 Abschluss

2FA Pflicht:

S01 Neues Passwort setzen -> S03 2FA erforderlich -> S04 2FA einrichten -> S05 Recovery Hinweis -> S06 Abschluss

Blocker:

S04 2FA einrichten -> V03 2FA Setup gesperrt

9. Screen-Pakete

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.
Relevante Zustaende sind beschrieben.
Zubringer-/Core-Regel ist dokumentiert.
Zurueck-/Abbrechen-Aktion ist dokumentiert.
Offene Fragen sind sichtbar.
Subframe-Link ist eingetragen.

9.4 KiB Raw Permalink Blame History