Komplexität im Human Interface Design
Komplexität im Human Interface Design: Organisation von Funktionalität
Organisation von Funktionalität

Komplexität im Human Interface Design: Organisation von Funktionalität

Softwareteams sehen sich oft mit einem Paradoxon konfrontiert – sie sollen Apps gestalten, die über immer mehr Funktionalität verfügen, aber gleichzeitig so übersichtlich und einfach zu bedienen sind, dass sie von Erstbenutzern ohne Anlaufschwierigkeiten verwendet werden können. In diesem Beitrag betrachten wir einige Ansätze und Fallbeispiele, wie Interface Designer mit dieser Komplexität umgehen.

Die Benutzeroberfläche einer App oder Plattform ist die Schnittstelle, an der die technischen Vorgänge der Software und die Realität des Benutzers aufeinandertreffen – somit hat sie einen signifikanten Einfluss darauf, wie wir mit der Software interagieren. Die Disziplin des User Interface Design beschäftigt sich damit, diese Benutzeroberflächen so zu konzipieren, dass sie von uns möglichst mühelos verwendet werden können.

Bei kleineren Apps mit überschaubarem Funktionsumfang ist diese Aufgabe oft verhältnismässig einfach zu erledigen, bei grösseren Programmen ergeben sich jedoch einige Herausforderungen:

  • Wie können wir alle wichtigen Funktionen für die Benutzer sichtbar oder nur wenige Klicks entfernt halten, aber die Benutzeroberfläche übersichtlich und simpel gestalten, damit die Benutzer nicht überfordert sind?
  • Wo macht es Sinn, Patterns über die ganze Applikation (oder auch durch Konventionen über verschiedene Apps) hinweg konsistent zu halten, und wo nicht?
  • Wie gestalten wir Benutzeroberflächen, die für mehrere unterschiedliche Nutzergruppen einfach zu lernen sind? (Beispielsweise eine Unternehmerin und ein Treuhänder, die im selben Buchhaltungsprogramm unterschiedliche Aufgaben erledigen möchten)

Mit diesen drei grundlegenden Fragen möchten wir uns in dieser Spark-Serie zum Designen von komplexen Benutzeroberflächen näher beschäftigen und beginnen in diesem Beitrag gleich mit der ersten: Wie managen wir den Trade-Off zwischen möglichst vielen Möglichkeiten auf einen Blick und einem möglichst übersichtlichen User Interface?

Das Problem von «Bloated Interfaces»

Entwicklungsteams realisieren oft nicht, wenn die Benutzeroberflächen ihrer Software für Endbenutzer zunehmend komplizierter werden, und bemerken oft zu spät, dass die Software an einen Punkt angelangt ist, an dem sie neue Benutzer durch ihre Fülle abschreckt. Es ist daher wichtig, laufend zu evaluieren, wie bedienfreundlich und übersichtlich die Benutzeroberfläche auf Erstbenutzer wirkt, und wenn nötig eine robustere Organisationsstruktur für die Funktionalität zu schaffen.

Eine Benutzeroberfläche mit sehr vielen Steuerelementen, die sehr unübersichtlich und auf den ersten Blick überfordernd wirkt
Ein Extrembeispiel – das überfüllte User Interface des Programmes «FileMatrix» überfordert die meisten Benutzer beim ersten Anblick. Bildquellen: G. Nickerson, A. Papadimoulis’ .NET Blog

Komplexität verstecken – der naive Ansatz

Das Entwicklerteam hinter Microsoft Office 2000 fühlte sich auch mit genau diesem Problem konfrontiert: Durch die zunehmende Komplexität in Programmen wie Word oder Excel fühlte sich die Software für die Nutzer zunehmend überfüllt und chaotisch an. Mit jedem Release fügte Microsoft neue Features hinzu, die von den Kunden gewünscht wurden, aber nur wenige konnten diese im überfüllten Interface dann auch finden.

