Anwenderbesuche sind eine wertvolle Methode bei der Erstellung benutzerfreundlicher User Interfaces. Dennoch können Missverständnisse und Vorurteile dazu führen, dass die Methode nicht zum Einsatz kommt und eine Lösung letztendlich bezüglich der User Experience hinter den Erwartungen zurückbleibt. Die Informationen in diesem Beitrag soll ein zentrales Missverständnis in Bezug auf Anwenderbesuche ausräumen und dabei einen ersten Überblick über Sinn und Zweck von Anwenderbesuchen geben.
Ein wesentliches Missverständnis
Ein Missverständnis, das im Kontext von Anwenderbesuchen verbreitet ist, lässt sich zusammenfassen in der Aussage „Wir können die Anwender ja auch einfach fragen, wie sie das existierende System finden“. Dieses Missverständnis hat zwei Facetten: Die Vorstellungen, dass
- ein existierendes aktuelles System im Zentrum des Interesses steht und
- Anwenderbesuche primär Befragungen sind.
Beides ist jedoch nicht der Fall.
Fokus von Anwenderbesuchen
Anwenderbesuche dienen nicht primär dazu, ein existierendes System kennenzulernen. Der Zweck besteht vielmehr darin, den Kontext kennenzulernen, in dem ein zu gestaltendes System zum Einsatz kommen soll. „Kontext“ bezieht sich dabei u.a. auf die Anwender selbst, ihre Arbeitsaufgaben und Ziele und die (physische) Umgebung, in der das zukünftige System genutzt werden soll. Diese Perspektive ist deshalb so wichtig, weil die Entwicklung eines interaktiven Systems in der Regel nur Einfluss darauf hat, wie das System letztendlich gestaltet ist. Der Kontext dagegen muss üblicherweise so hingenommen werden, wie er ist. Wenn man UX Design als „Puzzlespiel“ begreift, dann ist das interaktive System das letzte „Puzzleteil“, das sich nur dann optimal in das Gesamtbild einfügt, wenn man den Rest des Puzzles, und damit die „Lücke“, so exakt wie möglich beschreiben kann. Deshalb ist es wichtig, den Kontext so detailliert wie möglich zu kennen. So müssen beispielsweise zur Gestaltung eines optimalen User Interface die Licht- und Geräuschverhältnisse an einem Arbeitsplatz bekannt sein, um über passende Farbdarstellungen und Systemtöne zu entscheiden. Wird hier nur aufgrund von Mutmaßungen gearbeitet, besteht das Risiko, dass ein scheinbar benutzerfreundliches System im konkreten Kontext völlig an den Bedürfnissen der Anwender vorbei geht. Eine besondere Herausforderung kann sich gerade durch den – häufigen – Fall ergeben, dass es bei einem Anwenderbesuch schon ein existierendes System gibt, das optimiert werden soll. Dann kann es schwierig sein, die „echten“ Kontextfaktoren von denjenigen zu unterscheiden, die gewissermaßen durch die vorliegende Implementierung eines Systems beeinflusst oder überlagert sind. Es ist durchaus kein seltener Fall, dass Anwender still vor einem System „kapitulieren“ und ihre Arbeitsprozesse nach den Zwängen einer Implementierung ausrichten, obwohl sie mit einer besseren Unterstützung durch ein System deutlich effizienter und zufriedenstellender arbeiten könnten. Keinesfalls sollte also aus der Tatsache, dass kaum Anwenderbeschwerden beim Support eingehen, gefolgert werden, dass ein System sehr gut oder gar perfekt ist. Im schlimmsten Falle wird immer weiter für einen scheinbaren „Idealworkflow“ implementiert, der schlicht durch das System erzwungen wird, so dass die Nutzer mit jedem Update weiter in einen suboptimalen Workflow gepresst werden.
Es müssen also die „wahren“ Arbeitsziele und -prozesse von Anwendern mit ihren Regelmäßigkeiten aber auch Ausnahmefällen detailliert bekannt sein, um ein Werkzeug zu erstellen, das die Anwender bestmöglich unterstützt, ohne dass die Anwender wiederum sich dem System anpassen müssen. Letztendlich ist ein interaktives System für Anwender immer nur ein Werkzeug, mit dem sie ihre Ziele erreichen wollen und kein Selbstzweck. Auch aus diesem Grund sollte das System dem schon existierenden Kontext möglichst gut gerecht werden.
Das bedeutet insbesondere auch, dass Anwenderbesuche auch dann sinnvoll durchführbar sind, wenn noch gar kein interaktives System existiert. Dies kann beispielsweise bei Innovationsprojekten der Fall sein. Erst wenn das Projektteam mit dem gesamten Kontext vertraut ist, in dem das zukünftige System zum Einsatz kommen soll, kann das „fehlende Element“ – das System – passgenau gestaltet werden, um Anwendern eine Lösung zur Verfügung zu stellen, die sich optimal in den (Arbeits-)Alltag einfügt und eine optimale User Experience bietet.
Ein Aspekt, der Anwenderbesuchen immer wieder überraschend sein kann, ist das Ausmaß, in dem Anwender auf Papier zurückgreifen, um ihre Aufgaben zu erledigen – seien es schnelle Notizen, die auf einen Schreibblock gemacht werden, um das Gedächtnis kurzfristig zu entlasten, oder auch Klebezettel am Monitor, auf denen Informationen festgehalten werden, die immer wieder von Bedeutung sind. Ist dies nicht bekannt und wird der Blick nur auf Workflows gelegt, wie sie in einer idealen Welt (in der die Gedächtniskapazität von Anwendern quasi unbegrenzt ist) und ohne externe „Hilfsmittel“ durchgeführt werden sollten, so kann viel Potenzial ungenutzt bleiben, wenn es um die Erstellung eines wirklich innovativen Systems geht, dass Anwendern eben nicht nur die „Kernarbeiten“ erlaubt, sondern auch das „Drumherum“ der Arbeit in der Praxis mit abdeckt.
Mehr als Befragungen
Befragungen spielen bei Anwenderbesuchen eine Rolle, allerdings bilden sie in der Regel nicht den Schwerpunkt. Der Kern von Anwenderbesuchen besteht vielmehr in Beobachtungen, die im realen Kontext stattfinden, also z.B. in einem Großraumbüro, in dem ein zukünftiges System zum Einsatz kommen soll. Es kann durchaus passieren, dass in einem solchen Großraumbüro viele Anwender mit Kopfhörern an Ihren Arbeitsplätzen und Musik hören oder eine Noise Cancelling Funktion nutzen, um Ablenkungen zu vermeiden. In einem solchen Fall ist natürlich akustisches Feedback in einem System weitestgehend ohne Nutzen, was für das User Interface Design gewichtige Konsequenzen haben kann.
Das Projektteam gewinnt durch die Beobachtung also tiefgreifende Einblicke in die reale Welt, die alleine mit Befragungen nicht zu gewinnen sind. Erst durch das reale Eintauchen in den Kontext werden Details zu Anwendern, Zielen, Aufgaben, Umgebung etc. sowie deren vielfältige Wechselspiele deutlich – Informationen, die Anwender bei Befragungen niemals im gleichen Umfang preisgeben würden. Dies hat allerdings nichts mit „bösem Willen“ von Anwendern bei Befragungen zu tun. Vielmehr hängt dies damit zusammen, dass bestimmte Aspekte Anwendern gar nicht (mehr) bewusst sind, z.B. bei Arbeitsprozessen und Routinen, die aufgrund langjähriger Erfahrung quasi schon „automatisiert“ ablaufen, ohne dass ihnen noch viel Aufmerksamkeit gewidmet werden muss. Außerdem gibt es bestimmte Faktoren, die von Anwendern als nicht relevant erachtet und deshalb in einer Befragung nicht berichtet werden. Für ein Design-Team können jedoch auch scheinbare „Kleinigkeiten“ wesentlich sein, wenn es um die Gestaltung einer innovativen und benutzerfreundlichen Lösung geht. Insofern sollte das Design-Team sein Wissen über den Kontext möglichst maximieren, um eine Wissensgrundlage zu schaffen, die der Gestaltung einer optimalen User Experience angemessen ist. Und dazu kann keine Methode das direkte „Eintauchen“ in den echten Kontext des (zukünftigen) interaktiven Systems mittels Anwenderbesuch vollständig ersetzen. Erst dadurch werden die vielfältigen und zum Teil subtilen Facetten des Kontexts in ihrer Reichhaltigkeit deutlich und bieten Anknüpfungspunkte zur Gestaltung von Lösungen, die Anwender überraschen und begeistern.
Oft ist es Anwendern z.B. gar nicht bewusst, wie oft sie die Arbeit an einer Aufgabe im Arbeitsalltag unterbrechen. Sei es, weil Kollegen ein Anliegen haben, das Telefon klingelt oder eine Aufgabe mit höherer Priorität schnell einmal „zwischendurch“ erledigt werden muss. All dies hat natürlich Auswirkungen auf Konzentration und Gedächtnis, wird aber bei Befragungen oft schlicht überhaupt nicht von Anwendern thematisiert, weil diese Dinge zum Teil unbewusst als Ausnahme von der Regel gesehen werden, obwohl sie die Regel sind, nach der sich der reale Workflow in den meisten Fällen zu richten hat. Dementsprechend bleibt Potenzial ungenutzt, wenn man das betreffende System nicht auch darauf ausrichtet, es den Anwendern zu ermöglichen, Workflows jederzeit „aussetzen“ zu können und sie nach einer bestimmten Zeit wieder fortzusetzen, z.B. durch schnelle „Bookmark“-Möglichkeiten, automatisches Speichern von Arbeitsständen o.ä.
Fazit
Anwenderbesuche sind eines der wertvollsten User Research Werkzeuge, wenn es darum geht, detaillierte Kenntnisse über den Kontext zu gewinnen, in dem ein System zukünftig zum Einsatz kommen soll. Zuweilen gibt es jedoch Vorurteile über Zweck Durchführung von Anwenderbesuchen, die der Anwendung dieser Methode im Wege stehen. Es ist daher wichtig, zu verstehen, dass Anwenderbesuche nicht schwerpunktmäßig Befragungen sind und dass sie insbesondere auch durchgeführt werden können – und sollten – wenn es noch kein existierendes interaktives System gibt. Gerade wenn der Wunsch nach innovativen Lösungen existiert, die sich optimal in die Welt der Anwender integrieren, führt an fundiert durchgeführten Anwenderbesuchen im Grunde kein Weg vorbei.