Durch die Brille des Nutzers: Nutzungskontext eines interaktiven Systems analysieren, Nutzungsanforderungen ermitteln und dieses Wissen in der Praxis anwenden

Dieser Artikel erschien zuerst bei den Webkrauts.


Interaktive Systeme können nur dann erfolgreich sein, wenn von Beginn an klar ist, welche Probleme sie eigentlich lösen sollen, und wenn jede einzelne Anforderung aus der Sicht des Nutzers begründet ist. Sonst kommt es zu fehlenden oder überflüssigen Funktionen, wodurch Nutzer vergrault (und die Kosten gesteigert) werden und das Projekt scheitert. Es ist einfach, an die richtigen Anforderungen zu gelangen: Man stellt Nutzern die richtigen Fragen und hört aufmerksam zu.

Dieser Artikel erklärt, wie Usability Engineers den Nutzungskontext eines interaktiven Systems analysieren und beschreiben und daraus Nutzungsanforderungen ableiten. Anschließend geht es darum, wie diese Analysen in der Praxis angewendet werden, auch dann, wenn es lediglich darum geht, kleine Websites oder Anwendungen zu entwickeln. Dabei reicht es häufig, auf eigene Erfahrungen zurückzugreifen; diese sollten aber vernünftig erfasst und hin und wieder mit echten Nutzern abgeglichen werden. 

Der benutzerzentrierte Gestaltungsprozess

Usability ist definiert als »Ausmaß, in dem ein interaktives System durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um festgelegte Ziele effektiv, effizient und zufriedenstellend zu erreichen« (ISO 9241-11). Hohe Usability lässt sich planen und erzielen, wenn in allen Phasen der Entwicklung des interaktiven Systems der Benutzer im Mittelpunkt steht. Man spricht dabei von einem benutzerzentrierten Gestaltungsprozess, der aus vier miteinander verbundenen Aktivitäten besteht (siehe Abbildung 1).

Abbildung 1: Benutzerzentrierter Gestaltungsprozess (© itemis AG, nach ISO 9241-210)

Abbildung 1: Benutzerzentrierter Gestaltungsprozess (© itemis AG, nach ISO 9241-210)

Die beiden ersten Aktivitäten nach der Planung lassen sich unter dem Stichwort »benutzerzentrierte Analyse« zusammenfassen; darauf basierend erfolgt die »benutzerzentrierte Gestaltung«; den Abschluss einer Iteration bildet die »benutzerzentrierte Evaluation«.

Warum überhaupt analysieren?

Eine Websites und Web-Anwendungen kann nur dann erfolgreich sein, wenn von Beginn an klar ist, welches Problem sie eigentlich lösen soll, und wenn jede einzelne Anforderung aus der Sicht des Nutzers begründet ist. Sonst kommt es zu fehlenden oder überflüssigen Funktionen, wodurch Nutzer vergrault (und die Kosten gesteigert) werden und das Projekt scheitert. Das wurde in der Vergangenheit durch zahlreiche Beispiele bestätigt, besonders drastisch beispielsweise bei der Ablösung AltaVistas durch Google.

AltaVista war bis ins Jahr 1999 neben HotBot die bekannteste Volltext-Suchmaschine der Welt. Ende der 1990er veränderte AltaVista seine strategische Ausrichtung und entwickelte sich von einer Suchmaschine zu einem Portal mit Nachrichten, E-Mail und Einkaufsangeboten (siehe Abbildung 2). AltaVista versuchte damit, mit Yahoo! zu konkurrieren, war damit aber nahezu erfolglos. Im Suchmaschinenmarkt wurde AltaVista währenddessen ziemlich schnell von Google überholt. Das lag vor allem daran, dass Google sich konsequent auf die primären Anforderungen der Nutzer ausgerichtet hatte: Das User Interface beschränkte sich auf Wesentliche, nämlich das Suchfeld und die Anzeige der Suchergebnisse. Bei den damals noch üblichen langsamen Internet-Verbindungen brachte das den Suchmaschinennutzern erhebliche Vorteile. AltaVista wurde nach mehreren Übernahmen von Yahoo! gekauft und verlor bis zu seiner Schließung im Juli dieses Jahres mehr und mehr an Bedeutung. Google hingegen gehört seit Jahren zu den wertvollsten Marken der Welt.