Der erste Ansatz von Microsoft nannte sich «IntelliMenu» – ein Interface-Pattern, bei dem eine arbiträre Auswahl an weniger oft verwendeten Befehlen standardmässig versteckt und erst durch einen zusätzlichen Klick sichtbar wurden. So sollte das Gefühl der Nutzer, dass das Programm überfüllt sei, reduziert werden.

Das Tools-Menü in Microsoft Word 2000 mit einigen ausgeblendeten Optionen, die über einen Pfeil ausgeklappt werden können.,
Adaptive Menüs in Microsoft Word 2000. Eine Auswahl an Befehlen wurde hinter einer Ausklappen-Option versteckt. Bildquelle: Danny Cohen

Was in der Theorie erst einmal nicht so schlecht klingt, hat sich in der Praxis nicht bewährt: Nicht nur fanden Benutzer die «versteckten» Features kaum mehr, wenn sie diese doch einmal benötigten, auch die Wahrnehmung der Komplexität hatte sich nur minimal reduziert, was eigentlich niemanden überraschen sollte, da die tatsächliche Komplexität auch nicht verringert wurde.

Komplexität hinter Hamburger-Menüs verstecken

Ein moderneres Pattern, das häufig in mobilen Benutzeroberflächen verwendet wird, aber auch zunehmend seinen Weg in Desktop-Applikationen wie Dropbox oder Figma gefunden hat, ist das «Hamburger-Menü». Die Navigationselemente einer App werden dabei kurzerhand in ein Off-Screen-Menü verfrachtet, das über einen Button – oftmals dargestellt durch drei horizontale Striche, wodurch das Menü seinen Namen erhält – geöffnet wird.

Drei horizontale Striche, die ein Hamburger-Menü repräsentieren

Hamburger-Menüs können, wenn richtig eingesetzt, vor allem auf mobilen Webseiten durchaus sinnvoll sein, wenn nur sehr limitierter Bildschirmplatz vorhanden ist und die Navigation ohnehin primär über Links im Inhalt vorangetrieben wird. Als Navigationsmuster in Apps, bei denen man regelmässig zwischen einzelnen Teilen der App wechseln möchte, eignet sich das Hamburger-Menü allerdings zumindest für Hauptnavigationspunkte aus mehreren Gründen schlecht:

  • Nutzer können nicht auf einen Blick sehen, wo sie gerade sind und wo sie in der App hingelangen können (im Human Interface Design nennen wir dies «Discoverability»).
  • Jedes Wechseln zwischen Teilen der App erfordert einen zusätzlichen Tipp.
  • Hamburger-Menüs kollidieren mit Back-Buttons, die oft an dieselbe Stelle kommen.
  • Wie bei Microsofts IntelliMenu wird die Komplexität hier nicht behandelt, sondern nur in einem Menü versteckt, um eine Illusion von Übersichtlichkeit zu erschaffen.

Eine bessere Alternative zu Hamburger-Menüs in mobilen Apps ist die Verwendung einer Tableiste am unteren Bildschirmrand. Diese erlaubt Nutzern, sich jederzeit in der App zu orientieren, und mit einem Tipp zu einem anderen Programmteil zu wechseln.

Vergleich der Google-Maps App mit Hamburger-Menü zuvor und einer Tableiste danach
Sogar Google ist mittlerweile von ihrer früheren Obsession, alle Funktionalität ihrer Apps hinter Hamburger-Buttons zu verstecken, auf den Boden der Vernunft zurückgekehrt und bringt mit der «Bottom Bar» eine Navigation mit deutlich besserer Discoverability in die Google Maps und Fotos-App.

Der limitierte horizontale Platz auf der Tableiste führt zudem dazu, dass ein Produktteam sich intensiver damit befassen muss, die Navigationsstruktur der App auf maximal fünf Punkte auf der höchsten Ebene zu vereinfachen, anstatt alle Punkte einfach in ein Off-Screen-Menü packen zu können.

«All types of drawers have a nasty tendency to fill with junk»

Mike Stern, User Experience Design bei Apple

User Testing bei Spotify hat gezeigt, dass Navigationspunkte bis zu 30% öfter angewählt werden, wenn eine Tableiste anstelle eines Hamburger-Menüs verwendet wird, weshalb sie und viele weitere Apps mittlerweile zunehmend andere Navigationssysteme bevorzugen.

