Die meisten Customer Experiences scheitern nicht am Design — sie scheitern daran, dass nichts sie zusammenhält. Ich baue die Struktur, die das ändert: Journeys, die auf den Nutzer ausgerichtet sind. Systeme, die mit dem Unternehmen wachsen.
Die Grundlage dafür, dass Qualität und Wachstum zusammen skalieren.
Die meisten Unternehmen bauen Touchpoints — und wundern sich, warum die Experience nicht zusammenwächst. Der Unterschied: Journeys denken vom Nutzer her, nicht vom Kanal. Was danach entsteht, ist kein Konzept — sondern ein System, das damit Schritt hält.
Ob man gerade zum ersten Mal von einem Produkt hört oder kurz vor dem Kauf steht – in jeder Phase gibt es andere Bedürfnisse. Der richtige Moment ist entscheidend.
Informationen, Handlungsoptionen, Self-Services. Priorisiert danach, was in dieser Situation tatsächlich hilft. Keine unnötigen Hürden. Kein Gated-Content, der richtige Inhalt ist entscheidend.
Web, App, E-Mail oder Chat – Lösungen werden so gedacht, dass sie auf verschiedenen Kanälen funktionieren. Da wo es ihre Kunden brauchen.
der Kunden verlassen dich nach einer einzigen schlechten Erfahrung. Journey-Thinking dreht das um: bis zu 73% höhere Zufriedenheit, 5–10% Umsatzplus. (McKinsey, 2016)
Barrierefreiheit war kein Feature. Sie war der Ausgangspunkt. Ein vollständiger eShop-Relaunch, eine neue Los-Konfiguration, Jahre der Weiterentwicklung. 300 Lose pro Minute in der Spitze. Details
Eine modulare Kantinenlösung, neun Kundengruppen und Bedürfnisse, optimierte Services — neu gedacht, vereinheitlicht, spürbar besser.
Markenidentität erhalten, Experience modernisiert. Navigation neu aus Archetypen-Perspektive gedacht. Für alle Viewports und eCommerce optimiert.
Ein durchdachtes White-Label-Fundament – token-basiert, sofort einsatzbereit, beliebig individualisierbar. Schneller loslegen, früher liefern, später optimieren statt wochenlang Variablen-Strukturen debattieren.
Jede Änderung an Farbe, Schrift oder Komponente wirkt sich sofort auf alle Kanäle aus. Kein manuelles Nachziehen, keine Inkonsistenzen, kein Versionswirrwarr zwischen Design und Entwicklung. Ein System, das mit dem Produkt wächst — statt den Launch zu bremsen.
Ich baue Design Systems, mit dem Ziel Styles dynamisch auszuliefern: CD-konform, kanalunabhängig, ohne manuellen Overhead. Figma und Codebase bleiben synchron. Was sich im System ändert, landet automatisch im Frontend.
Stelle dir vor, je nach Kontext, müssten Stile geändert werden. Oder neue CD konforme Elemente dynamisch erstellt. Automatisch, nach klaren Regeln.
Ich liefere nicht nur Designs — ich denke in der Verbindung von Design Tokens und Frontend Code. Nicht weil ich alles selbst bauen will, sondern weil ich überzeugt bin, dass nur so ein wirklich lebendiges, synchrones System entsteht. Eines, das sich anpassen lässt ohne jedes Mal von vorne anzufangen.
Dieser Ansatz ist kein Zufall. Er ist eine Antwort auf das, was kommt: Omnichannel, KI, Hyperpersonalisierung. Journeys, die sich verändern. Systeme, die mithalten müssen.
Eine Journey ist nur so gut wie das System dahinter. Inhalte, Services und Erlebnisse müssen dort verfügbar sein, wo sie gebraucht werden — im richtigen Moment, auf dem richtigen Kanal. Nicht als Einmallieferung, sondern als lebendiges System das mit dem Nutzer mitwächst.
Der Ansatz: Content Hubs und Self-Services zentral organisiert, kanalunabhängig ausgespielt. Eine konsistente Experience über den gesamten Customer Lifecycle — getragen von einem Headless-System auf Basis eines token-basierten, dynamischen Design Systems.
Unternehmen, die Experience strategisch aufbauen, wachsen schneller, binden Kunden länger und skalieren effizienter. Wenn du ein Team aufbaust, das Experience von Anfang an zusammendenkt — ich bin dabei.
Kurze Antworten auf die Fragen, die am häufigsten kommen – damit du weißt, was dich erwartet und was ich mitbringe.
Jein – ich kann Frontend-Code schreiben, Design Systems aufbauen und Token-Strukturen zwischen Figma und Codebase synchronisieren. Ich bin kein Full-Stack-Entwickler, aber ich spreche die Sprache der Entwickler und schließe die Lücke zwischen Design und Implementierung.
Fünf Prinzipien, die in der Praxis den größten Unterschied machen:
Semantische Klarheit: Aktionen, Zustände und Felder müssen im DOM eindeutig beschriftet sein – nicht nur visuell erkennbar.
Vorhersehbare Flows: Agenten brauchen stabile, konsistente Pfade. Dynamische UIs, die sich je nach Kontext stark verändern, erhöhen die Fehlerrate.
Explizite Fehlerbehandlung: Fehlerzustände müssen maschinenlesbar kommuniziert werden – nicht nur als rote Umrandung.
Strukturierte Inhalte: Headings, Landmarks und ARIA-Attribute sind nicht nur Accessibility-Pflicht – sie sind die Navigation für Agenten.
Klare Abbruchpunkte: Ein Agent muss wissen, wann eine Aufgabe erfolgreich abgeschlossen ist – und wann nicht.
Überall dort, wo automatisierte Prozesse auf digitale Oberflächen treffen: B2B-Software, Self-Service-Portale, Checkout-Flows, CRM-Systeme, Support-Hubs, interne Tools und komplexe Konfigurationsstrecken.
Kurz: Wenn dein Produkt heute von Menschen bedient wird – und morgen von Agenten mitbedient werden soll – braucht es Agentic UX. Das ist keine ferne Zukunft. Unternehmen wie SAP, Salesforce und ServiceNow bauen ihre Plattformen gerade aktiv darauf um.
Praxisbeispiel: Ein Beschaffungsprozess, der heute 12 Klicks braucht, wird morgen von einem KI-Agenten delegiert. Wenn die Oberfläche dafür nicht gebaut ist, scheitert die Automatisierung – nicht die KI.
MCP – das Model Context Protocol – ist ein offener Standard, der KI-Agenten eine strukturierte Schnittstelle zu externen Systemen gibt: Datenbanken, Tools, APIs, aber auch digitale Oberflächen und Inhalte. Entwickelt von Anthropic, inzwischen von den meisten großen KI-Anbietern unterstützt.
Für Agentic UX bedeutet das: MCP ist die Brücke zwischen dem Agenten und deinem Produkt. Während Agentic UX das Design-Denken beschreibt – wie müssen Flows, Strukturen und Inhalte gebaut sein, damit ein Agent sie verlässlich nutzen kann – ist MCP ein konkreter technischer Baustein, der genau das ermöglicht.Praxisbeispiel: Ein KI-Assistent, der über MCP auf ein CRM zugreift, braucht klar definierte Aktionen, eindeutige Datenpunkte und vorhersehbare Zustände. Wenn das Produkt darunter strukturell schwach ist – inkonsistente Benennung, fehlende semantische Marker, unklare Fehlerzustände – scheitert die Integration. Nicht wegen MCP. Sondern wegen fehlendem Agentic UX.
Kurz gesagt: MCP definiert, wie ein Agent kommuniziert. Agentic UX definiert, womit er kommuniziert. Beides braucht einander.
Ja, konkret. Bei Aktion Mensch habe ich einen vollständig barrierefreien eShop konzipiert – inklusive barrierefreier Los-Konfiguration. Barrierefreiheit ist für mich kein Nachgedanke, sondern Teil des Konzepts von Anfang an.
Eine User Journey beschreibt den Weg, den ein Nutzer mit einem Produkt oder Service zurücklegt – vom ersten Kontakt bis zum Ziel. Sie zeigt, wo Menschen abspringen, was sie brauchen und wann. Für Unternehmen bedeutet das: weniger Streuverlust, mehr Conversions – weil Inhalte und Funktionen genau dort auftauchen, wo sie gebraucht werden.
Ein Design System ist eine gemeinsame visuelle Sprache für ein digitales Produkt – Farben, Schriften, Buttons, Komponenten – alles an einem Ort definiert und für alle Teams zugänglich. Der praktische Nutzen: Entwickler und Designer arbeiten schneller, Änderungen wirken sich automatisch überall aus, und das Produkt sieht auf jedem Kanal konsistent aus. Kein Copy-Paste mehr, keine Inkonsistenzen.
