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:
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?
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.
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.
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.
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.
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:
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.
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.
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.
In der Praxis kann dieses Pattern vielseitig angewendet werden, hier nur einige wenige Beispiele:
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.
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.
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.
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.
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.
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.
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.
