[IT kompakt] Usability Engineering kompakt ||

3. Aufl age

Michael Richter Markus Flückiger

Usability Engineering

Benutzbare Produkte gezielt entwickeln

IT kompakt

Werke der „kompakt-Reihe“ zu wichtigen Konzepten und Technologiender IT-Branche:

• ermöglichen einen raschen Einstieg,• bieten einen fundierten Überblick,• sind praxisorientiert, aktuell und immer ihren Preis wert.

Weitere Titel der Reihe siehe: http://www.springer.com/series/8297

http://www.springer.com/series/8297

Michael Richter · Markus D. Flückiger

Usability Engineeringkompakt

Benutzbare Produkte gezielt entwickeln

. Auflage

Michael RichterMarkus D. FlückigerZühlke Engineering AGSchlieren, Schweiz

ISSN: 2195-3651ISSN: 2195-366X (electronic)

ISBN 978-3-642-34831-0DOI 10.1007/978-3-642-34832-7

ISBN 978-3-642-34832-7 (eBook)

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deut-schen Nationalbibliografie; detaillierte bibliografische Daten sind im Internetüber http://dnb.d-nb.de abrufbar.

Springer Vieweg© Springer-Verlag Berlin Heidelberg 2007, 2010, 2013Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Je-de Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassenist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere fürVervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und dieEinspeicherung und Verarbeitung in elektronischen Systemen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungenusw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu derAnnahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutztwerden dürften.

Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier

Springer Vieweg ist eine Marke von Springer DE.Springer DE ist Teil der Fachverlagsgruppe Springer Science+Business Mediawww.springer-vieweg.de

http://www.springer-vieweg.de

Vorwort

Zur dritten Auflage

Damit hätten wir nicht gerechnet: Die zweite Auflage dieses Buches warin nicht einmal drei Jahren abverkauft – das ist ein großartiger Erfolg,der uns unglaublich freut!

Unser Usability Engineering kompakt geht nun in sein siebtes Lebens-jahr. Was hat sich in dieser Zeit eigentlich verändert? Anwendungspro-gramme sehen kaum anders aus, Fahrkartenautomaten haben nach wievor das Potenzial, uns frühzeitig altern zu lassen, und bei der Bedienlo-gik vieler neuer Produkte kapitulieren selbst gestandene Technik-Freaks.

Aber hat sich wirklich so wenig getan? Dieses Vorwort tippe ich ge-mütlich im Wohnzimmer liegend auf einem Tablet Computer. Wenn ichmöchte kann ich daran morgen unterwegs auf meinem Smartphone wei-terarbeiten. Ein kurzes Wischen über den Bildschirm bringt mich zu denNeuigkeiten einiger Freunde im Ausland. Und meine nächste Fahrkartemuss ich nun nicht mal mehr ausdrucken. Eine neue Generation mobilerGeräte und Technologien hat uns – gerade wegen ihren intuitiven Be-dienkonzepten – Anwendungsmöglichkeiten eröffnet, die wir uns nochvor wenigen Jahren nicht erträumt hätten.

Auch in der Entwicklung von Software und Produkten ist viel gesche-hen. Agile Vorgehensweisen versprechen schnelle Feedback-Zyklen undfokussieren auf den Mehrwert für die Benutzer.

V

VI Vorwort

In der dritten Auflage unseres Buches haben wir uns vor allem mit die-sen Neuerungen auseinandergesetzt. Und nicht zuletzt haben auch wirAutoren uns weiterentwickelt und in unseren Projekten neue Erkennt-nisse aus der Praxis gewonnen, so dass wir viele Stellen ergänzen undaktualisieren konnten.

Wir bedanken uns bei Ihnen als Leser für Ihr Interesse und die wert-vollen Rückmeldungen. Wir freuen uns auf viele weitere spannendeDiskussionen und anregende Inputs!

Zur zweiten Auflage

Beispiele spielen eine wichtige Rolle in unserer täglichen Kommuni-kation. Sie unterstützen das Lernen von Sachverhalten und schaffenein gemeinsames Verständnis. Beispiele sind auch nützliche Werkzeugein Software- oder Produktentwicklungsprojekten. Mit aussagekräftigenBeispielen können Informationen auf äußerst effiziente Weise von derAnalyse bis zur Implementierung transportiert werden. Usability-Metho-den nutzen diesen Sachverhalt. Sie bringen die Bedürfnisse der Benutzerin die Entwicklung ein, erlauben Feedback zu Lösungsvarianten und fo-kussieren auf die Realität der täglichen Anwendung von Produkten undSystemen, indem sie konkrete Beispiele verwenden.

In der zweiten Auflage dieses Buches möchten wir Ihnen eben-falls mehr Beispiele mitgeben. Ein ganzes Kapitel ist vier interessantenFallstudien aus der Praxis gewidmet, in denen wir benutzerorientierteVorgehensweisen und die Anwendung von Usability-Methoden in unter-schiedlichen Projekten beleuchten. Zudem haben wir viele Abschnitteüberarbeitet, aktualisiert und nach neusten Erkenntnissen erweitert.

Der Erfolg von Usability Engineering kompakt freut uns und zeigt,dass das Thema auch im deutschen Sprachraum auf großes Interessestößt. Wir bedanken uns an dieser Stelle herzlich bei Allen, die zu dervorliegenden zweiten Auflage beigetragen haben, insbesondere Christi-an, Hilmar, Jeannine, Médard, Olivier, Thomas und Thorsten.

Vorwort VII

Zur ersten Auflage

In unserer Tätigkeit als Berater werden wir immer wieder nach einer„kurzen Übersicht“ über das Thema Usability Engineering gefragt. Esbleibt uns jeweils nichts anderes übrig, als auf eine Reihe guter Fachbü-cher zu verweisen. Diese sind meist auf Englisch geschrieben und häufigmehrere hundert Seiten dick. Zudem haben wir den Eindruck, dass vie-le dieser Bücher für Usability-Fachpersonen selbst geschrieben wurdenund Methoden oder Prozesse im Detail behandeln, ohne eine Integrationin bestehende Software-Engineering-Vorgehensmodelle zu versuchen.

Dieses Buch richtet sich in erster Linie an Beteiligte im Software-Ent-wicklungsprozess – Produktverantwortliche, Projektleiter, Berater undAnalysten, die vor einer großen Herausforderung stehen: Software oderProdukte zu entwickeln, die gut benutzbar sind. Unser Ziel ist es, Ihneneine kompetente Übersicht zu verschaffen.

Was erwartet Sie in dieser Lektüre? Lassen Sie uns damit beginnen,was Sie in diesem Buch nicht finden werden:

• Regeln, deren Einhaltung gute Usability garantiert,• Eine Anleitung zur Durchführung von Usability-Methoden,• User-Interface-Richtlinien für Entwickler,• Theorie, die in der Praxis nicht anwendbar ist.

Sie werden hingegen Antworten zu folgenden Fragen finden:

• Wie viel Usability ist notwendig?• Wie passen Usability-Aktivitäten in den Entwicklungsprozess?• Wie plane ich Usability-Methoden ein und wie laufen sie ab?• Welche Resultate erhalte ich und wie kann ich diese kontrollieren?• Wie kann ich Benutzerorientierung im Unternehmen etablieren?• Welche verwandten Gebiete gibt es und wo finde ich weitere Informa-

tionen?

Wir hoffen, auch dem interessierten Laien eine leicht verständliche Ein-führung in die Materie zu vermitteln. Als Benutzer von technischenSystemen haben wir alle die Wahl: Entweder wir akzeptieren, was wirtäglich vorgesetzt bekommen, oder wir tun dies nicht. Natürlich könnenwir nicht in jedem Fall ein anderes System verwenden, wenn uns dies

VIII Vorwort

notwendig erscheint. Aber dann können wir zumindest versuchen, zu ei-ner Verbesserung beizutragen.

Unser Dank gilt der Firma Zühlke Engineering, die uns das Schreibendieses Buches ermöglichte, und allen Personen, die uns dabei mit vielZeit und Geduld geholfen haben: Andreas, Arun, Barbara, Calla, Chris-tian, Christian, Elisabeth, Jörg, Luana, Marco, Michael, Niko, Patrick,Peter, Rainer, Sandra und Toni.

Wir wünschen Ihnen viel Spaß beim Lesen!

Markus Flückiger und Michael Richter

Inhaltsverzeichnis

1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Wir alle sind Benutzer . . . . . . . . . . . . . . . . . . . . 11.2 Der Benutzer ist nicht wie ich . . . . . . . . . . . . . . . . 21.3 Was ist Usability Engineering? . . . . . . . . . . . . . . . 31.4 Ein Blick in die Vergangenheit . . . . . . . . . . . . . . . 9

2 Usability Engineering im Entwicklungsprozess . . . . . . . 132.1 Software Engineering: Die vergessenen Benutzer? . . . 132.2 Usability-Methoden im Zusammenhang . . . . . . . . . 19

3 Die 7 ± 2 wichtigsten Usability-Methoden . . . . . . . . . . 293.1 Facetten der Arbeit: Contextual Inquiry . . . . . . . . . . 303.2 Modellierte Realität: Personas und Szenarien . . . . . . 383.3 Einfach kommunizieren: Storyboards . . . . . . . . . . . 473.4 Kritzeln für Fortgeschrittene: UI Prototyping . . . . . . 523.5 In die Entwicklung tragen: Use Cases . . . . . . . . . . . 633.6 Usability Guidelines und Styleguides . . . . . . . . . . . 713.7 Auf dem Prüfstand: Usability Testing . . . . . . . . . . . 793.8 Zahlenmaterial: Fragebögen . . . . . . . . . . . . . . . . . 87

4 Usability im Griff: Planung . . . . . . . . . . . . . . . . . . . . 974.1 Ziele erreichen . . . . . . . . . . . . . . . . . . . . . . . . . 974.2 Risiken kontrollieren . . . . . . . . . . . . . . . . . . . . . 994.3 Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . 1004.4 Planungsbeispiele . . . . . . . . . . . . . . . . . . . . . . . 1004.5 Einsatz von Benutzern . . . . . . . . . . . . . . . . . . . . 107

IX

X Inhaltsverzeichnis

4.6 Schwierige Situationen . . . . . . . . . . . . . . . . . . . . 1094.7 „Karl ist zuständig“ . . . . . . . . . . . . . . . . . . . . . . 113

5 Strategische Usability . . . . . . . . . . . . . . . . . . . . . . . 1175.1 Usability unternehmensweit . . . . . . . . . . . . . . . . . 1175.2 Aufbau eines benutzerorientierten Prozesses . . . . . . . 1195.3 Usability-Standardisierung . . . . . . . . . . . . . . . . . . 1215.4 Usability-Institutionalisierung . . . . . . . . . . . . . . . . 1245.5 Wie sieht es in Ihrem Unternehmen aus? . . . . . . . . . 126

6 That’s life: Beispiele aus der Praxis . . . . . . . . . . . . . . 1316.1 Fallstudie 1: Usability und Requirements Engineering

sorgen für gutes Klima . . . . . . . . . . . . . . . . . . . . 1316.2 Fallstudie 2: Usability Engineering von A bis Z . . . . . 1356.3 Fallstudie 3: User Centered Innovation – Simulierte

Realität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1406.4 Fallstudie 4: Gezielter Einsatz, große Wirkung . . . . . 144

7 Rückblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1497.1 Fragestellung: Zielgerichtet vorgehen . . . . . . . . . . . 1497.2 Kontext: Für die Realität entwerfen . . . . . . . . . . . . 1507.3 Partnerschaft: Benutzer konstruktiv einbeziehen . . . . 1517.4 Fakten interpretieren . . . . . . . . . . . . . . . . . . . . . 1517.5 Modellieren: Entwerfen und Feedback einholen . . . . 152

8 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1558.1 Accessibility . . . . . . . . . . . . . . . . . . . . . . . . . . 1558.2 User Experience (UX) . . . . . . . . . . . . . . . . . . . . 1568.3 Interaction Design . . . . . . . . . . . . . . . . . . . . . . . 1578.4 Security und Usability . . . . . . . . . . . . . . . . . . . . 1588.5 Web Usability . . . . . . . . . . . . . . . . . . . . . . . . . 1598.6 Mobile User Experience . . . . . . . . . . . . . . . . . . . 1608.7 Der allgegenwärtige Computer . . . . . . . . . . . . . . . 165

Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Sachverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

1Einführung

Der Weltraum – unendliche Weiten. Wir schreibendas Jahr 2200. Dies sind die Abenteuer desRaumschiffs Enterprise. Persönliches Logbuch desCaptains: Der Computer versteht einfach nicht,was ihm gesagt wird. Scotty versucht seit Tagen, dieBedienung des neuen Transporters in den Griff zubekommen, und unser Tricorder liefert immerdieselbe unverständliche Fehlermeldung . . .

1.1 Wir alle sind Benutzer

Ist Ihnen auch schon aufgefallen, dass im Fernsehen die Leute immermühelos mit der Technik klarkommen? Wir hingegen stolpern bei An-wendungsprogrammen, tippen falsche PIN-Codes ein, verlaufen uns inFlughäfen und verzweifeln an neuen Geräten. Im täglichen Kontakt mittechnischen Systemen haben wir uns alle schon eine Vorstellung davongemacht, was Usability bedeutet. Lassen Sie uns diese Einführung des-halb mit einigen Usability-Klassikern aus dem Alltag der Gegenwartbeginnen. Sicher sind auch Ihnen schon solche oder ähnliche Situationenmit gut oder schlecht benutzbaren technischen Systemen in Erinnerunggeblieben:

• Der Fahrkartenautomat, der immer gut funktionierte, bis zu dem Zeit-punkt, als Sie die Fahrkarte (mit Quittung) für den nächsten Tag lösenwollten.

1M. Richter, M.D. Flückiger, Usability Engineering kompakt, IT kompakt,DOI 10.1007/978-3-642-34832-7_1, © Springer-Verlag Berlin Heidelberg 2013

2 1 Einführung

• Der neue Harddisk-Videorekorder, der auf Knopfdruck das Fußball-spiel aufzeichnet, wenn der Pizza-Kurier klingelt. Oder war es eineTastenkombination? Und wo war noch mal die Anleitung?

• Die Leichtigkeit, mit der Sie Musik aus dem Internet herunterladen, inMusiklisten ordnen und auf Ihrem Smartphone überall hören können.

• Die Telefonrechnung, nachdem Sie mit dem neuen automatischenBuchungssystem endlich Ihre Kinotickets für die Abendvorstellungreserviert hatten.

Interaktive Produkte begleiten uns in unserem Alltag. Wahrscheinlich ge-hören auch Sie zu jenen Menschen, die sich längst damit abgefundenhaben, dass viele Systeme schlichtweg kaum zu benutzen, andere dage-gen hervorragend sind. Ist das Zufall? Welche Faktoren bestimmen, obwir mit einem Produkt sehr einfach, nur schwer oder gar nicht zum Zielkommen? Welche Möglichkeiten bieten sich, diese Faktoren bereits inder Entwicklung systematisch in den Griff zu bekommen? Mit diesenFragestellungen beschäftigt sich Usability Engineering.

1.2 Der Benutzer ist nicht wie ich

Bestimmt haben Sie schon einmal einen wichtigen Text geschrieben undden Entwurf jemand anderem zum Lesen gegeben. Sicher haben Sie dieErfahrung gemacht, wie wertvoll die Hinweise dieser anderen Personwaren. Sie selbst hatten sich über längere Zeit intensiv mit dem Themabefasst und waren deshalb nicht mehr in der Lage, sich in die Sicht einesaußenstehenden Lesers zu versetzen. Sie hätten den Text auch einfachalleine schreiben können, er wäre allerdings nicht so gut geworden wienach Einarbeitung des Feedbacks.

Die Entwicklung von Software oder interaktiven Produkten ist (inaller Regel) komplexer als das Verfassen eines Textes. Die Projektbetei-ligten sind vom Blickwinkel der späteren Anwender in zweierlei Hinsichtweit entfernt:

• Sie sind Spezialisten, die sich über längere Zeit mit der eingesetztenTechnologie befasst haben und die Sichtweise eines unbedarften Be-nutzers nicht mehr ohne Weiteres einnehmen können.

1.3 Was ist Usability Engineering? 3

• Sie sind bezüglich des Anwendungsgebietes, in dem die entwickel-te Lösung zum Einsatz kommt, oft Laien. Hier ist der Benutzer derExperte. Die Entwickler werden sich nicht umfänglich mit dem Fach-gebiet, den Konzepten und Begriffen und schon gar nicht mit denkonkreten Abläufen in der alltäglichen Anwendung vertraut machenkönnen.

In beiden Punkten ist die Perspektive der Benutzer notwendig, damit einebrauchbare Lösung entstehen kann. Usability Engineering befasst sichim Wesentlichen damit, wie die Benutzersicht systematisch in die Ent-wicklung einbezogen werden kann.

Hintergrund: PerspektivenübernahmeAls Perspektivenübernahme wird in der Psychologie die Fähigkeit bezeichnet, einebestimmte Gegebenheit aus der Sicht eines anderen zu verstehen. Die Fähigkeit derPerspektivenübernahme entwickelt sich im Kindesalter und wird im Verlauf des Le-bens individuell unterschiedlich stark ausgeprägt. Dabei spielt es nicht nur eine Rolle,ob man sich in die Lage eines anderen versetzen kann. Entscheidend ist auch, den Be-darf für eine Perspektivenübernahme zu erkennen, die Lage aus der Sicht des anderenzu analysieren und die daraus resultierenden Erkenntnisse anzuwenden.

1.3 Was ist Usability Engineering?

Alles sollte so einfach wie möglich gemacht werden, aber nicht einfacher.(Albert Einstein)

Der Begriff Usability

Noch vor zwei Jahrzehnten war Usability als Begriff, zumindest imdeutschen Sprachraum, weitgehend unbekannt. Eine eher kleine Fach-gemeinde von „Software-Ergonomen“ befasste sich mit der „Gebrauchs-tauglichkeit“ bei der Verwendung von interaktiven Systemen. Für unvor-eingenommene Ohren müssen diese Bezeichnungen klingen, als wärensie dem Labor einer Forschungseinrichtung entwichen. Auch der etwasgeläufigere Ausdruck „Benutzerfreundlichkeit“ ist nicht ganz befriedi-gend, da der Grad der Freundlichkeit eines Systems gegenüber demBenutzer ein eher diffuses Konzept darstellt. Die „Benutzbarkeit“ eines

4 1 Einführung

Systems ist eindeutiger und scheint uns im Sinne der Allgemeinverständ-lichkeit die treffendste Übersetzung. Usability hat sich inzwischen aberauch im deutschen Sprachraum als Begriff in der alltäglichen Konver-sation, in den Medien oder auf Produktbeschreibungen etabliert. Immerhäufiger ist der Begriff User Experience anzutreffen, der auf das Gesam-terlebnis des Benutzers mit einem Produkt abzielt (siehe Abschn. 8.2).Wir verwenden die genannten Bezeichnungen in diesem Buch weitge-hend gleichbedeutend.

Usability – mehr als die Qualität der Benutzeroberfläche

Es gibt viele Definitionen, was Usability ist, und wir wollen an die-ser Stelle auch keine weiteren formal korrekten und allgemeingültigenKonzepte postulieren. Für die Einbettung dieses Buches ist eine Begriffs-bestimmung indessen notwendig.

Usability wird manchmal im engeren Sinne als Gütekriterium fürdie Gestaltung einer Benutzeroberfläche verstanden. Qualitätskriteriensind etwa die Anordnung von Bedienelementen, die Anzahl notwendi-ger Klicks oder die Verständlichkeit der angezeigten Bezeichnungen undDialoge.

Hinter dem Begriff verbirgt sich jedoch mehr. Die Benutzbarkeiteines Systems muss im Kontext seiner Verwendung beurteilt werden.Software-Anwendungen oder Produkte weisen eine hohe Usability auf,wenn sie von den vorgesehenen Benutzern einfach erlernt und effizientverwendet werden können und diese damit ihre beabsichtigten Ziele undAufgaben zufriedenstellend ausführen können.

Ein gutes Beispiel, um den Unterschied zwischen engerem und wei-terem Verständnis von Usability zu verdeutlichen, ist der große Erfolgvon Kurznachrichten (SMS) mit dem Aufkommen von Mobiltelefonen.Niemand wird bestreiten, dass die rein numerischen Tastaturen dieserGeräte eigentlich nicht für die Erfassung von Text vorgesehen waren.Viele Benutzer empfanden die Erstellung von Nachrichten damit sogarals ziemlich umständlich. Die Benutzerschnittstelle im engeren Sinnewar für sie nicht optimal. Betrachtet man die gesamte Anwendung, botsie hingegen genau das, was der Benutzer eigentlich wollte: Kurze Nach-richten konnten auf einfache und effiziente Weise übermittelt werden.


Benutzer

Umfeld

Aufgabe

Werkzeug

Abb. 1.1 Usability steht dafür, wie gut Benutzer ein Werkzeug in ihrem Umfeld zurBewältigung ihrer Aufgaben einsetzen können

Das Ziel des Benutzers wurde vom System gut unterstützt. Mit anderenWorten, die Anwendung insgesamt wies eine gute Usability auf. DiesesBeispiel verdeutlicht, dass die Betrachtung der Benutzeroberfläche al-leine zu kurz greifen würde. Abbildung 1.1 zeigt die vier prinzipiellenKomponenten eines Mensch-Maschine-Systems.

Eine Definition von Usability in diesem weiteren Sinne wurde in einerISO-Norm festgelegt. Diese Definition wird oft zitiert, und Sie sollten siedeshalb kennen. Die ISO-Norm 9241-11 definiert Gebrauchstauglichkeitals „das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einembestimmten Nutzungskontext genutzt werden kann, um bestimmte Zie-le effektiv, effizient und zufriedenstellend zu erreichen.“ [DIN EN ISO9241-11, 1998].

Aus dieser Definition lässt sich ableiten, dass die verbreitete Ansicht,Usability sei ausschließlich eine Eigenschaft eines Produktes, falschist. Um das an einem sehr einfachen Beispiel zu verdeutlichen: DieUsability eines Hammers zum Einschlagen von Nägeln kann gut sein.Doch sie wird ziemlich schlecht ausfallen, wenn Ihre Aufgabe darinbesteht, Schrauben einzudrehen. Entsprechend muss das zu erstellen-

6 1 Einführung

Abb. 1.2 Für die Opti-mierung der Benutzbarkeitmüssen nebst der Benutzer-schnittstelle weitere Ebenenwie zum Beispiel Ziele undFunktionalität des Produktseinbezogen werden

Ziele,Abläufe,

Anwendung

Struktur,Informationen,Funktionalität

GestaltungBenutzer-oberfläche

de Produkt in die Welt der Benutzer eingepasst werden. Abbildung 1.2veranschaulicht, dass bei der Betrachtung der Usability verschiedeneEbenen berücksichtigt werden müssen, die aufeinander aufbauen.

Für die Erstellung einer benutzbaren Lösung heißt das, dass dieOptimierung der Benutzeroberfläche allein nicht ausreicht. FolgendeAufgaben sind essenziell (mehr dazu finden Sie im Abschn. 2.2):

• Analyse der Benutzer, ihrer Aufgaben und des Anwendungskontexts,• Festlegen des Funktionsumfangs und der benötigten Informationen,• Erarbeitung der optimalen Abläufe und Prozesse.

In diesem Zusammenhang werden wir in diesem Buch öfter auf Prozesseoder Abläufe aus Benutzersicht zu sprechen kommen, um den zeitli-chen Aspekt von Interaktionen zu verdeutlichen. Stellen Sie sich dieBenutzung eines Systems vereinfacht als Schritte in einer bestimmten,wiederkehrenden Abfolge vor, die zum Ziel führen. Wahrscheinlich gibtes nicht nur eine, sondern mehrere solche Abfolgen. Aus Benutzersichtkönnen die gewünschten Abläufe mehr oder weniger gut mit dem Sys-tem ausgeführt werden. Usability umfasst die Eignung eines Systems,die Abläufe und Prozesse aus Benutzersicht zu unterstützen.


Usability Engineering: Reduktion auf das Wesentliche

Usability Engineering umfasst Mittel und Techniken, um bei der Ent-wicklung neuer Software oder Produkte die angestrebte Benutzbarkeitzu erreichen. Dies beinhaltet die Fragestellung, wer die genaue Benut-zergruppe ist, die Analyse der Arbeitsabläufe sowie die Festlegung deridealen Funktionalität und Konzeption einer passenden Benutzerschnitt-stelle.

Eine wesentliche Aufgabe von Usability Engineering ist es, unnötigeKomplexität zu vermeiden und die Funktionalität eines Produktes auf einfür den Benutzer ideales Minimum zu reduzieren. Das technische Systemsoll den Anwender in der Ausführung seiner Ziele optimal unterstützenund wird genau dafür konzipiert. Diese Reduktion auf das Wesentlichekommt nicht von selbst und Personen mit den entsprechenden Fähig-keiten müssen im Projektteam sein. Der Aufwand zahlt sich allerdingsbereits in der Realisierung aus.

DenkanstoßStellen Sie sich einen Toaster vor, der gleichzeitig Spiegeleier bratenkann. Welche Zielgruppen erreichen Sie mit diesem Produkt:

a.) Toast-Liebhaberb.) Spiegeleier-Liebhaberc.) Beide Zielgruppen: Sowohl Toast- als auch Spiegeleier-Liebhaberd.) Die Schnittmenge: Jene Leute, die bevorzugt Toast zusammen mit

Spiegelei zum Frühstück genießen.

Bonusfrage: Wie wird idealerweise die Dauer der Toast-Zeit auf dieDauer der Spiegelei-Bratzeit abgestimmt?

Der obige Denkanstoß soll einen weiteren Aspekt verdeutlichen: Pro-dukte werden häufig mit vielen Features ausgestattet, um möglichst vieleKäufer anzusprechen. Mehr Funktionsvielfalt muss aber in der Regeldurch eine höhere Komplexität in der Bedienung erkauft werden. Diesezusätzliche Komplexität darf den Nutzen aus Benutzersicht nicht über-schreiten, andernfalls akzeptieren die Benutzer das Produkt nicht oderweichen auf Konkurrenzprodukte aus. Die Zielgruppe der potenziel-len Benutzer wird damit nicht größer, sondern kleiner. Konsequentes

8 1 Einführung

Usability Engineering zeigt solche Zielkonflikte schon zu Beginn derProduktentwicklung auf. Vergleichen Sie dazu auch die Fallstudie in Ab-schn. 6.3.

Anwendungsgebiete für Usability Engineering

Gute Usability spielt überall dort eine Rolle, wo Benutzer mit interakti-ven technischen Systemen zu tun haben und damit in irgendeiner Formeine Benutzerschnittstelle zum Einsatz kommt. Dies umfasst Softwaream Arbeitsplatz ebenso wie Produkte, die in der Freizeit verwendet wer-den. Der Fokus liegt auf Systemen mit grafischer Benutzeroberfläche(GUI), doch auch Sprachdialoge oder physische Bedienelemente könnenbezüglich Usability optimiert werden.

Die Entwicklung der Benutzerschnittstelle wird ein zunehmend wich-tiger Bestandteil im Software Engineering. Das in diesem Buch be-schriebene Vorgehen fokussiert auf die Entwicklung von Software-Anwendungen sowie Produkten mit softwarebasierten Benutzerschnitt-stellen. Aufgrund der vielen Freiheitsgrade und der Komplexität, diemoderne Software-Entwicklungen beinhalten, sehen wir hier die größ-te Wirkung für benutzerorientierte Vorgehensweisen. Die vorgestelltenMethoden und Prinzipien lassen sich jedoch ohne Weiteres auch für dieOptimierung von Hardware-Produkten, Dienstleistungsangeboten oderArbeitsprozessen im weiteren Sinne anwenden. Mehr dazu finden Sieim Abschn. 8.2 zu „User Experience“.

Symptome für ungenügende Usability

DenkanstoßEntwickelt Ihr Unternehmen selbst Software oder Produkte? Wie stel-len Sie heute sicher, dass Ihre Produkte gut benutzbar sind? Sind Siezufrieden mit der erreichten Usability?

Der obige Denkanstoß klingt banal. Doch woher wissen Sie, wie gut dieBenutzbarkeit Ihrer Produkte ist? Haben Sie entsprechende Rückmel-dungen oder haben Sie diese gemessen? Es ist nicht immer ganz einfach,

1.4 Ein Blick in die Vergangenheit 9

die Symptome schlechter Usability auf die Ursache zurückzuführen. Ent-sprechend verstärkt man unter Umständen den Marketingaufwand, stattUsability-Maßnahmen zu ergreifen. Die folgende Liste zeigt einige Sym-ptome, die von ungenügender Usability herrühren können:

• Die Mitarbeiter arbeiten mit den Systemen nicht so schnell wie er-hofft.

• Die Einarbeitung und die Schulung von Benutzern nimmt viel Zeit inAnspruch.

• Die Qualität der geleisteten Arbeit sinkt merklich.• Die Hotline ist überlastet.• Mitarbeiter minimieren die Tätigkeit am System. Arbeitsschritte wer-

den auf andere Art und Weise gelöst.• Prozessvorgaben werden umgangen und Sicherheitsmaßnahmen

ignoriert.• Es gibt immer wieder Fälle, in welchen „Benutzerfehler“ die Ursache

von Schäden (Unfälle, Datenverluste, kommerzielle Schäden) sind.

1.4 Ein Blick in die Vergangenheit

Um Usability Engineering als Fachdisziplin einzuordnen, lohnt sich einBlick zurück. Ohne Anspruch auf einen vollständigen geschichtlichenAbriss möchten wir hier einige Meilensteine und Personen aufführen,die maßgeblich zur Entstehung und Verbreitung des Gebietes beigetragenhaben:

• Im 15. Jahrhundert stellt Leonardo da Vinci die Kenntnis des Men-schen in den Mittelpunkt für die Entwicklung neuer Technologien.Sein Gedankengut sollte Wissenschaft und Technik nachhaltig beein-flussen.

• In den 40er-Jahren des letzten Jahrhunderts investiert vor allem dasamerikanische Militär in die Optimierung der Mensch-Maschine-Schnittstelle komplexer Systeme. Human Factors, das Fachgebietzur Erforschung menschlicher Einflussgrößen bei der Anwendungvon Technologien, entsteht.

• 1957 erscheint die erste Ausgabe der Fachzeitschrift Ergonomics,welche die internationale Verbreitung der Ergonomie als Wissen-

10 1 Einführung

schaft zur Erforschung der Beziehungen zwischen dem Menschen undseiner Arbeit auslöst.

• 1970 gründet Brian Shackel in England das ForschungsinstitutHUSAT (Human Sciences and Advanced Technology). Die Er-forschung der Kommunikation zwischen Mensch und Computer(Human Computer Interaction oder kurz HCI) wird zur anerkann-ten wissenschaftlichen Disziplin.

• Mitte der 1980er-Jahre erlebt die systematische Untersuchung derMensch-Computer-Interaktion durch die Disziplin der Software-Ergonomie mit der zunehmenden Verbreitung von Rechnern in derArbeitswelt einen Aufschwung. Insbesondere im deutschen Sprach-raum erscheint eine Fülle von Veröffentlichungen, die das Gebietprägen.

• 1988 veröffentlicht Donald Norman sein heute als Klassiker geltendesWerk The Psychology of Everyday Things [Norman 88]. Das Buchverdeutlicht auf eindrucksvolle Weise die Relevanz psychologischerFaktoren bei der Entwicklung von technischen Systemen.

• 1993 erscheint das Buch Usability Engineering von Jakob Nielsen[Nielsen 93]. Es beschreibt die Anwendung von Usability-Methodenin einem systematischen Prozess und gilt als Wegbereiter für benut-zerorientierte Vorgehensweisen.

• Im Internet-Boom Ende der 1990er-Jahre setzen viele Unternehmenauf das World Wide Web. Die Nachfrage für die Erstellung benutzer-freundlicher Websites und Anwendungen steigt explosionsartig. WebUsability wird zum Schlagwort.

• Im neuen Jahrtausend führt die zunehmende Digitalisierung von In-halten wie Musik, Foto, Video, die für jedermann erschwinglichenGeräte und Breitband-Verbindungen zu einer weiteren Veränderung.Der Computer wird zum Arbeits-, Kommunikations- und Unterhal-tungsmittel und damit zum Alltagsgegenstand. Web 2.0 und SocialMedia Plattformen führen zu mehr und schnellerem Austausch.Neue Technologien mit revolutionären Konzepten für die Mensch-Computer-Interaktion werden alltagstauglich und durchdringen denMarkt. Usability wird zum neuen Differenzierungsfaktor für Unter-nehmen und ihre Produkte.

• 2007 präsentiert Apple das iPhone. Das Gerät verfügt über bahn-brechende, intuitive Interaktionsmöglichkeiten und setzt einen neuen

1.4 Ein Blick in die Vergangenheit 11

Standard für die Benutzbarkeit mobiler Produkte und Anwendun-gen. Die damit verbundene Möglichkeit der Installation kleinererAnwendungen (Apps) auf mobilen Geräten wird breiten Bevölke-rungskreisen geläufig. Durch die Einfachheit der Benutzung läutet dasiPhone eine neue Ära der Informationstechnologie ein. Fortan verän-dern Smartphones, Tablet PCs und andere mobile Begleiter unserenAlltag. Die Mobile User Experience dieser Produkte und Anwen-dungen wird zu einem zunehmend wichtigen Thema (siehe auchAbschn. 8.6).

2Usability Engineeringim Entwicklungsprozess

Ein Vorgehen für Usability Engineering zu beschreiben, das auf all dieverschiedenen Situationen passt, die Sie antreffen werden, ist unsererAnsicht nach nicht möglich. Sie werden auch kein „Kochbuch“ für dieAnwendung von Usability-Methoden zu lesen bekommen. Die folgendenKapitel sollen vielmehr eine Hilfestellung geben, wie Usability Engi-neering in der Praxis der Software- und Produktentwicklung betriebenwerden kann, wie die wichtigsten Usability-Methoden grundsätzlich ab-laufen, wie sie eingeplant werden können und worauf Sie achten sollten.

Dieses Kapitel gibt eine Übersicht über den Zusammenhang derverschiedenen Usability-Methoden und deren Integration in gängigeSoftware-Entwicklungsprozesse. Im nächsten Kapitel werden die einzel-nen Methoden näher beschrieben.

2.1 Software Engineering:Die vergessenen Benutzer?

Software-Entwicklungsprozesse

Gemäß einer viel zitierten Studie der Standish Group sind unvollständi-ge Anforderungen und mangelnde Einbeziehung der Benutzer die zweiführenden Gründe, warum Software-Projekte scheitern [Standish Group1994–2010]. Aktuelle Vorgehensmodelle nehmen für sich in Anspruch,hier Abhilfe zu schaffen. Tätigkeiten im Bereich Anforderungsanalyse


14 2 Usability Engineering im Entwicklungsprozess

Tab. 2.1 Die sechs primären Software-Engineering-Disziplinen im Unified Process(Quelle: IBM Rational Unified Process®)

Geschäftsprozessmodellierung (Business Modeling)Anforderungsanalyse (Requirements)Analyse und Entwurf (Analysis & Design)Implementierung (Implementation)Test (Test)Auslieferung (Deployment)

und -management haben in den meisten neueren Prozessbeschreibungeneinen hohen Stellenwert.

Der Unified Process (RUP), ein etablierter Software-Entwicklungs-prozess, definiert beispielsweise Requirements als eine von sechs pri-mären Disziplinen im Software Engineering (siehe Tab. 2.1).

Die Disziplin Requirements umfasst jene Aktivitäten, bei denen esum das Erfassen, Dokumentieren und Verwalten von Anforderungen derverschiedenen Interessengruppen geht (siehe unter „Hintergrund: Re-quirements Engineering“). Als eine der wichtigsten Interessengruppensollten die Benutzer dabei eine zentrale Rolle spielen!

Agile Vorgehensweisen wie beispielsweise Scrum versprechen nochmehr Kommunikation und engere Feedbackzyklen zwischen allen an derSoftware-Entwicklung Beteiligten (siehe auch „Hintergrund: Agile Soft-ware-Entwicklung“).

Für Usability-Engineering-Aktivitäten sind in modernen Software-Entwicklungsprozessen somit einige wesentliche Rahmenbedingungenerfüllt:

• Die Bedürfnisse der Benutzer werden im Rahmen der Anforderungs-analyse erhoben.

• Die Anforderungen aus Benutzersicht werden modelliert und in dieEntwicklung getragen.

• Eine iterative Vorgehensweise erlaubt die ständige Überprüfung undVerfeinerung von Ergebnissen mit Kunden und Benutzern.

• Einige Best Practices aus dem Usability Engineering, wie User Inter-face Storyboards zur Darstellung von Dialogabläufen, Personas zur

2.1 Software Engineering: Die vergessenen Benutzer? 15

Charakterisierung der Benutzer und die Erstellung von GUI-Prototy-pen, werden in vielen Vorgehensbeschreibungen explizit erwähnt.

Es wäre somit zu erwarten, dass in Software-Projekten generell und inder Entwicklung von Benutzerschnittstellen im Speziellen eine systema-tische Einbeziehung der Benutzer und ihrer Anforderungen stattfindenmüsste.

Ist das Problem damit gelöst? Die Praxis spricht eine andere Sprache.In vielen Projekten wird das User Interface vom Entwickler alleine, ohnefremde Hilfe erstellt. Die späteren Benutzer werden selten einbezogen.

Ein Grund dafür mag in Folgendem liegen: Obwohl die Berücksich-tigung der Benutzeranforderungen in aktuellen Software-Engineering-Vorgehensmodellen als wichtig erachtet wird, fehlen für das tatsäch-liche Einbeziehen von „Endbenutzern“ entsprechende Methoden undTechniken weitgehend. Damit fehlen auch Erfahrungswerte für die Pro-jektplanung. Das Resultat ist, dass viele Projekte benutzerorientierteVorgehensweisen als optional oder als zusätzlichen Aufwand betrachtenund ohne entsprechende Aktivitäten vorgehen.

Hintergrund: Agile Software-EntwicklungIn agilen Vorgehensweisen wird die Entwicklung einer Software in kurze – im All-gemeinen zwei bis vier-wöchige – Abschnitte aufgebrochen. Diese Zyklen werdenIterationen genannt. Das Ergebnis jeder solchen Iteration ist ein realisiertes, getes-tetes und mit Kunden geprüftes Teilprodukt. Dieses kann – soweit es die zu diesemZeitpunkt umgesetzte Funktionalität erlaubt – potenziell verwendet werden.

Eine Iteration soll dabei insbesondere ein Lernprozess sein. Dazu legt das Teamzusammen mit Kunden fest, was genau entwickelt werden soll, realisiert und prüft dievereinbarte Software, reflektiert anschließend die Ergebnisse und das Vorgehen undleitet Verbesserungsmaßnahmen ein. So lernt ein Projektteam über das zu entwickeln-de Produkt, die eingesetzten Technologien und die Zusammenarbeit.

Agile Teams streben aus diesem Grund danach, die Spezifikation so zeitnahwie möglich mit der eigentlichen Entwicklung vorzunehmen und zwar im direk-ten Gespräch mit Kunden anstatt über Dokumente. So entsteht die Spezifikation ausdem entwickelten Teilprodukt, dem besseren Problemverständnis und der optimiertenZusammenarbeit. Ein Projektteam beurteilt immer wieder neu, wie mit den verblei-benden Ressourcen das bestmögliche Produkt realisiert werden kann.

Agile Prinzipien wurden im Manifest für agile Software-Entwicklung [Beck et al.01] festgehalten:

• Die Kommunikation zwischen allen Beteiligten – inklusive der späteren Benut-zer – wird über die Definition von Prozessen und Werkzeugen gestellt.


• Funktionierende Software wird als wichtiger erachtet als umfassende Dokumen-tation.

• Die Zusammenarbeit mit dem Kunden spielt eine wichtigere Rolle als Vertrags-verhandlungen.

• Die Reaktion auf Veränderungen steht über der Befolgung eines Plans.

Agile Vorgehensweisen verfolgen eine Philosophie, die sich stark an den menschli-chen Denkprozessen und der Zusammenarbeit im Team orientiert und versprechendamit eine höhere Produktivität bei der Softwareentwicklung. Mehr zu dieser Thema-tik finden Sie im Buch „Software entwickeln mit Verstand“ [Dirbach et al. 11].

Benutzerorientierte Modelle

Auf der anderen Seite existieren seit gut fünfzehn Jahren benutzer-orientierte Vorgehensmodelle, welche die Anwendung von Usability-Methoden im Entwicklungsprozess beschreiben. User Centered Design(UCD) beschäftigt sich damit, wie Benutzer systematisch in die Ent-wicklung von Systemen und Produkten einbezogen werden können. Andieser Stelle sei auf die hervorragenden, durchgängig benutzerorientier-ten Vorgehensbeschreibungen von namhaften Vertretern des Fachgebietsverwiesen:

• The Usability Engineering Lifecycle von Deborah Mayhew [May-hew 99] beschreibt den Zusammenhang von Usability-Methoden überden gesamten Lebenszyklus bei der Entwicklung einer neuen Lösung.Mayhew illustriert, wie aus Benutzeranforderungen konkrete Usabil-ity-Ziele abgeleitet und in User Interface Entwürfe umgesetzt werden,die wiederum mit Benutzern geprüft werden.

• Contextual Design von Hugh Beyer und Karen Holtzblatt [Beyer et al.98] ist ein benutzerzentrierter Design-Prozess. Er vertieft die Analyseder Benutzer und deren Umfeld und zeigt auf, wie die gewonnenenInformationen in die Entwicklung einfließen. Aus diesem Vorgehenstammt die Methode „Contextual Inquiry“ (vergleiche Abschn. 3.1).

• Goal Directed Design von Alan Cooper [Cooper et al. 10] beschreibteine Vorgehensweise, um Benutzeranforderungen zu modellieren undin ein passendes Interaktionsdesign umzusetzen. Cooper’s Ansatzorientiert sich bei der Gestaltung neuer Lösungen an den über-liegenden Zielen der Benutzer. Um die relevanten Eigenschaften und

2.1 Software Engineering: Die vergessenen Benutzer? 17

Benutzerorientierte Aktivitäten planen

Lösungsvorschlag erfüllt die Anforderungen

Nutzungskontext verstehen

und spezifizieren

Benutzeranforderungenspezifizieren

Lösungsvorschlägeerarbeiten

Lösungsvorschlägeevaluieren

Erforderliche Iterationendurchführen

Abb. 2.1 Die ISO-Norm 9241-210 definiert die Schritte, die für eine benutzerorien-tierte Gestaltung von interaktiven Systemen eingehalten werden müssen. Ein neuerLösungsvorschlag erfüllt die Anforderungen erst dann, wenn er erfolgreich mit Be-nutzern evaluiert wurde

Bedürfnisse der Benutzer darzustellen, hat Cooper die Verwendungprototypischer Benutzer (Personas) eingeführt (siehe Abschn. 3.2).

Ein Prozessmodell für die benutzerorientierte Gestaltung interakti-ver Systeme wurde sogar in einer ISO-Norm verankert [DIN EN ISO9241-210]. In Abb. 2.1 sind die wichtigsten Prozessschritte dargestellt.Eine genaue Beschreibung dieser Schritte ist in ISO 9241-210 enthalten.

Wer nach diesen Ansätzen vorgeht, wird bessere Software und Pro-dukte produzieren – kein Zweifel!

Eines ist indessen nicht von der Hand zu weisen: Eine Integra-tion in gängige Software-Entwicklungsprozesse fehlt weitgehend. Esentsteht unweigerlich das Gefühl, dass diese Ansätze als aufwändige,eigenständige Disziplinen gehandelt werden: „Vergesst eure alten Vor-gehensweisen und nehmt unseren Prozess“. Diese Abgrenzungshaltungmag dazu beitragen, dass Usability Engineering von Auftraggebern und


Projektbeteiligten oft als zeit- und kostenintensiver Zusatz zum beste-henden Vorgehen betrachtet wird.

Wenn Sie nun aber ein Projekt nach einem bestehenden Vorgehensmo-dell oder einem gegebenen Entwicklungsprozess abwickeln müssen, weilIhr Unternehmen dies vorschreibt oder weil Sie darin ganz einfach vielenützliche Hilfsmittel finden, wie können Sie benutzerorientierte Me-thoden integrieren? Sollen Sie nun Geschäftsprozessmodellierung oderBenutzerbeobachtungen in Auftrag geben, um die notwendigen Arbeits-schritte zu analysieren? Verwenden Sie besser Szenarien, User Storiesoder Use Cases für Ihre Spezifikation? Wann testen Sie Ihre neue Lösungam besten mit Benutzern – und mit wie vielen? Die folgenden Kapitelsollen Sie bei solchen und ähnlichen Fragen unterstützen.

Das Beste aus beiden statt zweiWelten

Die Erfahrung aus einer Vielzahl von Projekten hat uns gezeigt, dasssich Usability Engineering nahtlos in gängige Software und Produkt-Entwicklungsprozesse integrieren lässt und sich dadurch viele Vorteilebieten. So hat sich beispielsweise die Anwendung von Usability-Metho-den im Requirements Engineering in der Praxis als äußerst erfolgreicherwiesen. Erstens werden die Anforderungen der Benutzer systematischin die Analyse einbezogen und zweitens kann sichergestellt werden, dassdiese Anforderungen auch ihren Weg in die Realisierung finden. DasErgebnis ist eine Lösung, die sich an ihrem tatsächlichen Verwendungs-zweck ausrichtet.

Eine solche integrierte Sicht bedingt, dass Vorgehensbeschreibungennicht einfach unreflektiert angewendet werden, sondern dass die zugrun-de liegenden Prinzipien beider Welten verstanden und berücksichtigtwerden.

Hintergrund: Requirements EngineeringRequirements Engineering befasst sich damit, die Bedürfnisse der Benutzer, Auftrag-geber und weiterer Interessengruppen (Stakeholder) hinreichend aufzuarbeiten, zuverwalten und zu kommunizieren, damit das Projektteam eine passende Lösung er-stellen kann. Wesentlich für den Projekterfolg ist eine von allen Interessengruppenvereinbarte und getragene Zielvorstellung. Aufbauend darauf kann der Analyst dieRahmenbedingungen und Qualitätsanforderungen erarbeiten sowie den funktionalen

2.2 Usability-Methoden im Zusammenhang 19

Umfang und das Verhalten der neuen Lösung modellieren. Eine gute Übersicht überdie Thematik bietet das Buch „Systematisches Requirements Engineering“ [Ebert 10].

2.2 Usability-Methoden im Zusammenhang

Hinweis: Dieser Abschnitt zeigt die Integration von Usability-Methodenund gängigen Software-Engineering-Vorgehensweisen. Er ist als Über-sicht für den erfahrenen Leser gedacht. Dem Einsteiger in die Materieempfehlen wir, sich im folgenden Kapitel („Die 7 ± 2 wichtigsten Usa-bility-Methoden“) zunächst mit den einzelnen Methoden und Konzeptenvertraut zu machen.

Die Kernaufgaben in der Software- oder Produktentwicklung lassensich vereinfacht in fünf Bereiche zusammenfassen. Die Einteilung inAufgabenbereiche erleichtert das Verständnis von Ziel und Zweck dereingesetzten Methoden und der gewünschten Arbeitsergebnisse. Sie sindunabhängig vom eingesetzten Entwicklungsprozess. Abbildung 2.2 zeigtdiese Aufgabenbereiche in der Übersicht.

Jedem Aufgabenbereich kann ein Ziel im Sinne der Benutzerorientie-rung zugeordnet werden:

• Analyse: Benutzer und Kontext verstehen,• Modellieren: Entwurf und Optimierung einer passenden Lösung,• Spezifikation: Die Lösung in die Entwicklung tragen,• Realisierung: (Unterstützung bei der) Implementierung der Lösung,• Evaluation: Resultate mit Benutzern überprüfen.

Diese Aufgabenbereiche sind nicht im Sinne eines zeitlichen Ablaufszu verstehen. So kann es beispielsweise zielführend sein, zunächst eineEvaluation eines bestehenden Systems vorzunehmen, bevor die Model-lierung einer neuen Lösung angegangen wird. Oder es kann ein erstesModell erstellt werden, das der Analyse dient. In der Praxis werdendiese Aufgaben oft auch wiederholend (iterativ) oder sogar paralleldurchgeführt. In Kap. 4 werden diese zeitlichen Zusammenhänge näherbeschrieben.

Im Folgenden wird für jeden Aufgabenbereich aufgezeigt, welcheAnsätze und Methoden einerseits aus den Software-Engineering-Vorge-hensmodellen und andererseits aus benutzerorientierten Prozessmodel-


Abb. 2.2 PrinzipielleAufgabenbereiche bei derEntwicklung von Produktenund Systemen

len zur Verfügung stehen und wie diese in einem integrierten Vorgehenzusammenspielen. Die Details der einzelnen Usability-Methoden werdenim nächsten Kapitel beschrieben.

Aufgabenbereich 1: Analyse von Benutzern und Kontext

Am Anfang eines neuen Projekts steht das Team vor der Herausforde-rung, eine neue Lösung zu planen, von der er noch nicht genau wissenkann, wofür sie eingesetzt wird, was sie bieten soll und wer die Benutzersein werden.

In der Geschäftsprozessanalyse bzw. -modellierung (Business Ana-lysis, Business Modeling) werden die Prozesse des Unternehmens ana-lysiert, in welche die neue Lösung eingebettet werden soll. Dabei mussauch der Tatsache Rechnung getragen werden, dass sich diese Prozessein der Regel durch die Einführung der Lösung verändern. Abbildung 2.3illustriert einen Ausschnitt aus einem solchen Geschäftsprozess.

Es würde den Rahmen dieses Buches sprengen, die Tätigkeiten derAnalyse und Modellierung im Detail zu beschreiben. Wichtig ist an die-ser Stelle, dass die Geschäftsprozesse wesentliche Rahmenbedingungenfür die neue Lösung definieren, zum Beispiel, welche Stellen und Prozes-se im Unternehmen betroffen sind, welche Aufgaben und Tätigkeiten vondiesen Stellen ausgeführt werden und wie der offizielle Informationsfluss


Inves��ons-antrag erstellen

Uni

t Lei

ter

Mita

rbei

ter

Adm

in/F

inan

ceG

L Inves��on genehmigen

Inves��on genehmigen

[>= EUR

5000]

[< EUR 5000]

Bestellung erstellen

Bestellung freigeben

Bestellung freigeben

[< EUR 5000]

[>=

EUR

5000

]

Abb. 2.3 Modell eines Geschäftsprozesses am Beispiel einer Hardware-Beschaffung

und die Zusammenarbeit zwischen den verschiedenen Stellen stattfinden.Basierend auf diesen Informationen lässt sich aus Geschäftssicht definie-ren, für welche Aufgaben das neue System eingesetzt werden soll.

Neben den formellen Geschäftsprozessen ist ein fundiertes Verständ-nis über die Benutzer und die tatsächliche Anwendung der neuen Lösungim Geschäftsalltag eine notwendige Voraussetzung. Usability Enginee-ring komplettiert die formellen Prozesse aus der Geschäftsprozessmo-dellierung mit den konkreten Details der täglichen Arbeit und füllt dieabstrakten Unternehmens-Rollen mit den Eigenschaften und Möglich-keiten der Menschen dahinter.

Contextual Inquiry (siehe Abschn. 3.1) soll in diesem Buch alsstellvertretendes Beispiel für weitere Techniken stehen, die von Beob-achtungen über Interviews und moderierte Gesprächsgruppen (FocusGroups) bis zu strukturierten Aufgabenanalysen reichen. Das Ziel dieserMethoden ist es, die Bedürfnisse der Benutzer sowie die Hintergründezu verstehen. In Beobachtungen und Befragungen der Benutzer vor Ortwerden die konkreten Aufgaben, Abläufe und Verhaltensmuster sowiedie Umgebung der Anwendung analysiert, ausgewertet und dokumen-tiert. Die Resultate hält das Team in Form von grafischen Modellen odernatürlichsprachlichen Beschreibungen fest. Abbildung 2.4 zeigt das Er-gebnis einer solchen Untersuchung vor Ort zum Beschaffungsprozessaus Abb. 2.3.


FrankMitarbeiter

- bestellt Hardware

HansProjektleiter- macht das

Administra�ve

PhilippUnit Leiter

HannaGL Mitglied

- Unterschreibt Bestellung

1) Ich brauche Unterschri�

2) Es eilt!

3)

Lieferant

4) Bi�e liefern

in zwei TagenBestellung

Bestellung

Bestellung(unterschrieben)

Bestellung

(unterschrieben)

5) Das haben

wir bestellt ok?Kopie Bestellung

(unterschrieben)

Abb. 2.4 Darstellung als Informationsfluss (Flow Model) der im Kontext untersuch-ten Abläufe

Die Erarbeitung von Anforderungen der verschiedenen Interessen-gruppen ist eine zentrale Aufgabe im Requirements Engineering. DieAnalysetätigkeiten umfassen beispielsweise Interviews, moderierteWorkshops sowie die Analyse von Altsystemen und Dokumentatio-nen. Usability-Methoden dienen zur Erarbeitung von Anforderungenaus Benutzersicht und ergänzen damit die Techniken im RequirementsEngineering.

Im nächsten Kapitel werden diese Methoden und deren Einsatz zurErarbeitung und Prüfung der Benutzeranforderungen im Detail beschrie-ben.

Aufgabenbereich 2: Modellieren einer passenden Lösung

Selbst bei kleineren Anwendungen ist es praktisch unmöglich, auf An-hieb ein System zu entwerfen, das allen Anforderungen genügt. Es istnotwendig, das neue System aus verschiedenen Sichten zu modellie-ren und Schritt für Schritt zu präzisieren. In mehreren Zyklen werden


Entwürfe erstellt und Feedback eingeholt. Das Team modelliert bei-spielsweise die Einbettung in die Geschäftsprozesse, die Arbeitsweiseder Benutzer mit dem neuen System sowie die Funktionalität und dasVerhalten des Systems.

Die Erkenntnisse aus der Analyse von Benutzern und Kontext werdenin Personas und Szenarien umgesetzt (siehe Abschn. 3.2).

Personas stellen prototypische Benutzerprofile dar, während Szena-rien die Arbeit mit dem neuen System aus Benutzersicht beschreiben.Personas und Szenarien bringen die im Contextual Inquiry erarbeitetenErgebnisse auf den Punkt und dienen als Grundlage für die Entwicklung.

Personas und Szenarien liefern auch eine gute Basis für den Entwurfeines Use-Case-Modells oder User Stories (siehe Abschn. 3.5). Dabeiwird zuerst eine Übersicht über den funktionalen Umfang der neuen Lö-sung erarbeitet und in einem zweiten Schritt das Verhalten des Systemsgemäß den Qualitätsanforderungen und Rahmenbedingungen detailliert.Als Modellierungselemente dienen bei der Use-Case-Modellierung Ak-teure (Actors), die in Anwendungsfällen (Use Cases) mit dem Systeminteragieren.

Ein genaues Verständnis der Objekte und Daten des Fachbereichs,welche im System repräsentiert werden sollen, ist eine wichtige Voraus-setzung für die Erstellung der Benutzerschnittstelle. Diese Konzepte undZusammenhänge können in einem Domänenmodell abgebildet werden.Ein durchdachtes Domänenmodell ist hilfreich für die Erstellung der Be-nutzerschnittstelle. Es zeigt die angezeigten und einzugebenden Datenund deren Zusammenhänge auf. Abbildung 2.5 zeigt eine erste Versioneines solchen Domänenmodells sowie des entsprechenden GUIs.

Ein Glossar ist ein weiteres einfaches, aber wichtiges Hilfsmittel, umBegriffe zu definieren und ein gemeinsames Verständnis im Projekt zuerreichen.

Mit Storyboards (siehe Abschn. 3.3) hat ein Projektteam die Mög-lichkeit, Lösungsideen anschaulich darzustellen, um beispielsweiseFeedback von Benutzern und Führungskräften zu erhalten und neueTeammitglieder einzuführen. Storyboards visualisieren und detaillierendie Anwendung aus Benutzersicht, indem sie einen ersten Eindruck überdie Abläufe der Benutzerschnittstelle im vorgesehenen Kontext geben.

Um das Verhalten des Systems weiter zu verfeinern und die Ab-laufschritte aus Benutzersicht in Aktion darzustellen, werden im User


Bestellung

Antrag

Kostenstelle: Kostenstelle IDBezeichnung: TextGegenstand: TextBegründung: TextBudge�ert: Ja/NeinKosten (einmalig): BetragKosten (jährlich): Betrag

Ak�vität

Tä�gkeit: TextAusführender: PersonDatum erledigt: Datum

IT Equipment

Service Tag: Text

Workflow

*

ersetzt

betri�*

Antrag bearbeiten

Kostenstelle

Gegenstand

Begründung

Kosten

CHF

Bezeichnung

Budge�ert?

speichern abbrechen

Kosten / Jahr

CHF

Workflow:

Antrag einreichen

Inves��on freigeben

Genehmigung GL

Genehmigung Finance

*

*

Abb. 2.5 Ausschnitt eines Domänenmodells und entsprechendes GUI am Beispieleines Beschaffungsprozesses

Interface Prototyping (siehe Abschn. 3.4) erste Dialogschritte mit mög-lichst einfachen Mitteln umgesetzt und von ausgewählten Benutzernund weiteren Stakeholdern geprüft. Die so erstellten Prototypen vermit-teln den Beteiligten erstmals einen Eindruck der laufenden Anwendungund dienen als einfach verständliche und gemeinsame Sprache zwischenBenutzern, Auftraggebern und Entwicklern. Die in Anwendungsfällentextuell oder mit grafischen Modellen formulierten Anforderungen wer-den dadurch greifbar und vorstellbar. Dank der erhöhten Realitätsnähekommen bisher unentdeckte Anforderungen zum Vorschein. Ein wich-tiges Ergebnis ist das User-Interface-Konzept (siehe Abschn. 3.4 „DieBenutzerschnittstelle konzipieren“), das die Eckpunkte für das zu erstel-lende User Interface festlegt.

Aufgabenbereich 3: Spezifizieren für die Entwicklung

Wenn genügend Klarheit über die vorgesehene Lösung herrscht, wird daszu erstellende System für die Entwicklung spezifiziert. In sehr formellenProjekten legen Auftraggeber und Hersteller mit der Anforderungsspe-zifikation den fachlichen Inhalt für die Vertragserfüllung fest. Use-Case-


Spezifikationen beschreiben die funktionalen Abläufe des Systems (sieheAbschn. 3.5). Neben weiteren funktionalen Anforderungen werden auchalle Rahmenbedingungen aufgenommen (siehe Abschn. 3.5. „Funktio-nale und nicht-funktionale Anforderungen“). Die Anforderungen an dieneue Lösung werden üblicherweise in strukturierten Dokumenten oderauch in speziellen Werkzeugen festgehalten.

Zwischen den Tätigkeiten für das Modellieren der neuen Lösungund deren Spezifikation besteht ein fließender Übergang. Ausgewähl-te Ergebnisse aus der Modellierung dienen auch der Spezifikation. Sokönnen Szenarien, Storyboards oder UI-Prototypen auch Teil der An-forderungsspezifikation sein und wesentlich zur Verständlichkeit, Voll-ständigkeit und zur Präzisierung der Anforderungen für die Realisierungbeitragen. Die Spezifikation besteht schließlich aus einem Konglo-merat von formalen Anforderungsnotationen und natürlichsprachlichenBeschreibungen wie dem Use-Case-Modell, Use-Case-Spezifikationen,Ablaufdiagrammen, dem Domänenmodell, Anforderungssätzen, nicht-funktionalen Anforderungen und zusätzlichen Ergebnissen wie Story-boards und UI-Prototypen.

Agil geführte Projekte betonen die direkte Kommunikation. Die Spe-zifikation soll dabei das Resultat dieser Kommunikation sein und sozeitnah mit der Entwicklung wie möglich entstehen. Die Spezifikationkann also, so die Theorie, informeller ausfallen. Die anschaulichen Tech-niken des Usability Engineerings wie Mock-ups und Szenarien sind hierbesonders einfach einsetzbar (vgl. Abschn. 3.5 „User Stories“).

Aufgabenbereich 4: Unterstützung der Realisierung

Für die Realisierung der Lösung muss die Spezifikation in ein tech-nisches Design umgesetzt, eine Software-Architektur entworfen undimplementiert werden. Vorgehensmodelle in der Software- oder Produkt-entwicklung setzen oft hier ihren Schwerpunkt.

In der Realisierung unterstützen Usability Guidelines und Stylegui-des die Entwicklung und helfen, ein konsistentes und regelkonformesUser Interface Design zu erreichen (siehe Abschn. 3.6).

User-Interface-Prototypen bilden eine wertvolle Grundlage für dieEntwicklung (siehe Abschn. 3.4). Moderne Software-Entwicklungspro-


zesse und agile Vorgehensweisen unterstützen dabei einen iterativenProzess, bestehend aus der Erstellung von Lösungsvarianten und Ein-arbeiten von Feedback in kurzen Zyklen. Diese Denkhaltung lässt sichausgezeichnet mit benutzerorientierten Vorgehensweisen vereinbaren.

Aufgabenbereich 5: Evaluation der Resultate

Ein wesentlicher Aufgabenbereich einer benutzerorientierten Software-oder Produktentwicklung besteht darin, die erstellten Resultate mit Be-nutzern zu überprüfen und zu optimieren. Dabei kann es sich um bereitsrealisierte Teile des Systems oder um einen Prototypen handeln. Inter-essanterweise bieten die gängigen Software-Engineering-Vorgehensmo-delle hier relativ wenige Hilfsmittel an. Im Wesentlichen beschränken siesich auf formale Reviews, Stellungnahmen und Abnahmetests durch denAuftraggeber.

Hingegen gibt es zahlreiche Usability-Methoden zur Evaluation einesSystems. In einem formalen Usability-Test werden Benutzer in einemUsability Lab dabei beobachtet, wie sie mit einer neuen Anwendung odereinem Prototypen arbeiten (siehe Abschn. 3.7). Die Probleme werdendokumentiert und daraus Verbesserungsmaßnahmen erarbeitet. Usabil-ity-Tests können auch im Rahmen eines Abnahmetests zur Erfüllung derAnforderungen eingesetzt werden. Usability Walkthroughs sind weni-ger formal und eignen sich zur Überprüfung und Optimierung von erstenPrototypen früh im Prozess.

Mithilfe von Usability-Fragebögen (mehr dazu in Abschn. 3.8) kannvon einer größeren Anzahl von Benutzern Feedback zur Benutzbarkeiteiner neuen Lösung eingeholt werden.

Schließlich besteht die Möglichkeit, Benutzerschnittstellen anhandvon Checklisten oder durch Experten prüfen zu lassen.

Zusammenfassung der Methoden

Tabelle 2.2 zeigt die Integration der Methoden aus Software Enginee-ring und benutzerorientierten Prozessmodellen nochmals als Übersicht.


Die kursiv gedruckten Methoden werden im nächsten Kapitel näher be-schrieben.

Tab. 2.2 Gegenüberstellung gängiger Methoden aus Software Engineering und be-nutzerorientierten Vorgehensmodellen für jeden Aufgabenbereich

Aufgabenbereich SE-Vorgehensmodelle BenutzerorientierteProzessmodelle

Analyse Business Analysis Contextual InquiryBusiness Modeling BeobachtungenStakeholder-Interviews InterviewsModerierte Workshops Focus GroupsAnalyse von Altsystemen Aufgabenanalysen

FragebögenModellieren Business Modeling Personas und Szenarien

Use-Case-Modell StoryboardsUse Cases UI Prototyping, Mock-upsDomänenmodell User-Interface-KonzeptGlossarUser Stories

Spezifikation Use-Case-Modell SzenarienUse-Case-Spezifikationen StoryboardsNicht-funkt. Anforderungen UI-PrototypenAblaufdiagramme StyleguidesDomänenmodellAnforderungssätzeUser Stories

Realisierung Technisches Design Usability GuidelinesSW-Architektur StyleguidesImplementierung UI-Prototypen

Evaluation Formale Reviews Usability TestingStellungnahmen WalkthroughsFunktionales Testen FragebögenAbnahmetests Checklisten und Heuristiken

Experten-Reviews

3Die 7 ± 2 wichtigstenUsability-Methoden

Im vorigen Kapitel haben wir argumentiert, dass sich Usability Engi-neering nahtlos in bestehende Software-Engineering-Ansätze integrierenlässt, und Ihnen einige Methoden im Zusammenhang aufgezeigt. Indiesem Kapitel möchten wir Ihnen acht1 wichtige Usability-Methodennäher vorstellen. Wir sind davon überzeugt, dass diese Auswahl einemProjekt eine umfassende Werkzeugpalette zur Verfügung stellt, um inunterschiedlichen Situationen gezielt benutzbare Software entwickeln zukönnen. Tabelle 3.1 fasst diese acht Methoden und ihren primären Zweckzusammen.

1 Eine Randnotiz für den interessierten Leser: Bei der Zahl im Titel handelt es sichum nichts anderes als die oft zitierte „magische Zahl 7 ± 2“. Der Psychologe Geor-ge A. Miller veröffentlichte 1956 eine Studie über die Limitationen der menschlichenInformationsverarbeitung [Miller 56]. Das menschliche Gehirn ist demnach in der La-ge, im Durchschnitt maximal 5 bis 9 gleichwertige Sinnesreize zu beurteilen. DieseGrenze konnte durch verschiedene Experimente, unter anderem mit Tonhöhen, Laut-stärken, visuellen Stimuli usw., nachgewiesen werden. Dieselbe Zahl wurde auch inanderen Studien gefunden: 7 ± 2 entspricht etwa der Anzahl Informationen, die einMensch gleichzeitig im Kurzzeitgedächtnis behalten kann. 7 ± 2 ist die Anzahl Ob-jekte, welche die menschliche Aufmerksamkeit umfasst. Missverständnis, Zufall oderGesetzmäßigkeit? Auf jeden Fall galt die magische Zahl 7 ± 2 fortan als eine Art fun-damentale Konstante. In der Software-Ergonomie wird argumentiert, dass aufgrundder Limitationen der menschlichen Informationsverarbeitung eine effiziente Auswahlnur etwa 5 bis 9 gleichartige Elemente enthalten sollte.


30 3 Die 7 ± 2 wichtigsten Usability-Methoden

Tab. 3.1 Übersicht der wichtigsten Usability-Methoden

Methode Zweck

Contextual Inquiry Analyse der Benutzer und des Einsatzumfelds desneuen Systems

Personas und Szenarien Modellieren der unterschiedlichen Benutzergrup-pen und der Anwendung aus Benutzersicht

Storyboards Kommunizieren von ausgewählten Abläufen mitdem neuen System

User Interface Prototyping Klären der Anforderungen, Konzipieren und Opti-mieren der Benutzerschnittstelle

Use Cases und User Stories Funktionale Anforderungen in die Entwicklungtragen

Guidelines und Styleguides Definieren der GestaltungsrichtlinienUsability Testing Beurteilen des neuen Systems durch BenutzerFragebögen Sammeln aussagekräftiger Zahlen zur Analyse

von Benutzern und Kontext oder zur Beurteilungeines Systems oder Prototyps

3.1 Facetten der Arbeit: Contextual Inquiry

Es locken heiße Features, coole Technologien und verführerisches Spar-potenzial. Sie brauchen nur zuzugreifen. Scheinbar ist die seit überzwanzig Jahren akute Software-Krise nur eine Frage der richtigen Tech-nologie und heute dank Tablets, SOA und Cloud gelöst (ersetzen Sie dieAbkürzungen mit beliebigen Schlagworten der aktuellen IT-Marketing-Maschinerie).

Contextual Inquiry geht die Software-Krise nicht durch neue Tech-nologien an, sondern durch ein fundiertes Verständnis der künftigenBenutzer, ihren Tätigkeiten und Bedürfnisse. Contextual Inquiry lässtsich mit „Erhebung im Umfeld der Benutzer“ übersetzen. Der Analystuntersucht die Bedürfnisse der Anwender, indem er diese bei ihren Tä-tigkeiten beobachtet und sie dazu befragt.

3.1 Facetten der Arbeit: Contextual Inquiry 31

Von Beobachtung und Befragung zu BedürfnissenEine neue Software soll Versicherungsberater beim Erstellen von Offerten un-terstützen. Das Projektteam besucht die Benutzer, um die Arbeitsweise derBerater zu verstehen und eine passende Software zu erarbeiten. Besondersrelevant ist das eigentliche Beratungsgespräch, da die Software gemäß Pro-jektauftrag die Qualität der Beratung verbessern soll. Die Analysten nehmenan einigen Beratungsgesprächen teil. Sie beobachten das Gespräch und befra-gen zudem den Berater über den Verlauf. Die Beobachtung ermöglicht es denAnalysten, wichtige Informationen aufzunehmen, die in einer reinen Befra-gung nicht auftauchen würden. Die Analysten zeichnen im Detail auf, welcheInformationen tatsächlich relevant sind und wie die Berater daraus auf geeig-nete Versicherungsprodukte schließen. Die Analysten machen sich ebenfallsein Bild von einigen Software-Anwendungen, die von den Beratern eingesetztwerden, beispielsweise um Berechnungen durchzuführen, Informationen ab-zulegen, Briefe zu schreiben etc. Diese detaillierten Informationen erlaubenes dem Projektteam, ein zu den Aufgaben der Benutzer passendes System zuentwerfen.

Die psychologische Forschung bestätigt, dass Menschen viel Wissen, dassie in einer bestimmten Situation anwenden, nicht einfach abrufen kön-nen. In einem Interview ist solches Wissen nur schwer erfassbar. DieKombination von Beobachtung und Befragung ermöglicht einerseits, daswirkliche Geschehen im Detail zu erfassen, und andererseits, die Grün-de und Zusammenhänge dahinter zu durchleuchten. Diese Informationensind wertvoll, um den notwendigen Informationsgehalt, die Benutzerfüh-rung und die Funktionalität des geplanten Systems abzuleiten.

Fragestellung

Mit Contextual Inquiry sollen ausgewählte Fragestellungen beantwortetwerden. Lohnenswerte Fragen zielen auf den Einsatz und das Umfeldvon heute benutzten Produkten ab. Für die Weiterentwicklung eines Na-vigationsgerätes im Auto kann es beispielsweise aufschlussreich sein,wie die Rollenverteilung zwischen Beifahrer und Fahrer auf einer Ur-laubsreise ist.

Bevor ein Analyst mit Benutzern spricht, stellt sich das Projektteamdie Frage, was in Bezug auf das neue System wichtig zu wissen ist. Na-türlich ergeben sich auch Fragestellungen, die mit Contextual Inquirynicht beantwortet werden können: Beispielsweise wie viel ein Kunde


Kommunikation

Rollenteilung

Handlungsstrategien

Artefakte

Kultur

Physisches Umfeld

Vorgehen

Soziale Einflüsse

Abb. 3.1 In einer Contextual Inquiry werden unterschiedliche Aspekte beim Einsatzbestehender Produkte und Systeme untersucht, um den Kontext der geplanten neuenLösung detailliert zu beleuchten

für ein Produkt bezahlen würde (Marketing und Marktforschung), obeine bestimmte Technologie geeignet ist (Entwicklung) oder wie einGeschäftsprozess grundsätzlich ablaufen soll (Geschäftsprozessmodel-lierung).

Contextual Inquiry fokussiert auf die Tätigkeiten der späteren Benut-zer und das Umfeld der Anwendung. Abbildung 3.1 stellt fünf Sichtendar, die mit der Methode erfasst und dokumentiert werden können.

In kaum einem Umfeld ist der gesamte Nutzungskontext in nur einerInterviewrunde erfassbar. Die Erfahrung zeigt, dass die Fragestellun-gen zu Beginn breit und unscharf sind. Im Verlauf des Projektes kenntdas Analyseteam den Kontext immer besser, und die Fragestellung wirdkonkreter und enger gefasst. Es lohnt sich deshalb, mehrere Iterationendurchzuführen. Die Resultate befruchten jeweils die Fragestellung dernächsten Iteration.

Im Kontext untersuchen

Mit einer ausgewählten Fragestellung stößt der Analyst gezielt in dieWelt der Benutzer vor. Die Auswahl der Interviewpartner muss nicht


Tab. 3.2 Fragestellungen, die in einer Contextual Inquiry untersucht werden können

Sicht Fragestellung

Rollenteilung undKommunikation

Typische RollenverteilungenAufgaben und VerantwortlichkeitenKommunikationsmittelKommunikationszweck und InhalteVorteile und Probleme der Rollenteilung

Handlungsstrategienund Vorgehen

Ausführung von TätigkeitenUnterschiedliche VorgehensweisenStärken und SchwächenHäufigkeit, Frequenz, Intensität und Dauer der Durch-führungAusnahmesituationen und Fehler, Spezialfälle

Artefakte Bei der Arbeit benutzte Dokumente, Formulare, Werk-zeuge usw.Aufbau und InformationsgehaltVerwendungszweckAnpassung an individuelle BedürfnisseZweckentfremdete VerwendungVorteile und Probleme bei der Arbeit

Kulturelle undsoziale Einflüsse

Personen, die Einfluss nehmenWirkung von sozialem Druck, MachtausübungVerhaltensregelnZiele, Werte und VorliebenWidersprüchliche EinflüsseProbleme und Chancen auf kultureller Ebene

Physisches Umfeld Raumaufteilung, ArbeitsplatzgestaltungVerfügbare HilfsmittelWege und DistanzenEinfluss auf KommunikationVerbesserungspotenzial

repräsentativ im Sinne der Statistik sein, doch sie sollte ein breites Spek-trum an Meinungen und Bedürfnissen abdecken. Es lohnt sich, auf einegewisse Streuung bezüglich Alter, Geschlecht, Position, Arbeitsort, Er-fahrung, Fachwissen, kulturellem Hintergrund und mehr zu achten.


Die Untersuchung findet vor Ort und während der Arbeit statt. DerAnalyst beobachtet den Interviewpartner und stellt gezielt Fragen überdas Beobachtete. Der Interviewpartner soll die eigene Handlungsweisereflektieren und so angewandtes Expertenwissen aufdecken.

Um dies zu erreichen, ist eine partnerschaftliche Haltung des Analys-ten notwendig. Der Interviewpartner sollte den Beobachter instruieren,damit dieser die Aufgabe verstehen und nachvollziehen kann – und nichtumgekehrt. Für diesen Zweck hat sich die Technik des Apprenticingetabliert, eine Art Rollenspiel, bei dem der Analyst die Rolle eines Aus-zubildenden einnimmt.

Der Analyst und der Interviewpartner diskutieren, ausgehend voneiner gerade vorgeführten Arbeitstätigkeit, über Probleme, fachlicheZusammenhänge und Verbesserungsmöglichkeiten. Der Analyst sam-melt alles, was im Interview diskutiert wird: ausgefüllte Formulare,Screenshots, Skizzen über interessante fachliche Zusammenhänge, Au-dioaufnahmen von Gesprächen und mehr.

Bei neuartigen Produktentwicklungen sollten erste Entwürfe, Proto-typen oder existierende vergleichbare Produkte in die Interviews ein-bezogen werden. Je näher die Erhebungssituation an die Realität dergeplanten Anwendung heranreicht und je lebensechter der Kontext dieserAnwendung vermittelt werden kann, desto wertvoller sind die Rückmel-dungen der Benutzer.

Analysieren der gesammelten Daten

Die Analyse basiert auf den gesammelten Unterlagen, Notizen, Skizzen,Video- und Audioaufnahmen. Es ist von Vorteil, in einem Team aus Ana-lysten und Entwicklern zu arbeiten: Analysten stellen sich andere Fragenund suchen nach anderen Lösungsansätzen als Entwickler. Entwicklerlernen dabei insbesondere das Arbeitsumfeld kennen. Das Team extra-hiert die folgenden Informationen:

• Ziele und Bedürfnisse der befragten Personen sowie deren Probleme,Werte und Eigenheiten: In Abschn. 3.2 zeigen wir, wie das Team dar-aus mittels Personas das Zielpublikum charakterisiert.


Abb. 3.2 Ein Affinitätsdiagramm führt zu einem aktiven Austausch der Teilnehmerbei der Analyse von qualitativen Daten

• Aufgaben, Abläufe und Tätigkeiten: Diese Informationen dienen alsGrundlage für die Beschreibung der künftigen Abläufe mit dem neuenSystem.

• Schwierigkeiten und erprobte Lösungsansätze der Benutzer mit heu-tigen Werkzeugen: Diese Informationen schärfen den Blick für diewesentlichen Bedürfnisse der Benutzer und die dazu passenden Funk-tionen.

• Begriffe und Informationen zum Fachbereich: Ein genaues Verständ-nis der Objekte und Daten des Arbeitsumfelds ist für die Gestaltungeiner neuen Lösung unverzichtbar. In der Software-Entwicklung ist esgeläufig, solche Zusammenhänge in einem Domänenmodell abzubil-den. Eine Contextual Inquiry liefert dafür hervorragende Grundlagen.Das Team wird hier vor allem in gesammelten Formularen und Doku-menten sowie bestehenden Software-Anwendungen fündig.

Abbildung 3.2 zeigt eine effektive Art der Auswertung vieler Daten.Das Team hält relevante Beobachtungen und Erkenntnisse auf Kärtchenfest. In einem Auswertungsworkshop werden diese Kärtchen gemeinsam


EinsatzleiterFeuerwehr

- Situation abklären- Wagen einsetzen

Koordinator- Einsatzteam aufbieten- Feuerwehr alarmieren

- informieren

Leiter Einsatzteam- Leitung Team vor Ort

- Koordinator informieren

11:1

5 Alar

mKo

ntak

t zum

Eins

atzte

am

11:04 Einsatz in Talhausen,

Brandgefahr

11:15 angekommen,

schwarzer Rauch

Wesentliche Infos zur

Situation vor Ort fehlen

(Öl, Chemi-kalien?)

Leiter Einsatzteam nicht erreichbar

(während 4 Minuten)

11:19 Details

zur Situation

Abb. 3.3 Darstellung der Kommunikation während eines Störungsfalls in einemInformationsflussmodell (Flow Model). Es zeigt die komplexe Kommunikation zwi-schen den Beteiligten in allen Details und weist auf Stärken und Schwächen hin

interpretiert, geordnet und daraus Schlüsse gezogen. Durch die Zusam-menarbeit und den aktiven Austausch der Teilnehmer verdichten sich dieErkenntnisse in einem mehrstufigen Prozess zu Anforderungen, die es imHinblick auf eine neue Lösung zu beachten gilt. Aufgrund der dabei ent-stehenden Gruppen von thematisch zusammenhängenden Kärtchen wirddiese Technik auch als Affinitätsdiagramm bezeichnet.

[Beyer et al. 98] beschreiben mit Contextual Design eine weiterfüh-rende Methodik, in welcher die Resultate aus einer Contextual Inquiryin grafischen Modellen festgehalten werden. Grafische Modelle eignensich gut zur Verdeutlichung der fünf Sichten des Kontexts und liefernwichtige Ansatzpunkte und Erkenntnisse für die Gestaltung einer neu-en Lösung. Zur Untersuchung von Störungsfällen kann beispielsweisedie Kommunikation zwischen den beteiligten Personen in einem In-formationsflussmodell aufgezeichnet werden. Abbildung 3.3 zeigt einenAusschnitt eines solchen Modells.


Geschäftsprozessmodellierung ergänzen

Contextual Inquiry ergänzt die Geschäftsprozessanalyse und -modellie-rung. Geschäftsprozesse geben die konsolidierten und standardisiertenAbläufe in einem Unternehmen wieder. Sie modellieren hingegen nichtdie Problemlösungsstrategien, die eine bestimmte Person anwendet, wel-che Abkürzungen und Optimierungen diese vornimmt und wie sie sichmit den Kollegen abspricht. Geschäftsprozesse sagen auch nichts überdas konkrete physische und kulturelle Umfeld aus, in der die Benut-zung stattfindet. Diese Lücke schließt Contextual Inquiry und bringt dieAspekte der täglichen Arbeit und der konkreten Anwendung der Ge-schäftsprozesse in ein Projekt hinein.

Innovation aus dem realen Leben

Innovation in einem Unternehmen entspringt unterschiedlichen Quellen:Neue und bessere Technologien ermöglichen neue Produkte und eröff-nen neue Geschäftsfelder. Durch die Optimierung der Geschäftsprozessewerden neue Wege aufgezeigt und das bestehende Potenzial einer Fir-ma besser ausgenutzt. Contextual Inquiry erschließt eine weitere Quellefür Innovation: Die Methode zeigt verbreitete Muster, erprobte Lösungs-ansätze und ungelöste Probleme in der Arbeitswelt auf – Faktoren, diePotenzial für wirklich nützliche Produkte bieten, welche die Benutzerdirekt ansprechen.

Darauf sollten Sie achten

• Niemand wird gerne bei der Arbeit beobachtet, wenn nicht klar ist,wozu die Analyse dient. Nur eine transparente, offene, interessierteund partnerschaftliche Haltung führt zum Ziel.

• Behalten Sie während der Analyse die ausgewählte Fragestellung imAuge. So manches Projektteam hat sich schon in der Unzahl der In-formationen in der Analyse verloren.


• Halten Sie auch fest, worauf Ihre Erkenntnisse zurückzuführen sind.Irgendwann kommt ein Auftraggeber und will wissen, weshalb einbestimmtes Feature eingebaut wurde.

In Kürze

Methode Contextual Inquiry

Resultate Fundiertes Wissen über Benutzer und KontextOptimierungspotenzial erkannt und abschätzbarGrundlage zur Beurteilung der NützlichkeitAnforderungen aus dem Nutzungskontext bekannt

Vorgehen Benutzer und ihre Tätigkeiten während der Arbeit be-obachten und befragen. Iterationen anhand der offenenFragen steuern. Optimierungspotenzial identifizierenund Lösungsideen protokollieren.

Aufwand Hängt stark von der Komplexität des Projekts ab.[PT = Personentage] Klein: 1 Iteration, 1–2 Analysten, 3–6 Interviews: 3–12

PT.Mittel: 2 Iterationen, 2 Analysten, 6–12 Interviews:12–30 PT.Groß: mehrere Durchgänge à 2 Iterationen mit 3–5 Ana-lysten und jeweils 6–12 Interviews: 30 PT und mehr.

Beteiligte Analyst übernimmt die Führung, Entwickler und Pro-duktmanager arbeiten aktiv mit.

Planung Bei Projektinitialisierung; in den ersten Phasen desProjekts.

3.2 Modellierte Realität: Personas und Szenarien

Eine Versicherungsgesellschaft entwickelt ein Softwaresystem, um Schadens-meldungen und die daraufhin geleisteten Entschädigungen zu verwalten. In derSpezifikation erscheint der Akteur „Sachbearbeiter“ und als einer der wesent-lichen Anwendungsfälle „Schadensmeldung erfassen“. In einem Workshop,in dem ein erster Prototyp mit einigen Benutzern besprochen wird, verläuftdie Diskussion etwas hitzig: Während ein Sachbearbeiter den Vorschlag ganzgut findet, da alle notwendigen Informationen übersichtlich dargestellt seien,

3.2 Modellierte Realität: Personas und Szenarien 39

stöhnt ein anderer über die vielen Eingabefelder und Abhängigkeiten. Es stelltsich heraus, dass der Erste das bestehende System täglich benutzt und vieleFälle erfasst, während der andere nur einige Male pro Monat Daten für wenigeSpezialfälle eingibt und deshalb viele der Funktionen gar nicht benötigt. DerPrototyp erfüllt offenbar nur die Anforderungen des ersten Benutzers, nichtaber jene des zweiten.

Dieser Abschnitt befasst sich mit der Methode Personas und Szenarien.Es handelt sich dabei um zwei Instrumente, um die unterschiedlichenBedürfnisse der Benutzer zu modellieren und daraus passende Lösungenabzuleiten.

Personas

Personas stellen prototypische Benutzer dar und verkörpern ihre unter-schiedlichen Ziele, Verhaltensweisen und Eigenschaften, die im Hinblickauf das zu entwickelnde Produkt relevant sind. Die Methodik wurdevom Interaktionsdesigner Alan Cooper eingeführt und publik gemacht[Cooper et al. 10]. Die Namensgebung leitet sich vom griechischen Thea-ter der Antike ab. Die Persona war eine Maske, welche die Rolle derSchauspieler typisierte und gleichzeitig als Schallverstärker diente – eintreffender Begriff, wie wir finden. Abbildung 3.4 zeigt ein Beispiel einerPersona.

Personas werden aufgrund von Informationen über die zukünftigenBenutzer eines Systems erarbeitet. Dazu dienen beispielsweise Ergeb-nisse aus Workshops mit Benutzern, Contextual Inquiries, Fragebögenoder Usability Walkthroughs mit bestehenden Systemen. Der Analystentwirft Vorschläge und validiert diese mit den Beteiligten, oder die Per-sonas werden in einem gemeinsamen Workshop erstellt. Eine Personasollte schließlich die für das Produktdesign relevanten Eigenschaften derBenutzer widerspiegeln.

Im obigen Beispiel könnten zwei Personas, nennen wir sie Jakob undNiklaus, für zwei unterschiedliche Benutzergruppen stehen. Jakob undNiklaus unterscheiden sich deutlich in ihren Zielen und arbeiten ganzunterschiedlich mit der Applikation. Während Jakob mehrere Fälle proTag bearbeitet und das heutige System sehr gut kennt, arbeitet Niklausnur gelegentlich am System für einzelne, komplexere Fälle.


Jakob

• arbeitet täglich mit dem heutigen System• behandelt viele Fälle direkt am Telefon• benutzt Headset und vor allem Tastatur• übergibt komplexe Fälle an Case Manager

„Der Zeitdruck ist gross. Man erwartet von mir, dass ich die Fälle in sieben Minuten erledige."

„Ich ärgere mich über die vielen überflüssigen Klicks, um zwischen den Daten zu navigieren. Warum kann ich nicht alles, was ich für einen Fall brauche, auf einmal sehen?"

„Ich weiss genau, was wohin gehört.“

„Mir ist es wichtig, dass sich der Kunde verstanden fühlt."

„Es rufen genügend Leute an, mit denen ich nichts zu tun haben wollte. Man braucht schon eine dicke Haut."

• Sachbearbeiter Schadensabteilung• 43 Jahre alt• kaufmännische Ausbildung• seit 24 Jahren bei Versicherungen• seit 7 Jahren in der Abteilung

Schaden

Abb. 3.4 Personas illustrieren wichtige Eigenschaften und Bedürfnisse der Benutzerim Hinblick auf ein geplantes neues Produkt

Was Sie über Ihre Benutzer festhalten sollten

Im Rahmen eines Projekts entstehen mehrere Personas, die jeweils einentypisierten Benutzer beschreiben. Eine Persona kann über folgende Ei-genschaften Auskunft geben:

• Ziele der Benutzer,• Beruf, Funktion, Verantwortlichkeiten und Aufgaben,• Fachliche Ausbildung, Wissen und Fähigkeiten,• Verhaltensmuster und Vorgehensweisen,• Werte, Ängste, Sehnsüchte, Vorlieben,• Allgemeine Computerkenntnisse,• Kenntnisse über verwandte Produkte, Vorgängersysteme, Konkur-

renzprodukte,• Verbesserungspotenzial in der heutigen Situation,• Erwartungen an eine neue Lösung.


Tab. 3.3 Die Klassifikation von Personas fördert die Fokussierung auf bestimmteBenutzergruppen und damit eine Priorisierung der Anforderungen bei der Gestaltungeines neuen Produkts

Typ Bedeutung

Primäre Persona Für deren Bedürfnisse und Anforderungen wird das Produktoptimiert und die Benutzerschnittstelle erstellt.

SekundärePersona

Bedürfnisse sind größtenteils durch eine primäre Personaabgedeckt. Nur kleine Erweiterungen notwendig.

ErgänzendePersona

Bedürfnisse sind vollständig durch eine primäre Personaabgedeckt.

Non-Persona Eine Persona, die vom Projektteam explizit nicht berück-sichtigt wird.

Der erstellte Charakter soll einprägsam sein. Seine Eigenschaften solleneinfach verinnerlicht werden können. Dazu kann eine Persona mit zu-sätzlichen passenden Informationen zum Leben erweckt werden:

• Name, Alter, Geschlecht,• Markige Charakterzüge,• Bild, Skizze, Porträt,• Passende Zitate aus Interviews,• Ein Tag im Leben von ...

Insbesondere die weichen Kriterien wie Ziele, Werte und Ängste erschei-nen einem Ingenieur im ersten Moment zwecklos. Die Handlungsweisevon Menschen wird indessen stark von genau solchen Faktoren beein-flusst.

Fokussierung der neuen Lösung

Das Projektteam lässt den Blick über die Galerie der Charaktere schweifen.Ein Analyst meint: „Jakob und Niklaus sind sehr verschieden. Müssen wir danicht zwei User Interfaces erstellen?“ Die Diskussion ist eröffnet. Wie soll dasProjektteam mit den unterschiedlichen Personas umgehen? Gibt es wichtigereund weniger wichtige Benutzergruppen?


Personas lassen sich wie in Tab. 3.3 dargestellt klassifizieren. Die Ein-stufung der Personas Jakob und Niklaus ist eine bewusste Entscheidung.Handelt es sich um zwei primäre Personas, dann wird das Projektteamzwei optimierte Benutzerschnittstellen entwerfen. Wäre Niklaus hinge-gen eine Non-Persona, dann würde bewusst keine Optimierung für dieseBenutzergruppe erfolgen.

DenkanstoßDenken Sie an ein spannendes Projekt zurück. Wurde über Benutzerdiskutiert? Wurden gewisse Benutzerkreise ausgeklammert, bewusstoder unbewusst? Wie hätte die Verwendung von Personas dieses Pro-jekt beeinflusst?

Szenarien

Anwendungsszenarien oder kurz Szenarien sind ein zentrales Elementin jeder benutzerorientierten Entwicklung. Sie schlagen die Brücke zwi-schen den Anforderungen und dem Entwurf einer neuen Lösung.

Ein Szenario beschreibt in Form eines realistischen Beispiels, wieein Benutzer mit dem geplanten System interagieren wird. In einfachenSätzen oder mittels Aufzählungspunkten wird ein konkreter Ablauf ausBenutzersicht im Anwendungskontext dargestellt. Dabei sollte, wie auchbei Personas, mehr auf inhaltlich richtige Aussagen als auf deren forma-le Korrektheit geachtet werden. Das folgende Beispiel zeigt ein kurzesSzenario zur Beschreibung einer neuen Versicherungsapplikation:

Szenario 1: Aufnehmen eines SchadensfallsEs ist 15:00 Uhr. Bei Jakob klingelt das Telefon. Auf seinem Bild-schirm erscheinen neben der Telefonnummer Name und weitere An-gaben des anrufenden Kunden. Jakob nimmt den Anruf entgegen undbegrüßt den ungeduldigen Kunden, der eine kaputte Fensterscheibemelden möchte. Da für diesen Kunden verschiedene Versicherungs-verträge bestehen, wählt Jakob die entsprechende Police aus derÜbersicht aus. Danach nimmt Jakob den Schadensfall des Kundenauf.


Das obige Szenario beschreibt in wenigen Sätzen, wie die Aufnahme ei-nes Schadensfalls in Zukunft mit dem neuen System ablaufen soll. Esspiegelt eine Reihe von zusammengehörigen Anforderungen aus Benut-zersicht wider:

• Automatische Anzeige des Namens und Angaben des Anrufers,• Darstellung aller bestehenden Versicherungspolicen eines Kunden,• Kurze Antwortzeiten des Systems.

Szenarien werden basierend auf den Anforderungen an ein neues Systemerstellt. Sie können iterativ entwickelt oder in Workshops zusammen mitBenutzern erarbeitet werden. Ein großer Vorteil von Szenarien ist ihreleichte Verständlichkeit. Sie können von verschiedenen Stellen wie Auf-traggeber, Benutzer und Entwicklung schon zu einem frühen Zeitpunktüberprüft, ergänzt oder korrigiert werden. Mit anderen Worten: Der Ana-lyst modelliert mit Szenarien die Anforderungen an ein neues System.Folgende Eigenschaften zeichnen ein Szenario aus:

• Es wird für eine bestimmte Benutzergruppe entworfen, berücksichtigtihre Eigenschaften und erfüllt ihre Bedürfnisse.

• Es stellt einen konkreten Fall aus der Anwendung dar.• Es zeigt, wie die Benutzer die neue Software in ihrem realen Umfeld

einsetzen werden.• Es illustriert die für die Entwicklung der neuen Lösung relevanten

Aspekte.• Es beschränkt sich nicht auf den Schönwetterfall, sondern beschreibt

auch exemplarisch wichtige Ausnahme- und Fehlersituationen.

Verwendung von Szenarien

Szenarien können zu unterschiedlichen Zeitpunkten in der Entwicklungeiner neuen Lösung und für verschiedene Ziele eingesetzt werden:

• Erhebung und Validierung von Anforderungen: Die Reflektion amkonkreten Beispiel erlaubt es Auftraggebern und Benutzern, Anforde-rungen in der konkreten Anwendungssituation zu vergegenwärtigen,zu überprüfen und zu ergänzen. Szenarien können als erste Prototypeneines neuen Systems betrachtet werden.


• Spezifikation: Szenarien illustrieren die Anwendung im realen Kon-text und dienen als Ergänzung des Use-Case-Modells (siehe Ab-schn. 3.5). Sie vermitteln den Entwicklern ein Verständnis der Ab-läufe und Zusammenhänge. In agilen Projekten sind Szenarien einegute Quelle für die Erstellung von User Stories (vgl. Abschn. 3.5).Szenarien bringen die konkrete Anwendung in die Diskussion ein.

• User-Interface-Konzept: Design-Szenarien dienen dazu, die Abläufeder Benutzerschnittstelle zu beschreiben. Damit kann die Interaktionmodelliert und mit Benutzern optimiert werden. Die technischen An-forderungen können von Entwicklern überprüft werden.

• Usability-Testszenarien: Szenarien dienen als Basis für die Evaluationeines Systems oder eines Prototypen zusammen mit Benutzern (sieheAbschn. 3.7).

• Testszenarien: Aus den erstellten Szenarien können Testszenarien fürdie Prüfung der entwickelten Software abgeleitet werden.

• Schulung: Szenarien dienen zur Schulung von Benutzern und als Ba-sis für die Erstellung von Anleitungen.

Diese Durchgängigkeit über den gesamten Entwicklungsprozess machtSzenarien zu einem äußerst effektiven Instrument in der Entwicklungvon interaktiven Systemen. Für eine weiterführende Vertiefung der sze-nariobasierten Entwicklung möchten wir an dieser Stelle auf das Buch[Rosson et al. 02] verweisen.

Hintergrund: Die Macht des guten BeispielsEin Analyst achtet darauf, formal korrekt und präzise zu formulieren. Die Spezifi-kation eines neuen Systems darf schlussendlich nur wenig Interpretationsspielraumzulassen. Um formal korrekt zu formulieren, muss zwangsläufig über verschiedenemögliche Fälle generalisiert werden. Die Gefahr dabei ist, dass die Realität auf derStrecke bleibt.

Der Sachbearbeiter nimmt eine Schadensmeldung eines Kunden auf ist eine for-mal korrekte Formulierung des Sachverhalts im obigen Beispiel, sie sagt allerdingswenig über die tatsächliche Situation aus. Natürlich wird im Beispiel nicht nur Jakobmit dem neuen System arbeiten. Es sollen damit auch nicht nur Schadensmeldun-gen für kaputte Fensterscheiben erfasst werden. Eine für die Usability des Systemszentrale Anforderung ist im vorliegenden Fall, dass der Benutzer aufgrund der Kun-denanfrage (eine kaputte Fensterscheibe) schnell und eindeutig (denn der Kundewartet am Telefon) die richtige Versicherungspolice (z. B. eine Hausratversicherung)zuordnen kann. Diese Anforderung wird erst durch die Schilderung der konkreten


Anwendungssituation ersichtlich und kommt in einer formal korrekten, generalisier-ten Darstellung nur schwer zum Ausdruck.

Ein Beispiel dagegen ist weder eindeutig noch vollständig. Interessanterweise istdas menschliche Gehirn hervorragend dafür geeignet, aus Beispielen Regeln abzulei-ten. Mittels weniger, guter Beispiele kann ein Sachverhalt oft schneller, umfassenderund manchmal sogar präziser dargestellt werden als mit einer formalen Spezifikati-on. Personas und Szenarien nutzen diese Tatsache aus. Indem sie wichtige, stimmigeund realistische Beispiele wiedergeben, können sie die Anwendung eines geplantenSystems schon früh im Entwicklungsprozess relativ genau umreißen, ohne dass dieDetails präzisiert werden müssen.

Die Benutzerperspektive

Mit Personas und Szenarien kann das Projektteam die Perspektive derBenutzer einnehmen und aus deren Sicht diskutieren. In erster Linie solldamit das System oder Produkt entworfen und die Benutzerschnittstelleoptimiert werden. Zum Beispiel könnte ein Szenario zeigen, in welcherReihenfolge Jakob Informationen sucht, liest und eingibt. Der Vergleichzu einem analogen Szenario mit Niklaus würde die Unterschiede im Vor-gehen sichtbar machen. So kann für unterschiedliche Benutzergruppendie richtige Mischung zwischen unterstützenden, beschränkenden undflexiblen Funktionen definiert werden.

Personas und Szenarien dienen einem Projektteam auch zur Beur-teilung von Konkurrenz- oder Vorgängerprodukten: Wie gut wird einePerson den im Szenario skizzierten Fall lösen? Dies gibt wertvolle Hin-weise über Stärken und Schwächen anderer Lösungen.

Durch die Benutzerperspektive ändert sich die Diskussion. Die Teil-nehmer werden zur Perspektivenübernahme (vgl. Abschn. 1.2) ermun-tert. Sie diskutieren aus der Sicht der Persona, statt aus einer aufgrundeigener Erfahrungen oder klischeehaften Vorstellungen gebildeten Indi-vidualsicht. Die Diskussion wird dadurch objektiver. Statt darüber zustreiten, ob der Benutzer dieses oder jenes Konzept verstünde oder nicht,lässt sich die Frage untersuchen, welche Persona das Konzept kennt. Jefundierter die Daten, die zu den Personas führten, desto objektiver dieDiskussion.



• Wenn immer möglich sollten Personas aufgrund von Erkenntnissenüber die (zukünftigen) Benutzer abgeleitet werden, beispielsweiseaus Ergebnissen von Interviews, Contextual Inquiries, Beobachtungenoder Befragungen. Es besteht sonst die Gefahr, dass aufgrund falscherVorstellungen an der Zielgruppe vorbeientwickelt wird.

• Es ist nicht immer möglich, mit Benutzern zu sprechen. Hier leistenPersonas einen wertvollen Dienst, um Annahmen über die Benutzeraufzudecken, unterschiedliche Verständnisse zu diskutieren und eingemeinsames Verständnis zu erreichen. In diesem Fall können dieBeiträge von Fachleuten, Callcentern, Schulungen und andere sekun-däre Informationsquellen ausgewertet werden.

• Personas erlauben einem Projektteam, bewusst auf die relevanten Ei-genschaften der Benutzer zu fokussieren. Sie sind somit Teil derProjektabgrenzung und ein wichtiges Mittel für die Planung von Usa-bility-Aktivitäten.

• Das Projektteam sollte die Anzahl Personas klein halten. Für jede pri-märe Persona wird eine eigene Benutzerschnittstelle bzw. eine eigeneSicht auf diese erstellt. Mehrere sekundäre Personas weisen zudemdarauf hin, dass die Ziele der Benutzerschnittstelle zu breit gefasstoder unklar sind.

• Bei Änderungen der Anforderungen im Verlauf des Projekts kann esrelativ viel Aufwand bedeuten, Personas und Szenarien nachzupfle-gen und konsistent zu halten. Personas und Szenarien sind deshalb nurbegrenzt als Modellierungswerkzeuge für Detailanforderungen geeig-net. Ihre Stärke liegt in der Vermittlung von wichtigen Informationenmit Übersichtscharakter, zum Beispiel für eine Produktvision oder zurErgänzung der Use Cases.

• Personas sind keine quantitativen Zielgruppenbeschreibungen. Per-sonas verkörpern die für die Entwicklung relevanten Aspekte derBenutzer, während sich Zielgruppen auf die für Marketing und Ver-kauf wesentlichen Aspekte konzentrieren.

• Personas sind keine Marktsegmente. Segmente teilen die potenziellenKäufer entsprechend ihrer Eigenschaften in verschiedene Bereiche ein(z. B. alle Kunden im Alter von 18–35). Die Eigenschaften von Per-sonas dagegen weisen keine Bereiche auf und erfüllen einen anderen

3.3 Einfach kommunizieren: Storyboards 47

Zweck. Sie spiegeln Bedürfnisse einer Benutzergruppe wider und fo-kussieren auf die Interaktion mit dem zukünftigen Produkt.

In Kürze

Methode Personas und Szenarien

Resultate Benutzergruppen im Detail charakterisiertAnwendungsszenarien ausgearbeitetDas Team nimmt die Benutzerperspektive ein.

Vorgehen Für ein neues System die wesentlichen Eigenschaften der Benutzerzusammentragen, daraus Personas entwickeln und diese zum Le-ben erwecken. Szenarien erarbeiten, wie Benutzer mit dem neuenSystem umgehen. Personas einsetzen, um aus der Perspektive derBenutzer zu diskutieren und zu bewerten.

Aufwand Modellieren von Personas: 2–6 PTErarbeiten von Szenarien: 3–10 PTInkl. Aufwand für Auftraggeber und Beteiligte. Diese Angabe gehtdavon aus, dass alle notwendigen Grundlagen vorhanden sind.

Beteiligte Analyst erstellt Personas und Szenarien. Auftraggeber, Analyst,Software-Architekt, Entwickler, Fachleute usw. diskutieren aus derSicht der Benutzer.

Planung Personas entstehen bereits während der Projektabgrenzung undwerden später verfeinert. Szenarien entstehen vor allem in derDetaillierungsphase, um Anforderungen und wesentliche Aspekteder Benutzerschnittstelle zu erarbeiten.

3.3 Einfach kommunizieren: Storyboards

In einer Fünftelsekunde kann man eine Botschaft rund um die Welt senden.Aber es kann Jahre dauern, bis sie von der Außenseite eines Menschenschädelsnach innen dringt.(Charles F. Kettering)

Software-Entwickler, Auftraggeber, Fachvertreter und Benutzer spre-chen unterschiedliche Sprachen. Ein Beispiel stammt aus einem Projekt,


in welchem der Software-Architekt von den Fachvertretern wissen woll-te, ob „optimistic“ oder „pessimistic locking“ gefordert sei (keine Sorge,die beiden Begriffe sind hier nicht relevant). Der Software-Architektstand vor der Entscheidung, auf welche Weise die neue Software damitumgehen sollte, wenn mehrere Benutzer zur gleichen Zeit die gleichenDaten bearbeiten wollen. Die Schwierigkeit bestand darin, dass er die-se Frage nicht so formulieren konnte, dass die Fachvertreter diese auchverstehen und beantworten konnten.

Dieser Abschnitt stellt Storyboards vor, ein Mittel zur Kommunika-tion zwischen Auftraggebern, Benutzern und Entwicklern. Storyboardswerden auch in anderen Gebieten, zum Beispiel in der Filmbranche, ein-gesetzt. Das Storyboard hilft dem Regisseur dabei, den Schauspielernund dem Filmteam den Aufbau des Films zu vermitteln. Es visualisiertAspekte wie Perspektive, Beleuchtung, Gesichtsausdrücke, Kostüme undso weiter.

Die Anwendung visualisieren

Ein Storyboard zeigt mithilfe der Benutzerschnittstelle, wie ein Systemoder Produkt verwendet wird. Es stellt wichtige Aspekte der Anwendungbildlich dar und dient damit der Kommunikation zwischen allen Beteilig-ten. Im Wesentlichen handelt es sich dabei um die Visualisierung einesSzenarios (vgl. Abschn. 3.2). Abbildung 3.5 zeigt einen Ausschnitt auseinem Storyboard.

Abhängig vom Kommunikationszweck kann ein Storyboard in un-terschiedlichen Ausprägungen erstellt werden. Die Palette reicht vonskizzenartigen oder realistisch gestalteten Abfolgen der Benutzerschnitt-stelle (User Interface Storyboard) bis zu Bildergeschichten, die auchKontext und handelnde Personen darstellen.

Der Analyst setzt Storyboards in Situationen ein, wo Text alleine nichtausreicht. Zwei wichtige Gründe sprechen für eine solche Visualisierung:

• In Bildern können Aspekte vermittelt werden, die mit Text nicht odernur schwer auszudrücken sind, beispielsweise neuartige Konzepte, fürdie es noch keine Begriffe gibt.


Abb. 3.5 Mit Hilfe eines Storyboards wird ein erster Eindruck der geplanten neuenAnwendung vermittelt

• Mit der visuellen Umsetzung können Erlebnisse, die für die An-wendung von Bedeutung sind, besser in die Welt des Zielpublikumstransportiert werden.

Ein Storyboard eignet sich deshalb, um folgende Gesichtspunkte aufzu-zeigen:

• Dialogabläufe der Benutzerschnittstelle,• Schwer verständliche Konzepte oder Sachverhalte,• Wichtige Aspekte des Anwendungskontexts,• Spezielle oder komplexe Umgebungen, in denen das System einge-

setzt wird.

Eine Geschichte erzählen

Ein Storyboard erzählt die Geschichte, wie die Benutzer ein neues Sys-tem nutzbringend einsetzen. Eine solche Geschichte vermittelt Vorschlä-ge und Entscheidungen über Funktionsumfang, Gestaltung, Software-Architektur und mehr. Das Storyboard stellt eine implizite Frage an dieZuhörer: „Wir als Projektteam denken, dass diese Lösung eure Bedürf-nisse erfüllt und so realisiert werden kann. Wo irren wir uns und wo habtihr Bedenken?“ Damit dies erreicht werden kann, sollten die folgendenAspekte beachtet werden:


• Die Geschichte erzählt ein konkretes Fallbeispiel.• Sie ist örtlich und zeitlich eingeordnet.• Sie erklärt die Zusammenhänge und stellt die kritischen Punkte de-

tailliert dar.• Der dargestellte Fall sollte kein Trivialfall sein.• Die handelnden Personen werden charakterisiert.• Die Geschichte begründet plausibel, warum die Personen so handeln.

Die Realitätsnähe und die Details der kritischen Punkte bieten Anlass zuinteressanten Diskussionen, in denen Missverständnisse und Diskrepan-zen aufgedeckt werden.

Was sollte ein Storyboard enthalten?

Ein Storyboard wird mit den Erkenntnissen im Verlauf eines Projektspräzisiert. Sind am Anfang nur erste Ideen oder verschiedene Variantenskizziert, so beinhaltet ein Storyboard später die bereits getroffenen Ent-scheidungen. Es enthält Aussagen zu folgenden Aspekten des geplantenSystems:

• Berücksichtigte und nicht berücksichtigte Bedürfnisse,• Änderungen der Geschäftsprozesse,• Neuerungen in der Arbeitsweise,• Enthaltene bzw. ausgeklammerte Funktionalität,• Den grundsätzlichen Aufbau der Benutzerschnittstelle,• Ausgewählte User-Interface-Details.

Diese Liste ist nicht vollständig. Abhängig vom Kommunikationszweckmüssen auch nicht zu jedem Punkt Aussagen vorhanden sein.

Zielgerichtet kommunizieren

Storyboards können in verschiedenen Situationen und für unterschiedli-che Zwecke eingesetzt werden:

• Zur Diskussion einer Idee oder einer ausgearbeiteten Lösung mit Be-nutzern und weiteren Stakeholdern.


• Um das korrekte Verständnis der Bedürfnisse und der fachlichen Zu-sammenhänge zu prüfen und Missverständnisse auszuräumen.

• Zur Diskussion von Vor- und Nachteilen verschiedener Varianten.• Um über Neuerungen zu informieren und damit beispielsweise Ak-

zeptanz für das neue Werkzeug zu erzeugen.• Um neugierig auf das Neue zu machen.• Um Führungskräfte darüber zu informieren, wie ihre Vision durch die

neue Lösung Realität wird.• Um Entwicklern die relevanten Anforderungen der Benutzung näher-

zubringen und zu zeigen, warum gewisse Entscheidungen getroffenwurden.

• Um Benutzern im Rahmen einer Ausbildung einen Überblick über dasSystem zu geben.

• Für Projektmarketing bei Auftraggebern, Geschäftsleitung und Be-nutzern.

Die Realität in denWorkshop holen

Storyboards sind ein ausgezeichnetes Mittel, um die Realität der An-wendung in einen Workshop einzubringen. Die Teilnehmer diskutierenbasierend auf der erzählten Geschichte über Annahmen, reflektieren Un-terschiede zur heutigen Situation und klären Missverständnisse an realenBeispielen.

Möchte der Software-Architekt in unserem obigen Beispiel also wis-sen, wie die Applikation reagieren soll, wenn mehrere Benutzer gleich-zeitig an den Daten arbeiten, dann kann ein User Interface Storyboardals Grundlage für eine angeregte Diskussion mit den Fachvertretern die-nen. Diese können so die Konsequenzen für ihre Arbeit abschätzen unddie beste Lösung wählen. Der Software-Architekt wird in einem solchenWorkshop nicht nur eine fundierte Antwort auf seine Frage erhalten, son-dern gleichzeitig viel über die Benutzer und ihre Arbeit lernen.


In Kürze

Methode Storyboards

Resultate Anwendung des neuen Systems aufgezeigtAkzeptanz bei Auftraggebern und Benutzern erzeugtFeedback zu Ideen und Entscheiden erhaltenKontext an das Projektteam kommuniziert

Vorgehen Abläufe aus Benutzersicht aus vorhandenen Informationenzusammenstellen und visualisieren. Mit Auftraggebern,Benutzern und Mitgliedern des Projektteams validieren undÄnderungen einarbeiten.

Aufwand Pro Storyboard ca. 1–2 PT. Diese Angabe geht davon aus,dass alle notwendigen Grundlagen vorhanden sind.

Beteiligte Analyst erstellt das Storyboard.Auftraggeber, Benutzer, Software-Architekt, Entwicklergeben Feedback.

Planung Früh im Projekt für Projektmarketing bei SponsorenIm Requirements Engineering, um Feedback einzuholenIn späteren Phasen zur Einführung und Ausbildung

3.4 Kritzeln für Fortgeschrittene: UI PrototypingIngenieure erstellen Prototypen, um ausgewählte Merkmale einer neu-en Lösung, zum Beispiel deren Funktionsfähigkeit oder die eingesetzteTechnologie, unter Beweis zu stellen. User Interface Prototyping (UIPrototyping) wird im Usability Engineering eingesetzt, um Aspekteder Benutzerschnittstelle zu entwerfen, zu evaluieren und zu verbessern,noch bevor ein lauffähiges System vorhanden ist. Weil dabei oft ein-fachste Werkzeuge wie beispielsweise Papier und Bleistift zum Einsatzkommen, spricht man auch von LoFi Prototyping (von englisch LowFidelity: geringe Wiedergabetreue).

Dimensionen eines UI-Prototypen

Abhängig vom Ziel, das verfolgt wird, können unterschiedliche Artenvon UI-Prototypen zum Einsatz kommen. Um den geplanten Prototypen

3.4 Kritzeln für Fortgeschrittene: UI Prototyping 53

näher zu charakterisieren, lassen sich die folgenden Dimensionen unter-scheiden:

• Funktionsumfang: Wie viel der vorgesehenen Funktionalität der Be-nutzerschnittstelle soll im Prototyp gezeigt werden? Sind dies aus-gewählte Ausschnitte, oder geht es darum, den gesamten Umfangdarzustellen?

• Funktionstiefe: Wie detailliert sollen die einzelnen funktionalen Ele-mente wiedergegeben werden? Sollen beispielsweise mehrstufigeBerechnungen nur angedeutet werden, oder sind die Zwischenschritteund ihre Resultate entscheidend?

• Darstellungstreue: Wie ähnlich soll der Prototyp dem Endprodukt inBezug auf Aussehen der Benutzeroberfläche (Look & Feel) sein? Ab-bildung 3.6 zeigt unterschiedliche Ausprägungen eines UI-Prototypenbezüglich Darstellungstreue.

• Interaktivität: Wie interaktiv soll der Prototyp sein? Braucht es lauffä-hige Beispiele, um komplexe Abläufe wiederzugeben, oder genügenstatische Darstellungen der Benutzerschnittstelle?

• Datengehalt: Sollen reale Daten zum Einsatz kommen, genügenrealistische Beispiele oder gar Platzhalter für Bezeichnungen und dar-gestellte Informationen? Wie relevant ist die dargestellte Menge anInformationen?

• Technische Reife: Wie viel der endgültigen User-Interface-Technolo-gie soll im Prototypen verwendet werden? Muss der Prototyp mit derEntwicklungsumgebung der Zielplattform entwickelt werden, odersind einfache Zeichnungswerkzeuge ausreichend?

Jeder Prototyp stellt einen Kompromiss zwischen notwendigem Auf-wand und Zweck dar. Bevor Sie mit UI Prototyping loslegen, solltenSie sich deshalb im Klaren sein, welche Fragestellungen Sie verfolgen.Daraus lässt sich ableiten, welche Art von UI-Prototyp geeignet ist. Diefolgenden Abschnitte beinhalten einige typische Verwendungszweckefür UI-Prototypen.


Abb. 3.6 Unterschiedliche Ausprägungen von UI-Prototypen. Links: einfacheHandskizze. Mitte: Drahtmodell (Wireframe). Rechts: endgültiges Look & Feel

Anforderungen klären

Das Team skizziert aufgrund der mittels Contextual Inquiry vor Ort gesam-melten Informationen erste Entwürfe der Benutzerschnittstelle mit Papier undBleistift. Bestehende Formulare und Applikationen geben Auskunft über Be-griffe und Daten. Die beobachteten Abläufe zeigen, in welcher Reihenfolgedie Benutzer diese Informationen verwenden. Die Entwürfe werden zu einerersten Simulation der Benutzerschnittstelle zusammengestellt und mit den Be-nutzern besprochen.

Man spricht bei Attrappen der Benutzerschnittstelle wie im obigenBeispiel auch von Mock-ups. Mit Mock-ups können Benutzer bereitskonkrete Fälle durchspielen und diskutieren. Dabei geht es nicht darum,das System zu entwerfen, sondern die Anforderungen der Benutzer miteinem einfachen Hilfsmittel erfahrbar zu machen. Das Projektteam decktdabei neben fachlichen Missverständnissen auch weitere Bedürfnisse derBenutzer auf:

• Notwendiger Informationsgehalt,• Funktionalität und Abläufe,• Einbettung in die Geschäftsprozesse,


Abb. 3.7 Mit einer einfachen Attrappe („Mock-up“) eines geplanten neuen mobi-len Scanners für die Paketzustellung konnten die Anforderungen aus Benutzersichtbereits in einer frühen Konzeptphase konkretisiert werden

• Datenaustausch mit anderen Systemen und Applikationen,• Darstellung von Tabellen, Grafiken, Funktionen usw.,• Wichtige Details der Benutzerschnittstelle.

Abbildung 3.7 zeigt ein Beispiel eines solchen Mock-ups.

Die Benutzerschnittstelle konzipieren

Eine der zentralen Aufgaben im Usability Engineering ist es, ein fürdie Aufgaben der Benutzer geeignetes User-Interface-Konzept zu er-arbeiten. Dabei geht es darum, die Grundsätze der Benutzerschnittstellefestzulegen. Wie bewegen sich die Benutzer durch Menüs und Dialoge?Wie wird die Information strukturiert und dargestellt? Muss das System


für spezielle Technologien, zum Beispiel für die Bedienung per Touchs-creen, optimiert werden?

Als Ausgangslage dienen die erarbeiteten Personas und Szenarienund die vereinbarten Anforderungen. Einfache Prototypen helfen demUser Interface Designer, die Szenarien durchzuspielen und ein geeigne-tes Konzept auszuarbeiten. Das User-Interface-Konzept sollte schließlichfolgende Aspekte beinhalten:

• Grundsätzlicher Aufbau und Screen-Layout,• Anzeige- und Eingabegeräte,• Aufteilung und Struktur von Informationen,• Verwendung und Verhalten von Fenstern,• Wichtige Bedienelemente,• Navigation mittels Menüs, Schaltflächen und Links,• Prüfung von Eingaben und Anzeige von Fehlermeldungen,• Konzepte für das Speichern von Informationen und Zuständen,• Rückgängig machen und erneut ausführen,• Interaktionsprinzipien wie Gesten, direkte Manipulation, Drag&Drop

oder Kontextmenüs.

Dabei muss auch die Technologie der Zielplattform berücksichtigt wer-den, beispielsweise Eingabe- und Ausgabemedien, Betriebssystem, Bild-schirmgrößen und Auflösung.

Die Benutzerschnittstelle optimieren

Gerade wenn hohe Anforderungen an Effizienz, Verständlichkeit oderan die Qualität der Arbeitsresultate gestellt werden, gewinnen Detailsder Benutzerschnittstelle große Bedeutung. Schon eine unglücklich for-mulierte Bezeichnung kann verhindern, dass Benutzer einen Automatenrichtig benutzen können. Eine immer wieder zu bestätigende Warn-meldung wird Vielbenutzer zur Weißglut treiben, und umständlicheMausoperationen verlangsamen die Arbeit.

Ein User Interface Designer sollte deshalb kritische Ausschnitte derBenutzerschnittstelle mittels Prototypen umsetzen und mit Benutzernevaluieren (vgl. Abschn. 3.7). Im Folgenden einige wesentliche Frage-stellungen:


• Erlaubt die Benutzerschnittstelle flüssiges Arbeiten?• Gibt es Hürden oder Stolpersteine für Personen, die das System zum

ersten Mal benutzen?• Ist die Navigation effizient?• Finden Benutzer die gewünschte Information?• Werden Warnmeldungen bemerkt und richtig interpretiert?• Passt die Benutzerschnittstelle zu den Details der Arbeitsabläufe?

Kritische Funktionen sollten mit einer realistischen Menge echter Datenhinterlegt sein. Damit können Benutzer ausgewählte Fälle durchspielenund die Benutzerschnittstelle auf ihre Tauglichkeit beurteilen.

Für gutes Aussehen sorgen

Ein nicht unerheblicher Aspekt moderner Benutzeroberflächen ist einästhetisches Design. Grafikdesigner arbeiten mit Prototypen, um sichverschiedene Design-Varianten vor Augen zu führen und die Details derGestaltung auszuarbeiten. Ein zentraler Punkt dabei ist, Funktionalitätund Ästhetik zu verbinden. Der User Interface Designer wird sich des-halb zu folgenden Punkten Gedanken machen:

• Anordnung und Abstände der Bedienelemente,• Ausrichtung der Beschriftungen,• Gruppieren von Elementen,• Farben und Kontraste,• Verwendung von Schriften,• Stil und Darstellung von Icons,• Weitere grafische Elemente.

Für solche Betrachtungen ist im Regelfall ein Werkzeug notwendig,welches eine grafische Gestaltung der Bedienelemente ermöglicht. Zahl-reiche Grafikprogramme bieten die häufigsten Bedienelemente moder-ner Benutzeroberflächen als vordefinierte Schablonen an und erlaubengleichzeitig, schnell und detailliert zu gestalten.


Das User Interface spezifizieren

Mit einem User-Interface-Prototypen können viele Aspekte der Benut-zerschnittstelle auf anschauliche Weise festgehalten werden. In agilenEntwicklungsteams, die eine leichtgewichtige Dokumentation bevorzu-gen, kann das Projektteam viele Ergebnisse einer Diskussion mit UI-Skizzen für die spätere Entwicklung festhalten. Im Rahmen der Spezi-fikation kann ein Prototyp für folgende Zwecke eingesetzt werden:

• Illustration des Funktionsumfangs,• Verdeutlichung der Funktionsweise,• Spezifizieren der User-Interface-Elemente,• Aufzeigen der Navigation und Interaktion,• Visualisierung der geplanten Lieferung,• Abschätzung des Realisierungsaufwands durch die Entwickler.

In der Regel sind im Rahmen der User-Interface-Spezifikation dieDarstellung des Funktionsumfangs und für ausgewählte Aspekte aucheine realistische Funktionstiefe gefordert. Eine gewisse Interaktivität istebenfalls hilfreich, da so verschiedene Zustände des User Interface visua-lisiert werden können. Ein solcher Prototyp wird deshalb in vielen Fällenmit einer Technologie erstellt, welche der Zieltechnologie nahekommt.Bei einfacheren Produkten genügen auch Grafik- und Bildbearbeitungs-programme.

Tabelle 3.4 fasst die beschriebenen Verwendungszwecke und diedafür notwendigen Dimensionen für die Erstellung von Prototypen zu-sammen.

Paper Prototyping

Leider sind wir Erwachsenen der Ansicht, dass Zeichnen nur etwas fürKinder oder Künstler ist, jedoch keine seriöse und ernsthafte Tätigkeit. Indiesem Abschnitt möchten wir in aller Deutlichkeit darstellen: Zeichnen


Tab. 3.4 User-Interface-Prototypen können je nach Verwendungszweck unterschied-liche Dimensionen der geplanten Benutzerschnittstelle darstellen

Zweck Dimensionen

Anforderungen klären Großer Funktionsumfang (in mehreren Prototy-pen) mit realistischen Daten

Benutzerschnittstellekonzipieren

Mittlere DarstellungstreueAusgewählte Funktionen im DetailTeilweise interaktiv

Benutzerschnittstelleoptimieren

Hohe DarstellungstreueInteraktiv für ausgewählte FunktionenOft reale Daten notwendigOft hohe technische Reife notwendig

Für gutes Aussehen sorgen Hohe DarstellungstreueUser Interface spezifizieren Funktionsumfang und -tiefe sind mittel bis hoch

Mittlere bis hohe Interaktivität

ist eine Notwendigkeit! Der Entwurf eines ersten Prototypen mit Papierund Bleistift hat verschiedene Stärken:

• Praktisch alle Personen können damit umgehen.• Einfache Skizzen sind schnell erstellt und angepasst.• Es wird weniger Zeit für Details aufgewendet als mit Grafikprogram-

men.• Es sind keine technischen Hilfsmittel notwendig.• Auch nicht standardisierte Bedienelemente sind schnell skizziert.• Mehrere Personen können gemeinsam arbeiten.• Einen Papier-Prototypen zu zerknüllen und wegzuwerfen, fällt leicht.

Aus diesen Gründen arbeitet beispielsweise ein Projektteam bei der Be-dürfnisanalyse effizienter mit Papier und Bleistift als mit elektronischenWerkzeugen. Papier-Prototypen sind auch gut geeignet, um im Rahmenvon Interviews und Workshops aufkommende Ideen zu visualisieren.


Ein weiterer wichtiger Punkt ist, dass Mock-ups auf Papier undelektronische Prototypen nicht die gleiche Wirkung haben. Papier-Pro-totypen signalisieren durch ihre Skizzenhaftigkeit, dass noch viel offenist und auch über Grundsätzliches diskutiert werden kann. Entspre-chend lässt sich gezielter über Abläufe und den konzeptionellen Aufbaudiskutieren. Bei einem endgültig aussehenden Prototypen gehen hin-zugezogene Personen eher davon aus, dass das Grobkonzept bereitsfeststeht und nur noch an den Details gefeilt werden soll. Eine um-fassende Übersicht zum Thema bietet das Buch Paper Prototyping[Snyder 03].

Iteratives Vorgehen

User Interface Prototyping ist ein iterativer Prozess. Auf das Wesentlichereduziert stellt dies Abbildung 3.8 dar.

Das Projektteam erstellt aufgrund der Anforderungen einen ersten UI-Prototypen des geplanten Systems. Dieser hilft bei der weiteren Optimie-rung und Präzisierung der Anforderungen, beispielsweise im Rahmenvon Usability-Tests und Walkthroughs (mehr dazu im Abschn. 3.7) so-wie Workshops oder Reviews.

Abb. 3.8 UI-Prototypendienen der Evaluation vonAnforderungen in einemiterativen Vorgehen

Anforderungen

Evaluation

Prototyp


Einige gängige Prototyping Tools

User-Interface-Prototypen können mit verschiedenen Werkzeugen er-stellt werden. Tabelle 3.5 zeigt einige Möglichkeiten.

Abbildung 3.9 zeigt einen mit Microsoft Expression Blend Sketch-Flow® erstellten skizzenartigen, jedoch beliebig interaktiven User-Inter-face-Entwurf, der für das UI Prototyping verwendet werden kann.

Tab. 3.5 Übersicht verschiedener Arten von Prototyping Tools

Tool Verwendung

Papier & Bleistift, Whiteboard,Folien

Diese Mittel eignen sich besonders inWorkshops und Interviews, sowie fürexplorative Skizzen.

Office-AnwendungenMicrosoft Powerpoint, AppleKeynote

Mit wenig Aufwand können damit ersteInteraktionen erstellt werden.

BildbearbeitungsprogrammeAdobe Photoshop

Volle Kontrolle über die grafische Gestal-tung.

GrafikprogrammeOmniGraffle, Microsoft Visio, Ado-be Fireworks

Bieten vordefinierte Schablonen der gän-gigen Bedienelemente. Damit lassen sichschnell gut und echt aussehende Mock-ups erstellen.

UI-Prototyping-WerkzeugeAxure RP, Balsamiq Mockups,iRise

Speziell für UI Prototyping entwickelt,unterstützen diese Werkzeuge den Desi-gnprozess von der interaktiven Skizze biszur Umsetzung auf der Zielplattform.

MultimediawerkzeugeAdobe Director, Adobe Flash

Insbesondere für interaktive Prototypenmit hohen Design-Anforderungen oderAnimationen.

Programmierwerkzeuge,HTML-Editoren, Entwicklungs-werkzeuge,Microsoft Expression Blend, AdobeFlex

Interaktive Prototypen mit größeren Da-tenmengen und komplexerem Verhalten.


Abb. 3.9 Die Erstellung eines interaktiven UI-Prototypen mit Hilfe eines Entwick-lungswerkzeugs erfordert grundlegende Programmierkenntnisse


• User Interface Prototyping ist eine iterative Tätigkeit. Investieren Sienicht zu viel Zeit in die Perfektionierung, bevor Sie Feedback einho-len.

• Es lohnt sich, ein Werkzeug zu wählen, mit dem ohne großen Auf-wand verschiedene Varianten ausgearbeitet und Änderungen umge-setzt werden können. Häufig wird zu früh auf Programmierwerkzeugefür die Erstellung von UI-Prototypen gesetzt.

• Bei Geräten sollten Prototypen die Software in Kombination mit derHardware zeigen. Anzahl, Größe und Anordnung von Bedienelemen-ten beeinflussen das Konzept auf dem Display maßgeblich.

3.5 In die Entwicklung tragen: Use Cases 63

In Kürze

Methode User Interface Prototyping

Resultate Anforderungen evaluiertDetails der Benutzerschnittstelle erarbeitetBenutzerschnittstelle optimiert

Vorgehen Erstellen von Prototypen und Evaluieren mit BenutzernAufwand Der Aufwand hängt sehr stark vom Zweck des Prototypen

ab. Einige Größenordnungen für die Erstellung:– Papier: Minuten bis Stunden– Visio: Stunden bis Tage– Photoshop: Tage bis Wochen– Entwicklungstools: Tage bis Monate

Beteiligte Analyst, um erste Ideen zu evaluieren.User Interface Designer, um Funktionalität, dargestellte In-formationen und das User-Interface-Konzept zu erarbeiten.Entwickler, Benutzer, Auftraggeber geben Feedback.

Planung In den frühen Phasen eines Projekts, um Ideen zu konkreti-sieren und Anforderungen zu erheben.Während der eigentlichen Spezifikation, um die Details derBenutzerschnittstelle zu erarbeiten und zu evaluieren.

3.5 In die Entwicklung tragen: Use Cases

Anwendungsfälle (Use Cases) stammen aus dem Software Engineeringund sind ein verbreitetes Instrument zur Spezifikation von technischenSystemen.

In der Usability-Literatur findet sich zum Thema dagegen eher wenig.Dies mag überraschen, da mittels Anwendungsfällen das Verhalten einesSystems aus Benutzersicht dargestellt wird. Die Abläufe, die ein Benut-zer später mit dem System erlebt, werden zu einem großen Teil von denspezifizierten Anwendungsfällen bestimmt. Deren Entwurf hat für dieUsability eines Systems daher eine zentrale Bedeutung. Auch wenn UseCases und deren Modellierung keine Usability-Methode im engeren Sinndarstellen, haben wir uns aus oben genannten Gründen entschieden, sie


in unsere Sammlung der wichtigsten Usability-Methoden aufzunehmen.Wir beschränken uns allerdings auf eine Übersicht und den Zusammen-hang mit anderen Usability-Methoden.

Das Use-Case-Modell

Use Cases beschreiben die (geplante) Funktionalität eines Systems unddamit dessen Verhalten gegenüber der Außenwelt. Eine große Stärkevon Use Cases ist, dass diese die Funktionsvielfalt aus Benutzersichtin zusammengehörige Einheiten aufbrechen und Schritt für Schritt nä-her definieren. Ein weiterer Vorzug von Use Cases ist die Beschreibungin natürlichsprachlicher Form, die im Verlauf der Entwicklung für alleBeteiligten verständlich bleibt.

Um eine bestimmte Funktionalität darzustellen, verwendet das Pro-jektteam sogenannte Akteure (Actors), die mit dem System in Inter-aktion treten. Akteure verkörpern dabei die Rollen von Benutzern oderanderen Systemen. Der Anwendungsfall beschreibt den funktionalen Ab-lauf mit dem System aus Sicht des Akteurs. Soll beispielsweise dieFunktionalität für eine Anwendung zur Buchbestellung im Internet be-schrieben werden, dann wäre der Kunde, der das Buch bestellt, einAkteur, die Bestellung eines Buches ein Anwendungsfall, die Verfolgungder Bestellung ein zweiter, die Bewertung eines Buches ein dritter usw.Dabei sollte ein Anwendungsfall immer eine aus Sicht des Akteurs ab-schließende Handlung umfassen.

Die Gesamtheit der Akteure und Anwendungsfälle eines Systemswird als Use-Case-Modell bezeichnet. Das Projektteam modelliert damitim Rahmen der Anforderungsanalyse die Funktionsweise des Systems.Das System selbst wird dabei von außen als Blackbox betrachtet, d. h.es wird noch nicht beschrieben, wie das Verhalten zustande kommt.Die einzelnen Interaktionsschritte jedes Anwendungsfalls werden in ei-nem zweiten Schritt beschrieben und dienen zur Spezifikation für dieEntwicklung. Die Anwendungsfälle verkörpern somit das funktionaleVerhalten eines Systems. Das Use-Case-Modell lässt sich auch grafischdarstellen. Ein solches Use-Case-Diagramm dient als Übersicht über dieFunktionalität des Systems und seiner Schnittstellen zur Außenwelt. Ab-


Abb. 3.10 Ein Use-Case-Diagramm eignet sich alsÜbersicht der Funktiona-lität einer geplanten neuenAnwendung

Bücherportal

Bücher bestellen

Buchangebot anpassen

Stand der Bestellung einsehen

ud Use Case Übersicht

Besteller

Sachbe-arbeiter

bildung 3.10 zeigt ein Beispiel eines Use-Case-Diagramms in der UML-Notation.

Woher kommen die Akteure?

Akteure und Anwendungsfälle werden typischerweise in Use CaseWorkshops mit Auftraggebern, Fachstellen und Benutzern erarbeitet. DieSchwierigkeit dabei ist, dass Akteure keine realen Benutzer, sondernRollen darstellen, die mit dem System interagieren. Ein häufiger Feh-ler ist, dass Akteure so weit verallgemeinert werden, dass der Bezug zurRealität verloren geht. Dies kann dazu führen, dass wichtige Bedürfnissevergessen oder Anforderungen von unterschiedlichen Benutzergruppenin einem einzigen Akteur vereinigt werden. In der Folge werden Anwen-dungsfälle konstruiert, die eine Vermischung von Funktionen beinhaltenund besser klar getrennt würden; mit dem Resultat, dass die so spezifi-zierten Abläufe für die tatsächlichen Benutzer in der realen Anwendungspäter nicht geeignet sind.

Besser ist es, ein Use-Case-Modell aufgrund der Ergebnisse aus derAnalyse von Benutzern und Kontext zu erstellen. Contextual Inquiry,Interviews oder vergleichbare Methoden, mit denen die Verantwortlich-keiten und Tätigkeiten der Benutzer aufgenommen werden, sind einewichtige Voraussetzung dafür.


Die Use-Case-Spezifikation

In der Use-Case-Spezifikation wird ein Anwendungsfall beschrieben.Die Schritte in der Interaktion zwischen Akteur und System werden auf-geführt. Neben dem „Schönwetterfall“ berücksichtigt das Projektteamhier auch alternative Abläufe und Fehlerfälle.

Bei der Ausformulierung eines Anwendungsfalls sollten noch keinetechnischen Details beschrieben werden. Ein häufiger Fehler ist, dassin Use-Case-Spezifikationen Details der Benutzeroberfläche vorwegge-nommen werden. Dies ist aus zweierlei Gründen nicht sinnvoll: Derbeschriebene Ablauf kann unter Umständen mit einem alternativen In-teraktionskonzept besser umgesetzt werden als zunächst angenommen.Weiter erschwert eine zu starke Detailtiefe die Pflege und Anpassungder Anwendungsfälle bei Änderungen. Es ist deshalb weitaus besser,neben der Use-Case-Spezifikation einen User-Interface-Prototypen oderein Storyboard zu erstellen, das die Abläufe mit der konkreten Benut-zerschnittstelle verdeutlicht. Mit einem solchen Prototypen kann einProjektteam die Entwürfe mit Auftraggebern und Benutzern verifizierenund verfeinern. Neben natürlichsprachlichen Beschreibungen in struktu-rierten Dokumenten werden ergänzend auch Ablaufdiagramme für dieDarstellung der einzelnen Schritte verwendet.

Die Spezifikation muss schließlich von zwei ganz unterschiedlichenParteien verstanden werden können: dem Auftraggeber und den Ent-wicklern. Anwendungsfälle sollten deshalb sowohl formal korrekt alsauch verständlich sein. Eine hervorragende Hilfestellung für die Formu-lierung guter und verständlicher Anwendungsfälle bietet [Cockburn 03].

Hintergrund: Funktionale und nicht-funktionale AnforderungenIm Anforderungsmanagement wird zwischen funktionalen und nicht-funktionalenAnforderungen unterschieden:

Funktionale Anforderungen betreffen, wie der Name sagt, jene Aspekte, die mitder Funktionalität des geplanten Systems zusammenhängen. Ein Buchbestellsystemkann beispielsweise Funktionen zum Suchen, Bestellen und Bewerten eines Buchesanbieten. Die funktionalen Abläufe, die für das Bestellen eines Buches notwendigsind, können etwa mit Use Cases näher beschrieben werden.

Nicht-funktionale Anforderungen umfassen sämtliche geforderten Rahmenbedin-gungen. Im Beispiel muss das Buchbestellsystem bestimmten Anforderungen bezüg-lich Verfügbarkeit, Antwortzeiten, Ausfallsicherheit usw. genügen. Nicht-funktionaleAnforderungen spielen ebenfalls eine wesentliche Rolle für die Benutzbarkeit eines


Systems und haben Auswirkungen auf die verwendete Technologie und Software-Architektur. Auch bezüglich Usability können nicht-funktionale Aspekte festgelegtwerden, etwa im Hinblick auf die geforderte Effizienz für die Benutzer. In unseremBeispiel: Die Suche und Bestellung eines bestimmten Buches soll für 90 % der Be-nutzer in weniger als fünf Minuten möglich sein.

Essential Use Cases

Die Überlegung, technische Details in Anwendungsfällen noch weit-gehend auszuklammern, führte zum Konzept der Essential Use Cases[Constantine et al. 99]. Dabei wird versucht, in der Beschreibung vonAnwendungsfällen nur die Interaktion mit dem System als solche auszu-drücken und von deren technischen Umsetzung konsequent zu trennen.Damit soll vermieden werden, dass zu früh auf eine – eventuell nichtoptimale – technische Lösung eingeschwenkt wird. Das Konzept der Es-sential Use Cases fand in Usability-Fachkreisen großen Anklang. DasBeispiel in Tab. 3.6 zeigt einen einfachen Essential Use Case für ein Bü-cherbestellsystem.

Tab. 3.6 Ein Essential Use Case zeigt den Ablauf der vorgesehenen Benutzerinter-aktion ohne Informationen zur technischen Umsetzung

Essential Use Case: ein Buch für eine Bestellung vormerkenAbsicht des Benutzers Verantwortlichkeit des Systems

präsentiert Suchdialogführt Suche aus

präsentiert passende Bücher[optional] informiert sich über Buch

präsentiert Details zum Buchfügt Buch zur Bestellung hinzu

bestätigt Abschluss


User Stories

User Stories haben sich im agilen Umfeld (vergl. Abschn. 2.1 „Hinter-grund: agile Software Entwicklung“) anstelle der Use Cases etabliert.Die beiden Techniken muten im ersten Augenblick sehr ähnlich an. Wieein Use Case beschreibt auch eine User Story eine Funktionalität ausSicht der Benutzer. Der Titel eines Anwendungsfalls mit dem Akteur„Kunde“ lautet beispielsweise „Bücher bestellen“. Eine User Story imselben Kontext könnte lauten: „Als unangemeldeter Benutzer kann ichein Buch in den Warenkorb legen, um dieses später zu bestellen“.

Tatsächlich gründen die Unterschiede der beiden Techniken im Ver-wendungszweck. Use Cases modellieren funktionale Anforderungen unddas Verhalten des künftigen Systems, um dieses zu vereinbaren, zu ent-wickeln und zu testen. Typischerweise gibt es formelle Vorlagen für dieDokumentation der Use Cases.

User Stories halten eine Kommunikationsabsicht fest. Wenn das Pro-jekt soweit ist, soll die User Story mit den richtigen Personen detailliertdiskutiert und vereinbart werden. Allen Beteiligten soll klar sein, was fürwelchen Zweck implementiert wird, wie es getestet und abgenommenwird. User Stories können zu Beginn grobgranular sein, werden im Ver-lauf des Projekts jedoch in neue, feinere aufgebrochen. Das Ziel ist, dassmehrere User Stories in einer Iteration vollständig implementiert werdenkönnen. User Stories bedingen die direkte und zeitnahe Kommunikationzwischen den Beteiligten. Das Team hält Details entsprechend mit Stich-worten, Skizzen der Benutzerschnittstelle, einfachen Szenarien und soweiter fest. Siehe dazu auch [Wirdemann 10].

Agile Teams verwenden auch Personas bei der Formulierung von UserStories und schlagen so die Brücke zwischen Benutzeranforderungenund Entwicklung.

Use Cases oder Szenarien?

Akteure und Anwendungsfälle sind konzeptionell verwandt mit Personasund Szenarien (siehe Abschn. 3.2). Beides sind Methoden, mit denen einAnalyst die Interaktionen mit dem System modelliert. Dennoch gibt eseinige wesentliche Unterschiede:


Tab. 3.7 Gegenüberstellung von Personas und Szenarien mit den Elementen der Use-Case-Technik (Akteure und Anwendungsfälle)

Methode Format Ziel

Akteur Rollenbeschreibung Gruppierung zusammengehöri-ger funktionaler Abläufe

Persona Prototypischer Benutzer Charakterisierung unterschiedli-cher Benutzergruppen

Anwendungsfall Beschreibung des Sys-temverhaltens

Spezifikation des funktionalenVerhaltens für die Entwicklung

Szenario Konkretes Beispiel derSystemnutzung

Beschreibung der Anwendungim realen Kontext

• Akteure definieren Rollen, die mit dem System interagieren. Personashingegen charakterisieren prototypische Benutzer und fokussieren aufdie Eigenschaften von unterschiedlichen Benutzergruppen.

• Anwendungsfälle halten einen bestimmten Teil des Systemverhaltensfür die Entwicklung fest. Sie generalisieren über die verschiedenenMöglichkeiten der Nutzung. Szenarien dagegen beschreiben konkre-te Beispiele der Systemnutzung und illustrieren die Anwendung imrealen Kontext.

Tabelle 3.7 verdeutlicht die unterschiedlichen Ziele.Die beiden Methoden ergänzen sich in der Praxis ausgezeichnet. Rea-

listische Personas und Szenarien, die aufgrund von Benutzeranalysenerstellt wurden, bilden eine gute Grundlage für den Entwurf des Use-Case-Modells. Im Verlauf des Projekts detailliert und komplettiert derAnalyst die Anwendungsfälle, sodass das gesamte funktionale Verhaltendes Systems, inklusive Anbindung von externen Systemen, spezifiziertwird.

DenkanstoßStellen Sie sich ein System zum Bestellen von Büchern vor. DenkenSie sich den Akteur „Besteller“ und den Use Case „Buch bestellen“.

Nun stellen Sie sich Ruth vor. Sie ist Mitarbeiterin einer wissen-schaftlichen Bibliothek und ordert am Montag 219 Neuerscheinungenüber dieses Bestellsystem.


Wie unterscheidet sich ein solches Bestellsystem von jenem, dasLara verwendet, um den neusten Roman ihres Lieblingsautors zu be-stellen?

Ein Analyst, der eine Spezifikation für ein neues System schreibt, unter-sucht verschiedene einzelne Situationen und generalisiert die erhaltenenInformationen zu einem abstrakten Modell. Hat der Leser der Spezifika-tion allerdings nur dieses abstrakte Modell zur Verfügung, kann er diekonkreten Einzelfälle und deren Unterschiede nicht herleiten. Denn die-se Informationen sind in der Abstraktion nicht mehr enthalten. Beispielehingegen sind hervorragende Instrumente, um Zusammenhänge oder Ab-läufe aufzuzeigen (vgl. Abschn. 3.2 „Hintergrund: Die Macht des gutenBeispiels“). In den meisten Fällen ist es bereits hilfreich, wenige stellver-tretende Beispiele – etwa einen typischen Arbeitsablauf eines typischenBenutzers – möglichst realitätsnah wiederzugeben.

Checkliste für den Einsatz von Use Cases

• Sind die erstellten Akteure in der Realität wiederzufinden? Wurdensie auf Basis der Analyse von Benutzern und Kontext erstellt? Wurdenverschiedene Benutzergruppen berücksichtigt?

• Umfassen die Anwendungsfälle abgeschlossene Handlungsabläufeaus Benutzersicht? Entsprechen diese den erarbeiteten Szenarien undtatsächlichen Arbeitsprozessen der Benutzer?

• Wurde in den Use-Case-Spezifikationen an Alternativabläufe und dasVerhalten bei Fehlerfällen gedacht? Auch diese gilt es in einem be-nutzerorientierten Systemdesign zu berücksichtigen.

• Wurden die Anwendungsfälle sowie alternativen Abläufe mit Anga-ben zu Dauer und Häufigkeit des Vorkommens ergänzt?

• Beinhalten die Beschreibungen keine technischen Details, die besserin einem User-Interface-Konzept, Storyboard oder Prototypen abge-bildet würden?

• Ist bei jedem Schritt im Use Case klar, welche Informationen der Be-nutzer für seine Aufgabe benötigt?

3.6 Usability Guidelines und Styleguides 71

In Kürze

Methode Use Cases

Resultate Übersicht über die Funktionalität eines SystemsDetaillierte Beschreibung des Verhaltens des Systems aus Benut-zersicht

Vorgehen Ermitteln von Akteuren und AnwendungsfällenEntwurf eines Use-Case-ModellsSpezifikation der AnwendungsfälleReview mit Stakeholdern

Aufwand Entwurf und Review Use-Case-Modell: 3–10 PTSpezifikation stark abhängig vom funktionalen Umfang desSystems. 10–15 Use Cases: 15–30 PT

Beteiligte Auftraggeber, AnalystPlanung Im Rahmen der Anforderungsanalyse, im Anschluss an Contex-

tual Inquiry oder bei Vorliegen von Personas und Szenarien

3.6 Usability Guidelines und Styleguides

It’s like a jungle sometimesIt makes me wonder how I keep from goin’ under(Grandmaster Flash, 1982)

„Gibt es nicht einfach ein paar Richtlinien für gute Usability, damit unser Pro-dukt besser benutzbar wird?“

Ja, ungefähr 200’000. Zumindest ist dies die Anzahl Treffer, wenn manim Internet nach „Usability Guidelines“ googelt. Halten Sie also einfach allerelevanten Regeln ein. Genauso wie ein Schriftsteller, der ein Buch schreibtoder ein Architekt, wenn er ein Haus baut. Alles klar?

Was sind Usability Guidelines?

Usability Guidelines beinhalten Regeln für die Gestaltung von Benut-zeroberflächen. Darunter fällt zunächst ein sehr breites Spektrum vonRegelwerken. Die Palette reicht von globalen Grundsätzen bis hin zu


Tab. 3.8 Grundsätze der Dialoggestaltung (DIN EN ISO 9241-10, neu: 9241-110)

Aufgaben-angemessenheit

Das System unterstützt die Erledigung der Aufgabenund den Arbeitsablauf der Benutzer.

Selbstbeschreibungs-fähigkeit

Das System enthält Erläuterungen und ist ausreichendverständlich.

Steuerbarkeit Der Benutzer kann den Dialogablauf beeinflussen.Erwartungskonfor-mität

Erwartungen, Eigenschaften und Gewohnheiten derBenutzer werden unterstützt.

Fehlertoleranz Fehler erfordern keinen oder nur geringen Korrekturauf-wand.

Individualisierbar-keit

Das System kann an die individuellen Bedürfnisse ange-passt werden.

Lernförderlichkeit Das System erfordert einen geringen Lernaufwand undunterstützt das Erlernen neuer Funktionen.

detaillierten Vorgaben. In der Praxis werden deshalb oft die folgendenBegriffe unterschieden:

• (G)UI Guidelines: eher generelle Richtlinien für die Verwendung unddas Verhalten von (grafischen) User-Interface-Elementen.

• Styleguides: konkrete Vorgaben für die visuelle Gestaltung und dasLayout einer bestimmten Benutzeroberfläche. Styleguides beschrei-ben Aussehen und Verhalten (Look&Feel) von User-Interface-Ele-menten, abhängig von der eingesetzten Technologie.

Verschiedene Arten von Guidelines

Usability Guidelines können bezüglich ihres Verwendungszwecks un-terschieden werden. Die folgende Aufzählung erleichtert Ihnen dieEinordnung, wenn Sie es mit Regelwerken im Bereich Usability zu tunbekommen:

• Gesetzliche Verordnungen: Vorschriften, die in erster Linie den Ge-sundheitsschutz des Arbeitnehmers beim Umgang mit technischen


(Bildschirm-)Geräten bezwecken. Es mag Sie vielleicht überraschen,dass Aspekte der Benutzerfreundlichkeit gesetzlich geregelt sind, ei-ne nachweisbare Missachtung könnte für einen Arbeitgeber allerdingsunerfreuliche Konsequenzen haben. Im EU-Raum diesbezüglich re-levant ist die Richtlinie 90/270/EWG [EG 90], die unter anderemVorschriften zu Mindestanforderungen an die Mensch-Maschine-Schnittstelle beinhaltet.

• Normen: Nationale oder internationale Normen mit dem Ziel, durchGestaltungsvorgaben die Anwendung von Technologien zu standardi-sieren und für die Benutzer zu vereinfachen. Prominentestes Beispielist die internationale ISO-Norm 9241, die „Ergonomische Anforde-rungen für Bürotätigkeiten mit Bildschirmgeräten“ definiert [DIN ENISO 9241, 1997–2012]. Häufig verwendet werden die in Tab. 3.8aufgeführten sieben Kriterien, die ein benutzerfreundliches Dialog-system auszeichnen.

• Regelsammlungen: mehr oder weniger umfangreiche, meist frei ver-fügbare Sammlungen von Regeln, um die Entwicklung von UserInterfaces zu optimieren. Darunter fallen allgemeine Usability-Prin-zipien, z. B. Nielsens Usability Heuristics [Nielsen 93] oder dieGoogle User Experience Principles [Google 12] sowie konkrete Re-geln zu einem bestimmten Anwendungsgebiet. So gibt es „Do’s andDon’ts“ für mobile Anwendungen oder „goldene Regeln“ für gu-tes Webdesign. Diverse Sammlungen sind als Bücher erhältlich, z. B.[Johnson 07].

• User Interface Patterns: der Versuch, häufig auftretende oder ähnlicheDesignprobleme in Mustern zu beschreiben und bewährte Lösungs-ansätze zu bieten. Mittlerweile sind im GUI-Bereich einige hilfreichePatterns-Sammlungen zu finden, z. B. [Tidwell 11, Scott et al. 09].Typischerweise sind die beschriebenen Patterns auf eine bestimmteGUI-Technologie bezogen. Die Abgrenzung zu Elementsammlungen,wie sie häufig in Styleguides verwendet werden, ist in der Praxis des-halb oft nicht eindeutig.

• Hersteller- oder plattformabhängige Styleguides: beschreiben dasvorgesehene Look&Feel der Applikationen eines bestimmten Be-triebssystems mit dem Ziel einer konsistenten Anwendung aller GUI-


Elemente wie Eingabefelder, Listboxen, Schaltflächen etc. Gute undnützliche Beispiele sind die Apple Human Interface Guidelines [Ap-ple 00–12] bzw. [Apple 08–12] und die Windows User ExperienceInteraction Guidelines [Microsoft 05–10].

• Unternehmens-Styleguides: Vorgaben, welche die verschiedenen Ap-plikationen eines Unternehmens bezüglich Look&Feel sowie Corpo-rate Design erfüllen sollen. Dabei ist zu unterscheiden, ob es sich umRichtlinien für die firmeninterne Applikationslandschaft handelt oderum Anwendungen bzw. Produkte für externe Kunden. Auf den Ein-satz von Unternehmens-Styleguides wird in Abschn. 5.3 noch nähereingegangen.

• Projekt-Styleguides: Richtlinien, welche die Konsistenz der Benut-zerschnittstelle bei der Entwicklung einer Applikation (z. B. beimEinsatz verschiedener UI Designer) oder von Produkten für denEndkunden sicherstellen. In manchen Fällen müssen auch neue Be-dienelemente definiert und beschrieben werden (z. B. für neuartigeConsumer-Produkte).

Abbildung 3.11 zeigt ein Beispiel aus einem Styleguide. Zur Auswahlaus längeren Listen wird eine sortierbare Tabelle eingesetzt. Dieses GUI-Element sieht in jeder Anwendung gleich aus und verhält sich immerkonsistent. Schrift und Kontrast wurden auf Lesbarkeit am Bildschirmoptimiert, die Sortierfunktion ist intuitiv verständlich. Die Farbgebungentspricht dem Corporate Design des Unternehmens, die technische Um-setzbarkeit ist gewährleistet.

Die Verwendung vonUsability Guidelines

Das Wichtigste vorneweg: Selbst wenn Sie alle relevanten Regeln einhal-ten würden, könnten Sie noch immer eine für die Anwender unbrauch-bare Lösung entwerfen. Mehr und mehr setzt sich die Erkenntnis durch,dass Zielgruppe und Nutzungskontext über die tatsächliche Qualität ei-ner Benutzerschnittstelle entscheiden.


Abb. 3.11 In Styleguides werden User-Interface-Elemente definiert und beschrieben,die bei der Entwicklung einer neuen Anwendung eingesetzt werden sollen

Usability Guidelines stellen in erster Linie ein Hilfsmittel für eineinheitliches und regelkonformes User Interface Design dar. Die Berück-sichtigung von Richtlinien erleichtert dem Benutzer später die Anwen-dung, indem er auf bekannte Elemente trifft, die sich immer konsistentverhalten. Die Entscheidung, ob ein Regelwerk oder eine bestimmteVorgabe für die vorliegende Anwendung und eingesetzte Technologietatsächlich relevant ist, bedingt allerdings gute Fachkenntnisse. Die blin-de Einhaltung von Vorgaben kann sonst schnell zu einem unnötigen„Klotz am Bein“ werden und gute Usability schlussendlich sogar ver-hindern.


Meist reicht es nicht aus, bestehende Regelsammlungen einzusetzen,weil diese nicht oder zu wenig auf die spezifische Situation zutreffen.Die Erstellung eines Styleguides, der die eingesetzten GUI-Elemente de-finiert und beschreibt, ist in einem größeren Projekt ein Instrument, umeine einheitliche Funktionsweise für die Anwender sicherzustellen. Zu-dem können zu einem frühen Zeitpunkt die Rahmenbedingungen für dasUser Interface Design gesetzt werden. Es ist zum Beispiel ein wesent-licher Unterschied, ob hoch effiziente Controls zur Unterstützung vonExpertenbenutzern oder einfache, selbsterklärende Bedienelemente fürGelegenheitsbenutzer zum Einsatz kommen.

Gut erarbeitete, visuell und technisch abgestimmte Styleguides sindeine wertvolle Hilfe für die Entwickler. Statt das Rad jedes Mal neuzu erfinden, können sie ausgearbeitete Elemente verwenden, die denAnsprüchen bezüglich Ergonomie, Ästhetik, Corporate Design und tech-nischer Umsetzbarkeit genügen.

Der Einsatz eines Styleguides in einem größeren Projekt oder Un-ternehmen hat auch eine organisatorische Komponente. Indem User-Interface-Elemente mit einem Namen vergeben, beschrieben und allenBeteiligten bekannt sind, können sowohl die Anforderungen an das UserInterface als auch die technischen Restriktionen früher adressiert werden.In Abschn. 5.3 „Usability-Standardisierung“ wird noch näher beleuchtet,wie der Einsatz von Styleguides den benutzerorientierten Prozess in ei-nem Unternehmen unterstützen kann.

Die Problematik des Detaillierungsgrads

Je konkreter Usability Guidelines verfasst sind, umso enger wird de-ren Gültigkeitsbereich. Es kann zum Beispiel sinnvoll sein, detaillierteStyleguides für eine bestimmte Applikation zu erstellen, welche dieBenutzeroberfläche genau beschreiben. Diese Regeln sind allerdingsnicht einfach auf andere Anwendungen übertragbar. Umgekehrt kann esnützlich sein, generelle Usability-Richtlinien zu verfassen, die weitge-hend technologieneutral und anwendungsübergreifend gelten. Wie diese


Richtlinien im konkreten Fall dann allerdings eingehalten werden, bleibtdem jeweiligen User Interface Designer oder Entwickler überlassen.

Häufig entstehen Probleme, wenn zu detaillierte Styleguides mit einerkonkreten Anwendung im Hinterkopf erstellt werden. Die Richtlinienwerden in Unternehmen oft „offiziell abgesegnet“ und gelten zukünftigfür weitere Anwendungen als strikte Vorgabe, zum Beispiel für exter-ne Entwicklungs-Teams. Dies führt dazu, dass unter Umständen Regelneingehalten werden müssen, die im vorliegenden Fall gar keinen Sinn er-geben oder sogar kontraproduktiv sind. Es ist deshalb genau abzuwägen,welcher Detaillierungsgrad in einem spezifischen Fall anzustreben ist.Eine Abbildung eines beispielhaften Benutzerdialogs mit Erklärungenist vielfach effektiver als die ausschließliche Formulierung von Regeln.Ein Beispiel kann auch leichter abstrahiert und auf andere Anwendungs-situationen übertragen werden.

Was sollte ein guter Styleguide regeln?

Als Hilfestellung für die Erstellung eines eigenen Styleguides oder alsReferenz, falls Sie einen Styleguide in Auftrag geben müssen, ist es nütz-lich zu wissen, welche Informationen im Werk enthalten sein sollten:

• Technologische Rahmenbedingungen und Zielgruppe: Auf welcheSysteme bezieht sich der Styleguide? Wer ist der Empfänger des Re-gelwerks?

• Software-Ergonomie: Allgemeingültige Regeln, die im konkreten Fallzu berücksichtigen sind (z. B. Anzahl Menü-Einträge) sowie auch Re-geln bezüglich der spezifischen Zielgruppe und Anwendung (z. B.vollständig über die Tastatur bedienbare Dialoge).

• Grundsätzlicher Aufbau: Vorgaben für den Aufbau einer Applikation,z. B. Titelleiste, Ribbons, Navigation-, Arbeits-, Hilfe- und Statusbe-reich, sowie Dialogtypen.

• Anzeigegeräte und Anordnung: Definition, wie der Aufbau abhängigvon Bildschirmgröße und Bildschirmauflösung zu gestalten ist.

• Eingabemedien: Welche Eingabemedien wie Tastatur, Touch, Stift,Gesten und Maus verwendet werden und für welchen Zweck.


• Anwendungsregeln: Welche GUI-Elemente für welche Situation ver-wendet werden. Dies gilt sowohl für die Basis-Elemente des Be-triebssystems (z. B. wann werden Radio Buttons, wann Listboxeseingesetzt) als auch für zusammengesetzte Elemente (z. B. sortierba-re Tabellen, Wizards) und insbesondere für neu definierte Elemente(z. B. Kalender-Pop-up zur Datumsauswahl).

• Verhalten der GUI-Elemente: Beschreibung der Reaktion des Systems(z. B. Selektion eines Eintrags, Deaktivierung von Controls).

• Navigation: Beschreibung der Navigationselemente (z. B. Einsatz vonMenus, Links, Buttons).

• Visuelles Design: Farbschema, Kontraste, Schriften, Layout, Abstän-de, Icons etc. Hier werden auch Corporate-Design-Aspekte referen-ziert.

• Technische Umsetzbarkeit: Hinweise auf die technische Umsetzung,z. B. Referenz auf verfügbare GUI-Komponenten.

• Terminologie: Begriffe und Bezeichnungen der Benutzeroberfläche,wie wird der Benutzer angesprochen, welche Fachbegriffe werdenverwendet, Formulierung von Fehlermeldungen.

• Tastaturbedienung: Shortcuts, Kommandos, Tabulator-Reihenfolge,Default Buttons in einem Dialog.

Checkliste für den Einsatz von Styleguides

• Müssen für Ihre Anwendung bestimmte Normen oder gesetzliche Vor-gaben bezüglich der User-Interface-Gestaltung eingehalten werden?

• Gibt es bestehende Regelwerke, z. B. Regelsammlungen oder proprie-täre Styleguides als Hilfestellung?

• Lohnt sich die Entwicklung eines eigenen Projekt-Styleguides?• Sind die eingesetzten Usability Guidelines auf einer angemessenen

Detaillierungsebene?• Werden im Styleguide Aspekte beschrieben, die eher in die Spezifika-

tion gehören?• Könnte durch den Einsatz eines durchgängigen Styleguides die Kom-

munikation in Ihrem Projekt oder im Unternehmen erleichtert wer-den?

3.7 Auf dem Prüfstand: Usability Testing 79

In Kürze

Methode Usability Guidelines und Styleguides

Resultate Regelkonformes User Interface DesignEinheitliche Funktionsweise für die AnwenderAnforderungen an die Benutzeroberfläche adressiertHilfe für die User-Interface-Entwickler

Vorgehen Verwendung vorhandener Regelsammlungen oder Erarbeitungeines Projekt-Styleguides

Aufwand Abhängig von Umfang und DetaillierungsgradSammlung der relevanten Usability Guidelines: 1–2 PTErarbeitung eines vollständigen Projekt-Styleguides nicht unter10 PTUnternehmens-Styleguides: nicht unter 100 PT

Beteiligte Analyst, User Interface DesignerPlanung Nach Aufnahme der Benutzeranforderungen, vor Implementie-

rung der Benutzerschnittstelle

3.7 Auf dem Prüfstand: Usability Testing

Vermutlich haben Sie schon davon gehört, dass Software und Produkte insogenannten Usability Labs geprüft werden können. Vielleicht hatten Siesogar schon selbst dazu Gelegenheit, einem Usability-Test als Zuschau-er oder Testperson beizuwohnen. Obwohl man Usability-Labore nun seitgut 20 Jahren auch im deutschen Sprachraum findet, ist deren Bekannt-heitsgrad noch immer relativ klein, und die Wenigsten wissen, was sichbei einem solchen Test genau abspielt. Wir wollen deshalb den typischenAblauf eines formalen Usability-Tests aufzeigen, um danach auch kurzauf andere, weniger formale Methoden einzugehen.

Der formale Usability-Test

Zunächst müssen Auftraggeber und Testleiter das Ziel des Usability-Tests klären. Fachleute unterscheiden zwischen formativer Evaluation,


die eine Verbesserung des geprüften Systems zum Ziel hat, und sum-mativer Evaluation, die ein Produkt im Sinne einer Qualitätskontrollezusammenfassend prüft.

Als Vorbereitung für eine Usability-Testserie stellen Testleiter undAuftraggeber die Aufgaben zusammen, die von den Testpersonen mitder zu prüfenden Applikation bearbeitet werden sollen. Um ein gewis-ses Maß an Vergleichbarkeit zu erreichen, sind diese Aufgaben für jedeTestperson dieselben. Man spricht deshalb auch von Standardaufgaben.Die Qualität der Ergebnisse eines Usability-Tests hängt wesentlich vonder Ausarbeitung dieser Aufgaben ab. Im Kap. 1 wurde aufgezeigt, dassdie Usability einer neuen Lösung davon abhängt, wie gut die Abläu-fe für die Benutzer unterstützt werden. Die Erarbeitung relevanter undaus Benutzersicht realistischer Aufgaben sollte deshalb mit großer Sorg-falt durchgeführt werden. Wurden bereits Anwendungsszenarien erstellt,dienen diese als Grundlage (siehe Abschn. 3.2). Ein guter Testleiter wirdauf die Einhaltung folgender Kriterien für die Standardaufgaben achten,die Sie als Auftraggeber kontrollieren sollten:

• Die Aufgabenstellung ist ein aus Benutzersicht realistisches Szenariound könnte sich tatsächlich so abspielen.

• Es wird ein Ziel aus Sicht des Anwendungsgebietes formuliert, keinetechnische Anleitung zur Erfüllung dieses Zieles. Zum Beispiel: „Siesuchen nach einer passenden Farbe für . . . “ ist besser als „setzen Siedie Filterkriterien auf gelb und rosa“.

• Die Aufgaben stellen für die Testpersonen einen mittleren Schwierig-keitsgrad dar. Sie sollten lösbar, jedoch nicht zu trivial sein.

• Begriffe und Bezeichnungen, welche in der Applikation vorkommen,sind zu vermeiden. Zum Beispiel: „Sie überweisen den Betrag von. . . “ ist neutraler als „gehen Sie im Menü auf Einzahlungen“.

Neben den Aufgaben für den Test muss auch das zu prüfende Systemselbst bzw. der Prototyp entlang der beabsichtigten Anwendungsszenari-en vorbereitet werden. Dies kann zum Beispiel bedeuten, dass bestimmteSystemzustände oder Ausgaben abgebildet werden müssen, um der Test-person den Eindruck eines möglichst realistischen, lauffähigen Systemszu vermitteln.

Für eine Usability-Testserie sollten Testpersonen eingeladen werden,die möglichst aus der Benutzergruppe der zu prüfenden Applikation


stammen, d. h. tatsächlich zu den späteren Benutzern gehören oder ge-hören könnten. Während dies bei Consumer-Produkten oder Internet-Anwendungen vielleicht auch die Sekretärin oder die Mitarbeiter ausdem Nachbarbüro sein können, ist es für spezialisierte Anwendungenunerlässlich, die entsprechenden Fachleute zu rekrutieren.

Die notwendige Anzahl Testpersonen hängt im Wesentlichen von denZielen des Tests ab. In der Regel genügen fünf bis sieben Testperso-nen, um die wichtigsten Anwendungsszenarien einer Applikation anhandeines Prototyps zu prüfen und gezielte Verbesserungsmaßnahmen einzu-leiten. Sollen dagegen mit großer Sicherheit sämtliche Stolpersteine vorder Einführung einer Anwendung ausgeräumt werden, sind weitere Test-serien notwendig (mehr dazu in Abschnitt „Wie viele Testpersonen sindnotwendig?“ weiter unten in diesem Kapitel).

In manchen Fällen kann es sinnvoll sein, dass die Testpersonen ei-ne kurze Schulung oder Einführung in die Applikation erhalten, zumBeispiel wenn es sich um Expertenbenutzer handelt, die nach einer Ein-arbeitsphase eine hocheffiziente Applikation bedienen sollen. Handeltes sich dagegen um Gelegenheitsbenutzer, etwa für eine Consumer-An-wendung, sollte die Applikation selbstverständlich nicht zuerst erklärtwerden.

Der Testleiter führt jede Testperson in die Ziele und den Ablauf desUsability-Tests ein, und es werden Spielregeln vereinbart:

• Die Testperson darf den Test jederzeit unterbrechen bzw. abbrechen.• Die Testperson wird meist gebeten, laut zu denken, d. h. ihre Arbeit

für die Beobachter zu kommentieren.• Sollte die Testperson mit einer Aufgabe nicht mehr weiterkommen,

kann sie selbstständig zur nächsten Aufgabe weitergehen.• Die Beobachter melden sich nur, wenn wirklich notwendig. Sie soll-

ten den Testverlauf möglichst nicht beeinflussen. Eine Konversationerfolgt kontrolliert, zum Beispiel über eine Gegensprechanlage.

Während der eigentlichen Testphase arbeitet die Testperson in einem spe-ziell eingerichteten Testraum mit der zu prüfenden Applikation gemäßden Aufgaben. Abbildung 3.12 zeigt den Aufbau eines typischen Usabi-lity Labs.

Als Beobachter sollten Vertreter des Auftraggebers, Entwickler undUsability-Experten teilnehmen. Testleiter und Beobachter verfolgen die


Abb. 3.12 Schematische Darstellung mit den wichtigsten Elementen eines UsabilityLabs. Die Benutzer bearbeiten im Testraum Aufgaben mit dem neuen Produkt. DieBeobachter protokollieren Schwachstellen. Die Interaktion mit der Benutzerschnitt-stelle wird zur späteren Analyse auf Video aufgezeichnet

Abb. 3.13 In Usability-Testskönnen UI-Prototypen einge-setzt werden, um Usability-Probleme frühzeitig zu erken-nen und das User Interface zuverbessern

Arbeit aus einem separaten Raum, der häufig durch eine Glasscheibe ab-getrennt ist. Der Bildschirm bzw. das zu prüfende Produkt sowie häufigauch das Gesicht der Testperson und die Situation als Ganzes werden aufVideo aufgezeichnet. Abbildung 3.13 zeigt eine solche Sicht.

Die Beobachter protokollieren unklare und problematische Situatio-nen oder Fehler, die sich in der Anwendung mit der Applikation ergeben.Die Testphase sollte nicht länger als etwa eine Stunde dauern.


In einer Nachbesprechung analysieren die Beobachter die entspre-chenden Stellen im Video nochmals mit der Testperson. Dabei werdenbereits erste Möglichkeiten für Verbesserungsmaßnahmen besprochen.In jedem Fall sollte die Testperson dazu Gelegenheit haben, das Erlebtein einem kurzen Interview oder frei zu kommentieren. Oft ergeben sichgerade aus eher informellen Situationen wertvolle Hinweise.

Die Feststellungen und Verbesserungsvorschläge werden in einemTestbericht festgehalten. Die Resultate hängen einerseits von der Erfah-rung von Testleiter und Beobachter ab und anderseits von der Zeit, die fürdie Ausarbeitung von Verbesserungsvorschlägen zur Verfügung steht. Esist deshalb lohnenswert, das Ergebnis vorher zu vereinbaren. Wiederumgibt es einige formale Kriterien, die ein guter Testbericht erfüllen sollte:

• Gute wie schlechte Ergebnisse werden aufgeführt.• Für jede Schwachstelle bzw. Verbesserungsmaßnahme wird ein

Schweregrad angegeben.• Die Schwachstellen sind mit Screenshots illustriert.• Die Standardaufgaben sowie eine Beschreibung der Testpersonen

werden angefügt.• Es wird klar zwischen beobachteten Problemen und persönlichen

Meinungen und Vorschlägen unterschieden.

Stärken und Schwächen des Usability-Tests

Lange Zeit galt der formale Usability-Test als die Königsmethode imUsability Engineering, und tatsächlich hat die Methode auch einige Stär-ken:

• Unter Laborbedingungen können Schwachstellen der Benutzerober-fläche eindeutig nachgewiesen werden.

• Methodische Gütekriterien wie Objektivität, Reliabilität und Validi-tät können weitgehend eingehalten werden (siehe auch „Hintergrund:Methodische Gütekriterien“).

• Die Beobachtungssituation in einem Usability Lab ist optimal, die Be-obachter können sich ein gutes Bild über die Stärken und Schwächeneiner neuen Lösung machen.


• Die Beteiligten werden dazu gezwungen, einem Benutzer zuzusehen,ohne in das Geschehen einzugreifen. Jeder Usability-Testleiter wirdIhnen versichern, dass die Scheibe zwischen Test- und Beobachtungs-raum vor allem dazu da ist, die Beobachter davon abzuhalten, demBenutzer zu helfen.

• Schwierigkeiten in der Anwendung werden schnell deutlich.• Die Methode ist für alle Beteiligten gut sichtbar. Die Bedeutung von

Usability Engineering wird unmittelbar ersichtlich.

Die Schwächen der Methode sind die folgenden:

• Eine formale Usability-Testserie ist aufwändig. Es muss genügendZeit für die Ausarbeitung der Aufgaben, die Vorbereitung des zuprüfenden Systems, die Rekrutierung der Testpersonen, die Durch-führung der Testreihe in einem Usability Lab und nicht zuletzt dieErarbeitung von Verbesserungsvorschlägen und das Verfassen einesTestberichts eingesetzt werden.

• Die Methode kommt im Allgemeinen relativ spät zum Einsatz. Proto-typen müssen so weit vorbereitet sein, dass die Testpersonen selbst-ständig damit arbeiten können.

• Es besteht die Gefahr, dass der Testbericht mit wertvollen Resultatennach dem Test in der Schublade des Auftraggebers verschwindet, weilKenntnisse oder Mittel für Verbesserungsmaßnahmen fehlen. Es istdeshalb notwendig, dass Testleiter, Auftraggeber und Entwickler dieSchwachstellen zusammen besprechen und priorisieren. Es kann unterUmständen sogar sinnvoll sein, auf einen ausführlichen Bericht zuverzichten und die Zeit direkt in Lösungsvorschläge zu investieren.

Hintergrund:Methodische GütekriterienIn der Testtheorie verwendet man eine Reihe von Gütekriterien, anhand derer Aus-sagen über die Qualität eines Messinstruments in einer bestimmten Untersuchunggemacht werden. Die Kenntnis dieser Gütekriterien ist auch für die Anwendung vonUsability-Methoden von Relevanz, besonders wenn es um die Evaluation von Syste-men geht. Als Hauptgütekriterien werden unterschieden:

• Objektivität: Die Resultate der Untersuchung sollen unabhängig von den Rah-menbedingungen sein. Ein wichtiger Aspekt ist dabei die Unabhängigkeit von derdurchführenden Person, die als Testleiterunabhängigkeit bezeichnet wird.


• Reliabilität: Bei wiederholter Anwendung unter gleichen Bedingungen soll dasInstrument zu gleichen Resultaten kommen.

• Validität: Das Instrument soll das messen, was es vorgibt, in unserem Fall alsodie Usability eines Systems und nichts anderes. Dies kann zum Teil durch dieAusschaltung von ungewollten Einflüssen erreicht werden (interne Validität). VonBedeutung ist indessen auch die Generalisierbarkeit der Ergebnisse (externe Va-lidität). Sie kann durch eine Erhöhung der Anzahl befragter Personen und eineÜberprüfung mit anderen Methoden gesteigert werden.

Alternativen zum formalen Usability-Test

Der Usability Walkthrough ist eine Alternative zum formalen Usabil-ity-Test. Statt eine Testperson unter kontrollierten Bedingungen in einemseparaten Testraum allein arbeiten zu lassen, begleitet der Testleiter denBenutzer und moderiert den Testablauf. Wie beim formalen Test bear-beitet der Benutzer realistische Aufgaben mit dem zu prüfenden System,aber der Moderator hat die Möglichkeit, direkt einzugreifen, Fragen zustellen und bestimmte Abläufe mit dem Benutzer durchzugehen. Dieskann, muss aber nicht in einem Usability Lab durchgeführt werden. Die-se Methode eignet sich besonders gut, um früh im Prozess noch unfertigePrototypen zu evaluieren, ohne dass schon ein lauffähiges System vor-handen wäre. Es ist selbstredend, dass die Testleiterunabhängigkeit beidieser Spielart nicht mehr gegeben ist und der Moderator sehr genauwissen muss, wie er den Benutzer anleiten kann, ohne ihn zu stark zubeeinflussen.

Als mobiles Usability Lab wird eine mobile Einrichtung zur Durch-führung von Usability-Tests vor Ort anstatt in einem Labor bezeichnet.Statt das User Interface auf Video aufzuzeichnen, verwenden heuteviele Testleiter spezielle Programme, die eine Aufzeichnung der Be-nutzerinteraktion auf dem Testcomputer selbst auf Harddisk erlauben.Ausgestattet mit einem Laptop und einer Webcam lassen sich auf dieseWeise Usability-Testserien ohne die Kosten eines Usability Labs durch-führen. Nutzen und Resultate hängen aber stark von der Erfahrung desTestleiters ab.


Mobile Usability-Tests sind vor allem dann angebracht, wenn bei denBenutzern vor Ort getestet werden soll, zum Beispiel an speziellen Ar-beitsplätzen oder wenn die Umgebung einen maßgeblichen Einfluss hat,beispielsweise bei öffentlichen Terminals wie Ticketautomaten in Bahn-höfen oder Bankomaten im Freien. Fachleute sprechen dann auch vonUsability-Feldtests.

Wie viele Testpersonen sind notwendig?

Stellen Sie sich vor, Sie wären ein Ladenbesitzer. Gerade haben Sie beob-achtet, wie eine ältere Dame im Eingangsbereich über eine hervorstehendeTürschwelle stolpert. Kurz darauf geschieht einem jungen Mann dasselbe.Würden Sie die Schwelle ersetzen oder warten, bis weitere Personen strau-cheln?

Kritische Usability-Probleme können ebenso deutlich sein, wenn sieim Rahmen eines Usability-Tests auftreten. Wenn zwei oder drei Test-personen an derselben Stelle der Anwendung Mühe bekunden, ist esoffensichtlich, dass ein Stolperstein vorliegt, den es auszuräumen gilt.Es ist schlichtweg nicht notwendig, eine vierte oder fünfte Testpersondabei zu beobachten. Mit anderen Worten: Um mittels Usability-TestsVerbesserungen der Benutzerschnittstelle zu erreichen, genügen qualita-tive Aussagen. Es sind keine quantitativen Untersuchungen mit vielenBenutzern erforderlich (siehe auch Abschn. 3.8 „Hintergrund: quantitati-ve und qualitative Methoden“). Trotzdem stellt sich die Frage, wie vieleTestpersonen sinnvoll und notwendig sind, um genügend Sicherheit zuerhalten, dass kritische Stellen auch aufgedeckt werden. Im Folgendenfinden Sie einige Anhaltspunkte:

• Iteratives Prototyping, Verbesserung und Anpassung auf die Benut-zerbedürfnisse, qualitative Aussagen: 4–6 Benutzer pro Iteration.Systeme mit hohen Anforderungen an die Benutzbarkeit: 7–15 Be-nutzer. Risikominimierung bei kritischen Systemen: nicht unter 15Testpersonen.

• Qualitätskontrolle vor Einführung eines Systems, quantitative Aussa-gen: abhängig von Systemumfang und Anforderungen an die Benutz-barkeit: nicht unter 10 Testpersonen.

3.8 Zahlenmaterial: Fragebögen 87

In Kürze

Methode Usability Testing

Resultate User Interface auf Usability geprüftSchwachstellen identifiziert, dokumentiert und priorisiertVerbesserungsmaßnahmen erarbeitet

Vorgehen Testen mit Benutzern anhand von StandardaufgabenAufwand Formaler Usability-Test im Labor mit 5–7 Benutzern (Vor-

bereitung, Durchführung und Auswertung): Testleiter 10 PT,Auftraggeber 5–10 PT, Testpersonen total 3–5 PTUsability Walkthrough mit 5–7 Benutzern: Testleiter 5 PT,Auftraggeber 3–5 PT, Testpersonen total 2–3 PT

Beteiligte Auftraggeber, Entwickler, Benutzer, Testleiter, BeobachterPlanung Nach der Erstellung eines ersten Prototyps

Am Ende jeder IterationVor der Einführung

3.8 Zahlenmaterial: Fragebögen

Beziehen Sie regelmäßig die neusten Studien bekannter Analysten undMarktforschungsinstitute? Für die Erhebung des zugrunde liegendenZahlenmaterials werden häufig Fragebögen benutzt. Die Methodik fürdie Erstellung und den Einsatz von Fragebögen hat ihre Wurzeln in denSozialwissenschaften, wo statistisch auswertbare Daten von Personengefragt sind, wie etwa bei der Erhebung von Einstellungen, Meinungenund Erfahrungen, oder wenn die Ergebnisse mit einer größeren Gesamt-heit verglichen werden sollen, etwa bei psychologischen Studien.

Im Usability Engineering sind Benutzerbefragungen mittels Fragebö-gen eine wichtige Methode, um Antworten von einer größeren AnzahlPersonen zu erhalten. Wenn Sie schon selber einen Fragebogen entwor-fen haben, zum Beispiel um Meinungen von Mitarbeitern oder Kundenabzufragen, dann wissen Sie, dass dies gar nicht so einfach ist. Die Zu-verlässigkeit der Aussagen hängt von der Qualität des Fragebogens, derAuswahl der befragten Personen und der richtigen Durchführung der Be-fragung ab.


Einsatz von Benutzerbefragungen

Erinnern Sie sich an die im Abschn. 2.2 vorgestellten Aufgabenbereicheim Usability Engineering? Benutzerbefragungen dienen zwei Aufgaben:Sie können sowohl zur Analyse von Benutzern und Kontext als auch zurBeurteilung der Usability eines Systems (Evaluation) eingesetzt werden.Benutzerbefragungen stellen eine Ergänzung zu den bereits vorgestell-ten Usability-Methoden dar. Der Analyst erreicht damit im Vergleich zuContextual Inquiry oder Usability-Tests eine größere Anzahl Personen.Fragebögen dienen ihm zur standardisierten Erfassung und Auszählungder Antworten.

Abhängig vom Ziel und der Fragestellung können verschiedene In-strumente eingesetzt werden. Die Palette reicht von einfachen, selbsterstellten Fragebögen bis zum Einsatz von methodisch geprüften Usa-bility-Standardfragebögen.

Für die Durchführung einer Benutzerbefragung kommen verschiede-ne Befragungsformen in Betracht: Ein Fragebogen kann beispielsweiseschriftlich verschickt, online angeboten oder per Telefonbefragung aus-gefüllt werden.

Der Einsatz von Fragebögen erfolgt oft mit dem Ziel, für die gesamteBenutzergruppe repräsentative Aussagen zu erhalten. Da solche Unter-suchungen auf zählbare Werte abzielen, sprechen Fachleute auch vonquantitativen, im Gegensatz zu qualitativen Studien. Für sie gilt eine Rei-he von methodischen Besonderheiten, die beachtet werden müssen. Dadies mit entsprechendem Aufwand verbunden ist, sollte genau geprüftwerden, ob die vorliegende Fragestellung überhaupt mit einer quantitati-ven Befragung beantwortet werden kann.

Hintergrund: quantitative und qualitative MethodenDie empirische Forschung unterscheidet zwei grundsätzliche Ansätze zur Erkenntnis-gewinnung:

• Quantitative Studien haben zum Ziel, zahlenmäßige Ausprägungen möglichstgenau zu beschreiben. Dabei wird üblicherweise eine repräsentative Stichprobebefragt und die erhobenen Daten auf die Grundgesamtheit verallgemeinert. In derRegel wird vorher eine Hypothese festgelegt, die anhand der Ergebnisse überprüftwerden soll. Quantitative Methoden laufen typischerweise stark standardisiert ab,um möglichst gleiche Voraussetzungen für die Aussagen der Befragten zu schaf-fen.


Tab. 3.9 Vergleich zwischen quantitativen und qualitativen Forschungsansätzen.

Quantitative Forschung Qualitative Forschung

Viele Teilnehmer Wenige TeilnehmerRepräsentative Stichprobe Typische VertreterHypothesen prüfen Hypothesen bildenStandardisiert Flexibel, explorativZahlenmäßige Ausprägungen Hintergründe, ZusammenhängeGeschlossene Fragen Offene FragenStatistische Analyse InhaltsanalyseEinfache Auswertung Aufwändige AuswertungBeispiele: schriftliche Befragung,standardisiertes Telefon-Interview

Beispiele: Contextual Inquiry, Stake-holder Interview, Focus Group

• Qualitative Erhebungen zielen darauf ab, Hintergründe, Zusammenhänge und Ur-sachen festzustellen. Dabei wird auf die subjektiven Aussagen der Befragten Wertgelegt. Der Ablauf dieser Methoden ist im Vergleich zu quantitativen Verfahrenflexibel, offen und explorativ. Oft werden während der Durchführung neue Hy-pothesen generiert, um diese in einer nächsten Iteration weiterzuverfolgen. Ausqualitativen Daten kann man keine Mengenangaben ableiten.

Tabelle 3.9 stellt die beiden Ansätze gegenüber.

In keinem Fall darf ein Fragebogen als eine einfache Sammlung vonFragen verstanden werden, die man mal eben so verschickt. Die Durch-führung einer Befragung setzt voraus, dass sich der Ersteller genauüberlegt, welche Fragestellung beantwortet werden soll, wie die Unter-suchung durchgeführt wird und wie der Fragebogen dafür aufgebaut seinmuss. Methodiker sprechen auch vom Untersuchungsdesign und der Fra-gebogenkonstruktion.

Planung einer Benutzerbefragung

Zur Festlegung eines geeigneten Untersuchungsdesigns gehören einigezentrale Überlegungen:


• Welche Fragen oder Hypothesen sollen beantwortet werden? Werdenreine Fakten erhoben, soll ein System beurteilt oder ein Vergleichdurchgeführt werden?

• Wie ist der zeitliche Ablauf der Untersuchung? Wird nur einmal er-hoben, werden die Aussagen verschiedener Gruppen verglichen oderwerden die gleichen Benutzer in Abständen mehrmals befragt?

• Wie erfolgt die Auswahl der zu befragenden Benutzer: als zufälligeStichprobe oder nach bestimmten Kriterien?

• Wie viele Personen müssen befragt werden, um statistisch genügendgesicherte Aussagen machen zu können?

• Mit welchen Instrumenten wird die Untersuchung durchgeführt? Wirdein bestehender Fragebogen eingesetzt oder wird dieser erstellt?

Fragebogenkonstruktion

Konstruktion und Einsatz eines Fragebogens müssen methodisch korrekterfolgen, um aussagekräftige Ergebnisse zu erhalten. Dies gilt auch füreinfache Umfragen mit wenigen Fragen. Bevor die Erstellung eines eige-nen Fragebogens ins Auge gefasst wird, sollte deshalb abgeklärt werden,ob nicht Standardfragebögen für die Fragestellung verfügbar sind. Fürdie Konstruktion von eigenen Fragebögen zu statistisch zuverlässigenAussagen lohnt sich in jedem Fall das Hinzuziehen eines Fragebogen-Experten.

Die folgenden methodischen Aspekte sind sowohl für die Erstellungeines eigenen Fragebogens als auch bei der Auswahl eines Standardfra-gebogens relevant:

• Soll mit offenen oder geschlossenen Fragen gearbeitet werden? Beioffenen Fragen können die Benutzer freie Antworten formulieren, beigeschlossenen wird aus vorgegeben Antworten ausgewählt. OffeneFragen erlauben es, eine Frage in der Breite auszuleuchten; sie sindallerdings in der Auswertung aufwändiger als geschlossene Fragen.Offene Fragen sind deshalb für qualitative Untersuchungen besser ge-eignet, während geschlossene Fragen eher für quantitative Studienverwendet werden.

• Kommen Skalen (z. B. Werte von 1–7) zum Einsatz? Was bedeutendie Skalen (z. B. einverstanden – nicht einverstanden, Note 1–6)? Dies


ist von Bedeutung im Hinblick auf die Auswertung und Interpretationder erhobenen Werte.

• Wie erfolgt die Instruktion zum Ausfüllen des Fragebogens?• Sind alle Fragen für die Zielgruppe verständlich? Ein Fragebogen

sollte immer an einer Versuchsstichprobe getestet werden.• Wie lange dauert das Ausfüllen des Fragebogens? Die Abbruchquote

steigt, und die Antwortqualität sinkt mit der Länge eines Fragebogens.Diese Effekte sind bei Online-Befragungen noch ausgeprägter als beischriftlichen Fragebögen.

Für die methodischen Details zur Durchführung von Fragebogen-Un-tersuchungen sei an dieser Stelle auf die einschlägige Fachliteraturverwiesen, z. B. [Bortz et al. 06].

Analyse von Benutzern und Kontext

Fragebögen können zur Analyse der Benutzer und des Kontexts der An-wendung eingesetzt werden und damit zur Klärung der Anforderungenan eine neue Lösung beitragen. Da es in der Anforderungsanalyse meistdarum geht, ein neues Gebiet in seiner Breite auszuloten, Details dertäglichen Arbeit zu erfassen oder Ursachen und Zusammenhänge zuerkunden, ist dies zunächst einmal die Domäne von qualitativen Me-thoden. Ergänzend zur Durchführung von Contextual Inquiry, Interviewsoder Beobachtungen kann es indessen erwünscht sein, bestimmte Aspek-te mit einem größeren Benutzerkreis abzuklären oder Aussagen gezieltzu erhärten. Eine sinnvolle Anwendung wäre beispielsweise, die Be-nutzer zunächst mit offenen Fragen nach Vorlieben und Problemen mitbestehenden Systemen zu fragen und damit erste Hinweise für Verbesse-rungsmaßnahmen zu sammeln und diese in einem zweiten Schritt mittelseiner Beurteilungsskala bewerten zu lassen.

Fragebögen können auch eingesetzt werden, um Fakten über Benutzerund Anwendung zu erheben, die im Hinblick auf die Anforderungen andie neue Lösung relevant sind:

• Alter, Geschlecht, Ausbildung und Erfahrung der Benutzer,• Rollen, Aufgaben, Tätigkeiten,• Häufigkeit, zeitliche und örtliche Verteilung der Anwendung,


• Vorhandene technische Ausstattung, z. B. Betriebssystem, Bild-schirmgröße und -auflösung, Browserversion, vorhandene Appli-kationen usw.

In Marktbefragungen für neue Produkte wird manchmal auf diese Weiseversucht, Auskunft von den zukünftigen Benutzern über die erwünschteFunktionalität oder die Notwendigkeit bestimmter Features zu erhal-ten. Die Möglichkeiten solcher Befragungen sind allerdings begrenzt.Können sich die befragten Personen beispielsweise nicht ganz genauvorstellen, worum es bei der neuen Lösung geht, sind die Antwortenirreführend oder wertlos. Auch die Schwierigkeiten, die sich aus den ge-wünschten Funktionen ergeben, können die Benutzer kaum abschätzen.Sie entstehen erst in der Anwendungssituation.

Beurteilung der Usability: Standardfragebögen

Usability-Standardfragebögen sind Instrumente zur Beurteilung der Usa-bility von Systemen, die gekauft werden können oder sogar frei ver-fügbar sind. Sie können mit relativ wenig Aufwand zur Evaluation vonlauffähigen Prototypen, zur Identifikation von Schwachstellen oder alsQualitätskontrolle bei produktiven Systemen eingesetzt werden.

Die Beurteilung durch die Benutzer erfolgt dabei nach bestimmtenKriterien. Verbreitete Standardfragebögen zur Beurteilung der Usabilityvon Software sind der IsoMetrics [Willumeit et al. 96], der in der aktu-ellen Version 75 Fragen (Items) umfasst, und der ISONORM 9241/10[Prümper et al. 97] mit insgesamt 35 Fragen. Beide Fragebögen verwen-den die Dialogkriterien der ISO-Norm 9241-10 (siehe auch Abschn. 3.6).

Der ISONORM 9241/10 wurde auch in eine Online-Befragung um-gesetzt [Richter 99] und stellt damit ein einfaches Mittel zur Beurteilungvon Internet-Anwendungen dar. Abbildung 3.14 zeigt einen Ausschnittdieser Online-Version.

Die Bearbeitung des Fragebogens dauert etwa 20 Minuten. Die Aus-wertung erfolgt im Sinne einer Gesamtbeurteilung der Usability über dieDurchschnittswerte aller Fragen oder auf Ebene der einzelnen ISO-Kri-terien. So lassen sich beispielsweise erste Hinweise auf Schwachpunktefinden. Tabelle 3.10 zeigt ein Beispiel einer Auswertung mit Mittelwertx und Standardabweichung s (Werte 1–7).


Abb. 3.14 Der ISONORM 9241/10 ist ein Standard-Fragebogen zur Beurteilung derUsability einer Anwendung durch deren Benutzer. Der Fragebogen basiert auf densieben Dialogkriterien der ISO Norm 9214-10. Die Abbildung zeigt einen Ausschnittdes Kriteriums „Aufgabenangemessenheit“

Tab. 3.10 Auswertung einer Benutzerbefragung mit dem Fragebogen ISONORM9241/10

ISO-Kriterium x s

Aufgabenangemessenheit 4,76 0,88Selbstbeschreibungsfähigkeit 5,20 0,87Steuerbarkeit 4,64 1,05Erwartungskonformität 4,95 0,96Fehlertoleranz 4,76 0,97Individualisierbarkeit 3,76 1,22Lernförderlichkeit 5,48 1,06ISO-Gesamtbeurteilung 4,80 0,75

Auch zur Beurteilung der User Experience gibt es standardisierte Fra-gebögen, wie z. B. den UEQ (User Experience Questionnaire) [UEQ 12].Der UEQ erfasst die sechs Dimensionen Attraktivität, Durchschaubar-keit, Verlässlichkeit, Effizienz, Steuerbarkeit und Originalität.

Ein wichtiger Aspekt bei Standardfragebögen ist die Vergleichbarkeitder Daten. Dadurch, dass jede Person dieselben Urteilsskalen ausfüllt,können die Ergebnisse verdichtet, statistisch ausgewertet und die Aus-sagen miteinander verglichen werden. Standardfragebögen sind deshalbein geeignetes Mittel, um Vergleiche anzustellen, zum Beispiel wenn die


Benutzbarkeit zweier verschiedener Prototypen, die Aussagen von un-terschiedlichen Benutzergruppen oder die Beurteilung eines Systems zuverschiedenen Zeitpunkten untersucht werden soll.

Für die Interpretation der Resultate ist es wichtig zu wissen, dass beider Beurteilung mittels Fragebögen folgende generelle Urteilsfehler auf-treten können:

• Bei der Beurteilung der Software besteht die Gefahr, dass die Beur-teiler nicht zwischen den einzelnen Kriterien differenzieren, sondernsich von ihrem Gesamteindruck der Software beeinflussen lassen(Halo-Effekt).

• Das zu beurteilende Objekt kann systematisch zu niedrig oder zu hocheingestuft werden (Milde-Härtefehler). Die Gründe dafür könnenvielfältig sein und beispielsweise mit Ablehnungen oder Vorlieben zutun haben.

• Es besteht eine gewisse Tendenz, alle Kriterien im mittleren Bereicheiner Urteilsskala einzustufen (zentrale Tendenz). Ist dieser Effektausgeprägt, kann dies ein Hinweis auf eine mangelnde Kenntnis deszu beurteilenden Objekts sein.

Kannman Usability messen?

In der Praxis taucht hin und wieder die Frage auf, ob und wie mandie Usability von Systemen oder Produkten messen kann. Damit ließensich unterschiedliche Produkte miteinander vergleichen oder Qualitäts-prüfungen durchführen. Nicht zuletzt wäre eine hohe, mit anerkanntenInstrumenten gemessene Usability auch ein gutes Verkaufsargument.Nicht selten werden Vergleiche publiziert, die auf Ergebnissen aus Usa-bility-Tests oder Expertenmeinungen basieren. Genügt das? Wie müssteein solches Instrument zur Messung der Usability aussehen?

Halten wir uns nochmals die Definition aus Kap. 1 vor Augen: EinMensch-Computer-System setzt sich zusammen aus dem Benutzer, demWerkzeug (System), der Aufgabe und dem Umfeld. Eine ganzheitli-che Bewertung der Usability ist nur unter Berücksichtigung aller vierKomponenten möglich, sollte also mit tatsächlichen Benutzern in deren


Umfeld stattfinden. Weiter muss eine genügend hohe Anzahl Fälle vor-handen sein, um statistisch signifikante Aussagen machen zu können.Ein gutes Messinstrument muss außerdem den testtheoretischen Güte-kriterien genügen (siehe auch Abschn. 3.7, „Hintergrund: MethodischeGütekriterien“). Und schließlich muss für die Interpretation genügendVergleichsmaterial verfügbar sein, um überhaupt eine Aussage über dieHöhe der gemessenen Werte machen zu können („das Produkt erreichtden Wert 6,5“).

Qualitative Evaluationsmethoden wie Usability-Tests oder Experten-Reviews liefern wichtige Ergebnisse für die Entwicklung und interessan-te Vergleiche, was in den meisten Fällen auch genügt. Für eine Messungvon Usability sind sie hingegen nicht geeignet. Entsprechende quan-titative Untersuchungen mit Benutzern in ihrem realen Umfeld wärenvorstellbar, sind aber zum einen sehr aufwändig und zum anderen nichtüber verschiedene Systeme vergleichbar.

Ein vielversprechender Ansatz ist der Einsatz von Usability-Standard-fragebögen, die als Evaluationsinstrument die oben genannten Anforde-rungen weitgehend erfüllen. Die Beurteilung eines Systems findet ausSicht der Benutzer im Anwendungskontext statt und erfolgt einheitlichüber dieselben Kriterien. Die Fragebögen wurden von ihren Autorenbezüglich Gütekriterien überprüft und optimiert. Mit einer Normierungstreben die Autoren zudem an, eine Vergleichsbasis für verschiedene An-wendungen zu schaffen. So wäre es zumindest theoretisch möglich, auchunterschiedliche Software-Produkte über ihre Benutzer beurteilen zu las-sen und die so erhaltenen Werte zu vergleichen.

Über den Nutzen eines Vergleichs unterschiedlicher Systeme oderProdukte lässt sich streiten. Eine interessante Anwendung für diePraxis ist indes sicher folgende: Mittels regelmäßiger Benutzerbefra-gungen lässt sich im Sinne einer Qualitätskontrolle die Benutzbarkeiteines Systems über die Zeit überprüfen. Dies ist beispielsweise beiInternet-Anwendungen mithilfe einer regelmäßig geschalteten On-line-Befragung ohne großen Aufwand möglich. Sollten sich dieWerte (z. B. nach einem Redesign) negativ verändern, ist Hand-lungsbedarf angesagt. Einige Anbieter nutzen diese Möglichkeit undüberprüfen die Benutzbarkeit ihrer Produkte regelmäßig mittels Online-Fragebögen.


Checkliste zum Einsatz von Fragebögen

• Ist für die vorhandene Fragestellung eine quantitative Untersuchungnotwendig und geeignet, oder sind vielmehr qualitative Methodenbesser (z. B. Contextual Inquiry, Interviews, Usability-Tests mit Pro-totypen)?

• Dienen Zahlenwerte und statistische Angaben zur Beantwortung derFragestellung?

• Können die Benutzer die Fragen aus ihrem Wissen oder ihrer Erfah-rung beantworten?

• Lässt sich die Fragestellung so in einen Fragebogen verpacken, dasssie verständlich bleibt und in kurzer Zeit beantwortet werden kann?Wie groß ist die Gefahr von Falschantworten?

• Ist eine statistische Auswertung der Antworten möglich, sinnvoll undbezüglich Aufwand vertretbar?

• Muss ein Fragebogen selbst entwickelt werden oder ist ein geeigneterStandardfragebogen verfügbar?

In Kürze

Methode Benutzerbefragung mittels Fragebögen

Resultate Quantitative Daten, statistische Aussagen zur Usability einesSystems, als Ergänzung in der Anforderungsanalyse oderzur Qualitätssicherung

Vorgehen Einsatz eines Standardfragebogens oder Erstellung eineszugeschnittenen Fragebogens, Durchführung der Befragungund Auswertung der Antworten

Aufwand Erstellen und Auswerten eines kleineren qualitativen Frage-bogens: 5–10 PTDurchführen und Auswerten einer Untersuchung mit Stan-dardfragebogen: 10–20 PTErstellen und Auswerten einer quantitativen Fragebogen-Studie: nicht unter 30 PT

Beteiligte Auftraggeber, Fragebogen-ExpertePlanung Analyse: Im Anschluss an Contextual Inquiry Evaluations-

instrument: Im Rahmen eines Pilottests oder zur ständigenQualitätssicherung

4Usability im Griff: Planung

„Wir entwickeln ein neues Produkt für jedermann.Wie viel Usability brauchen wir denn?“Wir denken, etwa 5 Kilo sollten reichen. Am bestenscheibchenweise. Aber was genau haben Sie dennvor?

In den letzten Kapiteln haben wir die wichtigsten Usability-Methodenund ihren Zusammenhang in einem benutzerorientierten Prozess im All-gemeinen vorgestellt. Damit die Techniken richtig eingesetzt werdenkönnen, müssen die projektspezifischen Ziele, Risiken und Rahmenbe-dingungen berücksichtigt werden. Für Projektleitung und Team bedeutetdas, die notwendigen Methoden einzuplanen, gut ausgebildete Fachkräf-te einzusetzen und den Fortschritt zu überwachen. Dieses Kapitel befasstsich mit der Planung von Usability Engineering in Projekten.

4.1 Ziele erreichen

Bei der Optimierung der Benutzbarkeit von Systemen oder Produktenkönnen unterschiedliche Schwerpunkte gesetzt werden. Der Einsatz ge-eigneter Usability-Methoden hängt von den Zielen ab, die ein Projekterreichen soll. Nicht selten wird in Projektaufträgen pauschal eine „ho-he Usability“ gefordert. Damit Usability-Aktivitäten jedoch überhaupteingeplant werden können, müssen zumindest abschätzbare, wenn nicht


98 4 Usability im Griff: Planung

Abb. 4.1 Ziele, Risiken undRahmenbedingungen bestim-men bei der Entwicklungeines neuen Produkts, welcheUsability-Methoden einge-setzt werden, wann und inwelchem Ausmaß. Sie sindwichtige Grundlagen für diePlanung

Ziele

Risiken

Rahmenbedingungen

sogar messbare Ziele festgelegt werden. Im Folgenden finden Sie eineAuswahl möglicher Ziele:

• Die Arbeitsgeschwindigkeit der Benutzer mit dem neuen System ma-ximieren,

• Die Anzahl notwendiger Schritte zur Ausführung einer Funktion unddie dafür benötigte Zeit minimieren,

• Den Ausbildungs- und Lernaufwand minimieren,• Die Qualität des Arbeitsresultates steigern,• Die Anzahl Fehler der Benutzer minimieren,• Das Gefährdungspotenzial aufgrund falscher Interpretationen oder

Fehlmanipulationen reduzieren,• Die Zufriedenheit der Benutzer mit dem Produkt und ihrer Arbeit er-

höhen,• Die Akzeptanz eines neuen Produktes erhöhen.

Ein Beispiel dazu: Will die Geschäftsleitung die Zeit reduzieren, dieein Kunde beim Musikhören in der Warteschlaufe eines Callcenters ver-bringt, kann ein in der Benutzung effizienteres System dazu beitragen. Jeschneller die Mitarbeiter die Anrufe im Mittel abarbeiten, desto kürzerist die Wartezeit der Anrufer. Die Reduktion der durchschnittlichen Be-arbeitungszeit eines Kunden-Anrufs ist ein messbares Ziel, das verfolgtwerden kann. Es bestimmt, welche Usability-Methoden mit wie viel Auf-wand im Projekt einzuplanen sind.

4.2 Risiken kontrollieren 99

4.2 Risiken kontrollieren

Ein weiterer wesentlicher Faktor für die Planung von Usability Engi-neering ist die Risikobetrachtung eines Projekts. Dabei gilt es, Risikenzu identifizieren und gezielt anzugehen. Vereinfacht lassen sich Projekt-und Produktrisiken unterscheiden:

Projektrisiken gefährden den erfolgreichen Abschluss eines Projekts.Sie sind oft technischer und projekt-politischer Natur. Zwei typischeProjektrisiken, welche mit Usability Engineering angegangen werdenkönnen, sind schlechte Akzeptanz bei den Benutzern sowie zu viele, erstspät entdeckte Anforderungen.

Produktrisiken hingegen gefährden den erfolgreichen Einsatz einesProduktes. Usability-Aspekte spielen bei Produktrisiken oft eine ent-scheidende Rolle. Die Identifikation solcher Produktrisiken ist für dieEinplanung von Usability-Maßnahmen im Projekt zentral. Dazu einigeBeispiele:

• Systeme mit mangelnder Usability erfordern vom Benutzer mehr Auf-merksamkeit und lenken ihn von seiner eigentlichen Tätigkeit ab.Dieses Risiko mag beispielsweise für Büroanwendungen tolerierbarsein – für ein neuartiges Navigationsgerät im Auto muss es dagegenmit geeigneten Methoden minimiert werden.

• Fehleingaben können unangenehme Folgen haben. Bei einem Systemfür den Börsenhandel können sie sogar fatale Auswirkungen haben,falls beispielsweise ein Händler ungewollt 10.000.000 statt 10.000Aktien verkauft. Solche Fehleingaben müssen unter allen Umständenvermieden werden.

• Eine unklare Benutzerschnittstelle stellt bei der Entwicklung einesFarbenmischgeräts ein anderes Risiko dar als bei einem Gerät für dieDosierung von Medikamenten. Entsprechend unterschiedlich hochsind die Anforderungen bezüglich Usability.

DenkanstoßSind Sie zurzeit in ein Projekt involviert? Überlegen Sie sich, wel-che Ziele das Projekt erreichen will und welche Risiken bestehen. Zuwelchen dieser Ziele und gegen welche Risiken kann Usability Engi-neering einen wesentlichen Beitrag liefern?


4.3 Rahmenbedingungen

Neben den zu erreichenden Zielen und den zu beherrschenden Risiken istder Einsatz von Usability-Methoden von diversen Rahmenbedingungenabhängig. Diese Faktoren beeinflussen die Planung von Usability En-gineering im Projekt maßgeblich. Beispielsweise lässt sich ContextualInquiry nur durchführen, wenn das Projektteam tatsächlich mit Benut-zern vor Ort sprechen kann. Im Folgenden ist eine Auswahl weitererEinflussfaktoren aufgeführt:

• Wie verfügbar sind die Benutzer für Beobachtungen, Interviews undWorkshops?

• Handelt es sich um interne oder externe Benutzer?• Wie intensiv arbeiten die Benutzer mit dem Produkt und wie groß ist

ihr Fachwissen?• Findet die Entwicklung intern, extern oder off-shore statt?• Muss auf Personen mit besonderen Merkmalen geachtet werden, z. B.

Kinder, ältere Menschen, Analphabeten, Personen mit Behinderun-gen?

• Wird spezielle Hardware oder besondere Software-Technologievorgegeben, z. B. mehrere Bildschirme, Joysticks, Spracheingabe,Touchscreens, 3-D-Grafik?

• Kommt das System an einem besonderen Ort zum Einsatz?• An welchem Punkt der Entwicklung steht das Projekt, wie weit sind

die Projektziele, die Anforderungen, die Architektur und das User In-terface bereits fortgeschritten und gefestigt?

• Welche Kenntnisse sind im Projektteam im Bereich Usability Engi-neering vorhanden? Müssen Berater zugezogen werden?

• Welche Firmenrichtlinien, wie Corporate-Design-Vorgaben und Vor-gehensstandards, müssen berücksichtigt werden?

• Nach welchem Entwicklungsprozess wird vorgegangen?

4.4 Planungsbeispiele

Ziele, Risiken und Rahmenbedingungen bilden die Grundlage für diePlanung. Aus diesen Eckpfeilern lässt sich ableiten:

4.4 Planungsbeispiele 101

• Welches die am besten geeigneten Usability-Methoden sind,• Zu welchem Zeitpunkt diese zum Einsatz kommen,• Mit wie viel Aufwand gerechnet werden muss,• Welche Personen mit welchen Fähigkeiten eingesetzt werden müssen.

Die folgenden Abschnitte illustrieren dies anhand von drei prototypi-schen Projekten.

Agile Entwicklung eines internenDatenverarbeitungssystems

Fokus Effizienz und EffektivitätBenutzer Interne Mitarbeiter; ca. 700 Benutzer; ausgebildetes Fachper-

sonal, das intensiv mit dem System arbeitetUsability-Ziele

Produktivitätssteigerung der Mitarbeiter; sehr gute Einpassungin erneuerte Prozesse; Arbeitsweise optimieren; effizientesUser Interface; kurze Schulung; Training on the job

Projektrisiken Schlechte Akzeptanz; viele Nachbesserungen; Entwicklungverschlingt zu viel Zeit, Geld und Ressourcen

Produktrisi-ken

Sinkende Effizienz der Mitarbeiter; hoher Aufwand für Schu-lung und Support

Projektstand Das noch inoffizielle Projektteam erarbeitet den Projektan-trag. Das Team umfasst später 18 Personen, davon 8 Software-Entwickler.

Prozess Nach erfolgtem Projektantrag agile Entwicklung in fünf Relea-ses in zwei Teams.

Folgende Usability-Methoden kommen zum Einsatz:

• Contextual Inquiry: in der Zeit bis zum Projektantrag Verbesse-rungspotenzial und kritische Rahmenbedingungen der heute gelebtenArbeitswelt erkennen und damit das grobe Geschäftsprozessmodellergänzen. Während der Entwicklung vor Ort Detailwissen für die an-stehenden Iterationen erwerben.

• Storyboards: für den Projektantrag die gemeinsame Vision mit einemStoryboard dokumentieren und der Geschäftsleitung kommunizieren.Die Storyboards während der Entwicklung aktuell halten, um neue


Teammitglieder einzuführen und Stakeholder zu informieren. Späterbei Schulungen als Überblick und Einführung verwenden.

• User Stories: in der Zeit bis zum Projektantrag mit groben User Sto-ries das erste Release planen. Während der Entwicklung die UserStories stetig verfeinern, ergänzen und neu priorisieren. Mit User Sto-ries die Ziele der Benutzer in die Diskussionen einbringen.

• Szenarien: Anhand von Fallbeispielen neue Prozessschritte durch-denken und damit die User Stories verfeinern und validieren. Ausden Szenarien konkrete Informationen für das User Interface Designableiten. In der Testphase als Basis für Testfälle und Usability-Test-aufgaben einsetzen.

• UI Prototyping: Für die Umsetzung der anstehenden User Stories dieFunktionalität und den Informationsgehalt mit den Fachabteilungenerarbeiten. UI-Konzept iterativ erarbeiten.

• Usability Walkthroughs: Während der Entwicklung UI-Konzept, Pro-totypen und Produktinkremente prüfen.

• Projekt-Styleguide: als Nachschlagewerk für die Detailgestaltung desUI während der Entwicklung.

• Usability Testing: als Teil der Abnahme eines Releases sowie zurAbnahme ausgewählter Iterationen. Zur Optimierung wichtiger UI-Aspekte während der Entwicklung. Zeigt zudem die Aspekte, auf diebei Handbüchern und Schulung besonderer Wert gelegt werden soll.

• Fragebögen: im Betrieb die Erfüllung der Usability-Ziele auch nachmehreren Wartungsupdates prüfen.

Beim geschilderten Vorgehen sollte ein Projektteam auf die folgendenPunkte achten:

• Datenverarbeitungssysteme zeichnen sich im Allgemeinen durch vie-le Spezialfälle in der Anwendung aus. Diese werden typischerweiseerst durch die Betrachtung konkreter Beispiele sichtbar. Jeder nichtdurch das System berücksichtigte Fall bringt zusätzlichen Arbeits-aufwand in der Benutzung. Werden reale Fälle zu wenig betrachtet,besteht das Risiko, dass die Benutzer nicht genügend Unterstützungfür die Besonderheiten der realen Arbeitswelt erhalten und damit Pro-duktivität und Qualität sinken.

• Das Team sollte die Benutzer wenn immer möglich in das Projekt ein-beziehen: Einzelne Benutzer in das Projektteam integrieren, andere


durch sporadische Teilnahme an Befragungen und Tests einbeziehenund alle mit regelmäßigen Informationen über Ziele, Fortschritte undPlanung auf dem Laufenden halten. Dadurch wird der notwendigeVeränderungsprozess bei den Mitarbeitern früh angestoßen und dieAkzeptanz steigt.

• Agile Teams umfassen idealerweise alle notwendigen Tätigkeiten,von der Prozessoptimierung bis zum Testing. Usability Engineeringund Interaction Design ist Aufgabe der Teams. Die Mitarbeiter sollenentsprechende Fähigkeiten mitbringen oder werden von Usability Ex-perten angeleitet. Usability Experten wie auch Interaction Designerkönnen mehrere Teams beraten, übergreifende Themen bearbeitenund Spezialwissen einbringen.

Ein neues digitalesWunderwerk für den Consumer-Markt

Fokus Schlichtheit und AttraktivitätBenutzer Konsumenten: verschiedene Altersgruppen; technisch

Interessierte sowie absolute Anfänger; aus sämtlichen Kul-turkreisen

Usability-Ziele Sofort benutzbar ohne Training; gutes Design; überschauba-re Menge an Funktionen, geringe Bedienkomplexität

Projektrisiken Neue, wenig bekannte Technologien; viele unterschiedlicheAnforderungen müssen unter einen Hut gebracht werden

Produktrisiken Hohe Kosten für Support; überlastete Hotline; schlechteVerkaufszahlen; Imageverlust

Projektstand Das Produktmanagement hat ein Set von Features, Rahmen-bedingungen und die angestrebte Zielgruppe definiert. Dasentstandene Lastenheft ist Vorgabe für das Projektteam

Prozess Marktanalyse, Konzept, iterative Entwicklung, Serienreifma-chung, Produktion, Markteinführung

Das digitale Wunderwerk, beispielsweise ein Harddisk-Videorekorder,hat einige Eigenschaften, die eine deutlich andere Planung als für das in-terne Datenverarbeitungssystem erfordern. Insbesondere die heterogeneBenutzergruppe stellt eine besondere Herausforderung dar. Das digitaleWunderwerk ist funktional einfacher als ein Datenverarbeitungssystem,


zeichnet sich aber durch spezialisierte Hardware aus. Folgende Metho-den werden eingesetzt:

• Contextual Inquiry: in der Marktanalyse als Ergänzung zur Marktfor-schung. Der Fokus liegt auf Problemen mit bestehenden Produkten,Anwendungssituationen und dem Kontext der Anwendung.

• Personas und Szenarien: in der Marktanalyse und Konzeptphase Be-nutzer und Abläufe modellieren und dokumentieren; Fokussierungauf das Zielpublikum und Priorisierung der möglichen Funktionen.

• UI Prototyping, Usability Walkthroughs: in der Konzept- und Ent-wicklungsphase die Benutzerschnittstelle erstellen und optimieren;z.B. in wöchentlichen Iterationen. Varianten der möglichen Hardwareund der möglichen Interaktionen aufstellen und mit Benutzern prüfen.Komplexe Features oder schwer verständliche Konzepte ausschließenund erfolgreiche Funktionen weiter optimieren.

• Use Cases: während der Konzeptphase die funktionalen Anforderun-gen festhalten, später verfeinern und aktuell halten.

• Usability Testing: Testen der Prototypen am Ende der jeweiligen Pha-sen; Testen des Produktes vor Markteinführung.

Beim geschilderten Vorgehen sollten Projektleiter und Produktverant-wortliche auf die folgenden Punkte achten:

• Im Gegensatz zum internen Informationssystem müssen die für Usa-bility Engineering bedeutsamen Informationen aus vielen Quellen zu-sammengetragen werden. Beispielsweise können relevante kulturelleAspekte wie Modeströmungen, Vorlieben und mehr mit Methodender Marktforschung erarbeitet werden. Weitere wichtige Informati-onsquellen sind die lokalen Vertriebsgesellschaften und der Kunden-dienst. Auch Contextual Inquiry ist für ausgewählte Fragestellungenzu Benutzung und Umfeld hilfreich.

• Es gilt, den Funktionsumfang gegen die daraus resultierende Kom-plexität in der Bedienung abzuwägen. Mit einer benutzerorientiertenMethodik kann jede geplante neue Funktion auf den Nutzen für dieZielgruppe kritisch hinterfragt und in der Anwendung überprüft wer-den, bevor sie im Produkt implementiert wird.

• Benutzer erfahren ein solches Produkt als Ganzes. Software undHardware müssen zusammenpassen. Das Gerät sollte von Beginn


an als Ganzes dargestellt und evaluiert werden. Nebst funktionalenAspekten spielen auch emotionale Faktoren, Ästhetik und Design ei-ne wichtige Rolle und können über den Erfolg oder Misserfolg einesProdukts entscheiden.

Wenn Leben auf dem Spiel steht

Fokus SicherheitBenutzer Personen mit fachlicher Ausbildung, ausgiebigem TrainingUsability-Ziele Gravierende Folgen durch Fehlbedienungen müssen vermie-

den werden; Fehlerrate bei Benutzern minimieren; Qualitätdes erreichten Resultates maximieren; Nachlässigkeiten undUmgehungen erschweren; effiziente Bedienung sicherstellen

Projektrisiken Hohe Anforderungen an den Entwicklungsprozess; Auf-lagen des Gesetzgebers und der Zulassungsstellen müsseneingehalten und Qualitätsnormen erfüllt werden

Produktrisiken Unfälle mit schwerwiegenden Auswirkungen auf Mensch,Umwelt und Sachwerte.

Prozess Analyse, Konzept, Entwicklung, Testphase, Produktion

Produkte mit hohen Anforderungen an die Sicherheit finden sich in vie-len Bereichen, beispielsweise in der Medizin, in der Automobilbranche,in der Flugsicherung und bei industriellen Anlagen. Fehlbedienungen,Nachlässigkeiten und Umgehung von Sicherheitsmaßnahmen sind Ur-sachen für Unfälle, die üblicherweise unter die Rubrik „menschlichesVersagen“ fallen. Eine auf Sicherheit optimierte Benutzerschnittstelleverringert solche Unfälle, manchmal auch auf Kosten von Bequemlich-keit und Effizienz. Zum Beispiel werden Behälter für Medikamente heuteso konstruiert, dass sie durch kleine Kinder nur schwer geöffnet werdenkönnen. Genauso werden bei kritischen Eingabefeldern keine Standard-werte vorgegeben, damit ein unaufmerksamer Benutzer das Feld nichteinfach überspringen kann. Folgende Methoden werden typischerweiseeingesetzt:

• Contextual Inquiry: in der Analysephase die Aufgaben, die eintrai-nierten Verhaltensweisen sowie die Gestaltung bestehender Systeme


im Detail verstehen und dokumentieren. Einflüsse des Umfelds, wiebeispielsweise Lärm, Stress, Zusammenarbeit im Team, das Verhaltenin Störungsfällen und weitere kritische Aspekte müssen untersuchtwerden.

• UI Prototyping: in der Konzeptphase eine zu den fachlichen Abläufenpassende Benutzerschnittstelle erarbeiten.

• Usability Walkthroughs, Expertenreviews und Usability Testing: inder Konzeptphase und der Testphase das System mit Benutzern über-prüfen. Einerseits soll gezeigt werden, dass getroffene Maßnahmen inder Gestaltung tatsächlich auch zur angepeilten Erhöhung der Sicher-heit beitragen werden. Andererseits muss auch die User Experienceals Gesamtes stimmen.

• Usability Testing: in der Testphase das System im Usability Lab vali-dieren und die Qualität der mit dem System geleisteten Arbeit prüfen;im Feldtest Vorfälle bezüglich ungenügender Usability analysieren.

• Vorfälle analysieren: Im Betrieb sicherheitsrelevante Vorfälle sam-meln, auswerten und bezüglich Verbesserungspotenzial durch Usabi-lity-Maßnahmen untersuchen.

Beim geschilderten Vorgehen sollte ein Projektleiter auf die folgendenPunkte achten:

• Es ist eine 100%-Einstellung gefordert: Bei den meisten Optimie-rungen kann bereits mit wenig Aufwand eine messbare Verbesserungerzielt werden. Dies genügt bei kritischen Risiken nicht: Bereits einfalscher Standardwert oder eine falsche Bezeichnung eines Knopfeskönnen die Eintretenswahrscheinlichkeit eines Risikos massiv erhö-hen. Jedes Detail ist wichtig!

• Es ist nur 99% Sicherheit erreichbar. Kein Produktrisiko kann voll-ständig verhindert werden. Auch wird die Vielfältigkeit des Alltagsimmer nicht vorhersehbare Situationen hervorbringen. Sicherheitsori-entierte Vorgehen legen deshalb Wert auf die Erfassung und Aus-wertung sicherheitsrelevanter Vorfälle im Betrieb. Eine systematischeAuswertung dieser Vorfälle aus Sicht der Benutzbarkeit hilft einemProjektteam, bei der nächsten Generation die richtigen Verbesserun-gen vorzunehmen.

• Usability Engineering allein genügt nicht. Risikomanagement mussbei hohen Risiken auf breiter Front ansetzen, z. B. mittels Notfalls-

4.5 Einsatz von Benutzern 107

zenarien, Ausbildung und Zertifizierung der Benutzer, Analyse vonVorfällen und weiteren Maßnahmen.

• Im sicherheitskritischen Umfeld sind oft zusätzliche Usability-Nor-men zu berücksichtigen. In der Medizinaltechnik sind beispielsweisedie Normen [IEC 60601-1-6] und [IEC 62366] relevant. Der Einbezugvon Benutzern wird in diesen Normen vorgeschrieben.

4.5 Einsatz von Benutzern

Für die Durchführung von Usability-Methoden werden oft gut quali-fizierte Benutzer benötigt. Dies ergibt für ein Projektteam zusätzlicheAufgaben.

Benutzer rekrutieren

Das Rekrutieren von Benutzern kann ein schwieriges Unterfangen sein.In vielen Situationen muss ein Projektteam selbstständig Benutzer an-werben. Dabei sollte auf die folgenden Punkte geachtet werden:

• Überlegen Sie sich vor einer Untersuchung, welche Eigenschaften dieeingeladenen Benutzer haben sollten, und prüfen Sie, ob diese erfülltwerden.

• Achten Sie auf ein breites Spektrum an Eigenschaften und Fähigkei-ten der eingeladenen Benutzer.

• Besprechen Sie den Einsatz von internen Benutzern mit ihren Vorge-setzten.

• Halten Sie bei externen Benutzern mit Marketing und Verkauf Rück-sprache, und achten Sie auf die notwendige Geheimhaltung.

Im Verlauf eines größeren Projekts wird ein Projektteam in der Regeleine ganze Reihe von Benutzern einbeziehen. Der Aufbau einer Benut-zerdatenbank kann die Rekrutierung mit der Zeit stark vereinfachen.

Eine umfassende Darstellung zum Thema Rekrutierung von Benut-zern und deren Einbezug in Usability-Aktivitäten gibt das Buch [Courageet al. 05].


Benutzer entlohnen

Eine angemessene Bezahlung der Benutzer ist angebracht. Bei externenPersonen werden die Leistungen deshalb meist mit Geld, Gutscheinenoder Geschenken vergütet. Für interne Benutzer ist die Wertschätzungihrer Mitarbeit oft die beste Abgeltung. Dies bedeutet, dass das Pro-jektteam die Benutzer nutzbringend einsetzt, Anregungen und Kritikaufnimmt und darauf reagiert. Es ist die Aufgabe des Projektleiters, diebeteiligten Benutzer regelmäßig über den erreichten Fortschritt zu infor-mieren.

Anonymität und Vertraulichkeit

Die Äußerungen von Benutzern müssen anonym und vertraulich gehand-habt werden. In einem Interview wird ein Analyst auch einmal negativeAussagen zu hören bekommen. Genauso wird er vielleicht Fehler undVerstöße beobachten. Die folgenden Punkte bezüglich des Datenschut-zes müssen Sie beachten:

• Dem Teilnehmer einer Untersuchung sollte klar sein, wie die gesam-melten Daten verwendet werden und wie Anonymität und Vertrau-lichkeit eingehalten werden.

• Aussagen, die ein Projektteam aufbewahrt, sollten anonymisiert wer-den.

• Für Video- oder Audioaufnahmen ist das Einverständnis der Benut-zer einzuholen. Klären Sie ab, ob Sie die Aufnahmen aufbewahrendürfen und zu welchem Zweck Sie diese verwenden können. Eineeinfache schriftliche Einverständniserklärung ist hier angebracht. Ab-bildung 4.2 zeigt ein Beispiel.

• Beachten Sie die Datenschutzgesetze. Diese regeln, wie mit personen-bezogenen Daten umgegangen werden muss.

4.6 Schwierige Situationen 109

Information zur … Usability-Studie

Danke, dass Sie sich bereit erklärt haben, am … Usability-Test teilzunehmen. Durch Ihre Mitarbeit helfen Sie,

die … Produkte noch besser auf die Bedürfnisse der Kunden abzustimmen.

Zu Auswertungszecken werden wir die Testsitzung (Video und Audio) aufnehmen.

Einverständniserklärung

Ich bin damit einverstanden, dass die Video-Aufnahmen für die spätere Auswertung gespeichert werden.

Ich bin zudem damit einverstanden, dass Ausschnitte der Video-Aufnahmen für interne Zwecke (z.B.

Zusammenschnitt für Präsentationen) verwendet werden.

Unterschrift: Ort, Datum:

_________________________________ _________________________________

Abb. 4.2 Beispiel einer einfachen Einverständniserklärung für die Verwendung vonVideo- oder Audioaufnahmen

Benutzer einbeziehen ist Projektmarketing

Jeder Kontakt mit Benutzern ist eine Möglichkeit, deren Bedenken undÄngste zu erfühlen und sie über die Chancen, die das Projekt bietet, zuinformieren. Usability-Methoden sind deshalb ein ausgezeichnetes Mit-tel, um die Akzeptanz bei Benutzern zu erhöhen. Die Bedingung dazu ist,dass das Projektteam auf die Kritik und die Bedenken der Benutzer ein-geht. Vergessen Sie nicht: Auch wenn Sie nicht mit Benutzern sprechen,kommunizieren Sie!

4.6 Schwierige Situationen

Hoffentlich sprühen Sie nun vor Tatendrang und möchten das Gelesenebaldmöglichst umsetzen. Manchmal holt einen die Praxis allerdings nurallzu schnell wieder auf den Boden zurück. Die Landung ist zuweilenhart, doch selten schädlich. In diesem Abschnitt stellen wir in der Pra-xis häufig anzutreffende, schwierige Situationen dar und zeigen Ansätze,diese zu bewältigen.


Benutzer werden vertreten

In größeren Unternehmen sind Benutzervertreter oft fester Bestandteileines Projektteams. Dies ist grundsätzlich eine ausgezeichnete Idee, dadiese Fach und Anwendung kennen und entsprechend wichtige Punkteschnell klären können.

Die Schwierigkeit in der Praxis besteht darin, dass Benutzervertre-ter oft mit der Aufgabe betraut werden, selbst die Anforderungen andie Benutzerschnittstelle für ein neues System zu definieren. Benutzer-vertreter sind allerdings weder Methodiker noch Systemanalysten nochUser Interface Designer und auch keine Software-Architekten. Es istfür sie deshalb kaum möglich, eine passende Lösung zu definieren. Esbesteht die Gefahr, dass zentrale Anforderungen vergessen und persönli-che Wünsche eingefordert werden, die den Benutzern, die sie vertreten,nicht dienen. Mit dieser Arbeit verlieren sie mit der Zeit auch den unvor-eingenommen Blickwinkel der Benutzer und können das System nichtmehr aus deren Sicht beurteilen. Die Problematik ist in jenen Firmenbesonders stark ausgeprägt, in welchen Mitarbeiter der Geschäftseinhei-ten vollamtlich als Benutzervertreter eingesetzt werden und deshalb baldkeine eigentlichen Benutzer mehr sind.

Die Projektleitung kann in einer solchen Situation eine entscheidendeRolle übernehmen. Es liegt an ihr, die notwendige Methodik einzuführenund ein Projektteam mit dem benötigten Know-how zusammenzustellen.Im Idealfall bildet sie ein effektives Team von Benutzervertretern. DiesesTeam sollte aus erfahrenen Benutzern bestehen und eine große fachlicheBandbreite abdecken. Es nimmt die folgenden Aufgaben wahr:

• Bedürfnisse der Anwender und Geschäftseinheiten einbringen• Fachliche Fragen beantworten• Den Zugang zu Benutzern ermöglichen• Das System auf fachliche Korrektheit testen

Dieses Team bildet die Schnittstelle zwischen Entwicklung, Benutzernund Fachleuten. Es ist für die korrekte Bedürfnisabklärung bei den Be-nutzern mitverantwortlich. Zur Erfüllung dieser Schnittstellenfunktionhelfen die Benutzervertreter bei Contextual Inquiry mit, unterstützen beider Erarbeitung von Personas, Szenarien und Storyboards, helfen beimUser Interface Prototyping und rekrutieren Testpersonen für Usability-

4.6 Schwierige Situationen 111

Tests. Damit die Benutzervertreter diese Aufgaben lösen können, müs-sen sie entsprechend methodisch unterstützt werden.

Kein Benutzer am Horizont

Bei manchen Projekten bleibt der Zugang zu Benutzern verwehrt. Damitfehlt dem Analysten eine wichtige Informationsquelle zur Erarbeitungeiner benutzbaren Lösung. In dieser Situation können die folgenden se-kundären Quellen hilfreich sein:

• Lokale Vertriebsgesellschaften• Hotline und Support• Trainer• Schulungsmaterial und Bedienungsanleitungen• Serviceleute• Konkurrenzprodukte• Verfügbare Literatur• Vorhandenes Wissen über die Benutzer im Unternehmen, wie bei-

spielsweise aus Marketing und Marktforschung• Kundenkontakte auf Messen und Ausstellungen

Methoden wie Personas und Szenarien tragen dazu bei, das vorhandeneWissen der Beteiligten für die Produktvision zu nutzen sowie verborgeneAnnahmen über Benutzer und Anwendung auf den Tisch zu bringen, umein gemeinsames Verständnis zu erarbeiten.

Es kann für ein Unternehmen lohnenswert sein, das Sammeln solcherInformationen zu institutionalisieren und damit einen ständigen Draht zuBenutzern und Kunden zu etablieren. Beispielsweise könnte es zu der Tä-tigkeit von Service-Ingenieuren gehören, vor Ort gezielt Informationenüber die Benutzer aufzunehmen, die zur Weiterentwicklung der Produktebeitragen.

Wenn Zeit und Geld knapp sind

Am Anfang dieses Kapitels haben wir argumentiert, dass in erster Li-nie Geschäftsziele und Produktrisiken als Grundlage für Planung undEinsatz von Usability Engineering im Projekt dienen. In der Praxis sind


Geld und Zeit meist knapp. Eine den Zielen und Risiken angepasste Me-thodik findet im Budget oft keinen Platz. In Kap. 5 diskutieren wir denTrade-off zwischen Aufwand, Zeit, Qualität und Funktionsumfang aus-führlicher. Ist jedoch hohe Qualität gefordert, beispielsweise bei hohenProduktrisiken, führt kein Weg an der entsprechenden Methodik vorbei.Alles andere wäre schlichtweg fahrlässig.

Steht hingegen tatsächlich eine möglichst kurze Zeit bis Einfüh-rung bei begrenztem Budget im Vordergrund, dann ist ein Vorgehenerwünscht, um die schlimmsten Usability-Probleme kostenneutral auszu-merzen. Für ein solches Vorgehen prägte Nielsen schon früh den BegriffDiscount Usability Engineering [Nielsen 93]. Sein Argument war, dassmit simplen, kostengünstigen Methoden in einfachen Praxissituationenbereits relativ viel erreicht werden kann, und dass ein vereinfachtes Vor-gehen auch mit höherer Wahrscheinlichkeit zur Anwendung kommt alseine vollständigere, aber auch aufwändigere Methodik. Ein solches ver-einfachtes Vorgehen kann folgendermaßen aussehen:

• Minimale Analyse des Nutzungskontexts: Wenige Beobachtungenoder Interviews bei den Benutzern vor Ort anstelle einer ausführli-chen Contextual Inquiry

• LoFi-Prototyping entlang der wichtigsten Anwendungsszenarien• Iteratives Prüfen und Verbessern mittels einfacher Usability

Walkthroughs mit Benutzern• Experten-Reviews anhand von Usability-Prinzipien oder Checklisten

Wasserdicht spezifizieren?

Der Vertrag zwischen Auftraggeber und Hersteller regelt die Grundla-gen, falls die Entwicklung einer neuen Lösung extern vergeben wird.Vor allem im Rahmen von Ausschreibungen werden oft Verträge ausge-arbeitet, die neben Angaben zu Kosten, Zeit und Qualität auch detaillierteVorgaben zu Funktionsumfang und Benutzerschnittstelle enthalten. Einsolch enges Korsett erlaubt nach Vertragsabschluss typischerweise nurnoch kleine Optimierungen bezüglich Usability, beispielsweise Anpas-sungen der Benutzeroberfläche von eher kosmetischer Natur. Entspre-chen Funktionalität, Informationen und Abläufe nicht den Benutzerbe-dürfnissen, dann sind Änderungen nach Vertragsabschluss nur noch mit

4.7 „Karl ist zuständig“ 113

größerem Aufwand möglich: interne Abstimmungen und Vertragsände-rungen kosten für alle Beteiligten viel Zeit, Geld und Nerven.

Um in einer solchen Vertragssituation trotzdem die erwünschte Usa-bility für das geplante Produkt zu erreichen, sind die Phasen bis zumVertragsabschluss entscheidend. Der Auftraggeber sollte insbesondereauf die folgenden Punkte achten:

• Usability-Methoden für die Analyse, Modellierung, Spezifikation undEvaluation mit Benutzern sind vor der Auftragsvergabe durchzufüh-ren.

• Der Auftraggeber muss dazu Usability Engineering einplanen undentsprechendes Know-how aufbieten.

• Im Vertrag muss die Aufgabenteilung mit dem Hersteller bezüglichAusgestaltung der Benutzerschnittstelle geregelt werden. Auch dieTeilung von Folgekosten, die sich aus falschen Annahmen oder feh-lenden Informationen bezüglich Usability-Aspekten ergeben, kannvertraglich festgehalten werden.

• Die Spezifikation sollte dabei nicht nur vollständig ausgearbeitete UseCases, sondern auch ein mit Benutzern geprüftes User-Interface-Kon-zept und gegebenenfalls UI-Prototypen und Styleguides umfassen.

Ein grundsätzlich anderer Ansatz besteht darin, nicht vollständig zuspezifizieren und eine enge Zusammenarbeit mit dem Hersteller anzu-streben. Anstelle einer umfassenden Anforderungsspezifikation stecktder Auftraggeber seine Ziele und Rahmenbedingungen ab und definiertden Prozess für das weitere Vorgehen. Hersteller und Auftragnehmerführen Usability-Methoden gemeinsam durch. Die enge Zusammen-arbeit erlaubt beiden, gegenseitige Stärken auszunutzen. Verfügt derAuftraggeber über wenig Erfahrung im Bereich Usability Engineering,kann er dies bei der Wahl eines geeigneten Auftragnehmers berücksich-tigen und sich so das notwendige Know-how sichern.

4.7 „Karl ist zuständig“

Wer ist zuständig für Usability? In der Praxis sind verschiedene Si-tuationen anzutreffen. Typischerweise ist niemand zuständig. In derKonsequenz kümmert sich der User-Interface-Entwickler ein wenig um


Tab. 4.1 Am Usability Engineering beteiligte Rollen bei der Entwicklung von Soft-ware und Produkten

Produktmanager Release-Planung und Produkte-RoadmapAufnahme des MarktfeedbacksAbgrenzung zu KonkurrenzproduktenPreisgestaltungDefinition der Vertriebskanäle

Risikomanager Identifizieren von ProduktrisikenDefinieren der Usability-Maßnahmen

Projektleiter Einplanen von Usability EngineeringFördern des Bewusstseins für UsabilityBeschaffen des notwendigen Usability Know-howsRekrutieren der Benutzer für Workshops und Usability-Tests

Analyst/Require-ments Engineer

Analysieren und beschreiben von Benutzern und Kon-textAnalysieren der Projektziele und Risikomaßnahmenbezüglich Usability-AspektenErarbeiten und Modellieren passender AnforderungenErstellen von ersten Entwürfen der BenutzerschnittstelleEvaluation der Ergebnisse mit BenutzernVermitteln bei widersprüchlichen Anforderungen

Geschäftseinheiten Anpassen der Organisation, Prozesse, Arbeitsanweisun-gen und Arbeitsplätze der Benutzer

User Interface Desi-gner

Entwerfen einer funktionalen und ästhetischen Benut-zerschnittstelleOptimieren der BenutzeroberflächeAnwendung von Styleguides

Software-Architekt Identifizieren der architekturkritischen AnforderungenEntwerfen einer passenden Architektur

Entwickler Implementieren der BenutzerschnittstelleUsability-Tester Einplanen der Usability-Tests

Festlegen der TestzieleAusführen und auswerten der Usability-Tests

Technical Writer Erarbeiten des Hilfesystems sowie der Bedienungsanlei-tungen

4.7 „Karl ist zuständig“ 115

die Usability des Systems, der Software-Architekt hat auch eine Meinungdazu, und die Personen aus den Geschäftseinheiten geben ihre Wünschebekannt. Usability wird in diesen Fällen eher zufällig oder gar nicht be-rücksichtigt.

Manchmal ist indessen eine bestimmte Person, beispielsweise Karl,explizit für Usability zuständig. Leider ist Karl auf sich allein gestelltund kämpft gegen die Wünsche der Auftraggeber, die fixen Ideen derBenutzer und die technische Verliebtheit der Software-Entwickler.

Usability Engineering ist ein Ansatz, um bestimmte Ziele zu errei-chen und Risiken zu reduzieren. Es genügt nicht, dass der Designer eingeeignetes User Interface definiert, wenn der Software-Architekt eine zulangsame Architektur wählt und der Software-Entwickler unverständli-che Fehlermeldungen programmiert. Damit die vorgesehene Usabilityerreicht werden kann, müssen viele Personen zusammenspielen. Ta-belle 4.1 gibt einen Einblick, welche Rollen für welche Tätigkeitenzuständig sind.

Diese lange und sicher nicht vollständige Liste illustriert eindrück-lich, wie viele Stellen auf die Usability eines neuen Produktes oder zuentwickelnden Systems Einfluss nehmen. Egal ob Karl für Usabilityzuständig ist, in Tat und Wahrheit ist jede in einem Projekt involvier-te Person mitverantwortlich, inklusive Auftraggeber und Management.Gutes Usability Engineering beinhaltet deshalb auch moderierende undvermittelnde Tätigkeiten, achtet auf gute Kommunikation und findet sel-ten im stillen Kämmerchen statt.

5Strategische Usability

Ausgerüstet mit der Kenntnis der wichtigsten Usability-Methoden, miteiner guten Planung in der Tasche und den richtigen Leuten an Bordbeginnt Ihr nächstes Projekt, in dem endlich ein wirklich benutzbaresProdukt entstehen soll. Und dann wird alles ganz anders: Das Budget fürUsability-Tätigkeiten wird gekürzt, in einem Management Board wirdüber neue Funktionalität abgestimmt, und Sie reden seit einer Woche anWände – kurzum: Sie befinden sich in den organisatorischen Mühleneines jeden (größeren) Unternehmens.

Die vorherigen Kapitel haben gezeigt, wie Usability-Methoden inein Projekt für die Software- oder Produktentwicklung integriert werdenkönnen. Dieses Kapitel gibt Hinweise:

• Wie Usability unternehmensweit platziert werden kann.• Wie Sie es schaffen, dass die involvierten Stellen in einem benutzer-

orientierten Prozess zusammenspielen.• Welche strategischen Aspekte in Usability Engineering stecken.

Dieses Kapitel dürfen Sie auch Ihrem Chef zeigen!

5.1 Usability unternehmensweit

Ein benutzerorientiertes Vorgehen in einem Unternehmen zu etablieren,bedeutet in der Regel, einige zementierte Ansichten aufzubrechen. Es


118 5 Strategische Usability

Abb. 5.1 Usability Engineering etabliert eine möglichst direkte Feedback-Schlaufezwischen Benutzern und Entwicklung

mag auf den ersten Blick unkonventionell erscheinen, Kundenberater undEntwickler in einem Prototyping Workshop zusammenzubringen odereinen halben Tag am Arbeitsplatz eines Benutzers zu verbringen. Unddennoch wird dies zu Erkenntnissen führen, die im weiteren Verlauf desProjekts viel Zeit und Kosten sparen werden und das Ergebnis positivbeeinflussen.

Usability Engineering als Feedbackschlaufe

Usability Engineering hat zum Ziel, dass optimal auf die Benutzer zuge-schnittene Lösungen erstellt werden. Dazu müssen

• Informationen über die Benutzer, deren Arbeitsabläufe, Bedürfnisse,Anforderungen, Aufgaben und Umgebung systematisch in die Soft-ware- oder Produktentwicklung einfließen und

• die technischen Möglichkeiten, Grenzen und Rahmenbedingungen ineiner verständlichen Form an die Benutzer zurückfließen.

Aus organisatorischer Sicht heißt dies nichts anderes, als eine Feedback-schlaufe zwischen Benutzern und Entwicklungseinheiten aufzubauen.Usability-Methoden unterstützen diesen Prozess, der in Abb. 5.1 verdeut-licht wird.

Wer Usability Engineering in Organisationen auf diese Weise ver-steht, löst sich von der isolierten Betrachtung des Datensammelns, User-

5.2 Aufbau eines benutzerorientierten Prozesses 119

Interface-Gestaltens oder Usability-Testens. An die Stelle von Kritik, diedem Entwickler in Form des neusten Testberichts aus dem Usability Labvor die Nase gehalten wird, tritt eine konstruktive Haltung: Usability En-gineering bringt jene Stellen zusammen, die für die Entwicklung vonbenutzbaren Lösungen unverzichtbar sind: Benutzer und Entwickler.

Nun gilt es, die notwendigen Rahmenbedingungen zu schaffen, umdieses Ziel umzusetzen. Die folgenden Abschnitte zeigen drei praxiser-probte Ansätze, um Usability Engineering unternehmensweit zu platzie-ren: Den Aufbau eines benutzerorientierten Prozesses, die Einführungvon Usability Standards und Hilfsmitteln und die Institutionalisierungvon Usability im Unternehmen.

5.2 Aufbau eines benutzerorientierten Prozesses

Usability Engineering bewegt sich organisatorisch an den Schnittstel-len zwischen Geschäftseinheiten und Entwicklung; in der Praxis wirdhäufig vom „Business“ und der „Technik“ gesprochen. Die Anforderun-gen der Benutzer sollen erhoben werden und unter Berücksichtigungder technischen Möglichkeiten und Grenzen in die Entwicklung ein-fließen. Um nachhaltig für benutzbare Lösungen zu sorgen, muss einUnternehmen einen Entwicklungsprozess etablieren, welcher die Feed-backschlaufe zwischen Business und Technik zum richtigen Zeitpunktermöglicht.

Um den benutzerorientierten Aktivitäten das notwendige Gewichtzu verleihen, ist es wichtig, entsprechende Rollen und Lieferergebnis-se in diesen Prozess aufzunehmen und die notwendigen Ressourcen(Zeit und Budget) bereitzustellen. In einem größeren Unternehmen wur-de beispielsweise die Projektrolle „Usability Engineer“ definiert. DerenVerantwortung umfasste die Begleitung des Entwicklungsteams bei derDurchführung von Usability-Methoden und die Erstellung von User-In-terface-Konzepten als Teil der Spezifikation.

Es bringt dabei wenig, theoretisch korrekte, aber nicht akzeptierteVorgaben einzuführen. Die benutzerorientierten Aktivitäten müssen inden bestehenden (gelebten) Entwicklungsprozess eingepasst werden. DieBerücksichtigung der folgenden drei Punkte erachten wir als essenziell:


• Business-Analyse und Requirements Engineering: Benutzerorientier-te Methoden müssen dort ansetzen, wo Anforderungen von derBusiness- oder Kundenseite erarbeitet, analysiert und in Spezifika-tionen oder Lösungsvorschläge übersetzt werden. Dort werden dieWeichen für eine benutzbare Lösung gestellt. Später im Prozess kannnur noch korrigiert werden.

• Iteratives Vorgehen: Es sollte ein iterativer Prozess aufgesetzt wer-den, in welchem Anforderungen und Spezifikationen visualisiert,mit Benutzern und Geschäftseinheiten überprüft und falls notwen-dig angepasst werden können. Wenn formale Freigaben erfolgen oderFachstellen Spezifikationen verabschieden müssen, dann sollten dieseiterativen Tätigkeiten möglichst vorher stattfinden. Eine enge Zusam-menarbeit im Team fördert diesen Prozess.

• Gemeinsame konkrete Sprache: Um eine benutzbare Lösung zu er-reichen, müssen Benutzer, Business-Einheiten, Fachstellen und Ent-wickler ein gemeinsames Verständnis entwickeln. Dies ist alleinmit formalen, abstrakten Beschreibungen nicht möglich. Beispielori-entierte Methoden wie Szenarien, Storyboards und User-Interface-Prototypen fungieren als verbindende Aktivitäten in der Produkt-entwicklung. Das User Interface ist die gemeinsame Sprache derverschiedenen Stellen und erlaubt eine effiziente Zusammenarbeit.

Checkliste für die Anpassung Ihres Entwicklungsprozesses

• Methoden: Welche Usability-Methoden unterstützen in welchen Pha-sen der Projekte am meisten?

• Lieferergebnisse: Usability Engineering verwendet bestimmte Er-gebnisse und Modelle, um Lösungen zu erarbeiten und Resultatefestzuhalten. Welche benötigen Sie? Sollen diese mit bestehendenLieferergebnissen zusammengeführt, zusätzlich erstellt oder beste-hende ersetzt werden?

• Werkzeuge: Beim Erstellen von informellen, bildlichen und auf Pro-totypen basierenden Ergebnissen können geeignete Werkzeuge helfen(siehe Abschn. 3.4 „UI Prototyping Tools und -Komponenten“). Wiekönnen Sie von bestehenden Tools profitieren, welche Werkzeugemüssen Sie neu einführen?

5.3 Usability-Standardisierung 121

• Feedbackschlaufe: Usability Engineering analysiert, interpretiert, er-arbeitet Lösungsvorschläge und überprüft diese mit Benutzern ineinem iterativen Prozess. Wo lassen sich solche Feedbackschlaufenin Ihrem Unternehmen integrieren?

• Rollen und Tätigkeiten: Ein benutzerorientierter Prozess führt zu neu-en Tätigkeiten und Projektrollen. Wer in Ihrem Unternehmen kanndiese wahrnehmen? Wie funktioniert die Zusammenarbeit im Team?

• Prinzipien: Usability Engineering baut auf bestimmten Prinzipien auf(vergleiche Kap. 7). Auf welchen Prinzipien gründet der Entwick-lungsprozess in Ihrer Firma? Könnte dies zu Widersprüchen führen?

5.3 Usability-Standardisierung

Unternehmens-Styleguides

Im Kapitel Usability-Methoden wurde gezeigt, wie User Interface Sto-ryboards und UI-Protoypen verwendet werden können, um die Anfor-derungen zwischen Business und Technik auszutauschen. Sie haben denEinsatz von Styleguides auch bereits als wichtiges Mittel für die Ent-wicklung einheitlicher Benutzerschnittstellen kennengelernt (vgl. Ab-schn. 3.6). In allen Fällen übernimmt das User Interface die Funktioneiner gemeinsamen Sprache zwischen den Beteiligten. Aus organisa-torischer Sicht verkörpern Unternehmens-Styleguides gewissermaßenWörterbuch und Grammatik dieser Sprache, indem sie User-Interface-Elemente mit Bezeichnungen und Anwendungsregeln festlegen. Durcheine solche Standardisierung können Konsistenz und Qualität der erstell-ten User Interfaces in einem Unternehmen nachhaltig verbessert werden.

Die Entwicklung eines Unternehmens-Styleguides ist besonders loh-nenswert, wenn viele ähnliche Anwendungen realisiert werden, die sichbezüglich Zielgruppe, Verwendungszweck und eingesetzter Technologiegleichen. Dann lassen sich standardisierte User-Interface-Elemente de-finieren, die in verschiedenen Projekten verwendet werden können. Beistark unterschiedlichen Anwendungen oder schnell wechselnden Tech-nologien ist der Aufwand für die Ausarbeitung und Aktualisierung einesUnternehmens-Styleguides dagegen sehr hoch.


Der Aufwand für den Einigungsprozess bei der Erarbeitung einesUnternehmens-Styleguides sollte nicht unterschätzt werden. Oft müs-sen Anforderungen aus vielen unterschiedlichen Projekten abgestimmtund auf einen gemeinsamen Nenner gebracht werden. Zudem gilt es,zahlreiche Aspekte wie Ergonomie, technische Umsetzbarkeit, Corpo-rate Design, Ästhetik und einige mehr zu berücksichtigen.

Unternehmens-Styleguides sollten keinesfalls als bloßes Regelwerkdie strikte (und manchmal blinde) Einhaltung von Vorgaben erzwingen.Ein guter Styleguide trägt dazu bei, dass Anwendungen schneller undeinfacher erstellt werden können. Styleguides entfalten in einem Un-ternehmen nur dann ihre Stärke, wenn sie mit guten Beispielen undHilfsmitteln ein gemeinsames Verständnis und das sinnvolle Anwen-den der Regeln fördern. Der folgende Abschnitt beschreibt zwei solcherHilfsmittel.

UI Prototyping Tools und -Komponenten

Es ist immer wieder verblüffend, wie Personen auf abstrakter Ebene an-einander vorbei diskutieren und welche Missverständnisse sich klären,sobald jemand eine erste Skizze einer Benutzerschnittstelle auf ein BlattPapier kritzelt. Was im Kleinen funktioniert, nützt auch im Rahmen ei-ner größeren Organisation: Die Visualisierung von Anforderungen durchUser-Interface-Entwürfe hilft, Missverständnisse zu vermeiden. DieserProzess kann mit folgenden Hilfsmitteln unterstützt werden:

Prototyping Tools stellen die in einem Unternehmens-Styleguide de-finierten User-Interface-Elemente zur Erstellung erster Entwürfe zurVerfügung (siehe auch Abschn. 3.4). Je einfacher diese Werkzeuge sind,desto eher sind auch technisch unbedarfte Personen bereit, ihre Ide-en und Vorstellungen auf Papier zu bringen. Elementsammlungen füreinfache Zeichnungswerkzeuge oder bereits vorhandene Office-Applika-tionen, mit denen Benutzeroberflächen baukastenartig zusammengestelltwerden können, haben sich dafür bewährt. Abbildung 5.2 zeigt ein Werk-zeug auf Basis von Microsoft Visio® zur Erstellung von einfachen User-Interface-Prototypen. Die vordefinierten GUI-Elemente entsprechen denVorgaben eines Unternehmens-Styleguides.

5.3 Usability-Standardisierung 123

Abb. 5.2 Ein einfaches UI Prototyping-Werkzeug erlaubt die Visualisierung von An-forderungen in Form von GUI-Entwürfen. Solche Hilfsmittel führen in Unternehmenzu einer höheren Qualität und Konsistenz der Benutzerschnittstellen über verschiede-ne Projekte hinweg

Auf der anderen Seite können die definierten GUI-Elemente in Formvon ausprogrammierten Komponenten für die Entwicklung zur Verfü-gung gestellt werden. Solche Komponenten erleichtern den Entwicklerndie Einhaltung der Styleguide-Vorgaben und erhöhen die Qualität der er-stellen User Interfaces. Selbstverständlich muss der Aufwand hierfür wiebei jeder Engineering-Tätigkeit sorgfältig abgewogen werden.

Die Kombination von Styleguides, Prototyping Tools und GUI-Kom-ponenten übt eine Schlüsselfunktion für einen benutzerorientierten Pro-zess aus:

• UI-Elemente mit einer konsistenten Bezeichnung und Verwendungerlauben einen durchgängigen Prozess von der Spezifikation bis zurImplementierung und vereinfachen die Kommunikation und das Ver-ständnis zwischen Benutzern, Geschäftseinheiten und Entwicklern.

• Die technischen Möglichkeiten sind schon in der Spezifikation sicht-bar und werden auch von Nicht-Technikern verstanden. Geschäfts-einheiten sind damit in der Lage, ihre Anforderungen innerhalb der


technischen Rahmenbedingungen zu formulieren und bereits mit ers-ten Entwürfen zu visualisieren.

5.4 Usability-Institutionalisierung

Ein eigenes Usability Team

Während kleinere Organisationen in der Regel Usability-Dienstleistun-gen von spezialisierten Anbietern in Anspruch nehmen, kann es sich fürgrößere Unternehmen mit einer Vielzahl von Entwicklungsprojekten loh-nen, ein eigenes Usability Team aufzubauen. Usability Know-how imHause zu haben, bringt eine Reihe von Vorteilen mit sich:

• Experten unterstützen langfristig die Etablierung von Usability-Me-thoden im Entwicklungsprozess und können mit internen Marke-tingmaßnahmen und Schulungen das Bewusstsein für das Themanachhaltig stärken.

• Das Team baut das für Usability Engineering erforderliche Bereichs-und Branchenwissen auf.

• Interne Usability-Spezialisten können bereits in frühen Phasen einesProjekts mitwirken, wenn unter Umständen noch kein externes Bud-get verfügbar ist.

Die Nachteile sind:

• Die für Usability Engineering positive unvoreingenommene externeSicht geht mit der Zeit verloren; es stellt sich auch beim besten Usa-bility-Spezialisten eine gewisse „Betriebsblindheit“ ein.

• Die Akzeptanz ist oftmals geringer als gegenüber externen Spezia-listen. Intern wird das Vertreten der Benutzersicht oft als Kritikempfunden, während man von Externen gerne die ungeschminkteWahrheit sucht.

5.4 Usability-Institutionalisierung 125

Abb. 5.3 Bei jeder Pro-duktentwicklung bestehenZielkonflikte zwischen ange-strebter Qualität, notwendigerEntwicklungszeit, Funktio-nalität des Produkts sowieRessourcen und Kosten.Usability ist ein Qualitätskri-terium und sollte deshalb aufstrategischer Ebene sicherge-stellt werden

Qualität

Kosten

FunktionZeit

Chefsache: Usability als Teil der Geschäftsstrategie

Kundenzufriedenheit, einfach zu benutzende Produkte und effizienteProzesse stehen meist ganz oben auf der strategischen Landkarte vonUnternehmen. Immer öfter erscheint Usability auch als Begriff in Stra-tegiepapieren und Visionsdokumenten. Was fehlt, ist indessen der Bezugzu der Planung und den Aktivitäten, die helfen sollen, diese strategischenZiele zu erfüllen.

Usability ist ein Qualitätskriterium, das durch benutzerorientierte Me-thoden im Entwicklungsprozess erhöht werden kann. Die Geschäftslei-tung muss definieren, mit welcher Priorität und mit welchen Ressourcendieses Ziel verfolgt werden soll. Abbildung 5.3 stellt die Abhängigkei-ten dar, die es dabei zu berücksichtigen gilt: Qualität, Funktionsumfang,Entwicklungszeit und Kosten stehen in einem Zielkonflikt.

Es kann für einen Marktführer zum Beispiel wichtig sein, als erstesUnternehmen ein neues Produkt mit gegebenem Funktionsumfang undgerade noch akzeptabler Qualität zu lancieren und dafür hohe Kostenin Kauf zu nehmen. Es ist hingegen nicht möglich, alle vier angegebe-nen Aspekte gleichzeitig zu optimieren. Wer eine Applikation mit hohemFunktionsumfang in kurzer Zeit durchboxen will, darf sich nicht wun-dern, wenn die Usability für die späteren Anwender auf der Streckebleibt.

Die Entscheidung für Qualität ist eine wesentliche Voraussetzung,dass Usability-Aktivitäten im Unternehmen mit der erforderlichen Prio-rität durchgeführt werden können. Dann kann Usability Engineering zum


Unternehmenserfolg beitragen, Kunden nachhaltig begeistern und Mitar-beitern wirklich effiziente Anwendungen liefern.

DenkanstoßSpiegelt die Vision Ihres Unternehmens die originären Bedürfnis-se Ihrer Kunden wider? Leiten sich Ihre Mission Statements ausden grundlegenden Problemen der Benutzer ab oder stehen vielmehrtechnologiegetriebene Ansätze dahinter? Google publiziert auf seinerWebsite (www.google.com) die Firmenphilosophie in zehn Punkten.Der erste Punkt ist: „Focus on the user and all else will follow“. Wieist das Leitbild ihrer Firma?

5.5 Wie sieht es in IhremUnternehmen aus?

Überlegen Sie sich die folgenden Punkte für das Unternehmen, in demSie arbeiten. Betrachten Sie das letzte Projekt, an dem Sie beteiligt wa-ren.

• Auf welchem Weg gelangen heute die Anforderungen der Benutzer indie Entwicklung?

• Welches sind die beteiligten Stellen, Prozesse und Instrumente?• Wie erfolgt das Feedback der Benutzer?• Wie zufrieden waren die Benutzer mit dem Resultat? Ist dies über-

haupt bekannt?

Beurteilen Sie Schwachstellen und Stärken dieses Vorgehens. Wo kön-nen Sie mit gezielter Institutionalisierung von Usability Engineering eineVerbesserung erreichen?

DenkanstoßBetrachten Sie die folgenden realen Beispiele anhand der aufgeführ-ten Punkte. Gibt es typische Muster?

Beispiel 1In einer Großbank wird eine spezialisierte Applikation für Kunden-berater von einer internen Software-Entwicklungsabteilung erstellt.

5.5 Wie sieht es in Ihrem Unternehmen aus? 127

Die Anforderungen der Geschäftseinheiten werden von Benutzerver-tretern eingebracht und von einer speziellen Einheit von Business-Analysten gesammelt. Sie erstellen Spezifikationen und geben diese inForm von umfangreichen Dokumenten an die Entwickler weiter. DerEntwicklungsprozess des Unternehmens sieht Sign-offs vor, in denendie Spezifikationen von den verschiedenen Fachstellen geprüft undfreigegeben werden, bevor schließlich implementiert wird. Zwischenden Entwicklungs- und Business-Einheiten gibt es keine direkte Kom-munikation. Die Kundenberater werden erstmalig bei Einführung mitder neuen Anwendung konfrontiert. Die Akzeptanz für die neue Lö-sung ist denkbar schlecht, die Kundenberater arbeiten mehrheitlichmit dem alten System weiter.

Beispiel 2Im Bereich der öffentlichen Verwaltung ist eine zentrale Einheit fürdie Definition und Einführung von neuen IT-Lösungen für die rund 40Geschäftsstellen mit Kundenkontakt zuständig. Um die Anforderungenzu sammeln, finden regelmäßige Boardmeetings der Geschäftsstellen-leiter mit dem Leiter der zentralen Einheit statt. Die Anforderungenwerden dokumentiert und zum größten Teil an externe IT-Dienstleis-tungsanbieter in Auftrag gegeben. Bei der zentralen Einheit arbeitenzwei bis drei ehemalige Geschäftsstellen-Mitarbeiter, die das Wissenüber die Geschäftsfälle einbringen und die zudem den telefonischenSupport für die Geschäftsstellen übernehmen. Das Feedback aus denGeschäftsstellen ist unterschiedlich, die eingeführten Lösungen sindvielfach zu komplex.

Beispiel 3In einem Unternehmen der Maschinenbauindustrie ist die For-schungs- und Entwicklungsabteilung zuständig für die Weiterentwick-lung der Maschinen. Die Kundschaft ist international und umfasstunterschiedliche Kulturen. Der Produktmanager formuliert zusam-men mit dem Marketing die Anforderungen an die neue Produktlinieund hält diese in einem Lastenheft fest. Als Grundlage dienen dasFeedback der Vertriebsgesellschaften und die Features der Kon-kurrenz. Im Entwicklungsprojekt werden Maschine, Steuerung und


Bedienpanel voneinander getrennt spezifiziert und entwickelt. Ers-tes Feedback durch Kunden erhält das Projekt an Fachmessen unddurch ausgewählte Verkäufer an Marketingveranstaltungen. Die Ma-schine integriert sich gut in den Produktionsprozess der Kunden, istjedoch umständlich zu benutzen und für angelerntes Personal kaumverständlich.


In vielen Fällen können Benutzer und Projektteam nicht direkt mitein-ander kommunizieren. Vielleicht gibt es noch gar keine Benutzer für einneues Produkt, oder die Benutzer sind schwer greifbar. Oft erzeugen Ent-scheidungsträger aber Distanzen und Barrieren aus unternehmerischenÜberlegungen mit entsprechenden Auswirkungen auf die Kommunika-tion:

• Geografische Entfernung: Die Software- oder Produktentwicklungaus Kostengründen an einen billigeren Standort auszulagern, erzeugtDistanz zum eigentlichen Geschäft und damit schwierigere Kommu-nikationswege.

• Kulturelle Hürden: Neben der geografischen Distanz kommenSprachbarrieren und Kulturunterschiede hinzu.

• Unternehmensgrenzen: Technische Funktionen werden an Drittfirmenund deren Zulieferer vergeben. Im internationalen Geschäft wird zu-sätzlich über Vertriebspartner und Servicestellen gearbeitet. Prozesse,Management und Unternehmensziele sind unterschiedlich.

• Organisatorische Entfernung: Auch innerhalb eines Unternehmenssind Benutzer organisatorisch von der Entwicklung weit entfernt.Auch wenn Zwischenstellen wie Benutzervertreter, Business-Analys-ten, Vorgesetzte und Fachstellen wichtige koordinierende Funktionenübernehmen, muss der Informationsfluss dabei viele Stellen durchlau-fen.

• Methodische Lücken: Business-Analysten halten Anforderungen inabstrakten Spezifikationen fest, Marktforschungseinheiten verpackenErkenntnisse über Zielgruppen in Statistiken und Vorgesetzte fassenBenutzerbedürfnisse zusammen. So notwendig die Konsolidierung

5.5 Wie sieht es in Ihrem Unternehmen aus? 129

der Benutzeranforderungen auch ist – falsche Methoden verhindern,dass wichtige Informationen über die Benutzer den Weg zu den Ent-wicklern finden.

6That’s life: Beispiele aus der Praxis

Die einen, so scheint mir, haben viele Werkzeugeund wenig Ideen; die anderen haben viele Ideenund gar keine Werkzeuge.(Denis Diderot)

In diesem Kapitel möchten wir Ihnen vier Projekte präsentieren, die denEinsatz der vorgestellten Usability-Methoden in der Software- und Pro-duktentwicklung näher beleuchten. Vielleicht kommt Ihnen die eine oderandere Herausforderung bekannt vor?

6.1 Fallstudie 1: Usability und RequirementsEngineering sorgen für gutes Klima

Im Rahmen der Neuentwicklung einer Berechnungs- und Auslegungs-software für einen Hersteller von Luftbefeuchtungsanlagen wurdenUsability- und Requirements-Engineering-Aufgaben so integriert, dassmit wenig Aufwand eine effiziente und einheitliche Anwendung ent-stand.


132 6 That’s life: Beispiele aus der Praxis

Steckbrief

Benutzer Verkäufer der verschiedenen LändervertretungenProdukt Software zur Auslegung von Luftbefeuchtungs-Anlagen mit

ProduktkatalogUsability-Ziele Verkaufsprozess effektiv und effizient gestalten, Konsistenz

über alle ProduktfamilienProjektphase Vision bis RealisierungMethoden Personas und Szenarien, Contextual Inquiry, UI Storyboards,

UI Prototyping, Use Cases, Usability Walkthroughs

Ausgangslage

Luftbefeuchtungsanlagen kommen in den unterschiedlichsten Anwen-dungsgebieten zum Einsatz. In Bürogebäuden oder Einkaufszentren sollbeispielsweise ein gesundes und angenehmes Luftklima entstehen, Kran-kenhäuser sind auf optimale Hygiene angewiesen, in Lebensmittellagerndürfen die Kartoffeln nicht verfaulen, während auf Baustellen die Aus-härtung des Betons nur mit der notwendigen Luftfeuchtigkeit optimalverläuft. Dafür stehen unterschiedliche Technologien und Komponentenzur Verfügung, welche beispielsweise durch Verdampfung oder Einsprit-zung für die richtige Luftfeuchtigkeit sorgen.

Für eine erste Berechnung und Auslegung solcher Luftbefeuchtungs-anlagen kommen Software-Anwendungen zum Einsatz, die den Verkäu-fer in der richtigen Auswahl und Dimensionierung der Komponentenfür die Angebotserstellung unterstützen. Bei größeren Projekten sind aufKundenseite meist externe Planer für die Konzipierung der Befeuch-tungsanlagen verantwortlich.

Die bisher eingesetzten Berechnungsprogramme sind komplex undumständlich und zudem für jede Produktfamilie und Technologie unter-schiedlich.

Herausforderungen

• Bei Projektstart ist noch nicht sicher, ob die neue Software ausschließ-lich für die Verkäufer oder alternativ auch für die externen Planer derLuftbefeuchtungsanlagen zum Einsatz kommen soll.

6.1 Fallstudie 1: Usability undRequirements Engineering sorgen für gutes Klima133

• Die neue Anwendung soll in den Ländervertretungen des Unterneh-mens weltweit eingesetzt werden. Die Ländervertretungen unterschei-den sich nicht nur in Sprache und regionalen Anforderungen, sondernauch stark bezüglich Größe, Verkaufsprozess und anzubindenden Sys-temen.

• Für verschiedene Produktfamilien stehen unterschiedliche Berech-nungsprogramme und Produktkataloge zur Verfügung. Eine Heraus-forderung besteht darin, eine einheitliche Applikation zu erstellen,welche die gesamte Produktpalette des Unternehmens integriert, unddabei jegliche unnötige Komplexität für die Benutzer vermeidet.

Vorgehen

Die ersten Workshops mit dem Auftraggeber dienten der Analyse desVerkaufsprozesses im Hinblick auf die neue Lösung. Eine genauere Be-trachtung der potenziellen Benutzergruppen ergab, dass die Bedürfnisseder Verkäufer und jene der Planer auf Kundenseite sich so stark unter-schieden, dass sie nicht gleichzeitig mit der neuen Anwendung adressiertwerden konnten. Als wichtiger Schritt musste deshalb die Zielgruppeeingegrenzt werden. Die Verantwortlichen entschieden, die geplante ers-te Version der Software ausschließlich für die Verkäufer zu entwickeln.

In einem Benutzerworkshop kamen Teilnehmer aus fünf verschie-denen Ländervertretungen zusammen, um realistische Personas undAnwendungsszenarien für den Einsatz der neuen Software zu erarbeiten.Die Szenarien lieferten eine wichtige Basis für die optimale Unter-stützung eines typischen Verkaufsablaufs und dienten der Eingrenzungund Fokussierung der Funktionalität für die Benutzer. Der Austauschzwischen den Teilnehmern erlaubte auch eine erste Abgrenzung derneuen Software gegenüber den in den Ländervertretungen eingesetztenSystemen, beispielsweise zur Erstellung und Ablage der schriftlichenAngebote oder für die Nachbestellung von Produkten und Komponen-ten bei der Muttergesellschaft.

Als nächster Schritt erfolgte ein Besuch in einer typischen Vertre-tung im Ausland. Die Verkäufer gaben Auskunft über ihren Arbeitsablaufvom Anruf des Kunden bis zur schriftlichen Angebotserstellung. Einigekritische Arbeitsschritte wurden vor Ort live beobachtet. Dabei konntenweitere wertvolle Informationen über die Arbeitsplätze, Prozesse und das


Abb. 6.1 a Grundlegende GUI-Konzepte wurden mit einfachen Handskizzen visua-lisiert. Die Zeichnung zeigt einige für die Berechnung der Luftfeuchte notwendigeParameter sowie die Einbettung in den vorgesehenen Dialogablauf. b Die verfeiner-ten Dialoge wurden in einem detaillierten Storyboard in Zusammenhang gebracht.Die Screens wurden mit MS Visio® erstellt

Umfeld für den Einsatz der Software gesammelt werden. Die erarbeitetenAnforderungen wurden in einem Visionsdokument zusammengefasst.

Mit User Interface Storyboards holte das Team in kurzen ZyklenFeedback von den Fachvertretern ein. Die Storyboards zeigten dieAbläufe für die Auswahl und Berechnung der Komponenten der Be-feuchtungsanlagen und gaben einen ersten Eindruck der vorgesehenenGUI-Konzepte der Applikation. Abbildung 6.1 zeigt verschiedene Aus-führungen.

Auf Basis dieser Storyboards und der dokumentierten Anforderungenerstellte das Team einen lauffähigen GUI- und Architektur-Prototypen,der weitere Feedbackrunden am sichtbaren Objekt erlaubte. Paralleldazu wurden die funktionalen Abläufe mit Anwendungsfällen formal be-schrieben und in mehreren Iterationen weiter detailliert.

Der GUI-Prototyp ermöglichte bald, in Usability Walkthroughs dasFeedback der Benutzer einzuholen. Dazu bearbeiteten die Verkäufermit dem Prototypen eine fiktive Kundenanfrage. Die Ergebnisse derWalkthroughs flossen in Form von weiteren Optimierungen in den Pro-totypen ein.

Die vollständige Realisierung der Applikation erfolgte schließlich aufBasis des Prototypen sowie der Spezifikation bestehend aus den Use-Case-Beschreibungen und zusätzlichen Anforderungen.

6.2 Fallstudie 2: Usability Engineering von A bis Z 135

Nutzen und Fazit

• Mit der aktiven Eingrenzung der Zielgruppe in einer frühen Projekt-phase wurde die Produktvision wesentlich fokussierter. Dies war einerster wichtiger Schritt zur Vermeidung unnötiger Funktionalität unddie Voraussetzung für eine gute Benutzbarkeit.

• Durch die frühe Einbeziehung von Benutzern aus verschiedenen Län-dervertretungen und die gemeinsame Erarbeitung von Anwendungs-szenarien konnten unterschiedliche Bedürfnisse sofort adressiert undein gemeinsames Verständnis erzielt werden.

• Die Visualisierung der Arbeitsabläufe mit User Interface Storyboardsund GUI-Prototypen erlaubte eine frühe Überprüfung der Anforde-rungen. Die Zusammenführung der verschiedenen Produktfamilienfür die Luftbefeuchtung in eine einheitliche Lösung wurde sicht-bar und konnte vom Produktmanagement und den Fachvertreternjederzeit begutachtet werden. Dank des iterativen Vorgehens konntenLösungsvorschläge schnell auf die Bedürfnisse der Benutzer ange-passt werden.

• Die parallele Erstellung des GUI-Prototypen und der Use Cases stelltesich als sehr effizientes Vorgehen heraus. Der GUI-Prototyp erlaubtees, die einzelnen Schritte der Anwendungsfälle am sichtbaren Objektspielerisch nachzuvollziehen, während die Use Cases mit Alternativ-und Fehlerabläufen die Spezifikation vervollständigten. GUI-Abläufeund Use Cases befruchteten sich so gegenseitig.

• Die Vorgehensweise mit schlanken Methoden aus dem Usability- undRequirements Engineering führte mit wenig Aufwand zu guten Resul-taten und insgesamt zu einer vergleichsweise kurzen Projektlaufzeit.

6.2 Fallstudie 2: Usability Engineering von A bis Z

Usability Engineering begleitet ein Projekt idealerweise in seiner gan-zen Dauer, von den ersten Ideen bis zum Betrieb. Im Rahmen einesProjekts im Bahnumfeld wurden Usability-Methoden durchgängig in dieEntwicklung integriert. Dies stellte sicher, dass die Anwender eine Soft-ware erhielten, welche den hohen Anforderungen ihrer täglichen Arbeitgerecht wurde.


Steckbrief

Benutzer Operatives Personal mehrerer BahnverkehrsunternehmenProdukt Individualsoftware für die Behandlung von Störungen im

BahnverkehrUsability-Ziele Schnell und mit wenigen Fehlern in einer anspruchsvollen

Situation kommunizierenProjektphase Vision, Konzept, Realisierung in zwei SchrittenMethoden Contextual Inquiry & Design, Storyboards, UI Prototyping,

Usability Walkthroughs und Tests, Rollenspiele, Feedback-Fragebogen

Ausgangslage

Tritt im Bahnverkehr eine Störung auf, werden innerhalb weniger Minu-ten eine große Anzahl von Personen aktiv, um diese Störung zu behebenund die Auswirkungen auf die Kunden sowie die Züge zu minimieren.Dazu müssen viele Detailinformationen und Entscheidungen kommu-niziert werden: Wie verläuft die Störung, was soll mit den betroffenenZügen geschehen, wie können die Reisenden möglichst pünktlich an ihrZiel gebracht werden und mehr. Bei größeren Ereignissen, beispielsweisewenn eine Strecke überhaupt nicht mehr befahren werden kann, werdenvorbereitete Notfallkonzepte eingesetzt.

Die bisher übliche Kommunikation per Telefon ist redundant, fehler-behaftet und kostet wertvolle Zeit, die für die eigentliche Ereignisbe-wältigung fehlt. Das neue System soll diese Informationen präzise undzuverlässiger zu den Benutzern bringen, sodass diese schnell und richtighandeln können.

Herausforderungen

• Tritt eine Störung ein, sind die Anwender vollauf mit deren Bewälti-gung beschäftigt. Überflüssige Information ist möglichst zu vermei-den und der Aufwand für die Bedienung der Software zu minimieren.


Abb. 6.2 In Workshops mit Benutzern, Fachexperten und Usability Engineers wur-den Anforderungen an die neue Software gemeinsam in Skizzen erarbeitet. DieSkizzen zeigen erste Konzepte zur effizienten Behandlung von Störungen im Bahn-betrieb (© Schweizerische Bundesbahnen, 2009)

• Mehrjährige Erfahrung und großes Fachwissen ist für die Störungs-behandlung notwendig – Wissen, das nur langjährige Mitarbeiterbesitzen. Diese müssen deshalb in das Projekt eingebunden werden.

• Die Benutzer verlassen sich auf die Informationen im System. Falscheoder fehlende Angaben können kostspielige Folgen haben.

Vorgehen

Ein Team aus Anwendern und Fachexperten wurde von einem Usabi-lity Engineer unterstützt und legte mit Requirements- und Usability-Methoden die Basis für die Entwicklung. Anhand von Fallbeispielenskizzierte das Team Ideen und Ansätze mit Mock-ups auf Papier. Ab-bildung 6.2 zeigt gemeinsam erstellte Skizzen aus den Workshops.

Ebenfalls analysierte das Team die Kommunikation in einer Störung.Dazu wurden Videokameras aufgestellt – mit der Bitte, diese in einemStörungsfall einzuschalten. Diese Aufnahmen und die anschließendenInterviews lieferten nicht nur wertvolle Detailkenntnisse, sondern schärf-ten auch die Produktvision. Es zeigte sich beispielsweise, dass dieDisponenten viele Informationen entgegennahmen und weitergaben –und wenig Zeit für die eigentliche Behandlung der Störung übrig blieb.Die Disponenten von der Rolle einer Informationszentrale zu entlasten,wurde zu einem wichtigen Fokus für die Software.


Die gefestigte Vision ermöglichte es nun, die vielen gesammelten Lö-sungsansätze zu konsolidieren und zu detaillieren. Das Team erstelltedabei insbesondere ein Storyboard. Dieses visualisierte das neue Sys-tem zum ersten Mal mit vielen wichtigen Details des User Interface, derangebundenen Systeme und im Zusammenhang mit der täglichen Ar-beit. Nutzen und Bedenken konnten mit Mitarbeitern und Vorgesetztendiskutiert werden. Des Weiteren untersuchte das Projektteam die Auswir-kungen auf die Prozesse. Rollenspiele halfen, die notwendigen Änderungan den Prozessen abzuschätzen und ein erstes Gefühl für die Umsetzbar-keit zu gewinnen.

Schließlich wurde ein interaktiver UI-Prototyp erstellt. Dieser zeig-te einen großen Teil der geplanten Funktionen und war zusammen miteiner Anforderungsdokumentation der Ausgangspunkt für die Entwick-lung. Aber erst, nachdem der UI-Prototyp in Usability Walkthroughs dieNützlichkeit des Systems hinreichend belegt hatte.

Für die nun startende Entwicklung wurde das Team um Software-Entwickler und einen Interaction Designer erweitert. Usability-Methoden wurden fortschreitend eingesetzt. Einerseits arbeitete dasTeam mit Mock-ups die Benutzerschnittstelle im Detail aus. Ande-rerseits gaben punktuell eingesetzte Usability Tests Sicherheit unddas nötige Wissen, um schwierigere Design-Probleme zu lösen. Bei-spielsweise wurde im mobilen Usability Lab die Geschwindigkeit derTastatureingaben optimiert. Das iterative Vorgehen ermöglichte es demProjektteam, noch vor Ablauf des Projekts eine erste Version in Betriebzu nehmen. Das ungeschminkte Feedback der täglichen Arbeit konnteso in die Entwicklung einfließen. Abbildung 6.3 zeigt einen Screenshotder fertigen Software.

Nutzen und Fazit

• Experten der täglichen Arbeit, also künftige Benutzer, waren kontinu-ierlich im Projekt eingebunden. Das kritische Wissen der Störungsbe-handlung war im Team verfügbar. Diese Teamzusammensetzung legtedie Basis für die Nützlichkeit der Software.

• Usability-Methoden waren nicht allein das Arbeitsmittel eines Ex-perten, sondern des Projektteams als Ganzem. Insbesondere auch die


Abb. 6.3 Screenshot der fertigen Software mit Übersicht, Störungsmeldungen undStörungsbehandlung mit Visualisierung für das operative Bahnpersonal (© Schwei-zerische Bundesbahnen, 2009)

Anwender im Projektteam wurden in der Anwendung der Methodengeschult. So konnte jeder im Rahmen seiner Tätigkeit zur guten Be-nutzbarkeit beitragen.

• Dadurch, dass Benutzbarkeit systematisch und von Beginn an be-trachtet wurde, besaßen realisierte Teile bereits eine hohe Usability.Während der Entwicklung selber konnten deshalb die im Verhältnisaufwändigen Usability-Tests sehr gezielt und damit sehr effizient ein-gesetzt werden: in erster Linie zur Optimierung besonders schwierigerAspekte.

• Die komplexe, tägliche Arbeit war in einer künstlichen Situation, wiesie beispielsweise in einem Usability Lab erzeugt werden kann, nurungenügend nachstellbar. Es war deshalb notwendig, bereits früh eineerste Version in Betrieb zu nehmen, um auf eventuelle Unzulänglich-keiten reagieren zu können.


6.3 Fallstudie 3: User Centered Innovation –Simulierte Realität

Wie kann Usability Engineering die frühen Projektphasen unterstützen,wenn weder Produkt noch Benutzer vorhanden sind? Diese Fallstudiebeschreibt das benutzerorientierte Vorgehen für die Planung und Kon-zeption einer neuen Fernbedienung für Hörgeräte.

Steckbrief

Benutzer Personen mit HörschwächenProdukt Fernbedienung für HörgeräteUsability-Ziele Dem Benutzer eine effiziente Einstellung auf die aktuelle

Hörsituation ermöglichen; Komplexität vermeidenProjektphase Vorprojektphase, Analyse, Vision, Konzept, RequirementsMethoden Interviews, Personas und Szenarien, Interaktionsdesign, UI

Prototyping, Usability Testing

Ausgangslage

Die meisten Hörgeräte verfügen heutzutage über verschiedene Einstell-möglichkeiten, mit denen der Hörgeräteträger die jeweilige Hörsituationbeeinflussen kann. Personen mit eingeschränktem Hörvermögen könnenbeispielsweise die Lautstärke optimal auf ihre Bedürfnisse einstellen undzwischen Programmen für spezielle akustische Situationen wechseln.Die Bedienung findet je nach Modell entweder direkt am Hörgerät stattoder alternativ über eine spezielle Fernbedienung, die der Benutzer beisich trägt.

Aktuell angebotene Fernbedienungen bieten umfangreiche Funktio-nen, sind aber für viele Benutzer zu komplex. Eine zukünftige Produkt-palette von Hörgeräten soll deshalb eine neuartige, stark vereinfachteFernbedienung beinhalten. Diese neue Fernbedienung soll klein, leichtund sehr einfach in der Handhabung sein. Die Anforderungen der Trägervon Hörgeräten an eine solche Fernbedienung sind aber noch weitgehendunbekannt.

6.3 Fallstudie 3: User Centered Innovation – Simulierte Realität 141

Herausforderungen

• Das Projekt befindet sich in einer frühen Innovationsphase mit sehrvielen Freiheitsgraden für das zukünftige Produkt. Zielgruppen,Funktionsumfang, Größe und Form, technologische Lösungsvari-anten, Tastenbelegung und viele andere Punkte sind noch offen undentsprechend viele unterschiedliche Meinungen und Vorstellungenüber mögliche Lösungsansätze existieren im Unternehmen.

• Bei den potenziellen Benutzern, den Trägern von Hörgeräten, handeltes sich um eine schwer einzugrenzende Zielgruppe mit unterschiedli-chen Bedürfnissen. Ein Großteil sind ältere Personen mit zunehmen-dem Hörverlust. Komplexe Funktionen und Bedienvorgänge solltengerade für ältere Menschen vermieden werden. Eigenschaften undVerhaltensmuster, wie beispielsweise der Grad an Mobilität und Ak-tivitäten unterscheiden sich aber individuell stark. Dies führt zuabweichenden Anforderungen, was Häufigkeit und Art der Bedienungihrer Hörgeräte anbelangt.

• Die Aufgabe des neuen Produkts ist das situative Anpassen desHörgerätes für ein optimales Hören. Solche Hörsituationen sind nurschwer beobachtbar. Die für die Benutzer passende Einstellung ist fürAußenstehende nicht objektiv nachvollziehbar.

• Die akustische Erlebniswelt und wichtige Konzepte bei der Bedie-nung von Hörgeräten lassen sich nur schwer in Worte fassen undbeschreiben. Ein gemeinsames Verständnis für alle Projektbeteiligtenist deshalb umso wichtiger.

Vorgehen

In einer ersten Phase erfolgte eine Bestandsaufnahme im Unterneh-men, um relevante Informationen über Hörgeräteträger und die Ver-wendung und Bedienung von Hörgeräten zusammenzutragen. DieseAnalyse bestand in erster Linie aus Gesprächen und Workshops mit Inter-essensvertretern und Spezialisten, beispielsweise Produktmanagement,Forschung und Entwicklung, Marketing und Marktforschung. Personenmit direktem Kundenkontakt konnten wertvolle Informationen über dieBenutzerbedürfnisse beitragen, zum Beispiel Audiologen, die für die


individuelle Anpassung des Hörgerätes für den Hörgeräteträger verant-wortlich sind. Weitere wichtige Grundlagen waren Kundenfeedbacks zubestehenden Produkten, Ergebnisse von Marktforschungs- und Benutzer-studien, Konkurrenzprodukte sowie Unternehmens- und Projektziele. Ineinem Visionsdokument wurden die gesammelten Resultate festgehalten.

In einem nächsten Schritt erstellte und priorisierte das Team Personasund Anwendungsszenarien für die neue Fernbedienung. Die Basis dazulieferten Workshops sowie Interviews mit Hörgeräteträgern, in welchendie Bedürfnisse bei der Bedienung von Hörgeräten und dem Einsatz vonFernbedienungen ausgelotet wurden.

Für die weitere Definition von Form, Bedienelementen, Tastenbe-legung und Funktionen der neuen Fernbedienung war es notwendig,verschiedene Varianten und Hardware-Prototypen mit Benutzern zuüberprüfen. Das Ziel dabei war, mit Usability-Tests in kurzen ZyklenResultate zu erzielen, problematische Lösungsvarianten auszuschließenund das Interaktionsdesign weiter zu verfeinern.

Zu diesem Zweck wurde eigens eine Prototyping-Plattform ent-wickelt, welche mit Hilfe von Video Clips und Audio Streams dasHörerlebnis für den Benutzer in beliebigen Umgebungen simuliert undeinen realistischen Eindruck einer funktionstüchtigen Fernbedienung fürHörgeräte erzeugt. Mithilfe dieser Prototyping-Plattform konnten sowohlbestehende Anwendungsfälle für die Bedienung heutiger Hörgeräte über-prüft werden, als auch Szenarien für zukünftige Hörgerätegenerationenausprobiert werden, die in dieser Form nicht existieren oder technischnoch nie umgesetzt wurden.

An den Usability-Tests nahmen Hörgeräteträger aus den möglichenZielgruppen teil. Die Benutzer bekamen auf der Prototyping-Plattformrealistische Hörsituationen präsentiert und interagierten mit verschiede-nen Prototypen der Fernbedienung. Bereits die ersten Usability-Testseri-en konnten Hardware-Varianten ausschließen, weil sich Bedienelementein der tatsächlichen Anwendung als vergleichsweise schlecht mani-pulierbar herausstellten, während andere bei den Benutzern sehr gutabschnitten. Abbildung 6.4 zeigt einige zu diesem Zweck erstellteHardware-Prototypen der Fernbedienung mit unterschiedlichen Tasten-anordnungen, die in den Usability-Tests verwendet wurden.

Eine zentrale Fragestellung für die Entwicklung der neuen Fernbe-dienung war der Zusammenhang von Funktionsumfang und Manipula-

6.3 Fallstudie 3: User Centered Innovation – Simulierte Realität 143

Abb. 6.4 In Usability-Tests verwendeten die Benutzer unterschiedliche Hardware-Prototypen der Fernbedienung. Sowohl die physischen Bedienelemente als auch dieTastenbelegungen sowie Funktionen und Interaktionskonzept der Fernbedienung wur-den variiert

Abb. 6.5 Das Endprodukt:Eine neue, einfache undeffiziente Fernbedienungfür Hörgeräte mit wenigenTasten und optimalem Inter-aktionskonzept (© PhonakAG, 2012)

tionsmöglichkeiten, welche das User Interface der Fernbedienung bietensollte. Ein Ziel war beispielsweise, die Anzahl Tasten der Fernbedienungmöglichst gering zu halten, und dabei für die Benutzer eine effizienteBedienung der wichtigsten Einstellmöglichkeiten sicherzustellen. In denUsability-Tests zeigte sich, dass sowohl zu viele Tasten, als auch eine zugeringe Anzahl Tasten mit Mehrfachbelegung die Benutzer überforderte.Nach wenigen Iterationen konnte schließlich ein gut verständliches In-teraktionskonzept mit einer optimalen Tastenbelegung gefunden werden.Abbildung 6.5 zeigt die neue Fernbedienung, wie sie schließlich auf denMarkt kam.


Nutzen und Fazit

• Eine benutzerorientierte Methodik kann bereits in der Innovations-phase wichtige Aspekte aus Benutzersicht beitragen und damit nebentechnischen Rahmenbedingungen und strategischen Entscheidungenmaßgebliche Anhaltspunkte für die Konzeption eines neuen Produk-tes liefern.

• Die Personas und Szenarien dienten den Projektbeteiligten zum Auf-zeigen von impliziten Annahmen über Benutzer und Anwendungssi-tuationen. Dies erlaubte Diskussionen und schaffte eine gemeinsameVorstellung der Produktvision.

• Aufgrund der Benutzerbedürfnisse konnte bereits zu einem frühenZeitpunkt eine Abschätzung der Wichtigkeit verschiedener Funktio-nen aus Benutzersicht vorgenommen werden. Das Vorgehen erlaubteeine Eingrenzung des geplanten Funktionsumfangs und damit eineReduktion der Komplexität für die Benutzer.

• Die Prüfung von Varianten in iterativen Usability-Testserien dienteder Risikominimierung, indem wenig erfolgreiche Lösungen bereitsfrüh im Prozess ausgeschieden und erfolgreiche Design-Variantenweiter optimiert werden konnten.

• Die eigens für die Usability-Tests entwickelte Prototyping-Plattformermöglichte eine schnelle Umsetzung von Varianten des Interaktions-designs. Es musste keine aufwändige Entwicklung in Kauf genommenwerden, um lauffähige und testbare Prototypen auf der Hörgeräte-Zielplattform zu realisieren. Dies stellte sich als großer Vorteil her-aus. Damit war es möglich, zu einem frühen Zeitpunkt ausgereifteInteraktions-Konzepte für die neue Fernbedienung zu erarbeiten unddiese mit Benutzern zu überprüfen.

6.4 Fallstudie 4: Gezielter Einsatz, großeWirkung

Nicht in jedem Fall besteht die Möglichkeit, einen Experten für Usabili-ty Engineering über das ganze Projekt einzubinden. Wir möchten Ihnendeshalb hier ein Fallbeispiel zeigen, bei welchem ein kurzer Einsatz einegroße Wirkung erzielte.

6.4 Fallstudie 4: Gezielter Einsatz, große Wirkung 145

Abb. 6.6 Eine Handskizzedes geplanten Bedienpanelsillustriert die Kombinationvon Bedienelementen undGUI

Steckbrief

Benutzer Operateure, Einrichter und ServicepersonalProdukt Bedienpanel einer Schneidemaschine für Bleche im industri-

ellen BereichUsability-Ziele Einfachheit und vielfältige Anwendung unter einen Hut

bringenProjektphase Konzept, AnforderungserhebungMethoden Personas und Szenarien, UI Prototyping, Design Workshops,

Use Cases

Ausgangslage

Ein Hersteller von Schneidemaschinen ist gut im High-end-Bereich po-sitioniert und will mit einem neuen Produkt in ein neues Marktsegmentvordringen. Dieses soll insbesondere auch bereits für kleine Firmen mitzwei bis drei Angestellten erschwinglich sein. Mit der Maschine kanneine solche Firma Kleinserien von Blechteilen in einer fast beliebigenForm aus einem Blech schneiden, beispielsweise für Lampen, Zahnräder,Luftgitter, Halterungen und vieles mehr. Die Entwicklung der Maschi-ne selber ist bereits gut vorangeschritten, und es geht nun darum, diegrafische Benutzerschnittstelle des Bedienpanels zu definieren. Abbil-dung 6.6 skizziert ein solches Bedienpanel für eine Schneidemaschine.


Herausforderungen

• Der internationale Vertrieb der Maschine erzeugt eine große Distanzzu den Benutzern, nicht nur geografisch, sondern auch unternehmens-bezogen: Der Hersteller kommuniziert mit den Kunden nur indirektüber die lokalen Vertriebsgesellschaften.

• Das Bedienpanel besteht nicht nur aus einem GUI, sondern ist auchein Stück Hardware und Teil einer Maschine. Die Funktionsweise derMaschine beeinflusst das Panel und umgekehrt.

• Für Usability Engineering waren nur wenige Tage Aufwand budge-tiert.

Vorgehen

Der Einsatz des Usability Engineer fokussierte sich in diesem Projektauf die Phase der Anforderungserhebung. Einfache Personas halfen, dasZielpublikum dem Projektteam näher zu bringen. Die Grundlagen warenInformationen, welche von den lokalen Vertriebsgesellschaften mittelsFragebogen eingeholt wurden, sowie einzelne Interviews mit Service-technikern und Trainern, welche gelegentlich beim Kunden vor Ort sind.Die Personas räumten mit vielen Vorurteilen auf. So entdeckte das Pro-jektteam nicht den oft zitierten, angelernten Reisbauern, sondern einengut ausgebildeten Ingenieur mit einem Bachelor-Abschluss. Passenddazu zeigten die Personas auch, dass die vorgesehene, strikte Rollen-aufteilung zwischen dem Einrichter, welcher Aufträge auf der Maschinekonfiguriert und dem Operateur, welcher die Aufträge dann ausführt, fürdieses Modell nicht sinnvoll war.

Parallel zu dieser Erhebung erstellte das Team ein User Interface Sto-ryboard. Dieses zeigte ein charakteristisches Anwendungsszenario mitder Maschine in allen Details auf.

Damit waren die Grundlagen für einen Workshop geschaffen. DasZiel war, das User Interface des Bedienpanels zu definieren. Der Wegdazu führte jedoch über den Produktionsprozess als Ganzes: Aufträgedefinieren, Rohmaterialien zuliefern und einführen, Produktion startenund überwachen und gefertigte Teile und Abfälle abtransportieren – in-klusive Fehlerfälle. Es herrschte ein reges Interesse von allen an der

6.4 Fallstudie 4: Gezielter Einsatz, große Wirkung 147

Entwicklung beteiligten Disziplinen: Entscheidungsträger der Mechanik,Elektronik, Systems Engineering, Marketing und mehr waren eingeladenworden und kamen, bereit für eine aktive Diskussion. Diese Teilnehmerspielten nun mit den Personas das Szenario Schritt für Schritt durch. EinStyropormodell der geplanten Maschine stellte die Bühne dar, und dasUser Interface Storyboard das Drehbuch. Mit guten Resultaten: Nichtnur wurde das Konzept für das Bedienpanel in vielen Teilen weiterentwi-ckelt und den Personas und den Prozessen angepasst, auch die Maschineselber wurde verbessert.

Die Erkenntnisse des Workshops wurden vom Projektteam konsoli-diert. Mit der überarbeiteten Version wurde anschließend ein zweiterWorkshop gestaltet, in welchem auf bisher noch offen gebliebene Fra-gestellungen eingegangen wurde und die Arbeiten bestätigt wurden. AufBasis der so entstandenen Szenarien und User Interface Storyboards wardas Dokumentieren der Anforderungen für das Projektteam nun auchsehr einfach. Use Cases und Skizzen des User Interfaces wurden dazuverwendet.

Der Usability-Experte begleitete das Team des Bedienpanels in derMethodik, leitete insbesondere die beiden Workshops und gab regelmä-ßig Feedback zu den vom Team erstellten Mock-ups. Die so erstellteSpezifikation wurde anschließend umgesetzt.

Nutzen und Fazit

• Bei einer Maschine für die industrielle Produktion geben Hardwareund mögliche Produktionsprozesse das User Interface des Bedienpa-nels stark vor. Die Usability-Diskussion fokussierte konsequent aufdie Prozesse und die Hardware und gestaltete dafür das Bedienpanelso einfach wie möglich; mit dem Nebeneffekt, dass auch Optimierun-gen bei Maschine und Prozessen vorgenommen wurden.

• Die Käufer der Maschine und deren Mitarbeiterstruktur definierteninsbesondere Rollenaufteilung und Ausbildungsniveau der Benutzer.Die Personas brachten diese beiden Punkte in die Diskussion ein.Sie schärften den Blick auf das Zielpublikum, und es gelang, eini-ge Vorurteile zu lösen. Einfachere und direktere Abläufe auf demBedienpanel waren die Folge davon.


• User Interface Prototyping mit Papier und mit der Entwicklungsum-gebung erlaubte es, in kurzer Zeit mehrere Iterationen des Bedien-panels durchzuführen. Anpassungen an Personas und Produktions-prozess, wie auch das Feedback vom Gesamtprojektteam und demUsability-Experten konnten so sehr kostengünstig eingearbeitet wer-den.

• Diesem Projekt fehlte eine Feedbackschlaufe mit tatsächlichen Be-nutzern. Eine vertiefte Analyse mit Contextual Inquiry wie auchUsability-Tests mit Benutzern hätten sicherlich noch viele wichtigePunkte zu Tage gefördert. Doch ein solches Vorgehen hätte das Bud-get für Usability Engineering weit überzogen.

• Für Hersteller und Kunden stimmte der gewählte Kompromiss: DerHersteller erhielt mit wenig Zusatzaufwand ein Bedienpanel mit einerim Vergleich zur Konkurrenz guten Usability und die Kunden eineleistungsfähige Maschine zu einem guten Preis, mit welcher auch dieMitarbeiter gut arbeiten konnten.

7Rückblick

Das also war des Pudels Kern!(Johann Wolfgang von Goethe)

Usability Engineering folgt einer bestimmten Philosophie. Dieses Ka-pitel soll einige Kernpunkte nochmals in Form von fünf zentralenPrinzipien zusammenfassen. Es kann hilfreich sein, sich diese Prinzipienin einer ruhigen Minute zu vergegenwärtigen und den eingeschlagenenKurs zu überprüfen.

7.1 Fragestellung: Zielgerichtet vorgehen

Lassen Sie die in diesem Buch vorgestellten Methoden und KonzepteRevue passieren. Es wurde oft betont, wie substanziell die Definitioneiner Fragestellung ist:

• Contextual Inquiry wird von den offenen Fragen gesteuert, die es zubeantworten gilt.

• Personas werden unterschiedlich charakterisiert, je nachdem, ob hoheQualität der Arbeit, hohe Effizienz oder hohe Sicherheit im Vorder-grund steht.

• Aus der Fragestellung lässt sich ableiten, welche Art von Prototypingzielführend ist: Sollen Anforderungen geklärt oder die Benutzer-


150 7 Rückblick

Ziele, Risiken, Fragen---

Vorgehen/Methoden----

Quellen--------

Resultate--------

Ressourcen---

Abb. 7.1 Ein einfaches Hilfsmittel zur gemeinsamen Entwicklung von Fragestellun-gen und Planung der beabsichtigten Usability-Methoden in einem Workshop

schnittstelle konzipiert werden? Geht es darum, ein User Interface zuoptimieren oder für die Entwicklung zu spezifizieren?

• Wie und wann ein Fragebogen zum Einsatz kommt, hängt von derFragestellung der Untersuchung ab.

Jeder Methode sollte eine wohlüberlegte Fragestellung zugrunde liegen.Abbildung 7.1 zeigt ein Hilfsmittel, um in einem Workshop eine Frage-stellung zu entwickeln. Die Teilnehmer schreiben aktuelle Fragen undZiele auf und ergänzen notwendige Quellen, Methoden, beabsichtigteResultate und dafür erforderliche Ressourcen.

7.2 Kontext: Für die Realität entwerfen

Usability hängt per Definition nicht vom Produkt allein, sondern von derWechselwirkung zwischen Benutzer, Werkzeug, Aufgabe und Umfeldab. Usability-Methoden zielen deshalb darauf ab, den realen Anwen-dungskontext einzubeziehen:

• Im Rahmen von Contextual Inquiry geht der Analyst zu den Benut-zern und beobachtet diese bei der Arbeit.

7.3 Partnerschaft: Benutzer konstruktiv einbeziehen 151

• Personas und Szenarien bringen den Kontext in Design und Entwick-lung hinein.

• Storyboards zeigen das Produkt im Umfeld der Benutzung.• In Usability-Tests werden realistische Szenarien durchgespielt.

Eine Software ist kein in sich abgeschlossenes System, sondern untrenn-bar mit dem Kontext verbunden. Die zu erstellende Lösung muss in derWechselwirkung mit ihrer Umwelt betrachtet werden, damit sie auch indiese Umwelt hineinpasst.

7.3 Partnerschaft: Benutzer konstruktiv einbeziehen

Partnerschaft bedeutet, Benutzer als Experten ihres Fachgebietes zu ver-stehen und ihre Wünsche und Bedürfnisse zu berücksichtigen. Benutzerkennen die konkreten Details und Besonderheiten ihrer täglichen Arbeitund sind schließlich die Messlatte für die Praxistauglichkeit des neuenSystems.

• Contextual Inquiry ermöglicht, die Arbeit der Experten vor Ort ken-nenzulernen.

• Storyboards, UI-Prototypen und Styleguides schaffen eine Sprache,die Benutzern und Entwicklern verständlich ist und ermöglichen dieZusammenarbeit.

• In Usability-Tests setzt das Projektteam seine Arbeit systematisch derKritik der Benutzer aus.

• Fragebögen erlauben die Beurteilung eines Systems aus Sicht der Be-nutzer.

Projektmitarbeiter und Benutzer bilden ein interdisziplinäres Team undbearbeiten zusammen eine ausgewählte Fragestellung. So wird konstruk-tive Zusammenarbeit möglich.

7.4 Fakten interpretieren

Fakten werden zusammengetragen, interpretiert und die eigene Interpre-tation wiederum geprüft:

152 7 Rückblick

• Contextual Inquiry und Fragebögen dienen zum Sammeln und Aus-werten von Fakten.

• Personas und Szenarien werden nicht einfach erfunden, sondern ausden gesammelten Informationen herausgearbeitet.

• Use Cases werden aufgrund der Ergebnisse aus der Analyse von Be-nutzern und Kontext erstellt.

• User-Interface-Prototypen werden in Usability-Tests objektiv geprüft.

Es sollten möglichst unvoreingenommene Diskussionen über die Soft-ware geführt werden. Projektmitarbeiter müssen vorgefasste Meinungenüberprüfen und gegebenenfalls revidieren. Lassen Sie die gesammeltenFakten sprechen, hören Sie aufmerksam zu, und entwerfen Sie die zu denFakten passende Software.

7.5 Modellieren: Entwerfen und Feedback einholen

Eine benutzbare Lösung zu entwickeln bedeutet, Entwürfe und Modellezu erarbeiten und mithilfe der Benutzer zu überprüfen und zu optimieren:

• Contextual Inquiry nimmt Bezug auf bereits vorhandene Systeme undArbeitsprozesse. Die Benutzer werden nicht einfach nach ihren Vor-stellungen befragt. Schon in den ersten Interviews schaffen Entwürfeund Prototypen oder vergleichbare Produkte einen Bezug zu der Er-fahrungswelt der Benutzer.

• Personas und Szenarien modellieren Bedürfnisse und Anforderungender Benutzer. In Storyboards und User-Interface-Prototypen werdendiese so aufbereitet, dass die Benutzer eine reale Vorstellung von dergeplanten Lösung erhalten.

• Use Cases repräsentieren die geplante Funktionalität des neuen Sys-tems. Sie werden aufgrund der Rückmeldungen der Beteiligten präzi-siert.

• User-Interface-Prototypen spiegeln die geplanten Abläufe aus Benut-zersicht wider. In Usability Tests wird die Interaktion geprüft undangepasst.

7.5 Modellieren: Entwerfen und Feedback einholen 153

Das Verständnis des Modellierens ist im Usability Engineering es-senziell. Ein effektiv und effizient benutzbares Produkt kann nicht aufAnhieb erstellt werden. Feedbackzyklen auf verschiedenen Ebenen sindnotwendig.

DenkanstoßHalten Sie sich ein aktuelles Projekt vor Augen. Wenn Sie die fünfgeschilderten Prinzipien auf die methodischen Gepflogenheiten indiesem Projekt anwenden würden, was müssten Sie ändern?

8Ausblick

Im letzten Kapitel dieses Buches geben wir Ihnen einen Überblick übereinige verwandte Gebiete und Themen. Eine scharfe Abgrenzung, woUsability Engineering aufhört und ein anderes Gebiet anfängt, ist dabeimit Sicherheit unmöglich und auch nicht unsere Absicht. Dieses Kapitelsoll vielmehr aufzeigen, welche fachlichen Strömungen es gibt, wohinsich die Disziplin entwickelt und unter welchen Begriffen Sie zu einembestimmten Thema weitere Informationen finden können.

8.1 Accessibility

Das Fachgebiet Accessibility setzt sich mit der Frage auseinander,wie technische Systeme für Menschen mit Behinderungen oder Ein-schränkungen zugänglich gemacht werden können. BehindertengerechteTechnologien sind besonders bei öffentlichen Systemen wie beispiels-weise Fahrkartenautomaten, staatlichen Webseiten, Auskunftssystemenoder Internet-Anwendungen von großer Relevanz.

Ein wichtiger Grundsatz beim Thema Accessibility ist zunächst dasPrinzip der Gleichstellung. Menschen, die beispielsweise von visuellen,kognitiven oder motorischen Einschränkungen betroffen sind, sollen dieMöglichkeit erhalten, technische Systeme weitgehend genauso zu nut-zen wie nicht Behinderte. Moderne Technologien tragen gerade für diesePersonen dazu bei, ein selbstständiges Leben zu führen. So erlauben etwa


156 8 Ausblick

elektronische Publikationen auch Blinden oder stark Sehbehinderten dieKonsumation von schriftlichen Medien. Online-Anwendungen ersparenden Weg zur Bank oder ins Lebensmittelgeschäft. Gleichstellungsgeset-ze sind für eine ganze Reihe von Ländern in Kraft, dazu gehören auchDeutschland, Österreich und die Schweiz.

Große Bedeutung erlangte die Einhaltung von Accessibility-Kriteri-en in der Entwicklung von Webseiten. Im Rahmen der Standardisierungvon Web-Technologien wurden Accessibility-Standards verabschiedet,wie z.B. die Web Content Accessibility Guidelines 2.0 [W3C 08], dieseit 2012 in einer ISO-Norm [ISO/IEC 40500 12] festgehalten sind. DasEinhalten dieser Norm stellt beispielsweise die freie Vergrößerung vonSchriften oder die Ausgabe von Inhalten mit Hilfsmitteln wie Braille-Lesegeräten und Sprachausgabesystemen sicher. Im deutschsprachigenRaum hat sich dafür der Begriff barrierefreies Internet eingebürgert.Webseiten der öffentlichen Hand müssen barrierefrei gestaltet sein.

8.2 User Experience (UX)

Die Disziplin User Experience hat zum Ziel, das Gesamterlebnis zuoptimieren, das mit der Nutzung von Diensten oder Produkten zusam-menhängt. Ihre Vertreter führen ins Feld, dass sich Usability zu stark aufdie funktionalen Aspekte technischer Systeme bezieht, und versuchen,die Betrachtungsweise um mehrere Dimensionen zu erweitern:

• Neben der Benutzbarkeit technischer Systeme sollen auch Erlebnissemit nicht technischen Systemen optimiert werden, wie beispielsweiseEinkaufswelten, Museen, Bibliotheken, Messen und ähnlichen Ein-richtungen.

• Der Fokus der Optimierungen liegt nicht allein auf funktionalenAspekten, sondern es werden vermehrt auch emotionale Faktoren be-züglich Design und Ästhetik einbezogen, welche das Vergnügen inder Benutzung erhöhen sollen. Das aktuelle Schlagwort dafür ist Joyof Use.

• Die Betrachtung geht über das zu entwickelnde Produkt hinaus. Ins-besondere in der Interaktion mit Kunden gilt es, das Erlebnis überalle Kundenberührungspunkte des Unternehmens (Customer Touch

8.3 Interaction Design 157

Points) zu verbessern, also beispielsweise alle Kontakte eines Kundenvor und nach der eigentlichen Nutzung eines Produkts. Dazu gehö-ren das Einholen von Informationen ebenso wie die Unterstützungwährend Bestellung und Kauf oder Supportanfragen bei Problemen.Da hier ein positives Erlebnis der Kunden als (potenzielle) Käu-fer im Mittelpunkt der Betrachtung steht, spricht man auch vonCustomer Experience. Das Thema bewegt sich nahe am Dienst-leistungsmarketing, welches ebenso zum Ziel hat, dem Kunden eineideale Erlebniswelt zu vermitteln.

Mit der Behandlung des gesamten Erlebnisses im Umgang mit Produk-ten geht die Disziplin weit ins Produkt-Design, in die Gestaltung derBenutzerschnittstelle und der umliegenden Prozesse. Eine umfassendeDarstellung mit vielen Beispielen bietet das Buch „User Experience De-sign“ [Moser 12].

8.3 Interaction Design

Das Interaktionsdesign definiert die Möglichkeiten zur Steuerung ei-nes Systems, dessen Verhalten sowie Rückmeldungen an den Benutzer.Als Fachgebiet fokussiert sich Interaction Design auf die Herleitungund den Entwurf von Interaktionskonzepten für digitale Produkte undAnwendungen. Neben der Gestaltung der funktionalen Benutzerschnitt-stelle (User Interface Design) steht dabei eine gute User Experienceim weiteren Sinne im Vordergrund, welche das Gesamterlebnis bei derVerwendung des Produktes umfasst. Usability Engineering, InteractionDesign und User Interface Design sind somit in der Regel eng gekop-pelt und nicht scharf trennbar. Mittels Usability-Methoden werden dienotwendige Funktionalität, Informationen und Abläufe definiert und mitBenutzern überprüft. Im Interaction Design werden die Bedürfnisse derBenutzer in konkrete Entwürfe der Benutzerschnittstelle umgesetzt, undim User Interface Design werden die Konzepte auf der Zielplattform im-plementiert.

Das Thema Interaction Design wurde in den vorigen Kapiteln schonmehrmals gestreift:

158 8 Ausblick

• Im Abschn. 3.4 haben wir gezeigt, wie Prototypen unter anderemzur Konzeption der Benutzerschnittstelle, zur Optimierung von Be-dienelementen und zur Ausarbeitung des Designs beitragen können.

• Der Abschn. 3.6 gibt einen Überblick über Richtlinien und Vorgabenfür die visuelle Gestaltung und das Layout einer bestimmten Benut-zeroberfläche.

Interaction Design beinhaltet die folgenden wesentlichen Aspekte:

• Kenntnisse über gute Gestaltung und Designprozesse mit Fokus aufinteraktive Produkte, z. B. aus den Disziplinen der grafischen Gestal-tung oder dem Industriedesign

• Kreative, gestalterische Techniken und Aktivitäten unter Berücksich-tigung der zu vermittelnden Gefühlswelten

• Detaillierte Kenntnisse der eingesetzten Technologie der Benutzer-schnittstelle

Die Art der Benutzerschnittstelle ist dabei von Bedeutung. Währenddie eingesetzten Usability-Methoden für unterschiedliche Technologiensehr ähnlich oder sogar gleich ablaufen, ist es für den Entwurf der Be-nutzerschnittstelle ein wesentlicher Unterschied, ob beispielsweise einDatenverarbeitungssystem, ein mobiles Gerät, ein Bedienpanel zur Ma-schinensteuerung oder ein Fahrkartenautomat entwickelt wird. FolgendePunkte müssen unter anderem berücksichtigt werden:

• Eingabe- und Ausgabemedien wie Stifte, Gesten, Maus und Tastatur,Bildschirme, Touchscreens, Tasten und Displays auf Geräten,

• Zu verwendende Bedienelemente und Interaktionsprinzipien,• Struktur und Layout der Benutzerschnittstelle,• Aspekte wie Ergonomie, grafische Gestaltung, Industriedesign, tech-

nische Umsetzbarkeit, Corporate Design und Ästhetik.

Zu empfehlende Werke zum Thema Interaction Design sind [Cooper etal. 10] sowie [Buxton et al. 12].

8.4 Security und Usability

Das Fachgebiet der IT-Security befasst sich damit, Systeme und diedamit bearbeiteten Informationen vor unerlaubtem Zugriff zu schüt-

8.5 Web Usability 159

zen. Klassischerweise befassen sich Experten dabei vor allem mit dentechnischen Mitteln, wie beispielsweise Verschlüsselung, Identifikati-onsverfahren, Virenschutz, Firewalls usw.

Immer öfter melden sich zum Thema Sicherheit auch Fachleuten ausdem Bereich Usability zu Wort. Ein System kann nur sicher sein, wenndie Benutzer auch richtig mit der Sicherheitstechnologie umgehen. Bei-spiele für falsche Verwendung kennen wir aus unserem eigenen Alltag:Wir verschicken vertrauliche Dokumente unverschlüsselt per E-Mail,verwenden immer wieder dieselben Passwörter oder notieren sie, öffnenpotenziell böswillige E-Mails und so weiter.

Damit Sicherheitstechnologien auch verwendet werden, müssen sieeinfach und effizient sein und dürfen die Arbeit nicht behindern. Eine austechnischer Sicht gesteigerte Sicherheit, die Teamwork, Mobilität oderEffizienz der Benutzer in unzumutbarer Weise einschränkt, wird ganzeinfach umgangen.

Das Gebiet Security setzt sich deshalb immer mehr auch mit denmenschlichen Verhaltensweisen bei der Anwendung von Technologienauseinander. Usability-Methoden helfen dabei, die tatsächlichen Zieleund Handlungsweisen der Benutzer zu verstehen. Entsprechend erschei-nen vermehrt Publikationen, die sich mit der gegenseitigen Abhängigkeitvon Security und Usability befassen. Eine umfassende Darstellung bietetdas Buch Security and Usability [Cranor et al. 05].

8.5 Web Usability

Nach dem Internetboom Ende des letzten Jahrtausends setzte sich beivielen Unternehmen die Erkenntnis durch, dass Websites nur dann eineWirkung erzielen, wenn sie auch bezüglich Usability einen guten Standaufweisen. Es erschienen zahlreiche Publikationen mit Vorgehenswei-sen, Richtlinien, Tipps und Tricks für die benutzerfreundliche Gestaltungvon Web-Auftritten (siehe auch Abschn. 3.6). Web Usability wurde bei-nahe zum Synonym für gutes Web Design.

Die Benutzbarkeit von Websites wird durch einige Besonderheiten be-einflusst:

160 8 Ausblick

Websites stellen meist eine große Menge von Informationen dar, indenen sich ein Besucher zurechtfinden soll. Eine wichtige Frage ist des-halb, wie Benutzer durch das Web-Angebot navigieren. Dazu ist derAufbau einer verständlichen und übersichtlichen Informationsarchitek-tur notwendig.

Auch wenn Grafiken und Bildwelten schon lange im Webdesign Ein-zug gehalten haben, sind Texte nach wie vor das wichtigste Medium zurVermittlung von Informationen und Inhalten. Web Usability beschäftigtsich deshalb auch mit der Darstellung und Aufbereitung von Texten fürdie Verwendung im Web.

Bei Web-Auftritten treffen zwei unterschiedliche Interessen aufein-ander: Zum einen das Ziel der Besucher, Informationen und Inhalteeffizient zu finden, und zum anderen die Absicht der Marketingabtei-lungen, die Identität ihres Unternehmens zu kommunizieren. Für WebUsability ist deshalb ein Verständnis für effektive Kommunikation mitText und Bild von Bedeutung. Zum Thema Web Usability und Web De-sign gibt es viel Literatur. Ein empfehlenswertes Buch ist [Wirth 04].

Durch neue Technologien und aufgrund der zunehmenden Verbrei-tung von Breitbandanschlüssen erfuhr das Web in den letzten zehn Jahrendie zweite große Veränderung seit dem Wandel vom universitären Wis-sensnetz zur kommerziellen Informationsplattform. Multimediale Inhal-te, Kollaboration und Community-Plattformen sind aktuelle Trends, dieunseren Alltag und unser Sozialverhalten verändern. Hier verschmelzenInformationsverbreitung, soziale Interaktion und interaktive Applikatio-nen. Es warten neue Aufgaben auf die Disziplin Web Usability.

8.6 Mobile User Experience

Eine neue Generation mobiler Geräte und Technologien mit intuitivenBedienkonzepten hat die nächste Ära der Informationstechnologie ein-geläutet. Mobile Produkte verändern unseren Alltag. Bei der Gestaltungvon mobilen Anwendungen und Diensten gilt es eine Reihe neuartigerKonzepte zu berücksichtigen.

8.6 Mobile User Experience 161

Einfacher Zugriff jederzeit und überall

Der Zugriff auf Informationen unterwegs war schon in den 1990er Jah-ren ein Bedürfnis. Eine Ausrüstung mit Laptop und Modem sowie teureDatenzugriffe erlaubten dem geduldigen Benutzer früher die Arbeit un-terwegs. Die wesentliche Neuerung ist nicht, dass wir nun von überallE-Mails beantworten, im Web surfen und unsere Dokumente bearbei-ten können; die eigentliche Revolution ist die Einfachheit, mit der diesheute möglich ist und die dadurch erreichte, hohe Marktdurchdringung.Ein Smartphone in der Jackentasche reicht unterwegs für die eleganteErledigung der meisten Aufgaben aus. So verteilen wir – bewusst oderunbewusst – unsere Arbeit und Kommunikation auf unseren Alltag. Wirgewinnen Flexibilität und können Wartezeiten besser nutzen. Es mussweniger im Voraus geplant werden. Mobile Anwendungen verändernauch unser (Sozial-) Verhalten. Wir können jederzeit über verschiedeneKommunikationskanäle interagieren (zum Beispiel per Telefon, SMS, E-Mail, Web, Facebook, Foren, Apps und so weiter). Die Arbeit dringt inunser Privatleben vor. Damit verbunden sind alle positiven und negativenAuswirkungen, mit denen sich die mobile Produktentwicklung auseinan-dersetzen muss.

Gezielte Funktionalität

Die mobile Anwendung von Diensten und Produkten bringt eine weitereKonsequenz für deren Gestaltung mit sich: Der Nutzen von umfang-reichen integrierten Lösungen nimmt ab. Im Gegenzug verteilen sichFunktionen auf zahlreiche kleinere Einheiten, die situativ genutzt wer-den. So verdrängen heute smarte Apps und Online-Dienste für mobileGeräte zusehends die großen Softwarepakete des letzten Jahrzehnts. Fürdie Gestaltung dieser Apps bedeutet dies eine noch sorgfältigere Betrach-tung der grundlegenden Fragen im Usability Engineering: Wer ist dieanvisierte Zielgruppe und was sind deren Bedürfnisse? In welchem Kon-text und in welchen Situationen wird die Anwendung verwendet? WelcheFunktionalität ist für die Benutzer in diesen Situationen wirklich nutz-bringend? Die gezielte Reduktion der Funktions- und Interaktionsvielfaltklassischer Anwendungen auf die Gegebenheiten mobiler Geräte und

162 8 Ausblick

Abb. 8.1 Bei der Entwicklung einer mobilen Anwendung entscheidet die Art derBedienung in hohem Maß über den Erfolg eines Produkts. Gezielte Funktionalität undGestaltung der Interaktion sind für eine passende Mobile User Experience essenziell

Technologien ist eine wichtige Aufgabe bei der Gestaltung erfolgreichermobiler Applikationen (siehe auch Abschn. 1.3, „Usability Enginee-ring – Reduktion auf das Wesentliche“). Abbildung 8.1 illustriert diesenProzess.

Location Based Services

Noch vor wenigen Jahren haben sich Service-Anbieter darüber den Kopfzerbrochen, den Kunden standortbezogene Dienstleistungen schmack-haft zu machen. Heute ist es eine Selbstverständlichkeit, dass unseremobilen Geräte dank GPS und Internetanbindung jederzeit wissen, wowir sind und was es um uns herum gibt. Der nächste Italiener für einegute Pizza? Was ist das für ein Gebäude vor mir? Was zeigt das Fo-to, welches ich gerade aufgenommen habe? Wann fährt der nächste Zug

8.6 Mobile User Experience 163

nach Hause – und hat er Verspätung? Mit den entsprechenden Apps sindsolche Aufgaben kein Thema mehr. Die Erwartungen der Benutzer sindentsprechend hoch. Bei der Gestaltung neuer Anwendungen ist deshalbdie Frage zu klären, welche standortbezogenen Daten einen echten Mehr-wert bringen, ob und wie diese verwendet werden können.

Sozialer Austausch

Mobile Anwendungen erlauben den ständigen Kontakt mit anderen.Auf Social Media Plattformen wie Facebook können wir das bebilder-te Tagebuch mancher Freunde praktisch in Echtzeit nachverfolgen undunserem Darstellungsdrang selbst freien Lauf lassen. Kommunikations-plattformen wie Twitter bieten uns sofortige Informationen aus unseremNetzwerk und fordern im Gegenzug zu möglichst ständiger Kommu-nikation unserer Neuigkeiten auf. Über Networking-Dienste wie Xingund Linkedin treten wir mit interessanten Geschäftspartnern in Kontaktoder pflegen den fachlichen Austausch. Viele dieser sozialen Funktionensind bereits weit in die Betriebssysteme mobiler Geräte integriert. DieseMöglichkeiten des sozialen Austauschs gilt es bei der Gestaltung neuerProdukte zu berücksichtigen. Was bedeutet es, Informationen jederzeitseinem Netzwerk zugänglich machen zu können? Welche Bedürfnisse,Chancen und Gefahren gilt es dabei zu beachten? Für welche Zielgrup-pen ist dies interessant? Was sind die Konsequenzen einer unmittelbaren,schnellen und unter Umständen unreflektierten Mund zu Mund Propa-ganda?

Für das Interaktionsdesign und die Implementierung mobiler Appli-kationen stellt sich eine Reihe weiterer Fragen:

• Auf welchen Geräten soll die Anwendung laufen? Welche Betriebs-systeme und mobile Plattformen werden unterstützt? Die letztenJahre brachten eine immense Vielfalt mit sich. Die wichtigsten Ver-treter mobiler Plattformen sind Apples iOS Geräte wie iPhone undiPad, Googles Android OS mit zahlreichen Geräten verschiedenerHersteller in allen möglichen Größen und Formen sowie Microsoftsmobile Betriebssysteme und Tablet Hardware. Die Berücksichtigungder plattformspezifischen Design-Prinzipien und Richtlinien erfordert

164 8 Ausblick

vertiefte Kenntnisse der User Interface Designer und Entwickler (sie-he auch Abschn. 3.6).

• Eine besondere Herausforderung ist das Zusammenspiel verschiede-ner Kanäle bei der Planung neuer Dienste, also etwa die Gestaltungder Funktionalität von Anwendungen, welche sowohl über klassischeApplikationen, Online-Dienste und Apps auf mobilen Geräten an-geboten werden soll. Solche Multi-Channel Strategien spielen einezunehmend wichtige Rolle für Unternehmen. Die isolierte Betrach-tung des mobilen User Interfaces reicht nicht aus.

• Mobile Geräte mit den beschriebenen neuen Möglichkeiten erfreu-en sich einer hohen Marktdurchdringung. Neue Apps sind für dieBenutzer leicht zugänglich. Mobile Anwendungen erreichen so ei-ne potenziell breite und heterogene Zielgruppe. Im Gegenzug ist derWechsel zum Angebot der Konkurrenz für die Benutzer sehr einfach.

• Mobile Anwendungen stellen hohe Anforderungen an Security-Aspekte (siehe auch Abschn. 8.4) sowie Datensicherheit und wer-fen nicht zuletzt vielfältige und ernst zu nehmende Fragen bezüglichDatenschutz auf.

Die Anforderungen und Bedürfnisse der Benutzer im Hinblick auf die-se und weitere Aspekte müssen bei der Konzeption mobiler Lösungenberücksichtigt und sorgfältig angegangen werden. Usability-Methoden,welche den Kontext der Anwendung einbeziehen und für die Benutzervorstellbar machen, spielen in der Entwicklung eine wichtige Rolle.

In der Fallstudie „User Centered Innovation – Simulierte Realität“(siehe Abschn. 6.3) haben wir bereits eine verwandte Problemstellungbeschrieben. Bei mobilen Anwendungen ist es gewinnbringend, schonin einer frühen Phase der Produktentwicklung die zukünftige Anwen-dung realitätsnah zu simulieren. In einem solchen Vorgehen kommennicht nur Prototypen der neuen Applikation zur Anwendung. Es werdenauch realistische Anwendungssituationen simuliert und mit den Benut-zern durchgespielt, zum Beispiel die Verwendung im Zug, in einem Café,zuhause, auf dem Weg zur Arbeit und so weiter. Auf diese Weise kann einneues Produkt unter möglichst realistischen Bedingungen und mit über-schaubarem Aufwand in kurzen Usability-Test Zyklen optimiert werden.

8.7 Der allgegenwärtige Computer 165

8.7 Der allgegenwärtige Computer

Das Gebiet Ubiquitous Computing stellt die These auf, dass die Allge-genwärtigkeit der Computertechnologie die nächste Ära der Informati-onsgesellschaft einläutet. Der Begriff geht auf eine Veröffentlichung desInformatikers Mark Weiser zurück [Weiser 91].

Durch die fortschreitende Miniaturisierung und Vernetzung nehmenintelligente Gegenstände mehr und mehr Einzug in unseren Alltag undlösen das Paradigma des klassischen PCs mit seinen Limitationen ab.Schon heute gibt es dafür zahlreiche Beispiele, wie rechnergestützteHaussteuerungen, die Verschmelzung von Computer, Videorekorder, Hi-Fi-Anlage und Fernsehgerät, den medienwirksamen intelligenten Kühl-schrank mit Internetanschluss, RFID-Mikrochips zur Kennzeichnungvon Gegenständen, mobile Geräte und Anwendungen, Smartphones,Tablet PCs und viele mehr. In Zukunft sind noch kleinere Computerein-heiten in großer Anzahl denkbar, die unsere Umgebung durchdringen.

Weiser selbst legte großen Wert darauf, dass neben den techno-logischen Möglichkeiten auch die damit verbundenen soziologischenVeränderungen dieser neuen Ära diskutiert werden. Ein wesentlicherPunkt dabei ist, dass die Computerisierung der Umwelt für den Men-schen weitgehend unsichtbar bleibt und im Gegensatz zum klassischenComputer keine spezielle Aufmerksamkeit erfordert. Information wirdprinzipiell überall dort zur Verfügung stehen, wo sie benötigt wird. De-ren Abruf soll auf natürliche Art und Weise erfolgen, ohne zu einemInformationsüberschuss zu führen. Anwendungen sollen damit schneller,einfacher und intuitiver werden. Information wird auch jenen zur Verfü-gung stehen, die heute keinen Zugang zu entsprechenden Technologienhaben.

Noch ist diese Vision mit einigen offenen Fragen verbunden. Aspektewie Sicherheit, Privatsphäre und Datenschutz bedeuten dabei eine beson-dere Herausforderung.

Auch für das Gebiet Usability Engineering führt dieser Paradigmen-wechsel zu Veränderungen. Individuelle, nicht standardisierte Geräte-Hardware, neue Interaktionsweisen, intelligente, mitdenkende Systemeund in die Umgebung integrierte Geräte fordern die Disziplin.

166 8 Ausblick

Abb. 8.2 Intuitive Bedienung, attraktives Design und der Situation angepasste Funk-tionen haben zu einer neuen Generation mobiler Anwendungen – und Benutzer –geführt. Wo geht die Reise hin?

Eines wird indessen gleich bleiben: Der „Faktor Mensch“ wird beider fortschreitenden Integration der Informationstechnologie in unserenberuflichen und privaten Alltag eine zentrale Rolle spielen. Die Analyseund das Verständnis menschlicher Ziele und Verhaltensweisen werdenfür die Umsetzung in nützliche und benutzbare Anwendungen immersubstanzieller.

8.7 Der allgegenwärtige Computer 167

Persönliches Logbuch des Captains, Nachtrag: Wie stellt man dieses verflixteLogbuch eigentlich wieder ab?

Glossar

Agil Das Stichwort agil bezeichnet in der Software-Entwicklung eineMenge von Prinzipien, Methoden und Vorgehensweisen, um die Ent-wicklung von Software durch Reduktion von Bürokratie und Besinnungauf wenige, entscheidende Grundsätze produktiver zu machen. SolcheGrundsätze sind iterative Entwicklung, Zusammenarbeit, kontinuierlicheVerbesserung und Adaption an Veränderungen.

Analyst Rolle im Software-Entwicklungsprozess. In diesem Buch inerster Linie Personen, die mit der Aufnahme und Modellierung von An-forderungen beschäftigt sind.

Anforderung Eine geforderte Eigenschaft, die vom neuen System er-füllt werden soll.

Anforderungsmanagement (Requirements Engineering) EineSammlung von Methoden, um die Anforderungen für die Entwicklungeines technischen Systems zu erheben, zu modellieren, zu verwalten, zuprüfen und zu kommunizieren.

Benutzer Rolle im Software-Entwicklungsprozess. Diese sollte aus-schließlich von Personen wahrgenommen werden, die potenziell dasneue technische System benutzen werden.

Benutzerschnittstelle (User Interface) Auch Mensch-Maschine-Schnittstelle, Benutzungsschnittstelle oder Benutzeroberfläche genannt.

169M. Richter, M.D. Flückiger, Usability Engineering kompakt, IT kompakt,DOI 10.1007/978-3-642-34832-7, © Springer-Verlag Berlin Heidelberg 2013

170 Glossar

Die Benutzerschnittstelle umfasst die Teile eines Systems, mit denenPersonen direkt interagieren.

Computer Eine Maschine, mit der man fast so schnell schreiben wiedenken kann. (Umberto Eco)

Ergonomie Wissenschaft zur Erforschung der Beziehungen zwischendem Menschen und seiner Arbeit, Arbeitsmittel und Umgebung.

Evaluation Bezeichnung für den Vorgang, ein technisches System mitBenutzern zu beurteilen.

Geschäftsprozessmodellierung (Business Modeling) Eine Sammlungvon Methoden, um ein Modell eines Geschäftssystems zu erstellen, zuverwalten und zu überprüfen.

Human Computer Interaction (HCI) Wissenschaft zur Erforschungder Kommunikation zwischen Mensch und Computer.

Human Factors Psychologisches Fachgebiet zur Erforschung mensch-licher Einflussgrößen bei der Anwendung von Technologien.

Interaction Design Die Gestaltung der Interaktion zwischen Benut-zer und System. Das Interaktionsdesign definiert die Möglichkeiten zurSteuerung eines Systems, sein Verhalten und seine Rückmeldungen. AlsFachgebiet umfasst Interaction Design die Herleitung einer guten Be-nutzerschnittstelle durch die Einbeziehung von Benutzern und beinhaltetdabei Aspekte der grafischen Gestaltung oder des Industriedesigns.

Iteratives Vorgehen Wiederholende und zielgerichtete Durchführungeines Entwicklungszyklus von Analyse bis Evaluation zur schrittweisenAnnäherung von Prototypen oder Teilen eines neuen Systems an die ge-wünschte Lösung.

Glossar 171

Kontext Auch Anwendungs- oder Nutzungskontext. Die Umwelt, in dieein technisches System eingebettet wird, bestehend aus den Benutzernund deren Arbeitsweisen sowie dem kulturellen, sozialen, organisatori-schen, physischen und technischen Umfeld.

Mobile User Experience Die Gestaltung der Erlebniswelt bei der Nut-zung von mobilen Geräten, Anwendungen und Diensten.

Mock-up Eine Attrappe der Benutzerschnittstelle, die zur Evaluati-on mit Benutzern und anderen Interessensvertretern verwendet werdenkann. Beispielsweise mit Papier, Karton, Styropor oder mit elektroni-schen Mitteln wie Grafikprogrammen erstellt. In diesem Zusammenhangspricht man auch von LoFi-Prototypen (von englisch Low Fidelity: ge-ringe Wiedergabetreue).

Modellieren Die vereinfachte Darstellung und Verdeutlichung ei-nes gewissen Ausschnitts der Realität zu einem bestimmten Zweck.Modellieren ist eine notwendige Tätigkeit auf dem Weg von den Benut-zerbedürfnissen zur Spezifikation eines Systems.

Prozess Der Ablauf von Tätigkeiten, um ein bestimmtes Ziel zuerreichen. Häufig anzutreffende Bedeutungen sind: Informationsflüsseund Zusammenarbeit im Unternehmen (Geschäftsprozesse), Arbeitsab-läufe eines Benutzers mit einem bestimmten System (Mensch-System-Interaktion), Vorgehensmodelle für die Erstellung von Anwendungenund Produkten (Entwicklungsprozesse).

Software-Ergonomie Fachgebiet zur Erforschung und Anpassung vonComputerprogrammen an die menschlichen Anforderungen und Bedürf-nisse.

Spezifikation Beschreibung einer neuen Lösung als Vorgabe für dieEntwicklung. Teil des Vertrags zwischen Auftraggeber und Hersteller.

Usability Ein Maß für die Benutzbarkeit eines technischen Systems.Verwandte Begriffe sind Gebrauchstauglichkeit und Benutzerfreundlich-keit.

172 Glossar

Usability Engineering Die systematische Anwendung von Methodenund Techniken, um gezielt benutzbare Systeme und Produkte zu entwer-fen und herzustellen.

Usability Lab Eine speziell für Usability Testing eingerichtete Räum-lichkeit.

Usability-Prinzipien Allgemeine Richtlinien für die benutzerorientier-te Gestaltung von Benutzerschnittstellen. Usability-Prinzipien könnensowohl für den Entwurf als auch zur Evaluation von User Interfaces ein-gesetzt werden.

Use-Case-Modell Ein Modell des Verhaltens eines Systems. Die amhäufigsten verwendeten Modellelemente sind Anwendungsfall (Use Ca-se), Akteur (Actor) und Beziehung (Relationship).

User Centered Design (UCD) Vorgehensmodelle, welche die späterenBenutzer systematisch in die Entwicklung von Systemen und Produkteneinbeziehen.

User Experience (UX) Disziplin, die sich mit der Gestaltung dergesamten mit einem Produkt oder einer Dienstleistung verbundenenKommunikation zum Benutzer auseinandersetzt.

User Interface Design Fachbereich, der sich mit der Gestaltung vonBenutzerschnittstellen anhand definierter Anforderungen beschäftigt.

Literatur

[Apple 00–12] Apple OS X Human Interface Guidelines. (2000–2012). http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/

[Apple 08–12] Apple iOS Human Interface Guidelines. (2008–2012). http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/

[Beck et al. 01] Beck et al. (2001). Manifesto for Agile Software Development. http://agilemanifesto.org/

[Beyer et al. 98] Beyer, H., & Holtzblatt, K. (1998). Contextual Design: DefiningCustomer-Centered Systems. San Francisco: Morgan Kaufmann

[Bortz et al. 06] Bortz, J., & Döring, N. (2006). Forschungsmethoden und Evaluation:für Human- und Sozialwissenschaftler. Berlin: Springer

[Buxton et al. 12] Buxton, B., Greenberg, S., Carpendale, S., & Marquardt, N. (2012).Sketching User Experiences: The Workbook. San Francisco: Morgan Kaufmann

[Cockburn 03] Cockburn, A. (2003). Use Cases effektiv erstellen. Bonn: Mitp-Verlag[Constantine et al. 99] Constantine, L., & Lockwood, L. (1999). Software for Use: A

Practical Guide to the Models and Methods of Usage-Centered Design. Addison-Wesley Professional

[Cooper et al. 10] Cooper, A., Reimann, R., & Cronin, D. (2010). About Face: Inter-face und Interaction Design. Bonn: Mitp-Verlag

[Courage et al. 05] Courage, C., & Baxter, K. (2005). Understanding Your Users: APractical Guide to User Requirements Methods, Tools and Techniques. San Fran-cisco: Morgan Kaufmann

[Cranor et al. 05] Cranor, L. F., & Garfinkel, S. (2005). Security and Usability: Desi-gning Secure Systems That People Can Use. O’Reilly Media

[DIN EN ISO 9241-11, 1997–2012] DIN EN ISO 9241. Ergonomische Anforderun-gen für Bürotätigkeiten mit Bildschirmgeräten, seit 2006: Ergonomie der Mensch-System-Interaktion. (1997–2012). Berlin: Beuth

[DIN EN ISO 9241-210] DIN EN ISO 9241-210. Ergonomie der Mensch-System-Interaktion – Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiverSysteme. (2012). Berlin: Beuth

173

http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/



http://developer.apple.com/library/ios/#documentation/UserExperience/Conceptual/MobileHIG/



http://agilemanifesto.org/

http://agilemanifesto.org/

174 Literatur

[Dirbach et al. 11] Dirbach, J., Flückiger, M., & Lentz, S. (2011). Software entwickelnmit Verstand. dpunkt Verlag

[Ebert 10] Ebert, C. (2010). Systematisches Requirements Engineering: Anforderun-gen ermitteln, spezifizieren, analysieren und verwalten. Bonn: dpunkt-Verlag

[EG 90] EG 90/270/EWG. Verordnung über Sicherheit und Gesundheitsschutz bei derArbeit an Bildschirmgeräten. (1990). EG

[Google 12] Google User Experience Principles. (2012). http://www.google.com/corporate/ux.html

[IEC 60601-1-6] IEC 60601-1-6. Medical electrical equipment – Part 1–6: Generalrequirements for basic safety and essential performance – Collateral standard:Usability. (2010). IEC

[IEC 62366] IEC 62366. Application of usability engineering to medical devices.(2007). IEC

[ISO/IEC 40500 12] ISO/IEC 40500. Information technology – W3C Web ContentAccessibility Guidelines (WCAG) 2.0. (2012.) Berlin: Beuth

[Johnson 07] Johnson, J. (2007). GUI Bloopers 2.0: Common User Interface DesignDon’ts and Dos. San Francisco: Morgan Kaufmann

[Mayhew 99] Mayhew, D. (1999). The Usability Engineering Lifecycle: A Prac-titioner’s Handbook for User Interface Design. San Diego: Morgan KaufmannAcademic Press

[Microsoft 05–10] Microsoft Windows User Experience Interaction Guidelines(2005–2010). http://msdn.microsoft.com/

[Miller 56] Miller, G. A. (1956). The Magical Number Seven, Plus or Minus Two:Some Limits on our Capacity for Processing Information. Psychological Review,63, 81–97

[Moser 12] Moser, C. (2012). User Experience Design: Mit erlebniszentrierter Soft-wareentwicklung zu Produkten, die begeistern. Springer Vieweg

[Nielsen 93] Nielsen, J. (1993). Usability Engineering. San Francisco: Morgan Kauf-mann

[Norman 88] Norman, D. (1988). The Psychology of Everyday Things (neuer Titel:The Design of Everyday Things) New York: Basic Books

[Prümper et al. 97] Prümper, J., & Anft, M. (1997). ISONORM 9241/10. Beurteilungs-bogen auf Grundlage der Internationalen Ergonomie-Norm ISO 9241-10. Berlin:Büro für Arbeits- und Organisationspsychologie

[Richter 99] Richter, M. (1999). Online Befragung als neues Instrument zur Beur-teilung der Benutzerfreundlichkeit von Software. In U.-D. Reips, B. Batinic, W.Bandilla, M. Bosnjak, L. Gräf, K. Moser, & A. Werner (Hrsg.), Aktuelle Onli-ne Forschung – Trends, Techniken, Ergebnisse. http://www.gor.de/gor99/tband99/Zürich: Online Press

[Rosson et al. 02] Rosson, M. B., & Carroll, J. M. (2002). Usability Engineering:Scenario-Based Development of Human Computer Interaction. San Francisco:Morgan Kaufmann

[Scott et al. 09] Scott, B., & Neil, T. (2009). Designing Web Interfaces. Principles andPatterns for Rich Interactions. O’Reilly Media

http://www.google.com/corporate/ux.html

http://www.google.com/corporate/ux.html

http://msdn.microsoft.com/

http://www.gor.de/gor99/tband99/

Literatur 175

[Snyder 03] Snyder, C. (2003). Paper Prototyping: The fast and easy way to defineand refine User Interfaces. San Francisco: Morgan Kaufmann

[Standish Group 1994–2010] The Standish Group (1994–2010). „Chaos Report“http://www.standishgroup.com/

[Tidwell 11] Tidwell, J. (2011). Designing Interfaces: Patterns for Effective Interac-tion Design. O’Reilly Media

[UEQ 12] User Experience Questionnaire (UEQ). (2012). http://www.ueq-_online.org/

[W3C 08] W3C Web Content Accessibility Guidelines 2.0. (2008). http://www.w3.org/WAI/

[Weiser 91] Weiser, M. (1991). The Computer for the 21st Century. Scientific Ameri-can, 265(3)

[Wirdemann 10] Wirdemann, R. (2010). Scrum mit User Stories. Hanser[Willumeit et al. 96] Willumeit, H., Gediga, G., & Hamborg, K.-C. (1996). IsoMe-

trics: Ein Verfahren zur formativen Evaluation von Software nach ISO 9241/10.Ergonomie & Informatik, 27, 5–12

[Wirth 04] Wirth, T. (2004). Missing Links: Über gutes Webdesign. München: Hanser

Weiterführende Literatur

Goodwin, K. (2009). Designing for the Digital Age. New York: WileyHoltzblatt, K., Wendell, J., & Wood, S. (2004). Rapid Contextual Design: A How-

to Guide to Key Techniques for User-Centered Design. San Francsico: MorganKaufmann

Sharp, H., Rogers, Y., & Preece, J. (2011). Interaction Design: Beyond Human-Com-puter Interaction. Wiley

http://www.standishgroup.com/

http://www.ueq-online.org/

http://www.ueq-online.org/

http://www.w3.org/WAI/

http://www.w3.org/WAI/

Sachverzeichnis

AAccessibility, 155agil, 14, 15, 25, 44, 68, 101, 169Akteure, 23, 38, 64, 65, 68–70, 172Analyse, 20, 27, 34, 91Anforderung, 14, 15, 25, 43, 54, 66,

134, 169Anforderungsanalyse, 13, 64, 91Anwendungsfälle, 23, 63, 68, 70, 134Anwendungsgebiete, 8Apprenticing, 34

BBarrierefreies Internet, 156Benutzbarkeit, 3, 171Benutzer, 21, 30, 40, 107, 151, 169Benutzerbefragungen, 88Benutzerfreundlichkeit, 3, 171Benutzergruppen, 41Benutzerperspektive, 45Benutzerschnittstelle, 55, 56, 58, 158,

169Benutzervertreter, 110, 125Beobachtung, 31, 83

CContextual Design, 16, 36Contextual Inquiry, 21, 30, 65Customer Experience, 157

DDefinition, 5Discount Usability Engineering, 112Domänenmodell, 23, 35

EEntwicklungsprozess, 13, 119, 120Ergonomie, 9, 170Essential Use Cases, 67Evaluation, 26, 27, 44, 79, 84, 92, 170

FFeldtests, 86Fragebögen, 87, 91Fragebogenkonstruktion, 90Funktionale Anforderungen, 66Funktionalität, 7, 23, 53, 54, 64, 66, 68,

102, 112, 133, 135, 161

GGebrauchstauglichkeit, 3, 5, 171Geschäftsprozessmodellierung, 20, 37,

170Geschäftsstrategie, 125Gesetzliche Verordnungen, 72Glossar, 23Gütekriterien, 83, 84GUI-Elemente, 74, 78, 123

HHuman Computer Interaction, 10, 170

177

178 Sachverzeichnis

Human Factors, 9, 170

IInformationsarchitektur, 160Innovation, 37, 140Institutionalisierung, 124Interaction Design, 157, 170Interview, 31, 34, 83, 108ISO-Norm, 5, 17, 73, 92Iteratives Vorgehen, 26, 60, 120, 170

KKontext, 20, 32, 69, 91, 150, 171

LLoFi Prototyping, 52

MMensch-Computer-Interaktion, 10Messen der Usability, 94Mobile UX, 11, 160Mock-up, 54, 60, 171Modellieren, 22, 27, 152, 171Multi Channel, 164

NNicht-funktionale Anforderungen, 66Normen, 73

OObjektivität, 84Online-Befragung, 92

PPaper Prototyping, 58Personas, 23, 34, 39, 68, 133, 142, 146Perspektivenübernahme, 3, 45Planung, 97Planungsbeispiele, 100Prototyping Tools, 61, 122Prozess, 119, 171

Qqualitative Studien, 88, 91

quantitative Studien, 88

RRealisierung, 25, 27Reliabilität, 85Requirements Engineering, 14, 18, 22,

120, 131, 169Risikobetrachtung, 99Rollen, 115RUP, 14, 63

SScrum, 14Security, 158Social Media, 10, 163Software-Ergonomie, 10, 77, 171Spezifikation, 25, 27, 44, 58, 64, 66,

113, 123, 171Standardaufgaben, 80Standardfragebögen, 92Standardisierung, 121Storyboard, 23, 48, 50, 66, 134Styleguide, 25, 72–74, 77, 121Symptome, 8Szenarien, 23, 42, 43, 68, 133, 142

TTestbericht, 83Testpersonen, 80, 86

UUbiquitous Computing, 165Untersuchungsdesign, 89Urteilsfehler, 94Usability, 3–5, 150, 171Usability Engineering, 7, 118, 149, 172Usability Guidelines, 25, 71, 74Usability Lab, 79, 81, 172Usability Lab, mobiles, 85Usability Walkthrough, 26, 85, 134, 138Usability-Fragebögen, 26Usability-Methoden, 19, 29Usability-Prinzipien, 73, 172Usability-Test, 26, 79, 83, 142

Sachverzeichnis 179

Use-Case-Modell, 23, 64, 172Use-Case-Spezifikation, 25, 66User Centered Design, 16, 172User Experience, 4, 156, 172User Interface Design, 157, 172User Interface Patterns, 73User Interface Prototyping, 24, 52, 60,

122, 142, 148User Stories, 23, 26, 67, 100User-Interface-Konzept, 24, 44, 55

User-Interface-Prototyp, 52, 66

VValidität, 85

WWeb Usability, 159Wireframe, 53, 54

ZZiele, 97, 149

Documents

[IT kompakt] Usability Engineering kompakt ||