Während der einstündigen Diskussion gingen Maren und Johanna der Frage nach, warum der Digital Gender Gap existiert und diskutierten mögliche Lösungen. In der Diskussion ging es einerseits um die Ungleichheit innerhalb der Belegschaften in digitalen Teams, aber auch um den sogenannten “Digital Gender Data Gap”. Der Digital Gender Data Gab bezieht sich auf den Zustand der Daten, welche Algorithmen füttern und mit denen KIs trainiert werden. Diese sind aktuell ziemlich einseitig und benachteiligen marginalisierte Gruppen. Diese Themen führten uns im Laufe des Diskussion zu der Frage: Wenn wir einen Online-Accessibility Countdown haben, warum haben wir eigentlich keinen Countdown für Digitale Inklusivität, einen Online-Inclusivity Countdown?

Was ist der Online-Accessibility-Countdown?

Der Online-Accessibility-Countdown bezieht sich auf ein 2021 erlassenes Gesetz, das kurz gesagt verlangt, dass digitale Services für Menschen mit Einschränkungen in der EU zugänglich sein müssen. Annika Brinkmann stellte daraufhin eine Seite ins Netz, die anzeigt, wie viele Tage noch bleiben, bis alle Webseiten in der EU zugänglich sein müssen. Auf der Seite wir der Online-Accessibility-Countdown beschreiben: “Am 28. Juni 2025 tritt der European Accessibility Act (EAA) in Kraft. Dann müssen auch die Webseiten von Firmen mit mehr als 10 Mitarbeiter:innen und mehr als 2 Mio. EUR Jahresumsatz barrierefrei sein bzw. die, die danach veröffentlicht werden.”
Der Online-Accessibility-Countdown ist jedoch nicht das Thema dieses Beitrags – er ist uns nur als Vorlage dienlich, eine Inspiration für eine wirklich zugängliche und inklusive digitalisierte Welt.

Warum brauchen wir einen Digitalen-Inklusivitäts-Countdown?

Grund #1 Wenn wir fortschrittlich werden wollen dürfen wir nicht am Status quo festhalten

Beim Digitale Gender Gap gibt es viele Aspekte, auf die man sich konzentrieren kann. Eines sind z.B. homogene, weitgehend männerdominierte Teams innerhalb der Tech-Industrie. Es existiert eine Ungleichheit innerhalb der Belegschaft von Arbeitsteams in der Tech Branche, wobei der Anteil der Frauen in der Branche je nach geografischem Standort etwas variiert. Laut www.womentech.net wird es zwischen 53 Jahre (in Lateinamerika und der Karibik) bis 189 Jahre (in Ostasien und im Pazifikraum) dauern, um diese Ungleichheit zu schließen. Dies hat direkte und indirekte Auswirkungen auf die Produkte und Services, welche entwickelt werden, da ein relativ einseitiger Blickwinkel entsteht.

Obwohl die o.g Zahlen schockierend sind, wird sich unsere Petition für einen Digital-Inklusivitäts-Countdown darauf konzentrieren, die sogenannte Digital Gender Data Gap zu schließen. Der Grund dafür ist, dass durch die rasante Entwicklung der KI ein Rückschritt bzw. Stillstand anstatt einer Verbesserung der Inklusivität bei digitalen Diensten und Produkten droht, was sofortiges Handeln erfordert.

Aktuell ist die Wahrscheinlichkeit sehr hoch, dass Daten, auf die sich Algorithmen verlassen und mit denen KIs trainiert werden, voreingenommen, sexistisch und daher schädlich oder diskriminierend gegenüber marginalisierten Gruppen sind. Dieser Zustand ist historisch bedingt. Während der Panel Diskussion sagte Maren Hetschle zurecht, dass in einer ungerechten Welt mit ungerechten Daten faire Systeme utopisch erscheinen.

Ein zusätzliches Problem: Trainingsdaten werden nicht reguliert. Dies ist u.a. wirtschaftlich bedingt. Die Geschäftsmodelle und der Wettbewerbsvorteil der meisten KI-Unternehmen würden zunichte gemacht, wenn man Einsicht in die Daten bekommen könnte. Wenn es nun den Anschein macht, dass wir uns ausschließlich im Interesse des Erfolgs der KI-Unternehmen darauf geeinigt haben, dass eine Regulierung auf internationaler Ebene unmöglich ist, ist das nur die halbe Wahrheit. Denn es besteht die Frage: wer, also welche Instanz sollte denn für die Regulierung der Daten international zuständig sein?

Wenn man nun glaubt, dass es einige Zeit dauern wird, bis die Folgen dieser Entwicklung hässliche Ausmaße annehmen wird, sollte man einen Blick in einen aktuellen UNESCO-Bericht werfen, der bereits heute Beweise für regressive Geschlechterstereotypen in der generativen KI findet (www.unesco.org/en/articles/generative-ai-unesco-study-reveals-alarming-evidence-regressive-gender-stereotypes). KI, mit der z.B. Kinder und Jugendliche bereits heute ihre Hausaufgaben machen.

Grund #2: Diskriminierung bedeutet (wirtschaftliche) Chancen zu verpassen.

27 % der in der EU lebenden Menschen leben mit einer oder mehreren Beeinträchtigungen. Zwar sind nicht alle Menschen mit Einschränkungen bei der Interaktion mit digitalen Produkten beeinträchtigt, aber die Zahl der Menschen, die von nicht inklusiv gestalteten Systemen betroffen sind, ist groß genug, um die EU zur Vernunft zu bringen und den European Accessibility Act (EAA) in Kraft zu setzen.

Es ist deshalb umso verwunderlicher, dass es noch keinen Countdown zur Online-Inklusivität gibt, da der Frauenanteil in der EU im Mittel mit fast 51% Bevölkerungsanteil die Mehrheit bildet. Aufgrund dieser Fakten erscheint es geradezu absurd, dass wir derzeit noch nicht einmal versuchen, Datenmodelle, die in Algorithmen einfließen, zu regulieren. Denn faktisch diskriminieren sie die meisten Menschen.

Egal welche Rolle Frauen, also die Hälfte der Weltbevölkerung für Deine tägliche Arbeit bedeuten: ob es sich dabei um Kund*innen, Mitarbeiter*innen, Patient*innen oder Wähler*innen handelt, wenn man sich bei der Interaktion mit diesen Menschen auf diskriminierende Daten verlässt, wird man Chancen und Möglichkeiten z.B. zur Gewinnung von Kund*innen, Mitarbeiter*innen oder Wähler*innen ungenutzt lassen.

Grund #3: Diskriminierung ist teuer

Falls das Argument der Diskriminierung gegenüber mehr als 50 % Bevölkerung zu schwach erscheint, könnten die finanziellen Auswirkungen von Diskriminierung gegenenfalls ein überzeugenderes Argument sein.

Ein kostspieliges Entwicklungsfiasko wie das Amazon Recruiting Tool oder das österreichische Arbeitsmarktservice Arbeitsmarkt-Chancen-Assistenzsystem (AMAS) (Stefanies Talk beim WUD Berlin reißt dieses Tool an: youtu.be/PndW3UR_p1s?si=uRhYHQJpB-DSrp2k&t=483) hätte vermieden werden können, wenn die u.a. Daten vor der Entwicklung der Tools ausgewertet und angepasst worden wären.

Falls Du nun glaubst, dass diese Art der Diskriminierung Dein Budget nicht negativ beeinflusst, weil Du z.B. keine Tools entwickelst, dann liegst Du falsch. Wenn Du z.B. das Internet nutzt, um darin Werbung für deine Zielgruppe zu schalten, könnten diskriminierende Algorithmen verhindern, dass Du die gewünschten Personen erreichst. Mehr dazu: algorithmwatch.org/en/automated-discrimination-facebook-google.

Wir sind sicher, dass es noch viele weitere Gründe gibt, die für einen Online-Inclusivity-Countdown sprechen würden, deren Auflistung wird aber nur dann relevant sein, wenn wir eine Antwort auf folgende Frage finden: Wie entwerfen wir nicht-diskriminierende Systeme und Dienstleistungen, wenn unsere Werkzeuge fehlerhaft sind?

Derzeit scheint der internationale Konsens zu sein, dass eine Datenbereinigung und -anreicherung, sowie die Regulierung von Trainingsdaten nicht umsetzbar sind. Wir werden daher unsere eigenen Lösungen entwickeln müssen.

Gerechte Systeme in einer ungerechten Welt entwerfen

#1 Lerne Deine Daten kennen

Egal ob Du ein Design auf Analytics Daten basierst oder ob Du eine KI mit Datensätzen trainierst, schaue Dir Deinen Datensatz genau an und stelle ihn auf die Probe. Finde heraus, wie, wann und von wem die Daten gesammelt wurden. Frage, welche Art von Daten gesammelt wurde und – vielleicht noch wichtiger – was nicht gesammelt wurde. Tust Du dies nicht, befindest Du Dich mehr oder minder im Blindflug. Dies wäre vergleichbar mit der Performanz Analyse einer Webseite, die nicht von Spam-Traffic bereinigt wurde.

