Der schnelle Weg zum großartigen Nutzererlebnis: Das ganze Team schaut dem User zu

Als wir untersucht haben, was Teams brauchen, um gute Nutzererlebnisse zu schaffen, sind wir über einen interessanten Fund gestolpert. Was wir gefunden haben, kommt einer Wunderwaffe sehr nahe, die es ermöglicht, die Entwicklungen des Teams zuverlässig zu verbessern. Die Lösung ist so einfach, dass wir es zunächst gar nicht glauben wollten, denn: Wenn es so einfach ist, warum verfährt nicht jeder so?

Um sicherzugehen, haben wir die letzten paar Jahre immer wieder eng mit Teams zusammengearbeitet, ihnen unsere Lösung gezeigt und ihnen bei der Umsetzung geholfen. Und Menschenskind, es funktioniert tatsächlich. Wir waren fassungslos.

Die Lösung? Expositionsstunden. Das sind die Stunden, die jedes Teammitglied direkt mit einem echten Nutzer verbringt, der mit der eigenen Anwendung oder der eines Konkurrenten interagiert. Es gibt einen unmittelbaren Zusammenhang zwischen dieser Exposition und den Verbesserungen, die ein Entwicklungsteam produziert.

Jetzt ergibt alles einen Sinn: Beobachte deine Anwender

Seit mehr als 20 Jahren wissen wir, dass Teams ihre Ergebnisse signifikant verbessern können, wenn sie immer wieder ihren Nutzern zuschauen. Dennoch treffen wir regelmäßig auf Teams, die zwar Nutzerforschung betreiben, aber dennoch komplizierte, unbrauchbare Produkte hervorbringen. Bislang war uns das ein Rätsel.

Jedes Teammitglied muss direkt mit den Usern konfrontiert werden. Teams, die mit hingebungsvollen, professionellen Usability-Fachleuten zusammenarbeiten, die User-Tests durchführen und ihre Ergebnisse in Form von Berichten und Videos vorstellen, erzielen nicht die gleichen Erfolge. Es ist der direkte Kontakt mit den Anwendern, der zu wirklich signifikanten Verbesserungen führt.

Im Laufe der Jahre hat es einige Debatten drüber gegeben, wie viele Teilnehmer für eine solche Studie ausreichen. Es sieht so aus, als hätten wir uns damit auf Nebenschauplätzen aufgehalten. Sobald man sich nämlich auf die Dauer der Exposition konzentriert, erscheint die Anzahl der Teilnehmer nicht länger diskussionsrelevant.

Wir haben herausgefunden, dass zwei Stunden, in denen ein Teammitglied einem User direkt ausgesetzt ist, ebenso wertvoll (wenn nicht wertvoller) sein können wie je 15 Minuten mit acht Teilnehmern. Wenn sie sinnvoll genutzt werden, können diese zwei Stunden mit einem einzigen Nutzer für das Team von unschätzbarem Wert sein. Hier zeigen sich die Feinheiten und Nuancen bei der der Interaktion mit der Entwicklung.

Erste Ausflüge: Feldstudien

Als wir uns angesehen haben, wie verschiedene Teams diesen Prozess durchlaufen, sind uns einige wiederkehrende Muster aufgefallen. Beispielsweise verbringen viele Teams keine oder kaum Zeit damit, ihre Anwender zu beobachten. Bei diesen Teams handelt es sich häufig um solche, die erfolgreiche, profitable Produkte entwickelt haben, die über viele Jahre hinweg zu sehr komplizierten Konstrukten angewachsen sind, vollgestopft mit Features, die kaum ein User findet und die frustrierend zu benutzen sind.

Bevor sie damit beginnen, die Nutzer zu beobachten, sind sich diese Teams in Meetings oft uneinig. Ihnen ist klar, dass die Software immer komplexer wird, aber niemand weiß so recht, wie die Leute tatsächlich mit der Anwendung arbeiten. Entscheider treiben die Implementierung weiterer Features voran, ohne dem Team wichtige Details an die Hand zu geben. Vielfach wird hier nach dem Motto „Lasst es uns bauen, und wenn es schiefgeht, reparieren wir es eben!“ gearbeitet.