Abbildung 2: AltaVista und Google 1999 (Quelle: archive.org)

Abbildung 2: AltaVista und Google 1999 (Quelle: archive.org)

Anforderungen konsequent aus der Perspektive der Benutzer zu berücksichtigen, ist die zentrale Grundlage erfolgreicher Projekte und kann entscheidend sein für den Erfolg eines gesamten Unternehmens. Der Ansatz der benutzerzentrierten Analyse stellt sicher, dass diese sogenannten Nutzungsanforderungen systematisch ermittelt, dokumentiert, geprüft und verwaltet werden.

Den Nutzungskontext verstehen und beschreiben

Wer die oben genannte Definition von Usability verinnerlicht hat, wird aufhorchen, wenn er Aussagen hört wie »Die Usability dieser Anwendung ist schlecht« und sich fragen: Schlecht für wen? Schlecht unter welchen Rahmenbedingungen? Oder mit den Worten eines Usability Engineers: Schlecht für welchen Nutzungskontext?

Der Nutzungskontext eines interaktiven Systems wird beschrieben durch die Benutzer, deren Aufgaben und Arbeitsmittel (Hardware, Software und Materialien) sowie die Umgebung, in der sie mit dem interaktiven System arbeiten (ISO 9241-11), siehe Abbildung 3.

Abbildung 3: Elemente des Nutzungskontexts eines interaktiven Systems (© itemis AG)

Abbildung 3: Elemente des Nutzungskontexts eines interaktiven Systems (© itemis AG)

Was bedeutet das genau, beispielsweise für eine Web-Anwendung zur Erstellung von Terminumfragen wie Doodle?

  • Benutzer sind Personen, die eine Umfrage erstellen oder daran teilnehmen wollen. Zumindest der ersten Gruppe lässt sich eine gewisse IT- bzw. Online-Affinität unterstellen.
  • Ziele und Arbeitsaufgaben: Eine Umfrage erstellen und andere dazu einladen; an einer Umfrage teilnehmen; Umfrageergebnisse einsehen.
  • Arbeitsmittel sind primär ein Webbrowser und ein Gerät, auf dem dieser läuft, beispielsweise ein Notebook oder ein Smartphone. Arbeitsmittel sind aber auch ein Kalender und ein Adressbuch.
  • Über die Umgebung lässt sich am wenigsten sagen. Termine werden überall vereinbart, daher ist ein mobiler Kontext, vielleicht unter widrigen Sicht- und akustischen Bedingungen, genauso wahrscheinlich wie eine Nutzung im Büro auf einem 24-Zoll-Display.

Klingt diese Nutzungskontextbeschreibung überzeugend? Sie wurde wohlüberlegt und gewissenhaft verfasst. Aus Sicht eines Usability Engineers ist sie dennoch wertlos – sie basiert vollständig auf Annahmen und ist ohne Benutzerbeteiligung entstanden.

Bei überschaubaren Websites und Web-Anwendungen mit bekannter Aufgabenstellung, reicht es aus, die Beschreibung des Nutzungskontexts mit echten Benutzern zu diskutieren und zu validieren. Beispielsweise bei der Website des örtlichen Zahnarztes oder eben einem Online-Terminfinder. Bei komplexen interaktiven Systemen hingegen oder solchen, die Arbeitsaufgaben einer unbekannten Fachdomäne abbilden, ist es unabdingbar, Interviews mit Benutzern zu führen und zu dokumentieren. Folgende Leitfragen können dabei zur Orientierung dienen:

  • Welche Aufgaben führen Sie mit dem System durch?
  • Wie häufig fallen die einzelnen Aufgaben an? Welche führen Sie häufig durch, welche eher selten?
  • Gibt es eine bestimmte Reihenfolge, in der Sie die Aufgaben abarbeiten?
  • Sind zur Lösung von Aufgaben Dialogschritte oder Eingaben notwendig, die Sie eigentlich nicht benötigen?
  • Wo kann etwas schief gehen? Wie bemerken Sie das?
  • Arbeiten Sie mit jemandem über das System zusammen? Wie läuft die Zusammenarbeit ab?
  • Macht Ihnen die Nutzung des Systems Spaß?
  • Welche besonderen Stärken hat die derzeitige Lösung?
  • Welche besonderen Schwächen hat die derzeitige Lösung?

