Nicht alles auf einmal: Progressive Disclosure in der Praxis

Viele Unternehmen investieren erheblich in die Einführung neuer Software – und stellen Monate später fest, dass ein Großteil der Funktionen schlicht nicht genutzt wird. Die übliche Reaktion: mehr Schulungen. Die eigentliche Ursache liegt oft woanders, nämlich im Interface selbst.

Software, die Nutzer beim ersten Öffnen mit Dutzenden Optionen, Feldern und Menüpunkten konfrontiert, erzwingt eine kognitive Priorisierungsarbeit, die nichts mit der eigentlichen Aufgabe zu tun hat. Das menschliche Arbeitsgedächtnis kann nur eine begrenzte Anzahl von Elementen gleichzeitig verarbeiten. Software, die das Arbeitsgedächtnis jedoch überfordert, steht einem konzentrierten Arbeiten im Weg.

Das Designprinzip, das dagegen hilft, heißt Progressive Disclosure. Es ist älter als das iPhone, wird von den meisten erfolgreichen digitalen Produkten der Welt angewendet – und in vielen Unternehmenssoftwaresystemen bis heute konsequent ignoriert.

Was Progressive Disclosure bedeutet

Das Konzept ist einfach: Zeige Nutzern zunächst nur das, was sie für den aktuellen Schritt brauchen. Alles Weitere wird erst sichtbar, wenn es relevant wird: auf Anfrage, durch eine Aktion oder automatisch basierend auf dem, was der Nutzer zuvor getan hat.

Die Methode funktioniert, weil die Tatsache, dass etwas auf der ersten Ebene erscheint, dem Nutzer bereits eine Information gibt: Das hier ist wichtig. Dieser Umstand kommt nicht nur neuen Nutzer:innen zugute, die direkt wissen, worauf sie sich konzentrieren sollen, sondern auch erfahrenen Nutzer:innen, die nicht nicht an Dingen vorbeiscannen müssen, die sie nie brauchen.

Vier Ausprägungen in der Praxis

Progressive Disclosure ist kein einzelnes Interface-Element, sondern ein Prinzip, das sich auf verschiedene Weisen umsetzen lässt.

Conditional Disclosure zeigt Felder und Optionen erst, wenn eine vorherige Auswahl sie relevant macht. Ein Formular, das nach der Unternehmensform fragt, blendet Felder zur Umsatzsteuer-ID erst dann ein, wenn die Option “Unternehmen” gewählt wurde. Privatpersonen sehen diese Felder nie. Das reduziert neben der visuellen Komplexität auch Fehleingaben.

Contextual Disclosure liefert zusätzliche Informationen genau dann, wenn sie für den aktuellen Kontext relevant sind. Ein Wareneingangsprozess in einer Logistiksoftware, der Zollrelevanz erst abfragt, wenn ein bestimmtes Herkunftsland gewählt wurde, ist ein Beispiel dafür. Niemand muss eine Option bewusst überspringen, die für seinen Fall gar nicht gilt.

Progressive Enabling aktiviert Interaktionsmöglichkeiten schrittweise, anstatt sie von Anfang an verfügbar zu machen. Ein “Weiter”-Button bleibt inaktiv, bis alle Pflichtfelder ausgefüllt sind. Eine erweiterte Exportfunktion schaltet sich erst frei, wenn ein Nutzer die Basisfunktion genutzt hat. Das Prinzip ist eng mit Gamification-Mechanismen verwandt – und aus denselben Gründen wirksam.

Staged Disclosure teilt komplexe Prozesse in diskrete Schritte auf, bei denen jeweils nur der aktuelle Schritt sichtbar ist. Mehrstufige Formulare, Einrichtungsassistenten und Onboarding-Flows funktionieren nach diesem Prinzip. Der Nutzer sieht nie alle Schritte gleichzeitig, sondern bewegt sich durch eine logische Abfolge mit klarem Fokus auf das, was jetzt zu tun ist.

Drei Kostenfaktoren, die selten so benannt werden

Wenn Nutzer zu viel auf einmal sehen, entstehen konkrete betriebliche Konsequenzen.

Zuerst zu nennen sind längere Einarbeitungszeiten. Software, die Komplexität nicht stufenweise einführt, erzwingt intensive Schulungen. Unternehmen, die komplexe Plattformen wie ERP- oder CRM-Systeme einführen, berichten regelmäßig von mehrtägigen Trainingsmaßnahmen, nach denen die Akzeptanz trotzdem gering bleibt. Der Grund: Wissen, das nicht im Kontext der Arbeit erworben wird, wird nicht behalten. Die unmittelbare Anwendung neu erworbenen Wissens ist dagegen förderlich für den Lerneffekt.

