Prepaid Management · B2B · Kreuzfahrt-Operations · 2026
Prepaid-Verwaltung
für die Flotte
Alleiniger Product Designer – von einer 200-Spalten-Excel zu einer Weboberfläche, die die Crew an Bord ohne Einarbeitung bedient. B2B-System für ein großes europäisches Kreuzfahrtunternehmen (NDA).
01 — Kontext
Ein komplexes System
hinter jeder Reise.
Ein großes europäisches Kreuzfahrtunternehmen verwaltet für jede Reise große Mengen vorab gebuchter Bordleistungen – Spa, Restaurants, Ausflüge, Bordguthaben. Vor der Reise setzt das Unternehmen einen Umsatz-Forecast. Während der Reise weicht der Ist-Zustand laufend davon ab: Gäste erscheinen, stornieren, verschieben. Parallel läuft ein Verkaufsziel für Zusatzleistungen, dessen Fortschritt jederzeit ablesbar bleiben muss.
Zwei Nutzergruppen arbeiten im System: die Crew an Bord sieht nur ihre eigene Reise und ihren Bereich; Manager an Land sehen die gesamte Flotte, steuern übergreifend und ziehen Reports.
02 — Problem
Was sich ändern
musste.
Bis dahin lief alles über Excel-Tabellen mit rund 200 Spalten, verteilt auf mehrere Systeme – ohne gemeinsame Datenbasis.
03 — Rolle & Prozess
Allein verantwortlich –
vom Stack bis zum Prototyp.
Alleiniger Designer mit voller Verantwortung für UX, UI und Design-System. Ausgangslage: eine grob gebaute Demo aus der Entwicklung (funktional, ohne Designqualität) und Balsamiq-Wireframes eines Entwicklers, der eine Idee fürs Haupt-Dashboard hatte, sie aber nicht in Figma umsetzen konnte.
- Ohne direkten User-Zugang gearbeitet. Kein Kontakt zu den Power-Usern – stattdessen präzise schriftliche Tabellen-Anforderungen plus enge Abstimmung mit Projektleitung und Entwicklung.
- Erst den Stack analysiert, dann gezeichnet. Frontend-Framework und seine Grenzen verstanden, bevor der erste Screen entstand.
- Foundations aufgebaut und nach CSS exportiert. Typografie, Farben, Spacing, Radien – dokumentiert, daraus ein Komponenten-Set und ein UI-Kit als gemeinsame Quelle.
- Edge- und Corner-Cases durchgespielt. Mit Projektleitung und Entwicklung: z. B. Mehrfachauswahl bei gleichzeitigem Statuswechsel, widersprüchliche Zustände.
- Alle Szenarien, Zustände und Pop-ups gezeichnet. Dazu eine untere Summenleiste ergänzt, die es vorher nicht gab.
- Interaktive Figma-Prototypen. Nach dem Client-Review Freigabe und eine Iterationsrunde an Tabellen und Feldern.
„Sechs Jahre IT-Infrastruktur zahlen hier direkt ein: Ich spreche die Sprache der Entwicklung und entwerfe nichts, was sich nicht bauen lässt.“
04 — Design-System
Erst der Stack,
dann die Screens.
Der schnelle Weg wäre gewesen, die vorhandenen Konzept-Ideen in Figma „schön zu machen“. Gebaut wurde aber auf einem konkreten Frontend-Framework mit eigenem Raster und eigenen Komponenten-Grenzen. Also zuerst der Stack: Grenzen analysiert, dann eine Token-Struktur entlang des Frameworks aufgebaut, nach CSS exportiert und ein Komponenten-Kit als Single Source of Truth erstellt.
Der Effekt: Das Design überlebt den Handoff. Die Entwicklung baut schneller, das Interface bleibt konsistent, und am Ende steht kein „so lässt sich das nicht bauen“.
05 — Entscheidungen
Dichte, die man
aushalten kann.
200 Felder – nur das Wesentliche sichtbar
Alle rund 200 Felder mussten verfügbar bleiben – alles gleichzeitig zu zeigen hätte dieselbe unbenutzbare Datenwand ergeben. Also standardmäßig nur die entscheidenden Spalten; alles Weitere über Filter und Spaltensteuerung bei Bedarf zuschaltbar. Die Standardansicht ist in Sekunden erfassbar, ohne dass Power-User ein Feld verlieren.
Das Status-System als Kern der Bedienung
Die gesamte tägliche Arbeit besteht aus Statuswechseln – Pending, Active, Completed, In Progress, Absent, Voided, Reimbursed, Reversed, Deferred, Config Error. Reihenfolge, Farbe und Klarheit entscheiden über Tempo und Fehlerquote. Status-Priorität erarbeitet, farblich codiert, Darstellungsvarianten mit der Entwicklung getestet und die kritischen Interaktionen sauber abgefangen. Dazu eine untere Summenleiste, die die Kernzahlen – nicht abgeglichen, zur Freigabe offen, Ziel gegen Ist – dauerhaft im Blick hält.
Mehrfachauswahl bei gleichzeitigem Statuswechsel
Ein Edge-Case aus der Zusammenarbeit mit der Entwicklung: Werden mehrere Zeilen mit unterschiedlichem Status gleichzeitig ausgewählt, zeigt die Seitenleiste jede betroffene Statusgruppe einzeln mit Anzahl – statt eines mehrdeutigen Sammelzustands. Nur eindeutig erlaubte Zielstatus bleiben wählbar, alles andere ist sichtbar deaktiviert.
06 — Interface
Jeder Screen,
eine Quelle der Wahrheit.
Ausgewählte Screens aus dem gelieferten System. White-label, Kundendaten ersetzt.
07 — Ergebnis
Ohne Einarbeitung
im Live-Betrieb.
Die Crew bediente das System ohne Einarbeitung – von den Nutzern direkt bestätigt. Auf einem Schiff zählt jede Minute Personalzeit; genau das war hier die relevante Messgröße. Der Kunde beauftragte Folge-Iterationen an Tabellen und Feldern, das System ist inzwischen auf mehreren Schiffen im Einsatz und an das bordseitige Abrechnungssystem für Export und Reporting angebunden.
„Rückmeldung aus der Bordleitung: klar strukturiert, im Alltag einfach zu bedienen, spürbar weniger Reibung in der täglichen Abrechnung.“ — Chief Purser, Pilotschiff
08 — Reflexion
Ehrlich zu
den Grenzen.
Kein direkter Zugang zu den Endnutzern: gearbeitet wurde mit schriftlichen Anforderungen und enger Abstimmung mit Projektleitung und Entwicklung, nicht mit klassischer User Research. Und es wurden keine formalen Metriken erhoben.
Die Stärke des Projekts liegt woanders: in der Sorgfalt bei Edge-Cases und in der engen Partnerschaft mit der Entwicklung. Dass die Crew ohne eine Minute Schulung sofort produktiv war, ist das belastbarste Signal, das dieser Kontext hergibt.
„Ein System, das sich ohne Erklärung bedienen lässt, ist der ehrlichste Usability-Test.“