1993 erschien Jakob Nielsens Buch Usability Engineering. Es enthält eine Liste von zehn kurzen Merksätzen, die Usability Slogans. Sie verdichten zentrale Erkenntnisse der Usability-Forschung zu Aussagen, die man sich merken kann. Die Sätze stammen aus der Zeit vor Smartphone, App Store und Cloud – die Fehler, vor denen sie warnen, treten in der Produktentwicklung aber bis heute auf.
Beide Sätze stehen so bei Nielsen. Sie widersprechen sich nur scheinbar – die Auflösung steht im Abschnitt „Das Nutzer-Paradox".
Usability meint die Gebrauchstauglichkeit eines Produkts, nicht seine Optik. Steve Krug beschreibt es so: „Usability is about people and how they understand and use things, not about technology." Schlechte Usability hat messbare Folgen: mehr Supportanfragen, höhere Absprungraten und geringere Akzeptanz. Die folgenden zehn Slogans benennen die häufigsten Ursachen.
Inhaltsverzeichnis
Hintergrund
Wer Nielsen war und wozu die Slogans dienen.
Die zehn Usability-Slogans
Alle zehn im Überblick, anschließend nach Themen erläutert.
Vom Slogan zur Praxis
Der iterative Prozess und warum frühe Tests Kosten sparen.
Häufige Missverständnisse
Fünf verbreitete Annahmen – und was dagegen spricht.
Hintergrund
Jakob Nielsen, später Mitgründer der Nielsen Norman Group, fasst die Kernaussagen seines Buches in einem Abschnitt mit dem Titel „Usability Slogans" zusammen. Der Zweck ist praktisch: Forschungsergebnisse so zu formulieren, dass sie im Projektalltag präsent bleiben – im Sprint ebenso wie im Gespräch mit Stakeholdern.
Die Slogans sind keine Methode und kein Regelwerk. Sie helfen, wiederkehrende Fehlannahmen früh zu erkennen. Wer die Themen vertiefen möchte: Eine Videoreihe erläutert die Slogans im Einzelnen.
Usability ist die Gebrauchstauglichkeit eines Produkts: Erreichen Nutzer:innen ihr Ziel – schnell, fehlerfrei und ohne unnötige Hürden? Entscheidend ist, dass sich das messen lässt: über Erfolgsrate, Aufgabenzeit und Fehlerquote. Usability ist deshalb kein Geschmacksthema, sondern eine Ingenieursdisziplin.
Die zehn Usability-Slogans
Zunächst der Überblick, danach die Erläuterung nach Themengruppen. Jeder Slogan steht zusätzlich im englischen Original, so wie Nielsen ihn formuliert hat.
| Slogan | Nielsens Kernaussage | Was es heute bedeutet |
|---|---|---|
| „Ihre beste Vermutung reicht nicht" — Your Best Guess Is Not Good Enough | Annahmen über Nutzer:innen sind unzuverlässig. | Testen statt raten; schon kleine Stichproben sind aussagekräftig. |
| „Nutzer:innen haben immer recht" — The User Is Always Right | Probleme der Nutzer:innen sind reale Probleme. | Ein Abbruch im Funnel ist ein Designfehler, kein Anwenderfehler. |
| „Nutzer:innen haben nicht immer recht" — The User Is Not Always Right | Geäußerte Lösungsvorschläge sind oft falsch. | Verhalten beobachten, nicht nur Wünsche abfragen. |
| „Nutzer:innen sind keine Designer:innen" — Users Are Not Designers | Bedürfnisse benennen ist nicht dasselbe wie Lösungen entwerfen. | Feedback ist ein Hinweis, keine fertige Spezifikation. |
| „Designer:innen sind keine Nutzer:innen" — Designers Are Not Users | Das Team ist nicht repräsentativ für die Zielgruppe. | Eigene Routine ist kein Maßstab für den Erstkontakt. |
| „Führungskräfte sind keine Nutzer:innen" — Vice Presidents Are Not Users | Hierarchie ersetzt keine Daten. | Entscheidungen an Evidenz binden, nicht an den höchsten Titel. |
| „Weniger ist mehr" — Less Is More | Mehr Funktionen erzeugen mehr Komplexität. | Fokus erleichtert Auffindbarkeit und Nutzung. |
| „Details entscheiden" — Details Matter | Kleine Schwächen summieren sich. | Microcopy, Ladezeiten und Fehlermeldungen sind keine Nebensache. |
| „Hilfe hilft nicht" — Help Doesn't | Hilfetexte werden kaum gelesen. | Die Oberfläche selbst verständlich machen, statt Hilfe nachzurüsten. |
| „Usability ist ein Prozess" — Usability Engineering Is Process | Gebrauchstauglichkeit ist Methode, kein Endzustand. | Iterativ messen und verbessern, über den gesamten Lebenszyklus. |
Daten statt Annahmen
Drei Slogans betreffen denselben Fehler: Annahmen über Nutzer:innen werden für gesichertes Wissen gehalten. „Your Best Guess Is Not Good Enough" widerspricht dem. Auch erfahrene Teams schätzen oft falsch ein, wie Menschen ein Interface bedienen – nicht aus Unvermögen, sondern weil man das eigene Produkt nicht mehr unvoreingenommen sieht.
Der dritte Slogan dieser Gruppe lautet „Vice Presidents Are Not Users" – Führungskräfte sind keine Nutzer:innen. Auch die Geschäftsführung benutzt das Produkt anders als die eigentliche Zielgruppe. Eine Entscheidung wird nicht dadurch richtig, dass sie von der ranghöchsten Person kommt. Kurz gesagt: Wenn ein Nutzungstest etwas anderes zeigt als die Meinung im Meeting, zählt der Test.
| Feature | Annahme („Best Guess") | Evidenz (Usability Engineering) |
|---|---|---|
| Grundlage | Meinung, Erfahrung, Bauchgefühl | Beobachtetes Verhalten echter Nutzer:innen |
| Leitfrage | „Was würde ich tun?" | „Was tun die Nutzer:innen tatsächlich?" |
| Wer entscheidet | Wer am lautesten oder am höchsten ist | Das Testergebnis, nicht die Position |
| Typisches Risiko | Teure Korrektur nach dem Launch | Frühe, günstige Iteration |
Das Nutzer-Paradox
Hier lösen sich die beiden Sätze aus der Einleitung auf. „The User Is Always Right" bedeutet: Wenn Nutzer:innen scheitern, ist das ein reales Problem – und zwar das des Produkts. Steve Jobs formulierte denselben Gedanken: „If a user is having a problem, it's our problem." Ein abgebrochener Checkout ist kein Bedienfehler, sondern ein Designproblem.
„The User Is Not Always Right" ergänzt die Einschränkung: Nutzer:innen erkennen Probleme zuverlässig, schlagen aber häufig die falsche Lösung vor. Nielsen rät deshalb: „Pay attention to what users do, not what they say." Wer nur abfragt, was sich Nutzer:innen wünschen, baut am Bedarf vorbei. Wer beobachtet, was sie tun, erhält die verlässlicheren Hinweise.
Worauf es ankommt: Probleme der Nutzer:innen ernst nehmen.
- Jeder Abbruch und jede Verwirrung ist ein valides Signal.
- Beschwerden sind Daten, kein Rauschen.
- Die Verantwortung liegt beim Produkt, nicht beim Menschen.
Konsequenz: Reibungspunkte systematisch erfassen und beseitigen.
Rollen sauber trennen
Zwei gegensätzliche Slogans warnen vor den beiden häufigsten Fehlschlüssen. „Users Are Not Designers": Nutzer:innen können genau sagen, wo es hakt – eine fertige Lösung folgt daraus nicht. Ein Feature-Wunsch ist ein Hinweis, keine Spezifikation.
„Designers Are Not Users": Wer ein Produkt täglich bearbeitet, verliert den Blick für den ersten Eindruck. Was dem Team selbstverständlich erscheint, ist für die Zielgruppe oft eine Hürde. Frank Chimero formuliert die Folge so: „People ignore design that ignores people."
Nutzer:innen liefern Probleme
Ihre Stärke ist das Aufzeigen realer Hürden. Sammeln Sie diese Signale – und übersetzen Sie sie selbst in Lösungen.
Teams haben blinde Flecken
Routine erzeugt Betriebsblindheit. Holen Sie regelmäßig unvoreingenommene Außensicht ein.
Reduktion und Sorgfalt
Drei Slogans betreffen die konkrete Gestaltung. „Less Is More": Jede zusätzliche Funktion und jedes zusätzliche Bedienelement erhöht die kognitive Last und lenkt vom Wesentlichen ab. Mehr Optionen führen nicht zu mehr Zufriedenheit.
„Details Matter" ist die notwendige Ergänzung: Reduktion bedeutet nicht Nachlässigkeit. Eine unklare Fehlermeldung, eine lange Ladezeit oder ein mehrdeutiges Label summieren sich zu Frust und Abbrüchen.
„Help Doesn't": Hilfetexte und Tutorials werden in der Praxis kaum gelesen. Ein FAQ-Eintrag dokumentiert ein Usability-Problem, behebt es aber nicht. Golden Krishna formuliert das Ziel zugespitzt: „The best interface is no interface." Gemeint ist eine Oberfläche, die ohne zusätzliche Erklärung verständlich ist.
Bevor Sie einen Hilfetext schreiben, prüfen Sie, ob sich die Oberfläche so anpassen lässt, dass die Erklärung überflüssig wird. Oft ist das möglich.
Usability ist kein Zustand, sondern ein Prozess
Der zehnte Slogan fasst die übrigen zusammen: „Usability Engineering Is Process". Gebrauchstauglichkeit entsteht nicht durch einmalige Nacharbeit am Ende, sondern durch einen wiederholten Zyklus aus Verstehen, Gestalten, Testen und Messen – über den gesamten Lebenszyklus eines Produkts.
Usability Engineering als iterativer Zyklus – nicht als einmalige Endabnahme
Vom Slogan zur Praxis
Für diesen Prozess gibt es einen gut belegten wirtschaftlichen Grund: Je später ein Usability-Problem entdeckt wird, desto teurer ist seine Behebung. Eine Änderung am Prototyp dauert Minuten. Dieselbe Änderung nach dem Launch verursacht ein Vielfaches an Aufwand – für Entwicklung, Tests und Migration.
Schematische Darstellung des in der Softwaretechnik gut dokumentierten Prinzips steigender Korrekturkosten über die Projektphasen. Die konkreten Faktoren variieren je nach Projekt – die Richtung ist konstant.
Der größte Hebel liegt also früh im Prozess. Der Aufwand dafür ist geringer als oft angenommen: Bereits rund fünf Testpersonen decken einen Großteil der gravierenden Usability-Probleme auf – eine der bekannteren Erkenntnisse aus Nielsens Arbeit. Ein Labor oder ein großes Panel ist dafür nicht erforderlich.
Nutzungskontext verstehen
Früh und günstig prototypen
Mit echten Nutzer:innen testen
Messen statt meinen
Iterieren
Gute Usability senkt den Supportaufwand, erhöht Akzeptanz und Conversion und reduziert spätere Nacharbeit. Dr. Ralf Speth benennt die Kehrseite: „If you think good design is expensive, you should look at the cost of bad design."
Häufige Missverständnisse
Die folgenden Aussagen klingen plausibel, führen aber regelmäßig zu schlechten Entscheidungen. Daneben steht jeweils das Gegenargument.
Fazit
Nielsens Slogans sind über dreißig Jahre alt und weiterhin anwendbar. Sie lassen sich auf drei Grundsätze verdichten:
1. Evidenz vor Meinung
Die beste Vermutung reicht nicht, und der höchste Titel ersetzt keine Daten. Testen statt raten.
2. Reduktion vor Fülle
Weniger ist mehr, Details entscheiden, Hilfe hilft nicht. Die Oberfläche sollte sich selbst erklären.
3. Prozess vor Politur
Usability ist eine Schleife, kein Meilenstein. Früh, regelmäßig und mit echten Nutzer:innen messen.
Damit löst sich auch der scheinbare Widerspruch vom Anfang: Nehmen Sie die Probleme Ihrer Nutzer:innen ernst, aber übernehmen Sie nicht ungeprüft deren Lösungsvorschläge. Davon hängt ab, ob ein Produkt benutzt wird – oder nicht.
Wenn Sie wissen möchten, an welchen Stellen Ihr Produkt Nutzer:innen verliert, unterstützen wir Sie bei Usability-Tests, Analyse und Umsetzung. Kontakt aufnehmen.