Wenn jemand ein Foto aus einem Album entfernt: Was glaubt die Person, was damit passiert ist? Sie erwartet vielleicht, dass das Original in der Mediathek bleibt, von jedem Gerät verschwindet oder im Papierkorb landet, der später geleert werden kann. Dieselbe Aktion kann verschiedene plausible Bedeutungen haben – und das Interface muss unmissverständlich klarstellen, welche davon zutrifft.
Ein mentales Modell ist das Verständnis einer Person davon, wie etwas funktioniert. Es hilft ihr, Ergebnisse vorherzusehen und zu entscheiden, was zu tun ist – selbst wenn dieses Verständnis unvollständig oder ungenau ist. Im Produktdesign geht es meist um die Frage, ob dieses Verständnis für die jeweilige Aufgabe und deren Konsequenzen ausreicht.
Niemand startet ohne vorgefasste Erklärung
Ein Interface ist selten die erste Berührung mit Aktionen wie Speichern, Teilen, Löschen oder Suchen. Frühere Produkte, Gewohnheiten aus dem Arbeitsalltag und die ganz normale Alltagssprache prägen, was diese Aktionen bedeuten. Das Produkt liefert dann weitere Hinweise durch Beschriftungen, sichtbare Statusanzeigen und Feedback.
Die Erklärung mentaler Modelle der Nielsen Norman Group hebt hervor, dass unterschiedliche Menschen völlig verschiedene Vorstellungen desselben Systems entwickeln können. Das macht „das mentale Modell des Nutzers“ zu einer potenziell irreführenden Verkürzung. Neukund*innen, Admins und Personen, die von einem anderen Produkt wechseln, interpretieren dasselbe Bedienelement unter Umständen ganz anders.
Bei einem fiktiven Fotodienst könnte das Wort „Album“ für einen Ordner stehen, der die Inhalte tatsächlich besitzt – oder für eine Sammlung von Verweisen auf Fotos, die an anderer Stelle gespeichert sind. Funktioniert das System nach dem zweiten Prinzip, muss es vermitteln, worauf sich das Entfernen eines Elements auswirkt und worauf nicht. Eine Warnung, die lediglich „Entfernen?“ wiederholt, lässt die eigentliche Unsicherheit ungelöst.
Erwartungen genau im entscheidenden Moment untersuchen
Beobachten Sie relevante Aufgaben und achten Sie auf Vorhersagen, Überraschungsmomente und Versuche, Fehler zu korrigieren. Ein Think-Aloud-Protokoll kann aufdecken, was jemand während der Nutzung erwartet – auch wenn die Bitte um Erklärung die Handlung selbst bewusster und überlegter machen kann.
Mit gezielten Nachfragen lässt sich ein bestimmter Moment vertiefen: Was sollte nach dem Entfernen des Fotos laut Erwartung der Person übrig bleiben, und was auf dem Bildschirm hat zu dieser Annahme geführt? Vergleichen Sie die Antwort mit den Aktionen und dem daraus resultierenden Zustand. Ein einzelner Fehlklick kann viele Gründe haben; man sollte daraus nicht voreilig auf ein festes mentales Modell schließen.
Card Sorting zeigt, wie Menschen Informationen strukturieren, während Tree Testing prüft, ob sie sich in einer geplanten Hierarchie zurechtfinden. Diese Methoden beleuchten ganz bestimmte Aspekte des Verständnisses. Sie decken jedoch nicht alle Annahmen ab, die jemand über Berechtigungen, Speicherorte oder Ursache und Wirkung hat.
Das Nutzungserlebnis anpassen, das das Modell formt
Treten Missverständnisse wiederholt auf, prüfen Sie Begrifflichkeiten und Systemverhalten gemeinsam. Manchmal reicht ein klareres Wording schon aus; mitunter sind die Systemregeln aber auch einfach unnötig kompliziert. Wenn das Teilen eines Albums beispielsweise auch Zugriff auf künftige Ergänzungen gewährt, muss diese fortlaufende Verknüpfung direkt bei der Freigabe verständlich und auch danach noch sichtbar sein.
Es ist weder immer möglich noch sinnvoll, ein System an jede bestehende Erwartung anzupassen. Neue Funktionen erfordern manchmal Lernprozesse. Gutes Design liefert eine schlüssige Erklärung, nützliches Feedback und Wege zur Fehlerbehebung bei absehbaren Fehlern – statt auf ein Tutorial zu setzen, das man sich dauerhaft merken müsste.
Testen Sie die überarbeitete Interaktion mit der tatsächlichen Zielgruppe. Das entscheidende Kriterium ist, dass Menschen die Konsequenzen so gut vorhersehen können, dass sie sicher handeln und Fehler bei Bedarf selbst korrigieren können. Sie müssen nicht die interne Architektur des Produkts erklären können, um zu beweisen, dass das Design sie optimal unterstützt.