Scoping

Proto-Problem Statement

In einem Proto-Problem Statement identifiziert ein Team zu Beginn eines Projektes, welche Probleme zu überwinden sind, welche Akteure von den Problemen und ihren Lösungen betroffen und welche Randbedingungen zu berücksichtigen sind. Das Proto-Problem Statement steckt den Projektrahmen ab.

Format:
Workshop
Teilnehmer:
UX Mitarbeiter, Projektleitung, Product Owner
Dauer:
1-4 Stunden

Arbeitsmodus

Workshop

Voraussetzung

Es gibt ein Projektvorhaben.

Teilnehmende

Erweitertes Team mit Auftraggeber, Product Owner, Fachspezialist,  UX Designer und vereinzelten Entwickler:innen

Dauer

0.5 - 1 Tag

Am Anfang des Projektes ist es dem Team noch unklar, was genau der Inhalt des Projektes ist. Es braucht ein Grundverständnis über die Ziele und die Randbedingung des Projektes. Ein Hilfsmittel, den Projektumfang genauer abzustecken, bietet die gemeinsame Formulierung eines Proto-Problem Statements. Es hilft, die Lücke zwischen einem IST-Zustand und einem SOLL-Zustand zu definieren, indem es die zu überwindenden Probleme des IST-Zustandes beschreibt. Durch die Definition der Probleme, die durch das Vorhaben adressiert werden sollen, wird implizit auch der Projektumfang festgelegt.

Das Proto-Problem Statement wird ganz zu Beginn des Projektes erarbeitet. Dann stellen die Inhalte noch Annahmen dar (daher auch das "Proto" in der Bezeichnung). Im Verlauf der Verstehens-Phase wird das Bild des Proto-Problem Statements zunehmend geschärft und gegebenenfalls auch revidiert. So kann die Nutzerforschung beispielsweise aufzeigen, dass andere Probleme wichtiger sind, oder aber die Annahmen werden bestätigt. Als Ergebnis resultiert ein überarbeitetes Problem Statement.

Ein Projekt wird aus ganz unterschiedlichen Gründen lanciert. Wir stellen hier gleich drei Beispiele vor, die im weiteren Verlauf immer wieder aufgegriffen werden.

Im ersten Beispiel geht es um einen Hersteller von Kaffeemaschinen und sein Modell für größere Büros mit vielen Mitarbeitern. Die Kaffeemaschine soll über das Mobilfunknetz direkt mit einem Service-Anbieter kommunizieren. Mit zusätzlichen Sensoren können Probleme früher erkannt, dem Service-Anbieter mitgeteilt und Ausfälle der Kaffeemaschine verhindert werden. Im Proto-Problem Statement soll auch die Frage gestellt werden, welche weiteren Probleme für die Nutzenden im Zuge dieses Projekts behoben werden sollen. So soll beispielsweise die Wartungsfunktion für die Nutzenden vereinfacht werden.

Im zweiten Beispiel geht es um ein sehr großes Beratungsunternehmen. Die Berater erfassen ihre Arbeitszeiten so, dass die Leistungen am Monatsende den Kunden in Rechnung gestellt werden können. Das Beratungsunternehmen vermutet, dass aufgrund einer fehlenden mobilen Anwendung die Zeiten zu spät und ungenau erfasst werden, so dass es in der Folge zu Kundenreklamationen bezüglich der Rechnungen kommt.

Im dritten Beispiel geht es um eine Reservierungs-App für eine Restaurantkette. Die Restaurantkette besitzt mehrere Restaurants pro Ortschaft und möchte die Auslastung der Restaurants mit Hilfe der neuen Reservierungs-App optimieren.

Wenn wir die oben genannten Beispiele betrachten, wird schnell deutlich, dass die Ursache der erwähnten Projekte nicht unbedingt mit einer Verbesserung der Benutzererfahrung zu tun hat. Da jedoch wesentliche Teile der Anwendungen neu gestaltet werden sollen, besteht nun die Möglichkeit, auch diese in Angriff zu nehmen.

Im Problem Statement wird daher gemeinsam mit dem Auftraggeber überlegt, welche grundlegenden Ziele in Bezug auf die Verbesserung der Benutzererfahrung bestehen. Dazu werden wichtige Probleme oder Chancen identifiziert.

Ergebnis

Ein Proto-Problem Statement besteht aus nachfolgenden Elementen.

Nutzende

In der Spalte “Nutzende” werden betroffene Nutzergruppen angegeben. Die Nutzergruppen werden in der Folge des Projektes in Form von Proto-Personas detailliert. Im Fall der Zeiterfassung erkennen wir Mitarbeitende und Projektleiter.

Probleme

