ISO 9241-210 beschreibt menschzentrierte Gestaltung als vier Aktivitäten: den Nutzungskontext verstehen, Nutzungsanforderungen festlegen, Gestaltungslösungen entwerfen und Lösungen evaluieren. Der Beitrag beschreibt je Aktivität, was dort erarbeitet wird, welche Erkenntnis entsteht und welche Entscheidung sie vorbereitet. Produktverantwortliche und Entwicklungsteams können danach benennen, an welcher Stelle im Vorgehen ihr Vorhaben steht und was am Ende jeder Aktivität vorliegen muss.
Ausgangslage
Ein Abnahmetest, den ich vor einigen Jahren begleitet habe: Zwei Sachbearbeiterinnen sitzen vor der neuen Fachanwendung, der Projektleiter steht hinter ihnen, die Aufgabe lautet „Legen Sie einen Vorgang an". Nach einer Weile ist der Vorgang angelegt, mit einem Umweg über das alte System und einem Anruf bei einer Kollegin. Der Projektleiter notiert: bestanden. Auf meine Frage, woran er das misst, sagt er, der Vorgang sei ja da.
In dieser Organisation gab es alle vier Aktivitäten, ohne dass sie so hießen: Gespräche mit Kunden, ein Anforderungsdokument, Entwürfe und diesen Abnahmetest. Was fehlte, war die Zuordnung: Welche Erkenntnis entsteht wo, und welche Entscheidung hängt davon ab. Der Test sollte zeigen, ob die Nutzenden ihre Aufgaben erledigen, und niemand hatte vorher festgelegt, welche Aufgaben das sind und woran der Erfolg gemessen wird.
ISO 9241-210 ordnet die Aktivitäten und definiert für jede ein Ergebnis. Die Norm legt zusätzlich fest, dass die Aktivitäten wiederholt durchlaufen werden, bis die Nutzungsanforderungen erfüllt sind, und dass der Prozess geplant wird, bevor er beginnt.
Aktivität 1: Den Nutzungskontext verstehen und festlegen
Die erste Aktivität erhebt, wer das System benutzt, welche Aufgaben diese Personen erledigen, mit welchen Arbeitsmitteln und unter welchen Bedingungen. Die vier Bestandteile stammen aus ISO 9241-11. Die Erhebung findet dort statt, wo die Nutzung stattfindet: durch Beobachtung, Kontextinterviews und die Analyse vorhandener Dokumente.
Die Erkenntnis, die hier entsteht, ist eine Beschreibung des Ist-Zustands: welche Ziele die Nutzenden verfolgen, wo sie Umwege gehen und welche Bedingungen die Nutzung erschweren. Die Entscheidung, die sie vorbereitet, betrifft den Umfang des Vorhabens. Welche Nutzergruppen und Aufgaben das System abdecken soll, lässt sich erst festlegen, wenn bekannt ist, welche es gibt. Der Umweg über das alte System wäre hier aufgefallen, lange vor dem Abnahmetest.
Das Ergebnis ist die Kontextbeschreibung: ein Dokument mit den vier Bestandteilen, je Angabe mit Quelle.
Aktivität 2: Nutzungsanforderungen festlegen
Die zweite Aktivität leitet aus der Kontextbeschreibung ab, was die Nutzenden mit dem System erreichen müssen. Eine Nutzungsanforderung nennt eine Nutzergruppe, eine Aufgabe, eine Bedingung und ein Kriterium, an dem die Erfüllung geprüft wird. Sie beschreibt ein Erfordernis und keine Lösung.
Die Erkenntnis, die hier entsteht, ist eine geordnete Menge von Erfordernissen mit ihrer Herkunft aus der Beobachtung. Die Entscheidung, die sie vorbereitet, ist die Priorisierung: Welche Erfordernisse muss die erste Lösung erfüllen, welche können warten. Diese Entscheidung fällt im Produktmanagement, auf Grundlage dessen, was erhoben wurde.
Das Ergebnis ist die Anforderungsliste mit Erfolgskriterien. Sie ist zugleich der Maßstab für die vierte Aktivität; ihr Fehlen ließ den Projektleiter ohne Maß zurück.
Aktivität 3: Gestaltungslösungen entwerfen
Die dritte Aktivität entwirft Lösungen, die die Anforderungen erfüllen sollen. Sie beginnt mit Aufgabenabläufen und Interaktionskonzepten, geht über Skizzen und Prototypen und endet bei der umgesetzten Oberfläche. ISO 9241-110 liefert die Dialogprinzipien für den Entwurf. Die Reife steigt von Schleife zu Schleife; die erste Fassung ist ein Papierprototyp, die letzte das Produkt.
Die Erkenntnis, die hier entsteht, ist eine prüfbare Hypothese: Diese Lösung erfüllt die Anforderungen unter den beschriebenen Bedingungen. Die Entscheidung, die sie vorbereitet, ist die Auswahl zwischen Alternativen; ein einziger Entwurf lässt sich nur bestätigen oder verwerfen.
Das Ergebnis ist ein Prototyp in der Reife, die die Evaluation braucht, mit Verweis auf die Anforderungen.
Aktivität 4: Gestaltungslösungen evaluieren
Die vierte Aktivität prüft die Lösung gegen die Anforderungen aus der zweiten Aktivität. Geprüft wird mit den Menschen, für die es gedacht ist. Die Methode richtet sich nach der Reife des Entwurfs: eine Inspektion gegen ISO 9241-110 für frühe Fassungen, ein moderierter Usability-Test für Prototypen, eine Messung unter Einsatzbedingungen für das fertige System.
Die Erkenntnis, die hier entsteht, ist zweigeteilt. Erstens: welche Anforderungen die Lösung erfüllt und welche nicht. Zweitens: was die Sitzungen über den Nutzungskontext gezeigt haben, das vorher nicht bekannt war. Die Entscheidung, die sie vorbereitet, ist die über die nächste Schleife: Reicht der Stand für die Freigabe, oder geht die Lösung in die Überarbeitung, und welche der drei anderen Aktivitäten wird dafür wieder aufgenommen.
Das Ergebnis ist ein Evaluationsbericht mit Erfüllungsstatus je Anforderung und einem Abschnitt für Beobachtungen zum Nutzungskontext.
Die Reihenfolge im Projektalltag
Die Norm zeichnet die vier Aktivitäten als Kreis. Im Projektalltag beginnt der Kreis selten bei der ersten Aktivität, und ich halte das für richtig. Ein bestehendes Produkt steigt bei der Evaluation ein: Ein Usability-Test des Ist-Systems liefert Befunde und Kontextbeobachtungen für die nächste Fassung. Ein neues Produkt beginnt mit der Kontexterhebung. Ein Projekt mit vorhandenem Backlog beginnt mit der Prüfung, welche der Anforderungen auf eine Beobachtung zurückgehen.
Entscheidend ist die Richtung der Abhängigkeiten. Anforderungen ohne Kontextbeschreibung sind Annahmen. Entwürfe ohne Anforderungen lassen sich nicht prüfen, weil der Maßstab fehlt. Eine Evaluation ohne Kriterien liefert eine Fehlerliste, deren Bedeutung niemand einordnen kann.
Grenzen
Die vier Aktivitäten beschreiben, welche Ergebnisse vorliegen müssen. Sie schreiben keine Methoden vor und keinen Aufwand. Wie tief eine Kontexterhebung geht und wie viele Testpersonen eine Evaluation braucht, hängt vom System und von den Folgen eines Fehlers ab. Den Einwand, die Norm sei für agile Teams zu schwer, höre ich oft; sie verlangt vier Ergebnisse und keine vier Phasen, und ein Sprint kann alle vier enthalten. Die Norm beschreibt zudem den Prozess und nicht die Organisation. Ob die Ergebnisse in Entscheidungen einfließen, hängt davon ab, ob sie an einem Entscheidungspunkt vorliegen und dort verlangt werden.
Was danach vorliegt
Wer die vier Aktivitäten kennt, kann für jedes Vorhaben angeben, an welcher Stelle es steht und welches Ergebnis dort vorliegen muss: Kontextbeschreibung, Anforderungen mit Kriterien, Prototyp, Evaluationsbericht. Die Zuordnung zeigt zugleich, wo ein Vorhaben eine Aktivität übersprungen hat: ein Backlog ohne Kontextbeschreibung, ein Entwurf ohne Anforderungen, ein Release ohne Evaluation. Dort lässt sich benennen, was nachgeholt wird, bevor die nächste Entscheidung fällt.