Konzept: Benutzerzentriertes Design
Benutzerzentriertes Design ist ein Anwendungsdesign, in dem die Bedürfnisse und die Effektivität des Endbenutzers im Mittelpunkt stehen.
Hauptbeschreibung

Was ist benutzerzentriertes Design?

Es gibt keinen klaren Konsens über das, was ein benutzerzentriertes Design ausmacht. John Gould und seine Kollegen bei IBM haben jedoch in den achtziger Jahren einen Ansatz (Design for Usability [GOU88]) entwickelt, der die gemeinhin akzeptierten Definitionen beinhaltet. Dieser Ansatz stützt sich auf praktische Erfahrung in einer Reihe von interaktiven Systemen, von denen insbesondere das Olympic Messaging System der IBM von 1984 [GOU87] zu erwähnen ist. Der Ansatz hat vier Hauptkomponenten, die im Folgenden beschrieben sind.

Fokus auf Benutzern

Gould schlägt vor, dass Entwickler die Zielgruppe festlegen müssen und sie zum frühestmöglichen Zeitpunkt einbezieht. Er schlägt eine Reihe von Methoden vor, um sich mit den Benutzern, ihren Aufgaben und Anforderungen vertraut zu machen:

·    Mit Benutzern sprechen

·    Kunden besuchen

·    Benutzer bei der Arbeit beobachten

·    Videos von Benutzern bei der Arbeit erstellen

·    Informationen zur Arbeitsorganisation sammeln

·    Selbst ausprobieren

·    Benutzer dazu bringen, bei der Arbeit laut zu denken

·    Kooperatives Design

·    Erfahrene Benutzer in das Designteam aufnehmen

·    Aufgabenanalyse durchführen

·    Umfragen machen und Fragebogen austeilen

·    Testfähige Ziele entwickeln


In Rational Unified Process (RUP) werden in mehreren Schlüsselstadien Workshops abgehalten, aber diese müssen durch die von Gould beschriebenen Arten von Aktivitäten ergänzt werden, um ein genaues Bild zu erhalten. (Ein Grund hierfür ist, dass Personen häufig etwas anderes beschreiben als das, was sie wirklich tun. Häufig ausgeführte Aufgaben und scheinbar unwichtige Details wie der Zeitpunkt, zu dem eine Aktivität ausgeführt wird, oder die Existenz "mysteriöser" Zettel werden häufig vergessen oder weggelassen, weil sie "offiziell" nicht zum aktuellen Prozess gehören.)

Integration mit dem Design

Aufgaben im Bereich Benutzerfreundlichkeit müssen bereits in einem frühen Stadium der Entwicklung parallel ausgeführt werden. Zu diesen Aufgaben gehören beispielsweise das Skizzieren der Benutzerschnittstelle und das Erstellen eines Entwurfs für die Benutzerhandbücher oder die Onlinehilfe. Gould stellt sogar das Prinzip auf, dass Benutzerfreundlichkeit in die Hände einer speziellen Gruppe gelegt werden sollte.   

Ein wichtiges Merkmal des integrierten Design ist, dass der Gesamtansatz - das Framework - für detailliertes Benutzerschnittstellendesign in einem frühen Stadium entwickelt und getestet wird. Es besteht ein wichtiger Unterschied zwischen benutzerzentriertem Design und anderen rein inkrementellen Techniken. Das benutzerzentrierte Design stellt sicher, dass inkrementelles Design, das in späteren Phasen durchgeführt wird, sich nahtlos in das Framework einfügt und dass die Benutzerschnittstelle in Erscheinung, Terminologie und Konzept konsistent ist.

In RUP kann dieses Framework durch Verwendung eines Domänenmodells eingerichtet werden, um sicherzustellen, dass Terminologie und Konzepte, die in der Benutzerschnittstelle vorkommen, in ihrer Gesamtheit im Geschäft im Allgemeinen und bei den Benutzern im Besonderen bekannt sind und verstanden werden. (Außerdem wird es Teile des Domänenmodells geben, die nur für bestimmte Gruppen von Benutzern relevant sind. Es sollte sorgfältig darauf geachtet werden, dass das Domänenmodell so aufgebaut ist, dass diese Teile leicht zu erkennen sind.) Mit fortschreitendem Benutzerschnittstellendesign werden viele Domänenklassen als Benutzerschnittstellenelemente dargestellt. Die Benutzerschnittstellenelemente und ihre Beziehungen untereinander müssen mit dem Domänenmodell konsistent sein und in allen Teilen des entworfenen Systems konsistent dargestellt werden. (Dies hilft nicht nur den Benutzern, sondern unterstützt auch die Wiederverwendung von Benutzerschnittstellenkomponenten.)

