Review UC00-Wireframes¶

Stand: 01.08.2026 14:55 Branch: docs/einheitliche-kopfbereiche Status: Review

Datum, Uhrzeit	Version	Änderung	Autor
01.08.2026 14:55	1.0	Kopfbereich vereinheitlicht	David Mittig

Ziel dieses Reviews¶

Dieses Review bewertet die bestehenden UC00-Wireframes aus docs/developer/wireframes/ im Hinblick auf:

fachliche Vollständigkeit
Bedienbarkeit
Sicherheit
technische Umsetzbarkeit
Wiederverwendbarkeit für spätere Use Cases

Die Bewertung bezieht sich auf UC00 Tenant-Onboarding und Schulverwaltung.

Gesehener Stand¶

Die UC00-Spezifikation beschreibt 11 abgeschlossene Screens:

SA-01 Tenant-Liste
SA-02 Neuer Tenant
SA-03 Tenant-Detail
OB-01 Einladungslink öffnen
OB-02 Passwort setzen
OB-03 2FA einrichten
OB-04 Recovery-Codes sichern
OB-05 Schulprofil ausfüllen
OB-06 Dashboard
TA-01 Schulprofil bearbeiten
TA-02 Login mit Recovery-Code

Die Wireframes liegen jeweils als JSX und SVG vor. Das ist für die frühe Phase sehr sinnvoll, weil damit sowohl interaktive Prototypen als auch statische Dokumentationsansichten möglich sind.

Positive Punkte¶

1. Sehr guter fachlicher Screen-Flow¶

Der Ablauf ist logisch aufgebaut:

Superadmin legt Tenant an.
Schulinhaber erhält Einladung.
Schulinhaber setzt Passwort.
Schulinhaber richtet 2FA ein.
Recovery-Codes werden gesichert.
Schulprofil wird vervollständigt.
Danach erfolgt der Einstieg ins Dashboard.

Das entspricht sauber dem Ziel von UC00: erst die Plattformgrundlage schaffen, bevor weitere Use Cases wie UC01 aufgesetzt werden.

2. Klare Trennung der Rollen¶

Die Wireframes unterscheiden klar zwischen:

Superadmin-Screens SA-*
Onboarding-Screens OB-*
Tenant-Admin-Screens TA-*

Diese Trennung ist wichtig, weil sie später direkt in Routing, Guards und Layouts übernommen werden kann.

3. Gute Fehlerfall-Abdeckung¶

Besonders positiv ist, dass bereits Fehlerfälle im Wireframe mitgedacht sind:

abgelaufener Einladungslink
bereits verwendeter Einladungslink
falscher 2FA-Code
2FA-Sperre nach mehreren Fehlversuchen
Recovery-Code-Ablauf
Deaktivieren-Dialog mit Pflichtgrund

Damit sind die Wireframes nicht nur schöne Oberflächen, sondern beschreiben bereits wichtige Systemzustände.

4. Gute Sicherheitsorientierung¶

Die folgenden Punkte sind aus Sicherheitssicht sinnvoll:

2FA als Pflicht im Onboarding
Recovery-Codes werden nur einmal angezeigt
Bestätigung, dass Recovery-Codes gesichert wurden
2FA-Reset mit Warnhinweis und Checkbox
Deaktivieren eines Tenants mit bewusstem Dialog
Token-Zustände werden sichtbar gemacht

5. Gute Basis für spätere React-Komponenten¶

Die Wireframes enthalten bereits wiederkehrende UI-Muster:

Fortschrittsleiste
Formularfelder mit Fehlerzustand
Info-Banner
Warn-Banner
Status-Badges
Dialoge
Bestätigungs-Checkboxen
Success-Screens

Diese Muster sollten später in wiederverwendbare Komponenten überführt werden.

Verbesserungsvorschläge nach Priorität¶

A. Hohe Priorität¶