Solchen Teams empfehlen wir eine Feldstudie als ersten Ausflug in die Nutzerforschung. Feldstudien sind toll, weil wir die User in ihrer natürlichen Umgebung erleben. Es müssen keine Aufgaben exakt definiert werden. Wir interviewen die Teilnehmer, finden heraus, welche Ziele und Vorstellungen sie haben, und bitten sie, das System für ihre Bedürfnisse zu nutzen.

Eine typische Sitzung dauert zwei Stunden und in der Regel nehmen zehn bis zwölf Personen an einer solchen Feldstudie teil. Im Rahmen eines Tagesausflugs kann jedes Teammitglied mindestens vier Nutzer treffen, von denen jeder die Anwendung auf seine eigene interessante Weise nutzt.

Das Ergebnis ist normalerweise eine Liste mit kleinen Problemen, die sich leicht beheben lassen. Kürzlich waren wir dabei, als ein zehnköpfiges Team zwölf Nutzer besucht hat: Das Ergebnis war eine Liste mit 350 recht einfach umzusetzenden Punkten. Innerhalb weniger Wochen konnten diese Leute ihr Produkt massiv verbessern.

Alle sechs Wochen ist das Minimum

Viele Teams, die wir kennengelernt haben, führen nur ein Mal im Jahr oder sogar noch seltener nutzerbasierte Studien durch. Diese Teams mühen sich fast genauso ab wie solche, die überhaupt keine Nutzerforschung betreiben. Die Anwendungen werden immer komplexer, mit jeder Erweiterung zeigen sich die User frustrierter.

Die Teams mit den besten Ergebnissen betreiben ihre Nutzerforschung kontinuierlich. Für die gerade beschriebene Zwei-Stunden-Dosis scheint sich ein maximaler Zeitabstand von sechs Wochen als effektiv erwiesen zu haben. Teams, deren Mitglieder mindestens alle sechs Wochen jeweils mindestens zwei Stunden mit ihren Nutzern verbringen, produzieren deutlich bessere Ergebnisse als Konkurrenten, die das seltener tun. Und je häufiger solche Studien stattfinden, desto besser.

Diese Regelmäßigkeit ist aus zwei Gründen so wichtig. Erstens funktioniert unser Gedächtnis auf eine bestimmte Art und Weise. Es ist schwieriger, sich an jemanden zu erinnern, den man vor mehr als sechs Wochen getroffen hat, als an jemanden, dem man letzte Woche begegnet ist. Wenn wir wollen, dass wir unsere Anwender und ihre Bedürfnisse immer im Hinterkopf haben während wir unsere Produkte entwickeln, müssen wir sie regelmäßig sehen.

Der zweite Grund hat mit dem Schmerz zu tun, den andauernde Frustration verursacht. Es ist eine Qual, Leute dabei zu beobachten, wie sie sich mit unserer Anwendung herumplagen. Noch schmerzhafter ist die Tortur, wenn wir ein paar Wochen später wiederkommen und sehen, dass sie schon wieder mit denselben Problemen kämpfen. Je häufiger wir diesem Leid ausgesetzt sind, desto frustrierter werden wir und umso dringlicher wollen wir diese Probleme beseitigen (und umso glücklicher sind wir, wenn wir schließlich sehen, dass jemand unser neues Release als Kinderspiel empfindet).

Einige Probleme sind besonders knorrig. Wenn wir „im Feld“ oder im Labor feststellen, dass diese Probleme immer wieder auftreten, erhalten wir Einblicke in die Nuancen, die über die potentiellen Ursachen hinausgehen. Das Ausprobieren neuer, alternativer Umsetzungsideen kann uns helfen, schneller zu Lösungen zu kommen. Regelmäßige User-Forschung unterstützt die Lösungsfindung in jedem Fall.

Mit diesem sechswöchigen Zeitfenster machen wir uns diese beiden Faktoren zunutze, so werden unsere Anwender und ihre Bedürfnisse zum Antrieb für unsere tägliche Arbeit.

Möglichkeiten der Anwender-Exposition

