Projektübersicht
Herausforderung
Durch eine AI-gestützten Analyse aller Support-Tickets aus 2025 entdeckte ich ein erhebliches Optimierungspotenzial bzgl. Error Messagings.. Diese datengestützte Erkenntnis, kombiniert mit bestehendem Kundenfeedback und weiteren, die Error Messages betreffende Problems-to-solve, bestätigte die hohe Relevanz der Verbesserung, welches im Leadership Team großen Anklang fand
Als initiierender UXler bestand meine Herausforderung darin, eine systematische Lösung zu entwickeln, die über oberflächliche Korrekturen hinausgeht. Ziel war es, ein skalierbares, nutzerzentriertes Framework zu schaffen, das einen messbaren Beitrag zur Reduzierung der Supportkosten leistet, durch Steigerung der Nutzerautonomie.
Ziele
-
Graduelle Reduzierung des Support-Ticket-Volumens
-
Steigerung der Selbstlösungsrate.
-
Etablierung eines konsistenten, skalierbaren und verständlichen Frameworks für alle Fehlermeldungen.
-
Implementierung KI-gestützer Hilfe bei Error Messaging
Probleme
-
Bis zu 45% aller Support-Tickets stehen mit unklare Fehlermeldungen in Verbindung was wertvolle Entwicklerressourcen bei Supporttätigkeiten bindet.
-
Vage Meldungen ohne Lösungsansatz führten zu künstlichen Dead-Ends, die die Produktivität der Nutzer stoppt und zu Frustration führt.
-
Fehlender Kontext in den Fehlermeldungen erzwang zeitaufwendige Rückfragen und verzögerte die Problemlösung erheblich während des Supports.
Projektumfang
-
UX Research
-
UX Strategy & Systems Thinking
-
Product Design
Dauer
-
November 2025 - Dezember 2025
Rolle
-
Lead UX
Tools
-
Figma
-
Mural
-
ServiceNow
-
Confluence/Jira
Vorgehen
01.
Problem Discovery &
Strategic Framing
02.
Framework-Konzeption &
Prototyping
03.
Multi-Track-Validierung
mit Nutzern und Developern
04.
Synthese &
Strategische Roadmap
01. Problem Discovery &
Strategic Framing
Durch eine übergreifende Analyse von Support-Tickets deckte ich ein kritisches Problem mit hohem Geschäftswert auf. Ich quantifizierte den Business Impact, um die Initiative von einer reinen UI-Optimierung zu einem strategischen Projekt zu heben.
Proaktiv brachte ich die Verbesserung der Error Messages in die Quartalsplanung ein. Denn eine KI‑gestützte Auswertung, mittels Topic‑Clustering und Keyword‑Klassifikation, von ServiceNow‑Tickets (Q1-Q4 2025) offenbarte, dass konstant 35% - 45% aller Supportanfragen im Zusammenhang mit unklaren Fehlermeldungen standen. Diese Metrik lieferte eine belastbare Datenbasis zur Priorisierung. Die Analyse identifizierte außerdem vier kritische Bereiche mit den höchsten Supportkosten und größter Frustration:
1
Projekt-Deployment & -Release
3
Ai Services & DOX
.png)
2
Externe Konnectivität
(Destinations, Actions, and Mail Server)
4
In-Studio Authoring Experience (Saving & Editing)
In der weiterführenden qualitativen Analyse dieser Bereiche zeigte sich ein klares Bild der aktuellen Experience:
-
Undurchsichtig & nicht handhabbar: Generische Meldungen wie "Something went wrong" boten keinen Lösungsansatz.
-
Relevante, technische Informationen werden nicht angezeigt: 5 von 6 Nutzern nahmen sofort Entwickler-Tools (F12) zur Diagnose zur Hilfe.
-
Irreführender Inhalt: Gefundene Details waren oft ungenau, führten zu langwierigen Suchprozessen oder sogar zu künstlichen Dead-Ends
Aus diesen Erkenntnissen leitete ich drei klare Nutzerbedürfnisse ab, die das Fundament für die Lösungsentwicklung bildeten:
-
Klarer & handhabbarer Inhalt: Eine verständliche Erklärung des Problems und des Lösungswegs.
-
Kontextbezogene Informationen: Die Angabe des genauen Schritts und der Daten, die den Fehler auslösten.
-
Direkte Navigation: Klickbare Fehlermeldungen, die direkt zur Problemquelle führen.
Die vollständige Synthese dieser initialen Projektphase ist hier als Dokument einsehbar.
02. Framework-Konzeption & Prototyping
Auf Basis der Discovery-Erkenntnisse entwickelte ich ein skalierbares Design-Framework statt isolierter Einzellösungen. Gezielte Prototypen für vier "Assistance Levels" dienten als Grundlage, um Hypothesen zur Nutzerunterstützung systematisch zu testen.
Die Anatomie einer wirksamen Fehlermeldung ist einfach:
-
Sie benennt das Problem,
-
erklärt die Ursache
-
und führt den Nutzer zur Lösung.
Zusätzlich gaben die SAP Fiori Guidelines die visuelle Gestaltung vor, definierten aber nicht unterschiedliche Assistenzstufen und deren Wechselwirkung — beides Voraussetzungen für ein skalierbares Framework. Daher visualisierte ich alle viable Content‑Variationen der Assitenzstufen als Wireframes (siehe unten) und analysierte diese im Kontext der in Phase 1 identifizierten Problembereiche, um wirkungsvolle Kombinationen zu ermitteln. Weitere Formen (z. B. Banner, Toasts) wurden dort exploriert, wo sie passend erschienen.
Aus dieser Exploration kristallisierten sich 4 zentrale Muster heraus, die ich in testbare Assitenzstufen mit entsprechenden Hypothesen überführte. Diese sind:
-
Level 1: Präzise Textmeldung für einfache Fehler.
H1: Kurzer, handlungsfokussierter Text erhöht die First‑Contact Self‑Resolution. -
Level 2: Kontextsensitiver Link zur Hilfe-Dokumentation.
H2: Mit steigendem Assistance‑Level sinkt die Nutzerfrustration bei Fehlern. -
Level 3: Direkter "Deep Link", der zur Fehlerquelle navigiert.
H3: Deep‑Links erhöhen die wahrgenommene Selbst‑Wiederherstellbarkeit und reduzieren Time‑to‑Recovery. -
Level 4: KI-gestützte Lösungsangebote durch Joule.
H4: KI‑gestützte Hilfe reduziert Frustration.
H5: KI‑gestützte Hilfe verringert den Bedarf der Nutzer, selbst kontextuelle Details zu konsumieren.
Diese Konzepte wurden in einem interaktiven Prototyp zusammengeführt, um ihre Wirksamkeit in Nutzertests zu validieren.
03. Multi-Track-Validierung
In einem dualen Validierungsansatz prüfte ich die Konzepte sowohl mit Nutzern als auch deren Machbarkeit mit Entwicklern. Dieser Prozess zeigte nicht nur die Bedürfnisse der Nutzer, sondern deckte auch die tieferliegenden Ursachen und potentielle Lösungsansätze für die aktuell bestehenden Probleme mit den Error Messages auf.
3.1: Qualitative Nutzer-Validierung
Participants
-
10 Teilnehmende insgesamt: 6 initiale Sessions + 4 Follow‑ups, als klar wurde, dass Novice vs. Expert Unterschiede besser abgedeckt werden mussten.
-
Gemischte Erfahrungsgrade: Anfänger und Experten; verschiedene technische Skills; Fokus auf SBPA Nutzer.
Method
-
Moderierte Remote‑Sessions mit Think‑Aloud‑Methodik.
-
Aufgaben fokussierten die in Phase 1 identifizierten kritischen Use‑Cases.
Beobachtete Messgrößen:
-
Problemerkennung — Erkennen die Nutzer das Problem korrekt?
-
Wiederherstellungsfähigkeit — Können die Nutzer angeben, wie der Fehler behoben werden kann?
-
Verhaltensreaktionen — Welche Aktionen und Reaktionen zeigen die Nutzer?
-
Wahrgenommene Leichtigkeit/Zufriedenheit — Gemessen über SEQ
Level | User Perception | Impact on Actionability | Representative Quote |
|---|---|---|---|
📄 Level 1: Text Only | Effective, but only for simple issues. Seen as sufficient and straightforward for specific errors (Use Case C) but frustrating for undefined problems (Use Case B). | High. Users knew exactly what to do next: either fix the simple error or follow the procedural steps (retry/contact support). | "This is pretty straightforward because it tells exactly what’s the issue like duplicate name." |
🔗 Level 2: Help Portal Link | Helpful. Universally seen as a positive, low-effort addition that saves users from having to search for documentation manually. | High. Provided a clear next step for users who needed more context to understand the syntax or rules. | "What I really like is the help link because… normally I would then like type in build help process automation and just of course it’s one step easier." |
➡️ Level 3: Actionable Link | Extremely Positive. The "Go to artifact" link was a standout feature, perceived as a highly efficient and direct way to resolve issues. | Very High. Provided the clearest and fastest path to resolution by eliminating the need for users to manually search for the problematic component. | "With my experience… it’s five, especially also with the point. I can now just jump to it." |
🤖 Level 4: AI Fix / Create | Mixed & Skeptical. While the idea of AI help was exciting, users were skeptical of a generic "Ask Joule" prompt, assuming it would provide a non-specific answer. | Low to Moderate. Most experienced users stated they would ignore the AI for complex errors and investigate manually due to a lack of trust. New users were more curious to try. | "I would now currently assume that I would get a generic answer on the type of AH, OK Yeah, all of your projects must be valid before releasing the project." |
Zusammenfassung: Die Analyse der Nutzerreaktionen zeigt eine klare Hierarchie in der Wirksamkeit der vier Assistenzstufen: Während ein direkter Navigationslink (Level 3) die höchste Effizienz und Akzeptanz erzielte, wurde die KI-Unterstützung (Level 4) von Nutzern mit deutlicher Skepsis betrachtet. Diese Skepsis war besonders bei erfahrenen Nutzern ausgeprägt. Generell zeigte die Studie, dass Experten vor allem die Beschleunigung ihres Workflows durch tiefen Kontext suchen, während unerfahrene Nutzer eine einfache, schrittweise Handlungsanweisung priorisieren.
3.2: Technical Discovery & Architectural Alignment
Im zweiten Teil der Validierung führte ich Interviews um die technische Machbarkeit unserer Konzepte zu prüfen und Lösungsansätze zu ergründen.
Participants
-
6 Teilnehmende
-
Unterschiedliche Arbeitserfahrung: 3-25 Jahre, verschiedene Berufe: Lead Developer, Manager, Architekten
Method
-
Semi Strukturiertes, exploratives remote Interview von 60-90 Minuten
Die vier zentralen Erkenntnisse waren:
-
Das Kernproblem ist der Informationsverlust über Systemgrenzen. Detaillierte Fehlerinformationen werden in der Kette von Microservices nicht weitergegeben. Nur ein architektonischer, teamübergreifender "Vertrag" (Error Contract) kann sicherstellen, dass strukturierte Fehlerdaten konsistent an die Benutzeroberfläche durchgereicht werden.
-
Machbarkeit der "Deep Links": Der von Nutzern favorisierte "Deep Link" ist für die meisten Prozessfehler der Design-time technisch umsetzbar, vorausgesetzt, die notwendigen Kontext-IDs werden mitgeliefert. Dies war eine wichtige Bestätigung unserer vorhergegangenen Nutzervalidierung.
-
Potenzial eines "Easy Bug Report" Workflows: Entwickler bestätigten, dass ein einfacher interner Prozess zur Meldung schlechter Fehlermeldungen die Qualität kontinuierlich verbessern könnte bei mäßigem Aufwand.
-
Grundlagen für eine KI Assistenz: Für eine wirklich hilfreiche KI ist das Übermitteln strukturierter Fehlerdaten (Log ID, Error Code, Model ID) im Hintergrund entscheidend. Eine generische "Frag mich"-Funktion ohne diesen Kontext wird von Nutzern nach unseren Erkenntnisnissen kritisch wahrgenommen. Nur eine graduelle Einführung von KI Hilfen in Fällen, bei denen eine Lösung bereitgestellt werden kann, kann Vertrauen schaffen.
Aus der Synthese der Interviews konnten allerdings noch deutlich mehr Ansätze abgeleitet werden. Alle 18 potenziellen Initiativen zur Verbesserung der Error Messages können hier eingesehen werden:
04. Synthese & Strategische Roadmap
Ich führte die Erkenntnisse aus Nutzer-Validierung und technischer Discovery in einer strategischen Roadmap zusammen. Diese priorisiert konkrete Maßnahmen in kurzfristige Quick Wins und langfristige, fundamentale Verbesserungen.
Durch die Synthese der Nutzerbedürfnisse und der technischen Discovery entwickelte ich eine pragmatische und wirkungsorientierte Roadmap. Diese priorisiert Lösungen nach Aufwand und Wirkung und balanciert kurzfristige Verbesserungen mit langfristigen, fundamentalen Korrekturen
.jpg)
Strategische Empfehlungen in drei Horizonten:
-
Sofortmaßnahmen: Implementierung der "Deep Links" und UA Verbsserungen für die Top-4-Fehlerszenarien sowie Einführung eines standardisierten "Technical Details"-Blocks mit kopierbarer Log-ID zur Beschleunigung des Supports.
-
Taktische Initiativen: Etablierung des "Easy Bug Report" Workflows, um kontinuierliche Verbesserung zu fördern. Parallel dazu gezielte Implementierung von Joule mit strukturierten Fehlerdaten für erste, spezifische Anwendungsfälle, um Vertrauen aufzubauen
-
Fundamentale, architektonische Maßnahmen: Initiierung und Umsetzung des teamübergreifenden "Error Contracts", um das Problem des Informationsverlusts zu lösen und die Grundlage für eine exzellente Fehler-Experience zu schaffen.
Messkonzept:
-
Instrumentation: Tracking von Deep‑Link‑Nutzung, Help‑Link‑Clicks und KI‑Interaktions‑Outcomes; Tagging relevanter Fehlerarten in ServiceNow.
-
A/B‑Testing: Vergleich von Message‑Varianten für Top‑Fehlerszenarien; primäre Metriken: Self‑Resolution, Time‑to‑Recovery, Repeat Tickets; Testfenster 2–4 Wochen pro Variante.
-
Wöchentliche Überwachung von Fehler‑Ticket‑Anteil, Self‑Resolution und Time‑to‑Recovery; qualitative Feedback‑Reviews für kontinuierliche Iteration.
Resultate & Lerneffekte
Dieses Projekt lieferte eine datengestützte, validierte und technisch fundierte Strategie, die nun als priorisierter Backlog für Implementierung dient und die Wahrnehmung von SBPA‑Fehlermeldungen nachhaltig verändern wird.
-
Strategische Ausrichtung durch proaktive Analyse
Meine wichtigste Erkenntnis war, dass die größte Wirkung nicht im Design, sondern in der strategischen Vorbereitung lag. Ich habe gelernt, Support-Daten als Ressource zu nutzen, um den Geschäftswert eines latenten Problems zu quantifizieren und es so von einem "Ärgernis" zu einer anerkannten, priorisierten Initiative zu erheben.
-
Effizienz durch duale Validierung: Die parallele Validierung mit Nutzern und Entwicklern war der Schlüssel, um das Potential dieser Researcharbeit zu maximieren. Sie stellte sicher, dass die entwickelte Lösung sowohl erwünscht als auch technisch realisierbar ist und gab einen klaren Ausblick in Effort, Feasability und Usability aller Items im Solutionspace.
-
UX als systemische Diagnose
Dieses Projekt hat mir gezeigt, dass eine schlechte User Experience oft nur das Symptom einer tieferliegenden, systemischen Ursache ist. Ich habe wieder einmal unter Beweis gestellt, dass meine Rolle als UXler über das Oberflächendesign hinausgeht und wir als "System-Diagnostiker" agieren müssen, die die Ursachenkette bis in die Architektur zurückverfolgen und die notwendigen Gespräche zwischen den Disziplinen beginnen und moderieren.
-
Vertrauen in KI als Ergebnis, nicht als Anforderung
Die deutliche KI-Skepsis der Experten hat mir eindrücklich gezeigt dass Vertrauen ein Ergebnis ist, kein Input: Man muss es durch schrittweise, nachweislich nützliche Anwendungsfälle verdienen, die dem Nutzer die Kontrolle geben und transparent darstellen, wie die KI zu ihrer Empfehlung kommt.
