Unsicherheit in Produktrichtung verwandeln.

Die Herausforderung

Dieses Programm begann nicht mit KI. Es begann mit den Menschen, die Enterprise-Accounts betreuten, und den breiteren Teams, die sie unterstützten – überfordert von fragmentierten Informationen.

Kritische Alerts waren über mehrere interne Systeme verstreut, von denen jedes zu unterschiedlichen Zeitpunkten unterschiedliche Informationen anzeigte, mit wenig Konsistenz darin, wie Arbeit tatsächlich priorisiert werden sollte. Nutzer:innen stießen häufig auf widersprüchliche Informationen, wenn sie zwischen operativen Tools und Datenquellen wechselten, Berichte manuell verglichen und entschieden, was zuerst Aufmerksamkeit verdiente.

Die Geschäftsführung glaubte, dass intelligente Unterstützung helfen könnte, doch es gab keine Belege dafür, dass dies die richtige Antwort war, was sie tatsächlich leisten sollte, oder ob die Menschen ihr genug vertrauen würden, um sie anzunehmen.

Anstatt eine Engineering-Investition auf bloßer Annahme zu tätigen, brauchten wir zunächst Evidenz.

Die Aufgabe war größer, als nur eine Oberfläche zu gestalten. Es ging darum zu verstehen, wie Menschen über Regionen, Kundentypen und Geschäftsmodelle hinweg tatsächlich arbeiteten, bevor entschieden wurde, was – wenn überhaupt – gebaut werden sollte.

Meine Rolle

Ich leitete den UX-Workstream für das gesamte Programm und war dafür verantwortlich, organisatorische Unsicherheit in eine validierte Produktrichtung zu verwandeln – nicht nur Forschung zu erstellen oder Screens zu gestalten.

Über das gesamte Programm hinweg plante und steuerte ich einen mehrphasigen Discovery-Prozess über fünf globale Regionen hinweg und moderierte den Großteil der Interviews, Workshops und Usability-Sitzungen persönlich selbst. Wo Sprache oder lokale Expertise dies unpraktikabel machten, leitete ich regionale Moderator:innen an, blieb dabei aber für Synthese und Urteilsbildung verantwortlich, damit der Evidenzstandard überall dort, wo das Programm lief, konsistent blieb.

Über die Forschung hinaus verantwortete ich die Gestaltung der Lösung von Anfang bis Ende: die Übertragung fragmentierter Workflows in Service Blueprints, die Definition des Interaktionsmodells und der Informationsarchitektur sowie die Übersetzung der Evidenz in die funktionalen Produktanforderungen, auf denen das Konzept aufbaute. Da keine interne Engineering-Kapazität verfügbar war, arbeitete ich mit einem externen Engineering-Unternehmen zusammen, um diese Richtung in codierte Proofs of Concept auf vier Plattformen umzusetzen. Ich leitete außerdem die Namensfindung und visuelle Identität des Konzepts und verdichtete das gesamte Programm zu der Executive-Empfehlung, auf deren Grundlage die Geschäftsführung letztlich handelte.

Unser erstes Ziel war es, Annahmen infrage zu stellen statt sie zu bestätigen. Durch Interviews, Umfragen und Workshops in allen Regionen untersuchten wir, wie Menschen tatsächlich mit konkurrierenden Anforderungen umgingen und wo die eigentliche Reibung lag.

Das Problem war nicht einfach „zu viele Alerts“. Es war fragmentierte Entscheidungsfindung.

Interviews und Workshops offenbarten bedeutsame Unterschiede nach Region, Kundentyp und Rolle: Manche Kolleg:innen betreuten einen einzigen strategischen Account, andere Hunderte von Accounts über Hunderte von Standorten hinweg. Diese Unterschiede – und nicht eine einzelne gemittelte Persona – prägten in der Folge jede weitere Entscheidung. Dieses Kapitel deckte zudem Probleme auf, die der ursprüngliche Business Case nicht vorausgesehen hatte, allen voran doppelte Informationen, ineffektive Kommunikation und Entscheidungsmüdigkeit.

Bevor ich auch nur eine einzige Oberfläche gestaltete, kartierte ich, wie Alerts durch die Organisation liefen, und verfolgte mehr als dreißig operative Alert-Typen über mehrere Systeme, Nutzerrollen und Geschäftsprozesse hinweg. Das legte offen, wo Informationen entstanden, wie sie zwischen Teams flossen und wo Nutzer:innen unnötige Komplexität erlebten.

Statt einzelne Screens zu optimieren, gestaltete ich den Service des Zielzustands selbst. Die Arbeit etablierte eine skalierbare Service-Architektur, die sowohl zeitkritische als auch nicht zeitkritische Alerts abdeckte, und definierte konsistente Verhaltensweisen, Entscheidungspunkte, Backstage-Prozesse, operative Verantwortlichkeiten und User Journeys, bevor die Interface-Gestaltung begann.

Nur weil die Organisation einen Alert erzeugen konnte, hieß das nicht, dass der Nutzer ihn erhalten sollte.

Diese Service Blueprints wurden zur gemeinsamen Referenz für Produkt, Engineering und Design und brachten alle auf eine gemeinsame Sicht, wie der Service funktionieren sollte, bevor entschieden wurde, wie er aussehen sollte.

Zeitkritikalität & Priorität

Eine der bedeutendsten Erkenntnisse aus der Forschung war, dass das Problem nicht einfach die Anzahl der Alerts war, die Nutzer:innen erhielten.

Die eigentliche Herausforderung bestand darin zu verstehen, welche Alerts wirklich Aufmerksamkeit erforderten, wann sie ein Handeln erforderten und was von den Nutzer:innen als Nächstes erwartet wurde.