#2 Lerne Deine Benutzer*innen kennen

Nutzer*innenforschung kann mehr als nur nutzer*innen zentriertes Design informieren. Sie hat auch das Potenzial, vorhandene Daten durch eigene zu ergänzen und diese somit herauszufordern. Dies ist insofern wichtig, da Daten selten neutral und unvoreingenommen sind. Echte Erkenntnisse kann man sich nur sichern, indem man die Menschen fragt, für die man gestaltet. Um zu verhindern, dass diese Erkenntnisse zu einer weiteren Quelle von voreingenommenen Daten werden, sollten diese gründlich dokumentiert sein und z.B. erklären, wie Designentscheidungen von ihnen beeinflusst werden.

#3 Diversifiziere Deine Teams

Jede Person ist letztendlich das Ergebnis aus “Nature und Nurture” (Anlage & Umwelt). Verschiedene Menschen, geprägt von verschiedenen Umgebungen, stellen verschiedene Fragen und entwickeln verschiedene Lösungen. Das ist ein Vorteil, den man unbedingt nutzen sollte.

Während wir nichts weiter tun können, als zu hoffen, dass der Online-Inklusivitäts-Countdown eines Tages zu ticken beginnen wird, werden wir nicht untätig herumsitzen und auf diesen Tag warten! Wenn Du Hilfe bei der Erstellung inklusiver Design Lösungen benötigst, melde Dich gerne bei uns! Der erste Geekettez Claim lautete “We Design For Humans”. Diesem Anspruch sind wir seit 2012 treu geblieben. #PowerToThePeople

Weiterführende Links und Quellen:

• Initiative D21: initiatived21.de/publikationen/digital-gender-gap
• Online Accessibility Countdown von Annika Brinkmann: online-accessibility-countdown.eu
• Women Tech Network: www.womentech.net/en-de/women-in-tech-stats
• Generative AI: UNESCO study reveals alarming evidence of regressive gender stereotypes: www.unesco.org/en/articles/generative-ai-unesco-study-reveals-alarming-evidence-regressive-gender-stereotypes
• Fakten und Zahlen zum Thema Behinderung in der EU: www.consilium.europa.eu/de/infographics/disability-eu-facts-figures
• Percent female population – Country rankings: www.theglobaleconomy.com/rankings/percent_female_population/Europe
• Amazon’s “holy grail” recruiting tool was actually just biased against women: qz.com/1419228/amazons-ai-powered-recruiting-tool-was-biased-against-women
• Austria’s employment agency rolls out discriminatory algorithm, sees no problem: algorithmwatch.org/en/austrias-employment-agency-ams-rolls-out-discriminatory-algorithm
• “UUX – aber bitte inklusive” – Stefanies Talk beim WUD 2021, Berlin: https://youtu.be/PndW3UR_p1s?si=uRhYHQJpB-DSrp2k&t=483
• Automated discrimination: Facebook uses gross stereotypes to optimize ad delivery: algorithmwatch.org/en/automated-discrimination-facebook-google

Oft herrschen innerhalb eines Teams und Unternehmens sehr viele unterschiedliche Meinungen, wer die Nutzer*innen oder Kund*innen sind und welche Wünsche, Bedarfe, Fragen und Ziele diese haben. In der Folge wird relativ schwammig vom “User” oder den “Nutzer*innen” gesprochen. Diese “User” sind jedoch sehr formbar und können sich den Meinungen und Vorannahmen der jeweiligen Person, die gerade über den/die “User” spricht, perfekt anpassen. Alan Cooper, der „Erfinder“ von Personas nannte dieses Phänomen „The elastic user“.

Statt aus der Perspektive der Nutzer*innen wird somit anhand von Meinungen und Annahmen oder gar aus der Perspektive der Technik entschieden und priorisiert, welche Funktionen geplant werden oder welche Features wann umgesetzt werden.

Die Folge sind Systeme, die an den Nutzer*innen vorbei entwickelt und eventuell überladen sind, keinen echten Mehrwert bieten, dem Wettbewerb nicht weiter standhalten oder nichts Neues im Sinne einer Innovation bereitstellen.

Eine Lösung bieten hier research-basierte Personas. Research-basierte Personas können als Ausgangspunkt für Journey Maps dienen, welche wiederum das Optimierungs- sowie Innovationspotenzial von Produkten und Services offenlegen. So werden die Requirements- sowie Produktentwicklung und die Priorisierungen von Funktionen enorm erleichtert und basieren auf fundierten Entscheidungen statt auf Meinungen.

Was sind Personas?

Personas sind prototypische Beschreibungen von repräsentativen Nutzer*innen. Sie werden basierend auf qualitativen Interviews und ggf kontextbezogenen Beobachtungen erstellt. Kurz gesagt, sind Personas eine Möglichkeit, User Research Ergebnisse zusammenzufassen. Sie sind weder echte Menschen noch ein “durchschnittlicher” Benutzer oder sollten gar auf Stereotypen basieren. Sie sind Benutzermodelle.

Abb. 2: So könnte ein Persona Profil aussehen: Die Persona hat einen Namen, Ziele, Präferenzen, Bedenken und Fragen

Aber was heißt das überhaupt – „Modell“ ? George Box, ein bekannter Statistiker hat dies einmal in seinem bekannten Spruch „All models are wrong, but some are useful”  auf den Punkt gebracht. Burnham und Anderson (2002) erklärten Modelle als “ (….) eine Vereinfachung oder Annäherung an die  der Realität (…) sie spiegeln daher nicht die gesamte Realität wider.” Kurz gesagt, werden Modelle verwendet, um komplexe Dinge  wie beispielsweise Hirnforschung , das Universum oder U-Bahnpläne  mit einer nützlichen Abstraktion darzustellen.

Personas sind Benutzermodelle

Warum legen wir hier so viel Wert darauf? Wir sind der Überzeugung, es ist sehr wichtig zu verdeutlichen, dass Personas als Modelle gesehen werden, denn dies bedeutet, dass wir uns jederzeit bewusst sind, dass sie nicht zu 100% die Realität widerspiegeln, sondern eine Abstraktion dieser komplexen Realität sind. Sie sind als Werkzeuge zu sehen, um Forschungsergebnisse zu kommunizieren und helfen für ein geteiltes Verständnis dieser Ergebnisse im Team bzw. im Unternehmen.

Diese Abstraktion führt zu der Frage: Warum verwenden wir Modelle und nutzen nicht einfach die Realität?

Der U-Bahn-Plan der BVG ist ein hervorragendes Beispiel für ein Modell. Der Plan enthält die wichtigsten Informationen, um an das gewünschte Ziel zu gelangen: eindeutige Namen und Farben für jede Linie, die Reihenfolge der Stationen auf jeder Linie, die Umsteigebahnhöfe zwischen den Linien usw. Aber die für uns als Fahrgäste weniger wichtigen Details  – wie z. B. die Tiefe der einzelnen Tunnel, die genaue Entfernung zwischen den Stationen werden ignoriert. Eine Tiefbaufirma z.B. benötigt hierzu andere Modelle, da sie etwas anderes tun möchte als einfach von A nach B zu fahren. Für uns als Fahrgäste wäre ein solches Detailgrad im Plan nicht nötig, es könnte sehr wahrscheinlich sogar die Lesbarkeit für uns enorm erschweren und den Plan für uns unverständlich machen.

Abb.3: Ein Modell des BVG U-Bahn Netzes mit sinnvollen Abstraktionen der Realität

Auch Modelle des Universums erklären nicht, wie das Universum in der “Realität” funktioniert, aber sie machen das Konzept für nicht-Astrophysiker greifbar und ersparen uns Fachjournals zu wälzen, um ein Verständnis über das Themengebiet zu bekommen.

Genauso kann Nutzer*innenforschung verwendet werden, um beschreibende Modelle der Nutzer*innen zu erstellen. Diese Modelle helfen, die Komplexität der Interviewdaten auf eine besser verständliche Weise in das Team zu kommunizieren. Modelle zeigen die Funktionsweise von Dingen in einer konsumierbaren Form, die zugänglich und leicht zu kommunizieren sind. Es ist einfacher, einige wenige Personas zu kommunizieren, als alle ethnographischen Reporte zu lesen.

Personas informieren den IST Zustand einer User- oder Customer Journey

Anhand der research-basierten Personas bekommt man Einblicke in die Fragen, Bedürfnisse und Bedenken, aber auch in typische Nutzungsszenarien. Aus diesen Informationen ist es möglich, einen IST-Zustand der Customer Journey abzuleiten – mit all ihren positiven und auch negativen Erfahrungen – den Pain Points. Diese Pain Points sind genau das, was von großem Interesse ist – denn hier steckt das Potenzial für Optimierungen und Neuerungen.

Was sind Journey Maps?

Eine Journey Map ist eine Darstellung aller Interaktionspunkte (oder: Touchpoints) zwischen Ihren Nutzer*innen/Kund*innen (repräsentiert durch die Personas) und Ihrem Produkt bzw. Dienstleistung. Journey Maps repräsentieren somit die momentane Nutzer*innenerfahrung und eignen sich hervorragend, um Optimierungspotenzial aufzudecken. Durch die auf den Interviewdaten basierenden Personas werden die jeweiligen Interaktionspunkte / Touchpoints ermittelt. Anschließend wird pro Touchpoint der Ist-Zustand der Nutzererfahrung auf diesen Touchpoints “gemappt”. Dies können positive als auch negative Erfahrungen wie Sorgen, Ängste, Fragen oder Bedenken sein, die aus Interviews ersichtlich wurden. Anhand dieses Mappings wird sichtbar, wo die Optimierungspotenziale stecken: Oftmals genau in  den „Lücken“ einer positiven Nutzererfahrung.

All dies wird in einer Übersicht zusammengefasst, so dass klar wird, wo genau der größte Optmierungsbedarf besteht.

Abb. 4: Ein Beispiel, wie eine User/Customer Journey Map aussehen kann

Diese Darlegung der Nutzererfahrung mit dem Produkt/der Dienstleistung stellt dann einen wertvollen Ausgangspunkt für die folgende Ideenphase (Future Scenarios/ Maps) sowie für die Priorisierung der Funktionen und die weitere Produktentwicklung dar.

Fazit:

Research-basierte Personas und die daraus resultierenden Journey Maps sind hervorragende Werkzeuge, um anschließend fundierte Ideen zur Ausschöpfung der Optimierungspotentiale zu entwickeln. Dies wiederum bildet eine solide Basis für eine an Nutzer*innen ausgerichtete und priorisierte Requirement – und Produktentwicklung, denn mit einem abteilungsübergreifenden Verständnis über Ihre Nutzer*innen und Kund*innen stellen Sie sicher, dass das ganze Team ein gemeinsames Verständnis der Nutzer*innen und deren Ziele und Bedürfnisse hat und treffen fundierte Entscheidungen darüber, was wann umgesetzt werden soll und verringern somit Ihr Kostenrisiko in einem  Neu- oder Umgestaltungsprozess.

Quellen

• Alan Cooper , Robert Reimann , Dave Cronin, About face 3: the essentials of interaction design, John Wiley & Sons, Inc., New York, NY, 2007
• Burnham, K. P.; Anderson, D. R. (2002), Model Selection and Multimodel Inference: A Practical Information-Theoretic Approach (2nd ed.), Springer-Verlag

Bild: Header Photo by Kaleidico on Unsplash

Das Wissen um die Gefühle und Sorgen der Versuchspersonen ist nicht unerheblich, denn Untersuchungen wie Usability-Tests gehen auch mit einem gewissen psychologischen Druck auf die Teilnehmenden einher, der sich wiederum auch negativ auf das Testergebnis übertragen kann.

Mögliche Ängste von Proband*innen

• „Stage fright“ bzw. Performance-Angst. Dieser Leistungsdruck kann sich sich wiederum auf Selbstsicherheit sowie Selbstwirksamkeit auswirken und in eine Art selbsterfüllende Prophezeiung münden.
• Proband*innen könnten sich „dumm“ fühlen, wenn sie Tasks nicht lösen können oder Dinge im System nicht finden. Sie schieben sie Schuld auf sich und nicht auf das System, es fühlt sich für sie an wie ein IQ Test.
• Sie vergleichen sich innerlich mit anderen Nutzer*innen nach dem Motto: „Andere stellen sich sicher nicht so doof an…“

Als Moderator*innen eines Tests sollten wir daher immer versuchen, uns in die Situation der Teilnehmenden hinein zu versetzen: Diese sitzen als Proband*innen im “Rampenlicht”, sind also Mittelpunkt der Beobachtung und werden aufgefordert, Aufgaben mit einem für sie unbekannten und möglicherweise nicht optimal nutzbaren Produkt vor fremden Menschen durchzuführen. Es ist ganz natürlich, dass man in der Situation ggf. etwas nervös ist. Bei den Teilnehmenden kommen dann Gedanken auf wie z.B.  „Mache ich das richtig?“  oder: “Halten mich diese Leute für dumm, weil ich es nicht verstanden habe?“

Dieser Druck ist real. Jared Spool, ein amerikanischer Usability-Berater, erzählte eine Geschichte darüber, wie er eine Testperson während eines Usability Tests weinen sah. Diese Situation kam durch eine Anhäufung von unbedachtem Verhalten seitens der Moderator*innen und Testleiter*innen zustande: Der ursprüngliche Teilnehmer tauchte am Testtag nicht auf und dann wurde einfach eine Angestellte, die gerade ihren ersten Arbeitstag absolvierte auf die Schnelle als Ersatz herangezogen. Das Team dachte, dass es eine gute Idee ist, sie zu nehmen, da sie anders als andere Angestellte wenig über das Produkt wusste. Im Beobachtungsraum saßen zudem eine Reihe von Beobachter*innen,  die nicht darüber informiert waren, wie sie sich während eines Tests verhalten sollten, darunter auch der Chef  der Probandin. Und last but not least wurde kein Pilottest durchgeführt, so dass das Team nicht wusste, dass die erste Aufgabe, die die Teilnehmenden erledigen sollten, in Wirklichkeit völlig veraltet, falsch formuliert und somit unmöglich durchzuführen war. Während die Frau verzweifelt versuchte, diese erste Aufgabe durchzuführen, wurde allen außer ihr schnell klar, dass die Aufgabe veraltet und nicht durchführbar war, und sie fingen an, über ihre eigene Dummheit zu lachen. Leider dachte die Benutzerin, dass man über sie lachte, und sie fing dann an zu weinen.

Das ist genau eine Situation, die wir vermeiden möchten.

Wie man auf diese Ängste reagieren kann

Man kann solchen Ängsten entgegentreten indem wir z.B. immer wieder betonen, dass wir nicht die Proband*in testen, sondern das System. Dieses „ich bin zu blöd, den Computer zu bedienen“ basiert leider auf internalisiertem Denken. Self-blaming ist hier ein Problem. Viele Nutzer*innen von Computersystemen denken immer noch, dass es ihr Fehler sei, wenn etwas nicht klappt, dass sie nicht “richtig” mit der Software  umgehen können und beschuldigen sich eher selbst als das System.

Hier ist ein Satz den wir gerne bei Tests in dieser oder abgewandelter Form gebetsmühlenartig wiederholen:
„Wir testen nicht Sie, wir testen das System.” und:  “Jegliche Probleme, die Sie ggf haben werden, sind die Schuld des Systems. Und genau um diese Probleme aufzuspüren, benötigen wir Ihre Hilfe, um das System besser und gut bedienbar zu machen. Sie helfen, das System zu bewerten/zu evaluieren, da wir dafür zu betriebsblind sind.“

Auch das Wording/Framing – also wie man  die Untersuchung an sich bezeichnet spielt hierbei eine Rolle. Wenn wir zum Beispiel  von “User testing” sprechen, impliziert dies, dass wir den User testen möchten. Dem ist aber nicht so. Wir testen die Nutzbarkeit des Systems, daher  sollte man tatsächlich eher von „Usability Testing / Überprüfung” sprechen – vor allem vor den Nutzer*innen.

Zudem spielt ein wertschätzender und respektvoller Umgang eine große Rolle. Klingt eigentlich selbstverständlich, dennoch ist es wichtig, sich immer wieder daran zu erinnern, gerade wenn es hektisch zugeht.

Daher im Folgenden einige grundlegende und einfache Möglichkeiten um psychologischen Stress bei Proband*innen zu reduzieren und einen Usability Test nach ethischen Richtlinien durchzuführen.

11 ethische Prinzipien für einen Usability-Test