A1. Konsistenz zwischen Spezifikation, Datenmodell und Wireframes prüfen¶

In der UC00-Spezifikation werden teilweise Felder und Zustände genannt, die nicht vollständig zum aktuellen Prisma-Schema passen könnten. Beispiele:

is_active wird in der Spezifikation erwähnt, während im Prisma-Schema bereits Status-Enums wie TenantStatus und UserStatus genutzt werden.
token_type und recovery_codes werden in der Spezifikation erwähnt, müssen aber mit dem aktuellen Prisma-Schema abgeglichen werden.
notification_templates wird in der Spezifikation erwähnt, muss mit dem tatsächlichen Datenbankstand und Prisma-Schema abgeglichen werden.

Empfehlung:

Eine kleine Mapping-Tabelle ergänzen:

Fachbegriff im Wireframe	API-Feld	Prisma-Feld	DB-Spalte	Status
Tenant aktiv	status	status	status	prüfen
Schulinhaber E-Mail	admin_email	invitedEmail	invited_email	prüfen
Standard-Währung	default_currency	defaultCurrency	default_currency	prüfen
Token verwendet	used_at	usedAt	used_at	prüfen

Nutzen:

So wird verhindert, dass Frontend, Backend und Datenbank dieselben Begriffe unterschiedlich verwenden.

A2. Öffentliche Onboarding-Screens fachlich stärker absichern¶

Die Screens OB-01 bis OB-05 sind öffentlich beziehungsweise vor vollständigem Login erreichbar. Deshalb sollten sie besonders klar definieren:

Wann ist ein Token gültig?
Wann darf welcher Schritt geöffnet werden?
Was passiert bei Browser-Abbruch?
Darf OB-03 direkt geöffnet werden, wenn OB-02 noch nicht erledigt ist?
Wie wird verhindert, dass jemand Schritte überspringt?

Empfehlung:

Für jeden OB-Screen ergänzen:

Screen	Voraussetzung	Serverprüfung	Fehler bei ungültigem Zustand
OB-01	Token vorhanden	Token gültig, nicht verwendet	F3/F4
OB-02	Token gültig	Einladung offen	Linkfehler
OB-03	Passwort gesetzt	2FA noch offen	Zurück zu OB-02
OB-04	2FA bestätigt	Recovery-Codes erzeugbar	Zurück zu OB-03
OB-05	Codes bestätigt	Profil unvollständig	Profil anzeigen

Nutzen:

Das verhindert spätere Sicherheits- und Zustandsfehler im Onboarding.

A3. Recovery-Codes nicht als normale Kopierdaten behandeln¶

OB-04 enthält Kopieren und Download als Aktionen. Das ist benutzerfreundlich, aber sicherheitsrelevant.

Risiko:

Kopierte Codes landen in der Zwischenablage.
Heruntergeladene Dateien können ungeschützt auf dem Gerät liegen.
Auf gemeinsam genutzten Geräten ist das riskant.

Empfehlung:

Die Oberfläche sollte klarer warnen:

„Nicht auf einem gemeinsam genutzten Gerät speichern.“
„Nicht per E-Mail an dich selbst senden.“
„Codes in einem Passwortmanager oder an einem sicheren Ort speichern.“

Zusätzlich sinnvoll:

Nach „Kopieren“ Hinweis anzeigen: „Zwischenablage nach dem Einfügen wieder leeren.“
Download-Dateiname nicht tenant-spezifisch mit echtem Namen erzeugen.
Optional: „Ich habe die Codes nicht nur kopiert, sondern sicher gespeichert“ als Bestätigung.

A4. 2FA-Simulation von späterer Echtdatenlogik trennen¶

OB-03 nutzt einen festen Simulationscode und einen festen Secret-Wert. Für Wireframes ist das akzeptabel, muss aber in der späteren Umsetzung streng getrennt werden.

Empfehlung:

Im Wireframe oder Review vermerken:

