Nur wenige Dinge im Geschäftsleben sind schlimmer als ungemütliche Buchhalter, und diese Buchhalterin war richtig sauer. Sie war aufgebracht, weil sie gefühlte 20 Minuten lang nach etwas gesucht hatte, dass so selbstverständlich ist, dass es einfach da sein muss. War es aber nicht.
Die Buchhalterin in unserer Studie suchte nach einem Weg, eine doppelte Unterstreichung zu indizieren. Wenn man eine Spalte mit Zahlen hat, die in Sektionen wie Einkünfte und Ausgaben unterteilt ist, nutzt man für die Summen der einzelnen Sektionen einfache Unterstreichungen. Die Gesamtrechnung ganz unten wird standardmäßig doppelt unterstrichen.
Die Praxis der doppelten Unterstreichung gilt nicht nur bei Computern und Tabellen. Auch wenn man sich Hauptbücher aus dem Industriezeitalter anschaut, sieht man die allgegenwärtige Doppelunterstreichung unter dem Saldo.
Das wollte die User-Test-Teilnehmerin haben. Sie hatte die Sektion Einnahmen, danach kam die ordentlichen Ausgaben-Sektion. Die Anwendung der Formel zur Subtraktion der Ausgaben von den Einnahmen ergab immerhin einen ergreifend kleinen Gewinn. Die Zeile bettelte förmlich um eine doppelte Unterstreichung.
Doch nirgends in der Google-Tabelle konnte sie so etwas finden. Es war eine Tabelle wie Microsoft Excel, Lotus 1-2-3 und alle die anderen davor.
Aber aus unerfindlichen Gründen hatten die Entwickler die doppelte Unterstreichung weggelassen oder versteckt. Die Buchhalterin konnte sich indes nicht vorstellen, dass so etwas Normales nicht im Design enthalten ist, also suchte sie danach.
Und suchte danach.
Und suchte danach.
Alles umsonst. Es war einfach nicht da. Die Entwickler hatten die Funktion weggelassen.
Eine doppelte Unterstreichung ist nicht schwer zu implementieren. Vielleicht haben sie daran gedacht, wollten es aber nicht einbauen, um alles schlank zu halten, und das Feature hat sich nicht für die Umsetzung qualifiziert.
Der Tod durch 1.000 Nadelstiche
Das hielt diese Nutzerin nicht davon ab, die doppelte Unterstreichung zu erwarten und in der Folge etliche Minuten mit der Suche zu verbringen. Dieses einfache Ding regte sie fürchterlich auf und sie ließ uns deutlich wissen, was sie von der Arbeit mit der Anwendung hielt.
Es gab noch andere Features und Elemente, nach denen sie suchen musste. Jede Suche nahm Zeit in Anspruch. Jede hielt sie von ihrem Ziel ab, eine simple Einnahmen-Ausgaben-Aufstellung aufzusetzen, etwas, das sie im Rahmen ihrer Arbeit millionenfach getan hatte.
Die Anwendung war den Tod durch 1.000 Nadelstiche gestorben. Kein fehlendes Feature war für sich betrachtet eine große Sache, aber in der Summe machten sie die Arbeit mit der Anwendung wenig erstrebenswert. Das ist das Problem mit Dingen, die man erwartet und die dann fehlen.
Erwartete, aber fehlende Dinge vs. enttäuschte Erwartungen
In einem Haarstudio, das wir kürzlich besucht haben, war die Empfangsdame niedergeschlagen. Wenn ein Kunde hereinkommt, sollte sie eigentlich auf den Bildschirm mit den heutigen Terminen schauen, den Kunden nach seinem Namen und seinem Wunsch fragen und gut.
Doch ein paar Tage zuvor war der Server der Terminvereinbarungs-Applikation gecrasht. Wenn es denn Backups gab, wusste niemand im Unternehmen und auch der Software-Provider nicht, wie sie wiederhergestellt werden könnten. Alle Daten des Salons waren dahin.
Kunden würden nun also mit Terminvereinbarungen hereinkommen, über die es keine Aufzeichnungen gab. Sie versuchten, alles neu zu erstellen, aber es war extrem frustrierend.
Der Besitzer des Haarstudios hatte die Erwartung, die Daten seines Salons wären sicher. Hardware-Versagen ist im Computerleben seit Jahrzehnten ein Fakt. Der Besitzer hatte erwartet, dass der Software-Provider alle Vorkehrungen treffen würde, um im Katastrophenfall keine Daten und keine Zeit zu verlieren, und nun standen sie mit einer geschäftlichen Katastrophe epischen Ausmaßes da.
Der Datenverlust ist eine Erwartung, die enttäuscht wurde, während bei der Sache mit der Google-Tabelle etwas Erwartetes gefehlt hat. Nutzern und Kunden ist der Unterschied egal, doch Entwicklungsteams sollten ihn berücksichtigen, denn sie müssen an verschiedenen Stellen nach Erwartungen suchen.
Nicht erfüllte Erwartungen lassen sich durch eine gründliche Untersuchung der Anwendung aufdecken. Wir können uns jede funktionale Komponente ansehen und fragen: "Inwiefern könnte es unsere User enttäuschen oder in ihrer Arbeit unterbrechen, wenn dieses Feature nicht wie erwartet funktioniert?"
Dinge, die man erwartet und die dann fehlen, sind teuflischer als nicht erfüllte Erwartungen. Sie sind viel schwerer zu entdecken. Die einfache Untersuchung der Applikation bringt uns hier kaum weiter. Vielmehr muss hier solide Nutzerforschung zum Einsatz kommen.
Umfragen und User-Tests helfen nicht viel weiter
Wenn UX-Experten in ihren Werkzeugkasten greifen, ziehen sie normalerweise zuerst Umfragen und User-Tests heraus. Allerdings sind diese Methoden nicht hilfreich, um potenzielle Dinge aufzuspüren, die Nutzer erwarten und die fehlen.
Stellen Sie sich zum Beispiel vor, ich baue ein Hotel und frage Sie, was Sie von einem idealen Hotelzimmer erwarten. Wahrscheinlich denken Sie jetzt nicht an ein funktionierendes Bad, weil Sie einfach annehmen, ich wisse, dass zu einem Hotelzimmer ein Bad gehört. Aber ich wette, Sie wären ziemlich überrascht, wenn Sie nach dem Checkin kein Bad vorfinden würden.
Nutzern bei der Arbeit mit einer Anwendung zuzuschauen, das Kernprinzip des User-Tests also, ist nicht die optimale Methode, um solche erwarteten, aber fehlenden Dinge aufzudecken. Nur scheinbar sind User-Tests perfekt, aber die Art und Weise, wie wir die Aufgaben konstruieren, die die Teilnehmer mit der Applikation abarbeiten sollen, steht uns im Weg.
Um Tests einfach und unter Kontrolle zu halten, definieren wir im Vorfeld häufig das gewünschte Ergebnis. Beispielsweise hätten wir beim User-Test der Google-Tabelle die Profit- und Verlustrechnung vielleicht schon vorbereitet und die Probanden dann gebeten, sie nachzubauen. Um klarzumachen, was wir erwarten, hätten wir den Teilnehmern das gewünschte Ergebnis schon vorher gezeigt.
Da wir nie im Leben an die Bedeutung der doppelten Unterstreichung gedacht hätten, würde unsere Rechnung auch keine haben. Unsere Teilnehmerin würde das tun, was wir von ihr wollen, und wohl ihrerseits auch keine doppelte Unterstreichung einfügen wollen. Die Beeinflussung durch uns hätte sich in den Testergebnissen niedergeschlagen; die erwarteten, jedoch fehlenden Dinge wären nicht entdeckt worden.
Jeden Kundenkontakt melken
Eine gute Quelle, um solche Erwartungen zu identifizieren, sind Anrufe und Fragen, die beim Kundenservice eingehen. User, frustriert, weil sie etwas nicht finden, sprechen wahrscheinlich regelmäßig die Servicemitarbeiter auf diese Erwartungen an.
Wir haben jedoch herausgefunden, dass die meisten Unternehmen keine gute Arbeit bei der Sammlung dieser Informationen machen. Weil es sich nicht um direkt reparierbare Probleme handelt, werden sie normalerweise nicht systematisch registriert und kategorisiert. Selbst wenn man sie sammelt, geschieht das zumeist nur, indem die Zahl der Anfragen zu einem bestimmten Issue erfasst wird – ohne Informationen darüber, warum die Nutzer es brauchen. Und wenn man das nicht weiß, werden Versuche, es zu implementieren, vermutlich schiefgehen.
Eine Erweiterung der Kundensupportmechanismen um die Sammlung und Kategorisierung der Anfragen kann das Bewusstsein für die beschriebenen Erwartungen schärfen, was im Gegenzug weitere Nutzerforschung legitimiert.
Das ethnographische Spiel
Bewaffnet mit einer vom Kundenservice generierten Liste möglicher Dinge, die Nutzer erwarten und die nicht vorhanden sind, können sich Teams nun ins Feld begeben und beobachten, wie sich diese Bedürfnisse manifestieren. Hier lernen wir wirklich, wodurch und wie wir unsere Anwendung besser machen können.
Wenn man zum ersten Mal Kunden in ihrem Büro oder zu Hause besucht, fühlt man sich, als würde man mitten in der Nacht aufwachen und dann das Licht im Badezimmer anknipsen – Es ist zu grell, um etwas deutlich zu erkennen, ehe sich die Augen darauf eingestellt haben. Die Flut an kontextuellen Informationen, die aus initialen Kundenbesuchen hervorgeht, ist für Neulinge auf dem Gebiet der Feldstudie überwältigend. Entsprechend schwierig ist es zu sagen, was man gelernt hat.
Doch mit weiteren Besuchen bei anderen Kunden kristallisieren sich Muster heraus. Die Definition der erwarteten und fehlenden Dinge wird klar. An jedem Ort zeigen sie sich etwas anders, aber das Grundthema ist dasselbe.
Regelmäßige ethnographische Aktivitäten sind erfolgskritisch für jedes Team, das sichergehen will, den Erwartungen der User zu entsprechen. Die Investitionen dafür sind durch reduzierte Supportkosten, eine stärkere Kundenbindung und eine solide Differenzierung von den Konkurrenten, die keine Feldstudien unternehmen, leicht zu rechtfertigen.
Erweiterte User-Tests: interviewbasierte Aufgaben
Nachdem es im Feld war, kann das Team ähnliche Umgebungen im Labor schaffen. Mithilfe einer Technik, die als interviewbasiertes Task-Design bekannt ist, kann das Team Erwartungen extrahieren, indem es eng simuliert, was die Nutzer wirklich tun, und dabei auch aufdecken, warum die User denken, dass sie es tun müssen.
Statt exakt zu diktieren, was der User-Test-Teilnehmer tun soll, beginnt der Moderator jede Sitzung mit einem Interview. Er fragt danach, wie der Teilnehmer die Aktivitäten, die die Anwendung unterstützt, früher durchgeführt hat. Der Moderator dringt tief dahinter, warum der Proband die Dinge wie tut und wie sich die Applikation für ihn darstellt.
Auf der Grundlage der so generierten Erfahrungen arbeitet der Moderator dann mit dem Probanden eine Aufgabe aus, die einer entspricht, die er tatsächlich zuletzt ausgeführt hat. Dann wird der Teilnehmer gebeten, dieses frühere Nutzererlebnis zu replizieren.
Die erneute Durchführung der Arbeit führt dazu, dass die erwarteten Dinge, die fehlen, an die Oberfläche kommen. Da die auf Basis der Interviews definierten Aufgaben besser zu den früheren Erfahrungen der Nutzer passen, nehmen diese ihre eigenen und gewohnten Verhaltensweisen an. Wenn sie sich sicher fühlen und so arbeiten, wie sie es immer tun, kommen die Stellen, an denen ein Feature fehlt oder etwas ungeschickt implementiert ist, schnell zutage.
Dieser Ansatz ist differenzierter als der, den Standard-User-Tests verfolgen. Viele Fachleute fühlen sich nicht wohl dabei, wenn sie Aufgaben improvisieren sollen und zugleich sicherstellen müssen, dass sie dem Teilnehmer keinen Weg vorgeben, der nur dazu führt, dass sich die Auffassungen des Teams bestätigen.
Mit einer guten Kombination aus ethnographischer Feldarbeit und erweiterten User-Test-Techniken wie interviewbasierten Aufgaben können Teams vermeiden, dass wichtige Dinge fehlen. Selbst die Dinge, die zunächst geringfügig erscheinen, dann aber zum Tod durch 1.000 Nadelstiche führen, lassen sich so aufdecken und nahtlos in die Anwendung integrieren.
Dieser Artikel wurde im Original am 24. Oktober 2012 unter dem Titel The Hunt for Missing Expectations