Frühe Benutzertests

Frühe Benutzertests bedeuten Storyboarding und Entwicklung von Prototypen mit geringer Genauigkeit in einem frühen Stadium. Prototypen mit hoher Genauigkeit folgen später im Prozess.

Storyboards können zusammen mit Anwendungsfällen verwendet werden, um konkrete Szenarios für das zu entwerfende System zu schreiben. Diese können eine erzählende Form oder eine erzählende Form mit Bildern (unter Einbeziehung der Benutzerschnittstellenmodelle zur Veranschaulichung) annehmen. Storyboards, Walkthroughs (mit Benutzern) und benutzerkonzentrierte Gruppen sind Ansätze, mit denen viele Softwareentwickler möglicherweise nicht vertraut sind. Diese Ansätze sind jedoch ganz eindeutig kostenwirksamer, als nach der Implementierung erkennen zu müssen, dass das Design nicht angemessen ist oder die Anforderungen missverstanden wurden.

Iteratives Design

Objektorientierte Entwicklung ist zu einem Synonym für einen iteratives Prozess geworden. Iteratives Design eignet sich bestens für Probleme, die einer Verständnisklärung bedürfen und Anforderungsänderungen unterliegen. Deshalb ist es nicht überraschend, dass iteratives Design eine Schlüsselkomponente des benutzerzentrierten Designs ist. Dies ist teilweise auf die Bedürfnisse der Benutzer zurückzuführen, die sich mit der Zeit ändern, aber auch auf die inhärente Komplexität der Erstellung von Designlösungen, die unterschiedliche Bedürfnisse bewältigen können.

In benutzerzentrierten Methoden findet iteratives Design innerhalb eines integrierten Frameworks statt. Wir meiden inkrementelle Entwicklung außerhalb eines beschlossenen Frameworks absichtlich, da dies zu einer "Patchwork-Lösung" führen könnte.

Warum benutzerzentriertes Design?

Benutzerbedürfnisse treffen

Erfolgreiche interaktive Systeme stützen sich auf ihre Fähigkeit, die Bedürfnisse von Benutzern zu erfüllen. Dies bedeutet nicht nur, die diversen Benutzergruppen zu ermitteln, sondern auch das Know-how, die Erfahrung und die Vorlieben einzelner Benutzer zu erkennen.

Obwohl es für viele Entwickler und Manager verlockend ist, davon auszugehen, sie würden verstehen, was der Benutzer braucht, bewahrheitet sich dies in der Praxis nur selten. Häufig liegt die Aufmerksamkeit darauf, wie der Benutzer Aufgaben ausführen sollte, und nicht, wie er bevorzugt, die Aufgaben auszuführen. In vielen Fällen ist der Aspekt von Vorlieben viel mehr, als einfach das Gefühl der Kontrolle zu haben, obwohl dies für sich selbst genommen ein wichtiger Aspekt ist. Vorlieben werden auch durch Erfahrung, Fähigkeiten und Verwendungskontext bestimmt. Diese Aspekte werden als so wichtig für den Designprozess betrachtet, dass sie in dem internationalen Standard [ISO 13407] mit dem Titel Benutzer-orientierte Gestaltung interaktiver Systeme Berücksichtigung gefunden haben. Der Standard und zugehörige Aspekte werden im verbleibenden Teil allgemein beschrieben.

Benutzerschnittstellendesign

Benutzer begreifen ein System über seine Benutzerschnittstelle, über die sie mit ihm interagieren. Die Konzepte, Bilder und Terminologie, die in der Schnittstelle präsentiert werden, müssen den Bedürfnissen der Benutzer entsprechen. Ein System, das Kunden ermöglicht, Tickets zu kaufen, würde sich beispielsweise erheblich von einem System unterscheiden, das professionell von Ticketverkaufspersonal verwendet wird. Die Hauptunterschiede sind nicht bei den Anforderungen und auch nicht bei den detaillierten Anwendungsfällen, sondern bei den Merkmalen der Benutzer und den Umgebungen, in denen die Systeme betrieben werden, zu finden.

