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.
Arbeitsmodus
Voraussetzung
Teilnehmende
Dauer
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
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.
Vorbereitung
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.
Informationen vorstellen
Haben wir in der Vorbereitung bereits Informationen gesammelten, werden diese nun vorgestellt.
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.
