Verstehen vor Anforderungen: Ein tiefgehender Blick auf User Requirements und den Nutzenskontext

Im komplexen Feld der Produktentwicklung und Gestaltung ist es essenziell, nicht einfach nur Anforderungen blind umzusetzen, sondern gründlich zu verstehen, was Nutzer tatsächlich brauchen, um ihre Ziele zu erreichen. Dieses Verständnis ist das Fundament, auf dem erfolgreiche Lösungen aufgebaut werden. In diesem Artikel möchte ich mit euch teilen, wie wir aus Forderungen und Anforderungen zu einem echten Verstehen gelangen können, das uns befähigt, passgenaue Nutzungsanforderungen zu formulieren. Dabei gehe ich auf den Nutzenskontext, das Verhalten der Nutzer, mentale Modelle, Objekte und Strukturen sowie das Hinterfragen von Lösungsalternativen ein. Außerdem erkläre ich, wie wir Validität sicherstellen und den Übergang zu Anforderungen gestalten. Lasst uns gemeinsam diese spannende Reise antreten.

Von Forderungen zu User Requirements: Der kleine, aber feine Unterschied

Oft begegnen wir in Projekten Listen von Anforderungen: „Wir wollen Funktion A, Funktion B, Funktion C und Information D im Interface haben.“ Das klingt erstmal plausibel, doch reicht das selten aus, um eine wirklich nutzerzentrierte Lösung zu schaffen. Diese sogenannten Forderungen sind oft nur Wünsche oder Vorstellungen darüber, was die Lösung können oder wie sie aussehen soll. Sie bleiben aber Forderungen, die nicht zwangsläufig das widerspiegeln, was Nutzer tatsächlich brauchen.

Hier liegt ein wichtiger Unterschied: Eine Forderung ist nicht gleich ein User Requirement. Ein User Requirement ist eine Nutzungsanforderung, also eine Anforderung an das, was die Lösung in der Nutzung leisten muss, damit der Benutzer sein Ziel erreicht. Es geht dabei nicht darum, wie die Lösung technisch oder gestalterisch aufgebaut sein soll, sondern was sie leisten muss.

„Wir müssen aus dem Verstanden heraus ableiten, was eine Lösung in der Nutzung erfüllen muss, damit der Benutzer sein Ziel erreicht.“

Dieser Unterschied ist zentral, um nicht direkt in die Umsetzung einer vermeintlichen Lösung zu springen, die vielleicht gar nicht den Kern des Nutzerbedarfs trifft. Stattdessen sollten wir das „Warum“ hinter den Forderungen verstehen und herausfinden, was Nutzer wirklich in ihren Kontexten brauchen.

Der Nutzenskontext: Wo beginnt echtes Verstehen?

Das „Warum“ zu verstehen bedeutet, tief in den Nutzenskontext einzutauchen. Der Nutzenskontext beschreibt die reale Situation, in der Personen mit bestimmten Zielen und Aufgaben agieren. Dabei sind die Umstände so vielfältig wie die Nutzer selbst: Der eine arbeitet bei Regen, der andere bei Sonnenschein; der eine hat viel Zeit, der andere wenig; der eine nutzt eine bestimmte Ressource, der andere eine ganz andere.

Diese Unterschiede sind entscheidend, denn sie beeinflussen, ob und wie Nutzer ihre Ziele erreichen können. Wer verstehen will, welche Anforderungen eine Lösung erfüllen muss, muss also den Nutzenskontext umfassend betrachten und analysieren.

• Personen und Nutzergruppen: Wer sind die Nutzer? Welche unterschiedlichen Bedürfnisse, Ziele und Einstellungen haben sie?
• Aufgaben und Ziele: Welche Kern- und Teilaufgaben gehören zum Nutzungskontext? Welche Ziele verfolgen die Nutzer?
• Ressourcen und Arbeitsmittel: Welche physischen, sozialen und technischen Bedingungen herrschen vor? Welche Ressourcen stehen zur Verfügung?
• Verhalten zur Zielerreichung: Wie verhalten sich Nutzer in diesem Kontext, um ihre Ziele zu erreichen?