Die Benutzerschnittstelle muss außerdem einen potenziell weiten Bereich von Erfahrungen in mindestens zwei Dimensionen - Computer- und Domänenerfahrung - ansprechen. Vergleichen Sie dazu Abbildung 1. Computererfahrung bezieht sich nicht nur auf eine allgemeine Vertrautheit mit Computern, sondern auch auch Erfahrung mit dem entwickelten System. Benutzer, die wenig Erfahrung mit Computern oder der Problemdomäne haben (linke Ecke der Abbildung) erfordern einen grundsätzlich anderen Ansatz in der Benutzerschnittstelle als erfahrene Benutzer (in der rechten Ecke der Abbildung).

Im Begleittext beschriebene Abbildung

Abbildung 1: Die Auswirkungen von Computer- und Domänenerfahrung auf die Erlernbarkeit vs. Benutzerfreundlichkeit

Es ist nicht selbstverständlich, dass unerfahrene Benutzer mit der Zeit Experten werden. Seltene Verwendung, geringe Motivation und hohe Komplexität sind Faktoren, die einer solchen Entwicklung im Wege stehen können. Umgekehrt können einige Systeme vorwiegend erfahrene Benutzer haben. Faktoren können hier eine gute Schulung, häufige Verwendung und hohe Motivation (Jobabhängigkeit) sein. Einige dieser Aspekte und ihre Auswirkungen auf das Benutzerschnittstellendesign sind in Tabelle 1 gezeigt.

 

Niedrig

Hoch

Computererfahrung

Einfache Frage und Antwort, Ausfüllen einfacher Formulare, Schnittstelle im Web- (Hyperlink-) oder Menüstil

Ausfüllen komplexer Formulare, Schnittstelle im Web- (Hyperlink-) oder Menüstil; (Frage und Antwort oder Ausfüllen einfacher Formulare können für erfahrene Benutzer sehr frustrierend sein)

Domänenerfahrung

Allgemeine Terminologie und Konzepte

Domänenspezifische Terminologie und Konzepte

Schulung

Fokus auf Erlernbarkeit (konsistent, vorhersagbar, einprägsam)

Fokus auf Benutzerfreundlichkeit (direkt, anpassbar, unaufdringlich)

Verwendungshäufigkeit

Einfach zu lernen und merken, einfacher Schnittstellenstil

Einfach zu verwenden, mehrere Direktaufrufe und Techniken für Benutzereingabesteuerung

Motivation

Interessante Verwendung, leistungsstark, ohne komplex zu erscheinen.

Ausgereift mit vielen innovativen und anpassbaren Features.


Tabelle 1, Einige Faktoren, die das Benutzerschnittstellendesign beeinflussen

Interaktive Systeme müssen entweder so entworfen werden, dass sie einen entsprechenden Bereich von Benutzererfahrung und Situationen abdecken, oder es müssen Schritte eingeleitet werden, um das Designuniversum einzuschränken. Beispielsweise können durch Schulungen die Anforderungen für die Erlernbarkeit in einem komplexen System verringert werden. Alternativ kann ein System in seinem Umfang reduziert werden, so dass es den Kernanforderungen seiner Benutzer besser entgegenkommt (ein Vorschlag, den Alan Cooper in seinem Buch The Inmates Are Running the Asylum [COO99] macht).

Gesetzliche Vorschriften und Standards

Beim benutzerzentrierten Design müssen wir das Know-how und die physischen Attribute von Benutzern berücksichtigen. Diese Aspekte werden immer mehr in gesetzliche Vorschriften eingebettet. Diese Vorschriften zielen zum Großteil darauf ab, Benutzern mit Behinderungen Rechnung zu tragen. Systeme einem breiteren Bereich von Benutzern zugänglich zu machen, wird jedoch generell als vorteilhaft für die Benutzergemeinde als Ganzes angesehen.

In der folgenden Tabelle sind die relevanten gesetzlichen Vorschriften und die zugehörigen Quellen aufgeführt, die für viele Teile der Welt gelten:

Beschreibung Website

AUSTRALIEN

 
Disability Discrimination Act http://www.hreoc.gov.au/disability_rights/dda_guide/dda_guide.htm
Disability Rights http://www.hreoc.gov.au/disability_rights/index.html

EUROPA

 
European Disability Forum http://www.edf.unicall.be