1. Sprache. Wir plädieren für die Vermeidung des Begriffs “User test”.  Wir testen nicht den User, wir testen ein System mit Hilfe der Nutzer*innen.
2. Schaffen einer freundlichen Atmosphäre. Die Atmosphäre sollte entspannt sein und frei von Ablenkungen, Störungen wie z.B. Zwischenfragen von anderen gehalten werden. Bei In-Person Tests werden auch Getränke sowie kleine Snacks immer gerne gesehen.
3. Proband*in ankommen lassen. Begrüßung und etwas Smalltalk sind wichtig zum “Ankommen” und Entspannen der Teilnehmenden. Daher sollte man dies zeitlich mit einplanen.
4. Informierte Einwilligung. Die informierte Einwilligung ist einige Tage vor dem Test an die Probanden auszuhändigen und spätestens am Tag des Tests unterschrieben an das Testteam zu geben. In dieser Einwilligung sollte über den Zweck der Untersuchung und den groben Ablauf des Tests informiert werden. Außerdem sollte verständlich und genau beschrieben sein, wie die Ergebnisse verwendet werden und wie sichergestellt wird, dass die Daten des Teilnehmers vertraulich behandelt werden. Die Teilnehmenden sollten über die Nutzung der Daten umfassend und verständlich aufgeklärt werden. Dies heisst, es sollten sich Infos darüber finden wer auf die Daten zugreifen kann, wo und wie lange die Daten gespeichert werden (DGSVO) und wie lange die Teilnehmenden die Löschung ihrer Daten oder deren Nichtverwendung beantragen können – denn sobald Daten anonymisiert wurden ist das meist schwierig. Auch sollten die Freiwilligkeit der Teilnahme und der zu jedem Zeitpunkt mögliche Abbruch des Tests seitens der Proband*innen erwähnt werden. Weiterhin sollten für eventuelle Fragen Kontaktmöglichkeiten angeboten werden.
5. Wiederholung der Aufklärung direkt vor dem Test. Bevor der Test beginnt, geht man am besten nochmals alle Punkte, die auch in der informierten Einwilligung zu finden sind, kurz mit den Proband*innen durch und stellt nochmals sicher, dass alles verstanden wurde und es diesbezüglich keine offenen Fragen mehr gibt. Empfehlenswert ist es, nochmals auf die Anonymisierung der Daten einzugehen und den Proband*innen zu erklären, dass z.B. Zitate, welche in Reports oder Präsentationen auftauchen, nicht auf die jeweiligen Personen zurückverfolgbar sind. Auch sollte man nochmals darauf hinweisen, dass die Proband*innen den Test absolut freiwillig durchführen und das Recht haben, den Test jederzeit abzubrechen. Somit sind die Proband*innen in der Kontrolle, wenn sie sich aus welchem Grund auch immer z.B. anfangen unwohl zu fühlen.
6. Warm-up Fragen/Pre-Test Interview. Vor dem eigentlichen Test, bei dem wir mit der Bearbeitung der Aufgaben loslegen, ist es gut, wenn wir zuerst mit thematisch passenden allgemeinen Warm-up Fragen starten. Diese Fragen sind meistens sowieso von Interesse und eher offener Natur, wie z.B. Fragen über bisherige Nutzung des betreffenden Produktes /Services, Fragen zur Häufigkeit der Nutzung, Fragen zu konkreten Erlebnissen von der letzten Nutzung etc. Diese Konversation (Pre-Test Interview) hilft den Proband*innen weiter etwas “herunterzufahren”, etwas zu entspannen und sich mit der Umgebung und den Moderator*innen vertraut zu machen.
7. Non-verbale Cues und Mimik kontrollieren. Während  wir mit den Proband*innen zusammen sitzen, sollten wir uns niemals ungeduldig verhalten und auch implizite, unbewusste Verhaltensmuster auf dem Schirm haben – wie z.B unsere Mimik. Das ist leichter gesagt als getan, denn vieles passiert einfach unbewusst. Daher ist es eine gute Idee, dies mit in das Moderationsskript aufzunehmen bzw. das Thema auf dem Schirm zu haben. Eine im falschen Moment hochgezogene Augenbraue, ein zu lautes Atmen oder nervöses Fingertippeln kann völlig missinterpretiert werden und seitens der Proband*in auf sich selbst bzw. die Leistung bezogen werden – mit Auswirkungen auf den Test.
8. Zeit der Teilnehmenden respektieren. Es ist ein Zeichen von Höflichkeit, wenn wir die Zeit  unserer Teilnehme*innen respektieren: Das bedeutet für uns, gut vorbereitet zu sein und zeitlich nicht zu überziehen. Hier kommt auch die besondere Rolle des sogenannten Pilottests ins Spiel: Der Pilottest dient dazu, unseren Test zu testen :)– der Test des Tests sozusagen. Der Pilot ist sehr hilfreich, um herauszufinden, ob unsere Aufgaben für Verwirrung bzw. Unklarheiten sorgen oder Fehler beinhalten und ob die Testbedingungen insgesamt “smooth” laufen. Der Pilottest  läuft genau wie ein richtiger Test ab, inklusive Proband*in, Einwilligung, Skript etc…und  findet einige Tage vor dem ersten richtigen Test statt. Somit haben wir noch genug Zeit eventuelle Korrekturen einzupflegen oder Aufgaben verständlicher zu formulieren.
9. Nach dem Test: Datenverwendung nochmals bestätigen lassen. Am Ende der Test Session sollten die Moderator*innen nochmals sicherstellen/abfragen, ob der/die Proband*in mit der Verwendung der Daten einverstanden ist. Es kann sein, dass die Proband*innen sich das während der Teilnahme anders überlegen. Ein späterer Rücktritt davon ist, wie bereits erwähnt, meist wegen der Anonymisierung der Datensätze schwierig bis nicht möglich. Dies sollte deutlich kommuniziert werden.
10. Bei Remote Tests: Technik-Setups am Vortag anbieten. Bei moderierten Remote Test Sessions ist es sinnvoll, Technik Setups z.B einen Tag vorher anzubieten. Hier besteht die Möglichkeit sich mit der Technik wie z.B Screensharing mithilfe einer Testseite (nicht dem Testprodukt an sich!) vertraut zu machen. Positiver Nebeneffekt:  Die Proband*innen lernen das Testteam schon mal kennen, das hemmt die Aufregung am Teststag sowie eventuelle Berührungsängste.
11. Transparente Kommunikation über weitere Beobachter*innen. Manchmal wollen und sollten (!) auch Manager*innen oder Entwickler*innen bei den Tests zusehen können. So erleben Mitglieder des Teams die Probleme hautnah mit, welche die Nutzer*innen bei der Bedienung des betreffenden Systems erleben und dies kann wichtig sein, um ein Verständnis für UX in Unternehmen zu etablieren und darüber den UX Reifegrad eines Unternehmens zu steigern. Auf der anderen Seite kann es problematisch werden, wenn zu viele Personen gleichzeitig den Test beobachten, denn dies bringt eine weitere künstliche Dimension mit in den Test indem Nutzer*innen sich noch mehr „beobachtet“ und “getestet” fühlen. Somit können Leistungsdruck und die “Performance Angst“ steigen, was wiederum die Testergebnisse verfälschen könnte. Also lieber weniger Beobachter und lieber das Team pro Test oder Testreihe rotieren, statt das komplette Team in den Beobachtungsraum zu stellen.

Falls zusätzlich zu den Moderator*innen noch weitere Personen den Test beobachten…

• … sollte auf jeden Fall transparent darauf hingewiesen werden und es ist sinnvoll, dass diese Personen kurz bei der Begrüßung dabei sind. Es sollte immer offen und ehrlich kommuniziert werden, wer warum zuschaut.
• ….müssen wir sie unbedingt gut briefen, wie sie sich vor, während und nach dem Test zu verhalten haben. Es geht darum, dass keine Unterbrechung durch Zwischenfragen oder Bemerkungen erfolgt oder wie oben bereits erwähnt unbewusste Gestik, Mimik oder Geräusche vernehmbar sind (Schnauben, Gähnen, Lachen, Fingertippeln). Wir erzählen gerne  die oben genannte Geschichte von Jared Spool, da sie eindrücklich demonstriert wie schnell es unabsichtlich falsch laufen kann.
• …ist es hilfreich, den Beobachter*innen z.B. einige Sticky Notes auszuhändigen um Unterbrechungen in Form von Fragen der Beobachter*innen zu vermeiden. So kann man das Gefühl der “drängenden” Frage, die jetzt sofort gestellt werden muss, entkräftigen. Hier haben Beobachter*innen die Möglichkeit, ohne Unterbrechung des Tests ihre Fragen oder Gedanken direkt aufzuschreiben. Diese können sie sie uns  Moderator*innen dann am Ende des Tests überreichen. Wir sichten diese kurz und geben diese Fragen ggf dann an den/die Proband*in weiter. Auch dies sollte zeitlich eingeplant werden. Durch dieses Vorgehen bleiben die Moderator*innen Hauptansprechpartner für die Testperson und es gibt keine Unruhe und  Durcheinander.

Fazit: Macht „Versuchspersonenstunden“!

Es gibt sicher noch sehr viel mehr zu sagen, dennoch sollten diese grundlegenden Punkte erst einmal ausreichen. Wir können nur allen Designer*innen, Produktmanager*innen und Entwickler*innen empfehlen, ähnlich wie Psychologiestudierende auch „Versuchspersonenstunden“ zu absolvieren und öfter selbst in die Rolle der Probanden zu schlüpfen und einen Usability Test aus dieser Perspektive mitzumachen. So bekommt man ein Gespür, wie sich das alles anfühlt und kann diese Erfahrung in die Gestaltung eines eigenen Tests mit einbringen.

Illustration: Question illustrations by Storyset

Summative Tests: Ist unser Produkt effizient?

Bei summativen Tests liegt der Fokus meist auf statistischen Kennzahlen. Hier geht es grob gesagt um Effizienz – also darum herauszufinden bzw zu messen – ob die gestaltete Lösung effizient ist.

