Please, make me think!

Mein erster Kontakt mit dem Thema "Usability" (als ich das früher mal lernte, hieß es noch "Software-Ergonomie")  war nicht Nielsen sondern Steve Krugs epochales Don't make me think!. Genaugenommen stand da schon alles drin, was man zu dem Thema wissen muß. Und sogar mit Beispielen (deren Design manchmal wirklich ... ääh, na, ja, eben "Geschmackssache" waren)! Der Tenor war einfach: mach es simpel, mach es deutlich, mach es so, wie es alle anderen (speziell die erfolgreichen) machen, denn das kennt dein User schon.

Ist plausibel und funktioniert sogar (wenn man sich dem Thema mit etwas Intelligenz annimmt und nicht versucht, platten Regeln zu folgen). Kann aber auch zu Langeweille und Einförmigkeit führen. Manche denken auch, dass zu konsequente Anwendung dieser Prinzipien Kreativität und Innovation abwürgen (siehe Verhindern Usability und User-Centered Design Innovation?) Und dann stellt sich natürlich die Frage, ob es wirklich immer richtig ist, vom Anwender kein Denken zu verlangen - immer von DAU (zynisch für "dümmsten anzunehmenden User") auszugehen?

Andrei Herasimchuk von designbyfire hat schon vor längerer Zeit einen Artikel geschrieben, der dieses Unbehagen sehr schön ausdrückt: Please make me think!

To the point: Should you, as a designer, be bound by some ethical mantra to make your work deeper, more thoughtful and complex, not aimed for the lowest common denominator of your user base?

Should your design work require your users think? Should your design work not allow users to potentially be lax mentally, so they can glide thoughtlessly through your website, software or product you’ve designed that they interact with on an ongoing basis? Or should every control and widget be labeled explicitly? Should every set of instructions be aimed at the most inexperienced user?

Should everything be so damned obvious all of the time?

Tatsächlich liefert nicht der Artikel, aber die Kommentare dazu einige sehr schöne Antworten auf diese Fragen. Im Detail ... 

Das Unbehagen mit obiger Fragestellung ist ja nicht nur eine Frage des persönlichen Frusts beim Designer, für den es wenig befriedigend ist, wenn alles "immer offensichtlich", standardisiert, langweilig sein soll und nie eine neue Lösung ausprobiert werden darf (was Usability bzw. User-Centered Design genau genommen gar nicht ausschließen).

Anfänger vs. versierte Anwender
Tatsächlich kann das übersimplifizierte Design ja auch für den regelmäßigen Anwender lästig werden. Der will ja irgendwann statt endloser Erläuterungen, Zwischenschritte, Sicherheitsabfragen etc., die er als Anfänger gut und sinnvoll fand, auch Schnelligkeit und Effizienz. Er will zum Beispiel Eingabebereiche oder Bedienungselemente, die vielleicht etwas Vorkenntnisse voraussetzen aber die Arbeit dann auch schnell und mit wenigen gezielten Klicks und Tastendrücken erledigen. (Was übrigens auch Usability sein kann, nur nicht für Anfänger!)

Und eine Anwendung, die einen zwingt, jedesmal denselben Weg zu gehen, wie bei der allerersten Benutzung, kann ja auch schrecklich langweilig sein - wie monotone Arbeitsabläufe, Fast Food, Fernsehserien mit vorhersehbarem Ablauf etc.

The question for me that’s more interesting though is in my design work. I find myself as a designer buying into the usability mantra of designing everything so it’s obvious and doesn’t ask people to take the time to learn or think about its use. At times when doing this, I feel like I’m pandering to the worst traits in most people, only helping to promote the uglier side of mass consumerism.

Der Artikel selbst ist gut, teilweise amüsant geschrieben und in mancher Hinsicht ganz aufschlussreich. Er wirft aber nur Fragen und Zweifel auf. Viel Futter für die Feinde der Usability. das ist Herasimchuk nicht (allerdings bekennender Nielsen-Gegner).

Die Balance zwischen Anforderungen und Fähigkeiten - Get in the Flow!
Wie häufig bei Artikeln bekannter Blogger stecken viele wertvolle Inhalte in den Kommentaren. Lesen! Ich selbst fand den Beitrag von Gordon Ross am besten. Der schreibt

Re: “don’t make me think” and lowest common denominator design, I attended a great talk here in Vancouver on Thursday  night from a local usability professional who introduced behavioural psychologist Mihaly Csikszentmihalyi’s concept of flow and how it applies to UI design.