VEREINIGTES KÖNIGREICH

 
Disability Discrimination Act http://www.hmso.gov.uk/acts/acts1995/1995050.htm
New Deal for Disabled People http://www.disability.gov.uk
Digital Access Campaign http://www.rnib.org.uk/digital/welcome.htm

VEREINTE NATIONEN

 
United Nations Standard Rules on the Equalization of Opportunities for Persons with Disabilities http://www.un.org/esa/socdev/enable/dissre00.htm
Social Development Information on the Internet http://www.unescap.org/esid/psis/disability/index.asp

VEREINIGTE STAATEN

 
Americans with Disabilities Act (ADA): US Department of Justice http://www.usdoj.gov/crt/ada/
Ziffer 508 des Workforce Investment Act: US Department of Justice http://www.usdoj.gov/crt/508/508home.html 
US Access Board Electronic and Information Technology Advisory Committee (EITAAC) http://www.access-board.gov 
World Wide Web Consortium Web Accessibility Campaign http://www.w3.org/wai/ 

WEITERE QUELLEN

 
Internetressourcen zum Theme Behinderungen http://www.disabilityresources.org

 Tabelle 2a, Gesetzliche Vorschriften, die sich auf Behinderungen beziehen, sortiert nach Land, Region und Behörde

Benutzerzentriertes Design und Benutzerschnittstellendesign finden nicht nur in den gesetzlichen Vorschriften, sondern auch in der Standardisierung immer mehr an Beachtung, wie die folgende Tabelle zeigt.

Beschreibung Website/Standards

ANSI

www.ansi.org

ANSI

ANSI-HFES

ANSI-NSC

ANSI und die Human Factors and Ergonomics Society haben eine Reihe gemeinsamer Standards veröffentlicht. ANSI hat unter anderem den Standard ANSI-NSC Z365 entwickelt, der sich auf die Kontrolle und Vorbeugung kumulativer Stresssyndrome (auch Repetitive Strain Injury oder RSI genannt) bezieht.

ANSI entwirft Standards, die sich im Rahmen des Information Infrastructure Standards Panel (IISP) mit der Mensch-Computer-Interaktion (HCI, Human Computer Interaction) beschäftigen.

ISO

www.iso.ch
ISO 9241 Eine umfangreiche Reihe von Standards, die sich hauptsächlich mit der Ergonomie von Workstations beschäftigen, aber auch Anleitung zur Benutzerfreundlichkeit (Teil 11) enthalten und die Basis für den gerade entwickelten Standard ANSI-HFES 200 bilden.
ISO 10075: 1991 Ergonomische Richtlinien für mentale Belastung
ISO 17041-1: 1995 Cursorsteuerung für Textverarbeitung
ISO 11581 Reihe von Entwicklungsnormen für Symbole und Zeiger.
ISO 13407: 1999 Standard für benutzerzentrierte Gestaltung von Prozessen für interaktive Systeme.

 Tabelle 2b, ANSI- und ISO-Standards für Benutzerschnittstellen- und benutzerzentriertes Design

Benutzerzentriertes Design in RUP

Die Entwicklung von Systemen, die Benutzerbedürfnissen entsprechen, bedeutet einen erheblichen Aufwand bei der Anforderungsanalyse. Beim benutzerzentrierten Design konzentriert sich dieser Aufwand auf Endbenutzer.

Die Disziplin Geschäftsmodellierung deckt die Modellierung der Mitarbeiter (innerhalb des Geschäfts) und der Geschäftsakteure (außerhalb des Geschäfts) ab.

Ein wesentlicher Schwerpunkt im benutzerzentrierten Design liegt auf dem Verständnis der Anforderungen der realen Personen, die die Rollen ausfüllen, die in den zuvor beschriebenen Arbeitsergebnissen beschrieben sind. Im Besonderen müssen wir vermeiden, hypothetische Benutzer zu entwerfen, für die das Design von Softwaresystem ein Leichtes ist. Die Arbeitsergebnisse, die Benutzer beschreiben, dürfen erst nach ausgiebigem und direktem Kontakt mit Benutzern geschrieben werden. Beim benutzerzentrierten Design ist der direkte Kontakt zu Benutzern Teil eines Prozesses, der zuweilen auch als kontextbezogene Recherche bezeichnet wird. Hugh Beyer und Karen Holtzblatt beschreiben (in ihrem Buch Contextual Design, [BEY98]) die Voraussetzung für eine kontextbezogene Recherche wie folgt:

