2026-03 · 4 Min. Lesezeit
Entscheidungen ohne vollständiges Wissen
Enterprise-Nutzer werden oft als Experten beschrieben. In Wirklichkeit verbringen die meisten ihren Arbeitsalltag damit, mit Unsicherheit umzugehen. Das verändert die Rolle von Design grundlegend.
Enterprise-Software wird oft so gestaltet, als wüssten Menschen genau, was sie tun müssen.
Die meisten Male ist das nicht der Fall.
Richtlinien ändern sich. Prozesse entwickeln sich weiter. Ausnahmen treten auf. Der Fall vor ihnen entspricht selten exakt dem Beispiel aus der Schulung — und die Schulungsunterlagen sind selten auf dem neuesten Stand.
Der „Experte" ist oft nicht die Person mit vollständigem Wissen, sondern diejenige, die genügend Muster erkannt hat, um auch dann zu einer vernünftigen Entscheidung zu kommen, wenn die Regeln die Situation nicht vollständig abdecken. Und genau das ist die Regel, nicht die Ausnahme.
Die besten Enterprise-Produkte gehen nicht von vollständigem Wissen aus. Sie helfen Menschen dabei, vernünftige Entscheidungen zu treffen, wenn vollständiges Wissen nicht verfügbar ist.
Nutzer können Symptome meist besser beschreiben als Ursachen.
Ein Sachbearbeiter wird zunächst sagen, eine Oberfläche sei „nervig", lange bevor er konkret benennen kann, warum. Fragt man einmal nach, zeigt er auf einen Button. Fragt man ein zweites Mal nach, stellt sich heraus, dass der Button gar nicht das Problem ist. Das eigentliche Problem liegt vielleicht in einem Feld weiter oben, das bereits eine Kategorisierung verlangt, obwohl zu diesem Zeitpunkt noch nicht genügend Informationen vorliegen, um diese Entscheidung sicher treffen zu können.
Der Button war das Symptom. Die verfrühte Festlegung war die Ursache.
Genau dort beginnt Design. Das Formular ist nicht deshalb problematisch, weil das Layout schlecht ist — das Layout ist lediglich der Ort, an dem ein tiefer liegendes Problem sichtbar wird. Ein Workflow wirkt umständlich, weil er eine Richtlinie abbildet, die nicht mehr zur Realität passt. Ein Dashboard wirkt verwirrend, weil es eine Frage beantwortet, die seit zwei Reorganisationen niemand mehr stellt.
Die Oberfläche ist der Ort, an dem das Problem sichtbar wird. Die eigentliche Arbeit besteht darin, zu verstehen, woher es kommt.
Deshalb ist „den Screen zu reparieren" selten die richtige Problemdefinition.
Gute Interfaces zeigen Menschen, was sie tun können. Gute Systeme helfen ihnen zu verstehen, was gerade geschieht. Das sind unterschiedliche Aufgaben — und sie werden häufig verwechselt.
Ein Interface mit der Aufforderung „Zur Eskalation klicken" macht lediglich deutlich, dass eine Aktion verfügbar ist. Ein System, das erklärt, warum eine Eskalation in diesem Fall sinnvoll ist, was danach geschieht und welche Auswirkungen sie hat, unterstützt Menschen dabei, eine Entscheidung zu treffen.
Das eine skaliert Funktionen. Das andere baut Verständnis auf.
Enterprise-Software ist meist deutlich stärker im ersten als im zweiten. Dafür gibt es nachvollziehbare Gründe. Interfaces lassen sich leichter testen als Verständnis. Klicks lassen sich leichter messen als Orientierung. Und Designteams werden meist an Oberflächen gemessen, nicht an der Qualität von Entscheidungen.
Die Konsequenzen zeigen sich später — dann, wenn Nutzer auf einen Fall treffen, den der Workflow nicht vorgesehen hat, und ihnen kein mentales Modell zur Verfügung steht, auf das sie zurückgreifen können.
Genau diese Art von Arbeit empfinde ich als die wertvollste. Nicht Entscheidungen vereinfachen. Sondern die Bedingungen verbessern, unter denen sie getroffen werden.
Das wertvollste Designartefakt ist oft kein Screen. Sondern ein gemeinsames Verständnis.
Ein Team, das sich darüber einig ist, was ein Fall tatsächlich bedeutet, was Nutzer tatsächlich tun und an welcher Stelle ein Prozess tatsächlich scheitert, kann zahlreiche gute Interfaces entwickeln. Ein Team, das zwar die visuelle Gestaltung perfektioniert hat, dieses gemeinsame Verständnis aber nicht teilt, wird immer wieder neue Varianten derselben Fehlannahme produzieren.
Ein großer Teil meiner Arbeit besteht darin, zwischen unterschiedlichen Perspektiven auf dasselbe Problem zu übersetzen: Nutzer, Fachbereiche, Entwicklungsteams und zunehmend auch intelligente Systeme. Jede dieser Gruppen sieht nur einen Ausschnitt. Der eigentliche Hebel entsteht dort, wo diese Perspektiven füreinander verständlich werden. Der Screen ist häufig nur das Ergebnis dieser Arbeit.
Mit der Zeit habe ich begonnen, Enterprise UX als die Gestaltung von Entscheidungsbedingungen zu verstehen — jener Bedingungen, unter denen Menschen auch ohne vollständiges Wissen zu einer vernünftigen Antwort gelangen können, mit den Informationen, die ihnen zur Verfügung stehen, der Zeit, die sie haben, und den Konsequenzen, die sie tragen müssen.
Diese Sichtweise hat verändert, wie ich Projekte betrachte. Die Frage lautet nicht mehr: „Was muss dieser Screen zeigen?" Sondern: „Was muss diese Person über ihre Situation verstehen, um mit Zuversicht handeln zu können?"
Das wertvollste Ergebnis von Design ist selten eine aufgeräumtere Oberfläche. Es ist eine Person, die ihre Situation gut genug versteht, um eine bessere Entscheidung zu treffen.
Sobald diese Frage beantwortet ist, gestaltet sich die Oberfläche oft erstaunlich selbstverständlich.