In der Spalte "Probleme" werden die Herausforderungen aufgeführt, die durch das Vorhaben angegangen werden sollen. Mithilfe einer Proto-Journey können die Probleme der Nutzer:innen im Zusammenhang mit einem bestimmten Ablauf beschrieben werden.

Für die Mitarbeitenden ist die Zeiterfassung heute sehr aufwändig und sie sind immer wieder mit der Situation konfrontiert, das Projekte fehlen, auf die sie ihre Zeiten buchen sollten. Die Projektleiter erhalten immer wieder Reklamationen von Kunden wegen Unklarheiten oder falschen Rechnungen.

Lösungen

In der Spalte "Lösungen" werden zunächst Erwartungen festgehalten. Die eigentlichen Lösungen sollen während der Projektlaufzeit erarbeitet werden. Zu Beginn kann es jedoch hilfreich sein, bestehende Lösungsideen zu erfassen.

Ziele

In der Spalte "Ziele" wird angegeben, wie sich der Erfolg eines Projektes feststellen lässt. Die Definition von Metriken erlaubt es, Erwartungen an ein Projektergebnis zu objektivieren. Metriken können in einem Metriken-Board weiter detailliert werden.

Die Mitarbeitenden sollen im Durschnitt weniger als 10 Minuten für die Erfassung der Zeiten aufwenden müssen. Die Projekttleiter sollten maximal eine Reklamation pro 20 Rechnungen erhalten.

Stakeholder

Stakeholder sind von einem Problem bzw. von dessen Lösung direkt oder indirekt betroffen. Sie sollten involviert oder zumindest regelmäßig über Zwischenergebnisse des Projektes informiert werden. Stakeholder können mit Hilfe einer Stakeholder-Analyse genauer untersucht werden.

Im vorliegenden Beispiel gilt es das Produktmanagement, die Support- und Schulungsabteilung sowie den Verkauf und das Marketing mit einzubeziehen.

Randbedingungen

Der Auftraggeber legt Randbedingungen für das Projekt fest. Dazu gehören in der Regel das Budget, Zeitbeschränkungen, technische Anforderungen, Vorgaben für die zur Verfügung gestellten Ressourcen oder den Kundenzugriff. Im vorliegenden Beispiel soll keine Änderung an der Datenbank vorgenommen werden. Diese Randbedingung wird im Verlauf des Projekts sicherlich hinterfragt. An diesem Punkt wird sie jedoch einfach aufgenommen.

Risiken

Bei der Lösung der Probleme können auch Risiken vorhanden sein. Diese werden hier gesammelt. Allenfalls ist es notwendig, Massnahmen zur Mitigation der Risiken zu definieren.

Vorgehen

Ein Workshop zur Erarbeitung eines Proto-Problem Statements besteht aus folgenden Schritten.

1

Vorbereitung

Wir definieren das Ziel des Proto-Problem Statement Workshops und identifizieren die relevanten Teilnehmer:innen. Es kann hilfreich sein, im Rahmen der Vorbereitung des Workshops mit ausgewählten Stakeholdern Interviews durchzuführen.
2

Einführung und Kontext

Wir erklären den Teilnehmenden den Zweck und die Bedeutung von einem Proto-Problem Statement. Wir geben ihnen einen Überblick über das Konzept und erklären, wie Proto-Problem Statements zur Verbesserung der Benutzerorientierung beitragen können. Wir stellen die Ziele des Workshops vor.

3

Informationen vorstellen

Haben wir in der Vorbereitung bereits Informationen gesammelten, werden diese nun vorgestellt.

4

Probleme beschreiben

Basierend auf den vorgestellten Informationen beginnen, wir mögliche Zielgruppen zu identifizieren. Je Zielgruppe identifizieren wir nun mögliche Probleme. An dieser Stelle geht es aber nicht darum, detaillierte Usability-Probleme zu sammeln, sondern um grundlegende Herausforderungen. Wir beschreiben aus Nutzerperspektive einen gewünschten Zielzustand, der sich nach der Lösung des Problems einstellen sollte. Diese Ziele operationalisieren wir mit konkreten Metriken.

5

Weitere Aspekte

Wir sammeln Stakeholder, Randbedingungen und Risiken, die bei dem Vorhaben zu berücksichtigen sind.
6

Feedback und Überprüfung

Wir stellen das finale Proto-Problem Statement nochmals vor und bitten um Feedback und Verbesserungsvorschläge. Wir überprüfen das Problem Statement auf seine Klarheit, Verständlichkeit und Vollständigkeit.
7

Abschluss

Wir bedanken uns für den erfolgreichen Workshop und stellen das weitere Vorgehen vor.
No items found.

Weiter lesen