Typische Fragen, die ein solcher Test beantwortet, sind z.B. ob das Design einem bestimmten Maßstab oder Kriterium entspricht. Dies können einerseits Fragen sein, welche die benötigte Zeit zur Erledigung einer Aufgabe betreffen wie z.B.

• Wie lange brauchen Proband*innen für Aufgabe X?
• Sind Proband*innen in der Lage, Aufgabe x in (z.B.) unter einer Minute zu erledigen?

Dies ist besonders relevant im industriellen Kontext, in der Medizin und immer wenn Geräte (Autos, Flugzeuge) gesteuert werden müssen – also überall da, wo Reaktionszeiten eine Rolle spielen.  Summative Tests werden aber auch im Benchmarking eingesetzt – also um Vergleiche anzustellen. Typische Fragen wären hier z.B:

• Performt unser Produkt besser als das Produkt der Konkurrenz?
• Performt Design A besser als Design B?
• Klicken mehr Menschen bei Design A auf den Button als bei Design B?

Ein typischer Vertreter dieses Bereiches sind z. B. A/ B Tests.

Typische Ergebnisse von summativen Tests basieren auf Zahlen

• 40% unserer Anwender konnten die Aufgabe x in weniger als 30 Sekunden erledigen.
• Design A hat eine 40% höhere Fehlerquote als Design B.
• In Design A klicken 20% mehr Personen auf den Button als in Design B.

Die Ergebnisse betreffen also ”wie viel”, oder “wie lang” –  beantworten aber meistens nicht das “warum” hinter einem spezifischen Verhalten. Es wird als „summativer“ Test bezeichnet, da es das Ziel hat, die Ergebnisse zusammenzufassen / zu “summieren”.

Voraussetzungen summativer Tests

Für summative Tests benötigt man in der Regel ein fertiges Produkt oder mindestens einen voll funktionalen Prototypen, da sie „richtig“ funktionieren müssen, um eine valide Aussage über die Effizienz treffen zu können.

Summative Tests erfordern zudem mindestens um die 20-30 (+/-) Teilnehmer*innen, abhängig von den verwendeten statistischen Methoden. Wir brauchen also jemanden, der sich mit Statistik und den Voraussetzungen für die jeweiligen statistischen Methoden auskennt.

Formative Tests: Wie erleben Nutzer*innen das Produkt / Design?

Formative Tests sind häufiger innerhalb von UX Designprozessen anzutreffen, da sie als Teil eines iterativen Designprozesses eingesetzt werden können. Das Ziel von formativen Tests besteht darin, dass wir etwas über das Erleben (Experience) und das Verhalten der Teilnehmer*innen herausfinden – z.B. sollten uns Teilnehmende direkt  mitteilen, wenn sie etwas verwirrend oder komisch finden. Diese Tests beantworten – anders als summative Tests – also oftmals das “warum” hinter einem spezifischen Verhalten.

Formative Tests beantworten Fragen wie:

• Wie erleben die Menschen unser Design?
• Wo bleiben sie hängen, und vor allem: warum bleiben sie da hängen?
• Was sind die größten Probleme/Herausforderungen mit unserem Design, die wir als nächstes beheben sollten?

Formative Tests können bereits früh im Designprozess helfen Optimierungspotenzial zu identifizieren. Das heißt, formative Tests sollten idealerweise schon sehr früh im Designprozess z.B. mit Klick-Dummies gemacht werden, um erste Probleme zu erkennen und schnell zu beheben.

Ein typisches Ergebnis so eines Tests ist zumeist qualitativer statt quantitativer Natur z.B.:  “Teilnehmende hatten Schwierigkeiten, die Aufgabe X zu erledigen, weil die Schaltflächen mit der Bezeichnung OK / Cancel  verwirrend wirken.“

Formative Tests werden also durchgeführt, wenn das Ziel darin besteht, Probleme zu aufzudecken um weiteres UX Potenzial zu identifizieren. Sie helfen uns dabei, das Design für ein Produkt oder eine Dienstleistung zu „formen”. Daher der Name „formativ“. Im Gegensatz zu summativen Tests, bei denen wir aufgrund der Voraussetzungen für statistische Methoden mehr Proband*innen benötigen, lassen sich bei formativen Tests mit ca. 7-10  Benutzern bereits einige der Hauptprobleme aufspüren, die sich  anschließend optimieren lassen.

Zusätzliche Infomationen gewinnen mit der Methode des Lautes Denkens /Thinking aloud

Oftmals liegen erfahrungsgemäß die Gründe für Abbrüche darin, dass sich Nutzer*innen nicht gut zurechtfinden oder sich schlecht informiert fühlen. Und dies kann man wunderbar mit formativen,  moderierten Usability Tests und der Methode des „Lauten Denkens“ (Ericsson & Simon, 1984) herausfinden. Beim „Lauten Denken“ geben die Teilnehmer*innen einen ständigen Kommentar über ihre Denkprozesse ab, während sie mit dem System interagieren. Das hat zum Ziel, zusätzliche Informationen über die kognitiven Prozesse der Teilnehmenden während der Bedienung des zu testenden Systems zu gewinnen: Was geht ihnen während der Bedienung durch den Kopf? Was für Fragen haben sie gerade? In welche Wissenstrukturen ordnen sie die präsentierten Informationen ein? Was irritiert oder verwirrt sie?

Limitationen der Methode des Lauten Denkens

Selbstverständlich kann man nur das laut denken, was auch bewusst ist. Einige –  eigentlich sogar sehr viele Prozesse laufen bei uns Menschen aber unterhalb der Bewusstseinsschwelle ab und können daher nicht verbalisiert werden (Wilson, 1994).

Dies ist wichtig zu verstehen und das ist der Grund wieso wir für diese Form der Usability Tests auch eher moderierte Tests empfehlen. Moderierte Usability Tests sind ein hervorragendes Instrument, um das WARUM hinter Abbrüchen und schlechten Conversion Rates herauszufinden.

Auf subtile Verhaltenscues reagieren mit moderierten formativen Tests

Bei einem moderierten Test findet nämlich – und das ist das wichtige daran – eine Echtzeit Interaktion zwischen den Usability Expert*innen, welche den Test moderieren – also die Teilnehmenden hindurchführen – und den Proband*innen statt. Das bedeutet, dass wir als Usability Experten entweder remote über eine Videokonferenz oder vor Ort mit den Proband*innen zusammensitzen und sie durch den Test führen.  Das ist bei unmoderierten Usability Tests so nicht möglich, da bei unmoderierten Tests keine Echtzeit Interaktion mit den Proband*innen stattfindet. Dazu später mehr.
Durch die stetige Beobachtung während eines moderierten Usability Tests können wir unabhängig davon, was laut gedacht wird – also dem was verbalisiert werden kann – zusätzlich subtile Hinweisreize im Verhalten – sog. Verhaltenscues –  wie z.B. Mimik oder Augenzusammenkneifen, Stirnrunzeln etc. identifizieren, notieren und später nach dem eigentlichen Test gezielt auf diese Stellen, die solche subtilen Cues beinhalten zurückkommen. Oftmals sind diese subtilen Verhaltenscues ein Indikator dafür, dass Nutzerinnen sich unsicher fühlen, es aber nicht unbedingt verbalisieren (können), da es Ihnen – wie oben erläutert –  nicht zwingend bewusst ist. Das Ziel ist es also, dann später nach dem eigentlichen Test zusätzlich zu den offensichtlichen problematischen Punkten genau an diese Stellen zurückzukehren, bei denen solche subtilen Verhaltenscues beobachtbar waren und hier tiefer nachzuforschen, ob da was nicht verstanden wurde, Unsicherheit voherrschte und was denn da eventuell los war. Oftmals bekommt man dann weitere wertvolle  Informationen, wenn man nochmals zu den entsprechenden Stellen zurückkehrt und die Proband*innen Dinge z.B wiederholen lässt und dabei gezielte Nachfragen stellt.

Unmoderierte formative Tests

Dieses gezielte Nachfragen ist bei unmoderierten Usability Tests so leider nicht möglich, denn unmoderierte Usability Test Sessions werden vom Teilnehmer allein durchgeführt, d.h. die Proband*innen führen den Test meistens remote von zuhause mithilfe von speziellen Online Tools aus. Diese Sessions werden in Bild und Ton aufgezeichnet, so dass wir als Usability Experten sie nachträglich sichten und auswerten können. Hier findet also keine Echtzeit Interaktion mit den Proband*innen statt. Trotzdem ist es möglich, Fragen in die Studie zu bauen, welche entweder nach jedem Task (z.B „wie schwer fandest du das?“) oder am Ende der Sitzung angezeigt werden. Diese Fragen sind jedoch meist  standardisiert – also für alle Proband*innen gleich. Es gibt in unmoderierten Sessions keine Möglichkeit, detaillierte Fragen zu stellen, die sich speziell auf das Verhalten der jeweiligen Teilnehmenden beziehen, bzw. auf die Proband*innen im Einzelnen einzugehen.

