Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Durch die Brille des Nutzers II

Usability Engineering: Benutzerzentrierte Analysen in der Praxis

Durch die Brille des Nutzers II

Die benutzerzentrierte Analyse hilft dabei, Websites und Web-Anwendungen so zu gestalten, dass sie nützlich und effizient sind. Die notwendigen Informationen werden über Interviews mit den Benutzern erhoben – das kann aufwendig sein. Für gewöhnliche Websites genügt es, auf eigene Erfahrungen zurückzugreifen, diese sollten aber vernünftig erfasst und hin und wieder mit echten Nutzern abgeglichen werden.

Nutzungsanforderungen bilden die Grundlage für die Gestaltung

In den ersten beiden Phasen des benutzerzentrierten Gestaltungsprozesses (Abbildung 1) geht es darum, den Nutzungskontext zu beschreiben und Nutzungsanforderungen zu spezifizieren. In der dritten Phase werden darauf basierend Lösungen entworfen. Dabei finden im Wesentlichen zwei Aktivitäten statt: das Interaktionsdesign sowie die Gestaltung des User Interfaces.

Benutzerzentrierter Gestaltungsprozess: Nutzungskontext verstehen und beschreiben, Nutzungsanforderungen spezifizieren, Gestaltungslösungen entwickeln, Produkt evaluieren
Abbildung 1: Benutzerzentrierter Gestaltungsprozess (© itemis AG, nach ISO 9241-210)
Das Interaktionsdesign beschreibt das Zusammenspiel zwischen den Eingaben des Nutzers und den Ausgaben des Systems, während der Nutzer mit dem System arbeitet, um seine Aufgaben zu erledigen. Das User Interface wiederum besteht nach ISO 9241-210 aus allen Bestandteilen eines interaktiven Systems, die Informationen und Steuerelemente zur Verfügung stellen, die der Benutzer benötigt, um seine Aufgaben mit dem interaktiven System zu erledigen. Das bedeutet, dass alle Elemente, die er dafür nicht benötigt, im User Interface nichts zu suchen haben.

Letztlich dreht sich auch hier wieder alles um den Benutzer und seine Aufgaben. Beides gehört zum Nutzungskontext und findet sich in den Erfordernissen und Nutzungsanforderungen wieder, die dem Designer damit klar vorgeben, was sie zu gestalten haben (und was nicht).

Auf der anderen Seite lassen Nutzungsanforderungen Designern aufgrund der Art, wie sie formuliert sind, auch viele Freiheiten. Sie beschreiben zwar, wie ein Nutzer mit einem System interagiert, implizieren aber keine Lösung. Folgende Gegenüberstellung macht den Unterschied deutlich:

»Der Nutzer muss über das System Kontakt zu einem Ansprechpartner aufnehmen können.«

»Das System muss dem Nutzer ein Kontaktformular bereitstellen, das in einem Popup-Fenster eingeblendet wird.«

Die erste Formulierung ist eine Nutzungsanforderung. Sie macht dem Designer keine Vorgaben und überlässt es ihm, die Steuerelemente und Informationen auszuwählen und anzubieten, die aus seiner Sicht die Aufgabenerfüllung bestmöglich unterstützen. Die zweite Formulierung ist eine Systemanforderung und beschreibt bereits eine konkrete Lösung, aber sicherlich nicht die beste. Im mobilen Kontext wäre vielleicht eine Telefonnummer wünschenswert, aber die konkret formulierte Anforderung bietet keinen Raum für eine derartige Idee.

Anwendbarkeit der benutzerzentrierten Analyse in der Praxis

Interviews mit Benutzern führen, den Nutzungskontext beschreiben, Erfordernisse erkennen und dokumentieren – das alles, um zu einer möglichst vollständigen Spezifikation der Nutzungsanforderungen zu gelangen? In welchen Projekten lässt sich das wirtschaftlich durchführen? Lohnt sich der Aufwand bei einer Website, über die der örtliche Zahnarzt auf sein Angebot aufmerksam machen möchte, oder über die eine Ferienwohnung präsentiert und zur Reservierung angeboten werden soll? Ist es sinnvoll, Nutzungsanforderungen zu spezifizieren, wenn es darum geht, kleine Web-Anwendungen zu entwickeln wie beispielsweise ein einfaches Tool zur Arbeitszeiterfassung oder einen Online-Terminfinder? Die Antwort lautet in allen Fällen: Ja! Man muss nur pragmatisch vorgehen.

Bei den gerade genannten Beispielen gehört vermutlich jeder Webworker selbst zur Gruppe der potenziellen Nutzer und kann daher auf Basis der eigenen Erfahrungen und Erfordernisse versuchen, den Nutzungskontext zu beschreiben. Daraus ergibt sich ein erster Satz von Nutzungsanforderungen, der allerdings noch mit Vorsicht zu genießen ist. Die Annahmen müssen validiert und gegebenenfalls korrigiert und ergänzt werden.