Vergleich der Spotify-App mit einem Hamburger-Menü vor 2016 und die aktuelle Darstellung mit einer Tableiste
Spotify wechselte im Jahr 2016 nach intensivem User Testing vom Hamburger-Menü zu einer Navigationsleiste. Die Tests zeigten, dass Benutzer mit der neuen Navigation bis zu 30% öfter andere Menüpunkte anwählen. Bildquellen: Hampus Nilsson, MacStories

Progressive Disclosure

Wie können wir die Komplexität im Interface nun tatsächlich vernünftig organisieren, anstatt sie nur hinter einem Allzweckmenü zu verstecken? Ein nützliches Interaction Pattern, das wir verwenden können, ist «Progressive Disclosure». Dabei werden Informationen, Befehle und Optionen schrittweise über mehrere Screens verteilt und erst dann gezeigt, wenn sie wirklich benötigt werden. Dadurch wird die kognitive Last bei den Nutzern, die mit dem Interface interagieren, reduziert, weil sie mit weniger Optionen gleichzeitig konfrontiert sind.

Ohne progressive Disclosure wird aus einer langen Liste von einzelnen Transportationsmöglichkeiten ausgewählt. Mit progressive Disclosure wird zuerst gefragt, ob die Transportmethode auf dem Land oder in der Luft sein soll, bei Landtransport ob Fuel-betrieben oder nicht, und erst dann werden kleinere Optionssets angezeigt.
Progressive Disclosure vereinfacht Entscheidungen, indem lange Listen von Optionen durch kleinere ersetzt werden. Man zeigt zu jedem Zeitpunkt nur die notwendigsten Auswahloptionen. Bildquelle: Apple WWDC Session «Designing intuitive user experiences»

In der Praxis kann dieses Pattern vielseitig angewendet werden, hier nur einige wenige Beispiele:

  • Vorschau von Inhalten oder Überkategorien mit «Mehr erfahren»-Option
  • Gestaffelte Auswahlmenüs
  • Aufteilen von komplexen Interaktionen in mehrere Schritte mit Fortschrittsbalken
Einstellungen-App auf dem iPhone, zuerst der Screen mit allen Überkategorien, dann der Screen "Wi-Fi", der nur die ausgeschaltete Option "Wi-Fi" beinhaltet, und bei aktivierter Option ein Screen mit weiteren Wi-Fi-Einstellungen.
Beispiel von Progressive Disclosure in den iPhone-Einstellungen. Bildquelle: weloveuxd

Panels und temporäre UI

Eine Variante, um Progressive Disclosure umzusetzen, sind Panels und temporäre Fenster oder Symbolleisten, die vom Benutzer geöffnet werden können oder kontextuell erscheinen.

Zum Beispiel können im Videoschnittprogramm Final Cut Pro X mit einem Klick Panels für Effekte, Übergänge oder Farbkorrekturen bei Bedarf geöffnet und wieder geschlossen werden.

So bleibt den Benutzern mehr Platz für die restlichen Workflows, wenn die Panels geschlossen sind, aber die Optionen bleiben dennoch in Sichtweite (gute Discoverability) und können schnell aufgerufen werden.

Ein zu grosszügiger Umgang mit temporärer UI – besonders wenn diese automatisch kontextuell erscheint – kann jedoch dazu führen, dass Benutzer viel Aufwand in das Managen dieser Fenster investieren müssen. Es gilt also eine delikate Balance zu finden.

Beispiel einer verbreiteten Finanzbuchhaltungssoftware. Es entsteht bei der Verwendung viel temporäre UI, die vom Anwender gemanagt werden muss.

Ein gelungenes Beispiel für temporäre UI ist die Mini Toolbar in Microsoft Word, die in Office 2007 eingeführt wurde. Beim Markieren von Text erscheinen häufig verwendete Formatierungsoptionen direkt beim Cursor. Der Benutzer muss dieses Fenster nicht managen, da es bei einer Auswahl von selbst erscheint und wieder verschwindet, wenn man die Maus davon wegbewegt oder den Text wieder abwählt.

