Kein Blick zurück

In Projekten kümmern sich zunächst Requirements Engineers um eine Anforderungsanalyse. Dabei greifen sie auf drei Arten von Informationsquellen zu: Stakeholder, Dokumente und Bestandssysteme. Stakeholder sind Personen, die Einfluss auf Anforderungen haben, beispielsweise Fachexperten oder Nutzer. Relevante Dokumente sind etwa Anforderungsdokumente und Fehlerberichte des Bestandssystems, aber auch Normen und Gesetzestexte. Bestandssysteme sind Vorgänger- oder Konkurrenzsysteme. Requirements Engineers erwarten, in der Analyse von Bestandssystemen und Dokumenten Lösungen für eine neue Anwendung – eine neue App, eine Website, ein Shop-System oder eine B2BSoftware – zu finden. Diese Arbeitsweise führt aber oft in eine Sackgasse, da sie im schlimmsten Fall bereits begangene Fehler weiterentwickelt. Unsere UX Engineers von MAXIMAGO haben sich deshalb von diesem Weg verabschiedet: Wir interessieren uns in der ersten Phase nicht für Bestandssystem und Dokumentation, wollen Pflichtenheft und Anforderungsdokumente nicht sehen.

Warum Projekte bereits bei der Anforderungserhebung scheitern

Erfolgreiche Software hilft Kunden, ihre unternehmerischen Ziele zu erreichen: Entweder direkt oder als Teil einer Gesamtlösung, die den Kunden der Kunden weiterhilft. Deshalb muss der Nutzungskontext allen Teilnehmern des Entwicklungsprozesses klar sein. Wir fragen uns, welche Funktion einen echten Nutzen hat. Sie muss im Nutzungskontext eindeutig begründet sein, denn fehlende oder überflüssige Funktionen behindern und überfordern den Nutzer – das gefährdet unternehmerische Ziele.

Dieser Nutzungskontext kann aus dem Altsystem oft nur schwer herausgelesen werden, weil es nur aus Lösungen besteht – guten und schlechten. In der etablierten Arbeitsweise hat sich gezeigt, dass sich Designer und Entwickler an diesen Lösungen orientieren, sobald sie sie kennen. Dadurch entstehen nur selten neue innovative Lösungen. Deshalb interessieren sich UX Engineers in der Analyse nicht für Lösungen, sondern nur für Probleme in Form von Zielen und Aufgaben sowie den tatsächlichen Anforderungen der Nutzer, die den Entwicklungsprozess antreiben werden. Der UX Engineer hinterfragt gemeinsam mit dem Kunden etwa, ob eine Suchfunktion nötig ist, die fast jede Anwendung bietet. Warum sollte der Kunde diese Funktion auch auf seiner Website oder in seiner Anwendung anbieten, gibt es dafür einen Grund? »Der Nutzer braucht die Suche, um…« Ja, um was? Weil sie jeder bietet oder weil das Programm nicht die richtige Funktion zum richtigen Moment intuitiv anbietet? Dass sich nutzlose Funktionen in Anwendungen einschleichen, hat meist einen der drei folgenden Gründe:

• Der Maßstab sind Konkurrenzlösungen: Funktionen werden kopiert, ohne den Nutzen zu hinterfragen. Viele Onlineshops sehen zum Beispiel wie Amazon aus und funktionieren genauso. In Bezug auf Selbstbeschreibungsfähigkeit und Erwartungskonformität ist die Kopie scheinbar eine gute Lösung. Aber ist die Lösung eines Marktführers sinnvoll für einen Online-Shop, der lediglich ein Nischenpublikum bedient?
• Es wurden die falschen Stakeholder befragt: Stakeholder halten sich häufig für die Repräsentanten der Nutzer, aber sie gehören oft nicht zur echten Benutzergruppe oder sind fachlich vorbelastet. Deswegen fällt es ihnen schwer, valide Aussagen zur Nutzung zu treffen: Der Vertriebsmitarbeiter eines Sensorenherstellers betrachtet die Anwendung eines Mitbewerbers ganz anders als der Techniker, der mit der Sensorensoftware Lecks in seiner Produktionsanlage sucht.
• Es wurden die richtigen Stakeholder mit den falschen Fragen befragt: Erfahrene UX Engineers halten sich sehr lange im Problemraum auf und verwenden viel Zeit auf die Analyse, um zum Kern des Problems vorzudringen. Dazu beobachten und befragen sie die Nutzer. Die UX Engineers gehen aber niemals so weit, den Nutzer nach Wünschen zu fragen oder um Lösungen zu bitten. Denn dazu ist der Nutzer meist nicht in der Lage, weil er das Problem nicht unabhängig und unbefangen von der bestehenden Lösung betrachten kann. Daher müssen UX Engineers Bestandssystemen immer skeptisch begegnen und sich auf die Ermittlung des Nutzungskontextes konzentrieren. Denn daraus lassen sich die tatsächlichen Nutzungsanforderungen ableiten.