"...go where the customer works, observe the customer as he or she works, and talk to the customer about the work."

(Einige konkrete Beispiele hierfür wurden bereits unter Fokus auf Benutzer aufgeführt.) Dieser Ansatz wird nicht nur verwendet, um ein besseres Verständnis der Systemanforderungen zu erlangen, sondern auch ein besseres Verständnis der Benutzer selbst, ihrer Aufgaben und ihrer Umgebungen. Jeder Benutzer hat eigene Attribute, die zusammen den so genannten Verwendungskontext bilden. Diese Attribute sind im ISO-Standard für benutzerzentriertes Design, der im Folgenden beschrieben wird, ausführliche dargelegt.

Verwendungskontexte

Der ISO-Standard Benutzer-orientierte Gestaltung interaktiver Systeme [ISO13407] beschreibt den ersten Schritt im Design als Verstehen und Spezifizieren des Verwendungskontextes. Die vorgeschlagenen Attribute sind:

Kontext Attribut

Aufgaben

Ziele der Systemverwendung, Häufigkeit und Dauer der Aufgaben, Arbeitsschutzüberlegungen, Zuordnung von Aktivitäten, Interaktion zwischen Benutzern und technischen Ressourcen. Aufgaben sollten nicht nur mit Funktionen oder Features beschrieben werden, die ein Produkt oder ein System bereitstellt.

Benutzer (für jeden Typ oder jede Rolle)

Wissen, Know-how, Erfahrung, Ausbildung, Schulung, physische Attribute, Gewohnheiten, Vorlieben, Fähigkeiten.

Umgebungen

Hardware, Software, Material; physische und soziale Umgebungen, relevante Standards, technische Umgebung, räumliches Umfeld, gesetzgebende Umgebung, soziale und kulturelle Umgebung.


Tabelle 3: Verwendungskontext aus dem ISO-Standard für benutzerzentriertes Design

Es ist hilfreich, den Benutzerkontext in zwei Bestandteile (Benutzertyp und Rolle) aufzuteilen und anschließend die Beziehungen zwischen allen vier Kontexten zu betrachten:

Im Begleittext beschriebenes Diagramm

Abbildung 2: Beziehungen zwischen Kontexten

Abbildung 2 zeigt, dass jede Aufgabe innerhalb einer Rolle ausgeführt wird, die ein Benutzer in einer Umgebung einnimmt. Diese Kontexte entsprechen den RUP-Arbeitsergebnissen, die in Tabelle 4 aufgelistet sind.

ISO-13407-Kontext RUP-Arbeitsergebnisse

Umgebungen

Benutzer

Rollen

  • Hohe Ebene:
    • Geschäftsakteur (externe Benutzer), 
    • Mitarbeiter oder Geschäftssystem (interne Benutzer)
  • Detailliert:

Aufgaben


 Tabelle 4, Gegenüberstellung der ISO-Standardkontexte für benutzerzentriertes Design und der RUP-Arbeitsergebnisse

Jeder dieser Kontexte kann nicht unerhebliche Auswirkungen auf das Design einer entsprechenden Benutzerschnittstelle haben. Deshalb stehen wir einer potenziell hohen Anzahl von Permutationen gegenüber. Selbst für ein kleines System kann es zwei Umgebungen (z. B. Geschäft und Kunde), drei Typen von Benutzern (Vertriebsneuling, Vertriebsexperte und Management) sowie sechs Rollen (Telefonvertriebsassistent, externe Vertriebsbeauftragte usw.) geben. Dies bedeutet 36 potenzielle Varianten pro Aufgabe, obwohl die Anzahl realistischer Kombinationen gewöhnlich wesentlich kleiner ist.

Aufgaben müssen ganz eindeutig individuell beschrieben werden, aber eine einzelne Beschreibung reicht für alle Permutationen wahrscheinlich nicht aus. Ein Ansatz ist, die Benutzer- und Umgebungskontexte in der Rollenbeschreibung zu berücksichtigen. Diese Lösung wird von Constantine und Lockwood [CON99] angewendet. Bei dieser Lösung wird eine separate "Benutzerrolle" für jede wichtige Permutation von Rolle, Benutzer und Umgebung verwendet. Anschließend wird diese Benutzerrolle mit einer beschreibenden Wortfolge und nicht nur mit einem einzelnen Substantiv benannt. Vergleichen Sie beispielsweise die Rolle "Kunde" mit den Benutzerrollen "Gelegentlicher Kunde", "Webkunde", "Regelmäßiger Kunde" und "Erfahrener Kunde".