Simulationswerte dürfen nie in produktiven Code übernommen werden.
QR-Code und Secret müssen serverseitig erzeugt werden.
Secret darf nur in der 2FA-Einrichtungsphase sichtbar sein.
Nach bestätigter 2FA darf das Secret nicht mehr erneut angezeigt werden.

B. Mittlere Priorität¶

B1. Sprachstil vereinheitlichen¶

In den Wireframes wird teilweise „Sie“ verwendet. Das kann sachlich passend sein, sollte aber bewusst entschieden werden.

Empfehlung:

Eine Sprachregel für DiveLogix360 festlegen:

Kontext	Empfehlung
Plattform-UI	sachlich, professionell, eher „Sie“
interne Admin-Hinweise	kurz und direkt
Fehlermeldungen	klar, nicht technisch überladen
Sicherheitswarnungen	deutlich, aber nicht panisch

Wichtig ist weniger, ob „du“ oder „Sie“ verwendet wird, sondern dass es überall konsistent ist.

B2. Mobile Darstellung früh berücksichtigen¶

Die Wireframes sind aktuell sehr desktoporientiert. Für eine PWA ist Mobile First aber wesentlich.

Auffällige Punkte:

SA-03 nutzt ein zweispaltiges Layout.
OB-03 nutzt QR-Code und Anleitung nebeneinander.
OB-05 nutzt mehrere Formularbereiche und Kennzahlen nebeneinander.

Empfehlung:

Für jeden Screen zusätzlich eine mobile Regel ergänzen:

Desktop	Mobile
Zwei Spalten	Eine Spalte
Modale Dialoge	Bottom Sheet oder Fullscreen Dialog
Breite Fortschrittsleiste	Kompakte Schrittanzeige
Tabellen	Kartenlayout
Admin-Aktionen nebeneinander	Aktionsmenü

B3. Fortschrittsleiste zentralisieren¶

OB-02 bis OB-05 enthalten eine sehr ähnliche Fortschrittsleiste.

Empfehlung:

Später als Komponente umsetzen:

OnboardingStepper

Eigenschaften:

aktueller Schritt
erledigte Schritte
Schrittlabels
optionaler Fehlerzustand
mobile Kurzvariante

Nutzen:

Weniger Duplikation, konsistenteres Verhalten und einfachere Wartung.

B4. Formularfelder zentralisieren¶

Die Wireframes enthalten mehrfach eigene Field-Hilfskomponenten und eigene Input-Styles.

Empfehlung:

Später als Komponentenbibliothek definieren:

FormField
TextInput
SelectInput
PasswordInput
InfoBanner
WarningBanner
StatusBadge
ConfirmDialog

Das passt gut zum geplanten Frontend mit React, TypeScript, Tailwind und Storybook.

B5. Prozentanzeige bei Schulprofil überdenken¶

OB-05 zeigt zwei Prozentwerte: Pflichtfelder und alle Felder.

Positiv:

Der Nutzer sieht sofort, ob Pflichtfelder vollständig sind.

Mögliches Problem:

Zwei Prozentwerte können verwirren.
Für den Abschluss zählt fachlich nur die Pflichtfeld-Vollständigkeit.

Empfehlung:

Pflichtfelder klar priorisieren:

Hauptanzeige: „Pflichtfelder vollständig: 75 %“
Nebeninfo: „Optionale Angaben: 1 von 2 ergänzt“

Damit ist die Entscheidungslogik verständlicher.

C. Niedrige Priorität¶

C1. Screen-Codes in der Produktoberfläche ausblenden¶

Die Wireframes zeigen Codes wie OB-02 oder SA-03 direkt im UI. Für Entwicklung und Review ist das sinnvoll.

Empfehlung:

Später trennen:

In Wireframes sichtbar lassen.
In der echten App nicht anzeigen.
Optional nur im Dev-Modus einblenden.

C2. Emoji-Einsatz später prüfen¶