Ein neuer Weg der Anwendungsentwicklung

Die Grundlage unserer Projekte ist die Nutzerperspektive, sie ist mitentscheidend für den Erfolg eines ganzen Unternehmens. Deshalb binden wir unseren Kunden bereits von Projektbeginn ein: Am Anfang steht eine Analyse, Dokumentation und Prüfung der Produktstrategie, des Nutzungskontext und der Erfordernisse. Unsere Vorgehensweise gliedert sich in folgende Abschnitte:

• Herausarbeiten der Unternehmensperspektive und der sich daraus ergebenen Ziele;
• Identifizierung der Nutzerperspektive, der Ziele und nötigen Zwischenziele in der Wertschöpfungskette des Kunden;
• Synchronisierung der Perspektiven anhand von konkreten Motivationstechniken.

Häufig liegen diese Informationen bereits vor, allerdings nicht bei jedem. Um diese Informationen allen zugänglich zu machen, beginnen wir das Projekt mit einem Workshop. Relevante Teilnehmer sind dabei das Management, das die übergeordneten Ziele und operative Maßnahmen kennt; Marketing und Produktmanagement, Vertrieb, Support und Entwickler, um die Machbarkeit festzustellen. Und natürlich echte Nutzer, um die Kernanforderungen zu ermitteln. Am Workshop sollten mindestens drei, besser vier oder mehr Personen teilnehmen, damit ausreichend Expertise an einem Tisch sitzt, aber immer noch ausführliche Diskussionen möglich sind. Falls ein Workshop sechs Personen übersteigen würde, teilen wir ihn auf mehrere Tage und Gruppen auf, um effizient zu arbeiten. In diesem bei Bedarf mehrtägigen Workshop diskutieren die Teilnehmer etwa folgende Fragen:

• Was ist die Funktionsvision in einem Satz?
• Wer profitiert davon?
• Warum ist noch nicht jeder potenzielle Kunde bereits Kunde?
• Was sind die zukünftigen Zielsegmente und warum?
• Wie lassen sich die Benutzergruppen charakterisieren?
• Welche Anwendungsfälle gibt es in jedem Szenario?
• Was sind die Auslöser und Ziele der Anwendungsfälle?
• Welche Schritte durchläuft der Benutzer?
• Wie läuft die Zusammenarbeit verschiedener Benutzer ab?

Als Ergebnis erhalten wir eine vollständige und validierte Nutzungskontextbeschreibung und damit unter anderem

• Informationen über Produktvision und Wertschöpfungskette;
• die (verschiedenen) Benutzergruppen der Anwendung sowie
• deren Ziele, Arbeitsaufgaben und Aufgabenabfolgen;
• für jede Nutzungsanforderung eine Begründung aus Benutzersicht in Form eines oder mehrerer Erfordernisse;
• Informationen über die Rahmenbedingungen, unter denen das System eingesetzt wird, darunter Schnittstellen zu vorangehenden und nachgelagerten Prozessen;
• eine Grundlage für die weiteren Arbeitsschritte im Projektverlauf, vor allem natürlich für die Konzeption;
• eine professionelle Basis für die Angebotserstellung.

Unabdingbare Voraussetzung dafür ist die Bereitschaft, dass alle Rollen ihren Teil beitragen und sich offen auf einen freien und von allen Seiten kritischen Austausch der Perspektiven einlassen. Der Vorteil einer unvorbelasteten UX-Entwicklung ist offensichtlich: UX Engineers erstellen neue Nutzungskonzepte, ohne sich an im schlimmsten Fall überholten Entwicklungen orientieren zu müssen. Denn diese sind während der Konzeption unbekannt.