Jede Beschreibung einer Benutzerrolle enthält Details zur Rolle selbst und zu ihren Benutzern (den so genannten Rolleninhabern) und zur Umgebung. Dieser Ansatz kann in RUP übernommen werden, indem Akteure ausgewählt werden, die den Benutzerrollen entsprechen.

Szenarios, Anwendungsfälle und wichtige Anwendungsfälle

Die Begriffe Szenarios, Anwendungsfälle und wesentliche Anwendungsfälle weisen einen teilweise verwirrenden Grad von Überlappung auf und werden in unterschiedlichen Designansätzen verwendet, um etwas geringfügig Anderes zum Ausdruck zu bringen. In RUP bedeutet "Szenario" beispielsweise eine Anwendungsfallinstanz, d. h. einen speziellen "Pfad" durch die möglichen Basis- und Alternativabläufe. Häufig findet man jedoch Methoden im benutzerzentrierten und Benutzerschnittstellendesign, die Szenarios als Verwendungsstorys beschreiben, die wesentlich mehr Details als lediglich den Ereignisablauf enthalten. Obwohl diese zusätzlichen Informationen in späteren Designphasen irrelevant sein können, tragen sie zum Verständnis von Benutzern, Aufgaben und Umgebungen bei. Deshalb können Szenarios (beim Storyboarding und Rollenspiel) in der Disziplin Geschäftsmodellierung ausgiebig verwendet werden, wohingegen sich der Fokus in der Disziplin Anforderungen auf Anwendungsfälle verlagert.

Abbildung 3 zeigt die Art dieser Überlappung. Die obere Skala umfasst eine Reihe unterschiedlicher Faktoren, die gewöhnlich miteinander variieren. Wenn sich die Zielsetzung beispielsweise mehr in Richtung Anforderungen verschiebt, wird die Struktur gewöhnlich formaler. Wesentliche Anwendungsfälle werden rechts von den generischen Anwendungsfällen dargestellt, weil Benutzerrollen sie ein wenig spezifischer machen (siehe vorheriger Abschnitt) und weil sie eine formalere Struktur haben.

Im Begleittext beschriebene Abbildung

Abbildung 3: Überlappung der Konzepte von Szenarios und Anwendungsfällen im benutzerzentrierten Design

Die Unterschiede zwischen Systemanwendungsfällen und wichtigen Anwendungsfällen lassen sich am besten anhand von Beispielen veranschaulichen. Tabelle 5 zeigt einen Anwendungsfall aus der Veröffentlichung "Software for Use" von Constantine und Lockwood [CON99]:

Benutzeraktion Systemantwort
Karte einführen Magnetstreifen lesen
PIN anfordern
PIN eingeben PIN prüfen
Transaktionsauswahlmenü anzeigen
Taste drücken Kontomenü anzeigen
Taste drücken Betrag anfragen
Betrag eingeben Betrag anzeigen
Taste drücken Karte ausgeben
Karte nehmen Geld ausgeben
Geld entnehmen  

Tabelle 5: Generischer Anwendungsfall für Abheben von Bargeld an einem Geldautomaten

Dieses Beispiel zeigt detailliert die Abfolge der Ereignisse zwischen dem Akteur und dem System. Die vertikale Linie zwischen den beiden Spateln stellt die Benutzerschnittstelle dar. Obwohl Constantine und Lockwood diesen Stil für wesentliche Anwendungsfälle empfehlen, ist dieser spezielle Anwendungsfall kein wichtiger, weil er auf den syntaktischen Interaktionsdetails basiert. Hier wird gezeigt, wie die Interaktion stattfindet. Ein wichtiger Anwendungsfall konzentriert sich darauf, worum es bei der Interaktion geht (die Semantik). Tabelle 6 zeigt die essenzielle Version der Interaktion.

Benutzerabsicht Systemzuständigkeit
sich selbst identifizieren Identität prüfen
Auswahl anbieten
Auswahl Geld ausgeben
Geld entnehmen  

Tabelle 6: Wesentlicher Anwendungsfall für Abheben von Bargeld an einem Geldautomaten