Weitere  Nachteile können zudem sein, dass in unmoderierten Sessions weniger laut gedacht wird – einfach weil niemand da ist der die Proband*innen daran erinnert. Wir haben in unmoderierten Sessions schon die Beobachtungen gemacht, dass die Teilnehmenden mit der Zeit immer schweigsamer wurden. Das ist  schade, denn so weiß man nie, was  Proband*innen gerade durch den Kopf geht während sie die Aufgabe bearbeiten.

Zudem kann es sein, dass Proband*innen abbrechen, Aufgaben überspringen oder generell eher unmotiviert sind, die Aufgaben zu erledigen. Oft  erfahren wir selten, woran z.B ein Abbruch lag. Funktionierte die Technik nicht? Hatten sie keine Lust mehr? Wurden sie unterbrochen oder war die Aufgabe zu schwer? Somit könnten einige Sitzungen nicht auswertbar sein. Gerade beim moderierten Test entsteht durch den sozialen Druck der direkten Beobachtung  doch etwas mehr Motivation, die Aufgaben auch durchzuführen bzw. sich darauf einzulassen.

Das Fehlen der detaillierten Nachfragen zu spezifischen Problemen, welche die jeweiligen Probanden hatten ist ein großer Nachteil der unmoderierten Tests –  gerade bei Tests, die in einer frühen Designphase durchgeführt werden sollen. Unmoderierte Tests werden gerne wegen ihrer angeblichen Zeitersparnis herangezogen. Selbstverständlich spart man die Zeit, in der die Moderatoren mit den Teilnehmenden 1:1 interagieren – jedoch kommt dies unserer Meinung nach oftmals mit einem nicht unerheblichen Erkenntnisverlust einher, den wir oben dargestellt haben. Zudem erfordert auch ein unmoderierter Usability Test genau die gleiche – wenn nicht sogar noch mehr– Planung wie ein moderierter Test. Wenn trotz alledem eine unmoderierte Test Session durchgeführt werden soll, empfehlen wir dies ausschließlich für Systeme, die funktional sind, wie z. B. Live-Webseiten, da nicht funktionales in einem Klick Dummy z.B zu viele Fragen aufwerfen könnte. Im Zweifel empfehlen wir immer eine moderierte Session anstelle einer unmoderierten Session, da moderierte Sessions wie gesagt in der Regel mehr Erkenntnisgewinn bringen.

Wir sehen also,  welche Art eines Usability Tests durchgeführt werden soll – summativ oder formativ und moderiert oder unmoderiert hängt daran, was und wie genau man etwas herausfinden möchte. Summative Tests können bei einem funktionalen Prototypen oder einem fertigen Produkt gut helfen, Informationen über die Effizienz eines Produktes zu liefern und formative Tests helfen entweder schon sehr früh im Designprozess oder auch bei fertigen Produkten problematische Stellen und somit weiteres UX Potential zu identifizieren. Bei den formativen Tests bieten moderierte Tests den großen Vorteil spezifischer Nachfragen und erhöhen somit deutlich die Chancen detaillierte  Einblicke in das Nutzer*innenerlebnis und somit wertvolle Erkenntnisse zur Verbesserung und UX-Optimierung des Systems zu bekommen.

Literatur

• Ericsson, K. A., & Simon, H. A. (1984). Protocol analysis: Verbal reports as data (p. 426). The MIT Press.
• Wilson, T. D. (1994). The Proper Protocol: Validity and Completeness of Verbal Reports. Psychological Science, 5(5), 249–252. https://doi.org/10.1111/j.1467-9280.1994.tb00621.x

Illustration

Web illustrations by Storyset

Oft hört man auch den Begriff „User testing“. Wir empfehlen diesen Begriff insbesondere vor den Nutzer*innen aus dem Wortschatz zu streichen. Wir “testen” nicht unsere Nutzer*innen, sondern unsere Nutzer*innen testen unser System für uns, weil wir in der Regel zu betriebsblind dafür sind.

Was aber bringen Usability-Tests?

Hier sind vier gute Gründe warum man in Usability-Tests Zeit investieren sollte.

#1 Optimierung der Conversion

Durch Usability-Tests lassen sich in der Regel sehr gut Probleme in der Bedienung von Systemen wie Software oder Webseiten und Apps identifizieren und Gründe für Abbrüche herausfinden, um sie anschließend zu beheben. Es werden also Möglichkeiten und Potenziale zur Optimierung von Systemen aufgedeckt. Außerdem lernt man –  wenn man sie regelmäßig und oft durchführt – eine Menge darüber, wie Nutzer*innen denken und handeln.

#2 Senken von Supportkosten

Gerade bei großen Firmen mit Kundensupport lassen sich Kosten einsparen. Wenn Nutzer*innen zum Beispiel Probleme haben sich auf einer Webseite zurechtzufinden oder diese zu bedienen steigen oft Anfragen beim Kundensupport. Mit Hilfe von Usability-Tests und dem Identifizieren von Problemstellen und anschließender Optimierung lassen sich diese Anfragen senken. Dies macht  sich langfristig bezahlt.

Unser Tipp lautet hier: Den Kundensupport einfach einmal die Top 3 Probleme der letzten Monate auflisten lassen und dann einen Usability-Test bezüglich dieser Schwachstellen durchführen.

#3 Senken von Entwicklungskosten

Würde man ein Haus ohne die Bewertung eines Statikers bauen? Wahrscheinlich eher nicht. Was in der Architektur selbstverständlich ist, gilt leider nicht unbedingt für die Softwareentwicklung. Scheinbar können wir es uns hier leisten, alles ohne einer ersten Evaluation aufzubauen, dann – weil es nicht funktioniert – alles wieder abzureißen, um dann wieder neu aufzubauen.

“Das ziehen wir nach”, “Aktuell leider keine Zeit zum testen” oder: “Das ist so aufwändig, das machen wir später” – All das sind leider Aussagen die wir in der Regel bei der Entwicklung von Produkten hören.

Aber was bedeutet es eigentlich, wenn erst nachdem die Webseite schon fertig programmiert wurde, herauskommt, dass die Nutzer*innen z.B. nicht mit der Navigation klarkommen indem es Beschwerden hagelt oder es über Analysetools ersichtlich wird, dass es viele Abbrüche gibt  bzw die Besucher*innen die Seite verlassen?

Im Klartext bedeutet dies:

1. Es muss zuerst herausgefunden werden, was genau das Problem ist.
2. Dann muss aufgrund dieser Ergebnisse neu konzipiert werden.
3. Anschliessend muss die Neukonzeption neu programmiert werden, was meistens sehr aufwändig und damit sehr teuer werden kann!

Wenn allerdings während des Designprozesses bereits Usability-Tests durchgeführt werden, kann man solche Schwachstellen wahrscheinlich schon vorab, also bevor nur eine Zeile Code geschrieben wurde identifizieren und genauer anschauen. Man könnte schon konzeptionell in die richtige Richtung arbeiten und es würde viel Geld und Zeit in der Entwicklung gespart.

Um es mit den Worten von Joyce Durst in “Cost-Justifying Usability zu sagen (Bias, 2005)

“It costs much less to code the interface in a customer acceptable way the first time than it does to introduce a poor UI in the field and then rework that UI in version two. In addition, a poor UI will increase support costs.” 

#4 Mitarbeiter*innen Zufriedenheit steigern

Eine gute Usability von Enterprise Software kann die Zufriedenheit der Mitarbeitenden des Unternehmens und somit auch die Arbeitseffizienz und Effektiviät steigern, indem es stressmindernd wirkt. Schlecht nutzbare Werkzeuge wie z.B Software, die nicht reibungslos funktionieren sind ein Arbeitshindernis und somit ein potenzieller Auslöser von Stress am Arbeitsplatz. (Frese & Zapf, 1994)

Man stelle sich vor, man müsste bei der Arbeit mit einem Kugelschreiber schreiben, der nur sehr umständlich in der Hand liegt, öfter einfach mal nichts schreibt –  das macht niemand lange mit – da nimmt man sich einfach den nächsten.

Interessanterweise passiert das bei Software am Arbeitsplatz gar nicht so selten, dass die Technik nicht so rund läuft wie man das gern hätte, nur kann man diese nicht mal schnell wie einen Kugelschreiber austauschen. Zudem haben sich die meisten Menschen daran gewöhnt, dass “die Technik mal wieder nicht so will” oder schieben sich selbst die Schuld zu.

Dies kann Stress im Arbeitsalltag verursachen, der sich schädlich auf die Mitarbeitenden  und auf die Organisation auswirken kann. Gestresste Mitarbeiter*innen können häufiger krank werden, arbeiten eventuell mit weniger Freude und sind dadurch dann weniger effizient und effektiv – auch weil sie schlicht mehr Zeit benötigen mit umständlich zu bedienender Software umzugehen, oder immer wieder Dinge nachschlagen oder Kolleg*innen fragen müssen.