Die Wireframes nutzen Emojis für Hinweise, Erfolg, Warnungen und Aktionen.

Für Wireframes ist das gut sichtbar. Für die spätere App sollte geprüft werden, ob Icons aus einer konsistenten Icon-Bibliothek besser sind.

Empfehlung:

Wireframes: Emojis weiterhin okay.
Produktion: konsistente Icons, z. B. aus einer Icon-Bibliothek.

C3. Texte für Fehlermeldungen vereinheitlichen¶

Die Fehlertexte sind bereits verständlich. Für spätere Umsetzung sollte eine zentrale Fehlertext-Liste entstehen.

Beispiel:

Fehlercode	Benutzertext	Technischer Status
F3	Dieser Link ist abgelaufen. Bitte fordere eine neue Einladung an.	410
F4	Dieser Link wurde bereits verwendet. Bitte melde dich an oder kontaktiere den Administrator.	410
F7	Der 2FA-Code ist ungültig. Bitte prüfe den Code und versuche es erneut.	401

Vorschlag für spätere React-Struktur¶

Die Wireframes sollten nicht direkt als Produktivcode übernommen werden. Sinnvoller ist eine strukturierte Umsetzung:

frontend/src/features/uc00-onboarding/
  components/
    OnboardingStepper.tsx
    RecoveryCodeList.tsx
    PasswordPolicyChecklist.tsx
    TwoFactorSetupCard.tsx
    SchoolProfileForm.tsx
  pages/
    InviteTokenPage.tsx
    SetPasswordPage.tsx
    SetupTwoFactorPage.tsx
    RecoveryCodesPage.tsx
    SchoolProfilePage.tsx
    OnboardingDonePage.tsx
  hooks/
    useInviteToken.ts
    useOnboardingState.ts
  api/
    onboardingApi.ts
  types/
    onboarding.types.ts

Für Superadmin:

frontend/src/features/superadmin-tenants/
  components/
    TenantStatusBadge.tsx
    TenantPlanBadge.tsx
    TenantDeactivateDialog.tsx
    TenantPlanDialog.tsx
    TwoFactorResetDialog.tsx
  pages/
    TenantListPage.tsx
    CreateTenantPage.tsx
    TenantDetailPage.tsx
  api/
    tenantsApi.ts
  types/
    tenant.types.ts

Empfohlene nächste Schritte¶

Schritt 1¶

Keine direkte UI-Neuentwicklung starten, sondern zuerst eine kleine fachliche Konsistenzprüfung erstellen:

UC00 Field Mapping: Wireframe → API → Prisma → DB

Schritt 2¶

Die Sicherheitsregeln für öffentliche Onboarding-Schritte dokumentieren:

OB-01 bis OB-05: erlaubte Zustände, Serverprüfungen, Fehlerfälle

Schritt 3¶

Erst danach eine erste echte React-Komponente umsetzen, am besten:

OnboardingStepper

Warum diese Komponente zuerst?

Sie kommt in mehreren Screens vor.
Sie ist fachlich ungefährlich.
Sie hilft, das spätere Designsystem zu stabilisieren.
Sie ist gut in Storybook testbar.

Gesamteinschätzung¶

Die UC00-Wireframes sind für diese Projektphase ungewöhnlich weit und fachlich bereits sehr gut durchdacht.

Die wichtigsten Verbesserungen liegen nicht darin, „mehr UI“ zu bauen, sondern in:

Konsistenz zwischen Wireframe, API, Prisma und Datenbank
klaren Sicherheitszuständen für öffentliche Onboarding-Schritte
mobiler Darstellung
Wiederverwendung gemeinsamer Komponenten
Trennung von Wireframe-Simulation und späterer Produktivlogik

Die Wireframes sind damit eine sehr gute Grundlage für die spätere Frontend-Umsetzung, sollten aber vor dem Coding noch in ein technisches Komponenten- und Datenmapping überführt werden.