Das Ziel ist es, zusammen mit den beteiligten Benutzern ein gemeinsames Verständnis des Kontexts und der Aufgaben zu entwickeln und darin deren Erfordernisse zu erkennen.

Nutzungsanforderungen spezifizieren

Erfordernisse beschreiben, welches Ziel ein Benutzer erreichen will und welche Voraussetzung dafür erfüllt sein muss. Sie sind aus der Sicht des Nutzers und vollkommen systemneutral formuliert, das heißt sie geben keine technischen Details vor.

Einige Erfordernisse sind offensichtlich und ergeben sich direkt aus der Aufgabe, beispielsweise das folgende Erfordernis für das Beispiel »Online-Terminfinder«:

»Ein Teilnehmer einer Terminumfrage (Benutzer) muss wissen, welche Termine angeboten werden (Voraussetzung), um bei der Teilnahme an der Umfrage (Nutzungskontext) eine Auswahl treffen zu können (Ziel).«

Andere Erfordernisse ergeben sich erst dann, wenn der Usability Engineer genau zuhört, wenn Nutzer erzählen, was sie tun oder worauf sie achten, wenn sie ihrer Arbeitsaufgabe nachgehen, und wenn er gezielt nachfragt. Beispiele dafür könnten sein:

»Ein Ersteller einer Terminumfrage muss einsehen können, welche Personen der Einladung zwar gefolgt sind, aber noch keine Angaben gemacht haben, um explizit nachfragen zu können, ob diese kein Interesse an der Veranstaltung generell oder nur an keinem Termin Zeit haben.«

»Ein Teilnehmer einer Terminumfrage muss wissen, welche Termine welche anderen Teilnehmer angegeben haben, um bei der Teilnahme an der Umfrage die Termine angeben zu können, die bevorzugte Personen ebenfalls gewählt haben.«

Alle erkannten Erfordernisse werden in einem Bericht gesammelt, der dem nächsten Schritt zugrunde liegt, der Spezifikation der Nutzungsanforderungen.

Nutzungsanforderungen beschreiben eine erforderliche Leistung oder Aktion eines Benutzers während er eine Aufgabe an einem interaktiven System durchführt. Aus dem ersten Erfordernis des oben genannten Beispiels lassen sich zwei Nutzungsanforderungen ableiten:

»Der Nutzer muss am System erkennen können, welche Termine angeboten werden.«

»Der Nutzer muss am System die Termine auswählen können, an denen er teilnehmen will.«

Die folgenden (zusätzlichen) Nutzungsanforderungen ergeben sich aus den beiden nächsten Erfordernissen:

»Der Nutzer muss am System erkennen können, welche Personen der Einladung bereits gefolgt sind.«

»Der Nutzer muss am System die bisherigen Umfrageergebnisse detailliert einsehen können, also welcher Teilnehmer welche Termine angegeben hat.«

»Der Nutzer muss am System die bisherigen Umfrageergebnisse einsehen können, bevor er selbst an der Umfrage teilnimmt.«

Je nach Größe und Komplexität des interaktiven Systems umfasst eine Nutzungsanforderungsspezifikation eine Handvoll bis viele Hundert Nutzungsanforderungen. Aus Nutzersicht ist das System damit vollständig beschrieben. Die Phase der benutzerzentrierten Analyse ist abgeschlossen.

Nutzungsanforderungen bilden die Grundlage für die Gestaltung

In den ersten beiden Phasen des benutzerzentrierten Gestaltungsprozesses 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.

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

0 Kommentare

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Kommentar verfassen