Fazit

Wir sehen also eine gute Usability und UX zahlt sich aus und führt zu einer Zeit- und Kostenersparnis und zu Vorteilen für das Unternehmen!

Je nachdem was man herausfinden möchte, bieten sich zwei große Kategorien von Tests an –  nämlich summative Usability-Tests (summiert Ergebnisse) und formative Usability-Tests (formen das Design innerhalb iterativer Designprozesse) und die schauen wir uns in einem anderen Beitrag an.  Bis dahin!

Möchten Sie mehr über Usability-Testing erfahren? Sprechen Sie Sie uns an! Wir freuen uns über Ihre Nachricht.

Quellen

• Bias, R. G. (2005). 22 Chapter – Cost-Justifying Usability: The View from the Other Side of the Table. In R. G. Bias & D. J. Mayhew (Eds.), Cost-Justifying Usability (Second Edition) (pp. 613–621). Morgan Kaufmann. https://doi.org/10.1016/B978-012095811-5/50022-5

• Frese, M., & Zapf, D. (1994). Action as the core of work psychology: A German approach. Handbook of Industrial and Organizational Psychology, 4. https://www.researchgate.net/publication/232492102_Action_as_the_core_of_work_psychology_A_German_approach

Photo 

David Travis on Unsplash

Yes, we know: using surveys for ux research allow the collection of large amounts of data in a relatively short time. This is why there is conventional wisdom that surveys are easy and cheap, which is not entirely true. A good questionnaire design is hard work and often means investing in pre-tests to ask questions that will lead to meaningful answers. However, these beliefs about surveys are the reason why there is a high tendency to use surveys in design research. But this is a fallacy.

Surveys work well when you want to know about the demographic structure of a population or general opinions (a.k.a. trends) on already-known topics. They are an excellent tool if you want to evaluate hypotheses. But if that is not the goal of your UX Research we suggest not using them in UX Research. Here is why:

There is something called the social-desirability bias, which is the tendency to respond in a way that makes people look better than they are. For example, a survey respondent might report that they engage in more healthy or „better“ behaviours than they actually do. Interviews or — even better — user observations or diary studies allow us to navigate the response bias more efficiently, as you observe the interviewees‘ reactions and/or by asking better follow-up questions.

Additionally, surveys are designed to be standardised. This means everybody gets the same questions and — this is the point — the same options to choose an answer from. Standardization is important for surveys so results can be generalized to a larger population due to comparable answers. To achieve this surveys most often use close-ended questions, providing people with a range of possible answers. Some examples:

Are you satisfied with solution A?
A) Yes
B) No

Which colour do you like most?
A) Red
B) Blue
C) Green

These questions make the results quantifiable: „35% said that they like blue, but 75 % prefer green.“

But these types of questions do not tell us why people do not like blue as much as red. Sure we can implement those questions in our survey and have fun mixing qualitative data with quantitative data when evaluating large amounts of accumulated data. However, we cannot individually address the answers of individual people, ask targeted follow-up questions to that specific answer and dig deeper.

Instead of relying mindlessly on quantitative data generated with surveys, we would recommend sitting down and doing 10 in-person interviews, especially if your research includes the exploration of a new topic or domain. Yes, you will receive fewer answers, but you are guaranteed to receive more insights into topics, which will also lead to a deeper understanding of the why.

Open-ended questions in interviews vs closed-ended questions in surveys

In contrast to closed-ended questions used in surveys, open-ended questions in interviews are intended to give the interviewee space to provide us with more detailed answers. For example:

What do you think of XYZ?
Can you tell me a bit more about XYZ (…)?

Using open-ended questions is especially important if you are unfamiliar with a topic, or you need some background information on that topic and want to dig deeper. Additionally, this will allow us to see *how* people react: non-verbal cues are valuable information – especially during the early stages of topic research when we begin building hypotheses. All this provides valuable information we will not get with a survey.

Unleash your inner journalist

When you listen to someone and let them speak using their own words, you will get new insights which will lead to new possibilities and opportunities that you may not have considered by only asking close-ended questions.

You also get insights into their thinking — their mental models and schemas, and the vocabulary they use to describe things. Journalists often start their conversations with people with simple open-ended questions:

Tell me a little bit about yourself!
How often do you use XY?
Why don’t you use XY?
Tell me more about that experience.

Using open-ended questions can also be a good follow-up to closed-ended questions:
Do you like XYZ?
A) Yes
B) No
C) Don’t know

What exactly don’t you like?
Can you describe it a little bit more?
Why do you think this might not work for you?

By asking open-ended questions you allow your interviewee to expand upon why they think this specific layout/thing/whatever might not work. Depending on those expanded answers you can react, i.e. ask further follow-up questions, which often lead to new insight — a vital benefit you would be missing out on by just presenting a survey to a bazillion people and waiting for their response.

In short, quantity is not always better or more truthful than quality. You will also be surprised by all the new insights you get through in-person interviews and/or observations which is especially important when we conduct design research, especially if this research is the basis for design decisions.

Photo

Matthew Brodeur on Unsplash

This doesn’t require that you tell them what you want explicitly and give them obvious cues. Participants only need to guess/hypothesize what you want from them based on some subtle cues you send out which are often based on your implicit opinions. So the assumption your participants make regarding what you might want from them is sufficient enough. For example, a general assumption which occurs during usability testing sessions could be that you want them to like the product you’ll be testing.

It’s important because demand characteristics may put the complete validity of your usability test/interview at risk.

Here’s how to weaken/temper the effect:

1. Make clear at the beginning and throughout your test or interview that you want to hear honest feedback. Try to take the fears of non-desirable answers away.
2. Be aware of subtle cues and nonverbal language your participant sends out. Seems the answer is forced. Is he/she struggling? Take notes during the test, ask afterwards in the debrief interview, and eventually play the scenario through again.
3. In addition to an in-person usability test/interview, provide a post-test questionnaire like for example the SUS (System Usability Scale) which is a quantitative tool to measure the perceived usability
4. Last but not least: Demand characteristics may be one of the reasons the designer, who designed the system is not always the right person to conduct a usability test or do debriefing interviews, because he or she may send subtle positive cues about the system he/she designed and so participants might react more positive than they feel about the task or question you gave them.

For this reason – even though we also claim research should be not outsourced but should be conducted by the interaction design team itself – it may be worth considering another person to conduct the test or interview – in the best case people that are not directly involved in the design or development team. If this is not possible, it’s important to be aware of this bias throughout your test.

Comic image 

http://www.markstivers.com/wordpress/?p=67

Im UX Design bedienen wir uns gerne aus dem Methodenrepertoire, welches sich in den Sozialwissenschaften bewährt hat. Daher dachte ich mir, das wir mal ein paar Einblicke in einige Methoden geben. 🙂

Los gehts im ersten Teil mit einer bekannten und beliebten Methode – dem qualitativen User Interview – und der grundlegenden Frage: Wann macht ein solches überhaupt Sinn?

Vorab: Die Rolle von narrativen Interviews im Designprozess

Interviews können eine große Rolle beim Design von (digitalen) Produkten spielen – einmal a) im Bereich des User Interviews um z.B. Einstellungen oder Motivationen zu einem gewissen Thema „herauszukitzeln“ bzw. um auch bei komplexen, fremden Thematiken „Experteneinblicke“ zu bekommen oder b) im Bereich der Stakeholder Interviews, um herauszufinden, welche Ziele aus Produkt/ Businesssicht verfolgt werden – quasi: den Kern der Ziele heraus zu finden und zu überprüfen, ob es hier gravierende Meinungsunterschiede / Diskrepanzen gibt, also: in welche Richtung es geht.
Ich schreibe hier der Einfachheit halber ausgehend vom Fall a ) – den User Interviews.

Ist doch easy!?

„Machen wir doch einfach schnell ein paar Interviews, dann wissen wir bescheid…“

Das Interview ist eine sehr beliebte Methode zur Gewinnung von Daten. Mit Interview meine ich hier eine zumeist qualitative Datenerhebungsmethode – also eine narrative, d.h offen gehaltene, “erzählerische” mündliche Befragung mit einer oder mehreren Personen. Qualitativ, da ich hier wie gesagt eine eher offen gehaltene Befragung meine. Es gibt auch voll standardisierte Interviewmethoden, die zu den quantitativen Datenerhebungsmethoden zählen und keinen/einen weniger narrativen – also qualitativen Charakter haben. Bei solchen wird die Befragung anhand eines strikt abzuarbeitenden durchstandardisierten Fragebogens durchgeführt und ist nicht flexibel/erzählerisch gehalten, aber diese werden hier erst einmal nicht behandelt.

Das Interview ist so beliebt, weil es scheinbar so einfach durchzuführen ist. Ist doch easy – Fragen stellen, das kann doch wohl jeder, denkt man. Leider ist es aber nicht so. Eine Menge Dinge müssen beachtet werden, wenn man aussagekräftige Erkenntnisse erhalten möchte, die im Prozess weiterführen.

