# 🖌️ [UI/UX Designer] — Zwischenstand & Roadmap

> **Stand:** 3. April 2026
> **Rolle:** High-Density Design, Wireframes, Usability, Design-System, Empty States

---

## ✅ Erledigte Sprints

### Sprint A — Abgeschlossen

- [x] **A-1** | Design-Inventur: Bestehende V3-Screens analysiert
  - [x] Alle vorhandenen V3-Screens katalogisiert (Screenshots in `docs/06_Frontend/Screenshots/`)
  - [x] Inkonsistenzen in Spacing, Typografie und Farbgebung identifiziert
  - [x] Offene UX-Probleme und fehlende Empty States dokumentiert
  - [x] Issue-Liste für Sprint B vorbereitet

### Sprint B (Teilweise) — Wireframes erstellt

- [x] **B-1 Wireframes** | Editier-Formulare (AlertDialog vs. dedizierter Screen)
  - [x] Entscheidungsgrundlage erarbeitet: Wann AlertDialog, wann Fullscreen-Edit?
  - [x] Wireframes für beide Varianten erstellt (Reiter-Edit, Pferd-Edit als Beispiele)
  - [x] Ergebnis: `docs/06_Frontend/Guidelines/Editier-Formulare_Dialog-vs-Fullscreen_v1.md`
  - [ ] **Finale Entscheidung dokumentieren und als Design-Richtlinie festschreiben** (Review durch 🎨 Frontend
    ausstehend)

- [x] **B-2 Wireframes** | Bewerb anlegen mit Abteilungs-Logik
  - [x] Dialog-Flow: Bewerb-Grunddaten → Abteilungs-Vorschlag → Bestätigung
  - [x] CSN-C-NEU Pflicht-Teilung: Visuelle Darstellung der automatischen Vorschläge
  - [x] Abteilungs-Typ-Auswahl: `SEPARATE_SIEGEREHRUNG` vs. `ORGANISATORISCH` verständlich gestaltet
  - [x] Ergebnis: `docs/06_Frontend/Wireframes/Bewerb_anlegen_Abteilungs-Logik_v1.md`

- [x] **B-3 Wireframes** | Veranstaltungs-Kassa
  - [x] Gesamt-Saldo-Ansicht: Teilnehmer mit offenen Beträgen aus mehreren Turnieren
  - [x] Zahlvorgang-Dialog: Eine Zahlung, Aufteilung auf Turniere sichtbar
  - [x] Rechnungsvorschau: Zwei separate Rechnungen je Turnier als Tab
  - [x] Ergebnis: `docs/06_Frontend/Wireframes/Kassa_Veranstaltung_v1.md`

---

## 🔴 Sprint B — Offen (höchste Priorität)

- [ ] **B-1 Abschluss** | Finale Design-Entscheidung Editier-Formulare
  - [ ] Review durch 🎨 Frontend Expert durchführen
  - [ ] Entscheidung (AlertDialog vs. Fullscreen) als verbindliche Richtlinie dokumentieren

- [ ] **B-4** | Empty States für alle Listenansichten
  - [ ] Liste aller Screens mit möglichen leeren Zuständen erstellen
  - [ ] Illustrations-Konzept oder Icon + Text für Empty States definieren
  - [ ] Konsistente Vorlage als Composable umsetzen (z. B. `MsEmptyState`)

---

## 🟠 Sprint C — Priorität 2 (nächste Woche)

- [ ] **C-1** | Wireframes aus Sprint B in Compose umsetzen
  - [ ] Editier-Dialog / Fullscreen-Edit gemäß finaler Entscheidung (B-1)
  - [ ] Bewerb-Anlegen-Dialog mit Abteilungs-Logik (B-2)
  - [ ] Kassa-Screen (B-3)

- [ ] **C-2** | Design-System konsolidieren
  - [ ] Farb-Palette in `MaterialTheme` / `Theme.kt` vereinheitlichen
  - [ ] Typografie-Skala definieren (Überschriften, Body, Labels, Captions)
  - [ ] Wiederverwendbare Komponenten als Composables extrahieren (Cards, Badges, Chips)

- [ ] **C-3** | Abteilungs-Ansicht: Startliste und Ergebnisliste
  - [ ] Wireframe: Startliste einer Abteilung (Startnummer, Reiter, Pferd, Verein)
  - [ ] Wireframe: Ergebnisliste einer Abteilung (Platz, Reiter, Pferd, Ergebnis)
  - [ ] Wireframe: Ranglisten-Zusammenführung bei `ORGANISATORISCH`

> ⏸️ **Web-App / PWA Design** — Nach Desktop-MVP; Anforderungen noch nicht definiert

---

## 📌 Abhängigkeiten

| Warte auf                           | Von wem       | Betrifft                 |
|-------------------------------------|---------------|--------------------------|
| Domänen-Modell (Kassa, Abteilung) ✅ | 🏗️ Architect | B-3 Kassa-Wireframes ✅   |
| ViewModel-Struktur ✅                | 🎨 Frontend   | B-1 Finale Entscheidung  |
| Meine Wireframes (B-1, B-3)         | 🎨 Frontend   | B-3, B-4 Implementierung |
| Meine Wireframes (B-2)              | 🎨 Frontend   | Bewerb-Anlegen-Dialog    |

---

## 💡 Empfehlungen (nach Priorität)

1. **B-1 Finale Entscheidung** — Frontend wartet auf die Richtlinie für Editier-Formulare; ohne sie können keine
   konsistenten Edit-Dialoge implementiert werden.
2. **B-4 Empty States** — Alle Listenansichten zeigen aktuell nichts bei leerem Zustand; schlechte UX für neue Nutzer
   und beim ersten Start.
3. **C-2 Design-System** — Frühzeitige Konsolidierung verhindert kostspielige Nacharbeit; am besten parallel zu C-1
   erledigen.