# Design: Konzeption vor Farbe

Die meisten Gründer-Webapps scheitern nicht an hässlichem Design, sondern an unklarem. Wer die App benutzen soll, was er als Erstes sieht, ob er sich anmelden muss bevor er etwas tun darf, ob sein Handy reicht oder ob er einen Laptop braucht: das sind Design-Entscheidungen, lange bevor du an Farbpaletten denkst.

Dieses File führt dich durch die Konzeption. Farbe und Komponenten kommen danach, nicht davor.

## Schritt 1: Nutzer-Rollen festlegen

Wer benutzt deine App? Sei spezifisch. Nicht "alle", sondern zum Beispiel "Cafébesitzer mit 10 bis 30 Sitzplätzen, die keine Lust auf Reservierungssoftware-Abos haben".

Für jede Rolle drei Fragen:
- Was ist seine Hauptaktion? (eine, nicht fünf)
- Wann benutzt er die App? (täglich, wöchentlich, einmalig)
- Auf welchem Gerät? (Handy unterwegs, Laptop im Büro, Tablet an der Theke)

Beispiel Buchungs-App:

| Rolle | Hauptaktion | Frequenz | Gerät |
|---|---|---|---|
| Gast | Tisch buchen | Einmalig pro Besuch | Handy |
| Cafébesitzer | Buchungen sehen, Tische sperren | Mehrmals täglich | Tablet an der Theke, Laptop im Büro |

Das Ergebnis: Gast-Sicht muss mobil perfekt sein, Betreiber-Sicht darf Tablet/Desktop sein. Das beeinflusst alle nachfolgenden Entscheidungen.

## Schritt 2: Self-Service oder Setup-Modell

Zwei Welten:

**Self-Service**: Nutzer registriert sich selbst, legt los, zahlt vielleicht später. Klassisch für SaaS, Communities, öffentliche Tools.

**Setup-Modell**: Du oder dein Team richten den Account ein, gibst Zugang, der Kunde nutzt. Klassisch für B2B-Tools, interne Software, betreute Pilotkunden.

Im Prototyp ist Self-Service oft Overkill. Wenn du in der ersten Phase nur fünf Pilot-Kunden hast, mach Setup-Modell: du legst deren Account an, schickst Login-Daten per Mail. Spart dir Registrierung, Email-Verification, Onboarding-Wizard.

Ab welcher Größe lohnt Self-Service:
- Unter 50 Kunden: Setup. Persönlicher Kontakt, schneller Lerneffekt.
- 50 bis 500: Self-Service mit Magic-Link oder OAuth.
- 500+: Self-Service mit Passwort + 2FA, plus Setup-Variante für Enterprise.

## Schritt 3: Die fünf Onboarding-Fragen

Wenn ein Nutzer zum ersten Mal die App öffnet, was muss er wissen, einstellen, eingeben, bevor er den Hauptnutzen hat?

Fünf typische Fragen:
1. Wer bist du? (Name, Email)
2. Was ist dein Kontext? (Firma, Rolle, Sprache)
3. Mit wem arbeitest du? (Team-Member einladen)
4. Welche Daten bringst du mit? (Import, Verknüpfung mit anderen Tools)
5. Was willst du als Erstes tun? (Direktlink zur Hauptaktion)

Pro-Tipp: nimm Frage 5 immer rein. Selbst wenn alles andere übersprungen wird, will der Nutzer wissen, wo es losgeht.

Im Prototyp reicht oft Frage 1. Email rein, Magic-Link bekommen, direkt zur Hauptaktion. Alles andere ist Premium-Onboarding für später.

## Schritt 4: Mobile-First-Entscheidung

Frag dich ehrlich: wer benutzt das auf welchem Gerät?

| Hauptnutzung | Strategie |
|---|---|
| Mobile dominant (>70%) | Mobile-First. Layout in einer Spalte, Buttons groß, keine Hover-Effekte als kritische Interaktion. |
| Desktop dominant (>70%) | Desktop-First mit responsive Fallback. Tabellen, Multi-Spalten-Layouts, Sidebar. |
| Beides etwa gleich | Two-Mode. Sidebar auf Desktop, Hamburger auf Mobile. Forms gleich. Tabellen werden mobil zu Cards. |

Wichtig: "Responsive Webapp" heißt nicht automatisch "auf Handy gut". Du musst es testen. Öffne jeden Bildschirm während der Entwicklung im Browser-Devtools im iPhone-Modus, nicht erst am Ende.

Standard-Breakpoints (Tailwind):
- Mobile: bis 640px (`sm:` greift ab da)
- Tablet: bis 1024px (`lg:`)
- Desktop: ab 1024px

Faustregel: alles unter 1024px ist "mobil-like" und sollte einspaltig und Touch-tauglich sein.

## Schritt 5: Tonalität

Wie spricht deine App mit dem Nutzer?