Mini Toolbar in Microsoft Word, die automatisch beim Markieren von Text erscheint und eigenständig wieder verschwindet, wenn man die Maus vom Text wegbewegt.

Gruppieren von Funktionalität nach Themen oder Workflows

Eine weitere Möglichkeit, um Komplexität in einem Interface zu organisieren, ist die Gruppierung von Funktionalität in grobe Kategorien oder über ganze Applikationsteile hinweg.

Nachdem mit IntelliMenu in Office 2000 das Problem der Auffindbarkeit der Befehle nicht gelöst werden konnte, hat das Microsoft Office UI-Team mit Office 2007 das Ribbon eingeführt – eine Leiste am oberen Bildschirmrand, die die Befehle aus allen anderen Menüs und Toolbars an einem Ort zusammenführt und in klar verständliche Gruppen einordnet. User Testing und Zufriedenheitsumfragen bei Käufern haben gezeigt, dass die Office-Programme durch das neue Interface als einfacher zu bedienen und weniger komplex wahrgenommen wurden.

Ribbon in Microsoft Word Online. Alle Funktionen des Programms sind in dieser Leiste zu finden und sind in klar verständliche Gruppen wie «Einfügen» oder «Layout» eingeteilt.

Aus diesem Grund wird das Ribbon auch noch heute, bald 15 Jahre später, aktiv in Office eingesetzt. In der Online-Version und in Outlook wurde es mit einer einklappbaren, einzeiligen Version sogar noch weiter vereinfacht. Auch andere komplexe Programme wie die CAD-Software AutoCAD oder die Dateitransfersoftware SmartFTP nutzen das Ribbon, um eine Vielzahl von Befehlen zu organisieren. Nicht allen Entwicklern gelingt es allerdings, das Ribbon ebenso gut umzusetzen, da es nicht einfach ist, alle Funktionen so zu kategorisieren, dass sie auch den Nutzererwartungen entsprechen.

Arbeitsbereiche für Workflows

Ein ähnlicher Effekt kann auch mit unterschiedlichen Arbeitsbereichen innerhalb einer Applikation erzielt werden. Dabei wird eine globale Navigation hinzugefügt und es werden Bereiche geschaffen, die möglichen Workflows eines Benutzers entsprechen. In den jeweiligen Arbeitsbereichen werden dann standardmässig diejenigen Funktionen gezeigt, die zu diesem Workflow passen. Nennenswerte Beispiele für diesen Ansatz sind die Kompositionssoftware Dorico, das 3D-Programm Blender oder auch das Videoschnittprogramm Premiere Pro.

Verschiedene Tabs in der Musiksoftware Dorico. Die sichtbaren Funktionen im Programm unterscheiden sich je nachdem, in welchem Bereich sich der Benutzer befindet. Bildquelle: Steinberg
Workspaces in der 3D-Software Blender. Durch die Auswahl verschiedener Tabs wie «Modeling», «Sculpting» oder «Animation» verändert sich das Interface und die dargestellten Funktionen, damit die häufig verwendeten Befehle und Panels für den jeweiligen Workflow einfach erreichbar sind.

User Testing

Diese verschiedenen Ansätze sollen als Denkanstoss verstanden werden, wie die Organisation von Funktionalität innerhalb einer umfangreichen Software gehandhabt werden kann. Es gibt keine goldene Regel, wo genau jede Applikation auf dem Spektrum zwischen Effizienz und Übersichtlichkeit landen muss – das ist auch abhängig von der Zielgruppe (z.B. Consumer oder Professional). Die beste Evaluation, ob der gewählte Aufbau eines User Interfaces gut funktioniert, ist letzten Endes der Test mit echten Nutzern, die auf die Software angewiesen sind.

Im nächsten Beitrag dieser Serie befassen wir uns dann mit der Frage, wo wir in einem Interface konsistent sein sollten und wann es möglich oder gar sinnvoll ist, mit Konventionen oder eigenen Regeln zu brechen.