Das Verstehen dieser Facetten ist die Grundlage, um aus Forderungen echte Nutzungsanforderungen abzuleiten.

Neugierde als Schlüssel: Wo schauen wir hin?

Wenn ich an meine eigenen Projekte und Erfahrungen zurückdenke, frage ich mich immer wieder: Wo muss ich überall hinschauen, um ein umfassendes Verständnis zu bekommen? Das sind die Bereiche, die ich mir besonders anschaue:

1. Relevante Nutzergruppen: Wer nutzt das System? Welche Rollen und Einstellungen haben die Nutzer? Beispiel: Bei Flugbegleitern gab es eine Gruppe, die nur ihren Job erledigen wollte, und eine andere, die sich stark mit dem Unternehmen identifizierte. Diese Unterschiede haben Einfluss auf Informationsbedürfnisse und Nutzungserwartungen.
2. Verhalten der Nutzer: Wie verhalten sich Menschen tatsächlich in ihrem Kontext? Neugierige Beobachtung und Hinterfragen sind hier entscheidend, um auch ungewöhnliche Verhaltensweisen zu verstehen.
3. Objekte, Strukturen und Abläufe: Was sind die „Dinge“, mit denen Nutzer interagieren? Bei Antragstellungen etwa sind das Anträge, Adressen, Antragsteller – alles Objekte mit ihren Attributen und Beziehungen.
4. Lösungsalternativen: Welche bestehenden Lösungen oder Wettbewerber gibt es? Wie funktionieren sie? Und vor allem: Warum sind sie so gestaltet?
5. Validität und Iteration: Sind unsere Annahmen und Erkenntnisse richtig? Wie können wir sie überprüfen und gegebenenfalls anpassen?

Diese Perspektiven helfen, den Nutzenskontext umfassend zu erfassen und ermöglichen es, aus der Vielzahl an Informationen das Wesentliche herauszufiltern.

Verhalten und Motivation: Happy Pass und Worst Case

Beim Verstehen des Nutzerverhaltens ist es wichtig, nicht nur den „Happy Pass“, also den idealen, problemlosen Ablauf, zu betrachten. Oft wird nur das Beste für den glücklichen Nutzer gestaltet. Doch was passiert, wenn etwas schiefgeht? Was passiert in risikobehafteten Situationen?

Gerade in Bereichen wie der Medizintechnik ist das ein zentrales Thema. Dort müssen Usability und User Experience so gestaltet sein, dass keine Gefährdungen entstehen. Risiken werden bewusst analysiert und in die Gestaltung einbezogen.

Auch in weniger regulierten Bereichen sollten wir uns fragen, wo Risiken lauern. Beim Ausfüllen eines Antrags kann ein Fehler dazu führen, dass eine Förderung nicht gewährt wird – das ist ein Worst Case, der berücksichtigt werden muss.

Umfassendes Verständnis bedeutet also auch, Anti-Personas zu definieren, also Nutzergruppen oder Verhaltensweisen, die wir bewusst nicht unterstützen wollen, und zwischen intrinsisch motivierten Zielen (die Nutzer wollen etwas aus eigenem Antrieb erreichen) und extrinsisch motivierten Zielen (Ziele werden vorgegeben, z.B. im Job) zu unterscheiden.

Mentale Modelle, Objekte, Strukturen und Abläufe verstehen

Ein oft unterschätzter Aspekt ist das Verständnis der mentalen Modelle der Nutzer. Diese Modelle sind individuelle Vorstellungen und Erwartungen darüber, wie Dinge funktionieren, welche Objekte es gibt und wie Abläufe gestaltet sind.

Mentale Modelle bestehen aus:

• Objekten: Dinge, mit denen Nutzer interagieren (z.B. Anträge, Bücher, Nebel, Nebelscheinwerfer).
• Attributen: Eigenschaften oder Merkmale dieser Objekte (z.B. Titel eines Buches, Adresse eines Antragstellers).
• Strukturen: Beziehungen zwischen Objekten (z.B. ein Autor hat mehrere Bücher).
• Abläufen: Übliche Prozesse aus Nutzersicht, wie sie Ziele erreichen (z.B. Antrag ausfüllen, Taxi rufen).

