Wir designen Enterprise-Software für Nutzer, die es nicht gibt
Unsere Nutzer wollen keine intuitive Software. Sie wollen schnell fertig werden.
Vom Erlernen zum Entdecken
Meine ersten intensiven Kontakte mit Computern hatte ich Anfang der 1990er Jahre. Ich erinnere mich noch gut daran, wie ich als Kind vor dem Weihnachtsbaum saß und das Handbuch eines Commodore Amiga las. In einem der ersten Kapitel wurde detailliert beschrieben, wie man eine Maus bedient. Was ein Klick ist und was ein Doppelklick.
Heute sehe ich meinem kleinen Neffen zu, wie er mit noch nicht einmal zwei Jahren auf meine Apple Watch drückt und sich wundert, was passiert. Er erlernt nichts. Er entdeckt.
Und genau hier liegt ein wichtiger Unterschied: Mein Neffe entdeckt, aber er erreicht kein Ziel. Entdecken beantwortet die Frage, was passiert. Arbeiten braucht die Antwort auf eine andere Frage: was passieren wird. Wer einen Vorgang abschließen muss, kann nicht ausprobieren, was ein Klick bewirkt. Er muss es vorher wissen.
Irgendwann in den letzten Jahrzehnten hat sich dieser Wandel auch im Großen vollzogen. Software soll heute nicht mehr erlernt werden, sie soll entdeckt werden und entdeckbar sein. Das hat massive Auswirkungen darauf, wie wir Software erleben und wie sie unsere Arbeit gestaltet.
Früher war es vollkommen normal, dass zu einem Softwareprodukt ein Handbuch gehörte, oft ein ganzes Kompendium. Die Handbücher enthielten die Informationen, die man überhaupt erst brauchte, um mit dem Produkt umgehen zu können. Bei großen Businessanwendungen ging das noch einen Schritt weiter. Ich erinnere mich daran, wie meine Mutter in den 1990er Jahren erzählte, dass in ihrer Firma jetzt auch Computer zum Einsatz kämen. Von Software sprach kaum schon jemand. Es waren schlicht "Computer". Dass ein solches System immer aus Hardware und Software besteht, war für die breite Masse noch kein greifbares Konzept.
Und bevor sie diese Computer im täglichen Geschäft einsetzen konnte, war eine ganze Woche Schulung eingeplant. Eine komplette Woche, in der es darum ging zu lernen, wo welche Daten hinterlegt waren, wie man sie abruft und welche Auswirkungen bestimmte Aktionen haben. Solche Einführungen waren die Regel, nicht die Ausnahme. Und was leistete diese Software? Eine frühe Form von dem, was wir heute wohl ERP nennen würden. Deutlich weniger leistungsfähig und deutlich umständlicher zu bedienen als alles, was wir heute ausliefern würden.
So aufwändig diese Einführungen waren, so schnell zeigten sich danach Ergebnisse. Wer einmal Nutzer an solchen Expertensystemen gesehen hat, der weiß: Sie sind extrem effizient. Nach einer Weile geht die Bedienung in Fleisch und Blut über. Wer jeden Tag Stunden vor demselben System verbringt, weiß intuitiv, wo welche Information steht, welche Tastenkombination zum nächsten Schritt führt und wie oft man Tab drücken muss, um in das relevante Feld zu kommen. Software spielt dann das aus, was sie ausspielen soll: Sie erzeugt Effizienzgewinne. Sie macht bestimmte Aktionen überhaupt erst möglich.
Und ich glaube, genau hier ist Software zum Opfer ihres eigenen Erfolgs geworden.
Früher fand man Software in klaren Nischen und an klaren Orten. Im Büro gab es den Computerarbeitsplatz. Zuhause gab es den Computerschreibtisch. Der Computer war ein wertvolles Möbelstück. Heute tragen wir unsere Computer im wahrsten Sinne des Wortes mit uns herum. Laptop, Tablet, Smartphone, Smartwatch. Software ist omnipräsent. Schon 2009 ließ uns Apple in Werbespots wissen: "There's an app for that".
Das hat verändert, wie wir mit Software umgehen. Wenn die nächste App zwei Klicks entfernt ist, hat niemand mehr Lust auf Handbücher oder Einführungen. Was zählt, sind schnelle Erfolgserlebnisse. Wer sein Publikum nicht in den ersten Minuten überzeugt, verliert es an die Konkurrenz.
Diese Entwicklung hat Software für Millionen, vielleicht sogar Milliarden Menschen zugänglich gemacht, die früher nie eine benutzt hätten. Mein Problem ist nicht der Wandel. Mein Problem ist, was wir daraus gemacht haben: ein Gesetz.
Wir haben eine sinnvolle Antwort auf eine bestimmte Art von Software zur Antwort auf jede Art von Software erklärt.
Und im Unternehmenskontext kostet uns das jeden Tag Produktivität.
Zwei Kategorien, ein Maßstab
Die Softwarewelt teilt sich nämlich in zwei komplett unterschiedliche Bereiche. Auf der einen Seite die kleinen, hilfreichen Apps. Klar umgrenzte Aufgaben. Einen Timer stellen, eine Nachricht schicken, schnell ein Auto mieten. Moderne Oberflächen und eine einfache Benutzerführung machen es hier tatsächlich möglich, die Bedienung zu entdecken, statt sie zu erlernen. Und das ist auch genau richtig so, denn niemand wird eine Woche investieren, um zu erlernen, wie man einen Timer stellt.
Auf der anderen Seite gibt es sie weiterhin: die großen, die "richtigen" Applikationen. Systeme, die komplexe Prozesse abbilden. Systeme, die nicht mehr nur dabei unterstützen, Geschäftsprozesse abzubilden, sondern die diese Prozesse überhaupt erst möglich machen. Ohne sie findet das Geschäft nicht statt.
Ich beschäftige mich hauptberuflich häufig mit Enterprise-Software. Software, die im Unternehmenskontext eingesetzt wird, die Geschäftsprozesse trägt und manchmal erst ermöglicht. Diese Software unterliegt völlig anderen Einflüssen als die Software, die ich abends als Privatperson benutze. Der Nutzerkreis ist bekannt und begrenzt. Die Nutzung ist nicht freiwillig, sondern Teil des Arbeitsvertrags. Die Nutzungsdauer wird nicht in Minuten gemessen, sondern in Stunden pro Tag über Jahre hinweg. Und die Alternative ist nicht die nächste App im Store, sondern gar keine Alternative.
Wenn sich die Rahmenbedingungen so fundamental unterscheiden, dann können die Bewertungskriterien nicht dieselben sein. Genau das ist aber der Fehler, den ich immer wieder sehe: Wir legen an beide Kategorien denselben Maßstab an. Und das führt zu einem Effekt, den ich zu häufig beobachtet habe: Software macht die Arbeit nicht einfacher. Sie macht sie schwerer.
Deutlich sieht man das immer wieder bei Migrations- und Ablöseprojekten.
Alte Systeme, oft jahrzehntelang im Einsatz, sollen durch moderne Systeme abgelöst werden. Nicht selten geht das mit einer Umstellung von nativen Anwendungen auf Weboberflächen einher. Und genauso häufig geht es mit Beschwerden einher: Mit dem neuen System dauert plötzlich alles länger. Alles ist komplizierter geworden.
Ein Teil davon ist immer die Hürde, sich mit etwas Neuem zu beschäftigen. Die Tipps und Tricks, die man sich im alten System über Jahre angeeignet hat, funktionieren nicht mehr oder nicht mehr so, wie man es gewohnt war. Wandel tut weh, und ein Teil dieser Beschwerden verschwindet nach einigen Wochen von selbst.
Aber ein großer Teil davon ist real. Und dieser Teil verschwindet nicht.
Er hat damit zu tun, wie wir heute an die Gestaltung von Oberflächen und Benutzerprozessen herangehen. Moderne User Experience Guidelines und die Konzepte, die wir dabei anwenden, sind überwiegend auf private Endnutzer und Gelegenheitsnutzer ausgerichtet. Das Ziel ist, Friktion zu vermeiden. Software so intuitiv wie möglich zu gestalten. Ein klarer Fokus auf die aktuelle Aufgabe, viel Weißraum, wenig störende Information.
Für viele Anwendungsbereiche ist das genau die richtige Intention. Nur eben nicht für alle. Wir haben ein Projekt technisch erfolgreich abgeschlossen, die Oberfläche gegen alles geprüft, was wir über gutes Design zu wissen glauben, und trotzdem arbeitet die Fachabteilung jetzt langsamer als vorher. Das ist kein Betriebsunfall. Das ist die logische Folge eines Maßstabs, der von Anfang an nicht gepasst hat.
Komplexität verschwindet nicht, aber nicht jede muss sein
Business-Prozesse sind häufig kompliziert und komplex. Software, die diese Prozesse gut abbilden will, kann diese Komplexität nicht ignorieren und nicht wegabstrahieren.
Komplexität ist wie Energie. Sie verschwindet nicht, sie lässt sich nur in andere Formen umwandeln.
Diese Aussage braucht allerdings eine Einschränkung, sonst wird sie zur Ausrede für jede schlecht gemachte Oberfläche. Es gibt eine alte Unterscheidung, die hier weiterhilft, und die geht auf Fred Brooks zurück: die zwischen essenzieller und akzidenteller Komplexität. Essenziell heißt: gehört zur Sache. Akzidentell heißt: ist nur zufällig dazugekommen, hätte auch anders sein können.
Essenzielle Komplexität stammt aus dem Problem selbst. Wenn ein Vorgang fachlich vierzig Angaben braucht, dann braucht er vierzig Angaben. Daran ist nichts zu optimieren, das ist der Prozess. Akzidentelle Komplexität haben wir selbst hinzugefügt, meistens ohne böse Absicht und oft ohne es zu merken. Drei verschiedene Datumsfelder in derselben Maske. Feldbezeichnungen, die aus dem Datenbankschema stammen. Ein Ablauf, der die Struktur unserer Tabellen abbildet und nicht die Reihenfolge, in der ein Sachbearbeiter arbeitet. Ein Bestätigungsdialog, den niemand braucht. Nichts davon macht die Aufgabe komplexer. Alles davon macht die Bedienung komplexer.
Der Unterschied ist entscheidend, weil er zu zwei völlig verschiedenen Konsequenzen führt. Akzidentelle Komplexität ist immer ein Fehler, egal wie erfahren die Nutzer sind. Essenzielle Komplexität ist eine Anforderung und die darf man erfahrenen Nutzern zumuten. Das Erhaltungsgesetz gilt nur für die zweite Art.
Wenn wir das ernst nehmen, wird aus der Gestaltungsfrage eine sehr konkrete Entscheidung. Nehmen wir an, ein Geschäftsprozess braucht eine große Menge unterschiedlicher Informationen. Ich kann alles auf einem Screen darstellen. Dann wirkt dieser Screen schnell überladen und ohne tiefere Kenntnis dessen, was da angezeigt wird, verläuft man sich. Die Alternative: Ich verteile die Informationen auf verschiedene Screens. Jeder Screen ist für sich klar und aufgeräumt, aber der Nutzer muss zwischen Screens wechseln, um an die jeweiligen Informationen zu kommen.
Die Komplexität ist damit nicht kleiner geworden. Sie liegt nur woanders. Vorher lag sie darin, die relevanten Informationen auf einer vollen Seite zu unterscheiden. Jetzt liegt sie darin zu wissen, auf welchen Screen man wechseln muss. Und die zweite Variante hat einen Preis, den wir selten benennen: Sie kostet bei jedem einzelnen Vorgang Zeit, und zwar für immer.
Welche der beiden Varianten besser ist, lässt sich nicht allgemein sagen. Es ist im Einzelfall eine Abwägung von Trade-offs. Wer ist mein Nutzerkreis? Was ist sein Kenntnisstand? Mit welcher Art von Komplexität kann er am besten umgehen?
Wichtig ist mir dabei die Trennung: Bei der Frage, wie ich essenzielle Komplexität verteile, gibt es kein Richtig und kein Falsch, sondern nur eine begründete Entscheidung. Bei akzidenteller Komplexität gibt es sehr wohl ein Falsch und dort ist auch jedes Argument über Expertennutzer eine Ausrede.
Wer Komplexität in einer Oberfläche verteidigt, muss also sagen können, welche. Und wer sie bekämpft, genauso.
Selbsterklärend ist kein Qualitätsmerkmal
Der kapitale Fehler, den ich beobachte, ist, diese Abwägung nicht oder nu unzureichend durchzuführen. Stattdessen werden Grundsätze und Ratschläge zu allgemeingültigen Gesetzen erklärt. Oberflächen müssen selbsterklärend sein. Ein Screen darf nur eine Information zeigen. Zwischen Eingabefeldern muss viel Weißraum sein.
Das sind gute Ratschläge. Als Gesetze sind sie Unsinn, weil ihnen der Kontext fehlt, für den sie einmal formuliert wurden.
Was hier priorisiert wird, ist die Entdeckbarkeit von Software. Und was dabei vergessen wird, ist eine einfache Tatsache:
Entdeckbarkeit ist eine Eigenschaft der ersten Stunde. Danach spielt sie keine Rolle mehr.
Bei einer App, die kurz oder selten genutzt wird, ist das völlig in Ordnung. Wenn die erste Stunde alles ist, was ich habe, dann muss die erste Stunde perfekt sein. Aber bei einem System, das zwanzig Jahre im Betrieb bleibt und täglich acht Stunden bedient wird, optimieren wir auf einen verschwindend kleinen Teil der Nutzungsbeziehung. Wir investieren unsere Sorgfalt in den Moment, in dem der Nutzer das System zum ersten Mal öffnet, und lassen die restlichen zwanzig Jahre unbeachtet.
Und dann, in den zwanzig Jahren, kippt die Bewertung vollständig. Eine hohe Einstiegshürde klingt nach einem Mangel. Hat man diese Hürde einmal überschritten, sind die vielen Informationen auf einem Screen aber kein Hindernis mehr. Sie sind das Feature. Sie sind der Grund, warum ein Vorgang zwanzig Sekunden dauert und nicht zwei Minuten. Was aus der Perspektive der ersten Stunde wie Überforderung aussieht, ist aus der Perspektive des zweiten Jahres die eigentliche Leistung der Software.
Natürlich ist auch Entdeckbarkeit nicht einfach nur Selbstzweck oder Mode. Sie ist eine Antwort auf reale Probleme und diese Probleme kenne ich aus genügend Projekten.
Es gibt Bereiche mit hoher Personalfluktuation, in denen niemand lange genug bleibt, um Experte zu werden. Es gibt Saisonkräfte, die für sechs Wochen kommen. Es gibt Systeme mit tausenden Gelegenheitsnutzern, die sie dreimal im Jahr anfassen. Es gibt Organisationen ohne jedes Schulungsbudget. Es gibt Anforderungen an Barrierefreiheit. Und es gibt Prozesse, in denen ein Fehler eines Ungeübten so teuer ist, dass jede zusätzliche Hürde ein Gewinn ist.
In all diesen Fällen ist Entdeckbarkeit nicht nur legitim, sondern das dominierende Kriterium. Wer hier auf Expertenoberflächen setzt, optimiert für Nutzer, die er nie bekommt.
Genau deshalb ist meine Kritik keine Kritik an Entdeckbarkeit. Sie ist eine Kritik daran, dass wir sie nicht mehr abwägen.
Und damit stellt sich für mich die interessanteste Frage des ganzen Themas: Wenn ich mit Entwicklern, Architekten oder Designern einzeln über einen konkreten Fall spreche, stimmt mir fast jeder zu. Natürlich sind das Trade-offs. Natürlich hängt es vom Nutzerkreis ab. Warum setzt sich die Regel dann so verlässlich durch?
Ich habe dazu keinen Beweis, aber einen Verdacht: Regeln sind billiger als Kontextwissen.
Eine Regel lässt sich aufschreiben. Sie passt in ein Design-System, in ein Review Template, in eine Definition of Done, in eine Ausschreibung. Sie ist prüfbar, sie ist delegierbar und sie ist vor allem verteidigbar. Wenn eine Oberfläche kritisiert wird, kann ich auf die Richtlinie zeigen. Ich habe mich an den Standard gehalten. Damit ist die Verantwortung woanders.
Kontextwissen dagegen ist teuer. Es bedeutet, mit echten Nutzern zu sprechen, und zwar nicht in einem Workshop, sondern an deren Arbeitsplatz. Es bedeutet zu verstehen, wie oft ein Vorgang am Tag läuft, wo die Leute eigentlich hängen und was sie sich über Jahre für Umgehungslösungen gebaut haben. Es bedeutet Zeit, die im Projektplan nicht vorgesehen ist. Und am Ende bedeutet es, eine Entscheidung zu treffen, die nicht in einer Richtlinie steht und die man mit seinem eigenen Namen verantworten muss.
Dazu kommt ein struktureller Effekt, der gerade im Enterprise-Umfeld wirkt. Der Käufer einer Enterprise-Software ist meistens nicht ihr Nutzer. Entschieden wird in Präsentationen und Auswahlverfahren, von Menschen, die das System später nie täglich bedienen werden. Und in einer Demo von 45 Minuten gewinnt die entdeckbare Oberfläche. Immer. Nicht, weil sie besser ist, sondern weil Effizienz im Dauerbetrieb in 45 Minuten schlicht nicht sichtbar werden kann. Was man in einer Demo zeigen kann, ist die erste Stunde. Also optimieren wir die erste Stunde.
Der eigentliche Fehler ist damit nicht die falsche Entscheidung. Es ist die Entscheidung, die niemand getroffen hat. Die Regel hat sie ersetzt.
Software darf komplex sein
Es gibt sie nämlich weiterhin, die Software mit steiler Lernkurve. Software, die man nicht mal eben entdeckt, mit der man sich intensiv beschäftigen muss und aus der man dann echte Effizienzgewinne zieht.
Wir Entwickler haben dafür das Paradebeispiel direkt vor uns: eine IDE. Für mich das komplizierteste Stück Software, mit dem ich arbeite. Eine Unmenge an Funktionen, eine Unmenge an Möglichkeiten, so leistungsfähig, dass ich nach Jahren und Jahrzehnten der Nutzung immer noch neue Wege finde, Dinge schneller zu erledigen. Niemand von uns käme auf die Idee zu fordern, dass eine IDE in einer halben Stunde entdeckbar sein muss. Die Grundfunktionen, sicher. Aber das, was uns wirklich schnell macht, erschließt sich nicht von selbst. Es will gelernt werden.
Ein Beispiel aus einem ganz anderen Bereich findet sich in der Luftfahrt. Im Cockpit eines modernen Verkehrsflugzeugs gibt es hunderte Schalter und Anzeigen. Mit einer reinen UX-Brille betrachtet, ist das erschlagend, eine einzige kognitive Überforderung. Und dennoch hat sich dieses Konzept über Jahrzehnte bewährt. In kritischen Momenten haben Piloten keine Zeit, sich durch komplexe Menüs zu klicken, um eine Lösung für ein Triebwerksproblem zu suchen. Während Turbulenzen muss jeder Schalter allein durch Position und Haptik eindeutig zu erkennen sein.
Die Kehrseite ist offensichtlich: Es dauert Monate, bis ein Pilot das alles durchschaut.
Ein Cockpit ist das absolute Gegenteil von entdeckbar. Es ist ausschließlich erlernbar.
Aber wenn diese Lernkurve geschafft ist, steht die volle Bandbreite an Funktionalität zur Verfügung und kaum jemand in der Luftfahrt bezweifelt den Nutzen dieser Ausbildung.
Bevor jetzt jemand das Cockpit als Argument für überladene Masken mitnimmt: Die Voraussetzungen dieses Beispiels sind extrem. Airlines haben ein hochstandardisiertes Nutzerprofil, eine verpflichtende Ausbildung und das Budget, sie zu finanzieren. Kaum eine Organisation, für die wir Software bauen, hat das. Und auch in der Luftfahrt hat gute Gestaltung Komplexität abgebaut. Glass Cockpits haben hunderte Einzelinstrumente durch wenige Displays ersetzt, Automatisierung hat Handgriffe übernommen. Das ist kein Widerspruch zu dem, was ich hier vertrete, sondern die Unterscheidung von oben in der Praxis: Weggefallen ist akzidentelle Komplexität. Die essenzielle ist geblieben, denn ein Flugzeug ist dadurch nicht einfacher geworden.
Was IDE und Cockpit gemeinsam haben, ist genau das Profil, das viele Enterprise- Systeme auch haben: ein hoher Anteil an essenzieller Komplexität, ein Nutzerkreis, der dauerhaft eingearbeitet ist, und Geschwindigkeit im Dauerbetrieb als dominierendes Kriterium. Wenn dieses Profil vorliegt, ist eine anspruchsvolle Oberfläche kein Versäumnis. Sie ist die richtige Antwort.
Nur haben die meisten Systeme, an denen wir arbeiten, nicht genau ein Nutzerprofil. Sie haben mehrere. Die Sachbearbeiterin, die acht Stunden am Tag damit arbeitet, und der Abteilungsleiter, der einmal im Monat eine Freigabe erteilt. Beide brauchen dasselbe System und ganz unterschiedliche Dinge davon.
Die naheliegende Antwort darauf ist ein Kompromiss in der Mitte. Ich halte das für die schlechteste aller Optionen, weil das Ergebnis für beide Gruppen nicht passt. Die bessere Antwort ist, die Bedienung zu schichten: ein zugänglicher, geführter Weg für Gelegenheitsnutzer und darauf aufbauend eine Beschleunigungsschicht für die, die täglich darin leben.
Konkret sind das Dinge, die in vielen modernen Enterprise-Anwendungen fehlen, obwohl ihre Vorgänger sie hatten. Eine durchgängige Tastaturbedienung mit vorhersagbarer Reihenfolge, sodass ein geübter Nutzer eine Maske ohne Maus ausfüllen kann. Massenbearbeitung, statt vierzig Vorgänge einzeln zu öffnen. Gespeicherte Sichten und Filter, damit sich jeder seinen Arbeitsvorrat einmal einrichten kann statt jeden Morgen neu. Eine umschaltbare Informationsdichte, damit derselbe Screen luftig oder kompakt sein kann. Rollenspezifische Masken, wodurch die Aufgaben sich wirklich unterscheiden. Und Tastenkürzel, die sichtbar sind, statt sich als Geheimwissen zu verbreiten.
Von "progressive Disclosure" als Antwort halte ich dabei wenig, jedenfalls in ihrer üblichen Anwendung. Funktionalität hinter Klicks zu verstecken, löst das Problem der ersten Stunde und verlängert dafür jeden einzelnen der folgenden Vorgänge. Was wir brauchen, ist nicht Verstecken, sondern Belohnen: Wer das System beherrscht, soll dafür schneller sein können, nicht nur weniger verwirrt.
Diese Unterscheidung zu treffen ist unbequem, weil sie Arbeit macht. Man muss den Fachprozess verstanden haben, um sagen zu können, welche Komplexität aus ihm stammt und welche aus uns. Wer diese Arbeit nicht leistet, landet in einem von zwei Fehlern. Entweder erklärt man alles zu essenzieller Komplexität und verkauft die eigene Nachlässigkeit als Fachlichkeit. Oder man erklärt alles zu akzidenteller Komplexität und amputiert den Prozess so lange, bis die Oberfläche den Richtlinien entspricht und die Fachabteilung doch wieder mit Excel arbeitet.
Mein Appell ist daher nicht, ab morgen wieder Software zu bauen, die eine wochenlange Einführung braucht. Mein Appell ist, Software wieder offener zu denken. Uns nicht von scheinbar allgemeingültigen Gesetzen treiben zu lassen. Anzuerkennen, dass es Software gibt, die komplex sein darf, weil sie nur so ihre Stärken ausspielen kann. Und anzuerkennen, dass diese Art von Software im Enterprise-Kontext deutlich häufiger vorkommt als im privaten Umfeld, weshalb wir sie mit anderen Maßstäben bewerten müssen.
Wir dürfen keine Angst davor haben, Software wieder komplexer werden zu lassen, wenn diese Komplexität einem Ziel dient und uns hilft, dieses Ziel schneller und sicherer zu erreichen.
Es liegt an uns zu erkennen, in welchem Umfeld unsere Software eingesetzt wird. Wer die Nutzer sind, woher sie kommen, welches Vorwissen sie mitbringen und wie wir sie am besten unterstützen. Wenn das bedeutet, dass wir uns von dem lösen müssen, was man normalerweise für gutes Interface Design hält, dann sollten wir das tun. Denn das eigentliche Ziel war nie, eine Richtlinie zu erfüllen. Es war, die Schnittstelle zwischen Mensch und Maschine so zu gestalten, dass Nutzer ihre Ziele mit minimalem Aufwand und minimaler Fehlerquote erreichen.
