Die goldenen Regeln des Interface-Designs (2013)
(cs.umd.edu)- Ben Shneidermans 8 Prinzipien des Interface-Designs sind praktische Kriterien, die sich auf die meisten interaktiven Systeme anwenden lassen, erfordern aber je nach Designbereich eine Überprüfung und Anpassung
- Konsistente Begriffe und Abläufe, universelle Nutzbarkeit und informatives Feedback sind Grundvoraussetzungen dafür, dass Nutzer Zustandsänderungen vorhersagen und verstehen können
- Arbeitsabläufe sollten zu Einheiten mit Anfang, Mitte und Ende gebündelt werden; zum Abschluss sollte eine klare Bestätigung erfolgen, damit Nutzer leichter zur nächsten Handlung übergehen können
- Bei Fehlern hat Prävention Vorrang; treten sie dennoch auf, sollten konkrete Hinweise zur Wiederherstellung und ein einfaches Rückgängigmachen die Unsicherheit der Nutzer reduzieren
- Wenn Kontrollgefühl und geringe Gedächtnisbelastung im Zentrum stehen, lassen sich Produktivität und Souveränität in mobilen, Desktop- und Web-Interfaces steigern
Charakter der Prinzipien und Anwendungsbereich
- Ben Shneiderman hat umfangreiches Wissen zur Gestaltung von User Interfaces in einige Golden Rules verdichtet und als Leitlinien formuliert, die auf die meisten interaktiven Systeme anwendbar sind
- Diese Prinzipien stammen aus der Erfahrung und wurden über mehr als 30 Jahre verfeinert, in bestimmten Designbereichen sind jedoch eine separate Überprüfung und Anpassung nötig
- Auch die frühe Liste von 1985 wurde von Studierenden und Designern als nützliche Orientierung angenommen; Jakob Nielsen, Jeff Johnson und andere ergänzten Varianten und Erweiterungen
- Diese Version stammt aus Abschnitt 3.3.4 von Designing the User Interface: Strategies for Effective Human-Computer Interaction: Sixth Edition
8 goldene Regeln des Interface-Designs
-
Konsistenz anstreben
- In ähnlichen Situationen braucht es konsistente Handlungsabfolgen
- In Prompts, Menüs und Hilfebildschirmen sollten dieselben Begriffe verwendet werden
- Auch Farben, Layout, Großschreibung und Schriftarten sollten insgesamt konsistent sein
- Ausnahmen wie Bestätigungen für Löschbefehle oder das Nichtanzeigen bei der Passworteingabe sollten verständlich und begrenzt sein
-
Universelle Nutzbarkeit anstreben
- Es braucht ein flexibles Design, das die Anforderungen verschiedener Nutzer erkennt und die Umwandlung von Inhalten erleichtert
- Unterschiede zwischen Einsteigern und Experten, Altersgruppen, Behinderungen, internationale Unterschiede und technische Vielfalt erweitern den Anforderungsbereich
- Erklärungen für Einsteiger sowie Tastenkürzel und Funktionen zum schnellen Vorankommen für Experten erhöhen die wahrgenommene Qualität des Interfaces
-
Informatives Feedback geben
- Auf jede Nutzerhandlung sollte Feedback des Interfaces folgen
- Bei häufigen, kleinen Handlungen reicht eine einfache Reaktion aus, bei seltenen und wichtigen Handlungen ist eine substanziellere Reaktion nötig
- Wenn das Objekt von Interesse visuell dargestellt wird, lassen sich Änderungen leichter klar zeigen
-
Dialogabläufe mit Abschlussgefühl gestalten
- Arbeitssequenzen sollten in Gruppen mit Anfang, Mitte und Ende organisiert werden
- Informatives Feedback am Ende einer Arbeitsgruppe vermittelt Erfolgserlebnis, Erleichterung und das Signal, für die nächste Aufgabe bereit zu sein
- Bei E-Commerce-Websites ist ein Beispiel der Ablauf von der Produktauswahl zur Zahlung und der Abschluss der Transaktion über eine klare Bestätigungsseite
-
Fehler vermeiden
- Wo immer möglich sollte das Interface so gestaltet sein, dass Nutzer keine schwerwiegenden Fehler machen können
- Beispiele sind das Deaktivieren ungeeigneter Menüeinträge oder das Nichtzulassen alphabetischer Zeichen in numerischen Eingabefeldern
- Wenn ein Fehler auftritt, sollten einfache, konstruktive und konkrete Hinweise zur Wiederherstellung gegeben werden
- Wegen einer einzigen falschen Postleitzahl sollte nicht das gesamte Namens- und Adressformular erneut eingegeben werden müssen; stattdessen sollte nur die fehlerhafte Stelle korrigiert werden
- Fehlhandlungen sollten den Zustand des Interfaces nicht verändern oder eine Möglichkeit bieten, den Zustand wiederherzustellen
-
Einfaches Rückgängigmachen ermöglichen
- Handlungen sollten so weit wie möglich rückgängig gemacht werden können
- Rückgängigmachen gibt Nutzern die Gewissheit, Fehler widerrufen zu können, reduziert Unsicherheit und ermutigt dazu, auch unbekannte Optionen zu erkunden
- Die Einheit des Rückgängigmachens kann eine einzelne Handlung, eine Dateneingabeaufgabe oder eine Aufgabengruppe wie ein Namens- und Adressblock sein
-
Nutzer die Kontrolle behalten lassen
- Erfahrene Nutzer möchten stark das Gefühl haben, dass sie das Interface kontrollieren und das Interface auf ihre Handlungen reagiert
- Unerwartete Änderungen, Änderungen vertrauter Abläufe, mühsame Dateneingaben, Schwierigkeiten beim Abrufen benötigter Informationen und Situationen, in denen gewünschte Ergebnisse nicht erreicht werden können, verunsichern Nutzer
-
Belastung des Kurzzeitgedächtnisses reduzieren
- Die Informationsverarbeitungskapazität des menschlichen Kurzzeitgedächtnisses ist begrenzt; als Faustregel kann man sich etwa „7±2 Chunks“ merken
- Interfaces sollten vermieden werden, bei denen Nutzer Informationen von einem Bildschirm behalten und auf einem anderen verwenden müssen
- Mobiltelefone sollten keine erneute Eingabe von Telefonnummern verlangen, die Position auf einer Website sollte weiterhin angezeigt werden, und lange Formulare sollten so verdichtet werden, dass sie auf einen Bildschirm passen
Praktische Maßstäbe für Designer
- Diese Prinzipien müssen passend zur jeweiligen Umgebung interpretiert, verfeinert und erweitert werden
- Trotz ihrer Grenzen sind sie ein guter Ausgangspunkt für Designer von mobilen, Desktop- und Web-Interfaces
- Vereinfachte Dateneingabe, verständliche Anzeigen sowie schnelles und informatives Feedback zielen darauf ab, die Produktivität der Nutzer zu erhöhen
- Ein gutes Interface sollte Nutzern helfen, sich im Umgang mit dem System kompetent, souverän und in Kontrolle zu fühlen
1 Kommentare
Hacker-News-Kommentare
Performance wird ebenfalls oft übersehen, auch wenn sie nicht unbedingt als Teil des „Designs“ einer UI gilt.
Eine UI mit schlechter Performance bricht im Grunde all diese Designregeln. Mein Sony-Android-Smart-TV sieht großartig aus, aber die UI ist so langsam, dass sie praktisch unbenutzbar ist.
Auch eine sich ständig ändernde, instabile UI verletzt die meisten Prinzipien. Smart-TVs sind auch darin besonders schlecht: Das Layout des Startbildschirms und die Positionen der App-Icons ändern sich häufig ohne ersichtlichen Grund.
Dazu kommt ein persönlicher Ärger, der immer schlimmer wird: Icons ohne Beschriftung. Oft gibt es nicht einmal Tooltips, und wenn man die Dokumentation googeln muss, um den Namen eines Buttons herauszufinden, ist das UI-Design schlecht.
Junge Nutzer strömen zu schwer bedienbaren Interfaces, und diese Unverständlichkeit funktioniert wie ein Insider-Feature, das die Elterngeneration ausschließt.
Gute Designer besprechen mit Entwicklern, welche Auswirkungen die von ihnen vorgeschlagene UI auf die Performance hat, und helfen bei Kompromissen, wenn Engineering technische Entscheidungen trifft, die für Nutzer sichtbar werden.
Die UI hatte nicht nur Hunderte kleiner Icons, auch in der Dokumentation wurden genau diese Icons verwendet. Das Handbuch las sich etwa wie: „Klicken Sie zuerst auf [], drücken Sie dann [], gehen Sie schließlich zu [] und führen Sie [] aus.“
Das war eine sehr frühe Version von V5 und ist lange her; ich hoffe, es ist inzwischen besser geworden.
Alles andere ist eher Codierung.
Ich höre jeden Morgen dieselben zwei Nachrichten-Podcasts, aber die Empfehlungen in der App werden jeden Morgen ohne jeden Grund durcheinandergewürfelt.
Noch nerviger ist, dass die App beim Start kurz das Layout von gestern zeigt, dann etwa eine Sekunde zum Laden einfriert und anschließend die Elemente neu anordnet. In genau diesem Moment tippe ich jedes Mal versehentlich auf ein sich bewegendes Element, was extrem frustrierend ist.
Ein Designer, mit dem ich vor ein paar Jahren zusammengearbeitet habe, hat hervorragend erklärt, warum Konsistenz wichtig ist.
Es geht nicht um eine begrenzte Farbpalette oder um eine Font-Auswahl, die ohnehin niemand bemerkt. Wenn man Detailregeln hinterherjagt, entsteht schreckliche Software. Manche glauben fälschlicherweise, je weniger Vielfalt eine UI habe, desto konsistenter sei sie.
Der Kern ist, dass Nutzer dadurch zu Experten der Software werden können.
Der Designer nannte Microsoft Office als Beispiel. Menschen sind stolz darauf, Microsoft Office zu „kennen“, und weil sie die Trägheit von „Office“ spüren, wechseln sie ganz selbstverständlich zwischen den verschiedenen Apps. Bei Vim habe ich dasselbe Gefühl. Man weiß einfach, wie etwas funktionieren sollte, und ein gut gemachtes neues Plugin respektiert dieses Muster normalerweise.
Office und (Neo)Vim sind keine Beispiele für herausragende UI, aber sie sind ungewöhnlich stabil.
Wenn man zum Beispiel vier Optionen anzeigen will, kann man eine durchsuchbare Checkbox-Combo-Box aus [Insert UI Library] mit Branding-Theme verwenden, oder man zeigt einfach normale Radio-Buttons oder Checkboxen mit Beschriftung an. Letzteres ist in jeder Hinsicht besser.
Nutzer erkennen allein an Kreis und Quadrat, ob sie eine oder mehrere Optionen auswählen können, sehen alle vier Optionen auf einmal, es gibt kein Problem, dass die mobile Tastatur zum „Suchen“ hochfährt und den kleinen Bildschirm weiter verdeckt, und die Barrierefreiheit liegt praktisch immer nahe bei 100 %.
Diese Option scheitert aber am Kriterium „passt hübsch zu unserem Designsystem“, weshalb Designer normalerweise die erste wählen – und schlimmer noch, diese Vorgehensweise standardisieren und die Nutzung normaler Widgets zum „Bug“ erklären.
Am Ende verehren zu viele „UX-Designer“ Ästhetik und Branding und opfern alles andere dafür. UI-Widgets sind nicht der Ort, um Marke oder Kreativität zu zeigen. Es ist so, als würde man eine eigene Schrift bauen, die jeden Buchstaben in die Form des Logos zwingt. Kunden ist wichtiger, ob sie ihre Arbeit erledigen können, als die Marke.
Es hat die Fähigkeit, benötigte Funktionen zu finden, massiv verschlechtert.
Es ist immer besonders, jemanden, der sich selbst nicht für technisch hält, extrem schnell durch Excel navigieren zu sehen.
Microsofts UI-Designregeln sind ziemlich beeindruckend. Dank jahrelanger Konsistenz können Menschen die Software weiter nutzen, auch wenn sie alle ein bis zwei Jahre upgraden. Das sage ich nicht, weil ich Microsoft-Fan wäre.
Der Kern eines Upgrades sind inkrementelle Änderungen, die die UX verbessern. Allerdings verstehe ich nicht, warum das Designteam nicht widersprochen hat, als Win 95 das Konzept „Rechtsklick überall für Eigenschaften und tiefere Einstellungen/Detailinformationen“ einführte. Es war nämlich eine unsichtbare Funktion, die den Nutzern nicht zeigte, ob ein Rechtsklick möglich ist. In den ersten paar Malen mit Win 95 hat offenbar niemand den Rechtsklick verstanden.
Ich stimme zu, dass Kompetenz relevant ist, aber es braucht noch etwas mehr Verbindung, warum Konsistenz zu Kompetenz führt.
Konsistenz bedeutet, dass sich das, was Nutzer bereits über das System wissen, wie Zinseszins auf andere Teile des Systems ausweitet. Wenn ein System konsistent ist, lernt man mit dem Aufwand für X und Y auch Z und W, weil sie auf dieselbe Weise funktionieren werden. In einem inkonsistenten System ist der Wert der bisherigen Lerninvestition deutlich geringer.
Office ist zumindest langfristig nicht stabil. Das berüchtigte Ribbon war eine traurige Abkehr von der stabilen und effizienten Word-UI, und Microsofts schwer nachvollziehbare Rückschritte auf der gesamten Windows-Plattform haben das Problem noch verschärft. Zum Beispiel das Entfernen der Menüleiste aus Anwendungen. Warum um alles in der Welt sie das getan haben, weiß ich nicht.
Eine weitere „Regel“, die ich mir wünschen würde, ist, dem Nutzer das konzeptionelle Modell offenzulegen.
Wenn man das konzeptionelle Modell eines Produkts nicht versteht, bleibt es immer verwirrend, egal wie gut die Icons beschriftet sind. Man stelle sich zum Beispiel ein Produkt mit dem Befehl „New Configuration“ vor: Schon was „Configuration“ bedeutet, ist unklar. Ist es eine Vorlage, mit der man andere Objekte definieren kann? Eine Möglichkeit, schnell zwischen mehreren Bündeln von Optionen zu wechseln? Ein Container wie ein Ordner?
Die UI sollte so gestaltet sein, dass Nutzer das konzeptionelle Modell allein durch das Erkunden der Oberfläche erschließen können. Das ist nicht immer einfach.
Der Punkt „Wenn ein Nutzer zum Beispiel eine falsche Postleitzahl eingibt, sollte man ihn nicht das ganze Name-und-Adresse-Formular erneut ausfüllen lassen, sondern ihn nur den fehlerhaften Teil korrigieren lassen“ ist für mich der größte Ärgerpunkt, und man sieht ihn immer noch häufig.
Auch bei mehrseitigen Formularen sollte dieses Prinzip beim Vor- und Zurücknavigieren eingehalten werden.
Wichtig ist auch: „Eine ungültige Aktion sollte den Zustand der Oberfläche nicht verändern; falls sie ihn verändert hat, sollte erklärt werden, wie man den ursprünglichen Zustand wiederherstellt.“
Auf kleinen Bildschirmen wie bei Smartphones und Uhren verlassen sich Designer immer stärker auf Icons, um Platz zu sparen. Viele Icons sind aber ungewohnt oder schwer zu interpretieren, manchmal erfährt man erst durch Antippen, was sie bedeuten. Für solche Icons muss es unbedingt eine Möglichkeit geben, nach einem Fehler zum ursprünglichen Zustand zurückzukehren.
Schon beim Einloggen mit E-Mail-Adresse und Passwort ist das ein Problem, aber wenn ich auf „Passwort vergessen“ klicke, sollte man mich bitte nicht auf ein Formular schicken, in das ich genau die gerade eingegebene E-Mail-Adresse noch einmal eintragen muss.
Bei „Unpassende Menüpunkte ausgrauen“ gibt es eine Bedingung.
Wenn nicht klar ist, warum etwas ausgegraut ist, sollte man es nicht tun. Der Befehl sollte aktiviert bleiben, und wenn er beim Anklicken gerade nicht verfügbar ist, sollte eine Fehlermeldung erklären, warum er nicht verfügbar ist. Nutzer herausfinden zu lassen, warum ein Befehl deaktiviert ist, ist frustrierend.
Die Ausnahme sind Fälle, in denen der Nutzer sonst wahrscheinlich erst nach erheblichem Zeitverlust erfährt, dass etwas nicht verfügbar ist.
Weiterführender Artikel dazu: https://medium.com/@vedranio/james-bond-and-the-design-of-di...
Das wirkt wie eine Lösung, die die Vorteile beider Seiten verbindet.
Eine To-do-App macht das so. Premium-Befehle sind visuell nicht von kostenlosen Befehlen zu unterscheiden, sodass man sie häufig anklickt, und jedes Mal erscheint ein Registrierungsdialog, der den gesamten Ablauf unterbricht.
Für mich ist das ein gravierender UI-Fehler.
Eine UI, die bestimmte Aktionen deaktiviert, ohne den Grund zu nennen, macht mich immer wütend.
Nielsens 10 Usability-Heuristiken sind ein guter Nordstern.
https://www.nngroup.com/articles/ten-usability-heuristics/
Die NN-Seite ist viel leichter aufzunehmen, knapper und hat auch ein deutlich besseres Seitenlayout.
Beide Texte enthalten beachtenswerte Informationen und Orientierung, aber es ist ironisch, dass die Originalseite jene altmodischen Konventionen mit gleicher Schriftgröße und Absatzgestaltung verwendet, die die NN-Seite hinter sich gelassen hat.
Frustrierend ist auch, dass Hacker News einige dieser Hinweise nicht befolgt. Wenn man einen bestehenden Beitrag bearbeitet und auf den „update“-Button klickt, ist das Feedback nicht klar genug. Vermutlich wird der Bildschirm neu gezeichnet.
UIs sollten aufhören, genau an der Stelle, die ich gerade auswählen wollte, etwas anderes einzuschieben und mich dadurch danebenklicken zu lassen.
Vielleicht verletzt das einige der vorherigen Regeln oder lässt sich dadurch abmildern, aber persönlich macht mich das wahnsinnig, und ich halte es für einen besonders schweren Fehler.
Eine wichtige Regel fehlt: Früher wirkte sie fast selbstverständlich, nämlich statische Informationen und Bedienelemente zu unterscheiden.
Außerdem sollte man nicht anwendbare Bedienelemente nicht verstecken, sondern ausgrauen. So lernen Nutzer, dass die Funktion existiert, wo sie sich befindet und welche Bedingungen erfüllt sein müssen, um sie zu verwenden.
Damit zusammenhängend sollte man sich nie auf Versteckspiel-UIs verlassen, bei denen etwas nur erscheint, wenn der Nutzer zufällig den Cursor darüber bewegt. Man will eine Aufgabe erledigen, nicht einen Adventskalender erkunden.
Eine goldene Regel, die ich gelernt habe: Nachdem die Oberfläche gezeichnet wurde, dürfen sich Elemente nicht unerwartet bewegen.
Google ist dabei besonders schlimm, wenn sich ein Button zwischen dem Heben des Daumens und dem Tippen auf den Bildschirm bewegt, aber Google ist nicht der einzige Fall.
Wenn ein Ziel erst innerhalb von etwa 0,25 Sekunden vor der Berührung neu erschienen ist, sollte kein Touch-Event erzeugt werden. Aufgrund der menschlichen Reaktionszeit kann man einen Button so schnell gar nicht gezielt anvisieren und antippen.
Das sind ganz offensichtlich goldene Regeln einer Utopie
Die meisten würden solchen Regeln wohl nicht widersprechen
Und dennoch dürften die meisten Entwickler schon mit Interfaces zu tun gehabt haben, die solche Regeln häufig verletzen. Nicht, weil sie sie nicht verstanden hätten oder nicht wollten, sondern weil die Kosten zu diesem Zeitpunkt zu hoch waren
Zum Beispiel ist Rückgängig machen sehr schwierig und nur möglich, wenn die Datenstrukturen unter der Anwendung von Anfang an darauf ausgelegt wurden. Bei der Fehlervermeidung ist es ähnlich: Schon genau zu wissen, was ein Fehler ist, ist schwierig und teuer, und perfektes Feedback in der Sprache der Nutzer zu geben, ist noch wesentlich komplexer