Ich entwickelte eine Alert-Strategie für den Zielzustand, die sowohl zeitkritische als auch nicht zeitkritische Alerts abdeckte, und stellte eine konsistente Beziehung zwischen Dringlichkeit, Priorität und Nutzerverhalten her, bevor überhaupt mit der Interface-Gestaltung begonnen wurde.

Diese Prinzipien wurden zum Fundament für den Alert-Lifecycle, das Priorisierungs-Framework und den Service Blueprint des Zielzustands.

Vor jeder Engineering-Investition testete ich einen interaktiven Prototyp in moderierten Sitzungen, die ein persönliches Usability-Labor mit Remote-Forschung in allen anderen Regionen kombinierten.

Das Ziel war nie, eine Oberfläche zu validieren. Es ging darum herauszufinden, ob die Menschen dem Konzept vertrauten.

Die Menschen mussten die Logik hinter der Priorisierung verstehen und wirklich das Gefühl haben, dass sie ihren Aufwand reduzierte – eine Erkenntnis, die die nächste Iteration lange vor der ersten Zeile Code prägte.

Usability-Tests vor Ort

Ich plante, entwickelte und leitete das erste Usability-Testprogramm der Organisation, sowohl vor Ort als auch remote: von Rekrutierung, Prototyp-Design, Moderation und Interviews bis hin zu Beobachtung, Synthese und der direkten Rückführung der Erkenntnisse in das Produktdesign.

Remote-Nutzerforschung

Remote moderierte Forschungssitzungen zur Validierung von Konzepten mit Teilnehmenden aus mehreren Regionen, die schnelles Feedback und iterative Verfeinerung während des gesamten Designprozesses ermöglichten.

Eine Frage blieb unbeantwortet: Wenn mehrere Dinge gleichzeitig Aufmerksamkeit forderten, was sollte das System zuerst anzeigen? Statt diese Frage selbst zu beantworten, bauten wir ein eigenes Priorisierungs-Forschungsprogramm auf: Workshops, die offenlegten, wie Menschen über Dringlichkeit, Risiko, Kundenauswirkung und Aufwand nachdachten, gefolgt von einer Umfrage, die diese Muster im großen Maßstab validierte.

Das Ergebnis war keine weitere Oberfläche. Es war ein evidenzbasiertes Entscheidungsmodell.

Dieses Modell wurde zur Logik hinter der Priorisierungs-Engine, die in den Proof of Concept integriert wurde. Es offenbarte zudem echte regionale Unterschiede, die sich durch die Workshops und die Umfrage zeigten und nicht durch irgendeinen visuellen Test: Manche Märkte gewichteten die Kundengröße stärker, andere das vertragliche Risiko. Diese Evidenz prägte direkt, wie sich eine zukünftige Version des Modells nach Region und Rolle anpassen ließe, statt allen eine einzige Regel aufzuzwingen.

Priorisierungs-Workshops

Ich plante und moderierte funktionsübergreifende Priorisierungs-Workshops zu Nutzerbedürfnissen, operativem Wert und Geschäftsprioritäten.

Die Ergebnisse dieser Workshops halfen, die Anforderungen zu definieren, die letztlich in den Priorisierungsalgorithmus und die künftige Alert-Strategie einflossen.

Erst nachdem das Konzept selbst validiert war, ging das Programm zu codierten Proofs of Concept über. In Zusammenarbeit mit einem externen Engineering-Team übersetzte ich die UX-Richtung in funktionsfähige Builds auf vier Plattformen – nie als Produktivsoftware gedacht, sondern als Mittel, um Umsetzungsansätze zu testen, bevor interne Engineering-Investitionen getätigt wurden.

Mehrere codierte Konzepte wurden bewertet. Die Menschen bevorzugten durchweg die eigenständige mobile Erfahrung, doch die Evidenz erzählte eine andere Geschichte: Die meisten arbeiteten überwiegend vom Laptop aus, viele hatten kein firmeneigenes Telefon, und eine separate App würde wahrscheinlich ungenutzt bleiben.

Es war nicht die spannendste Option. Es war die Option mit der größten Erfolgsaussicht.

Diese Empfehlung ist der klarste Beleg für den Zweck des gesamten Programms: Urteilsvermögen, fundiert auf Evidenz, statt persönlicher Vorliebe.

Ergebnis

Das Programm war erfolgreich – nicht, indem es Software auslieferte, sondern indem es die Unsicherheit beseitigte, die die Auslieferung von Software zu einem Glücksspiel gemacht hätte.

Es lieferte eine validierte Produktrichtung, ein evidenzbasiertes Priorisierungsmodell, Service Blueprints des Zielzustands, funktionale Produktanforderungen, funktionsfähige Proofs of Concept und – am wichtigsten – Vertrauen der Geschäftsführung, fundiert auf globaler Evidenz statt auf Annahmen.

Mehr im Detail ansehen: Forschung & Daten als Grundlage für Design (PDF) →

Von der Unsicherheit zur Produktrichtung.

Das Programm endete mit einem Concept-Film, der Monate an Forschung, Priorisierung und Validierung zu einer einzigen Vision für die Stakeholder zusammenführte. Statt isolierte Funktionen zu präsentieren, zeigte er, wie Evidenz jeden Aspekt der vorgeschlagenen Erfahrung geprägt hatte.

Eine Fußnote zum Namen: Dieses Programm begann sein Leben als „Digital Co-Pilot“ — noch bevor Microsofts Copilot existierte, wie es der Zufall wollte. Als die Namenskollision unvermeidlich wurde, leitete ich das Rebranding zu Nexa und gestaltete den neuen Namen und die neue Identität neben der oben beschriebenen Produktarbeit.