Dazu kommen höhere Fehlerquoten. Kognitive Überlastung führt häufig zu falschen Klicks. In Geschäftsprozessen, die auf korrekte Dateneingabe angewiesen sind, haben diese Fehler direkte operative Konsequenzen.

Zuletzt ergibt sich eine geringe Nutzungstiefe. Features, die Nutzer nicht finden oder nicht verstehen, werden nicht genutzt. Das betrifft häufig genau jene Funktionen, für die am meisten Entwicklungsaufwand betrieben wurde. Das Ergebnis ist eine teure Software, die im Alltag wie eine weitaus einfachere genutzt wird – für die das Unternehmen trotzdem die volle Lizenz zahlt.

Was vorne steht – und wer das entscheidet

Die schwerste Aufgabe bei der Umsetzung von Progressive Disclosure inhaltlicher Natur: Was gehört in die erste Ebene, was in die zweite?

Diese Frage lässt sich nicht am Schreibtisch beantworten. Sie erfordert ein Verständnis darüber, was Nutzer tatsächlich tun – nicht was sie tun sollten, nicht was das Produktteam sich vorstellt, dass sie tun, sondern was sie im Arbeitsalltag wirklich tun. Nutzungsstatistiken, Beobachtungen, Interviews: Das sind die Quellen, auf die sich eine solche Entscheidung stützen muss. Ein gründlicher Research-Prozess ist daher unumgänglich.

In Projekten zeigt sich regelmäßig, dass die Einschätzung von Teams darüber, welche Funktion am häufigsten genutzt wird, und die tatsächliche Nutzung stark voneinander abweichen. Was intern als “Kernfunktion” gilt, ist aus Nutzersicht oft ein Sonderfall (und umgekehrt).

Im tatsächlichen Design lassen sich diese Erkenntnisse über die Häufigkeit der genutzten Funktionen dann übersetzen, indem sie bestimmen, was auf der ersten Ebene sichtbar ist und was dahinter liegt. Häufig benötigte Funktionen gehören nach vorne – alles, was nur gelegentlich relevant ist, kommt in eine zweite Ebene. Was darüber hinausgeht, in eine dritte.

Rollenstrukturen als zusätzliche Dimension

Business-Software bedient selten eine homogene Nutzergruppe. Ein typisches ERP-System hat, je nach Unternehmenskontext, gleichzeitig Sachbearbeiter, Buchhalter, Lageristen, Controller und Administratoren als Nutzer – jede Gruppe mit anderen Aufgaben, anderen Wissensständen und anderen Bedürfnissen.

Progressive Disclosure lässt sich auf diese Rollenstruktur anwenden: Was für einen Administrator sichtbar sein muss, muss für einen Sachbearbeiter nicht einmal existieren. Was ein erfahrener Nutzer in drei Klicks erledigen will, sollte ein neuer Nutzer Schritt für Schritt geführt durchlaufen können.

Das ist keine Funktion, die sich einfach „zuschalten“ lässt. Es erfordert eine strukturelle Entscheidung darüber, wie das Interface mit Rollen, Erfahrungsstufen und Kontexten umgeht. Wie bereits erwähnt, sollten auch diese Entscheidungen durch Research fundiert sein.

Fazit

Progressive Disclosure ist kein Designtrend und keine Meinungsfrage, sondern eine Antwort auf ein messbares Problem: Software, die zu viel auf einmal zeigt, wird schlechter genutzt, führt zu mehr Fehlern und erfordert mehr Schulungsaufwand.

Dass das Prinzip in Unternehmenssoftware nach wie vor so konsequent fehlt, liegt meistens daran, dass die Frage „Was gehört nach vorne?“ keine einfache Antwort hat. Sie erfordert Nutzerdaten, die oft nicht vorliegen, und ein Design- und Entwicklungsteam, welches bereit ist, diese Entscheidungen auch zu treffen. Dafür ist ein Dialog mit den betroffenen User:innen und anderen Stakeholder:innen erforderlich. In dieser Frage zeigt sich also einmal mehr, dass gutes UX Design nur entstehen kann, wenn auch die Organisationsstruktur als Rahmenbedingung mitspielt.