In seinem Buch The Design of Everyday Things beschreibt Don Norman fundamentale Prinzipien des UI-Designs. Folgende fünf Begriffe sind dabei essenziell:
- Affordances,
- Signifier,
- Constraints,
- Mapping,
- Feedback
Ich möchte diese Begriffe und vor allem ihre Bedeutung anhand anschaulicher Beispiele verdeutlichen und erklären. Schließlich ist es nicht nur für UI-Designer wichtig, sich mit den Benutzer:innen zu beschäftigen. Softwareentwickler und -architekten profitieren davon ebenfalls.
Affordances
Affordances werden in vielen Beiträgen leider falsch als der “Aufforderungscharakter” von Objekten beschrieben. Tatsächlich beschreiben Affordances die Möglichkeiten zur Interaktion, die ein Objekt anbietet (von englisch: to afford = etw. bieten).
Nehmen wir bspw. einen Stuhl. Er bietet eine Vielzahl von möglichen Interaktionen an. Wir können uns darauf setzen (so wie sich Designer das dachten), etwas darauf abstellen, selbst darauf stehen und vieles mehr. All diese Interaktionen sind möglich, auch wenn sie nicht explizit sichtbar sind. Ein weiteres Beispiel ist Werkzeug. Ein Hammer ist dazu da, Nägel in die Wand zu schlagen. Schraubendreher sind dazu da, Schrauben in oder aus etwas heraus zu drehen. Kombiniert man beide Werkzeuge, so kann mit Hammer und Schraubendreher ein hervorragender Hebel geschaffen werden. Diese Interaktion ist möglich, auch wenn sie so vom Designer nicht erdacht sind.
Auch mit LEGO®-Steinen lässt sich der Begriff von Affordances wunderbar erklären. Die kleinen Steine können annährend beliebig zusammengesteckt, aufeinander gestapelt oder sonst wie verbunden werden, um daraus neue Formen entstehen zu lassen. Beobachtet man Kinder, wenn sie mit LEGO® spielen, dann zeigen sie genau das. In kurzester Zeit entstehen fantastische Formen und Gebilde. Der Kreativität sind dabei kaum Grenzen gesetzt, weil die Steine so viele Möglichkeiten zur Interaktion – also Affordances – bieten.
Signifier
Um den Benutzer:innen anzuzeigen, welche Interaktionen möglich sind, nutzt man Signifier. Sie deuten an, welche Interaktionen möglich sind (englisch: to signify = etw. andeuten / bedeuten). Sie sollen den Benutzer:innen Hinweise liefern, wie ein Objekt zu bedienen ist.
Glas besitzt die Affordance, d.h. bietet an, hindurchzusehen. Allerdings hindert Glas allerdings die meisten Materialien daran, hindurch zu gelangen. So passiert es häufig, dass Vögel gegen Scheiben fliegen und auch Menschen laufen von Zeit zu Zeit gegen Glasflächen. Um dies zu verhindern, wird diese Anti-Affordance durch Signifier angedeutet: die Scheiben werden beklebt. So kann man verdeutlichen, dass hier eine Scheibe ist, durch die wir sehen aber nicht gehen können.
Häufig sieht man auf Touch-Screens ein Icon auf dem ein Zeigefinger auf einen bestimmten Punkt drückt. Damit zeigt man uns an, dass wir auf den Bildschirm klicken können und er aktuell vermutlich einen Bildschirmschoner anzeigt. Dieses Icon zeigt uns aber nicht, ob wir nur auf diesen einen Punkt oder irgendwo auf der gesamten Fläche berühren können und / oder sollen.
Constraints
Constraints sind Einschränkungen. Sie schränken die Anzahl möglicher Aktionen (Affordances) ein. Es gibt vier Kategorien von Constraints:
- phsische,
- logische,
- semantische und
- kulturelle Constraints.
Ich möchte diese vier Arten von Constraints am Beispiel eines LEGO® DUPLO® Feuerwehrautos erklären:
Physische Contraints
Wenn ein Objekt eine bestimmte Interaktion überhaupt nicht zulässt, besteht ein physisches Constraint. Die Aktion kann also nicht durchgeführt werden. Beim Feuerwehrauto treten physische Constraints bei der Leiter auf. Wir können die Leiter kann nur auf die dafür vorgesehene Halterung montieren. Sie auf einem der anderen Steinen zu montieren ist schlicht nicht möglich. Ebenso unmöglich ist es, ein Teil auf die Halterung zu montieren, das nicht die Leiter ist. In Formularen treten solche physischen Constraints vor allem dann auf, wenn in Eingabefeldern z.B. nur bestimmte Werte ausgewählt werden können (Combobox) oder nur Zahlen o.ä. eingegeben werden können.
Logische Constraints
Logische Constraints treten immer dann auf, wenn bestimmte Interaktionen schlicht aus logischen Gründen nicht durchgeführt werden können. In unserem Beispiel ist es logisch, die Karosserie auf das Fahrgestell zu montieren. Das Fahrgestell muss immer zuunterst sein. Alles andere wäre schlicht nicht logisch. Die Anwendung solcher Constraints im Design von Formularen oder grafischen Oberflächen ist allerdings gefährlich. Was dem Designer oder Entwickler logisch erscheint, muss für die Benutzer:innen nicht derselben Logik folgen.
Semantische Constraints
Semantik ist die Wissenschaft der Bedeutung. Semantische Constraints tragen also eine Bedeutung. Soll das Feuerwehrauto also fahren, ist es nötig, dass der Feuerwehrmann im Führerhäuschen sitzt (siehe Abbildung rechts). Muss er gerade eine Katze von einem Baum retten, so ist sein einzig sinnvoller Platz auf der Leiter. Auf diese Art und Weise schränkt der Kontext also die Platzierung des Männchens ein. Seine Position trägt eine Bedeutung.
Kulturelle Constraints
Kulturelle Constraints tauchen immer dann auf, wenn wir uns in unbekanntem Terrain befinden, aber aufgrund von Erfahrungen wissen, wie wir uns verhalten müssen. In uns bekannten Kulturen sind solche Constraints sehr nützlich. Kennen wir die Kultur nicht, sind uns solche Constraints nicht bekannt und behindern uns. Das kann sehr frustrierend sein. Betreten wir bspw. ein Hotel, wissen wir, dass wir zur Rezeption gehen müssen. Besonders deutlich werden kulturelle Constraints z.B. bei der Begrüßung. In manchen Kulturen ist es üblich, sich zu küssen, andere geben sich die Hand, verbeugen sich voreinander, winken sich zu usw. In unserem Beispiel tauchen keine kulturellen Constraints auf. Grund dafür ist, dass die Zielgruppe dieses Autos kleine Kinder sind, die noch keine Erfahrungen im Bereich kultureller Constraints sammeln konnten. Wären die Scheinwerfer und Blinker aber nicht aufgedruckt, sondern zu montieren, so müssten wir die weißen Scheinwerfer vorn, die roten hinten und die Blinker an den Seiten montieren. Kulturelle Constraints sind immer dann wichtig, wenn ein System in unterschiedlichen Kulturkreisen genutzt werden soll (Stichwort: Textrichtung in arabischen Ländern, Bedeutungen von Farben).
Mapping
Wir wollen zu jeder Zeit wissen, welche Objekte wir durch unsere Interaktionen manipulieren oder bedienen. Wissen wir das nicht, haben wir das Gefühl, die Situation nicht zu kontrollieren und zu steuern. Genau das verbirgt sich hinter dem Prinzip des Mappings.
Mappings tauchen immer dann auf, wenn mit einem Bedienelement, ein oder mehrere andere Objekte gesteuert werden. Bei Lichtschaltern besteht das Problem unklarer Mappings häufig dann, wenn mehrere Lichtschalter unterschiedliche Lampen in einem Raum steuern. Häufig probieren wir dann einfach aus, welcher Schalter welcher Lampe zugeordnet ist und bedienen die Schalter so lange, bis die erhoffte (oder eine akzeptable) Beleuchtung erreicht ist. Eine solche trial-and-error-Strategie muss aber vermieden werden, wenn es nur irgend möglich ist. Ein Pilot darf in kritischen Situationen nicht erst ausprobieren müssen, welcher Knopf den Schleudersitz auslöst.
Sind Mappings nicht klar, ist das frustrierend. Systeme, bei denen wir häufig ausprobieren müssen, welches Element zum gewünschten Ergebnis führen, werden nur in Ausnahmefällen akzeptiert.
Feedback
Genau wie bei Mappings wünschen wir uns, erkennen zu können, welchen Effekt eine von uns durchgeführte Aktion hat. Bleibt diese Rückmeldung aus, sind wir verunsichert und wissen nicht, ob die Interaktion erfolgreich war. Wir versuchen es also erneut oder brechen die Interaktion frustriert ab.
Bei Ampeln wissen wir häufig nicht, ob unsere Bedienung des gelben Druckknopfes (“Anforderungstaster”) erfolgreich war. Meist leuchtet ein kleines Licht auf, wenn das Signal erkannt wurde und die Ampel bald für uns auf grün schaltet. Tagsüber ist dieses kleine Licht aber oft nur schlecht zu erkennen. Häufig kann man Menschen beobachten, die deshalb aus Gewohnheit gleich mehrmals den Anforderungstaster bedienen, um sicherzustellen, dass sie die Straße bald überqueren können.
Bei Feedback besteht jedoch auch die Gefahr, zu viel Feedback zu geben. Zu viel Feedback stört uns meist noch deutlich mehr als zu wenig Feedback. Wenn wir einen Button zum Speichern unserer Formulareingaben betätigen, wollen wir nicht, dass aufwändige Animationen ablaufen, uns ein Lied vorgespielt wird und der gesamte Bildschirm aufleuchtet. Ein einfaches Feedback ist hier vollkommen ausreichend.
Fazit
Mit den fünf in diesem Eintrag beschriebenen, grundlegenden Prinzipien des UI-Designs entwickeln wir ein konzeptuelles Modell. Es beschreibt die Funktionsweise des Systems, so wie wir es uns gedacht haben.
Benutzer:innen entwickeln bei der Bedienung des Systems ein mentales Modell, mit dem sie aus ihrer Sicht die Funktionsweise des Systems beschreiben.
Je besser die beiden Modelle zueinander passen, desto besser ist das System bedienbar. Aus diesem Grund ist es wichtig, dass sich Designer, aber auch Softwareentwickler und -architekten, mit ihren Benutzer:innen auseinander setzen und so versuchen, das konzeptuelle Model möglichst gut auf die Bedürfnisse der Anwender:innen zu zu schneidern.
Schreiben Sie einen Kommentar