B2B-Buchungsportal · Reisevertrieb · KI-gestützter Prototyping-Workflow · 2026
Buchen und verwalten,
in einem System.
Alleiniger Product Designer für ein B2B-Portal, über das Reisebüros Reisen suchen, buchen und verwalten. Den Weg vom Design zum abgenommenen Stand habe ich über einen KI-gestützten Workflow umgebaut: aus einer eigenen Figma-Bibliothek entstand via MCP klickbares HTML in rund 90 % Design-Treue – bedienbar dort, wo ein statisches Figma an Grenzen stößt. B2B-System für einen Reiseveranstalter (NDA).
01 — Kontext
Ein Portal für
den ganzen Vertrieb.
Ein Reiseveranstalter wollte den Vertrieb über Reisebüros in eine eigene B2B-Plattform holen. Über das Portal suchen Reisebüros Reisen, buchen Kabinen und Kontingente, stornieren, buchen um und vergeben Rabatte und Gutscheine. Zwei Kernbereiche tragen das System: die Reise-Suche – finden und buchen – und die Verwaltung – Buchungen, Kunden und Rechnungen steuern.
Als ich dazukam, war ein erster Designstil bereits angelegt und vom Kunden freigegeben. Er sollte erhalten bleiben. Meine Aufgabe begann also nicht bei „wie sieht es aus“, sondern bei „wie wird daraus ein tragfähiges, konsistentes System – und wie kommt es schnell genug zum Kunden“.
02 — Problem
Statische Screens
beweisen nichts.
Am Anfang stehen grobe Skizzen: ein schneller Papier-Wireframe der Reise-Suche mit Navigation und einer ersten Preis-Matrix. Gut genug, um die Struktur zu klären – aber kein Beleg dafür, dass das System im Alltag trägt.
Der Weg von Konzept zu abgenommenem Design lief danach über statische Figma-Screens und lange Abstimmungsrunden. Bei laufenden Änderungen drohte er sich über Monate zu ziehen.
Und das Entscheidende ließ sich in Figma gar nicht prüfen: Tabellenlogik, Filter, Pop-ups, ein- und ausfahrende Seitenpanels, das Zusammenspiel der Zustände, die Ruhe der Übergänge. Genau daran entscheidet sich aber, ob ein Buchungs-Interface im Alltag trägt – nicht an einem hübschen Standbild.
03 — Rolle & Prozess
Viele Ideen,
eine Regie.
Alleiniger Designer, verantwortlich für den gesamten Weg von Konzept bis Handoff. Ich habe den vorhandenen Stil in ein echtes Komponenten-System überführt, den Prototyping-Workflow aufgebaut und die Iterationen mit Projektleitung, Entwicklung und Kunde koordiniert.
Ideen kamen aus allen Richtungen – von mir, der Projektleitung, dem Kunden, der Entwicklung, die Dinge aus technischer Sicht anpasste. Zusammengeführt, abgewogen und in eine konsistente Lösung dirigiert habe ich.
„Sechs Jahre IT-Infrastruktur zahlen hier direkt ein: Ich baue keinen Prototyp, den die Entwicklung wegwerfen muss, sondern einen, der auf echtem Frontend-Code steht.“
04 — Design-System
Erst das System,
dann das Tempo.
Der bestehende Stil war ein Anfang, aber keine Basis. Also habe ich ihn auseinandergenommen und zu einer echten Bibliothek gemacht: Farb- und Text-Tokens, eine Typo-Skala, Abstände und Radien – und Komponenten in allen Zuständen. Buttons mit Hover, Aktiv, Fokus und Disabled; Eingabefelder mit Fokus-, Fehler- und Erfolgs-Status; dazu Tabs, Tags, Schalter, Avatare und Diagramme. Alles dokumentiert als eigene Library-Datei und zur Single Source of Truth erklärt.
Das war kein Selbstzweck. Nur ein sauber strukturiertes System lässt sich verlässlich weiterverarbeiten – von Hand wie maschinell. Diese Bibliothek wurde die Grundlage für alles, was danach kam: Sie war die Voraussetzung dafür, dass der KI-Workflow im nächsten Schritt überhaupt konsistente Ergebnisse liefern konnte.
05 — KI-Workflow
Den Prototyp nicht malen,
sondern bauen.
Der eigentliche Hebel: Ich habe die Figma-Komponenten über MCP an die Bibliothek angebunden und daraus klickbares HTML erzeugt – rund 90 % Design-Treue, aber echt bedienbar. Damit ließ sich prüfen, was in Figma nur behauptet wird: Pop-ups, ausfahrende Seitenpanels, Filter, Tabellenverhalten, Übergänge.
Der erste Versuch trug – also habe ich ihn der Projektleitung gezeigt: schnell, testbar, überzeugend. Wir haben den Weg übernommen. Ab da lief es im Takt: Hypothese am lebenden Prototyp testen, an die Entwicklung geben, an den Kunden schicken, Feedback einarbeiten. Aus Wochen wurden Tage.
Wichtig: kein „prompt and pray“. Ich habe Regeln definiert und einen prüfenden Agenten gebaut, der Abweichungen vom Stil abfängt. Fehler von der KI gab es trotzdem – klein, ein vergessener Abstand, eine nicht ersetzte Schriftgröße. Der Rahmen fing das Grobe, den Rest habe ich kontrolliert nachgezogen. Der Unterschied liegt nicht im Prompten, sondern im System darunter und in der Kontrolle darüber.
„Der Prototyp war kein Bild vom Produkt. Er war eine erste, bedienbare Version davon.“
06 — Entscheidungen
Die richtige Zahl
zuerst.
Reise-Suche: die Preis-Matrix
Ein Reisebüro entscheidet über Kabinenkategorie und Preis in einem Blick. Also eine Preis-Matrix, die Kabinenkategorie gegen Tarif stellt – die relevante Information zuerst, nicht verschachtelt in Detailmasken. Verfügbarkeit, bester Preis und Preistrend stehen direkt in der Zeile; Gutscheine und Rabatte kamen auf Kundenwunsch dazu, sauber in die Buchungsstrecke integriert statt drangeflanscht.
Verwaltung: die Provision nach vorn
In der Verwaltung zählt für das Reisebüro vor allem eine Zahl: die eigene Provision. Die habe ich nach vorne geholt – nicht drei Klicks tief, sondern direkt in der Übersicht, neben Status und Zahlungsstand. Darüber eine kompakte Analyse-Ebene: Buchungsvolumen, Provision und Buchungsstatus als Diagramm. Was der Nutzer geschäftlich am dringendsten braucht, gehört an die erste Stelle. Diese Priorisierung habe ich mit dem Kunden erarbeitet und verteidigt.
Ein Verhalten für alle Bereiche
Suche, Buchungen, Kunden und Rechnungen teilen dieselbe Tabellenlogik, dieselben Filter, denselben visuellen Stil. Wer den einen Bereich beherrscht, versteht den anderen sofort – Konsistenz, die aus dem gemeinsamen System kommt, nicht aus doppelter Arbeit.
07 — Interface
Ein System,
viele Bereiche.
Ausgewählte Screens aus dem klickbaren Prototyp. White-label, alle Daten fiktiv.
08 — Ergebnis
In Tagen statt
Monaten am Kunden.
Beide Kernbereiche – Suche und Verwaltung – wurden vollständig neu aufgebaut. Der Kunde hat den klickbaren Prototyp getestet, abgenommen und die Entwicklung beauftragt: Budget freigegeben, Vertrag unterschrieben, Umsetzung startet im Herbst. Der KI-gestützte Prototyping-Weg wurde intern als Methode übernommen. Statt Monaten in Figma stand in gut einem Monat – neben anderen Aufgaben – ein bedienbarer, mit dem Kunden validierter Stand.
„Rückmeldung des Kunden: genau so soll sich das Portal anfühlen.“ — Projektleitung, Kundenseite
09 — Reflexion
Ehrlich zu
den Grenzen.
Getestet wurde mit dem Kunden, nicht mit den Endnutzern – kein Reisebüro-User-Test, keine formalen Metriken. Und ein KI-Workflow ist kein Selbstläufer: Er braucht ein sauberes System darunter, klare Regeln darüber und jemanden, der prüft.
Die Stärke dieses Projekts liegt nicht im Zaubertrick, sondern im Handwerk – ein reproduzierbarer Weg, der aus Design in Tagen einen bedienbaren, mit dem Kunden validierten Stand macht. Dass die Methode danach im Team weiterlebte, ist das belastbarste Signal, das dieser Kontext hergibt.
„Nicht schneller prompten – besser dirigieren.“