Ein frühes Einbinden von Nutzer*innen in Software-Entwicklungsprozesse ist mehr als notwendig. Diese Erkenntnis hat sich mittlerweile herumgesprochen. Leider ist es aber mit einem simplen „Da fragen wir halt unsere Nutzer” nicht getan. Gerne wird mit halbgaren Methoden ins Feld gegangen – und das User-Feedback landet anschließend unreflektiert in Form von Lösungsvorschlägen direkt in To-Do-Listen oder in Sprint Boards. Das kann gravierende negative Folgen für das Produkt haben. Wie lässt sich Feedback also strukturiert aufnehmen und was sagt das über die Menschen aus, die mit dem Produkt in Berührung kommen? Wie lernen wir schließlich, das richtige Produkt zu bauen, ohne den geäußerten Wünschen blind zu folgen? Hier sind ein paar Vorschläge.
The Homer – oder wie man es nicht macht
Das perfekte Beispiel für blinden Gehorsam gegenüber User-Wünschen und das daraus resultierende Ergebnis im Produktdesign lässt sich schön bei den Simpsons beobachten: Staffel 2, Folge 15 – „Oh Brother, Where Art Thou?”. Homer wird als Stellvertreter des typischen Durchschnitts-Amerikaners gebeten, sein Wunschauto zu designen. Was folgt? Klare Feature-Wünsche:
- Zwei Glaskuppeln: Eine für den Fahrer, die andere für die Kinder mit Fesseln und Maulkörben für selbige
- Ein apokalyptisches Motorgeräusch
- Drei Hupen, die alle „La Cucaracha” spielen
- Ein überdimensionierter Getränkehalter
Spoiler Alert: Das Auto wird ein Flop. Homer alleine wäre damit wahrscheinlich glücklich gewesen, aber selbst darüber kann man sich letzten Endes nicht sicher sein. Man sieht ihn schließlich nie damit fahren.
Viel Feedback führt zu einem besseren Verständnis
Die Geschichte klingt überzeichnet, findet aber in ähnlicher Form in Softwareprojekten immer wieder statt: Nutzer*innen, oftmals nicht die leisesten, werden repräsentativ für eine ganze Gruppe auserkoren und nach ihren Wünschen befragt, die man folglich eins-zu-eins erfüllt. Oder noch schlimmer: Es melden sich viele Einzelstimmen, die alle eine eigene Meinung haben, individuelle Bedürfnisse aussprechen oder ganz einfach Wunsch-Features beschreiben, die ihnen das Produkterlebnis hoffentlich versüßen. Wer da als Produktverantwortliche*r keine klare Haltung und Vision hat, wird dem Rauschen der Feedback-Stimmen leicht erliegen, frei nach dem Motto: „If you don’t stand for anything, you’ll fall for everything.”
Sollten wir im Umkehrschluss also das Ohr nicht in Richtung Nutzer*innen halten? Weit gefehlt! Viel Feedback ist gut und wichtig. Der springende Punkt: Was machen wir daraus? Feedbacks sind keine Handlungsaufträge, die ins Backlog wandern, Feedbacks sind Datenpunkte auf dem Weg zu einem besseren Verständnis unserer User-Gruppen. Aber erst aus der richtigen Kondensation aller Datenpunkte lassen sich hilfreiche Schlüsse über das Produktdesign ziehen. Nutzer*innen selbst sollen das Produkt nicht direkt gestalten. Sie haben ein Problem, das wir lösen sollen. Und auf diese Problemebene wollen wir das Feedback transformieren.
Sagen vs. Tun
Schon Jakob Nielsen hat in einem Artikel 2001 provokativ geschrieben „First Rule of Usability? Don't Listen to Users”. Er meint damit, dass Menschen sehr schlecht darin sind, ihr eigenes Verhalten zu beschreiben. Dies bezieht sich auf vergangenes und gegenwärtiges, insbesondere aber auf zukünftiges Verhalten. Einer Aussage wie „Das Feature werde ich mit Sicherheit oft nutzen” kannst du nicht vertrauen, selbst wenn sie offenherzig und ehrlich gemeint ausgesprochen wird.
Zielerreichung lässt sich besser beobachten als erzählen
Nielsen schlägt sinngemäß vor, Menschen dabei zu beobachten, wie sie ihre Aufgaben erledigen, um ein übergelagertes Ziel zu erreichen. Ist das Ziel beispielsweise ein “Opernbesuch in München” folgt die Hauptaufgabe “Online-Ticket kaufen”, woraus sich wiederum Unteraufgaben ableiten wie “Tag wählen”, “Sitzplatz wählen” oder “Bezahlen”. Im Rahmen von Kontextanalysen oder Usability-Tests lässt sich sehr gut beobachten, wie leicht oder schwer diese Aufgaben aktuell zu erledigen sind. Lügen geht dabei nur schlecht: Die Lösung klappt entweder gut, mit Schwierigkeiten oder schlimmstenfalls überhaupt nicht, aber man kann sich eine nicht erfüllte Aufgabe schwer schön reden. Dabei kann die subjektiv empfundene User Experience übrigens sehr gut sein, obwohl die Probandin gerade vielleicht das Ticket für die falsche Vorstellung gekauft hat, ohne es zu merken. Sie ist glücklich, aber merkt (noch) nicht, dass die Aufgabe nicht erfüllt ist. Auch hier wiegt das tatsächlich Geschehene schwerer als die geäußerte Emotion.
Auf verzerrende Einflüsse achten
Gerade bei explizit verbalem Feedback ist der Kontext, in dem es ausgesprochen wurde, von immenser Wichtigkeit. Oftmals schleichen sich unbewusste, voreingenommene Haltungen oder Verzerrungen ein, auch Bias genannt, die das Urteilsvermögen und damit den Wahrheitsgehalt der Aussagen stark beeinflussen. Äußerungen von Fokusgruppen sind beispielsweise gerne stark geprägt von der dort herrschenden Gruppendynamik und den impliziten Erwartungshaltungen. Äußern sich vier von fünf Partizipant*innen einer Fokusgruppe deutlich negativ über ein Produkt, hängt es stark von der Persönlichkeit des*der fünften Teilnehmer*in ab, ob er*sie das vielleicht positive Erlebnis dennoch ausdrücken möchte. Im Zweifel kommt es nicht zur Sprache und das Gesamturteil fällt in der Gruppe zu hundert Prozent negativ aus. Am Ende kann eine einzige dominante Stimme ausschlaggebend sein, um den Ton und damit das Gesamtbild maßgebend zu beeinflussen. In Einzelinterviews wäre ein ganz anderes, differenzierteres Urteil das Resultat gewesen. Dieser Wirkkräfte musst du dir bewusst sein, wenn du Daten verwendest, die auf diese Weise erhoben wurden.
Zu großer Bias macht Studien-Ergebnisse unwirksam
Ein anderes Beispiel aus dem Kontext Usability-Testing beschreibt sehr treffend den Effekt „Sagen vs. Tun“ unter Bias-Einfluss. Stell dir vor, du wählst für den geplanten Usability-Test des hauseigenen Online-Shops selbst die Proband*innen aus. Dafür selektierst du nur persönlich bekannte Premium-Kund*innen, die du im Vorfeld in Form eines sehr wertvollen Geschenkkorbs inklusive persönlichem Dankesschreiben incentivierst. Während des Testings können die Proband*innen dabei beobachtet werden, wie sie an den ihnen gestellten Aufgaben scheitern. Sie schaffen es beispielsweise nicht, ein vorgegebenes Produkt über die Suche zu finden, beschreiben aber gleichzeitig die User Experience als durchweg positiv und loben dich über den grünen Klee. Frei nach dem Motto: „Ich kann den Turnschuh zwar nicht finden, aber es ist so wunderschön hier”. Auch in diesem Fall ist das beobachtete Verhalten der relevantere Ansatz für Produktverbesserungen, während das explizit geäußerte Erlebnis in krassem Kontrast dazu steht und erwartungsgemäß von viel mehr Frustration hätte geprägt sein müssen. Hier ist auf jeden Fall der Wunsch nach sozialer Zustimmung am Werk, auch Social Desirability Bias genannt und mit Sicherheit auch eine Stichprobenverzerrung, ein Selection Bias. Als ausgewählte*r Premium-Proband*in möchte wohl niemand undankbar wirken, dafür war der Champagner aus dem Geschenkkorb zu lecker. Diese Wirkkräfte sind jedoch keine kleinen Verzerrungen mehr, sondern sie stellen die Validität des gesamten Forschungsprojekts in Frage. In diesem Fall heißt die Lösung: eigenständig neue Proband*innen rekrutieren – oder Abbruch.
Wer Visionen hat, sollte zum User gehen
Neben der möglichst von Einflüssen befreiten Erhebung von Daten kommt mit dem Double Diamond aus dem Design Thinking ein besserer Ansatz, um mit Feedback umzugehen: Zuhören, nachfragen und verstehen lernen, bevor du in die Umsetzung gehst.
Problemraum: Verstehen
Während der divergenten Phase „Verstehen” gilt es, im Problemraum so viel Feedback aus so vielen zur Verfügung stehenden Kanälen zu generieren, wie möglich und wie sinnvoll. Das können quantitative Daten aus einer Web-Analytics-Anbindung sein, Ergebnisse aus Online-Umfragen oder KPIs wie die Retention Rate, die insgesamt dabei helfen, ein plastisches Bild über das User-Verhalten zu zeichnen. Bei Produkten, die bereits in den Händen der Nutzer*innen liegen, kann es sinnvoll sein, Feedback-Tools direkt in die Anwendung zu integrieren oder regelmäßig Usability-Tests zu veranstalten, um zu erfahren, wo momentan Schmerzen auftreten und um damit die quantitativen Daten qualitativ zu ergänzen. So soll aus der Frage „Was passiert?” ein „Warum passiert es?” werden.
Noch aber weiß man zu diesem Zeitpunkt meist zu wenig, um dem Feedback blind vertrauen zu können und damit dann direkt in die Umsetzung zu gehen. Lautet ein User-Feedback beispielsweise: „Ich möchte hier für die Tabelle einen Excel-Export.” wäre das ein eindeutiger Indikator dafür, das direkte Gespräch mit Endanwender*innen zu suchen, die genau diesen Bedarf ausdrücken. Jetzt gilt es, so lange „Warum?” zu fragen, bis du zum Kern des Problems vorgedrungen bist: „Was soll mit den Daten in Excel passieren? Warum und wie werden die Daten in Excel neu arrangiert? Werden die Daten aus Excel heraus in ein anderes Tool überführt? Wie wurde in der Vergangenheit mit den Daten umgegangen? Haben die Kollegen einen ähnlichen Bedarf?“. Und so weiter.
Problemraum: Definieren
Beim qualitativen Forschen kann das „Warum?” so lange eingesetzt werden, bis sich ein Sättigungsgefühl gegenüber den Ursprungsfragen eingestellt hat und ein Gefühl für die Hintergründe da ist. Zeichnet sich jetzt ein klareres Bild für die Problematik ab, gilt es, die zahlreichen erhobenen Daten wiederum in der konvergenten Phase des „Definieren” zu verdichten und in eine klare Problemdefinition zu überführen.
Diese Definition kann in Artefakten wie Personas oder Szenarien münden, aus denen heraus einfach erklärt wird, woher der Bedarf einer bestimmten User-Gruppe nach den genannten Excel-Exports kommt, welche Schmerzen der Bedarf im Arbeitsalltag lindern soll und welche konkreten Aufgaben und Ziele damit verbunden sind. Bestenfalls kann eine auf Daten basierte Modellierung von Personas auch helfen, Einzelfeedbacks in Zukunft richtig einzuordnen. Ist die Frage nach einem bestimmten Feature ein exotischer Einzelwunsch oder gehört sie zum bereits bekannten Schmerz einer archetypischen User-Gruppe, auf die man sich auf jeden Fall ausrichten möchte? Das kannst du nun alles besser beantworten.
Eine gute Vision sorgt für Fokus im Lösungsraum
Auf das gesamte Produkt gespiegelt kann die Problemdefinition auch positiv als Vision formuliert werden. Diese steht als Nordstern über dem Projekt und gibt die Richtung an, ohne konkret zu beschreiben, wie das Produkt die Probleme im Einzelnen löst. Wenn ein Team intern geklärt hat, für wen und in welchem Kontext welches Problem gelöst werden soll, fällt es auch leichter, eine Haltung gegenüber Feedback aus allen Richtungen zu bewahren. Und bestenfalls ist dennoch genug Offenheit vorhanden, um bei wiederkehrenden Feedback-Mustern noch einmal in den Problemraum zurückzukehren und zu gucken, ob man Dinge übersehen oder vielleicht noch nicht richtig verstanden hat. Nutzer*innen und deren Probleme und Bedürfnisse zu verstehen, bleibt ein andauernder Lernprozess, ist aber im Wesentlichen etwas vollkommen anderes, als Nutzer*innen eins-zu-eins ihre Wünsche zu erfüllen. Erst mit einer klaren Vision über das eigene Handeln und den Wert, der bei den Endnutzer*innen erzeugt werden soll, bist du einem Feedback von außen nicht mehr hilflos ausgeliefert und kannst die Einflüsse strukturiert unter die eigene Strategie einordnen.
Anekdotisches zum Abschluss
Die Telefon-Service-Abteilung eines Online-Shops soll in Beratungsgesprächen effizienter arbeiten. Fragt und beobachtet man die Damen und Herren aus besagter Abteilung bei ihrer täglichen Arbeit, klagen sie darüber, dass die Endkund*innen für ihre Identifikation am Telefon entweder ihre Shop-Konto-Nummer durchgeben, die Auftragsnummer einer Bestellung oder aus Versehen die Paketnummer des Transportdienstleisters. Alle drei Nummern befinden sich auf verschiedenen Masken auf dem Bildschirm der Service-Mitarbeiter*innen verteilt, zwischen denen im Kontext eines Telefonats umständlich hin- und hergeschaltet werden muss. So gestaltet sich das Gespräch in den ersten Minuten mühsam für alle Beteiligten, weil man sich erstmal „finden” muss. Ein eloquenter Mitarbeiter der Telefon-Service-Abteilung schlägt also vor: „Wir packen alle drei Eingabefelder auf eine Seite, dann müssen wir nicht mehr blättern und haben alles auf einen Blick”. Das Entwicklungsteam nimmt das Feedback dankbar an, die Lösung klingt sinnvoll und kommt von einem täglichen Anwender. Am bestehenden System werden also die drei Eingabefelder auf einer Seite zusammengeführt und man hofft auf erhöhte Effizienz.
Ginge man hier zurück auf Anfang und zurück zur Frage nach dem „Warum”, würde man bei der Problembeschreibung weniger über Eingabefelder sprechen, sondern eher über die Aufgabe der Service-Abteilung, Kund*innen möglichst effizient zu identifizieren, um über ein aktuelles Problem mit einer kürzlich getätigten Bestellung zu sprechen. Betrachtet man das Problem also aus einer höheren Flughöhe und versperrt sich auch im Lösungsraum über geeignete Ideation-Methoden nicht gegenüber alternativen Ansätzen, käme man beispielsweise auf Ideen, wie die anrufenden Personen über die schon halbwegs smarte Telefonanlage der Service-Abteilung zu identifizieren und den aktuellen Auftrag schon auf dem Bildschirm zu präsentieren, bevor die Service-Mitarbeiter*innen den Hörer überhaupt abgenommen haben. Über eine derartige Automatisierung hatte der Feedback-gebende Mitarbeiter aber nicht mehr nachgedacht, weil die initiale Identifikation zum integralen Bestandteil seines Arbeitsalltags geworden ist und das Telefonsystem für ihn bis dato keine großen Interaktionsmöglichkeiten bietet.
Gute UX bewegt sich über aktuelle Systemgrenzen hinaus
Nutzer*innen, die täglich und über Jahre in einem System arbeiten, denken häufig auch in den Grenzen dieses Systems, wenn sie Feedback geben. Dabei ist es unsere Aufgabe als Entwickler*innen und Produktgestalter*innen, über diese Grenzen hinweg und im Rahmen aktueller technischer Möglichkeiten Anwendungen zu bauen, die die grundlegenden Probleme unserer Nutzer*innen nachhaltig lösen. Das geht nur über ein tiefgreifendes Verständnis. Und obwohl auch bei Einzelfeedbacks eine innovative Perle dabei sein kann, sollten wir uns die Hoheit über die Frage bewahren, wie Probleme am effektivsten für Endanwender*innen gelöst werden können.
Es ist ein bisschen wie beim Zahnarzt. Dieser möchte hören, wo es wehtut. Beispielsweise rechts oben. Er möchte nicht hören, dass man sich beim 17er eine Wurzelbehandlung mit anschließender Keramikverkronung wünscht. Der Zahnarzt macht im Regelfall nämlich erst einmal selbst ein Röntgenbild, um zu sehen, was los ist. Diesem Beispiel sollten wir im übertragenen Sinne auch folgen.
Der Artikel ist ebenfalls veröffentlicht in der Spezialausgabe von der Softwerker customercentric.
