9.4 KiB
9.4 KiB
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 Auth/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
- Screens/S01 Neues Passwort setzen
- Screens/S02 2FA freiwillig anbieten
- Screens/S03 2FA erforderlich
- Screens/S04 2FA einrichten
- Screens/S05 Recovery Hinweis
- Screens/S06 Abschluss
- Varianten/V03 2FA Setup gesperrt
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.