Dieser Anwendungsfall erfasst das Wesentliche der Interaktion "Geld abheben". Die Überschriften Benutzeraktion und Systemantwort wurden durch Benutzerabsicht bzw. Systemzuständigkeit ersetzt, um die Verlagerung des Schwerpunkts zu veranschaulichen. Ein gutes Schnittstellendesign konzentriert sich auf Benutzerziele und -absichten. Diese bleiben in konventionellen Anwendungsfällen häufig verborgen. Wesentliche Anwendungsfälle sind besonders hilfreich in den folgenden Situationen:

  • Es gibt nur wenige Designeinschränkungen (beispielsweise gilt die implizierte Designeinschränkung für die Verwendung von Bankkarten hier nicht).
  • Das System wird möglicherweise erweitert, um andere Mittel der Identifizierung zuzulassen (z. B. eine Art sicheren Internetzugangs).
  • Es besteht der Wunsch, Anwendungsfälle ohne Designeinschränkungen zu erstellen, um sie unter Umständen in Projekten wiederverwenden zu können, in denen diese Einschränkungen nicht bestehen.

Wesentliche Anwendungsfälle haben jedoch auch ihre Nachteile. Ganz eindeutige Anwendungsfälle wie der in Tabelle 5 können ausgedehnte Debatten auslösen, wenn es darum geht, das Wesentliche herauszuarbeiten. Wird beispielsweise beim Einführen der Karte der Kunde oder das Konto identifiziert? Bei den meisten Geldautomaten ist letzteres der Fall, obwohl Constantine und Lockwood vorgezogen haben, diese Tatsache so zu interpretieren, dass der Kunde identifiziert wird. Dies mag angesichts neuerer Technologien wie Identifizierung durch Scannen der Netzhaut oder durch Fingerabdruck eine absichtliche Entscheidung, kann aber auch ein Versehen gewesen sein. Die Konsequenzen sind in diesem Fall, dass eine zusätzliche Auswahl von solchen Kunden getroffen werden muss, die mehrere Konten haben.

Eine weitere Schwierigkeit wesentlicher Anwendungsfälle ist die, dass sie nicht für die Prüfung durch Benutzer und andere Stakeholder geeignet sind, weil sie abstrakter Natur sind. Ein Teil dieses Problems ist darauf zurückzuführen, dass wesentliche Anwendungsfälle in eine konkrete Form mit Benutzeraktionen zurück übersetzt werden müssen. Dies kann getan werden, sobald ein Designmodell verfügbar ist, indem Szenarios geschrieben werden, die die Interaktion konkret beschreiben (ähnlich im Konzept wie eine Anwendungsfallrealisierung, obwohl es hier um die Interaktion zwischen Benutzer und System und nicht um interne Objektkollaboration geht).

Zusammenfassend gesagt, die Erstellung von wesentlichen Anwendungsfällen bietet sich in den folgenden Situationen nicht an:

  • Die Benutzerschnittstellentechnologien sind absichtlich mit vielen Einschränkungen belegt (z. B. das System muss Bankkarten akzeptieren).
  • Die Zeit, die Benutzer brauchen, um die abstrakteren Anwendungsfälle zu verstehen, steht in keinem Verhältnis zu den zu erwartenden Vorteilen.

Wesentliche Anwendungsfälle in RUP

RUP verweist nicht explizit auf wesentliche Anwendungsfälle, aber in der Aufgabe Benutzerschnittstelle entwerfen werden wesentliche Anwendungsfälle als Ausgangspunkt verwendet, die dann mit Anforderungen an die Benutzerfreundlichkeit entwickelt und erweitert werden, um Storyboards zu erstellen (siehe Richtlinie: Storyboard).  

Alle Design- bzw. aktuellen Implementierungsdetails werden entfernt, so dass nur die Semantik, d. h. die Bedeutung der Interaktion, verbleibt. Anschließend werden verschiedene Designalternativen untersucht und dem wesentlichen Anwendungsfall als Typ der Realisierung syntaktische Details (wie findet die Interaktion statt) hinzugefügt. (Jedes alternative Design ist eine Realisierung desselben wesentlichen Anwendungsfalls.)

Storyboards können anschließend als Eingabe für die Aufgabe Prototyp der Benutzerschnittstelle erstellen verwendet werden, um den Benutzerschnittstellenprototyp zu entwickeln.