| Stil | Beispiel |
|---|---|
| Formell (Sie, vollständige Sätze) | "Ihre Reservierung wurde erfolgreich gespeichert." |
| Locker (Du, kurze Sätze) | "Gespeichert. Bis später." |
| Sachlich (neutral, Verb-betont) | "Reservierung angelegt." |
| Persönlich (Vorname, Emoji) | "Cool Jana, dein Tisch wartet." |

Empfehlung Prototyp: sachlich. Keine Anrede, kein Emoji, kurze Bestätigungen. Spart dir Endlos-Diskussionen über Wording. Du kannst später lockerer werden, wenn du Persona und Markenstimme entwickelt hast.

Eine Sache durchziehen: wenn du an einer Stelle "Du" sagst und an anderer "Sie", merkt das jeder. Konsistenz schlägt Stil.

## Schritt 6: Layout-Skelett

Bevor du Komponenten baust, skizziere die Hauptseiten als Boxen-Diagramme. Papier reicht.

Drei Standard-Skelette:

**Public-Layout** (Login, Landingpage, Buchungsformular für Gäste)
```
┌─────────────────────────────┐
│  Logo                  ☀️/🌙 │
├─────────────────────────────┤
│                             │
│      [Inhalt zentriert]     │
│                             │
└─────────────────────────────┘
```

**App-Layout mit Sidebar** (interne Tools, Dashboards)
```
┌──────┬──────────────────────┐
│ Logo │  Page-Titel  [Action]│
├──────┼──────────────────────┤
│ Nav  │                      │
│ Nav  │   [Cards / Content]  │
│ Nav  │                      │
├──────┤                      │
│ User │                      │
└──────┴──────────────────────┘
```

**Mobile-First-Layout** (Self-Service-Apps, Konsumenten)
```
┌─────────────────────┐
│ ☰ Logo         👤   │
├─────────────────────┤
│                     │
│   [Eine Spalte]     │
│   [Card]            │
│   [Card]            │
│                     │
└─────────────────────┘
```

Wähle eines. Mische sie nicht in einer App.

## Schritt 7: Farbpalette (zuletzt)

Erst jetzt zu Farben. Drei Variablen reichen für den Prototyp:

- **Background**: hell (Light Mode) oder dunkel (Dark Mode). Hellgrau `#f7f7f9`, Dunkel `#0f172a`.
- **Surface**: Cards und Inputs. Weiß auf hell, dunkelgrau auf dunkel.
- **Accent**: deine Markenfarbe. Ein Blau, Lila, Grün. Nicht Rot (Rot ist für Fehler reserviert).

Plus drei semantische Farben:
- Success: Grün (`#16a34a`)
- Warn: Gelb/Orange (`#d97706`)
- Danger: Rot (`#dc2626`)

Definiere alle als CSS Custom Properties (`--accent`, `--bg`, etc.), nie als Hex-Wert direkt im Code. Sonst kannst du später kein Dark Mode bauen, ohne alles anzufassen.

```css
:root {
  --bg: #f7f7f9;
  --surface: #ffffff;
  --fg: #0f172a;
  --accent: #2563eb;
  --border: #e5e7eb;
}
:root[data-theme="dark"] {
  --bg: #0f172a;
  --surface: #1e293b;
  --fg: #f1f5f9;
  --accent: #60a5fa;
  --border: #334155;
}
```

In Tailwind v4 verwendest du sie via `bg-[var(--bg)]` oder im Stylesheet als `background: var(--bg)`.

## Schritt 8: Komponenten-Klassen statt Komponenten-Library

Statt 50 verschiedene Buttons im Code zu haben, definiere eine Hand voll Klassen einmal in globals.css:

```css
.btn-primary {
  height: 38px;
  padding: 0 16px;
  border-radius: 8px;
  background: var(--accent);
  color: white;
  font-weight: 500;
}
.card {
  background: var(--surface);
  border: 1px solid var(--border);
  border-radius: 12px;
  padding: 20px;
}
.input {
  height: 38px;
  padding: 0 12px;
  border: 1px solid var(--border);
  border-radius: 8px;
}
```

Dann im JSX: `<button className="btn-primary">Speichern</button>`. Fertig. Keine UI-Library nötig, keine 200kB JavaScript zusätzlich, alles konsistent.

## Anti-Patterns

- Mit der Farbpalette anfangen, bevor die Pages skizziert sind.
- Mehrere Layouts in einer App vermischen.
- Komponenten-Library installieren, dann 80 Prozent davon überschreiben.
- Nutzer-Rollen nicht durchdenken und am Ende drei UI-Modi haben, die alle halb fertig sind.
- Mobile-Optimierung als letzten Schritt planen. Sie wird nie kommen.

## Nächster Schritt

Skizziere für deine App: Rollen, Hauptaktionen, Geräte, Layout-Skelett. Erst dann lass dir den Agent das erste Layout bauen. Lies parallel webapp-techstack.md für die technische Umsetzung.