Yep! Genau das klärt letztendlich zumindest die Frage, ob Usability auf den kleinsten gemeinsamen Nenner und den legendären DAU fokussieren muss oder dem versierten Anwender möglichst viel Effizienz bieten muss. Es kommt drauf an ...

Dazu muss ich ganz kurz ausholen und ein paar Worte zu Csikszentmihalyi’s Flow-Ansatz sagen. Der hat viele Aspekte und beschäftigt sich eher damit, wie das Gefühl "Glück" im Menschen entsteht. Wichtig für Usability ist aber vor allem die Balance zwischen unseren Fähigkeiten und den Herausforderungen, die ein Job (oder ein Stück Software?) an uns stellt. Sind unsere Fähigkeiten oder Kenntnisse (noch) niedrig, darf die Herausforderung nicht zu groß sein. Sonst sind wir demotiviert. Sind unsere Fähigkeiten, Kenntnisse, Erfahrungen größer, darf die Herausforderung nicht zu gering sein. Sonst sind wir unterfordert, langweilen uns (und machen vielleicht deshalb Fehler). Etwas mehr zu "Flow" auch hier.

Für das Produktdesign bzw. auch die Oberfläche einer Software heißt das unter anderem, dass die Fähigkeiten, Kenntnisse und Erfahrungen der Anwender ermittelt und berücksichtigt werden müssen. Es kann tatsächlich kontraproduktiv sein, die Anwender zu unterfordern, "Mitdenken" nicht zu erwarten.

Das Flow-Prinzip ist keine Ausrede für schlechte Usability!
Allerdings gilt das nur bei einer Optimierung der Anwendung (oder auch Website) für Anwender, die sich häufig, intensiv und lange damit auseinandersetzen! Von solchen Anwendern gehen Entwickler und Betreiber zwar gerne aus. Die Annahme "ich bin wichtig und jeder besucht täglich meine Website" ist menschlich nachvollziehbar. Aber ehrlich gesagt sind solche Anwendungen sehr selten.

Die meisten Websites sucht ein Anwender nur schnell auf, um eine Information zu erhalten, eine kleine Interaktion anzustossen etc. Das soll schnell gehen, da will kaum jemand denken oder "in den Flow" kommen. Deswegen sind auch die ganzen "myDingsbums"-Portale in den letzten Jahren gescheitert, wo nahezu jede größere Firma "ihren" Kunden die Möglichkeit bieten wollte, ihre Homepage individuell anzupassen. Nett gemeint, aber wozu sollte ich mir die Mühe machen, die Homepage einer Autofirma anzupassen, die ich zweimal im Jahr aufsuche?

Vorkehrungen für den versierten User braucht wirklich nur eine Website oder Anwendung treffen, die auch versierte, wiederkehrende Anwender hat. Ein webbasierte E-Mail-System zum Beispiel wie GMX, Web.DE oder GMail (bei denen sich genau deshalb in den letzten Monaten Tastaturabkürzungen für wichtige Befehle durchgesetzt haben). Oder ein Online-CRM-System, oder eBay oder meine Weblog-Software oder ... Aber sicherlich nicht die Niederlassungssuche des Schraubenherstellers Müller auf dessen Homepage!

Wer für solche Allerwelts-Anwendungen bahnbrechende Innovationen an der Benutzeroberfläche einplant - die "enorme Geschwindigkeitsvorteile bringen, wenn man nur erst einmal die Anleitung gelesen und verstanden hat" (oder gar "um mal etwas anderes zu machen und die Anwender nicht zu langweilen") - tut den Besuchern seiner Website keinen Gefallen und sich auch nicht.

One Size fits all?
Ergo: Einfach (Don't make me think!) für alle Anwendungen, die typischerweise selten benutzt werden. Fokus auf Effizienz (eventuell Kompromisse bei der Anfänger-Usability) und steilere Lernkurve (Please, let me think!) bei Anwendungen mit Fokus auf täglichen Einsatz.

Problematisch wird es, wenn ein- und dieselbe Anwendung unterschiedliche Nutzergruppen bedienen soll. Die Erstanwender, die "nur mal eben schnell" etwas einfaches damit machen wollen und die versierten Anwender, die tagtäglich Stunden darin zubringen.

Eine solche Anwendung wäre zum Beispiel die Fahrplanauskunft der Bahn. Wenn ich die das erste Mal aufrufe, will ich vermutlich nur wissen, wie ich an einem bestimmten Tag von A nach B komme. Mehr sollte das Teil auch nicht von mir erfragen - und mir erst nach Nennung der Verbindungen anbieten, wahlweise Zwischenziele anzugeben, bei der Preisberechnung auch eine Bahncard zu berücksichtigen, gleich die Rückfahrt mitzubuchen, mehrere Reisende auf einer Karte fahren zu lassen, etc.

Der Mitarbeiter im Reisebüro oder der Bahnhofsauskunft - der die selben Funktionalitäten benötigt - braucht hingegen eine große Eingabemaske, auf der das alles gleich angegeben werden kann. Vielleicht sind sogar Tastatürkürzel sinnvoll, mit denen schnell zwischen erster und zweiter Klasse, mit und ohne Bahncard etc. gewechselt werden kann.

Das sind dann de facto zwei Oberflächen für die selbe Software. Was naturgemäß aufwendiger zu entwickeln und in der Aktualisierung umständlicher ist, sich aber bei großen, heterogenen Anwendergruppen lohnt. (Leider macht die Bahn das online nicht so sondern klatscht mir selbst bei der "einfachen" Suche schon eine ziemliche Monstermaske auf den Bildschirm. Die erweiterte Suche ist kurioserweise kaum komplizierter.)

Ideal sind selbstverständlich "lernende" Anwendungen, die sich dem Kenntnisstand ihrer User anpassen können - und somit das Flow-Erlebnis immer in optimaler Balance zwischen Können und Herausforderung herstellen. Aber so unbescheiden wollen wir mal nicht sein, so etwas gleich zu verlangen. Microsoft macht immer wieder mal Versuche in dieser Richtung. Die Ergebnisse sind bislang aber "nicht so extrem erfolgreich".

Comments

[Markus Breuer]

danke für die blumen, nicole, aber wogeben genau argumentiertest du? ich zumindest hatte nirgends im text "tolles design" hochgehalten. verwechselst du da etwas? ich hatte lediglich über unterschiedliche optimierungsziele bei unterschiedlich versierten usern gesprochen.

andrej (bei designbyfire) hatte den aspekt design angesprochen und damit vermutlich nicht ganz unrecht. es gibt dimensionen der usability, die mit emotion zu tun haben. ich vermute nicht, dass er schickes design meinte, bei dem es die tab-taste (oder, viel häufiger) cursortasten, scrollrad der maus etc. nicht mehr tun.

[Markus Breuer]

druckversion?

just hit me. trifft schon den richtigen.
... aber ... ich programmiere die templates von typepad nicht.

ausserdem: drucken? papier ist tot!

nein, nein, du hast schon recht. ich drucke auch oft längere artikel aus und fluche dann, wenn die kein print-optimiertes stylesheet haben. sorry!

[Marcus Völkel]

»hybsches Design und schrottige Bedienbarkeit«... weshalb denn immer diese Trennung von Design und Benutzbarkeit? Beides gehört untrennbar und sich gegenseitig unterstützend zusammen, wenn es sich denn »gut« nennen will. »Langeweile« ist dann übrigens prima dazu geeignet, um Floweffekte zu erzeugen – solange Langeweile nicht gleich Unterforderung bedeutet.

Allerdings sind durch diese Erkenntnis in den letzten Jahren immer wieder die gleichen austauschbaren Websites entstanden. Seit fast drei Jahren möchte ich mal endlich einen Artikel überarbeiten, den ich damals über Usability und Flow geschrieben habe. Da geht es um ebendieses Thema (Print-Stylesheet inklusive): http://www.scoreberlin.de/usability-artikel/flow-content-usability/

Ich glaube (wir hatten das neulich so ähnlich drüben bei Alp), dass das auch daran liegt, dass Entwickler-Teams nicht vernetzt genug miteinander arbeiten (Workflow!). Designern und Usabiliteers würde es beispielsweise unheimlich gut tun, stärker miteinander zu arbeiten – nicht nur bei ordinären Websites, sondern vor allem auch, was Anwendungen betrifft (und ihre Anforderungen an unterschiedliche User-Gruppen). Vielen Designern, die unterschiedliche User beim Usability-Test beobachten und vielleicht auch hinterher selbst einmal interviewen, geht oftmals ein Licht auf: Es gibt nämlich weder *den* User noch *den DAU* (welche ihnen so oft Frust verursachen). Umgekehrt können Usabiliteers von Designern lernen, wie wichtig neben der Benutzbarkeit auch die emotionale Bedeutung optischer und haptischer Anmutung ist. Und dass sich das sehr wohl miteinander vereinen lässt. Und daher der Fokus auf den kleinsten gemeinsamen Nenner sich vielleicht nicht wirklich gerade zielführend auswirkt...

Viele HCI-Leute sagen gerne, dass der User sich wohl fühlen solle. Yep, aber dafür ist in erster Linie das Design verantwortlich. Gute Usability führt lediglich dazu, dass man seine Ziele und Aufgaben im Nutzungskontext schnell, effektiv und effizient erreicht. Wenn die Usability wirklich gut ist, merkt man ihre Arbeit nämlich *überhaupt gar nicht*. Also, vielleicht sollte man mal einen integrierenden Workshop oder sowas in der Art veranstalten, damit sich diese Leute nicht mehr gegenseitig bashen; das führt doch zu nichts.

[Markus Breuer]

ja, es ist leider wirklich das selbe - oder ein ähnliches - thema, wie "neulich drüben bei alp". zumindest ist es die selbe ursache für die probleme: die haltung "wir guten/klugen/ehrbaren hier" und "die bösen/doofen/geldgeilen/arroganten da". ob die bösen nun "die designer" sind, die sich "nicht genug um usability kümmern", oder "die usabiliteers", die die "bedeutung der emotionalen ansprache nicht erkannt" haben oder "die usability-gurus, die nur (igittebäh) geld machen" wollen.

du hast die wurzel des ganzen sehr schön beschrieben: organisatorisch sind das in unternehmen und projekten verschiedene "fraktionen" oder gar unternehmen und nicht EIN team. das rituelle usability-lab am ende des projekts fördert diese separation eher noch. dabei geht es anders: die fragestellung "wie sieht der user das, was kann er, braucht er" im team und im zeitlichen ablauf des projektes zu einem integralen bestandteil machen wie zum beispiel auch qualität (die man auch nicht wirklich gut "am ende reintesten" oder "extern einkaufen" kann). der beste artikel (wenn auch nur sehr oberflächlich) zu dem thema ist für mich immer noch
http://www.adaptivepath.com/publications/essays/archives/000328.php

ob ein workshop reicht, das bashing einzustellen? glaub ich nicht. das klappt meiner erfahrung nach erst durch gemeinsame arbeit in einem team, wo der designer irgendwann merkt, dass die entwicklerin irgendwie gar nicht so doof und stur ist und beide merken, das der HCI-man kein brürokrat sondern ein engagierter kollege ist.

abe eigentlich ging es mir in diesem post gar nicht um den ständig schwelenden fight zwischen usability und design (das nervt, dieses ständige "wir hier und die da") sondern um die aussage "usability ist relativ". was für den gelegentlichen unerfahrenen anwender "usable" ist, kann für den versierten "un-usable" oder zumindest suboptimal sein.

dein flow-artikel (den ich noch nicht gelesen hatte, sorry) beschreibt das sehr schön. wobei Csikszentmihaly m.E. tatsächlich die emotionalen faktoren einer flow-situation (und damit u.a. designfragen sowie die von von Donald Norman "reflektiv" genannte ebene) nicht ganz zureichend berücksichtigt. ich finde das flow-modell trotzdem sehr hilfreich.

man sollte es nur nie als alibi nehmen, um dem nutzer größere "herausforderungen" zuzumuten, als er für einen bestimmten job anzunehmen bereit ist. der großteil der applikationen und applikatiönchen im web wendet sich doch tatsächlich an den eiligen, gelegentlichen benutzer. lange nachdenken (und die anspannung seiner grauen zellen genießen) will der/die in diesen anwendungssituationen nicht.

(und es wundert mich stets aufs neue, warum die verbindung flow-usability sowohl bei designern als auch HCI-leuten immer wieder mal auf überraschung stößt. neu ist dieser ansatz ja wirklich nicht.)

[Marcus Völkel]

Ja, das mit dem Workshop war dumm und ist mir so rausgerutscht, aus dem Flow quasi. Ich halte das ebenso für eine unternehmensinterne Angelegenheit bzw. Aufgabe. Mir fiel nur auf, wie peinlich es vielen Menschen ist, wenn sie im Miteinander-Arbeiten entdecken und feststellen, dass ihre vorherige Ablehnung/Antipathie (meist in Klischees und Vorurteilen begründet) eine Mauer auf dem Weg zu noch besserer Arbeit war.

Und was »Usability ist relativ« betrifft, denke ich, dass es für Teams sehr befreiend und förderlich ist, wenn sie diese Relativität für ihre Arbeit entdecken: Nämlich eben gerade genau nicht auf diesem engen, kleinsten gemeinsamen Nenner DAU oder $_User zu arbeiten. Aber ich »befürchte«, um das erfolgreich hinzubekommen (ohne die Teams zu frustrieren und User zu verärgern), ist echtes team- und (!) userzentriertes Arbeiten notwendig.