256 lines
12 KiB
Markdown
256 lines
12 KiB
Markdown
---
|
|
kind: wireframe-package
|
|
project: HiveGrid Screen Project
|
|
ticket: D-P2
|
|
package: WF-P2 Signup
|
|
typ: Flow
|
|
status: In Subframe
|
|
subframe: "https://app.subframe.com/f023064a5ca0/flow/5bb64c72-46af-46a8-84dd-5b4ac6bcfcfe/edit"
|
|
canvas: "02 Wireframes/P2 Auth/WF-P2 Signup/WF-P2 Signup.canvas"
|
|
---
|
|
|
|
# WF-P2 Signup
|
|
|
|
Status: In Subframe
|
|
Subframe-Link: https://app.subframe.com/f023064a5ca0/flow/5bb64c72-46af-46a8-84dd-5b4ac6bcfcfe/edit
|
|
Canvas: [[WF-P2 Signup.canvas]]
|
|
Stand: 2026-06-24
|
|
|
|
---
|
|
|
|
## 1. Kurzfassung
|
|
|
|
Dieses Paket klaert den Self-Service-Signup fuer HiveGrid.
|
|
|
|
Der Signup ist fuer v1 bewusst ein minimaler Test-/Basis-Signup, kein Wizard. Er soll grundsaetzlich Account und ersten Workspace erstellen koennen, damit die App nutzbar und testbar ist.
|
|
|
|
Wichtig: Dieser Signup ist fachlich noch nicht der finale volle Signup. Spaeter muss er deutlich ausgebaut werden. Firmenname ist in v1 nur ein Platzhalter fuer den Workspace-/Firmenkontext; Billing, USt-ID, Branding, Team, Onboarding und weitere Firmendaten kommen spaeter.
|
|
|
|
---
|
|
|
|
## 2. Intent Check
|
|
|
|
| Frage | Antwort |
|
|
|---|---|
|
|
| Welches Ticket/Modul ist betroffen? | D-P2 Auth / Identitaet & Mandantentrennung |
|
|
| Was soll der Nutzer am Ende schaffen? | Account und Workspace anlegen und danach in den ersten sicheren Einstieg kommen |
|
|
| Ist es ein Flow, einzelner Screen, Zustand oder nur Dokumentation? | kleiner Signup-Flow mit Hauptformular und wichtigen Blocker-/Feedback-Zustaenden |
|
|
| Welche Planning-Quellen wurden geprueft? | D-P2, SCREEN-MAP §1 Auth-Screens |
|
|
| Was ist sicher im Scope? | E-Mail, Passwort innerhalb des Signup-Flows, Vorname, Nachname, Firmenname als Platzhalter, Captcha, AGB-/Datenschutz-Checkbox, Auto-SHK-Seed |
|
|
| Was ist sicher nicht im Scope? | USt-ID, Rechnungsdaten, Logo/Branding, Mitglieder einladen, Template-Auswahl, CRM-/Pipeline-Konfiguration, mehrstufiger Onboarding-Wizard, Tenant-Auswahl nach Login, Admin-Rollenverwaltung |
|
|
| Gibt es Admin/Normalrolle-Unterschiede? | Signup-Ersteller wird initialer Tenant-Admin; weitere Rollen kommen spaeter ueber Mitarbeiter/Admin-RBAC |
|
|
| Welche Annahmen sind noch unsicher? | Keine fuer v1; spaeterer Ausbau ist im Backlog markiert |
|
|
|
|
---
|
|
|
|
## 3. Scope
|
|
|
|
| Punkt | Inhalt |
|
|
|---|---|
|
|
| Ticket/Modul | D-P2 Auth |
|
|
| Nutzerrolle | neuer Nutzer ohne Account |
|
|
| Admin-Variante | erster Nutzer wird Tenant-Admin |
|
|
| Normale Rolle | nicht relevant im Signup selbst |
|
|
| Startpunkt | `/signup`, Link aus Login |
|
|
| Ziel | Tenant/Workspace + erster User angelegt, sicherer Folgepfad klar |
|
|
| Haupt-Archetyp | A4 Form |
|
|
| Bespoke-Anteil | nein |
|
|
| Out of scope | Onboarding-Checkliste, Demo-Daten, detaillierter Firmen-Wizard, Billing-/USt-Daten, Branding, Team-Setup |
|
|
|
|
---
|
|
|
|
## 4. Brainstorming
|
|
|
|
### Flow-Frage
|
|
|
|
Soll Signup als einzelnes Formular gebaut werden oder als mehrstufiger Wizard?
|
|
|
|
### UX-Varianten
|
|
|
|
| Option | Beschreibung | Vorteil | Nachteil | Empfehlung |
|
|
|---|---|---|---|---|
|
|
| A | Ein schlankes Formular mit Account, minimalem Firmen-Platzhalter und Rechtlichem | schnell, gut fuer Testzugang, wenig Reibung | spaeter fachlich unvollstaendig | genommen |
|
|
| B | Mehrstufiger Wizard Account -> Firma -> Rechtliches -> Setup | ruhiger pro Schritt | widerspricht v1-Schnitt, hoeherer Aufwand | raus fuer v1, spaeterer Ausbau |
|
|
| C | Einladung-only, kein Self-Service | kontrollierter Vertriebspfad | D-P2 fordert Self-Service-Signup | raus |
|
|
|
|
### Entscheidung
|
|
|
|
| Entscheidung | Status | Notiz |
|
|
|---|---|---|
|
|
| Ein Formular, kein Wizard | genommen | entspricht D-P2 und SCREEN-MAP |
|
|
| Minimaler Test-/Basis-Signup | genommen | Ziel ist erstmal grundsaetzlich Accounts/Workspaces erstellen zu koennen |
|
|
| Firmenname nur als Platzhalter | genommen | spaeter kommen echte Workspace-/Firmen-/Billing-Daten dazu |
|
|
| Captcha im Signup | genommen | Anti-Spam/Schutz fuer Self-Service-Signup |
|
|
| Legal-Consent sichtbar im Formular | genommen | AGB und Datenschutz sind vor Submit notwendig |
|
|
| Passwort im Signup verankert | genommen | Ausnahme fuer Neukunden-Signup, damit moeglichst wenig Reibung entsteht |
|
|
| `WF-P2 Set Password` nicht fuer Signup | genommen | Core-Flow bleibt fuer Einladung, Reset, Change Password, Admin-Reset und spaetere Trigger |
|
|
| Vorbereitungsscreen nach E-Mail-Bestaetigung | genommen | S02 zeigt, dass Workspace/Account vorbereitet wird; kann technisch uebersprungen werden, wenn alles sofort fertig ist |
|
|
| E-Mail-Bestaetigung vor Abschluss | genommen | Signup kann ohne bestaetigte E-Mail nicht final abgeschlossen werden |
|
|
|
|
### Happy Path
|
|
|
|
1. Nutzer oeffnet `/signup`.
|
|
2. Nutzer gibt E-Mail, Passwort, Vorname, Nachname und Firmenname/Workspace-Platzhalter ein.
|
|
3. Nutzer loest Captcha und bestaetigt AGB/Datenschutz.
|
|
4. Nutzer sendet Signup ab.
|
|
5. Nutzer muss die E-Mail bestaetigen, bevor der Signup abgeschlossen wird.
|
|
6. Danach legt/finalisiert das System Workspace/Tenant und ersten Admin-User.
|
|
7. Nutzer sieht S02 `Workspace wird vorbereitet`, falls Provisioning/Laden sichtbar ist.
|
|
8. Wenn kein sichtbares Laden noetig ist, kann S02 technisch uebersprungen werden und direkt in die App fuehren.
|
|
|
|
### Varianten / Branches
|
|
|
|
- Passwort ist zu schwach oder in Breach-Liste.
|
|
- Firmen-/Tenant-Slug ist reserviert oder bereits vergeben.
|
|
- Legal-Checkbox fehlt.
|
|
- Tenant-Provisioning laeuft noch.
|
|
|
|
### Roadblocks
|
|
|
|
- E-Mail bereits registriert
|
|
- Passwort durch Policy blockiert
|
|
- Legal-Consent fehlt
|
|
- reservierter Tenant-Slug
|
|
- Provisioning-Fehler beim Tenant/Seed
|
|
|
|
### Meldungs-/Error-State-Brainstorming
|
|
|
|
| Ereignis | UI-Form | Blockiert? | Bauen? | Copy/Notiz |
|
|
|---|---|---|---|---|
|
|
| Passwort zu schwach | Inline | ja | nein | A4-Validierung, klare Policy |
|
|
| Passwort in Breach-Liste | Inline/Banner im Formular | ja | nein | sicherheitskritisch, aber kein eigener Screen |
|
|
| E-Mail existiert bereits | Inline + Link zu Login/Reset | ja | nein | keine Account-Enumeration ausserhalb Signup uebertreiben |
|
|
| Legal-Consent fehlt | Inline | ja | nein | Nutzer kann direkt korrigieren |
|
|
| Tenant-Slug reserviert/vergeben | Inline | ja | nein | Alternativvorschlag anzeigen |
|
|
| Signup erfolgreich / Workspace wird vorbereitet | Screen mit Ladezustand oder App-Redirect | nein | ja | Screen bauen, aber bei sofort fertigem Workspace ueberspringbar |
|
|
| Provisioning-Fehler | Banner | ja | nein | Retry/Kontakt anbieten |
|
|
|
|
### S01 Validierter Minimalumfang
|
|
|
|
| Feld / Element | Status | Notiz |
|
|
|---|---|---|
|
|
| E-Mail | rein | Pflichtfeld |
|
|
| Passwort | rein | direkt im Signup-Flow verankert, inklusive Staerke-/Breach-Feedback |
|
|
| Vorname | rein | Pflichtfeld fuer Basisprofil |
|
|
| Nachname | rein | Pflichtfeld fuer Basisprofil |
|
|
| Firmenname | rein als Platzhalter | erzeugt Workspace-/Tenant-Kontext, spaeter deutlich ausbauen |
|
|
| Captcha | rein | Anti-Spam/Schutz |
|
|
| AGB-Checkbox | rein | Pflicht |
|
|
| Datenschutz-Checkbox | rein | Pflicht |
|
|
| USt-ID | raus v1 | spaeter in Workspace/Billing-Settings |
|
|
| Rechnungsdaten | raus v1 | spaeter Billing |
|
|
| Logo/Branding | raus v1 | spaeter Branding/Workspace-Settings |
|
|
| Mitglieder einladen | raus v1 | spaeter Admin RBAC/Checklist |
|
|
| Template-Auswahl | raus v1 | spaeter Onboarding-Ausbau |
|
|
|
|
---
|
|
|
|
## 5. Screen-Kandidaten nach Entscheidung
|
|
|
|
| Kandidat | Warum eventuell noetig? | Erste Einschaetzung |
|
|
|---|---|---|
|
|
| Signup | Hauptformular | Bauen |
|
|
| Signup erfolgreich / Workspace wird vorbereitet | klaert Folgepfad und Auto-SHK-Seed | Bauen |
|
|
| E-Mail bestaetigen | Pflicht, sonst ist Signup nicht abgeschlossen | Bauen |
|
|
| Passwort/Breach blockiert | Sicherheitsfeedback | Nur dokumentieren |
|
|
| Tenant-Slug reserviert/vergeben | korrigierbarer Formularfehler | Nur dokumentieren |
|
|
| Legal-Consent fehlt | korrigierbarer Formularfehler | Nur dokumentieren |
|
|
| Provisioning-Fehler | technischer Fehler mit Retry | Nur dokumentieren |
|
|
|
|
---
|
|
|
|
## 6. Screen Validation Gate
|
|
|
|
| ID | Screen/Zustand | Ist eigener Arbeitsmoment? | Neue Struktur/Entscheidung/Risiko? | Entscheidung | Begruendung |
|
|
|---|---|---|---|---|---|
|
|
| S01 | Signup | ja | ja, Hauptformular | Validiert | minimaler Test-/Basis-Signup mit E-Mail, Passwort, Name, Firmenname-Platzhalter, Captcha und Legal |
|
|
| S02 | Signup erfolgreich / Workspace wird vorbereitet | ja | ja, Folgepfad nach E-Mail-Bestaetigung | Validiert | eigener Lade-/Vorbereitungsscreen; bei sofort fertigem Workspace technisch ueberspringbar |
|
|
| S03 | E-Mail bestaetigen | ja | ja, Auth-Sicherheitsentscheidung | Validiert | Pflicht, sonst ist Signup nicht abgeschlossen |
|
|
| D01 | Passwort zu schwach/Breach | nein | nein | Nur dokumentieren | Inline-Zustand in S01 |
|
|
| D02 | Slug/Firma reserviert | nein | nein | Nur dokumentieren | Inline-Zustand in S01 |
|
|
| D03 | Legal-Consent fehlt | nein | nein | Nur dokumentieren | Inline-Zustand in S01 |
|
|
| D04 | Provisioning-Fehler | nein | ja, technischer Blocker | Nur dokumentieren | Banner mit Retry reicht voraussichtlich |
|
|
|
|
### Copy-kritische Zustaende
|
|
|
|
| Zustand | Bauen? | Warum / Copy-Entscheidung |
|
|
|---|---|---|
|
|
| Passwort in Breach-Liste | nein | Formulierung muss klar, aber nicht technisch sein |
|
|
| Legal-Consent | nein | muss vor Submit eindeutig sein |
|
|
| Workspace wird vorbereitet | ja | eigener Lade-/Feedbackscreen nach E-Mail-Bestaetigung, ueberspringbar wenn sofort fertig |
|
|
|
|
### Blockierende Error States
|
|
|
|
| Zustand | UI-Form | Primaeraktion | Sekundare Aktion | Inhalt/Copy-Richtung |
|
|
|---|---|---|---|---|
|
|
| E-Mail existiert bereits | Inline | Einloggen | Passwort vergessen | Kein Sackgassen-Text |
|
|
| Slug reserviert/vergeben | Inline | Vorschlag uebernehmen | Firmenname anpassen | Kurz, konkret |
|
|
| Provisioning-Fehler | Banner | Erneut versuchen | Support kontaktieren | Keine Rohfehler |
|
|
|
|
---
|
|
|
|
## 7. Validierte Screen-Liste
|
|
|
|
S01 ist als minimaler Test-/Basis-Signup validiert. S03 E-Mail bestaetigen ist Pflicht und validiert. S02 ist als Vorbereitungsscreen nach E-Mail-Bestaetigung validiert.
|
|
|
|
| ID | Screen/Zustand | Typ | Umsetzung | Ort | Status |
|
|
|---|---|---|---|---|---|
|
|
| S01 | Signup | Auth Form | Bauen | `/signup` | Validiert |
|
|
| S02 | Signup erfolgreich / Workspace wird vorbereitet | Auth Feedback | Bauen | nach E-Mail-Bestaetigung | Validiert |
|
|
| S03 | E-Mail bestaetigen | Auth Feedback | Bauen | nach S01 | Validiert |
|
|
|
|
---
|
|
|
|
## 8. Subframe-Grid
|
|
|
|
```text
|
|
S01 Signup -> S03 E-Mail bestaetigen -> E-Mail-Link -> S02 Signup erfolgreich / Workspace wird vorbereitet -> App-Start
|
|
```
|
|
|
|
Hinweis: Wenn der Workspace ohne sichtbares Warten fertig ist, darf S02 technisch uebersprungen werden und direkt in die App fuehren.
|
|
|
|
---
|
|
|
|
## 9. Screen-Pakete
|
|
|
|
| ID | Datei |
|
|
|---|---|
|
|
| S01 | [[Screens/S01 Signup]] |
|
|
| S02 | [[Screens/S02 Signup erfolgreich Workspace wird vorbereitet]] |
|
|
| S03 | [[Screens/S03 E-Mail bestaetigen]] |
|
|
|
|
---
|
|
|
|
## 10. Backlog / Ausbau
|
|
|
|
Diese Punkte muessen spaeter nochmal gross ausgebaut werden. Der v1-Signup ist nur ein schlanker Einstieg, damit Accounts/Workspaces erstellt und getestet werden koennen.
|
|
|
|
| Thema | Warum spaeter |
|
|
|---|---|
|
|
| Voller Firmen-/Workspace-Step | Rechtsform, Adresse, USt-ID, Rechnungsdaten, Logo, Branding, ggf. weitere Organisationseinstellungen |
|
|
| Billing/Trial/Plan-Auswahl | gehoert zu P20/Billing, nicht in den Minimal-Signup |
|
|
| Onboarding-Wizard | v2 laut Planning; v1 nutzt Auto-SHK-Seed und spaeter Checklist/Banner |
|
|
| Template-/Branchen-Auswahl | echte Templates existieren noch nicht; SHK ist Default |
|
|
| Mitglieder einladen | nach Signup ueber Admin RBAC / Erste-Schritte-Checklist |
|
|
| Integrationen verbinden | spaeter In-App-Setup fuer E-Mail, Kalender, Telefonie, Formulare |
|
|
| CRM-/Pipeline-Konfiguration | spaeter Settings/Onboarding, nicht Signup-Blocker |
|
|
|
|
---
|
|
|
|
## 11. Handoff-Check
|
|
|
|
- [x] Paket ist angelegt.
|
|
- [x] Screen-Kandidaten sind gesammelt.
|
|
- [x] Meldungs-/Error-State-Matrix ist ausgefuellt.
|
|
- [x] Offene Fragen sind sichtbar.
|
|
- [x] S01 Minimal-Signup ist validiert.
|
|
- [x] Passwort ist fuer Neukunden-Signup direkt im Signup-Flow verankert.
|
|
- [x] `WF-P2 Set Password` bleibt fuer Einladung, Reset, Change Password und andere Passwort-Trigger reserviert.
|
|
- [x] S03 E-Mail bestaetigen ist als Pflichtschritt validiert.
|
|
- [x] S02 Signup erfolgreich / Workspace wird vorbereitet ist validiert.
|
|
- [x] Spaeterer Signup-/Onboarding-Ausbau ist im Backlog markiert.
|
|
- [x] David hat die Kandidaten validiert.
|
|
- [x] Screen-Dateien sind angelegt.
|
|
- [x] Canvas ist angelegt.
|
|
- [ ] Subframe-Link ist eingetragen.
|