Der Auftraggeber eignet sich dafür im Allgemeinen nicht. Häufig gehört er selbst zu keiner (echten) Benutzergruppe des Systems oder ist fachlich vorbelastet. Ein Zahnarzt besucht die Website eines anderen Zahnarztes aus ganz anderen Gründen als Personen mit Zahnschmerzen auf der Suche nach Hilfe und einem Termin.

Auch der Blick auf vergleichbare Websites und Anwendungen ist nicht hilfreich, denn was dort zu sehen ist, sind Lösungen. In der Analyse sucht man aber nach Problemen (Arbeitsaufgaben) und den tatsächlichen Anforderungen der Nutzer. Was lässt sich beispielsweise daraus schließen, wenn auf vier von fünf analysierten Ferienwohnungen-Websites eine Anzeige des örtlichen Wetters zu sehen ist? Braucht man das? Warum? Anderes gefragt: Gibt es dafür ein Erfordernis? »Der Besucher der Website muss wissen, wie das aktuelle Wetter am Ort der Ferienwohnung ist, um« – tja, um was? Vermutlich gibt es dafür kein Erfordernis und diese Funktion ist unnötig.

Die einzige Möglichkeit, Annahmen zu validieren, bieten Interviews mit anderen (potenziellen) Benutzern. An die ist relativ einfach heranzukommen, wenn das Ziel der Website oder Web-Anwendung allgemeinverständlich ist. Vermutlich eignet sich fast jeder. Am Beispiel der Ferienwohnung-Website reichen zwei Fragen, um herauszufinden, ob jemand zur avisierten Benutzergruppe gehört oder nicht: »Machen Sie Urlaub in Ferienwohnungen? Würden Sie eine Ferienwohnung über das Internet reservieren?« Wer diese beiden Fragen mit »Ja« beantwortet, gehört dazu und eignet sich für eine Befragung (die zudem vermutlich nicht lange dauert). Häufig kommt bereits nach zwei oder drei Gesprächen nichts Neues mehr. Wenn es mehr als eine Benutzergruppe gibt, beispielsweise Ersteller von Terminumfragen und Teilnehmer an Terminumfragen, dann sind entsprechend mehr Interviews notwendig.

Auf diese Weise können Webworker die Annahmen, die sie beim ersten Entwurf der Nutzungskontextbeschreibung getroffen haben, bestätigen oder widerlegen sowie durch neue Erkenntnisse ergänzen. Als Ergebnis erhalten sie eine vollständige und validierte Nutzungskontextbeschreibung und damit

  • Informationen über die (verschiedenen) Benutzer des interaktiven Systems sowie
  • deren Ziele, Arbeitsaufgaben und Aufgabenabfolgen und somit eine Beschreibung des Zwecks des Systems;
  • für jede Nutzungsanforderung eine Begründung aus Benutzersicht in Form eines oder mehrerer Erfordernisse und dadurch Hinweise darauf, welche Funktionen unnötig komplex oder gar überflüssig sind;
  • Informationen über die Rahmenbedingungen, unter denen das System eingesetzt wird;
  • eine Grundlage für die weiteren Arbeitsschritte im Projektverlauf, vor allem in Bezug auf die Gestaltung;
  • eine Basis für Inspektionsverfahren in der Phase der benutzerzentrierten Evaluation (dabei dient die Liste der Nutzungsanforderungen als Checkliste, anhand der überprüft wird, ob das System effektiv ist, also alle Nutzungsanforderungen erfüllt);
  • eine professionelle Basis für die Angebotserstellung gegenüber den Kunden sowie – last but noch least –
  • eine Grundlage für die benutzerzentrierte Analyse bei folgenden, ähnlichen Projekten.

Und dafür lohnt es sich doch, ein wenig Zeit bei Gesprächen mit seinen Nutzern zu verbringen, oder?

Literatur und Quellen

Kommentare

Gunnar Bittersmann
am 16.12.2013 - 12:51

Zum Thema Formulierung von Nutzungsanforderungen finde ich den Artikel „Writing ‘As a User’ does not make it a user story“ lesenswert.

Permanenter Link
Michael Jendryschik

Michael Jendryschik (Autor)
am 17.12.2013 - 10:45

Ja, das ist richtig, eine Anforderung wird nicht dadurch zur Nutzungsanforderung, indem ich sie über eine Formulierungsschablone als Nutzungsanforderung »verkleide«. Entscheidend ist nicht, wie Anforderungen formuliert werden, sondern wie sie ermittelt werden. Das beschreibe ich vor allem im ersten Teil des Artikels. Dort steht vielleicht nicht klar genug, dass Nutzungsanforderungen sich stets aus Erfordernissen ableiten sollten, weil sonst die Gefahr besteht, dass es sich eben nicht um Anforderungen der Nutzer handelt, sondern um Anforderungen anderer Stakeholder.

Permanenter Link

Die Kommentare sind geschlossen.