Viele Probleme im Projektalltag entstehen aus mangelnder Kommunikation, verschiedenen Sichtweisen und unterschiedlichen Zielen. Daher ist es zu Beginn eines Projektes wichtig, ein gemeinsames Verständnis der verschiedenen Projektbeteiligten und Stakeholder für die zu entwickelnde Lösung zu schaffen und dieses während des Projektes immer wieder abzugleichen. Wir müssen zunächst verstehen, welches Problem wir überhaupt lösen wollen. User-Experience Design bewegt sich grundsätzlich in zwei Bereichen, dem Problemraum und dem Lösungsraum. Es ist wichtig, diese beiden Bereich zu trennen.
Dem eigentlichen Problem auf den Grund zu gehen, ist gar nicht so einfach, denn wir tendieren dazu, immer wieder bereits über Lösungen zu sprechen, wenn das Problem noch gar nicht klar ist.
Meine Lieblingsmethode aus dem Buch Collaborative UX Design von Toni Steimle, die sich übrigens auf viele andere Bereiche anwenden lässt, ist das Problem Statement. Das Problem Statement ist eine sehr nützliche Methode, wenn man alle Projektbeteiligten zu Beginn eines Projektes auf die Ausgangslage fokussieren möchte. Ein gemeinsames Verständnis des zu lösenden Problems im Projekt ist unerlässlich für einen erfolgreichen Projektstart.
Vorgehen
Idealerweise werden Stakeholder aus verschiedenen Bereichen eingeladen, um eine möglichst breite Sicht auf das Problem zu erhalten: Es sollte sowohl die Businesssicht, die technische Seite als auch die Nutzersicht vertreten sein. Alle Teilnehmenden erhalten einen Stapel Postits und einen Stift. Die Kategorien werden als vertikale Achse an einer grossen Wand vorbereitet.
Zu Beginn werden die Kategorien vorgestellt und die Teilnehmenden bekommen genügend Zeit ihre Inputs auf Postits zu notieren. Danach wird geklebt, am besten in wechselnder Reihenfolge.
Kategorien
Nutzer
Zunächst müssen wir uns fragen, wer die Nutzer der Lösung sein werden. Sind es auch gleichzeitig die Kunden oder trifft jemand anders die Kaufentscheidung? Oft können wir mehrere Benutzergruppen identifizieren. Interessant ist auch, wie gross die Nutzergruppen sind. Und handelt es sich um eine kleine homogene Gruppe, wie z.B. für eine Fachanwendung oder ist es eine grosse und diverse Masse, z.B. eine Webanwendung für die breite Öffentlichkeit?
Problem
Nun folgt die oft schwierigste Frage – welches Problem soll die zu entwerfende Lösung für unsere Nutzer lösen? Dabei ist es besonders wichtig darauf zu achten, nicht über Lösungen zu sprechen, sondern immer wieder auf das Problem zu fokussieren. Und oft wird über Probleme gesprochen, die die Auftraggeberin lösen möchte, das sind nicht immer auch die Probleme der Nutzer. Wenn zum Beispiel ein Zeiterfassungstool optimiert werden soll, weil die Mitarbeiter ihre Arbeitszeit nicht zeitnah oder unvollständig erfassen, ist dies nicht das Problem der Nutzer. Der Auslöser können verschiedene Probleme der Nutzer sein, zum Beispiel Zeitmangel oder ein unverständliches Interface. Möglicher Weise gibt es bereits Hinweise auf die Probleme der Nutzer, beispielsweise aus Supportanfragen. In der Regel kommt man den wahren Problemen der Nutzer erst durch Nutzerforschung auf den Grund.
Lösungsansätze
Oft gibt es bereits Ideen für Lösungsansätze, die berücksichtigt werden sollten. Vielleicht gibt es auch konkurrierende Produkte, die bereits Lösungsansätze enthalten.
Metriken
Um die Qualität der Lösung zu messen, brauchen wir Metriken und passende Messmethoden. Die Effizienz einer Anwendung kann zum Beispiel über die task completion time (TCT) gemessen werden, die durchschnittliche Zeit, die Nutzerinnen benötigen, um eine Aufgabe vollständig durchzuführen. Metriken sind auch wichtig, um den Erfolg einer Lösung zu messen und zu belegen. Wenn zum Beispiel ein nutzerfreundliches Interface die benötigte Zeit zur täglichen Erfassung von Arbeitszeit verkürzt, können in einem Unternehmen mit vielen Mitarbeitern hohe Kosten durch Einsparung von nicht verrechenbarer Arbeitszeit reduziert werden.
Stakeholder
Nicht nur die Nutzer und Kundinnen sind von der Lösung betroffen. Auch weitere Personengruppen wie Support, Verkauf oder die IT-Abteilung.
Rahmenbedingungen
Rahmenbedingungen können erfolgskritisch sein und müssen berücksichtigt werden. Oft sind das technische Voraussetzungen, wie bestehende Datenbankstrukturen, Schnittstellen zu Umsystemen, aber auch Endgeräte wie z.B. die Bedienung via Touchscreen oder viele Sprachversionen.
Weiteres Vorgehen
Die einzelnen Antworten auf die Fragen sind in der Regel Annahmen – bei einigen verfügen wir über mehr gesichertes Wissen, bei einigen weniger. Sie bilden die Grundlage für die Forschungsplanung, denn nun wissen nicht nur alle, welches Problem wir lösen wollen, sondern auch, wo wir noch Wissenslücken haben. Unsichere Annahmen werden nun markiert. Der nächste Schritt ist die Priorisierung der gesammelten Annahmen (zum Beispiel auf einer Annahmen-Map) nach Grad des Wissenstandes und der Grad der Auswirkung auf den Erfolg des Produktes oder des Projektes. Diese Priorisierung bildet die Grundlage für die Nutzerforschung: Nun wissen wir, welche Annahmen überprüft werden müssen.
Tipps und Erfahrungswerte
- Der Workshop benötigt ca. 1-2h Zeit, je nach Anzahl der Teilnehmenden.
- Wie bei jedem Workshop sollte man einen Zeitplan erstellen und diesen auch einhalten. Ein Timer hilft dabei, auch um Redezeiten von Vielrednern einzuschränken… 😉
- Die Teilnehmenden sammeln ihre Postits auf sogenannten Omnibussen. Das sind A4-Blätter angeschrieben mit der jeweiligen Kategorie auf denen die Teilnehmenden ihre jeweiligen Postits sortieren und transportieren können.
- Für Themen, die während des Workshops auftauchen, zum Beispiel Probleme des Auftraggeberin, die nicht unter den Problemen der Nutzer erfasst werden sollen, kann man einen «Parkplatz» einrichten, ein Platz für diese Postits ausserhalb des Problemstatements. So bekommen diese Themen Raum, stören aber nicht den Fokus des Workshops.
- Am Schluss und während das Workshops unbedingt Fotos machen, vor allem von den Ergebnissen. Sie sind ein ebenso wertvolles Ergebnis wie ein mehrseitiger Bericht.
- In einer idealen und pandemiefreien Welt verfügt das Team über einen Projektraum, wo das Statement während des Projektes hängen bleiben kann, so dass der Fokus darauf, was welches Problem wir für wen lösen, immer präsent bleibt.
- Alternativ kann man das Problemstatement auf einem digitalen Whiteboard erarbeiten, damit es später weiter bearbeitet werden kann. Man kann die Postits von physischen Workshop auch im Nachgang digitalisieren, Miro zum Beispiel bietet eine Postit-Erkennung.
- Das Problemstatement ist ein lebendes Artefakt, es sollte während des Projektes in den einzelnen Iterationen immer wieder überprüft werden. Es können sich zum Beispiel technische Einschränkungen während des Projektes ändern oder neue Risiken erkannt werden.
Wie geht ihr vor, um ein gemeinsames Verständnis unter den Projektbeteiligten zu erreichen?