Referent - German UPA

Transcription

Matthias Peissner
Kerstin Röse (Hrsg.)
Usability
Professionals
2003
Berichtband des ersten Workshops des German Chapters der Usability Professionals Association e.V.
Impressum
Herausgeber:
Matthias Peissner, Fraunhofer IAO
Kerstin Röse, Universität Kaiserslautern
Vertrieb:
German Chapter der Usability Professionals Association e.V.
Postfach 80 06 46
70506 Stuttgart
Bestellungen an: mc2003@gc-upa.de
Copyright:
German Chapter der Usability Professionals Association e.V.
ISBN:
3-8167-6376-6
Erscheinungstermin:
September 2003
Cover Design:
Nick Kapica
ständige vertretung design und kommunikation gmbh
http://www.staendige-vertretung.com
Druck:
Fraunhofer Informationszentrum Raum und Bau IRB
© German Chapter der Usability Professionals Association e.V.
Alle Rechte vorbehalten. Dieses Werk ist einschließlich seiner Teile urheberrechtlich
geschützt. Jede Verwertung, die über die engen Grenzen des Urheberrechts hinausgeht, ist
ohne schriftliche Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere
für Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Speicherung in
elektronischen Systemen. Die Wiedergabe von Warenbezeichnungen und Handelsnamen in
diesem Buch berechtigt nicht zu der Annahme, dass solche Bezeichnungen im Sinne der
Warenzeichen- und Markenschutzgesetzgebung als frei zu betrachten wären und deshalb
von jedermann benutzt werden dürften.
WILLKOMMEN ZUM ERSTEN WORKSHOP DES GERMAN CHAPTERS
DER USABILITY PROFESSIONALS ASSOCIATION E.V.
Liebe Kollegen!
Nun ist es schon fast ein Jahr her, dass in Darmstadt die Gründung des deutschen Berufsverbands der
Usability Professionals statt gefunden hat. Neben all den bürokratischen Herausforderungen, die die
Gründung eines Berufsverbandes mit sich bringt, haben wir unseren wichtigsten Auftrag, die Organisation
des ersten Workshops, in Angriff genommen. Und jetzt ist es endlich so weit:
Erstmals findet auf der diesjährigen Konferenz „Mensch & Computer 2003“ der Usability Professionals Track
statt. Diese Workshopreihe konzentriert sich auf die praktischen Fragestellungen des Usability Engineerings
und bietet Usability Praktikern die Möglichkeit, Erfahrungen auszutauschen, sich über neue Methoden,
Techniken und Trends zu informieren, sowie neue Kontakte zu Partnern aus dem gesamten
deutschsprachigen Raum zu finden.
Als Organisatoren des Usability Professionals Tracks freuen wir uns, dass wir schon bei der ersten
Durchführung ein so vielseitiges und interessantes Programm präsentieren können. Vielen Dank an alle
Autoren, Referenten und Session Chairs!
In insgesamt 13 Usability Professionals Sessions werden die wichtigsten Themen und die aktuellsten Trends
des Usability Engineerings behandelt. Der hohe Anteil an Referenten aus der Industrie und von namhaften
Partnern der angewandten Forschung verdeutlicht die starke Praxisorientierung und Praxisrelevanz der
Sessions.
Ein besonderes Anliegen bei der Vorbereitung des UPA-Tracks war es, die klassischen Beitragsformate einer
wissenschaftlichen Konferenz zu erweitern und eine möglichst offene und interaktive Gestaltung der
Sessions zu erreichen. Dieser Berichtband fasst die Beiträge von 3 Tagen Workshop in Kurzform zusammen
und gibt einen Überblick zu den einzelnen Referenten. Im Sinne des Networking sind kurze Beschreibungen
und Kontaktinformationen zu den jeweiligen Referenten enthalten.
Der Usability Professionals Track wird vom German Chapter der Usability Professionals Association e.V.
(www.gc-upa.de) organisiert und ist dessen erster Workshop, der von nun an jährlich stattfinden wird.
Unser ganz besonderer Dank gilt den Veranstaltern und Organisatoren der Mensch & Computer 2003, die es
uns ermöglicht haben, uns mit einer kompletten Workshopreihe an der Gestaltung der Konferenz zu
beteiligen. Allen voran Herr Professor Dr. Jürgen Ziegler, der von Anfang an unsere Einbindung in die
Mensch & Computer 2003 unterstützt hat. Wir hoffen, dass das German Chapter der UPA e.V. mit dem
Usability Professionals Track durch interessante Präsentationen und Workshops, durch die stärkere
Einbeziehung von Praktikern aus der Industrie und nicht zuletzt durch persönliche Begegnungen zwischen
Forschern und Praktikern zu einer echten Bereicherung der Konferenz beitragen kann.
Stuttgart, September 2003
Matthias Peissner
Kerstin Röse
Im Auftrag des German Chapter der Usability Professionals Association e.V.
Kontakt:
German Chapter der UPA e.v.
Postfach 80 06 46
70506 Stuttgart
matthias.peissner@gc-upa.de
kerstin.roese@gc-upa.de
http://www.gc-upa.de
Wir danken den Sponsoren der Mensch & Computer 2003
INHALT
Assistenzsysteme: Woher und wohin?
3
Assistenzsysteme: Woher und wohin?
H. Wandke, E. Wetzenstein-Ollenschläger
8
Ermittlung von Assistenzwünschen von Fahrern mit Hilfe der Methode Nutzer-Mock-Up
H. Enigk, K. Polkehn
13
Mehr als Look and Feel: virtuelle Helfer
N. Krämer
Der Weg zu einer stärkeren Verzahnung von Usability Engineering und Software Engineering
21
K. Kohler, F. Leidermann, A. Birk
Usability Professionals und Requirements Engineering
29
Usability Professionals und Requirements Engineering - Erfahrungen und Trends
A. Beck
34
Anforderungsmanagement als eigenständige Disziplin
R. Fahney
39
Customer-centered "New Application" Design
M. Hatscher, J. Beringer
44
Praktische Integration des Requirements-Engineering im Feld der multimedialen interaktiven
Lehrmedien
R. Hartwig
49
Requirements-Analyse und GUI Design
F. Strauß
Sprache und Multimodalität
57
Praxisbericht zur Gestaltung auditiver Benutzungsoberflächen
P. Klante
63
User Modelling in a Dialog System
R. Kompe, M. Emele, S. Goronzy, R. Mencl, S. Torge
69
Voice Portale - Usability Aspekte aus der Praxis
P. Wetzel
V
Inhalt
Usability Professionals in Deutschland
75
Das German Chapter of the Usability Professionals' Association e.V.
K. Röse, A. Beu, M. Hassenzahl, M. Peissner
79
Das Netzwerk der regionalen Gruppen des German Chapters der UPA e.V.
S. Stoessel
84
Usability Report Deutschland 2003 - Eine Befragung zur Situation der Usability Professionals in
Deutschland
A. Beu, E. Reitmayr, P. Vogt, D. Mauch, K. Röse
Erlernen und Anwenden: Projekterfahrungen mit Methoden benutzerzentrierten Gestaltens
93
Focus Group Erhebung des Informationsbedarfs für das Intranet der Polizei im Projekt
"Polizei-Online"
F. Länge, S. Lotterbach
98
Bedienerverhalten und Feedbackqualität bei der Steuerung einer computersimulierten
Heizungsanlage
C. Schmeink, J. Sauer, D. Wastell
103
Optimierung der redaktionellen Workflows in einer Online-Redaktion
P. Schumacher, B. Terwey, R. Wessler
107
Projekt Hilwa - Benutzerorientierte Gestaltung eines Lerncontentmanagementsystems
für die Berufliche Aus- und Weiterbildung
S. Raimer
Phaszination Ergonomie: Von der Entlastung am Fließband zur Inspiration im Design
115
Phaszination Ergonomie: Von der Entlastung am Fließband zur Inspiration im Design
C. Lazzeroni, P. Gersch, T. Hofmann, C. Noss
Methoden und Prozesse
123
Design Faktoren als ein Instrument zur Verbesserung der Qualität von Design-Prozessen
H. Degen
127
Methoden zur Einbindung des Kunden in Planung, Durchführung und Auswertung
eines Usability-Anwendungstests
S. Krause, J. Heuer
If it doesn't feel right - who cares if it works
135
"If it doesn't feel right, who cares if it works?" oder "Muss Software mehr als nur
gebrauchstauglich sein?"
M. Hassenzahl, E. Hofvenschiöld
User Interface Tuning
143
User Interface Tuning - mit Benutzern gestalten
J. Machate, M. Burmester
147
Sicherheit fängt beim Benutzer an - benutzerzentrierter Gestaltungsprozess für
SAM Jupiter
J. Schwagereit, A. Kern, A. Beu
VI
Usability Professionals 2003
Inhalt
151
Gestaltung touchscreen-basierter Maschinensteuerungen bei TRUMPF
K. Bauer, A. Beu
156
Website-Evolution - Was der Besucher wirklich braucht
J. U. Parkitny, C. Görner
161
Interaktives Fernsehen erleben
A. Weiss, F. Koller
Interkulturelles Usability-Engineering
167
Kulturdimensionen für die Gestaltung und Analyse internationaler User Interfaces:
Welche sind wichtig und nützlich?
V.-J. Baumgartner
171
Determining Cultural Issues in Attitude to and use of Mobile Phones
E. Hofvenschiöld
175
Interkulturelle Unterschiede in der Interaktion mit Fahrer-Informations-Systemen
M. Peißner
Barrierefreies Internet
181
Barrierefreies Internet: WebUsability for All
M. Mund, F. Leidermann, H. Weber
Mobile User Interfaces
189
Usability Engineering Prozess bei Vodafone Global
H. Degen
194
Kleiner, bunter, lustiger - aktuelle Herausforderungen für die User Interface-Gestaltung
mobiler Telefone
U. Leiner, P. Honold
199
UI Design Patterns für Navigationssysteme auf mobilen Geräten
F. Hermann, R. Gibbert
VII
ASSISTENZSYSTEME: WOHER UND WOHIN?
ASSISTENZSYSTEME: WOHER UND WOHIN?
Hartmut Wandke
Institut für Psychologie der
Humboldt-Universität zu Berlin
Oranienburger Str. 18
D- 10178 Berlin
hartmut.wandke@psychologie.hu-berlin.de
http://www.psychologie.hu-berlin.de
ABSTRACT
Die zunehmende Häufigkeit, mit der von
Assistenzsystemen bei der Entwicklung von
interaktiven Systemen und auch in der Forschung
zur Usability die Rede ist, steht im deutlichen
Kontrast zur geringen semantischen Trennschärfe
des Begriffs Assistenz. Es wird deshalb ein
Assistenzkonzept vorgestellt, das sich an den zu
unterstützenden Handlungsphasen bei der Nutzung
interaktiver Systeme orientiert. Aus einer Analyse
bekannter Assistenzsysteme und unter Bezug auf
Formen sozialer Assistenz lassen sich 25
verschiedene
Grundformen
von
Assistenz
identifizieren.
Weitere
Merkmale
von
Assistenzsystemen
(Anpassbarkeit;
Initiative)
werden erläutert.
Elke Wetzenstein-Ollenschläger
Institut für Psychologie der
D- 10178 Berlin
wetzenstein@psychologie.hu-berlin.de
http://www.psychologie.hu-berlin.de
2. ANWENDUNGSFELDER FÜR
ASSISTENZ
Assistenzsysteme für private Benutzer finden sich
unter anderem
•
In PC-Softwarepaketen (Assistenten führen z. B.
Benutzer
Schritt
für
Schritt
durch
Installationsprozesse, Wizards helfen bei der
Bewältigung von Aufgaben wie dem Entpacken
von Dateien und dem Brennen von CDs,
Programmfunktionen
führen
automatisch
Formatierungsfunktionen oder Korrekturen aus).
Bekannt, aber oft umstritten sind comicartige
Wesen, die Tipps und Hinweise für den
Benutzer bereit halten, wie er seine Aufgabe
besser machen kann [5].
•
Als Führer und Helfer in den unüberschaubaren
Weiten des Internets, aber auch für
umfangreiche Websites mit den entsprechend
großen Datenbanken.
1. EINLEITUNG
•
Der Begriff „Assistenz“ spielt im der UsabilityForschung der letzten Jahre eine zunehmende
Rolle.
Dabei
versteht
man
je
nach
Anwendungsgebiet sehr verschiedene Merkmale
und Funktionen interaktiver Systeme, die Assistenz
ausmachen. Obwohl einige Assistenzsysteme im
professionellen Bereich schon lange existieren (z. B.
der Autopilot im Flugzeug), ist dieses Thema erst
mit ihrem Einsatz für private Benutzer in größerem
Rahmen bekannt und zum Gegenstand der
Usability-Forschung geworden.
In Pkws finden sich mittlerweile zahlreiche
Assistenten, die der Spurhaltung und der
Fahrzeugstabilisierung
dienen
(ABS,
Bremsassistent, ESP, Distronic), aber auch der
Routenplanung
(Navigationsund
Zielführungssysteme) und der Bewältigung von
Fahrmanövern wie Einparken (Parktronic),
Darüber
hinaus
sollen
Assistenten die
Benutzung
zahlreicher
Komfort-,
Kommunikations- und Entertainmentfunktionen
im Fahrzeug erleichtern [1].
•
In Form sogenannter Persönlicher Digitaler
Assistenten (PDAs). PDAs bieten vor allem
Unterstützung beim Termin- und Kontaktmanagement. Gegenwärtig entwickelt man
PDAs,
die
über
Lokalisierungsund
Telekommunikationsfunktionen verfügen und
die so situation awareness unterstützen sollen
[4].
•
Als Teil sogenannter Smart Home-Konzepte, bei
denen Bewohner eines Hauses bei der
Bewältigung alltäglicher Aufgaben (von der
Regelung der Raumtemperatur bis zum
Bestellen von Lebensmitteln) unterstützt werden.
Aber nicht nur zu Hause, sondern auch auf
Keywords
Assistenz,
Automatisierung,
Funktionsteilung
Mensch-Maschine-Systeme, User Interface.
Es ist erlaubt digitale und Kopien in Papierform des ganzen Papers
oder Teilen davon für den persönlichen Gebrauch oder zur
Verwendung in Lehrveranstaltungen zu erstellen. Der Verkauf oder
gewerbliche Vertrieb ist untersagt. Rückfragen sind zu stellen an
den Vorstand des GC-UPA e.V. (Postfach 80 06 46, 70506
Stuttgart).
Proceedings of the
1st annual GC-UPA Track
© 2003 German Chapter of the UPA e. V.
3
Wandke, H. & Wetzenstein-Ollenschläger, E.
Reisen sollen smarte Interaktionen mit der
Umgebung möglich sein [8].
•
Als Unterstützung für Benutzergruppen mit
besonderen Anforderungen. Hierfür hat sich der
Begriff assistive technology eingebürgert.
Spezielle Assistenzsysteme helfen z. B. Blinden
bei der selbständigen Orientierung in fremder
Umgebungen [2]. Andere ermöglichen es
gelähmten Menschen, die in der Bewegung ihrer
Hände und Finger stark eingeschränkt sind, mit
vertretbarem Aufwand Texte zu schreiben oder
am Computer zu arbeiten.
Zukünftig werden wir das Zusammenwachsen dieser
verschiedenen Anwendungsbereiche erleben; wofür
der Butler in Apple’s Video Szenario Knowledge
Navigator ([7] ein bisher nicht erreichtes Vorbild
darstellt. Für dieses Zusammenwachsen ist es
wichtig zu wissen, worin die Gemeinsamkeiten und
Unterschiede
aller
dieser
Assistenzsysteme
bestehen? Wie kann soll man sie gestalten?
3. WAS IST ASSISTENZ?
Diese Frage kann unterschiedlich beantwortet
werden. Assistenz in einem weiteren Sinne wird
durch jedes technische Artefakt geboten. Bereits ein
einfaches Handwerkzeug stellt dem Benutzer
Funktionen zur Verfügung, über die er selbst nicht
verfügt und die es ihm ermöglichen nicht nur
Aufgaben schneller, mit weniger Kraft und mit
geringer kognitiver Beanspruchung ausführen,
sondern auch überhaupt Dinge zu tun, die er allein
mit seinen natürlichen Fähigkeiten nicht tun könnte.
Eine enge Auslegung des Begriffs Assistenz, wie sie
in der traditionellen Mensch-Maschine-SystemForschung anzutreffen ist, sieht Assistenz als eine
Zwischenform zwischen der rein manuellen/
mentalen Ausführung von Steuerungsaufgaben und
der vollständig automatischen Ausführung. Damit
werden jedoch alle neueren Anwendungsfelder nicht
erfasst. Betrachtet man das gesamte Spektrum der
Anwendungsfelder,
so
erscheinen
zwei
Einschränkungen des weiten Assistenzbegriffs
sinnvoll:
1. Assistenz bezieht sich immer auf den Umgang
mit interaktiven Systemen. Unterstützt wird nicht
die Bewältigung aller möglichen Aufgaben,
sondern nur solche, die die Nutzung von
Technik (speziell von interaktiven Systemen)
betreffen.
2. Assistenz bezieht sich auf den Zugang zu den
Funktionen eines technischen Systems, nicht
auf die Funktionsteilung. Die Funktionsteilung
zwischen
Mensch
und
Technik
ist
Voraussetzung für Assistenz, aber sie ist noch
nicht die Assistenz selbst.
Assistenz ist somit eine Brücke, die eine Verbindung
herstellt zwischen den Wünschen, Zielen, dem
Wissen und den Fähigkeiten der Benutzer auf der
einen Seite und den Funktionen eines interaktiven
4
Systems auf der anderen Seite. Damit ist Assistenz
natürlich auch Teil des User Interface.
3.1 Assistenz für Handlungsphasen
Um
entscheiden
zu
können,
wie
ein
Assistenzsystem gestaltet sein sollte, damit
Benutzer die Funktionen eines interaktiven Systems
möglichst einfach in Anspruch nehmen können, ist
es hilfreich zu wissen, welche Arten von Assistenz
denn prinzipiell existieren und wodurch sie sich
unterscheiden. Dabei erweist es sich als hilfreich,
sich daran zu orientieren, WAS unterstützt werden
soll.
Ansätze
zur
Klassifikationen
von
Assistenzsystemen, die auf diesem WAS beruhen,
stammen von [3], die sich auf zu unterstützende
psychische Funktionen beziehen, und von [6], die
vier Handlungsphasen differenzieren, die unterstützt
werden können.
De Gedanken der Handlungsphasen weiterführend
unterscheiden wir sechs verschiedene Abschnitte
einer Handlung, die einzeln oder in Kombination von
einem Assistenzsystem unterstützt werden können.
Jede dieser
Handlungsphasen kann durch
verschiedene Assistenzsysteme unterstützt werden.
Wenn man die bisher in der Literatur beschriebenen
Assistenzsysteme analysiert und den verschiedenen
Handlungsphasen zuordnet, kommt man zu einer
geordneten Menge von Assistenzarten. Diese
Ordnung kann weiter ausgebaut werden, in dem
man betrachtet, wie zwischenmenschliche Assistenz
funktioniert. Auf diese Art und Weise lassen sich 25
verschiedene Assistenzfunktionen identifizieren, die
in den verschiedenen Anwendungsgebieten und mit
Hilfe verschiedener Techniken realisiert werden
können:
1. Motivation, Aktivierung und Zielbildung
(Aktivierungs-, Coach-, Orientierungs-, Warnund Mahnassistent)
2. Informationsaufnahme:
Wahrnehmung
von
Signalen des interaktiven Systems und von
Umgebungsinformation
(Anzeige-, Verstärker- und Wiederholungsassistent)
3. Informationsintegration,
Erzeugung
Situationsbewusstseins
(Präsentations-,
ÜbersetzungsErklärungsassistent, Label Assistent)
eines
und
4. Entschluss zum Handeln, Treffen einer
Entscheidung, Auswahl einer Handlungsoption
(Angebots-, Filter-, Vorschlags-, Delegationsund Übernahmeassistent, informierender und
stiller Ausführungsassistent)
5. Ausführung der Handlung oder Operation
(Power-, Limit-, und Dosierassistent, Short Cut
Assistent, Eingabeassistent)
6. Verarbeitung der Rückmeldung des Systems
oder des eingetretenen Zustands
(Rückmeldungs-, Kritikassistent)
Assistenzsysteme: Woher und Wohin?
3.2 Anpassung von Assistenz
Wie andere Komponenten des User Interface sollte
Assistenz
angepasst
werden
können
an
verschiedene Benutzer, an deren Aufgaben und an
unterschiedliche Situationsbedingungen.
Wir
unterscheiden
Grundformen:
zwischen
folgenden
Konstante Assistenz
Konstante Assistenzsysteme verhalten sich bei allen
Benutzern und in allen Situationen gleich. Sie
weisen damit den Vorteil der Konsistenz und
Transparenz auf. Benutzer erleben mit solchen
Assistenzfunktionen
keine
Überraschungen.
Allerdings sind solche Systeme aber auch inflexibel
und die bereit gestellte Unterstützung passt nicht
immer zum Benutzer und seiner aktuellen Situation.
Anwenderspezifische Assistenz
Solche Systeme sind “maßgeschneidert” für die
Bedürfnisse bestimmter Anwender und für deren
spezifische Aufgaben in spezifischen Kontexten. Die
Anpassung erfolgt bereits während der Entwicklung.
Diese Art von Anpassung erfordert eine sorgfältige
Anforderungsanalyse. Zwar ist die Berücksichtigung
von Anwenderbedürfnissen schon ein Verbesserung
gegenüber dem „one size fitts all“-Ansatz, schafft
aber
Probleme,
wenn
sich
z.
B.
der
Benutzungskontext
ändert
oder
Benutzer
hinzulernen. Hier ist es angezeigt, die Anpassung in
die Hände des Benutzers (Adaptierbarkeit) oder des
Systems (Adaptivität) zu legen.
Adaptierbare Assistenz
Benutzer können diese Systeme an ihre speziellen
Bedürfnisse, Aufgaben und Benutzungssituationen
selbst anpassen. Die Anpassung kann zum einen
durch Auswahl geschehen, z. B. wählt Benutzer A
eine vollautomatische Schaltung und Benutzer B
eine Tipptronic-Schaltung. Die Auswahl kann sich
prinzipiell auf alle Merkmale von Assistenzsystemen
beziehen. Benutzer X möchte z. B. immer eine
aktive Assistenz, während Y eine passive Assistenz
bevorzugt. Neben der Anpassung durch Auswahl,
können Benutzer Assistenzsysteme auch durch
Parameteränderungen
anpassen.
Benutzer
beeinflussen z. B. das Verhalten von aktiven
Assistenzsystemen durch das Einstellen von
Schwellenwerten. Nur wenn das Telefon mindestens
fünfmal klingelt, wird die Lautstärke des Fernsehers
vermindert, die Teilnehmerinformation auf dem
Schirm angezeigt und das Gespräch angenommen.
Bei einem anderen Benutzer liegt diese Schwelle
schon bei einmal klingeln. Neben der Klingeldauer
lassen sich in diesem Beispiel eine Vielzahl weiterer
Anpassungsparameter denken. Die Initiative zur
Anpassung liegt immer beim Benutzer.
Adaptive Systeme
Bei adaptiven Systemen wird die Anpassung nicht
auf der Basis von expliziten Auswahlentscheidungen
oder Parametereinstellung des Benutzers vollzogen,
sondern durch die Auswertung von aktuellen und
gespeicherten
Kontextmerkmalen
durch
das
System. Adaptive Systeme passen die Assistenz
selbständig an den Benutzer, seine Vorlieben,
Wünsche
und
Bedürfnisse
bezüglich
der
Unterstützung in bestimmten Situationen an. Analog
zur Adaptierbarkeit kann man wieder Selektion und
Parametereinstellung unterscheiden. Eine einfache
Realisierungsform von Adaptivität auf der Basis
eines
singulären
Kontextmerkmals
ist
die
automatische Selektion der passenden Modalität bei
der
Ausgabe
von
unterstützenden
Handlungsanweisungen in Abhängigkeit von der
(durch Sensoren erfassten) Blickrichtung des
Autofahrers. Schaut er auf ein Display erfolgt die
Ausgabe des Textes visuell, ist sein Blick
abgewendet, erfolgt die Ausgabe akustisch.
Komplexere
Realisierungsformen
könnten
zusätzliche Merkmale (wie die Fahrtgeschwindigkeit)
berücksichtigen und z. B. auch gespeichert Daten
dahingehend auswerten, wie oft der Benutzer bei
beginnender Sprachausgabe den Blick auf das
Display gelenkt hat.
3.3 Initiative
Aktive Assistenz
Bei dieser Form, die manchmal auch pro-aktive
Assistenz genannt wird, um zu betonen, dass das
System vorbeugend Unterstützung anbietet, ergreift
das System die Initiative. Dazu braucht es
Informationen:
Wann
und
unter
welchen
Bedingungen soll es welche Assistenz anbieten? In
den allereinfachsten Fällen reicht für diese
Entscheidung die Identifizierung des individuellen
Benutzers aus oder das System wird aktiv, wenn ein
einzelnes Kontextmerkmal vorliegt, etwa eine
bestimmte Ausprägung der Raumhelligkeit (dann
wird z. B. das Licht gedimmt beim Fernsehen). In
komplizierten Fällen wird das System über eine
diagnostische Komponente verfügen müssen, um
auf der Basis einer Vielzahl von aktuellen und
gespeicherten Informationen über den Benutzer,
sein Verhalten, den jeweiligen Zuständen und
Zustandsfolgen des Systems, sowie seiner
Umgebung eine hilfreiche Assistenz anbieten zu
können. Die gespeicherten Informationen können
dabei auf verschiedenen Wegen gewonnen worden
sein. Benutzer können z. B. zuvor explizit nach ihren
Wünschen und Vorlieben gefragt worden sein oder
das Assistenzsystem schließt aus zurückliegendem
Benutzerverhalten auf Wünsche und Vorlieben.
Passive Assistenz
Bei passiven Assistenzsystemen initiiert der
Benutzer die Assistenz. Konventionelle Hilfesysteme
sind einfache Beispiele für passive Assistenz.
Aktive und passive Assistenz haben jeweils Vor- und
Nachteile. Wenn die Initiative beim Benutzer liegt,
so ist er es, der die Situation meistert und die
Technik steuert und kontrolliert. Allerdings muss er
bereits wissen, dass es diese Art von Unterstützung
5
Wandke, H. & Wetzenstein-Ollenschläger, E.
gibt und er muss sich auch in schwierigen
Situationen wenigstens soviel Zeit und freie
kognitive Kapazität haben, um sich daran zu
erinnern und die Unterstützung abfordern zu können.
Wenn die Initiative beim System liegt (aktive
Assistenz) ist keine Erinnerungsleistung beim
Benutzer
notwendig.
Systementscheidungen
erfolgen meist sehr viel schneller und Aktionen
werden schnell und präzise ausgeführt. Es kann
aber sein, dass der Benutzer das Gefühl hat, der
Technik ausgeliefert zu sein, insbesondere, wenn
das System sich anders verhält, als es der Benutzer
erwartet.
Meist
hat
ein
Benutzer
mehr
Kontextinformationen zur Verfügung als das System
und kann diese Information auch besser verknüpfen.
Aktive Assistenz hat hingegen den großen Vorteil
der Schnelligkeit, was sich besonders in
sicherheitsrelevanten
Situationen
(z.
B.
Bremsassistent) auswirkt.
System. in K.-P. Timpe, T. Juergensohn, und H.
Kolrep (Hrsg.) Mensch Maschine Systemtechnik
- Konzepte, Modellierung, Gestaltung,
Evaluation. Düsseldorf: Symposion Publishing
GmbH, 41-62 (2000).
[4] Kirste, Th., Situation-Aware Mobile Assistance.
in Earnshaw, R.A. (ed.) Frontiers of HumanCentered Computing, Online Communities and
Virtual Environments, London: Springer, 99-115
(2001)
[5] Krämer N C. und Bente G., Virtuelle Helfer:
Embodied Conversational Agents in der
Mensch-Computer-Interaktion. In G. Bente, N.
C. Krämer & A. Petersen (Hrsg.), Virtuelle
Realitäten. Göttingen: Hogrefe, 203-225 (2002).
4. REFERENCES
[6] Parasuraman, R., Sheridan, Th.B. & Wickens,
Ch.D. (2000). A model for Types and Levels of
Human Interaction with Automation. IEEE
Transactions on Systems, Man, and
Cybernetics, 30, 286-297
[1] Bubb, H., Fahrerassistenz primär ein Beitrag
zum Komfort oder für die Sicherheit? in: VDIBerichte 1768, Der Fahrer im 21. Jahrhundert.
(Düsseldorf: VDI Verlag), 25-45 (2003).
[7] Sculley, J., The relationship between business
and higher education: A perspective on the 21st
century. Communications of the ACM 32, 10561061 (1986).
[2] Enge, M., Sprachassistenz für verschiedene
Nutzergruppen beim Bedienen von Automaten.
In: VDI-Berichte 1678, Useware 2002: MenschMaschine-Kommunikation/Design, Düsseldorf:
VDI-Verlag-GmbH, 61-66 (2002).
[8] Wahlster, W., SmartKom: Symmetric
Multimodality in an Adaptive and Reusable
Dialogue Shell. in: Krahl, R., Günther, D. (eds):
Proceedings of the Human Computer Interaction
Status Conference 2003, Berlin: DLR, 47-62
(2003).
[3] Hauss, Y. und Timpe, K.-P. , Automatisierung
und Unterstützung im Mensch-Maschine-
6
Assistenzsystme: Woher und Wohin?
Referenten
Hartmut Wandke ist Professor für Ingenieurpsychologie / Kognitive Ergonomie an der
Humboldt-Universität zu Berlin. Seine aktuellen Forschungsinteressen liegen u.a. auf
den Gebieten: Arbeiten und Lernen mit Inter- und Intranet / Orientierung und
Navigation in vernetzten Systemen / Website Usability / Benutzungsschnittstellen für
interaktive Systeme im Alltag / Wissensmanagement / Assistenzsysteme
/Hypermedia-Anwendungen.
Elke Wetzenstein ist PD am Lehrstuhl für Arbeitspsychologie der HumboldtUniversität zu Berlin. Sie promovierte und habilitierte zu Fragen der multimodalen
Kodierung. Im Rahmen der Lehre vertritt sie vor allem das Gebiet der Methodik
Arbeits- und Ingenieurpsychologischer Forschung und zur anforderungsbezogenen
Diagnostik von Personeneigenschaften.
In einer Reihe von Praxisprojekten beschäftigte sie sich vor allem mit der Entwicklung
von Assistenzsystemen für LkW, PkW, im Haushalt, zur Robotersteuerung oder zum
Bedienen komplexer Produktionsanlagen.
7
ERMITTLUNG VON ASSISTENZWÜNSCHEN VON FAHRERN
MIT HILFE DER METHODE NUTZER-MOCK-UP
Holger Enigk
DaimlerChrysler AG
Research and Technology / Body and Powertrain
096/U152 RBP/BA
12274 Berlin
Holger.Enigk@daimlerchrysler.com
Knut Polkehn
10178 Berlin
knut.polkehn@rz.hu-berlin.de
http://arb1.psychologie.hu-berlin.de/ingpsy
ABSTRACT
sogar
In
diesem
Beitrag
des
Workshops
“Assistenzsysteme”
wird der Benutzer-(Fahrer-)
orientierte Entwurf von Fahrerassistenzsystemen am
Beispiel der Methode “Nutzer-Mock-Up” vorgestellt.
Die Teilnehmer werden die Methode bei der
Konfiguration eines Systems zur Abstandsregelung
ausprobieren. Die Ergebnisse werden anschließend
mit den Ergebnissen realer Befragungen verglichen.
ermöglichen. Dabei ermöglicht moderne Sensor-,
Bildverarbeitungs- und Telekommunikationstechnik,
differenzierte Informationen aus der Verkehrsumwelt
und dem Fahrzeug zu erfassen. Die Drive-by-wireTechnologie erlaubt es, aufgrund der mechanischen
Entkopplung von Lenkung, Bremse und Fahrpedal
den technischen Prozess elektronisch zu steuern.
Darüber hinaus werden ungeahnte Möglichkeiten
eröffnet, das Fahrzeug zu personalisieren und
individuelle Unterstützung anzubieten. Gleichzeitig
werden
die
Freiheitsgrade
in
der
Handlungsausführung, die durch die zunehmende
Automatisierung entstehen, mit Zusatz- und
Komfortfunktionen
gefüllt.
Hierzu
werden
Telekommunikations-,
Infotainmentoder
Internetdienste bereitgestellt.
Keywords
Fahrassistenz,
Akzeptanz,
benutzerzentrierte
Entwicklung,
Anforderungsanalyse,
Evaluation,
Nutzer-Mock-Up
1. FAHRASSISTENZ
1.1 Technik: Nicht ist unmöglich!?
Die Entwicklung von Unterstützungssystemen
boomt.
Gegenwärtig
werden
in
der
Automobilindustrie
große
Anstrengungen
unternommen, dem Fahrer eines Kraftfahrzeugs
vielfältige Unterstützung anzubieten, um das
Autofahren
sicherer,
komfortabler
und
wirtschaftlicher zu gestalten [3].
Die ersten Unterstützungssysteme, wie z. B. ein
Antiblockiersystem oder ein Navigationssystem,
kamen bereits Ende der 80er Jahre auf den Markt
und
gehören
heute
auch
im
unteren
Fahrzeugsegment zur Serienausstattung. Momentan
sind Systeme, wie der Abstandsregeltempomat
(Distronic),
der
Bremsassistent
oder
das
elektronische Stabilitätsprogramm (ESP) in aller
Munde. Für die Zukunft gibt es Bestrebungen, die
Fahraufgabe zunehmend zu automatisieren und
gewerbliche Vertrieb ist untersagt. Rückfragen sind zu stellen an den
Vorstand des GC-UPA e.V. (Postfach 80 06 46, 70506 Stuttgart).
Proceedings of the
© 2003 German Chapter of the UPA e.V.
8
autonomes Fahren auf
Teilstrecken zu
1.2 Wirkung: Alles so gewollt?
Wenn die technische Unterstützung hinreichend gut
ist, so erzielt ein Assistenzsystem die erwünschte
Wirkung
auf
Fahrsicherheit,
Komfort
oder
Wirtschaftlichkeit. Allerdings weiß man aus der
Analyse sozialer Assistenz, das Unterstützung auch
unerwünschte Wirkungen haben kann. Ein
klassisches
kommunikationspsychologisches
Beispiel sei hier angeführt [7]. Auf die Anmerkung
des Beifahrers “Da vorne ist grün” antwortet die
Beifahrerin mit “Fährst Du oder fahre ich?”. Weitere
Konsequenzen lassen sich erahnen.
Auch beim Einsatz technischer Unterstützung sind
derartige unerwünschte Reaktionen möglich. So
kann z.B. ein durch den Fahrer selbst einstellbarer
Schwellwert zur Warnung vor dem Unterschreiten
eines Mindestabstandes dazu führen, dass ein
geringerer Mindestabstand eingehalten wird als
durch Fahrer, die kein Abstandswarnsystem
benutzen [5].
Erste Ideen, was man gegen unerwünschte Wirkung
von Assistenz unternehmen kann, finden sich in den
Ergebnissen des Projekts “EMPHASSIS” [2]. In
Untersuchungen am Fahrsimulator wurden am
Beispiel der Unterstützung der Längs- und
Querführung Hinweise darauf gefunden, dass die
Sinnesmodalitäten Haptik und Kinästhetik eine
besondere Rolle beim Rückmeldungen an den
Fahrer spielen.
1.3 Akzeptanz: Was meint der Nutzer?
Die Akzeptanz dient häufig als ein wichtiges
Kriterium zur Evaluation von Assistenzsystemen.
Dabei erhofft man sich Aussagen, die Rückschlüsse
auf die Nutzungs- und Kaufabsicht zulassen. Das
methodische Vorgehen spielt eine entscheidende
Rolle, da man nicht weiß, ob eine Person, die Idee
eines Systems oder dessen Realisierung bewertet,
welchen Einfluss die Relevanz des Urteils (z.B.
wegen einer anstehenden Kaufentscheidung) auf
das Urteil selbst hat oder inwieweit die
Versuchssituation (z.B. eine “Fahrsimulation”) in der
Lage ist den Trade-Off zwischen der Maximierung
der Sicherheit und der Minimierung des subjektiv
empfundenen
Eingriffs
in
die
Entscheidungsautonomie
zu
vermitteln.
Die
Einbeziehung
des
Nutzers
in
den
Entwicklungsprozess erfordert deshalb sowohl eine
differenzierte Erfassung von Akzeptanz (z.B.
Nützlichkeit vs. Zufriedenheit [8]) als auch die
Verwendung weiterer Methoden (siehe Abschnitt 3)
2.2 Wo kann gestaltet werden?
Die Abbildung 1 zeigt, welche Bereiche für die
Gestaltung von Unterstützungssystemen relevant
sind: die Gesellschaft, die Ausführungsbedingungen,
die Aufgabe und deren verschiedene Unterebenen
sowie die Markteinführung. Hauptgegenstand der
Gestaltung
sind
die
Teilaufgaben,
die
Bedienabläufe, die Ein- sowie Ausgabemedien und
letztlich
die
Einzelinformationen
und
Bedienelemente.
2. ENTWURF VON FAHRASSISTENZ
2.1 Wie geht man vor?
Wie lassen sich nun Systeme entwickeln, die
technische
Möglichkeiten
mit
erwünschten
Wirkungen und einer hohen Akzeptanz durch den
Nutzer kombinieren? Hierzu ist ein Kunden- und
Fahrerorientierter Entwicklungsansatz notwendig,
wie er z.B. von Enigk [3] speziell für
Unterstützungssysteme im Kraftfahrzeug und
allgemein für alle Unterstützungssysteme im
Rahmen des Projektes EMBASSI [6] entwickelt
wurde.
Der
Grundgedanke
des
Entwicklungsansatzes ist es, dass auf der Grundlage
einer
fundierten
der
spezifische Unterstützungsbedarf der jeweiligen
Nutzer für die jeweilige Fahraufgabe sowie den
spezifischen
Fahrzeugund
Umgebungsbedingungen identifiziert wird. Diese Anforderungen
bilden dann die Basis für den Entwurf eines
Assistenzkonzepts. Dabei wird die Gestaltung von
Assistenzsystemen im Rahmen der psychologischen
Tätigkeitsgestaltung betrachtet.
Nach Hacker, Timpe & Plath [4] unterliegen die
Gestaltungsfragen bei rechnergestützten Tätigkeiten
einem hierarchischen Konzept. So müssen
Aussagen und Entscheidungen auf der jeweils
höheren Ebene getroffen werden, bevor darunter
liegende Schichten bearbeitet werden können. Das
heißt, Entscheidungen auf der höheren Ebene bilden
Grundlage
und
Rahmenbedingung
für
die
Entscheidungen auf den tieferen Ebenen. Diese
Hierarchie der Gestaltungsebenen für MenschMaschine-Systeme wurde von Enigk [3] auf die
Gestaltung von Unterstützungssystemen angewandt.
Abbildung 1: Hierarchie der Gestaltungsebenen bei
Fahrerunterstützungssystemen (Enigk [3] in
Anlehnung an Hacker, Timpe & Plath, [4])
9
Enigk, H. & Polkehn, K.
Die Gesamtaufgabe wird in der Regel nicht
gestaltet, weil ein Unterstützungssystem “nur” ein
Teilsystem im Gesamtsystem “Mensch und
Fahrzeug” ist.
Dies würde es erlauben, Gestaltungsentscheidungen
im Sinne des Nutzers zu treffen und die Akzeptanz
zu erhöhen.
Das heißt, es wird im Allgemeinen nicht die
Fahrtätigkeit als solche neu konzipiert oder die
Mensch-Mensch-Aufgabenteilung
verändert.
Sondern es sind primär aufgabenrelevante
Teilaspekte zu gestalten, um den Fahrer bei der
Erreichung seiner Ziele in der Handlungsausführung
zu
unterstützen.
Trotzdem
müssen
die
Rahmenbedingungen, die durch die Gesellschaft,
die
Gesamtaufgabe
und
durch
die
Ausführungsbedingungen gegeben sind, analysiert
und berücksichtigt werden. Sie bestimmen die
Freiheitsgrade für die Gestaltung. Letztere werden
nur Gegenstand der Gestaltung, wenn eine
Innovation an die Grenzen der Umsetzbarkeit stößt.
3. METHODE: NUTZER-MOCK-UP
2.3 Was soll wie unterstützt werden?
Für die Gestaltung von Assistenzsysteme im
Fahrzeug bedeutet das, dass als erstes die Frage
beantwortet werden muss, welche Handlungen
unterstützt werden müssen und wie diese
Unterstützung
aussehen
soll
(unterstützte
Handlungsphasen,
nötige Assistenzform
und
Automatisierungsgrad bei der Ausführung – vgl.
Wandke & Wetzenstein in diesem Workshop).
Damit wird festgelegt, ob das System nur
Informationen
oder
Warnungen
liefern,
Handlungsvorschläge geben, selbst Entscheidungen
treffen oder auch automatische Eingriffe oder
Handlungen durchführen soll.
Auf der Ebene der Bedienabläufe stehen Fragen der
Adaptivität, Adaptierbarkeit und Initiative der
Assistenz im Mittelpunkt. Aufgrund der großen
Dynamik der Fahrtätigkeit und geringen zeitlichen
Freiheitsgrade in der Handlungsausführung bedarf
es eines geeigneten Informationsmanagements. Es
muss erreicht werden, dass der Fahrer zu jeder Zeit
über die notwendige Information verfügt, ohne ihn
dabei zu überfordert oder abzulenken. Die folgenden
Ebenen beschäftigen sich dann mit klassischen
Themen der Ein- und Ausgabemedien sowie der
Gestaltung
von
Einzelinformationen
und
Bedienelementen.
Diese Entscheidungen sind in der Entwurfsphase
von Usability-Experten oder Entwicklern zu treffen.
Allerdings besteht dann immer noch die Frage, ob
das Assistenzkonzept vom Nutzer akzeptiert und in
dieser Form gewünscht wird. Hierzu werden im
Allgemeinen die Entwürfe in Form von Skizzen,
Sitzkisten oder Prototypen umgesetzt und dann mit
zukünftigen Nutzern oder Kunden bewertet. Dieses
Vorgehen ist sinnvoll und notwendig, jedoch kann
eine Evaluation erst mit der Umsetzung der
Entwürfe erfolgen. Die Frage ist nun, ob nicht schon
im Vorfeld der Entwurfsentscheidungen die
Vorstellungen der Nutzer erfasst und in den
Entscheidungsprozess einbezogen werden können.
10
3.1 Assistenz konfigurieren
Die Methode des Nutzer-Mock-Up’s [1] dient dazu
das
aus
Sicht
des
Nutzers
ideale
Unterstützungskonzept zu erfassen. Dem Probanden
werden dazu ein oder mehrere Aufgaben und
Situation
vorgestellt,
für
die
ein
Unterstützungssystem entwickelt werden soll. Der
Nutzer hat dann die Aufgabe, für diese Fahraufgabe
(z. B. Abstandshaltung) ein für sich ideales
Assistenzsystem zusammenzustellen. Dabei muss
er die oben beschriebenen Gestaltungsfragen zur
Automatisierung, aktiven und passiven Assistenz,
Informationsdarstellung,
Adaptivität
und
Adaptierbarkeit etc. beantworten. Die Methode kann
somit als eine Art Assistenzkonfigurator verstanden
werden, mit dem die naiven Vorstellungen der
zukünftigen Nutzer und Käufer des Systems erfasst
werden. Das Nutzer-Mock-Up kann bereits im
Vorfeld des Entwicklungsprozesses eingesetzt
werden, wenn gerade einmal eine erste Idee für ein
zu entwickelndes System besteht.
3.2 Assistenz evaluieren
Das Nutzer-Mock-Up kann aber auch zur Evaluation
verwendet
werden.
Hierzu
wird
dem
Versuchsteilnehmer das zu evaluierende System als
Skizze, Video, Prototyp oder ähnliches als eine
mögliche Alternative der Assistenz vorgestellt.
Anschließend wird der Nutzer gefragt, ob er sich die
Unterstützung so oder anders vorstellen würde. Mit
Hilfe des Nutzer-Mock-Ups kann sich der Nutzer
dann sein ideales System zusammenstellen.
Dadurch erfolgt eine indirekte Evaluation des
vorgestellten Systems, da die Differenz zwischen
realisierter Gestaltung und dem beschriebenen Ideal
bestimmt werden kann. Somit kann die Methode zu
allen Zeitpunkten des Entwicklungsprozesses
eingesetzt werden. Der Entwickler erhält Hinweise,
welche Form der Assistenz der Nutzer wünscht.
3.3 Assistenz entwickeln
Die Methode wurde mehrfach erfolgreich im
Entwicklungsprozess eingesetzt und in einer
Längsschnittuntersuchung
evaluiert.
Eine
Längsschnittstichprobe evaluierte ein System zur
Abstandsregulation im Fahrzeug. Hierbei wurde die
Methode zu vier verschiedenen Zeitpunkten
eingesetzt: im Vorfeld ohne Systemkenntnis, nach
der Videopräsentation des Systems, nach einer
Probefahrt mit dem System, nach einer mehrtägigen
Nutzung des Systems. Ein und die selben
Versuchsteilnehmer füllten den Fragebogen zum
Nutzer-Mock-Up aus. Zusätzlich wurden zu jedem
Zeitpunkt Querschnittsstichproben erhoben. Die
Ergebnisse zeigen, dass die Nutzer bereits sehr früh
eine recht konkrete Vorstellung vom idealen System
besitzen. Diese Vorstellung konkretisiert sich, je
mehr die Fahrer die Möglichkeit haben, das System
mit allen Sinnen zu erleben und im eigentlichen
Sinne des Wortes zu “erfahren” können. Somit
können bereits in frühen Phasen Aussagen zur
Akzeptanz und Schlussfolgerungen zur Gestaltung
ermittelt werden. Wird die Methode bei einer
hinreichend großen Stichprobe eingesetzt können
zusätzlich,
per
Clusteranalyse
spezifische
Nutzergruppen
und
spezifische
Systemkonfigurationen identifiziert werden.
4. VORGEHEN IM WORKSHOP
(Förderkennzeichen: 19 S 9812 7). Würzburg:
Interdisziplinäres Zentrum für
Verkehrswissenschaften an der Universität
Würzburg (IZVW) (2002).
[3] Enigk H., Ein psychologisches Vorgehensmodell
zur Entwicklung von Unterstützungssystemen für
Kraftfahrzeuge. Dissertation. Berlin:
Mathematisch-Naturwissenschaftliche Fakultät II
der Humboldt-Universität zu Berlin (2003).
[4] Hacker W., Timpe K.-P. & Plath E., Aufgaben
und Ergebnisse psychologischer Forschung bei
der Vorbereitung, Einführung und Nutzung von
Schlüsseltechnologien. Psychologie für die
Praxis, 4 (1989).
Im Workshop wird die Methode “Nutzer-Mock-Up”
bei der Konfiguration von Assistenz vorgestellt und
an einem Beispiel für eine Fahraufgabe in
Interaktion mit den Teilnehmern verdeutlicht. Die
Ergebnisse des Workshops werden am Ende den
Ergebnissen einer vorhandenen Nutzerbefragung
gegenübergestellt.
[5] Polkehn K., Preuschhof C. & Kussmann H.,
Assistenz und Automatisierung im KFZ –
Simulationsstudien zur Unterstützung der
Abstandshaltung. In: Situation Awareness in der
Fahrzeug- und Prozessführung. DGLR-Bericht
2002-04, Bonn: DGLR (2002).
5. REFERENZEN
[6] Projekt Embassi (Förderkennzeichen
01IL904A4).
http://www.embassi.de [15.07.03]
[1] Beier B., Enigk H. & Renner G., Methoden zur
Bestimmung präferierter Automatisierungsgrade
bei Assistenzsystemen. In Useware: MenschMaschine-Kommunikation/Design. Tagung
Darmstadt 11./12. Juni 2002, VDI-Berichte 1678,
Düsseldorf: VDI-Verlag (2002).
[2] Buld S., Krüger H.-P., Hoffmann S., Kaussner
A., Tietze H. & Totzke I., Wirkungen von
Assistenz und Automation auf Fahrerzustand
und Fahrsicherheit. Veröffentlichter
Abschlussbericht Projekt EMPHASIS: EffortManagement und Performance-Handling in
sicherheitsrelevanten Situationen
[7] Schulz von Thun F., Miteinander reden:
Störungen und Klärung. Allgemeine Psychologie
der Kommunikation. Reinbek (1981).
[8] Van der Laan J. D., Heine A. & de Waard D., A
simple procedure for the assessment of
acceptance of advanced transport telematics.
Transportation Research - Part C: Emerging
Technologies. 5 (1), 1 -10 (1997).
11
Enigk, H. & Polkehn, K.
Referenten
Holger Enigk ist stellvertretender wissenschaftlicher Leiter der Forschungsabteilung
„Akzeptanz und Verhaltensanalyse“ der DaimlerChrysler AG. Zuvor war er mehrere
Jahre Mitarbeiter am Institut für Psychologie der Humboldt-Universität, wo er auch
Psychologie studierte und im Jahr 2003 promovierte. In seiner Promotion entwickelte
er
ein
psychologisches
Vorgehensmodell
für
die
Entwicklung
von
Unterstützungssystemen im Kraftfahrzeug.
Seit mehreren Jahren ist er im Bereich der Kundenforschung tätig. Er beschäftigt sich
mit Fragen der Anforderungen und Evaluation von innovativen Systemen und
Fahrzeugen aus Kundensicht. Ein weiteres Forschungsgebiet ist die
kraftfahrzeugspezifische Entwicklung und Anpassung psychologischer Methoden.
Knut Polkehn ist Diplom-Psychologe und seit 1998 wissenschaftlicher Mitarbeiter am
Lehrstuhl für Ingenieurpsychologie / Kognitive Ergonomie an der HumboldtUniversität zu Berlin.
Zu seinen Schwerpunkten gehörten zunächst Untersuchungen zur Navigation und
Orientierung in Hypertexten, dabei insbesondere die Analyse gestaltungsrelevanter
Merkmale
einzelner
Webseiten,
sowie die Entwicklung von webbasierten Untersuchungsmethoden.
Derzeit beschäftigt er sich neben der Lehre (webbasierte Kooperation und neue
Techniken in der Mensch-Rechner-Interaktion) mit der Entwicklung und Evaluation
von Assistenzsystemen für das KFZ. Von besonderen Interesse ist für ihn dabei die
Analyse erwünschter und unerwünschter Auswirkungen von Assistenz.
12
MEHR ALS LOOK UND FEEL:
VIRTUELLE HELFER
Nicole C. Krämer
Psychologisches Institut
Universität zu Köln
Bernhard-Feilchenfeld-Str. 11
50969 Köln
nicole.kraemer@uni-koeln.de
http://www.uni-koeln.de/phil-fak/psych/diff/darkraem.htm
ABSTRACT
Im Zuge der Entwicklung neuer Mensch-TechnikInteraktionsformen muss auch die Usability
Forschung neue Aspekte berücksichtigen und ihre
Methoden den neuen Erfordernissen anpassen.
Insbesondere
die
zunehmende
Anthropomorphisierung von Schnittstellen durch
aktuelle Entwicklungen im Bereich der sogenannten
anthropomorphen Interface Agenten (AIA) erfordert
die Anwendung neuer Methoden, die nicht nur auf
die Erfassung klassischer Usability Kriterien
ausgerichtet sind, sondern im Hinblick auf
sozialpsychologische Konzepte erweitert werden.
Der Beitrag stellt in diesem Sinne die Verschränkung
von Effektivität/Effizienz und sozialen Wirkungen vor.
Keywords
Anthropomorphe Interface Agenten, multimodale
Mensch-Technik-Interaktion, Evaluation, soziale
Wirkungen
1. EINLEITUNG
Als eine Möglichkeit zur Gestaltung intuitiver und
möglichst
natürlich bedienbarer Benutzungsschnittstellen werden in den letzten Jahren
besonders häufig anthropomorphe Interface Agenten
(AIA) präsentiert, die dem Nutzer langfristig einen
der face-to-face Interaktion ähnelnden Kontakt mit
der
Technik
ermöglichen
sollen.
Virtuelle,
menschenähnliche
Figuren
sollen
natürliche
Sprache und Gestik nicht nur verstehen, sondern
vor allem auch autonom produzieren können, um
die Interaktion zwischen Mensch und Technik zu
erleichtern.
Stuttgart).
Proceedings of the
Für den Bereich des Usability Engineering stellen
sich in diesem Zusammenhang verschiedene
Aufgaben. Zum einen sind zentrale Fragen sowohl
zur
Gestaltung
als
auch
zum
Einsatz
anthropomorpher Agenten bislang unbeantwortet:
Die Frage, welche Art von Helfer, im Rahmen
welcher Aufgaben, von welchen Personengruppen
akzeptiert wird sowie zu Effektivität und Effizienz
beiträgt, ist beispielsweise nur unzureichend
erforscht. Zum anderen kann vor dem Hintergrund
erster
empirischer Untersuchungen vermutet
werden, dass virtuelle Helfer spezifische und
neuartige Wirkungen auslösen, die mit Hilfe
bisheriger Methoden nicht oder nur unzureichend
erfasst werden konnten. Im Rahmen dieses
Beitrages soll vor allem die letztgenannte
Aufgabenstellung fokussiert werden. Eingegangen
werden soll insbesondere auf sogenannte soziale
Wirkungen von anthropomorphen Interface Agenten.
Unter sozialer Wirkung ist hierbei zu verstehen, dass
sich in Gegenwart des technischen Systems
ähnliche
emotionale,
kognitive
und
verhaltensmäßige Reaktionen einstellen, wie in
Gegenwart eines Menschen [6]. Häufig sind diese
Wirkungen eng verknüpft nicht nur mit der
Akzeptanz der Schnittstelle, sondern vor allem auch
mit der Effizienz und Effektivität bei Bedienung
und/oder Aufgabenerledigung. Soziale Wirkungen
erscheinen
somit
hochrelevant
auch
im
Zusammenhang mit den klassischen Usability
Kriterien. Im weiteren werden nun zunächst
empirische Ergebnisse zu sozialen Wirkungen
geschildert, aus denen im Anschluss die relevant
werdenden methodischen Erweiterungen abgeleitet
werden.
2. EFFEKTE ANTHROPOMORPHER
AGENTEN
Im Folgenden werden zunächst Ergebnisse zur
Evaluation anthropomorpher Interface Agenten
berichtet, die einerseits als soziale Wirkung
verstanden werden können, andererseits das
Kriterium der Effektivität und/oder Effizienz
beeinflussen.
13
Krämer, N. C.
2.1 Aufmerksamkeit
Eine der ersten Fragen, die sich in diesem
Zusammenhang
stellt,
ist
die
nach
der
Aufmerksamkeit, die die anthropomorphen Interface
Agenten auf sich ziehen sowie nach den damit
einhergehenden Folgen für die Effektivität bei der
Nutzung. Es konnte gezeigt werden, dass ein
virtuelles Gesicht in Konkurrenz zu einem StandardInterface ebensoviel Aufmerksamkeit auf sich zu
ziehen vermag wie ein reales menschliches Gesicht
[1]. Darüber hinaus können virtuelle Gesichter auch
zu spezifischen Inferenz- und Attributionsprozessen
führen, wie sie aus der Humankommunikation
bekannt sind. So stellen Takeuchi und Naito [14]
fest, dass Versuchspersonen in der Interaktion mit
virtuellen Figuren offensichtlich versuchen, deren
Gesichtsausdruck im Sinne dahinter liegender
Emotionen zu deuten und darüber sogar die
gestellte Aufgabe vergessen. Während diese
Ergebnisse eher darauf hindeuten, dass die
Anwesenheit von virtuellen Personen eher zu einer
auf diese fokussierten Aufmerksamkeit führt, die die
Performanz behindert, lassen die Ergebnisse von
Lester et al. [10] einen anderen Schluss zu: Hier
steigt die Leistung der Probanden, wenn ein
pädagogischer Agent anwesend ist,
2.2 Social facilitation
Besondere Aufmerksamkeit bei der Untersuchung
anthropomorpher Schnittstellen wurde der Frage
entgegengebracht, ob die Gegenwart von virtuellen
Personen zu Social Facilitation führt. Im Rahmen
dieses Phänomens verursacht die Anwesenheit
anderer Menschen, dass gut geübte oder wenig
komplexe Aufgaben besser erfüllt werden, während
es bei wenig geübten oder komplexen Aufgaben zu
Leistungsverschlechterungen kommt [16]. Die
Hypothese, dass anthropomorphe Interface Agenten
ebenfalls als soziale Entitäten wahrgenommen, legt
die Vermutung nahe, dass sich vergleichbare
Effekte zeigen. Rickenberg und Reeves [12]
untersuchten diesen Aspekt mit Hilfe eines
Microsoft-Charakters („Professor“). Die Autoren
konnten feststellen, dass Probanden, die einen
animierten Charakter auf dem Bildschirm sehen,
größere Angst erleben und mehr Fehler machen –
insbesondere dann, wenn der Agent den Nutzer zu
beobachten scheint. Es zeigten sich somit eher
negative Effekte. Die Autoren führen dies auf eine
durch die soziale Gegenwart bedingte höhere
Erregung zurück, aus der sich dann eine
Akzentuierung
der
vorhandenen
Handlungsund/oder Gefühlstendenzen ergibt. Auch Sproull et
al. [13] weisen Effekte nach, die sich konsistent zur
Theorie der Social Facilitation interpretieren lassen:
Ähnlich wie bei Rickenberg und Reeves [12]
berichten Versuchspersonen, die mit einem anthropomorphen Interface konfrontiert sind, über eine
höhere Erregung sowie weniger Selbstsicherheit und
Entspannung. Walker, Sproull und Subramani [15]
können positive Leistungsveränderungen bei
14
Nutzern feststellen, die mit einem synthetischen
Gesicht arbeiten, und interpretieren dies ebenfalls
im Sinne der Social Facilitation: Personen, die von
einem synthetischen Gesicht befragt wurden, ließen
sich mehr Zeit, machten weniger Fehler und
antworteten ausführlicher auf offene Fragen. Dieser
Effekt konnte sogar noch verstärkt werden, wenn
das Gesicht einen ernsten statt neutralen Ausdruck
zeigte – auch wenn dieses am wenigsten positiv
bewertet wurde.
2.3 Kommunikation und Kooperation
Auch Kommunikation und Kooperation im Sinne der
Frage, ob Nutzer das System in einer adäquaten
Weise bedienen und ob sogar Zusammenarbeit im
Hinblick auf die gewünschte Zielerreichung gefördert
wird, sind Aspekte, die Einfluss auf die Effektivität
und Effizienz der Bedienung nehmen. Dabei steht
hinsichtlich der Kommunikation beispielsweise im
Vordergrund,
ob Nutzer
ein System
mit
anthropomorphem Interface Agenten bereitwilliger
durch natürliche Sprache adressieren. Tatsächlich
ließ sich nachweisen, dass Nutzer ein Video-System
eher durch natürlichsprachige Befehle bedienen,
wenn ein virtueller Helfer auf dem Bildschirm
sichtbar ist [8]. Die Situation bzw. die Figur wird
somit zumindest als so sozial wahrgenommen, dass
mögliche Hemmungen, ein technisches Gerät
anzusprechen, abgebaut werden. Sproull et al. [13]
interessieren sich für Fragen der Kooperation mit
virtuellen Agenten. Die empirischen Ergebnisse
zweier Studien, innerhalb derer Nutzer und
Computer kooperativ eine soziale Dilemma-Aufgabe
lösen sollen, sind allerdings nicht konsistent:
Während Kiesler, Sproull und Waters [4] berichten,
dass die Nutzer weniger häufig mit dem Computer
kooperieren, wenn ein menschenähnliches Interface
präsent ist, zeigen Parise et al. [11], dass ComputerPersonen durchaus in ebenso großem Ausmaß
kooperatives Verhalten auslösen können wie eine
reale Person in einer Videodarstellung. Ebenfalls in
diesem
Zusammenhang
eingesetzte
HundeCharakter (computer dog und computer cartoon dog)
dagegen werden zwar als äußerst liebenswert
beurteilt, Kooperation erfolgt aber lediglich dann,
wenn der Nutzer Hundebesitzer ist. Die Autoren
schließen, dass „if participants were able to form a
social expectation of the agents as a cooperator,
then they could safely choose cooperation“ (S. 140).
Dies sei bei einem menschenähnlichen Äußeren für
die Mehrzahl der Nutzer der Fall gewesen; bei
einem Hunde-Charakter jedoch nur für diejenigen,
die gewöhnlich mit einem Hund interagieren. Die
Inkonsistenz zur Studie von Kiesler et al. [4] erklären
die Autoren mit dem Hinweis, dass dort ein
künstlicheres Gesicht eingesetzt wurde.
2.4 Impression management
Eine der interessantesten Formen sozialer
Wirkungen konnten Sproull, Subramani, Kiesler,
Walker und Waters [13] nachweisen: Füllten die
Mehr als Look und Feel: Virtuelle Helfer
Versuchspersonen
Fragebögen
zu
sozial
erwünschtem
Verhalten
mit
Hilfe
eines
anthropomorphen „Talking face“ aus, wurde eine
verstärkte Tendenz zur positiven Selbstdarstellung
beobachtet. Auch Krämer, Bente und Piesk [7]
konnten zeigen, dass bei der Präsentation einer
Auswahl von Fernsehbeiträgen durch einen
virtuellen Helfer die Tendenz besteht, sich für eine
sozial erwünschte Sendung zu entscheiden. Dieses
auch
als
„Impression
Management“
oder
Selbstpräsentation bezeichnete Phänomen [2], tritt
vorrangig in Gegenwart anderer Personen auf und
führt häufig zu konformistischem oder sozial erwünschtem Verhalten [9]. Ziel ist das Hinterlassen
eines möglichst 'guten Eindrucks', der das
Gegenüber zu einer positiveren Behandlung
veranlassen soll. Dieses Phänomen hat natürlich
weitreichende Implikationen für den Einsatz anthropomorpher Interfaces im alltäglichen Leben. Denn
dem
denkbaren
Nutzen
eines
adaptiven
Interfaceagenten, im Sinne von Orientierung und
Motivation des Users, stehen möglicherweise auch
erhebliche psychologische Kosten gegenüber – auch
in Bezug auf einen potentiellen Effizienzverlust - ,
die in der Evaluation zu berücksichtigen sind. So
fragen denn auch Sproull et al. [13]: „Many people
want computers to be responsive to people. But do
we also want people to be responsive to
computers?“ (S. 119).
3. ERFASSUNG DER SOZIALEN
WIRKUNGEN
Vor dem Hintergrund der berichteten Ergebnisse
muss für die Usability Forschung im Bereich
anthropomorpher
Interface
Agenten
eine
Erweiterung in Bezug auf sozialpsychologische
Aspekte gefordert werden. Um dem Phänomen
gerecht zu werden, ist nicht nur eine herkömmliche
Erfassung von Akzeptanz und Effizienz/Effektivität
erforderlich, sondern darüber hinaus wird eine
Berücksichtigung
potentiell
sozialer
Aspekte
notwendig, die die Ergebnisse zu Akzeptanz und
Effizienz/Effektivität möglicherweise mediieren.
Hinweise auf soziale Wirkungen können einerseits
durch die Erhebung subjektiver Daten, andererseits
durch
objektive
Daten
gewonnen
werden.
Möglichkeiten zur Erhebung subjektiver Eindrücke in
Bezug auf soziale Wahrnehmungen lassen sich
etwa mit Hilfe von Fragebögen gewinnen, die auch
im Rahmen der Humankommunikation eingesetzt
werden. Vor allem bieten sich Verfahren zur
Personwahrnehmung
an
–
beispielsweise
semantische
Differentiale,
aufgrund
derer
Eigenschaftszuschreibungen (sympathisch, nervös,
dominant etc.) vorgenommen werden können [5].
Ein weiteres aufschlussreiches Instrument stellen die
im Rahmen der Medienpsychologie entwickelten
Verfahren zur
Erfassung der
sogenannten
parasozialer Interaktion dar. Mittlerweile lässt sich
auf diese Weise auch für virtuelle Personen prüfen,
ob sich beim Nutzer eine andauernde Beziehung zur
Persona, d.h. in diesem Fall zur virtuellen Figur,
ausgebildet hat [3].
Um
auch anhand objektivierbarer Aspekte
Aufschluss über soziale Wirkungen zu erhalten,
empfiehlt
sich
beispielsweise
Verhaltensbeobachtung, mit deren Hilfe Aspekte im Sinne der
oben angeführten Ergebnisse erhoben werden
können. So kann erfasst werden, ob in höherem
Ausmaß sozial erwünschte Verhaltensweisen
auftreten, ob die Kooperation ansteigt oder die
Kommunikation natürlicher wird, wenn ein virtueller
anwesend ist.
4. FAZIT
Bisherige Ergebnisse zu anthropomorphen Interface
Agenten zeigen, dass diese in verschiedener
Hinsicht
Einfluss auf
die Mensch-TechnikKommunikation nehmen. Dabei scheinen Effekte,
die die Effektivität und Effizienz betreffen, eng
verbunden zu sein mit spezifischen sozialen
Wirkungen, die denen der Humankommunikation
ähneln. Dies kann je nach Bereich zu einer
Effizienz- oder Leistungsverbesserung, aber im
Gegenteil auch zu deren Minderung führen. Künftige
Usability Studien müssen diesen zusätzlichen
Einflussfaktor mit Hilfe angemessener Methoden
berücksichtigen, um Effekte nicht nur erklären und
vorhersagen zu können, sondern um vor allem auch
entsprechende Optimierungen anzuregen bzw. die
Einsatzgebiete von virtuellen Helfern zu planen.
5. REFERENCES
[1] Dehn D. M. & van Mulken S., The impact of
animated interface agents: a review of empirical
research, International Journal of HumanComputer Studies, 52, 1-22 (2000).
[2] Goffman E., The presentation of self in everyday
life. New York: Doubleday & Company, (1959).
[3] Hartmann T., Klimmt C. & Vorderer P., Avatare:
Parasoziale Beziehungen zu virtuellen Akteuren,
Medien und Kommunikationswissenschaft, 49
(3), 350-368 (2001).
[4] Kiesler S., Sproull L. & Waters K., A prisoner´s
dilemma experiment on cooperation with people
and human-like computers. Journal of
Personality and Social Psychology, 70, 47-65
(1996).
[5] Krämer N. C., Bewegende Bewegung. Sozioemotionale Wirkungen nonverbalen Verhaltens
und deren experimentelle Untersuchung mittels
Computeranimation, Lengerich: Pabst (2001).
[6] Krämer N. C. & Bente G., Virtuelle Helfer:
Embodied Conversational Agents in der
Mensch-Computer-Interaktion, In G. Bente, N.
C. Krämer & A. Petersen (Hrsg.), Virtuelle
15
Krämer, N. C.
Realitäten (S. 203-225), Göttingen: Hogrefe
(2002).
Computers in Human Behavior, 15, 123-142
(1999).
[7] Krämer N. C., Bente G. & Piesk J., The ghost in
the machine. The influence of Embodied
Conversational Agents on user expectations and
user behaviour in a TV/VCR application. In G.
Bieber & T. Kirste (Eds.), IMC Workshop 2003,
Assistance, Mobility, Applications, (2003).
[12] Rickenberg R. & Reeves B., The effects of
animated characters on anxiety, task
performance, and evaluations of user interfaces.
Letters of CHI 2000, April 2000, 49-56 (2000).
[8] Krämer N. C. & Nitschke J.,
Ausgabemodalitäten im Vergleich: Verändern
sie das Eingabeverhalten der Benutzer? In R.
Marzi, V. Karavezyris, H.-H. Erbe & K.-P. Timpe
(Hrsg.), Bedienen und Verstehen. 4. Berliner
Werkstatt Mensch-Maschine-Systeme (S. 231248), Düsseldorf: VDI-Verlag (2002).
[9] Leary M. R., Self presentation. Impression
management and interpersonal behavior.
Madison, Wis.: Brown & Benchmark Publishers
(1995).
[10] Lester J. C., Towns S. G., Callaway C. B.,
Voerman J. L. & FitzGerald P. J. Deictic and
emotive communication in animated
pedagogical agents. In J. Cassell, J. Sullivan, S.
Prevost & E. Churchill (Eds.), Embodied
Conversational agents (pp. 123-154). Boston:
MIT Press (2000).
[13] Sproull L., Subramani M., Kiesler S. Walker J.
H. & Waters K., When the interface is a face,
Human Computer Interaction, 11 (2), 97-124
(1996).
[14] Takeuchi A. & Naito T., Situated facial displays:
towards social interaction. In I. Katz, R. Mack, L.
Marks, M. B. Rosson & J. Nielsen (Eds.), Human
factors in computing Systems: CHI´95
Conference Proceedings (pp. 450-455), New
York: ACM Press (1995).
[15] Walker J. H., Sproull L. & Subramani R. Using a
Human Face in an Interface. In B. Adelson, S.
Dumais & J. Olson (Eds.), Human Factors in
Computing Systems: CHI´94 Conference
Proceedings (pp. 85-91), Boston: ACM (1994).
[16] Zajonc R. B., Social facilitation. Science, 149,
269-274 (1965).
[11] Parise S., Kiesler S., Sproull L. & Waters K.,
Cooperating with life-like interface agents,
16
Mehr als Look und Feel: Virtuelle Helfer
Referentin
Dr. Nicole Krämer ist Diplom-Psychologin und seit 1998 wissenschaftliche
Mitarbeiterin der Abteilung Differentielle Psychologie und Kommunikationsforschung
der Universität zu Köln.
Zu ihren Forschungsschwerpunkten zählen vor allem Mensch-Computer-Interaktion,
nonverbale Kommunikation sowie Kommunikationsstrukturen in Organisationen. Ihre
Lehrtätigkeit umfasst Sozialpsychologie, Differentielle Psychologie sowie Medien- und
Organisationspsychologie.
17
DER WEG ZU EINER STÄRKEREN
VERZAHNUNG VON USABILITY ENGINEERING
UND SOFTWARE ENGINEERING
DER WEG ZU EINER STÄRKEREN VERZAHNUNG VON USABILITY
ENGINEERING UND SOFTWARE ENGINEERING
Kirstin Kohler
Fraunhofer IESE
Sauerwiesen 6
D-67661 Kaiserslautern
kohler@iese.fhg.de
www.iese.fhg.de
Frank Leidermann
Bluewin AG
Hardturmstrasse 3
CH-8037 Zürich
frank.leidermann@team.bluewin.com
www.bluewinag.com
ABSTRACT
Dieser Artikel beschreibt Herausforderungen und
Lösungsansätze für das Zusammenwirken von
Usability Engineering (UE) und Software Engineering
(SE) in der Praxis industrieller Software-Projekte.
Die Praktiken sowohl des UE als auch des SE
müssen in viele Projekte noch stärker eingebracht
werden. Dazu müssen UE- und SE-Methoden
besser miteinander verbunden werden und auch im
Praxisumfeld weiter reifen.
Keywords
Usability-Engineering, Software-Engineering
1. EINLEITUNG
Die steigende Bedeutung von Usability für Software
Produkte, die mit hohem Zeitdruck und unter
Berücksichtigung anderer Qualitätsaspekte, wie zum
Beispiel Sicherheit und Zuverlässigkeit entwickelt
werden, erfordert die Anwendung von Usability
Engineering (UE) und Software Engineering (SE).
Doch trotz der Notwendigkeit, Methoden beider
Disziplinen im Entwicklungszyklus von SoftwareProjekten einzusetzen, existieren gravierende
Hindernisse. Ungenügend definierte Schnittstellen
zwischen Aktivitäten beider Disziplinen führen zu
Problemen, die sowohl den Entwicklungszyklus als
auch die Qualität der Software negativ beeinflussen.
Rollen wie die des Usability-Ingenieurs müssen auf
die anderen Rollen und Aufgabenfelder eines
Projektes abgestimmt werden. Terminologieprobleme müssen aufgedeckt und geklärt werden.
Das folgende Kapitel gibt einen Überblick über die
Herausforderungen bei der weiteren Etablierung von
Es ist erlaubt digitale und Kopien in Papierform des ganzen
Papers oder Teilen davon für den persönlichen Gebrauch oder zur
Stuttgart).
Proceedings of the
Andreas Birk
sd&m AG
Löffelstraße 46
D-70597 Stuttgart
andreas.birk@sdm.de
www.sdm.de
UE und SE in der Praxis von Software-Projekten.
Kapitel 3 stellt dem Lösungsansätze und Empfehlungen gegenüber.
2. HERAUSFORDERUNGEN
2.1 Terminologie
Terminologieprobleme sind auf den ersten Blick
leicht überbrückbar. Im Alltag des Projektgeschäftes
können sie aber große Missverständnisse und
Schwierigkeiten bereiten. Daher ist es wichtig,
mögliche Terminologieprobleme zu kennen und
darauf vorbereitet zu sein.
UE und SE haben sich weitgehend unabhängig von
einander
entwickelt
und
weisen
somit
Terminologiekonflikte auf. Auch innerhalb jeder
einzelnen Disziplin gibt es Terminologieprobleme,
die sich noch verstärken können, sobald sie auf
andersartige
firmenspezifische
Terminologien
treffen. Beispiele für unterschiedlich belegte Begriffe
sind: Design, Usability, Test, Nutzer, Interface,
Prototyp.
2.2 Konstruktive Methoden
Konstruktive Methoden des UE und des SE sind
jene, die primär gestaltenden Einfluss auf ein
Software-System nehmen. Beispiele aus dem
Bereich des UE sind Card Sorting, Storyboarding,
Prototyping. Beispiele aus dem Bereich des SE sind
Methoden zum Anforderungsmanagement (z.B.
Volere), die Vielzahl objektorientierter Verfahren
(z.B. Rational Unified Process, Catalysis, CRC
Cards) und die verschiedenen Programmiertechniken (z.B. die Benutzung von ProgrammierMustern und –Idiomen, die Konzepte des TestDriven Programming und Pairwise Programming im
Extreme Programming (XP) sowie Aspect-Oriented
Programming).
Die besondere Herausforderung bei der Integration
von konstruktiven UE- und SE-Methoden ist, dass es
sich bei diesen Methoden oft um in sich
geschlossene Vorgehensweisen handelt. Zur
Integration von Methoden müssen Teile von ihnen
eng aufeinander abgestimmt werden. Nicht selten ist
dies recht aufwändig und führt letztlich zu einer
neuen eigenständigen Methode.
21
Kohler, K., Leidermann, F. & Birk, A.
Auch die Übertragung der Methoden in die
Projektpraxis ist oft nicht trivial. Viele Methoden sind
noch nicht umfassend in der Praxis erprobt. Ihr
Einsatz erfordert weitere Anpassungen und
Nachbesserungen während des Projektablaufes.
Exemplarisch werden im Folgenden einige konkrete
Herausforderungen beim Zusammenwirken von UEund SE-Methoden skizziert:
Es existieren keine ganzheitlichen Erhebungsmethoden, die es ermöglichen ein vollständiges Bild
aller für ein Produkt relevanten nichtfunktionalen
Anforderungen zu erlangen. Im UE werden zu
Projektbeginn Usability-Ziele definiert, während SEMethoden in den frühen Phasen vorwiegend
Anforderungen wie Zuverlässigkeit, Wartbarkeit und
Portierbarkeit erheben. Die integrative Betrachtung
der nichtfunktionalen Anforderungen (d.h. Usability
und alle anderen) ist notwendig, um Abhängigkeiten
und Konflikte rechtzeitig zu erkennen und zu lösen.
So werden in der Praxis vielfach Entscheidungen zu
User-Interface-Technologien
getroffen
werden,
bevor die nicht-funktionalen Systemanforderungen
geklärt sind .
Des
weiteren
existieren
keine
definierten
Schnittstellen zwischen UE- und SE-Aktivitäten. So
ist zum Beispiel oft unklar, wie AufgabenBeschreibungen
einer
UE-Aufgabenanalyse
zielgerichtet in ein objektorientiertes Design
überführt werden können. Ebenso gibt es noch kein
weithin anerkanntes Vorgehen, welches die
Übergabe von Artefakten zwischen User-InterfaceDesignern
und
User-Interface-Entwicklern
unterstützt, in dem es definiert, welche Information
in welcher Notation zur Spezifikation eines
graphischen User Interfaces übergeben sollte.
2.3 Evaluationsmethoden
Evaluationsmethoden
überprüfen
die
bereits
vorliegenden Artefakte der Software-Entwicklung,
sei es durch Verifizierung (Überprüfung gegenüber
Vorgaben anderer Artefakte) oder durch Validierung
(Überprüfung gegenüber den Erwartungen von
Auftraggebern oder Benutzern). Beispiele im UE
sind Heuristic Evaluation, Cognitive Walkthrough
oder Usability Testing. Beispiele im SE sind
Inspektionsmethoden und die Testverfahren wie
Akzeptanztest, Regressiontests und Unittest.
Evaluationsmethoden
besitzen
oft
geringere
Komplexität als konstruktive Methoden. Sie lassen
sich somit einfacher miteinander kombinieren und
auch leichter in einen gegebenen Projektkontext
einfügen.
Die Herausforderungen liegen hier vor allem darin,
die Einsetzbarkeit und Effizienz der Methoden zu
steigern. Das betrifft sowohl die Abstimmung
evaluativer
SE- und UE-Maßnahmen (bspw.
zwischen Funktions- und Usabilitytests), als auch die
Abstimmung
zwischen
konstruktiven
und
evaluativen UE- und SE-Maßnahmen aus UE und
22
SE
(bspw.
zwischen
Komponentendesign).
Usabilitytesting
und
2.4 Werkzeugunterstützung
Die
wesentliche
Herausforderung
für
die
Werkzeugunterstützung von UE und SE ist die
Integration der verschiedenen Werkzeuge und die
Schaffung
durchgängiger,
unterbrechungsfreier
Toolketten. Während hier im SE zuletzt große
Fortschritte gemacht worden sind, bleiben UEAspekte noch weitgehend ausgespart. So wäre
beispielsweise
die
Integration
von
Prototypwerkzeugen und GUI-Buildern (CodeGeneratoren) wünschenswert.
2.5 Organisatorische Aspekte
Die Herausforderungen bei der Projektorganisation
bestehen vor allem darin, die Belange von UE und
SE zu integrieren. Industrielle Projekte orientieren
sich vorwiegend an SE-Erfordernissen, während
organisatorische Aspekte des UE nicht wirklich
berücksichtigt
werden.
Dies
umfasst
z.B.
Rollenmodelle und Zuständigkeitsregelungen sowie
die Gestaltung von Kommunikationsmaßnahmen
(Regelkommunikation, Ermöglichung informeller
Kommunikation, Eskalationswege, etc.).
So sind Prozessverbesserungen im Bereich UE in
SE-gesteuerten Unternehmen deshalb schwer
einzuführen,
da die Ziele der
einzelnen
Organisationseinheiten
kontraproduktiv
wirken.
Sollen durch Verbesserungen im UE Supportkosten
gesenkt werden, so lastet die dadurch entstehende
Mehrarbeit auf der Entwicklungsabteilung. Diese
wird allerdings nicht anhand der Anzahl der
Supportcalls bewertet, sondern deren Erfolg wird
durch die Geschwindigkeit der Umsetzung von
Funktionalität bestimmt [1].
Weitere Herausforderungen entstehen in der
operativen Zusammenarbeit von UE und SEIngenieuren sowie Designer. Infolge der ungeklärten
Schnittstellen zwischen Aktivitäten des UE and SE
(siehe dazu Abschnitt 2.1). kommt es in der Praxis
immer wieder zu Missverständnissen bzgl. den
Verantwortlichkeiten, bspw. zwischen AnforderungsIngenieur und Usability-Ingenieur.
An der Schnittstelle zwischen Aktivitäten des UE
und SE treffen häufig verschiedene Disziplinen
aufeinander. So sind im UE vorwiegend
Psychologen und Designer tätig, während sich mit
SE Ingenieure und Informatiker beschäftigen. Dies
führt nicht selten zu Konflikten, Kommunikationsproblemen und beiderseitigem Unverständnis.
Bedingt durch die personelle Situation übernehmen
Software Ingenieure in der betrieblichen Praxis
häufig Aufgaben, die traditionell dem UE zugeordnet
sind (z.B. User Interface Design), ohne jedoch die
Grundlagen dafür erlernt zu haben [2]. Dem
gegenüber steht die fehlende SE-Vorbildung vieler
Usability Ingenieure im Bezug auf Implementierung.
Vorschläge von User Interface Designern sind unter
Umständen schwer oder gar nicht in lauffähige
Software umzusetzen, da den Usability-Spezialisten
das technische Verständnis fehlt, wodurch sich
zeitraubende Iterationen ergeben.
Die Einbindung von Benutzern in den SoftwareEntwicklungzyklus wird in vielen SE-Verfahren
wenig beachtet. Demgegenüber legen UE-Methoden
großen Wert auf Benutzereinbindung. Sie kümmern
sich aber wenig darum, dass Benutzer in der Praxis
oft nur schwer verfügbar und zugänglich sind und
dass die Benutzereinbindung die Anforderungen an
die Projektplanung stark erhöht.
3. LÖSUNGSANSÄTZE
3.1 Methoden und Werkzeuge
Auf dem Gebiet der Objekt Orientierten Methoden
sind zunehmend Bemühungen zu erkennen, die
Lücke zwischen HCI und SE durch entsprechende
Vorgehensmodelle und Notationen zu schließen
[3],[4],[5]. Ein Beispiel sind technologie-unabhängige
„Essential Use Cases“ die als methodische
Ergänzung zu den aus der Objektorientierung
bekannten konkreten Use Cases entwickelt wurden
[6].
User
Interaction
Patterns
stellen
einen
vielversprechenden Ansatz dar, um den Übergang
von Usability Anforderungen in geeignete Software
Architekturen zu unterstützen. Im Esprit Projekt
Status wurde eine Zuordnung von Usability Zielen
zu User Interaction Patterns erarbeitet [7][8].
In anderen Ansätzen aus Praxis und Forschung
wurden Vorgehen erarbeitet, die die ganzheitliche
Spezifikation von User Interface Anforderungen und
Funktionalen Anforderungen unterstützen, in dem
sie die zu beschreibenden Elemente, Notationen
und Abhängigkeiten zwischen den verschiedenen
Typen von Anforderungen vorgeben. Allerdings sind
diese Ansätze in der industriellen Praxis bisher noch
weitgehend unbekannt [9][10].
3.2 Organisatorische Aspekte
Im Gegensatz zum SE ist das UE im industriellen
Bereich selten systematisch und durchgängig in die
Organisation eingebettet. Für eine organisatorische
Integration von SE und UE ist diese (auch als
„Strategic Usability“ [11] [12] bezeichnete)
Einbettung die Grundvoraussetzung.
kontinuierlichen Pflege muss ein besonderes
Augenmerk auf die Integration der beiden
Kompetenzbereiche SE und UE gelegt werden.
Mittel für Kompetenzaufbau und –pflege sind klare
Kompetenzprofile für die verschiedenen Rollen,
angemessene
Schulungsund
Ausbildungsprogramme, Unterstützung für Training-on-the-Job,
sowie vielfältige Wissensmanagement-Maßnahmen.
Das Zusammenspiel von UE und SE in der
Projektpraxis lässt sich nicht durch kurze einmalige
Maßnahmen erreichen. Vielmehr sind eine
schrittweise Einführung und der kontinuierliche
Ausbau von UE- und SE-Praktiken erforderlich.
Diese kontinuierlichen Prozesse sind dauerhaft im
Projekt oder der Organisation zu etablieren. Diese
Aufgabe
korrespondiert
teilweise
mit
der
kontinuierlichen Kompetenzpflege, geht aber auch
darüber hinaus. Fragestellungen dieser Art werden
im SE als kontinuierliche Prozessverbesserung
behandelt [15].
Einen sehr umfassenden Ansatz stellt die ISO 18529
dar, die ein UE-Prozessmodell beschreibt, dessen
organisatorische Reife durch die in der SE-Welt zu
verortenden Verfahren der ISO 15504 gemessen
werden soll.
4. ZUSAMMENFASSUNG
Die Herausforderungen an der Schnittstelle
zwischen UE und SE sind vielfältig und bei weitem
noch nicht vollständig verstanden oder gelöst. Der
Workshop soll dazu beitragen diese Problematik vor
allem aus dem Blickwinkel des Usability Engineering
tiefer zu beleuchten und zu ergänzen, um
aufbauend darauf Verbesserungspotential zu
identifizieren und Synergien zwischen beiden
Disziplinen zu fördern, die sowohl zur Zufriedenheit
der Endkunden als auch der Designer und
Entwickler (UE und SE) beitragen.
5. REFERENCES
[1] McCoy, T., Letter from the Dark Side:
Confessions of an Application Developer,
interactions, 9, November 2002
[2] Maguire, M.C. and Graham, R., "A Survey of
Usability Practice and Needs in Europe",
Hanson, M.A. (Hrsg.), Contemporary
Ergonomics, Taylor & Francis, 1998
Diese setzt wiederum in vielen Fällen voraus, dass
auf Ebene der Unternehmenskultur gegen UE
(„Usability Myths“ [13]) abgebaut werden. Als
Leitsätze für Usability-Ingenieure können dabei
dienen: „Be an engineer, not an artist.“; „Cast
yourself as an ally, not an enemy“ [14]. Aber auch
die Zusammenstellung interdisziplinärer Teams im
User Interface Design und Development oder
gegenseitige Schulungen sind hier Lösungsansätze.
[3] Constantine, L.L., and Lockwood, L.A.D.,
Software for Use: A Practical Guide to the
Models and Methods of Usage Centered design,
Addision-Wesley, 1999
Bei dem in industriellen Umfeldern dringend
erforderlichen Aufbau von Kompetenzen und deren
[6] Constantine, L.L., and Lockwood, L.A.D.,
Structure and Style in Use Cases for User
[4] Paterno, F., Towards a UML for Interactive
Systems, Proceedings of EHCI2001, May 2001,
Springer
[5] Van Harmelan, M., Object Modeling and User
Interface Design, Addision-Wesley, 1999
23
Kohler, K., Leidermann, F. & Birk, A.
Interface Design, in: Van Harmelen, M. (Hrsg.),
Object-Modeling and User Interface Design,
Addison-Wesley, 1999
[11] Rosenbaum, S. et al., A Toolkit for Strategic
Usability: Results from Workshops, Panels, and
Surveys, Proceedings of CHI 2000
[7] STATUS, Software Architecture that supports
Usability, Esprit Project,
http://www.ls.fi.upm.es/status/index.html
[12] Rosenbaum, S. et al., Usability in Practice: User
Experience Lifecycle – Evolution and
Revolution, Proceedings of CHI 2002
[8] Juristo, N., Lopez, M., Moreno A., Sanchez, I.;
Improving software usability through
architectural patterns, Proceedings of the ICSE
Workshop Bridging the Gap Between Software
Engineering and Human-Computer Interaction,
May 2003
[13] Knight, J., Jefsioutine, M., Relating Usability to
Design Practice, European Usability
Professionals Association Conference, eupa’02,
London, 2002
[9] Paech, B., Kohler, K., Task Driven
Requirements in Object-oriented development,
in Perspectives on Requirements Engineering,
Kluwer Academic Publishers, to appear
[10] Lauesen, S., Task Descriptions as Functional
Requirements, IEEE Software, März/April 2003
24
[14] Mayhew, D. : Strategic Development of the
Usability Engineering Function, interactions,
september+october 1999
[15] Birk, A., Rombach, D. A Practical Approach to
Continuous Improvement in Software
Engineering, in: Meyerhoff, D.B., Wieczorek,
M.J. (Hrsg.), Software Quality – State of the Art
in Management, Testing, and Tools, Springer,
Berlin, 2000
Referenten
Kirstin Kohler leitet die Gruppe Usability Engineering am Fraunhofer Institut für
Experimentelles Software Engineering (Fh IESE) in Kaiserslautern. Zuvor war sie
mehrere Jahre für Hewlett-Packard im Bereich User-Interface Entwicklung und
Einführung von User-Centered-Design Prozessen tätig. Ihr Interessensschwerpunkt liegt
in der Integration von Software Engineering und Usability Engineering Methoden. Sie hat
Informatik mit Nebenfach Wirtschaftswissenschaften (Dipl. Inform.) und Biologie (Dipl.
Biol.) studiert.
Frank Leidermann ist seit April 2003 als Usability Consultant beim Internet Service
Provider Bluewin AG in Zürich tätig. Zuvor war er fünf Jahre am Institut für Technologie
und Arbeit (ITA) Kaiserslautern beschäftigt (Schwerpunkte: Usability-Engineering,
WebAccessibility und Design for All), unterbrochen von einem sechsmonatigen
Gastaufenthalt in der Arbeitsgruppe für Human-Computer Interaction and Assistive
Technologies (ICS-FORTH).
Andreas Birk ist Berater und Projektleiter bei der sd&m AG, software design &
management, in Stuttgart. Seit 1993 beschäftigt er sich intensiv mit Themen des
Software-Engineering, zunächst als Berater und in der angewandten Forschung. Er hat
Informatik mit Nebenfach Wirtschaftswissenschaften (Dipl.-Inform.) in Kaiserslautern
studiert und ist im Bereich Software Engineering promoviert (Dr.-Ing.).
25
USABILITY PROFESSIONALS UND
REQUIREMENTS ENGINEERING
USABILITY PROFESSIONALS UND REQUIREMENTS ENGINEERING
ERFAHRUNGEN UND TRENDS
Astrid Beck
GUI Design
Offenbachstr. 18-20
70195 Stuttgart
Astrid_Beck@gui-design.de
http://www.gui-design.de
ABSTRACT
Usability und Requirements Engineering sind als
gleichrangige Aspekte im Softwareentwicklungsprozess zu berücksichtigen. Dieser Beitrag formuliert
Anforderungen und Anregungen zur Umsetzung. Der
Beitrag ist Motivation und Einführung zum
gleichnamigen Workshop auf der Veranstaltung des
GC-UPA 2003.
Keywords
Usability, Usability Professionals, Requirements
Engineering, Anforderungsermittlung, SW-Entwicklungsprozess
1. EINLEITUNG
Einer meiner ersten Aufträge bestand darin, einen
Style Guide für die Entwickler eines anspruchsvollen
Entwicklungsprojekts zu erstellen. Ich arbeitete also
einen Style Guide aus, erstellte dazu viele
erläuternde Beispiele aus dem Projekt und
berücksichtigte
die
gängigen
Normen,
programmierte eine Online-Hilfe und führte
Workshops und Seminare zur Einführung durch.
Teile des Style Guides konnten als fester
Bestandteil des Fachtests etabliert werden.
Doch der Style Guide wurde quasi nicht angewandt,
die Benutzungsoberflächen wurden größtenteils
genauso von den Entwicklern weiterentwickelt, wie
sie es schon immer gewohnt waren – nämlich nach
eigenem Wissen und Geschmack. Entsprechend
inkonsistent sahen die Anwendungskomponenten
aus. Was lief hier falsch?
Meine Erkenntnisse möchte ich im folgenden vorstellen und sie sollen gleichzeitig den Austausch mit
Usability Professionals anregen.
Es hat sich als nützlich erwiesen, in SoftwareEs ist erlaubt digitale und Kopien in Papierform des ganzen Papers
Stuttgart).
Proceedings of the
Entwicklungsprojekten – wenn nötig auch wiederholt
– folgende Aspekte zu diskutieren und im Projekt
transparent und verbindlich zu regeln:
Usability ist im
SW-Entwicklungsprozess zu etablieren
Usability ist Teil des Requirements Engineering
Usabilityarbeit ist Teamwork
Usability ist Chefsache
Die Rolle des Usability Professionals:
Screen Visagist oder Usability Consultant?
Im folgenden
erläutert.
werden diese Aspekte genauer
2. USABILITY IST IM SWENTWICKLUNGSPROZESS ZU ETABLIEREN
Wie das einführende Beispiel zeigt, ist es nicht
damit getan, einen Style Guide für das Projekt zu
erstellen und dann zu hoffen, dass die Anwendung
von nun an benutzerfreundlicher wird.
Usability ist nicht bloß durch einen Style Guide zu
bewerkstelligen, genau so wenig wie beispielsweise
die Einführung eines Testtools den SW-Test
verbessert oder ein QM-Handbuch die Qualität
sicherstellen kann.
Usability – also eine bestens zufriedenstellende
Benutzbarkeit eines Produkts – ist nicht durch
Regelwerke oder einmaliges Handeln sicherzustellenden. Usability ist auch kein Selbstläufer, der
einmal
angestoßen
sich
wunschgemäß
manifestieren wird. Im Gegenteil – Usability kann
erst durch konsequente, wiederkehrende Prozesse
etabliert werden.
Usability ist ein notwendiger Teil des SoftwareEntwicklungsprozesses. Dieser These werden sicher
viele Usability Professionals zustimmen, im Projektalltag hat sie sich aber noch nicht überall durchgesetzt. Daher muss ständig daran gearbeitet
werden
Projektverantwortliche,
Teamleiter,
Chefentwickler davon zu überzeugen, dass der
Usability im Projekt mehr Bedeutung und Zeit
beizumessen ist.
29
Beck, A.
Dabei
ist
Usability
im
gesamten
Softwarelebenszyklus Aufmerksamkeit zu schenken.
Die benötigten Usability-Prozesse und -methoden
müssen im
Projektvorgehensmodell etabliert
werden, dabei können als Anhaltspunkte die DIN EN
ISO 13407 [2] sowie die ISO/TR 18529 [8] dienen.
Gleichzeitig sorgen auf Usability zielende Aktivitäten
und Meilensteine, die auch Eingang in den
Projektplan
finden,
für
Transparenz
und
Messbarkeit.
Usability stellt ein Qualitätsmerkmal dar, und ist im
Projekt mit konstruktiven und analytischen Qualitätsmanagementverfahren sicherzustellen. Damit ist das
Software-Qualitätsmanagement angesprochen und
aufgefordert, mehr für Usability im Projekt und im
Unternehmen zu tun.
Hartwig plädiert für ein Prozessmodell, das einen
iterativen, nutzerzentrierten Ansatz verfolgt. Dabei
werden die Anforderungen konsequent aus dem
Nutzungskontext begründet und zu konkreten,
testbaren Kriterien verfeinert [6].
Bevan und Bogomolni [1] empfehlen die folgenden
zehn Methoden in den Softwareentwicklungsprozess
(Planung, Analyse, Design und Test) aufzunehmen.
Sie betonen, dass keine kostenintensiven Tools
benötigt werden und die Einarbeitungsaufwand sich
in Grenzen hält.
1. Stakeholder meeting
identify and agree on the role of usability, broadly
identifying the intended context of use and usability
goals, and how these relate to the business
objectives and success criteria for the system
2. Context of use
collect and agree detailed information about the
intended users, their tasks, and the technical and
environmental constraints
3. Scenarios of use
document examples of how users are expected
carry out key tasks in a specified contexts, to provide
an input to design and a basis for subsequent
usability testing
4. Evaluate an existing system
evaluate an earlier version or competitor system to
identify usability problems and obtain measures of
usability as an input to usability requirements
5. Usability requirements
establish usability requirements for the user groups
and tasks identified in the context of use analysis
and in the scenarios.
6. Paper prototyping
evaluation by users of quick low fidelity prototypes
(using paper or other materials) to clarify
requirements and enable draft interaction designs
30
and screen designs to be rapidly simulated and
tested.
7. Style guide
identify, document and adhere to industry, corporate
or project conventions for screen and page design
8. Evaluation of machine prototypes
informal usability testing with 3-5 representative
users carrying out key tasks to provide rapid
feedback on the usability of prototypes
9. Usability testing
formal usability testing with 8 representatives of a
user group carrying out key tasks to identify any
remaining usability problems and evaluate whether
usability objectives have been achieved
10. Collect feedback from users
collect information from sources such as usability
surveys, help lines and support services to identify
any problems that should be fixed in future versions
Bei SAP verwenden Hatscher und Böringer [7] ganz
ähnlich eine Mischung von Contextual Design, Goaldirect™ Design und Szenario-basiertem Design
unter Mitwirkung der Kunden sowie frühzeitigem
Prototyping.
Auch Strauss [10] betont die Notwendigkeit von
Prototyping. Dabei hat er gute Erfahrungen vor
allem mit “low fidelity prototypes”, also Prototypen
mit wenig aufwendigem Technikeinsatz gemacht.
Darunter versteht man Papierprototypen, die
manuell oder mit Grafikwerkzeugen erstellt werden.
Es wird aber empfohlen, auf die Verwendung von
GUI Buildern nicht zu verzichten, damit auch die
technische
Machbarkeit,
insbesondere
die
Bildschirmdarstellung und -auflösung beurteilt
werden kann.
Bevan und Bogomolni [1] nutzen in ihrem Projektbeispiel Papierprototypen bereits während der
Aufgabenanalyse. Benutzerfunktionen wurden mit
Post-It-Notes ermittelt und gruppiert.
Meiner Erfahrung nach sind es gerade die weniger
techniklastigen Methoden, die bei Fachvertretern
wie Softwareentwicklern gleichermaßen erfolgreich
sind.
3. USABILITY IST TEIL DES
REQUIREMENTS ENGINEERING
Erst die umfassende Kenntnis der zukünftigen
Anwender und deren Aufgaben stellt sicher, dass
das Projektkonzept für die Usability auf einer soliden
Basis aufsetzen kann. Aus Sicht der Usability ist die
Nutzung der späteren Produkts während der Anforderungsermittlung zu analysieren. Auf dieser Basis
lassen sich dann weitere Maßnahmen wie z.B. Style
Guides, Usability Tests, Benutzerzirkel erfolgreich
definieren und durchführen. Neuere Ansätze des
Requirements Engineering (z.B. [11]) sehen neben
Usability Professionals und Requirements-Engineering
funktionalen Anforderungen auch Benutzerfreundlichkeit und Anwenderanforderungen vor, aber es
wird offen gelassen, wie diese zu erreichen sind und
wer dies mit welchen Mitteln im Projekt dann
letztendlich analysieren, entwickeln und umsetzen
soll (und kann).
Usability Professionals, Software Ergonomen, Psychologen sind eher die Mahner und Besserwisser,
seltener die Bessermacher. Sie wissen noch immer
zu wenig vom Alltag der Softwareentwickler und
agieren oftmals isoliert und nicht als Projektmitglied.
Systemanalytiker, Anforderungsermittler, Spezifikationsersteller – also jene, die Analyse durchführen
und die Fachspezifikationen und Pflichtenhefte
erstellen – werden unter Zeitdruck mit unvollständiger Dokumentation und widersprüchlichen
Aussagen
der
Fachvertreter
konfrontiert.
Zusätzlichen Anforderungen aus Usabilitysicht wird
entsprechend mit Skepsis begegnet. So hängt es
stark von der “Einsicht” der Projektverantwortlichen
ab, ob man sich mit Usability und deren
Anforderungen beschäftigen “darf”.
Projekt- oder sogar unternehmensweite Vorgaben
können hier die Lösung sein, die in einheitlicher
Weise festschreiben, wie Benutzeranforderungen im
Rahmen der Anforderungsermittlung zu erheben und
zu integrieren sind. Dazu gehört auch, die Rolle des
Usabilitymitarbeiters so zu formulieren, dass dieser
gleichberechtigtes Projektmitglied ist und entsprechende Aufgaben übernimmt wie z.B. Analyse,
Qualitätsmanagement, Test und Evaluation (es gäbe
hier noch viel aufzuzählen) und im Rahmen dieser
Tätigkeit Usability umsetzt.
Ein stärkeres Augenmerk auf Requirements
Engineering insgesamt zu legen, dafür plädiert
Fahney in seinem Beitrag [5], da “professioneller
Umgang mit Anforderungen ein Drittel bis die Hälfte
des Erfolgs von erfolgreichen IT-Projekten
ausmacht”, Anforderungsmanagement in Projekten
aber noch zu unprofessionell betrieben werde.
Kürzere Produktionslebenszyklen führen zu ständig
neuen
Anforderungen
(s.a.
Projektbeispiel,
dargestellt in [5]). Dementsprechend sind die
bezüglich Usability ermittelten Anforderungen nicht
fix sondern ebenso einem Change-Request-Prozess
zu unterwerfen. Daraus wiederum ergibt sich ein
Bedarf
nach
kontinuierlichem
Anforderungsmanagement, permanenter Zusammenarbeit mit
Kunde
und
Benutzern,
sowie
ständigem
Aktualisieren von Dialogoberflächen, Style Guides,
Testfällen etc. (s.a. [6]).
4. USABILITYARBEIT IST TEAMWORK
Den eben geschilderten Problemen ist frühzeitig
durch Rollenbeschreibungen zu begegnen. In der
Sprache des Projekts ist festzulegen, wer
Anforderungen ermittelt, festschreibt und freigibt und
wie deren Änderungsprozess definiert ist. Bevan und
Bogomolni [1] schlagen vor, dies in einem
Stakeholder meeting (s.a. Abschnitt 2) zu erarbeiten.
Benutzeranforderungen sind – beispielsweise auf
Grundlage der DIN EN ISO 9241-10 – zu erheben
und in die Spezifikation mit aufzunehmen.
Anforderungen der verschiedenen Interessengruppen sind nicht unumstößlich, sondern ein Aushandlungsprozess. Was Usability im Projekt bedeutet, ist mit allen Teammitgliedern gemeinsam zu erarbeiten. Dies ist in der Projektdokumentation (z.B.
Usability Spezifikation, Style Guide, QM- oder PMHandbuch, Projektakte, Fachspezifikation) festzuhalten.
In dem eingangs angesprochenen Projekt (wie auch
in vielen späteren Projekten) habe ich zusammen
mit engagierten Entwicklern sowie Mitarbeitern der
Fachseite, einem Trainer und einem Mitarbeiter des
Benutzerservice ein ”Style-Guide-Team” gebildet, in
dem der Style Guide kritisch überarbeitet und verabschiedet wurde. Regelmäßige Treffen stellten sicher,
dass aktuelle Fragestellungen mit Lösungen erarbeitet und in den Style Guide aufgenommen wurden.
Die Akzeptanz des so erarbeiteten Style Guides war
drastisch verbessert worden.
Um Style-Guide-Konformität auch praktisch sicherzustellen, wurden Framework-Komponenten entwickelt, die von nun an verpflichtend zu verwenden
waren.
Ein Style Guide ist folglich nicht als Quantensprung
anzusehen, sondern ein kontinuierlicher, partizipativer und iterativer, kritischer Prozess.
Benutzerbeteiligung (“User Involvement”) ist der
wichtigste Erfolgsfaktor in der Softwareentwicklung
[4, 9]. Strauss [10] beschreibt beispielsweise User
Boards, die sich in Entwicklungsprojekten als höchst
sinnvoll und praktikabel erwiesen haben. In diesen
User Boards, die sich aus Mitarbeitern des Projektteams inklusive Kunden und Benutzern zusammensetzen, werden Dialogentwürfe konstruktiv durchgespielt und bearbeitet. Gearbeitet wird dabei mit
Papierausdrucken, Overhead-Folien und Post-Its.
5. USABILITY IST CHEFSACHE
Wie
man
bereits
vom
Qualitätsund
Projektmanagement weiß, lassen sich unbeliebte
und scheinbar erst mal nur Arbeit erzeugende
Tätigkeiten nur dann erfolgreich im Projekt
einsetzen, wenn sie auch vom Management
konsequent gewollt und verfolgt werden. Aufgabe
des Managements ist es, Usability zu würdigen und
die Forderung nach Usability bei den Entwicklern
durchzusetzen. Ein gemeinsames Verständnis zu
Usability ermöglicht allen Beteiligten zu erkennen,
welchen Nutzen Usability neben einer guten
Funktionalität für das Produkt, die Anwender und
das Unternehmen bringt.
“Wir wollen eine benutzungsfreundliche Software”
lässt sich als Anspruch erst dann durchsetzen, wenn
entsprechende Ressourcen im Projekt vorgesehen
31
Beck, A.
werden, wenn beispielsweise Usability Tests nicht
als Luxus und zu kostspielig abgetan werden und
wenn der Projektleiter auch bei Zeit- und
Budgetdruck hinter den ursprünglich geplanten
Maßnahmen steht und diese regelmäßig auf der
Agenda hat.
6. DIE ROLLE DES USABILITY
PROFESSIONALS: SCREEN VISAGIST
ODER USABILITY CONSULTANT?
Die dargestellten Aspekte legen nahe, dass ein
Usability Professional mehr können und sein muss
als ein Screen Visagist.
Der Usability Consultant ist im Requirements
Engineering genauso zu Hause wie in der Softwareergonomie, er hat umfassende Kenntnisse von
Qualitäts- und Projektmanagement, er kann
programmieren sowie präsentieren und Schulungen
durchführen. Er berät User gleichermaßen wie
Entwickler und das Management. Hilfreich sind
Kenntnisse
von
Softwarearchitekturen
(z.B.
Komponentenbasierte Technologien, Corba, XML,
Webservices). Er (oder sie) hat weitreichende
soziale Kompetenzen, um mit unterschiedlichen
Charakteren und Projektbeteiligten konstruktiv
agieren zu können. Hilfreich sind natürlich auch
Fach- und Branchenkenntnisse. Kurz gesagt: es ist
ein Berater gefragt, der zu den Fragen des
Software-Entwicklungsprozesses Stellung beziehen
und Lösungen anbieten kann.
Usability lässt sich dann am erfolgreichsten
umsetzen, wenn z.B. die Bewertung einer
Benutzungsoberfläche oder die Entwicklung eines
Style Guides Teil von projektbegleitenden und übergreifenden Usability-Maßnahmen sind.
7. REFERENZEN
[1] Nigel Bevan, Itzhak Bogomolni: Incorporating
user quality requirements in the software
development process, 4th International Software
Quality Week Europe (Qwe2000)
http://www.soft.com/QualWeek/QWE2K/Papers.
pdf/Bevan.pdf
[2] DIN EN ISO 13407, Benutzerorientierte
Gestaltung interaktiver Systeme, 2000/11
[3] DIN EN ISO 9241-10, Ergonomische Anforderungen für Bürotätigkeiten mit
Bildschirmgeräten. Grundsätze der
Dialoggestaltung, 1996/07
[4] Steve McConnell: From the Editor - The Best
Influences on Software Engineering. IEEE
Software 17(1): 2000, p. 10-17
[5] Ralf Fahney, Anforderungsmanagement
als eigenständige Disziplin, GC-upa 2003
[6] Ronald Hartwig, Praktische Integration des
Requirements-Engineering im Feld der multimedialen interaktiven Lehrmedien, GC-upa
2003
[7] Michael Hatscher, Jörg Beringer: Customercentered ”New Application” Design, GC-upa
2003
[8] ISO/TR 18529, Ergonomics of human-system
interaction - Human-centred lifecycle process
descriptions, 2000/06
[9] Standish Group. ”CHAOS Chronicles or
CHAOS: A Recipe For Success”, 1999
http://www.standishgroup.com/chaos/intro1.php
http://www.standishgroup.com/sample_research/
PDFpages/chaos1998.pdf
[10] Friedrich Strauß: Requirements-Analyse und
GUI Design, GC-upa 2003
[11] Volere 2003, http://www.volere.co.uk/
32
Usability Professionals und Requirements-Engineering
Referentin
Dipl.-Inform. M.Sc. Astrid Beck hat in Berlin Informatik und in Los Angeles
Computer Science studiert. Zuvor hat sie eine Ausbildung als Informatik-Assistentin
absolviert. In Stuttgart war sie bei der Universität Stuttgart in Kooperation mit dem
Fraunhofer-Institut für Arbeitswirtschaft und Organisation tätig, bis sie sich 1994
selbstständig machte.
Astrid Beck ist seitdem als Beraterin aktiv für Software-Qualitätsmanagement.
Ihre Beratungsschwerpunkte sind die Gestaltung von Benutzungsoberflächen,
Konzeption von Webprojekten sowie Methoden und Verfahren für die Softwareentwicklung, wie z.B. Anforderungsermittlung und Test. Ihre Kunden sind Banken
und große Unternehmen.
33
ANFORDERUNGSMANAGEMENT
ALS EIGENSTÄNDIGE DISZIPLIN
Ralf Fahney
Anforderungsmanagement
Helfrichstrasse 8
D-82041 Oberhaching
fahney@anforderungsmanagement.de
www.anforderungsmanagement.de
ABSTRACT
Veränderung der Anforderungen schützen.
Studien belegen, dass professioneller Umgang mit
Anforderungen ein Drittel bis die Hälfte des Erfolgs
von erfolgreichen IT-Projekten ausmacht. Umgekehrt
liegt es etwa zur Hälfte an mangelhaftem
Anforderungsmanagement, wenn ein IT-Projekt
schief läuft.
Dieser Beitrag
Anhand eines Praxisbeispiels und der gängigen
Literatur
motiviert
dieser
Beitrag,
als
eigenständige
Disziplin in IT-Projekten zu sehen. Er zeigt das
Entwicklungspotenzial für Unternehmen auf, die
als
Disziplin
im
Unternehmen etablieren.
Keywords
Anforderungsmanagement,
Requirements
Management,
Requirements
Engineering, Change Request Management
1. EINLEITUNG
Besonders Großunternehmen sind von Einflüssen
betroffen wie
•
allgemeine wirtschaftliche Entwicklung;
•
internationale Akquisitionen;
•
gesetzliche und politische Vorgaben;
•
wechselnden
Unternehmen.
Verantwortlichkeiten
im
Es ist hier zum einen wichtig, den Umfang von
IT-Projekten so zu vereinbaren, dass in kurzer Zeit
Ergebnisse entstehen, die Nutzen erzeugen und
weiter verwendbar sind. Zum anderen muss man
Projekte gegen unkontrollierte und ungewollte
Stuttgart).
Proceedings of the
34
•
zeigt anhand eines Praxisbeispiels auf, wie klar
vereinbarte
Anforderungen
stabile
Rahmenbedingungen schaffen;
•
motiviert
anhand
des
Praxisbeispiels,
Anforderungsmanagement als eigenständige
Disziplin in IT-Projekten zu sehen;
•
unterstützt diese Sichtweise durch Verweise und
Zitate der Anforderungsmanagement-Literatur;
•
zeigt
das
Entwicklungspotenzial
für
Unternehmen
auf,
die
Anforderungsmanagement als Disziplin im
Unternehmen etablieren.
2. PRAXISBEISPIEL
Aufgrund von Akquisitionen und gewachsenen
Strukturen kommen im Kundenservice / Callcenter
eines
Logistik-Dienstleisters
mehrere
Auskunftssysteme zum Einsatz.
2.1 Projektziele
In einem Projekt will der Logistik-Dienstleister die
Beauskunftung harmonisieren und dem Callcenter
eine einheitliche Sicht auf Sendungen verschiedener
datenliefernder Systeme zur Verfügung stellen
(Harmonisierungsprojekt).
In einem zweiten Projekt will er das Reklamationsund Schadensmanagement stärker als bisher in den
Arbeitsablauf im Callcenter integrieren.
Parallel zu diesen Aktivitäten entwickelt ein drittes
Projekt die IT-Unterstützung für ein neues Produkt
(Produkt-Neuentwicklung). Das Projekt formulierte
einen
Change
Request
an
das
Harmonisierungsprojekt
mit
dem
Ziel,
die
Auskunftsfähigkeit im Callcenter um das neue
Produkt zeitnah zu erweitern und die Pilotierung des
neuen Produktes unterstützen zu können.
2.2 Pflichtenhefte
Der Logistik-Dienstleister lässt für die drei Aufgaben
Pflichtenhefte erarbeiten. Hier sind wie üblich
Masken,
Dialogabläufe,
Geschäftslogik,
Schnittstellen usw. spezifiziert.
In die regelmäßigen Abstimmungsgespräche sind
der fachliche Auftraggeber, die Endbenutzer und die
notwendigen Fachexperten eingebunden. Sie sind
die
wichtigsten
Informationsgeber
für
die
Spezifikation.
2.3 Reviewprozess
Gemeinsam mit dem Auftraggeber begutachtet die
Projektleitung die Pflichtenhefte. Es ergibt sich, dass
die Anforderungen in zwei Bereichen ausreichend
stabil für eine Implementierung sind:
•
Masken
und
Dialogabläufe
für
die
Beauskunftung und für das Reklamations- und
Schadensmanagement;
•
Geschäftslogik
zur
Sendungsinformation.
Vereinheitlichung
der
Bei der Geschäftslogik für das Reklamations- und
Schadensmanagement ergibt sich, dass die
zentralen Vorgaben für die Gesamtarchitektur noch
zu großen Spielraum für die Umsetzung lassen.
Datenlieferanten
ergeben
sich
geringfügige
Änderungen im Modell der vereinheitlichten
Sendung
und
der
bereits implementierten
Dialogoberfläche.
Die
Pflichtenhefte
werden
entsprechend aktualisiert.
In Folgebeauftragungen erfolgte die planmäßige
Umsetzung der vollständigen Lösung.
3. UNTERSUCHUNG DES
PRAXISBEISPIELS
Dieser Abschnitt untersucht nun die Tätigkeiten der
Projektleitung unter den Aspekten Projekt-,
Qualitätsund
Anforderungsmanagement.
Abbildung 1 setzt die drei Disziplinen schematisch
zueinander in Beziehung. Sie verdeutlicht, dass es
Überschneidungen und Abhängigkeiten gibt. Die
Pfeile kennzeichnen den Informationsfluss zwischen
den Disziplinen. Die Zahlen bezeichnen die Aspekte,
die in den folgenden Unterabschnitten beleuchtet
werden.
Für die Anbindung der datenliefernden Systeme ist
zum einen das technische Design weiter zu
konkretisieren.
Zum
anderen
sind
die
Releaseplanungen der datenliefernden Systeme mit
der Terminplanung des Harmonisierungsprojektes
zu synchronisieren.
Projektmanagement
2
2.4 Beauftragung von Teillösungen
Die Auftraggeber wünschen noch stärker sichtbaren
Projektfortschritt. Gleichzeitig ist Raum erforderlich
für die Klärungen z.B. im Bereich der
Gesamtarchitektur und der Schnittstellen zu den
datenliefernden Systemen. Es entsteht die Idee,
umsetzbare Teillösungen zu ermitteln und zu
implementieren, die für sich genommen bereits Sinn
im Hinblick auf die Projektziele ergeben.
In
einem
Klärungsprozess
erarbeiten
und
vereinbaren alle Beteiligten zwei Teilprojekte, mit
denen zum einen die gesamte Dialogoberfläche und
zum
anderen
die
Geschäftslogik
zur
Vereinheitlichung von Sendungen implementiert
wird. Die Anforderungen aus dem Change Request
des dritten Projektes sind so gestaltet, dass sie im
Rahmen der beiden Teilprojekte mit umgesetzt
werden können.
Der
Logistik-Dienstleister
beauftragt
Softwarehaus mit der Durchführung.
ein
2.5 Weitere Durchführung der Projekte
Der Umfang der beiden Teilprojekte und die
umzusetzenden Anforderungen waren im Vorfeld so
klar herausgearbeitet, dass der Dienstleister die
Ziele innerhalb des geschätzten Zeit- und
Budgetrahmens erreicht.
Parallel zur Durchführung der Teilprojekte werden
die erforderlichen Klärungen für die Stabilisierung
der verbleibenden Anforderungen fortgeführt. Aus
den finalen Schnittstellenabstimmungen mit den
1
3
Qualitätsmanagement
4
Abbildung 1: Verhältnis der Disziplinen ProjektQualitäts- und Anforderungsmanagement zueinander
3.1 Gemeinsame Wurzel aller drei Disziplinen
Alle drei Disziplinen beginnen ihre Arbeit mit der
Frage nach Projektauftrag und Projektziel.
erhält
initiale
Orientierung für die weitere Klärung von
Anforderungen.
3.2 Überschneidungen zwischen Anforderungsund Projektmanagement
bedient
sich
der
Methoden des Projektmanagements, um sein
eigenes Vorgehen zu planen und zu koordinieren.
Projektmanagement
benötigt
geklärte
Anforderungen, um verlässliche Aufwands- und
Zeitschätzungen erstellen zu können.
3.3 Überschneidungen zwischen Anforderungsund Qualitätsmanagement
Zu jeder Anforderung sind z.B. die Abnahmekriterien
festzulegen. Die Anforderungen selbst müssen
qualitativ
hochwertig
formuliert
sein
(z.B.
vollständig, widerspruchsfrei, verbindlich).
35
Fahney, R.
3.4 Originärer Anteil des
Anforderungsmanagements
In diesen Bereich fallen sämtliche Tätigkeiten, die
mit
der
Ermittlung,
Klärung,
Priorisierung,
Dokumentation
und
Veränderung
von
Anforderungen zu tun haben. Im dargestellten
Praxisbeispiel sind dies u.a.
•
Erstellung der Pflichtenhefte nebst notwendiger
Informationsbeschaffung und -klärung;
•
Intensive
Einbeziehung
des
Auftraggebers, der Endbenutzer
notwendigen Fachexperten;
•
Einfordern
von
Konkretisierungen,
Interpretationsspielraum blieb;
•
Formulierung und Abstimmung des Change
Request
für
die
Berücksichtigung
der
Anforderungen aus der Produkt-Neuentwicklung;
•
Klärung von Umfang und Abgrenzung der
beiden Teilprojekte: Welche Anforderungen
sollen in den Teilprojekten umgesetzt werden,
welche nicht?
•
Fortführung der Klärungen im Bereich der
Gesamtarchitektur,
um
daraus
die
Anforderungen an die Architektur ableiten zu
können;
•
fachlichen
und der
wo
Dokumentation
und
Kommunikation
der
veränderten Anforderungen z.B. im Bereich der
vereinheitlichten Sendung und deren Darstellung
im Dialog.
3.5 Zusammenfassung
Eine konkrete zahlenmäßige Aufteilung der
Arbeitsanteile in den Disziplinen ist von Fall zu Fall
verschieden und darüber hinaus unterschiedlich je
nach Projektphase:
•
Bis zur Auslieferung der Pflichtenhefte
dominierte Anforderungsmanagement.
•
Während des Reviewprozesses ging es vor
allem um Qualitätsmanagement.
•
Die Ausarbeitung der Beauftragung betraf
wegen der Klärung und Abgrenzung von
Projektumfang
und
unzureichenden
Anforderungen
wieder
eher
das
Anforderungsmanagement.
der sorgfältigen Vorarbeit aller Beteiligten konnte
das Softwarehaus Aufwand und Zeit detailliert und
präzise schätzen. Der fachliche Auftraggeber konnte
beruhigt der Durchführung der Teilprojekte
entgegensehen. Es gab nur wenig nachfolgenden
Klärungsbedarf.
4. METHODISCHE GRUNDLAGEN DES
ANFORDERUNGSMANAGEMENTS
Studien der Standish Group ([8], [9]) belegen, dass
professioneller Umgang mit Anforderungen ein
Drittel bis die Hälfte des Erfolgs von erfolgreichen
IT-Projekten ausmacht. Umgekehrt liegt es etwa zur
Hälfte an mangelhaftem Anforderungsmanagement,
wenn ein IT-Projekt schief läuft. Schienmann
([7] S.15) zitiert eine Studie der ESPITI, die “zu
ähnlichen Ergebnissen kommt”.
Anforderungsmanagement ist keine neue Disziplin.
Der Einsatz von Pflichtenheften, Lastenheften,
Fach- und Systemspezifikationen ist seit langen
Jahren gängige Praxis. Es gibt jedoch Literatur
(u.a. [3], [6], [7], [10]), die sich speziell beschäftigt
mit
•
Ermittlung und Verwaltung von Anforderungen;
•
Verbindlicher Formulierung und Dokumentation
von Anforderungen;
•
Umgang
mit
Anforderungen;
•
den für diese Tätigkeiten erforderlichen
Kompetenzen. Hierzu gehört z.B. auch die
erforderliche Konfliktmoderation ([4], [7]);
•
Einführung
einer
Methodik
für
Anforderungsmanagement in Unternehmen.
Veränderungen
von
In dieser Literatur ist wenig bis gar nicht die Rede
von den Themen, mit denen sich Projekt- und
Qualitätsmanagement beschäftigen:
•
Terminplänen
•
Ergebnisstrukturplänen
•
Budgetplänen
•
Schätzverfahren
•
Testverfahren
•
Reviewverfahren
•
Die Vorbereitung der fachlichen Tests war
wieder Gegenstand des Qualitätsmanagements.
Der Rational Unified Process [2] kennt einen
eigenen Requirements Workflow.
•
Zu
jeder
Zeit
waren
Methoden
des
Projektmanagement gefordert, um Koordination
und Synchronisation in Gang zu setzen und die
richtigen Personen an den Tisch zu bekommen.
Das V-Modell kennt die Submodelle PM, QS, KM
und SE ([1], [5]). Anforderungen werden im
Submodell SE behandelt. Das V-Modell sieht den
Umgang mit Anforderungen also weder im
Projektmanagement noch im Qualitätsmanagement.
In
dem
Praxisbeispiel
hat
konsequentes
Anforderungsmanagement zu einem erheblichen
Teil zum Erfolg der beiden Teilprojekte und der
Projekte
insgesamt
beigetragen.
Klare
Vereinbarungen
schafften
stabile
Rahmenbedingungen für die Umsetzung. Aufgrund
36
Aus diesen Feststellungen ergibt sich eine weitere
Motivation,
als
eigenständige Disziplin zu betrachten.
Damit leistet Anforderungsmanagement einen
erheblichen Beitrag dazu, die Wirtschaftlichkeit der
erstellten Lösungen sicherzustellen.
5. ENTWICKLUNGSPOTENZIAL FÜR
UNTERNEHMEN
Anforderungen sind eine treibende Kraft in
Unternehmen. Unternehmen sind bedeutungslos,
wenn Kunden keine Anforderungen an sie stellen.
Eigene Visionen der Unternehmen über zukünftige
Marktentwicklungen sind weitere Quellen von
Anforderungen.
Schienmann
schlägt
in
[7]
einen
projektübergreifenden, kontinuierlichen Prozess des
Anforderungsmanagements
vor.
Es
gibt
Unternehmen mit Organisationseinheiten, die
speziell
für
im
Unternehmen verantwortlich sind.
Es ist möglich, den Umgang mit Anforderungen und
den Prozess des Anforderungsmanagements zu
hinterfragen und bei Bedarf zu optimieren.
Mögliches Einsparungspotenzial ergibt sich z.B. in
folgenden Bereichen:
•
Schnellere
Informationsgewinnung
durch
unmittelbare
dezentrale
Erfassung
von
Anforderungen;
•
Detailliertes Controlling des Fortschritts der
Anforderungsklärung;
•
Ermittlung der Auswirkungen der Veränderung
von Anforderungen;
•
Einarbeitung neuer Mitarbeiter.
Der Nutzen von Anforderungsmanagement liegt für
Unternehmen in
•
klar
herausgearbeiteten
Rahmenbedingungen;
Zielen
und
6. REFERENCES
[1] Bröhl, A.P., Dröschel, W. (1993): Das V-Modell
– Der Standard für die Softwareentwicklung mit
Praxisleitfaden. Oldenbourg, München 1993.
[2] Kruchten, P. (1999): The Rational Unified
Process – An Introduction. Addison-Wesley,
Reading, Massachusetts 1999.
[3] Leffingwell, D., Widrig, D. (1999): Managing
software requirements – a unified approach.
Addison-Wesley, Boston 1999.
[4] Mayrshofer, D., Kröger, H.A. (2001):
Prozesskompetenz in der Projektarbeit.
Windmühle Verlag, Hamburg 2001.
[5] Müller-Etrich, G. (1999): Objektorientierte
Prozeßmodelle – UML einsetzen mit OOTC, VModell, objectory. Addison-Wesley, Bonn 1999.
[6] Rupp, C. (2002): Requirements-Engineering und
-Management. Professionelle, iterative
Anforderungsanalyse für die Praxis, 2.,
überarbeitete Auflage. Carl Hanser Verlag,
München, Wien 2002
[7] Schienmann, B. (2001): Kontinuierliches
Anforderungsmanagement. Prozesse Techniken - Werkzeuge. Addison-Wesley,
München 2001.
[8] http://www.standishgroup.com/sample_research/
chaos_1994_1.php ff. (4 Web-Seiten)
•
der Möglichkeit fundierter Ressourcenplanung;
[9] http://www.standishgroup.com/sample_research/
PDFpages/chaos1998.pdf
•
hoher Planungssicherheit (Budget, Termine);
[10] Versteegen, G., Salomon, K., Heinold, R.
•
effizienter Umsetzung wegen klarer Ziele und
Rahmenbedingungen;
•
der Eingebundenheit der Betroffenen mit der
Konsequenz, dass diese die zukünftige Lösung
kennen und mittragen.
(2001): Change Management bei
Softwareprojekten, Springer-Verlag, Berlin,
Heidelberg 2001
37
Fahney, R.
Referent
Ralf Fahney besitzt 14 Jahre Berufspraxis im Bereich Projektmanagement von ITProjekten,
Produktmanagement,
Objektorientierung,
Einführung
von
Geschäftsprozessen. Seine langjährige Erfahrung als Berater bei verschiedenen Kunden
in unterschiedlichen Branchen führten ihn zu der Überzeugung, dass professioneller
Umgang mit Anforderungen erheblich zum Erfolg von IT-Projekten beiträgt.
Seit Januar 2003 bietet er als freier Berater Anforderungsmanagement als Dienstleistung
an. Er unterstützt bei der Einführung und Durchführung von Anforderungsmanagement
in Unternehmen und Projekten.
38
CUSTOMER-CENTERED “NEW APPLICATION” DESIGN
Michael Hatscher
SAP AG
Neurottstr. 16
69190 Walldorf
michael.hatscher@sap.com
www.sap.com
Dr. Jörg Beringer
SAP AG
Neurottstr. 16
69190 Walldorf
joerg.beringer@sap.com
www.sap.com
aggregiert
und
angereichert
ABSTRACT
Der folgende Bericht beschreibt die Erfahrungen der
SAP XDG (xApps Design Group) mit einem DesignProzess, der frühe Prototypen, massive Einbindung
von (Pilot-)Kunden und enge Zusammenarbeit mit
dem Produkt-Management als Kernelemente für ein
erfolgreiches Design einsetzt. Es wird dargestellt,
welche Elemente verschiedener Design-Methoden
sich gut kombinieren lassen, und zwei Praxisprojekte
werden skizziert.
Keywords
customer-centered design, goal-directed design,
contextual design, SAP xApps, design patterns
1. WAS SIND XAPPS? WER IST XDG?
SAP xApps sind SAPs neue Klasse von „composite
applications“, Anwendungen, die auf bestehende
Lösungen
aufsetzen
und
prozessund
komponentenübergreifend
verschiedenen
NutzerInnen in den Unternehmen die für ihre
Aufgaben
notwendigen
Informationen
und
Funktionalität bereitstellen. Sie zeichnen sich durch
folgende Merkmale aus:
•
cross functional: quer
strukturen
werden
unterstützt
•
composite: Integration bestehender Systeme in
neue Lösungen
•
collaborative:
Zusammenarbeits-Szenarien
werden unterstützt
•
content-driven: strukturierte und unstrukturierte
Inhalte werden in den Geschäftsprozess
integriert
•
zu OrganisationsGeschäftsprozesse
close the loop: bestehende Information wird
Es ist erlaubt, digitale und Kopien in Papierform des ganzen Papers
oder von Teilen davon für den persönlichen Gebrauch oder zur
Proceedings of the
mit
Kontextinformation
Die xApps Design Group (XDG) ist eine zentrale, in
Deutschland und den USA angesiedelte SharedServices-Gruppe im Bereich der xApp-Entwicklung,
die die jeweiligen xApp-Produktteams bezüglich
Anforderungsanalyse, Interaktions- und visuellem
Design unterstützt. Zusätzlich arbeitet die Gruppe an
xApp-übergreifenden Fragestellungen wie DesignMethoden und User Interface-Patterns und stellt
diese Informationen Entwicklungsteams und xAppPartnern zur Verfügung.
2. XDG DESIGN-PROZESS
Der XDG Design-Prozess verknüpft eine Reihe
verschiedener
Methoden
zum
Requirements
Gathering
und
Interaktions-Design.
Frühe
Prototypen helfen dabei, die Ideen zu visualisieren;
die Einbindung von Pilotkunden sorgt dafür, dass die
xApps die Prozesse der Kunden optimal
unterstützen. Später im Prozess erweist sich die
enge
Zusammenarbeit
mit
dem
ProduktManagement (PM) und der Entwicklung als sehr
fruchtbar bei der Definition realistischer Designs.
Gegen Ende des Design-Entwicklungszyklus’ binden
wir Produkt-Management und Entwicklung in
Methoden zur Evaluation der Usability ein (meist
Usability Tests, aber auch Cognitive Walkthroughs
[3] beim Kunden oder auf Messen; siehe auch
Wixons [4] kritischen Beitrag zu Literatur und Praxis
im Bereich der Usability-Evaluation).
Die Besonderheiten und Schwerpunkte dieses
Prozesses werden in den folgenden Abschnitten
auszugsweise dargestellt.
2.1 Produktdefinition
Für die Anforderungsanalyse und frühe Konzeption
einer xApp verwenden wir eine Mischung von
Contextual Design, Goal-directed® Design und
Szenario-basiertem Design:
•
Contextual Design (Hugh Beyer / Karen
Holtzblatt) [1]: In Ergänzung zu konventionellen
Methoden des Produkt-Managements beim
Kunden werden für alle xApp-Projekte so
genannte
Contextual
Interviews
an
Arbeitsplätzen
potenzieller
Benutzer
durchgeführt.
Dies
geschieht
in
enger
39
Hatscher, M. & Beringer, J.
Kooperation mit dem Produkt Management
(PM). Diese werden auch von der XDG
ausgebildet,
Interviews
selbstständig
durchzuführen.
Die
Interviews
werden
mittlerweile sowohl intern als auch bei Kunden
sehr geschätzt, weil sie viele neue Einsichten
hervorbringen und sowohl PM als auch den
Designern
helfen,
Produktmerkmale
zu
priorisieren. Der enge Zeitrahmen und die zeitund kostenintensive Anreise zu internationalen
Pilotkunden zwingen uns jedoch dazu, die
Aufarbeitung der Daten auf ein Minimum zu
beschränken. Interpretation Sessions, Flow- und
Sequence-Modell und Affinity Building sind für
uns die wesentlichen Maßnahmen, um
Interviewdaten maximal zu nutzen. Die FlowModelle sind für die Spezifizierung der Worksets
(SAPs Rollendefinitionen) und kollaborativen
Strukturen äußerst hilfreich. Mit den SequenceModellen
können
wir
wiederkehrende
Arbeitsprozesse spezifizieren und als Szenario
beschreiben. Diese Modelle geben uns
Aufschluss über die tatsächlich gelebten
Arbeitsprozesse, die sich i.d.R. in formalen
Prozessbeschreibungen nicht oder nur teilweise
wieder finden. Mit den Affinity Notes
identifizieren
wir
die
wichtigsten
verbesserungsfähigen Punkte für ein gegebenes
Geschäftsszenario und helfen damit, den
Innovationsgrad der xApp-Lösung zu erhöhen.
•
•
40
Goal-Directed® Design (Alan Cooper) [2]:
Cooper setzt im Goal-Directed® Design so
genannte „Personas“, fiktive archetypische
Nutzerpersönlichkeiten, ein, die die in Interviews
gewonnenen empirischen Daten greif- und
handhabbar machen. In einigen Fällen
entwickeln wir aufbauend auf den Daten des
Contextual Designs Personas, um sie als
Kommunikationsinstrumente und als Aufhänger
für Szenarien zu verwenden. Sie dienen uns
primär als Richtungsgeber für DesignEntscheidungen, während die substanzielle
Information aus den Contextual DesignModellen
kommt.
Im Cooper’schen Sinne haben wir während des
Designs bisher noch nicht mit Personas
gearbeitet, d.h. wir haben sie nicht formal
genutzt zur Ableitung oder Priorisierung der
Requirements. Für generische Anwendungskomponenten aber erweisen sich Personas als
besonders hilfreich, weil sich die Rollendefinition
nicht unmittelbar aus einem betriebswirtschaftlichen Szenario ergibt und deshalb mit Hilfe von
Personas künstlich geschaffen werden muss.
Szenario-basiertes Design: Die durch die
Contextual Interviews gewonnenen Sequence
Modelle und die Liste der Verantwortlichkeiten
von Rollen dienen als Ausgangspunkt für die
Entwicklung von Szenarien. Szenarien sind für
uns komplexe Use Cases, mit deren Hilfe die
wichtigsten Design- und Systemanforderungen
ermittelt werden. Diese Szenarien dienen
einerseits als Grundlage für Demo-Skripts,
anhand derer Prototypen erstellt werden, als
auch zur Erstellung von Testfällen für Usability
Tests.
2.2 Frühe Prototypen in HTML & Papier
Zur Kommunikation unserer Ideen und Designs
haben sich frühe konzeptionelle Prototypen (auf
HTML-Basis)
bewährt.
Zwar
bedeutet
die
Prototypen-Erstellung
einen
größeren
Arbeitsaufwand, der aber in einem sehr guten
Verhältnis steht zum Nutzen: Die Prototypen werden
für Präsentationen vor Top Level Management
(wegen der notwendigen Unterstützung) und vor
Kunden (auf Messen und vor Ort) ebenso eingesetzt
wie für erste konzeptionelle Usability Tests.
Da zur Implementierung eine grundsätzlich andere
Technologie zum Einsatz kommt, gibt es auch keine
Versuchung, bestehenden HTML-Code für das
Produkt zu übernehmen (und so das zu erzeugen,
was Cooper “Narbengewebe” nennt).
Zur schnelleren Iteration nutzen wir zusätzlich
Papierprototypen oder quasi-interaktive so genannte
„Wireframes“, grobe konzeptionelle Screen Designs
auf PowerPoint-Basis. Im Rahmen von PrototypInterviews
setzen
wir
diese
als
Kommunikationsgrundlage
ein,
um
weitere
Anforderungen zu sammeln und gleichzeitig
Designideen und Anwendungsstruktur zu testen. Ein
aufwendig gebauter Papierprototyp mit Post-it®
Notes erwies sich im Test nicht unbedingt als den
ausgedruckten Prototypen überlegen; zwar schien
der
Test
den TeilnehmerInnen (zumindest
anfänglich) mehr Spaß zu bereiten, aber der erhoffte
Effekt trat nicht ein: Wir hatten erwartet, dass die
Teilnehmer beginnen würden, Elemente auf dem
Screen zu verschieben, um die Applikation neu zu
strukturieren.
Insgesamt helfen die frühen Prototypen sehr, die
Produktidee zu vermitteln und zu testen, sie führen
aber auch zu sehr frühem Interaktions- und
visuellem Design, das oft ohne ausreichende
Grundlage erstellt werden muss. Hierin liegt
sicherlich ein Risiko, weil der Prototyp schnell als
informelle Designspezifikation verstanden wird und
man sich bekanntlich schwer von einem einmal
existierenden Design trennen kann.
Ein Reverse Engineering der Prototypen in User
Environment Designs (siehe Contextual Design) mit
nachfolgendem User Interface-freien Spezifizieren
der Anwendungsfunktionalität und –struktur können
diesen potenziell negativen Effekt eines Prototypen
jedoch kompensieren.
Der
positive
Effekt
ist
unserer
Meinung
vorherrschend, weil das User Interface der
Prototypen wesentlich die Backend-Funktionalität
und Datenmodelle der Anwendung mitbeeinflusst
und
hierdurch
eine
EndbenutzerIn-zentrierte
Softwaregestaltung gefördert wird, indem die User
Experience vor dem Datenmodell definiert wird.
2.3 (Pilot-)Kunden-Einbindung
Ein weiteres zentrales Merkmal des xApp-DesignProzesses stellt die frühe Einbindung von
Pilotkunden dar. Pilotkunden gewähren uns unter
anderem Zugang zu ihren MitarbeiterInnen an deren
Arbeitsplätzen und in deren Räumlichkeiten und
geben uns somit die Gelegenheit, die tatsächlichen
Arbeitsprozesse mit Hilfe von Contextual Interviews
zu analysieren. Dieses Vorgehen hat sich schon bei
vielen Pilotkunden bewährt und zu signifikant
besserem Verständnis für die Anforderungen
geführt.
2.4 Kooperation mit anderen Teams
Die enge Zusammenarbeit mit anderen Teams (wie
PM und Entwicklung) hat sich als sehr positiv
herausgestellt. Vor allem Produkt-Management und
Entwicklung in den verschiedenen Anwendungen
konnten von uns gut
in den Design-Prozess
eingebunden werden. Ebenso werden wir von diesen
Gruppen angefragt, wenn es Fragen zum Design
gibt – d.h. uns ist es hier gelungen, unter Beweis zu
stellen, dass unsere Arbeit die Qualität der
Applikation signifikant verbessert.
Beispiele für die erfolgreiche Einbindung sind
•
gemeinsame
Kundenbesuche
Interviews, Usability Tests)
Auf Kundenseite werden Contextual Interviews als
Beleg für SAPs Willen zu einem people-centric
Anwendungsdesign wahrgenommen und führen
auch nicht selten bei kunden-internen IT-Teams zu
zusätzlichen Erkenntnissen. Auf der Entwicklungsseite sorgen die konkreten und realistischen Felddaten für ein tieferes Verständnis der Geschäftsprozesse
und
eventueller
Probleme
oder
Verbesserungsmöglichkeiten. Mit diesem intensiven
Verständnis kann der Wert von Produktideen und
Produktmerkmalen in der Sprache des Kunden und
an realistischen Beispielen des Kunden plastisch
aufgezeigt werden. Die Position des Projektteams
beim Kunden wird damit insgesamt verbessert, und
MitarbeiterInnen fühlen sich in den Prozess
eingebunden.
•
gemeinsame
Tests)
•
gemeinsame Design-Aktivitäten
Ein offensichtliches Risiko des Pilotkunden-Ansatzes
ist die zu starke Spezialisierung des Erstprodukts
auf einen spezifischen Kunden. Es ist deshalb
wichtig, mit Hilfe der weiter oben beschriebenen
Methoden die in den Interviews beobachteten
Arbeitsvorgänge hinsichtlich des ursprünglichen
Arbeitsziels zu betrachten und zu „best practice“Mustern zu abstrahieren, die in ähnlicher Formen
bei anderen Kunden auch anzutreffen sind. Hierfür
sind die Contextual Design-Modelle extrem hilfreich,
weil
sie eine abstrahierte ethnographische
Beschreibung des Marktes ermöglichen und nicht
eine einfache Protokollierung des Beobachteten
sind.
3. PRAXISBEISPIELE
Um zu einer repräsentativen Anforderungsanalyse
zu kommen, werden selbstverständlich auch andere
interessierte SAP-Kunden einbezogen, die eigenes
Interesse daran haben, eine SAP-Standardlösung
mit zu beeinflussen. In enger Abstimmung mit den
Kunden entsteht so eine Anwendung, die an den
konkreten Bedürfnissen der Pilotkunden orientiert ist
(Benefit für den Kunden), gleichzeitig aber auch als
eigenständiges Produkt verkauft werden kann, weil
sie ein generisches Geschäftsproblem oder Szenario
adressiert und allgemeingültig gestaltet ist (Benefit
für SAP).
Usability-Aktivitäten
(Contextual
(Usability
Die organisatorisch zentrale Aufhängung der XDG
macht jedoch eine ständige interne Promotion nötig
und erzeugt den Druck, gute Designs und Mehrwert
für die Produktteams zu liefern. Es hat sich als sehr
hilfreich herausgestellt, wenn innerhalb des xAppProduktteams eine Person als Designerpartner
agiert und somit dem zentralen XDG Lead Designer
als Ansprechpartner für Designdiskussionen bereit
steht. Ebenso stellt eine solche Person einen
kontinuierlichen Wissenstransfer in das Produktteam
sicher. Diese Rolle haben typischerweise ProduktManagerInnen oder Front End-EntwicklerInnen.
Im Folgenden werden kurz zwei Beispielprojekte
beschrieben, in denen wir den XDG Design-Prozess
gut haben umsetzen können.
3.1 Product Definition xApp
Die Product Definition xApp (xPD) wird derzeit in
enger Zusammenarbeit mit einem Kunden aus den
USA entwickelt. Bei dieser Applikation geht es
darum, den Ideen-Prozess klar zu strukturieren,
Ideen
verfügbar
zu
machen,
aus
ihnen
Produktkonzepte zu generieren und diese Konzepte
zu einem Reifegrad zu führen, von dem aus die
Produktion anlaufen kann.
Hier begannen wir mit einer Demo, die erste grobe
Ideen zu visualisieren half. Das Konzept und die
Inhalte der Demo definierten wir gemeinsam mit
dem Produkt-Management, d.h. wir waren in den
Produkt-Definitions-Prozess
bereits
stark
eingebunden.
Später
unterstützten
wir
die
Entwicklung bei der eigentlichen Erstellung der xPDDemo, die auf der größten SAP-Kundenmesse
eingesetzt wurde.
Reger Austausch mit dem Pilotkunden ermöglichte
uns später eine schrittweise Vereinfachung des
Datenmodells und des User Interfaces – immer
wieder wurde uns klar, dass wir schon in der Demo
zu komplex gedacht hatten und die BenutzerInnen
41
Hatscher, M. & Beringer, J.
für ihre Arbeit bestimmte Features gar nicht
benötigen, über die wir uns lange den Kopf
zerbrochen hatten. Mehrmalige Usability TestZyklen mit Papierprototypen (unter Beteiligung von
PM und Entwicklung) erlaubten es uns, ein
benutzbares User Interface zu konzipieren und eine
sinnvolle Applikationsstruktur zu entwerfen, bevor
die Anwendung in die Entwicklung ging. Mit den
ersten lauffähigen Prototypen werden wir weitere
Usability Tests mit MitarbeiterInnen des Kunden
durchführen.
3.2 Employee Relationship Management xApp
Im Employee Relationship Management geht es um
eine Suite von Werkzeugen, die – auch wenig mit
dem System vertraute – BenutzerInnen bei der
Erledigung häufig anfallender sequenzieller Abläufe
unterstützen
sollen.
Ebenso
sollen
die
BenutzerInnen in die Lage versetzt werden, selbst
solche Sequenzen aufzusetzen.
Enge Zusammenarbeit mit PM und Entwicklung ließ
auch hier schnell einen präsentierbaren Prototyp
entstehen, der als Grundlage für weitere Iterationen
(via Usability Tests) und Präsentationen (auf
Messen) diente.
Die gesamte Produktidee ist sehr stark von dem
Prototyp getrieben, an dem sich nun die Entwicklung
orientiert.
Prozess scheint sich zu bewähren – gutes Feedback
vom Top Level Management und von den Kunden
sowie Test-TeilnehmerInnen bestätigen, dass die
frühe Visualisierung von Produktkonzepten, die
intensive Einbindung von Pilotkunden bei der
Anforderungsanalyse und die enge Zusammenarbeit
mit PM und Entwicklung während des Designs
Früchte trägt.
Wir
hoffen,
dass
durch
entsprechenden
Produkterfolg sich dieser Design-Prozess weiter
verbreitet und andere Produktteams sich von
diesem benutzer-zentrierten, auf empirischen Daten
basierenden Design-Prozess überzeugen lassen.
5. REFERENCES
[1] Beyer H. and Holtzblatt K., Contextual Design:
Defining Customer-Centered Systems. Morgan
Kaufmann Publishers (1998).
[2] Cooper A., The Inmates are running the Asylum:
Why High-Tech Products drive us crazy and how
to restore the Sanity. SAMS (1999).
[3] Nielsen J., Usability Engineering. Morgan
Kaufmann Publishers (1993).
[4] Wixon D., Evaluating usability methods: Why
the current literature fails the practitioner.
Interactions, X.4, 28-34 (2003).
4. RESÜMEE & POTENZIALE
Nachdem wir seit über einem Jahr wie beschrieben
vorgehen, können wir sagen: Der XDG Design-
42
Referenten
Michael Hatscher, Diplom (Psychologie) 2000 an der Universität Osnabrück über „Joy of
use – Determinanten der Freude bei der Softwarenutzung“. Seit Anfang 2001 im SAP-Umfeld
tätig: Usability Engineering Center der SAP AG; Consultant im Bereich Usability Engineering
/ User Interface Design (SAP Portals Europe GmbH & Co. KG; SAP Deutschland AG & Co.
KG); seit Anfang 2003 Interaction/User Interface Designer bei den xApps der SAP AG.
Dr. Jörg Beringer, seit 1997 bei SAP tätig als Produkt Designer und Architekt mit
Schwerpunkten User-Integration, Collaborative Solutions, Enterprise Portale. Seit 2002 leitet
er die xApp Design Gruppe und arbeitet an xApp Produktkonzepten und Koordination des UI
Frameworks.
43
PRAKTISCHE INTEGRATION DES REQUIREMENTS-ENGINEERING IM
FELD DER MULTIMEDIALEN INTERAKTIVEN LEHRMEDIEN
Ronald Hartwig
Institut für Multimediale und
Interaktive Systeme
Universität zu Lübeck
Willy-Brandt-Allee 31a - 23554 Lübeck
hartwig@imis.uni-luebeck.de
www.imis.uni-luebeck.de
ABSTRACT
Der Artikel beschreibt die Besonderheiten, die bei
der Integration des Usability-Engineering in Entwicklungsprozesse multimedialer Lernmedien zu berücksichtigen sind.
Keywords
e-Learning, Content-Management, QS, Usability
1. EINLEITUNG
Die Entwicklung klassischer Arbeitsplatz-Software
und die Qualitätssicherung innerhalb dieser Projekte
ist ein inzwischen weitgehend untersuchter, wenngleich noch nicht abgeschlossener Forschungsbereich. Ziel des Software-Engineering ist die vorhersagbare Erreichung einer definierten Qualität, wobei
die Gebrauchstauglichkeit als eine der zu betrachtenden Qualitäten die effektive, effiziente und zufriedenstellende Zielerreichung bei der Abarbeitung
von Arbeitsaufgaben sicherstellen soll. Es ist fraglich, inwieweit diese Qualitätssicherung und die dafür notwendigen Prozesse in der Praxis bereits Einzug gehalten haben oder ob noch immer die „Software-Krise“ der letzten 20 Jahre anhält. Doch nun
kommen immer weitere Entwicklungsfelder hinzu,
bei denen nicht mehr eine klassische Arbeitsaufgabe
im Mittelpunkt steht, sondern Unterhaltung oder
Bildung die Einsatzziele der Systeme charakterisieren. Dort können die bekannten Modelle nicht mehr
1:1 umgesetzt werden, weil allein der Begriff der
„Aufgabe“ und ihrer effektiven und effizienten Abarbeitung neu überdacht werden müssen.
Im Gegensatz zu den grundsätzlichen Beiträgen [1],
[2] und [4] soll in diesem Beitrag die praktische
Kombination der verschiedenen Kompetenzen in
oder Teilen davon für den persönlichen Gebrauch oder zur Verwendung in Lehrveranstaltungen zu erstellen. Der Verkauf oder
den Vorstand des GC-UPA e.V. (Postfach 80 06 46, 70506 Stuttgart).
Proceedings of the
einem Entwicklungsprozess für e-Learning Module
betrachtet werden. Die praktischen Erfahrungen
stammen aus den BMBF-Projekten „Virtuelle Fachhochschule“ (VFH) und „Medien in der medizinischen Informatikausbildung“ (medin).
2. QUALITÄT IM E-LEARNING?
Bei der Entwicklung von multimedialen Lehrinhalten
(„Modulen“) kommen neben den klassischen Qualitätsansprüchen an interaktive computerbasierte
Systeme (Stabilität, Korrektheit, Gebrauchstauglichkeit, …) weitere Qualitätsfelder hinzu. Insbesondere
die Pädagogik aber auch das ästhetische Design
tragen zum Gesamterfolg eines solchen Moduls bei.
In der Kombination wird dabei neuerdings vom Gesamterlebnis bzw. der „User Experience“ gesprochen, die es zu optimieren gilt. Diese enthält beispielsweise auch den Spaß bei der Nutzung „Joy of
Use“ als Abgrenzung zur eher nüchternen Zielerreichung aus der ISO 9241-11. Dieser Beitrag kann
dabei die Qualitätskriterien der verschiedenen Domänen nicht im Einzelnen darstellen, sondern nur
einen praktischen Weg, diese im Rahmen einer
gemeinsamen Entwicklungsrichtlinie und eines gemeinsamen Prozesses zu vereinen.
Wichtig ist in diesem Zusammenhang aber, dass die
klassische Definition von Gebrauchstauglichkeit mit
ihren Dimensionen Effektivität, Effizienz und Zufriedenstellung nun bezogen auf die Gesamtaufgabe
Lernerfolg betrachtet werden müssen. Dabei sind bei
Teilaufgaben, zum Beispiel dem Lösen einer Aufgabe durch die Lernenden, nicht immer die kürzesten
Wege die optimalen. Im Gegenteil kann die bewusste Verlangsamung des Bedienablaufes einen didaktischen Hintergrund haben, der bezogen auf den
Gesamtlernerfolg zu einer besseren Performanz des
Nutzers führt. Aus Sicht der Usability müssen also
auch gewohnte Herangehensweisen immer mit Blick
auf übergeordnete didaktische Konzepte kritisch
überprüft werden.
Im Mittelpunkt steht die geschickte Umsetzung des
Requirements-Engineerings im Rahmen der begrenzten verfügbaren Ressourcen.
44
Integration des Requirements-Engineering im Feld der multimedialen interaktiven Lehrmedien
2.1 Integration der verschiedenen Domänen
In der Praxis der Großprojekte VFH und medin hat
es sich bewährt, dass die verschiedenen Teilkompetenzen Technik, Didaktik, Design und Ergonomie
aber auch zum Beispiel juristische Rahmenbedingungen in einer gemeinsamen Arbeitsgruppe zu
einem gemeinsamen Entwicklungsleitfaden (historisch begründet aber fälschlich als „Styleguide“ bezeichnet) finden. Als eine Hauptschwierigkeit stellten
sich dabei die unterschiedlichen Begriffswelten der
verschiedenen Bereiche heraus. Der so entstandene
Styleguide [3] ist dabei in der Formulierung an die
internationale Normung angelehnt und besteht aus
„KANN“, „SOLL“ und „MUSS“-Forderungen. Dies
war für den Bereich Technik und Ergonomie ein
vertrautes Vorgehen, erforderte aber ein erhebliches
Umdenken im Bereich der Pädagogik. Bemühungen
auch das Design in diesem Leitfaden zu verankern,
scheiterten an der politisch gewünschten Heterogenität des Projektes. Am Ende gelang es aber, dass
zumindest die Anforderungen an eine pädagogische
Planung auch in die Form solcher Regeln gebracht
werden konnten, indem die Autoren der Module
gezwungen werden, Konzepte und methodische
Entscheidungen zumindest zu dokumentieren.
Damit wird eine nach den Maßstäben der klassischen Qualitätssicherung nachvollziehbare und tragfähige Prozessdokumentation der einzelnen Module
bestärkt, ohne dass ein zu strenges Korsett von
Vorgaben über die Auswahl und die konkrete Ausgestaltung der Methoden die Autoren in ihrer Kreativität einengt.
2.2 Umsetzung eines Prozessmodells
Bei der Kombination von Experten aus verschiedenen Domänen in einem Projekt mit mehr als 100
Entwicklern (VFH), hoher räumlicher und zeitlicher
Verteilung und sehr heterogenen Entwicklungsteams, ist die Flexibilität der Prozessvorgaben von
entscheidender Bedeutung, um nicht kleine Teams
im Prozessoverhead zu ersticken, aber andererseits
die rechtzeitige und ausreichend vorbereitete Kommunikation mit den jeweils zuständigen Kompetenzen sicherzustellen. Dazu wurde ein Prozessleitfaden erstellt, der Zeitpunkte definiert, zu denen Reviews initiiert werden müssen, die sich dann spezifischen Fragestellungen widmen. So ist am Anfang
ein Review der didaktischen Methoden vorgesehen,
wohingegen gebrauchstauglichkeitsbezogene Reviews erst nach erfolgreicher Begutachtung der didaktischen Modelle sinnvoll sind. Durch diese Entzerrung aber auch Hilfestellung wurde dem bis dahin
in diesen Projekten auftretenden Problem begegnet,
dass ein Großteil der Kommunikation aus dem Weiterleiten von Fragestellungen an die jeweiligen Experten bestand. Auf Seiten der Entwickler wiederum
half dieser Leitfaden, die richtigen Fragen zu formulieren.
Als Grundlage für das Prozessmodell diente die aus
der klassischen Softwaren-Entwicklung bekannte
ISO 13407, die einen iterativen, nutzerzentrierten
Ansatz verfolgt. Dabei werden die Requirements
konsequent auf den Nutzungskontext begründet und
zu konkreteren Kriterien abgeleitet (siehe [2] für eine
genaue Beschreibung). Dabei bildet die Entwicklung
dieser Anforderungen den erfolgskritischen Anteil
des Prozessmodells.
3. REQUIREMENTS-ENGINEERING
Die Ableitung der Anforderungen an ein Produkt ist
bereits bei klassischen Arbeitssystemen eine nichttriviale Aufgabe, deren Lösung sicher noch nicht
abgeschlossen ist. Schon die Lücke zwischen den
funktionalen Anforderungen aus dem Bereich des
traditionellen
Software-Engineering
und
den
Gebrauchstauglichkeitsanforderungen der Usability
scheint bis heute noch nicht überwunden zu sein. Im
Falle eines so neuen Feldes wie des so genannten
„e-Learning“ entstehen aber weitere, neue Unsicherheiten.
Der Workflow, sofern es einen einheitlichen
Workflow überhaupt gibt, während des Lernens auf
der Lernerseite ist noch schwerer zu fassen als bei
den Arbeitsaufgaben, die die Autoren der ISO9241
offenbar vorgesehen hatten. Dadurch entsteht zunächst eine Unterspezifikation, die eine seriöse Qualitätssicherung, zum Beispiel im Bereich Usability,
fast unmöglich macht. Wie soll entschieden werden,
ob etwas „aufgabenangemessen“ ist, wenn die optimale Lösung der Aufgabe mit den gebotenen Mitteln
noch unklar ist. Erschwerend kommt hinzu, dass die
Analyse der Lerneraktivitäten im Vorfeld in Ermangelung entsprechender Testobjekte schwierig war.
Insbesondere der Nutzungskontext einer berufsbegleitenden und langfristigen Weiterbildung mittels eLearning Modulen war künstlich unter Laborbedingungen kaum nachstellbar. Deshalb wurde die Analysephase mit dem Test der ersten Prototypen zusammengelegt, wohl wissend, dass die Gestaltung
der Prototypen bereits implizit deren Nutzung formte. Allein, es blieb gar keine andere Möglichkeit.
So entstand eine pragmatische, iterative aber doch
reduzierte Version eines Prozesses im Sinne der
ISO 13407 [5] bei dem aber die Defizite einer eigentlich für die ersten Module zu späten Analyse
bewusst in Kauf genommen wurden, um zumindest
für deren Nachfolger eine bessere analytische
Grundlage zu haben.
3.1 Meta-Requirements
Zentrale Aufgabe bei der Erstellung und Dokumentation der Requirements aus den verschiedenen
Domänen war die Qualitätssicherung dieser Requirements selbst. Es muss verhindert werden, dass
widersprüchliche Anforderungen aus den verschiedenen Bereichen entstehen oder aber Requirements
auf sehr unterschiedlicher Basis oder sehr unterschiedlicher Güte entstehen. Dazu wurden im Projekt Meta-Requirements aufgestellt, die die Mindestanforderungen an die eigentlichen Anforderungen
definierten.
45
Hartwig, R.
Die wichtigste Minimalforderung war, dass jede Anforderung sich zu einem prüfbaren Kriterium im
Entwicklungsleitfaden konkretisieren lassen musste.
D.h. eine allgemeine pädagogische Forderung nach
selbstgesteuerten Lernmöglichkeiten konnte in konkretere technische und gebrauchstauglichkeitsrelevante Teilkriterien („Lernende müssen die Möglichkeit haben, frei innerhalb der Inhalte zu navigieren“)
werden.
Eine andere wichtige Anforderung aus der Praxis
eines Produktionsprojektes war die Lesbarkeit und
Kürze der aufgestellten Anforderungen an die Produkte. Die Erfahrung in diesem Projekt zeigte, dass
den betroffenen Entwicklern und Autoren nur sehr
wenig Zeit zur Aufnahme der Qualitätsforderungen
im Allgemeinen und der Usability-Requirements im
Besonderen zur Verfügung stand. Deshalb wurde bei
der Entwicklung des Leitfadens darauf geachtet,
dass die Gesamtzahl und der Umfang der Forderungen nicht wesentlich über 20 Seiten hinausgehen.
Dadurch sollte die Einstiegshürde in die qualitätsrelevanten Richtlinien vereinfacht werden. Um dies zu
erreichen, wurde vornehmlich nur solche Bereiche
mit konkreten Regeln und Anforderungen beleuchtet, bei denen in den bisherigen Evaluationen tatsächlich auch Probleme aufgetreten waren. Dabei
war auch die Entwicklung der Richtlinien einem kontinuierlichen Verbesserungsprozess unterworfen, der
über die gesamte Projektdauer lief.
Entwickelt wurde die Richtlinie innerhalb einer speziellen Arbeitsgruppe, die mit Vertretern aus den
verschiedenen Domänen (Technik, Didaktik, virtuelle Gruppenarbeit, Ergonomie) sowie Entwicklern, die
diese Richtlinien dann umsetzen sollten, besetzt
war. Durch diese enge Einbindung in den Entwicklungsprozess und die Entwicklerzentrierung bei der
Richtlinienformulierung konnte die Akzeptanz der
Richtlinie gesteigert werden.
3.2 Erhärtungsprüfung
Das wichtigste Meta-Requirement bei der Erstellung
der Richtlinie ist sicher die Validität der Requirements. Um diese sicherzustellen wurde auf eine aus
dem DATech-Prüfbaustein Usability [1] entlehnte
Form der „Erhärtungsprüfung“ zurückgegriffen. Dabei wurden die Forderungen und Kriterien vor der
Aufnahme in die Entwicklungsrichtlinie daraufhin
überprüft, welchen Einfluss ihre Nichteinhaltung auf
die Effektivität, Effizienz und Zufriedenheit der Lernenden bezogen auf den Lernerfolg haben würde.
Berührte eine Forderung vermutlich nicht diese drei
aus der Usability bekannten Dimensionen, wurde es
als vermutlich irrelevant verworfen bzw. die Relevanz bei der Auswertung der Benutzertests und der
dabei stattfindenden Szenario-Erhebung besonders
geprüft.
4. DATENHALTUNG
Bei dem Versuch die oben beschriebene pragmatische Methodik konsequent anzuwenden, entstanden
46
Probleme mit der Gebrauchstauglichkeit der Werkzeugunterstützung für den beratenden Experten. Es
entstanden umfangreiche Dokumente im Rahmen
der Analyse, der Benutzertests, des Styleguides und
der Reviews. Alle diese Dokumente standen zunächst unverbunden als Textdokumente nebeneinander. Aufgrund der langen Projektdauer wurde es
zunehmend problematischer die implizite Vernetzung dieser Dokumente konsistent zu halten. Praktisch bedeutete dies, dass es nach einiger Zeit
schwierig war, Requirements gegenüber Entwicklern
zu rechtfertigen, da die Fundierung dieser Requirements in Beobachtungen aus den Benutzertests
oder den Studienszenarien nicht gut zu dokumentieren waren. Verweise auf Textdokumente veralteten
und wurden inkonsistent.
Aus dieser Problematik heraus wurde ein ursprünglich zur Aufgabenanalyse entwickeltes webgestütztes Datenbank-System so erweitert, dass ein semantisches Netz mit den Prozessdaten über eine einfache Browserschnittstelle angelegt und gepflegt werden konnte. Da es sich bei den Zielprodukten ebenfalls um Web-Inhalte handelte, lag es nahe, diese
ebenfalls in dieser Prozessdatenbank zu verwalten.
So ist es dann möglich, dass Entwickler und unterstützende Fachexperten alle gemeinsam an einem
Datenbestand arbeiten und ihre jeweiligen Anteile
mit denen anderer Zuarbeiten vernetzen können.
Eine genaue Beschreibung des Tools findet sich in
[4] aber an dieser Stelle sei auf den Nutzen eines
solchen Systems bei der Kommunikation der Richtlinien hingewiesen. Durch die Vernetzung der Richtlinien mit ihren Grundlagen und dem Herleitungsweg
wird die Argumentation mit den Entwicklern erleichtert. Man kann nun nicht nur sehen, was gefordert
wird, sondern das warum steht direkt dabei und kann
bis zum Benutzertestprotokoll oder dem unterliegenden didaktischen Konzept zurückverfolgt werden. Diese kann durch die Experten indirekt nachgesehen und zusammengestellt oder von den Entwicklern direkt nachvollzogen werden.
5. ZUSAMMENFASSUNG
Dieser Bericht kann die verschiedenen Aspekte des
Requirements-Engineering in so einem neuen Feld
nur kurz beleuchten und einige praktische Hinweise
geben. Die wichtigsten „Best-Practices“ sind aus
Sicht der Autoren:
•
Requirements aus verschiedenen Domänen
anhand von gemeinsamen Meta-Requirements
ausrichten und entwickeln.
•
Usability (Lesbarkeit, Verständlichkeit, Konstruktivität, Umfang) der Requirements und daraus
abgeleiteter Richtlinien selbst prüfen.
•
Aus den Requirements abgeleitete Richtlinien in
einem nutzerzentrierten Prozess analog der ISO
13407 entwickeln. Dabei sind die Entwickler die
Nutzer!
Integration des Requirements-Engineering im Feld der multimedialen interaktiven Lehrmedien
•
Richtlinien und andere Qualitätssicherungsmaßnahmen als Hilfestellung und nicht als Reglementierung einbinden.
•
Das Überzeugen der Entwickler als wichtigen
Aufgabenbestandteil verstehen und durch Beispiele und nachvollziehbare Herleitungswege für
Vorschriften unterstützen.
•
Einbettung aller Prozessdokumente in ein ganzheitlicheres System, um Medienbrüche und vor
allem „Prozessdokumentenfriedhöfe“ zu vermeiden.
6. REFERENCES
[1] Dzida, W., Hofmann, B., Freitag, R., Redtenbacher, W., Baggen, R., Geis, T., Beimel, J.,
Hartwig, R., Hampe-Neteler, R., Peters, H.
(2001): Gebrauchstauglichkeit von Software. ErgoNorm: Ein Verfahren zur Konformitätsprüfung
von Software auf der Grundlage von DIN EN
ISO 9241 Teile 10 und 11. Schriftenreihe der
Bundesanstalt für Arbeitsschutz und Arbeitsmedizin, Forschung Fb 921, Bremerhaven, Wirtschaftsverlag NW
[2] Hartwig, R.; Triebe, J.K.; Herczeg, M. (2002):
Software-ergonomische Evaluation im Kontext
der
Entwicklung multimedialer Lernmodule für die
virtuelle Lehre. In Herczeg, M; Prinz, W.; Oberquelle, H. (Hrsg.): Mensch & Computer 2002:
Vom interaktiven Werkzeug zu kooperativen Arbeits- und Lernwelten. Stuttgart: B.G. Teubner,
2002, S.313-322
[3] Hartwig, R.; Triebe, J.K.; Herczeg, M. (2002):
Styleguide - Richtlinien zur Qualitätssicherung
bei der Realisierung von Studienmodulen im
Projekt VFH. Universität zu Lübeck - Institut für
Multimediale und Interaktive Systeme;
http://www.imis.uniluebeck.de/de/forschung/publikationen.html#2002
[4] Hartwig, R; Herczeg, M. (2003): XMendeL –
Web-gestützte objektorientierte Datenhaltung in
Usability-Engineering-Prozessen – Mensch und
Computer 2003, Stuttgart, 2003 (to appear)
[5] International Organization for Standardization
(1999): ISO 13407 - Human-centred design
processes for interactive systems. Berlin, Beuth
Verlag
[6] Rosson, M. B.; Carroll, J.M. (2002): Usability
Engineering – Scenario based development of
human-computer interaction, San Francisco,
Morgan Kaufmann Pub.
47
Hartwig, R.
Referent
Dipl.-Inform. Ronald Hartwig ist seit 1999 wissenschaftlicher Mitarbeiter am Institut
für Multimediale und Interaktive Systeme der Universität zu Lübeck und parallel dazu
als Usability-Berater (www.benutzerfreundlichkeit.de bzw. www.human-interface.de)
tätig. Vorher war er in der allgemeinen ergonomischen Qualitätssicherung eines der
größten deutschen Prüfhäuser tätig. Er arbeitet schwerpunktmäßig an der möglichst
effizienten Einbringung von gebrauchstauglichkeitsteigernden Prozessbausteinen in
Entwicklungsprozesse.
Ziel ist dabei die Einbindung von bisher nicht ausreichend berücksichtigten Entwicklungskompetenzen (z.B. Design) und Qualitätskomponenten („Joy of Use“) in den Qualitätssicherungsprozess, um so eine ganzheitliche „User Experience“ gestalten zu helfen. Daneben hat Ronald Hartwig das Entwicklungsprojekt für das Prozessdatenmanagmentsystem „XMendeL“ geleitet.
48
REQUIREMENTS-ANALYSE UND GUI DESIGN
Friedrich Strauß
sd&m AG
Thomas-Dehler-Str. 27
81737 München
strauss@sdm.de
www.sdm.de
ABSTRACT
Die Anforderungsermittlung der Benutzerschnittstelle
ist eng mit ihrem Design verbunden. In diesem
Artikel erläutern wir, welches Vorgehen sich in der
Praxis bei sd&m bewährt hat. Wir beschränken uns
dabei
auf
zwei
Aspekte:
Weshalb
ist
Anforderungsermittlung
und
Spezifikation
miteinander verschränkt und welche Techniken sind
am effektivsten, um zu prüfen, ob ein eine
Spezifikation und insb. das GUI-Design die
Anforderungen erfüllt.
Keywords
User
Boards,
Paper
Mockups,
Spezifikation, Requirements-Analyse.
Prototyp,
1. EINLEITUNG
Eine Anforderungs-Analyse
wird nicht dadurch
besser, dass man alle Anforderungen detailliert
dokumentiert. Dazu schildern wir in Abschnitt 2 ein
Vorgehen, das ohne eine aufwändige Anforderungsdokumentation zu hochwertigen Spezifikationen
führt.
Die Aufgabenangemessenheit eines Systems gehört
zu den wichtigsten Eigenschaften für ein gebrauchstaugliches System und hängt von den Funktionen
des Systems wie von der Dialogoberfläche ab. In
Abschnitt 3 erläutern wir, wie mittels MockupTechniken und Evaluationen einfach geprüft werden
kann, ob das spezifizierte System die funktionalen
und nichtfunktionalen Anforderungen erfüllt.
Diese Erfahrungen beziehen sich auf betriebliche
Informationssysteme, die als Individualsoftware von
sd&m konzipiert und implementiert werden.
Typischerweise sind die Projekte zwischen 5 und 50
Bearbeiterjahre groß.
Stuttgart).
Proceedings of the
2. REQUIREMENTS-ANALYSE
Für die Anforderungsanalyse existieren mittlerweile
viele Erhebungsmethoden und Dokumentationstechniken, die jedoch zumeist die Funktionalität im
Fokus haben. Aber auch (Nichtfunktionale)
Anforderungen an die Benutzerschnittstelle und das
Design der Benutzerschnittstelle müssen in der
Spezifikation berücksichtigt werden.
Eine etablierte Requirementsdokumentation sind
zum Beispiel die Volere Snowcards [4]. Hier werden
Anforderungen
einzeln
als
Snowcard
mit
Begründung, Messkriterium für die Umsetzung,
Klassifikation und Anforderer beschrieben. Dies führt
bei unseren Projektgrößen zu mehr als Hundert ggf.
auch mehr als Tausend Anforderungen die
dokumentiert und verwaltet werden müssen.
Bei sd&m wird eine Anforderungsdokumentation a
la Volere oder verwandte Verfahren
nicht
durchgeführt.
Neben
dem
hohen
Dokumentationsaufwand
gibt
es
noch
ein
strukturelles Problem: Bei diesem Vorgehen können
Anforderungskonflikte bei der Analyse nur schwer
entdeckt werden, da die einzelnen Anforderungen
unverbunden nebeneinander stehen. Viele fachliche
Konflikte ergeben sich aber erst aus einer
Kombination von mehreren Anforderungen.
Statt einer vollständigen Anforderungs-Analyse als
eigenständige Phase vor der Spezifikation, wird in
der Regel die Anforderungs-Analyse mit der
Spezifikationsphase verwoben. Am Anfang der
Spezifikation – bei komplexen oder unklaren
Themen ggf. in einer Vorab-Studie – steht die
Festlegung
einer
kurzen
Anforderungs-,
Ausgrenzungs- und Prämissenliste (AAP-Liste) im
Vordergrund. Diese AAP-Listen von typischerweise
3 mal 5-25 Punkten definieren vor allem den
Umfang des Systems, als Basis für eine
Beauftragung durch den Kunden.
Die detaillierten Anforderungen werden implizit
dokumentiert, indem die Spezifikation des Systems
entsprechend erweitert wird. Dies hat zwei wichtige
Vorteile:
Zum
einen
werden
inkonsistente
Anforderungen viel früher und einfacher erkannt, da
sie direkt in das entstehende Daten- GUI- oder
Funktionsmodell integriert werden.
49
Strauß, F.
Abbildung 1 verdeutlicht die zeitliche Verschränkung
von
Anforderungsermittlung
und
Spezifikationsphase. Nach den AAPs werden zuerst
die Anwendungsfälle identifiziert aber dann parallel
zu
Benutzerschnittstelle
und
Datenmodell
spezifiziert und detailliert. Geschäftsprozessanalyse
und -modellierung sind optionale Aktivitäten. Zu
beachten ist, dass die Anforderungsanalyse nicht
direkt mit der Erstellung des AAP-Dokuments endet.
Zur Spezifikationstechnik von sd&m siehe auch
[1,2].
Ergebnisse
AAP-Papier
P1
P2
N1
Anforderungsanalyse
GeschäftsprozessAnalyse
Fachkonzept
Pro je ktgrun dlagen
P1
Z en trale Zie le u .Ra hme nb ed ni gu ng en
P2
Arc hitek turü be rblick
A blä ufe un d Fun ktio nen
F1
Ges chä ftspro ze sse
F2
Anwe nd un gsfä le
F3
Anwe nd un gs uf n ktion en
Daten
D1
Daten mo dell
D2
Da ten typ env erz eichn is
B enu tz erschn ittstelle
B1
Dia logs pe zifik ation
B2
Batch
B3
Druc ka usg ab en
S chnittstellen z u Alt-u nd Nachb arsyste men
S1
Na chb ars yste m-Sc hn itts telle n
S2
Daten migra tio n a us Alts yste men
S3
Einfü hru ng / Mig ratio n
Erg änze nde B au ste in e
E1
Les ea nleitun g
E2
Glos sar
n
e
g
n
ru
e
rd
fo
n
A
l
a
nte e
n
f tio
hasc n
k
n u
igeE tfch
i
ale N
ioktn
nfu
th 1
ic N
N
e
t
p
ze
n
o
tsk
it
n
ch
rse
u
Q
2N
GeschäftsprozessSpezifikation
AnwendungsfallSpezifikation
DatenmodellSpezifikation
DialogSpezifikation
Zeit
Abbildung 1: Zeitlicher Aufriss in der Spezifikation.
3. ANFORDERUNGEN AN DIE
DIALOGOBERFLÄCHE
Wir haben oben beschrieben, dass das explizite
Dokumentieren von detaillierten Anforderungen
aufwändig ist. Konkrete Anforderungen an
Dialogoberflächen sind besonders kompliziert zu
dokumentieren: Eine Anforderung zu beschreiben
ohne eine Lösung vorwegzunehmen, führt schnell zu
sehr abstrakten oder zu umständlich Texten. UseSzenarien sind vielleicht noch die praktikabelste
Technik um vor allem Anforderungen an zu
unterstützende Abläufe zu formulieren.
Gerade für Dialogoberflächen gibt es sehr effiziente
Methoden, um statt einer expliziten Anforderungsermittlung direkt ein GUI-Design zu erstellen bzw.
abzuändern sowie das erstellte Design zu
evaluieren.
Für die Designerstellung bieten sich Paper-Mockups
für den Ablauf und das Grob-Design an, sowie GUIPrototypen für die Detailphase der Spezifikation.
Beim Durchspielen eines Anwendungsfalls anhand
eines Mockups oder Prototypen prüft man, ob das
Design die kritischen Anwendungsfälle geeignet
unterstützt. Benutzer des späteren Systems können
erheblich einfacher Probleme eines GUI-Designs
identifizieren als Anforderungen benennen. Im
folgenden erläutern wir, wie sd&m diese Methoden
beim Erstellen der (GUI-) Spezifikation einsetzt und
welche Vorteile und Nachteile sie besitzen.
3.1 Paper-Mockups
Schwerpunkt bei den Paper-Mockups ist das GrobDesign inkl. Ablauflogik, d.h. wie verteilt sich die
Bearbeitung auf einzelne Fenster bzw. Karteikarten
50
und wie verhält sich der Dialog. Durch die Nutzung
von Papier, Ausdrucken, Post-Ist, Schere usw. wird
ein Dialog viel schneller änderbar als mit DVUnterstützung. Eine gute Einführung zu MockupTechniken bietet [5].
Echte Paper-Mockups werden dabei in manchen
Projekten nicht zusammen mit dem Fachbereich,
sondern nur intern im Team erstellt. Dies hat den
Vorteil, dass Design-Ideen in Ruhe ausprobiert und
umgesetzt werden können; die Fachbereichsmitarbeiter des Kunden prüfen, ob das neue Design
geeigneter ist. Hierzu setzen wir häufig User-Boards
ein,
die
jedoch
abhängig
vom
Kunden
unterschiedlich durchgeführt werden (siehe unten).
Paper-Mockups werden bei sd&m für GUIs erst in
letzter Zeit häufiger eingesetzt. Das Haupthindernis
ist die scheinbar einfache Nutzung von GUIBuildern. Ohne weitere Ergonomie-Kenntnisse
greifen viele Mitarbeiter gerne schon am Anfang zu
einem
GUI-Builder,
um
schnell
optisch
ansprechende
Oberflächen
zu
entwerfen.
Mittlerweile wird aber die Paper-Mockup-Technik in
den sd&m-internen Schools GUI-Gestaltung und
Spezifikation geschult (seit 3 bzw. 2 Jahren). Ein
einmaliges Ausprobieren in einer Schulung reicht bei
vielen Kollegen schon aus, um es dann später auch
in echten Projekten einzusetzen.
Wichtigster Vorteil ist neben der einfachen
Änderbarkeit der klare Low-Fidelity Ansatz:
Ablenkende Diskussionen um Farben, Ausrichtung
von Widgets Beschriftungen, fehlende Elemente wie
Statuszeilen, Menüs usw. werden so gut wie nie
geführt: Den Kundenmitarbeitern ist klar, dass dies
noch nicht das endgültige Design ist. Dieser Vorteil
bleibt erhalten, wenn man beim Feindesign nicht zu
einem echten GUI-Builder, sondern zu MalWerkzeugen wie Powerpoint wechselt.
3.2 GUI-Prototypen
Keine Spezifikation kommt ohne GUI-Prototypen
aus. Ein GUI-Prototyp umfasst zumindest die
statische Präsentation einzelner Fenster, er kann
ggf. auch funktionale Ausschnitte umsetzen und
vereinfachte Datenbanktabellen enthalten (zum
Beispiel mit Microsoft Access programmiert). In
diesem Sinne sind die oben beschriebenen PaperMockups genauso GUI-Prototypen, wie Visual-Basic
Entwürfe oder die Programmierung der Oberfläche
in der Zielplattform.
Fast alle Informationssysteme sind sehr datenlastig:
Das Dialog-Design ist hier immer auch ein Kampf
um das Layout, wobei viele Daten gleichzeitig
darzustellen sind und man trotzdem eine
strukturierte,
übersichtliche
Oberfläche
mit
geeigneten Widgets definieren möchte. Mit einem
Paper-Mockup (bzw. einem Malwerkzeug) kann man
nicht sinnvoll entscheiden, ob noch drei weitere
Felder auf eine Karteikarte passen oder nicht. Ist
das (erste) Grobdesign fertig, dann lohnt bei solchen
Fragestellungen der Wechsel zu einem GUI-Builder.
Sind doch noch Änderungen am Grobdesign nötig,
sollte man ruhig zur Papier-Mockup Technik
zurückwechseln – unter Nutzung von zurechtgeschnittenen Ausdrucken!
Problematisch
ist
der
Bau
von
Oberflächenprototypen mit GUI-Buildern und insb.
Access, weil es dazu verleitet Funktionalität
einzubauen. Bei Nutzung von Access werden gerne
Tabellen angelegt und mit Testdaten gefüllt, sowie
elementare Funktionen in Basic programmiert.
Der Aufwand dieser Prototypprogrammierung – die
über die Erstellung statischer Präsentationen
hinausgeht – zahlt sich häufig nicht aus. Da das
System sehr datenlastig ist und sich die
Anforderungen in der Spezifikation doch noch häufig
ändern, erreicht der Prototyp selten eine
ausreichende
Qualität,
um
ernsthafte
Fragestellungen zu beantworten. Hier sind ein oder
zwei zusätzliche User-Board WKS effektiver,
außerdem wird die Konzentration auf die
Spezifikation so auch besser sichergestellt – beim
Prototyp-Programmieren aber ohne ein paar schöne
Schnörkel auszukommen, fällt wahrscheinlich nicht
nur sd&m-Mitarbeitern schwer.
Auch das von Projektleitern manchmal anvisierte
Sparziel, den Prototyp-Code aus der Spezifikation in
der Programmierung weiterverwenden zu können,
wird selten erreicht, da doch viele Korrekturen und
ggf. Redesigns nötig sind.
Sinnvoll ist ein funktionaler Prototyp, um neue
Konzepte exemplarisch vorzuführen. Die Nutzung
von dynamischen Fensterbereichen und Split-Panes
versteht ein Sachbearbeiter am einfachsten am
Beispiel.
Statt eines GUI-Builders wird manchmal auch Visio
oder auch Powerpoint für das Design der Oberfläche
genutzt. Hier ist die Bedienung noch einfacher, die
Konzentration auf das Wesentliche fällt wegen der
Low-Fidelity Technik einfach. Zudem sind die
Grafiken leider bequem skalierbar, was zu einer
gefährlichen Situation führen kann: Erst die spätere
Programmierung mit Standardcontrols zeigt, ob man
alle Widgets in der Standardgröße unterbringen
kann. Nicht immer findet sich eine so einfach
Lösung wie in einem ernsten Problemfall im
Bankbereich: statt eines aufwändigen Redesigns,
wurden die 25 Benutzer mit extra großen Monitoren
ausgestattet.
3.3 User-Boards
User-Boards sind bei uns Workshops mit 1-6
Benutzern des späteren Systems. In diesen
Workshops werden Dialogentwürfe auf gute
Bedienbarkeit und Vollständigkeit bzgl. der nötigen
(GUI-) Funktionalität evaluiert. Außerdem nehmen
2-4 Personen des Projektteams (inkl. Kunden-IT)
teil, ein Ergonomie-Experte wird nur in kritischen
Projekten hinzugezogen. Die Ausgestaltung der
Workshops ist in Abhängigkeit von Kunde und
Projekt sehr unterschiedlich. Zwei wichtige
Kernelemente
gibt
es
aber
immer:
Die
Dialogentwürfe
werden
auf
großen
Papierausdrucken (teilweise größer als DIN A0) oder
auf Overhead-Folie mitgebracht. Zu einem
Teilbereich werden jeweils von den Benutzern
praktische
Anwendungsfälle
genannt
(oder
vorbereitet mitgebracht). Die Bearbeitung wird dann
mit den Dialogentwürfen anhand konkreter Daten
durchgespielt. Dabei werden bei Papierausdrucken
gerne Post-Its zum Beschreiben genutzt. Dagegen
war das Durchspielen eines Prototyps am Beamer
häufig weniger effektiv. Anscheinend hilft der
Einsatz von Low-Fidelity Techniken, um sich auf die
wichtigen Aspekte zu konzentrieren.
Das konkrete Durchspielen zusammen mit dem
Fachbereich ist eine der effektivsten Maßnahmen.
Dadurch können wir überflüssige Funktionen finden,
inkonsistente oder unvollständige Abläufe entdecken
und Hinweise zu anderen Bereichen der
Spezifikation wie dem Datenmodell oder auch zu
Geschäftsprozessen erhalten.
Die durchgespielten Beispielanwendungsfälle (Use
Szenarien)
haben
wir
manchmal
explizit
dokumentiert, sind damit aber wenig glücklich
geworden. Im Nachhinein stellte sich häufig raus,
dass die Dokumentation nach der Erstellung nicht
weiter genutzt wurde. Die richtige Granularität der
Beschreibung
zu
finden,
ist
eine
der
Herausforderungen. In den Workshops einigte man
sich in der Regel schnell auf bestimmte interessante
fachliche
Konstellationen
und
für
das
Spezifikationsteam reichte in der Regel die
Dokumentation der Datenkonstellation oder ggf. die
nötige Bearbeitungsreihenfolge.
Diese User-Boards sind in der wissenschaftlichen
Literatur als Review- bzw. Evaluationstechniken mit
unterschiedlichen Schwerpunkten unter vielen
Namen bekannt. Cognitive-Walkthrough ist die
gängige Bezeichnung bei der Evaluation durch
einen einzelnen Benutzer. Unser Vorgehen
entspricht meistens dem simplified Thinking aloud
wie es zum Beispiel im Discount Usability
Engineering Approach von J. Nielsen [3]
beschrieben ist.
4.
EIN BEISPIELPROJEKT
In einem Projekt im Automotive Bereich haben wir
das Stammdaten-System für die Plausibilisierung
von PKW-Aufträgen inklusive der bestellten Sonderausstattungen konzipiert. Die Baubarkeit für die ca.
200 verschiedenen PKW-Typen und der weit mehr
als 700 möglichen Sonderausstattungen wird durch
komplexe Regeln definiert: ein Navigationssystem
kann zum Beispiel nur zusammen mit einem Radio
für die Anzeige bestellt werden, verhindert aber
gleichzeitig den Einbau eines CD-Wechslers bei
PKWs mit Klima-Anlage (aus Platzproblemen) … .
In einem Fachgrobkonzept wurde die Such- und
Pflegeoberfläche für die Regeln konzipiert. Eine
wichtige Anforderung war, möglichst wenige Fenster
51
Strauß, F.
zu verwenden. In einem ersten Design wurde daher
in einem Top-Down Ansatz versucht, die
Fensterzahl durch Nutzung von Treeviews und
Karteikarten einzudämmen und trotzdem die
hierarchische Struktur der Daten sichtbar zu machen
sowie flexible Zugriffsmöglichkeiten auf das
komplexe Datengeflecht zu ermöglichen.
Erst bei der Verfeinerung des Fachkonzepts wurden
insgesamt sieben anderthalbtägige User-Board
Workshops durchgeführt. Beim Durchspielen von
Use-Szenarien, die vom Fachbereich genannt
wurden, konnten relativ schnell Anforderungen an
die gleichzeitige Anzeige von Suche, Ergebnisliste
und ggf. auch des Bearbeitungspanels entdeckt
werden.
Zudem stellte sich raus, dass die übergeordnete und
bekannte Struktur der Daten in Codes, Gültigkeiten,
Kontexte usw. nicht kompakt visualisiert werden
muss. Hier wurde ein dynamisches Layout
eingeführt, bei dem Suche, Ergebnisliste und
Bearbeitung in einem Fenster in drei horizontale
Split-Panels gemeinsam dargestellt werden. Jedes
Panel kann ausgeblendet werden, so dass ggf. die
Ergebnisliste oder die Bearbeitung auch das
gesamte Fenster einnehmen können.
Neben dieser Änderung des Grobdesigns erwies
sich das konkrete Durchsprechen aller Dialoge in
den WKS auch als die geeignete Form, um die
Anforderungen
an
Suchmöglichkeiten
,
Ergebnislisten usw. zu ermitteln und abzustimmen,
und um einige überflüssige (weil nicht der
Arbeitsweise
entsprechend)
Suchund
Bearbeitungsfunktionen wieder aus der Spezifikation
zu entfernen.
Interessant ist in diesem Zusammenhang auch die
Tatsache, dass das endgültige Design einen guten
ergonomischen Qualitätsstandard hat, obwohl kein
Usability-Spezialist dabei war. Es war ausreichend,
das im Team Mitarbeiter die Mockup-Technik (vor
allem intern genutzt) und die User-Boards zum
Analysieren eines Designs kannten und angewendet
haben.
5. ZUSAMMENFASSUNG
Ausgrenzungen und Prämissen AAPs für den
Systemumfang zusammen mit einer Spezifikation
sinnvoller ist als eine eigenständige AnforderungsAnalyse und - dokumentation.
Vor allem mit Hinblick auf ein aufgabenangemessenes System ist es wichtig, dass die
funktionale Spezifikation und das GUI-Design über
User-Boards zusammen gebracht werden und direkt
durch Kunde und Spezifikationsteam evaluiert
werden. Dies ist mit Mockups bzw. GUI-Prototypen
und
User-Boards
einfach
möglich.
Bei
Designkonflikten oder sich widersprechenden
Anforderungen kann hier auch sinnvoll entschieden
werden, ob das Design einen akzeptablen
Kompromiss darstellt.
Diese
Methoden
können
von
einem
Spezifikationsteam einfach erlernt werden und dann
auch ohne Usability-Experten durchgeführt werden.
Leider ist die Informatik Ausbildung derzeit in
Deutschland meist noch nicht mal in der Lage, diese
Methoden
zu erwähnen, geschweige denn zu
einzuüben.
6. REFERENCES
[1] Kretschmer, D., Krug, W., Stutz, C.
Siedersleben, J.: Analysis beyond UML. In
Proceedings of the RE'02: IEEE Joint
International Requirements Engineering
Conference 2002, S. 215.
[2] Krug, W., Siedersleben, J: Bausteine zur
Spezifikation. In Siedersleben J. (Hrsg.),
Softwaretechnik, Hanser (2002).
[3] Nielsen, J., Guerrilla HCI: Using Discount
Usability Engineering to Penetrate the
Intimidation Barrier. In Bias, R. G., Mayhew, D.
J., Cost-Justifying Usability. Academic Press
(1994).
[4] Robertson, J. und S.: Mastering the
Requirements Process. London: AddisonWesley (1999).
[5] Snyder, C.: Paper Prototyping. Morgan
Kaufmann (2003).
Wir haben erläutert, warum eine Mischung aus
Anforderungsdokumentation durch Anforderungen,
52
Referent
Dr. Friedrich Strauß, arbeitet seit 1995 bei sd&m in Projekten als Programmierer,
Spezifikateur, Chef-Designer und Projektleiter über alle Phasen. Nebenbei unterstützt er
bei sd&m das Wissensmanagement zur Ergonomie und ist Referent bei internen
Schulungen zum Design graphischer Oberflächen und zur Spezifikationsmethodik. Als
stellvertretender Sprecher der GI-Fachgruppe Software-Ergonomie will er darauf
hinwirken, dass die in der Praxis wichtige Verbindung zwischen Software-Engineering
und Software-Ergonomie auch Eingang in die Informatik-Ausbildung findet.
53
SPRACHE UND MULTIMODALITÄT
PRAXISBERICHT ZUR GESTALTUNG AUDITIVER
BENUTZUNGSOBERFLÄCHEN
Palle Klante
Kuratorium OFFIS e.V.
Escherweg 2
26131 Oldenburg
klante@offis.de
http://www.offis.de
ABSTRACT
Der Bericht gibt einen Einblick in die praktischen
Probleme, die bei der theoriegeleiteten Gestaltung
von auditiven Benutzungsoberflächen auftreten. Auf
Grundlage mehrerer Projekte zur Entwicklung von
auditiven Benutzungsoberflächen ist eine verallgemeinerte Vorgehensweise entstanden, die in
anderen Projekten als Handlungsrahmen eingesetzt
werden kann. Wichtiges Prinzip bei der Vorgehensweise ist die strikte Trennung von Dialogstruktur, Entwicklung von Interaktionsobjekten und
dem Sounddesign.
Keywords
Auditory User Interface, Hearcon, Multimodal
Interaction, Usability Engineering, Sounddesign
•
Intensitätsunterschiede, die normalerweise für
die Entfernungsschätzung genutzt werden,
bekommen plötzlich eine andere Bedeutung.
•
Grosse
Anzahl
Geräusche.
•
Ständige Konzentration auf die Soundausgabe.
•
Lokalisation der Geräusche an der exakten
Position durch zielgerichtetes Vorgehen.
•
Differenzierung mehrerer Soundquellen und
korrekte Zuordnung von Soundquelle und
Position.
•
Interaktion mit einem Objekt, welches nicht real
(für den Benutzer kein greifbarer Gegenstand)
vorhanden ist.
•
Permanentes Erklingen der Geräusche, die nur
durch
Interaktion
leiser
werden
oder
verschwinden.
•
Erkennung der Interaktionsmöglichkeiten mit
einem
Objekt
und
Identifizierung
der
Funktionalität.
•
Trennung der Geräusche aus dem realen
Umfeld und der virtuellen Welt.
1. EINLEITUNG
Zur Einführung in die Problematik eine kurze
Beschreibung eines typischen Szenarios: Erklärt
man potentiellen Benutzern vor einer Evaluation die
Versuchsdurchführung und den Gegenstand der
Evaluation, kommen die Probanden zunächst zu
dem Schluss: „Dies macht bestimmt keine
Schwierigkeiten. Ich kann gut hören und außerdem
benutze ich meine Ohren ja den ganzen Tag.“ Die
anschließende Versuchsauswertung macht deutlich,
dass insbesondere bei Untersuchungen mit räumlich
angeordneten Soundquellen eine Reihe von
Problemen auftreten:
•
Identifizierung künstlich erzeugter Sounds, die
nicht aus der eigenen und bekannten
Erfahrungswelt stammen.
•
Erlernen
dieser
Geräusche.
vollkommen
fremden
Proceedings of the
gleichzeitig
erklingender
Der gewünschte Grad an Realismus ist nur schwer
zu erreichen und die tatsächliche auditive Ausgabe
weicht von der theoretisch möglichen Ausgabe ab.
Die Probleme betreffen nicht nur die potentiellen
Benutzer, sondern auch die Gestalter des interdisziplinären
Designerteams
der
auditiven
Benutzungsoberflächen. Sie treten schon während
des Entwicklungsprozesses auf und müssen dort
berücksichtigt werden. Darüber hinaus liegen die
Schwierigkeiten während der Entwicklung noch an
anderen Stellen:
•
Zeitabhängigkeit des Mediums.
•
Ein „Screenshot“ spiegelt den Systemzustand
nicht wider.
•
Minimale Auflösung einer auditiven Benutzungsoberfläche und mangelnde Darstellungspräzision.
•
Ungenügende Vorstellungskraft, wie sich die
tatsächliche auditive Ausgabe zu einer
57
Klante, P.
grafischen Darstellung anhört.
•
Interdependenzen zwischen den einzelnen
Geräuschen, die zu falschen Informationsdarstellungen führen können.
•
Komposition der Geräusche und Interaktionsmöglichkeiten müssen gekoppelt werden und
sind frühzeitig zu klären.
•
Wenig
vorhandenes
Basiswissen
und
Erfahrungen auf das Designentscheidungen
gelegt werden kann.
•
Kommunikationsproblem, da nicht auf einzelne
Objekte in einer Ausgabe gezeigt werden kann.
Die genannten Probleme haben ihren Ursprung in
der auditiven Informationspräsentation und unterscheiden sich deutlich von der Gestaltung und dem
Vorgang der Gestaltung von grafischen Benutzungsoberflächen.
2. AUDITIVE
BENUTZUNGSOBERFLÄCHEN
Obwohl Akustik als Medium zur Kommunikation und
Darstellung von Sachverhalten in unserer Umwelt
verwendet wird, hat es relativ spät Einzug zur
Bedienung von Rechnern erhalten. Es dient dort nur
zur redundanten Darstellung primär grafisch präsentierter Informationen oder zur Ausgabe von
Warnungen und ist damit eher negativ vorbelastet.
Zur Einordnung der hier beschriebenen auditiven
Benutzungsoberflächen eine kurze Kategorisierung:
Im Wesentlichen kann die Unterscheidung zwischen
einer Sprachausgabe, bei der die Ausgabe von
Informationen über einen Sprachdialog erfolgt und
einer nicht-sprachlichen Ausgabe erfolgen. Die
Sprachausgabe ist ein serielles Medium, welches
nur langsam und schrittweise Informationen ausgibt
und eine Exploration des Datenbestandes nur
schwer zulässt. Nichtsprachliche Ausgaben sind
hingegen von Parallelität geprägt. Sie können
gleichzeitig mehrere Objekte darstellen und geben
einen Überblick.
Gegenstand dieser Arbeit sind die nichtsprachlichen
Benutzungsoberflächen, die sich dem Benutzer über
Töne, Klänge, Musik oder Geräusche präsentieren.
Vorreiter auf konzeptioneller Ebene sind die
Arbeiten von Blattner [1] zu Earcons, wo einfache
Töne genutzt werden, die zu Klängen erweitert
werden, um Objekte und Hierarchien darzustellen.
Eine Kombination von verschiedenen Tönen kann
eine bestimmte Position in einer Hierarchie angeben
oder verdeutlichen, welche Funktionalität auf ein
Objekt angewendet werden kann. Dieses Konzept ist
für eine große Menge an Informationen gut
geeignet, hat jedoch Schwächen bei der
Erlernbarkeit der Bedeutung der verwendeten
Klänge. Hingegen haben die Auditory Icons von
Gaver [2] als Grundidee, die Verwendung von
assoziativen Geräuschen, die in der natürlichen
Umwelt (Everyday Listening) existieren und bei
58
denen der Benutzer beim Hören des Geräusches
sofort eine Vorstellung von dem zugehörigen Objekt
bekommt. Diese Codierung ist leicht zu erlernen, hat
aber auch Nachteile: Nicht für alle Objekte
existieren entsprechende Geräusche und sie werden
als unangenehm wahrgenommen, wenn man sie
dauerhaft hört. Die Lösung zur Wahl geeigneter
Sounds liegt in der geschickten Kombination dieser
beiden Soundkonzepte.
2.1 Hearcons
Wie der angegebenen Literatur zu entnehmen ist,
sind entsprechende Konzepte zum Sounddesign
relativ alt, was nicht zuletzt auch auf die zur
Verfügung stehende Soundhardware zurückzuführen
war. Diese Situation hat sich durch die Verbreitung
adäquater Soundhardware, die stereophonische
Soundausgaben ermöglichen, geändert. Es stehen
somit mittlerweile innovative auditive Interaktionsmöglichkeiten zur Benutzung von Rechnern zur
Verfügung. Entscheidendes Attribut ist die Dreidimensionalität. Objekte können in einem virtuellen
akustischen Interaktionsraum positioniert werden.
Diese Phantomgeräusche werden Hearcons [3]
genannt und sind permanent klingende Objekte mit
•
einem spezifischen Geräusch,
•
einer bestimmten Schallintensität,
•
einer Position im Raum und
•
einer Interaktionsfläche.
Hearcons sind die kleinste Komponente in einer
auditiven
Benutzungsoberfläche
und
alle
Interaktions- und Informationsobjekte werden aus
ihnen entwickelt. Diese Objekte bestehen dabei
unter Umständen aus mehr als einem Hearcon. Die
Umsetzung der Codierungsattribute wird im
Folgenden genauer beschrieben und an zwei
Szenarien erklärt.
2.2 Anwendungsbeispiele
Zwei kurze Beispiele erläutern die Einsatzmöglichkeiten für auditive Benutzungsoberflächen:
Im Projekt „Zugang zum Internet für Blinde“ [4]
wurde ein auditiver Webbrowser (AirClient) für
blinde Rechnerbenutzer entwickelt. Ziel war die
Abbildung des Layouts einer Webbseite unter
Beibehaltung der Topologie und Topographie in
einem auditiven Interaktionsraum. Dazu wird die in
einem grafischen Browser gerenderte Darstellung
einer Webseite mit ihren Objekten ausgelesen und
auf eine virtuelle auditive Wand vor dem Benutzer
im auditiven Interaktionsraum übertragen. Unterschiedliche Kategorien von Typen wurden bestimmt
und jedem Typ ein Hearcon zugeordnet. Der blinde
Benutzer kann nun mit einem Eingabegerät die
Webseite auditiv explorieren, wobei die sog. Fackelmetapher angewendet wird.
Die Umsetzung eines mobilen auditiven MP3Players
[5]
verfolgt
die Darstellung von
Hierarchiestrukturen, wie sie von typischen Menüs
bekannt sind. Tragbare MP3-Player werden immer
kleiner,
wobei
Grenzen
hinsichtlich
der
Benutzbarkeit existieren. Häufig wird auf ein Display
verzichtet, um den Formfaktor zu minimieren,
wodurch als Nebeneffekt das System ohne
Feedback-Mechanismen bedient werden muss. Dies
widerspricht jedoch der Tendenz eine immer
größere Titelauswahl anzubieten und dem Wunsch
mehr Funktionalität in das System zu integrieren.
Die Lösung ist eine auditive Steuerung, besonders
weil die technischen Rahmenbedingungen schon
existieren und akustische Inhalte verwendet werden.
3. GESTALTUNGSPROZESS
Die Lösung der oben angegebenen Probleme kann
durch ein strukturiertes zielgerichtetes Vorgehen
erreicht werden, indem die Designkomplexität
minimiert wird. Entscheidend ist die frühzeitige
Identifizierung und Eliminierung der vielfältigen
Abhängigkeiten, um so eine geeignete Grundlage
für die Gestaltung zu schaffen. Als Grundlage des
Auditory Usability Engineering Process dient eine
weiterentwickelte Form von Mayhew [6] und des ISO
Human-Centred Design Processes for Interactive
Systems [7]. Dies sieht einen iterativen, sowohl
vertikal, als auch horizontal mehrschichtigen
Prozess vor. Auf die schnelle und kostengünstige
Entwicklung von Prototypen und deren Evaluation
ist aufgrund der Lücken in den Designprinzipien
dringend zu achten.
Abbildung 1: Entwicklungsphasen sind vertikal und
horizontal getrennt
In der Anforderungsanalyse werden erste Unterschiede deutlich. Es sind die Benutzercharakteristika
(z.B. Hörvermögen des Benutzers), der Kontext der
Bearbeitung (z.B. arbeitet der Benutzer allein oder
ist er auf die Kommunikation mit anderen
angewiesen), die Umgebung (z.B. befindet er sich in
einem lauten Umfeld) sowie die Eigenschaften des
zur Verfügung stehenden Systems (z.B. vorhandene
technische
Ausstattung,
Kopfhörer)
die
entscheidenden Aspekte. Die Analyse der zu
bearbeitenden
Aufgaben
unterscheidet
sich
hingegen nicht von der Vorgehensweise bei anderen
interaktiven Systemen. Das Hinzuziehen von
Design-Prinzipien und Grundsätzen ist problematisch, da sie für die Interaktion in auditiven Be-
nutzungsoberflächen noch nicht ausreichend existieren. Erste verstreute Ansätze sind gemacht, aber
es bedarf einer tieferen Auseinandersetzung mit der
Materie um die wichtigsten Regeln aufzunehmen.
Hier wird noch im Einzelfall entschieden und nicht
regelbasiert die Suche auf einen bestimmten Aspekt
gelenkt. Im Vorfeld eines Projekts sollten Designrichtlinien erstellt werden, welche weniger detailliert
sind. Sie sollten nur die wichtigsten Designphilosophien festhalten (etwa Art der Interaktion
oder zu verwendende Metapher).
Das iterative Entwerfen, Testen und Entwickeln
gliedert sich bei Mayhew in drei Ebenen, in denen
der Detaillierungsgrad stetig zunimmt. In dieser
Phase hat es sich für die Entwicklung von auditiven
Benutzungsoberflächen bewährt, eine Trennung vorzunehmen (vgl. Abb.1): Es gibt weiterhin in der
Vertikalen die drei Phasen Design, Prototyping und
Evaluation mit der Überprüfung, ob die Designrichtlinien eingehalten worden sind. In der
Horizontalen findet eine Aufteilung zwischen dem
dialogbezogenen, dem objektbezogenen und dem
geräuschbezogenen Teil der Benutzungsoberfläche
statt. Die Trennung ist notwendig, da die Interaktionsobjekte noch nicht vollständig entwickelt sind
und für jedes Projekt neu adaptiert werden müssen.
Sie können somit unabhängig von der Dialogstruktur
ausgetauscht und einzeln entwickelt werden.
3.1 Designphase
Ziel
ist
die
schnelle
Integration
der
Interaktionsobjekte in die Dialogstruktur, um die
Entwicklung des Systems in mehreren Teams zu
ermöglichen. Die einzelnen Komponenten (vgl.
Abb.2): Dialogstruktur, Interaktionsobjekte und
Sounddesign können unabhängig voneinander
evaluiert werden und für die Erstellung von MockUps oder Prototypen jederzeit zusammengefügt
werden. Für diesen Schritt sollte ein Entwicklungstool wie VisualAID [8] verwendet werden, mit dem
die am Prozess beteiligten Personen (Entwickler,
Psychologe, Musiker, Komponist, Physiker, Interface
Designer, Interaktionsspezialist) gemeinsam die
Oberfläche erarbeiten können.
3.1.1 Dialogdesign
Die Entwicklung der Dialogstruktur ist das federführende Element im Entwicklungsprozess. Sie
orientiert sich am Storyboard und dem Szenenkonzept. Aus der Aufgabenanalyse heraus werden
Hauptaufgaben identifiziert, die zu Teilaufgaben
verfeinert werden. Diese Teilaufgaben werden in
einem Storyboard exakt beschrieben und dabei ihr
Zusammenspiel überprüft. Anschließend wird das
Storyboard in einen Szenenbaum überführt. Szenen
spiegeln entscheidend die Haupteigenschaft von
Akustik durch ihre Dynamik wieder und unterstützen
somit den zeitlichen Charakter der Akustik. Der
Zustand der Benutzungsoberfläche verändert sich
ständig.
In
ersten
Versuchen wurde die
Dialogstruktur noch mit Hilfe von Papierskizzen
59
Klante, P.
entworfen, was bei häufigen Änderungen sehr
mühsam ist. Zudem wird die Dynamik des Mediums
dort nicht entsprechend dargestellt.
Abbildung 2: Designebenen und Ergebnisdokumente
Als Konzept wird die von Shneiderman postulierte
Aufteilung von Informationen zur Visualisierung von
grossen Datenmengen (Visual Information Seeking
Mantra) [9] genutzt: Die Benutzungsoberfläche
ermöglicht zunächst dem Benutzer sich einen
Überblick über die angebotenen Objekte zu verschaffen. Anschließend wird automatisiert oder vom
Benutzer eine Auswahl getroffen, die den darzustellenden oder interessanten Bereich weiter
minimiert. Hierzu können Filter, Hierarchieinformationen oder Zooms genutzt werden. Schließlich
kann ein Objekt ausgewählt werden und der
Benutzer bekommt auf Anfrage weitere Informationen.
3.1.2 Objektdesign
Die Gestaltung der Interaktionsobjekte beschreibt
auch die Ausgestaltung der vorher in der Dialogstruktur festgelegten Szenen. Für jede Szene (als
eigenständiges Interaktionsobjekt) werden die
äußeren Rahmenbedingungen beschrieben, etwa
die
akustischen
Eigenschaften
des
zu
verwendenden virtuellen Raumes. Der Benutzer
interagiert nur mit den Interaktionsobjekten innerhalb
einer Szene. Sie ermöglichen es Verarbeitungen
anzustoßen oder eine Szene zu verlassen. Es sollte
dabei versucht werden mögliche Standardaufgaben
zu finden, um für die Wiederverwendbarkeit der
Interaktionsobjekte zu sorgen.
Im Beispiel des AirClients ist dies etwa die Darstellung der Layoutstruktur in einer Szene. Der
Benutzer bekommt Inhalts- und Navigationsbereiche
angeboten, mit denen er interagieren kann. Im
AirClient können diese Bereiche mit einem
Zeigegerät
selektiert
werden
und
weitere
Informationen dazu mit einer Sprachinteraktion
abgefragt werden. Der Bereich kann aber auch
aktiviert werden und die darin befindlichen Objekte
werden präsentiert. Da sich die Form der Interaktion
innerhalb eines ausgewählten Bereiches (die
Objekte sind in einer Hierarchie strukturiert) von der
Interaktion in der Hierarchiestufe darüber unter-
60
scheidet, wird eine neue Szene initiiert und der
Inhalt darin angeboten.
Beim MP3-Player befindet sich das Hauptmenü in
einer
Szene.
Dieses
stellt
mehrere
Untermenüpunkte dar, die Funktionen des MP3Players steuern. Der Benutzer kann über seine
Cursortasten ein Untermenüpunkt auswählen, etwa
zur Erzeugung von Playlisten oder zum Starten
einer vorhandenen Playliste. Die Auswahl von
Untermenüpunkten findet entsprechend in der
gleichen Szene statt. Wird hingegen eine Funktion
ausgelöst, wird eine neue Szene generiert.
3.1.3 Sounddesign
Die Problematik des Sounddesign steht im Vordergrund der Entwicklung auditiver Benutzungsoberfläche. Um die Komplexität zu verringern,
erfolgt ein Sounddesign zunächst auf Basis der
Interaktionsobjekte. Weitere anwendungsbezogene
Sounds werden erst nach der Integration entworfen.
Die Kommunikation mit den Musikern und Komponisten erfolgt im Vorfeld deskriptiv. Es findet eine
exakte Beschreibung der gewünschten Geräusche
über Attribute statt. Die Deskriptoren sind leider
nicht vereinheitlicht und jeder Mensch hat
unterschiedliche Empfindungen beim Hören eines
Geräusches oder nimmt es anders wahr. Nach dem
Mapping der Geräusche auf die Interaktionsobjekte
sollte das Ergebnis erneut vom Musiker auf die
Einhaltung seiner Überlegungen und auf die nötige
Synchronität der Geräusche überprüft werden.
Zudem konkurrieren die Soundattribute miteinander:
Hat man gerade einen Sound gefunden, der eine
besonders gute Frequenzaufteilung für eine Lokalisation hat, ist es möglich, dass er nach einiger Zeit
für den Anwender unangenehm ist. Oder man findet
ein Geräusch, welches auch über einen längeren
Zeitraum von den Benutzern als angenehm
empfunden wird und es stellt sich heraus, dass die
tiefen Frequenzanteile in dem Geräusch dafür
sorgen, dass es nur schlecht lokalisiert werden kann.
Die technischen Einflussfaktoren auf der Ausgabeseite sind nicht zu vernachlässigen. Es konkurrieren
Standards, die es nötig machen eine möglichst
offene Architektur zu finden, in der auch
verschiedene Endausgabegeräte berücksichtigt
werden.
3.2 Evaluationsphase
Die Verwendung diverser Evaluationsmethoden
muss auf die genutzten Modalitäten abgestimmt
werden. So kann bspw. das „Laute Denken“ nur
eingeschränkt
verwendet
werden,
da
der
Versuchsteilnehmer nur sprechen kann, wenn keine
Soundausgabe erfolgt. Die Kommunikation zwischen
Versuchsteilnehmer
und
Versuchsleiter
wird
erschwert, wenn der Versuchsteilnehmer Kopfhörer
verwendet, bzw. sich auf die akustischen Signale
konzentrieren muss.
Dreidimensionale auditive Ausgaben können nicht
direkt mit herkömmlichen Methoden, etwa der
Videoaufzeichnung, gespeichert werden. Aus
diesem Grund ist eine Abbildung der Informationen
in einen grafischen Darstellungsraum notwendig. Zur
Beantwortung der Frage, wie die Akustik adäquat
über eine grafische Ausgabe dargestellt werden
kann, konzentriert man sich auf die primären
Codierungsattribute. Da wichtige Informationen über
Lautstärke und Art des Geräusches codiert werden,
müssen diese beiden Parameter in die grafische
Ausgabe integriert werden. Zusätzlich müssen alle
relevanten Informationen in einer Datenbank mitprotokolliert werden, um auditive Szenen nachstellen zu
können. Typischerweise ist es notwendig, vorhandene Anwendungen um diese Funktionalität zu
erweitern.
4. ZUSAMMENFASSUNG
Die Beschreibung typischen Probleme nach der
Auswertung einer Evaluation zu auditiven Benutzungsoberflächen, ermöglicht einen Einblick in
die erzielten Ergebnisse. Die Vielzahl kleinerer
Probleme und deren Interdependenzen machen es
notwendig, eine möglichst starke Trennung der
Entwicklungsschritte vorzunehmen.
Bei der Entwicklung hat sich eine Trennung in
Dialogstruktur, Entwicklung von Interaktionsobjekten
und dem eigentlichen Sounddesign bewährt.
Während der Entwicklungsphase können diese
Komponenten regelmäßig zusammengeführt und
einzeln, aber auch gemeinsam, evaluiert werden.
Auf dem Gebiet des zur Verfügung stehenden
Basiswissens besteht noch deutlicher Forschungsbedarf. Hier fehlen vor allem wichtige Grundlagenexperimente. Aber auch Guidelines und Styleguides,
die direkt für eine bestimmte Benutzergruppe für
definierte auditive Benutzungsoberflächen in einem
bestimmten Kontext und für bestimmte Aufgaben
konzipiert werden und dem Entwickler in seiner
aktuellen Gestaltungsaufgabe unterstützen.
Während der Entwicklung auditiver Benutzungsoberflächen ist ständig darauf zu achten, dass die
theoretischen Überlegungen auch in kostengünstig
erstellten Prototypen überprüft werden, um den
Mangel an Erfahrungen auszugleichen.
5. REFERENCES
[1] Blattner, M.M., Sumikawa, D.A., und Greenberg,
R.M. Earcons and Icons: Their Structure and
common design principles. In Journal of HCI,
Special Issue on Nonspeech Audio; V4, N1,
Lawrence Erlbaum Associates. (1989).
[2] Gaver, W.W., The SonicFinder: An Interface
that uses Auditory Icons In Journal of HCI,
Special Issue on Nonspeech Audio; V4, N1,
Lawrence Erlbaum Associates. (1989).
[3] Bölke, L. und Gorny, P., Direkte Manipulation
akustischer Objekte. In D.Böcker (Hg):
Proceedings Software-Ergonomie ’95. Teubner
Verlag, Stuttgart (1995).
[4] Donker, H., Klante, P. und Gorny, P. The Design
of Auditory User Interfaces for Blind Users. In
Proceedings of the Second Nordic Conference
on Human-Computer Interaction NordiCHI,
Association for Computing Machinery (2002).
[5] Klante, P. Mobiler MP3-Player mit auditiven
Interaktionsobjekten. http://www-cghci.informatik. uni-oldenburg.de/~klante/wabo
(2003)
[6] Mayhew, D., The usability engineering lifecycle:
a practitioners handbook for user interface
design. Morgan Kaufmann, San Francisco, USA
(1999).
[7] ISO 13407. Human-Centred Design Processes
for Interactive Systems. International
Organization for Standardization (1999).
[8] Klante, P. Visually Supported Design of Auditory
User Interfaces In Human-Computer Interaction:
Theory and Practice Volume 2 of the
th
Proceedings of the 10 HCI International 2003,
Crete, Greece, Lawrence Erlbaum Associates
(2003).
[9] Shneiderman, B., Information visualization:
Dynamic queries, starfield Displays, and Life
Lines http://www.cs.umd.edu/hcil/
members/bshneiderman/ivwp.html (2003)
61
Klante, P.
Referent
Palle Klante arbeitet seit vier Jahren beim Oldenburger Forschungs- und
Entwicklungsinstitut für Informatik-Werkzeuge und –Systeme (OFFIS) im INVITE
Teilprojekt „Zugang zum Internet für Blinde“. Seit 2000 arbeitet er an seiner Dissertation
zur „Gestaltung auditiver Benutzungsoberflächen“ an der Universität Oldenburg. Er
studierte Informatik in Oldenburg und machte 1999 sein Diplom in der Abteilung SoftwareErgonomie & Computer Graphics.
Sein Arbeitschwerpunkt ist die Entwicklung eines Usability Engineering Prozesses zur
Erstellung von auditiven Benutzungsoberflächen. Dazu entwickelt er Methoden, Tools und
Interaktionsobjekte, die in allen Prozessphasen das Entwicklungsteam unterstützen.
62
USER MODELLING IN A DIALOG SYSTEM
Ralf Kompe, Martin Emele, Silke Goronzy, Robert Mencl, Sunna Torge
Sony International Europe (GmbH) Sony Corporate Labs Europe
Advanced Software Lab
Hedelfinger Str. 61
D-70327 Stuttgart
{kompe, emele, goronzy, mencl, torge}@sony.de
ABSTRACT
In people’s home the amount of on-line available
digital content such as video, music, or pictures is
rapidly increasing. First home server products are
available. Efficient selection of content will be a
problem for users. We developed a flexible multimodal dialog system to overcome this. A keycomponent is the user model, which learns very fast
from user behaviour. All information like key-words
are determined automatically and scored according
to their relevance. No manual setting is required.
Keywords
User model, recommendation, multi-modal dialog
1. INTRODUCTION
The amount of digital content rapidly increases.
Electronic program guides (EPG) become more and
more popular. Home servers with large storage
space become available. People will have large
amounts of videos, music titles, and pictures on-line.
It will be a problem to select content efficiently, in
particular if the user does not have a specific item in
mind.
Therefore a system is needed which knows the user
preferences very well and which can be operated in
an intuitive and flexible manner, without the
necessity of reading manuals or memorising a set of
commands or key-words. The user should be free
how to formulate a request and which I/O modality
to use: Certain wishes are easier to express by
speech others easier by gestures, e.g. pointing or
crossing out or even a combination of both.
Easy access of content as well requires meta-data to
be associated with the content, which can be
retrieved from broadcasted digital content, via the
Stuttgart).
Proceedings of the
Internet or generated by the user. In any case metadata generation needs to be supported by automatic
methods like speech recognition; we will not discuss
this in this paper. Rather we want to focus on the
user modelling aspect and give a description of our
dialog system for content selection as far as
necessary.
2. DIALOG SYSTEMS
2.1 Overview
Current dialog systems range from pure graphical
interaction to pure speech driven interaction.
Concerning spoken dialog, systems are available
which
provide
a
simple
menu-driven
question/answer type of dialog. Sometimes speech
input is even restricted to simple commands rather
than spontaneous speech. Others allow flexible
dialogs where the user can take the initiative and
guide the dialog. The quality of speech recognition
technology has undergone remarkable progress over
the past years, however, it is still far behind human
capabilities in particular in the presence of noise,
room reverberation, or limited channel bandwidth.
To cope with this, usually vocabulary and grammar
are restricted and often close-talking microphones
are necessary [6]. Prosodic information is
sometimes used to support the interpretation
process [8], which usually is conducted with a parser
based on some type of grammar.
Recently research shifted its interest towards multimodal dialog, where simultaneous I/O through
different modalities is possible [7,11,14]. Multi-modal
interaction
increases
robustness,
efficiency,
expressiveness, and the ability to correct errors [3].
2.2 Qbit
We developed a multi-modal dialog system (Qbit:
Query by interaction technologies). Figure 1 depicts
the components of Qbit. They were all developed
within Sony apart from the dialog manager, which
was obtained from SemanticEdge [12]. The
application specific dialog model defining the flow of
dialog was designed by Sony in cooperation with
Semantic Edge.
Qbit provides several simultaneous input channels.
Currently, continuous speech recognition and
pointing gestures on a touch screen are
63
Kompe, R., Emele, M., Goronzy, S., Mencl, R. & Torge, S.
implemented. Speech interpretation relies on a
robust coarse concept spotting rather than on
interpretation of the exact meaning. On the output
side simultaneous output by graphics or speech are
possible. Research on haptics I/O (force-feedback)
is still at a rather initial stage, however, it will play an
important role in the future [9].
Typically the dialog system would e.g. upon a
request for a movie for tonight display (or output by
speechCore of the system are interaction
management and underlying knowledge bases. On a
semantic level the analysis hypotheses of the
different input modalities are merged and scored.
Cross-modal references are resolved, i.e., an
utterance play these with these referring to a
selection on the screen is interpreted correctly [5].
Based on the best scored hypothesis the dialog
manager decides about the next action to be taken.
This can be an output to the user or some actions on
device-side. We use a mixed-initiative dialog
system, where the user can take the initiative and
guide the direction of the dialog. That means (s)he
does not necessarily have to provide an exact
answer to the questions of the system. On the other
hand in order to reduce complexity of speech
recognition the user is not free to arbitrarily change
the topic of conversation. In case of output to the
user the media fission [4] decides depending on a
set of rules and the current context how to present
the information to the user.
The interaction management relies on several
knowledge-bases. The application is defined by
discourse and domain model. The context model
allows situation-specific decisions. Personalised
interaction is established by a user model which will
be described in detail in the next section.
depending on the context) to the user a list of 5-10
alternatives, leaving him/her some possibility to
select manually without overloading him/her with
irrelevant information. This list is computed with the
user model described below. In case of too many
well or similar matching suggestions the dialog
system needs to ask the user for further constraints.
In case of no good matches the dialog system as
well would clarify with the user possible alternatives.
Qbit functions as a central user interface, which
allows to operate an arbitrary and dynamically
changing number of devices through a planning
module (plug-and-play). This translates complex
user wishes into sequences of actions of possibly
several devices or services based on their abstract
function models. It also infers new functionalities
arising from the combination of devices through a
home network [13].
Figure 1: Structure of the dialog system Qbit
64
like title, actors, artists, directors, genre, abstract
of TV show, description of music, date and time
broadcasted/ recorded/viewed, play-time.
3. USER MODELING
3.1 Why personalisation?
Users want to have efficient access to the increasing
amount of digital content available on-line in homes.
Often, underspecified and vague requests like
•
Some happy music,
•
The pictures of the vacation in Venice,
•
A movie on Saturday night,
need to be fulfilled, such that the set of matching
items has to be restricted according to the user’s
preferences, or the user needs to be asked for
further constraints. A genre hierarchy as e.g. used
by Amazon for music is tiring to use and often it is
not clear how to categorise a title [10]. In general,
using a genre hierarchy is in most cases not the way
people want to access their music at home.
3.2 Key features
We originally developed our user model for TV
program selection, so that the following is focused
on this. However, meanwhile we have successfully
adapted it to music content and it can be easily
applied to still picture selection, news filtering, etc.
Our system differentiates from
following ways [1,2]:
others in the
•
It learns the user preferences very fast and fully
automatically. The user does not have to specify
any preferences or key-words manually.
•
It
automatically
generalises
from
past
observations of the user behaviour without the
need for any manually generated knowledgebase.
•
User’s are not classified into categories of
similar behaviour. Rather real individual profiles
are built. We do not use something like people
who watched the same show as you also
watched X.
•
•
The suggestions usually fit very well the taste of
the user, however (s)he is free to adjust the
number of suggestions.
The user is free about the constraints he
specifies. For example, all of the following
requests are possible: I want to watch TV, …
watch a report, … a report about X.
Our system is efficient in terms of CPU and memory
usage and can thus be implemented on the client
side. Therefore, no information on the user’s
preferences has to be stored on any server.
3.3 Basic Algorithm
Before describing our algorithm we have to define
the usage of a few terms:
•
Article (a): contains for one broadcasted or
recorded TV show (music title) all available
meta-data as usually distributed with in an EPG
•
User history (h): stores everything the user did
and all the articles of shows the user watched. It
contains all relevant information like article,
minutes viewed, zapping behaviour, switched on
just for this show, etc.
•
User input: Everything the user does such as
turning on the TV or requesting a movie to be
recorded.
•
User profile: a weighted list of key-words/phrases based on a (filtered) user history. Keyphrases are taken from all text in the articles
including title, genre. By this genre becomes just
one parameter of many.
•
User model: comprises user profile, matching
algorithm, and inference engine providing
generalisation.
The core of the algorithm consists of the
computation of the weights (w) of words/phrases (p)
given a specific article:
w(p|a) = I1 (p|a) * I2(p|h) / I3(p|d)
(1)
where d denotes the whole database of articles, and
Ii denotes a measure of importance. The term
I2(p|h)/ I3(p|d) defines the weights contained in the
user profile, i.e., the importance of a phrase in the
user history normalised by the importance of the
phrase in the whole database. Multiplying this with
I1, the importance of the phrase in the given article,
implies a matching of a specific article with user
profile. Phrases with neglectable weights are
discarded from the user profile for efficiency. The
functions Ii are based on the commonly used inverse
document frequency [1], which basically gives words
a high score given a certain document or set of
documents if they occur frequently in this and just
rarely in others.
We score each article of the future TV program al by
the following algorithm:
1. filter the user history depending on the request,
e.g., the day of the week specified by the user, if
applicable.
2. compile the user profile for the filtered history
based on the weights I2(p|h) / I3(p|d)
3. generalisation: extend the user profile by related
words or phrases, where these get a slightly
lower weight than the corresponding word
actually being in the user profile
4. for each phrase pk in the history compute
wkl(pk|al) according to equation (1)
5. the score wl for this article al is given by the
normalised sum Σkwkl(pk|al)
Then the N(wl) TV shows corresponding to the
articles with the greatest score wl are suggested to
the user. The number N depends on the weights,
65
such that only few or even none suggestions are
provided if none matches well. N can also be
influenced by the user, depending whether (s)he
wants few or many suggestions.
The related words or phrases mentioned in step 3
are taken from a thesaurus. We compute the
thesaurus automatically from the whole database of
articles on the basis of co-occurrences of words.
Thereby an application dependent thesaurus is
computed which achieves better results than a
generic thesaurus.
3.4 Evaluation
This basic algorithm has been evaluated by a
number of users. People were asked to mark in the
past TV program what they watched. Then they got
a suggestion for tonight’s TV program and had to
rate the quality of the first, second, and third
suggestion as being excellent, good, neutral, not too
bad, or bad. Figure 2 shows the average rating for
20 users having marked 3-4 TV shows from the past
program, i.e. a user history of 3-4 items. The
suggestions are rather good even after such a short
learning period: 80% of the first suggestion was
rated as either excellent or good. Note that in each
of these tests the user was not asked to compare the
suggestions with the full program. So (s)he is not
aware of what (s)he missed. The rating was done in
rather general terms.
100%
80%
60%
neutral
40%
good
excellent
20%
0%
Top
suggestion
2nd
3rd suggestion
suggestion
Figure 2: Quality of suggestions (history of 3-4 items)
3.5 Extensions
Meanwhile we have extended our algorithm in order
to better model different kinds of user behaviour.
These will be described informally in the following.
We can now provide the user with suggestions which
depend on the time of day and whether the day is on
a weekend or not.
The weights in the user profile incorporate whether
the user has watched a TV show from the beginning
to the end and if he turned the TV on at the
beginning of the show and turned it off afterwards.
This indicates that (s)he really intended to watch this
show. If the TV is just on for a longer period the
shows of this period are being taken into account
with a lower weight.
66
A forgetting factor ensures that “older” items in the
history influence the user profile less than newer
items. This, allows for a change of the user’s taste.
Note that our algorithm implicitly handles the
problem of favourite shows being broadcasted only
seldom. Relevant for our algorithm is only the
number of times the user actually watched the show
relative to the number of times it was broadcasted.
4. CONCLUSIONS AND DISCUSSION
The concern most frequently raised is that items
important for the user might be missed. This can
never be avoided but just minimised, however, fact
is that people will need sufficient support by systems
for contents selection. There should always be the
option for manual selections and to adjust the
degree of filtering done by the system. An
explanation function should help users to understand
certain decisions and to correct these.
There are many details in daily operation of such a
system which need to be taken into account. E.g.,
switching on a certain TV show accidentally can
cause problems. As another example, user requests
for tomorrow 10 pm have to be interpreted carefully:
Everything shown between now and tomorrow 10
pm should be taken into consideration, because it
could be recorded. As a third example, it might be
obvious from past user behaviour that (s)he does
not watch a show lasting for two hours or more after
10 pm.
Our system is a good step towards a flexible
personalised user interface for content access, and
we have overcome some of above mentioned
problems, however, there is still a lot of research
necessary to make user modelling fool-proof and
user interfaces really flexible.
Our next step will be that the user himself can
specify within the dialog with the system for a
current TV show or music title if he considers it to be
funny, happy, sad, exciting, … These attributes
should be automatically incorporated into the scoring
function.
Also, we need to capture with our algorithm the
following questions: Was the user unable to watch a
show although it was interesting? Did the user zap
because there was nothing interesting or because
there were two interesting shows at the same time?
Did the user watch a potentially interesting show
deliberately not, because there was another one
broadcasted on a different channel at the same
time, or because it was just a repetition?
5. REFERENCES
[1] P. Baudisch, Dynamic Information Filtering.
Ph.D. Thesis. GMD Research Series 2001, No.
16. GMD Forschungszentrum
Informationstechnik, St. Augustin
[2] M.M Beaulieu, M. Gatford, X. HUang, S.E.
Robertson, S. Waler, P. Williams, Okapi at
TREC-5, 5th Text retrieval conference, NUIST,
Gaithersburg (1997)
[3] P. Cohen, Multimodal Interaction: a new focal
area for AI, Int. Joint Conf. on Artificial
Intelligence IJCAI (2001)
[4] Ch. Elting, G. Möhler, Modelling output in the
EMBASSI multi-modal dialog system, Int. Conf.
On Multimodal Interfaces ICMI (2002)
[5] Ch. Elting, S. Rapp, G. Möhler, S. Strube,
Multimodal input processing and output
generation in EMBASSI System, Conf.
Multimodal Interfaces ICMI (2003)
[6] S. Goronzy, Robust Adaptation to Non-Native
Accents in Automatic Speech Recognition,
Springer (2002)
[7] T. Herfet, Multimodal Assistance for
Infotainment & Service Infrastructures. Proc.
Human Computer Interaction Conf., Berlin
(2003)
[8] R. Kompe: Prosody in Speech Understanding
Systems, Lecture Notes in Artificial Intelligence,
Springer, Heidelberg (1997)
[9] G. Michelitsch, A. Ruf, H. van Veen, J. van Erp,
Multi-finger haptic interaction within the MIAMM
project, Conf. EuroHaptics, Edinburgh (2002)
[10] F. Pachet, D. Cazaly, A taxonomy of musical
genres, Conference RIAO Computer-assisted
information searching on Internet (2000)
[11] N. Reithinger, C. Lauer, L. Romary, MIAMMmultidimensional information access using
multiple modalities, Multimodal Dialogue
Systems, Copenhagen (2002)
[12] SemanticEdge: www.semanticedge.de
[13] S. Torge, S. Rapp, R. Kompe, Serving complex
user wishes with an enhanced spoken dialog
system, Int. Conf. On Spoken Language ICSLP
(2002)
[14] W. Wahlster, SmartKom: Symmetric
Multimodality in an Adaptive and Reusable
Dialogue Shell. Proc. Human Computer
Interaction Conf., Berlin (2003)
67
Referent
Ralf Kompe obtained the diploma degree in computer science and the Ph.D. at the
University of Erlangen in 1989 and 1996, respectively. From 1989 to 1990 he was
research assistant at McGill University, Montreal working on speech recognition.
From 1991 to 1996 he was a member of the research staff of the Institute for Pattern
Recognition, Univ. of Erlangen working on the recognition of prosodic information and
its use in parsing, speech understanding, and dialog control. In 1997 he joined the
Sony Stuttgart Technology Centre. He is currently as a general manager responsible
for user interface activities. Current research interests are in multi-modal interaction,
user modelling, information retrieval, and usability. He is author or co-author of more
than 70 publications including 7 journal articles and one monograph.
68
VOICE PORTALE – USABILITY ASPEKTE AUS DER PRAXIS
Peter Wetzel
Infoman AG
Vaihinger Str. 169
70567 Stuttgart
wetzel@infoman.de
www.infoman.de
1. EINLEITUNG
Sprache und die Ausgabe von Informationen durch
automatisiertes Vorlesen, genannt Text-to-Speech.
Unter Voice Portalen werden Systeme verstanden,
die über Telefon den Zugang zu Informationswelten
schaffen, vergleichbar den gerade boomenden
Webportalen in Intranet und Internet. Durch die
schmale Bandbreite des Kommunikationsmediums
gelten für Voice Portale eigene Ergonomieregeln.
Der Autor stellt Lösungen und Erfahrungen aus der
Praxis am Beispiel des Programms Customer
Communication Portal Phone Manager vor. Dieses
System implementiert übliche Ergonomieregeln von
Voice Portalen und stellt dem Entwickler des Portals
eine abstrakte, intuitive Weboberfläche zur
Konfiguration zur Verfügung, so dass die
resultierenden Portale leicht den Grundregeln der
Ergonomie genügen können.
In den neunziger Jahren wuchsen die verschiedenen
individuellen Lösungen zu universellen Info-OnDemand-Systemen zusammen. Neue Technologien
zur
Medienintegration,
wie
z.B.
die
Telefonkomponenten von Unified Messaging
Systemen traten hinzu. Gleichzeitig entwickelte sich
die Spracherkennung und Text-To-Speech weiter
und erreichten gegen Ende des letzten Jahrhunderts
schließlich
eine
Qualität,
dass
natürliche
gesprochene Dialoge zwischen Mensch und
Maschine in greifbare Nähe zu rücken scheinen.
2. VOICE PORTALE
a. unterstützen Voice Portale in der Regel
gesprochene Spracheingabe und das Vorlesen
von Texten,
Voice Portale als automatisierter Telefonzugang zu
Information existieren seit Anfang der achtziger
Jahre. Sie haben sich aus einzelnen, früher
unabhängigen Systemen heraus entwickelt. So
standen am Anfang Fax-On-Demand-Systeme zur
Anfrage von Faxdokumenten per Telefon und
Tonwahltasten, VoiceMail-Systeme als elektronische
Weiterentwicklung
des
Anrufbeantworters,
Automated Attendants als einfachster automatischer
Ersatz einer Telefonzentrale und Interactive Voice
Response Systeme, die in der Regel über Tonwahl
gesteuert verschiedenste Informationen vorspielen
konnten.
Der heutige Begriff des Voice Portals ist eine
Wiederbelebung des ursprünglichen Ansatzes des
Interactive Voice Response mit zwei wesentlichen,
zusätzlichen Wesenszügen:
b. wird die Dialogsteuerung und die Information
durch eine Interpretationsschicht von der
Telefoniesteuerung getrennt.
Waren die Systeme anfangs von der Steuerung
durch Tonwahltasten und Abspielen aufgezeichneter
Audiodaten
geprägt,
so
entwickelten
sich
schleichend
dynamische
und
humanere
Technologien, die Steuerung mittels gesprochener
Proceedings of the
Abbildung 1: Voice Portale stellen Daten aus der ITWelt über das Telefon zur Verfügung.
69
Wetzel, P.
3. DIE GRENZEN DES SPRACHKANALS
Der Spruch ‚Ein Bild sagt mehr als 1000 Worte.’
drückt gut die Problematik aus, mit der Designer von
rein sprachbasierten Schnittstellen, wie beim
klassischen
Voice
Portal,
leben
müssen.
Informationen, die in Sprache geliefert werden, sind
im Vergleich zu einer Darstellung in Grafiken und
Bildern wesentlich langsamer transportierbar, die
Bandbreite des Kommunikationskanals wesentlich
geringer. Dies gilt sowohl für die Eingabe, als auch
für die Ausgabe aus den Systemen. Die Schnittstelle
muss bewußt mit diesen Beschränkungen umgehen,
um weder den Anwender noch die Maschine zu
überfordern.
Sprache birgt daneben noch ein intrinsisches Risiko:
Die Differenzierung zwischen Maschine und Mensch
fällt dem Anwender wesentlich schwerer als bei
haptischen und grafischen Systemen. Heutige
Systeme haben eine gute bis sehr gute Intonation,
bei aufgenommenen Texten ist praktisch kein
Unterschied
zu
einem
menschlichen
Gesprächspartner zu hören. Kommt noch die
Möglichkeit der Spracheingabe von kompletten
Sätzen hinzu, wird von der Maschine nicht nur das
mechanische Erkennen der gesprochenen Worte,
sondern das ‚Verstehen’ des Gesagten erwartet.
Leicht kommt es dann zu Enttäuschungen und
Frustrationen, wenn die Maschine eben nur wie eine
immer noch reichlich dumme Maschine reagiert.
Alternativen jedes Mal aufgezeigt werden und eine
fast schon vom Benutzer geführte Interaktion, bei
der der Anwender die Interaktionsmöglichkeiten
kennt oder aus dem Kontext errät. So könnte z.B.
ein System, dass das Lieblingstier erfassen möchte,
erst allgemein fragen „Was ist ihr Lieblingstier?“ und
dann, wenn es keine verwertbare Antwort auf die
Frage bekommt, nachfassen mit „Was ist ihr
Lieblingstier? Bitte sagen Sie ‚Hund’, ‚Katze’,
‚Armadillo’ oder ‚anderes’.“ um den Wertebereich
der Antworten anzubieten. Oder ein System, dass in
der Regel von Neulingen bedient wird, erwartet die
Nennung von vorgetragenen Menüpunkten, erlaubt
aber auch Aussagen über das aktuelle Menü hinaus,
die dann systemübergreifend interpretiert werden. Z.
B. können Sie sich in dem Voice Portal der Telekom
(0190/055555) durch ein Menü führen lassen. Sagen
Sie aber irgendwann „Ich möchte das Wetter.“
werden Sie sofort mit dem Wetterdienst verbunden.
5. EINFACHE ENTWICKLUNG
ERGONOMISCHER VOICE PORTALE
Zur Entwicklung ergonomischer Voice Portale wurde
bei der Infoman AG das Produkt Phone Manager in
der Familie Customer Communication Portal
designed. Es versucht, u. a. die oben genannten
Prinzipien in ein einfach zu administrierendes
Produkt zu gießen
Daher sollte trotz immer besser werdender
Spracherkennung ein System auch heute noch den
Kommunikationspartner spüren lassen, dass es eine
Maschine ist und in der Sprache keine versteckten
Botschaften
übermitteln,
die
menschliches
Verstehen assoziieren, wie z.B. rhetorische Fragen,
eigene emotionale Äußerungen, Rede in der IchForm, u.ä.
4. ANFÄNGER UND VERSIERTE
BENUTZER
Sprachsysteme können im Unterschied zu
grafischen Systemen nur sehr schwer den
Wertebereich möglicher Eingaben übermitteln. Bei
einfachen, menübasierten Systemen kann dies z.B.
durch Aufzählen aller Möglichkeiten bestehen, wie
z.B. ‚Wenn Sie mit der Geschäftsführung sprechen
möchten, drücken Sie die Eins. Wünschen Sie den
Vertrieb, drücken Sie die zwei, ...’ Bei Systemen mit
umfangreichem Spracheingabewortschatz ist dies
praktisch unmöglich. Hier muss der Anwender eine
Vorstellung von den Fähigkeiten des Systems haben
um z.B. eine Frage wie ‚Was ist ihr Lieblingstier?’ so
zu beantworten, dass das System die Antwort
versteht.
In der Praxis zeigt sich, dass gute Systeme daher
immer zwei verschiedene Interaktionsmodi mit dem
Anwender zulassen, zwischen denen idealer Weise
je nach Situation gewechselt werden kann: eine
stark vom Computer geführte Interaktion, bei der die
70
Abbildung 2: Die Hauptstruktur der Weboberfläche
von CCP Phone
Die Administrationsschnittstelle ist eine rein
webbasierte
Benutzungsoberfläche,
die
die
Komponenten des Voice Portals als Objekte,
sogenannte Manager, mit klar definierten Aufgaben
darstellt. Die einzelnen Aufgaben sind:
•
die Annahme von Anrufen in sogenannten Gates
durch den Gate Manager
•
die Zuordnung von Sprache und Inhalten
aufgrund der Herkunft im Number Mapper
•
die Zuordnung von Inhalten aufgrund des
Anrufzeitpunkts im ServiceTime Manager
Voice Portale – Usability Aspekte aus der Praxis
•
den rechnergesteuerten Menüablauf im Call
Flow Manager
•
die
Verwaltung
von
vordefinierten
Systemansagen im Prompt Manager
•
die Behandlung von Wartesituationen bei
Weitervermittlung im Waiting Queue Manager
•
die Definition der Behandlung komplexer
Spracheingaben im Grammar Manager
•
die Darstellung virtueller Faxgeräte für
Faxannahme und –versand im Fax Manager
Ich möchte hier nur auf die Funktion des
Menüablaufs im Call Flow Manager eingehen, um
die verschiedenen Formen der Ablaufkontrolle zu
demonstrieren:
Der Call Flow Manager definiert einen Dialogablauf
als eine Menge von Menüs mit erwarteten Eingaben
und damit verbundenen Aktionen. Jedes Menü hat
daneben noch Einführungsansagen und eine Aktion,
wenn keine Reaktion des Gesprächspartners erfolgt.
Abbildung 3 zeigt einen solchen Menüaufbau. Wir
sehen die Eingabe, die hier als Taste erfolgt, die
ausgewählte Aktion und einen Verweis auf das
Menü, das nach Durchführung der Aktion folgt. Mit
Hilfe dieser Definitionen kann damit nicht nur ein
klassischer
Menübaum,
sondern
ein
Transitionsnetzwerk
zwischen
Menüzuständen
abgebildet werden.
Sprache ist nun aber im Gegensatz zu den Tasten
nicht auf einen so kleinen Wertebereich beschränkt.
Heutige
Spracherkenner
können
auch
bei
unbekannten Anrufern schon über 1000 Worte
zuverlässig unterscheiden. Hat nun der Entwickler
allen Menüaktionen Wörter zugeordnet, so kann der
Anrufer auch Worte nennen, die nicht im aktuellen
Menü aufgelöst werden können. In diesem Fall sucht
das System alle für diesen Anrufer möglichen
Aktionen, die mit diesem Wort verknüpft sind, führt
eine eindeutige Aktion automatisch aus oder fragt, in
welches Menü es verzweigen soll. Damit kann ein
versierter Anwender schnell in den richtigen
Gesprächskontext gelangen.
Aber Sprache kann noch mehr: Die gesprochene
Eingabe kann gleichzeitig mehrere Informationen
und/oder Parameter enthalten. Z.B. sagt der Satz
„Ich möchte Herrn Huber in der Geschäftsleitung
sprechen.“ nicht nur, dass Herr Huber gefragt ist,
sondern auch welcher Herr Huber gefragt ist.
Um auch diese Interaktion möglichst einfach
konfigurierbar zu machen, wurde der Grammar
Manager eingeführt. Im Grammar Manager werden
die möglichen Spracheingaben grammatikalisch
beschrieben und den Satzteilen Bedeutungen
zugeordnet, so dass im obigen Fall z.B. das System
erkennt, dass ‚Geschäftsleitung’ einem bestimmten
Menü zugeordnet ist und darin ‚Huber’ einer
bestimmten Aktion.
Durch den gefundenen Ansatz kann das System
ohne Programmierkenntnisse des konfigurierenden
Anwenders beide Ansätze, den rechnergesteuerten,
menügetriebenen
und
den
weitgehend
anrufergesteuerten Dialogablauf realisieren.
6. AUSBLICK
Die Sprachtechnologie hat sich insbesondere in den
letzten drei Jahren mit großen Schritten
weiterentwickelt. Ihr auf dem Fuß folgen
Entwicklungen im Sprachverstehen und in der
Führung von Dialogen, für grafische Schnittstellen
gibt es sogar schon Ansätze, auch Emotionen zu
verarbeiteten. Die reinen Sprachschnittstellen
werden im Bereich der Mobilität Konkurrenz durch
gemischt sprachlich-grafische Interaktionen, z.B. auf
einem webfähigen Handy, bekommen.
Abbildung 3: Die Definition eines einfachen Menüs:
Die Taste 5 verzweigt zum ‘Fernservice’, tritt keine
Aktion ein, wird der Anrufer einer Warteschlange
zugewiesen.
Tasten sind innerhalb eines einzelnen Menüs
eindeutig und ja rein technisch auf 16 Werte,
üblicherweise 12 Werte beschränkt. Ganz anders
sieht dies aus, wenn Sprache hinzutritt. Die
Schnittstelle erlaubt es, jedem Menüeintrag
Schlüsselworte zuzuordnen. Spricht der Anrufer
eines der Worte, so hat dies den gleichen Effekt, wie
das Drücken der entsprechenden Taste.
Technisch
werden
reine,
telefoniebasierte
Sprachsysteme aber erst dann einen richtigen
Durchbruch erleben, wenn das Sprachverstehen der
Systeme
dem
unbekannter
menschlicher
Gesprächspartner ähnelt, oder wenn genügend
Menschen Verständnis für die Beschränkungen der
sprechenden und hörenden Maschinen entwickelt
haben. Bis dahin müssen Maschinen am Telefon
klar erkennbar als Maschinen kommunizieren und
stark rechnergesteuerte Dialogformen bereit halten
um so dem Menschen eine sichere, frustrationsfreie
Interaktion zu erlauben.
71
Wetzel, P.
Referent
Peter Wetzel (Dipl.-Inform.) studierte an der Universität Stuttgart Informatik und
Linguistik. Er beschäftigt sich seit 1983 mit Fragen der Mensch-Maschine-Interaktion
und hat an zahlreichen Forschungsprojekten zu Dialogsystemen mit Sprache, Zeigen,
Gesten,
grafischen
Benutzungsoberflächen,
Dialogwissen
aktiv
forschend
mitgearbeitet. Seit 1996 baut er als Vorstand die Infoman AG mit dem Ziel auf,
Produkte und Lösungen zu schaffen, die die zwischenmenschliche Kommunikation und
die Mensch-Maschine-Kommunikation in den Mittelpunkt optimierter kundenorientierter
Geschäftsprozesse stellen.
72
USABILITY PROFESSIONALS IN
DEUTSCHLAND
DAS GERMAN CHAPTER OF THE
USABILITY PROFESSIONALS’ ASSOCIATION E.V.
Kerstin Röse
Zentrum für Mensch-MaschineInteraktion, User-centered Product
Development, Postfach 3049
67653 Kaiserslautern
roese@mv.uni-kl.de
www.mv.uni-kl.de
Andreas Beu
User Interface Design GmbH
Lehrer-Götz-Weg 11
81825 München
andreas.beu@uidesign.de
www.uidesign.de
Matthias Peissner
Fraunhofer IAO
Nobelstrasse 12
D-70569 Stuttgart
matthias.peissner@iao.fhg.de
www.usability.iao.fhg.de
Marc Hassenzahl
Institut für Psychologie
Technische Universität Darmstadt
Steubenplatz 12, 64293 Darmstadt
hassenzahl@psychologie.tudarmstadt.de
ABSTRACT
Im vorliegenden Beitrag wird der 2002 gegründete
Berufsverband für deutsche Usability-Professionals
kurz vorgestellt; seine Struktur, aktuelle Aktivitäten,
Networking und Planungen für das nächste Jahr.
Zielstellung des Berufsverbandes ist es, den Stellenwert von Usability in der Öffentlichkeit und in den
Unternehmen zu steigern sowie über die Bildung von
beruflichen Netzwerken Plattformen für den persönlichen Austausch von Erfahrungen und Kompetenzen
der Usability Professionals zu schaffen. Damit soll der
Berufsstand der Usability-Experten gestärkt werden
und eine allgemeine Interessensvertretung etabliert
werden.
KEYWORDS
UPA, Networking, Ideen, Visionen
1. EINLEITUNG
In Deutschland sehen sich Usability- Professionals
mit dem Problem der fehlenden Lobby in Praxis und
Forschung konfrontiert. Viel zu oft wird das Thema
‚Usability’ noch als nette Ergänzung zur Softwareentwicklung angesehen. Durch zahlreiche Initiativen
(z.B. Zertifizierung von SoftwareentwicklungsprozesEs ist erlaubt digitale und Kopien in Papierform des ganzen Papers
Stuttgart).
Proceedings of the
sen) und entsprechende Öffentlichkeitsarbeit (z.B.
Tagungen wie ‚Mensch & Computer’ sowie ‚Useware’
und Zeitschriften wie ‚i-com’) wird versucht die Einstellung "Der Mensch ist lernfähig" hin zu "Der Benutzer ist das Maß der Entwicklung" zu beeinflussen.
Der fachliche Austausch mit Kollegen ist eine wichtige Basis für qualitativ hochwertige Entwicklungsergebnisse, d.h. gut benutzbare Produkte im Sinne des
‚Usability’-Gedanken. Die Gründung des 'German
Chapters' (GC) der 'Usability Professionals Association' (UPA) als Berufsverband ist ein erster Schritt, um
gezielt die berufliche Situation und die Lobby der
Usability-Professionals in Deutschland zu verbessern
[1].
Unter dem Sammelbegriff Usability Professional werden alle mit Usability Engineering Methoden arbeitenden Entwickler und Designer von Useware zusammengefasst. Der Begriff gilt somit für alle Branchen vom Industrie- und Maschinendesign bis hin
zum Konsumgüter- und Web-Design. Ein erster Überblick zur Situation in Deutschland wurde beim
europäischen Treffen der Usability Professionals,
2002 in London, vorgestellt [2]. Um einen Überblick
zur aktuellen Situation der Usability Professionals
und den in der Praxis angewandten Methoden zu
erhalten, wird aktuell ein Branchenreport erstellt, der
'Usability Report Deutschland 2003' 3].
2. USABILITY: HEUTE UND MORGEN
2.1 Struktur des German Chapter der UPA e.V.
Das 'German Chapter der Usability Professionals
Association e.V.' (GC UPA) besteht aus mehreren
Regionalgruppen (vgl. Abbildung 1) [5]. Diese Regionalgruppen treffen sich regelmäßig, um sich über
Usability-Themen auszutauschen. Dies meint: Erfahrungen teilen, Probleme analysieren und besprechen,
75
Röse, K., Beu, A., Peissner, M. & Hassenzahl, M.
Methoden erlernen und austauschen, etc. Jede Regionalgruppe hat einen 'Ansprechpartner' nach Außen,
für alle anderen Mitglieder des ‚German Chapter’.
Dieser Ansprechpartner koordiniert die Treffen vor
Ort und veröffentlicht diese Termine Online auf der
Website der Regionalgruppe, denn das ‚UPA-German
Chapter’ hat ein wenig den Charakter einer OnlineCommunity. Warum Online?
2.2 Das Szenario für Morgen
Der Usability-Professional wohnt und arbeitet in München und ist Mitglied der Münchener Regionalgruppe.
Er hat eine Dienstreise nach Frankfurt. Er schaut auf
die Webseiten des GC UPA und stellt fest, dass genau zu diesem Tag eine Zusammenkunft der Frankfurter Regionalgruppe ist (oder er kann den geplanten
Frankfurt-Termin flexibel zum Termin der Zusammenkunft der Frankfurter Regionalgruppe legen).
Termin, Treffpunkt und Kontaktinformationen des
regionalen Ansprechpartners sind auf der Webseite
der Frankfurter Regionalgruppe vermerkt. Somit besteht die Chance, das Angenehme mit dem Nützlichen zu verbinden und bei einem netten Abend die
Kollegen und ihre Ideen in Frankfurt kennen zu lernen (oder natürlich: Kontakte aufzufrischen).
eingeladen, um zumindest einmal im Jahr den persönlichen Kontakt zu Mitgliedern aus allen Teilen
Steutschlands herzustellen. Hier wird auf Interdisziplinarität, Praxisbezug und rege Kontaktmöglichkeiten Wert gelegt.
Dieses Szenario dient der Veranschaulichung der
‚Vison’ des German Chapter der UPA. Es wurde aus
den Analysen der Bedürfnisse von deutschen Usability Professionals abgeleitet. Zielstellung des GC UPA
ist die Schaffung eines Netzwerkes von persönlichen
Kontakten (das Individuum steht im Vordergrund und
nicht die Institution), um die fachliche Kompetenz
jedes Einzelnen zu stärken bzw. auszubauen und auf
diesem Wege eine Usability-Lobby für Deutschland
zu schaffen, die dem interdisziplinären Anspruch der
Usability Professionals entspricht.
3. AKTIVITÄTEN DES GC UPA
3.1 Zielgruppen
Das GC UPA stellt ein Forum für Praktiker dar. Ein
Ort um sich– abseits von allzu akademischen Ansprüchen – über Erfahrungen, Probleme und Wünsche auszutauschen. Typische Themen sind Erfahrungen mit der Anwendung bestimmter Methoden,
die Rolle der Usability im Produktentwicklungszyklus,
Fallstudien, oder ‚Politics’, also wie überzeuge ich als
Usability Professional das Management von Usability. Jedes Thema wird 'von Praktikern für Praktiker’
auf den jährlichen Workshops präsentiert. UPA
Workshops zeichnen sich durch ihren hohen Grad an
Interaktivität aus. Soziale Kontakte, Erfahrungsaustausch und Wissenstransfer stehen im Vordergrund
der Treffen.
3.2 Interaktive Plattform
Um einen möglichst breiten Zugang zu den Aktivitäten zu ermöglichen wird aktuell ein Webserver mit
unterschiedlichen Serviceangeboten aufgebaut. Von
den Aktivitäten der Regionalgruppen über die Vorstellung einzelner Mitglieder des Berufsverbandes werden zahlreiche aktuelle Informationen zur Thematik
‚Usability’, aktuellen Trends und Innovationen angeboten. Ein Schwerpunktthema ist die Unterstützung
des Aufbaus eines nationalen Netzwerkes für Usability-Experten, neben Job-Börse und Aktivitätenliste
Abbildung 1: Regionalgruppen in Deutschland 2003
Einmal im Jahr wird ein Usability-Workshop veranstaltet. Zu diesem sind alle Mitglieder des GC UPA
76
3.3 Networking
In Europa folgt die Initiative des German Chapter
dem Beispiel Schwedens und Großbritanniens. Insbesondere Großbritannien hat bereits ein starkes
Netzwerk von Usability Professionals aufgebaut. Weitere europäische Chapter wurden in letzter Zeit gegründet oder sind gerade in der Gründungsphase.
Dazu zählen Italien, Niederlande und Schweiz. Neben einzelnen Chapter Aktivitäten gibt es auch ein
jährliches Treffen der europäischen Chapter, die
Das German Chapter of the Usability Professionals’ Association e.V.
EUPA [4]. Somit versteht sich das German Chapter
der UPA als ein Baustein im europäischen Bauwerk
des Usability-Networking.
3.4 Weltweites Networking
Der Aufbau eines nationalen Networking ist weiterhin
eine wichtige Zielstellung des Berufsverbandes. Als
Chapter einer internationalen Organisation ist der
internationale Austausch ein weiterer Aspekt. Um den
internationalen Erfahrungsaustausch zu pflegen, werden Kontakte zu den weiteren 31 Chaptern gepflegt,
die weltweit existieren (vgl. Abbildung 2) [6]. Dies
ermöglicht in einigen Bereichen auch ein
internationales Vorgehen, z.B. bei Themenstellung
der Zertifizierung oder Ausbildung.
Gemäß dem aktuellen Globalisierungstrend sind dies
wichtige Aspekte, um eine angemessene Interessenvertretung als Berufsverband anzubieten.
4. ZUKUNFT DES GC UPA
4.1 Inhaltliche Arbeit
Die Aufgabenstellungen des Verbandes waren im
ersten Jahr eher bürokratischer Natur. Neben der
Gründung und amtlichen Registrierung des Verbandes, der Ausgabe der ersten Mitgliedschaften, der
Herstellung einer Arbeitsfähigkeit sowie dem internationalen Kontaktaufbau blieb kaum Zeit sich den inhaltlichen Herausforderungen zu widmen. Daher
steht die inhaltliche Arbeit im Fokus der nun anstehenden Aktivitäten. Dazu werden zunächst die Interessen der im Berufsverband aktiven Usability Professionals gebündelt. Wir werden Professionals, die
sich mit bestimmten Themen beschäftigen, wie z.B.
'accessibility', Zertifizierung, User Interface Design
für mobile Geräte oder 'Joy of Use', dabei helfen,
überregionale Kontakte zu knüpfen. So wird neben
der räumlichen Vernetzung auch eine inhaltliche entstehen.
4.2 Berufsspezifische Informationen
Eine weitere wichtige Aufgabe des GC UPA wird die
Ermittlung von berufsspezifischen Informationen
sein. Hierfür möchte das GC UPA Studien initiieren,
in deren Rahmen entsprechende Daten erhoben und
den Usability Professionals und der Öffentlichkeit zur
Verfügung gestellt werden. Diese Informationen sollen den Usability Professionals die Planung ihres
Ausbildungs- und Berufswegs erleichtern und für die
Öffentlichkeitsarbeit eingesetzt werden.
Eine erste Studie ist bereits im Entstehen. Diese ermittelt die Arbeitsumstände von Usability Professionals in Deutschland im Jahr 2003 [3]. Weitere Studien, beispielsweise zu den Bedürfnissen und Anforderungen von Unternehmen und Organisationen, die
entsprechende Usability Verfahren und Methoden
einsetzen, oder zur Wahrnehmung des Themas
'Usability' bei den Konsumenten, sollen folgen.
4.3 Berufsverband
Das Votum der Gründungsversammlung im Herbst
2002 war eindeutig. Es sollte ein Berufsverband und
nicht irgendein Verein gegründet werden. Durch das
German Chapter der UPA ist eine Plattform geschaffen, um die Probleme im Umgang mit Usability praxisnah und unkompliziert zu lösen. Im Sinne eines
Berufsverbandes werden fachliche Informationen und
Anleitungen vermittelt. Die gegenseitige Wissensvermittlung der Mitglieder sowie regelmäßige Weiterbildung stehen im Mittelpunkt unserer Aktivitäten.
Ganz klar, das German Chapter der UPA kümmert
sich nicht nur um die interne Weiterqualifikation seiner Mitglieder, es ist auch Ansprechpartner für die
Industrie, Verwaltung, etc. und vermittelt für jedes
Problem die entsprechenden Fachexperten.
Die Arbeit im Berufsverband ist klassische VolunteerArbeit. An dieser Stelle ein Dankeschön an alle Aktiven des letzten Jahres, die geholfen haben dem Berufsverband Leben einzuhauchen. Es ist viel private
Zeit investiert worden und die Mitarbeit aller Mitglieder bleibt somit weiterhin gefragt, um die Last des
Einzelnen zu verringern.
Das GC UPA versteht sich als ein aktiver Berufsverband und ist offen für Fragen der Mitglieder, als auch
der Nicht-Mitglieder, Arbeitgeber und Freiberufler.
Jeder Beitrag und jede Aktivität ist gefragt, denn unser gemeinsames Ziel ist und bleibt es, eine Usability-Lobby für Deutschland zu schaffen.
5. REFERENZEN
[1] http://www.gc-upa.de
[2] Peissner, M. und Röse, K., Usability Engineering
in Germany: Situation, Current Practice and Netst
working Strategies, Proceedings of the 1 EUPA
conference (2002).
[3] Beu, A.; Reitmayr, E.; Vogt, P.; Mauch, D.; Röse,
K.: Usability Report Deutschland. Proceedings of
the 1st annual GC-UPA Track, Stuttgart, September 2003.
[4] Hassenzahl, M.: "Praktiker vor" – Über die erste
europäische Konferenz der Usability Professionals' Association. In i-com Zeitschschrift für interaktive und kooperative Medien, 1, 2003.
[5] Stoessel, S.: Lokale Gruppen beim German
Chapter. Proceedings of the 1st annual GC-UPA
Track, Stuttgart, September 2003.
[6] Usability Professionals’ Association UPA,
http://www.upassoc.org (2003).
77
Röse, K., Beu, A., Peissner, M. & Hassenzahl, M.
Referenten
Kerstin Röse hat an der Humboldt Universität zu Berlin Psychologie studiert
und an der Universität Kaiserslautern im FB Maschinenbau promoviert. Von
1996 bis 2002 arbeitete Sie am Lehrstuhl für Produktionsautomatisierung
sowie am Zentrum für Mensch-Maschine-Interaktion und wurde 2002 zur
Juniorprofessorin für ‚Nutzergerechte Produktentwicklung' an der Universität
Kaiserslautern berufen. Seit 1996 arbeitet sie als Usability Consultant. Sie ist
außerdem Präsidentin des German Chapters der Usability Professionals’
Association e.V.
Andreas Beu ist Senior Usability Consultant und Manager Industry Solutions bei der User Interface Design GmbH in München. Im Rahmen dieser
Tätigkeit berät er Unternehmen aus dem industriellen Umfeld bei der benutzergerechten Gestaltung von Software Produkten und interaktiven Dienstleistungen. Anfang 2003 übernahm er zusätzlich die Leitung der UID Geschäftsstelle in München. Andreas Beu ist Vize-Präsident des German
Chapters der Usability Professionals’ Association e.V.
Mathias Peissner hat sein Studium der Psychologie an der Universität Regensburg 1999 abgeschlossen. Seit Anfang 2000 arbeitet er im Competence
Center Human-Computer Interaction des Fraunhofer-Instituts für Arbeitswirtschaft und Organisation (IAO) in Stuttgart. Seine Arbeitsschwerpunkte sind
Voice User Interface Design, Mobile Computing und Usability Engineering
Methoden. Er ist Mitglied im Vorstand des "German Chapters der Usability
Professionals Association".
Marc Hassenzahl hat sein Studium der Psychologie mit Nebenfach Informatik an der Technischen Universität Darmstadt 1998 abgeschlossen. Danach arbeitete er als "Usability Engineer" im Fachzentrum "User-Interface
Design" der Siemens AG in München und als "Senior Usability Consultant"
bei der User Interface Design GmbH in München. Seit Oktober 2001 ist er
als wissenschaftlicher Mitarbeiter am Institut für Psychologie der Technischen Universität Darmstadt in den Bereichen Sozialpsychologie, Forschungsmethodik und Urteilen und Entscheiden tätig. Seine Forschungsinteressen liegen im Bereich "Usability Engineering", attraktive Software (hedonische Qualität, Spaß bei Umgang mit Computern, "Joy of Use") und neue
Analyse- und Evaluationsmethoden. Er ist Mitglied im Vorstand des "German Chapters der Usability Professionals Association".
78
DAS NETZWERK DER REGIONALEN GRUPPEN DES
GERMAN CHAPTERS DER UPA E.V.
Sabine Stoessel
Freie Informationsarchitektin
Sigmundstr. 6
80538 München
stoessel@ubibene.de
www.ubibene.de
ABSTRACT
Das
vorliegende
Dokument
beschreibt
die
Organisation des German Chapter der Usability
Professionals Association e.V. (kurz GC UPA) auf
regionaler Ebene. Nach einer kurzen Einleitung
werden die einzelnen regionalen Aktivitäten und die
regionalen
Ansprechpartner
vorgestellt.
Abschließend erfolgen Informationen über das
Beitreten und Gründen einer regionalen GC UPAGruppe.
2. DEUTSCHLANDWEITE INITIATIVEN
Netzwerken passiert dort, wo Engagement ist. Hinter
jeder Initiative stehen aktive Usability Professionals,
die in ihrer Region Stammtische, Vorträge oder
Themenabende organisieren. Diese regionalen
Leiter sind Ansprechpartner ihrer Region und
können bei Interesse persönlich auf der M&C 2003
oder per E-Mail kontaktiert werden.
2.1 Lübeck / Kiel
Keywords
Regionaltreffen,
Neugründung
Chapter-
Der
Usability
Stammtisch
Lübeck / Kiel trifft sich
regelmäßig seit Januar 2003 in
Kiel.
Persönlicher Kontakt ist die Grundlage eines
funktionierenden Netzwerkes. Die regionalen
Initiativen des German Chapter der UPA e.V. bieten
Usability Professionals die Möglichkeit der
persönlichen Kontaktaufnahme mit der GC UPA
und das Knüpfen neuer Kontakte - nicht nur mit den
Organisatoren, sondern ebenso mit weiteren
Usability-Interessierten der Region. Damit sind die
Regionalgruppen die Knotenpunkte des GC UPA
Netzwerkes.
Stephan Raimer organisiert den
Stammtisch.
Regionalkontakte,
1. MOTIVATION
In den letzten Monaten haben sich in ganz
Deutschland regionale UPA-Initiativen gegründet.
Diese Initiativen sind nicht nur Anlaufstellen für
potentielle Interessenten, sondern ebenso „Augen,
Ohren und Stimme“ der jeweiligen Regionen.
Ansprechpartner
Stephan Raimer
e-Mail
stephan.raimer@gc-upa.de
URL
http://kiel.gc-upa.de
2.2 Berlin
Der
Berliner
Usability
Stammtisch findet einmal im
Monat an wechselnden Orten
statt. Leiter des Stammtisches
ist Jan Mühlig, Vorstand
Relevantiv AG.
Stuttgart).
Proceedings of the
Ansprechpartner
Jan Mühlig
e-Mail
jan.muehlig@gc-upa.de
URL
http://berlin.gc-upa.de
79
Stoessel, S.
2.5 Dresden
Der
Dresdener
Usability
Stammtisch startet im Herbst
2003 in Zusammenarbeit mit der
GI. Inhaltlich wird auch hier der
Schwerpunkt
im
Usability
Engineering und Anforderungsmanagement liegen. Durch die
Mitwirkung von Prof. Liskowsky
und Prof. Wünschmann von der
TU Dresden werden aber auch
Spezialthemen, wie z.B. EuroNormen, SW-Technologien oder
behinderten-gerechte Gestaltung
eine Rolle spielen.
2.3 Rhein / Ruhr
Der Usability Stammtisch Rhein
Ruhr trifft sich regelmäßig am
ersten Mittwoch im Monat bei
schlechtem Wetter im Haus
Mengwasser, bei gutem Wetter
ist der Treffpunkt das Cafe unter
der Pegeluhr am Rheinufer.
Ralph Hinderberger, Freelance
Usability-Engineer
über
den
Usability
Stammtisch
Rhein
Ruhr: „Die Teilnehmer kommen
zwar überwiegend
aus dem
Bereich der Telekommunikation,
aber wir freuen uns über jeden
Interessenten aus einem anderen
Anwendungsgebiet.
Die
Gespräche finden in lockerer
Atmosphäre statt und drehen
sich zwar hauptsächlich, aber
nicht ausschließlich um das
Thema Usability“.
Ansprechpartner
Ralph Hinderberger
e-Mail
ralph.hinderberger@gc-upa.de
URL
http://rheinruhr.gc-upa.de
Organisiert wird der Dresdener
Usability-Stammtisch von Dr.-Ing.
Gunter
Dubrau
(Dresdner
Usability-Beratung)
erreichbar
unter gunter.dubrau@gc-upa.de
Ansprechpartner
Gunter Dubrau
e-Mail
gunter.dubrau@gc-upa.de
URL
http://dresden.gc-upa.de
2.6 Rheinland
Der
Rheinländer
Usability
Stammtisch befindet sich in der
Entstehung. Dazu Arno Karrasch:
„Wir sind noch dabei, uns mit den
lokalen
Verbänden
auszutauschen und bauen den
Verteiler auf. Das erste Treffen
wollen wir bald in Angriff
nehmen“. Das Einzugsgebiet
erstreckt sich über Köln, Bonn
und Düsseldorf
2.4 Hamburg
Der
Hamburger
Usability
Roundtable findet seit Frühjahr
2001 immer am ersten Montag
im Monat statt.
Organisiert wird der Hamburger
Usability Roundtable von James
Kalbach, Information Architect
bei
LexisNexis
und
Sven
Heinsen, Dipl.-Psych., Wissenschaftl. Mitarbeiter & Doktorand
am psychologischen Institut Uni
Hamburg
Lokale Ansprechpartner sind
Arno Karrasch und Katja Busch.
Arno Karrasch arbeitet selbstständig in der Beratung &
Weiterbildung und ist über
arno.karrasch@gc-upa.de
erreichbar. Katja Busch, Dipl.Medienwirtin ist als Consultant
bei KGB - Büro Klaus Greiner
GmbH tätig (katja.busch@gcupa.de).
Ansprechpartner
Ansprechpartner
James Kalbach
Sven Heinsen
e-Mail
james.kalbach@gc-upa.de
sven.heinsen@gc-upa.de
URL
80
http://hamburg.gc-upa.de
Arno Karrasch
Katja Busch
e-Mail
arno.karrasch@gc-upa.de
katja.busch@gc-upa.de
URL
http://rheinland.gc-upa.de
2.7 Saar / Pfalz
2.9 Stuttgart
Der Usability Stammtisch Saar
/ Pfalz trifft sich regelmäßig
alle 5 Wochen, erstmals im
Januar 2003. In aller Regel hat
der Abend ein bestimmtes
Thema bzw. eine Firma stellt
sich vor.
Der
Stuttgarter
Usability
Stammtisch findet etwa alle
sechs bis acht Wochen statt,
meist im Anschluss an einen
Vortrag
des
Arbeitskreis
Interaktive Systeme, der von
Astrid Beck geleitet wird. Der
Vortrag
findet
im
Schulungszentrum der Fiducia
nahe
dem
Stuttgarter
Hauptbahnhof statt.
Kerstin
Röse
von
der
Universität Kaiserslautern und
Kirsten
Kohler,
Projektmanagerin am Fraunhofer
Institut für experimentelles
Software
Engineering
organisieren diese Regionalgruppe.
Ansprechpartner
Die Teilnehmer werden über
mehrere
Verteiler
zu
den
Veranstaltungen
eingeladen,
darunter
auch
der
allseits
bekannte sw-ergo. Dadurch ist
der Kreis der gelegentlichen
Teilnehmer sehr groß und
heterogen. Das Einzugsgebiet
konzentriert sich auf die Region
Stuttgart, Gäste aus Frankfurt,
Heidelberg, Freiburg, Ulm, etc.
sind jedoch gerne willkommen.
Die behandelten Themen sind
sehr vielfältig. Die Ausweitung
auf Usability Lab – Besichtigungen und Firmenbesuche ist
geplant bzw. teilweise schon
erfolgt.
Kerstin Röse
Kirsten Kohler
e-Mail
kerstin.roese@gc-upa.de
kirsten.kohler@gc-upa.de
URL
http://saarpfalz.gc-upa.de
2.8 Frankfurt / Darmstadt
Der Usability Stammtisch
Frankfurt / Darmstadt findet
alle zwei Monate statt.
Marc Hassenzahl ist Gründer
der GC UPA-Gruppe Frankfurt
/ Darmstadt. Er ist wissenschaftlicher Mitarbeiter am
psychologischen Institut der
TU Darmstadt.
Matthias Peissner arbeitet seit
2000 im Competence Center
Human-Computer Interaction des
Fraunhofer IAO, Stuttgart.
Ansprechpartner
Matthias Peissner
e-Mail
matthias.peissner@gc-upa.de
URL
http://stuttgart.gc-upa.de
Jürgen Mangerich arbeitet als
Senior-Berater bei Zühlke
Engineering. Für ihn bedeutet
die GC UPA Networking,
Erfahrungsaustausch, Lernen,
und Tipps & Tricks für die
tägliche Arbeit.
Ansprechpartner
Marc Hassenzahl
Jürgen Mangerich
e-Mail
marc.hassenzahl@gc-upa.de
juergen.mangerich@gcupa.de
URL
http://frankfurt.gc-upa.de
81
Stoessel, S.
2.10 München
Der
Münchner
Usability
Stammtisch München trifft
sich regelmäßig seit Frühjahr
2001immer
am
letzten
Donnerstag
im
Monat.
Abwechselnd werden Vorträge
gehalten,
in
Firmen
eingeladen oder gemütlich
beisammen gesessen.
Patrick Huber, User Interface
Manager
bei
Premiere
Fernsehen
und
Sabine
Stoessel, freie Informationsarchitektin
sind
die
Ansprechpartner
für
den
Münchner
Usability
Stammtisch.
Ansprechpartner
3. GRÜNDUNG EINER REGIONALGRUPPE
Möchten auch Sie:
•
ein Forum für Networking, Wissenstransfer,
Erfahrungsaustausch und auch Weiterbildung
für Usability Professionals schaffen
•
Ihre beruflichen Kontakte ausweiten
•
von Pressekontakten und Öffentlichkeitsarbeit
persönlich profitieren
•
engagierte Usability Professionals auch privat
kennen lernen
•
Aber in Ihrer Region gibt es noch keine GC UPA
Ansprechpartner?
Wenden Sie sich einfach an lokalgruppen@gcupa.de und gründen Sie Ihre eigene Gruppe. Das
GC UPA Board steht Ihnen mit Tipps zur Seite und
betreut Sie durch einen konkreten Ansprechpartner.
Patrick Huber
Sabine Stoessel
e-Mail
patrik.huber@gc-upa.de
sabine.stoessel@gc-upa.de
URL
82
http://muenchen.gc-upa.de
Referentin
Sabine Stoessel erstellt als freiberufliche Informationsarchitektin Fachkonzepte und
Informationsarchitekturen für User Interfaces und führt Usability Testings durch.
Sie gründete 2000 den ersten deutschen Usability Stammtisch in München und ist
Gründungsmitglied der gc-UPA. Seit 2002 betreut sie die regionalen gc-UPA Initiativen.
83
USABILITY REPORT DEUTSCHLAND 2003
EINE BEFRAGUNG ZUR SITUATION DER USABILITY
PROFESSIONALS IN DEUTSCHLAND
Andreas Beu
Lehrer-Götz-Weg 11
81825 München
www.uidesign.de
Ellen Reitmayr
Universität Mannheim
Schloss
68131 Mannheim
reitmayr@uni-mannheim.de
www.psychologie.uni-mannheim.de
Daniel Mauch
Carl Zeiss Vision
Zeppelinstr. 4
85399 Hallbergmoos
d.mauch@zeiss.de
www.zeiss.de
Kerstin Röse
Zentrum für Mensch-MaschineInteraktion,
User-centered Product Development
Postfach 3049
67653 Kaiserslautern roese@mv.uni-kl.de
Petra Vogt
Pecos AG
Musilweg 2
21079 Hamburg
pvogt@pecos.de
www.pecos.de
www.mv.uni-kl.de
Abstract
Es gibt kaum Untersuchungen zur Arbeitssituation
der Usability Professionals in Deutschland. Das
German Chapter der Usability Professionals Association e.V. (gc-UPA) möchte mit einer umfassenden
Befragung in Deutschland die individuelle und biographische Situation der Usability-Spezialisten, die
eingesetzten und angebotenen Methoden, sowie das
Honorar- und Gehaltsgefüge beleuchten. Ergebnisse
der Befragung soll der „Branchenreport Usability
2003“ sein, der gleichermaßen für Usability Professionals, anwendende Unternehmen, ausbildende
Organisationen, die Presse und die breite Öffentlichkeit interessant ist.
Keywords
UPA, Usability, Fragebogen, Methoden, Honorar,
Gehalt
1. EINLEITUNG
Usability – oder zu Deutsch „die Gebrauchstauglichkeit“ – ist ein etablierter Forschungsgegenstand in
oder Teilen davon für den persönlichen Gebrauch oder zur Verwendung in Lehrveranstaltungen zu erstellen. Der Verkauf oder gewerbliche Vertrieb ist untersagt. Rückfragen sind zu stellen an den
Proceedings of the
84
verschiedenen Wissenschaftsdisziplinen: Psychologen, Informatiker, Arbeitswissenschaftler, Designer,
Soziologen und manche anderen Wissenschaftler
aus benachbarten Bereichen beschäftigen sich
schon seit Jahren damit.
Der Durchbruch bei der Anwendung im Unternehmensalltag erfolgt im deutschsprachigen Raum jedoch nur zögerlich. In den USA dagegen, wo mit der
Usability Professionals’ Association UPA schon seit
1991 ein eigener Berufsverband für Usability Spezialisten existiert, gibt es zahlreiche Firmen, die mit
Usability Profis zusammenarbeiten bzw. eigene
Usability Engineers angestellt haben. Die Website
der UPA listet mehr als 60 Usability Dienstleister
auf. Der größte von ihnen hat an die 100 Mitarbeiter
[4].
In Deutschland ist das Thema Usability erst in den
letzten Jahren verstärkt in das Blickfeld der Industrie
gerückt. Besonders im Internet-Sektor fand das
Thema viel Beachtung und auch MedienAufmerksamkeit. Die Bedienbarkeit hat hier eine
besonders klar ersichtliche Bedeutung, da Websites
direkt auf Anhieb überzeugen müssen, weil der
Wettbewerber nur einen Mausklick entfernt ist. Aber
auch in anderen Anwendungsbereichen – von der
Öffentlichkeit eher unbemerkt – ebnete sich das
Thema „Usability“ mehr und mehr den Weg in die
Köpfe der Verantwortlichen. Die zahlreichen Neugründungen von Usability-Agenturen sind ebenso
ein Indiz für diese Entwicklung wie die wachsende
Anzahl von Stellenausschreibungen durch Unternehmen, die sich explizit an Usability Profis richten.
Auf diese Art und Weise hat sich auch in Deutsch-
Usability Report Deutschland 2003
land ein Berufsbild für Usability Professionals entwickelt.
Wie in jeder jungen, aber aufstrebenden Branche
herrscht jedoch viel Unklarheit, viel Diskussion und
viel Bewegung. Fragen nach Verdienstmöglichkeiten, Aufstiegsperspektiven, regionaler und branchenspezifischer Verteilung der Usability-Aktivitäten
stellen sich. Welche Firmen agieren in diesem Bereich? Wie groß sind diese? Über welches Angebotsspektrum verfügen sie? Die Kenntnis des Preisgefüges wird als Grundlage für Business-Pläne und
erfolgreiches Wachstum benötigt. Diese und viele
weitere Fragen stellen sich jedem BerufsInteressenten, aber auch jeder Firma, die in dieses
Thema investieren möchte oder muss. Um in der
Branche professionell agieren zu können, ist es für
alle sehr wichtig, einen „Marktüberblick“ zu haben.
Dieser liegt jedoch bisher nicht vor. Derzeit existieren allenfalls Ansätze zu einem Branchenüberblick
im Bereich Usability. So unternahm Jakob Nielsen
2001 im Rahmen seiner User Experience World
Tour den Versuch, einen Gehaltsspiegel zu erstellen, um weltweit die Einkommenssituation von Usability-Spezialisten vergleichen zu können [1]. Dabei
wurden nur diejenigen erfasst, die an der Seminarreihe teilnahmen – eine höchst spezielle Stichprobe.
Auch der Hightext-Verlag unternimmt 2003 den Versuch, ein „Branchenhandbuch“ Usability herauszubringen – jedoch mit dem Fokus der Selbstdarstellung von Usability-Dienstleistern. Peissner und Röse
haben 2002 eine Untersuchung zur Situation von
Usability-Leistungen im Bereich der Webagenturen
vorgestellt [2].
Alle diese Bemühungen bleiben bisher punktuell und
haben nicht den Anspruch ein objektives, unverfälschtes Bild einer möglichst großen Menge aller in
Deutschland im Bereich Usability Tätigen zu erheben. Aus diesem Grund ist das German Chapter der
Usability Professionals Association e.V. (gc-UPA)
als anerkannter Berufsverband der Deutschen Usability Profis angetreten, die Pionierarbeit zu leisten,
den ersten Branchenreport Usability in Deutschland
zu erstellen.
2. DER BRANCHENREPORT USABILITY
2003
Für den Branchenreport Usability muss das gc-UPA
echte Basisarbeit leisten, da bisher wenige objektiven Daten vorliegen, die für einen Marktüberblick
geeignet sind. Es erscheint am sinnvollsten im Sinne einer umfassenden Bestandsaufnahme mehrere
Themengebiete zu beleuchten. Ingesamt kristallisieren sich vier Schwerpunkte heraus:
4. und der Gehaltsspiegel
Wie aus den Themen Honorar- und Gehaltsspiegel
schon ersichtlich, soll hierbei sowohl die Situation
angestellter als auch selbständiger UsabilitySpezialisten erfasst werden.
Natürlich können nicht alle Themen umfassend und
unter Einbezug aller relevanten Abhängigkeiten in
einem ersten Fragebogen behandelt werden. Vielmehr soll der Branchenreport Usability den Grundstein für eine empirische Untersuchung der Branche
legen, dem mittelfristig weitere Detailuntersuchungen folgen. Die Schwerpunkte solcher Nachfolgeuntersuchungen werden entsprechend der Ergebnisse
der Erststudie gesetzt: Stellt sich zum Beispiel heraus, dass in punkto angewandter Methoden noch
viele Fragen offen geblieben sind, erscheint es sinnvoll, dort mit einer Detailstudie nachzusetzen.
2.1 Zielgruppen
Der Branchenreport Usability dient (vgl. auch
Abbildung 1)
• zur Orientierung für jeden einzelnen Usability
Professional
• zur Information für anwendende oder interessierte Unternehmen und Organisationen
• als Hintergrundinformation für ausbildende Organisationen und Institute
• als Material für Presse- und Öffentlichkeitsarbeit
Dem einzelnen Usability Professional soll der Branchenreport Usability behilflich sein, die eigene Position im Markt besser einschätzen zu können. So wird
er dem Report beispielsweise entnehmen können,
wie sich die Kollegen aus- und weiterbilden. Er kann
sich informieren, welche Methoden eingesetzt werden, und hat damit einen Vergleich, ob er selbst
noch „up to date“ ist. Er kann einschätzen, in welchem Bereich er sich mit seinem individuellen Gehalt im Vergleich zu den Branchenkollegen deutschlandweit bewegt. Der Branchenreport Usability soll
auch einen Überblick darüber ermöglichen, welche
Faktoren ausschlaggebend für ein höheres Gehalt
sind, z.B. eine bestimmte Aus- oder Weiterbildung.
Unternehmen profitieren vom Branchenreport Usability ebenfalls auf vielfältige Weise. Sie können durch
den Marktüberblick einschätzen, welche Methoden
die Wettbewerber einsetzen und vor allem, welche
Preise dafür realisiert werden. Sie bekommen einen
Einblick, welche Gehälter derzeit marktüblich sind
und welche Voraussetzungen Bewerber typischerweise aufweisen oder aufweisen sollten.
1. die individuelle und biographische Situation der
Usability-Spezialisten,
2. die eingesetzten und angebotenen Methoden,
3. das Honorargefüge im Sinne eines Honorarspiegels
85
Beu, A., Reitmayr, E., Vogt, P., Mauch, D. & Röse, K.
Version bereits ab Mitte Juli 2003 zur Bearbeitung
im Internet veröffentlicht.
Anwendende
Unternemen
&
Organisationen
Usability
Professionals
Branchenreport
Usability
2003
Ausbildende
Institute &
Organisationen
Presse
&
Öffentlichkeit
Abbildung 1: Zielgruppen, an die sich der Branchenreport Usability 2003 richtet
Organisationen und Institute, die in der Aus- und
Weiterbildung von Usability-Professionals engagiert
sind, erhalten ebenfalls wichtige Informationen. Der
Branchenreport Usability wird einen Überblick darüber geben, welche Aus- und Weiterbildungsmöglichkeiten Usability Professionals derzeit nutzen.
Schließlich soll der Branchenreport Usability für die
Presse eine wichtige Informationsquelle werden. Er
ermöglicht Journalisten eine objektive Einschätzung
der Branche, ohne allein auf individuelles PRMaterial einzelner Unternehmen oder Organisationen angewiesen zu sein. Dies ist ein wichtiger weiterer Schritt zur Professionalisierung der Branche.
2.2 Vorgehensweise
Um einen möglichst breiten Überblick über die
Branche zu erhalten, bot es sich an, die Daten vor
allem über einen anonymen Fragebogen zu erheben. Der Fragebogen liegt in einer online veröffentlichten Form vor und wird zusätzlich in einer gedruckten Version auf der Mensch & Computer 2003
in Stuttgart ausgegeben.
Die Durchführung einer quantitativen Befragung im
Gegensatz zu qualitativen Interviews hat zum einen
den Zweck, die Repräsentativität der ermittelten
Daten zu gewährleisten. Durch eine möglichst umfassende Bekanntmachung der Umfrage auf verschiedensten Wegen soll eine möglichst große
Stichprobe an Usability Professionals aus unterschiedlichsten beruflichen Umfeldern erreicht werden. Außerdem sollen durch anonymisierte Fragebögen Daten erfasst werden, die in einem persönlichen Interview vielleicht ungern genannt werden
(z.B. Fragen nach Honoraren und Gehältern).
Um bereits zur Mensch & Computer 2003 erste Ergebnisse präsentieren zu können, wurde die Online-
86
Trotz der genannten Vorteile sind zusätzlich zu dieser quantitativen Befragung qualitative Interviews
vorgesehen, um vor allem den Bereich der eingesetzten Methoden etwas detaillierter untersuchen zu
können. Geplant sind ca. 10 Interviews mit im Usability-Bereich arbeitenden Personen, die sich bezüglich der Eigenschaften des anstellenden Unternehmens möglichst stark unterscheiden und einen
Querschnitt der Branche repräsentieren.
2.3 Der Fragenkatalog
Entsprechend der Zielsetzung, ein möglichst breites
Bild über die Usability-Branche zu verschaffen, wurde der Fragebogen mit einem relativ breiten Fragenspektrum angelegt. Um für den Honorar-Teil
eine möglichst hohe Anonymität zu erreichen und
einen Rückschluss auf einzelne Unternehmen oder
Personen unmöglich zu machen, wurde der Fragenblock zu den realisierten Honoraren komplett vom
übrigen Fragenkatalog getrennt. Später werden diese Daten getrennt gesammelt und ausgewertet. So
soll die Basis geschaffen werden, diese heiklen Unternehmens- und Personendaten ohne Bedenken
preisgeben zu können.
Fragenkatalog zum Branchenreport Usability 2003
Allgemeine
Fragen für den
Branchenreport
Usability
Fragen zur
Person
Fragen zum
Unternehmen
Fragen zur
Usability im
Unternehmen
Fragen zum
UsabilityHonorarspiegel
Erzielte
Honorare
Einschätzung
der Lage
Getrenntes Einsammeln und getrennte Auswertung
Abbildung 2: Gliederung des Fragebogens
Dementsprechend gliedert sich der Fragebogen in
zwei unabhängige Teile (vgl. auch Abbildung 2):
1. Fragen für den allgemeinen Branchenreport Usability 2003
2. Fragen für den Usability-Honorarspiegel 2003
Jeder Teil hat der besseren Übersichtlichkeit halber
eine zusätzliche Binnengliederung.
Der allgemeine Branchenreport Usability 2003 ist
untergliedert in Fragen:
a) zur Person
b) zum Unternehmen
c) zur Usability im Unternehmen
Im ersten Teil macht der/die Befragte Angaben zur
eigenen Person. Beantwortet werden Fragen zur
eigenen Ausbildung, Berufserfahrung, sowie ergriffenen Weiterbildungsmaßnahmen.
Anschließend wird nach den Eigenschaften des
Unternehmens gefragt, in dem der Befragte arbeitet.
Hauptsächlich geht es hier um Fragen wie zur Größe des Unternehmens oder die Anzahl an Mitarbeitern im Bereich Usability. Dieser Bereich wendet
sich sowohl an Angestellte als auch an Selbständige. 3 Fragen zum Gehalt richten sich jedoch speziell
an Angestellte.
Darstellung der Ergebnisse
Die Ergebnisse der Befragung werden als Branchenreport Usability 2003 in Berichtsform aufgearbeitet
(vgl. Abbildung 3). Ziel ist es, den Branchenreport
Usability 2003 einer breiten Öffentlichkeit bekannt
zu machen. Zusätzlich ist eine offensive Verbreitung
der Resultate innerhalb und außerhalb der Usability
Szene geplant. Dazu gehören beispielsweise weitere
Veröffentlichungen sowohl in Fachmagazinen und
auf Fachkonferenzen, wie auch in anderen Publikationen. Weiterhin wird die Presse angesprochen, um
sie für das Thema zu interessieren.
Der dritte Teilbereich zielt schließlich darauf ab, die
Usability-Tätigkeiten des Unternehmens näher zu
charakterisieren. In diesem Zusammenhang interessieren vor allem Fragen nach eingesetzten Methoden, zur Integration in den Projektablauf, nach dem
Vorhandensein und der Ausstattung eigener Usabilty
Labs und Methoden der Rekrutierung von Testpersonen.
Der Usability-Honorarspiegel ist ebenfalls der besseren Übersichtlichkeit halber in Unterbereiche gegliedert:
a) erzielte Honorare
b) Einschätzung der Lage
Dieser Teil der Befragung soll Auskunft über die von
Unternehmen erzielten Honorare für "klassische"
Usability-Dienstleistungen geben. Gefragt wird nach
Art und Umfang bestimmter Angebotspakete, sowie
dem Honorar, das üblicherweise für diese Dienstleistungen realisiert wurde. In diesem Zusammenhang
interessiert auch die Zufriedenheit mit den erzielten
Honoraren.
Insgesamt werden 55 Fragen gestellt, die zum Teil
in offenen und zum Teil in geschlossenen Antwortformaten vorliegen [3]. Offene Antwortformate, genau wie explorative Interviews, dienen dazu, relevante Kategorien zu erkennen, die in Folgeuntersuchungen eingesetzt werden können.
Der Fragenkatalog kam in intensiver Diskussion und
auf der Basis der vorliegenden Erkenntnisse zur
Branche zustande. Bei der Konstruktion der einzelnen Fragen wurden bestimmte Hypothesen zugrunde gelegt, die sich aus dem Vorwissen über die Usability-Szene ergeben haben. Ein häufig genanntes
Problem von Usability-Profis ist es beispielsweise,
dass sie sich nicht 100% ihrer Zeit dem Thema
selbst widmen können, sondern in ihrem Unternehmen zu einem großen Teil auch andere Aufgaben
übernehmen. Durch eine Frage, die speziell auf
dieses Phänomen abzielt, soll herausgefunden werden, wie verbreitet dieses Phänomen wirklich ist.
Abbildung 3: Entwurf des Titelblatt zum ersten Branchenreport Usability 2003
3. WIE GEHT’S WEITER?
Die Erstellung des Branchenreports Usability 2003
soll keine einmalige Aktion sein, vielmehr soll nach
einem gewissen zeitlichen Abstand die Befragung
wiederholt werden, um die Zahlen zu aktualisieren
und Trends sichtbar zu machen. Dabei fließen natürlich methodische Erfahrungen aus der vorangegangenen Befragung ebenso ein wie Bedürfnisse der
Usability Szene nach weiteren Informationen, die in
der ersten Befragung noch nicht erhoben wurden.
Doch es gibt noch viele Fragestellungen zum Thema „Usability“, die für Usability Professionals, Anwender, lehrende Organisationen und die Öffentlich-
87
Beu, A., Reitmayr, E., Vogt, P., Mauch, D. & Röse, K.
keit ebenfalls sehr interessant sind, aber eigentlich
nicht im Fokus des Branchenreports Usability liegen.
Beispielsweise wäre eine Übersicht der Bedürfnisse
und Anforderungen der anwendenden Unternehmen
und Organisationen sehr aufschlussreich. Eine weitere interessante Frage könnte die Wahrnehmung
des Themas „Usability“ bei den Konsumenten sein.
Deshalb möchte das German Chapter der UPA e.V.
versuchen, weitere Studien zu initiieren. Das gcUPA lädt daher alle Interessierten zu einer gemeinsamen Diskussion ein. Das Ziel ist, den Bedarf und
die Themen für weitere Befragungen zu durchleuchten und möglichst nächste konkrete Schritte in die
Wege zu leiten. Das gc-UPA bietet folgende Unterstützung hierfür an:
• Fachliche Beratung
• Zugang zu Usability Professionals
• Bereitstellen des Namens und des Logos der
UPA, um die Überzeugungskraft der Studie zu
unterstützen
• Unterstützung bei der Verbreitung
88
• Unterstützung bei der Vermarktung und Öffentlichkeitsarbeit
Vielleicht gelingt es, den Startschuss zu einer Reihe
von Studien unter dem Oberbegriff „Usability Report
Deutschland“ zu geben, in der der Branchenreport
Usability 2003 den Anfang macht.
4. REFERENZEN
[1] Nielsen, J.: Salary Survey: User Experience
Professionals 2001. Nielsen Norman Group
2001.
[2] Peissner, M. und Röse, K., Usability Engineering
in Germany: Situation, Current Practice and
st
Networking Strategies, Proceedings of the 1
EUPA conference (2002).
[3] Bortz, J. und Döring, N., Forschungsmethoden
und Evaluation für Sozialwissenschaftler, Springer Verlag (1995).
[4] Usability Professionals’ Association UPA,
http://www.upassoc.org (2003).
Referenten
Andreas Beu ist Senior Usability Consultant und Manager Industry Solutions bei der User
Interface Design GmbH in München. Im Rahmen dieser Tätigkeit berät er Unternehmen aus
dem industriellen Umfeld bei der benutzergerechten Gestaltung von Software Produkten
und interaktiven Dienstleistungen. Anfang 2003 übernahm er zusätzlich die Leitung der UID
Geschäftsstelle in München. Andreas Beu ist weiterhin Vize-Präsident des German Chapters
der Usability Professionals’ Association e.V.
Ellen Reitmayr ist Studentin der Psychologie an der Universität Mannheim. Neben der
Wahl entsprechender Studienfächer hat sie sich durch Praktika und das Schreiben ihrer
Diplomarbeit in der Abteilung für User-Centered Design der IBM Entwicklung in Böblingen
auf Software Usabiliy spezialisiert.
Petra Vogt arbeitet als Consultant bei der Pecos AG in Hamburg. Ihr Schwerpunkt liegt auf
der Qualitätssicherung von Websites, besonders unter dem Gesichtspunkt Usability. Petra
Vogt ist Autorin mehrerer Computer-Fachbücher. Sie ist Mitglied des Vorstands des German
Chapters der Usability Professionals’ Association e.V. und dort für Presse- und Öffentlichkeitsarbeit zuständig.
Daniel Mauch ist bei Carl Zeiss Vision Projekt-Leiter für den Bereich Usability. Er ist dort
zuständig für Prototyping, User Interface Design, Testing, Implementation, Entwicklung von
Innovativen Bedienkonzepten und Einarbeitung des Usability Prozesses in die bestehende
Firmenstruktur. Er ist außerdem Mitglied des Vorstands des german Chapters der Usability
Professionals’ Association e.V. und dort zuständig für die Strategisches Zukunftsplanung.
Kerstin Röse hat an der Humboldt Universität zu Berlin Psychologie studiert und an der
Universität Kaiserslautern im FB Maschinenbau promoviert. Von 1996 bis 2002 arbeitete Sie
am Lehrstuhl für Produktionsautomatisierung sowie am Zentrum für Mensch-MaschineInteraktion und wurde 2002 zur Juniorprofessorin für ‚Nutzergerechte Produktentwicklung' an
der Universität Kaiserslautern berufen. Seit 1996 arbeitet sie als Usability Consultant. Sie ist
außerdem Präsidentin des German Chapters der Usability Professionals’ Association e.V.
89
ERLERNEN UND ANWENDEN:
PROJEKTERFAHRUNGEN MIT METHODEN
BENUTZERZENTRIERTEN GESTALTENS
FOCUS GROUP – ERHEBUNG DES INFORMATIONSBEDARFS
FÜR DAS INTRANET „POLIZEI ONLINE“
Friederike Länge
Hochschule der Medien (FB 3)
Wolframstraße 32
70191 Stuttgart
fl06@hdm-stuttgart.de
www.hdm-stuttgart.de
Silke Lotterbach
Hochschule der Medien (FB 3)
Wolframstraße 32
70191 Stuttgart
silke@lotterbach.de
Stuttgart Focus Groups mit Polizeibeamten durch.
ABSTRACT
Im Projekt „Polizei-Online“ haben Studierende des
Studienganges Informationsdesign der Hochschule
der Medien (HdM) in Stuttgart eine Nutzungskontextanalyse für das Intranet der Landespolizei
Baden-Württemberg erstellt. Dabei wurde die
Methode der Focus Group angewandt, welche die
Studierenden im Seminar Konzeption und Evaluation
erlernten. Durch die Zusammenarbeit mit der
Landespolizei bot sich den Studierenden die
Möglichkeit, diese Methode anhand eines realen
Projektes zu erlernen und praktisch anzuwenden.
In studentischen Kleingruppen wurden 2002/2003
drei Focus Groups durchgeführt. Dr. Michael Burmester – Professor für Ergonomie und Usability an
der HdM – betreute die Vorbereitung und Durchführung dieses Projektes. Die Landespolizei gewann
durch die Zusammenarbeit wichtige Daten, die für
den Relaunch der Intranetseiten verwendet werden.
Keywords
Focus Group, Polizei-Online, Ausbildung, Hochschule der Medien Stuttgart, Benutzerzentrierte
Gestaltung, Nutzungskontextanalyse
1. EINLEITUNG
Das Focus Group Projekt entstand durch die Kooperation der Hochschule der Medien in Stuttgart
(www.hdm-stuttgart.de) mit der Landespolizei
Baden-Württemberg. Diese betreibt in ihrem Intranet
unter der Bezeichnung „Polizei-Online“ ein Bildungsund
Informationssystem.
Zur
inhaltlichen
Optimierung der Plattform führte der Studiengang
„Informations- design“ der Hochschule der Medien in
Stuttgart).
Proceedings of the
Ziel der Studie im Wintersemester 2002/2003 war
es, herauszufinden, welche Informationen die
Beamten wie schnell und in welcher Form
benötigen. Im vorangegangenen Semester hatten
die Studierenden des Studiengangs „Informationsdesign“ das Intranet der Polizei unter
Usability-Aspekten evaluiert. Aus dem Bericht ging
hervor, dass das Intranet erheblich besser
strukturiert werden müsste, um für die Beamten
attraktiv und nützlich zu sein.
Für die Informationsdesign-Studierenden war dies
eine gute Gelegenheit, den Studienschwerpunkt
Konzeption und Evaluation zu vertiefen und
praktische Erfahrungen mit einem realen Projekt zu
machen.
2. METHODE – FOCUS GROUP
Um
möglichst
vielfältige
und
qualitative
Informationen von den Beamten zu erhalten, wurde
die Methode der Focus Group gewählt. Dabei
werden mehrere Personen gleichzeitig zu einem
Thema befragt. Die Teilnehmer können sich unter
Leitung eines Moderators gegenseitig austauschen
und
anregen.
So
können
unterschiedliche
Perspektiven und vielfältige Meinungen aufgezeigt
werden. Die soziale Interaktion der Teilnehmer ist
das unterscheidende Merkmal zu anderen Verfahren
der Datengewinnung [1, 2, 3].
Anhand
der
Focus
Groups
sollte
der
Nutzungskontext des Intranets „Polizei-Online“
geklärt und Ideen für einen Relaunch der Seiten entwickelt werden.
Zunächst wurden drei besonders wichtige Zielgruppen innerhalb der Polizei identifiziert, mit denen drei
Studierendengruppen die Focus Groups durchführen
sollten: Streifenbeamte, Ermittler und Führungskräfte.
Die Studierenden des Studiengangs Informationsdesign bereiteten die Focus Groups in Kleingruppen
vor und führten sie mit den jeweiligen Zielgruppen
durch.
Innerhalb von vier Monaten wurde ein detaillierter
Moderationsleitfaden erarbeitetet, drei Focus Groups
93
Länge, F. & Lotterbach, S.
durchgeführt und die gewonnenen Daten ausgewertet. In Übungen wurden die Studierenden für verschiedene Situationen sensibilisiert und konnten
Sicherheit im Umgang mit problematischen Befragungs- und Moderationssituationen gewinnen.
2.1 Planungssitzung
Bei der Planungssitzung war es wichtig, Umfang und
Ziele des Projekts festzulegen. In der Studie sollten
folgende Fragen geklärt werden:
•
Erhebung des Informationsbedarfs der Nutzer:
Welche Informationen benötigen die Polizeibeamten bei ihrer Arbeit?
•
Erhebung des Anspruchs an die Qualität der Informationen: Wie aktuell und verlässlich müssen
diese Informationen sein?
•
Erhebung von Perspektiven: Wie stellen sich die
Nutzer die Zukunft des Intranets vor?
Um Objektivität zu gewährleisten wäre die Durchführung von je zwei Focus Groups pro Zielgruppe
ideal gewesen. Da das Seminar jedoch auf vier Wochenstunden begrenzt war, wurde nur je eine Focus
Group pro Zielgruppe durchgeführt.
Wichtige Kriterien für ein homogenes Ergebnis
waren:
•
Jede Gruppe sollte den gleichen Anteil an Frauen und Männern haben.
•
Teilnehmer sollten unterschiedlich lange Berufserfahrung haben.
•
Alle Teilnehmer sollten auf der gleichen Hierarchiestufe stehen. Auf keinen Fall dürfen Vorgesetzter und Mitarbeiter in einer Gruppe vertreten
sein. Dies hätte sich eventuell negativ auf die
Offenheit einzelner Teilnehmer in der Gruppe
auswirken können.
2.2 Moderationsleitfaden
Ein guter Moderationsleitfaden trägt entscheidend
zur Effektivität und dem Erfolg einer Focus Group
bei. Der Moderationsleitfaden sollte vor der
Anwendung
getestet
und
gegebenenfalls
überarbeitet werden.
Die verschiedenen Phasen der Focus Group [4] sind
im Moderationsleitfaden ausgearbeitet und mit Zeitangaben versehen:
•
Eröffnung: Begrüßung; Vorstellung; Organisatorisches.
•
Einleitung: Einstieg ins Thema und Aufbauen
einer positiven Arbeitsatmosphäre. Frage:
„Wann haben Sie zum letzten Mal im Dienst
eine Information gesucht und nicht gefunden?“
•
94
Überleitung: führt in das Hauptthema ein. Frage:
„Gehen Sie die letzte Woche in Gedanken durch
und halten Sie alle Tätigkeiten auf einer Karte
fest.“
•
Schlüsselphase: Das Hautthema wird behandelt
und die entscheidenden Daten werden gesammelt. Frage: „Welche Informationen haben
Sie bei den jeweiligen Tätigkeiten benötigt?“
•
Schlussphase: Das Thema wird abgerundet und
abgeschlossen; die Teilnehmer erhalten die Gelegenheit, noch nicht Erwähntes anzubringen;
Bedanken für die Mitarbeit.
Im Projekt „Polizei Online“ enthielt der Moderationsleitfaden außerdem folgende Daten in einer übersichtlichen und schnell zu erfassenden Form
•
Die nötigen Vorbereitungen und Materialien am
Tag der Durchführung.
•
Stichworte zum Vorgehen, Namen der handelnden Personen und Aufgabenverteilung.
•
Pausen, Bearbeitungs- und Diskussionszeiten.
•
Fragen und Ziele.
Im Unterricht übten die Studierenden der
Hochschule der Medien die Moderation der Focus
Groups anhand des Leitfadens mit Kommilitonen als
Teilnehmern. So konnten die Leitfäden im Vorfeld
optimiert und die Moderation, Protokoll und
Assistenz trainiert werden. Schwierige Situationen
wurden im Vorfeld identifiziert und besprochen.
Die Moderationsleitfäden für die verschiedenen Zielgruppen unterschieden sich nur in Details voneinander. Die Phasen, Aufgaben und Zeitangaben
stimmten in allen drei Versionen überein, um die Ergebnisse miteinander vergleichen zu können.
2.3 Aufgabenverteilung
Bei der Befragung zu Analyse des Nutzungskontextes ist folgende Haltung der Moderatoren von
Vorteil: die Nutzer stehen im Vordergrund – sie
kennen sich in ihrem Fachgebiet und Umfeld aus
und sind dafür die Experten. Die Moderatoren fragen
nach und versuchen, die Sicht- und Arbeitsweise der
Nutzer zu verstehen – sie agieren wie Schüler [5].
Die Teilnehmer sollen sich möglichst authentisch
verhalten, um reale Daten zu liefern. Im Projekt
wurden pro Focus Group sechs Teilnehmer
eingeladen.
Die Moderatoren leiten den Diskussionsprozess und
sind für die Durchführung der Focus Group verantwortlich. Es wurden für jede Focus Group zwei Moderatoren eingesetzt, um die hohe Verantwortung zu
verteilen. Sie achteten darauf, dass der Moderationsleitfaden eingehalten wurde, konnten aber,
wenn es nötig war, flexibel reagieren und auf die
Teilnehmer eingehen.
Die Protokollanten dokumentieren die Aussagen der
Teilnehmer. Um die Aussagen auswerten zu
können, ist es wichtig, dass sie den jeweiligen Teilnehmern zugeordnet werden können. Aus dem
Protokoll muss auch hervorgehen, worauf sich die
Aussagen beziehen. Im Transkript muss die
Neutralität gewahrt werden, weshalb die Aussagen
Focus Group – Erhebung des Informationsbedarfs für das Intranet „Polizei Online“
chronologisch und möglichst wörtlich festgehalten
werden sollten. Auf jeden Fall muss der Sinn erhalten bleiben. Es dürfen keine Interpretationen einfließen. Um ein möglichst präzises Transkript zu
erstellen, wurden je zwei Protokollanten eingesetzt.
Die Assistenten unterstützen die Moderatoren. Sie
kümmern sich um die technische Unterstützung, Videoaufnahme, Arbeitsmaterialien und Getränke. In
jeder Focus Group wurde ein Assistent eingesetzt.
Im Projekt „Polizei-Online“ übernahm der Dozent die
Rolle des Supervisors. Er verfolgte den Ablauf der
Focus Group und konnte in schwierigen Situationen
Tipps geben oder eingreifen.
Die gute Teamarbeit war ein entscheidender Faktor
bei der Durchführung. Die Studierenden konnten
sich gegenseitig Hilfestellung geben und so Fehler
vermeiden.
2.4 Durchführung
Die Focus Groups wurden während der Dienstzeit
der Beamten in den Räumlichkeiten der Polizei
Baden-Württemberg durchgeführt und dauerten jeweils ca. 3,5 Stunden. Außer den oben erwähnten
Teilnehmern war auch ein Vertreter der Projektgruppe „Polizei-Online“ als Beobachter anwesend.
•
Interpretation
Bei der Interpretation wurden die Aussagen der
Teilnehmer
für
den
Abschlussbericht
ausgewertet und komprimiert. Durch die
Indexierung können alle Aussagen, die zur
Interpretation geführt haben, zurückverfolgt
werden.
Nach der Auswertung lagen die Daten in übersichtlicher und strukturierter Form vor. Der Bericht, der
an die Polizei Baden-Württemberg ging, erläuterte
intensiv die Methodik, Durchführung und Ergebnisse
der Focus Groups.
3. ERGEBNISSE
Die Teilnehmer der Focus Group haben sich sehr
konstruktiv an der Durchführung beteiligt, was zu einer großen Menge interessanter Informationen zum
Informationsbedarf und zu den Anforderungen an
das Intranet geführt hat.
Insgesamt wurden 31 Themenkomplexe mit jeweils
einer Fülle von Anforderungen erarbeitet. Folgende
Beispiele demonstrieren die Art der erfassten Anforderungen und des Informationsbedarfs:
•
Den Streifenbeamten war es besonders wichtig
bei der Aufnahme eines Verkehrunfalls unterstützt zu werden, zum Beispiel durch Formulare
und Checklisten.
•
Für Ermittler ist es wichtig, auf aktuelle Listen
mit Institutionen (Hotline/Telefonliste) für
Opferbetreuung zugreifen zu können, da sie
häufig mit Opfern und deren Angehörigen zu tun
haben.
•
Nach jeder Focus Group folgte eine Besprechung
der Moderatoren, Protokollanten und Assistenten mit
dem Supervisor. Zu diesem Zeitpunkt sind
Erfahrungen und Eindrücke noch sehr präsent und
können leicht dokumentiert werden, um zukünftige
Focus Groups zu optimieren. Außerdem können
nochmals wichtige Ergebnisse festgehalten werden.
Die Führungskräfte haben den größten Informationsbedarf. Sie brauchen Informationen, um
Entscheidungen treffen zu können und Managementaufgaben zu erfüllen (z.B. Ressourcen- und
Personal-Management).
•
2.5 Auswertung
Die Auswertung erfolgte in vier Schritten [5].
Alle Beamten waren sich einig darüber, dass
gesetzliche Grundlagen unbedingt hochaktuell
und zuverlässig sein müssen. Bei Informationen
zur Meinungsbildung stand die Quellenangabe
im Vordergrund.
•
Zu den Zukunftsperspektiven kamen wenige Anregungen. Dies ist vermutlich darauf zurück zu
führen, dass es den Teilnehmern leichter fiel
aktuelle Bedürfnisse zu formulieren als visionäre
Wünsche. Es wurden die Teilnehmer nach dem
Wunsch von Informationen zu eher privaten
Informationen befragt. Hier zeigte sich, dass die
Focus Group Teilnehmer eine klare Trennung
zwischen Arbeit und Freizeit vornahmen.
Trotz Nervosität war der Ablauf der Focus Groups
zielgerichtet und erfolgreich, was für eine gute und
präzise Vorbereitung sprach.
Kleinere Probleme waren:
•
Die Verschiebung des Zeitplans.
•
Die Verspätung einzelner Teilnehmer.
•
Fixierung einzelner Teilnehmer auf spezielle
Problemfelder.
•
Transkript
Das Transkript enthielt eine chronologische Abfolge der Teilnehmeräußerungen ohne Interpretationen.
•
Textsegmente
Aus dem Transkript wurden die einzelnen Aussagen der Teilnehmer extrahiert und aufgelistet.
•
Indexierung
Bei der Indexierung wurden die Textsegmente
inhaltlich gruppiert und bestimmten Inhalten (Indexen) zugeordnet. Die Anzahl der Unterpunkte
in den einzelnen Bereichen variierte je nach
Umfang der Informationen.
4. FAZIT
Anhand des realen Projekts „Polizei-Online“ konnten
die Studierenden intensive und praktische Erfahrungen im Umgang mit Focus Groups, benutzerzentrierter Vorgehensweise, Projektplanung, Organisation und Teamarbeit sammeln.
95
Länge, F. & Lotterbach, S.
Im Gegenzug erhielt die Landespolizei eine
qualitativ hochwertige Nutzungskontextanalyse zur
Auswahl relevanter Informationen und deren
Strukturierung im Intranets.
Das Projekt mit einem Partner außerhalb der Hochschule zeigt auf, wie wissenschaftliche Methoden
zur Datenerhebung und Analyse erfolgreich in der
Praxis eingesetzt werden können.
5. TEAMARBEIT
Folgende Personen trugen auf der Seite der
Hochschule der Medien zum Gelingen des Focus
Group Projekts „Polizei-Online“ bei: Der Dozent
Prof. Dr. Michael Burmester und die Studierenden
des Studiengangs Informationsdesign an der Hochschule der Medien Stuttgart – Yulia Abele, Agnes
Bachtin, Beatrix Buck, Martin Burkart, Trixy Freude,
Veronika Hilz, Ulrike Pfeil, Katrin Polzer, Jürgen
Schiel, Mildred Schill, Silke Tanzer, Isabel Weissbrodt.
96
6. REFERENCES
[1] Caplan, S. ‚Using Focus Groups Methodology
for Ergonomic Design’, Ergonomics 33, 5, Seite
527-533 (1990).
[2] Krueger, R.A. & Casey, M.A., ‘Focus Groups, A
Practical Guide for Applied Research’, London:
Sage (2000).
[3] Nielsen, J., ‘Usability Engineering’, San Diego:
Morgan Kaufmann (1993).
[4] Wennecker, G. ‚Die Fokusgruppe. Eine Methode
für die Requirementsanalyse zur ergonomischen
Systemgestaltung.’ Diplomarbeit am Fachbereich Humanwissenschaften der Universität
Osnabrück (2001).
[5] Beyer, H. & Holtzblatt, K., ‘Contextual design:
defining customer centered systems’, Morgan
Kaufman Publishers (1998).
Focus Group – Erhebung des Informationsbedarfs für das Intranet „Polizei Online“
Referentinnen
Friederike Länge studiert im 5. Semester Informationsdesign an der Hochschule der
Medien in Stuttgart. Ein Schwerpunkt des Studiengangs ist es, Evaluationsmethoden
kennen zu lernen und anzuwenden. Die Kooperation mit der Landespolizei BadenWürttemberg
ermöglichte
praktische
Erfahrungen
mit
heuristischen
Evaluationsmethoden und Focus Groups.
Friederike Länge war vor ihrem Studium als Krankenschwester am Robert-BoschKrankenhaus in Stuttgart tätig. Sie wird ihr Studium voraussichtlich im Januar 2005
abschließen.
Silke Lotterbach ist Studentin im 5. Semester Informationsdesign. Im Projekt „PolizeiOnline“ konnte sie den Studienschwerpunkt „Konzept und Evaluation“ praktisch
vertiefen und Erfahrungen in der Durchführung von Focus Groups sammeln.
Silke Lotterbach war drei Jahre als Werbe- und Medienvorlagenherstellerin tätig.
Danach studierte sie vier Semester „Communication“ an der Napier University in
Edinburgh/Schottland, bevor sie an die Hochschule der Medien in Stuttgart wechselte.
Ihr Studiengang endet voraussichtlich im Januar 2005.
97
BEDIENERVERHALTEN UND FEEDBACKQUALITÄT
BEI DER STEUERUNG EINER
COMPUTERSIMULIERTEN HEIZUNGSANLAGE
Claudia Schmeink
TU Darmstadt
Hochschulstraße 1
64289 Darmstadt
c.schmeink@web.de
Jürgen Sauer
TU Darmstadt
Hochschulstraße 1
64289 Darmstadt
sauer@psychologie.tudarmstadt.de
ABSTRACT
Untersucht wurde der Einfluss unterschiedlicher
Feedback-Qualitäten eines computersimulierten
Heizungssystems auf das Steuerungsverhalten von
Nutzern. Aufbereitetes Feedback unterstützte effizientes Steuerungsverhalten insofern, als eine detaillierte Rückmeldung über den Gesamtenergieverbrauch dabei zu einer besseren Steuerungsleistung führte. Weiterhin unterstützte eine graphische
Darstellung der erreichten Raumtemperaturen im
Vergleich zu den vorgegebenen den Nutzer bei der
Systembedienung. Quantitative und qualitative Daten wurden bei der Untersuchung erhoben. In einer
Nachbefragung zu der Bedieneroberfläche ergaben
sich noch wesentliche Verbesserungsvorschläge.
Gewünscht wurde u. a. ein Richtwert für die Menge
an Energie, die normalerweise gebraucht wird, ein
höherer Automatisierungsgrad und eine Anleitung,
wie das Verschwenden von Energie zu vermeiden
ist.
Keywords
Computersimulation, User Interface Design, HomeEnvironment
1.
EINLEITUNG
Bei der Suche nach Forschungsarbeiten zur Entwicklung und Gestaltung privat genutzter Geräte und
Systeme findet man einige Veröffentlichungen (für
einen Überblick: [1]). Untersuchungen zu Heizungssystemen gibt es jedoch nur wenige (z. B.
Stuttgart).
Proceedings of the
98
David Wastell
Information Systems Institute
University of Salford
Salford, M5 5WT
Great Britain
d.wastell@salford.ac.uk
[2]). Das ist erstaunlich, weil nahezu jeder Haushalt
eine Heizung besitzt und zudem durch ungünstiges
Heizverhalten Energie verschwendet wird. Damit
gibt es Belastungen auf zwei Ebenen: gesellschaftlich durch die Umweltbelastung und durch das unnötige Verbrauchen von Ressourcen, und individuell
durch vermeidbare Heizkosten. Unsere Untersuchung möchte einen Beitrag zur sinnvollen Gestaltung von Heizungssystemen leisten.
In einer Voruntersuchung an 40 Haushalten in Südhessen stellten wir fest, dass derzeitige Heizungssysteme, falls sie überhaupt zugänglich sind, meist
nicht transparent und damit für Laien nicht gut bedienbar sind. Ein Heizungsinstallateur riet dem Kunden beim Einbau des neuen Systems gar, dieses
nicht zu verstellen, da es optimal eingestellt sei. Die
Nutzer bekommen außer der jährlichen Heizkostenabrechnung und der tatsächlichen Temperatur in der
Wohnung bei Anwesenheit keine Rückmeldung über
die Güte des Heizverhaltens. Der Nutzer kann meist
nicht nachvollziehen, ob er sparen könnte, wie viel
und vor allem durch welche Maßnahmen. Laut Norman [3] jedoch soll der Benutzer leicht erkennen,
wie das System funktioniert, welches Modell dahinter steht und zusätzlich den aktuellen Zustand des
Systems feststellen können. Unangemessene Bedienung ist schließlich nicht das Erkennungszeichen
eines schlechten Nutzers sondern eines suboptimalen Systems [4].
Unser Ziel ist es, Gestaltungsrichtlinien für Heizungssysteme zu entwickeln, die den Ansprüchen
der Transparenz und der Bedienbarkeit gerecht werden. Das Problem der kostenintensiven Entwicklung
komplexer Systeme für experimentelle Untersuchungen lässt sich durch den Einsatz von Simulationen umgehen (z. B. [5]). Diese bieten den Vorteil,
mehrere mit Hilfe von qualitativen Daten entwickelte
Benutzeroberflächen innerhalb kurzer Zeit von mehreren Nutzern parallel an verschiedenen Computern
testen zu lassen. Zusätzlich ergeben sich ohne
Mehraufwand verlässliche quantitative Daten, welche die Güte der Transparenz und Bedienbarkeit
durch Leistungsmaße widerspiegeln.
Bedienerverhalten und Feedbackqualität bei der Steuerung einer computersimulierten Heizungsanlage
2.
SIMULATIONSAUFGABE CHESS
Unter Berücksichtigung der Erfahrungen und Rückmeldungen aus den Haushalten der Vorfelduntersuchung haben wir drei Bedieneroberflächen kreiert,
die mit einem eigens dafür entwickelten computersimulierten Heizungssystem CHESS (Central Heating System Simulation) getestet werden können.
Aufgabe der Benutzer ist es, eine 3-Zimmer Wohnung zu beheizen. Ihr Ziel ist es, ein vorgegebenes
Temperaturniveau zu erreichen und zugleich den
Energieverbrauch zu minimieren.
Die Testpersonen stellen die Heizung zentral für
jeden Raum der zu beheizenden Wohnung ein. Die
Einstellung wird in einem Koordinatensystem vorgenommen, dessen Abszisse die 24 Stunden eines
Tages und dessen Ordinate die zu erreichende
Temperatur abbildet (siehe Abb. 1). Der Nutzer kann
mit Hilfe der Maus einen Block markieren, der die
gewünschte Betriebsdauer der Heizung und die zu
erreichende Zieltemperatur darstellt. Diese Einstellungen können als Vorlagen gespeichert und modifiziert werden.
F1 erhält der Nutzer in einer Monatsübersicht Rückmeldung über den Energieverbrauch und die Kosten
aller simulierten Tage. Bei Feedbackqualitätsstufe
F2 erhöht sich die Detailliertheit des Feedbacks
noch um ein Maß für die geschätzte Energieverschwendung.
Die Rückmeldungen werden unterschiedlich präsentiert. Alle Testpersonen bekommen für den jeweils
zuletzt simulierten Tag eine Graphik, in der die erreichte Raumtemperatur für den Tag und Raum in
einem der Heizungseinstellung entsprechen Koordinatensystem abgetragen ist (siehe Abb. 2). Als zusätzliche Information erhalten die Nutzer die Außentemperatur des Tages.
Abbildung 2: Graphische Rückmeldung über die erzielte Raumtemperatur.
In einem Monatsbericht erhalten die Versuchspersonen eine tabellarische Rückmeldung über ihre Ergebnisse (siehe Abb. 3). Diese ist unterschiedlich für
die einzelnen Bedingungen.
Abbildung 3: Tabellarische Rückmeldung im Monatsbericht, hier am Beispiel der Feedbackstufe F2.
Abbildung 1: Einstellen der Heizung.
Die drei getesteten Oberflächen unterscheiden sich
im Grad der Transparenz des Systems. Die Systemtransparenz ist realisiert durch unterschiedlich detaillierte Rückmeldequalitäten über die erzielten Effekte
der vorgenommenen Einstellungen (siehe Tab. 1).
Versuchspersonen mit der Feedbackqualität F1 und
F2 haben die Möglichkeit, Ihre Heizeffekte zusätzlich in einem Tagesbericht zu überprüfen. In dem
Tagesbericht können Ergebnisse für alle Räume und
Tage auch rückwärtig abgerufen werden (siehe Abb.
4).
Feed- Rückmeldung zusätzlich zum erreichten
back Komfort
F0
Keine
F1
Energieverbrauch / Kosten
F2
Energieverbrauch / Kosten + Verschwendung
Tabelle 1: Detailliertheit der Feedbackqualitäten.
Rückmeldung über das Erreichen der vorgegebenen
Zieltemperatur, im folgenden Komfort genannt, wird
als grundsätzlich verfügbare Information angesehen
und daher bei allen Rückmeldequalitäten konstant
gegeben. Bei Feedbackqualitätsstufe F0 kann der
Nutzer den Energieverbrauch am Ende eines simulierten Tages abrufen. In der Feedbackqualitätsstufe
Abbildung 4: Tagesbericht am Beispiel der Feedbackstufe F2.
99
Schmeink, C., Sauer, J. & Wastell, D.
3.
FRAGESTELLUNG UND HYPOTHESEN
Ziel ist es zu ermitteln, welche Feedbackqualitätsstufe es dem Nutzer am einfachsten macht, die Heizung effizient zu regulieren. Effizient regulieren bedeutet in dem Experiment, zu genau definierten
Zeiträumen in den einzelnen Zimmern genau vorgegebene Temperaturen zu erreichen und gleichzeitig
möglichst wenig Energie zu verbrauchen.
Unsere Hypothese ist, dass die Versuchspersonen
mit den detaillierteren Rückmeldungen aus System
F2 bessere Ergebnisse erzielen, also die vorgegebenen Temperaturen mit weniger Energie erreichen.
Zudem prüfen wir, ob durch Übung implizites Systemwissen erworben wird und differenziertes Feedback überflüssig macht.
4.
die dafür benötigte Menge an Energie (virtuelles
Maß), die entstandenen Kosten in Euro und den
geschätzten Anteil unnötig verbrauchter Energie. Im
Anschluss an die experimentelle Phase erheben wir
mit einem kurzen Fragebogen das gewöhnliche
Heizverhalten der Versuchspersonen und das mentale Modell, mit dem die Heizung bedient wird. Zum
Schluss befragen wir die Versuchspersonen in einem halbstrukturierten Interview noch zu den positiven und negativen Eigenschaften der Bedieneroberfläche und wie diese verbessert werden könnte.
5.
ERGEBNISSE
Bisherige Auswertungen scheinen zu bestätigen,
dass sich eine erhöhte Rückmeldequalität positiv auf
die Steuerungsleistung auswirkt (siehe Abb. 5).
METHODE
4.1 Versuchspersonen
Es nahmen 45 Studentinnen und Studenten an dem
Versuch teil, die dafür mit 25 € entlohnt wurden. Die
Stichprobe besteht aus 58% Ingenieursstudenten,
31% Psychologiestudenten und 11% Studierende
anderer Studiengänge. An der Untersuchung haben
37,8% Frauen teilgenommen.
4.2 Versuchsdesign und Durchführung
Unsere Untersuchung basiert auf einem 3x4 Versuchsplan. Die Variable Feedbackqualität hat drei
Abstufungen (F0, F1 und F2), die Variable Durchführungsphase vier (Phase 1 bis 4). Der Versuchsplan
ist in Tabelle 2 dargestellt. Die Versuchspersonen
durchlaufen in unserem Design jeweils 4 Phasen.
Jede Phase besteht aus von 30 simulierten Tagen.
Aufgabe ist es, für diese 4 x 30 Tage eine 3-Zimmer
Wohnung zu beheizen. Das Ziel ist dabei, die für
jeden Raum vorgegebene Temperatur mit möglichst
wenig Energie zu erreichen. Alle Personen bedienen
in der ersten Phase das System F0, in dem außer
dem Komfortlevel lediglich der Energieverbrauch
des zuletzt simulierten Tages rückgemeldet wird.
Diese Phase gilt als Baseline. Die nächsten zwei
Phasen sind für je 15 VP entweder System F0, System F1 oder System F2. Die vierte Phase ist für alle
Personen wieder gleich und besteht aus dem System F0.
Phase 1
Phase 2
Phase 3
Phase 4
Gruppe F0
F0
F0
F0
F0
Gruppe F1
F0
F1
F1
F0
Gruppe F2
F0
F2
F2
F0
Tabelle 2: 3 x 4 Versuchsdesign (Feedbackqualität x
Durchführungsphase)
Durch die Computersimulation erhalten wir für jede
Testperson und jeden simulierten Tag (also 4 x 30)
Ergebnisse über den erreichten Komfort in Prozent,
100
Abb. 5: Effizienz der Steuerungsleistung als Funktion
von Feedbackstufe und Bearbeitungsdauer.
Die Nachbefragung ergab interessante Einblicke in
das Nutzungsverhalten und Anregungen zur Verbesserung. Von allen Teilnehmern positiv bewertet wurde die Möglichkeit, die Heizung in einem Koordinatensystem durch Erzeugen von Heizblöcken einzustellen. Dies wurde als sehr anschaulich beschrieben. Entsprechend positiv fiel die Bewertung der
graphischen Rückmeldung über den Temperaturverlauf (siehe Abb. 2) aus. Sowohl die graphische wie
die tabellarische Rückmeldung über den prozentualen Grad der Komforterreichung wurde von allen
Teilnehmern als Informationsquelle genutzt. Auch
die Vorgehensweise ähnelte sich laut Interviewaussagen: war der erreichte Komfort auffällig gering,
schauten die Personen in den graphischen Darstellungen nach, wodurch das Ergebnis verursacht ist,
um Gegenmaßnahmen einzuleiten. Hierfür sahen
sich die Teilnehmer mit Feedbackqualität F1 und F2
den Tagesbericht an, während die Teilnehmer mit
Feedbackqualität F0 die graphische Darstellung des
Temperaturverlaufs des letzten Tages nutzten. Die
Rückmeldung über die verbrauchte Energie wurde
von den Versuchspersonen weniger stark berücksichtigt, was nach Aussagen einiger Personen daran
lag, dass kein Richtwert zur Bewertung der gebrauchten Energie zur Verfügung stand. Eine Rückmeldung von beispielsweise 394 verbrauchten Energieeinheiten gab keinen direkten Hinweis darauf,
Bedienerverhalten und Feedbackqualität bei der Steuerung einer computersimulierten Heizungsanlage
ob das als ein gutes oder schlechtes Ergebnis zu
interpretieren ist. Die entstandenen Kosten spielten
bei der Evaluation der eigenen Bedienerstrategie
eine sehr untergeordnete Rolle, da sie dem Energieverbrauch proportional entsprach. Das in der
Feeback-Qualitätsstufe F2 rückgemeldete Maß für
die Verschwendung wurde von allen Teilnehmern,
die dieses Maß abrufen konnten, genutzt und als
Informationsquelle sehr positiv bewertet. Einige
Teilnehmer gaben an, in der letzten Phase, in der
diese Information nicht mehr zur Verfügung stand,
sensibilisiert gewesen zu sein für dieses Maß und
mehr auf den Energieverbrauch geachtet zu haben.
Insgesamt zeigten sich die Testpersonen zufriedener
mit dem Feedbacksystem F2, dem System mit dem
höchsten Transparenzgrad. Es ergaben sich aus der
Nachbefragung wertvolle Hinweise zur Verbesserung der Bedieneroberfläche. Eine wichtige Anregung war, der Information zur Energieverschwendung den Grund für die Verschwendung hinzuzufügen. Als hilfreich wurde eine Anleitung für zukünftige
Sparmaßnahmen gesehen. Diese sollte möglichst
graphisch dargestellt werden. Weiterhin wurde eine
automatische Anpassung des Systems auf sich verändernde Außentemperaturen angeregt. Einige
Testpersonen wünschten sich insgesamt einen höheren Automatisierungsgrad des Systems. Kritisiert
wurde vielfach die Umständlichkeit mit verschiedenen Fenstern arbeiten zu müssen. Angeregt wurde
von diesen Personen, alle Funktionen und Rückmeldungen in einem Fenster zu integrieren. Vielfach
wurde ein Richtwert für den durchschnittlichen
Verbrauch gewünscht, der es dem Nutzer vereinfacht, die Verbrauchsangaben zu bewerten. In der
Weiterentwicklung könnte das bedeuten, den Energieverbrauch direkt zu bewerten.
6.
DISKUSSION
Methodisch beinhaltete die Untersuchung die Erhebung quantitativer Daten durch die rechnergestützte
Simulation und die Erhebung qualitativer Daten,
einerseits durch das Aufzeichnen eines Journals mit
dem alle Arbeitsschritte der Versuchspersonen
nachvollzogen werden können, andererseits durch
die Nachbefragung der Testpersonen. Diese Daten
ergeben ergänzend ein umfassendes Bild über die
Qualität der Benutzeroberfläche.
Qualitative Daten zur Bedienbarkeit gaben wichtige
Informationen zur Weiterentwicklung der Systemoberfläche. Die Erhebung von qualitativen Daten
bietet zusätzlich die Möglichkeit, zu prüfen, welcher
Transparenzgrad nötig und welche Feedbackinformationen relevant sind für die umweltgerechte Steuerung eines Heizungssystems.
Das Ziel der Untersuchung war es, Gestaltungsrichtlinien für Heizungssysteme abzuleiten. Einige Aspekte der Untersuchungsergebnisse können auf die
in der Regel eher kleinen Displays von Heizungsanlagen übertragen werden. Die Ergebnisse sind natürlich besonders relevant für die Gestaltung von PC
gestützten Steuerungssystemen von Heizungsanlagen. Durch die Untersuchung sollten Hinweise für
effektive Informationen und deren optimale Darstellung gewonnen werden.
Das Heizungssystem wurde von den meisten Testpersonen möglichst automatisiert gewünscht. Dem
Wunsch der Vollautomatisierung steht der Verlust
der Kontrolle über das System dann entgegen, wenn
es für den Nutzer nicht mehr Transparent ist. Hohe
Transparenz löste sowohl größere Zufriedenheit bei
den Testpersonen aus, als auch bessere Regulationsergebnisse aus. Heizungssysteme sollten also
1. einen hohen Automatisierungsgrad erreichen,
2. Systemfunktionen und Effektgrößen transparent
darstellen,
3. Kontrollmöglichkeiten bieten und
4. detaillierte Hinweise darüber geben, wie das
Heizverhalten optimiert werden kann.
Letztendlich würde eine Bewertung der aktuellen
Einstellungen des Systems dem Nutzer Anhaltspunkte für die Optimierung der Systemanwendung
geben.
Eine Weiterentwicklung des untersuchten Systems
mit besonderem Fokus auf die praktische Umsetzbarkeit der Gestaltungsrichtlinien ist notwendig und
wird folgen.
7.
REFERENCES
[1] Sauer J. und Rüttinger B., Nutzerorientierte
Gestaltung von Gebrauchsgütern. In B. Zimolong und U. Konradt (Hrsg.): Enzyklopädie der
Psychologie: Ingenieurpsychologie. Göttingen:
Hogrefe (2003). Zur Begutachtung eingereichtes
Manuskript.
[2] Kempton W., Two theories of home heat control.
Cognitive Science. 10, 75-90 (1986).
[3] Sauer J., Wastell D., Hockey G.R.J., Crawshaw
C.M. and Downing J.C., Designing micro-worlds
of transportation systems: the computer-aided
bridge operation task. Computers in Human Behaviour. 19 (2), 169-183 (2003).
[4] Wandmacher J., Software-Ergonomie. Berlin:
Walter de Gruyter & Co. (1993).
[5] Norman D., The Design Of Everyday Things.
Cambridge, MIT Press (1988).
101
Referenten
Claudia Schmeink studiert seit 1998 Diplom - Psychologie am Institut für Psychologie
der TU Darmstadt. Sie ist seit 1999 als wissenschaftliche Hilfskraft in der Arbeitsgruppe
für MCI bei Herrn Prof. J. Wandmacher tätig. Ihr Praktikum absolvierte sie in der Abteilung für Personalentwicklung der Commerzbank AG, Frankfurt. Sie leitet seit 2000 für
die innerbetriebliche Aus- und Weiterbildung der TU Darmstadt sowohl EDVSchulungen, als auch Seminare zum Thema „Argumentieren und Verhandeln“.
Die Untersuchung ist zentraler Bestandteil ihrer Diplomarbeit, welche betreut wird von
Dr. J. Sauer.
Dr. Jürgen Sauer arbeitet als Hochschulassistent in der Arbeitsgruppe Arbeits- und
Organisationspsychologie am Institut für Psychologie der TU Darmstadt. Zuvor war er
als wissenschaftlicher Mitarbeiter an den Universitäten Bochum und Hull (GB) tätig.
Seine Promotion schloss er im Jahre 1997 an der Universität Hull zum Thema „Human
skill maintenance in complex work environments“ ab. Er studierte Psychologie in Giessen und erhielt einen M.Sc. in „Occupational Psychology“ von der Universität Sheffield.
Seine Forschungsinteressen gelten der nutzerorientierten und umweltgerechten Gestaltung von Gebrauchsgütern und den Auswirkungen von Arbeit in komplexen hochautomatisierten Arbeitsumgebungen. In diesen Forschungsfeldern hat er zahlreiche Fachzeitschriftenartikel und Buchbeiträge veröffentlicht.
David Wastell gained his Ph.D. in Psychology from the University of Durham in 1978.
He then moved to the Applied Psychology Unit in Cambridge where he undertook a
major project involving the psychophysiological analysis of stress and technological
change in British Telecomm. In 1980, he moved to Manchester taking up a lectureship
in Medical Informatics. He was promoted to Senior Lecturer in Information Systems in
1990, and in July 2000 took up his present position as Professor of the Information
Society at the University of Salford. He is currently moving to the University of Manchester to take up a chair in the School of Computation.
102
OPTIMIERUNG DER REDAKTIONELLEN WORKFLOWS IN EINER
ONLINE-REDAKTION
Patrick Schumacher
Sapient Deutschland GmbH
Speditionsstrasse 5
40221, Düsseldorf
pschumacher@sapient.com
www.sapient.de
Boris Terwey
Kellerstrasse 27
81667, München
bterwey@sapient.com
www.sapient.de
ABSTRACT
Der vorliegende Artikel umfasst sowohl den Datenerhebungsprozess als auch die Entwicklung von
Designlösungen für ein Content-ManagementSystem in einer Online-Redaktion. Die Datenerhebung erfolgte v.a. unter Verwendung ethnografischer
Interviews. Basierend auf den gesammelten Daten
wurden dann in partizipativen Designsessions gemeinsam mit den Redakteuren optimierte Kooperationsmodelle und Eingabeformulare erarbeitet.
Keywords
Ethnografische Interviews, partizipatorisches Design,
Workflowoptimierung, essential Use Cases
1. EINLEITUNG
In einer großen deutschen Online-Nachrichtenredaktion produzieren bis zu 100 Redakteure parallel Inhalte unterschiedlichster Art für verschiedene,
gleichberechtigte Kanäle (Web, WAP, PDA und TV).
Ein Content Management System (CMS) stellt das
zentrale Arbeitswerkzeug dar, mit dessen Hilfe
sämtliche Inhalte erstellt, arrangiert und veröffentlicht werden. Allerdings erschwerten die gegebenen
Arbeitsabläufe und Eingabemasken eine effektive
und effiziente Erledigung der täglichen Aufgaben.
Neben der daraus resultierenden Unzufriedenheit
der Redakteure gab die Höhe der anfallenden Betriebs- und Supportkosten den Anlass für das hier
beschriebene Optimierungsprojekt.
Rainer Wessler
Speditionsstrasse 5
40221, Düsseldorf
rwessler@sapient.com
www.sapient.de
2. PROJEKTBESCHREIBUNG
Das Projekt wurde von Sapient’s Seite aus mit zwei
Beratern aus dem Bereich User Experience und
einem Projektmanager aufgesetzt. Von Kundenseite
bestand das Projektteam aus den beiden Auftraggebern wie auch aus einer Arbeitsgruppe von ca. 6
Redakteuren. Das Projekt wurde in zwei Phasen zu
je 3 Wochen abgewickelt.
3. PROJEKTZIELE
Um einen Erfolg des Projektes anhand messbarer
Kriterien überprüfbar zu machen, wurden in Einklang
mit Sapient’s Arbeitsansatz für die Verbesserung der
Gebrauchstauglichkeit [1] die folgenden messbaren
Geschäftsergebnisse (Measurable Business Results,
MBR’s) vereinbart [2]:
Optimierung der Effektivität:
•
Verringerung der Fehlerhäufigkeit
•
Optimierung der Erlernbarkeit
Optimierung der Effizienz:
•
Verringerung der „Time-to-Publish“
•
Verringerung der notwendigen Interaktionsschritte pro Aufgabe
•
Optimierung der Erlernbarkeit
Steigerung der Nutzerzufriedenheit:
•
Verringerung der Medienbrüche
•
Vermeidung von indirekten Interaktionsschritten
4. VORGEHEN
Stuttgart).
Proceedings of the
In einem ersten Workshop mit den Auftraggebern
wurde vom Projektteam das folgende Vorgehen
vereinbart:
4.1 Ethnografische Interviews
Da an der Veröffentlichung von einzelnen Inhalten
fast ausnahmslos mehrere Nutzergruppen beteiligt
sind, erschien es notwendig, neben den individuellen
Arbeitsabläufen auch die Kooperationsmodelle unter
den beteiligten Nutzern in dem gegebenen Nutzugskontext zu verstehen und zu beschreiben [3]. Eine
103
Schumacher, P., Terwey, B. & Wessler, R.
ethnografische Beobachtung der Arbeitsgruppen am
Arbeitsplatz wurde daher individuellen Labortests
vorgezogen. Es wurden 22 Interviews durchgeführt,
die sich aus den folgenden Komponenten zusammensetzten:
•
Einleitendes Interview, qualitative Erhebung von
Schwachstellen und Verbesserungsmöglichkeiten aus der Sicht des Redakteurs
•
Aufgabenbearbeitung durch den jeweils befragten Redakteur in der betrachteten Arbeitsgruppe,
teilnehmende Beobachtung und Hypothesenbildung durch den Interviewer.
•
Abschlussinterview, Validierung der durch den
Interviewer gesammelten Eindrücke und Hypothesen, Erfassung von Aufgabenfrequenz, Feldnutzungshäufigkeiten und Nutzercharakteristika
Die Ergebnisse der erhobenen Arbeitsabläufe wurden dann zur Beschreibung des Ist-Zustandes als
Use Cases dokumentiert:
Nutzerziel: Veröffentlichung eines PDA-Artikels
Vorbedingung: Web-Artikel ist bereits erstellt
Nutzerziel: Veröffentlichung eines PDA-Artikels
Vorbedingung: Web-Artikel ist bereits erstellt
notw. Vowissen: Kenntnis des Multichannelprozesses
Nachbedingung: Fehlerfreie Artikelseiten in Web & PDA
1)
Erzeugen eines verbundenen Artikels für den PDA-Kanal
2)
Anpassung von Text- und Bildinformation für die Gegebenheiten des Ausgabemediums PDA
Abbildung 2: Erstellung eines Plattformdokumentes
in der Notation als "essentieller Use Case" (Auszug)
4.4 Analyse der essentiellen Use Cases & Gestaltung von Steuerelementgruppen
Die zuvor beschriebenen „essentiellen Use Cases“
wurden im nächsten Schritt auf häufig wiederkehrende, generische Aktionen (Microtasks) untersucht.
Es wurde dann versucht, Steuerelementgruppen zu
gestalten, mit deren Hilfe diese generischen Aktionen auf der zukünftigen Bedienoberfläche abgebildet werden sollten. Die so entwickelten Steuerelementgruppen bildeten die Grundbausteine der überarbeiteten Bedienoberfläche.
notw. Vowissen: Kenntnis des Multichannelprozesses
Nachbedingung: Fehlerfreie Artikelseiten in Web & PDA
1)
Öffnen des Masterdokumentes
2)
Auswahl des Dokumenttyps, Klick auf ‚Generieren’
3)
Auswahl einer Plattform
4)
Auswahl der Option ‚Inhalte übernehmen’
5)
Anpassung der Textinformationen
6)
Öffnen des verbundenen Bild-Dokumentes
7)
Wiederholung der Schritte 1) – 5) f. d. Bild-Dokument
8)
Auswahl eines anderen Bildes
9)
Anpassung der beschreibenden Bildinformationen
Abbildung 1: „Erstellung eines Plattformdokumentes“- Liste der derzeit notwendigen Benutzeraktionen
zum Erreichen seines Aufgabenzieles als „aktueller
Use Case“ (Auszug)
4.2 Identifikation und Priorisierung von Usability-Problemen
Basierend auf den erhobenen Daten und unter Berücksichtigung des Nutzungskontextes wurde eine
erste Liste von Usabilty-Problemen erstellt und zusammen mit den dokumentierten Use Cases in einem Workshop mit Vertretern der befragten Redakteure validiert und priorisiert.
4.3 Erstellung von essentiellen Use Cases
Um bei der Modellierung optimierter Arbeitsabläufe
nicht zu sehr durch die aktuelle Implementierung
des CMS beeinflusst zu werden, wurden die „aktuellen Use Cases“ in einem nächsten Schritt in „essentielle Use Cases“ überführt [4]. Hierfür werden die im
Augenblick tatsächlich notwendigen Arbeitsschritte
auf eine häufig deutlich kürzere Sequenz von Nutzer-Unterzielen reduziert:
104
Abbildung 3: Steuerelementgruppe zum Erstellen von
Dokumentverweisen mit "Zuletzt Verwendet"Funktion
4.5 Initiales Formulardesign
Mit Hilfe der zuvor entwickelten Steuerelementgruppen und unter Berücksichtigung der Variablen des
Nutzungskontextes wurde für die wichtigsten Arbeitsabläufe eine erste Version von Eingabenmasken erarbeitet.
4.6 Anschließende Optimierung der Formularentwürfe mit den Redakteuren
Die Formularentwürfe wurden schließlich in zwei
partizipativen Designsessions mit den Redakteuren
optimiert. Hierfür wurden die Formularentwürfe auf
Poster gedruckt und unter Verwendung von Stiften
und „Sticky Notes“ modifiziert.
5. DISKUSSION
Mit Hilfe des oben beschriebenen Vorgehens war es
uns gelungen, mit vergleichsweise geringem personellen und zeitlichen Aufwand ein komplexes System neu zu gestalten. So konnten vor allem durch
die Verwendung ethnografischer Interviews tiefe
Einblicke gewonnen werden.
Es viel einmal mehr auf, dass durch die Beobachtung im tatsächlichen Arbeitsumfeld Optimierungsmöglichkeiten entdeckt wurden, die durch eine bloße
Befragung oder einen Labortest nicht identifiziert
Optimierung der redaktionellen Workflows in einer Online-Redaktion
worden wären, weil die Redakteure nach der mehrjährigen Arbeit mit dem System den Blick für einige
Nutzungsprobleme bereits verloren hatten, und diese folglich auch nicht hätten berichten können. So
profitierte die Lösung von der Tatsache, dass die
Beobachter mit einem unvoreingenommenen Blick
im tatsächlichen Nutzungskontext arbeiten konnten
[5].
Für die partizipatorischen Designsessions bestätigte
sich einmal mehr eine bereits häufig von uns gemachte Beobachtung: Um einen offenen Dialog zu
gewährleisten und um ein möglichst ungehemmtes
In-Frage-Stellen der gegenwärtigen Designlösung zu
motivieren, sollten die Artefakte ein möglichst geringes technisches Niveau aufweisen. So erscheinen
befragte Nutzer eher bereit, radikale Änderungen
am Design zu fordern, wenn sie lediglich mit einer
detaillierten Handskizze umgehen, als wenn sie
bereits vollends gestaltete Screens oder gar klickbaren Prototypen vor sich haben.
Zuruf“ innerhalb weniger Tage parallel zum laufenden Designprozess zu planen, durchzuführen und zu
analysieren. Jedoch gilt bei diesen „weichen“ Methoden mehr denn je, dass die für qualitative Methoden empfohlenen Gütekriterien eingehalten werden dass also Vorgehensweise und erhobene Daten
gewissenhaft dokumentiert, offengelegt und Rückschlüsse für alle (insbesondere den Kunden) nachvollziehbar gemacht werden.
7. REFERENCES
[1] International Organization for Standardization:
ISO 9241-10: Grundsätze der Dialoggestaltung
(1998)
ISO 9241-11: Anforderungen an die Gebrauchstauglichkeit - Leitsätze (1998)
ISO 13407: Benutzer-orientierte Gestaltung interaktiver Systeme (2000)
6. ZUR PRAXISTAUGLICHKEIT
SOFTWARE-ERGONOMISCHER
METHODEN
[4] Constantine L., Lockwood L., Software for Use:
A practical guide to the methods of usagecentered design, Addison Wesley Professional
(1999)
Das beschriebene Projekt ist ein Beispiel für die
erfolgreiche Anwendung qualitativer softwareergonomischer Methoden in der Praxis. Aufgrund
der kurzen Projektlaufzeit schien es angemessen,
statt quantitativer Methoden wie z.B. summativen
Usability-Tests eher auf Methoden zu setzen, die ein
detailliertes Verständnis der Nutzungsprobleme und
die Einbeziehung des gesamten Nutzungskontextes
garantieren (Ethnografische Interviews). Sobald das
System implementiert und eingeführt ist, sind summative Tests bzw. Fragebogenstudien zur Dokumentation des Projekterfolgs geplant.
[5] Mayhew D: The Usability Engineering Lifecycle:
A practitioner’s handbook for User Interface Design, Morgan Kaufmann Publishers (1999)
Für unser Tagesgeschäft zeichnet sich ab, dass
qualitative pragmatische Methoden die größere Zukunft haben. Umfassendere Untersuchungen mit
mehr als 20 Teilnehmern und geschichteten Stichproben sind eher die Ausnahme.
Sapient ist eine führende Management- und Technologie-Beratung, die ihre Kunden bei Entwicklung
und Support fortschrittlicher Technologien zur Erreichung messbarer Geschäftsergebnisse unterstützt.
Hierzu verknüpft Sapient ein umfassendes Leistungsangebot mit einem integrierten Projektmanagement zu Projekten auf Festpreis- und Festlaufzeitbasis. Die ca. 1.500 Mitarbeiter arbeiten weltweit
in 13 Büros in Nord-Amerika, Europa und Asien. In
Deutschland unterhält Sapient Niederlassungen in
Düsseldorf und München.
So liegt denn auch eine besondere Herausforderung
darin, entsprechende Studien gewissermaßen „auf
105
Schumacher, P., Terwey, B. & Wessler, R.
Referenten
Patrick Schumacher arbeitet als Associate User Experience bei der Management- und
Strategieberatung Sapient. Zuvor war er zwei Jahre als Usability-Spezialist in der Designagentur frogdesign tätig und leitete die dortige Usability-Gruppe sowie das UsabilityLabor. Er studierte Informatik an den Universitäten Bonn und Warwick (England).
Sein Hauptinteresse gilt der erfolgreichen Projektarbeit im Spannungsfeld zwischen
Auftraggebern, Entwicklern und Designern. Weitere Interessengebiete umfassen Visualisierungstechniken, Mobile Devices sowie Agenten.
Boris Terwey arbeitet als Manager Program Management bei der Management- und
Strategieberatung Sapient. Zuvor war er beim Kundebindungssystem Webmiles und der
Multimediaagentur Medialab als Projektmanager tätig. Boris Terwey studierte DiplomMedienberatung und Kunstgeschichte an der Technischen Universität in Berlin.
Sein Hauptinteresse gilt der Planung, Steuerung und Koordinierung von multidisziplinären Projekten. Besonders wichtig ist Boris Terwey dabei die Sicherstellung eines
„One-Team-Approach“ bei Projekten mit Vertretern aus Strategie, User Experience und
Technik.
Rainer Wessler arbeitet als Manager User Experience bei der Management- und Strategieberatung Sapient. Zuvor arbeitete er als Usability Engineer bei der User Interface
Design GmbH in München. Rainer Wessler studierte Psychologie mit einem Schwerpunkt auf „Mensch-Maschine-Interaktion“ an der Universität Osnabrück.
Sein Hauptinteresse gilt dem Transformationsprozess, in dem das gesammelte Wissen
um den Nutzungskontext eines Systems in eine Designlösung überführt wird.
106
PROJEKT HILWA BENUTZERORIENTIERTE GESTALTUNG EINES
LERNCONTENTMANAGEMENTSYSTEMS FÜR DIE BERUFLICHE
AUS- UND WEITERBILDUNG
Stephan Raimer
Learnability – E-Learning & Usability
Mangoldtstraße 8
24106 Kiel
raimer@learnability.de
http://www.learnability.de
ABSTRACT
Im Rahmen des Projektes HILWA (Hypermediales
Informationsund
Lernsystem
webbasierter
Automatisierungslandschaften) wurde in einem
benutzerorientierten
Entwicklungsverfahren
ein
Prototyp eines Lernsystems entwickelt.
Obschon ein sehr spezieller Inhaltsbereich für das
Lernsystem gewählt wurde, kann die gewählte
Vorgehensweise sowie das erstellte Framework als
exemplarisch für andere Lernprojekte angenommen
werden.
der Leitidee Handlungskompetenz subsumieren sich
unterschiedliche Absichten und Qualifikationen.
Während etwa Schüler an allgemeinbildenden
Schulen ein grundlegendes Verständnis typisch
technischer Denk- und Handlungsmuster erwerben
und an exemplarischen Beispielen erproben sollen,
geht es in der gewerblich-technischen Aus- und
Weiterbitdung darum, berufsspezifische Denk- und
Handlungsmuster kennen zu lernen, bis zur Routine
zu automatisieren und als transferierbare Muster für
unbekannte berufliche Situationen, vor allem
problembehaftete, bereitzuhalten.
Keywords
Benutzerorientierte Gestaltung, berufliche Aus- und
Weiterbildung,
Problemlösen,
Lern-ContentManagement-System (LCMS), HILS Framework,
Web-Schnittstellen.
1. EINLEITUNG
Technische Bildung als Teil einer Allgemeinbildung
kann in der heutigen, von Technik und Wissenschaft
in hohem Maße geprägten sowie abhängigen
Gesellschaft als grundlegend betrachtet werden.
Leitidee und Ziel von Vermittlungsprozessen im
Rahmen technischer Bildung ist dabei auf allen
Niveaustufen (von allgemeinbildender Schule bis zu
beruflicher oder universitärer Bildung) technische
Handlungskompetenz,
verstanden
als
disziplintypisches Denken und Handeln. Technische
Bildung ist ein Persönlichkeitsmerkmal und
charakterisiert sich als Prozess und Ergebnis, unter
Stuttgart).
Proceedings of the
Abbildung 1: Auszubildende im Projekt HILWA
Auch wenn sich die Absichten, Anforderungen und
Randbedingungen
im
Rahmen
solcher
Vermittlungsprozesse unterscheiden, eins ist allen
gemein: Immer muss der Lerner technische
Informationsträger und Beschreibungsformen, z. B.
Texte, technische Zeichnungen, Simulationen.
Modelle, Realobjekte, im Rahmen seiner psychophysiologischen Grenzbedingungen wahrnehmen,
decodieren und - je nach Zielsetzung - zu kognitiven
oder
psychomotorischen
Netzoder
Handlungsmustern generieren.
Daher haben Medien, verstanden als Reizkonfigurationen
von
Informationsträgem
und
107
Raimer, S.
Beschreibungsformen, gerade in Vermittlungsprozessen im Rahmen technischer Bildung einen
großen Einfluss auf den Lernerfolg, weil einerseits
die umfassende Normung vor allem grafischer
Beschreibungsformen für technische Systeme,
andererseits
die
psycho-physiologischen
Grenzbedingungen und medialen Vorerfahrungen
des Lerners, aber auch Effizienzkriterien des
Lernprozesses zu beachten sind.
Analoges gilt, wenn Lehrfunktionen ganz oder in
Teilen auf computergestützte Medien übertragen
werden. Zeitgemäße Lernangebote – auch wenn sie
durch computergestützte Lehrformen realisiert
werden - sollten nicht mehr nur auf die alleinige
Vermittlung von Wissen setzen, wie es nicht erst
zuletzt durch Ergebnisse im Rahmen von PISA oder
etwa der BCG Studie [1] gefordert wurde, sondern
Handlungskompetenz (s.o.) zum Ziel haben.
Im Rahmen beruflicher Aus- und Weiterbildung
treten nun auch Lernsituationen auf, in denen der
direkte Zugriff auf die betriebliche Realität – etwa
auf wie auch immer geartete komplexe technische
Systeme – nicht möglich ist. Somit werden
Mediensysteme notwendig, die die Komplexität der
Realität
in
skalierbarer
Reduktion
des
Gültigkeitsumfanges abbilden.
2. ANFORDERUNGEN AN HILWA
Bedingt durch die dargestellte Konstellation wurden
Anforderungen, welche aus den verschiedenen
Bereichen resultieren, formuliert; diese sollen im
Folgenden in allgemeiner Form erläutert werden.
Den größeren Rahmen bilden dabei die didaktischen
Anforderungen durch die geplante Lernsituation.
Softwaretechnische
Anforderungen
an
die
Gestaltung des HILWA Prototypen werden
anschließend genannt.
2.1 Didaktische Anforderungen
Konstruktionsmethodisches Denken und Handeln
kann als Spezialfall menschlichen Problemlösens
eingeordnet
werden.
Lernprozesse
welche
Problemlösemethoden anbahnen und optimieren
sollen, müssen also derart gestaltet werden, dass sie
Erkenntnisse
der
Denkund
Problemlösepsychologie integrieren und anwenden.
Dazu gehören die Begünstigung von Lern- und
Wissenstransfer, wie auch die „Einsichtgewinnung in
relativ einfach strukturierte Probleme, strategisches
Denken, kreative Einfälle und Systemdenken“, die in
spezifischer Weise geübt werden sollten (vgl. [3], S.
227).
Das Projekt HILWA sollte einen Beitrag zur
Optimierung
von
konstruktionsmethodischen
Lernmustern im
Rahmen von technischen
Vermittlungsprozessen
leisten;
methodisches
Vorgehen im Sinne von aktivem Umsetzen
spezifischer Handlungs- und Denkmuster (vgl. etwa
VDI 2221) im Lernprozess war somit erklärtes Ziel.
Das Projekt HILWA wurde als Akzeptanz- und
Optimierungsstudie angelegt und im Rahmen einer
Dissertation [2] in Zusammenarbeit mit der Firma
Festo Didactic (Denkendorf) realisiert.
Exemplarischer Inhaltsbereich des Projektes HILWA
war die industrielle IT, hier hat in den letzten Jahren
verstärkt das Ethernet an Bedeutung gewonnen
(Schlagworte sind hier etwa „Factory Automation“,
„Industrial Ethernet“ etc.). Auf Basis von Web- und
Internettechnologien wurden Durchgängigkeit und
Standardisierung auf allen Ebenen der Fertigung –
von der Feldebene bis zum ERP-System –
eingeführt, eine Kompatibilität zwischen Office- und
der industriellen Vernetzung hergestellt.
Diese Veränderungen in der Produktionstechnik
bringen auch neue Anforderungen an die berufliche
Aus- und Weiterbildung in betroffenen Berufsbildern
mit
sich.
Der
Bereich
webbasierte
Automatisierungstechnik
stellt
hier
einen
Schnittpunkt betrieblicher Realität für Berufsgruppen
wie Mechatroniker, IT-Systemelektroniker oder
Fachinformatiker dar; je nach Sichtweise und
Akzentuierung gilt es Web- und Internettechnologien
in den Berufsbildern unterschiedlich zu verankern.
108
Abbildung 2: Verknüpfung Lernsystem - MPS Station
Für das Lernprojekt HILWA sollte eine Konfiguration
aus computergestütztem Lernangebot und einem
MPS Versuchsstand („Modulares Produktionssystem“ der Firma Festo Didactic) erstellt werden,
um industrielle Realität (dezentrales Bedienen und
Beobachten, Fernwartung und –diagnose etc.)
praxisgerecht abbilden zu können. Die Verknüpfung
von Lerngegenstand und Versuchsstand sollte durch
Web-Schnittstellen realisiert werden; zusätzlich
wurde für die Beobachtung eine leistungsfähige
steuerbare Web-Cam über dem Versuchsstand
montiert (s. Abb. 2).
Unter Nutzung dieser Gesamtkonfiguration von
Lernwerkzeugen
sollten
dann
von
berufsgruppenübergreifenden
Teams
von
Auszubildenden der genannten Berufsgruppen
praxisnahe Problemstellungen bearbeitet werden.
Projekt HILWA
2.2 Softwaretechnische Anforderungen
Für das hypermediale Informations- und Lernsystem
wurde schon sehr früh im Projektverlauf eine
Neuentwicklung
geplant,
hierbei
sollte
ein
Entwicklungsverfahren in Anlehnung an DIN EN ISO
13407 (Benutzerorientierte Gestaltung interaktiver
Systeme) realisiert werden.
Schwerpunkte bezogen auf die Berufsgruppen
geben sowie Einstellungen und Kompetenzen der
Durch Nutzung von Content Management Techniken
sollte HILWA eine weitestgehende Entkopplung der
Lerninhalte von ihrer grafischen Repräsentation
erlauben und dazu die Möglichkeit bieten,
Prototypen sehr einfach zu modifizieren. Als Basis
sollte die für Open-Source-Projekte (s. etwa
www.campussource.de für den Hochschulbereich)
weit verbreitete LAMP-Architektur (Linux, Apache,
PHP und MySQL) genutzt werden. Zusätzlich sollte
für die Realisierung interaktiver Funktionalitäten der
Benutzungsschnittelle Java-Script genutzt werden.
Basisfunktionalitäten
sind
stichpunktartig aufgeführt:
im
folgenden
•
Strukturierte Präsentation von (multimedialen)
Lerninhalte
•
Dokumentation
ergebnissen
•
Einbeziehung und Anwendung von Vorwissen
•
Erstellen von Lesezeichen und Textmarkern
•
Suchfunktionen
•
Hilfefunktionen zur Bedienung
von
Lernwegen
und
–
3. REALISIERUNG DES HILWA
PROTOTYPEN
Nutzungskontext (die Anforderungen an das
Lernsystem durch dessen definierte Funktionen) und
Benutzeranforderungen wurden zunächst in internen
Diskussionen am Institut für Technik und ihre
Didaktik (CAU Kiel) erörtert. Diese führten zur
Erstellung von grafischen Templates (Photoshop
Entwürfe), um Anordnung der GUI Elemente und
Bedienkonzept zu illustrieren (s. Abb. 3). Auch
mögliche Dialogabfolgen wurden zunächst mit
statischen HTML-Templates intern erprobt und
diskutiert.
Kennzeichnend für diese ersten Gestaltungslösungen war eine „gleichberechtigte“, zweifache
Navigationsfunktionalität an der linken bzw. rechten
Seite (Einmal als „Content Naviagtion“ zur
Abbildung der Sachstruktur des Lerngegenstandes
sowie eine als „User Topics“ bezeichnete
Lesezeichen-Navigation).
Im
nächsten Schritt wurden Berufsschulen
kontaktiert und Auszubildende der genannten
Berufsgruppen gebeten, einen informellen (nicht
standardisierten) Vorfragebogen zu beantworten.
Dieser sollte Aufschluss über den spezifischen
Kenntnisstand
bezüglich
der
thematischen
Abbildung 3: HILWA GUI Template
allgemeinen Computernutzung ermitteln (vgl. [2]
110f).
Für die Realisierung von HILWA wurde sodann ein
Framework für hypermediale Informations- und
Lernmanagementsysteme
(HILS
Framework)
entwickelt, welches eine klare Gliederung in
Funktionsmodule aufweist. Die Funktionsmodule
können als Bausteine für die Realisierung von
konkreten Lernsystemen herangezogen werden,
eine Übersicht gibt Tabelle 1.
Die Funktionsmodule des Frameworks können als
so genannte eingebettete Frames (iframes) in eine
Benutzungsschnittstelle integriert werden. Abbildung
4 zeigt die schließlich realisierte Gestaltungslösung
des HILWA Prototypen mit einer exemplarischen
Inhaltsseite.
Für die Evaluierung dieses Prototypen wurden zwei
Teams von jeweils vier Auszubildenden mit
Problemstellungen konfrontiert, die in eine
praxisnahe Rahmenhandlung eingebettet war. Unter
Nutzung
des
Lernsystems
sollten
diese
Problemstellungen gemeinsam gelöst werden,
zeitlicher Umfang waren vier Termine von jeweils
mindestens drei Stunden Dauer.
Abschließend wurde von den Auszubildenden der
standardisierte Benutzerbefragebogen ISONORM
9241/10 [4] sowie ein weiterer informeller (nicht
standardisierter) Abschluss-Fragebogen beantwortet,
außerdem wurden durch Diskussionsrunden mit den
Auszubildenden
weitere
Rückmeldungen
gesammelt.
In den Diskussionen wurden die Auszubildenden
gebeten zum einen ihr Vorgehen und ihre Lösungen
bezogen auf die Problemstellungen darzustellen.
109
Raimer, S.
Außerdem sollten Sie ihre Erfahrungen und
gegebenenfalls Benutzungsprobleme mit dem
HILWA Prototypen darstellen. Auch die Ergebnisse
des ISONORM 9241/10 und des AbschlussFragebogens wurden den Teilnehmern vorgestellt
und mit ihnen diskutiert.
Tabelle 1: Funktionsmodule des HILS-Framework
Funktionsmodul
Navigation
Topic
Bookmark
Memo
Session
Search
Textmarker
Lernweg
Lernscript
Hilfe
Datenbank
Reporting
110
Merkmale und Aufgaben
• Anzeige einer baumartigen
Navigations-Strukur auf Basis der in
einer Datenbank enthaltenen
Sachstruktur der Inhalte
• Anzeige von Links mit
Aufrufparametern für das TopicModul
• Dynamische Generierung einer
gewählten Informationsseite aus den
Inhalten der Datenbank (ggf. unter
Einbettung von Medienobjekten)
• Anzeige des Inhalts einer gewählten
Informationsseite
• Verwaltung von Nutzer-Lesezeichen
• Anzeige der Nutzer-Lesezeichen als
Links mit Aufrufparametern für das
Topic-Modul
• Verwaltung von Nutzer-Kommentaren
und Ergänzungen, die einzelnen
Informationsseiten zugeordnet
werden
• Sessionverwaltung der Nutzerdaten
• Speicherung von Lern- und
Informationswegen in die Datenbank
(Clickstreams)
• Volltextsuchfunktion durch alle
Informationsseiten, Lesezeichen und
Nutzer-Kommentare / Ergänzungen
• Dynamische Erzeugung von
Textmarkern (als farbige Hinterlegung
des Textes in Form einer Grafikdatei)
• Übersicht der aufgerufenen Seiten,
erstellten Textmarker,
Nutzer-Kommentare / Ergänzungen
sowie Lesezeichen.
• Erzeugung einer PDF-Datei zum
Drucken und / oder Speichern
(unter Einbeziehung von NutzerKommentaren und Lesezeichen)
• Anzeige von Hinweisen und
Hilfestellungen zur Bedienung
• Abstraktionsschicht für den
Datenbankzugriff für alle Module
• Bereitstellung von abstrahierten
Datenbankfunktionen (diese werden
nur hier in konkrete PHP-Funktionen
für eine bestimmte Datenbank
umgesetzt)
• Analysemodul für die Auswertung der
Benutzer-Protokolldaten
(z.B. grafische Click-Streamanalyse)
Abbildung 4: GUI des HILWA-Prototypen
4. ERGEBNISSE UND AUSBLICK
Die Akzeptanz- und Optimierungsstudie hatte eine
positive Beurteilung des HILWA - Prototypen zum
Ergebnis, dies wurde durch Ergebnisse im
ISONORM 9241/10 Fragebogen wie auch durch
Rückmeldungen
der
Benutzer
in
den
Diskussionsrunden klar belegt (vgl. Abb. 5 und [2],
121f). Gleichzeitig muss dieses Ergebnis bedingt
durch die kleine Stichprobe klar relativiert werden.
Abbildung 5: Ergebnisse des ISONORM 9241/10
Es konnten relevante Optimierungsansätze für die
Weiterentwicklung des HILS - Framework gewonnen
werden, diese bezogen sich zum einen auf eine
Erweiterung der Suchfunktion sowie auf eine
fehlende „Undo“-Funktion beim Löschen von
Textmarkern, Notizen oder Lesezeichen.
4.1 Exemplarität der gewählten Vorgehensweise
Die Benutzerorientierte Gestaltung des Lernsystems
konkretisierte sich in den folgenden Schritten:
•
Ermittlung der (medialen
Vorerfahrung der Lerner
•
Anwendung von Gestaltungsnormen für die
Entwicklung eines Prototypen
•
Nutzung von voneinander unabhängigen
GUI - Einzelelementen (s. Funktionsmodule)
und
inhaltlichen)
Projekt HILWA
•
Evaluierung des Prototypen durch informelle
Fragebögen sowie den ISONORM 9241/10
•
Unterstützung
der
Diskussionsrunden
•
Gestaltungsoptimierungen
Fragebögen
durch
Die Relation von Aufwand und Nützlichkeit, z.B.
bezogen auf den Umfang der ermittelten
Erkenntnisse beim gewählten Vorgehen kann als
klar positiv eingeschätzt werden. Als effizient hat
sich die Verwendung von informellen und
standardisierten Fragebögen erwiesen (besonders
bei automatisierbarer Auswertung - s. online Version
des ISONORM 9241/10 [5]).
Auch die Nutzung einer vergleichsweise kleinen
Stichprobe von Auszubildende, die in einem realen
Anwendungskontext über einen umfangreichen
Zeitraum (>12 Stunden, bedingt durch die
Problemstellungen) mit dem Lernsystem konfrontiert
waren, hat sich bewährt.
4.2 Ausblick
Resultierend aus dem Projekt HILWA wurde die
Übertragung
auf
andere
Zielgruppen
und
Inhaltsbereiche
beschlossen,
um
weitere
Evaluierungsdaten (auch in größerer Quantität) zu
ermitteln. Ein Lernmodul im Bereich Physik
(Zielgruppe Gymnasialschüler) wurde bereits
abgeschlossen, weitere sind in Vorbereitung (z.B. im
dem Bereich moderner Kfz-Technik).
außerdem befindet sich eine Umsetzung der
graphischen Benutzungsschnittstelle in Macromedia
Flash in der Entwicklung.
5. REFERENCES
[1] Studie der Boston Consulting Group: Die
Zukunft bilden – Eine gemeinsame Aufgabe für
die Schule und Wirtschaft, 02/2002.
http://www.netzworkshop.de/dyn/bin/2142-25151-bcg-studie.pdf
[2] Raimer, S., Anbahnung und Optimierung
konstruktionsmethodischer Lernmuster mit
hypermedialen Lernsystemen in der technischen
Bildung, Elektronische Dissertation (2002)
http://e-diss.uni-kiel.de/diss_631/
[3] Edelmann, W., Lernpsychologie, PVU,
Weinheim, 6.Auflage (2002)
[4] Prümper, J., Der Benutzerbefragebogen
ISONORM 9241/10: Ergebnisse zu Reliabilität
und Validität In: Liskowsky, R. / Velichkovsky,
B.M. / Wünschmann, W. (HRSG.) SoftwareErgonomie ´97: Usability Engineering:
Integration von Mensch-Computer-Interaktion
und Software-Entwicklung Teubner, Stuttgart,
55-69 (1997)
[5] Der Fragebogen ISONORM 9241/10 zur
Beurteilung der Software-Ergonomie
www.sozialnetz.de/awca/pq.asp?id=jsi
Für das HILS – Framework ist die Entwicklung
weiterer Funktionsmodule (z.B. Glossar) geplant,
111
Raimer, S.
Referent
Stephan Raimer ist Gründer der Firma learnability (Kiel), Anbieter von
Dienstleistungen rund um E-learning & Usability.
Nach dem Lehramtsstudium der Fächer Mathematik und Technik promovierte er
2002 an der Christian-Albrechts-Universität zu Kiel über Hypermediale
Lernsysteme zum Doktor der Erziehungswissenschaften. Parallel zum Studium
arbeitete er am Institut für Technik und ihre Didaktik in verschiedenen
Einzelprojekten sowie für über zwei Jahre in Teilzeit als Softwareentwickler
(ISION Internet AG, Ohltec AG) mit den Aufgabenbereichen Webentwicklung bzw.
Softwareergonomie.
Seit 2001 führt er Lehraufträge an der Christian-Albrechts-Universität zu Kiel aus.
112
PHASZINATION ERGONOMIE: VON DER
ENTLASTUNG AM FLIESSBAND ZUR
INSPIRATION IM DESIGN
PHASZINATION ERGONOMIE
VON DER ENTLASTUNG AM FLIESSBAND ZUR INSPIRATION IM
DESIGN
Claudius Lazzeroni, Thomas Hofmann, Petra Gersch, Christian Noss
Institut für Ergonomie und Designforschung
Universitätsstraße
45117 Essen
{c.lazzeroni, thomas.hofmann , petra.gersch, christian.noss}@uni-essen.de
www.uni-essen.de/ied
ABSTRACT
Der vorliegende Beitrag schafft die Basis für eine
grundlegende
Erweiterung
des
Ergonomieverständnisses. Durch die institutionelle
Verknüpfung von Kommunikationsdesign und
Industrialdesign bereiten wir uns auf die
Verschmelzung der Disziplinen in zukünftigen
Anwendungen vor.
Die Auseinandersetzung mit dem Leibraum, als
komplexes Gefüge und dem Zeitraum, als
gesellschaftlicher Kontext, zollt dabei dem Mensch
zentriertem Design den nötigen Respekt.
Somit verstehen wir Ergonomie als Bestandteil einer
Grammatik der Fantasie.
Keywords
Design, Ergonomie, Produktentwicklung
1. EINLEITUNG
„Das Wesen, dem Wesentliches mangelt, ist auf
Technik angewiesen, und da liegt es nahe, von
Tools, extensions of man und Armaturen der Sinne
zu sprechen.“ (Bolz, 2002) Von diesen Tools ist der
Computer zwar nur eines, jedoch ein enorm
populäres, dessen Leistungsfähigkeit immer noch
extrem
zunimmt. Gordon E. Moore, der
Mitbegründer der Intel Corporation, stellte bereits
1965 die Prognose auf, dass die Zahl der
Transistoren, die sich auf einem Chip integrieren
lassen, jedes Jahr verdoppeln werden. Jetzt
schreiben wir das Jahr 2003. Um auch nächstes
Jahr wieder Argumente zu haben einen neuen,
Stuttgart).
Proceedings of the
doppelt so schnellen Rechner verkaufen zu können,
steht die Computerindustrie vor dem Problem,
dieses enorme Leistungspotential auch nutzbar zu
machen. Gelingt das nicht, wird die Maschine
unterfordert.
Auf der anderen Seite steht das Wesen, dem
Wesentliches mangelt, der Mensch. Auch ihm
attestieren Gehirnforscher seit geraumer Zeit
Unterforderung, schließlich nutzt er nur einen Teil
der Hirnkapazität. Somit steht ein unterforderter
Mensch vor einer unterforderten Maschine,
verbunden durch eine Tastatur, eine grafische
Benutzeroberläche und eine Maus. Diese ist eine
Interface-Errungenschaft von Douglas Engelbart aus
dem
Jahre 1964.
Populär
wurde dieses
Interfacekonzept,
bestehend
aus
grafischer
Benutzeroberfläche und Maus, jedoch erst durch
Apple Anfang der 80er Jahre. Apples Lisa hatte
einen mit 5 MHz getakteten Prozessor und 1 MB
Arbeitsspeicher, also etwa 0.2% der Leistung
heutiger Rechner. Es scheint offensichtlich, dass
dieses 20 Jahre alte Interfacekonzept der geeignete
Ansatzpunkt für Innovationen ist. Aber wie könnten
diese Aussehen?
2. INTERFACE MIT HAND UND FUß
Die Diplomarbeit „Fisch kann man auch mit zwei
Gabeln essen“ von Heidrun von Irmer ersetzt
Tastatur und Maus durch ein multimotorisches
Interface. Hier sind bei der Steuerung des
Computers Hände und Füße im Einsatz. Jedoch
geht es in der Arbeit nicht um die Entwicklung einer
Bedienschnittstelle, die es dem Benutzer im Sinne
der EN ISO 9241 erleichtert seine Ziele in einem
bestimmten Nutzungskontext effektiv, effizient und
zufrieden stellend zu erreichen. Vielmehr geht es
darum, die Bedienung des Rechners zu einer völlig
anderen Erfahrung zu machen. Dabei sind die
Emotionen des Benutzers wichtig. Bei dieser Arbeit
steht das prototypische Interface für mehr als nur die
Bedienung einer Maschine, denn es löst beim
Benutzer sinnliche Erfahrungen aus.
115
Lazzeroni, C., Hofmann, T., Gersch, P. & Noss, C.
3. INTUITIVE BEDIENKONZEPTE
Ergonomische Untersuchungen im Design haben
zum Ziel, Produkteigenschaften bezüglich ihrer
Ausrichtung auf den Menschen zu optimieren. Je
einfacher ein Produkt zu bedienen ist, desto besser.
Einfacher bedeutet vielfach, in seiner Funktionalität
selbst erklärend. Bei der Betrachtung eines
Funktionselements soll dem Benutzer deutlich
gemacht werden, welche Aufgabe das Element hat
und wie es bedient wird. Im Bereich der
Produktentwicklung wird eine intuitive Bedienbarkeit
gefordert und als das Ziel einer benutzergerechten
Gestaltung angesehen.
Abbildung 1: Aufbau der Diplomarbeit „Fisch kann
man auch mit zwei Gabeln essen“
Ein solches Mensch-Maschine Interfacekonzept ist
nicht zwangsläufig den Bereichen Spiel oder Kunst
zuzuordnen. Schließlich wird eine andere beliebte
„extension of man“ auf ähnliche Art bedient: das
Automobil. Aber auch zur Steuerung von
Computerspielen werden neben dem Joystick auch
wesentlich komplexere Bedienteile angeboten, die
zwar einen hohen Lernaufwand haben, dafür aber
sehr unterhaltsame, sinnfällige und effiziente
Steuerungen ermöglichen.
Aber ab welchem Punkt kann man von einem
intuitiv bedienbaren Produkt sprechen? Sobald es
an einem Gerät ein Bedienelement gibt, welches in
seiner Bedienungsweise bekannt ist, wenn nach
einem Erlernprozess die Funktionsweise schlüssig
erscheint und immer wieder erinnert wird? Ist ein
Produkt intuitiv, wenn die grafische Gestaltung
Iconifizierung aus bekannten Metaphern benutzt
oder ist es dann intuitiv bedienbar, wenn es als
Gesamtprodukt
ohne
Einschränkungen
vom
Menschen bedient werden kann? Aber wie kann
dieser Zustand definiert werden?
Produktentwicklungen werden von unterschiedlichen
Seiten beeinflusst. Oft sind es Vorgaben von
"Maßzahlen" räumliche Abmessungen, Größe und
Anordnung von Bedienelementen,die dem Gestalter
einen Rahmen vorgeben. Sie basieren auf
Untersuchungen, welche sich nah am Status Quo
orientieren. Die Ergebnisse liefern Entsprechendes.
Sie verändern das Bestehende nur in Nuancen zu
Gunsten des Benutzers.
Die Aufgabe des Designs ist jedoch vielfach eine
andere. Hier steht nicht unbedingt die Annäherung
des Bestehenden an eine optimale Form, sondern
das Hinterfragen eines bestehenden Konzeptes auf
seine Sinnfälligkeit und Angemessenheit.
Kann man bei einem Softwarebetriebssystem von
intuitiver Bedienung sprechen, wenn die Icons eine
dreidimensionale Anmutung haben oder bei einem
Infotainment Modul im PKW Bereich, wenn es mit
einem multifunktionalen Bedienknopf auskommt?
Spricht man von einer signifikanten Verbesserung
der Usability, sollte man sich neuen Konzepten
zuwenden und sich lösen von bekannten und
suboptimalen Konzepten.
Beispiele für eine Annäherung an menschoptimierte
Lösungen werden häufig nur in Form von Science
Fiction Thematiken bekannt.
Abbildung 2: Steuergeräte für Computerspiele
116
Phaszination Ergonomie: Von der Entlastung am Fliessband zur Inspiration im Design
4. INSPIRATION IM DESIGN
Eine menschzentrierte Sichtweise bildet die primäre
Grundlage und den Ausgangspunkt für das Design.
So unterschiedlich die Aufgaben auch sein mögen,
steht der Mensch mit seiner physischen,
psychischen und emotionalen Konstitution am
Anfang des Designprozesses und gibt ihm so eine
entscheidende Richtung.
5. QUELLEN
[1] Bolz, N. „Im Blindflug über das globale Dorf.“; in:
Essener Unikate Design & Neue Medien, Essen:
Wissenschaftsverlag, 2002
[2] EN ISO 9241–11: Ergonomische Anforderungen
für Bürotätigkeiten mit Bildschirmgeräten, Teil
11: Anforderungen an die Gebrauchstauglichkeit
– Leitsätze. Berlin: Beuth Verlag, 1998
Abbildung 3: Interfacelösung aus dem Film Minority
Report
[3] Abblidung 1: Aufbau der Diplomarbeit „Fisch
kann man auch mit zwei Gabeln essen“,
Heidrun von Irmer
[4] Abbildung 2: Steuergeräte für Computerspiele,
Thrustmaster®
[5] Abbildung 3: Interfacelösung aus dem Film
Minority Report,  Twentieth Century Fox &
Dreamworks LLC
117
Lazzeroni, C., Hofmann, T., Gersch, P. & Noss, C.
Referenten
Prof. Claudius Lazzeroni
1988 - 1993 Mediendesign Studium, Bildo Akademie für Kunst und Medien, Berlin
1992 - 1996 Creative Director bei der Pixelpark AG
1996 Gründer und geschäftsführender Gesellschafter der im stall GmbH
seit 1999 Professor für Interfacedesign an der Universität Essen
seit 2003 Mitglied des Instituts für Ergonomie und Designforschung
Forschungsschwerpunkte
Dramaturgie des Zwischenraumes: Die Ausarbeitung von neuen Kriterien für die Basis der
gestalterischen Arbeit mit nicht linearen Medien. Das bedeutet Instrumente zu schaffen,
um als Mensch souverän mit Informationen und Emotionen umgehen zu können. Das setzt
die Entwicklung von neuen Informationsstrukturen voraus und führt zu bisher ungedachten
Dramaturgieformen.
Sinnlichkeit der neuen Medien: Um die unbegrenzten Möglichkeiten von multimedialen
Werkzeugen systematisch als Kommunikationsinstrumente einsetzen zu können, bedarf es
eines grundlegenden Verständnisses über menschliche Wahrnehmungsformen in den
durch den Fortschritt veränderten Umgebungen. Wir befinden uns auf dem Weg zu einer
neuen Grundlehre, die Wahrnehmungslehre sein muss, in ständiger Reflexion über die
entsprechende Reizform einer neuen Technologie.
Dipl. Des Petra Gersch
1991 - 1999 Studium des Industrial Design, Universität Essen
1997 - 1998 freiberufliche Tätigkeit als Designerin in verschiedenen Designbüros
1998 - 2000 Gestaltungskonzept für die feste Ausstellung STAHLWERK im Rheinischen
Industriemuseum Oberhausen. Erarbeitung der kompletten Ausstellungsarchitektur und
des Graphik Designs
1999 Diplom mit dem Thema: „Schnittstellengestaltung für intelligente Bürosysteme, unter
Einsatz von Agentensystemen, in Kooperation mit dem Fraunhofer Institut für graphische
Datenverarbeitung in Darmstadt“.
1999 Tätigkeit als Dozentin für Grundlagen des Designs am Zentrum für audiovisuelle
Medientechnik der Technischen Akademie Wuppertal
1999 - Juni 2000 Wissenschaftliche Hilfskraft im Fachgebiet Ergonomie im Design
seit Juni 2000 Wissenschaftliche Mitarbeiterin am Institut für Ergonomie und Designforschung
Museen und neue Medien: Wie werden neue Medien in Museen eingesetzt? Wie könnte eine
Vorgehensweise beschrieben werden die bewirkt, das analoge und digitale Konzepte bei
der Planung eines Museums oder einer Ausstellung zu einer sinnvollen Einheit
zusammengeführt werden.
118
Phaszination Ergonomie: Von der Entlastung am Fliessband zur Inspiration im Design
Dipl. Des Thomas Hofmann
1993 bis 2001 Industrial Design Studium, Universität-GH Essen und freiberufliche Tätigkeit
als Designer
1995 - 1997 Mitarbeiter IKEA Deutschland, Bereich Inneneinrichtung, Lehrtätigkeit für
Zeichenkurse
1997 Stipendium an der Danmarks Design Skole
1999 Gründung Designbüro
2000 - 2001 Anstellung bei der Fraunhofer Gesellschaft (Institut für Medienkommunikation)
2001 Diplom (in Kooperation mit der Fraunhofer Gesellschaft), Thema: „Entwicklung eines
Arbeitsplatzes für Industrial Designer unter Einbezug der Möglichkeiten Virtueller
Entwicklungsumgebungen“. Schwerpunkt war, die Arbeit in der VR den Vorgehens- und
Denkweisen
des
Designers
beim
Entwurf
anzupassen.
Ausgezeichnet mit einem LuckyStrike Junior Designer Award (innovativstes Produkt),
Designpreis Neunkirchen
seit 2001 Wissenschaftlicher Mitarbeiter am Institut für Ergonomie und Design-
wissenschaften, Lehrauftrag für Ergonomie und Interfacedesign an der Fachhoch-schule
Coburg, Lehrtätigkeit an der Universität Essen, Ergonomie
Entwicklung intuitiver Interfaces: Die Technologie heutiger Computer ermöglicht die
Umsetzung hochkomplexer virtueller Werkzeuge. Zum großen Teil ist es jedoch so, dass
diese wenig ergonomisch ausgelegt sind und wenig mit dem vom Designer gewünschten
workflow zu tun haben. Ziel der Arbeit ist es, die Entwicklungsum-gebung am Rechner
intuitiver und an den Designer angepasster zu gestalten.
Bewertung des Skizzenprozesses: Im Zusammenhang der Entwicklung intuitiver Werkzeuge
wird derzeit im Rahmen einer Studie der Skizzenprozess bei Designern untersucht. Es soll
untersucht werden, wo Gemeinsamkeiten und Unterschiede bei der Erstellung bestehen,
gibt es typische Charakteristika bei allen Designern?
Dipl. Des Christian Noss
1993 - 2001 Industrial Design Studium, Universität-GH Essen
1998 - 2000 Designer bei ERCO Leuchten im Bereich digitale Kommunikation
seit 2000 Geschäftsführender Gesellschafter der Klickmeister GmbH, Designbüro für
digitale Medien
2001 Diplom mit dem Thema: "e-dötzchen und Klickmeister, digitale Gestaltungs-
strategien für unterschiedlich geübte Nutzergruppen".
Mai 2001 Wissenschaftlicher
Designwissenschaften
seit
Mitarbeiter
am
Institut
für
Ergonomie
und
Gestaltung Web basierter Werkzeuge: Wie können Arbeitsprozesse durch den Ein-satz Web
basierter Werkzeuge vereinfacht, verbessert und beschleunigt werden und wie können
solche Werkzeuge benutzerfreundlich gestaltet werden?
Evaluation von Webangeboten mit dem Maus-O-Meter: Das Maus-O-Meter ist eine Methode
die es möglich macht, die Interaktion von Nutzern innerhalb eines World Wide Web
Angebotes aufzuzeichnen und zu rekonstruieren. So können Designer Nutzern beim
Umgang mit einer Website "über die Schulter gucken", und das online.
119
METHODEN UND PROZESSE
DESIGN FAKTOREN ALS EIN INSTRUMENT
ZUR VERBESSERUNG DER QUALITÄT VON DESIGN-PROZESSEN
Helmut Degen
Vodafone Holding GmbH
Global Products & Services
Mannesmannufer 2
40213 Düsseldorf
helmut.degen@vodafone.com, hdegen@acm.org
ABSTRACT
Der
vorliegende
Beitrag
beschreibt
ein
Instrumentarium zu Steuerung und Optimierung von
Design-Prozessen. Das Instrumentarium besteht aus
sechs Design-Faktoren: Content, Funktion, Media,
Wording, Layout, Linkage. Diese Faktoren werden
konstruktiv im Rahmen der Anforderungsermittlung
eingesetzt. Über die Auswertung der Ergebnisse von
Usability Tests können mit Hilfe der Design-Faktoren
Schwächen im angewandten Design-Prozess aufgedeckt und gezielt Verbesserungsvorschläge
gemacht werden. Weiterhin werden weitere
Nutzungsmöglichkeiten
der
Design-Faktoren
benannt.
Keywords
Usability Engineering, Prozess-Qualität, ProzessSteuerung, Design-Faktoren
1. EINLEITUNG
In vielen Branchen gehört das Steuern und
Kontrollieren von Prozessen zum StandardInstrumentarium. Zum Handwerkszeug des Usability
Engineerings gehört zwar das Messen der ProduktQualität, also das Messen der Usability-Qualität von
User Interfaces, aber bisher kaum das Steuern und
Kontrollieren des Design Prozesses. Der DesignProzess umfasst hier alle Phasen, wie sie
beispielsweise in der ISO 13407 beschrieben
werden.
In diesem Beitrag wird ein Instrumentarium
vorgestellt, mit dem ein Design-Prozess gesteuert
werden kann. Es soll damit möglich sein, die
Qualität des angewandten Design-Prozesses zu
messen und gezielt Verbesserungsmaßnahmen
Stuttgart).
Proceedings of the
abzuleiten. Das Steuern und Messen der Qualität
von Design - Prozessen erfolgt mit so genannten
Design-Faktoren, die später vorgestellt werden.
Die Design-Faktoren sind Teil eines DesignProzess-Frameworks, das für Design-Projekte von
webbasierten
E-Business-Anwendungen
am
Competence Center “User Interface Design“ der
Siemens AG entwickelt wurde [1].
Der Beitrag gliedert sich in folgende zwei Abschnitte.
Im nächsten Abschnitt werden in Kürze die Phasen
eines Design-Prozesses nach ISO 13407 vorgestellt.
Im dritten Abschnitt werden die 6 Design-Faktoren
und
deren
Verwendung
in
den
Phasen
Anforderungsermittlung, User Interface Design,
Evaluation und Prozess-Verbesserung beschrieben.
Der Beitrag schliesst mit einer Zusammenfassung.
2. DESIGN PROZESS
Um die Anwendungsweise der Design-Faktoren zu
zeigen, wählen wir hier beispielhaft einen DesignProzess nach ISO 13407, der nachfolgend skizziert
wird:
•
Nutzungskontext-Analyse:
Identifikation
von
Nutzungsumgebungen,
Benutzerprofilen, Aufgaben, Werkzeugen und
Funktionen, Dokumenten sowie Contents. Die
Nutzungskontext-Anaylse
gibt
Aufschluss
darüber,
welcher
Content
und
welche
Funktionen im welchem Nutzungskontext für die
Benutzungsoberfläche benötigt werden.
•
Anforderungsermittlung:
Identifizieren erwarteter Eigenschaften der
zukünftigen
User
Interfaces.
Die
Anforderungsermittlung gibt Aufschluss darüber,
wie die Benutzungsoberflächen gestaltet werden
sollen.
•
User Interface Design:
Gestaltung der User Interfaces, basierend auf
den Ergebnissen der Nutzungskontext-Analyse
und Anforderungsermittlung
•
(Formative) Evaluation:
Überprüfen der Qualität der User Interfaces im
Hinblick auf typische Aufgaben und Szenarien
der Benutzer. Identifikation von Verbesserungs-
123
Degen, H.
potentialen und ggf. von Verbesserungsvorschlägen.
•
Prozess-Verbesserung:
Analyse von Schwächen und ihrer Ursachen im
Design-Prozess und Identifikation von Verbesserungsmaßnahmen. Diese Phase ist nicht
Bestandteil des Prozesses gemäß ISO 13407
und Bestandteil der vom Autor vorgeschlagenen
Methode [1].
Innerhalb der ersten vier Phasen (NutzungskontextAnalyse, Anforderungsermittlung, User Interface
Design,
Evaluation)
werden
üblicherweise
spezifische Methodenbausteine verwendet.
3. DESIGN-FAKTOREN
3.1 Definition
Basierend auf der Auswertung von mehreren
Usability Test-Ergebnissen konnten 6 DesignFaktoren identifiziert werden. Mit diesen können die
Usability Probleme in Klassen von User InterfaceElementen klassifiziert werden. Es handelt sich um
folgende Faktoren:
•
Content: Welche Art von Content erwartet der
Benutzer? Wie sollte Content gruppiert werden?
•
Funktion: Welche Art von Funktionen erwartet
der Benutzer? Welchem Content oder ContentGruppen werden die Funktionen zugeordnet?
•
•
Information zu erfassen. Für die Erfassung von
Anforderungen im Rahmen von webbasierten EBusiness-Projekten (vor allem B2B) wurde eine
spezifische Methode entwickelt, die im Kern die
Design-Faktoren enthält. Diese Methode wird
NOGAP bezeichnet [1]. Kernidee dieser Methode ist
es, die beteiligten Benutzer ihre Vorstellungen
visualisieren zu lassen. Zu den visualisierten
Darstellungen (Skizzen) werden dann gezielt Fragen
unter Berücksichtigung der Design-Faktoren gestellt
(siehe Abschnitt 3.1).
3.2.2 User Interface Design
Die im Rahmen der Anforderungsermittlung
identifizierten gewünschten und/oder geforderten
Eigenschaften der User Interfaces werden für das
User Interface Design systematisch ausgewertet und
im Design berücksichtigt.
3.2.3 Usability Evaluation
Die Design-Faktoren können nicht nur zur Steuerung
des Design-Prozesses verwendet werden, sondern
auch zur Messung der bisher erreichten Qualität des
User Interfaces. Hierzu wird für jedes identifizierte
Usability-Problem geprüft, welchen der DesignFaktoren es zugeordnet werden kann. Für die
Zuordnung gibt es pro Design-Faktor Leitfragen, die
nachfolgend aufgeführt sind:
•
Media: In welcher Medienform (z.B. Text, Grafik,
Sound) sollte Content und/oder Funktionen
dargestellt werden?
Content: Content fehlt auf dieser Webseite;
angebotene Contents auf dieser Webseite sind
überflüssig.
•
Wording: Welche Ausdrucksform (textuell,
grafisch, akustisch) sollte für Content und/oder
Funktionen gewählt werden?
Funktion: Funktionen fehlen auf dieser
Webseite; angebotene Funktion sind auf dieser
Webseite überflüssig
•
Media: Die angebotene(n) Medienform(en)
werden nicht verstanden; eine Medienform fehlt.
•
Wording: Eine angebotene Ausdrucksform wird
nicht
verstanden;
eine
angebotene
Ausdrucksform wird missverstanden.
•
Layout: Die Anordnung der Elemente ist nicht
erwartungskonform; Gestaltungsmittel sind nicht
erwartungskonform gewählt
•
Linkage: Die Abfolge der Webseiten ist nicht
erwartungskonform.
•
Layout: Wie sollten die einzelnen Elemente
(Content, Funktionen) auf einer Webseite
angeordnet werden? Wie sollten sie gestaltet
werden?
•
Linkage: Wie ist die erwartete Abfolge von
einzelnen Webseiten?
3.2 Anwendung der Design-Faktoren
Die Design-Faktoren werden in den vier Phasen
unterschiedlich angewendet. Im Rahmen der
Anforderungsermittlung und des User Interface
Designs steuern sie den Design-Prozess, während
sie in der Usability Evaluation die Qualität messen.
In der Phase Prozess-Verbesserung können
Verbesserungsvorschläge identifiziert werden, um
die Qualität des Design-Prozesses gezielt zu
verbessern. Nachfolgend wird die Anwendung der
Design-Faktoren in den vier Phasen detailliert
beschrieben.
3.2.1 Anforderungsermittlung
Die sechs Design-Faktoren werden während der
Anforderungsermittlung als Leitfaden verwendet, um
für einzelne Szenarien gezielt design-relevante
124
Grundsätzlich ist es möglich, ein Usability-Problem
einem oder mehreren Design-Faktoren zuzuordnen.
Nach der Zuordnung der Usability-Probleme zu den
Design-Faktoren ergeben sich Häufigkeiten für die
einzelnen Design-Faktoren. Die Häufigkeit pro
Design-Faktor gibt Hinweise darüber, in welcher
Phase Verbesserungsmöglichkeiten bestehen. Dies
wird im nächsten Abschnitt beschrieben.
3.2.4 Prozess-Verbesserung
Gemäß der Logik des Design-Prozesses können die
Design-Faktoren den eingeführten Phasen des
Design-Prozesses zugeordnet werden:
•
Content: Nutzungskontext-Analyse
Design Faktoren als ein Instrument zur Verbesserung der Qualität von Design-Prozessen
•
Funktion: Nutzungskontext-Analyse
•
Media: Anforderungsermittlung
•
Wording:
Nutzungskontext-Analyse,
derungsermittlung
•
Layout: Anforderungsermittlung, User Interface
Design
•
Linkage: Anforderungsermittlung
Anfor-
Liegen beispielsweise besonders viele ContentProbleme vor, liegt die Ursache in der Nutzungskontext-Analyse und dort besonders bei den Schritten,
die für die Erfassung von Contents durchgeführt
werden. Liegen viele Wording-Probleme vor, so
kann die Ursache in der Nutzungskontext-Analyse,
aber auch in der Anforderungsermittlung liegen.
Liegen beispielsweise Linkage-Probleme vor, so
liegt die Ursache in der Anforderungsermittlung.
Häufen sich also die Usability-Probleme bei
einzelnen Design-Faktoren, so können die Phasen
im Design-Prozess und innerhalb der Phasen die
angewandten
Methoden-Bausteine
identifiziert
werden, die dann gezielt verbessert werden können.
Es kann natürlich auch das Ergebnis einer solchen
Prozess-Analyse sein, dass ein Methoden-Baustein
fehlt, der dann in den Design-Prozess integriert
werden sollte, um bestimmte Fehler zu vermeiden.
Nutzungskontext-Analyse nur unzureichend der
relevante Content und die relevanten Funktionen
identifiziert werden können. Ohne Anforderungsermittlung wird nicht der Flow zwischen einzelnen
Webseiten erhoben. Die drei Design-Faktoren
Content, Funktion und Flow stellen die tragenden
Säulen eines benutzerfreundlichen Konzepts für
Webseiten dar.
Bei der Beschreibung der Ursachenermittlung wurde
in den bisherigen Beschreibungen davon ausgegangen, dass sich die Ergebnisse des Design-Prozesses
1:1 umsetzen lassen. Es passiert in Projekten aber
immer wieder, dass im Rahmen von Abstimmungsprozessen zwischen Projektbeteiligten (z.B. Technik
und Marketing) Ergebnisse nicht 1:1 umgesetzt
werden können. Wurde die Nicht-Umsetzung bei der
Prozess-Schwachstellenanalyse als Schwäche der
Benutzungsoberfläche identifiziert, dann liegt
natürlich keine Schwäche des Design-Prozesses
vor. Ein solches Ergebnis lässt sich dann bei
späteren Abstimmungsprozessen als Argument einbringen, um zu versuchen, Design-Entscheidungen
zugunsten der Benutzerfreundlichkeit zu beeinflussen.
4. ZUSAMMENFASSUNG UND AUSBLICK
Die Benennung einer Phase ist für die Ursachenermittlung ein sinnvoller Startpunkt. In der Regel
reicht die Phasenbenennung nicht aus. Da jede
Phase in der Regel aus mehreren MethodenBausteinen besteht, wird die Ursachensuche dann
bis zur Identifikation des betreffenden MethodenBaustein fortgesetzt.
In diesem Beitrag wurden 6 Design-Faktoren
vorgestellt, mit denen es möglich ist, einen DesignProzess zu steuern, die Qualität eines DesignProzesses zu messen und damit gezielt einen
Design-Prozess zu verbessern. Hiermit ist es
Usability
Engineers
gezielt
möglich,
ihre
Arbeitstechniken und eingesetzten Methoden zu
verfeinern und gegebenenfalls mit notwendigen
neuen Methodenbausteinen anzureichern.
3.2.5 Weitere Nutzungsmöglichkeiten
Die Qualität eines Design-Prozesses kann übrigens
auch dann gemessen werden, wenn dieser gar nicht
bekannt ist. Für die Qualitätsmessung genügt die
Durchführung eines Usability-Tests und dann die
Zuordnung der Usability-Probleme zu den DesignFaktoren. Aus der Verteilung lässt sich dann
ablesen, welche Qualität der Design-Prozess hat,
der für die Gestaltung eines beliebigen User
Interfaces angewendet wurde.
Der hier vorgestellte Ansatz zur Optimierung von
Design-Prozessen bezieht sich auf webbasierte EBusiness-Anwendungen und einen Design-Prozess
nach ISO 13407. Für andere Anwendungsarten (z.B.
auf mobilen Endgeräten) und andere Prozess-Arten
ist ein ähnliches Optimierungsverfahren ebenfalls
anwendbar. Hier sind zuerst die relevanten DesignFaktoren zu ermitteln und dann der Zusammenhang
zwischen den Design-Faktoren und den ProzessPhasen herzustellen.
Die Zuordnung von Design-Faktoren zu einzelnen
Phasen des Design-Prozesses basiert auf der
Struktur des Design-Prozesses. Wenn ein DesignProzess der Logik des Prozesses nach ISO 13407
folgt, gilt die vorgeschlagene Zuordnung. Wird ein
anderer Prozess-Typ verwendet, so kann die
Zuordnung zu einem anderen Ergebnis kommen.
Der Zusammenhang zwischen Design-Faktoren und
Phasen im Design-Prozess kann bereits bei der
Projekt-Akquise genutzt werden. Es ist häufig zu
beobachten, dass potentielle Auftraggeber nur
bestimmte Arbeitspakete (z.B. nur das User
Interface Design) beauftragen wollen. Der Usability
Experte
kann
argumentieren,
dass
ohne
ACKNLOWLDGEMENT
Ich danke Petra Vogt für die kritische Durchsicht und
das schnelle und konstruktive Feedback.
5. REFERENCES
[1] Degen, H. and Pedell, S.: JIET Design Process
for e-Business Applications. Appears in: Diaper,
D. and Stanton, N. (eds): The Handbook of Task
Analysis for Human-Computer Interaction.
Lawrence Erlbaum (2003).
[2] ISO 13407: Human-Centred Design Processes
for Interactive Systems, ISO 13407: 1999.
125
Degen, H.
Referent
Dr. Helmut Degen arbeitet seit Beginn des Jahres bei der Vodafone Holding GmbH
und ist für die Gestaltung von Messaging-Produkten verantwortlich. Zuvor war er als
Principal Consultant im Competence Center „User Interface Design“ der Siemens AG
tätig, hier verantwortlich für den Aufbau einer E-Business-Gruppe und die Gestaltung
von E-Business-Anwendungen. Helmut Degen entwickelte das JIET Design ProzeßFramework für webbasierte E-Business-Applikationen. JIET wurde in internationalen
Projekten angewendet und international publiziert. Zuvor arbeitete er an der Freien
Universität Berlin, an der er im Fach Informationswissenschaft promoviert. Helmut
Degen studierte Informatik, Betriebswirtschaftslehre und Philosophie an der
Universität Karlsruhe (TH) und Semiotik an der Technischen Universität Berlin.
Sein Hauptinteresse gilt der Optimierung von Design-Prozessen unter Berücksichtigung der Qualität von User Interfaces und den bestehenden Rahmenbedingungen in der industriellen Praxis. Sowohl die interdisziplinäre Ausbildung wie
auch die interdisziplinäre und internationale Erfahrung sind Grundlage für eine
erfolgreiche Projektarbeit und den Austausch zwischen Wissenschaft und Praxis.
126
METHODEN ZUR EINBINDUNG DES KUNDEN IN PLANUNG,
DURCHFÜHRUNG UND AUSWERTUNG EINES USABILITYANWENDUNGSTESTS
Sven Krause
IBM e-business Innovation Center
Alter Wandrahm 10
D-20457 Hamburg
svekra@de.ibm.com
ABSTRACT
In Usability-Anwendungstests kommt der Einbindung
des Kunden über den gesamten Projektverlauf
besondere Bedeutung zu. Anhand von Beispielen
aus der Praxis zeigen wir, wo diese Einbindung
gewinnbringend und fruchtbar ist und diskutieren die
Methoden, welche sich dafür besonders eignen.
Demgegenüber diskutieren wir Projektphasen, in
denen diese Einbindung kritisch, wenn nicht sogar
kontraproduktiv ist.
Keywords
Usability, Anwendungstest, Kundeneinbindung
1. EINLEITUNG
Die Einbindung eines Kunden in Planung, Durchführung und Auswertung eines Anwendungstests stellt
einen wichtigen Faktor für das Gelingen des
Projektes dar. Sie birgt aber auch eine
psychologische Herausforderung für den UsabilityExperten (UE), welcher zwar den Input des Kunden
berücksichtigen sollte, sich aber durch dessen
Einfluss nicht im Ablauf des Projektes behindern
lassen darf. Dies gilt gleichermaßen, für den Fall,
dass es sich bei dem “Kunden“ um eine Abteilung
des eigenen Unternehmens handelt, wie für externe
Auftraggeber. Im Folgenden werden deshalb am
Beispiel eines idealtypischen Projektablaufes
anhand der einzelnen Projektphasen Nutzen und
Risiken dieser Einbindung diskutiert.
Jens Heuer
IBM e-business Innovation Center
Alter Wandrahm 10
D-20457 Hamburg
jens.heuer@de.ibm.com
etabliert. Sie gehören zu der Gruppe von Tests, in
denen potenzielle Endnutzer im Rahmen unterschiedlicher Szenarien eine Reihe von Aufgaben
innerhalb einer Website, einer Software, oder einer
vergleichbaren Anwendung ausführen sollen.
Anhand der Ergebnisse lassen sich gegenüber dem
Kunden Aussagen bezüglich der Erlernbarkeit und
Bedienbarkeit seiner Site treffen, es werden aber
auch Heuristiken, wie zum Beispiel Erwartungskonformität und Fehlertoleranz berücksichtigt. Am
Beginn einer umfangreicheren Zusammenarbeit mit
dem Auftraggeber steht dabei oft die Bewertung des
Webauftritts oder einer Software. Gerade bei einem
ersten Kontakt kann eine solche Bewertung eine
psychologisch recht schwierige Aufgabe darstellen.
Besonders bei einem negativen Urteil kann es
seitens des Kunden zu erheblichen Akzeptanzproblemen kommen. Aus diesem Grunde ist es
wichtig, den Auftraggeber von Anfang an in das
Projekt einzubinden. Auch bei der Auswahl der Testteilnehmer, der Erstellung geeigneter Szenarien und
der Definition von “Next Steps“ stellt der enge
Kontakt zum Kunden eine wichtige Voraussetzung
für den Erfolg des Testverfahrens dar.
2.1 Formen der Zusammenarbeit
Prinzipiell lassen sich in einem Projekt vier
Möglichkeiten unterschieden, wie der Austausch zwischen dem Auftraggeber und einem Usability Experten (UE) ablaufen kann:
•
Information des Auftraggebers
Der UE erarbeitet selbständig die entsprechenden Dokumente und gibt diese dem Auftraggeber zur Kenntnis.
•
Input von Kundenseite
Hierbei stellt der Kunde Dokumentationen oder
andere Materialien zur Verfügung. Diese Informationen können auch im Rahmen von sogenannten ‚Briefings’ persönlich oder telefonisch
vermittelt werden.
•
Abstimmungen
Hier gibt der UE Inhalte und Dokumente in
einem vorläufigen Status ab. Der Auftraggeber
erhält
die Möglichkeit,
die Dokumente
2. USABILITY- ANWENDUNGSTESTS
Anwendungstests haben sich in den vergangenen
Jahren als Standardverfahren in der Usability-Arbeit
Stuttgart).
Proceedings of the
127
Krause, S. & Heuer, J.
einzusehen und in einem gemeinsamen Treffen
Änderungswünsche zu besprechen.
•
Gemeinsames Erarbeiten von Ergebnissen
In gemeinsamen Workshops werden bestimmte
Arbeitsergebnisse unter Anleitung des UE
erstellt, wobei Auftraggeber und UE zu gleichen
Teilen Inhalte beitragen.
3. UMSETZUNG EINES ANWENDUNGSTESTS IM PROJEKT
Der prinzipielle Ablauf eines Usability-Testing
Projektes gliedert sich immer in sieben Phasen auf,
in denen eine unterschiedlich starke Beteiligung des
Auftraggebers möglich ist.
Planung
• Input
• Workshop
Design
Rekrutierung
Pilot
• Abstimmungen
• Abstimmung
• Kein Kontakt
Durchführung
Auswertung
• Beobachtung
• Information
2
Grobkonzept
Nutzergruppen def inieren
4
Untersuchungsgegenstand def .
5
Fragestellungen ausarbeiten
6
7
Auf gaben/Szenarien
Feinkonzept
8
Szenarien schreiben
9
Maße festlegen
10
11
12
Logisit k v orbereiten
Rekrutierung
Rekrutierungsprozess
13
Fragebögen v orbereiten
14
Agentur brief en
15
16
01. Sep ' 03
08. Sep '03
15.
M D M D F S S M D M D F S S M
Kickoff
3
Rücksprache mit Agent ur
Abstimmung Testt eilnehmer
17
Pilot
18
Durchführung
19
Auswertung
20
Präsentation & Next Steps
21
Lessons Learned
Abbildung 2: Typischer Projektplan eines Anwendungstests
Aus dieser Grafik wird deutlich, dass die einzelnen
Phasen starke Abhängigkeiten aufweisen. Gerade
parallel ablaufende Phasen sind zeitkritisch, so dass
hier eine problemlose Abstimmung mit dem Auftraggeber entscheidend für die Einhaltung des Zeitplans
ist.
128
Welchem Ziel dient der Test? Es gibt
Situationen, in denen Usability – Untersuchungen nicht einfach nur dem Zweck der
Produktverbesserung, sondern als politische
Argumentationshilfen dienen.
•
Wer ist der zentrale Sponsor (wer gibt den Test
in Auftrag)?
•
Wer ist der fachliche Ansprechpartner zur
Klärung von Fragen und zur Durchsetzung von
Entscheidungen?
•
Wer
sind
die
verschiedenen
Gruppen
(Marketing, Entwicklung etc.), die ggf. in den
Test mit einbezogen werden sollten?
• Workshops
Überführt man diese generellen Phasen in einen
Projektplan, ergibt sich folgendes Bild:
Name
•
Präsentation
Abbildung 1: Phasen eines Usability-Tests. "Dunkle"
Elemente stehen für intensiven Kontakt, helle Phasen
für wenig oder keinen Kontakt
Nr.
1
3.1 Planung: Klärung von Rahmenbedingungen
und Verantwortlichkeiten
Ein wichtiger Aspekt bei der Vorbereitung eines
Usability-Tests ist die Sondierung der bei einem
Auftraggeber bestehenden ‚politischen Landschaft’.
Hiermit sind alle organisatorischen Faktoren
gemeint, die die Durchführung des Tests und vor
allem die Aufbereitung und Präsentation der
Ergebnisse betreffen können. Als wichtig haben sich
insbesondere folgende Aspekte herausgestellt:
Sind diese Punkte nicht im Vorfeld des Tests
geklärt, kann sich die Abstimmung und die
Durchführung der eigentlichen Untersuchung stark
verkomplizieren, wenn zum Beispiel die Art der zu
rekrutierenden Testteilnehmer nicht mit dem
Auftraggeber abgestimmt werden kann.
Einige dieser Fragen lassen sich erst bei dem im
folgenden
beschriebenen
Kickoff-Workshop
bearbeiten. Spätestens dann ist ihre Beantwortung
jedoch unerlässlich für eine erfolgreiche Umsetzung
des Projektes.
Vor der Durchführung des Kickoff-Workshops sollten
zusätzlich alle Informationen vorliegen, die der
Auftraggeber zur Verfügung stellen kann. Hierbei
handelt es sich um Informationen über Zielgruppen
(z.B. aus Marketingstudien) oder vorherige
Aktivitäten zum Thema Usability (z.B. bereits
durchgeführte Tests, Umfragen etc.).
Um möglichst schnell und effizient an diese
Informationen zu gelangen ist ein guter Kontakt zu
einem zentralen Ansprechpartner des Auftraggebers
unerlässlich. Dieser übernimmt die Aufgabe, die
Dokumente ggf. aus verschiedenen Fachabteilungen
und Unternehmensbereichen einzusammeln und zur
Verfügung zu stellen.
Diese
insgesamt
recht
umfangreichen
Vorbereitungen ermöglichen eine genaue Planung
der weiteren Aktivitäten und stellen sicher, dass der
Test innerhalb des vorgegebenen Zeit- und
Kostenrahmens durchgeführt werden kann.
3.2 Planung: Kickoff Workshop
Den eigentlichen Projektstart markiert der Kickoff
Workshop beim Kunden. In ihm werden nicht nur die
zu testenden Aufgaben und die zu berückUsability Professionals 2003
Methoden zur Einbindung des Kunden in Planung, Durchführung und Auswertung eines Usability- Anwendungstests
sichtigenden
Nutzerprofile
grob
eingegrenzt,
sondern auch die für die Anwendungstests in Frage
kommenden Szenarien. Bei unterschiedlichen
Teilbereichen der Anwendung, die verschiedene
Verantwortliche haben (wie z.B. Subportalen, oder
Microsites), sollten spätestens hier die einzelnen
Ansprechpartner auf Seiten des Kunden definiert
werden. Es macht Sinn, zu Beginn dieses
Workshops dem Kunden nochmals kurz die
verwendete Methode vorzustellen. Daraufhin sollten
innerhalb dieses methodischen Rahmens die
Fragestellungen des Kunden Berücksichtigung
finden und konkretisiert werden.
Ziele des Workshops sind, dass dem UE alle für die
Planung und Durchführung der Anwendungstests
nötigen Informationen zur Verfügung stehen, dass
die inhaltlichen Schwerpunkte und Fragestellung des
Kunden ausreichend im Testdesign Berücksichtigung finden, und dass man sich gemeinsam
auf definierte „Meilensteine“ innerhalb des Projekts
geeinigt hat.
Insgesamt muss der Kunde in dieser Phase “mit ins
Boot geholt“ werden, und es sollte ein Gefühl des
Beteiligtseins vermittelt werden. Dies erleichtert dem
UE die Arbeit und steigert die Zufriedenheit auf
Seiten des Kunden.
3.3 Design: Erstellung des Grobkonzeptes
Auf der Basis der bisher gesammelten Informationen
ist es nun möglich, eine erste Version des Testkonzepts zu entwickeln. Hierbei handelt es sich typischerweise um eine Aktivität, die vom UE ohne
direkte Beteiligung des Auftraggebers durchgeführt
wird. Der Kundenkontakt gewinnt erst im Rahmen einer Abstimmung des Konzepts wieder an
Bedeutung. Für diese Abstimmung bekommt der
Auftraggeber Einblick in das Dokument und hat die
Gelegenheit, Änderungswünsche zu äußern. In den
meisten Fällen ist zur Diskussion von offenen
Punkten eine Telefonkonferenz ausreichend.
Am Ende dieser Phase besteht eine Übereinkunft
zwischen dem Auftraggeber und dem UE über folgende zentralen Punkte des Tests:
•
•
Definition der Zielgruppen: Festlegung auf eine
handhabbare Anzahl von Zielgruppen und
Testteilnehmern sowie deren spezifischen
Eigenschaften und Kriterien für die Auswahl der
Testteilnehmer (z.B. Auswahl nach demographischen Eigenschaften oder nach Rolle in einem
Unternehmen).
Klärung der zentralen Fragestellungen, auf
deren
Beantwortung
der
Auftraggeber
besonderen Wert legt. Hierbei müssen die
Interessen des Auftraggebers in Fragestellungen
überführt werden, die spezifisch genug und vor
allem messbar sind. Allgemeine Fragen wie
‚Versteht der Benutzer die Anwendung?’ oder zu
spezifische Aspekte wie ‚Klickt der Nutzer auf
die rechtlichen Hinweise?’ sind hierfür
ungeeignet und müssen auf eine geeignete
Granularitätsebene überführt werden.
•
Festlegung der zu testenden Aufgaben. An
dieser Stelle muss mit dem Auftraggeber sehr
genau abgestimmt werden, welche Aufgaben
und Szenarien sich aus den Fragestellungen des
Auftraggebers herleiten lassen und ob sie im
Rahmen der vorgegebenen Zeit bearbeitet
werden können. In dieser Phase muss vor die
schrittweise Ausweitung der Fragestellungen
und Aufgaben‚ vermieden werden (FeatureCreep).
Besonders in dieser Phase ist es wichtig, auf Seiten
des
Auftraggebers
einen
dedizierten
Ansprechpartner
zu haben,
der
die ggf.
unterschiedlichen Anforderungen der einzelnen am
Testergebnis
interessierten
Parteien
des
Auftraggebers koordiniert und damit eine effiziente
Diskussion erlaubt.
3.4 Design: Feinkonzept
In dieser Phase werden die bisher festgelegten
generellen Aspekte in einem finalen Testkonzept
dokumentiert. Auch hierbei handelt es sich um eine
Aktivität, die von dem UE selbständig durchgeführt
wird. Dem Auftraggeber wird das finale Konzept zur
Verfügung gestellt. Feedback in dieser Phase ist
noch möglich, alle grundlegenden Entscheidungen
sollten jedoch nicht mehr in Frage gestellt werden.
Aktivitäten für das Feinkonzept umfassen:
•
Szenarien schreiben: Die vorher abgestimmten
Aufgaben werden in zusammenhängende
Testszenarien überführt.
•
Maße festlegen: Es wird festgelegt, inwieweit
quantitative Maße (Fehlerzahl, Zeitdauer etc.)
qualitative Daten (Beschreibung von einzelnen
‚Findings’) und subjektive Einschätzungen (z.B.
Zufriedenheit) erhoben werden.
•
Logistik vorbereiten: Planung des zeitlichen Ablaufs, der erforderlichen Räumlichkeiten etc.
Das finale Testkonzept enthält somit alle Vorgaben,
die für die Durchführung des eigentlichen Tests erforderlich sind. Gleichzeitig ermöglicht die
detaillierte Dokumentation dem Auftraggeber, den
inhaltlichen Ansatz des Tests nachzuvollziehen.
3.5 Rekrutierung
Möglichst früh im Projektablauf sollte mit der Rekrutierung begonnen werden. Dies kann entweder durch
eine externe Agentur geschehen, oder vom UE
selbst vorgenommen werden. Wir gehen im
folgenden auf
unsere Erfahrungen aus der
Zusammenarbeit mit einer Rekrutierungsagentur
ein. Sind die Nutzerprofile, die getestet werden
sollen, hinreichend differenziert und mit dem
Kunden
abgesprochen
worden,
ist
dessen
Einbindung in dieser Projektphase nicht vorgesehen.
Hilfreich ist in dieser Phase die Erstellung eines
Rekrutierungsfragebogens, der die Nutzergruppen-
129
profile für die Agentur in eine Fragebogenform
übersetzt. Dies beschleunigt die Arbeit der Agentur,
schließt aber auch Missverständnisse bezüglich
einzelner Nutzerprofilkriterien aus.
der verschiedenen Testpersonen konsolidiert und
entsprechend ihrer Schwere priorisiert. Zusätzlich
werden die weiteren Maße aus Fragebögen oder
quantitative Daten zusammengefasst.
Von nun an findet eine laufende Rücksprache mit
den für die Rekrutierung verantwortlichen statt. Die
von der Agentur vorgeschlagenen Teilnehmer
sollten in schwierigen Fällen dem Kunden vorgestellt
werden, so dass er entscheidet, ob die gefundenen
Nutzer in das von ihm definierte Profil passen, oder
nicht.
Während der Auswertung wird – basierend auf der
Kenntnis des Testumfelds – festgelegt, in welcher
Form die Ergebnisdarstellung erfolgen soll.
Prinzipiell sind hier drei Varianten möglich:
3.6 Pilot
Der Pilottest ist ein ‚Probelauf’, in dem die
Testdurchführung noch einmal hinsichtlich des
Zeitaufwandes und der Stimmigkeit der Szenarien
überprüft wird. Diese ‚Generalprobe’ findet generell
ohne Kundenbeteiligung statt.
Für den Piloten müssen keine ‚echten’ Testpersonen
rekrutiert werden – schließlich dient der Pilot nicht
der Erhebung ‚echter’ Daten, sondern lediglich der
Überprüfung des Testkonzepts. Auf der Basis dieses
Probelaufs werden ggf. noch Änderungen an dem
Testkonzept vorgenommen und soweit wie nötig
(z.B.
bei
inhaltlichen
Anpassungen)
dem
Auftraggeber kommuniziert.
3.7 Durchführung
Auch
während
der
Durchführung
der
Anwendungstests agiert der Usability-Experte
weitestgehend autonom. Sollte die Rekrutierung zu
diesem Zeitpunkt noch nicht abgeschlossen sein,
finden unabhängig davon natürlich auch weiterhin
Rücksprachen mit der Agentur und dem Kunden
statt.
Bei jedem der durchgeführten Tests sollte die
Möglichkeit des Hospitierens bestehen, ohne
dadurch den Testablauf zu stören. Dies ist vor allem
für die folgenden drei Zielgruppen interessant:
•
Kunden, die sich ein Bild vom Ablauf und der
Methode eines Anwendungstests machen
möchten.
•
Eigene Mitarbeiter, um sie in der Durchführung
von Anwendungstests fortzubilden.
•
Fachfremde
Mitarbeiter
(Programmierer,
Consultans, Designer), vor allem wenn sie an
der Gestaltung der Anwendung beteiligt sind um
die
Sensibilität
gegenüber
UsabilityAnforderungen auf Seiten der Nutzer zu
erhöhen.
Als sehr sinnvoll hat sich die Aufzeichnung der Tests
per Kamera, oder Screencam gezeigt, um die
Testprotokolle gegebenenfalls zu ergänzen, aber
auch
als
lückenlose
Dokumentation
der
Anwendungstests für den Kunden.
3.8 Auswertung
Die Auswertung der Tests findet ohne Beteiligung
des Auftraggebers statt. Hierbei werden die Findings
130
•
Schriftlicher Ergebnisbericht. Dieser Bericht
enthält in ausführlicher Form alle Daten und Beobachtungen des Tests. Dieser Bericht wird dem
Auftraggeber zum ‚Selbststudium’ zur Verfügung
gestellt.
•
Ergebnispräsentation: In dieser Präsentation
werden die wichtigsten quantitativen Daten zusammengefasst. Kernpunkt ist vor allem die
ausführliche
Erläuterung
von
zentralen
Problemen anhand von Screenshots der
untersuchten Anwendung. Diese Präsentation
wird im Rahmen eines Ergebnisworkshops mit
dem Auftraggeber diskutiert.
•
Maßnahmendokument: Dieses Dokument dient
dem Auftraggeber und dem UE für eine gemeinsame Diskussion und Ausarbeitung von
Maßnahmen zur Problembehebung. Hier werden
noch einmal in strukturierter Form alle einzelnen
Findings dokumentiert mit Angaben zur
Schwere, (vermutetem) Änderungsaufwand und
Verantwortlichkeiten aufgelistet.
Je nach Zielsetzung des Usability-Tests ist zu
entscheiden, ob lediglich ein Ergebnisbericht zur
Verfügung gestellt wird, oder ob ggf. alle drei
Dokumenttypen zur Diskussion mit verschiedenen
Beteiligten des Auftraggebers erforderlich sind.
3.9 Präsentation und Next Steps
In einem abschließenden Workshop sollten den
Verantwortlichen beim Auftraggeber unabhängig von
den bereits übergebenen Ergebnisdokumenten
nochmals die Findings der Anwendungstests
präsentiert werden. Dies dient zum einen dazu, auf
einen gemeinsamen Stand zu kommen und
eventuelle Missverständnisse auszuräumen, zum
anderen stellt es auch die Basis für eine
Formulierung der weiteren Schritte und damit auch
einer fortdauernden Kundenbindung dar. Zu diesem
Zweck werden vom UE im Vorfeld die einzelnen
Findings nochmals priorisiert und ihr UsabilityImpact sowie der Änderungsaufwand geschätzt. Im
Meeting selbst werden diese Angaben dann um die
Einschätzungen der Experten auf Seiten des
Auftragebers ergänzt. Der Return of Investment
sollte
in
diesem
Prozess
als
Entscheidungsgrundlage dienen, so dass der
Usability - Nutzen zukünftiger Investitionen für den
Kunden maximiert wird. Gerade in diesem
Workshop kann sich der UE beim Kunden als
Experten auch für künftige Projekte bezüglich
dessen spezieller Anwendung positionieren, die
Methoden zur Einbindung des Kunden in Planung, Durchführung und Auswertung eines Usability- Anwendungstests
Einbeziehung des Kunden ist in dieser Phase
entsprechend eng.
3.10 Lessons Learned
Von entscheidender Bedeutung für die Evaluation
und Weiterentwicklung der eigenen Methoden ist
eine “Lessons Learned Session“ kurz nach Ende des
Projektes. Diese verläuft ohne die Einbindung des
Auftraggebers, da ausschließlich die interne Projektabwicklung sowie die Anwendung der Methode
behandelt werden. Dieses Treffen soll Anhaltspunkte
über Aspekte wie logistische Schwierigkeiten
während der Durchführung, Stärken und Schwächen
der Methode und besonders Anregungen für
kommende Projekte liefern. Es ist deshalb wichtig,
dass sie von einer neutralen Person moderiert wird,
und dass das erstellte Protokoll danach jedem der
Teammitglieder zur Verfügung steht.
4. VOR- UND NACHTEILE DER
KUNDENEINBINDUNG
Der vorgestellte Ansatz zeigt, dass die Einbindung
des Auftraggebers an verschiedenen Stellen
erfolgen kann. Abschließend sollen deshalb noch
einmal kurz Vor- und Nachteile einer intensiven
Kundenbeteiligung aufgezeigt werden.
4.1 Vorteile der intensiven Kundeneinbindung
Die
Gründe
für
eine
intensive
Kundenkommunikation sind:
•
Akzeptanz schaffen: Der Auftraggeber bekommt
einen transparenten Einblick in das Vorgehen
und kann aktiv auf die Gestaltung des Tests
Einfluss nehmen. Dadurch wird die Akzeptanz
für die Ergebnisse und ein Verständnis für die
Verbesserungsmöglichkeiten geschaffen.
•
Kundenerwartungen treffen: Durch intensive
Einbeziehung des Auftraggebers wird ein
„Auseinanderdriften“ der Erwartungen des Auftraggebers und der tatsächlichen Arbeitsergebnisse vermieden.
•
Effizienz steigern: Durch genaue Festlegung der
Verantwortlichkeiten werden unnötige Diskussionen und Leerläufe vermieden. Wenn sich alle
Beteiligten auf ein gemeinsames Vorgehen und
vorgegebene Methoden zur Kommunikation geeinigt haben, ist die Projektsteuerung des Gesamtprojekts deutlich einfacher.
4.2 Risiken
Neben den Vorteilen gibt es unbestreitbar auch Risiken, die sich wie folgt zusammenfassen lassen:
•
Zeitaufwand: Rücksprachen und Abstimmungen
mit dem Kunden erzeugen zum Teil hohe
Zeitaufwände, die in das Gesamtprojekt mit
eingeplant werden müssen.
•
Weitgehendes Mitspracherecht kann den
Auftraggeber dazu verleiten, immer neue
Anforderungen an das Projekt heranzutragen.
•
Wenn es nicht gelingt, auf Seiten des Auftraggebers einen dedizierten Ansprechpartner zu
finden, kann sich die Kommunikation beliebig
komplex gestalten.
•
Bei der Rekrutierung kann es leicht zu Verzögerungen kommen, wenn der Auftraggeber den
vorgeschlagenen Testteilnehmern nicht zustimmt.
5. FAZIT
Abschließend lässt sich feststellen, dass der Einbindung des Kunden vor allem in die Planung und
Auswertung
von
Anwendungstests
große
Bedeutsamkeit zukommt. An diesen Stellen kann
sich entscheiden, ob das Projekt erfolgreich verläuft
und die Erwartungen des Kunden trifft oder nicht.
Dabei ist es wichtig, den Kunden an einer Reihe von
Entscheidungsprozessen zu beteiligen und seine
Erwartungen und Bedürfnisse ernst zu nehmen, aber
auch für die Durchführung des Anwendungstests
unentbehrliche Materialien von dem Auftraggeber
zur Verfügung gestellt zu bekommen. Der UE sollte
dabei jedoch über den gesamten Projektablauf die
Führung nicht aus der Hand geben und seine Rolle
als Experte und Berater gegenüber dem Kunden
wahrnehmen.
131
Referenten
Sven Krause arbeitet seit Oktober 2002 im IBM e-business Innovation Center in
Hamburg und ist dort vor allem für die Konzeption und Durchführung von
Anwendungstests, Heuristischen Evaluationen und Benchmarks zuständig. Zuvor
hat er zwei Jahre in einem DFG Projekt des Neuropsychologischen Instituts der
Universität Hamburg, Grundlagenforschung in den Bereichen Blickbewegungen
und Aufmerksamkeit bei Parkinsonpatienten betrieben. Er studiert im letzten
Semester Psychologie in Hamburg.
Jens Heuer studierte in Göttingen Psychologie mit den Schwerpunkt Kongnitionsund Arbeitspsychologie. Zwischen 1992 und 1996 arbeitete er am Labor für
Mensch-Maschine System der Universität Kassel. Anschließend war er in
verschiedenen Unternehmen im Bereich der software-ergonomischen Produktprüfung und –gestalltung tätig. Seit einem Jahr leitet er im IBM e-business
Innovation Center die Usability-Community.
132
IF IT DOESN'T FEEL RIGHT WHO CARES IF IT WORKS?
"IF IT DOESN'T FEEL RIGHT, WHO CARES IF IT WORKS?" ODER
MUSS SOFTWARE MEHR ALS NUR GEBRAUCHSTAUGLICH SEIN?
Marc Hassenzahl
Technische Universität Darmstadt
hassenzahl@psychologie.tu-darmstadt.de
ZUSAMMENFASSUNG
Seit einiger Zeit macht sich unter usability professionals Unbehagen über die – vielleicht vermeintliche –
Überbetonung von Arbeitstätigkeiten, Effizienz und
Effektivität breit. Selbst die für Benutzer geforderte
Zufriedenstellung geht Praktikern und Wissenschaftlern noch nicht weit genug. Sie sehen in "Freude bei
der Nutzung", "Spaß" oder anderen emotionalen
Aspekten des Nutzungserlebens das eigentliche
Gestaltungsziel. Dazu scheint es notwendig, sowohl
den traditionellen Begriff der usability (Gebrauchstauglichkeit) zu erweitern, als auch neue, angemessene Methoden zu entwickeln. Zahlreiche Beiträgen
thematisieren Ansätze, Chancen und Schwierigkeiten, die dabei auftreten können.
Keywords
Emotionen, funology, Freude, Spaß, hedonische
Qualität
1. EINLEITUNG
Mies van der Rohes „Weniger ist mehr“ ist eines der
Prinzipien, denen sich usability professionals verpflichtet fühlen. Purismus, Klarheit, Einfachheit,
Effizienz und kein „Firlefanz“ – so lautet ihre Gestaltungsphilosophie. Aber ist weniger wirklich mehr?
Oder ist weniger – wie Robert Venturi, ebenfalls ein
Architekt, es ausdrückt – einfach nur langweilig?
Softwareprodukte haben sicherlich meist einen
Zweck im klassischen Sinne. Personen besitzen sie,
um ihre Umwelt zu manipulieren. Hat Software die
angemessene Funktionalität (Nützlichkeit) und läßt
sich diese Funktionalität auch bedienen (Benutzbarkeit), ist sie gebrauchstauglich im Sinne der DIN EN
ISO 9241-11. Aber das Manipulieren der Umwelt ist
nicht das einzige Bedürfnis, das Menschen mit ei
Stuttgart).
Proceedings of the
Elizabeth Hofvenschiöld
MT Usability Engineering
Fraunhofer IAO
elizabeth.hofvenschiold@iao.fhg.de
nem Produkt verbinden. Sie suchen auch Stimulation, d.h. Neuartigkeit, Veränderung, Herausforderung. Sie kommunizieren ihre Identität, z.B. Einstellungen, sozialen Status oder Zugehörigkeit zu einer
sozialen Gruppe, durch ein Produkt. Darüber hinaus
können Produkte symbolischen Wert haben, wie
z.B. ein Souvenir, das seinen Besitzer an einen
schönen Urlaub erinnert. Besitzen Produkte eine
solche Qualität sind sie "hedonisch" (siehe [6], [4];
vgl. auch [1]).
Gängige Prinzipien, Regeln und Methoden des usability engineerings bzw. der Software-Ergonomie
betonen meist einseitig Effektivität, Effizienz und
Zufriedenstellung im Sinne der Abwesenheit psychischer Belastung. Usability engineering ist in
Deutschland in den Arbeitswissenschaften verwurzelt. Es ging in diesem Bereich traditionell um die
Bedienung von Maschinen und später um die Gestaltung von Büroarbeitsplätzen. Leider spielen dabei
Qualitäten jenseits der Aufgabenerfüllung – Attraktivität und Freude bei der Nutzung – keine ausgeprägte Rolle.
Die Eingeschränktheit des klassischen Begriffs der
Gebrauchstauglichkeit scheint allerdings erkannt.
Unter dem Leitmotiv "New Horizons" wurde auf der
diesjährigen
"Computer–Human
Interaction"Konferenz (CHI) der "Association for Computing
Machinery" (ACM) besonders die Wichtigkeit von
Emotionen und Bedürfnissen, die über die eigentliche Manipulation der Umwelt hinausgehen, betont:
"As people become more sensitive to dimensions of
products that go beyond traditional aspects of usability, the need to understand and create emotional
and aesthetic resonance between people and technology
products
increases"
(http://www.chi2003.org/theme.html). Auch andere
Leitfiguren der usability professionals orientieren
sich neu (z.B. [9], [10]). So schrieb beispielsweise
Donald Norman in einem Beitrag für die InternetDiskussionliste
CHI-WEB@ACM.ORG
am
02.05.2002: "I'm starting a new career phase: Ugly is
out, beauty is in. [...] Usability? Yeah, that matters,
but beauty, pleasure, and fun – those are truly important. Yes, the product has to be balanced, yes, it
should provide value, fulfil the needs of the users,
and make good business sense. Sure, all of that. But
if it is unattractive, if it doesn't feel right, who cares if
it works? We need both pleasure and function.
135
Hassenzahl, M. & Hofvenschiöld, E.
Beauty and usability." Sogar der neue ISO-Standard
14915-1 "Software ergonomics for multimedia user
interfaces" erweitert die gängigen Dialogprinzipien
der DIN EN ISO 9241-10 um die Kriterien suitability
for explorati-on und suitability for engagment – beide
Prinzipien zielen auf die Motivation der Benutzer
und betonen damit auch "hedonische" Aspekte.
Der Begriff der usability (Gebrauchstauglichkeit) soll
also ergänzt oder erweitert werden. Einige Ansätze
dazu wurden bereits gemacht (z.B. [2], [3], [7], [8]),
allerdings ist man noch weit von einer gemeinsamen
Position entfernt. Die Gefahr scheint zwar erkannt,
aber noch lange nicht gebannt. Ziel des Workshops
soll es sein, einen Beitrag zur Entwicklung einer
gemeinsamen Agenda zur Erweiterung des usability
Begriffs leisten.
2. BEITRÄGE DES WORKSHOPS
Im folgenden werden die Inhalte der Beiträge zum
Workshop kurz zusammengefasst
Norbert Braun (Graphisch-Interaktive Systeme,
Technische Universität Darmstadt) entwirft eine
Zukunft der Interaktion, die sich über die Forderung
der Effizienz- und Effektivitätsoptimierung hinwegsetzt. Nicht jedes interaktive System muss mit minimalem Aufwand, maximalen Effekt erzielen. Im
Spaß und der Natürlichkeit der Interaktion sieht
Braun die Zukunft; und akteur- oder erzählerbasierte
Präsentation, virtuelle Charaktere, die mit Benutzern
interagieren, Multimodalität und Formen des Theaters, bei denen sich das Publikum aktiv beteiligen
kann, sind der Weg in diese Zukunft. Mit Hilfe des
Projektes GEIST, einem augmented reality Spektakel im und um das Heidelberger Schloss, werden
Ansätze und technische Lösungen vorgestellt.
Steffen Büffel (Medienwissenschaft, Universität
Trier) geht davon aus, dass durch die Allgegenwärtigkeit von Computern und dem Web, ihrer Verflechtung mit dem Alltag und der Tatsache, dass eine
zunehmende Palette menschlicher Bedürfnisse mit
dem Computer/Web befriedigt werden können, zu
einer "Emotionalisierung" der Schnittstelle zwischen
Mensch und Maschine führt. Seine These: Klassisches usability engineering wird dieser Veränderung
nicht gerecht. Am Beispiel des emotionalen Bedürfnisses nach Vertrauen im Kontext eines OnlineAktienangebots zeigt Büffel exemplarisch den Zusammenhang zwischen emotionalen Bedürfnissen
und software-ergonomischen Kriterien auf. Er plädiert für einen erweiterten integrativen Ansatz, der
emotionale und soziale Aspekte berücksichtigt.
Michael Hatscher (xApps Design Group, SAP) lenkt
die Aufmerksamkeit auf die zugrunde liegenden
Arbeitsaufgaben. Man kann alles tun, um ein Softwareprodukt so attraktiv wie möglich zu machen.
Allerdings ist das immer nur eine Voraussetzung für
Freude bei der Nutzung. Was Benutzer erleben,
hängt von einer Vielzahl zusätzlicher Faktoren ab,
wie eben der zugrunde liegenden Arbeitsaufgabe.
136
Die attraktivste Software kann nur bedingt Freude
erzeugen, wenn die abgebildeten Arbeitsaufgaben
langweilig, eintönig, nicht persönlichkeitsförderlich
sind. Er warnt vor der Gefahr des "Anhübschens"
von Benutzungsoberflächen – Freude setzt schon
bei den abgebildeten Arbeitsaufgaben an. Eine zu
starke Fokussierung auf die "Oberflächlichkeit des
Produkts" selbst, seine visuelle Gestaltung, ist so
problematisch, wie Zuckerguss auf einem übelschmeckenden Kuchen.
Anja Hoffman (digital storytelling, Zentrum für grafische Datenverarbeitung, Darmstadt) und Jan Köppen (freiberuflicher Interaktionsdesigner) beschäftigen sich mit Herausforderungen und Belohnungen in
Benutzungsoberflächen. Sie gehen dabei zunächst
von dem erwünschten Zustand des flows aus, einem
von Mihaly Csikszentmihaly geprägten Begriff für
den Zustand der Freude, dem Gefühl des "Einssein
mit dem Leben", des Entdeckens und des persönlichen Wachstums. Die Grundbedingungen für diesen
Zustand sind zum einen Herausforderungen, zum
anderen angemessene Fähigkeiten. Attraktive Softwareprodukte, so die These, schaffen es, die Balance zwischen Herausforderung und Fähigkeiten herzustellen. Mit Hilfe von Projektskizzen und Ideen
demonstrieren Hoffman und Köppen entsprechende
Gestaltungsansätze.
James Kalbach stellt emotive design vor, einen
Gestaltungsansatz, der explizit die emotionalen
Zustände der Benutzer berücksichtigt. Moderne
Forschung zeigt, das Kognition und Emotion nur
schwer zu trennen sind. Trotzdem sind Gestaltungsansätze für Informationssysteme im Web oft rein
kognitiv ausgerichtet: der Mensch wird als nutzenmaximierender Informationsverarbeiter verstanden;
emotionale Prozesse werden schlichtweg ignoriert.
Forschung im Bereich "Informationssuche" betont
allerdings die Allgegenwärtigkeit von Emotionen. Je
nach Phase (z.B., Erkennen eines Informationsbedürfnisses) herrschen andere Gefühle, Gedanken
und Handlungen vor. Im Rahmen der Informationssuche erlebt ein Benutzer die Gefühlszustände Besorgnis/Unsicherheit,
Optimismus,
Verwirrung/Zweifel,
Klarheit,
Zuversicht,
Erlösung/Zufriedenheit/Enttäuschung. An einem Beispiel
verdeutlich Kalbach, wie auf diese unterschiedlichen
emotionalen Zustände gestalterisch eingegangen
werden kann.
Steffen Klein und Lydia Wimmer (Research Communication and Interaction Design, DaimlerChrysler
AG) weisen auf die Unterschiede zwischen engineering und design hin. Engineering wird als eine problemgeleitete Herangehensweise verstanden, die sich
an notwendigen Kriterien orientiert. Design hingegen
eröffnet durch gestalterische Differenzierung, die
über das Notwendige hinausgeht, neue Spielräume
für persönliche Identifikation und kulturelle Aneignung. In diesem Zusammenhang weisen Klein und
Wimmer auf die Gefahr einer Verallgemeinerung
von Gestaltungszielen wie Spaß und Freude hin.
"If it doesn't feel right, who cares if it works?"
Um gestalterische Differenzierungspotenziale nicht
auf formale Ausdrucksmittel einzuschränken, sollte
eine hedonische Ausrichtung als Möglichkeit gestalterischer Differenzierung und nicht als notwendiges
Kriterium, verstanden werden.
Bettina Laugwitz (Zühlke Engineering GmbH) sieht
keinen Widerspruch zwischen traditioneller usability
und der geäußerten Forderung nach hedonischen
Aspekten, Freude, Emotionalität bei der Nutzung.
Die DIN EN ISO 9241-11, die das Qualitätsmerkmal
usability verbindlich definiert, versteht die Zufriedenstellung der Benutzer als eine Komponente von
usability. Versteht man Zufriedenheit weitgefasst als
"positive emotionale Reaktion", dann beinhaltet sie
schon die oben geforderte Erweiterung. Es ist dann
auch gerechtfertigt, bei der Gestaltung alle Aspekte
der Mensch-Maschine-Interaktion zu berücksichtigen, die in der Lage sind, positive Emotionen und
Einstellungen zu erzeugen. Am Beispiel einer Studie
über die Wirkung verschiedener, mehr oder weniger
ästhetischer Farbkombinationen auf die Benutzer
von Softwaresystemen diskutiert Laugwitz Farbgestaltung als ein Mittel zum Erzeugen positiver emotionaler Reaktionen.
Axel Platz (CT IC 7, Siemens AG) und Claus
Knapheide (Medical Solutions Health Services,
Siemens AG, USA) stellen die Benutzungsoberfläche des Computertomographen Somatom Smile
vor. Der Smile und die zugrunde liegende, von fast
allen medizintechnischen Produkten des Siemenskonzerns realisierte Gestaltsprache "Syngo" machen
deutlich, wie Ansprüche an die usability und die benutzungskontext-gerechte Anmutung eines Produkts
erfolgreich in Einklang gebracht werden können.
Ralph Tille, Stefanie Lauter und Ralph Bruder
(IED, Institut für Ergonomie und Designforschung,
Universität Duisburg-Essen) berichten über eine
"motivierende" Benutzungsoberfläche für ein Fahrerinformationssystem. Ziel ist – neben dem Bereitstellen von fahrtbezogenen Informationen – die emotionale Unterstützung der Fahrenden bei ihren ersten
Fahrten. An verschieden Gestaltungsbeispielen diskutieren die Autoren die Frage, wie man Fahrende
emotional erreichen und zugleich wichtiges technisches Wissen vermitteln kann.
Markus Weinländer (Automation and Drives, Siemens AG) macht kritisch auf einen essentiellen Unterschied zwischen Konsum- und Investitionsgüter
aufmerksam, den weder das traditionelle noch die
Entwürfe eines freude-zentrierten usability engineering berücksichtigen: Benutzer sind nicht die Käufer.
Sind Benutzer und Käufer nicht identisch, kann oft
nur schwer mit höherer Zufriedenheit oder sogar
Freude argumentiert werden. Einkäufer gehen nach
vermeintlich rationalen Kriterien vor: Usability muss
sich nach Weinländers Erfahrung in gesteigerter
Effizienz und Kostenersparnis ausdrücken, um als
wertvoll erachtet zu werden. Die Rolle des visuellen
Designs sieht Weinländer dementsprechend im überzeugenden Vermitteln dieser Effizienzbotschaft.
3. SCHLUSS
Die Beiträge des Workshops zeigen die Übereinstimmung der Teilnehmer dahingehend, dass am
Ende der Gestaltung ein Produkt steht, das über das
rein Notwendige hinausgeht. Freude, persönliches
Wachstum, neue Möglichkeiten und Emotionalität,
wie z.B. Vertrauen, sind erste Bezeichner für dieses
geforderte "Mehr." Bettina Laugwitz erinnert uns
daran, dass es hier um eine Erweiterung bestehender Konzepte und Methoden der usability und nicht
um eine radikale Negierung des bisher Erreichten
geht.
Die
Balance
zwischen
softwareergonomischen und "anderen" Anforderungen steht
im Vordergrund, so wie Hoffmann und Köppen die
Balance zwischen Herausforderungen und Fähigkeiten betonen. Klassische usability hat letzteres im
Auge, ein erweiterter Ansatz muss beides angemessen berücksichtigen. Dabei geht es nicht immer nur
um das Produkt alleine, sondern wie auch bei der
traditionellen Software-Ergonomie um die Aufgabe
– denn Softwaregestaltung ist immer auch Arbeitsgestaltung [5].
Neben theoretischen Überlegungen und empirischer
Forschung sind Projekte und Projektstudien eine
wichtige Quelle neuer Erkenntnisse. Durch das Lösen der zugrunde liegenden Gestaltungsprobleme
entstehen neue Sichten auf das eigentliche Problem. Diese können wieder in Theorie oder grundlegenderer Forschung zurückgeführt werden. Ein solcher research through design Ansatz bietet sich
besonders auf vorliegendem Gebiet an. Projekte wie
Norbert Brauns GEIST sind eine Spielwiese und
eine Quelle für das Erfinden und Erproben neuer
methodischer, technischer und theoretischer Ansätze. Projekte wie Axel Platz' und Claus Knapheides
Computertomograph zeigen, dass auch im Rahmen
von Investitionsgütern die Nachfrage nach usability
und dem "Mehr" besteht. Und bei aller Aufbruchsstimmung, die den Beiträgen dieses Workshops
anzumerken ist, ist es gut von Markus Weinländer
zur Vorsicht gemahnt zu werden. Wir dürfen zwei
Fragen nicht unbeantwortet lassen: Wo spielen neuen Gestaltungsziele – dieses "Mehr" – eine Rolle
und wie mache ich Sie Anderen plausibel.
4. KONTAKTE
Norbert Braun - norbert.braun@gris.informatik.tudarmstadt.de
Ralph Bruder - ralph.bruder@uni-essen.de
Steffen Bueffel - bueffel@uni-trier.de
Marc Hassenzahl - hassenzahl@psychologie.tudarmstadt.de
Michael Hatscher - michael.hatscher@sap.com
Anja Hoffmann - anja.hoffmann@zgdv.de
Elizabeth Hofvenschiöld - elizabeth.hofvenschiold@iao.fhg.de
James Kalbach - kalbach@scils.rutgers.edu
137
Hassenzahl, M. & Hofvenschiöld, E.
Steffen Klein - Steffen.Klein@daimlerchrysler.com
Claus Knapheide - claus.knapheide@siemens.com
Jan Köppen - contact@jankoeppen.de
Bettina Laugwitz - bettina.laugwitz@gmx.de
Stefanie Lauter - stefanie.lauter@uni-essen.de
Axel Platz - axel.platz@siemens.com
Ralph Tille - ralph_tille@gmx.net
Markus Weinlaender - markus.weinlaender@siemens.com
Lydia Wimmer - Lydia.Wimmer@daimlerchrysler.com
5. LITERATUR
[1] Batra, R. & Ahtola, O. T. (1990): Measuring the
hedonic and utilitarian sources of consumer
choi-ce. Marketing Letters, 2, 159-170.
[2] Djajadiningrat, J.P., Overbeeke, C.J. & Wensveen, S.A.G. (2000). Augmenting Fun and
Beauty: A Pamphlet. Proceedings of DARE
2000: Designing Augmented Reality Environments, 131-134. Helsingor, Denmark.
[3] Gaver, W.W. & Martin, H. (2000). Alternatives.
Exploring Information Appliances through Conceptual Design Proposals. Proceedings of the
CHI 2000 Conference on Human Factors in
Computing, 209-216.
138
[4] Burmester, M., Hassenzahl, M. & Koller, F.
(2002): Usability ist nicht alles – Wege zu attraktiven interaktiven Produkten. I-Com, 1(1), 32-40.
[5] Hacker, W. (1987). Software-Ergonomie: Gestalten rechnergestützter geistiger Arbeit?! In
W.Schönpflug & M. Wittstock (Hrsg.), SoftwareErgonomie '87: Nützen Informationssysteme
dem Benutzer? (31-54). Stuttgart: B.G. Teubner.
[6] Hassenzahl, M. (2003). The thing and I: understanding the relationship between user and
product. In M. Blythe, C. Overbeeke, A. F.
Monk, & P. C. Wright (Hrsg.), Funology: From
Usability to Enjoyment (31-42). Kluwer Academic Publishers.
[7] Hassenzahl, M., Burmester, M. & Beu, A.
(2001). Engineering Joy. IEEE Software, January/February, 70-76.
[8] Monk,A.F. & Frohlich,D. (1999). Computers and
Fun. Personal Technology, 3, 91.
[9] Nielsen,J. (2002). User Empowerment and the
Fun Factor. Jakob Nielsen's Alertbox,
http://www.useit.com/alertbox/20020707.html
[on-line].
[10] Norman,D.A. (2002). Emotion and attractive.
Interactions, July/August, 36-42.
"If it doesn't feel right, who cares if it works?"
Referenten
Marc Hassenzahl hat sein Studium der Psychologie mit Nebenfach Informatik an der
Technischen Universität Darmstadt 1998 abgeschlossen. Danach arbeitete er las als
"Usability Engineer" im Fachzentrum "User-Interface Design" der Siemens AG in München und als "Senior Usability Consultant" bei der User Interface Design GmbH in
München. Seit Oktober 2001 ist er als wissenschaftlicher Mitarbeiter am Institut für
Psychologie der Technischen Universität Darmstadt in den Bereichen Sozialpsychologie, Forschungsmethodik und Urteilen und Entscheiden tätig.
Er leitete und arbeitete in zahlreichen Projekten, die vom Planen und Durchführen von
Fokusgruppen zur Erhebung von Anforderungen an Computertomographen im chinesischen Markt über das Gestalten eines Hausautomatierungssystema bis zur Entwicklung eines Werkzeuges zur Messung der "Nutzungsqualität" interaktiver Produkte für
Nokia, Schweden reichen.
Seine Forschungsinteressen liegen im Bereich "Usability Engineering", attraktive
Software (hedonische Qualität, Spaß bei Umgang mit Computern, "Joy of Use") und
neue Analyse- und Evaluationsmethoden.
Seit 1997 hat er über 40 Artikel in anerkannten internationalen Fachzeitschriften,
Buchkapitel und Konferenzbeiträge publiziert. Er ist Mitglied im Vorstand des "German
Chapters der Usability Professionals Association".
Elizabeth Hofvenschiöld is a freelance HCI and interaction design consultant. She
currently works with the Fraunhofer IAO in Stuttgart on a range of projects. In 2001
she completed her Masters of Science in Human-Computer Interaction with Ergonomics at University College London, England.
Her main interests are in cultural issues, interaction design for mobile devices and
applications and developing the user experience for ubiquitous human-computer interaction. She has presented and published her work on these subjects as well as on
implementing a holistic approach to product development and evaluation through using a range of methods from different fields (e.g. marketing).
139
USER INTERFACE TUNING
USER INTERFACE TUNING - MIT BENUTZERN GESTALTEN
Joachim Machate
Teinacher Str. 38
D-71634 Ludwigsburg
joachim.machate@uidesign.de
www.uidesign.de
ABSTRACT
Die DIN EN ISO 13407 beschreibt einen iterativen
Produktentwicklungsprozess, in dem Benutzer eine
zentrale Rolle zur Sicherung der Nutzungsqualität
einnehmen. Wie dies in der Praxis umgesetzt werden kann und welche Methoden sich dabei bewährt
haben, wird unter dem Begriff „User Interface Tuning“ beschrieben. Die gleichnamige Session des
UPA-Tracks der Mensch und Computer 2003 stellt
exemplarisch Projektbeispiele aus der Praxis vor, die
sich diesen Ansatz zu Eigen gemacht haben.
Keywords
User Centred Design, User Interface Design, Benutzungsschnittstellen, benutzerzentriert gestalten, DIN
EN ISO 13407
1. EINLEITUNG
Der Begriff „User Interface Tuning“ legt nahe, dass
ein vorhandenes Etwas, das „User Interface“ oder
die Benutzungsschnittstelle, durch bestimmte Maßnahmen oder Eingriffe getunt werden kann. Tuning
bedeutet ja auch immer, ein Gerät so zu trimmen,
dass es in bestimmten Leistungseigenschaften mehr
oder weniger deutlich über den Standard hinaus
wächst. Im Hinblick auf die Entwicklung interaktiver
Produkte wollen wir mit „User Interface Tuning“ Methoden und Maßnahmen bezeichnen, die dafür geeignet sind, Benutzungsschnittstellen interaktiver
Produkte so zu entwickeln, dass sie ein hohes Maß
an Nutzungsqualität erreichen.
Produkte, deren Nutzen sich erst durch einen hohen
Grad an Interaktion erschließt, haben sich längst bis
in den letzten Winkel unseres Alltags ausgebreitet
[2]. Der Umgang mit Menüs und computerunterstützten Dialogen beschränkt sich nicht mehr nur auf
herkömmliche Computer, sondern ist allgegenwärtig.
Stuttgart).
Proceedings of the
Michael Burmester
Fachhochschule Stuttgart - Hochschule der Medien
Wolframstr. 32
D-70191 Stuttgart
burmester@hdm-stuttgart.de
Umso wichtiger ist es für einen nachhaltigen Produkterfolg, dass ihre Interaktions- und Navigationskonzepte so gestaltet sind, dass eine hohe Nutzungsqualität erzielt wird. Hohe Nutzungsqualität
bedeutet, dass ein Produkt optimal zu seinen zukünftigen Nutzern passt, dass es unterstützt, was
diese mit dem Produkt machen wollen, wie sie dies
gerne tun möchten und wo das der Fall sein soll.
Wenn all dieses Wissen in den Produktgestaltungsprozess einfließt, kann sichergestellt werden, dass
das Produkt eine hohe Nutzungsqualität erreicht und
somit für einen nachhaltigen Erfolg sorgt. Ein solches Vorgehen wird als benutzerzentrierte Produktgestaltung bezeichnet und ist in der Norm DIN EN
ISO 13407 (2000) beschrieben [3]. Um aber Begeisterung an einem Produkt zu erreichen, reicht eine
hohe Nutzungsqualität allein nicht aus. Erst wenn
eine Benutzungsschnittstelle auch als attraktiv angesehen wird und positive Emotionen beim Benutzer
hervorruft, wird der Umgang mit einem interaktiven
Produkt als attraktiv wahrgenommen. So müssen
bei der Entwicklung von Produkten beide Aspekte die „Nutzungsqualität“ und die so genannte hedonische Qualität - berücksichtigt werden [4]. Dies zu
erzielen, ist Gegenstand des „User Interface Tunings“.
2. DIE PRAXIS
Eine zentrale Komponente benutzerzentrierten Gestaltens ist, dass der Benutzer mit seinen Zielen,
Aufgaben, Bedürfnissen, sozialen Kontexten, Nutzungsumgebungen und Verhaltensweisen als Maßstab für Gestaltungsentscheidungen gesehen und in
den Gestaltungsprozess einbezogen wird.
Leider wird diese Forderung in der Praxis häufig
fehlinterpretiert und führt daher nicht selten zu einer
voreiligen Ablehnung eines solchen Vorgehens.
Als gängige Fehl-Interpretationen finden sich oft
folgende Deutungen [1]:
•
„Alle Macht den Benutzern“
•
„Denk wie ein Benutzer“
•
„Ich bin selbst ein Benutzer“
•
„Benutzer sind Versuchskaninchen“
Die genannten Fehl-Deutungen benutzerzentrierten
Gestaltens ignorieren das tatsächliche Potenzial des
Prozesses und werden entweder als Argument ge143
Machate, J. & Burmester, M.
gen ein solches Vorgehen vorgebracht oder sie werden als Vorwand genutzt, sich lediglich am Rande
mit realen Benutzern auseinandersetzen zu müssen.
Benutzerzentriertes Gestalten hat zum Ziel, dass
Informationen über Benutzer in der Zusammenarbeit
mit den Benutzern selbst gesammelt werden. Das
bedeutet, dass Benutzer nicht nur am Ende ein Ergebnis testen, auf das sie keinen Einfluss hatten,
sondern dass Benutzer in jeder Phase des Gestaltungsprozesses eines Produktes spezifische Beiträge leisten.
Der Benutzer ist von allen Beteiligten der größte
Experte für seinen Fachbereich, und er liefert damit
zentrale Basisinformationen. Entscheidungen auf
der Grundlage dieser Informationen obliegen aber
grundsätzlich dem Gestaltungsteam. Neben Vertretern des Produktmanagements, der SoftwareEntwicklung, des Usability Engineerings, des Marketings, der Grafik und anderen gehören natürlich auch
zukünftige Benutzer zu diesem Team.
Das Einbeziehen des Benutzers kann auf vielfältige
Weise stattfinden. Beispielsweise können Benutzer
am Arbeitsplatz befragt oder beobachtet werden.
Benutzer können in Diskussionsgruppen Anforderungen und Ideen für neue Produkte liefern. Sie
können an Gestaltungsworkshops teilnehmen und
die fachlich korrekte Umsetzung von Anforderungen
beurteilen. Sie können in Usability-Tests zur Beurteilung von Prototypen in verschiedenen Stadien der
Entwicklung beitragen, und vieles mehr.
Um Missverständnissen vorzubeugen, sei aber
nochmals betont: Benutzer sind Experten für Ziele
und Aufgaben. Sie sind keine Experten für das Gestalten: „users are not designers“ [8].
Die Mitwirkung von Benutzern in den Gestaltungsphasen ist unter der Moderation von UsabilityFachleuten aber sehr sinnvoll. Gestaltungsvorschläge von Benutzern erbringen wichtige Basisinformationen und Anregungen für die Gestaltung. Bei jedem
Gestaltungsvorschlag ist es jedoch von äußerster
Wichtigkeit zu verstehen, welche Anforderungen
hinter diesem Gestaltungsvorschlag stehen. Das
Gestaltungsteam muss seine Gestaltungsentscheidungen immer vor dem Hintergrund der Benutzeranforderungen treffen.
Benutzer liefern Informationen, Anforderungen und
Gestaltungsideen, Gestaltungsentscheidungen werden durch Gestaltungsteams getroffen.
3. METHODEN
Hat sich ein Unternehmen dafür entschieden, benutzerzentrierte Methoden bei der Produktgestaltung
einzusetzen, stellt sich häufig die Frage, wie dies am
Besten verwirklicht werden kann. Dabei stehen folgende Fragestellungen im Raum:
•
„Wie lässt sich benutzerzentriertes Gestalten in
existierende Softwareentwicklungsprozesse des
Unternehmens einbinden?“
144
•
„Wie lässt sich Methodenkompetenz im Unternehmen verankern?“
•
„Wie ist das Kosten-Nutzen-Verhältnis im Vergleich zu herkömmlichen Methoden?“
Bei der Einbindung benutzerzentrierter Vorgehensmodelle in bestehende Softwareentwicklungsprozesse stellt sich oftmals heraus, dass gerade in großen
Unternehmen der Softwareentwicklungsprozess in
allen Phasen sehr genau festgelegt ist, siehe z.B.
Rational Unified Process [6] und für die darin enthaltenen Phasen Rollen, Methoden und Artefakte genauestens beschrieben und hierfür benötigte Werkzeuge bereitgestellt werden. Der Benutzer erscheint
zwar in der Regel als Rollenkonzept und wird auch
besonders in der Analysephase in die Entwicklung
eingebunden, im Fokus stehen aber hierbei häufig
die Modellierung von Geschäftsprozessen und Arbeitsabläufen aus Sicht des Systems, also eher die
Frage, was der Benutzer mit dem System tun soll.
Wie er die Aufgaben erledigen will und wie dazu ein
optimales Nutzungskonzept entwickelt werden kann,
gerät dagegen öfter in den Hintergrund. Eine konsequente, auf den Benutzer zentrierte Vorgehensweise, die sich am Unified Process orientiert, bietet der
User Centred Design Process der IBM [5]. In der
Praxis, insbesondere bei kleinern oder mittleren
Softwareentwicklungsprojekten, erweisen sich allerdings beide Prozessmodelle als zu aufwendig und
schwer handhabbar. Von daher sollte bereits in der
Projektplanungsphase genau überlegt werden, welche Ziele in Bezug auf die Nutzungsqualität erreicht
werden sollen und welche Methoden dazu im Rahmen des Kostenplans eingesetzt werden können.
Einen kleinen Überblick über benutzerzentrierte
Methoden, die sich gerade auch im Einsatz bei kleineren Projekten bewährt haben, bietet Tabelle 1.
Phase
Methoden
Analyse
Kontextsitzung, Kontextbefragung,
Fokusgruppen
Gestaltung
Szenarios, Gestaltungsworkshops
Prototyping
Low-Fidelity und High-Fidelity Prototypen
Evaluation
Usability-Tests, Pluralistischer Usability-Walkthrough, Heuristische
Expertenevaluation, Fragebögen
Tabelle 1: Bewährte Methoden der benutzerzentrierten
Gestaltung
Hinsichtlich der Methodenkompetenz bzw. deren
Verankerung im Unternehmen steht als wichtige
Frage sicherlich im Vordergrund, wie häufig und mit
welcher Bandbreite Benutzungsschnittstellen im
Unternehmen entwickelt werden. Davon abhängig
entscheidet sich, ob die zentrale Verantwortung für
die Sicherung der Nutzungsqualität aller Produkte
einem „User Experience Manager“ obliegt, der für
die jeweiligen Projekte den Einsatz der Methoden
und Ressourcen koordiniert, oder ob dies jeweils neu
für einzelne Projekte festgelegt wird. Je nach ProUsability Professionals 2003
User Interface Tuning – mit Benutzern gestalten
jekterfordernissen und eigener Lage der Ressourcen
und des Know-Hows ist hier häufig die Einbindung
von qualifizierten externen Dienstleistern notwendig.
Damit dies auch nach einem allgemein anerkannten
Verständnis in der Vorgehensweise und hinsichtlich
der Durchführungs- und Ergebnisqualität geschehen
kann, haben sich in Deutschland Usability-Fachleute
in einem eigenen Berufsverband, der Usability Professionals Association zusammengeschlossen [9].
Hier findet auch ein reger Austausch über das Kosten-Nutzen-Verhältnis, Effizienz und Trade-Offs der
eingesetzten Methoden in Bezug auf die industrielle
Praxis statt.
5. REFERENZEN
4. USER INTERFACE TUNING
[4] Hassenzahl, M., Attraktive Software – Was Gestalter von Computerspielen lernen können. In:
J. Machate & M. Burmester (Hrsg.), User Interface Tuning, Benutzungsschnittstellen menschlich gestalten, Software & Support Verlag
(2003).
Eine zentrale Konsequenz aus den vorangegangenen Überlegungen und unserer Praxiserfahrung ist,
dass benutzerzentrierte Produktentwicklung immer
auf die Bedürfnisse der aktuellen Projektsituation
angepasst werden muss und kein starres Vorgehensmodell zugrunde gelegt werden darf. So wie in
der Nutzungskontextanalyse für ein Produkt das
Produktumfeld, die Nutzer und die Aufgaben analysiert werden sollten, sollte vor Projektbeginn das
Umfeld für den Einsatz benutzerzentrierter Entwicklungsmethoden analysiert werden und die in Frage
kommenden Methoden ausgewählt und entsprechend adaptiert werden. Solch ein flexibles Anpassen der Methoden auf die Projektbedürfnisse beschreiben die Praxisbeispiele aus „User Interface
Tuning“ [7]. Als wichtigster Leitfaden hierbei gilt:
„Frage Deine Benutzer“ und ermögliche dies in jeder
Produktentwicklungsphase.
[1] Burmester, M. und Görner, C., Das Wesen benutzerzentrierten Gestaltens. In: J. Machate &
M. Burmester (Hrsg.), User Interface Tuning,
Benutzungsschnittstellen menschlich gestalten,
Software & Support Verlag (2003).
[2] Cooper, A., The Inmates Are Running the Asylum, Why High Tech Products Drive Us Crazy
and How To Restore The Sanity, Pearson Professional Education (1999).
[3] DIN EN ISO 13407, Benutzer-orientierte Gestaltung interaktiver Systeme, Beuth Verlag (2000).
[5] IBM Ease of Use, What is User-Centered Design? www-3.ibm.com/ibm/easy/eou_ext.nsf/
EasyPrint/2.
[6] Kruchten, P., The Rational Unified Process – An
Introduction, Second Edition, Addison Wesley
Longman (2000).
[7] Machate, J. und Burmester, M. (Hrsg.), User
Interface Tuning, Benutzungsschnittstellen
menschlich gestalten, Software & Support Verlag (2003).
[8] Nielsen, J., Usability Engineering, Morgan
Kaufmann (1993).
[9] Usability Professionals' Association: German
Chapter.
www.uni-kl.de/pak/upa-germanchapter/
145
Machate, J. & Burmester, M.
Referenten
Joachim Machate studierte Informatik mit Schwerpunkt Mensch-MaschineKommunikation an der Universität Stuttgart. Seine Dissertation über die Nutzung der
Intonation in Dialogen mit sprachverstehenden Systemen erarbeitete er am Wissenschaftlichen Zentrum der IBM Deutschland Informationssysteme GmbH. Seit mehr als
15 Jahren ist er als Usability Consultant und Projektleiter im Bereich MenschComputer-Interaktion tätig. Seine berufliche Laufbahn begann am Fraunhofer Institut
für Arbeitswirtschaft und Organisation (IAO), an dem er 1998 die Leitung des Marktstrategieteams „Interaktive Produkte“ übernahm. Im Jahr 2000 wechselte er als Mitglied des Management Boards und Leiter Softwareentwicklung zur User Interface Design GmbH (UID). Als Key Account Manager IT & Enterprise Solutions ist er bei der
UID zuständig für die Betreuung von Kunden aus dem Finanzdienstleistungsbereich
und Unternehmenssoftware. Neben seiner Tätigkeit als Usability Consultant ist er zudem als Autor und Lehrbeauftragter aktiv. Ein besonderer inhaltlicher Schwerpunkt
seiner Arbeit richtet sich auf die Entwicklung von IT-basierten Verbrauchsgütern und
multimodalen Systemen.
Gemeinsam mit Michael Burmester ist er Herausgeber des Buches
„User Interface Tuning, Benutzungsschnittstellen menschlich gestalten“, dem die in
dieser Session vorgestellten Praxisbeispiele als Auszug entnommen sind.
Michael Burmester studierte Psychologie an der süddeutschen Universität Regensburg. Er begann seine Karriere als Forscher am Fraunhofer Institut für Arbeitswirtschaft
und Organisation (IAO) in Stuttgart. 1997 wechselte er zu Siemens Corporate Technology – User Interface Design als Usability Consultant und Forscher des Bereichs Usability Engineering. Ab März 2000 leitete er das Münchner Büro ebenso wie den Bereich
Usability Engineering der User Interface Design GmbH, eines beratenden Softwareund Usability-Unternehmens. Seit September 2002 vertritt Michael Burmester die Professur für Ergonomie und Usability im Studiengang Informationsdesign an der Hochschule der Medien in Stuttgart. Parallel dazu betreut er den Bereich Research & Innovation bei der User Interface Design GmbH. Neben der Arbeit als Usability Consultant
war Herr Burmester in mehreren nationalen und europäischen Forschungsprojekten als
Projektmanager beteiligt.
Seine Forschungsinteressen liegen in der Weiterentwicklung des Usability Engineerings in Richtung auf eine umfassende Gestaltungsdisziplin, die die Mensch-TechnikInteraktion zu einem für den Menschen positiven Erlebnis macht.
146
SICHERHEIT FÄNGT BEIM BENUTZER AN –
BENUTZERZENTRIERTER GESTALTUNGSPROZESS
FÜR SAM JUPITER
Johannes Schwagereit
Beta Systems Software AG
Josef-Lammerting-Allee 14
50933 Köln
johannes.schwagereit@betasystems.com
www.betasystems.com
Axel Kern
Beta Systems Software AG
Josef-Lammerting-Allee 14
50933 Köln
axel.kern@betasystems.com
www.betasystems.com
ABSTRACT
Die Verwaltung von Benutzern und deren Zugriffsrechten ist nur so sicher wie die Administratoren im
Umgang mit den Applikationen sind. SAM Jupiter ist
eine übergreifende Administrationsplattform für verschiedene IT-Systeme. Die grafische Benutzungsoberfläche für SAM wurde mit Hilfe eines benutzerzentrierten Gestaltungsansatzes entwickelt, der u.a.
drei internationale Usability-Tests mit Prototypen
bzw. frühen Versionen beinhaltete. Besonders berücksichtigt wurde dabei die Möglichkeit, die grafische Benutzungsoberfläche an die Bedürfnisse unterschiedlicher Unternehmen anzupassen. Bei der
Weiterentwicklung von SAM Jupiter ist die benutzerzentrierte Vorgehensweise inzwischen fest etabliert.
Keywords
Benutzerzentrierte Softwareentwicklung, UsabilityTests.
1. EINLEITUNG
SAM Jupiter ist eine Applikation zur Verwaltung von
Usern und Zugriffsrechten in heterogenen ITUmgebungen. Es stellt eine übergreifende Administrationsplattform über die vorhandenen Sicherheitssysteme verschiedener IT-Systeme (Betriebssysteme, wie Windows NT/2000, UNIX, z/OS, Datenbanken, wie LDAP, DB2 und Oracle, sowie Anwendungen, wie beispielsweise SAP R/3) dar. So kann mit
Hilfe von Vorlagen (sogenannten Roles) ein Benutzer (User) zentral über SAM Jupiter eingerichtet
werden. Die weiteren Schritte zum Einrichten der
Stuttgart).
Proceedings of the
Andreas Beu
Lehrer-Götz-Weg 11
81825 München
www.uidesign.de
entsprechenden Benutzer und Berechtigungen in
den einzelnen Zielsystemen werden dann von SAM
Jupiter automatisch übernommen. Weiterhin können
mit dem Zusatzmodul „SAM Jupiter Workflow“ organisatorische Abläufe zum Einrichten, Prüfen und
Freigeben von Benutzern und Berechtigungen abgebildet werden.
Anwender von SAM Jupiter sind mittlere und große
Unternehmen aller Branchen. Dort ist die Administration der Benutzer und deren Zugriffsrechte ein
äußerst anspruchsvolles und vor allem sicherheitskritisches Thema. Viele Unternehmen sind hochgradig von einer funktionierenden IT-Infrastruktur abhängig, diese ist Voraussetzung für die Arbeitsfähigkeit ganzer Unternehmensbereiche. Entsprechend
hoch sind auch die Anforderungen an SAM Jupiter.
Doch was nützen die ausgefeiltesten Funktionen von
SAM Jupiter, wenn die Administratoren damit nicht
sicher und zuverlässig umgehen können? "Sicherheit fängt beim Benutzer an": dies war der Anspruch,
als Anfang 2000 mit der Gestaltung der grafischen
Benutzungsoberfläche (Graphical User Interface
GUI) von SAM Jupiter begonnen wurde [1].
2. VORGEHENSWEISE
Um den hohen Erwartungen an eine sichere und
effiziente Bedienung gerecht zu werden, wurde ein
benutzerzentrierter Gestaltungsansatz gewählt, bei
dem der Benutzer und seine Anforderungen im Mittelpunkt stehen [2], [4]. Wesentliches Merkmal der
Vorgehensweise war die Entwicklung ausführlicher
Prototypen und die Durchführung mehrerer empirischer Untersuchungen (Usability-Tests).
Die drei internationalen Usability-Tests für SAM
Jupiter und SAM Jupiter Workflow mit Benutzern
aus Italien, Norwegen, Großbritannien, Deutschland
und den USA waren auch entscheidende Meilensteine bei der Entwicklung der GUI. Zahlreiche Gestaltungsdetails und Optimierungen des SAM User Interfaces beruhen auf bewussten Entscheidungen,
die systematisch und gestützt auf empirische Daten
herbeigeführt wurden.
147
Schwagereit, J., Kern, A. & Beu, A.
Abbildung 1 Darstellung eines Antrags zum Einrichten von Zugangsberechtigungen für einen Benutzer im
Zusatzmodul „SAM Jupiter Workflow“. Der Antrag wird auf einem virtuellen Klemmbrett dargestellt, welches
verschiedenen Stellen zur Prüfung und Genehmigung „vorgelegt“ wird.
Ergänzend wurden auch bestimmte Fragestellungen
im Rahmen dieser Tests ausführlich durchleuchtet,
beispielsweise die Individualisierbarkeit der GUI.
Diese erfolgt weniger aufgrund persönlicher Vorlieben, sondern mehr aus betrieblichen Notwendigkeiten, d.h. SAM Jupiter muss an organisatorische
Randbedingungen des jeweiligen Unternehmens
angepasst werden können. So muss es problemlos
möglich sein, Feldern ein anderes Label zu geben,
die Auswahl der angezeigten Daten zu ändern oder
eine neue Sprache für die Oberfläche zu definieren.
Aber auch komplexere Anpassungen, wie kundenspezifische Wertebereiche für bestimmte Felder,
müssen einfach realisierbar sein. Weiterhin wird
SAM Jupiter von sehr unterschiedlichen Endbenutzern zu verschiedenen Zwecken genutzt: vom
Frontoffice-Bankangestellten bis zum DV-Experten.
D.h. die Endbenutzer haben teilweise sehr unterschiedliche Aufgaben und verfügen über ganz unterschiedliche Vorerfahrungen, so dass eine Adaption
der GUI für verschiedene Benutzergruppen und
Aufgaben erforderlich war. Aus diesem Grund war
bei der Konzeption der GUI die leichte Anpassbarkeit immer ein wichtiges Thema.
148
Da mit einigen Lösungen Neuland betreten wurde,
waren frühzeitige Rückmeldungen, ob diese Lösungen auch in der Praxis funktionieren würden, dringend erforderlich. Eventuelle Fehlentwicklungen
mussten rechtzeitig erkannt und beseitigt werden.
Die Usability-Tests lieferten hier wertvolle Daten und
Hinweise zu Verbesserungspotentialen.
3. DISKUSSION UND AUSBLICK
Die benutzerzentrierte Gestaltung ist inzwischen bei
allen Weiterentwicklungen von SAM Jupiter fest
etabliert, sie hat eine hohe Akzeptanz bei den Software-Entwicklern
und
der
Projektleitung.
Änderungen und Erweiterungen in SAM Jupiter
werden daher ausgehend von der GUI gestaltet. In
der Designphase wird jeweils zunächst beschrieben,
wie sich das Aussehen und das Verhalten der neuen
Funktionalität
in
der
darstellen. Die Lösungen werden dann mit
Endbenutzern diskutiert. Erst wenn für die GUI eine
zufriedenstellende Lösung gefunden wurde, werden
die
notwendigen
Anpassungen
in
den
Datenstrukturen und der SW-Architektur entwickelt
und definiert.
Sicherheit fängt beim Benutzer an – benutzerzentrierter Gestaltungsprozess für SAM Jupiter
Nach Abschluss der Implementierung gehören
neben Tests der Funktionalität auch UsabilityÜberprüfungen zum festen Testprogramm der
Qualitätssicherung.
Alle Usability-Aktivitäten werden vorab im
Projektplan eingeplant und mit ausreichend Zeit und
Kapazität
berücksichtigt.
Dadurch
kann
sichergestellt werden, dass das hohe UsabilityNiveau von SAM Jupiter, welches in vorangegangen
Usability-Tests bescheinigt wurde, erhalten bleibt.
4. REFERENZEN
[1] Beu. A, Kern, A. & Schwagereit, J., Das User
Interface ist wunderschön... – der benutzerzent-
rierte Gestaltungsprozess nach ISO 13407 in der
Praxis, Java Magazin, 5.2002, 28-35, 2002.
[2] Burmester, M., Hassenzahl, M. & Machate, J.,
Benutzerzentriert - ja, aber wie? ISO13407:
Empfehlungen für einen benutzerzentrierten
Entwicklungsprozess, Java Magazin, 11.2000,
53-57, 2000.
149
Schwagereit, J., Kern, A. & Beu, A.
Referenten
Johannes Schwagereit war nach dem Studium der Informatik an der Universität Kaiserslautern seit 1992 als Software-Entwickler bei der Kubus Software GmbH in Meckenheim angestellt. Er entwickelte dort für eine Anwendung der Druckereibranche u.a. das
Datenmodell und die Benutzungsschnittstelle.
Seit 1996 ist Johannes Schwagereit bei der Beta Systems Software AG in Köln (früher
Systor Security Solutions GmbH bzw. Schumann AG) beschäftigt. Er arbeitet dort als
Software-Ingenieur in der Entwicklung von "SAM Jupiter", eines Administrationstools zur
Verwaltung von Benutzern und Zugriffsrechten in heterogenen IT-Umgebungen. Insbesondere gehören das Design und die Entwicklung einer neuen GUI zu seinen Aufgaben.
Zu den Interessenschwerpunkten von Johannes Schwagereit zählen intuitiv verständliche
Benutzungsoberflächen, die Datenbankmodellierung und Methoden der künstlichen Intelligenz.
Axel Kern war nach dem Studium der Elektrotechnik als wissenschaftlicher Mitarbeiter
am Institut für Datenverarbeitungsanlagen der Technischen Universität Braunschweig
beschäftigt. Er arbeitete dort im Rahmen des Verbundprojektes SUPRENUM, in dem
unter Beteiligung von Industrie, Großforschungseinrichtungen und Universitäten ein Superrechner für die Bearbeitung numerischer Anwendungen entwickelt wurde. 1993 promovierte er hier über "Entwurf, Bewertung und Optimierung eines Kommunikationssystems für Parallelrechner".
Axel Kern arbeitet seit 1993 bei der Beta Systems Software AG in Köln (früher der Systor
Security Solutions GmbH bzw. Schumann AG) in der Entwicklung von SAM, einem Administrationstools zur Verwaltung von Benutzern und Zugriffsrechten in heterogenen ITUmgebungen. Zur Zeit ist er Projektleiter der Entwicklung von SAM Jupiter, der neuen
Generation von SAM.
Seine Interessenschwerpunkte sind Software-Entwicklungsmethoden, das Design von
User Interfaces sowie Computer Security, hier insbesondere der Bereich Access Control.
Andreas Beu ist Senior Usability Consultant und Manager Industry Solutions bei der
User Interface Design GmbH in München. Im Rahmen dieser Tätigkeit berät er Unternehmen aus dem industriellen Umfeld bei der benutzergerechten Gestaltung von Software Produkten und interaktiven Dienstleistungen. Anfang 2003 übernahm er zusätzlich
die Leitung der UID Geschäftsstelle in München. Andreas Beu ist Vize-Präsident des
German Chapters of the UPA e.V.
150
GESTALTUNG TOUCHSCREEN-BASIERTER
MASCHINENSTEUERUNGEN BEI TRUMPF
Klaus Bauer
TRUMPF Werkzeugmaschinen GmbH+ Co. KG
Johann-Maus-Straße 2
71254 Ditzingen
klaus.bauer@de.trumpf.com
www.trumpf.com
ABSTRACT
Anhand von zwei Pilotprojekten wurde eine neue
Generation von touchscreen-basierten Maschinensteuerungen für den Werkzeugmaschinenhersteller
TRUMPF entwickelt. Ziel war es u.a. eine besonders
intuitiv bedienbare Benutzungsoberfläche zu schaffen, die für verschiedene Anwender individualisierbar
sein sollte. Der benutzerzentrierte Gestaltungsprozess beinhaltete Nutzungskontextanalyse, Gestaltungsworkshops und Usability-Tests mit Prototypen,
wobei jeweils potenzielle Endbenutzer einbezogen
wurden. Da Interaktionskonzepte und Gestaltungsvorgaben für alle künftigen TRUMPF Steuerungen
anwendbar sein sollen, wurden die Ergebnisse der
einzelnen Pilotprojekte abgeglichen. Im TRUMPF
Styleguide sind grundlegende und bindende Gestaltungsvorgaben für zukünftige Entwicklungen festgehalten. Bei den inzwischen gestarteten Folgeprojekten zeigt sich eine deutliche Reduzierung der
Aufwände durch den Styleguide.
Keywords
Maschinensteuerung, Styleguide, User-centred design, Touchscreen
1. EINLEITUNG
Die TRUMPF Gruppe gehört zu den weltweit führenden Unternehmen in der Fertigungstechnik. Innovationen von TRUMPF bestimmen die Richtung
bei Werkzeugmaschinen für die Blech- und Materialbearbeitung, in der Lasertechnik, Elektronik oder
Medizintechnik. Sie prägen technische Standards
und eröffnen den Anwendern neue und produktivere
Möglichkeiten.
Die Entwicklung neuer Verfahren und leistungsfähiEs ist erlaubt digitale und Kopien in Papierform des ganzen Papers
Stuttgart).
Proceedings of the
Andreas Beu
Lehrer-Götz-Weg 11
81825 München
www.uidesign.de
ger Maschinen, die rasche Umsetzung von technischen Gedanken in anwenderorientierte Innovationen, hohe Qualitätsansprüche und zuverlässige
Betreuung der Kunden kennzeichnen TRUMPF.
Mit der neuen Generation von touchscreen-basierten
Bedienoberflächen soll dieser Anspruch unterstrichen werden. Entwicklungsziel war und ist die einheitliche Gestaltung der Bedienoberfläche für
TRUMPF Maschinen aller Technologien (z.B. zum
Stanzen, Nibbeln und Umformen, für die Laserbearbeitung, für die kombinierte Bearbeitung, für das
Biegen ...)
Dabei werden folgende Zielsetzungen verfolgt:
•
Entwicklung einer besonders intuitiv bedienbaren Bedienungsoberfläche, die den Umstieg zwischen den unterschiedlichen Maschinentechnologien erleichtert,
•
Abbildung von typischen Arbeitsabläufen,
•
Erzielen eines Alleinstellungsmerkmals gegenüber Wettbewerbern,
•
Kundenbindung durch eine besonders intuitive
und attraktive Benutzungsoberfläche,
•
Optimale Touchscreen-Bedienung,
•
Möglichkeit der Individualisierbarkeit der Benutzungsoberfläche für verschiedene Anwender,
•
Reduzierung des Schulungsaufwands durch
intuitives Bedienkonzept.
Die einfache Bedienbarkeit der Maschinen mit einer
attraktiv gestalteten Bedienungsoberfläche ist die
Visitenkarte innovativer TRUMPF Produkte.
2. VORGEHENSWEISE
Das Interaktionskonzept und visuelle Design für die
zukünftigen touchscreen-basierten Bedienungsoberflächen von TRUMPF-Maschinen wurde anhand
folgender Pilotprojekte entwickelt:
•
TRUMPF TrumaTube B10
•
TRUMPF TrumaBend
Die Pilotprojekte wurden in Anlehnung an den benutzerzentrierten Gestaltungsprozess nach ISO
13407 durchgeführt [2], [4]. Ziel der Pilotprojekte war
151
Bauer, K. & Beu, A.
auch die Ableitung eines TRUMPF Styleguides für
touchscreen-basierte Maschinenbedienoberflächen.
Der Styleguide definiert Dialogbausteine und Bedienelemente und enthält konsistente Layout- und
Interaktionsvorgaben. Der Styleguide berücksichtigt
die Vorgaben etablierter Normen und Gestaltungsrichtlinien der ISO 9241 und der VDI-Norm zur nutzergerechten Gestaltung von Bediensystemen für
Maschinen basieren [1], [6].
zelnen Pilotprojekten zu (vgl. Abbildung 1). Immerhin
sollten Interaktionskonzepte und Gestaltungsvorgaben entwickelt werden, die für alle zukünftigen
TRUMPF Maschinen gelten. Die Harmonisierung der
Gestaltungsideen wurde durch folgende Maßnahmen gewährleistet:
2.1 Nutzungskontextanalyse
Gestartet wurden die Pilotprojekte mit einer Nutzungskontextanalyse, die in Form einer Kontextsitzung [4] gemeinsam mit Endanwendern, Mitarbeitern des Vertriebs und Produktmanagern durchgeführt wurde. Ergebnisse waren Profile der verschiedenen Benutzergruppen, die Beschreibung der wichtigsten Tätigkeiten, sowie die Darstellung der Nutzungsumgebung.
2.2 Gestaltungsworkshops mit Visualisierung
Es folgte eine Reihe von Gestaltungsworkshops.
Hierbei wurden für die wichtigsten Arbeitsabläufe
entsprechende Gestaltungsentwürfe entwickelt und
diskutiert. Bei den Gestaltungsworkshops waren
ebenfalls Endbenutzer beteiligt. Die Gestaltungsentwürfe wurden unmittelbar visualisiert, indem die
Skizzen aus den Workshops von den Designern der
User Interface Design GmbH (UID) grafisch ausgearbeitet wurden. Die ausgearbeiteten Entwürfe wurden so in einem Präsentationsprogramm eingebunden, dass ein „Rundgang“ durch das neue Design
möglich was. Auf diese Art und Weise konnten die
Gestaltungsentwürfe beim nächsten Workshop sofort diskutiert und bewertet werden.
2.3 Usability-Testing
Anhand der Gestaltungsentwürfe wurde eine interaktive Bedienungsattrappe (Wegwerf-Prototyp) erstellt.
Der Prototyp schaffte die Voraussetzung zur Durchführung eines Usability-Tests. Dazu wurden potenzielle Endbenutzer eingeladen, anhand von realistischen Aufgabenstellungen den Prototypen und damit die darin enthaltenen Gestaltungsideen zu bewerten. Die Aufgabenstellungen orientierten sich an
den wichtigsten Tätigkeiten, die im Rahmen der
Nutzungskontextanalyse erhoben wurden. Als Teilnehmer wurden in erster Linie Maschineneinrichter
eingeladen. Diese wurde bei der Nutzungskontextanalyse als die wichtigste Benutzergruppe identifiziert, da sie den größten Anteil an Interaktionen mit
der Steuerung haben, nahezu alle Tätigkeiten abdecken und auch bei der Kaufentscheidung für eine
Maschine eine wichtige Rolle einnehmen. Die Ergebnisse der Usability-Tests flossen in die abschließende Phase des Feindesigns.
2.4 Abgleich zwischen den Pilotprojekten
Eine wichtige Rolle bei der konsistenten Gestaltung
der touchsreen-basierten TRUMPF Bedienoberfläche kam dem Abgleich der Ergebnisse aus den ein-
152
Abbildung 1: Dialog „Biegeteil laden“ für Abkantpresse TRUMPF TrumaBend (oben) und Rohrbiegemaschine TRUMPF TrumaTube B10 (unten)
Parallele Durchführung der Gestaltungsworkshops aus allen Pilotprojekten
Die Gestaltungsworkshops der Pilotprojekte wurden
parallel durchgeführt. Dabei wurden die Inhalte der
Workshops auf einander abgestimmt. Gestaltungsideen für Problemstellungen, die alle Pilotprojekte
betrafen, wurden zuerst innerhalb eines Gestaltungsworkshops eines Projektes entwickelt. Die resultierenden Gestaltungsideen wurden dann den
anderen Projekten vorgestellt, dort diskutiert und
ggf. angepasst bzw. ergänzt. So wurden die maßgeblichen Ideen für die Service- und Wartungskomponente zuerst für die Lasersteuerung WinLas gestaltet und anschließend für die Maschinen adaptiert.
Die viel beachteten Korrekturen-Dialoge waren eine
Gestaltungsidee, die zuerst für die TRUMPF TrumaTube B10 entwickelt wurde und später auf die
Abkantpressen übertragen wurden. Die Dialoge für
die Zusammenstellung von Teilelisten waren hingegen eine Idee, die von der Abkantpresse stammte.
Teilnahme von Experten aus anderen
Technologie-Bereichen an den Gestaltungsworkshops
Die Teilnahme von Experten aus anderen Technologie-Bereichen von TRUMPF während der Gestaltungsworkshops sicherte außerdem schon während
der Ideengenerierung eine kontinuierliche Abstimmung. Diese Experten konnten Einfluss auf die Gestaltung nehmen, indem sie beispielsweise auf eigene
Bedürfnisse bzw. auf etablierte Gestaltungslösungen
aus ihrem Bereich aufmerksam machten oder an der
Bewertung einzelner Gestaltungsideen teilnahmen.
Dadurch wurde zugleich erreicht, dass die im Rahmen der Pilotprojekte entwickelten Gestaltungslösungen bereits sehr früh innerhalb von TRUMPF
bekannt und allgemein akzeptiert wurden.
Einrichtung eines Styleguide-Teams
Das Styleguide-Team hatte vor allem die Aufgabe,
aus den Gestaltungslösungen die Dialogbausteine
und Bedienelemente zu extrahieren und diese einheitlich zu definieren. Dabei wurden in gemeinsamen Workshops mit Software-Entwicklern aus verschiedenen TRUMPF Bereichen Layout, Interaktionsverhalten, aber auch Implementierungsdetails
diskutiert, und festgelegt. Damit hatte das Styleguide-Team wesentlichen Anteil an der einheitlichen
Gestaltung zukünftiger TRUMPF Maschinensteuerung. Resultat dieser Workshops ist der TRUMPF
Styleguide.
Abbildung 3: Grundsätzliches Layout der Hauptfenster für zukünftige TRUMPF Maschinensteuerungen
Die hieraus resultierenden Gestaltungsvorgaben
sind für die betroffenen Bereiche der TRUMPF
Gruppe bindend. Die Vorgaben lassen genügend
Spielraum, um auf deren Grundlage touchscreenbasierte Benutzungsoberflächen für unterschiedliche
TRUMPF Produkte zu entwickeln sowie auf die Anforderungen unterschiedlicher Technologien zu reagieren. Die Gestaltungsvorgaben sind so konkret wie
möglich und so flexibel wie nötig anwendbar.
Beschrieben werden das grundsätzliche Interaktionskonzept und Layout (vgl. Abbildung 3), wichtige
Interaktionsmechanismen für Touch- und Tastaturbedienung, sowie alle Bedienelemente und Dialogbausteine.
Die Beschreibung der Dialogbausteine und Bedienelemente erfolgte durch
Abbildung 2: Beispiel für die Bemaßung eines Context Buttons im TRUMPF Styleguide
3. DER TRUMPF STYLEGUIDE
Der TRUMPF Styleguide beinhaltet die grundlegenden und bindenden Gestaltungsvorgaben touchscreenbasierter
Benutzungsoberflächen
für
TRUMPF Werkzeugmaschinen. Er unterstützt Softwareentwickler, Projektmanager und Designer bei
der Entwicklung konsistenter und technologieübergreifender Interaktionskonzepte.
•
Definition des Verwendungszwecks
•
Darstellung der visuellen Gestaltung (Visuelle
Gestaltung, Fokus, Bemaßung) (vgl. Abbildung 2)
•
Festlegung des Interaktionsverhaltens (Allgemein, Touch-Bedienung, Mausbedienung, Tastatur-Bedienung)
4. ZUSAMMENFASSUNG &
SCHLUSSFOLGERUNG
Inzwischen wurden bei TRUMPF bereits mehrere
Folgeprojekte gestartet, welche die Gestaltung weiterer Bedienoberflächen für verschiedene Anwendungen zum Ziel haben (z.B. für CO2-LaserSteuerung, Stanz- und Laserbearbeitung, ScannerSchweißen, Metall-Laser-Schmelzen). Im Rahmen
dieser Projekte hat sich sehr schnell gezeigt, welchen Vorteil der TRUMPF Styleguide für die Entwicklung der Benutzungsoberflächen hat. Die Zeiten
und Aufwände für die Konzeption der Interaktion und
der grafischen Gestaltung konnten erheblich reduziert werden. Eine wesentliche Erleichterung war das
vorgegebene Grundlayout für die Hauptfenster der
153
Bauer, K. & Beu, A.
Maschinensteuerung (vgl. Abbildung 3). Dieses
Grundlayout konnte für nahezu alle Bedienoberflächen herangezogen und angepasst werden. Ebenso
konnten viele Dialoge, die ursprünglich für einen
bestimmten Maschinentyp entwickelt wurden, adaptiert und wieder verwendet werden. Die Dialogbausteine und Bedienelemente wurden teilweise als
Klassenbibliotheken für die wichtigsten TRUMPFEntwicklungsumgebungen implementiert und zur
Verfügung gestellt. Dadurch werden einerseits Entwicklungskosten gespart, andererseits wird durch die
Vorgabe der Bedienelemente sichergestellt, dass die
Benutzungsoberfläche optimal am Touchscreen
bedienbar ist.
Gleichzeitig integrieren sich die neuen Benutzungsoberflächen besser in die TRUMPF Landschaft. Sie
vermitteln den Kunden ein einheitliches Bild und
schaffen dadurch Vertrauen in die Marke TRUMPF
(vgl. auch Abbildung 4).
5. REFERENZEN
[1] DIN EN ISO 9241, Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten,
Beuth Verlag (1997-2002).
[3] Görner C., Dialog building blocks - A useful
means to improve compliance to international
user interface standards. Proceedings of the
ICAE'96. Istambul (1996).
[5] Thomas, C. & Bevan, N., Usability Context
Analysis - A Practical Guide, Version 4.04,
www.usability.serco.com/trump/documents/
UCA_V4.04.doc. (1996),
überprüft am 25.05.2003.
Abbildung 4: Dialog zum Teachen eines Kreises mit
drei Punkten im Raum (TRUMPF Scanner Schweißen)
154
[6] VDI-Richtlinie, VDI/VDE 3850, Blatt 1 – 3,
Nutzergerechte Gestaltung von Bediensystemen
für Maschinen, VDI Verlag (2000-2002).
Referenten
Klaus Bauer war nach seinem Studium der Technischen Informatik als SoftwareEntwickler bei der TRUMPF GmbH+Co. KG in der Steuerungsentwicklung tätig. Er war
dort für Steuerungssimulationssystemen und -tests zuständig, später für die Einführung
moderner Software-Architekturen und optimierter Software-Entwicklungsprozesse.
1997 wechselte er im Hause TRUMPF in das Kompetenzfeld Systementwicklung MMI,
mit dessen Leitung er seit 1998 beauftragt ist. Zu seinen Verantwortungsgebieten gehört
die Entwicklung moderner, attraktiver und tätigkeitsorientierter grafischer Benutzungsoberflächen für Stanz-, Laser- und Kombimaschinen. Seit 2002 leitet er ein internationales Projektteam zur Entwicklung eines technologieübergreifenden Bedienkonzeptes und
eines firmenweiten einheitlichen User-Interface-Styleguides für das komplette Maschinenspektrum bei TRUMPF.
Andreas Beu ist Senior Usability Consultant und Manager Industry Solutions bei der
User Interface Design GmbH in München. Im Rahmen dieser Tätigkeit berät er Unternehmen aus dem industriellen Umfeld bei der benutzergerechten Gestaltung von Software Produkten und interaktiven Dienstleistungen. Anfang 2003 übernahm er zusätzlich
die Leitung der UID Geschäftsstelle in München. Andreas Beu ist Vize-Präsident des
German Chapters of the UPA e.V.
155
WEBSITE-EVOLUTION
- WAS DER BESUCHER WIRKLICH BRAUCHT Jens Uwe Parkitny
Expedia.com GmbH
Landshuter Allee 10
D-80637 München
jensuwep@expedia.com
www.expedia.de
ABSTRACT
Der Artikel zeigt am Beispiel des Online-Reisebüros
Expedia.de, wie die Internet-Dienstleistung mit Hilfe
von Usability-Maßnahmen über mehrere Jahre situationsgerecht, erfolgskontrolliert und wirtschaftlich
weiterentwickelt werden konnte.
Keywords
Web-Usability, Online-Reisebüro, Usability-Testing,
benutzerzentrierter
Gestaltungsprozess,
user
centred design process.
1. EINLEITUNG
In der Zusammenarbeit mit Internet-Dienstleistern
taucht regelmäßig die Frage auf: Was liest der Benutzer wirklich, was überliest er und warum?
Die Gestaltung der Inhalte pendelt zwischen dem
Wunsch übersichtlich zu bleiben und der Angst, die
entscheidende Information wegzulassen, die den
Benutzer hätte „fesseln“ können.
Während Kleingedrucktes in herkömmlichen Verträgen auf Papier sehr oft ignoriert wird, zeigte sich bei
Usability-Tests gerade der umgekehrte Effekt: Wichtige Informationen, die vermeintlich gut sichtbar
dargestellt sind, werden überlesen, während Informationen, die sehr klein geschrieben sind, im Internet eher Misstrauen wecken und daher besonders
gründlich studiert wurden.
Die mess- und nachweisbaren Erfolge des OnlineReisebüros Expedia.de zeigen, wie man sich mit
benutzerzentrierten Maßnahmen aus solchen Unsicherheiten befreien kann. Expedia sieht in der Qualität der Benutzungsoberfläche die wichtigste Komponente, mit der das Vertrauen und die Akzeptanz
Claus Görner
Teinacher Str. 38
D-71634 Ludwigsburg
claus.goerner@uidesign.de
www.uidesign.de
durch die Kunden hergestellt und gesichert werden
kann.
Benutzerzentriertes Bewerten und Gestalten stehen
daher bei jedem neuen Release der Website im
Fokus. Allerdings wird Usability auch nicht zum
Selbstzweck betrieben. Nur Anpassungen, die
nachweislich zu Verbesserungen für Benutzer und
Vertrieb führen, werden umgesetzt.
2. ONLINE-REISEBÜRO
Expedia Inc. gilt heute als das weltweit größte Online-Reisebüro und weist rund zwölf Millionen Seitenabrufe pro Monat alleine in Deutschland auf.
Im Oktober 1996 startete Expedia.com in den USA
und erhielt bis heute zahlreiche Auszeichnungen und
Preise für Nutzerfreundlichkeit, Funktionalität und
Design. Ähnliche Erfolge verzeichnen Expedia-Sites
in Kanada, Groß-Britannien, Belgien, Deutschland,
Italien, Frankreich und den Niederlanden. Die deutsche Version der Reisewebsite Expedia ging im
September 1999 live (www.expedia.de).
Das Geschäftsmodell entspricht heute einem Mix
aus dem eines herkömmlichen Reisebüros und eines Reiseveranstalters, also Verkauf und Vermittlung von Produkten aus den Bereichen Reise und
Touristik.
Der Expedia-Besucher kann in Deutschland je nach
Saison bis zu 200.000 Reisen, Flüge von 500 Fluglinien und ca. 65.000 Hotels online abfragen.
Die Zahl der „Unique Users“ in Deutschland (Nutzer,
die nur einmal gezählt werden, selbst wenn sie innerhalb eines Monats öfters die Site benutzen), liegt
bei etwa. 1,2 Millionen. Die Conversion Rate (Besucher/Käufer) und die Zahl der Neukunden entwickeln
sich stetig wachsend.
Stuttgart).
Proceedings of the
156
Website-Evolution - Was der Besucher wirklich braucht -
3. WEBSITE-EVOLUTION
Abbildung 1: Im Vergleich von oben nach unten
Erste Site (USA, 1996), Sites Deutschland 1999, 2002 und 2003
157
Parkitny, J. U. & Görner, C.
3.1 Expedia.com 1996; Erste Site (USA)
Hauptmerkmale
• Geprägt von redaktionellen Themen, Reportagen und Reise-News
• Ein einziger Link zu verkaufsrelevanten Features auf der Startseite (Reisebüro).
Wirkung
• Bekanntheit und Besucherzahlen zufrieden stellend, Verkaufszahlen zunächst hinter den Erwartungen zurück.
Usability-Strategie
• Befragungen von Expedia-Interessenten in USA
Erkenntnis
• Redaktionelle Inhalte sind keine Voraussetzung
für den Verkauf
Konsequenz
• Informatorische Inhalte werden durch leistungsfähige Buchungsmodule ersetzt, die z.B. erlauben, den Fensterplatz im Flugzeug automatisch
zu reservieren
3.2 Expedia.de 1999; erste deutsche Site
Hauptmerkmale
Zahlreiche Links für Buchungsaktivitäten und Anlage
persönlicher Reiseprofile
•
•
•
Kopf und Hauptnavigationsleiste
Dreispaltiger Arbeitsbereich
Komplexere Interaktionen für den Benutzer
Wirkung
Verkaufszahlen bleiben auch in Deutschland zunächst hinter den Erwartungen zurück.
Usability-Strategie
Benutzerbefragung, und Beobachtung von Benutzern, die einen beliebigen Flug buchen.
Ziel einer besseren Einschätzung über Art der Nachfrage und der Kundenbedürfnisse
Im Vordergrund steht die funktionale Ausgestaltung,
noch nicht so stark die Bedienbarkeit.
Subjektive Empfindungen von Benutzern haben zu
diesem Zeitpunkt größere Bedeutung als die gezielte Beobachtung von ausgewählten Bedienabläufen.
•
•
•
•
Wie wird die Site generell empfunden?
Werden die wichtigsten Elemente und Funktionen erkannt und verstanden?
Was gefällt, was stößt auf Ablehnung?
Was hält vom Kauf ab?
Erkenntnis
• Unsicherheiten der Besucher bestehen bezüglich Verbindlichkeit der Buchung, der Produkthaftung, der Art der Bezahlung und dem Datenschutz
• Vorrangig erwartet werden: niedrige Preise,
hohe Performance (schneller Seitenaufbau und
158
•
sehr gute Reaktionszeiten) sowie multimedial
aufbereitete Hintergrundinformationen rund ums
Reisen, die Spaß machen und unterhalten sollen.
Der Registrierungszwang bereits vor einer
Suchabfrage und wiederholte Datenabfragen
werden als großes Hindernis gesehen.
Konsequenz
• Erweiterung und Änderung der Funktionalität
• Änderung des grafischen Erscheinungsbildes,
um die Attraktivität zu steigern
• Abspecken der Informationsfülle auf der Einstiegsseite
3.3 Expedia.de März 2000
Hauptmerkmale
• neues Grafik-Design, Einführung von Karteikarten
• Mehr Abrechnungsmöglichkeiten und optimierte
Buchungspfade
• Situationsgerechte Informationen, z.B. Registrierung nur als Option
Wirkung
• Gesteigerter Appeal
• Kauf auf Rechnung sehr gut angenommen,
• steigende Flugbuchungen und steigende Zahl
von Wiederholungskäufen
Usability-Strategie
Wettbewerbsanalyse: Welche Sites von Wettbewerbern kennen und besuchen die Benutzer? Wie
schneidet Expedia im Vergleich ab?
Funktionale Klärung: Bedarf an Auktionen und
„Community“-Foren, Suchkriterien
Erkenntnis
• Noch zu viele, als unwichtig eingestufte Inhalte
auf der Einstiegsseite.
• Inhalte der Spalte C werden komplett ignoriert
• Terminologieunklarheiten, z.B. Reisephasen
„Herbstferien“ und „Weihnachtsferien“
• Navigationsleiste mit zwei Reihen von Reiterkarten bewährte sich nicht.
Konsequenz
• Guidelines für Übersetzer
• Entfernung redundanter Webelemente wie Links
und Icons
3.4 Expedia.de September 2002
Hauptmerkmale
Die Komplexität der Benutzungsoberfläche ist immer mehr gewachsen und durch die gestiegene
Anzahl von integrierten Fremdapplikationen schleichen sich Inkonsistenzen in der Benutzungsoberfläche ein.
Website-Evolution - Was der Besucher wirklich braucht -
Wirkung
Unübersichtlicher, inkonsistenter, sinkende Bedienbarkeit, nach wie vor sehr gutes Produktangebot
Usability-Strategie
Bisherigen Studien hatten große Anteil marktforschungs-orientierter Themen. Sie legten somit naturgemäß auch viel Wert auf die Befragung der
Testteilnehmer.
Jetzt rückt die Bedienbarkeit der Website in ihrer
Gesamtheit stark in den Vordergrund. Die Untersuchung wird sehr detailliert.
In dieser Studie waren drei Buchungsaufgaben vollständig durchzuführen, bei denen die Benutzer intensiv beobachtet wurden. Jede Situation, in der
eine Bedienungshürde zu beobachten war, wurde
detailliert protokolliert und analysiert. Befragt wurden
die Tester erst im Anschluss an die Bearbeitung.
Hilfestellungen gab es keine, denn die Benutzer
sollten zunächst alles Notwendige selbst herausfinden. Während der ganzen Sitzung waren die Benutzer angehalten „laut zu denken“ und alle Erwartungen oder Überraschungen mitzuteilen. Unmittelbar
nach jeder Aufgabe wurden die Testpersonen gebeten, bestimmte Aspekte der Website in einer 5Punkte-Ratingskala einzustufen. Im Anschluss an
die Beobachtungsphase beantworteten die Testpersonen einen standardisierten Fragebogen, mit dem
die subjektive Einschätzung bezüglich Usability und
hedonischen Qualitäten der Website gemessen wurde.
Erkenntnis
Die Ergebnisse der Untersuchung machten deutlich,
wie wichtig die direkte Beobachtung für eine sinnvolle Gewichtung der subjektiven Aussagen der Benutzer ist:
•
•
•
Befragt nach der Qualität der Website, waren
viele Benutzer voll des Lobes. Dabei spielten
vor allem Angebotsinhalte eine Rolle, wie die
„sehr umfangreiche Reise-Auswahl“ oder die Informationsgenauigkeit, die z.T. “detaillierter als
erwartet“ war.
In der Auswertung des standardisierten Fragebogens wurde die Beurteilung bereits differenzierter: sowohl die pragmatische Qualität als
auch die hedonische Qualität wurden als eher
durchschnittlich eingestuft. Das bedeutet, dass
noch viel Raum für Verbesserungen vorhanden
war.
Die Beobachtung selbst brachte die Erkenntnis,
dass der Einstieg und das Suchen von Reiseangeboten ganz gut bewältigt werden (und darauf
hatten sich bisherige Arbeiten ja auch vorwiegend konzentriert). Sobald es aber einen Schritt
tiefer, von der Angebotssuche in die Auswahl
und Kaufentscheidung ging, tauchten noch viele
Ungereimtheiten und Ungenauigkeiten auf.
Konsequenz
In den bisherigen Versionen wurde vor allem die
Einstiegsseite optimiert und immer wieder verfeinert.
Bereits auf den nachfolgenden Seiten war die Gestaltung sehr stark von den verschiedenen Buchungssystemen (Flug, Städtereise, „Last Minute“)
geprägt und führte zu sehr unterschiedlichen Erscheinungsbildern.
Expedia entkoppelte daher zahlreiche Seiten der
Website wieder von den Buchungssystemen, so
dass bis zu einer gewissen Ebene nur noch die reinen Reisedaten geladen werden und diese in eigene, konsistent und attraktiv gestaltete Seiten eingebunden werden.
3.5 Expedia.de Januar 2003
Hauptmerkmale
Inhaltliche reduzierte, aber konsistente Benutzungsoberfläche
Wirkung
Sehr klar, ansprechend, einfach zu bedienen.
Usability-Strategie
Die neue Version wurde einem verkürzten Usability
Test mit wenigen Benutzern unterzogen und es wurde ein vergleichender Online-Feldtest durchgeführt.
Die bisherige Version bekamen nur noch 50% der
Besucher zu sehen, die anderen 50% erhielten bereits die neu gestaltete Version.
Erkenntnis
Der Usability Test zeigte deutliche Steigerungen der
hedonischen und pragmatischen Qualität. Benutzer
gaben durchweg sehr positives Feedback.
Nach 3 Wochen A/B-Testphase zeigte sich, dass die
neue Website signifikant weniger Abbrüche zu verzeichnen hat, als die Vorversion.
Das Branchenmagazin Touristik R.E.P.O.R.T untersucht für die Ausgabe 10/03 fünf große InternetReisebüros mit dem Fokus Gestaltung/Layout, Inhalt/Reiseinformation,
Angebotssuche/Buchung
sowie Interaktionsdesign/Dialog.
Die Begründung für den Testsieger Expedia.de bestätigt den großen Qualitätssprung im Vergleich zu
Mitbewerbern: "Bei Expedia dreht sich alles um den
Kunden. Der detaillierte persönliche Bereich, die
individuellen Beratungsmöglichkeiten, nützliche
Reiseinformationen und nicht zuletzt der einfache
Such- und Buchungsprozess - all dies macht die
Reisebuchung für Expedia-Kunden kinderleicht.“
Konsequenz
Funktionale Erweiterungen und weitere kontinuierliche Usability Checks mit Zielsetzungen und Fragestellungen, die auf die aktuelle Situation zugeschnitten werden.
159
Parkitny, J. U. & Görner, C.
Referenten
Jens Uwe Parkitny, Manager Product & Business Development, Expedia.com GmbH, ist
gelernter Verlagskaufmann und Diplombetriebswirt. Nach einem abgeschlossenen Volontariat arbeitete er als Redakteur für die Fachzeitung Touristik Aktuell und von 1995 bis
1997 als Auslandskorrespondent für in- und ausländische Medien, darunter Travel Asia,
in Singapur.
Für Expedia arbeitet er seit Anfang an, zunächst drei Jahre als Senior Producer bei
Microsoft in der Travel Business Unit und seit dem Börsengang 1999 für die Expedia, Inc.
Claus Görner ist seit 1998 Geschäftsführer der User Interface Design GmbH, und leitet
ein Team von renommierten Usability Experten, die kontinuierlich software-ergonomische
Methoden und Vorgehensweisen weiterentwickeln und in vielen Praxisprojekten anwenden. Er ist Autor von Artikeln und Büchern zur Software-Ergonomie, ISO 9241 und der
Bildschirmarbeitsplatz-Verordnung.
160
INTERAKTIVES FERNSEHEN ERLEBEN
Andreas Weiss
Programmdirektion Erstes Deutsches Fernsehen
Arnulfstr. 42
D-80335 München
andreas.weiss@daserste.de
www.daserste.de
ABSTRACT
Das Wohnzimmer wird vom Fernseher und seinen
Randbedingungen geprägt: Hohe Videoqualität, eher
passive Mediennutzung, sehr unterschiedliche
Nutzergruppen und eine einfache Fernbedienung zur
Nutzung der Medien. Interaktive Anwendungen für
den Fernseher werden anders als am PC genutzt
und wahrgenommen. Bei der Konzeption und
Entwicklung von interaktiven Anwendungen spielt
das Prototyping eine wesentliche Rolle.
Keywords
Digital TV; enhanced TV; interaktive Produkte;
Prototyping; benutzerzentrierte Softwareentwicklung.
1. EINLEITUNG
Der Fernseher ist ein bedeutender Teil unserer
Gesellschaft geworden und hat wie keine andere
technische Errungenschaft dieses Jahrhunderts in
fast allen Bereichen des privaten und öffentlichen
Lebens gravierende Veränderungen bewirkt. Die
Fernsehgewohnheiten werden sich weiter ändern
und neue Herausforderungen an die technische
Ausstattung der Geräte und Sender, an die
Produzenten und Fernsehschaffenden und nicht
zuletzt an den Konsumenten stellen.
Digitales Fernsehen ermöglicht faszinierende und
interaktive Formen der elektronischen Kommunikation. Allerdings können sich interaktive Dienste
nur durchsetzen, wenn sie einfach zu benutzen sind.
Insbesondere können Konzepte für grafische
Oberflächen, wie man sie von Computern kennt,
nicht einfach auf den Fernseher übertragen werden.
TV-Bedienkonzepte müssen berücksichtigen, dass
die Benutzer teilweise keinerlei Erfahrung mit
Computern haben und sie den Komfort erwarten,
den sie vom Fernsehen gewohnt sind: eine
Franz Koller
Teinacher Str. 38
D-71634 Ludwigsburg
franz.koller@uidesign.de
www.uidesign.de
Fernbedienung, mit der sie bequem vom Sessel aus
den Fernseher bedienen können. „Lazy Interactivity“
nennen Spötter das Konzept, sämtliche Funktionen
über nur wenige Tasten der Fernbedienung zu
steuern.
Ein zweiter wichtiger Aspekt ist die enge
Einbeziehung und Überzeugung der beteiligten
Redaktionen. Ihr Augenmerk gilt nicht so sehr der
technischen Innovation, sondern den inhaltlichen
Verbesserungen ihrer Programme, der Stärkung der
Zuschauerbindung und der Erweiterung der
demographischen Reichweite. Im Zentrum steht
nach wie vor das Fernseherlebnis, das heißt die
vorwiegend passive Rezeption von Programmen in
entspannter Haltung („Lean-Back-Position“). Diesem
werden mit Hilfe digitaler Software-Applikationen
und interaktiver Kommunikation personalisierte
Inhalte „beigemischt“. Dadurch kann der Zuschauer
bei Unterhaltungsprogrammen selbst mitspielen und
gewinnen; Informationssendungen bieten nun
persönliche
Informationen
und
WerbeEinschaltungen gehen auf persönliche Vorlieben ein.
Seit 1999 werden in dieser Weise angereicherte
Fernsehsendungen („enhanced TV“) regelmäßig
ausgestrahlt. Den Anfang machte die ARD mit der
interaktiven
Version
der
Unterhaltungsshow
„Verstehen Sie Spaß?“. Ihr folgten bald das
Ratespiel zur Krimiserie „Tatort“ und die interaktive
Begleitung der Fußball-Europameisterschaft 2000.
Stuttgart).
Proceedings of the
Abbildung 1: Screenshot aus “Verstehen Sie Spaß?”
mit enhanced TV Anwendung
161
Weiß, A. & Koller, F.
2. DER WEG ZU ERFOLGREICHEN
INTERAKTIVEN TV-FORMATEN
Abhängigkeit von der aktuellen Szene verändert
werden können.
Für Design und Realisierung interaktiver Systeme
eignet sich ein iterativer Entwicklungsansatz. Das
benutzerzentrierte Vorgehensmodell [1],[2] gibt
hierbei die wesentlichen Rahmenbedingungen vor.
Zunächst geht es vor allem darum, Eigenschaften
und Fähigkeiten des Nutzers, seine Aufgaben und
Ziele und seine Umgebung zu verstehen, um ein
Format entwickeln zu können, das seine Bedürfnisse
optimal unterstützt und richtig Spaß macht. Nutzer
werden herangezogen, um die A0nforderungen an
das System zu definieren. Welche Funktionen sollen
überhaupt verfügbar sein, welche Schnittstellen zu
anderen Nutzern oder Systemen benötigt werden
und welche Unterstützung soll der Nutzer
bekommen [3].
Um die Ideen und Anforderungen in interaktive
Konzepte umzusetzen, ist es wichtig neben der
Zielgruppe auch die technischen Randbedingungen
des interaktiven Fernsehens, die wesentlichen
Einfluss auf die zu realisierende Konzepte haben, zu
berücksichtigen
[4],
[5].
Den
deutlichen
Unterschieden zwischen PC und TV muss bei der
Gestaltung und Umsetzung von interaktiven
Anwendungen Rechnung getragen werden.
Abbildung 2: Screen eines interaktiven Powerpoint
Prototypen für eine Fußball-Wettanwendung
Wichtig ist, dass die genannten Besonderheiten bei
der Gestaltung von Konzepten für das interaktive
Fernsehen
zusätzlich
zu
den
klassischen
Anforderungen der Ergonomie (wie Konsistenz,
Erwartungskonformität, etc.), berücksichtigt werden,
sowie
Konzepte
für
frühzeitig
visualisiert
und
auch
auf
den
Zielplattformen getestet werden.
3. PROTOTYPING
Die Entwicklung interaktiver Konzeptionen verläuft
in aller Regel anders als die klassische Programmentwicklung im Fernsehen. Dies liegt in erster Linie
an einem Vermittlungsproblem: wer immer eine Idee
für ein interaktives Programmelement in die
Diskussion einführt, sieht sich als technischer Laie
einerseits der Unsicherheit ausgesetzt, ob die Idee
tatsächlich umsetzbar ist; andererseits führt die
(noch) geringe Erfahrung der Redaktionskollegen
mit
interaktiven
Anwendungen zur
Gefahr
unerkannter Missverständnisse, die erst dann
offenbar werden, wenn bereits erhebliche Ausgaben
für die Softwareentwicklung getätigt worden sind.
Zur Beherrschung dieses Dilemmas hat sich die
Methode des Prototyping als früher Schritt zur
Visualisierung von neuen Konzepten bewährt. Mit
Hilfe einfach bedienbarer Autorentools (Director,
Flash, Powerpoint) werden Ideen auch ohne Einsatz
teurer Software-Entwicklungen auf dem Computer
vorab visualisiert und Abläufe interaktiv erfahrbar
gemacht. Teilweise müssen die Prototypen mit dem
Video synchronisiert sein, so dass Interaktionen in
162
Abbildung 3: Screen eines interaktiven Prototyps für
“Christiansen interaktiv”
Die Anschaulichkeit der Darstellung vermeidet, dass
unterschiedliche Vorstellungen über das interaktive
Programmelement entstehen. Weiterhin leistet es
gute Dienste bei der Ermittlung der Machbarkeit. Die
frühzeitige interdisziplinäre Einbeziehung aller
betroffenen Stellen ist bei der Klärung typischer
Fragen unerlässlich. Hier eine Auswahl:
•
Stimmt
die
Interaktivität?
•
Gefällt den Nutzern das Konzept und verstehen
sie die Interaktion und das zugrunde liegende
Konzept?
•
Sind die ins Auge gefassten Funktionen
technisch umsetzbar? Können sie auf allen
gewünschten Plattformen (Kabel, Satellit,
Terrestrik) wiedergegeben werden? Wie viele
Zuschauer bleiben von der Interaktivität
ausgeschlossen?
inhaltliche
Konzeption
der
Interaktives Fernsehen erleben
•
Wie viel Übertragungsbandbreite erfordert die
Applikation – und steht diese zum Zeitpunkt der
Ausstrahlung zur Verfügung?
•
Erfordert die Anwendung – etwa bei Wetten und
Ratespielen – eine präzise Synchronisation mit
dem Videodatenstrom? Wie wird diese
implementiert?
•
Ist für die geplante Interaktivität ein Rückkanal
erforderlich?
Müssen
Punktestände,
Wetteingaben, Abstimmungen u.ä. erfasst,
ausgewertet
und
an
die
Zuschauer
zurückgemeldet werden? Auf welche Weise und
in welchen Zeiträumen geschieht dies?
tauglicher Endgeräte gelingt und zugleich das
Volumen attraktiver interaktiver Angebote wächst.
Während sich die ersten interaktiven Programme
stark
an
traditionellen
Nutzergewohnheiten
orientieren, werden die Applikationen der folgenden
Format-Generationen zunehmend auch „jüngere“
Kommunikationsformen (SMS, E-Mail, Internet,
neue Dienste) aufgreifen und damit den lange
erwarteten Konvergenz-Prozess einleiten.
Interaktive Fernsehprogrammformate werden dann
parallel für unterschiedliche Plattformen entwickelt.
Aktuelle „Content Management Systeme“ gestatten
bereits heute die medienadäquate Anpassung von
Inhalten an unterschiedliche Endgeräte. Eine große
Herausforderung trifft dabei die ProgrammVerantwortlichen
bei
der
Umstellung
ihrer
Produktionen auf eine integrierte, interdisziplinäre
und vernetzte Arbeitsweise.
5. REFERENZEN
[1] DIN EN ISO 13407, Benutzer-orientierte
Gestaltung interaktiver Systeme, Beuth Verlag
(2000).
menschlich gestalten, Software & Support
Verlag (2003).
Abbildung 4: Interaktiver Prototyp für „Pilawa“, mit
simulierter Fernbedienung und synchronisiertem
Video (siehe auch http://www.cutty-media.de)
4. AUSBLICK
Während interaktives Fernsehen besonders in
Großbritannien wohl seinen Siegeszug fortsetzen
wird, fallen Prognosen für Europa und insbesondere
für Deutschland schwer. Das Kunden-Potenzial für
interaktive Dienste scheint nach ersten Erfahrungen
zwar überall vorhanden zu sein. Seine Erschließung
hängt aber entscheidend davon ab, ob eine
hinreichende
Marktdurchdringung
multimedia-
[3] Mayhew, D., The Usability Engineering Lifecycle,
Morgan Kaufmann Publishers, Inc. (1999).
[4] Nielsen, J., TV Meets the Web,
www.useit.com/alertbox/9702b.html, (1997),
überprüft am: 10.03.2003.
[5] Weiss, A. und Koller, F., Interactive TV,
In: J. Machate & M. Burmester (Hrsg.), User
menschlich gestalten, Software & Support
Verlag (2003).
163
Weiß, A. & Koller, F.
Referenten
Andreas Weiß, Volljurist, war lange Jahre Fernsehredakteur beim Bayerischen
Rundfunk. Nach Stationen im Wirtschaftsressort (PlusMinus, Ratgeber Geld), beim
Politmagazin 'Report' und in der Auslandsberichterstattung zog Andreas Weiß 1986 als
ARD-Fernsehkorrespondent für die Türkei und Iran nach Istanbul. Nach seiner Rückkehr
zum BR im Jahr 1991 lag der Schwerpunkt seiner Tätigkeit in der Entwicklung neuer
Programmformate. Auch engagierte er sich in der Multimedia-Entwicklung. Als
Vorsitzender der Arbeitsgruppe 'Digitales Fernsehen' formulierte er maßgeblich die
Strategie der ARD im digitalen Zeitalter.
Seit 1997 ist Andreas Weiß als Koordinator Ausland in der Programmdirektion des Ersten
Deutschen Fernsehens tätig. Auch in dieser Funktion setzt er sich besonders für
Zukunftsstrategien der öffentlich-rechtlichen Sender Europas in der Welt der digitalen
Kommunikation und konvergierender Medien ein. Er wirkte und wirkt unter anderem in
folgenden Gremien mit: Mitglied der digitalen Strategiegruppe der Europäischen
Rundfunkunion (EBU), Vorsitzender des Multimedia-Forums der EBU, Beirat der
Industriemesse IBC, IDR - Initiative digitaler Rundfunk der Bundesregierung, Zahlreiche
ARD-Gremien
Andreas Weiß war an der Entwicklung des Elektronischen Programmführers der ARD
beteiligt und entwarf die ersten sendungsbegleitenden Applikationen „Verstehen Sie
Spaß?“ und „Tatort-Interaktiv“.
Franz Koller, Diplom-Informatiker, arbeitete zunächst als wissenschaftlicher Mitarbeiter
und anschließend als Projektleiter am IAT der Universität Stuttgart. Am Competence
Center Softwaretechnologie des Fraunhofer IAO leitete er das Multimedia Labor und
wurde dann Leiter des Marktstrategieteams „Interaktive Produkte“.
1998 wechselte er zur schwedischen UI Design AB, Linköping als stellvertretender Leiter
der deutschen Zweigstelle in Ludwigsburg. Im November 1998 wurde er
geschäftsführender Gesellschafter der neu gegründeten User Interface Design GmbH.
Schwerpunkte seiner Arbeit liegen in den Bereichen Medien & Consumer-Anwendungen
(Digital TV, Smart Home) sowie Webanwendungen und -technologien.
Franz Koller war Mitinitiator der Norm DIN EN ISO 14915: „Software ergonomics for
multimedia user interfaces“ und ist Mitglied in der Gesellschaft für Informatik, der ACM,
der Gesellschaft für Medien in der Wissenschaft und der FKTG.
164
INTERKULTURELLES
USABILITY-ENGINEERING
KULTURDIMENSIONEN FÜR DIE GESTALTUNG UND ANALYSE
INTERNATIONALER USER INTERFACES:
WELCHE SIND WICHTIG UND NÜTZLICH?
Valentina-Johanna Baumgartner
mavas Screenusability
Krenngasse 8/4/20
A-8010 Graz
vj.baumgartner@mavas.at
http://mavas.at
ABSTRACT
Der Artikel gibt eine Zusammenfassung der
Diplomarbeit „A Practical Set of Cultural Dimensions
for Global User-Interface Analysis and Design“, die
im Rahmen des Studiengangs Informationsdesign an
der FH JOANNEUM in Zusammenarbeit mit Aaron
Marcus and Associates, Inc. entstanden ist. Diese
Arbeit
beleuchtet
den
Einfluss
von
Kulturdimensionen auf die Gestaltung von UserInterface-Elementen. Durch eine Umfrage unter
ExpertInnen
wurden
die
einflussreichsten
Dimensionen herausgefiltert. Anschließend wurde
versucht, praktische Anwendungsgebiete für den
Einsatz dieser Dimensionen anzubieten.
Modelle erarbeitet, wie diese subjektiven Kategorien
erfasst und durch Kulturdimensionen beschrieben
werden können. Ziel der Diplomarbeit war es
einerseits,
herauszufinden,
ob
es
Kulturdimensionen gibt, die für das User-Interface
Design besonders relevant sind, ob also ein Ranking
nach Wichtigkeit subjektiver kultureller Dimensionen
für den Bereich Interface Design möglich ist.
Andererseits sollte ermittelt werden, ob bestimmte
Elemente des User Interfaces durch kulturelle
Unterschiede besonders stark beeinflusst werden.
Im Folgenden soll die Frage der Relevanz von
Kulturdimensionen im Mittelpunkt stehen.
Keywords
Globalization, Internationalization, Localization, UserInterface Design, Cultural Dimensions
Langfristig soll diese Arbeit auch eine Grundlage für
die Entwicklung von Content Management
Systemen (CMS) bilden, die fähig sind, subjektive
Kategorien kultureller Unterschiede handhabbar zu
machen.
1. EINLEITUNG
2. KULTURDIMENSIONEN
Die Gestaltung von User-Interfaces für international
diverse Nutzergruppen benötigt die Anpassung von
User-Interface-Elementen
auf
verschiedenen
Ebenen. Um die Benutzbarkeit von Produkten für
eine bestimmte kulturelle Zielgruppe zu optimieren,
sollten nicht nur objektive Kategorien wie Sprache,
Richtung des Schriftsystems oder Formatierungen
von Zahlen oder Daten die Gestaltung von
Bildschirmoberflächen
berücksichtigt
werden,
sondern auch subjektive Kategorien, wie z.B.
Wertesysteme
oder
Verhaltensmuster
der
betroffenen Zielgruppe.
Durch primäre und sekundäre Literaturanalyse der
AutorInnen bzw. AutorInnenteams Adler, Condon &
Yousef, Hall, Hofstede, Kluckhohn & Strodtbeck,
Parsons, Trompenaars, Victor und Wright wurden
insgesamt
folgende
29
Kulturdimensionen
herausgearbeitet:
Zahlreiche AnthropologInnen, PsychologInnen und
KommunikationswissenschaftlerInnen
haben
Stuttgart).
Proceedings of the
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Achievement vs. Ascription
Activity Orientation
Affective vs. Neutral
Authority Conception
Context
Degree of Power
Economic Progress
Experience of Technology
Face-Saving
Gender Roles
Human Nature Orientation
Individualism vs. Collectivism
Instrumental vs. Expressive
Internal vs. External Control
International Trade and Communication
Long-Term vs. Short-Term Orientation
Meaning of Life
167
Baumgartner, V.-J.
• Nonverbal Communication
• Political Decentralization
• Power Distance
• Property
• Resources
• Space
• Specific vs. Diffuse
• Technological Development
• Time Orientation
• Time Perception
• Uncertainty Avoidance
• Universalism vs. Particularism
Eine ausführliche Beschreibung
dieser 29
Dimensionen
und
Praxisbeispiele
für
die
Auswirkungen dieser Kategorien im realen
Alltagsleben
und
im
Design
von
Bildschirmoberflächen finden sich in Baumgartner
(2003).
3. ARBEITSMETHODIK
3.1 Online-Fragebogen
Mittels einer ExpertInnenumfrage wurde ermittelt,
welche Kulturdimensionen in der täglichen Designund Analysearbeit wichtig und einflussreich
erscheinen. Zu diesem Zwecke wurde ein
Onlinefragebogen entworfen, der mittels einer 5teiligen Likert-Skala eine Bewertung der Wichtigkeit
der jeweiligen Dimension zulässt. Der Fragbogen
umfasst eine detaillierte Beschreibung jeder
Dimension, weiters eine Hintergrundbefragen zu
relevanten demographischen Daten der ExpertInnen
(wie Herkunftsland, gegenwärtiger Aufenthaltsort,
berufliche Erfahrung
im Bereich User-Interface
Design)
sowie die Möglichkeit, allgemeine
Kommentare zum Thema in einem freien
Kommentarfeld zu geben.
4. ERGEBNISSE
4.1 Teilnehmende ExpertInnen
57 ExpertInnen aus 21 verschiedenen Ländern
füllten den Fragbogen aus. 19 davon leben in
anderen Ländern als sie geboren und kulturell
geprägt wurden. Betrachtet man die Verteilung auf
Kontinente, ergibt sich folgendes Bild:
Kontinent
Afrika
Asien
Australien
Europa
Nordamerika
Südamerika
Anzahl der teilnehmenden
ExpertInnen
3
3
1
20
29
1
Tabelle 1: Verteilung der ExpertInnen nach Kontinent
bzgl. derzeitiger Arbeitsstätte
168
4.2 Generelles Feedback
Der Grundtenor zur Studie war positiv. Viele der
Befragten merkten an, dass allein die Sammlung
dieser Kulturdimensionen ein nützliches Werkzeug
für ihre zukünftige Arbeit darstellt.
Inhaltliches Feedback wird dominiert durch die
Aussage „Everything depends“. Fast geschlossen
wird vermerkt, dass eine generalisierende Aussage
über die Auswirkungen von Kultur auf das Feld
User-Interface Design schwierig erscheint. Je
nachdem, um welches fachliche Gebiet des
Produkts
es
sich
handelt,
sind
andere
Kulturdimensionen wichtig.
4.3 Die einflussreichsten Dimensionen
Eine Faktorenanalyse der Daten ergab, dass
folgende Kulturdimensionen als „sehr wichtig“ oder
„wichtig“ eingeschätzt wurden: 1) Context, 2)
Experience of Technology, 3) Technological
Development, 4) Time Perception und 5) Uncertainty
Avoidance. Kombiniert mit einer statistischen
Mittelwertsauswertung und der Tatsache, dass sich
bei Betrachtung der Werte, die sich aus den Daten
der ExpertInnen ergeben, die über mehr als fünf
Jahre an Erfahrung im Bereich User-Interface
Design verfügen, die Dimension „Authority
Conception“ auf Rang fünf findet, und die
Dimensionen Technological development und
Experience of Technology nahe beieinander liegen
bzw. einander bedingen, schlage ich folgendes
Wichtigkeits-Ranking vor:
1.
Context
2.
Technological Development
3.
Uncertainty Avoidance
4.
Time Perception
5.
Authority Conception
Die Dimension Context beschreibt die Menge an
Information, die mit einer Aussage transportiert wird.
High Context bedeutet demnach, dass eine
Nachricht viele verschiedene Inhalte enthält und ihre
Bedeutung stark vom Kontext abhängt. Personen in
“high-context”-Kulturen sind bei Interaktionen stark
auf die äußere Umgebung, die Situation, den
Kontext angewiesen, um die Bedeutung einer
Nachricht korrekt zu interpretieren. Es wird ein
indirekter Kommunikationsstil bevorzugt. In „lowcontext“ Kulturen spielt die Umgebung eine
geringere Rolle, es wird explizit formuliert und direkt
kommuniziert. Für den Bereich User-Interface
Design ist diese Dimension deshalb so wichtig, weil
z.B. in High Context Kulturen viel vorsichtiger mit
Informationselementen umgegangen werden muss,
um nicht versehentlich Dinge zu vermitteln, die gar
nicht vermittelt werden sollen.
Technological Development beschreibt den Grad
technologischer Entwicklung eines Landes. In
direktem
Zusammenhang
damit
steht
der
Einstellung
der
Bevölkerung
gegenüber
Kulturdimensionen für die Gestaltung und Analyse internationaler User Interfaces: Welche sind wichtig und nützlich?
Technologie. Die Skala rangiert hier von kontrollorientiert (Technologie wird grundsätzlich positiv
wahrgenommen, die Umwelt soll und darf durch
Technologie
beherrscht
werden)
über
harmonisierend (Technologie ist neutraler Teil der
Umwelt) bis hin zu unterwerfungs-orientiert (es ist
nicht wünschenswert, dass die Umwelt z.B. durch
Technologie kontrolliert wird).
bei einer Anpassung an eine bestimmte Kultur
verändert werden müssen:
Uncertainty Avoidance meint den Grad an
Unbehagen mit dem Mitglieder einer Gesellschaft
unsicheren oder unbekannten Situationen begegnen.
Für den Bereich User-Interface Design ist dieser
Faktor besonders hinsichtlich Navigation und
Features wie Zahlungsmöglichkeiten wichtig.
Time Perception meint die Art, wie Mitglieder einer
Kultur mit Zeit umgehen. Die Skala reicht vom
monochron/sequentiell
(eine
Tätigkeit
folgt
sequentiell der nächsten) bis zu polychron/synchron
(mehrere Tätigkeiten werden parallel ausgeführt).
Da sich diese Einstellung laut Hall, Trompenaars
und Victor auch auf den Umgang mit
Verbindlichkeiten
zeitlicher
Abmachungen
gegenüber auswirkt, beeinflusst diese Kategorie z.B.
das Design von Zeitplanungssystemen usw. aber
auch die grundsätzliche Darstellung von Abläufen.
Authority Conception beschreibt den üblichen
Umgang mit Hierarchien und Macht innerhalb einer
Organisation. Die Skala reicht laut Condon & Yousef
von demokratisch über autoritätszentriert bis zu
autoritär. Die Design Komponente, die durch diese
Kategorie am meisten beeinflusst wird, ist – laut
Meinung vieler ExpertInnen – der Bereich der
Interaktion (z.B. Feedback-Nachrichten).
4.4 Visualisierung von
Anpassungsnotwendigkeiten
Fakt ist leider, dass uns nur über wenige
Kulturdimensionen empirische gewonnene Werte für
einzelne Länder vorliegen. Geert Hofsteede etwa
hat in seiner sehr bekannten Studie für die von ihm
propagierten Dimensionen Werte für ca. 80 Länder
erhoben.
Würden solche Werte für alle Länder und alle
Kulturdimensionen vorliegen, könnte folgendes Tool
hilfreich sein, um zu entscheiden, welche Bereiche
Abbildung 1: Vergleich Kultureller Werte mittels StarChart
Abbildung 1 geht davon aus, dass die konkreten
Werte für ein Ursprungsland und das Zielland eines
Bildschirmproduktes bekannt sind. Werden diese
Werte in ein Starchart Diagram eingetragen, ergibt
sich das klare Bild, dass die größten Veränderungen
in den Bereichen, die durch die Dimension Context
beeinflusst werden, durchgeführt werden müssen.
Die Arbeit hat gezeigt, dass es schwierig ist, ein
generelles
Wichtigkeits-Ranking
der
Kulturdimensionen für den Bereich User-Interface
Design zu erstellen, da – laut Ansicht der für die
Umfrage befragten ExpertInnen – der Fachbereich
für die das Interface erstellt wird, essentiell ist und
unterschiedliche Wichtigkeiten generiert. Trotzdem
wurden die fünf wichtigsten Dimensionen und ihre
Haupteinflussgebiete beschrieben.
Ein
interessantes
Folgeprojekt
wäre
die
Untersuchung dahingehend, inwieweit es in
unterschiedlichen Domänen zu unterschiedlichen
Rankings kommt.
6. REFERENCES
[1] Baumgartner, Valentina-Johanna: A Practical
Set of Cultural Dimensions for Global UserInterface Analysis and Design. Diplomarbeit
2003.
169
Baumgartner, V.-J.
Referentin
Valentina-Johanna Baumgartner studierte Geisteswissenschaften an der Universität
Graz und Bremen und ist Absolventin des Studiengangs Informationsdesign an der
Fachhochschule JOANNEUM in Graz, Österreich. Im Rahmen dieses Studiums und
auch als Geschäftsführerin der von ihr mitbegründeten Firma mavas Webengineering
Screenusability Computertrainings hat sie sich auf den Bereich User-Interface Design
spezialisiert. Ihr Forschungsschwerpunkt liegt im Bereich kultureller Unterschiede und
deren Auswirkungen auf das Gebiet User-Interface Design.
2002/2003 war sie als Praktikantin bei Aaron Marcus and Associates, Inc. in California,
USA als Designer/ Analyst tätig, wo sie sich forschungsmäßig hauptsächlich auf
kulturelle Unterschiede für WWW-Auftritte konzentrierte.
170
DETERMINING CULTURAL ISSUES IN ATTITUDE TO
AND USE OF MOBILE PHONES
Elizabeth Hofvenschiold
Fraunhofer IAO
Nobelstraße 12
70569 Stuttgart
elizabeth.hofvenschiold@iao.fhg.de
ABSTRACT
Cultural background and occupational status can
influence the way people interact with and perceive
technology. A study was undertaken to gather
information on the possible differences in the use of
and attitude to mobile phones of British and German
university students and young professionals. The
research findings were to contribute to the
development of future mobile phone interfaces and
applications. Geert Hofstedes’s work on culture was
used as a framework for interpreting the results and
also determining its relevance to the field of HumanComputer Interaction (HCI) in general. The study
proved that there were differences between the
groups but also many similarities. Also, some of the
differences were not as was predicted according to
Hofstede.
Keywords
Emotional
issues,
occupational status
culture,
mobile
phones,
1. INTRODUCTION
Many factors need to be taken into consideration
when designing interactive systems. Ergonomists
and usability professionals have traditionally
concentrated on the physical and the cognitive
issues involved in product development. More
recently issues concerning the emotional and
motivational aspects have increased in importance
and relevance to the fields of Ergonomics and
Human-Computer Interaction (HCI). There is a
growing move towards addressing the soft or
emotional issues of interaction design (i.e. what the
user wants) or understanding why a customer
actually chooses and uses a product. As Teague and
Stuttgart).
Proceedings of the
Whitney (2002) have pointed out, the emotional and
motivational needs of users have direct impact on
the usability and ultimate success of a design.
Culture is a factor that shapes the development of a
person’s values and beliefs and therefore
conceivably influences his/her interaction with a
product.
2. RESEARCH OBJECTIVES
The general research objective was to gather
information on the possible effects of a user’s
cultural background and occupational status on
his/her attitude to and use of mobile phones.
Additional objectives were to test the applicability of
Geert Hofstede’s cultural dimensions to HCI and to
identify motivational and emotional issues for
consideration in the development of future mobile
phone interfaces and applications.
University students and young professionals from
the United Kingdom (UK) and Germany made up the
participants for the study. The UK and Germany
were chosen for several reasons. Firstly, they are
part of northern Europe and have to a major extent
been marketed to and designed for as a group. The
two cultures have many similarities but differ
considerably in certain areas. Also, the UK and
Germany are the two countries that spent the most
on 3G licenses. How far do the cultural differences
need to be taken into consideration when designing
interfaces (and interactivity) for future mobile
phones? Cultural and other issues will influence the
strategies that mobile device manufacturers and
service providers decide to take.
Two occupational groups were chosen so as to
ensure that the groups in both countries were as
similar as possible. A subsidiary objective was to
see if there were differences between occupations,
as they are in themselves their own sub-cultures.
3. THEORETICAL CONTEXT
There are many definitions for what makes up a
culture. For the purposes of this study, Hofstede’s
cultural dimensions (see Hofstede 1980 and 1997)
were used as a framework for contrasting and
comparing the UK and Germany. Hofstede’s work
was chosen because his research has been used by
171
Hofvenschiöld, E.
many researchers and practitioners in various fields
to define a culture (Pugh and Hickson 1996). Also,
his work has defined the strategies developed for
countries in advertising and marketing campaigns
and more recently, HCI design practices (e.g. Jordan
2000). Using Hofstede’s research for this study was
also a way of determining its applicability to HCI in
general. His dimensions have been successfully
applied to the fields of advertising, marketing,
management
and
naturally
organizational
psychology. How useful are they for HCI?
3.1 How do Germany and the UK differ?
Four out of the five dimensions Hofstede defined
were used for this study. According to these, the UK
and Germany are both masculine, individualistic and
low-power distance cultures. However, the UK is a
much more individualistic country than Germany is.
And the dimension in which the UK and Germany
differ most is in uncertainty avoidance. The UK
scored very low in uncertainty avoidance whereas
Germany has very high uncertainty avoidance. This
was thought to be of particular importance to this
study as the way in which people deal with
uncertainty affects the technology, laws and
religion(s) of a country (Hofstede 1997).
Does the level of uncertainty avoidance and
individualism influence the way different cultures
interact with their mobile phones? Based on the
information above, it is plausible that Germans
would use and interact with their mobile phones in
ways that would reflect a society that has high
uncertainty avoidance. No fixed assumptions are
offered as to how each group would differ according
to where they are placed in the dimensional matrix.
However, two general research hypotheses were
constructed to guide the study. The first states that a
person’s culture would affect the way he/she
perceives, understands and uses a mobile phone.
The second states that there will be differences in
the perception and use of mobile phones between
the different occupational groups (for more
information please see Hofvenschiold 2002).
4. METHODS AND RESULTS
4.1 Data Gathering Techniques
A literature review was undertaken for the
preparation of the study and to help develop the
framework of analysis. This was however not
sufficient to fulfill the research objectives as at the
time of the study hardly any literature could be found
on the topic. A questionnaire was developed to
gather data and a representative of each group was
interviewed in-depth. The questionnaire was
essentially divided into five categories: (i) personal
information including nationality and occupation; (ii)
mobile phone functions used and their usability
ratings; (iii) suggestions for changes and additions of
function and display; (iv) attitudes to mobile phones
172
in general; (v) frequency of, reasons for and
perceived usability of personal Internet use.
4.2 The Participants
78 people participated in the study. Out of the 25
university students, 8 were British and 17 were
German. And out of the 53 young professionals, 21
were British and 32 were German. The participants
were 21 to 40 years old and 65% were male and
35% were female.
4.3 Questionnaire Results
Only the most relevant results from the
questionnaire are presented in this paper. Nearly all
participants found the same four functions easiest to
use when asked to list what they thought were the
four easiest to use functions on their mobile phone.
These were receiving a call, making a call, receiving
and reading a text message and writing a text
message. Only one group differed in the last
function – the German young professionals found
that the fourth easiest to use function was looking up
entries in the phone book and not writing text
messages. Generally all of the groups found the
same functions harder to use and it is interesting to
note that writing text messages was also included in
this list.
A majority of the British participants specified that
they would like a colour screen while a large number
of the Germans said that they would prefer a larger
screen. Some of the British also specified that a
larger screen was preferable and other German
participants mentioned that a colour screen was
desirable. They wanted the same things but
prioritised them differently.
Seven attitude statements were included in the
questionnaire. The Mann-Whitney U test was used
to check for significant statistical differences in the
responses. 2 values were found to be significant at
the 5% level. The university students of both
countries were more likely to agree to the statement,
“What a mobile can do is more important than its
‘look and feel’” than the young professionals of both
countries were (significance value was 0.026).
German young professionals were likely to disagree
with the statement, “Your mobile is a status symbol”
than the British young professionals (significance
value was 0.05).
4.4 Interview Results
The data gathered from the interviews was of a
qualitative nature and much richer in detail than the
questionnaire data. More interviews were planned
but unfortunately were not carried out due to time
and budget restrictions. The sample size was very
small but from the answers given, it seemed that the
British participants were more likely to individualize
their mobile phones and more emotionally attached
to them than their German counterparts.
Determining Cultural Issues in Attitude to and Use of Mobile Phones
5. DISCUSSION AND CONCLUSION
The information gathered for this study suggests that
culture and occupation do, to a certain extent, affect
the way in which people interact with their mobile
phones. For general usability issues, the groups
responded in much the same way. Differences
began to occur when the questions began to explore
the more emotional and motivational aspects of
mobile phone use. It is highly likely that a larger
population sample and a different statistical
approach would illuminate more than what was
discovered for this study.
Hofstede’s work did provide a good framework for
this study but perhaps his dimensions are not
entirely suited to this type of research. Based on his
dimensions, the differences found in the data were
not what were expected. For example, if someone
came from a high uncertainty avoidance culture,
he/she might be more disposed to having a mobile
phone for security reasons. When asked, more
British than German participants stated that they had
purchased and intended to use their mobile phones
for security purposes. The two cultural groups did
vary in certain ways but perhaps not as you might
expect, if your theoretical framework was based on
Hofstede. However, some of the other findings
related to the individualism dimension were more
predictable. It is also conceivable that the
dimensions affecting mobile phone use are the ones
in which Germany and the UK are very similar and
therefore no striking differences were discovered.
Therefore a different approach to defining cultures
might have been more appropriate for the study. In
general, a tailored set of Hofstede’s dimensions and
other cultural determinants might be more applicable
for HCI.
Another factor that has to be taken into
consideration when discussing the data is that the
mobile phones at the time of the study had
predominantly text-based interfaces. Therefore they
did not contain the culturally specific elements, such
as icons and graphics that web sites or software
applications do. This might be part of the reason
why not as many differences were discovered as
was expected from Hofstede’s results. This has
implications for the development of coming mobile
interfaces and applications. The mobile phones of
the future will have increased functionality and
graphical capabilities, which could lead to more
complex graphic interfaces and culturally specific
elements. It is not enough to study the existing
mobile phones. It is important that other existing
systems are involved when gathering user
requirements for future developments. This study
did include questions about Internet use (and
personal digital assistant use in the interviews) but
they were few and rather general in nature.
6. REFERENCES
[1] Hofstede G., Culture’s Consequences:
International Differences in Work-Related
Values, Sage Publications, Beverley Hills, USA
(1980).
[2] Hofstede G., Cultures and Organizations:
Software of the Mind, McGraw-Hill, USA (1997).
[3] Hofvenschiold E., Cultural Issues in Human
Computer Interaction and Ergonomics and the
Design of Smartphones, Contemporary
Ergonomics., 372-376 (2002).
[4] Jordan P.W., Designing Pleasurable Products:
An Introduction to the New Human Factors,
Taylor and Francis, London, UK (2000).
[5] Pugh D.S. & Hickson D.J., Writers on
Organizations (fifth edition), Penguin Books Ltd,
London, UK (1996).
[6] Teague R. & Whitney H.X., What’s love got to
do with it? User Experience, Vol. 1, no. 3, winter
edition (2002)
173
Hofvenschiöld, E.
Referentin
Elizabeth Hofvenschiöld is a freelance HCI and interaction design consultant. She
currently works with the Fraunhofer IAO in Stuttgart on a range of projects. In 2001
she completed her Masters of Science in Human-Computer Interaction with
Ergonomics at University College London, England.
Her main interests are in cultural issues, interaction design for mobile devices and
applications and developing the user experience for ubiquitous human-computer
interaction. She has presented and published her work on these subjects as well as on
implementing a holistic approach to product development and evaluation through
using a range of methods from different fields (e.g. marketing).
174
INTERKULTURELLE UNTERSCHIEDE
IN DER INTERAKTION MIT FAHRER-INFORMATIONS-SYSTEMEN
Maria Peißner
Harman/Becker Automotive Systems
Raiffeisenstrasse 34
70794 Filderstadt
m.peissner@caa.de
http://www.becker.de
ABSTRACT
Ein intuitiv nutzbares Fahrer-Informations-System
setzt eine Gestaltung der Schnittstelle zwischen
Mensch, System und Information voraus, die eine
Interaktion zwischen dem Fahrer und dem
Informations-System optimiert. Aufgrund einer
zunehmenden Globalisierung der Absatzmärkte
erfordert die Entwicklung einer Nutzeroberfläche die
Berücksichtigung kultureller Besonderheiten und
interkultureller Unterschiede. Ziel der vorliegenden
Untersuchung war es, herauszufinden, welche
Unterschiede sich hinsichtlich der Nutzung und
Bewertung
von
Fahrer-Informations-Systemen
zwischen verschiedenen Kulturen ergeben. Dazu
wurde parallel in Deutschland, Japan und den USA
eine Usabilitystudie mit bereits am Markt erhältlichen
Systemen durchgeführt. Erste Ergebnisse zeigen
interkulturelle Unterschiede im Umgang mit FahrerInformations-Systemen.
Eine
kulturorientierte
Anpassung des HMI an lokale Märkte kann den
Erfolg
von
Informations-Systemen
stark
beeinflussen.
Keywords
Fahrer-Informations-System,
Usability Testing
interkulturelles
1. EINLEITUNG
1.1 Fahrer-Informations-Systeme
Der Einsatz neuester Technologien ermöglicht eine
Integration
komplexer
Kommunikationsund
Informationssysteme
im
Fahrzeug.
FahrerInformations-Systeme (FIS) liefern dem Fahrer
Informationen über die zu fahrende Route, die
Stuttgart).
Proceedings of the
Verkehrssituation, das Fahrzeug, etc. Gleichzeitig
bieten sie eine Vielzahl an Entertainmentfunktionalitäten wie Radio, CD-, DVD-Spieler,
mobiles Fernsehen und
Kommunikationsapplikationen wie Telefon und künftig auch Internetzugang.
Bei der Nutzung von FIS erhält der Fahrer nicht nur
passiv Informationen vom System sondern gibt auch
aktiv Daten ein (z.B. bei der Zieleingabe) und trifft
eine
individuelle
Auswahl
aus
dem
Funktionsangebot. Es entsteht eine Interaktion
zwischen Nutzer und FIS.
Neben Sicherheitsaspekten im Verkehr sollte ein
FIS daher den Bedürfnissen und Erwartungen des
Fahrers gerecht werden und nutzerfreundliche
Interaktionsmöglichkeiten bieten [3].
1.2 Interkulturelle Unterschiede
Interkulturelle Unterschiede manifestieren sich in
relativ überdauernden Interaktionsmustern mit der
sozialen und materiellen, also auch technischen,
Umwelt. Sie umfassen kulturell geprägte Aspekte
der Wahrnehmung, des Denkens und Handelns
sowie Glaubenssätze, Werte und mentale Modelle
[2]. Beispielsweise können kulturell bedingte
Differenzen in der Wahrnehmung von Struktur und
Design eines Systems zu unterschiedlicher
Risikobewertung eines Warnhinweises führen [8].
Andererseits spiegelt ein technisches System
kulturspezifische Schemata und mentale Modelle
der Kultur wider, in der es entwickelt wurde. Vor
diesem Hintergrund können sich im und für den
west-europäischen Markt konzipierte Systeme nicht
selbstverständlich auch auf einem internationalen
Markt behaupten. Im Rahmen der fortschreitenden
Globalisierung des Marktes wird es unumgänglich,
interkulturelle Unterschiede bei der Entwicklung
eines
Anzeigeund
Bedienkonzeptes
zu
berücksichtigen.
2. METHODEN
Ziel der Usability Studie war es, herauszufinden,
inwieweit
kulturell
variierende
Denkmuster,
Problemlösestrategien und Nutzungsanforderungen
Einfluss auf den Umgang mit FIS und ihre
175
Peißner, M.
Bewertung durch den Nutzer nehmen. Parallel in
Deutschland, Japan und den USA wurden
summative Usability Tests mit drei FahrerInformations-Systemen durchgeführt, die sich in
ihrem Bedienkonzept voneinander unterscheiden.
2.1 Untersuchte Systeme
Für die Untersuchung wurden Systeme mit
vergleichbarem Funktionsumfang und ähnlich
großem farbigen Display ausgewählt. Zwei der
untersuchten
Systeme
wurden
von
westeuropäischen Herstellern entwickelt, das dritte
Fahrer-Informations-System stammt aus dem nichteuropäischen Markt.
Wesentliche
Unterscheidungsmerkmale
der
Systeme sind die Bedienelemente und eine
entsprechende Nutzerführung. Als repräsentative
Vertreter für aktuell handelsübliche Bedienprinzipien
wurden
ein
FIS
mit
dezentralisiertem
Bedienkonzept, ein System mit Touchscreen und ein
System mit zentralem Stellteil evaluiert. Bei dem
zentralisierten Konzept können alle Applikationen
und Funktionen des Systems, wie beispielsweise
Navigation, Entertainment und auch KlimaEinstellungen,
über
ein
zentrales
Stellteil
angesprochen und kontrolliert werden. Sowohl bei
dem dezentralisierten Konzept als auch bei der
Lösung mit Touchscreen sind die Hauptfunktionen
direkt
über
Hardkeys
anwählbar,
KlimaEinstellungen
können
über
separate
Bedienelemente modifiziert werden. Darüber hinaus
bietet das System mit dezentralisiertem Konzept
Multifunktionstasten, die über das Display variabel
belegt werden, sowie weitere fix belegte Tasten zur
Auswahl und Bestätigung.
2.2 Testpersonen
In Deutschland nahmen 23 Personen an der Studie
teil, in Japan 27 Personen. In den USA betrug die
Stichprobengröße 26 Personen. Der Anteil an
weiblichen Testpersonen konnte mit 20-30% über
die Kulturgruppen parallelisiert werden. Er liegt auf
einem repräsentativen Wert für die Zielgruppe von
Fahrer-Informations-Systemen.
2.3 Testaufgaben
Die Testaufgaben wurden so zusammengestellt,
dass sie einen möglichst breiten Funktionsumfang
der Fahrer-Informations-Systeme abdeckten und mit
allen drei Systemen durchgeführt werden konnten.
So wurde für die Bewertung durch die Testnutzer
eine hohe Vergleichbarkeit zwischen den Systemen
erzielt.
2.4 Subjektive Bewertung
2.4.1 Fragebögen
Die Nutzerfreundlichkeit der FIS wurde anhand
eines Usability-Fragebogens evaluiert, der bereits in
vergleichbaren Untersuchungen eingesetzt wurde [4]
[5] [6] [7]. Schwerpunkt dieses Fragebogens liegt auf
176
der
Erfassung
von
leistungsbezogenen
Dimensionen,
wie
beispielsweise
Aufgabenangemessenheit. Er umfasst aber auch
subjektive Aspekte von Usability, wie z.B. Akzeptanz
[1].
Ausgehend von der deutschen Version wurden die
englische
und
japanische
Version
in
Zusammenarbeit mit Muttersprachlern erstellt.
2.4.2 Interview
In
einem
abschließenden
halbstrukturierten
Interview hatten die Testpersonen die Möglichkeit,
die drei Systeme untereinander zu vergleichen.
Nach einem
ersten Ranking wurden die
Testpersonen entsprechend der von ihnen
festgelegten Reihenfolge detailliert zu jedem der
Systeme befragt. Hier interessierte vor allem,
welche Eigenschaften den Nutzern jeweils am
besten zusagten und worin sie die wichtigsten
Kritikpunkte sahen.
2.5 Verhaltensdaten
Zur Erhebung interkultureller Differenzen in der
Bedienung von FIS wurden neben den subjektiven
Urteilen
auch
objektive
Verhaltensdaten
herangezogen.
Analysiert
wurden
die
Lösungshäufigkeiten und Abweichungen vom
optimalen Bedienpfad. Zu diesem Zweck wurde die
Interaktion zwischen Nutzer und System mit
Einverständnis der Testpersonen auf Video
aufgezeichnet.
2.6 Versuchsdurchführung
Jeder Versuchsteilnehmer testete jedes FahrerInformations-System in permutierter Reihenfolge.
Für die Bearbeitung der Aufgaben in vorgegebener
Reihenfolge wurde keine Bedienungsanleitung zur
Verfügung
gestellt
Die
Systeme
wurde
ausschließlich im stehenden Fahrzeug evaluiert.
Konnte eine Aufgabe innerhalb eines bestimmten
Zeitfensters nicht gelöst werden, wurde die
Versuchsperson unterbrochen und zur Bearbeitung
der nächsten Aufgabe aufgefordert, nachdem die
Aufgabe exemplarisch vom Versuchsleiter zu Ende
geführt wurde. Jeweils im Anschluss an eine
Testsitzung
füllte die Versuchsperson den
Fragebogen zur Benutzerfreundlichkeit aus. Zum
Abschluss
der
Untersuchung
wurde
das
halbstrukturierte Interview durchgeführt.
3. ERGEBNISSE
Um
handlungsweisende
Aussagen
über
interkulturelle Unterschiede im Umgang mit FIS
treffen zu können, werden in einem ersten Schritt
der Datenauswertung Interaktionseffekte zwischen
den Kulturgruppen und den unterschiedlichen
Bedienkonzepten
analysiert.
Eine detaillierte
Auswertung der subjektiven Bewertungen und
objektiven Verhaltensdaten soll Aufschluss geben,
inwieweit Nutzeranforderungen und –Erwartungen
Interkulturelle Unterschiede in der Interaktion mit Fahrer-Informations-Systemen
zwischen den Kulturen variieren und wie ihnen
begegnet werden kann.
In einem vorausgehenden, vergleichbar angelegten
internationalen Usabilitytest [7] ergaben sich
interkulturelle Unterschiede in der Bewertung von
FIS in Bezug auf ihre Bedienkonzepte. Ein in Japan
entwickeltes System mit Touchscreen erzielte in
Japan deutlich bessere Werte als in Deutschland
oder den USA. Das in Deutschland entwickelte
System mit zentralem Dreh-Drück-Steller entsprach
eher den Erwartungen und Verhaltensweisen der
Testpersonen in Deutschland und den USA, wurde
aber in Japan weniger akzeptiert als das FIS mit
Touchscreen.
4. AUSBLICK
Eine erste Analyse der Ergebnisse der aktuellen
Studie zeigt entsprechend den zuvor berichteten
Ergebnissen, dass im Entwicklungsprozess von
Fahrer-Informations-Systemen mit zunehmender
Globalisierung des Marktes kulturelle bzw.
landesspezifische Einflüsse berücksichtigt werden
sollten. Diese Forderung stellt einen hohen
Anspruch an das Inteaktionsdesign eines FIS.
Ziel der vorliegenden Studie ist es daher,
kulturspezifische Besonderheiten im Umgang mit
Infotainment-Systemen
auszuloten,
um
so
Handlungswissen
für
globale
Entwicklungen
technischer Systeme und lokale Anpassungen zu
erhalten.
5. REFERENCES
[1] Han S.H., Yun M.H., Kwahk J. and Hong S.,
Usability of consumer electronic products. Int.
Journal of Industrial Ergonomics. 28, 143-151
(2001).
[2] Honold P., Interkulturelles Usability Engineering.
Fortsch.-Ber. VDI Reihe 10, Nr. 647, Düsseldorf:
VDI Verlag (2000).
[3] Norman D., The invisible computer. Cambridge:
MIT Press (1998)
[4] Rößger P. and Smyrek U., Licht und Schatten.
TeleTraffic, 11/12 (November/December 1999),
(1999).
[5] Rößger P. and Smyrek U., Reifeprüfung.
TeleTraffic, 11/12 (November/December 2000),
12-15 (2000).
[6] Rößger P., Metternich B. and Smyrek U.,
Stunde der Abrechnung. Tele Traffic, 1/2
(January/February 2001), 22-25 (2001).
[7] Rößger P.and Peißner M., Interkulturelle
Unterschiede der Mensch-MaschineSchnittstelle von Fahrer-Informations-Systemen.
Telematik im Kraftfahrzeug, VDI-Berichte 1728,
Düsseldorf: VDI Verlag (2002).
[8] Zühlke D. and Röse K., Design of global userinterfaces: Living with the challenge.
Proceedings of the IEA 2000. 6, 154-157 (2000)
177
Peißner, M.
Referentin
Maria Peißner ist seit einem Jahr im Bereich Human Factors, Customer Projects & MMI
Concepts der Firma Harman/Becker Automotive Systems tätig. Sie studierte
Psychologie in Regensburg mit den Studienschwerpunkten Verkehrspsychologie,
Mensch-Maschine-Interaktion und Psychophysiologische Beanspruchungsmessung.
Ihr Hauptinteresse gilt der Einbeziehung zielgruppenspezifischer Endnutzer und ihrer
Anforderungen in den Entwicklungsprozess eines Infotainment-Systems von der
Konzeptidee bis zur Serienreife.
178
BARRIEREFREIES INTERNET
BARRIEREFREIES INTERNET:
WEBUSABILITY FOR ALL
Markus E. Mund
Frank Leidermann
Harald Weber
Institut für Technologie und Arbeit
Bluewin AG
Institut für Technologie und Arbeit
Gottlieb-Daimler-Straße, Geb. 42
Hardturmstrasse 3
Gottlieb-Daimler-Straße, Geb. 42
CH-8037 Zürich
mmund@ita.uni-kl.de
frank.leidermann@team.bluewin.com
hweber@ita.uni-kl.de
www.ita-kl.de
www.bluewinag.com
www.ita-kl.de
ABSTRACT
Dieser Beitrag zeigt grundlegende Richtlinien für die
Gestaltung barrierefreier Websites auf und
beleuchtet diese hinsichtlich der Umsetzung in die
Praxis.
Darüber hinaus werden Empfehlungen für den
begleitenden Evaluationsprozess ausgesprochen.
Keywords
Barrierefreie
Informationstechnik,
Zugänglichkeit, WCAG, WAI, BITV
Accessibility,
den letzten Jahren schrittweise voran gebracht. Im
Juli 2002 trat die Bundesverordnung zur Informationstechnik BITV [1] in Kraft, die die öffentliche
Hand u. A. zur barrierefreien Gestaltung ihrer
Internetangebote
verpflichtet.
Entsprechende
Verordnungen auf Landesebene werden zur Zeit
erarbeitet bzw. wurden bereits verabschiedet (bspw.
in Rheinland-Pfalz). Für die Privatwirtschaft haben
diese Verordnungen zunächst noch Empfehlungscharakter.
Im Folgenden sollen die technischen Kernpunkte der
Verordnungen und deren Implikationen für die
Praxis kurz vorgestellt werden.
1. EINLEITUNG
Das Internet ist derzeit noch voller Zugangsbarrieren
für NutzerInnen mit besonderen Anforderungen,
bspw. für
•
NutzerInnen mit sensorischen oder motorischen
Einschränkungen,
•
NutzerInnen, die mit PDA,
Organizer surfen möchten, oder
•
NutzerInnen mit langsamem Internetzugang.
Handy
oder
Barrieren entstehen dabei aufgrund des Designs von
Web-Seiten, die die besonderen Anforderungen von
Menschen mit Behinderungen, von neuen Zugangstechnologien oder beschränkten Übertragungskapazitäten nicht ausreichend berücksichtigen. In
jüngster Zeit wird unter dem Begriff der
„Barrierefreiheit“ primär das Gestalten von
Produkten
oder
Dienstleistungen
unter
Berücksichtigung der Anforderungen von Menschen
mit Behinderungen verstanden.
Auf politisch-rechtlicher Ebene wird dieses Thema in
Stuttgart).
Proceedings of the
2. DESIGN- UND ENTWICKLUNGSRICHTLINIEN
Grundlage zur Entwicklung barrierefreier Internetseiten sind die Richtlinien der Web-AccessibilityInitiative (WAI) des World-Wide-Web Konsortiums
(W3C) [2]. Unter dem Titel „Web Content
Accessibility Guidelines (WCAG)“, die derzeit in der
Version 1.0 vorliegen, sind dort - nach drei
Prioritäten gestaffelt - die Anforderungen an das
Design barrierefreier Webseiten aufgeführt [3].
Derzeit wird an einer neuen Version dieser
Richtlinien gearbeitet, die sich insbesondere durch
eine neue Struktur auszeichnet. Die in diesem
Artikel aufgeführten Richtlinien sind Bestandteil
beider
Versionen,
die
zur
Referenzierung
verwendete Nummerierung bezieht sich auf die
geltende Version 1.0.
2.1 Exemplarische Richtlinien und deren
Umsetzung
An dieser Stelle sollen exemplarische Richtlinien
und deren Umsetzung dargestellt werden. Dabei
werden insbesondere solche Richtlinien ausgewählt,
die zu einer Grundzugänglichkeit des Webauftritts
führen und dadurch die größten Barrieren beseitigen
können. In den folgenden Abschnitten werden
thematisch ähnliche Richtlinien zusammengefasst.
Am Anfang jedes Abschnittes werden in Klammern
die Nummern der angesprochenen Richtlinien
angegeben.
181
Mund, M., Leidermann, F. & Weber, H.
2.1.1 Validierende Quelltexte
(Richtlinien 3.2; 5.1; 11.1; 11.2)
Die Konformität mit den Standards des W3C ist die
Grundvoraussetzung für Barrierefreiheit. Das
bedeutet, dass jede Seite die HTML-Validierung des
W3C [4] erfolgreich passieren muss. Es ist
anzuraten, die aktuellen Versionen der jeweiligen
Technologie zu verwenden, also HTML 4.01 oder
XHTML 1.0 bzw. XML. Dies bedeutet auch, dass
veraltete Auszeichnungselemente nicht mehr zu
verwenden sind.
2.1.2 Verwendung von Cascading Stylesheets
(Richtlinien 3.3; 3.7; 6.1; 11.1)
Die Verwendung von Cascading Stylesheets (CSS)
ist notwendig, um eine konsequente Trennung von
Inhalt
und
Darstellung
umzusetzen.
Die
Formatierung von Schriftarten, Farben, Abständen
u. Ä. im Quelltext der Seite entspricht nicht mehr
den aktuellen Versionen der Sprachen (X)HTML und
XML. Die Verwendung von CSS geht aber über die
reine Formatierung von Text hinaus und dient auch
zur Positionierung von beliebigen Seitenelementen.
Diese Trennung von Inhalt und Darstellung ist eine
grundlegende
Herangehensweise,
um
Barrierefreiheit im Kern umsetzen zu können.
Dadurch ist gewährleistet, dass Webseiten nicht
ausschließlich
nur
auf
eine
(visuelle)
Bildschirmdarstellung hin optimiert werden. CSS
ermöglicht die Anpassung von Inhalten an
verschiedene Ausgabemedien. Dabei spielen in
Bezug
auf
Barrierefreiheit
insb.
Screenreader/Voicebrowser oder Braille-Zeilen eine
wichtige Rolle, da bei diesen der visuelle
Ausgabekanal durch einen akustischen oder taktilen
ersetzt wird.
Moderne Browser unterstützen die aktuelle Version
von CSS 2.0. Teilweise noch bestehende geringe
Unterschiede in der Interpretation können durch
Workarounds im Bedarfsfall ausgeglichen werden,
ohne die Validität der CSS-Datei zu beeinflussen.
Durch CSS ist es möglich, auf Hilfskonstrukte wie
z.B. Layout-Tabellen zu verzichten. Dies hat darüber
hinaus den Vorteil, dass die Reihenfolge der
dargestellten Inhalte variiert werden kann. Somit
kann im Falle einer linearisierten Darstellung, also
bei nicht vorhandener CSS-Interpretation, eine
optimale Struktur und Abfolge der Inhalte erreicht
werden. Dies ist insbesondere für nicht visuelle
Ausgabemedien wichtig, die Inhalte auf akustischem
oder taktilem Weg nur zeilenweise, also sequenziell,
wiedergeben können.
2.1.3 Markupgerechte Formatierung
(Richtlinien 3.5; 3.6; 3.7)
Bei der Auszeichnung der Inhalte ist darauf zu
achten,
die
Formatierung
mittels
Markup
entsprechend
den
Vorgaben
des
W3C
durchzuführen. So sind bspw. die Tags <h1> bis
182
<h6> nur zur Auszeichnung von Überschriften,
blockquote-Tags nur bei Zitaten zu verwenden.
Diese Richtlinie bringt zum Ausdruck, dass Markups
primär die Struktur von Dokumenten definieren
sollen (z.B. Überschrift, Zitat, Liste), nicht dessen
visuelle Erscheinung.
2.1.4 Farbunabhängigkeit und ausreichender
Kontrast
(Richtlinien 2.1; 2.2)
Um die Inhalte für die visuelle Darstellung
hinsichtlich Barrierefreiheit zu optimieren, sind
einige Grundregeln zu beachten. So ist es bei der
Wahl der Farben erforderlich, dass ausreichender
Kontrast zwischen Hintergrund und Vordergrund
(Text) gewährleistet ist. Dies lässt sich am
leichtesten überprüfen, indem dies in einer
Graustufen-Darstellung der gleichen Seite getestet
wird. Ein Tool, was einen solchen Test durchführen
kann, wird zum Einbau als „Favorit“ in den Microsoft
Internet Explorer angeboten [5].
Wichtig ist diese Forderung auch bei der
Hervorhebung oder Unterscheidung verschiedener
Elemente (z.B. Unterscheidung von Links und Text).
Bei Links bietet sich z. B. an, eine zusätzliche
Hervorhebung durch Unterstreichung oder Fettung
zu erzielen. Informationen müssen jederzeit auch
ohne farbige Darstellung (z. B. bei Schwarz-WeißDarstellung
oder
Rot-Grün-Schwäche
von
BetrachterInnen) zugänglich sein.
Informationen müssen also unabhängig von der
Farbe erfassbar sein und - falls inhaltlich notwendig
- durch geeignete Darstellungsoptionen eine klare
Unterscheidungsmöglichkeit zu anderen Elementen
bieten.
2.1.5 Textäquivalente für nicht-textuelle
Elemente
(Richtlinie 1.1)
Um Menschen, die alternative (d. h. nicht-visuelle)
Ausgabemedien verwenden, die Nutzung des
Inhaltes einer Seite zu ermöglichen, ist darauf zu
achten, jede Information, die in nicht-textlicher Form
vorliegt, auch als Text-Äquivalent anzubieten. Dies
ist
insbesondere
bei
Bildern
oder
Animationen/Filmen
erforderlich.
Bei
einer
barrierefreien Gestaltung sollte jede Graphik und
jedes Bild einen „sprechenden“ Alternativtext
bereitstellen, der die gleiche Information, die das
Bild transportiert, auch in textlicher Form bereitstellt.
Dies wird ermöglicht durch das ALT-Attribut im
<IMG>-Element, das diese Beschreibung enthält.
Bei Graphiken, deren Beschreibung nicht in kurzen
Texten ausreichend erfolgen kann, ist das
longdesc-Attribut zu verwenden, durch das eine
URL referenziert werden kann, unter der eine
ausführliche Beschreibung der Graphik oder des
Bildes abgelegt werden kann.
Auch der barrierefreie Einsatz von Bildern, die
reinen Layoutzwecken dienen, ist möglich. An dieser
Stelle sollte alt=““ eingesetzt werden, und ein
möglichst
sprechender
Dateinamen,
wie
spacer.gif o. Ä. verwendet werden, um deutlich
zu machen, dass diese Bilder keinerlei Information
transportieren. Jedoch sollten Graphiken, die bspw.
über Farben kenntlich machen, in welchem Bereich
eines Site man sich aufhält, diese Information auch
im alternativen Text tragen.
2.1.6 Skalierbare Darstellung
(Richtlinie 3.4)
Bei einer visuellen Darstellung wird es häufig eine
dem Design entsprechende optimale Größe aller
Elemente geben, die sich im Idealfall derart
gestaltet,
dass
sie
den
Anforderungen
durchschnittlicher BenutzerInnen entspricht. Um
jedoch auch Anforderungen derjenigen Benutzer zu
entsprechen, die auf eine größere visuelle
Darstellung angewiesen sind, sollten alle Maße und
Größen relativ definiert sein. Das bedeutet
beispielsweise bei der Textauszeichnung, dass
relative Einheiten, wie em oder %, den fixen
Einheiten, wie pt und px, vorzuziehen sind. Auch
bei der Definition von Elementgrößen ist dies
anzuwenden, wodurch alle BenutzerInnen in die
Lage versetzt werden, die Darstellung den eigenen
Erfordernissen entsprechend individuell anzupassen.
2.1.7 Navigation
(Richtlinien 3.1; 13.1; 13.2; 13.3; 13.5; 13.6)
Um eine barrierefreie Navigation zu gewährleisten,
sind verschiedene Punkte zu beachten. So sollte
hinsichtlich der Skalierbarkeit darauf geachtet
werden, dass Menüpunkte als Text und nicht
ausschließlich über Graphiken bereitgestellt werden.
Bei der Bezeichnung von Links ist es von
erheblicher Bedeutung, dass „sprechende“ und
zielführende Begriffe verwendet werden.
Der Navigationsblock sollte als solcher gekennzeichnet und zusammengefasst sein und von markanten
Punkten der Seite über Sprungmarken und Anker
erreichbar sein. Diese Sprungmarken sollten
lediglich Benutzern der linearisierten Version
angeboten werden (bspw. durch display:none
und visbility: hidden in der CSS-Datei).
Darüber hinaus sollte die Navigationseinheit auch
überspringbar sein, oder wahlweise am Ende der
linearisierten Darstellung liegen.
Ebenso über Sprungmarken erreichbar sein sollte
der Beginn des eigentlichen Inhalts. Jede Seite
sollte Links zu den wichtigen Seiten des Website
beinhalten, wie bspw. Inhaltsverzeichnis (Sitemap),
Startseite
(Homepage)
und
Kontakt
bzw.
Impressumsseite. Hilfreich ist die Verwendung
dieser semantischen Daten im <head>-Bereich
durch Einsatz von entsprechenden meta-Tags
(meta rel=). Diese Elemente werden zwar derzeit
nur von wenigen Browsern unterstützt, der Einsatz
ist aber hinsichtlich einer zukunftsorientierten
Programmierung zu empfehlen, da er keinen
„Schaden“ anrichten kann und im „schlimmsten“ Fall
lediglich nicht interpretiert wird.
2.2 Diskussion
In der Praxis ist es bei mangelnden Ressourcen
nicht immer möglich, einen Website komplett zu
überarbeiten. In diesen Fällen kann ein mehrstufiges
Vorgehen gewählt werden. In einem ersten Schritt
können die wichtigsten Seiten angepasst werden, in
dem bspw. Layouttabellen entsprechend der
Richtlinien möglichst barrierefrei gestaltet werden.
Tabellen zu Layoutzwecken sind allerdings immer
nur zweite Wahl. Daher sollte in einem zweiten
Schritt ein Relaunch des Sites erfolgen, bei dem ein
rein CSS-basiertes Layout getrennt von der
semantischen Auszeichnung des Inhalts angestrebt
wird. Dies zahlt sich langfristig aus, da Änderungen
der gesamten Website-Darstellung leicht über
Änderungen in einer einzelnen Datei erfolgen
können und die saubere Struktur jeder Seite
ebenfalls leichter zu handhaben ist.
Praxisprobleme ergeben sich auch dadurch, dass
Zugangstechnologien, Browser, aber auch Assistive
Technologien wie z. B. Sprachbrowser, sich nicht
durchgängig an W3C-Standards orientieren.
Das größte Problem allerdings besteht darin, dass
derzeit noch kein vollständig barrierefreien Quelltext
erzeugendes Content Management System (CMS)
bekannt ist. Da größere Web-Präsenzen aber auf
CMS angewiesen sind, stellt eine Entwicklung in
dieser
Richtung
derzeit
eine
wichtige
Herausforderung dar.
3. EVALUATION
Während der Gestaltung barrierefreier Seiten ist
eine
begleitende
Validierung
notwendig.
Grundsätzlich hat die WAI eine entsprechende
Vorgabe für diese Testphase beschrieben [6]. Da
dieser Prozess hier nicht ausführlich dargestellt
werden kann, werden im Folgenden nur die für die
Praxis besonders wichtigen Aspekte angesprochen.
Ganz wesentlich ist das Verständnis dafür, dass
viele der skizzierten Richtlinien nicht durch
automatische Tests überprüft werden können,
sondern
der
experten-basierten
Beurteilung
bedürfen. Dabei ist es insbesondere wichtig, dass
die Interpretation der Richtlinie und die Beurteilung
der Umsetzung klaren Regeln folgt, möglichst durch
erfahrene Fachleute durchgeführt wird und
entsprechend dokumentiert ist.
Dennoch bieten halbautomatische Testwerkzeuge
wertvolle Unterstützung. Zunächst hat sich das Tool
Bobby [7] etabliert, berücksichtigt aber nach
Meinung
der
Verfasser
unzureichend
die
Notwendigkeit
zu
manuellen
Tests.
Die
Auszeichnung „bobby-approved“ impliziert jedoch
Barrierefreiheit, obwohl mangels experten-basierter
Untersuchung diese so nicht gegeben sein muss.
Hilfreich sind daher Tools, die bei der Benutzung
deutlich darauf hinweisen, welche Punkte der
183
Mund, M., Leidermann, F. & Weber, H.
Anforderungen manuell zu überprüfen sind, und auf
zertifikatähnliche Logos verzichten.
Diese Forderung berücksichtigen die Online-Tools
„Cynthia Says“ [8] und „Wave 3“ [9]. „Cynthia Says“
erzeugt ein Abbild der WAI Checkliste und bewertet
lediglich die aus dem Quelltext automatisch zu
beurteilenden Punkte. Darüber hinaus werden
jedoch alle Richtlinien angezeigt, und die Gestaltung
macht deutlich, welche Aspekte durch expertenbasierte Evaluation zusätzlich zu testen sind. „Wave
3“ ist ein graphisches Werkzeug. Die zu
überprüfende Seite wird ergänzt um Symbole, die
Gesichtspunkte der Zugänglichkeit beurteilen.
Allerdings ist es auch hier nur möglich, einige
ausgewählte
Punkte
zu
überprüfen.
Eine
abschließende Beurteilung oder gar ein Zertifikat
liefert „Wave 3“ nicht. Die Kombination von „Wave
3“ und „Cynthia Says“ gibt schon einen ersten recht
guten Anhaltspunkt hinsichtlich der erreichten
Barrierefreiheit.
Daneben seien auch Tools erwähnt, die
Erweiterungen
von
Entwicklungswerkzeugen
darstellen (z. B. [10]) sowie die Fähigkeit einzelner
Browser, verschiedene Nutzungsarten zu simulieren
(z. B. [11]). Beispiele für den Einsatz von Opera für
erste Test auf Barrierefreiheit sind unter [12] zu
finden. Weitere Testwerkzeuge sind auf den Seiten
der WAI aufgeführt [13]
Darüber hinaus sind Tests mit Hilfe von assistiven
Technologien erforderlich (z. B. Sprachbrowser)
eingesetzt werden. Eine optimale Testsituation lässt
sich selbstverständlich unter Einbeziehung von
NutzerInnen mit den zu berücksichtigenden
Einschränkungen erreichen.
184
Schließlich soll darauf hingewiesen werden, dass für
alle Untersuchungen eine möglichst große Anzahl
an Seiten herangezogen werden sollte. Eine
Beschränkung der Evaluation auf einzelne
exemplarische Seiten muss gut begründet sein.
Abschließend bleibt der Hinweis, dass die
Evaluation
bzgl.
Barrierefreiheit
einigen
Interpretationsspielraum bietet. Daher bedarf es
einer dokumentierten und klar festgelegten
Vorgehensweise. Derzeit wird von den Autoren eine
solche Vorgehensweise sowie entsprechende
Vorlagen für die Dokumentation entwickelt.
4. REFERENZEN
[1] http://jurcom5.juris.de/bundesrecht/bitv
[2] http://www.w3.org/WAI
[3] http://www.w3.org/TR/WCAG10/
[4] http://validator.w3.org
[5] http://www.508compliant.com/tools.htm
[6] http://www.w3.org/WAI/eval/
[7] http://www.cast.org/bobby
[8] http://www.cynthiasays.com/
[9] http://wave.webaim.org
[10] http://www.macromedia.com/macromedia/acces
sibility
[11] http://www.opera.com
[12] http://www.ita-kl.de/barriererfrei
[13] http://www.w3.org/WAI/ER/existingtools.html
Referenten
Markus Mund studiert Wirtschaftsingenieurwesen an der Universität Kaiserslautern. Seit
November 2000 war er zunächst am Lehrstuhl für Industriebetriebslehre und
Arbeitswissenschaft beschäftigt und wechselte ein Jahr später an das dem Lehrstuhl
angeschlossene Institut für Technologie und Arbeit. Dort befasst er sich seit zwei Jahren
mit der Gestaltung und Evaluation von Zugänglichkeit bei webbasierten
Informationssystemen. Darüber hinaus ist er für den Internetauftritt des Institutes und des
Lehrstuhls verantwortlich.
Frank Leidermann ist seit April 2003 als Usability Consultant beim Internet Service
Provider Bluewin AG in Zürich tätig. Zuvor war er fünf Jahre am Institut für Technologie
und Arbeit (ITA) Kaiserslautern beschäftigt (Schwerpunkte: Usability-Engineering,
WebAccessibility und Design for All), unterbrochen von einem sechsmonatigen
Gastaufenthalt in der Arbeitsgruppe für Human-Computer Interaction and Assistive
Technologies (ICS-FORTH).
Harald Weber ist stellvertretender Leiter des Instituts für Technologie und Arbeit (ITA),
Kaiserslautern. Er bearbeitet u. A. Forschungsprojekte im Bereich der Barrierefreiheit von
Informations- und Kommunikationstechnologien. Schwerpunkt seiner Arbeit liegt auf dem
Gebiet des Inclusive Design, um Partizipation zu ermöglichen und Chancengleichheit zu
gewährleisten.
185
MOBILE USER INTERFACES
USABILITY ENGINEERING PROZESS BEI VODAFONE GLOBAL
Helmut Degen
Vodafone Holding GmbH
Global Products & Services
Mannesmannufer 2
40213 Düsseldorf
helmut.degen@vodafone.com, hdegen@acm.org
ABSTRACT
In diesem Beitrag wird die Rolle der User Experience
Gruppe bei Vodafone Global Products & Services
vorgestellt. Es werden der Usability Engineering
Prozess und am Beispiel des Projekts “MMS-Album“
vier
Besonderheiten
des
Prozesses
herausgearbeitet: 1. Beteiligte Projekt-Rollen, 2.
Meilensteine und Ergebnisse, 3. Design für
verschiedene Kanäle und Devices und 4. Analyse
und Evaluation im Prozess. Ein kurzer Ausblick über
die Weiterentwicklung des Prozesses wird gegeben.
Keywords
Usability Engineering Prozess, Kanäle, Devices,
Seamless Experience,
1. EINLEITUNG
Usability Engineering Prozesse in der Literatur (z.B.
[1,2]) beschreiben einen idealtypischen Ablauf
einzelner Phasen und Schritte. In der industriellen
Praxis sehen solche Prozesse häufig anders aus,
d.h. die Prozesse aus der Literatur werden an
Rahmenbedingungen und Ziele der industriellen
Praxis angepasst.
In diesem Beitrag soll am Beispiel eines Projekts,
dem so genannten MMS-Album, der angewandte
Products & Services beschrieben und die
Besonderheiten dieses angewandten Prozesses
herausgearbeitet werden.
Der Beitrag gliedert sich in folgende Abschnitte: In
Abschnitt 2 werden die Vodafone Gruppe und
Vodafone Global Products & Services (im folgenden
Vodafone Global genannt) vorstellt. Es wird
weiterhin die Rolle der User Experience Gruppe
innerhalb von Vodafone Global beschrieben. In
Stuttgart).
Proceedings of the
Abschnitt 3 wird das MMS-Album vorstellt. Es folgt
eine Beschreibung des angewandten Usability
Engineering Prozesses mit seinen Besonderheiten.
2. VODAFONE
2.1 Globaler Mobilfunk-Anbieter
Vodafone ist zur Zeit der weltweit größte MobilfunkAnbieter. Vodafone hält in 28 Ländern Beteiligungen
an Mobilfunkanbietern und in 7 Ländern ist
Vodafone eine Partnerschaft mit Mobilfunkanbietern
eingegangen. Am 31 März 2003 gab es ca. 119,7
Mio. Vodafone-Kunden.
Die Rolle von Vodafone Global ist es, für die
Vodafone-Landesgesellschaften
Produkte
und
Services zentral zu entwickeln, die dann
entsprechenden Länder ausgeliefert und installiert
werden. Die zentrale Entwicklung hat 3 wesentliche
Vorteile: 1. werden Kosten eingespart und 2. wird
sichergestellt, dass die Kunden weltweit identische
Produkte und Services angeboten bekommen und 3.
Findet ein internationaler Wissensaustausch statt.
2.2 User Experience Gruppe
Die Arbeit der User Experience (UE) Gruppe
innerhalb von Vodafone Global ist von dem
Qualitätsziel der “Seamless Experience“ bestimmt.
Hierunter
werden
im
wesentlichen
zwei
Qualitätsansprüche
verstanden.
Die
zu
entwickelnden Produkte und Services sollen eine
attraktive
und
einfach
zu
bedienende
erhalten.
Dieser
Qualitätsanspruch setzt eine benutzerzentrierte
Vorgehensweise voraus. Desweiteren soll die Marke
Vodafone
wiedererkannt
werden,
um
den
Bekanntheitsgrad zu steigern. Dies bedeutet, daß
User Interfaces mit der für die Markenbildung
zuständigen Abteilung abgestimmt werden.
Das Qualitätsziel “Seamless Experience“ wird in
folgenden Bereichen angestrebt:
1.
Zwischen mobilen Endgeräten unterschiedlicher
Anbieter, d.h. es wird eine anbieterunabhängige
User Experience angestrebt.
2.
Zwischen
mobilen
Endgeräten
und
internetbasierten Produkten und Services (Web
und WAP), d.h. es wird eine geräte- und
189
Degen, H.
kanalübergreifende
angestrebt.
User
Experience
3.
Zwischen
verschiedenen Produkten und
Services, d.h. es wird eine anwendungsübergreifende User Experience angestrebt.
4.
Zwischen verschiedenen Vodafone Landesgesellschaften, d.h. es wird für Reisende eine
ortsunabhängige User Experience angestrebt.
2.3 Entwicklungsprozeß
Im Entwicklungsprozess von Vodafone Global
arbeitet die UE Gruppe dem Produkt-Management
zu. Das Produkt-Management definiert zuerst ein
Produkt/Service, d.h. es legt u.a. das Marktsegment
und die Produkt-Feature fest. Die UE Gruppe
gestaltet
dann
die
entsprechende
Benutzungsoberfläche für das Produkt/Service.
Wichtigstes Ergebnis der UE Arbeit ist eine DesignSpezifikation, in der für die technischen Realisierer
die
dargestellt
und
beschrieben wird. Nach der Lieferung der DesignSpezifikation
und
weiterer
Dokumente
implementieren
technische
Realisierer
die
Applikation. Es schließt sich die Auslieferung und
Installation der Applikation in den Vodafone-Ländern
an.
3. MMS-ALBUM
Am Beispiel des MMS-Albums (MMS steht für
Multimedia Messaging Service) soll dies beispielhaft
erläutert werden. Vereinfacht gesagt handelt es sich
bei der MMS um eine SMS (Short Messaging
Service), mit der auch Bilder und Töne versendet
werden können. Das MMS-Album erweitert die
Möglichkeiten der MMS-Nutzung für den VodafoneKunden. Es bietet neben der Anwendung auf dem
mobilen Endgerät zusätzlich über Web und WAP die
Möglichkeit an, MMS zu erstellen, MMS zu
speichern, gespeicherte MMS zu organisieren und
MMS zu empfangen. Außerdem bietet das MMSAlbum
die Möglichkeit, gespeicherte MMS
freizuschalten,
d.h.
beliebigen
Personen
Zugriffsrechte auf gespeicherte MMS zu geben. Das
MMS-Album Release 1.2 wurde im April 2002
gelauncht.
Am Beispiel des MMS-Albums soll nachfolgend der
Usability Engineering Prozeß beschrieben und die
Besonderheiten des Prozesses bei Vodafone Global
herausgearbeitet werden.
4. USABILTIY ENGINEERING PROZESS
4.1 Rahmenbedingungen
Wichtige Größen, die den Usability Engineering
Prozess beeinflussen, sind die zur Verfügung
stehende Zeit und die Zielkanäle WAP und Web.
Die zur Verfügung stehende Zeit wird durch die
Release-Planung vorgegeben, die in der Regel 6
Monate beträgt. Für die UE-Arbeit verbleibt ein
190
Zeitfenster von ca. 10 Wochen für die Lieferung
einer Design-Spezifikation. Im Einzelnen gehört
hierzu, ein Design-Konzept zu erstellen und zu
evaluieren,
das
Design-Konzept
detailliert
auszuarbeiten und die Design-Spezifikation zu
erstellen, zu prüfen, zu überarbeiten und zu liefern.
Der zweite relevante Parameter sind die beiden
Kanäle WAP und Web. Mit 2 Kanälen erhöht sich
der Aufwand entsprechend; denn es ist nicht nur die
Design-Qualität für jeden Kanal sicherzustellen,
sondern auch die Konsistenz zwischen den Kanälen
(“Seamless Experience“). Dies bedeutet, dass der
Aufwand für das Design mehr als doppelt so hoch
ist.
4.2 Einzelne Prozeßschritte
Der UE Prozeß beginnt mit der Beschreibung des
Produkts durch den Produkt-Manager. Danach
beginnt die Arbeit der UE Experten. Es erfolgt in der
Regel zuerst ein Produkt-Benchmarking, d.h. der
Markt wird nach ähnlichen Produkten durchforstet
und erfolgreiche und/oder erfolg versprechende UE
Design-Prinzipien identifiziert. Es schließt sich die
Entwicklung eines Design-Konzepts an, in dem die
Prinzipien des Designs mit Wireframes dargestellt
werden und die zugehörigen Flüsse die
Zusammenhänge zwischen den Wireframes zeigen.
Danach erfolgt gegebenenfalls eine Anforderungsermittlung,
d.h.
Vertreter
der
betroffenen
Benutzergruppen werden in Einzelinterviews oder
Workshops
zu
ihren
Vorstellungen
und
Nutzungserfahrungen
hinsichtlich
der
zu
gestaltenden Anwendung befragt. Innerhalb der
Anforderungsermittlung werden die gestalteten
Design-Konzepte zur Evaluierung den InterviewPartnern
vorgelegt.
Die
Ergebnisse
der
Anforderungsermittlung fließen in die Überarbeitung
und Ausarbeitung des Design-Konzepts ein.
Das Design-Konzept wird dann ausgearbeitet und
das Ergebnis fließt in die Design-Spezifikation ein.
Wenn es die Zeit zulässt, werden die
Zwischenergebnisse
mit
Vertretern
der
Benutzergruppe (keine Projektbeteiligten) evaluiert.
Diese Ergebnisse fließen dann wiederum in die
Design-Spezifikation ein, die als Grundlage für die
technische Implementierung der Ziel-Applikation
verwendet wird.
In einigen Projekten wird nach der Erstellung der
Design-Spezifikation ein Mock-Up gebaut. Dieser
Mock-Up hat drei Funktionen: 1. Kommuniziert er
die Design-Spezifikation für alle Projektbeteiligten,
vor allem die Projekt-Ansprechpartner in den
Vodafone Landesgesellschaften und die späteren
technischen Implementierer. 2. ermöglicht der Mockup, die größten Usability-Probleme zu identifizieren
und zu eliminieren. 3. wird die Vollständigkeit und
Korrektheit
der
Design-Spezifikation
selbst
überprüft.
Im Falle von Änderungen wird nach der Mock-UpErstellung die Design-Spezifikation angepasst und
an die technischen Realisierer ausgeliefert.
Im Rahmen des Projekts MMS-Album verlief der
Prozess featuregetrieben, d.h. es standen nicht
Benutzergruppen
mit
ihren
Szenarien
als
Ausgangspunkt der Gestaltungsarbeit, sondern eine
Featureliste. Damit einher geht die Release- und
Ressourcenplanung, die ebenfalls durch die
Featureliste bestimmt wird. Dies führte zu einer
suboptimalen Qualität der Benutzungsoberfläche,
womit die vorab beschriebenen strategischen Ziele
nicht erreicht werden können. Deshalb wurde diese
Herangehensweise in diesem und in anderen
Projekten geändert zu einem benutzerzentrierten
Ansatz. Im Mittelpunkt stehen Benutzergruppen mit
ihren bevorzugten Szenarien, für die dann DesignKonzepte und gleichzeitig die zugehörigen
Featurelisten erstellt werden. Die Projekt- und
Ressourcenplanung basiert jetzt ebenfalls auf dieser
benutzerzentrierten Vorgehensweise. Dies führte
beispielsweise dazu, daß mehr Ressourcen für die
Gestaltung der Benutzungsoberflächen eingeplant
werden.
Insgesamt
führt
die
veränderte
Vorgehenweise zu einer höheren Qualität von
Benutzungsoberflächen und letztendlich zu einer
Zielerreichung
im
Hinblick
auf
“Seamless
Experience“. Mit diesem Paradigmen-Wechsel im
Entwicklungsprozess wird deutlich, wie wichtig für
Vodafone die Qualität der Benutzungsoberflächen
ist.
4.3 Besonderheiten des Usability Engineering
Prozesses
4.3.1 Beteiligte Projekt-Rollen
Wie sich dies bereits bei der Beschreibung des
Prozesses angedeutet hat, wird der gesamte
Prozess von den Produkt-Managern begleitet. Die
Produkt-Manager achten darauf, dass sich die
definierten
Produkt-Anforderungen
in
den
widerspiegeln.
Häufig
beteiligen sich die Produkt-Manager bei der
Ideensammlung und Evaluation des DesignKonzepts. Obwohl die UE Experten über
Entscheidungskompetenz im Hinblick auf DesignEntscheidungen haben, nehmen die ProduktManager die Design-Konzepte mit ab.
Je nach Projekt ist es ebenfalls möglich, daß das
Design-Konzept
auch
von
Technik-Experten
evaluiert wird.
4.3.2 Meilensteine und Ergebnisse
Es gibt 3 wichtige Meilensteine für die Gestaltung
der Benutzungsoberflächen. Der erste Meilenstein
ist das Vorliegen des Feature-Dokuments, mit dem
das Produkt/Service spezifiziert wird. Dies stellt die
Grundlage
für
die
Gestaltung
der
Benutzungsoberfläche dar. Der zweite Meilenstein
ist die Abnahme des Design-Konzepts. Zu diesem
Zeitpunkt
liegen
alle
Flows,
die
Benutzungsoberflächen als Wireframes und die
wichtigsten Benutzungsoberflächen in visuell
gestalteter Form vor. Der dritte Meilenstein ist die
Lieferung der Design-Spezifikation einschließlich
aller Anhänge wie Assets, Lokalisierungstabellen,
Wording-Tabellen,
Message-Tabellen,
HilfeTabellen und Mock-Ups.
4.3.3 Design für verschiedene Kanäle und
Devices
Die Benutzungsoberflächen werden für mehrere
Kanäle (Web, WAP) und Devices (PC, mobiles
Endgerät) gestaltet. Aufgrund des Geschäftsmodells
von Vodafone liegt die Priorität hierbei bei WAP. Bei
der Gestaltung des Design Konzepts wird mit dem
WAP begonnen und danach die Konzepte auf das
Web übertragen und erweitert.
4.3.4 Analyse und Evaluation im Prozess
Der in der Literatur beschriebenen Usability
Engineering Prozess (z.B. [1,2]) hat eine analytische
Phase, in der Informationen gesammelt werden und
eine
anschließende
gestalterisch-konstruktive
Phase, in der Benutzungsoberflächen gestaltet und
evaluiert werden. Die Abfolge von Analyse- und
Design-Phase ist besonders dann sinnvoll, wenn
eine geringe Kenntnis der Benutzererwartungen und
–gewohnheiten vorliegt. Diese Vorgehensweise setzt
aber voraus, dass ausreichend Zeit zur Verfügung
steht, um nach der Analysephase die Ergebnisse
zusammenzufassen und Benutzungsoberflächen zu
gestalten und zu evaluieren.
Da es sich bei dem MMS-Album um eine KonsumerAnwendung handelt, ist potentiell jeder Designer
auch ein Benutzer der Anwendung. Insgesamt liegen
damit, z.B. im Vergleich zu speziellen BusinessAnwendungen, relativ viele Kenntnisse über
Benutzererwartungen und –gewohnheiten vor.
Weiterhin ist der Zeitraum für die Erstellung einer
Design-Spezifikation insgesamt relativ begrenzt.
Deshalb wird eine Analyse in eine Design-Phase
eingebettet. Bevor eine Analyse mit Vertretern der
Benutzergruppen
(keine
Projektbeteiligten)
durchgeführt wird, werden Konzept-Varianten
erstellt. Im Rahmen der Analyse werden diese als
Design-Vorschläge den Beteiligten gezeigt werden,
beispielsweise nach einer offenen Befragung.
Dasselbe gilt für die Evaluations-Phase. Die
Evaluation (z.B. ein Usability Test) wird ebenfalls
mit Vertretern der Benutzergruppen (keine
Projektbeteiligten) durchgeführt. Im Rahmen der
Evaluation werden neben den eigentlichen
Evaluationsaufgaben den Teilnehmern AlternativVorschläge vorgelegt. Diese Vorgehensweise hat
das Ziel, die Auswertung möglichst effizient zu
halten
Eine hohe Qualität der Benutzungsoberflächen von
Produkten und Services ist ein zentrales
191
Degen, H.
Geschäftsziel von Vodafone. Hierbei spielt der
Aspekt der “seamless experience” eine zentrale
Rolle. Im Rahmen kurzer Release-Zyklen kann der
in der Literatur beschriebene Usability Engineering
Prozess ohne zusätzliche Anpassungen nicht
angewendet werden. Wichtige Merkmale des
angewandten Prozesses sind die Beteiligung von
Produkt-Managern während des gesamten UsabilityEngineering Prozesses. Die Projektpraxis hat
gezeigt, dass mit einem featuregetriebener ProzeßApproach der Qualitätsanspruch nicht erreicht
werden
kann.
Deshalb
wurde
der
Entwicklungsprozeß zu einem benutzerzentrierten
Ansatz. Drei Meilensteine (Feature-Dokument,
Design Konzept, Design Spezifikation) sind für die
Gestaltung wichtig. Innerhalb des Prozesses werden
Analyse- und Evaluationstätigkeiten konsequent in
Design-Aktivitäten integriert. Innerhalb der beiden
Aktivitäten wird systematisch mit vorbereitetem
Design-Vorschlägen gearbeitet, um die vorhandenen
Zeitfenster einzuhalten.
Dokumenten-Vorlagen) kann insbesondere die gute
Zusammenarbeit mit dem Produkt-Managern die
Projektarbeit wesentlich vereinfachen. Hier genügen
aber nicht nur fachliche Qualitäten, sondern
insbesondere kommunikative Fähigkeiten und eine
Offenheit für die Ziele und Belange der ProduktManager.
ACKNOLEDGEMENT
Ich danke Michael von Roeder für die kritische
Dursicht
und
die
konstruktiven
Verbesserungsvorschläge.
6. REFERENCES
[1] ISO 13407: Human-Centred Design Processes
for Interactive Systems, ISO/IEC 13407: 1999.
[2] Nielsen, J.: Usability Engineering. Morgan
Kaufmann (1993).
Der Prozess wird beständig weiterentwickelt. Neben
der
Ausarbeitung
von Prozess-Tools (z.B.
192
Referent
Dr. Helmut Degen arbeitet seit Beginn des Jahres bei der Vodafone Holding GmbH
und ist für die Gestaltung von Messaging-Produkten verantwortlich. Zuvor war er als
Principal Consultant im Competence Center „User Interface Design“ der Siemens AG
tätig, hier verantwortlich für den Aufbau einer E-Business-Gruppe und die Gestaltung
von E-Business-Anwendungen. Helmut Degen entwickelte das JIET Design ProzessFramework für webbasierte E-Business-Applikationen. JIET wurde in internationalen
Projekten angewendet und international publiziert. Zuvor arbeitete er an der Freien
Universität Berlin, an der er im Fach Informationswissenschaft promoviert. Helmut
Degen studierte Informatik, Betriebswirtschaftslehre und Philosophie an der
Universität Karlsruhe (TH) und Semiotik an der Technischen Universität Berlin.
Sein Hauptinteresse gilt der Optimierung von Design-Prozessen unter
Berücksichtigung der Qualität von User Interfaces und den bestehenden
Rahmenbedingungen in der industriellen Praxis. Sowohl die interdisziplinäre
Ausbildung wie auch die interdisziplinäre und internationale Erfahrung sind Grundlage
für eine erfolgreiche Projektarbeit und den Austausch zwischen Wissenschaft und
Praxis.
193
KLEINER, BUNTER, LUSTIGER –
AKTUELLE HERAUSFORDERUNGEN FÜR DIE USER INTERFACEGESTALTUNG MOBILER TELEFONE
Ulrich Leiner
Siemens AG, ICM
Haidenauplatz 1
D-81667 München
ulrich.leiner@siemens.com
ABSTRACT
Mobile Telefone werden einerseits immer stärker
Fashion-Artikel, andererseits sind sie auch mehr und
mehr multifunktionale Alleskönner. In unserer
Präsentation möchten wir dieses Spannungsfeld
ausleuchten
und
daraus
resultierende
Fragestellungen an das User Interface (UI) Design
herausarbeiten. Wir diskutieren Designalternativen,
und zeigen anhand aktueller Produktbeispiele
Lösungsmöglichkeiten auf.
Keywords
Mobile phones, handheld devices, miniaturization,
smart phones, user interface design process,
hardware design.
1. EINLEITUNG
Mobile Telefone sind im Jahr 2003 aus dem
Alltagsleben einer großen Anzahl von Menschen
weltweit nicht mehr wegzudenken. Die Handys
weisen
dabei
einen
immer
größeren
Funktionsumfang auf.
Gerade weil somit der Funktionsbedarf der meisten
Nutzer erfüllt oder gar übererfüllt ist, treffen immer
mehr Käufer ihre Produktentscheidung nach Fun &
Fashion-Kriterien wie Design, Farben, Form und
Größe und Vorzeige- und Unterhaltungswert des
Telefons.
Im Vergleich zu PC-basierten Systemen, deren
Nutzungskontext relativ stabil ist, und deren Einund Ausgabeelemente (Tastatur, Maus, Display)
größtenteils standardisiert sind, variieren Handys in
Displaygröße und Tastatur ziemlich stark, ein
Standardisierungsprozess
hat
(noch)
nicht
stattgefunden
Pia Honold
Siemens AG, ICM
Haidenauplatz 1
D-81667 München
pia.honold@siemens.com
Weit über eine Milliarde weltweiter Nutzer bedingen
Bedien- und Anwendungsszenarien, die wie kaum
ein zweites technisches Alltagsgerät, quer durch alle
Bevölkerungs- und Altersgruppen, Regionen und
Kontinente gehen, der Nutzungskontext ist daher
sehr breit.
Der Geschäftsbereich „Mobile“ der Siemens AG hat
dieser Herausforderung Rechnung getragen und vor
über 8 Jahren die Abteilung „Competence Center
User Interface“ gegründet. Sie beschäftigt sich mit
den speziellen Anforderungen an die Gestaltung
leicht bedienbarer mobiler Endgeräte. Wir möchten
aus
der
Praxis-Sicht
beschreiben,
welche
Anforderungen an die Gestaltung von User
Interfaces sich in unserem Geschäft tagtäglich
ergeben, gemeinsam mit den Teilnehmern der
Tagung Gestaltungsalternativen diskutieren, und
anhand
von
Produktbeispielen
Lösungsmöglichkeiten aufzeigen.
2. EINE RADIKALE ANTWORT: DIE
FASHION-PHONES VON XELIBRI
Das Handy wird immer mehr als Accessoire
betrachtet, und unterliegt damit immer stärker den
gängigen Modetrends. Nicht Funktion, sondern
Marke und Trend bestimmen bei Geräten gerade für
eine junge Zielgruppe die Anforderungen an das
Design. In diesem Frühjahr hat Siemens daher eine
neue Marke eingeführt - Xelibri -, die diese
Entwicklung
bewusst
aufgreift
und
den
techniklastigen Feature-Zählern eine radikale
Alternative entgegenstellt.
Stuttgart).
Proceedings of the
194
Abbildung 1: Gerät ohne Nummerntastatur Xelibri 3
Kleiner, bunter, lustiger – aktuelle Herausforderungen für die User Interface-Gestaltung mobiler Telefone
2.1 UI: Wenige Funktionen, neuartige
Tastaturen
Die
Xelibri-Telefone
stellten
zwei
neue
Anforderungen an das UI-Design, die nur auf den
ersten Blick unabhängig voneinander zu sein
scheinen:
•
•
Verringerung und Vereinfachung der Funktionen
des Geräts und darauf aufbauend eine
Verschlankung
des
Menübaums
als
Funktionszugang. Seien es Cell Broadcast oder
Bluetooth, nahezu alle Funktionen wurden in
Frage gestellt oder wenigstens deutlich
reduziert. Unter der Annahme, dass die meisten
Anwender nur einen Bruchteil des angebotenen
Funktionsumfangs nützen, halten wir dies für
eine plausible und Erfolg versprechende
Hypothese. Allerdings ist nicht ausgeschlossen,
dass der psychologische Aspekt “mehr fürs
selbe Geld” bei der Kaufentscheidung doch den
Ausschlag
zugunsten
eines
reichhaltig
ausgestatteten Geräts geben könnte.
Reduktion der Hardware-Eingabeelemente bis
zum möglichen Minimum. Bei allen Geräten
wurde die Send- und End-Tasten eliminiert und
ihre Funktion in die weiterhin vorhandenen
Softkeys aufgenommen.
2.2 Beispiel aus der Praxis
Beim Produkt Xelibri 3 wurde sogar ganz auf die
Nummerntastatur verzichtet und nur eine 4-WegeNavigationstaste eingesetzt. Neben der erweiterten
Spracheingabe
(sprecherunabhängige
Zifferneingabe) wurde auch die SMS-Funktion auf die
Navigationstaste abgebildet.
Dazu wurde eine komplett neue zweistufige
Zeichen-Eingabe erarbeitet und implementiert.
Usability-Tests zeigten, dass diese Methode zwar
nicht gleichwertig zum 12-er-Ziffernblock ist, jedoch
nach etwas Trainingszeit als tauglich für kurze
Mitteilungen eingestuft werden kann.
3.1 Eine Antwort ist nicht genug
Unsere Studien und Testergebnisse zeigen, dass es
bei einer derart vielfältigen Nutzergruppe nicht
ausreicht, nur einen Bedienweg, nur eine
Möglichkeit der Aufgaben-Durchführung anzubieten.
Daher bieten wir in unseren Mobiltelefonen fast
überall verschiedene UI-Lösungen an, die mit dem
Erfahrungsstand aber auch dem Nutzungskontext
der Anwender korrelieren. Vereinfacht gesagt,
unterscheiden wir drei Kenntnis- und NutzungsNiveaus:
•
Anfänger, die nicht oder noch nicht über
nennenswerte Erfahrung mit unseren Geräten
verfügen. Für diese Anwendergruppe ist das
schrittweise Hinund Durchführen der
Wunschfunktion optimal. Pro Schritt dürfen nicht
zu
viele
Einzelinformationen
und
Entscheidungsoptionen angeboten werden. Im
Idealfall steht auch noch eine Hilfefunktion zur
Verfügung.
•
Standard-Anwender,
mit
einem
mittleren
Kenntnisstand, an denen sich die Hauptlösung
orientiert. Für diese Nutzergruppe gilt, dass
neben der Klarheit der Bedienschritte auch die
Effizienz der Zielerreichung an Gewicht gewinnt
und als Kriterium für optimale Usability
herangezogen wird.
•
Power-User, die bereit sind auch komplizierte
Bedien-Situationen
zu
durchlaufen
oder
Shortcuts zu erlernen, um Zwischenschritte und
Zeit einzusparen.
Diese etwas abstrakt klingende Kategorisierung
findet ihre Umsetzung in ganz konkreten UI-DesignLösungen unserer Geräte:
•
Daher halten wir diese Lösung für eine gelungene
Synthese aus Miniaturisierung, Minimalistik der
Bedienelemente und Absicherung der Bedienbarkeit.
Standardlösung ist dieselbe Navigation auf
einem Ikon-Gitter oder in Listen durchzuführen,
die mehrere Einträge gleichzeitig anzeigen. Die
Verwendung der Zifferntasten als Shortcuts zu
ihnen zugeordneten Einträgen, kann schon in
Richtung “Fortgeschritten” eingeordnet werden.
3. PASSENDE BEDIENFÜHRUNG FÜR
JEDES NUTZER-NIVEAU
Wie eingangs erwähnt, zeichnen sich Mobiltelefone
durch eine kaum zu übertreffende Diversität ihrer
Anwender aus: Vom Dauertelefonierer, über die
SMS-Süchtigen bis hin zum sporadischen NurNotfall-Einsatz reicht die Spannweite. Dies stellt
eine spannende Usability-Herausforderung: Wie
muss das User Interface gestaltet sein, damit alle
unterschiedlichen Anwendertypen sich optimal
zurechtfinden und so ihre Zielfunktionen sicher,
schnell und fehlerfrei ausführen können.
Beispiel 1: Auffinden einer Applikation im
Funktions-Menü: Einsteiger-Lösung ist zB die
Anzeige nur eines Eintrags im Display. Durch
Ab-/Auf-Navigation
und
Selektion
wird
schrittweise die Zielapplikation erreicht.
Typische
Power-User-Bedienung
ist
die
Verwendung von “Hotkeys”, d.h. die Softkeys
und die Zifferntasten aktivieren bestimmte
Funktionen direkt aus Idle durch langes
Drücken. Schließlich ist auch die Aktivierung der
Sprachsteuerung und die Spracheingabe der
Zielapplikation eine Power-User-Lösung.
•
Beispiel 2: Ein weiteres Beispiel für diese
Varianten-Technik ist das Senden einer SMS: im
einfachsten Fall geht man schrittweise über
Optionen
Senden
–
Auswahl
–
195
Leiner, U. & Honold, P.
Nummereingabe direkt oder aus Adressbuch –
OK. Streng schrittweises Vorgehen nach einer
möglichst einheitlichen Logik sind auch hier gut
erkennbar.
Die mittlere Lösung verwendet die Sequenz:
Sendetaste - Nummereingabe direkt oder aus
Adressbuch – OK. Die Beschleunigung wurde durch
einen Tasten- und Logikwechsel erkauft.
Eine Power-User-Lösung wäre es, sich vorab unter
“SMS-Profile/Empfänger”
die
5
häufigsten
Empfänger
einzutragen
und
die
Profile
entsprechend zu benennen. Beim Abschicken hätte
man dann die Sequenz: Optionen – Send via –
Profil – OK. Wenn man dann noch berücksichtigt,
dass die “send via”-Option statt mit 10 Abwärtsklicks
auch mit 2 Aufwärtsklicks erreichbar ist, hat man
den Status “Power-User” sicherlich erreicht.
Eine
flexible,
neuartige
Gestaltung
der
Nummerntastatur ermöglichte hier eine Einsparung
von ca. 80% der Größe konkurrierender Modelle.
Usability Tests zeigten zwar, dass z.B. das
Schreiben von SMS einen gewissen Lernaufwand
erforderten, und Zweihandbedienung von den
Nutzern favorisiert wurde. Durch die große
Gestaltung der Nummerntasten konnte aber
dennoch die Bedienbarkeit optimiert werden.
4. KLEINER IST BESSER – ODER?
Die Mobilität von Handys wird auch dadurch
gewährt, dass sie so klein sind, dass die Nutzer sie
mühelos überall mitnehmen können. In den letzten
Jahren gab es daher einen stetigen Prozess der
Miniaturisierung. Auf der anderen Seite gehören
multimediale Anwendungen (Photo, Video) und
Datendienste (E-Mail, Chat, Internet) mittlerweile
zum Featureset der Oberklassengeräte. Daraus
resultiert, dass Displays zur Darstellung dieser
Informationen möglichste groß sein sollten. Das
bedeutet, dass möglichst große Displays in
möglichst kleine Geräte integriert werden müssen.
4.1 UI-Design Herausforderungen
Aus der Forderung „kleines Gerät/großes Display“
ergibt sich die Gefahr, dass an anderen Elementen,
z.B. der Größe der Tastatur, gespart wird. Aber:
Während die Technologien miniaturisiert werden
können, sind die Maße des menschlichen Körpers
offensichtlich weniger flexibel. Aufgabe des Usability
Spezialisten ist daher, gemeinsam mit IndustrieDesignern im Spannungsfeld Miniaturisierung –
Usability bedienfreundliche Lösungen zu generieren.
Abbildung 2: SX1 mit 2x6 Nummerntastatur
Eine weitere Möglichkeit, die neue Tastenanordnung
funktional zu Nutzen besteht in der Möglichkeit, die
Nummerntasten in spezifischen Anwendungen als
Softkeys zu nutzen. Als Beispiel sei hier etwa die
Funktion „Radio“ angeführt. Generell ergab sich
durch die Tastennordung ein größerer Gestaltungsspielraum.
4.2 Design-Alternativen
Konzentrieren wir uns im folgenden auf die
Widerspruch: Großes Display, bedienbare Tastatur.
Folgende Designalternativen können dabei etwa
erörtert werden:
•
Slider (z.B. Nokia 7650, Samsung SPH-N270),
•
Clamshell (z.B. Samsung SGH-V200),
•
Monoblock Design mit 2x6 Tastatur (Siemens
SX1).
Für das SX1 standen wir genau vor der
beschriebenen Fragestellung: Eine Vielzahl von
Funktionstasten und Nummerntasten mussten im
Design „untergebracht“ werden.
196
Abbildung 3: Nutzung von Nummerntasten als Soft
keys
5. VISUAL DESIGN: EINBINDUNG NEUER
KOMPETENZEN
Wie bereits beschreiben, werden die Displays immer
größer – und sie werden auch immer farbiger und
brillanter. Somit erhält das „Visual Design“ der
Bedienoberflächen fast einen ebenso hohen
Stellenwert für die Nutzerakzeptanz wie das
Industriedesign.
Kleiner, bunter, lustiger – aktuelle Herausforderungen für die User Interface-Gestaltung mobiler Telefone
5.1 UI-Design Herausforderungen
Im Bereich der Mobiltelefone besteht ein großer
Erfahrungsschatz, wie man mit den Restriktionen
kleiner schwarz-weiß Displays zu optimalen
Ergebnissen gelangen kann. Durch die neuen
Möglichkeiten in punkto Größe und Farbe bestand
die Herausforderung darin, durch das Grafikdesign
diese
technischen
Neuerungen
maximal
auszuschöpfen und für die Kunden sichtbar zu
machen.
5.2 Design-Alternativen
Wie lässt sich die hohe Qualität eines Displays
durch das „Visual Design“ umsetzen? Folgenden
Alternativen wurden diskutiert
•
Symbolische Darstellungen 2D,
•
Symbolische Darstellungen 3D,
•
Realistische Darstellungen,
•
Hyperrealistische Darstellung.
Für das SX1 entschieden wir uns für einen
hyperrealistischen Stil. Dieser hat den Vorteil, dass
er durch die schwebend 3-dimensionale Gestaltung
auf der einen Seite einen durchgängigen Stil
generiert, auf der anderen Seite die Begrenzungen
eines naturalistisch/realistischen Stils aufhebt .
Abbildung 4: Hauptmenüicons SX1
6. AUSBLICK
Das Mobiltelefon hat sich in den letzten Jahren vom
Kommunikationsgerät einerseits zum FashionArtikel,
andererseits
zum
multifunktionalen
Alleskönner entwickelt. Die Aufgabe für Usability
Spezialisten ist dabei, die Belange der Endnutzer zu
vertreten, und gleichzeitig Produktmanager und
Marketing
in
der
Verwirklichung
ihrer
Produktvisionen zu unterstützen. Ziel dabei ist nicht,
einen Kompromiss zwischen allen beteiligten
Parteien
(Marketing,
Softwareentwicklung,
Industriedesign, um nur einige zu nennen) zu
schaffen, sondern gemeinsam eine optimale
Nutzungserfahrung zu gestalten.
197
Leiner, U. & Honold, P.
Referenten
.
Dr. Ulrich Leiner leitet das Team „Conceptual User Interface Design for Mobile Phones“
im Bereich ICM (Information and Communication mobile) der Siemens AG. Er studierte
und promovierte in angewandter Mathematik and der TU München. Er arbeitet seit 1989
innerhalb Siemens, zuerst in der Zentralabteilung Technik auf den Gebieten
Computeranimation, 3D-Interaktion, Multimedia, User Interface Design und
Managementsysteme,
sowie
selbstgenerierende
User
Interfaces
in
der
Anlagensimulation. 1998 wechselte er ins „Kompetenzzentrum User Interfaces“ für
Mobil- und Festnetztelefone. Seine Aufgaben umfassen die firmenweite Definition der
Bedienkonzepte für Siemens-Mobiltelefone unter ergonomischen, funktionalen und
emotionalen Aspekten.
Dr. Pia Honold ist im Team „Conceptual User Interface Design for Mobile Phones“ im
Bereich ICM (Information and Communication mobile) der Siemens AG tätig.
Schwerpunktmäßig beschäftigt sie sich mit der UI-Gestaltung für Smartphones.
Pia Honold studierte und promovierte in Psychologie an der Universität Regensburg. In
ihrer Dissertation „Interkulturelles Usability Engineering“ beschäftigte sie sich mit der
Frage, ob und wie Usability Spezialisten technische Systeme für die Nutzung in anderen
Ländern anpassen können. Sie arbeitet seit 1996 innerhalb Siemens, zuerst in der
Zentralabteilung Technik in der Abteilung „User Interface Design“.
Ihr Hauptinteresse gilt der Einbeziehung zielgruppenspezifischer Endnutzer und ihrer
Anforderungen in den Entwicklungsprozess mobiler Geräte, und der Berücksichtigung
kulturspezifischer Unterschiede in das Produktdesign.
198
UI DESIGN PATTERNS FÜR NAVIGATIONSSYSTEME
AUF MOBILEN GERÄTEN
Fabian Hermann
Fraunhofer IAO,
Competence Center Human-Computer Interaction
Nobelstr. 12, D-70569 Stuttgart
Fabian.Hermann@iao.fhg.de
http://www.hci.iao.fhg.de
ABSTRACT
In diesem Beitrag wird der Ansatz der Design
Patterns für das UI-Desgin vorgestellt. Am Beispiel
einer
Design
Pattern-Sprache
für
mobile
Applikationen, im Besonderen Navigationssysteme,
die im Rahmen des Forschungsprojekts SAiMotion
entwickelt wurde, werden Erfahrungen für die
praktische
Anwendung
des
Ansatzes
in
Entwicklungsprojekten diskutiert.
Keywords
Design
Patterns,
User
Interface
Navigationssysteme, mobile Applikationen
Design,
1. EINLEITUNG
Ursprünglich von Christopher Alexander in den
1970er Jahren für architektonische Gestaltungsprobleme entwickelt [1, 2] und 1987 im Software
Engineering aufgegriffen [4], wird der Design
Pattern-Ansatz in den letzten Jahren auch für das
User Interface- und Interaction Design als viel
versprechende Methode gehandelt [3]. Ziel ist es,
mit
gut
strukturierten
und
interdisziplinär
verständlichen Beschreibungen bewährter “MusterLösungen” für Gestaltungsprobleme gesammeltes
Design-Wissen in verständlicher und allgemein
gültiger Form zu katalogisieren. Ein einzelnes
Design Pattern beschreibt eine Lösung eines
wiederkehrenden
Design-Problems
und
gibt
Beispiele für konkrete Umsetzungen. Eine
Sammlung von Design-Patterns wird in einer
Sprache strukturiert, d.h. einer hierarchischen
Struktur von allgemeinen, abstrakten Problemen bis
zu konkreten, spezifischen Designfragen.
Stuttgart).
Proceedings of the
Rainer Gibbert
Fraunhofer IAO,
Competence Center Human-Computer Interaction
Nobelstr. 12, D-70569 Stuttgart
Rainer.Gibbert@iao.fhg.de
http://www.hci.iao.fhg.de
In diesem Beitrag stellen wir ein Beispiel für eine
Design-Pattern-Sprache vor, die im Rahmen des
Verbundprojekts SAiMotion (Situation Awareness in
Motion) der Fraunhofer-Gesellschaft entstanden ist.
In dem vom BMBF geförderten Projekt wird ein
mobiles Informationssystem entwickelt, das den
Besucher
in
einer
komplexen
Umgebung
personalisierte
und
situativ
angepasste
Informationen
bereitstellt.
Als
ein
Anwendungsszenario
unterstützt
es
die
Vorbereitung, Durchführung und Auswertung von
Messebesuchen. In SAiMotion wurde umfangreiche
Studien und Usability-Tests für die Entwicklung
benutzergerechter Kartendarstellungen auf mobilen
Endgeräten durchgeführt. Ziel der Entwicklung der
Design-Pattern-Sprache
war
es,
dieses
ergonomische Wissen integriert zu sammeln und
aufzubereiten.
Neben den Patterns für das Anwendungsgebiet der
Navigationssysteme wurde eine abstrakt gehaltene
Design Pattern-Sprache entwickelt, die Richtlinien
für die Gestaltung mobiler Applikationen im
Allgemeinen bietet. Insgesamt wurden so zwei
Design Pattern-Sprachen erarbeitet, die zwar keine
Ansprüche auf Vollständigkeit erheben, aber
dennoch als Unterstützung bei der Entwicklung
ähnlicher Systeme dienen zu können.
Im Folgenden stellen wir die Struktur der DesignPattern-Sprachen sowie ein konkretes Beispiel vor
und diskutieren abschließend die Relevanz des
Ansatzes für den Einsatz in Entwicklungsprojekten.
2. DESIGN PATTERNS FÜR NAVIGATIONSSYSTEME AUF MOBILEN GERÄTEN
Ausgehend von der Wurzel der Pattern-Hierarchie –
dem Pattern “Navigation System” – wird zunächst
zwischen den verschiedenen Anwendungsbereichen
von Navigationssystemen – der Fahrzeugnavigation
und der Fußgängernavigation – unterschieden.
Letztere unterteilt sich wiederum in Innen- und
Außennavigation. Alle weiteren Patterns teilen sich
dann nach den drei Hauptaufgaben von
Navigationssystemen auf – der Routenplanung, der
Wegführung sowie den Interaktiven Karten (vgl.
Abb. 1).
199
Hermann, F. & Gibbert, R.
dem Anwender Orientierung in der Karte geben (vgl.
Abb. 3 und 4).
IN-CAR-NAVIGATION
NAVIGATION SYSTEM
SLOW -TRAVELERNAVIGATION
INTERACTIVE MAPS
INDOOR-NAVIGATION
INTERACTIVE MAPS
PLANNING A ROUTE
OUTDOOR-NAVIGATION
ROUTE GUIDANCE
OVERVIEW
Abb. 1: Haupt-Pattern und Patterns zu den
Anwendungsbereichen und Hauptaufgaben
Patterns der Routenplanung (vgl. Abb. 2)
beschreiben unter anderem, wie ganze Routen als
Favoriten abzuspeichern sind oder wie neue Routen
mit Start, Ziel, Zwischenstationen und zu
vermeidenden Bereichen angelegt werden können.
Weiterhin wird erläutert, wie verschiedenen
Eingabemöglichkeiten
wie
Texteingabe,
Listenauswahl, Auswahl aus Adressbuch und
Favoriten oder direkte Kartenwahl gestaltet werden
können und wann welche dieser Möglichkeiten
angeboten werden sollte.
PLANNING A ROUTE
ROUTE FAVORITS
CREATING NEW ROUTES
ROUTE TYPES
LEVEL OF DETAIL
DEPARTURE AND
DESTINATION
HELICOPTER
FUNCTION
ADAPTIVE INTERACTIVE
LEGEND
NAVIGABLE
OVERVIEW W INDOW
PANNING
DISCRETE MOVEMENTS
USING
DOUBLE CLICKING
LIST SELECTION
CONTINUOUS PANNING
USING
SCROLL BARS
CONTINUOS PANNING
USING
DRAG'N'DROP
In den Wegführungs-Patterns (vgl. Abb. 5) werden
Lösungen zur Darstellung einer konkreten Route und
der Navigation entlang dieser gegeben. So können
Routen einerseits als Ganzes dargestellt werden,
beispielsweise in einer interaktiven Karte oder als
Anweisungsliste. Eine inkrementelle Darstellung der
Abbiegeanweisungen in 2D, 3D oder einfach als
textuelle Ausgabe auf dem Bildschirm oder als
Sprachausgabe kann jedoch auch sinnvoll sein.
Weiterhin werden Patterns zu konkreten Elementen
einer
Anweisung
wie
Entfernungsbalken,
Pfeildarstellungen in Piktogrammform oder auch zu
wichtigen Landmarks beschrieben.
EVASION
ROUTE GUIDANCE
INTERSTATIONS
ADDRESS BOOK
FAVORITE ADDRESSES
MAP SELECTION
POINTS OF INTEREST
INSTRUCTIONS LIST
FUZZY TEXT ENTRY
DISCRETE MOVEMENTS
USING
BUTTONS
Abb. 4: Patterns zu Interaktiven Karten II
INCREMENTAL
PRESENTATION
ROUTE AS A WHOLE
TEXT ENTRY
NIGHT VIEW
SIMILAR RESULTS
2D MAPS
CARD ORIENTATION
(user direction vs. north)
PSEUDO-REALISTIC
INSTRUCTIONS /
3D VIEW /
PERSPECTIVE VIEW
TEXTUAL AND SPOKEN
INSTRUCTIONS
DISTANCE
DYNAMIC
RECALCULATION
2D ROUTE SKETCHES
PICTOGRAMS
LANDMARKS
DISTANCE BAR
Abb. 2: Patterns zur Routenplanung
Abb. 5: Patterns zur Wegführung
Zur
Gestaltung interaktiver Karten werden
verschiedene Patterns mit Möglichkeiten zum
Zoomen
und
Verschieben
(Panning)
des
Kartenausschnittes beschrieben, die je nach
Rechenleistung des mobilen Gerätes und/oder der
verwendeten Rendering-Algorithmen kontinuierlich
oder in diskreten Schritten realisiert werden können.
ZOOM SLIDER
ZOOMING
DISCRETE VIEWS
SPEED-DEPENDENT
AUTO-ZOOM
Kontext
Sie wollen eine Überblicks-Funktion innerhalb
interaktiver Karten gestalten. Die Funktion soll einen
kurzen, aber informativen Überblick über die
Umgebung des aktuellen Kartenausschnittes geben.
Problem
INTERACTIVE MAPS
SCALE BAR
2.1 Beispiel: HELIKOPTER-FUNKTION
WHERE AM I?
Wie muss eine Funktion gestaltet werden, die auf
Knopfdruck einen direkten und informativen
Überblick einer Karte bietet? Welche Anforderungen
hat eine solche Funktion?
ZOOMING FOCUS
Problembeschreibung und Kräfte
MAGNETIC POSITIONS
Abb. 3: Patterns zu Interaktiven Karten I
Weiterhin sind Interaktionsmechanismen wie eine
Interaktive Legende, eine Helikopter-Funktion zum
kurzzeitigen Herauszoomen aus der Karte oder ein
navigierbares Übersichtsfenster beschrieben, welche
200
Anwender, die sich mit einer hohen Zoom-Stufe
innerhalb einer interaktiven Karte bewegen,
verlieren leicht die Orientierung, wo der gerade
dargestellte
Kartenausschnitt
innerhalb
der
Gesamtkarte liegt. Es besteht also der Bedarf nach
einer Überblicks-Funktion. Diese wird spontan
benötigt und sollte deshalb einfach aufrufbar sein
und eine schnelle Orientierung bieten.
Beispiele
In Falk City Guide [5] existiert eine HelikopterFunktion, die, solange der Anwender das Symbol
der Funktion anklickt, aus der interaktiven Karte
herauszoomt. Anschließend verweilt die Karte für
wenige Sekunden in diesem Zustand und zoomt
danach auf den vorherigen Ausschnitt zurück.
Der Online-Routenplaner Map24 [6] bietet ebenfalls
eine solche Funktion – hier allerdings RocketFunktion genannt. Obwohl die Funktionalität
dieselbe ist, trifft die Raketen-Metapher weniger zu,
da Raketen im Gegensatz zu Helikoptern meistens
nicht mehr zur Erde zurückkehren.
Lösung
Bieten Sie eine Helikopter-Funktion, die nach dem
Aufruf aus dem aktuellen Kartenausschnitt
herauszoomt, in dieser Übersicht einen Moment
verweilt und anschließend automatisch in die vorige
Ansicht zurückzoomt. Die Funktion sollte einfach auf
Knopfdruck aufrufbar sein und lange genug im
Überblicks-Zustand verweilen, so dass sich der
Anwender Orientieren kann.
Diagram
User Interface Design, die Informationsarchitektur
und das Interaktionsdesign ergeben.
In der Hierarchie folgen zunächst Patterns zur
Gestaltung von Fensteroberflächen auf mobilen
Geräten (vgl. Abb. 7). Das Pattern “One True
Window” [7] beschreibt die Richtlinie, Applikationen
für mobile Geräte in nur einem sichtbaren Fenster
zu gestalten – im Gegensatz zu DesktopComputern, auf denen mehrere verschiedene
Anwendungen gleichzeitig dargestellt werden
können. Ausnahmen zu diesem Pattern werden im
referenzierten Pattern “Secondary Window” gezeigt,
welches beispielsweise für Dialoge oder Meldungen
angewandt werden kann.
MOBILE APPLICATION
ONE TRUE WINDOW
SECONDARY WINDOW
Abb. 7: Das Haupt-Pattern “Mobile Application” sowie
Patterns zum Anwendungsfenster und
Sekundärfenstern
Weitere Unterpatterns zu “Mobile Application”
zeigen, wie in mobile Anwendungen Platz auf dem
Display gespart werden kann, indem beispielsweise
Interaktionselemente oder weitere Informationen in
Tooltips oder Kontextmenüs versteckt werden
können und wie Bedienelemente dargestellt und
dimensioniert werden sollten (vgl. Abb. 8).
MOBILE APPLICATION
A PICTURE IS
SMALLER THAN A
THOUSAND WORDS
SAVING SCREEN SPACE
Abb. 6: Diagramm Helikopter-Funktion
BIG THUMB
3. DESIGN PATTERNS FÜR MOBILE
APPLIKATIONEN
Als Grundlage der Design Patterns für mobile
Applikationen in diesem Beitrag dienen die Design
Patterns von Noble und Weir [7]. Diese sind in einer
Hierarchie angeordnet, die anhand eines zentralen
Gestaltungsproblems mobiler Geräte aufgebaut ist,
der beschränkten Displaygröße.
Die im Folgenden vorgestellte Struktur erweitert die
Pattern-Sprache von Noble und Weir [7] um einige
Patterns und modifiziert wo notwendig Darstellung
und Struktur, um insgesamt eine konsistente
Hierarchie zu erreichen.
Ausgangspunkt der Sprache ist das allgemeine
Pattern “Mobile Application” (vgl. Abb. 5), das
Charakteristiken mobiler Geräte beschreibt, wie z.B.
deren unterschiedliche Nutzungskontexte, die
kleinen
Displays
und
die
beschränkten
Eingabemöglichkeiten,
sowie
die
daraus
resultierenden Anforderungen, welche sich für das
TOOLTIPS
DIAL 'H' FOR HELP
HIDE AND SEEK
CONTEXT MENU
Abb. 8: Patterns zum Sparen von Platz auf dem
Display und zu Gestaltung und Dimensionierung von
Interaktionselementen
Patterns zur Informationsarchitektur und zur
Navigationsgestaltung beschreiben,
wie zum
Beispiel Dialoge strukturiert werden können,
komplexe
Informationen
in
hierarchischen
Strukturen dargestellt oder in Kategorien unterteilt
werden sollten (vgl. Abb. 9).
“Cup Of Tea Test” [7] wiederum beschreibt, wie
mobile Applikationen so gestaltet werden können,
dass Anwender die Interaktion kurzfristig oder
kurzzeitig unterbrechen können, ohne dass
Datenverluste entstehen oder die Orientierung im
Interaktionsablauf verloren geht. Als Lösung sollten
beispielsweise immer Informationen zum aktuellen
Status angezeigt oder in einen sichern Zustand
zurückgekehrt werden.
201
Hermann, F. & Gibbert, R.
MOBILE APPLICATION
INFORMATION
ARCHITECTURE AND
NAVIGATION
INFORMATION
HIERARCHIES
SCROLLING
TREE VIEW
CUP OF TEA TEST
ASSIGNED
CATEGORIES
PATH
CHAIN OF DIALOGS
TABBED DIALOGS
NESTED DIALOGS
Abb. 9: Patterns zu Informations-Architektur und
Navigation
Adaptivität und Adaptierbarkeit sind ebenfalls
wichtige
Gestaltungsprinzipien
mobiler
Anwendungen. Diese werden in den Patterns “User
Customization”, “Context Awareness” sowie “Task
Adaptation”, auf welche im abstrakteren Pattern
“Adaptability” verwiesen wird (vgl. Abb. 10),
ausführlicher erläutert.
Darstellung von Ergebnissen aus Usability-Studien
und
-Projekten
bezogen
auf
bestimmte
Anwendungsbereiche. Das Wissen über gewählte
Design-Patterns und ihre ergonomische Qualität
lässt sich auf diese Weise gut aufbereiten und
vermitteln. Langfristig können so erweiterbare
Bibliotheken bewährter Patterns entstehen, auch
weil Pattern-Sprachen durch ihren modularen
Aufbau leicht gepflegt und erweitert werden können.
Design Patterns bieten so ein leicht handhabbares
Format, das die Sammlung abstrakter Prinzipien
und Gestaltungswissen unterstützt. Sie ergänzen
sich damit gut zu UI-Spezifikationen oder
Styleguides, sind jedoch kein vollständiger Ersatz
dafür. Insbesondere bleiben sie in der konkreten
grafischen Ausgestaltung des UI unkonkret und
müssen deshalb um solche Beschreibungen ergänzt
werden.
5. REFERENCES
[1] Alexander C., Ishikawa S., Silverstein M.,
Jacobson M., Fiksdahl-King I. and Angel S., A
Pattern Language. Oxford University Press
(1977).
[2] Alexander C., The Timeless Way of Building.
Oxford University Press (1979)
MOBILE APPLICATION
[3] Borchers J., A Pattern Approach to Interaction
Design. John Wiley & Sons (2001)
ADAPTABILITY
[4] Falk City Guide; http://www.falk.de
USER CUSTOMIZATION
CONTEXT AWARENESS
TASK ADAPTATION
Abb. 10: Patterns zu Adaptivität und Adaptierbarkeit
4. EINSATZ DER PATTERNS IM PROJEKT
Die hier vorgestellten Design Patterns entstanden im
Projekt, um mit relativ wenig Aufwand wesentliche
Gestaltungsprinzipien zu formulieren und einfach im
Team zu kommunizieren. Hierin zeigt sich nach
unserer Auffassung die Stärke des Design PatternAnsatzes: auf allgemeiner Ebene können wichtige
Richtlinien dargestellt und verständlich gemacht
werden. Darüber hinaus eignen sich Design PatternSprachen
zur
Sammlung
und
integrierten
202
[5] Gamma E., Helm R., Johnson R. and Vlissides
J., Design Patterns: Elements of Reusable
Object Oriented Software. Addison-Wesley
(1995)
[6] Map24 - Das Internetportal für interaktive
Karten; http://www.map24.de in May 2003
[7] Noble J. and Weir C., A window in your pocket:
Some small patterns for user interfaces. In Proc.
European Pattern Languages of Programs. The
Hillside Group, Inc. (2001)
Referenten
Fabian Hermann ist wissenschaftlicher Mitarbeiter am Fraunhofer Institut für
Arbeitswirtschaft und Organisation
im Bereich Usability Engineering,
Methodenentwicklung und Interaktionsdesign. Seine Forschungsinteressen liegen auf
der UI-Gestaltung und grafischen Informationsdarstellung für mobile Endgeräte mit
kleinen Displays, insbesondere Kartenvisualisierungen. Für Kunden aus der Industrie
und in Forschungsprojekten arbeitete er an der UI-Gestaltung und an Styleguides für
mobile Applikationen und User-Interfaces auf verschiedenen Endgeräten, neben
benutzergerechten Designs für industrielle GUIs, z.B. für tragbare Messgeräte.
Fabian Hermann studierte an der Universität Freiburg Psychologie und promovierte
dort in der Forschungsgruppe „Kognitive Systeme“ über rechnervermittelte
Kooperation.
Rainer Gibbert arbeitet derzeit im Competence Center Human-Computer Interaction
des Fraunhofer Institut für Arbeitswirtschaft und Organisation in Stuttgart. Im Rahmen
seiner Diplomarbeit erarbeitet er eine Design Pattern-Sprache für mobile
Applikationen mit dem Schwerpunkt Navigationssysteme, die Grundlage dieses
Artikels ist.
Er studiert im Studiengang „Digitale Medien“ an der Fachhochschule Kaiserslautern,
Standort Zweibrücken, und wird dort voraussichtlich im Oktober 2003 sein Diplom in
Informatik erhalten.
203
AUTOREN
Bauer, K. 151
Leidermann, F. 21, 181
Baumgartner, V.-J. 167
Leiner, U. 194
Beck, A. 29
Lotterbach, S. 93
Beringer, J. 39
Machate, J. 143
Beu, A. 75, 84, 147, 151
Mauch, D. 84
Birk, A. 21
Mencl, R. 63
Burmester, M. 143
Mund, M. 181
Degen, H. 123, 189
Noss, C. 115
Emele, M. 63
Parkitny, J. U. 156
Enigk, H. 8
Peissner, M. 75
Fahney, R. 34
Peißner, M. 175
Gersch, P. 115
Polkehn, K. 8
Gibbert, R. 199
Raimer, S. 107
Görner, C. 156
Reitmayr, E. 84
Goronzy, S. 63
Röse, K. 75, 84
Hartwig, R. 44
Sauer, J. 98
Hassenzahl, M. 75, 135
Schmeink, C. 98
Hatscher, M. 39
Schumacher, P. 103
Hermann, F. 199
Schwagereit, J. 147
Heuer, J. 127
Stoessel, S. 79
Hofman, T. 115
Strauß, F. 49
Hofvenschiöld, E. 135, 171
Terwey, B. 103
Honold, P. 194
Torge, S. 63
Kern, A. 147
Vogt, P. 84
Klante, P. 57
Wandke, H. 3
Kohler, K. 21
Wastell, D. 98
Koller, F. 161
Weber, H. 21, 181
Kompe, R. 63
Weiss, A. 161
Krämer, N. 13
Wessler, R. 103
Krause, S. 127
Wetzel, P. 69
Länge, F. 93
Wetzenstein-Ollenschläger, E. 3
Lazzeroni, C. 115
205
"
Der Berufsverband der deutschen
Usability-Professionals stellt sich vor
German
Chapter
upa
"
Egal, in welchem Bereich Sie sich der Benutzerfreundlichkeit
von Produkten widmen, der Berufsverband der UsabilityProfessionals ist Ihr Ansprechpartner und Ihre Interessenvertretung.
Wer ist das GC UPA?
"
"
Das GC UPA ist anerkannter Berufsverband
der deutschen Usability-Profis. Es unterstützt
seine Mitglieder bei der Anwendung von
Usability-Methoden und Vorgehensweisen
in der Praxis und fördert die Behandlung
von Usability-relevanten
Themen in
Deutschland.
Die Mitglieder kommen aus einer Vielzahl
von verschiedenen Bereichen, neben anderen
z.B. aus Psychologie, Informatik, Arbeitswissenschaften sowie Grafik- und Industriedesign. Alle folgen aber dem gleichen Ziel:
die Entwicklung von effektiven, effizienten
und gebrauchstauglichen Produkten und
Dienstleistungen.
Die Mitgliedschaft im Berufsverband der
deutschen Usability-Professionals steht
allen Personen offen, die in Ihrer täglichen
Arbeit Usability Prinzipien anwenden.
"
"
Werden Sie Mitglied!
Der Berufsverband der deutschen UsabilityProfessionals vertraut in erster Linie auf
das ehrenamtliche Engagement seiner
Mitglieder. Doch ganz ohne Geld geht es
leider nicht. Die moderaten Mitgliedsbeiträge dienen dazu, unvermeidliche
Unkosten zu decken. Selbst wenn man sich
als Usability-Profi nicht aktiv an der Arbeit
des GC UPA beteiligen möchte, unterstützt
man mit seinem Beitrag die Arbeiten vieler
tatkräftiger Fachkollegen für das Thema
„Usability“ - und damit für seine eigene
Zukunft.
Zu den Aktivitäten der Mitglieder gehören
beispielsweise die Einrichtung regionaler
Gruppen zum Erfahrungsaustausch vor
Ort, die Durchführung von Studien zur
Ermittlung der Arbeitssituation von
Usability-Profis in Deutschland, die
Durchführung des „Usability Professional
Track“ während der Fachkonferenz
„Mensch & Computer“, die Einrichtung
von Arbeitskreisen zu speziellen Fragestellungen sowie der Betrieb einer eigenen
Website und vieles andere mehr.
Die Mitglieder des Berufsverbands lösen
komplexe Gestaltungsprobleme in den
verschiedenen Branchen - von der Automobilindustrie bis zum Versandhandel und tragen dazu bei, dass deutsche Produkte
und Dienstleistungen auch in schwierigen
Situationen im globalen Wettbewerb
bestehen können. Außerdem fühlen sich die
Mitglieder im besonderen Maße dazu
verpflichtet, das Bewusstsein für die Rolle
der Usability-Experten sowohl bei der
Produktentwicklung als auch in
Öffentlichkeit und Lehre zu fördern.
Unabhängig vom jeweiligen Einsatzfeld sind
die Mitglieder Kollegen und Mitstreiter beim
Streben nach dem gemeinsamen Ziel der
Förderung von Usability-relevanten Themen.
Sie unterstützen sich gegenseitig und
tauschen ihre Erfahrungen regelmäßig aus.
Wollen Sie mehr wissen?
Für nähere Informationen über den
Berufsverband der deutschen UsabilityProfessionals besuchen Sie unsere Website
unter http://www.usability-verband.de
oder schreiben Sie uns eine e-Mail an
info@usability-verband.de.
Einen Mitgliedsantrag finden Sie umseitig
oder online unter
http://www.usability-verband.de/mitgliedwerden
German
Chapter
upa
Antrag auf Mitgliedschaft
Hiermit beantrage ich die Aufnahme in den Berufsverband der deutschen
Usability-Professionals (German Chapter der UPA e.V.) zum nächstmöglichen
Beitrittstermin.
"German Chapter Professional" Mitglied für € 30,-- pro Jahr
"German Chapter Student" Mitglied für € 15,-- pro Jahr
(nur für Studenten oder Auszubildende, Nachweis erforderlich)
Die Mitgliedschaft ist freiwillig und gilt für ein Jahr. Nach Bestätigung meines
Antrages überweise ich den Betrag unter Angabe meiner Mitgliedsnummer auf
das Konto des Berufsverbandes.
Meine persönlichen Informationen
Frau*
Herr*
Name*
Vorname*
Email*
Adresszusatz
Hausnummer*
Strasse*
PLZ*
Ort*
Telefax
Telefon*
Mit "*" gekennzeichnete Felder bitte unbedingt ausfüllen.
Durch meine Unterschrift stimme ich der Satzung zu und erkläre mich
hiermit bereit, die Ziele und Zwecke des Berufsverbandes der deutschen
Usability-Professionals (German Chapter der UPA e.V.) nach Kräften zu
unterstützen.
, den
(Unterschrift)
German Chapter der Usability Professionals’ Associaton e.V., Postfach 80 06 46, D-70506 Stuttgart
e-Mail: info@usability-verband.de, URL: http://www.usability-verband.de
Postbank Stuttgart (BLZ 600 100 70), Kontonr. 4084 21-709

Referent - German UPA

Transcription

Similar documents

Jahresbericht 2009 - Hochschule Augsburg

Thalus von Athos, Buch 1 - liebevoll

PDF - Versorgerin

BITV Reloaded - ›Einfach für Alle‹ ist eine Initiative der Aktion Mensch

Die komplette Bachelorarbeit in PDF

Unsere Wirtschaft 4_2005.indd - IHK zu Coburg

PDF-Datei

Einfluss von Leistungsbeurteilungen auf das Vertrauen der

Viel drin Musikalienhandel.de

die nächste revolution