Fig 01 First rule of qualitative research

Wenn du schon einmal ein Interview geführt hat, wirst du schon gemerkt haben, wie komplex das sein kann. Ein Interview zu führen ist zudem ziemlich zeitaufwändig – und somit natürlich kostspielig. Man denke an:

• die Personenrekrutierung
• die Vorbereitung (entscheiden, welche Art von Interview, Fragen vorbereiten)
• die eigentlichen Durchführung
• die Auswertung (zB Transkription)
• plus der anschliessende Analyse

Auf der anderen Seite bekommst du mit Interviews Einblicke warum Menschen eine bestimmte Verhaltensweise an den Tag legen, die dir mit rein quantitativen Tests oft verwehrt bleiben. Es gibt dir also die Möglichkeit, neue Ideen und Vermutungen zu generieren, warum etwas so sein könnte (Hypothesengenerierung), welche du anschliessend genauer unter die Lupe nehmen und überprüfen kannst (Hypothesenprüfung). Darauf kommen wir gleich nochmal genauer zurück.
Das heisst, du solltest zuerst einmal ganz klar abwägen, ob ein Interview dich bei deiner Fragestellung überhaupt weiterbringt oder ob vielleicht eine andere Methode besser geeignet ist, die gewünschten Fragestellungen zu beantworten.

In diesen Fällen kann dir ein Interview weiterhelfen

1) Exploration eines völlig neuen Themengebietes: Wenn dir noch gar keine Information über das Themengebiet vorliegt, du also ganz am Anfang steht und planlos in einem Thema „herumstochert”. Du beabsichtigst, erste Einsichten über ein Thema zu gewinnen und das Gebiet worum es geht, erst einmal grob zu erkunden. Das Interview beantwortet dir im besten Fall dann diese Fragen: Was, wie, warum?

2) Wenn das “Wie” da ist, aber das “Warum” fehlt: Wenn dir zwar bereits Informationen vorliegen, es aber noch Wissenslücken bei bestimmten Prozessen gibt. Zum Beispiel wurden vielleicht schon Tests durchgeführt: man stellte eventuell in einem Usability Test oder durch andere Beobachtungen (User Observation, Google Analytics oder Fragebögen) ein bestimmtes Verhaltensmuster fest (wie/auf welche Weise verhalten sich Menschen), aber nun tappt man im Dunkeln, warum dieses Verhaltensmuster existiert. Durch ein Interview kannst du versuchen, diesem “warum” auf die Spur zu kommen.

3) Als nützliche Vorbereitung für einen Test: Interviews kannst du natürlich auch nutzen, um Stoff für quantitative, hypothesenprüfende Tests (aka die “hard facts”, wie zB Fragebögen, Usability Tests, A/B Tests) zu sammeln.
Bei den meisten Fragebögen z.B. sind die Antworten bereits von den Forschern vorgegeben. Man nennt dies ein “geschlossenes Antwortsystem”, was natürlich ein Einwand gegen solche Erhebungsmaßnahmen sein kann. Oder: wir als UX Experten geben das Wording und den Text bei Produkten, Softwareprogrammen oder auf Webseiten vor, und wundern uns, warum es nicht verstanden wird.

Der Knackpunkt ist in beiden Fällen der gleiche: Du weisst nicht, ob diese sprachlichen Kategorien, die den Gehirnen der Forscher/UX Experten entsprungen sind, auch den mentalen Konzepten/Schemata denen der Probanden/Testpersonen/Nutzergruppen entsprechen. Diese denken ja eventuell in ganz anderen „Kategorien“.
Daher ist eine ganz gute Methode, im Vorfeld – also bevor ein Test (oder Fragebogen) entwickelt wird – Interviews mit der angepeilten Testgruppe zu führen – und zwar genau über die Thematik des geplanten Tests. Somit bekommst du Einsicht in die Denkweise, also auch in die Formulierungen, die von den Testkandidaten benutzt werden. Den gleichen Effekt sieht man oft zB bei Firmenwebseiten, die zwar ihre Kompetenzen/Services in ihrer eigenen “internen Sprache” abbilden, die intern selbstverständlich ist, aber als Laie oder Neuling auf dem Gebiet versteht man kein Wort.

Hier kannst du ein Interview gut nutzen, um z.B. Beschriftungen von Navigationspunkten nutzergruppengerecht zu gestalten: d.h., das Verwenden einer Schreibweise und eine Wortwahl, die dem Denken der Nutzer entspricht.
Dies macht Sinn bei z.B. berufsgruppenspezifischen Fragen (Experten vs Laien), oder bei verschiedenen Altersgruppen (Kinder, Erwachsene, ältere Menschen) etc.. Die Frage, die dir hier beantwortet wird, lautet also: „Wie“ / In welchen Kategorien denken verschiedene Personengruppen, um einen Sachverhalt oder eine Thematik zu beschreiben?
Das ist im Endeffekt der gleiche Ansatz, der beim offenen Card Sorting angewendet wird.

Der Forschungskreislauf

Du siehst also, Interviews haben (meist) einen qualitativen Charakter und eignen sich eher zur zur Hypothesengenerierung statt zur Hypothesenüberprüfung. Diese neuen Vermutungen, die du aufgrund von Interviews aufstellst, können dann in weiteren Tests genauer überprüft werden, um zu schauen, ob diese neue Hypothese/Vermutung zutrifft.
Das funktioniert wie in einem Kreislauf: qualitative Erkundung – quantitative Testung – qualitative Erkundung – quantitative Testung etc.. 🙂

Fig 02 – The scientific method. Einmal unten angekommen, kann man wieder von vorne beginnen

Da Interviews so zeitaufwändig sind, wirst du in der Regel auch nur eine begrenzte Anzahl von Personen befragen. Angenommen du befragst 5-10 ausgewählte Personen. Von dieser geringen Anzahl an Antworten kannst du natürlich nicht auf die Allgemeinheit schliessen – d.h man kann diese neuen Erkenntnisse z.B nicht auf eine gewisse Nutzergruppe beziehen. Never ever.

Man spricht auch von einer geringen „externen Validität“* – d.h die gewonnen Daten sind nicht generalisierbar.
Da Interviews aber – wie bereits erwähnt – generell eher einen „erkundenden“ /hypothesengenerierenden Charakter haben, also erst einmal dazu dienen, in einen Bereich „reinzuschnuppern“ ist diese nicht vorhandenene Generalisierbarkeit nicht ganz so wichtig, da man die Hypothesenüberprüfung erst in weiteren Untersuchungen/Tests anordnet. Man prüft also dann später: Ist dies wirklich so, oder kamen die Vermutungen/Erkenntnisse aus dem Interview nur zufällig zustande?

Grundsätzlich kann man als Faustregel sagen: Überleg dir gut, ob dich ein Interview bei deiner Fragestellung wirklich weiterbringt. Ein qualitatives Interview ist immer dann sinnvoll, wenn du erst einmal grob „vorsortieren“ möchtest. Wenn du dir also ein Bild über z.B. Einstellungen und/oder Motivation zu einem bestimmten Thema machen willst. Später im Prozess kann man diese Vermutung dann in Tests überprüfen.

Das klingt jetzt alles nach sehr viel Aufwand, und wie wir alle aus vielen Projekten wissen, ist die Zeit leider selten gegeben. Natürlich kannst du das Ganze auch “lofi” und “quick and dirty”, betreiben. Gerade bei der Frage nach oben angesprochenen den mentalen Konzepten (Sprache, Wording) bekommst du doch recht schnell interessante Einblicke, die den eigenen Horizont erweitern können.

Du solltest nur im Hinterkopf behalten, das so eine “quick & dirty” Erhebung sehr wahrscheinlich ein verzerrtes Abbild der Realität liefert, und dies solltest du zumindest auch irgendwie dokumentieren/festhalten bzw kommunizieren. Zur Gewohnheit sollte dies nicht werden. 🙂

Das nächste Mal nehmen wir dann die verschiedenen Arten von Interviews unter die Lupe.

Key Takeaways – Wann ein User Interview in Frage kommt:

• Reflektieren: Ist das Interview in meinem Fall eine sinnvolle Methode? Was möchte ich erreichen, welche Frage versuche ich zu beantworten?
• Immer vor Augen halten: Ein Interview dient eher zur Gewinnung neuer Einsichten/ Vermutungen und nicht der Prüfung von Vermutungen (Hypothesengenerierung statt Hypothesenüberprüfung)
• Zeitaufwand beachten (Rekrutierung, Vorbereitung, Durchführung, Auswertung)
• Im Hinterkopf behalten: Erhobene Daten sind wegen kleiner Personenanzahl, die zudem noch willkürlich ausgesucht ist, auf keinen Fall auf die Allgemeinheit übertragbar

* Validität (Gültigkeit) ist ein Gütekriterium im sozialwissenschaftlichen Forschungsprozess

Photo credit: https://www.flickr.com/photos/cloneofsnake/14150603002/