Ausgangslage

Vor dem Start eines Projekts bitten wir das Produktteam um alles, was es über seine Nutzenden weiß. Was dann kommt, ist meist umfangreich: Personas, ein Prozessdiagramm, die Systemarchitektur, Notizen aus Kundengesprächen. Das Team hat eine Kontextbeschreibung, ohne sie so zu nennen. Beim Lesen fällt auf, dass die Dokumente an manchen Stellen ausführlich sind und an anderen nichts enthalten. Über die Nutzenden ist viel bekannt, über ihre Arbeitsumgebung wenig. Über das System ist alles dokumentiert, über die Aufgaben davor und danach nichts. Niemand hat das so entschieden. Die Lücken liegen dort, wo das Team nicht war.

ISO 9241-11 gibt ein Raster vor, an dem sich diese Lücken erkennen lassen. Gebrauchstauglichkeit ist nach der Norm das Ausmaß, in dem ein System durch bestimmte Nutzende in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen. Der Nutzungskontext setzt sich aus vier Bestandteilen zusammen: Nutzende, Aufgaben, Arbeitsmittel und Umgebung. Wer einen davon nicht erhoben hat, kann Gebrauchstauglichkeit nicht beurteilen, weil ein Teil der Bedingungen fehlt, unter denen das System genutzt wird. Ich benutze das Raster deshalb vor allem als Prüfliste für das, was fehlt.

Bestandteil 1: Nutzende

Der erste Bestandteil beschreibt, wer das System benutzt. Dazu gehören Merkmale, die für die Nutzung relevant sind: Vorwissen im Fachgebiet, Erfahrung mit vergleichbaren Systemen, körperliche Voraussetzungen, Sprache, Häufigkeit der Nutzung, Rolle in der Organisation. Nicht jedes Merkmal ist für jedes System relevant. Ob eine Person Handschuhe trägt, ist für eine Bürosoftware ohne Bedeutung und für ein Terminal in der Werkstatt entscheidend.

Die Frage im Feld lautet: Wer benutzt das System, und welche Eigenschaften dieser Personen wirken sich auf die Nutzung aus? Die Antwort entsteht aus Beobachtung und Gespräch. Eine Stellenbeschreibung nennt die Rolle, das Feld zeigt, wer die Rolle ausfüllt und wie. In einem unserer Projekte stand „Servicetechniker" in der Persona. Im Feld saßen dahinter ein Kollege mit langer Erfahrung an der Maschine und eine Auszubildende, mit demselben Terminal und unterschiedlichen Fragen an das System.

Typische Lücke: Die Nutzergruppe ist als Rolle benannt, aber ohne die Merkmale, die für die Gestaltung zählen. Dann fehlt später die Grundlage, um Anforderungen für Personen mit wenig Systemerfahrung von denen für Routinenutzende zu unterscheiden.

Bestandteil 2: Aufgaben

Der zweite Bestandteil beschreibt, was die Nutzenden erreichen wollen und welche Tätigkeiten sie dafür ausführen. Eine Aufgabe hat ein Ziel, einen Auslöser, Schritte, ein Ergebnis und Bedingungen wie Häufigkeit, Dauer, Zeitdruck und Folgen eines Fehlers. Aufgaben hängen zusammen: Was vor der Nutzung des Systems passiert und was danach, gehört zur Aufgabe, auch wenn das System dort nicht beteiligt ist.

Die Frage im Feld lautet: Was tun die Nutzenden, um ihr Ziel zu erreichen, in welcher Reihenfolge, und was passiert, wenn es nicht gelingt? Beobachtung zeigt hier mehr als das Gespräch, weil Routinehandlungen im Gespräch ausgelassen werden. Wer eine Nummer seit Jahren beim Kollegen erfragt, hält das für keinen Arbeitsschritt.

Typische Lücke: Die Aufgabe wird als Funktionsliste des Systems beschrieben („Auftrag anlegen, Auftrag freigeben"), nicht als Tätigkeit der Person. Dann fehlen die Schritte, die außerhalb des Systems liegen, etwa dieser Anruf.

Bestandteil 3: Arbeitsmittel

Der dritte Bestandteil umfasst alles, womit die Nutzenden arbeiten: Hardware, Software, Dokumente, Werkzeuge, andere Systeme, die parallel im Einsatz sind. Dazu gehört auch, was die Nutzenden sich selbst geschaffen haben: der Zettel am Monitor, die Excel-Liste neben dem Fachsystem, die Fotos auf dem Telefon.

Die Frage im Feld lautet: Womit arbeiten die Nutzenden, und welche Mittel benutzen sie zusätzlich, um die Aufgabe zu erledigen? Die zusätzlichen Mittel sind Hinweise auf Erfordernisse, die das bestehende System nicht erfüllt. Wenn ich an einem Arbeitsplatz einen Zettel am Monitor sehe, ist er meine erste Frage im Gespräch, weil auf dem Zettel steht, was das System nicht liefert.

Typische Lücke: Das eigene System ist vollständig beschrieben, die Systeme daneben fehlen. Dann entstehen Anforderungen, die den Wechsel zwischen Systemen übersehen, obwohl er einen großen Teil der Arbeitszeit ausmacht.

Bestandteil 4: Umgebung

Der vierte Bestandteil beschreibt die physischen, sozialen und organisatorischen Bedingungen der Nutzung. Physisch: Licht, Lärm, Temperatur, Vibration, Platz, Netzabdeckung. Sozial: Wer ist anwesend, wer schaut zu, wer unterbricht. Organisatorisch: Schichtbetrieb, Freigaberegeln, Haftung, Zeitvorgaben.

Die Frage im Feld lautet: Unter welchen Bedingungen findet die Nutzung statt, und welche davon verändern die Nutzung? Sonnenlicht auf dem Display, ein Kollege, der über die Schulter schaut, oder eine Freigaberegel, die zwei Personen verlangt, sind Bedingungen, die im Meetingraum nicht auffallen.

Typische Lücke: Die Umgebung wird als Standardbüro angenommen, weil dort die Erhebung stattfand. Die Bedingungen am Einsatzort tauchen später als Bedienfehler in der Evaluation auf.

Grenzen des Rasters

Das Raster sagt, was erhoben werden muss. Es sagt nicht, wie tief. Die Tiefe hängt vom System und vom Risiko ab. Für eine interne Anwendung mit geringen Fehlerfolgen reicht eine knappe Beschreibung, für ein System an einer Maschine oder in einem Leitstand ist jeder Bestandteil ausführlich zu dokumentieren. Das Raster ersetzt auch nicht die Erhebung im Feld. Wer die vier Fragen im Meetingraum beantwortet, füllt das Raster mit Annahmen.

Ein Einwand, den wir oft hören: Die vier Bestandteile seien bekannt, und erfahrene Teams hätten sie im Kopf. Für die Begriffe trifft das zu. Für die Lücken trifft es aus unserer Erfahrung nicht zu, weil eine Lücke im Kopf nicht auffällt. Sie fällt auf, wenn vier Abschnitte nebeneinanderliegen und einer davon leer ist.

Was danach vorliegt

Eine Kontextbeschreibung mit vier Abschnitten, je Abschnitt die erhobenen Angaben und ihre Quelle (Beobachtung, Interview, Dokument). Lücken sind als Lücken markiert. Aus dieser Beschreibung lassen sich Nutzungsanforderungen ableiten, die Nutzergruppe, Aufgabe und Bedingung nennen. Das Raster dient danach als Prüfliste: Vor jeder neuen Iteration wird geprüft, ob die Evaluation einen der vier Bestandteile verändert hat.