Diese mentalen Modelle sind höchst individuell und basieren auf Lebenserfahrungen. Wenn eine neue Lösung eingeführt wird, versuchen Nutzer, sie in ihre bestehenden Modelle zu integrieren. Konflikte zwischen Erwartung und tatsächlicher Lösung können zu Verwirrung und Ablehnung führen.

Deshalb ist es so wichtig, die mentalen Modelle zu erfassen und bei der Gestaltung zu berücksichtigen. Zum Beispiel erwarten Nutzer beim Zugfahren, dass sie zum Bahnhof gehen – wenn zukünftig ein autonomes Fahrzeug sie abholt, müssen wir diese neue Erwartung klar kommunizieren und mental modellieren.

Lösungsalternativen betrachten: Reverse Design Analyse

Ein spannender Ansatz ist es, bestehende Lösungen und Wettbewerberprodukte nicht einfach nachzubauen, sondern sie rückwärts zu analysieren. Dabei versuchen wir zu verstehen, welche Objekte, Strukturen und Abläufe in einer Lösung repräsentiert sind und warum bestimmte Informationen so präsentiert werden.

Diese „Reverse Design Analyse“ erlaubt es, Hypothesen über die Bedürfnisse und Anforderungen der Nutzer zu generieren. Zum Beispiel kann eine Zusammenfassung eines Antrags mit allen Attributen in einer Lösung darauf hinweisen, dass es für Nutzer wichtig ist, einen Überblick zu behalten und alles auf einen Blick zu prüfen.

Dabei gilt: Lösungen sind Gegenstand der Analyse, aber keine Vorgabe. Wir wollen nicht nachbauen, sondern verstehen, was im Kontext wichtig ist und wie wir bessere oder passendere Lösungen gestalten können.

Besonders wichtig ist es, das gesamte Ökosystem von Lösungen zu betrachten. Nutzer erreichen ihre Ziele oft nicht an nur einem Interface, sondern über verschiedene Touchpoints – Desktop-Anwendung, mobile App, physisches Interface etc.

Ein Beispiel ist das Taxi-Rufen: Neben der App gibt es die Möglichkeit, telefonisch eine Taxizentrale zu kontaktieren oder spontan auf der Straße ein Taxi zu nehmen. Alle diese Touchpoints gehören zum Nutzungskontext und müssen verstanden werden.

Validität sichern: Wie prüfen wir, ob wir richtig verstanden haben?

Ein häufiger Fehler ist, zu schnell zu glauben, alles richtig verstanden zu haben. Deshalb ist es essenziell, das gewonnene Verständnis zu validieren. Das kann auf verschiedene Weise geschehen:

• Workshops mit Nutzern: Ergebnisse wie Personas, Aufgabenmodelle oder Szenarien werden mit Nutzern besprochen, um Lücken oder Missverständnisse aufzudecken.
• Cardsorting: Nutzer sortieren Begriffe oder Objekte, um mentale Modelle zu erfassen und zu überprüfen, ob die Struktur verstanden wird.
• Teachback-Verfahren: Nutzer erklären Prozesse oder Abläufe aus ihrer Sicht, wodurch wir ihre mentalen Modelle offenlegen können.
• Usability-Tests: Bestehende Lösungen oder Prototypen werden getestet, um zu sehen, ob die Erfordernisse erfüllt werden und wo es Probleme gibt.

Validierung ist besonders wichtig bei schnellen Projekten mit wenig Ressourcen, um Fehlentwicklungen frühzeitig zu erkennen und zu korrigieren.

Erfordernisse definieren: Was brauchen Nutzer wirklich?

Nach dem umfassenden Verstehen des Nutzenskontexts und des Nutzerverhaltens steht die Frage im Raum: Was brauchen Nutzer tatsächlich, um ihre Ziele zu erreichen? Dabei unterscheiden wir drei wesentliche Erfordernisse:

1. Information: Was müssen Nutzer wissen? Zum Beispiel: Der Fahrgast muss wissen, was die Taxifahrt kostet, um entscheiden zu können, ob er Taxi fährt oder auf den Bus wartet.
2. Ressourcen: Welche Mittel müssen verfügbar sein? Zum Beispiel: Ein Taxi muss in der Nähe verfügbar sein, damit die Fahrt möglich ist.
3. Kompetenzen: Was müssen Nutzer können? Zum Beispiel: Nutzer müssen in der Lage sein, eine App zu installieren und zu bedienen, um die Taxibestellung darüber abzuwickeln.

Diese Erfordernisse sind unabhängig von der konkreten Lösung. Sie bilden die Basis für die späteren Nutzungsanforderungen, die dann definieren, was eine Lösung leisten muss.

Vom Verstehen zu Nutzungsanforderungen

Jetzt, wo wir die Erfordernisse kennen, können wir sie in Nutzungsanforderungen übersetzen. Eine Nutzungsanforderung beschreibt, was die Lösung in der Nutzung leisten muss, ohne sich auf eine konkrete technische Umsetzung festzulegen.

Beispielhafte Nutzungsanforderungen für das Taxi-Beispiel könnten sein:

• Der Benutzer muss am System erkennen können, was die Fahrt mit dem Taxi kostet.
• Der Benutzer muss am System erkennen können, ob ein Taxi in der Nähe verfügbar ist.
• Das System muss es dem Benutzer ermöglichen, eine Information oder Ressource auszuwählen, um die Fahrt zu buchen.

Wichtig ist, dass wir vermeiden, Anforderungen zu formulieren, die schon eine Lösung vorgeben, wie z.B. „Der Benutzer muss eine App installieren können“. Solche „immunisierten Anforderungen“ schränken die Lösungsfreiheit ein und können Innovationen verhindern.

Stattdessen sollten wir Anforderungen lösungsneutral formulieren, um den größtmöglichen Spielraum für kreative und passende Lösungen zu haben.

Formalität und Flexibilität im Analyseprozess

Eine wichtige Frage, die oft gestellt wird, ist, wie stark die einzelnen Analyseschritte formalisiert sein müssen. Die Antwort hängt stark vom Projekt, den verfügbaren Ressourcen und den Anforderungen ab.

Ich versuche, auf einer Ebene zu arbeiten, auf der die wichtigsten Herausforderungen klar beschrieben und für alle verständlich sind. Manchmal nenne ich diese Herausforderungen nicht „Erfordernisse“, weil nicht jeder diesen Begriff kennt, sondern spreche von „Herausforderungen“, die bewältigt werden müssen.

Die Dokumentation sollte nachvollziehbar sein und idealerweise durch Interviews oder andere Methoden belegt werden. So entsteht eine solide Grundlage, auf der Anforderungen formuliert und später umgesetzt werden können.

Fazit: Verstehen kommt vor Anforderungen

Das Herzstück erfolgreicher Gestaltung und Entwicklung ist das Verstehen des Nutzenskontexts, der Nutzerbedürfnisse und des Nutzerverhaltens. Nur wer wirklich versteht, warum Nutzer etwas wollen und was sie brauchen, kann Anforderungen formulieren, die zu echten Lösungen führen.

Dabei ist es essentiell, nicht direkt in die Umsetzung zu springen, sondern Forderungen kritisch zu hinterfragen, mentale Modelle zu erfassen, Lösungsalternativen zu analysieren und das Verständnis kontinuierlich zu validieren.

Der Übergang von Erfordernissen zu Nutzungsanforderungen schafft eine klare, lösungsneutrale Grundlage, auf der kreative und passgenaue Lösungen entstehen können. So vermeiden wir, dass Lösungen „vom Himmel fallen“ und stattdessen gestalten wir bewusst und nutzerzentriert.

Diese Vorgehensweise ist nicht nur theoretisch sinnvoll, sondern hat sich in zahlreichen Projekten bewährt, von der Antragstellung in Behörden bis hin zur Entwicklung zukünftiger Mobilitätskonzepte wie dem autonomen Fahren.

Lasst uns also neugierig bleiben, immer wieder hinterfragen und mit Empathie und Struktur an das Verstehen herangehen – denn Verstehen kommt vor Anforderungen!