236 lines
9.4 KiB
Markdown
236 lines
9.4 KiB
Markdown
---
|
|
kind: wireframe-package
|
|
project: HiveGrid Screen Project
|
|
ticket: D-P2 / Auth-Core
|
|
package: WF-P2 Set Password
|
|
typ: Auth-Core Flow
|
|
status: In Subframe
|
|
subframe: "https://app.subframe.com/f023064a5ca0/flow/534bffc2-b7d3-423b-b9b6-da424980dcf3/edit"
|
|
canvas: "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
|
|
|
|
1. Nutzer kommt aus einem Zubringerflow.
|
|
2. Nutzer setzt ein neues Passwort.
|
|
3. Flow prueft, ob 2FA Pflicht oder freiwillig ist.
|
|
4. Nutzer richtet 2FA ein oder ueberspringt, falls erlaubt.
|
|
5. Nutzer sieht Recovery-/Sicherheitshinweis.
|
|
6. 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:
|
|
|
|
```text
|
|
S01 Neues Passwort setzen -> S02 2FA freiwillig anbieten -> S04 2FA einrichten -> S05 Recovery Hinweis -> S06 Abschluss
|
|
```
|
|
|
|
Freiwillig ueberspringen:
|
|
|
|
```text
|
|
S02 2FA freiwillig anbieten -> S06 Abschluss
|
|
```
|
|
|
|
2FA Pflicht:
|
|
|
|
```text
|
|
S01 Neues Passwort setzen -> S03 2FA erforderlich -> S04 2FA einrichten -> S05 Recovery Hinweis -> S06 Abschluss
|
|
```
|
|
|
|
Blocker:
|
|
|
|
```text
|
|
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
|
|
|
|
- [x] Jeder Screen ist mit Umsetzung markiert.
|
|
- [x] Jedes sichtbare Feld hat eine Datenquelle.
|
|
- [x] Jeder Button hat eine Aktion.
|
|
- [x] Banner/Inline-Meldungen sind dokumentiert.
|
|
- [x] Toasts/Action-Feedback sind dokumentiert.
|
|
- [x] Relevante Zustaende sind beschrieben.
|
|
- [x] Zubringer-/Core-Regel ist dokumentiert.
|
|
- [x] Zurueck-/Abbrechen-Aktion ist dokumentiert.
|
|
- [x] Offene Fragen sind sichtbar.
|
|
- [x] Subframe-Link ist eingetragen.
|