Neben Feldstudien gibt es natürlich noch andere funktionierende Methoden. User-Tests, ob klassisch oder als Remote-Tests angelegt, sind sehr effektiv. (Unserer Erfahrung nach bringt ein Mix aus „klassisch“ und „remote“ im Vergleich zur reinen Remote-Test-Strategie allerdings bessere Ergebnisse.) Sobald wir die Aufgaben kennen, die User mit unserer Anwendung normalerweise erledigen – viele dieser Use-Cases entdecken wir bei unseren Feldstudien –, ist es leicht, ein realistisches Szenario für einen User-Test zu entwerfen.

Auch Leute, die sich intensiv mit Self Design beschäftigen und ihre Entwicklung selbst jeden Tag nutzen (siehe Manchmal entwickelt man Software doch für sich selbst), können wichtige Erkenntnisse liefern. Der Abgleich dieser Resultate mit den durch andere Methoden gewonnenen Ergebnissen hilft uns zu verstehen, welche unerwünschten Erfahrungen die User machen, wenn sie mit unserer Anwendung interagieren.

Übrigens sollte man nicht darauf verzichten, Nutzer auch bei der Arbeit mit Produkten der Konkurrenz zu beobachten. Sehen wir, wie die Teilnehmer die gleichen Aufgaben mit einer anderen Anwendung erledigen, erkennen wir nicht nur Lücken in unserer eigenen Software, sondern finden auch heraus, wo wir im Vorteil sind.

Das Team der Beeinflusser

Bei unseren Untersuchungen kam noch ein anderes, überraschende Ergebnis heraus: Teams, die Mitarbeiter ausschließen, die nicht unmittelbar mit Usability, Design und Umsetzung zu tun haben, erzielen weniger gute Ergebnisse als Teams, bei denen alle Personen in die Nutzerforschung integriert sind.

Beispielsweise haben wir mit Unternehmen zusammengearbeitet, in denen nur die Designer und Entwickler regelmäßig mit Anwendern in Kontakt kommen; andere Leute wie Produktmanager, Abteilungsleiter oder Kollegen aus den Bereichen technischer Support und Qualitätssicherung bleiben bei Feldstudien und User-Tests außen vor. Während das Kernteam intensiv mit den Bedürfnissen der Nutzer vertraut ist, hat es ständig Konfrontationen mit den Personen auszufechten, die diese Erfahrungen nicht teilen.

Die Stimmung schlägt um, wenn alle, auch die entfernt Beteiligten in die Nutzerforschung integriert werden. Dann stellen diese Leute ihre eigenen Vorstellungen nicht mehr über die Forschungsergebnisse. Die Teilnahme von Führungskräften, Entscheidungsträgern und anderen nicht unmittelbar in die Entwicklung involvierten Mitarbeitern führt insgesamt zu einem rundum anwenderorientierten Prozess.

Die Exposition ist leicht zu messen. Man kann einfach die Stunden zählen, die jeder an Usability-Studien teilgenommen hat. Wir halten es für sinnvoll, diese Beteiligung in die individuellen Zielvereinbarungen aufzunehmen (auch in die der Entscheider!) und so eine klare Botschaft auszusenden: Die Erfahrung, mit realen Anwendern zusammenzuarbeiten, ist sehr wichtig!

Die Herausforderung: Alle sechs Wochen zwei Stunden für jeden

Zugegeben, unsere Daten könnten fehlerhaft sein. Vielleicht spielen noch weitere Aspekte eine Rolle. Doch wir haben jede mögliche Theorie getestet, jeden denkbaren Faktor überprüft und wir kommen immer wieder auf diesen Punkt zurück: Lassen Sie alle sechs Wochen jedes Teammitglied zwei Stunden mit den Usern verbringen. Höchstwahrscheinlich werden Sie deutlich bessere Nutzererlebnisse erzielen.

Dieser Artikel wurde im Original am 30. März 2011 unter dem Titel Fast Path to a Great UX - Increased Exposure Hours von Jared M. Spool veröffentlicht. Jared M. Spool gehört zu den führenden Usability-Experten unserer Zeit. Seine Website erreichen Sie unter http://www.uie.com. Weitere Artikel von Jared M. Spool finden Sie im Usability-Special von //SEIBERT/MEDIA.

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar