Headerbild Empathy Maps

Empathy Maps als UX-Tool

28. Apr. 2022

In 30 Minuten ein einheitliches Mindset im Team schaffen

In Entwicklungs-, Design- oder Marketing-Teams bestehen oftmals unterschiedliche Vorstellungen von Zielgruppen, bzw. dem Endnutzer einer Applikation. Dies kann dann problematisch werden, wenn bspw. neue Features geplant oder versucht wird, den Endnutzer in Texten sowie Bildern direkt anzusprechen. Vor allem aber führt dies oftmals zu langwierigen Prozessen sowie Entscheidungen über die Nutzer und deren Bedürfnisse. Um dieser Herausforderung entgegenzuwirken, lassen sich unterschiedliche Ansätze sowie Methoden nutzen. Eine besonders effiziente und in der Umsetzung einfache Methode ist die „Empathy Map“.

Empathy Maps sind ein agiles Tool im Bereich des User Experience Designs, das dabei hilft, die Nutzer sowie deren Bedürfnisse besser zu verstehen und ein einheitliches Mindset im Projekt-Team zu etablieren. Die Nielsen Norman Group, eine Erfolgreiche UX Beratungsfirma aus Amerika, welche von den User Experience Pionieren, Don Norman und Jakob Nielsen gegründet wurde, definiert Empathy Maps wie folgt:

„Eine Empathy Map ist eine kollaborative Visualisierung, die verwendet wird, um zu artikulieren, was wir über einen bestimmten Benutzertyp wissen. Sie externalisiert Wissen über Benutzer um, 1.) ein gemeinsames Verständnis der Benutzerbedürfnisse zu schaffen und 2.) bei der Entscheidungsfindung zu helfen.“

[Gibbons, 2014]

Smartphone Morty-App

Wie aber kann eine solche Empathy Map nun erstellt werden? Welche Vorteile bietet die agile Arbeitsmethode, welche Vorbereitungen müssen für eine erfolgreiche Empathy Map vorab getroffen werden und was ist schließlich das Ergebnis einer solchen Map?

All‘ das und noch mehr soll in diesem Blogartikel anhand der Spiele-App „Morty – Das Motivationshörnchen“ – einer App, die Nutzer mit dem Tamagotchi-Spieleprinzip dazu motiviert Ihre persönlichen Ziele zu erreichen – erläutert werden.

Grafik Empathy Map

Das Format einer Empathy Map

Die Empathy Map wird zunächst immer in zwei Bereiche unterteilt. Im ersten Schritt geht es darum den Nutzer allgemein oder im Kontext einer bestimmten Situation zu beschreiben. Die Beschreibung erfolgt durch das Beantworten der folgenden vier Fragen:

1. Was sieht die Person? (See)

Hierbei kann zum einen die Umgebung, welche die Person sieht, beschrieben werden. Also wie bspw. der Arbeitsplatz aussieht oder in welchem Umfeld sich die Person befindet. Zum anderen können hier aber auch Informationen oder Ressourcen, welche die Person wahrnimmt, gesammelt werden.

2. Was hört die Person? (Hear)

Auch hier handelt es sich sowohl um die akustische Umgebung der Person, z.B. am Arbeitsplatz als auch um die Informationen aus Gesprächen, mit denen die Person konfrontiert wird.

3. Was sagt oder macht die Person? (Say and Do)

In diesem Bereich werden alle Handlungen einer Person beschrieben. Hier können auch Handlungen zu einem bestimmten Produkt aufgeführt und typische Aussagen der Person gesammelt werden.

4. Was denkt oder fühlt die Person? (Think and feel)

Dieser Aspekt ist oftmals schwierig zu beantworten, da die Informationen aus der Recherche nur bedingt verwendet werden können. Dennoch sollte sich bei dieser Frage in den Endnutzer hineinversetz und bspw. auf Basis der Bereiche „See“ oder „Hear“ mögliche Gefühle oder Gedanken abgeleitet werden.

Bei der Bearbeitung einer Empathy Map empfiehlt es sich zu Beginn mit den Bereichen „See“ und „Hear“ zu beginnen, da aus diesen oftmals auch viele wichtige Informationen für die Bereiche „Say and do“ sowie „Think and feel“ abgeleitet werden können.

Im zweiten Schritt der Empathy Map geht es um Probleme und Hindernisse (auch „Pains“ genannt) sowie die Ziele und Motivationen der Person (auch „Gains“ genannt). Es empfiehlt sich diesen Bereich erst dann zu bearbeiten, wenn die ersten vier Fragen bereits absolviert wurden.

Die Pains bzw. Gains sind zwei wertvolle Bereiche innerhalb der Empathy Map. Die Pains helfen dabei zu verstehen, warum ein Nutzer eine Applikation nicht verwenden könnte oder aber nicht mehr verwenden möchte. Die Gains wiederum geben uns Hinweise darauf, welche Ziele der Nutzer mit der Verwendung der Applikation verfolgt. Darüber hinaus helfen die Gains dabei herauszufinden, was den Nutzer motivieren könnte das Produkt oder die Applikation auch weiterhin zu benutzen.

Wann und wofür sich Empathy Maps eignen

Empathy Maps eignen sich zu jedem Zeitpunkt im Design Prozess. Im nutzerzentrierten Gestaltungsprozess ist der ideale Zeitpunkt am Anfang des Design Prozesses, da die Empathy Maps den gesamten Prozess unterstützen, indem ein einheitliches Bild des Endnutzers im Team geschaffen wird. Auch eignen sie sich bei einer fortgeschrittenen Iteration eines Produktes, vor allem dann, wenn deutlich wird das unterschiedliche Vorstellungen über den Endnutzer im Team vorhanden sind oder keine Personas für den Design Prozess definiert wurden.

Zudem eignen sich Empathy Maps sowohl für Applikationen oder Services als auch für physische Produkte. Denn auch in der Gestaltung eines physischen Produktes kann es maßgeblich für den Erfolg und die Effizienz des Teams sein, wenn ein einheitliches Persona vorhanden ist, sowie die „Pains“ bzw. „Gains“ der Konsumenten bekannt sind.

Durchführung eines Empathy Map Workshops

Die Empathy Map wird mit mehreren Mitgliedern eines Teams im Rahmen eines speziellen Workshops erarbeitet. In der Regel dauert ein Empathy Map Workshop für einen beispielhaften Nutzer, eine sogenannte Persona, nicht länger als 30 Minuten – dadurch ist der Workshop innerhalb einer agilen Arbeitsweise ideal einsetzbar.

Bevor ein Empathy Map Workshop gestartet werden kann, muss dieser jedoch erstmal geplant werden. In diesem Zusammenhang sollten vorab folgende Fragen geklärt sein:

  • Welche Persona soll ausgearbeitet werden?

Dabei sollte auch geklärt werden, ob mehrere Personas erstellt werden sollen. Eine Empathy Map bildet normalerweise nur eine Persona ab.

  • Was ist das Ziel der Empathy Map?

Welches konkrete Problem soll mithilfe der Empathy Map gelöst werden? Soll ein tieferes Verständnis vom Endnutzer aufgebaut werden? Oder soll das Bild der Personas des Teams geeicht werden?

Im Projekt Morty – Das Motivationshörnchen war es unser Ziel, einen einheitlichen Überblick über potentielle Nutzer von Morty sowie aktive Nutzer von Morty zu bekommen. Aus diesem Grund haben wir in der Planung bereits beschlossen, dass wir zwei Empathy Maps erstellen und dabei das gesamte Entwicklungsteam in den Prozess einbinden möchten.

Anschließend folgte die Recherche für den Empathy Map Workshop. Innerhalb der Recherche werden alle Daten, die dem Team über die Endnutzer zur Verfügung stehen, gesammelt und aufbereitet. Dies können z.B. Informationen vom Kundensupport sein, wenn es sich um eine bestehende Applikation handelt, oder Daten, die innerhalb von Usability-Tests erhoben wurden. Wenn beides nicht vorhanden sein sollte, besteht auch die Möglichkeit Daten von Meinungsforschungsportalen zu beziehen.

Bei der Spiele-App haben wir die Daten aus einer vorab durchgeführten Umfrage sowie einem Usability-Test zusammengestellt und diese nochmal visuell für den Empathy Map Workshop aufbereitet.

Nach der Datenaufbereitung kann der Workshop mit folgenden Teilschritten durchgeführt werden:

1. Präsentation der Recherche (ca. 5 Minuten)

Als erstes werden die Ergebnisse der Recherche zu den Nutzern oder Personas vorgestellt. Falls nicht alle Workshop-Teilnehmer wissen, was eine Empathy Map ist, sollte den Teilnehmern der Prozess sowie die Fragen einer Empathy Map an dieser Stelle ebenfalls erklärt werden.

2. Verteilen des Materials (ca. 2 Minuten)

Wenn der Workshop vor Ort stattfindet, können Haftnotizen und verschiedene Marker für das Workshop-Team hilfreich sein. Wenn der Workshop virtuell stattfindet, sollte den Teilnehmern die Nutzung der jeweiligen Online-Tools erläutert werden. Gute Tools für einen Online-Workshop sind bspw. Miro oder Mural.

3. Einzelne Bearbeitung der Empathy Maps (ca. 8 – 10 Minuten)

In dieser Phase sollen sich die Teilnehmer zunächst ungestört den Fragen der Empathy Map widmen. Der Moderator des Workshops sollte dabei nochmal auf die Reihenfolge zur Bearbeitung der Themen hinweien, um so ein möglichst strukturiertes Arbeiten zu ermöglichen: „See“ > „Hear“ > „Say and Do“ > „Think and Feel“ > „Pains“ > „Gains“.

4. Zusammentragen der Ergebnisse (ca. 10 - 15 Minuten)

In dieser Phase trägt das Team die Ergebnisse auf einer gemeinsamen Empathy Map zusammen. Bei einem vor Ort Workshop lässt sich dies am besten über eine Flipchart mit dem Empathy Template visualisieren. In einem virtuellen Workshop können die Notizen und Informationen auf einem gemeinsamen Template zusammentragen sowie diskutiert werden.

__

Für das Projekt Morty – Das Motivationshörnchen wurde ein virtueller Empathy Map Workshop mit dem Tool Miro durchgeführt. Zunächst wurde das Template einer Empathy Map erläutert, danach folgte das Zusammentragen der Ideen. Im Anschluss hat jeder Workshop-Teilnehmer zwei Editionen der Empathy Map bearbeitet: 1. für potenzielle Nutzer von Morty und 2. für aktive Nutzer von Morty. Nach 20 Minuten wurden die Ergebnisse auf zwei gemeinsamen Empathy Maps übertragen und diskutiert. Dabei haben die Teilnehmer des Workshops nacheinander ihre Notizen auf die gemeinsamen Empathy Maps gelegt und diese kurz erläutert. Diesen Schritt haben wir in zwei Phasen unterteilt, sodass zunächst der erste Schritt mit den vier Fragen und dann der zweite Schritt mit den „Pains“ bzw. „Gains“ besprochen wurde.

Beim Zusammentragen der Ergebnisse wurde schnell deutlich, dass das Projektteam insgesamt eine ähnliche Vorstellung der Personas hatte. Desweiteren konnten neue Hypothesen über die Nutzer aufgestellt werden, die in zukünftigen Usability-Tests validiert werden müssen. Auch konnte durch den Workshop festgestellt werden, in welchen Bereichen weitere Informationen über die Nutzer notwendig sind.

Nach insgesamt 1 Stunde Workshop hat sich folgendes Ergebnis in unserem Miro-Board abgebildet:

Da der Empathy MapWorkshop in der Regel von einem Entwicklungsteam durchgeführt wurde, wurde die Empathy Map visuell aufbereitet und auch anderen Teams des Projektes zwecks Feedbacks zur Verfügung gestellt. Die finalisierten Empathy Maps wurden dann dem gesamten Projektteam vorgestellt.

Damit die Empathy Maps auch in zukünftigen Sprints wiederverwendet werden können, ist es notwendig die Informationen stets durch User Research oder aus Ergebnissen von Usability-Tests zu erweitern sowie festigen. Beim Voranschreiten der Entwicklung ist es ebenfalls sinnvoll den Empathy Map Workshop zu wiederholen, um entweder das Bild des Nutzers zu verfeinern oder aber eine sich stark veränderte Persona neu zu definieren.

Die Quick-wins nach einem erfolgreichen Empaty Map-Workshop

Nach erfolgreicher Umsetzung lässt sich zusammenfassen, dass Empathy Maps ein schnelles und machtvolles Tool sind, um einem Projektteam zu einem einheitlichen Mindset der Personas zu verhelfen und die Befangenheit im Team reduzieren.

Des Weiteren unterstützen die Ergebnisse einer Empathy Map die künftige Planung und Priorisierung von Features und sorgen bei anschließenden Design Prozessen für mehr Effizienz. Dabei lieferte uns die Empathy Map nicht nur Hypothesen für weitere Usability-Tests, sondern offenbarte auch Lücken innerhalb der aktuell vorliegenden Informationen zu den Nutzern.

Empathy Maps sind darüber hinaus auch ein ideales Werkzeug für andere Workshops aus dem nutzerzentrierten Gestaltungsprozess wie etwa „Design Sprints“ oder „Design Thinking“. So lässt sich bspw. bereits am ersten Tag eines Design Sprints herausfinden auf welches Persona im Verlauf der Woche der Fokus gesetzt werden soll.

Empathy Maps sind eine effiziente Methode das eigene Projekt zum Erfolg zu führen – und das alles in nur 30 Minuten.

Marcel Tuchner

Unser UI- & UX-Experte

Marcel Tuchner

ist für Sie da!

+49 441 559 770 0

Marcel Tuchner
Haben Sie Fragen?

Weitere Blogartikel

08. Jan. 2024

Persönlich nachgefragt bei Adrian Macha und Torben Schinke von worldiety

Blog

Wie schauen Adrian Macha und Torben Schinke heute auf das Projekt „worldiety Zentrum Oldenburg“? mehr

10. Jan. 2023

Generator für Softwarearchitekturen

Blog

Bei der Entwicklung von Software treten bei fortlaufender Dauer, entsprechender Größe, Komplexität und bei häufig auftretenden Änderungen Herausforderungen hinsichtlich der Architektur des zu entwickelnden Softwaresystems auf. Diese bestehen zumeist darin, den immer größer werdenden Quellcode und die zunehmende Anzahl von Softwarekomponenten passend zu organisieren. Die Architektur des Softwaresystems ist dabei maßgeblich für die Wartung und Anpassungsfähigkeit der Software als auch für die Einarbeitungszeit neuer Entwickler. mehr

01. Mai. 2022

Benutzerdokumentation automatisiert generieren

Blog

Die agile Softwareentwicklung hat sich in den letzten Jahren zu einem wichtigen Ansatz der technischen Umsetzbarkeit entfaltet. Neben den Vorteilen, wie z. B. Flexibilität, Fehlererkennung und erhöhte Performanz durch eine stetige Kommunikation, bringt eine agile Softwareentwicklung jedoch auch Einschränkungen mit sich. So wird die Dokumentation - zu welcher auch die Benutzerdokumentation zählt - eher relativiert betrachtet und zugunsten der engen Zusammenarbeit zwischen Entwickler:innen, Tester:innen, Kund:innen und Nutzer:innen auf ein Minimum beschränkt. Bedingt durch Covid-19 musste der persönliche Kontakt mit Kunden, welcher in einer agilen Entwicklungsumgebung einen hohen Stellenwert besitzt, auf ein Minimum reduziert werden. Dabei gewann Software allgemein in den letzten Jahren immer mehr an Komplexität, welches auch eine zunehmende Rolle in der Organisation von Informationen innerhalb der Benutzerdokumentation zur Folge hat. mehr

15. Apr. 2022

Flexibel einsetzbare Markupsprache

Blog

Die Idee, dass Daten wertvoll sind und das strukturierte Speichern dieser sinnvoll ist, wurde schon in den 60er Jahren im Konzept des Generic Coding erkannt. Diese Versuche, eine vereinheitlichte Sprache zur Beschreibung von Daten zu entwickeln, mündeten 1986 in die Entstehung der Standard Generalized Markup Language (SGML), welche sich durch die Verwendung von sogenannten Tags auszeichnet. Die Ähnlichkeit zu modernen Markup-Sprachen wie HTML oder XML ist kein Zufall, da diese SGML-konform entstanden sind, sich aber mittlerweile davon gelöst haben, um ihre Struktur weniger eingeschränkt anpassen zu können. mehr