gcu_titel_2008 18.08.2008 16:32 Uhr Seite 1

Transcrição

gcu_titel_2008 18.08.2008 16:32 Uhr Seite 1
C
Probedruck
M
Y
CM
MY
CY CMY
K
Impressum
Herausgeber
Henning Brau
Sarah Diefenbach
Marc Hassenzahl
Franz Koller
Matthias Peissner
Kerstin Röse
Vertrieb
German Chapter der Usability
Professionals Association e.V.
Postfach 80 06 46
70506 Stuttgart
Bestellungen an: [email protected]
Copyright
German Chapter der Usability
ISBN 978-3-8167-7769-4
Erscheinungsdatum
September 2008
Cover Design
Ständige Vertretung
www.staendige-vertretung.com
Druck
Fraunhofer Informationszentrum
Raum und Bau IRB
© German Chapter der Usability
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 Verlags
unzulässig und strafbar. Dies gilt insbesondere
für Vervielfältigungen, Übersetzungen,
Mikroverfilmungen sowie 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.
Brau, H., Diefenbach, S., Hassenzahl, M., Koller, F., Peissner, M. & Röse, K., (Hrsg.): Usability Professionals 2008
2
Usability Professionals 08: Wissen. Können. Tun.
Henning Brau
Daimler AG
Data & Process Management
P.O. Box 2360
89013 Ulm
[email protected]
Sarah Diefenbach
Wirtschaftspsychologie und
Mensch-Technik-Interaktion
Universität Koblenz-Landau
Fortstraße 7
76829 Landau
[email protected]
Marc Hassenzahl
Fortstraße 7
76829 Landau
[email protected]
Franz Koller
User Interface Design GmbH
Martin-Luther Str. 57 - 59
71636 Ludwigsburg
[email protected]
Matthias Peissner
Fraunhofer IAO
Nobelstraße 12
70569 Stuttgart
[email protected]
Kerstin Röse
Nutzererechte Produktentwicklung
TU Kaiserslautern
Gottlieb-Daimler-Str. 42
67663 Kaiserslautern
[email protected]
Usability ist in aller Munde. Technik
soll gebrauchstauglich, benutzungsfreundlich, "usable" sein und sogar
Freude bereiten – Forderungen, von
deren Wichtigkeit man Hersteller heute
nicht mehr lange überzeugen muss.
Usability ist ein akzeptierter Erfolgsfaktor. Mittlerweile beschäftigt jedes größere Unternehmen Menschen, die Technik
so gestalten, dass sie möglichst perfekt
zu den Fähigkeiten, Fertigkeiten und
Aufgaben ihrer Benutzer passt. Usability
Professionals sind gefragter denn je.
Die gestiegene Nachfrage nach Usability
Professionals und die unbefriedigende
und uneinheitliche Ausbildungssituation
machen die Aus- und Weiterbildung zu
einem zentralen Thema. Allerdings gibt
es vielfältige Meinungen darüber, was
Usability Professionals wissen und können sollten und welche Tätigkeiten zu
ihrem Aufgabengebiet zählen. Ist ein
Interaktionsdesigner auch ein Usability
Professional? Ist die ergonomische Verbesserung einer Maschinensteuerung
die Arbeit eines Usability Professionals?
Sind Website-Konzepter Usability Professionals?
Wir, der Berufsverband der Usability
Professionals in Deutschland (German
Usability Professionals' Association,
www.gc-upa.de) würden alle drei Fragen
mit einem beherzten Ja beantworten.
Alle drei, Interaktionsdesigner, Ergonomen und Konzepter, berücksichtigen bei
ihrer Arbeit die Bedürfnisse der Benutzer
und messen das Ergebnis am Erfolg bei
den Anwendern. Sicher, nicht alle teilen
diese Sichtweise, und natürlich werden
je nach Bereich unterschiedliche Methoden, Kriterien und Vorgehensweisen bevorzugt. Aber die Entwicklung
einer bestimmten, von allen geteilten
Sicht steht für uns auch gar nicht an
erster Stelle. Es geht vielmehr um Erfahrungsaustausch, nicht um Gleichmacherei. Eine aus unserer Sicht erfolgreiche Aus- und Weiterbildung verlangt den Dialog der Perspektiven. So
wird sie zu einer gemeinsamen Suche
nach Geteiltem und Strittigem.
Ein wichtiges Forum für den intensiven
Austausch – und auch die eine oder
andere Debatte – ist die Usability Professionals, das jährliche Treffen aller
Menschen, die es sich zur Aufgabe
machen, Technik menschlicher werden zu lassen. Die Usability Professionals 08 findet vom 7. bis 10. September 2008 in Lübeck im Rahmen der
Mensch und Computer Konferenz zusammen mit der DeLFI und der Cognitive Design statt (www.vielmehr.org).
Das übergreifende Motto "Viel Mehr"
macht deutlich, wie wir die Pluralität
der Sichten auf Technikgestaltung
erleben: nämlich als eine Bereicherung.
An vier Tagen, in 18 eineinhalbstündigen Workshops, Tutorials, Praxis- oder
Vortragssessions und natürlich auch
während der Pausen und an den Abenden tauschen über 300 Aktive und
Interessierte Erfahrungen aus, diskutieren Themen rund um Usability, geben Methoden weiter, knüpfen und
pflegen Beziehungen.
Als prominentes Highlight der Veranstaltung präsentiert Gastredner Gilbert
Cockton von der Sunderland Universität
in Großbritannien seine Sicht auf User
Experience. In "Load while Aiming; Hit?"
plädiert Gilbert für ein breites Verständnis von Qualität: Weg von der verengten
Sicht auf die Benutzbarkeit eines Produkts, hin zu der Frage, was eigentlich
den Wert eines interaktiven Produktes
ausmacht.
Neben den regulären Beiträgen gibt es
drei Sessions zu Themen, die uns aus
Sicht der eigenen Professionalisierung
wichtig erscheinen: Der "Arbeitsmarkt
Usability" (Henning Brau, Sarah Diefenbach) behält die Usability Branche im
Auge und hat zum Ziel, Unternehmen
und Professionals zusammenzubringen.
"Young Professionals" (Jana Löffler)
richtet sich direkt an die Usability Professionals von morgen, den für uns so
wichtigen Nachwuchs. Und "Berufsbild
Usability" (Clemens Lutsch, Kerstin Röse) beschäftigt sich mit der Frage, was
Usability Professionals eigentlich tun,
und wie man es werden kann.
All diese Aktivitäten stehen unter dem
diesjährigen Motto "Wissen. Können.
Tun." - unsere Art zu sagen, was es
alles braucht um ein erfolgreicher Usability Professional zu sein.
Das Organisationsteam, dessen Hauptaufgabe es ist, ein interessantes Programm und einen guten Tagungsband
zusammenzustellen, bestand dieses
Jahr aus Henning Brau, Sarah Diefenbach, Marc Hassenzahl, Franz Koller,
Matthias Peissner und Kerstin Röse.
6
Ein herzliches Dankeschön an unsere
Sponsoren (siehe rechts), ohne die die
Usability Professionals 08 nicht möglich
gewesen wäre.
Am wichtigsten sind aber die Beitragenden selbst. Denn nur ihre Bereitschaft,
Wissen und Können mit anderen zu
teilen, macht die Usability Professionals
möglich. Diese Bereitschaft macht deutlich, wie sehr wir uns trotz aller Unterschiedlichkeit bereits als eine "Community" verstehen.
Vielen Dank für Ihr Engagement! Und
bis zur "Usability Professionals 09" in
Berlin!
Inhalt
Keynote
17
Gilbert Cockton
Tutorials
25
Q uantitative Methoden zur prozessbe-
gleitenden Evaluation von
Designvorschlägen 30
Kognitive Modellierung in der
Konzeption von Softwareprodukten
l oad while aiming; Hit?
P. Fischer, M. Schrepp, T. Held & B. Laugwitz
T. Held, M. Schrepp,
D. Mayer-Ullmann & D. Holt
ein System benutz´ ich nicht: Ein praxisorientierter Ansatz, Nutzerakzeptanz zu messen und
zu verbessern
H. Brau
40
User Interface Prototypen in Usability Engineering und Software Entwicklung:
Probleme und Synergien
45
Methoden, Notationen und Werkzeuge zur Übersetzung von Anforderungen in
User Interface Spezifikationen
49
Formulargestaltung für
Dummies: die häufigsten Fehler
erkennen, beheben und zukünftig vermeiden
M. Weber & T. Immich
T. Memmel, T. Geis & H. Reiterer
I. Niedermann & M. Hatscher
8
Inhalt
Eyetracking
55
Visuelle Orientierung auf einer Website: Vergleich von Sehbehinderten und Normalsichtigen mittels Eyetracking
60
Software-ergonomische Evaluation eines Buchungsportals für Flugtickets mittels Blickbewegungsanalyse
65
GoodGaze: Eine Technologie aus der Hirnforschung analysiert Webseiten auf ihre Aufmerksamkeitswirkung
73
Jenseits von Usability:
Website-Ästhetik
78
Der User Experience (UX) auf der Spur:
Zum Einsatz von www.attrakdiff.de 83
Softwareentwickler als Interaktionsgestalter: Erfahrungen zu Einsatz und Verwendung von Interaktionspattern
88
Exploration - ein Pattern zur Steigerung des Engagements
95
Season of Usability Usability-Studenten sammeln
Praxis-Erfahrung in Open Source
Projekten
Jenseits von Usability
Young Professionals
S. Duda & M. Saur
L. Schmidt & E. Smieonova
N. Höning, F. Stelzer, J. Steger, N. Wilming & P. König
M. Thielsch
M. Hassenzahl, Michael Burmester &
Franz Koller
K. Klöckner & K. Kohler
C. Nass & K. Kohler
E. Reitmayr
Inhalt
Usability Praxis I
101
Usability und/oder Security
106
Dann macht es doch selbst! - Entwickler
als Usability-Experten
111
User Interface Konstrukte und Key
Innovations in SAP Business by Design
117
Designing for People: Integration des User Centered Design(UCD) in den globalen Entwicklungsprozess in SAP BusinessByDesign 123
Rolle und Einfluss von Prototyping Tools in einem industrialisierten,
pattern-basierten
UI Entwicklungsprozess
131
Arbeitskreis: Berufsbild und Broschüre
Ein Statusbericht 133
Arbeitskreis: Ausbildung und Curriculum - StatusberichtCurriculum Usability
135
Usability Professionals - ein Rollenspiel
Usability für SAP Business ByDesign
Berufsbild
Usability Professional
M. Dahm & C. Thiel
R. Hartwig, M. Mäuselein,
S. Özalp & B. Kieseler
U. Arend & J. C. Peters
D. Markwig, S. Finke & I. Weissbrodt
T. Uhl & A. Hauser
C. Lutsch, C. Bogner, H. Brau, T. Geis,
M. Harbusch, P. Huber,
K. Petrovic & K. Polkehn
K. Röse & J. Löffler
M. Hatscher & I. Niedermann
10
Inhalt
Standards im
Usability Engineering
141
Standards im Usability Engineering
umsetzen - was funktioniert, was nicht ?
Usability Tools
149
Auswertung mit
Card-sorting-Experimenten
mit Casolysis
153
W-U-T: Ein interaktives
Web-Usability-Tool
157
Web-based Paper Prototyping mit
RapidRabb.it - Ein Ansatz zum
kollaborativen Prototyping
160
Swordfish: Eine Software zur
asyncronen Remote-Evaluation der Usability von Webseiten
164
Ein Tool zur Klassifikation und Auswahl von Evaluationsmethoden im
User-centered Design Prozess
B. Rummel & T. Geis, M. Schrepp, T. Held,
M. Offergeld, H. M. Scheurer & D. Willuhn
G. Szwillus & S. Emmrich
G. Szwillus, E. Demenev,
J. Hillebrand & H. Schröder-Mänz
T. Truppel, S. T. Golega & V. Gersabeck
F. Pilottek, N. Gerth & T. Krach
M. Freymann
Inhalt
Arbeitsmarkt Usability
169
Branchenreport Usability 08
Usability Praxis II
177
Erste methodische Erkenntnisse zur Usability-Analyse von Video-Inhalten auf Websites mittels Eyetracking
182
User Experience und Social Shopping
187
Praxistauglicher Usability-Engineering-
Prozess für Corporate-Websites
195
Innovative Maschinen brauchen
innovative Entwicklungsprozesse –
Usability, Design und Software optimal verzahnen.
199
Web Globalization balanced by User
Experience
204
NEW HMI
Möglichkeiten und Grenzen
abstrakt-geographischer Visualisierung in Bereich der Anlagensteuerung
Fallstudien
S. Diefenbach & M. Hassenzahl
S. Pagel, S. Goldstein & A. Jürgens
T. Bartel, G. Quint, S. Nicolai & S. Weichert
T. Beschnitt
F. Koller
A. Kittler & R. Gibbert
T. Hofmann & P. Holzkämper
12
Inhalt
Unternehmensstrategie
User-Centered-Design
211
Interdisziplinär: User Centered Design im Großunternehmen
215
Human Centred Design als
Unternehmensstrategie
223
Agile nutzerzentrierte
Softwareentwicklung mit
leichtgewichtigen Usability Methoden Mythos oder strategischer
Erfolgsfaktor?
228
Integration von User Centered Design in
agilen Entwicklungsprozessen
233
Extreme Gebrauchstauglichkeit: Agile
Prozess- und Softwareentwicklung mit den Mitteln des Usability Engineering 241
Wie sag ich’s meinem Anwender?
Vorgehen und Styleguide für die
Gestaltung von Anwendungsmeldungen.
246
Eloquent Design of Human-Computer
Interaction
252
Sprachapplikationen:
Qualität durch Standardisierung Agiles User-Centered-Design
Eloquenz in der Interaktion
K. Petrovic,
M. Harbusch & C. Fellenz-Thompson
C. Lutsch & K. Petrovic
T. Memmel, H. Brau & D. Zimmermann
M. Düchting, P. Kowallik & K. Nebe
H. Obendorf & R. Naumann
R. Oed & H. Ziegler
M. Marek
C. Hipp & M. Peissner
Inhalt
Interaktion von Morgen
259
Umsetzung von neuen
Interaktionskonzepten mit Hilfe der
Wii-Remote – Wii interagiere ich?
264
Gestaltung einer haptischen
Navigationshilfe für den mobilen Bereich
270
„Luftmäuse“ – berührungslose
„Multipointing-Interaktion“
User-Centered-Design und
Software Entwicklung
M. von Wilamowitz-Moellendorff,
M.Schreiber & R. Bruder
R. Kniewel & C. Hipp
P. Chojecki & U. Leiner
277
rfahrungen zur praktischen
Anwendung eines ganzheitlichen
Usability Engineering im Kontext der klassischen ITSystementwicklung
und Prozessreifung
M. Offergeld
282
Q ualitätsaspekte bei der Integration von
User Centred Design Aktivitäten in
Softwareentwicklungsprozesse
287
Faktoren zur erfolgreichen Umsetzung von User-Centered-Design Aktivitäten –
Beispiele aus der Praxis
K. Nebe, M. Düchting,
D. Zimmermann & V. Paelke
D. Zimmermann, M. van Ballegooy,
K. Jepsen & D. Wehr
14
Inhalt
Methoden und Prozesse
295
Evaluation eines
Human-Machine-Interface für
Tower-Fluglotsen unter Einsatz eines Simulators
C. König, T. Hofmann, J. Bergner & R. Bruder
sability Tests bei Immobilienscout24 Aktuelle Herausforderungen im User Experience Design
Monika Denk, A. Kimm & S. Klein
301
Strategisches User Experience Design
Anforderungen und Methoden der
wertorientierten Entwicklung von
Webinterfaces
304
Webdesign und Usability-Evaluierung: Ein Methodenmix für die Neugestaltung des Webautritts der Auto 5000 GmbH (Volkswagen AG)
308
Business Centered Design:
Erfolgsfaktoren im E-Business
D. Gilbert
T. Mandl, I. Rill & F. Caroli
C. Becker & C. Fernandez
Inhalt
Designaspekte
313
Virtual Reality für Jedermann –
Vereinfachter Zugang
zu komplexen Daten der
3D-Produktvisualisierung
316
Usability von VR-Anwendungen Was tun wenn das Problem in der menschlichen Wahrnehmung liegt?
319
Multimodales Interface Design: Wie wirkt sich redundantes Informations-
Design auf die Gebrauchstauglichkeit aus?
323
Standards für benutzerfreundliche
Medienwiedergabe on- und offline
328
Skinning vs. Usability vs. Branding
335
Referenten A - Z
Referenten
K. Wack & H. Brau
A. Köhler & H. Brau
T. Sackmann
J. Jacobsen & M. Gidda
C. S. Friedrich
16
K eynote
15
16
Load while Aiming; Hit?
Gilbert Cockton
Department of Computing, Engineering and Technology, St. Peter’s Way,
University of Sunderland,
Sunderland SR6 0DD, UK
[email protected]
Abstract
Usability and now UX specialists aren’t
in charge and shouldn’t be. Design
strategists should lead project teams to
focus on a common purpose rather than
squabble over competing value systems.
Evaluating too should have only one
purpose: to evaluate design purpose. In
this keynote address, I will introduce
worth-centred approaches to digital
products and services. These focus on
worth as a balance of benefits over
1.0
Who Would Aim First
An artillery battery commander’s
cries of “Load“, “Aim” and “Fire!” sequence a shot at a known enemy. An
artillery piece must be ready to fire, so
there is no point of “aiming” before “loading”. Yet, from the dawn of HCI, usability
specialists have wanted to get in ‘early’,
before anyone has made any commitments to artillery or munitions. “Aim”,
“Load”, “Fire!” was HCI battery commanders’ sequence. Initially, even “load
enough to fire at something” will do. We
had to get in first, take charge, and stay
in charge (Cockton 2008b). Who would
go into battle with battery commanders
who must see where to aim before
knowing what sort of artillery exists and
what it can do?
Designing is not warfare, however much
it feels like this in the trenches of software development. We are not firing at
enemies, but aiming for allies. We need
to know them well to know if our aim is
true. We must gather human intelligence
needed to assess success. Nevertheless, such human intelligence has to be
co-ordinated alongside gathering techni-
costs for all included stakeholders.
Worth-Centred Development (WCD)
takes designing to a point where a
focus on intended worth can progress
to achievable and on to achieved
worth. The evolving WCD framework
combines approaches in support of six
meta-principles that are necessary and
sufficient to enact designing as it ought
to be. Example approaches such as
worth maps,
cal intelligence to support delivery of
designs. Technology can’t and won’t
wait. UX planning needs to proceed
alongside exploration of technical and
creative opportunities
2.0
Load and Aim
UX specialists can never get in
‘first’. Technology creatives will have
always invented, tinkered and bootstrapped long before any UX involvement. We must shadow technology
development, looking for good places
to aim at while engineers and creatives
make things to load and things to load
them in. Designing must thus support
parallel activities. Some will focus on
technical and creative means. Others
will focus on human ends and experiences. Means and ends must be explored, compared, selected and refined in parallel. The required coordination can be achieved through an
integrating focus of worth that aligns
user research, design and evaluation.
element measurement strategies and
user experience frames are briefly illustrated to show how we must and can
move beyond user experience to focus
on achieving outcomes in the world as
the primary purpose of all designing.
Keywords
Value, Worth-Centred Development,
Designing, Worth Maps, User Experience,
3.0
Hit?
Back at battalion HQ, officers direct
batteries, updating their plans in response to (un)successful hits and moving targets. Their remote view yields
very different perspectives from those
formed in during batteries’ moment by
moment activities.
With little sense of any overall battle
plan, a battery UX evaluator could do
little more than focus on how guns are
fired. How fast can they load, aim and
fire? What sorts of errors get made?
Who gets injured and how? How does
the battery feel about their performance?
What’s it like to fire guns? What improvements are sought?
A battery evaluator returns to battalion
HQ with their UX report. No-one at HQ
cares. None of it matters. They win battles and are winning the war. They’d like
to win it quicker, with less damage, making the inevitability of defeat clear. Their
aim is less vanquishing the enemy than
receiving their surrender.
Measuring artillery UX has limited connections with effecting surrender. Every
17
shot is a cost. Peace on our terms is the
benefit. Battery evaluators see mostly
costs and few benefits.
4.0
Miss!
Measuring the wrong things in the
wrong place at the wrong time is hard to
value. There is no point in measuring
efficiency or effectiveness (as task completion) if they don’t matter. UX work can
be equally pointless by measuring emotions without regard for how they contribute to worthwhile outcomes within or
after interactive experiences.
comprehensive, lets us load, aim, fire
and check the result.
Designing as a human activity will always be subjective. Its norms and
ethos arise from the nature of design
outcomes, which “result from … decisions … Choice implies alternatives, in
how ends can be achieved, and for
whose advantage. … design is not
only about initial decision or concepts
by designers, but also about how
these are implemented and by what
means we can evaluate their effect or
benefit” (Heskett 2002, pp. 5-6).
There is limited, if any, summative value
in, measures of what are means to ends.
Such measures capture little of the complete means-end chains that shape how,
when and why means enable ends.
There are thus key design choices of:
Designers are often no better, also focused exclusively on means and never
firming up on ends. If designing has no
clear purpose, then so too will evaluation
focus on means, not ends.
A development process must explicitly
support and co-ordinate all four types
of design choice. If not, it does not
support designing, and at best is a
process of creative making. Support
for norms of designing can be expressed as expectations for development processes. Such expectations
can be expressed in specific contexts
as principles, which instantiate more
general meta-principles. Six such
meta-principles are necessary and
sufficient to support designing’s four
key choices:
5.0
Better by Designing?
The lessons from the artillery example are that we must not aim before
loading, and that we must be able to see
our targets and know whether we have
hit them. However, we cannot rely on a
remote battalion HQ to tell us where to
aim and whether we are hitting the target. We need to combine the battery and
the battalion HQ in an integrated approach to design management.
UX must be an integral part of development, but when integrated into the
wrong process, poor UX downstream
utility gets blamed for upstream futility
(Cockton 2007). UX can’t be expected to
fit into any development process and
deliver regardless. Development has to
be open to designing to let UX effectively support development of worthwhile
digital products. Designing, if and when
18
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
Means from alternatives
Ends (design purpose)
Beneficiaries (stakeholders)
Means of evaluation
Commitment
Receptiveness
Expressiveness
Inclusiveness
Credibility
Improvability
These meta-principles are holistic.
Commitment requires project teams to
overtly select means, ends, beneficiaries and evaluations.
Receptiveness requires being creatively open to alternative means, ends,
beneficiaries or evaluation methods.
Expressiveness requires effective representation of chosen means, ends, beneficiaries and evaluations, associations
between intermediate means, and between terminal means and ends.
Credibility needs feasible means, genuine ends for beneficiaries, relevant
evaluations, and plausible linking associations within means-end chains.
Improvability needs measurable means
and ends, evaluation instruments to
measure them, targets to hit, and
chances for more inclusiveness and
(recursively) more improvability.
Inclusiveness requires moral or ethical
justification of inclusion and exclusion of
stakeholders; for included stakeholders,
costs arising from chosen means must
be justified, as must benefits associated
with chosen ends, and also the ability of
chosen evaluations to properly assess
the balance of worth resulting from
achievable benefits given likely costs.
Project teams can partially instantiate
these six demanding meta-principles via
an appropriate framework. It is only
within specific development contexts
that principles can be fully instantiated.
A Worth-Centred Development (WCD)
framework is evolving to support partial
instantiation of the six meta-principles. It
is worth-centred, because it constructs
designing as the creation of worth, and
not just of value or of artefacts. Many
credible value propositions fail because
they do not offer sufficient value to offset
a wide range of costs. Price is one cost,
but others may be more important, such
as the cost of usage, ownership, integration of substitution. The latter two costs
are particularly important for digital products and services, which must have
good synergies within existing productservice ecosystems. Also, switching
costs must be acceptable. Together,
these costs can make even the most
apparently valuable design not worth it.
Pleasant
Sequel
Worthwhile Economic
Transaction
Successful gift, transfer
or disposal
Nicer
home
In Control
Good Value
Clear,
informative
Price information
and cost summary
Good Plan
Concerned, caring,
valuing
Email/fax confirmation
of booking
What to bring and
when information
Web pages with dowloadable documents (e.g., pdfs)
Not in control of costs,
more than planned
Complete, checkable,
thorough
Helpful,
considerate
Van load information
Depot maps and directions information
Email and fax
capabilities
Hirers can’t collect hired van
Load won’t fit into van/
more trips needed
Image capabilities of
html, java etc.
Hirers arrive late
at depot
Unable to find
van hire depot
Figure 1. Worth Map for Hypothetical Van Hire Site.
6.1
Worth is thus the arbitrator of product or
service success. Value is a motivator,
but costs can de-motivate. We need to
focus on the balance of costs and benefits to promote design success.
6.0
The WCD Framework
The WCD framework has been
populated by adapting existing HCI approaches and borrowing from consumer
psychology and ethnography to fill gaps.
They are called approaches rather than
methods, since they are tactical resources, often supported by diagrams or
tables. However, no fixed procedures
are associated with these tactics or representations. Due to space limitations,
three approaches are briefly illustrated,
and several further ones are noted.
Worth Maps
Worth Maps adapt hierarchical
value models (HVMs) from consumer
psychology. Cockton (2008a) covers
their predecessor, worth/aversion
maps (W/AMs), which were closer to
HVMs. Worth maps combine envisaged means-end chains (MECs) into a
network diagram. They support instantiation of commitment by presenting
chosen means and ends in MECs that
end at worthwhile outcomes. Means,
ends and associations between them
are shown in worth maps.
Figure 1 shows a worth map for a van
hire web site, mostly from a customer
perspective. The map is populated by
design elements (materials, features,
qualities) and value elements (user
experiences, outcomes). Element colours are: yellow for worthwhile out-
comes, pink for user experiences, light
blue for qualities, grey for features, white
for materials, and red edged for adverse
outcomes. Other negative elements (defects, adverse experiences) are omitted
for simplicity. Closely adjacent unassociated elements (no arrow links) are
(non-exclusive) alternatives (horizontally
adjacent) or sequenced (vertically adjacent). Outcomes are ends. All other
elements are means. An example MEC
is highlighted in red.
Worth maps express intended worth for
chosen beneficiaries and the means that
are expected to deliver it (see further
details in Cockton 2008c). Worth maps
express a project team’s commitment to
specific ends and the means that can
achieve them, and to associations between these map elements. Commitment to beneficiaries can be indicated
by associating included stakeholders
19
with specific experiences and outcomes.
Commitment to evaluations is expressed
through element measurements strategies, which plan for testing oft whether
loading and aiming resulted in any hits.
6.2
Beliefs
Looking forward
to getting van
Have all
necessary
details
UX evaluation has focused on usage,
yet many worthwhile outcomes that represent the true ends of design purpose
cannot be measured during use of digital
components of a wider product or service system. Most outcomes in Figure 1
need instrumentation at van hire depots,
where data would be provided directly
by customers/and or depot staff. Other
outcomes, and user experiences, require instrumentation of customers soon
after a hire, again either with data provided directly at the depot by customers
and/or staff, or via customer feedback
web pages, phone or email surveys. The
‘moments of truth’ of all outcome measures are such that none can be measured through web-site user testing, and
most cannot be fully measured until a
customer has completed removal of
goods, or abandoned delivery for some
reason.
System Usage
System Response
Acts in the
World
Staple and pin
up
Print pdf
EMSs and DWI
An Element Measurement Strategy
(EMS) associates measures, instruments and thresholds with each element
of a worth map. The main requirements
for summative evaluation are to measure achievement of worthwhile outcomes. In Figure 1, these are: a worthwhile economic transaction, a pleasant
sequel, successful gift/transfer/disposal
and/or nicer home). Adverse outcomes
should also be measured. In Figure 1,
these are: costs out of control, arrive
late, load won’t fit, can’t collect van/ find
depot). The diamond ended arcs in Figure 1 are aversion blocks, which express
claims that associated design elements
will prevent adverse outcomes. Measures can test such claims establishing
the achieved worth of the current design.
20
Feelings
Read email,
follow link to pdf
Feels great, all
well planned
now
Booked right
van for right
time period
Display pdf
Save and print
confirmation
page
Display and
email confirmation
Book and pay
for van
Can find right
van
Select appropriate van
Sally checks
details
Display book
this van page
Harry sees ok
van
That’s cool
Better to start
with depot
Select depot
Update depot
info
Enter Post
Code
Show depots
map
Nearest depot
is on ring road
Sally sees nearest depot
Can find info on
depots
Sally persuades
Harry
Not a good
place to start
Can find prices
and availability
Display home
page
Open lovelyvan.com
Figure 2. Good Plan Customer UEF for a Van Hire Web Site
Direct Worth Instrumentation (DWI) is
an evaluation approach that embeds
instruments in technical or wider sociodigital systems. This may require extensions to initial design elements,
e.g., email based feedback requests
linked to survey webpages. Systems at
a van hire depot could also be extended to track frequency and causes
of late pick ups and drop offs (e.g.,
getting lost on the way to the depot), or
inappropriately sized hired vans (both
too small and too large). The motivation
is always to measure what matters, and
not what is easy to measure.
6.3
User Experience Frames
User Experience Frames (UEFs,
Cockton 2008d) expose the internal detail of UX worth map elements. UEFs
adapt multi column transcripts from ethnographic research (Jordan and Henderson 1995) to express design commitments and expectations before there
is an implementation that can let representations be based on actual usage. In
contrast, both HVMs and ethnographic
transcripts are based on data from users/consumers with actual product experience, and must thus be created after
implementation and/or deployment.
Figure 2 shows an illustrative UEF for
the Good Plan UX in Figure 1. It has five
columns for the feelings, beliefs, user
actions, responses and human actions
within a specific abstract scenario for
two customers interacting with the van
hire site. The narrative structure is indicated by a thick double line snaking from
the bottom to the top, running underneath and around table cells (the narrative could run from top to bottom over a
few pages, or curved arrows could replace table cell border coding ― UEFs
use whatever is to hand and suits the
documentation context).
Figure 2 shows how the internal dynamics of a UX element can be expressed
as a narrative thread of beliefs, feelings,
actions and reactions. In the example,
positive emotional responses and a
growing confidence result in a UX that
ends with feeling well prepared to pick
up a van and use it to collect a purchase. The closing feeling and belief
cover most of a value proposition that
the site helps you book the right van for
the right time from the best depot at a
good price.
UEFs thus express project teams’ understanding of how human motivations
and abilities combine with design elements to produce a meaningful experience that brings benefits and costs as
worthwhile or adverse outcomes. UEFs
thus express achievable worth for specific stakeholders. Headers and footers
can be used to highlight resulting outcomes, as well as the relevant features
and qualities that support the UX. Any
worthwhile outcome so indicated must
also be linked from the UX in associated
worth maps. Alternative multi-column
formats are also possible for UEFs.
There can be several UEFs for each
UX element in a worth map, each representing one or more abstract scenarios for one or more stakeholders.
6.4
Some Other WCD Approaches
UEFs are sufficiently expressive to
support scenario and stakeholder
based analyses in further WCD approaches. For example, credibility
analysis can be supported by Worth
Delivery Scenarios (WoDSs). These
can start with the narrative paths
through UEFs, expand them into textual scenarios and assess the credibility of each link in the narrative.
WODSs must have happy endings
corresponding to worthwhile outcomes.
Credibility of outcomes depends on
credibility of means-end chains. There
are no grounds in Figure 2 for the belief that a van had been booked for the
right time period. This is because
some rows have been deliberately
deleted! Inspection can expose the
resulting insufficient grounds for forming the belief ’Booked right van for
right time period’. Missing rows must
be reinserted to improve credibility.
Once a UEF is complete enough to
make abstract scenarios credible, they
can be further challenged through authoring more detailed textual envisionment scenarios.
UEFs can be also assessed for stakeholder specific balances of worth. UEF
headers or footers can indicate worthwhile or adverse outcomes. Hedonic
qualities in feelings columns can also
be considered as part of a balance of
worth. Since even abstract scenarios
must be stakeholder specific, it follows
that the overall balance of worthwhile
and adverse outcomes and feelings
can be regarded as a detailed instan-
tiation for the inclusiveness metaprinciple. Headers or footers can indicate the stakeholder(s) to whom a UEF
applies, and can be further marked with
a graphical indication (e.g., a green to
red scale from positive to negative worth
balance). These indicators can be copied to the UX elements in worth maps,
allowing overall inclusiveness to be assessed relative to a range of likely
stakeholder outcomes. Unacceptable
likely outcomes can be addressed in
iterative activities of worth balancing.
Other WCD approaches include Worth
Webs, a Venn diagramming approach
that places stakeholders in overlapping
contexts of individual and collective
worth. They address individual worth
through Alderfer’s (1972) motivational
categories of Existence, Relatedness
and Growth (ERG). Collective worth is
addressed through worth spheres for
social categories of institutions, kin, and
kind (IKK). Relatedness links individual
and collective worth, as do Locales,
which are spatial processes that create
social places. Worth webs are thus use
this L-ERG-IKK framework that interrelates place, social structure and individual needs and wants. This simplifies an
earlier approach to individual and collective worth (MILKK, Cockton 2006).
Worth webs support worth mapping by
identifying the considerations (or sensitivities, Cockton 2008c) that provide
creative bases for sketching worth map
elements prior to adding associations
and refining worth maps. In terms of the
artillery metaphor, considerations or
sensitivities support both loading (of
design elements) and aiming (at human
elements). Hence we can load while
aiming, although the WCD framework
lets us load first. However, unlike UCD it
does not insist on aiming first. We can
load first as with technology probes
(Hutchinson et al. 2003). We can never
aim first. Even the most human-centred
destinies worth maps (Cockton 2008a)
21
still have some technologies in mind
when mapping out key worthwhile and
adverse outcomes.
6.5
HCI Approaches and WCD
Many existing HCI approaches can
be used in WCD, perhaps with some
modification. Scenarios have already
been mentioned in their modified WoDS
form, as have interaction analysis transcripts in their envisionment form of
UEFs. Similarly, a wide range of HCI
specification and sketching approaches
can be used without modification to express design elements. We can also use
existing field research approaches
(Randall et al. 2007), including indirect
methods such as cultural probes
(Boehner et al, 2007), be used to maximise receptiveness to potential design
and human elements. Considerations
and sensitivities cannot be wholly derived from worth webs. Thus although
sets of personas (Pruitt and Adlin 2007)
can readily be derived from worth webs,
these too are best grounded in appropriate field research.
6.6
Other Approaches and WCD
Human Science approaches such
as motivational and social theory underpin the L-ERG-IKK framework. Receptiveness can further benefit from choice
theory, affective psychology and theories of experience, amongst others.
Similarly, business approaches such as
value propositions and HVMs have been
adapted for WCD. Receptiveness can
benefit from use of trends data and approaches from consumer psychology.
WCD requires a wide range of approaches. While usability largely relied
on cognitive psychology, and much UX
relies on affective psychology, WCD
cannot be restricted to one disciplinary
subfield. To understand worth, and to be
receptive to its implications for stakeholder research, interaction design and
22
holistic evaluation, HCI must become
much more eclectic.
7.0
Conclusions
HCI must move beyond a UX focus on emotion and activity to a focus
on worthwhile outcomes. UX and usability remain important, but they have
a place and can be kept in it, much to
their benefit! This place is provided by
the common purpose begins with a
focus on intended worth and then progresses onto achievable and lastly
achieved worth. This strategic approach puts UX and usability where
they can be more effective. Within
WCD, UX and usability reduce costs
and increase some benefits, but what
matters is how they contribute to, or
obstruct, achievement of the intended
worth that provides purpose for design
projects. UX and usability are not absolutes. They can only be means to
ends, and not ends in themselves,
Acknowledgements
The development of the WCD metaprinciples and framework was supported by
a NESTA fellowship (www.nesta.org.uk).
Worth maps and UEFs were developed
during a visiting researcher position at Microsoft Research in Cambridge. Alan Woolrych of the University of Sunderland managed the commercial user testing work on
van hire web sites on which the examples
in Figures 1 and 2 are based. Thanks to all
for support, help and encouragement.
References
Alderfer, C. (1972) Existence, Relatedness,
and Growth. Free Press
Cockton, G. (2007) Upstream Futility Blocks
Downstream Utility. In: Law E. Lárusdóttir M.
and Nørgaard M. (Eds): Downstream Utility:
The Good, the Bad, and the Utterly Useless
Usability Evaluation Feedback
(cost294.org/upload/495.pdf), 100-105.
Cockton, G. (2008a) Putting Value into
E-valuation: In Law, E. Hvannberg, E. and
Cockton, G. (Eds): Maturing Usability: Quality
in Software, Interaction and Value, 287-317,
Springer.
Cockton, G. (2008b) Revisiting Usability’s
Three Key Principles. In. Czerwinski, M.,
Lund, A.M. and Tan, D.S. (Eds.): CHI 2008
Extended Abstracts, ACM, 2473-248.
Cockton, G. (2008c) Designing Worth: Connecting Preferred Means with Probable Ends.
To appear in: interactions, 15(4), ACM.
Cockton, G. (2008d) What Worth Measuring
Is. In: Law, E., Bevan, N., Christou, G.,
Springett, M. and Lárusdóttir, M. (Eds):
MAUSE Workshop on Meaningful Measures:
Valid Useful UX Measurement, 60-66.
Heskett, J. (2002) Design: A Very Short Introduction, Oxford.
Hutchinson, H., Mackay, W., Westerlund, B.,
Bederson, B. B., Druin, A., Plaisant, C.,
Beaudouin-Lafon, M., Conversy, S., Evans,
H., Hansen, H., Roussel, N., and Eiderbäck,
B. (2003) Technology probes: inspiring design for and with families. In: Proceedings of
CHI '03, ACM, 17-24.
Jordan, B. and Henderson, A. (1995) Interaction Analysis: Foundations and Practice In:
Journal of Learning Sciences, 4(1): 39-103.
Pruitt, J. and Adlin, T. (2006) The Persona
Lifecycle : Keeping People in Mind Throughout Product Design, Morgan Kaufmann.
Randall, D. Harper, R. and Rouncefield, M.
(2007) Fieldwork for Design: Theory and
Practice, Springer.
Boehner, K., Vertesi, J., Sengers, P., and
Dourish, P. (2007) How HCI interprets the
probes. In: Proc. CHI 2007, 1077-1086.
Cockton, G. (2006) Designing Worth is
Worth Designing. In: Proc. NordiCHI 2006,
eds. A.I. Mørch, K. Morgan, T. Bratteteig,
G. Ghosh, and D. Svanæs, 165-174.
Tu torials
23
24
Quantitative Methoden zur prozessbegleitenden Evaluation
von Designvorschlägen
Patrick Fischer
SAP AG
Dietmar-Hopp-Allee 16
69190 Walldorf
[email protected]
Martin Schrepp
SAP AG
69190 Walldorf
[email protected]
Theo Held
SAP AG
69190 Walldorf
[email protected]
Bettina Laugwitz
SAP AG
69190 Walldorf
[email protected]
Abstract
Im Designprozess stehen oft viele
Entscheidungen an, die nur schwer
aufgrund von vorhandenem Wissen
getroffen werden können. Aufwändige Userbefragungen sind in diesen Fällen meist nicht angebracht.
Was hier benötigt wird, ist eine kostengünstige und schnelle Methode,
1.0
Einleitung
Während der Gestaltungsphase von
Benutzungsoberflächen treten verschiedene Probleme auf, wie z.B. Entscheidung für ein konkretes visuelles Design
oder die Art der Verteilung von Informationen. In vielen Fällen sind es Usability
Experten, die durch ihr Wissen und ihre
Erfahrung ad hoc solche Probleme lösen
können.
Ist die Lösung eines Problems nicht offensichtlich, werden Endbenutzer in den
Entwicklungsprozess einbezogen. Hierfür gibt es altbewährte Methoden, wie
z.B. Usability Tests oder Usability Reviews. Bei diesen Methoden wird der
direkte persönliche Kontakt bevorzugt.
Endbenutzer bearbeiten im Labor Aufgaben, werden dabei beobachtet oder
gefilmt und bekommen anschließend
evtl. noch einen Fragebogen. Mitunter
werden durch unstrukturierte Interviews
zusätzliche Informationen gewonnen.
Experten werten die Daten aus, beurteilen anschließend die Datenlage und
kommen zu entsprechenden Vorschlägen, die in den Designprozess einfließen.
Ein Nachteil der Labor Tests bzw. anderer Methoden mit direktem Nutzerkon-
zur Entscheidung zu kommen. In
diesem Tutorial werden einige Methoden vorgestellt, die es ermöglichen schnell und mit wenig Aufwand
an das nötige Feedback zu gelangen. Die vorgestellten Verfahren
sind insbesondere auch zum Einsatz in Online-Studien geeignet.
takt ist der Aufwand (finanziell und
zeitlich). Für die im Designprozess
auftretenden Probleme wird eine kostengünstige und schnelle Methode
benötigt, um auf empirischer Basis
Entscheidungen zu treffen.
Nun sind aus den Bereichen der empirischen Marktforschung und der experimentellen Psychologie Methoden
bekannt, die prinzipiell in Frage kommen, Entscheidungshilfe zu leisten,
z.B.: Magnitude Estimation, conjoint
Measurement, vollständiger Paarvergleich sowie Fragebögen.
Insbesondere in Kombination mit der
Nutzung des Inter-/Intranets, bieten
sich solche quantitativen Methoden an,
um zügig an Feedback zu gelangen.
Nach unserer Erfahrung wird dies aber
selten praktiziert. Gerade die Methoden, die helfen unter Zeitdruck Entscheidungen zu treffen, sind eine sinnvolle Ergänzung im Methodenrepertoire.
2.0
Skalierungsverfahren
Skalierungsverfahren sind etablierte Methoden der empirischen Wissenschaften. Sie ermöglichen es, die
Qualität von Objekten in Bezug auf
Keywords
Quantitative Methoden, BTLSkalierung, Magnitude Estimation,
Conjoint Measurement
vorgegebene Kriterien zu messen. Die
Messwerte werden dabei aus den Daten
von Personen ermittelt, die die Alternativen in Bezug auf das Kriterium beurteilen. Für die Datenerhebung reichen in
der Regel kleine Stichproben (10 – 20
Personen) aus.
Beim Einsatz im Bereich des User Interface Designs sind die Objekte in der
Regel Designalternativen, z.B. Screens,
einzelne Controls, oder Entwürfe für das
visuelle Design. Als Kriterien für die Bewertung kommen z.B. die wahrgenommene Usability oder die Ästhetik des
Designs in Frage.
Die meisten Skalierungsmethoden sind
in Bezug auf die Datenerhebung recht
einfach. Sie eignen sich damit sehr gut
dafür, während des Designprozesses
schnell zu Entscheidungen zwischen
alternativen Entwürfen zu kommen. Wegen ihrer einfachen Struktur sind Skalierungsverfahren auch sehr gut für OnlineStudien geeignet.
Wir beschreiben drei Skalierungsverfahren, die wir teilweise schon in einigen
Projekten erfolgreich eingesetzt haben.
25
2.1
BTL Skalierung (Vollständiger
Paarvergleich)
Die Daten für eine BTL Skalierung
(Bradley & Terry 1952; Luce 1959) werden über einen vollständigen Paarvergleich ermittelt. Dabei werden n Personen jeweils alle Paare von Alternativen
(in zufälliger Reihenfolge) vorgelegt. Die
Person entscheidet dann für jedes Paar,
welche Alternative sie bevorzugt.
Die Alternativen sollten gleich häufig an
den beiden Positionen auftauchen, um
Reihenfolgeeffekte auszuschließen.
Dies wird oft dadurch erreicht, dass jedes Paar zweimal mit vertauschten Positionen dargeboten wird. Aus den Daten
der n Beurteiler kann dann die sogenannte Dominanzmatrix berechnet werden. Diese listet für jedes Paar (a, b)
von Alternativen auf, wie häufig Alternative a gegenüber Alternative b bevorzugt
wurde.
Aus der Dominanzmatrix werden dann
die Skalenwerte S(a) der Alternativen
ermittelt. Hier liegt die Annahme zugrunde, dass die Häufigkeit, mit der eine
Alternative einer anderen vorgezogen
wird, nur von den Skalenwerten der Alternativen abhängt. Konkret geht man
von folgendem Zusammenhang1 aus:
P ( a , b)
S (a )
S (a ) S (b)
Die BTL Skalierung liefert eine Verhältnisskala. Angenommen wir skalieren
mehrere visuelle Designs bzgl. ihrer
Ästhetik und für zwei dieser Designs a, b
gilt S(a) = 2 S(b). Dann kann man
schlußfolgern, daß Design a als doppelt
so ästhetisch wahrgenommen wird wie
Design b.
1 Dabei ist P(a, b) die Wahrscheinlichkeit,
dass a gegenüber b bevorzugt wird und
S(a) bzw. S(b) sind die Skalenwerte der
Alternativen a und b.
26
BTL Skalierung bietet sich insbesondere an, wenn man wenige2 Designalternativen in Bezug auf eine interessante Ausprägung (Ästhetik, wahrgenommene Usability, etc.) vergleichen
will. Besonders geeignet ist das Verfahren bei einfachen Reizen, z.B. visuellen Designs, bei denen man im
Paarvergleich jeweils zwei Alternativen
parallel darbieten kann.
Eine ausführliche Darstellung der BTL
Skalierung findet man z.B. in Gediga
(1998). Anwendungen auf das Formulardesign sind z.B. in Schrepp et al.
(2007) beschrieben.
2.2
Conjoint Measurement
Die Conjoint Analyse oder verbundene Messung wurde zur Messung
multidimensionaler Objekteigenschaften entwickelt. Das heutige Hauptanwendungsgebiet der Methode ist die
empirische Marktforschung.
Im Bereich des User Interface Designs
eignet sich die Conjoint Analyse immer
dann, wenn die alternativen Designentwürfe durch eine Anzahl von unabhängig voneinander variierbaren Attributen charakterisiert sind. In einer
Anwendung auf das Formulardesign
(Schrepp et al. 2007) wurde z.B. untersucht, wie sich die Anordnung der
Feldbezeichner, die Balance des Layouts und die Visualisierung der Feldgruppierung auf die Ästhetik des Formulardesigns auswirken.
Bei der Conjoint Analyse ist jede Alternative durch die Ausprägung der Attribute beschreiben. Das Verfahren liefert nun pro Attribut Skalenwerte, die
beschreiben, welchen Einfluss das
jeweilige Attribut auf das vorgegebene
Beurteilungskriterium hat. In der oben
beschriebenen Untersuchung zum
2 Der zeitliche Aufwand für einen vollständigen Paarvergleich steigt mit der Zahl
der Alternativen stark an.
Formularlayout lieferte das Verfahren
z.B. Skalenwerte für die drei Attribute
Anordnung der Feldbezeichner, Balance
des Layouts und Visualisierung der
Gruppen. Die Skalenwerte beschreiben
den Einfluss des jeweiligen Faktors auf
die Ästhetik des Layouts.
Die Daten für eine Conjoint Analyse
werden in der Regel über ein RankingVerfahren ermittelt. Bei einem RankingVerfahren ordnet ein Beurteiler alle Alternativen entsprechend seiner Präferenz direkt an. D.h. jeder Beurteiler produziert hierbei eine Rangreihe der Alternativen. Dieses Verfahren hat den Vorteil, dass es bei einer überschaubaren
Anzahl von zu beurteilenden Objekten
sehr schnell durchzuführen ist.
Die Skalenwerte der Attribute werden
aus den beobachteten Rangreihen über
eine Regressionsanalyse bestimmt.
Die Conjoint Analyse eignet sich immer
dann, wenn man den Einfluß bestimmter
Faktoren auf den Eindruck untersuchen
will, den ein Design beim Benutzer hervorruft.
Eine übersichtliche Darstellung über die
wesentlichen Aspekte der Conjoint Analyse gibt Klein (2002).
2.3
Magnitude Estimation
Anders als bei den beiden oben
vorgestellten indirekten Skalierungsverfahren handelt es sich bei der Magnitude
Estimation um einen Ansatz zur Direktskalierung. Das Verfahren wurde von
Stevens (1946) vorgeschlagen. In einem
typischen Magnitude Estimation Experiment ist es die Aufgabe der Versuchsperson, Reizen numerische Werte in der
Weise zuzuordnen, dass die zugeordneten Werte proportional zur Empfindungsgröße des wahrgenommenen Reizes sind. Im Allgemeinen wird zunächst
einem Referenz-Reiz ein gegebener
Wert zugeordnet (z.B. 100) und die Versuchsperson ist angehalten alle folgen-
den Wertezuordnungen auf diesen Referenzwert zu beziehen. Wenn die Versuchsperson also einen Reiz als dreimal
so intensiv (z.B. „laut“, „hell“, „angenehm“) wie den Referenzreiz empfindet,
sollte sie diesem Reiz eine dreimal so
hohe Zahl zuordnen (z.B. 300 bei einer
Referenz von 100). Ohne auf die formalen Details dieses Skalierungsverfahrens
einzugehen, sei hier nur erwähnt, dass
nach Stevens auf Basis der Daten eines
Magnitude Estimation Experiments eine
Verhältnisskala konstruiert werden kann.
Magnitude Estimation ist eine weitverbreitete Methode in der empirischen
Marktforschung und nach wie vor auch
in der experimentellen Psychologie. Interessant für Usability Professionals ist,
dass eine Anwendung des Verfahrens
für die Skalierung von Interaktionssequenzen bezüglich ihrer wahrgenommenen Usability vorgeschlagen wurde.
McGee (2003) und Rich & McGee
(2004) präsentieren mit der „Usability
Magnitude Estimation“ einen Ansatz, der
für sich beansprucht, effizient und verlässlich Verhältnisskalen zur wahrgenommenen Usability von Softwareprodukten zu generieren. Die Rolle der Reize spielen bei diesem Verfahren einzelne Interaktionssequenzen, die die Versuchsperson bei der Bedienung eines
Softwareprodukts zu durchlaufen hat.
Wie bei traditionellen Magnitude Estimation-Experimenten wird der Versuchsperson mit Hilfe neutraler Interaktionen
eine Bewertungsreferenz vorgegeben.
Die Interaktionssequenzen des zu beurteilenden Softwareprodukts werden
dann in Bezug auf die Referenz mit Zahlenwerten beurteilt.
Da die Versuchsperson bei allen Zuordnungen numerischer Werte auch die
vorher erfolgten Zuordnungen berücksichtigen muss, ist die Durchführung
eines solchen Verfahrens potentiell mit
einer hohen kognitiven Belastung verbunden.
Befunde der modernen psychologischen Messtheorie zeigen zudem,
dass Magnitude Estimation nicht notwendigerweise zu einer Verhältnisskalierung führt. Eine Theorie von Narens
(1996) bietet eine Axiomatisierung der
zugrunde liegende Messstruktur und
zeigt die notwendigen Bedingungen für
die Identifikation des realen Skalentyps auf. Zimmer et al. (2004) stellen
einen Vergleich von BTL-Skalierung
und Magnitude Estimation an und betonen ebenso das Problem des undeterminierten Skalentyps bei der Magnitude Estimation.
3.0
Fragebogen
Eine schnelle und einfache Möglichkeit, subjektive Einschätzungen
von Endbenutzern zu erheben, sind
Fragebögen. Zur Evaluation von Software stehen verschiedene solcher
Verfahren zur Verfügung. Diese können sich unterscheiden hinsichtlich
ihrer Zielsetzung, der Art der erzeugten Daten (quantitativ, ggf. zusätzlich
qualitativ) oder auch des Erhebungsaufwands.
Manche Fragebögen sind in erster
Linie darauf ausgelegt, eine grobe
Einschätzung von Produktmerkmalen
zu liefern. Ein Beispiel hierzu ist die
System Usability Scale SUS (Brooke
1996), der es erlaubt, aufgrund von 10
Items einen Gesamt-Usability-Wert zu
ermitteln, der zwischen 0 und 100 rangiert.
Ein differenzierteres Bild hinsichtlich
der Produkteigenschaften kann beispielsweise der IsoMetricsS (Gediga &
Hamborg 1999) liefern, der sich an
den Kriterien für Gebrauchstauglichkeit
gemäß ISO 9241 Teil 10 orientiert. Der
Benutzer beurteilt die Ausprägung der
entsprechenden Eigenschaften, wie
etwa der Aufgabenangemessenheit
oder der Fehlerrobustheit.
Der UEQ (Laugwitz et al. 2006) wurde
hingegen mit dem Ziel konstruiert, eine
schnelle, möglichst unmittelbare Einschätzung des Produkts bzw. der Zufriedenstellung des Benutzers gemäß
ISO 9241 Teil 11 zu unterstützen. Die
Auswertung liefert dann intervallskalierte
Werte auf fünf Skalen, darunter „Originalität“ oder „Vorhersagbarkeit“.
Die genannten Fragebögen liefern quantitative Daten und sind dadurch in der
Auswertung sehr effizient und besonders für eine computergestützte Erhebung geeignet. Andere Verfahren erlauben ein teil-standardisiertes Vorgehen,
in dem nicht nur ein Wert auf einer Ratingskala ausgewählt werden kann, sondern zusätzlich Raum für freitextliche
Äußerungen gegeben ist (z. B. IsoMetricsL, Gediga & Hamborg 1999; ErgoNorm-Benutzerfragebogen, Dzida et
al. 2000). Die Ergebnisse der qualitativen Anteile können Erkenntnisse über
Stärken und Schwächen des Produkts
mit einem Detaillierungsgrad liefern, wie
es den rein quantitativen Verfahren nicht
möglich ist. Preis hierfür sind ein erhöhter Erhebungs- und Auswertungsaufwand.
Auch wenn es dem Interaktionsdesigner
jederzeit freisteht, eigene Fragen zu
formulieren oder Fragensätze zu erstellen, sollte nach Möglichkeit den veröffentlichten Verfahren den Vorzug geben,
da hier relevante Gütekriterien wie die
Objektivität, Reliabilität und Validität
dokumentiert und nachvollziehbar sind.
Von der Abänderung vorhandener Fragebögen ist grundsätzlich abzuraten.
Für die Einschätzung oder den Vergleich
von Produkten hinsichtlich einzelner
Dimensionen wie Ästhetik oder wahrgenommene Usability durch Endnutzer
sind außerdem die oben beschriebenen
Skalierungsverfahren eher geeignet.
Einen Überblick über den Einsatz von
Fragebögen im Bereich Softwareergo-
27
nomie bieten z. B. Dzida et al. (2000)
oder auch Hamborg (2004).
4.0
Anwendungsbeispiel
Aus dem Tagesgeschäft der Autoren soll im Folgenden die Vorgehensweise für eine BTL-Skalierung kurz umrissen werden.
Es standen sechs Designvorschläge von
Widgets für eine Web-Applikation zur
Verfügung. Ziel war es, so zügig wie
möglich, eine Entscheidung für eine der
sechs Designalternativen zu treffen. Die
Widgets wurden in eine vorhandene
Screenstruktur integriert und davon
Screenshots angefertigt. Mithilfe eines
Softwaretools auf Basis von PXLab (Irtel
2007) wurde ein Online-Paarvergleich
generiert und im Intranet von SAP zugänglich gemacht. Alle Produktmanager
und User Interface Designer aus dem
CRM Bereich wurden per E-Mail aufgefordert den Paarvergleich durchzuführen.
Insgesamt wurden aus den sechs Designalternativen 15 Paare generiert. Die
Versuchspersonen mussten mithilfe der
Pfeiltasten ihre Entscheidung bezüglich
der Ästhetik für jedes Paar treffen (siehe
Abbildung 1). Für alle Entscheidungen
benötigten die Versuchspersonen im
Durchschnitt 5 Minuten.
Abb. 1: Screenshot zu einer Entscheidung für
einen der beiden Designvorschläge.
Das Softwaretool übernahm automatisch
die Datenauswertung und lieferte die
28
Skalenwerte für jede Designalternative
in numerischer und grafischer Form.
Die Daten wurden nach der BTLProzedur (Bradley & Terry 1952; Luce
1959) ausgewertet. Zu diesem Zweck
wurde auf das „eba“-Modul (Wickelmaier 2008) für die Statistiksoftware R
zurückgegriffen.
Der zeitliche Aufwand zur Abwicklung
der gesamten Studie, belief sich lediglich auf wenige Stunden. An einem
Tag konnte der Paarvergleich erstellt,
die Aufforderung zur Teilnahme per
Email versandt und die Ergebnisse
schon einige Stunden später gesichtet
werden. Dies ermöglichte eine zügige
Entscheidung für einen der Designvorschläge auf Basis von empirischen
Daten.
5.0
Fazit
Skalierungsverfahren erlauben es
den Einfluss bestimmter Designeigenschaften auf den durch das Design
hervorgerufenen Eindruck sehr genau
zu bestimmen. Dies kann insbesondere bei Fragen relevant sein, bei denen
eine Abwägung zwischen verschiedenen Faktoren bedeutsam ist. Zum Beispiel stellt sich bei der Gestaltung von
Web-Anwendungen oft die Frage, ob
der durch die Verwendung eines komplexeren Style-Sheets verbesserte
visuelle Eindruck die dadurch evtl.
hervorgerufene Verschlechterung bei
der zum Seitenaufbau notwendigen
Zeit aufwiegt. Solche Fragen können
mit den beschriebenen Skalierungsverfahren gut untersucht werden.
Der Einsatz von Fragebögen ist dann
besonders sinnvoll, wenn ein Maß für
bestimmte komplexe Produkteigenschaften (eingeschätzte Usability, Benutzerzufriedenheit) benötigt wird.
Fragebogendaten können zu verschiedenen Zeitpunkten mit unterschiedlichen Befragten zu verschiedenen Produkten erhoben werden und
erlauben es dennoch bis zu einem gewissen Grad, Vergleiche zwischen verschiedenen Produkten oder Produktversionen anzustellen.
Im Designalltag können quantitative
Methoden, wie die oben dar gestellten,
bei Designentscheidungen effiziente
Unterstützung bieten. Dies gilt insbesondere, wenn die Datenerhebung und
die Auswertung web- bzw. computergestützt erfolgt. Die im Tutorial vorgestellte
Software ermöglicht das Durchführen
von Online-Studien mit BTL-Skalierung,
Magnitude Estimation sowie Fragebogen.
6.0
Literatur
Bradley, R. A.; Terry, M. E. (1952): Rank
Analysis of Incomplete Block Designs: I. The
method of Paired Comparisons. Biometrika,
Vol. 39, S. 324-345.
Brooke, J. (1996): SUS: a "quick and dirty"
usability scale. In: Jordan, P. W.; Thomas, B.;
Weerdmeester, B. A.; McClelland, A. L.
(Hrsg.): Usability Evaluation in Industry. London: Taylor and Francis.
DIN EN ISO 9241-10 (1996): Ergonomische
Anforderungen für Bürotätigkeiten mit Bildschirmgeräten. Teil 10: Grundsätze der Dialoggestaltung. Berlin: Beuth Verlag.
DIN EN ISO 9241-11 (1999): Ergonomische
Anforderungen für Bürotätigkeiten mit Bildschirmgeräten. Teil 11: Anforderungen an die
Gebrauchstauglichkeit - Leitsätze. Berlin:
Beuth Verlag.
Dzida, W.; Hofmann, B.; Freitag, R.; Redtenbacher, W.; Baggen, R.; Geis, T.; Beimel, J.;
Zurheiden, C.; Hampe-Neteler, W.; Hartwig,
R.; Peters, H. (2000): 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
Arbeitschutz und Arbeitsmedizin. Dortmund:
Bundesanstalt für Arbeitschutz und Arbeitsmedizin.
Gediga, G. (1998): Skalierung. Münster: Lit
Verlag.
Gediga, G.; Hamborg, K.-C. (1999): IsoMetrics: Ein Verfahren zur Evaluation von
Software nach ISO 9241-10. In: Holling, H.;
Gediga, G. (Hrsg.): Evaluationsforschung.
Göttingen: Hogrefe, S. 195 - 234.
Hamborg, K.-C. (2004): Fragebögen zur Bestimmung der ergonomischen Qualität von
Software. In: Hassenzahl, M.; Peissner, M.
(Hrsg.): Usability Professionals 2004. Berichtband des zweiten Workshops des German Chapter der Usability Professionals Association e. V.. Stuttgart: German Chapter der
Usability Professionals Association e. V., S.
92-95.
Irtel, H. (2007). PXLab: The Psychological
Experiments Laboratory (Vers. 2.1.11). Online im Internet: URL: http://www.pxlab.de
(Stand 19. 6. 2007).
Laugwitz, B.. Schrepp, M. & Held, T.(2006):
Konstruktion eines Fragebogens zur Messung der User Experience von Softwareprodukten. In: A.M. Heinecke & H. Paul (Hrsg.):
Mensch & Computer 2006, 125–134. München: Oldenbourg Verlag.
Luce, R. D. (1959): Individual choice behavior: A theoretical analysis. New York: Wiley.
Stevens, S. S. (1946): On the theory of scales
of measurement, Science, 103, 677-680.
Klein, M. (2002): Die Conjoint-Analyse.
Eine Einführung in das Verfahren mit einem
Ausblick auf mögliche sozialwissenschaftliche Anwendungen. In: Zentralarchiv für
empirische Sozialforschung (Hrsg.), ZAInformation 50, 7–45. Köln: Universität zu
Köln.
Wickelmaier, F. (2008, März): The eba package. URL:
http://ftp5.gwdg.de/pub/misc/cran/web/packag
es/eba/eba.pdf (Stand: 26.05.2008).
McGee, M. (2003): Usability magnitude
th
estimation. Proceedings HFES, 47 Annual
Meeting, 691-695.
Zimmer, K., Ellermeier, W. & Schmid, C.
(2004): Using probabilistic choice models to
investigate auditory unpleasantness. Acta
Acustica united with Acustica, 90, 1019-1028.
Narens, L. (1996): A theory of magnitude
estimation. Journal of Mathematical Psychology, 40, 109-129.
Rich, A. & McGee, M. (2004): Expected
usability estimation. Proceedings HFES,
th
48 Annual Meeting, 912-916.
Schrepp, M., Held, T. & Fischer, P. (2007):
Untersuchung von Designpräferenzen mit
Hilfe von Skalierungsmethoden. MMIInteraktiv, Nr. 13, S. 72- 82.
29
Kognitive Modellierung in der Konzeption und Evaluation
von Softwareprodukten
Dr. Theo Held
SAP User Experience
Applications, CRM
SAP AG
69190 Walldorf
[email protected]
Dr. Martin Schrepp
SAP User Experience
Applications, CRM
SAP AG
69190 Walldorf
[email protected]
Dietrich Mayer-Ullmann
SAP User Experience
Applications, CRM
SAP AG
69190 Walldorf
[email protected]
Daniel Holt
Psychologisches Institut
Universität Heidelberg
Hauptstraße 47-51
69117 Heidelberg
[email protected]
Abstract
Kognitive Modellierung ist eine sehr hilfreiche Verfahrensweise im Prozess des
Produktdesigns. Grundsätzlich geht es
darum, möglichst fundierte und präzise
Vorhersagen über den zu erwartenden
zeitlichen (und auch kognitiven) Aufwand eines geübten Nutzers beim
Durchlaufen spezifischer Interaktionsaufgaben zu machen. Derartige Vorhersagen können die Arbeit von Interaktionsdesignern erheblich erleichtern,
1.0
Einführung
Interaktionen mit Softwareprodukten
setzen sich üblicherweise aus immer
wiederkehrenden elementaren Operationen zusammen. Beispiele dafür sind
mehr oder weniger unmittelbar beobachtbare Handlungen, wie z.B. Mausbewegungen, Tastaturanschläge oder
auch Änderungen der visuellen Fokussierung. Dazu kommen vielfältige kognitive Operationen wie Verlagerungen der
Aufmerksamkeit, Nachdenken oder
visuelle Suchen.
Ausgehend von „Low Level“ Modellen
der kognitiven Architektur, z.B. ACT-R
(Anderson & Lebiere, 1998), entstand
eine Reihe vereinfachter und in der
Praxis gut verwendbarer Ansätze zur
kognitiven Modellierung, die Aussagen
über die Zusammenhänge zwischen den
elementaren Operationen machen.
Prinzipiell geht es bei allen bekanten
Modellierungsansätzen darum, elementare Operationen, die zur Erledigung
einer Aufgabe erforderlich sind, zu iden-
30
wenn es darum geht, Designvarianten
miteinander zu vergleichen. Zur Anwendung steht eine Reihe prominenter
Modellierungsansätze zur Verfügung.
Wir werden hier die Familie der
GOMS-Modelle und das ACT-R basierte CogTool vorstellen. Als wichtige
Ergänzung stellen wir auch eine Möglichkeit vor, wie die zeitliche Dauer
elementarer Operationen effizient und
präzise bestimmt werden kann.
Keywords
tifizieren. Diesen Operationen werden
Zeiten zugeordnet und daraus wird die
Gesamtzeit für eine Aktion, die sich
aus den elementaren Operationen
zusammensetzt, ermittelt. Solche Analysen sind im Rahmen der Softwareproduktion sehr hilfreich, wenn es gilt,
unterschiedliche konzeptionelle Ansätze zu vergleichen, bevor eine Designentscheidung getroffen wird, bzw.
wenn bereits existierende Produkte mit
anderen Produktvarianten oder auch
Konkurrenzprodukten verglichen werden sollen. Die vergleichenden Analysen vermitteln Klarheit darüber, welche
und wie viele elementare Operationen
für das Erledigen typischer Aufgaben
erforderlich sind und mit welchen geschätzten zeitlichen Aufwänden (eines
geübten Nutzers) insgesamt gerechnet
werden muss. Es sind üblicherweise
Alternativen zu bevorzugen, die einen
geringeren kognitiven Aufwand erfordern und gleichzeitig weniger Zeit benötigen.
lierung vorgestellt, die im Rahmen der
Produktion von Business-Software eingesetzt werden. Wir diskutieren, wie sich
die Ergebnisse einer Modellierung gewinnbringend in den Design- und Entwicklungsprozess integrieren lassen und
welcher Beitrag zur Verbesserung der
Software-Qualität damit geleistet wird.
In unserem Beitrag werden zwei „High
Level“ Ansätze der kognitiven Model-
Kognitive Modellierung, GOMS, KLM,
User Performance
Als zwei prominente Vertreter der High
Level Ansätze habe wir GOMS (Card,
Moran & Newel, 1983) und das ACT-R
basierte CogTool (John & Salvucci,
2005) gewählt. Anhand dieser Vertreter
werden auch die Limitationen der Anwendbarkeit und generelle Nachteile der
Modellierungsansätze diskutiert.
Als Ergänzung der Modellansätze stellen wir zudem ein Software-Tool vor,
das die für die Modellierung erforderlichen Zeiten ermittelt. Das „User Performance Measurement Tool“ zeichnet sich
aus durch eine umfangreiche Konfigurierbarkeit und eine gute Anpassbarkeit
an sehr unterschiedliche Stufen der
Granularität der zu untersuchenden
Operationen.
2.0
GOMS Modelle
GOMS ist eine quantitative Methode
zur Bewertung der Effizienz von Benutzerschnittstellen. Eine GOMS Analyse
erlaubt vorherzusagen, wie lange ein
erfahrener Benutzer für die Bearbeitung
einer vorgegebenen Aufgabe in einer
vorgegebenen Benutzerschnittstelle
benötigt. GOMS ist daher geeignet verschiedene alternative Designvarianten
bzgl. ihrer Effizienz zu vergleichen.
Die Abkürzung GOMS steht für „Goals“,
„Operators“, „Methods“ und „Selection
Rules“. Dies sind die wesentlichen Komponenten eines GOMS Modells:
x
x
x
x
Ein Ziel (Goal) beschreibt, was der
Benutzer erreichen möchte.
Operatoren sind grundlegende physische oder kognitive Prozesse, die
der Benutzer zur Erreichung des
Ziels ausführen muss.
Methoden repräsentieren erlernte
Operator-Sequenzen, die ein Benutzer automatisch ausführt, um ein
Ziel oder Teilziel zu erreichen.
Stehen mehrere Methoden zur Verfügung, so entscheiden Selektionsregeln, welche Methode ausgeführt
wird.
Beispiele für typische physische Operatoren in GOMS Modellen sind das Drücken einer Taste, die Bewegung der
Hand von der Maus zur Tastatur oder
das Positionieren des Mauszeigers.
Beispiele kognitiver Operatoren sind der
Abruf einer Information aus dem Langzeitgedächtnis, die Entscheidung zwischen zwei Alternativen oder die mentale Vorbereitung für den nächsten Schritt
in einer Sequenz.
Verschiedene Personen benötigen natürlich unterschiedliche Zeiten für diese
Operationen. Für einen Vergleich zwischen mehreren alternativen Entwürfen
ist es aber ausreichend von der konkreten Person zu abstrahieren und auf typische Durchschnittswerte zurückzugreifen. Solche Durchschnittswerte werden
in experimentellen Studien ermittelt (z.B.
John & Kieras, 1996; Olson & Olson,
1990; Schrepp & Fischer, 2007). Auch
das unten vorgestellte UPM-Tool kann
dazu eingesetzt werden.
Beispiele verwendeter Durchschnittszeiten sind:
x
x
x
Tastendruck beim Tippen einer
Zeichenkette (0,2 Sekunden)
Positionieren des Mauszeigers
(1,1 Sekunden)
Mentale Vorbereitung für den
nächsten Schritt einer Sequenz
(1,35 Sekunden)
Es sind mehrere Varianten von GOMS
vorhanden. Zum Beispiel das „Critical
Path Method GOMS“ (CPM-GOMS),
die „Natural GOMS Language“
(NGOMSL) oder das „Keystroke Level
Model“ (KLM-GOMS). Diese Varianten
unterscheiden sich in der Komplexität
der Modellierung und damit bzgl. der
Genauigkeit der geschätzten Zeiten.
Das Keystroke Level Modell ist die
einfachste Form der GOMS Analyse.
Diese Variante beschränkt sich bei der
Vorhersage der Bearbeitungszeit einer
Aufgabe allein auf die dafür notwendigen Operatoren. Alternative Bearbeitungssequenzen, die über Selektionsregeln gesteuert werden, werden bei
dieser Variante nicht verwendet. Das
führt zu einer erheblichen Vereinfachung des Aufwands für die Modellierung. Deshalb ist diese Variante für die
praktische Anwendung in konkreten
Designprojekten besonders geeignet.
Bei der Analyse einer Aufgabenstellung mit KLM-GOMS ist es in der
Regel sehr einfach, die Sequenz aller
notwendigen physischen Operatoren
zu bestimmen. Wesentlich schwieriger
ist die korrekte Platzierung kognitiver
Operatoren. Typischerweise wird dies
gelöst, in dem man die Aufgabenstellung in mehrere Teilaufgaben zerlegt.
Vor jeder Teilaufgabe wird dann ein
kognitiver Operator (z.B. für mentale
Vorbereitung) platziert. Dies erfordert
ein gewisses Verständnis menschlicher
Problemlöseprozesse im analysierten
Aufgabengebiet und ist daher der
schwierigste Teil einer Analyse mit KLMGOMS.
Eine wesentliche Einschränkung des
KLM-GOMS ist, dass es dieser Ansatz
leider nicht erlaubt, parallele Prozesse
menschlicher Informationsverarbeitung
abzubilden. Bei Aufgaben, in denen solche parallelen Denkprozesse eine zentrale Rolle spielen, werden die aus der
KLM-GOMS Analyse resultierenden
Zeiten daher die realen Zeiten zur Aufgabenbearbeitung überschätzen.
Aufgrund der relativ einfachen Anwendbarkeit von KLM-GOMS eignet sich diese Methode in folgenden Bereichen:
x
x
x
3.0
Vergleich alternativer Designs bezüglich ihrer Effizienz für erfahrene
Benutzer.
Abschätzung, ob Aufgaben in einer
Benutzeroberfläche in der vorgegebenen Zeit erledigt werden können.
Evaluierung von Fragen im Bereich
der Barrierefreiheit von Entwürfen.
So kann schon mit Entwürfen geprüft werden, ob die spezifizierte
Tastaturbedienung im Vergleich zur
Mausbedienung ausreichend effizient ist (Schrepp & Hardt, 2007).
CogTool
CogTool wurde an der CarnegieMellon-University entwickelt (John et al.,
2004; John & Salvucci, 2005). Im Vergleich mit den Varianten von GOMS
basiert CogTool auf der „kognitiven Engine“ ACT-R, die von Anderson und
Lebiere (1998) vorgestellt wurde. Das
bedeutet, dass in die Zeiten, die CogTool liefert, wesentlich mehr Annahmen
und Erkenntnisse bezüglich erforderlicher kognitiver Operationen einfließen,
als es bei den klassischen GOMS Modellen der Fall ist. Beispiele sind die
Operationen „Nachdenken“, „Betrachten“, „bereite nächste Aktion vor“ etc.
31
Im Rahmen unserer Design-Arbeit wurde und wird CogTool z.B. in den folgenden Kontexten verwendet:
Man kann also annehmen, dass das
CogTool akkuratere und realitätsnähere
zeitliche Schätzungen liefert als GOMS.
Nähere Informationen zu CogTool und
die Software zum kostenlosen Download
finden sich unter www.cs.cmu.edu
/~bej/cogtool/. Wir werden hier nur auf
die wesentlichen Schritte zur Anwendung von CogTool eingehen. Die Arbeit
mit CogTool beinhaltet folgende wesentliche Aufgaben:
x
x
x
x
Erzeugen eines Design-Storyboards
mit dessen Hilfe Aufgaben ausgeführt werden können.
Definition einer Menge von Aufgaben.
Erzeugen eines Skripts.
Modifikation des Designs und Wiederholung der weiteren Schritte.
Ein Design-Storyboard besteht aus einer
Menge unterschiedlicher Screens oder
Screenzustände des zu untersuchenden
Systems (z.B. Eingabeformulare, Dashboards, Ergebnistabellen etc.).
Für jeden Screen (oder „Frame“ in der
CogTool Terminologie) werden dann
„Interaktions-Widgets“ erzeugt. Diese
Widgets sind mit den Screen-Elementen
assoziiert, die ein Nutzer beim Durchlaufen einer bestimmten Interaktionssequenz (d.h. einer Aufgabe) „anfassen“
würde (z.B. Eingabefelder, Menüs,
Check-Boxes etc.).
Einzelne Frames werden dann mit Hilfe
von „Übergängen“ (Transitions) miteinander verbunden. Ein Übergang führt
von einem Widget eines Frames zu einem anderen Frame. Abbildung 1 zeigt
ein Beispiel für ein Design-Storyboard in
dem bereits Widgets definiert sind. Die
Pfeile stellen die Übergänge dar.
32
x
x
Abb 1: Beispiel für ein CogTool DesignStoryboard mit Widgets und Übergängen.
Nun kommen die Aufgaben ins Spiel.
Designs werden natürlich bereits auf
der Basis möglicher typischer Interaktionssequenzen zusammengestellt.
Häufig lassen sich auf der Grundlage
eines gegebenen Designs unterschiedliche Aufgaben durchlaufen. Aus
den einzelnen Schritten einer Aufgabe
(z.B. „Öffne ein Menü“, „Speichere ein
Objekt“, „Navigiere zur Suche“ etc.)
kann nun ein Skript aufgezeichnet
werden.
Im Vergleich zu einer Aufgabe enthält
ein Skript auch Schritte, die automatisch von CogTool hinzugefügt werden.
(z.B. „Nachdenken“, „visuelle Orientierung“ etc.). In dieser Eigenschaft liegt
die besondere Stärke der Funktionsweise von CogTool. De facto wird das
Storyboard von CogTool in ein kognitives Modell basierend auf ACT-R übersetzt. Der Nutzer des Tools muss die
impliziten, nicht unmittelbar beobachtbaren kognitiven, motorischen oder
wahrnehmungsbezogenen Operatoren
weder kennen, noch explizit eingeben
– sie werden vom Tool geliefert.
Unsere Anwendung von CogTool als
Hilfsmittel zum Design von BusinessApplikationen hat gezeigt, dass die
vorhergesagten Zeiten durchgehend
sehr nahe an den Zeiten liegen, die
geübte Nutzer benötigen.
x
Vergleich unterschiedlicher Releases eines Softwareproduktes:
Wird das Anlegen eines Objekts in
Release n+1 wirklich schneller gehen als in Release n?
Vergleich unterschiedlicher Versionen eines Softwareprodukts: Wird
das Anlegen einer Order in der CallCenter Variante des Produkts
schneller gehen als in der (funktionsreicheren) Back-Office Version
Klärung grundsätzlicher Designfragen vor der Implementierung: Wird
Designvariante A zu einer höheren
Nutzer-Performance führen als Variante B?
Ein sehr wichtiges Feature von CogTool
ist das „ACT-R Visualisierungsfenster“.
Hier können die gemäß ACT-R angenommenen elementaren Operationen
inspiziert werden. Dadurch bekommt der
Anwender einen guten Überblick darüber, welcher Art diese Operationen
primär sind (z.B. motorische Aktion,
visuelle Orientierung, Nachdenken etc.).
Abbildung 2 zeigt beispielhaft den Inhalt
des Visualisierungsfensters. Einzelne
horizontale Balken stehen für die zeitliche Ausdehnung einzelner Arten von
Operationen. Zu beachten ist, dass
CogTool auch den parallelen Ablauf von
Operationen berücksichtigt.
Abb 2: ACT-R Visualisierungsfenster
Ein weiterer interessanter Aspekt ist die
Kombination von CogTool Nutzermodellen mit dem reinen Keystroke
Level Model-Ansatz, der die Stärken der
jeweiligen Systeme nutzt. Dazu werden
Interaktionen auf dem Keystroke-Level
detailliert mit CogTool modelliert und die
so gewonnenen Benutzungszeiten als
Makrooperatoren in ein höherstufiges
System übertragen, mit dem längere
Interaktionssequenzen im Baukastensystem zusammengestellt werden können. Dies verbindet den hohen Auflösungsgrad und einfache Umsetzung
der CogTool-Modellierung mit einem
pragmatischen Vorgehen zur Modellierung komplexer Interaktionsszenarien.
4.0
Messung elementarer Operationszeiten mit dem User Performance
Measurement Tool
Je nach gewähltem Modellierungsansatz und der Auflösung des Modells
können die betrachteten Interaktionen
aus einem oder mehreren elementaren
Operatoren bestehen, denen anschließend jeweils eine geschätzte Dauer
zugeordnet wird.
Zu diesem Zweck wurde das SoftwareTool UPM (User Performance Measurement) entwickelt, um das Erfassen der
Modellparameter zu erleichtern und zu
beschleunigen. Hauptfunktion des Tools
ist die möglichst exakte, informationshaltige und vollständige Aufzeichnung aller
Systemereignisse während der Interaktion eines Nutzers mit einem Softwareprodukt.
angepasst werden. Zudem kann mit
der Kalibrierung der „Auflösungsgrad“
für bestimmte Operator-Sequenzen
erhöht werden, indem variiert wird,
welche Elemente einer Sequenz als
eigenständige Ereignisse erfasst werden und welche Elemente mit anderen
kombiniert werden.
schiedliche Versionen des Tools. Neben
einer „Labor-Version“ mit umfangreichen
Funktionen (siehe Abbildung 3) existiert
eine kompakte „Online-Version“, die für
den Einsatz auf den Rechnern von Endnutzern und das Sammeln von Massendaten konzipiert wurde.
Durch die Vergabe sogenannter „Klassenattribute“ im Programmcode der zu
untersuchenden Bedienoberfläche
kann die Bedienung sehr spezifischer
oder sogar nur einmalig eingesetzter
Bedienelemente ermittelt und so die
Interaktion sehr detailliert nachvollzogen werden (z.B. Tabellenzeilen
2,5,10 einer Tabelle wurden mit gedrückter „Strg“-Taste und linker MausTaste selektiert).
5.0
Andererseits liefert das Tool auch Daten zu kombinierten Interaktionsschritten, wie z.B. Eingabe-Medienwechsel
zwischen Tastatur und Maus.
Neben der Ermittlung von Modellparametern ist das Tool natürlich auch
dazu geeignet, modellierte Interaktionsverhalten direkt an Prototypen oder
laufenden Systemen nachzutesten, um
Modell mit Realität vergleichen zu
können. Implementierungs- oder auch
Modellierungsfehler (z.B. falsche
zugrunde gelegte Annahmen) sind
dann schnell auffindbar.
Zudem kann das Tool aus aufgezeichneten Kombinationen von Ereignissen
bzw. Interaktionspfaden bereits die gesuchten Zeiten für (in Bezug auf einen
bestimmten Modellierungsansatz) relevante Operationen bereitstellen.
Das UPM Tool wurde zur Untersuchung
von Web-Anwendungen entwickelt und
kann durch eine Kalibrierungsfunktion
an Änderungen des Programmcodes
Abb 3: User Performance Measurement
Tool (Labor-Version)
Für unterschiedliche Einsatzzwecke
und -bedingungen existieren unter-
Diskussion
Kognitive Modellierung wurde von
uns im Zusammenspiel mit dem UPM
Tool erfolgreich innerhalb des Designprozesses für Business-Anwendungen
eingesetzt. Es ist wichtig zu erwähnen,
dass kognitive Modellierung wesentliche
Beiträge zur Identifikation von Designproblemen leisten und die Entscheidung
für das „optimale“ Design maßgeblich
unterstützen kann; jedoch sollte es möglichst in Verbindung mit anderen methodischen Ansätzen verwendet werden.
Unserer Ansicht nach kann kognitive
Modellierung formative Usability Tests
nicht ersetzen. Die oft ungeahnten Probleme, die von Endbenutzern „aufgedeckt“ werden, können üblicherweise
nicht per Modellierung identifiziert werden.
Wenn es um Designentscheidungen
geht, ist der benötigte zeitliche Aufwand
für das Bearbeiten von Aufgaben ein
wesentlicher Faktor. Andererseits ist
bekannt, dass neben der Zeit auch andere Einflüsse auf die „User-Experience“
berücksichtigt werden müssen. Einer
dieser Faktoren sind subjektive Präferenzen, die eher mit der Attraktivität
einer Nutzungsschnittstelle als mit der
zeitlichen Effizienz zu tun haben. Für die
Identifikation solcher Präferenzen sind
z.B. psychometrische Skalierungsverfahren (siehe Held et al., 2007) oder
Fragebögen geeignet (siehe z.B. Laugwitz et al., 2006).
Auch wenn CogTool (und auch GOMS
Editoren) den Nutzer beim Aufbau des
Modells weitgehend unterstützt, sind für
die Anwendung kognitiver Modellie-
33
rungsverfahren gewisse Grundkenntnisse aus den Bereichen der Modellierung
und der kognitiven Psychologie von Vorteil. Wir empfehlen deshalb, zumindest
bei den ersten Modellierungsprojekten
Experten zu Rate zu ziehen.
6.0
Literaturverzeichnis
Anderson, J.R.; Lebiere, C. (1998): The
Atomic Components of Thought. Mahwah:
Lawrence Erlbaum Associates.
Card S.; Moran T.P.; Newel A. (1983): The
Psychology of Human Computer Interaction.
Mahwah: Lawrence Erlbaum Associates.
Held, T.; Schrepp, M.; Fischer, P. (2007):
Skalierung von Designalternativen. In: T.
Gross (Hrsg.): Mensch & Computer 2007, 9–
18. München: Oldenbourg Verlag.
34
John, B.E.; Kieras, D.E. (1996): The GOMS
family of user interface analysis techniques:
Comparison and Contrast. ACM Transactions on Computer-Human Interaction, 3, 4,
S. 320-351.
John, B.; Prevas, K.; Salvucci, D.; Koedinger, K. (2004): Predictive Human Performance Modeling Made Easy. Proceedings of CHI, 2004 (Vienna, Austria, April 2429, 2004) ACM, New York.
John, B. E.; Salvucci, D. D. (2005): MultiPurpose Prototypes for Assessing User
Interfaces in Pervasive Computing Systems. IEEE Pervasive Computing 4 (4), 2734.
Olson, J.R.; Olson, G.M. (1990): The growth
of cognitive modelling in human-computer
interactions since GOMS. Human-Computer
Interaction, 5, S. 221-265.
Schrepp, M.; Fischer, P. (2007): GOMS models to evaluate the efficiency of keyboard
navigation in web units. Eminds – International Journal of Human Computer Interaction
Vol. I, No. 2, S. 33-46.
Schrepp, M.; Hardt, A. (2007): GOMS models
to evaluate the quality of an user interface for
disabled users. In: Eizmendi, G., Azkoita,
J.M. & Craddock, G.M. (Eds.), Challenges for
Assistive Technology, S. 646-651.
Laugwitz, B.; Schrepp, M.; Held, T.(2006):
Konstruktion eines Fragebogens zur Messung der User Experience von Softwareprodukten. In: A.M. Heinecke & H. Paul
(Hrsg.): Mensch & Computer 2006, 125–
134. München: Oldenbourg Verlag.
Mein System benutz‘ ich nicht: Ein praxisorientierter Ansatz,
Nutzerakzeptanz zu messen und zu verbessern
Henning Brau
Daimler AG
Data- & Processmanagement
Postfach 2360
89013 Ulm
[email protected]
Abstract
Der Beitrag stellt die Relevanz von
Akzeptanzuntersuchungen für Technologieeinführungen heraus. Dabei werden
verschiedene Ansätze der Akzeptanzanalyse dargestellt und auf ihre Praxistauglichkeit für konkrete Gestaltungsund Einführungsprojekte hin bewertet.
Es wird aufgezeigt, wie die Ergebnisse
1.0
Einleitung
Während Technologieakzeptanz in
der Konsumgüterwelt auch weiterhin ein
wenig beachtetes Konstrukt ist, hat sich
bei der Gestaltung von Technologiegetriebenen Veränderungsprozessen in
Organisationen in den letzten drei Jahrzehnten mit der verstärkten Durchdringung der Arbeitswelt durch Informationstechnologien (IT)1 ein wissenschaftlich
intensiv untersuchtes Feld ergeben.
Nicht zuletzt motiviert durch die Bedenken auf Arbeitgeberseite, dass Arbeitnehmer nicht in der Lage oder nicht
Willens sein könnten, IT-Systeme als
Arbeitsmittel zu akzeptieren, hat eine
vertiefte Auseinandersetzung auf psychologischer wie arbeitswissenschaftlicher Seite mit der Technologieakzeptanz stattgefunden.
Insbesondere älteren Mitarbeitern,
Frauen und Arbeitnehmern niederer bis
mittlerer Qualifikation wurde und wird
nachgesagt, dass sie weniger bereit
1
Auch wenn Technologie-Akzeptanz nicht
auf Software-Anwendungen beschränkt
ist, werden sich die weiteren Ausführungen hauptsächlich auf solche Systeme
beziehen.
von Praxisprojekten eine Abwendung
von rein theoriebasierten Ansätzen
bewirkt haben und in die Definition
eines pragmatischen und projektbezogenen Ansatzes der systematischen
Messung von Nutzerakzeptanz mündeten. Der Ansatz und seine praktischen Anwendung werden diskutiert.
Keywords
oder fähig seien, sich auf neue Technologien einzustellen. Frühe Befunde
untermauern tatsächlich diesen Eindruck und so ist es kein Wunder, dass
auch heute noch Alter, Geschlecht und
Qualifikation als maßgebliche Einflussfaktoren in fast jedem Akzeptanzmodell wieder zu finden sind. Sogar
die sogenannte „Computerangst“, von
den 70er bis frühen 90er Jahren der
Schrecken jeder IT-Einführung, findet
sich noch immer als zentraler Faktor in
vielen aktuellen Modellen wieder.
Die Technologieakzeptanz in heutigen
Einführungsprojekten bezieht sich tatsächlich weniger auf das „Ausrollen“
einer Technologie in einen technologiefreien Raum, sondern auf die Ablösung
eines Systems durch das nächste. Als
Veränderung nimmt der Mitarbeiter oft
nur noch die veränderte Benutzungsschnittstelle (grafische sowie konzeptuelle Oberfläche, Funktionsumfang und
direkte Interaktion) sowie einhergehende
Prozessänderungen innerhalb der einführenden Organisation wahr. Letztere
sind dabei oftmals relevanter für die
Akzeptanz als die „inneren“ Komponenten (HW/SW).
Diese Punkte aber widersprechen der
Demographie: 75% der deutschen
Haushalte haben heute einen PC mit
Internetzugang (Statista.org, 2008). Es
verbietet sich hier die Annahme, dass
nur hochqualifizierte junge Männer
diese auch nutzen. Man darf wohl eher
annehmen, dass der Haufen aus Silizium-Halbleitern (PC) mittlerweile seine Bedrohlichkeit für breite Schichten
der Bevölkerung weitgehend verloren
hat und etwas Alltägliches geworden
ist. Auch die heute älteren Arbeitnehmer blicken nicht selten bereits auf
mehr als 15 Jahre Computererfahrung
zurück – weitgehend unabhängig von
Geschlecht und zunehmend auch von
der Schulbildung.
Akzeptanz, Reaktanz, TechnologieEinführung, Veränderung, Organisation
Schon sind wir bei der Problemstellung,
der sich dieser Artikel widmen will: Auch
aktuelle Akzeptanzmodelle und -theorien
haben entscheidende Nachteile, wenn
man sie in der Praxis anwenden möchte:
x
Sie gehen häufig von einer freiwilligen Nutzung aus, von der im
Arbeitsleben kaum die Rede sein
kann.
x
Sie berücksichtigen zum größten
Teil die Sicht des Individuums (Demographie, Einstellungen), nicht die
der Organisation (Gruppendynamik,
Kooperation, Kommunikation etc.).
35
x
Sie messen meistens eine Akzeptanz, die sich rein auf die technologischen Aspekte, nicht aber auf die
mit ihnen einhergehenden Veränderungen in Organisation wie Prozessen vor, während und nach der Einführung bezieht; Technologie ohne
Kontext also.
x
Sie geben nebenbei bemerkt im
Allgemeinen so gut wie keine Hinweise zur Intervention bei ungünstiger Akzeptanzprognose.
Kurz: Für Praxisprojekte der Gestaltung
und Einführung sind diese Ansätze nur
eingeschränkt hilfreich. In diesem Artikel
wird nun ein pragmatisches Konzept der
Akzeptanzmodellierung vorgestellt und
seine Einbettung in das übergeordnete
Systems-Engineering besprochen.
2.0
Relevanz von Akzeptanzanalysen
In den frühen Tagen der Technologie-Einführungen in Unternehmen führten IT-Systeme ein Inseldasein. Sie hatten zumeist einen Werkzeug-Charakter
und waren auf nur wenige Funktionen
beschränkt. Diese Zeiten sind jedoch
vorbei. Moderne Engineering-Systeme
beispielsweise umfassen inzwischen
große Teile eines gesamten Produktlebenslaufes: von der Dokumentation
des frühen Designs, über die Archivierung von Konstruktionsdaten bis hin zur
Rückdokumentation von Garantiefällen
an die Produktentwicklung. Stehen momentan noch einzelne Clients im Vordergrund, die auf einen gemeinsamen
Daten-“Backbone“ zugreifen, geht der
Trend hin zu Vereinheitlichung und Integration.
Serviceorientierte Architektur und Organisation (SOA / SOO) ermöglichen es
zunehmend, alle Funktionen in einem
Client anzubieten, wobei der Mitarbeiter
nur jeweils die Funktionen zu Gesicht
bekommt, die er aktuell für bestimmte
Aufgaben benötigt.
36
Die immer komplexer werdenden ITSysteme formen aber längst nicht nur
mehr die Prozesse von Großunternehmen. Auch mittelständische bis
hinunter zu Kleinunternehmen werden
in immer stärkerem Maße abhängig
von einer effizienten Systemlandschaft
und deren adäquate Nutzung durch
die Arbeitnehmer. Längst wurde dabei
erkannt, dass Akzeptanz grade in frühen Phasen der Systemgestaltung ein
guter Indikator für den späteren Erfolg
in der Wertschöpfungskette sein kann.
Anders formuliert: Die Begründung für
die Ablehnung (Reaktanz) von Systemen als Arbeitsmittel hat viel mit der
Eignung des Systems für bestehende
Prozesse, mit der Bewertung dieser
Prozesse durch Nutzer sowie mit der
Kultur der Organisation zu tun. Ist diese Begründung bekannt, kann entsprechend interveniert werden. Somit
können nachfolgend System, Prozesse und Organisation optimiert werden.
3.0
Die Definition von Akzeptanz
Vor allem auf Basis der Theory of
Reasoned Action (TRA; Fishbein &
Aijzen, 1975) ist eine Vielzahl von elaborierten Modellen und Theorien der
Technologieakzeptanz entstanden.
Wichtige Meilensteine der Forschung
umfassen das Technology Acceptance
Model (TAM; Davis, 1986) und die
Unified Theory of Acceptance & Use of
Technology (UTAUT; Venkatesh, Morris, Davis & Davis, 2003).
Diese Ansätze haben alle den Anspruch,
eine Vorhersage der Technologieakzeptanz als tatsächliche Systemnutzung
(actual system use) anhand standardisierter Fragen (Items) zu ermöglichen.
Wenn Verhalten vorhergesagt werden
soll, müssen entsprechend die Prädiktoren bekannt sein, die eine Verhaltensintention (intention to use) erzeugen. Diese Prädiktoren sind im Wesentlichen
Nutzungseinstellungen (attitude towards
use) sowie Einflüsse aus dem sozialen
und organisatorischen Kontext der Nutzung, welche dann die Nutzungsintention direkt bzw. indirekt über die Einstellungen beeinflussen.
Einstellungen selbst sind psychische
Tendenzen, ein bestimmtes Objekt mit
einem Grad von Zu- oder Abneigung zu
bewerten (Eagly & Chaiken, 1998).
Zentral dabei ist der Vorgang der Bewertung, der auf Erfahrungen der bewertenden Person beruht. Die Prozesse, die zu
einer Einstellung führen sind dabei unterteilt in drei Komponenten (Rosenberg
& Hovland, 1960): Kognition (Meinungen, Gedanken und Informationen), Affekt (Gefühle, Emotionen) sowie Verhalten (Handlungsabsicht und tatsächliche
Handlungen). Akzeptanz ist also eine
mehrdimensionale positive Einstellung
gegenüber einen bestimmten Einstellungsgegenstand und bzw. oder einem
spezifischen Verhalten, welche sich in
kognitiven, affektiven und verhaltensbezogenen Reaktionen äußern kann.
4.0
perceived
usefulness
external
variables
attitude
towards use
intention
to use
perceived
ease-of-use
Abb. 1: TAM-Modell (Davis, 1986)
actual
system use
Prädiktoren der Akzeptanz
So weit so theoretisch. Lebendiger
wird es, wenn wir uns Beispiele für solche Einstellungen ansehen. Wir werden
an dieser Stelle den Terminus „Einstellung“ zugunsten von „Prädiktoren“ aufgeben. Diese sind Themen im Umfeld
der eigentlichen Technologie und der
Organisation, auf die sich die Einstellungen der Nutzer beziehen. Es gibt Prädik-
toren auf verschiedenen Ebenen, die
jeweils auf die nächsthöhere wirken.
Tabelle 1: Ebenen der Prädiktoren
Ebene:
Prädiktor:
I.
subjektiver Nutzen Æ
I.1.
I.1.1
Zeit
nötige Eingaben
Wahrnehmung:
vorhanden
Æ
Æ
Ersparnis
weniger
Im Beispiel in Tabelle 1 ist die Anzahl
nötiger Eingaben durch das Neusystem
gesunken (I.1.1). Dies ggf. zusammen
mit anderen Sub-Prädiktoren der Ebene
I.1.x (z.B. schnellere Verarbeitung, mehr
Automatisierung) führt auf einer höheren
Ebene (I.1) zur Wahrnehmung einer
Zeitersparnis. Diese wiederum führt mit
anderen Prädiktoren auf der Ebene I.x
(z.B. bessere Datensicherheit, geringere
Kosten) zu einer allgemein guten subjektiven Nutzenwahrnehmung (I.).
Hier finden wir etwas Entscheidendes,
das man kaum häufig genug wiederholen kann, auch wenn dies für Systementwickler mitunter frustrierend erscheinen mag: Akzeptanz hängt nicht von
den objektiven Eigenschaften eines Systems ab, sondern von der subjektiven
Wahrnehmungen des Nutzers bezüglich
dieser Eigenschaften. Beispielsweise
kann das neue System für eine bestimmte Berechnung nur noch Sekunden brauchen, wo früher Minuten nötig
waren. Je nach Kontext mag der Nutzer
dies dennoch als „lahm“ wahrnehmen;
vielleicht weil er das notwendige Wissen
nicht hat, die eigentliche Rechenleistung
zu bewerteten oder ihm die technischen
Parameter schlichtweg egal sind und er
die reine Wartezeit als unzumutbar erachtet.
Im TAM sind die beiden maßgeblichen
Prädiktoren denn auch „perceived usefulness“ (wahrgenommener Nutzen) und
„perceived ease-of-use“ (wahrgenommene Einfachheit der Benutzung). Das
UTAUT geht mutig sogar noch einen
Schritt weiter ins subjektiv Ungewisse
und spricht von „expectancy“ also Erwartungen, die Nutzer bezüglich „performance“ (Leistungsfähigkeit) und
„effort“ (Aufwand) an das System haben. Hier haben wir also einen prospektiven Charakter; eine subjektive
Wertelatte, die das System per se erst
einmal überspringen muss, um akzeptabel zu sein. Dies unabhängig davon,
ob die Nutzer das System überhaupt
schon kennen gelernt haben.
Beide Ansätze sehen noch weitere
Prädiktoren vor. Beim TAM werden
diese als „externe Variablen“ zusammengefasst, womit wirklich beinahe
alles gemeint sein kann: Demografische Daten, Einflüsse von Kollegen
und Vorgesetzten, Umgebungsfaktoren, individuelle Eigenschaften wie
Technologieangst etc. Das UTAUT
unterscheidet hier immerhin schon
zwischen „sozialen Einflüssen“ (Meinungen aus direktem wie indirektem
Umfeld der Nutzung), „unterstützende
Bedingungen“ (Training, Hilfesysteme,
technischer Support) sowie einer Reihe von demografischen Einflussgrößen (Geschlecht, Alter, Erfahrung,
Freiwilligkeit der Nutzung).
In verschiedenen Studien habe ich
zusammen mit verschiedenen Kollegen anfänglich versucht, anhand des
TAMs Vorhersagen der Akzeptanz zu
treffen. Dabei stellte sich die scheinbar
störende Offenheit des Modells bezüglich der externen Variablen im Nachhinein als Glückfall heraus. Je Studie
mussten zusätzlich zu den StandardItems immer auch zunächst noch die
maßgeblichen externen Variablen bestimmt und operationalisiert werden
(z.B. Brau & Schulze, 2004; 2005).
Dennoch waren diese angeblich nur
moderierenden Einflüsse zum Teil
deutlich aufschlussreicher für die Nutzerakzeptanz, als die Hauptprädiktoren des Modells selber. Insbesondere
Partizipation und Kommunikation entschieden in starkem Maße zwischen
Wohl und Wehe eines Einführungsprojektes (Brau & Schulze, 2005).
Dass Partizipation bedeutsam ist, steht
in guter Übereinstimmung mit den Erkenntnissen der Reaktanztheorie
(Brehm, 1972). Reaktanz entsteht als
negative Nutzungseinstellung nach einer
wahrgenommenen Einschränkung von
Handlungsspielräumen durch eine Veränderung, die von außen an eine Person herangetragen wird. Gestaltet ein
Nutzer die Veränderung mit, ist seine
Neigung zur Reaktanz geringer.
Die Relevanz der Kommunikation für die
Akzeptanz von Änderungsvorhaben
wurde bereits von Doppler und Lauterburg (1994) herausgestellt. Nur wenn
Informationen über eine Veränderung
verstanden werden, der eigene Nutzen
aus der Kommunikation heraus erkennbar ist und die Quelle der Information für
glaubwürdig gehalten wird, kann die
Bereitschaft entstehen, den Veränderungsprozess als solchen zu akzeptieren. Geeignete Partizipation und Kommunikation sind folglich bedeutsame
begünstigende Moderatoren der Technologieakzeptanz.
Doch zurück zu den „inneren“ Prädiktoren der Technologieakzeptanz. In unseren ersten Studien war bereits spürbar,
dass Veränderungsprozesse immer
auch durch Abwägung zwischen möglichen Chancen und Risiken bewertet
wurden. Dies steht in Übereinstimmung
zu den Aussagen Rayners (1993), der
explizit auf den Einfluss von Risikowahrnehmung auf die Akzeptanz von Technologien hinweist.
Getrieben von dieser Thematik wurde
eine groß angelegte Einführungsstudie
von Augmented Reality Systemen in die
LKW-Montage eines Mercedes-Benz
Werkes zum Anlass genommen, eine
tiefere Auseinandersetzung mit Ergebnissen der Risikoforschung als mögli-
37
chem zentralen Prädiktor für Technologieakzeptanz vorzunehmen (Ullmann,
2006). Die Studie wurde auf Basis des
UTAUT qualitativ (Prä-/Post-Interviewserie, Feldbeobachtungen, Teilnehmertagebuch) unter Feldbedingungen
durchgeführt. Als Ergebnis konnten folgende zentralen Akzeptanz-Prädiktoren
für dieses konkrete Projekt identifiziert
werden:
x
x
x
x
x
x
5.0
wahrgenommene Nützlichkeit
wahrgenommene Beanspruchung
wahrgenommene Risiken
Aufwandserwartung
unterstützende Bedingungen
soziale Einflüsse
Ableitung eines projektrelevanten
Akzeptanzmodells
Die Ergebnisse waren Auslöser dafür, die qualitativen Daten aller vorherigen Studien einer Meta-Analyse auf
Basis der Grounded Theory (Glaser &
Strauss, 1967) zu unterziehen. Hierbei
stellte sich heraus, dass sich einige wenige nicht mehr zu verdichtende Hauptprädiktoren ableiten lassen. Sie bilden
die Basis des projektrelevanten Akzeptanzmodells, das nachfolgend in Abbildung 2 wiedergegeben ist:
TA =
pU
pS + pR
× BT
2
Abb. 2: Projektrelevantes Akzeptanzmodell
Technologieakzeptanz (TA) ist im Inneren abhängig von drei Prädiktoren und
deren Verhältnis zueinander. Der wahrgenommene Nutzen (perceived usefulness; pU) als Akzeptanz erzeugendes
Moment wird verringert durch ein sum2
38
Auch wenn hier die Metapher einer Gleichung verwendet wird: Das Modell spiegelt keine mathematischen Abhängigkeiten wieder! Die Darstellung dient der Veranschaulichung der Verhältnisse der Prädiktoren zueinander.
mativ negatives Moment aus wahrgenommener Beanspruchung (perceived
strain; pS) und wahrgenommenem
Risiko (perceived risk; pR). Ein „externer“ Prädiktor wirkt weiterhin auf diese
„innere“ Technologieakzeptanz während des Veränderungsprozesses:
Vertrauensbilanz (bilance of trust; BT).
Hiermit ist die angesprochene Wirkung
adäquater Kommunikation und Partizipation auf das Veränderungsvorhaben
als solches gemeint.
1.) Perceived Usefulness: Wahrgenommene Nützlichkeit kann primärer
(z.B. Arbeitserleichterung, Zeitersparnis) oder sekundärer (z.B. beruflicher
Aufstieg, Anerkennung) Natur sein. In
Organisationskontexten sind primäre
Nutzen maßgeblich.
2.) Perceived Strain: Beanspruchung
bezeichnet alle Aspekte, durch die ein
subjektives Erleben von Erschwernis
durch die neue Technologie entsteht.
Dies umfasst physische wie psychische Anstrengungen, aber auch Aufwendungen aus dem Arbeitsumfeld
wie Zeit und Training.
3.) Perceived Risk: Risiken können
sozialer, ökonomischer, gesundheitlicher oder pragmatischer (z.B. Datenverlust durch Systemabsturz) Natur
sein. Die Folgen eines Risiko-Ereignisses werden hinsichtlich des Schädigungspotenzials und der persönlichen Betroffenheit bewertet.
4.) Bilance of Trust: Die Vertrauensbilanz entwickelt sich über die Zeit in
Abhängigkeit zur Bewertung der Botschaften, ihrer Quelle sowie dem Grad
der Partizipation. Vertrauen kann unabhängig vom inneren Verhältnis
der Technologiewahrnehmung - die
Akzeptanz des Veränderungsprozesses verstärken oder verringern. Dieser
Effekt verliert sich allerdings nach erfolgtem Roll-Out.
6.0
Anwendung und Vorgehen
Eine Tücke der Prädiktoren in diesem Modell ist, dass sie - ungleich zum
Anspruch der theoriebasierten Akzeptanzmodelle - nicht mit standardisierten
Items gefüllt werden können. Im Gegenteil stellt sich für jedes Projekt die Frage,
welche Sub-Prädiktoren auf die Hauptprädiktoren laden. Konkret bedeutet dies
also einen Abschied von der Annahme
eines Allheilmittels – jeder Patient benötigt eine individuelle Therapie.
Für konkrete Projekte sind somit zunächst die Sub-Prädiktoren zu ermitteln,
die für die Nutzergruppe relevant sind.
Hierbei sollte man sich nicht davon leiten lassen, welche Sub-Prädiktoren in
vorangegangenen Projekten maßgeblich
waren. Wird z.B. ein Wissensmanagementsystem eingeführt, sind die Risiken
eher unkritisch (z.B. Verlust von Alleinstellungsmerkmalen, wenn andere Nutzer auf „mein“ Expertenwissen zurückgreifen können). Bei der Einführung von
Systemen, die Rationalisierungszwecken dienen können, sieht dies anders
aus (z.B. Angst vor Arbeitsplatzverlust).
Ähnliches gilt für Systeme mit potenzieller gesundheitlicher Gefährdung.
Es sind unter Rückgriff auf alle sinnvoll
erscheinenden Informationsquellen (Mitarbeiter, Vorgesetzte, Feldbeobachtungen, Dokumente der Anforderungsanalyse) zunächst umfassend potenzielle
Sub-Prädiktoren zu erfassen. Diese
lassen sich durch Nutzerbefragungen
(Interviews und Fragebögen) im nachfolgenden Prozess priorisieren. Grobes
Ziel ist, die relevanten Top 5 der SubPrädiktoren je Hauptprädiktor benennen
zu können. Diese Sub-Prädiktoren können - wie unter Punkt 3.0 beschrieben ihrerseits wieder untergeordnete SubPrädiktoren haben. Die Gesamtheit der
identifizierten und priorisierten Prädiktoren ist im Projektverlauf kontinuierlich
mittels weiterer strukturierter Nutzerbefragungen (oder hemdsärmelig in
„Stammtischgesprächen“) zu evaluieren
und zu dokumentieren (Akzeptanzmanagement).
Ähnlich wie bei einem Anforderungsmanagement ist eine Unterscheidung in
funktionale bzw. nicht-funktionale Prädiktoren notwendig. Funktionale Prädiktoren beziehen sich auf Eigenschaften
der Technologie selber. Ihre Erhebung
dient zugleich als Input global für das
Anforderungsmanagement sowie spezifisch im Bereich User Interface/Usability.
Nicht-funktionale Prädiktoren beziehen
sich hingegen auf organisatorische bzw.
subjektive Aspekte. Sie dienen maßgeblich als Input für die strategische Projektkommunikation. Interventionsbedarfe
ergeben sich aus Evaluationen. Funktionale Bedarfe werden über das Anforderungsmanagement vertreten, nichtfunktionale Bedarfe sind vielschichtig
und langwierig zu beantworten. Dies
würde diesen Beitrag sprengen.
6.1
Integration des Akzeptanzmanagements in das Projekt
Die Aktivitäten, die im Rahmen des
Akzeptanzmanagements notwendig
sind, sollten Bestandteil des SystemsEngineerings sein und schon früh im
Projekt beginnen, beispielsweise während der Anforderungsanalyse. So kann
das Projekt frühzeitig akzeptanzrelevante Anforderungen identifizieren und diese umsetzen bzw. kommunizieren. Die
Systemqualität steigt damit sowohl objektiv als auch in der subjektiven
Wahrnehmung.
Nutzerzentrierte Gestaltungsprozesse
nach DIN EN ISO 13407 sehen Nutzerpartizipation zwingend vor. Damit ist
deren Implementierung in das SystemsEngineering gut zu argumentieren. Die
partizipierenden Mitarbeiter wirken so
gleichzeitig als Multiplikator gegenüber
ihren Kollegen – und sollten ihrer Doppelfunktion bewusst gemacht werden.
Für die strategische Kommunikationsplanung hingegen ist eine Aufmerksamkeit im Projektteam nicht unbedingt vorauszusetzen. Hier empfiehlt
es sich, früh in Überzeugungsarbeit zu
investieren. Grade die Erstkommunikation der Inhalte und Ziele des Projekts ist kritisch und bestimmend für
die gesamte Projektlaufzeit.
7.0
Brehm, J. W. (1972): Responses to Loss of
Freedom. A Theory of Psychological Reactance. Morristwon: General Learning Press.
Davis, F. D. (1986): A Technoogy Acceptance
model for Empirical Testing New End-User
Information Systems: Theory and Results.
Doctoral Dissertation, Sloan School of Management, Massachusetts Institute of technology.
Zusammenfassung
Theoriebasierte Akzeptanzmodelle
eignen sich nur eingeschränkt zum
Einsatz in Praxisprojekten zur Technologiegestaltung und -einführung. Es
wurde ein praxisrelevantes Akzeptanzmodell ausgehend von Theorien
aber auf Basis empirischer Studien
erarbeitet und vorgestellt. Bei diesem
Ansatz ist es von zentraler Wichtigkeit,
jedes Projekt als neue Herausforderung auch hinsichtlich der Nutzerakzeptanz sowie die Akzeptanzmodellierung als integrativen Bestandteil des
Gesamtprojektes zu verstehen. Die
Unterscheidung in funktionalen und
nicht-funktionalen Prädiktoren analog
des Anforderungsmanagement erleichtert die Einordnung der Prädiktoren in
das Veränderungsprojekt. Wird das
Akzeptanzmanagement kontinuierlich
umgesetzt, profitieren das Anforderungsmanagement, das Usability Engineering sowie die Projektkommunikation von diesen Aktivitäten.
8.0
schung und Praxis, S. 351 – 366. Symposion:
Düsseldorf.
Brau, H.; Schulze, H. (2004): Minimierung
von Reaktanz gegen IT-Einführungsprojekte an industriellen Arbeitsplätzen
durch Nutzerpartizipation. In: VDIWissenforum (Hrsg.). Useware 2004 –
Nutzergerechte Gestaltung Technischer
Systeme. VDI-Verlag GmbH: Düsseldorf.
Brau, H.; Schulze, H. (2005): Der Einfluss
von Partizipation auf die Akzeptanz handgeführter Industrieroboter. In: Karrer, K.;
Gauss, B.; Steffens, C. (Hrsg.). Beiträge zur
Mensch-Maschine-Systemtechnik aus For-
Doppler, K.; Lauterburg, C. (1996): Change
Management: Den Unternehmenswandel
gestalten. Frankfurt/Main; New York: Campus
Verlag.
Eagly, A. H.; Chaiken, S. (1993): The Psychology of Attitudes. San Diego, CA and Fort
Worth, TX: Harcourt Brace Jovanovich.
Fishbein, M.; Aijzen, I. (1975): Belief, Attitude,
Intention and Behavior. Reading, MA: Addison-Wesley.
Glaser, B. G.; Strauss, A. L. (1967): The Discovery of Grounded Theory. Strategies for
Qualitative Research. New York: Aldine.
Rayner, S. (1993): Risikowahrnehmung,
Technologieakzeptanz und institutionelle
Kultur: Fallstudien für einige neue Definitionen. In: Bayrische Rück (Hrsg.) Risiko ist ein
Konstrukt. Berlin: Knesebeck-Verlag.
Rosenberg, M. J.; Hovland, C. I. (1960): Cognitive, Afective and Behavioral Components
of Attitudes. In: Rosenberg, M.J.; Hovland,
C.I.; McGuire, W.J.; Abelson, R.P.; Brehm,
J.W. (Eds.): Attitude Organization and
Change, pp. 1-14. New Haven, CT: Yale
University Press.Statista.org.
Statista.org (2008). http://de.statista.org/statistik/ diagramm/studie/22496/umfrage/ haushalt-mit-internetzugang/ [16.07.08]
Ullmann, C. (2006): Nutzerakzeptanz von
Augmented Reality - Eine Fallstudie zum
Vollschichteinsatz in der Automobilproduktion. Unveröffentlichte Diplomarbeit. Universität Hamburg.
Venkatesh, V.; Morris, M.G.; Davis, G.B.;
Davis, F.D (2003): User Acceptance of Information Technology: Toward a Unified View,
MIS Quarterly, Vol. 27, No.3, pp. 425-478.
39
User Interface Prototypen in Usability Engineering und
Software Entwicklung: Probleme und Synergien
Markus Weber
Centigrade GmbH
Science Park 2
66123 Saarbrücken
[email protected]
Thomas Immich
Centigrade GmbH
Science Park 2
66123 Saarbrücken
[email protected]
Abstract
Probleme beim praktischen Einsatz von
User Interface Prototypen in den Bereichen Usability Engineering und Software
Entwicklung können sich unter anderem
in folgenden Feldern manifestieren: Detaillierungsgrad des Prototyps, Erwartungshaltung der Rezipienten von Prototypen, Wiederverwendung prototypischer Entwicklungen sowie Abbildung
von Interaktionen und Workflows.
Zur Eliminierung dieser Probleme bieten
sich verschiedene Ansätze an.
1.0
Einleitung
Prototypen werden bei der Entwicklung von interaktiven Systemen auf vielfältige Weise eingesetzt. So können sie
beispielweise dazu dienen, technische
Machbarkeiten zu prüfen oder im Rahmen eines Usability Tests Erkenntnisse
zur Optimierung eines Systems zu gewinnen.
Häufig werden im Entwicklungsprozess
Prototypen von verschiedenen Beteiligten eingesetzt, die wiederum jeweils
spezifische Ziele und Anforderungen
bezüglich des Prototyps haben.
Der vorliegende Beitrag befasst sich mit
User Interface Prototypen, also mit solchen Prototypen, deren Zielsetzung darin besteht, zu einer Beurteilung bestimmter Aspekte des User Interface
eines Systems zu gelangen und auf
dieser Grundlage Entscheidungen zu
treffen. Hierbei wird der praktische Einsatz aus den zwei exemplarischen Perspektiven Usability Engineering und
Software Entwicklung betrachtet, um
40
Neben Maßnahmen in den beiden
Einzelbereichen sollte im Rahmen der
expliziten Kommunikation zwischen
Usability Engineer und Entwickler zur
Identifizierung von Synergien die Möglichkeit der gemeinsamen Verwendung
von Prototypen ebenso geprüft werden
wie ein koordiniertes Erwartungsmanagement nach außen. Durch die Abkopplung der User Interface Entwicklung von anderen BackendEntwicklungsarbeiten kann die Effizienz eines Projektes erhöht werden.
Keywords
Problemfelder aufzuzeigen und der
Frage nach Berührungspunkten bei
der Verwendung von Prototypen in
den beiden Bereichen nachzugehen.
ve Anwender mit dem Prototyp typische
Arbeitsaufgaben durchführen, damit auf
der Grundlage der hierdurch gewonnenen Daten Wissen zur Optimierung des
Systems gewonnen werden kann.
2.0
Prototyping, Erwartungsmanagement,
kooperative GUI Entwicklung, agile Entwicklung
Anwendungskontexte
2.2
Exemplarisch können bezüglich
des Einsatzes von Prototypen zwei
Anwendungskontexte und Stakeholdergruppen unterschieden werden, die
sich in ihren Zielsetzungen und Anforderungen hinsichtlich des Einsatzes
von Prototypen unterscheiden.
2.1
Zielsetzung des Usability Engineering Prozesses ist es, Erkenntnisse zu
gewinnen, die zur Verbesserung der
Anwenderfreundlichkeit des interaktiven Systems beitragen und diese Erkenntnisse in entsprechende Maßnahmen und Handlungsempfehlungen
umzusetzen.
Prototypen kommen hier zum Beispiel
dann zum Einsatz, wenn repräsentati-
Software Entwicklung
In der Software Entwicklung geht es
darum, ein funktionsfähiges System zu
erstellen, das den technischen Anforderungen genügt.
Prototypen kommen hier beispielsweise
zum Einsatz, wenn die Tauglichkeit von
Implementierungen, zum Beispiel spezieller Widgets, geprüft wird oder die
grundsätzliche Machbarkeit von Ansätzen evaluiert werden soll.
3.0
Problemfelder in der Praxis
Im Folgenden wird auf typische
Problemfelder beim praktischen Einsatz
von Prototypen eingegangen. Es wird
erläutert, wie sich Probleme in den beiden Bereichen Usability Engineering und
Software Entwicklung manifestieren
können und welche Ansatzpunkte zur
Beseitigung es gibt.
3.1
Detaillierungsgrad von Prototypen
Das Konzept „Detaillierungsgrad“
eines Prototyps bezieht sich darauf, wie
sehr visuelle oder funktionale Aspekte in
der prototypischen Umsetzung ausdifferenziert werden (low fidelity vs. high
fidelity).
Im Usability Engineering besteht die
Gefahr, dass der Fokus eines Teilnehmers in einem Usability Test durch einen
ungeeigneten Detaillierungsgrad von der
eigentlichen Fragestellung abgelenkt
wird. Dies kann beispielsweise dann der
Fall sein, wenn ein prototypisches User
Interface visuell sehr differenziert gehalten ist und hierdurch sehr viele Kommentare zur visuellen Gestaltung provoziert werden, obwohl die Fragestellung
des Tests dem Interaktionsdesign galt.
Aber auch ein zu gering aufgelöster Prototyp kann problematisch sein, wenn er
für die Anwender zu abstrakt bleibt und
das entsprechende Feedback sich in der
Folge auf einem vergleichbar abstrakten
Niveau bewegt.
In der Software Entwicklung kann das
Risiko von zu detaillierten Prototypen
darin bestehen, dass sie einen hohen
Implementierungsaufwand mit sich bringen, der dem eigentlichen Einsatzzweck
nicht angemessen ist. Dies ist etwa
dann der Fall, wenn sich Entwickler dazu animiert sehen, einen (funktionstechnisch) detaillierten Prototypen weiterzuentwickeln, „um keine Arbeit zu vergeuden“, obwohl die Ausdetaillierung des
Prototyps ausschließlich deshalb erforderlich war, um fundiert zu dem Schluss
zu kommen, dass ein bestimmter Implementierungsansatz nicht trägt. Durch
die hohe Detaillierung des Prototyps und
eine eventuell unzureichende Kommunikation im Projektteam kann sich daher
die Wahrscheinlichkeit des berechtigten
Verwerfens eines Prototyps verringern.
Letztendlich werden jedoch Ressourcen vergeudet, da die Arbeiten, die
aufbauend auf dem detaillierten Prototyp durchgeführt wurden, nicht zielführend waren.
In der Praxis sollte der Detaillierungsgrad eines Prototyps der jeweiligen
Fragestellung angemessen sein. Dies
setzt voraus, dass diese vor der Erstellung des Prototyps definiert und den
relevanten Personen mitgeteilt wird,
was im praktischen Projektalltag
durchaus nicht immer gegeben ist. Ist
dies nicht der Fall, so besteht die Gefahr, dass ein Prototyp entsteht, dessen Ausgestaltung sich vor allem an
umsetzungstechnischen Aspekten
orientiert, nach dem Motto: „Je einfacher etwas prototypisch umgesetzt
werden kann, desto eher wird es im
Prototyp realisiert“.
Für den Usability Engineer ist es wichtig, ein Gespür dafür zu entwickeln,
dass Teilnehmer in einem Usability
Test unterschiedlich mit dem Detaillierungsgrad eines Prototyps umgehen.
So findet man in der Praxis Teilnehmer, die sich in Feedback zu Details
verlieren und denen es von sich aus
unmöglich ist, davon zu abstrahieren,
während andere Teilnehmer damit
kein Problem haben. Neben der möglichst optimalen Ausrichtung des Detaillierungsgrads auf die Fragestellung
ist es damit für den Usability Engineer
also auch wichtig, in der konkreten
Situation mögliche negative Tendenzen bei den Teilnehmern zu beobachten und angemessen darauf zu reagieren. Dies kann er zum Beispiel tun,
indem er den Fokus der Teilnehmer
durch Hinweise und Erläuterungen
wieder auf die eigentliche Fragestellung richtet. Im Vorfeld des Tests kann
auch die Erfahrung des Usability Engineers mit vergleichbaren Tests und
Teilnehmergruppen zu einem Urteil
über den geeigneten Detaillierungsgrad
des Prototyps beitragen.
Für Entwickler ist es wichtig, den Stellenwert eines Prototyps zu kennen. Mit
diesem Wissen können sie ein fundiertes Urteil darüber fällen, ob eine relativ
hohe Detaillierung daher rührt, dass der
Prototyp als Grundlage weiterer Implementierungsarbeiten genutzt werden soll
oder daher, dass sie erforderlich war,
um eine implementierungstechnische
Frage umfassend bewerten zu können.
Insbesondere in größeren Entwicklerteams sollten daher die entsprechenden
Informationen klar kommuniziert werden.
3.2
Erwartungsmanagement
Häufig wird der Prototyp einer nicht
unmittelbar am Projekt beteiligten Öffentlichkeit zugänglich gemacht. Dies
geschieht beispielsweise im Rahmen
von Vorstandsmeetings oder auch bei
Tests mit repräsentativen Anwendern im
Kontext eines Usability Tests. Immer
werden durch die Konfrontation mit einem Prototyp auch die Erwartungen des
Publikums an das System beziehungsweise an das Entwicklungsprojekt beeinflusst.
Für Teilnehmer an einem Usability Test
kann es schwierig sein, den Stellenwert
eines Prototyps richtig einzuschätzen.
Beispielsweise wird unter Umständen
durch visuelle Gestaltung und scheinbare Funktionalität des Prototyps der Eindruck erweckt, dass die Entwicklung
schon sehr weit fortgeschritten ist und
das Release kurz vor der Fertigstellung
steht. Dies kann insbesondere bei inhouse Entwicklungen den Druck auf die
Projektverantwortlichen erhöhen, da
unter Umständen die Akzeptanz für Revisionen und „Verzögerungen“ der Entwicklung eines „weit gediehenen“ Systems reduziert wird. Eine andere Seite
der selben Problematik zeigt sich, wenn
es den Rezipienten nicht möglich ist,
von auftretenden Bugs zu abstrahieren
41
und sie diese als schwerwiegende Mängel des Endsystems ansehen, obwohl
es sich lediglich um die zu erwartenden
Fehler einer frühen Implementierung
handelt.
Aus der Entwicklerperspektive ist Erwartungsmanagement speziell dann bedeutsam, wenn ein hauptsächlich vom
Usability Engineer verantworteter Prototyp interaktive Elemente oder Paradigmen vorstellt, deren technische Machbarkeit bislang noch nicht geprüft wurde,
diese aber durch ihre Verwendung in
Tests und Präsentationen implizit Teil
des Anforderungskatalogs werden. Dies
kann unter Umständen dazu führen,
dass eine vom Publikum erwartete Programmeigenschaft nicht nur spät, sondern im schlimmsten Fall überhaupt
nicht realisierbar ist, was sich negativ in
der abschließenden Bewertung des Systems niederschlägt.
Der Usability Engineer sollte aktives
Erwartungsmanagement betreiben, um
sicherzustellen, dass der Stellenwert
des Prototyps von jeweiligen Publikum
richtig erkannt und der Prototyp richtig
eingeordnet wird. Dies kann beispielsweise durch eine Erläuterung dahingehend geschehen, dass tiefgreifende
Veränderungen des Prototyps durchaus
möglich sind und er lediglich ein Artefakt
für einen bestimmten, umschriebenen
Projektzweck darstellt, wie zum Beispiel
Kommunikation und Sammlung von
Feedback im Rahmen eines Usability
Tests. Der häufig im Rahmen von Usability Tests gegebene Hinweis, dass während der Interaktion Fehler auftreten
können, die auf noch existierende
Schwachstellen der Technik hinweisen,
dient ebenfalls dem Erwartungsmanagement.
Um das Risiko zu minimieren, dass in
einem Prototyp vorgestellte Konzepte
nicht umsetzbar sind, empfiehlt es sich,
dass Usability Engineer und Entwickler
frühzeitig miteinander in Kontakt treten,
42
so dass potenzielle Probleme erörtert
werden können oder die Umsetzbarkeit gegebenenfalls in Form von technischen „Spikes“1 geprüft werden
kann. Der Entwickler (beziehungsweise der Projektmanager) sollte die Implementierung eines Spikes im Voraus
zeitlich begrenzen, damit die Studie
ausschließlich auf die wesentlichen
Risikoquellen fokussiert wird.
3.3
Wiederverwendung von Prototypen
Zuweilen wird die Wiederverwendung von Prototypen als Ideal gesehen, das im Softwareentwicklungsprozess verfolgt werden sollte. So werden
dann beispielsweise bei der Erstellung
eines Systems Prototypen von Usability Test zu Usability Test sukzessive
erweitert oder evolutionäre technische
Prototypen in der Entwicklung eingesetzt.
Im Rahmen des Usability Engineering
Prozesses kann die Gefahr bestehen,
die jeweils in Usability Tests behandelten Fragestellungen dem Primat der
Wiederverwendung von Prototypen
unterzuordnen und damit den Erkenntnishorizont von vornherein zu
beschränken. Dies ist etwa dann der
Fall, wenn nur wenig Ressourcen zur
Verfügung gestellt werden, um Umstrukturierungen eines Prototyps vorzunehmen, die eine revidierte Informationsarchitektur reflektieren. Dies kann
so weit gehen, dass zur Untersuchung
einer Fragestellung auch kein Papierprototyp eingesetzt wird, da dies
scheinbar einen „Rückschritt“ im Vergleich zu einem bereits vorhandenen
interaktiven HTML-Prototyp darstellt.
1
Der Begriff „Spike“ wird oft in agilen
Entwicklungskontexten verwendet und
beschreibt eine fokussierte Studie, in
der Entwickler technisch relevante Aspekte und Designideen in Form von
kleinen abgeschlossenen Programmteilen umzusetzen versuchen (Proof of
Concept).
Bei der Software Entwicklung besteht
das Risiko darin, dass durch das Ideal
der Wiederverwendung von Prototypen
und aufgrund enger Projektzeitpläne
Implementierungen „mitgeschleppt“
werden, die von ihrer Qualität her unzureichend sind oder die auf ein bestimmtes, zum Entwicklungszeitpunkt aktuelles, Framework abgestimmt waren, welches sich über die Projektdauer jedoch
verändert hat oder durch ein anderes
abgelöst wurde.
Der Usability Engineer sollte vor dem
Einsatz von Prototypen prüfen, ob der
zu erwartende Erkenntnisgewinn den
Aufwand für eine Überarbeitung oder
Ergänzung eines Prototyps rechtfertigt.
Je günstiger das Kosten-Nutzen Verhältnis ist, desto eher sollten die erforderlichen Ressourcen dafür zur Verfügung gestellt werden. Insbesondere
wenn Papierprototypen eingesetzt werden, können Änderungen oder „Neuentwicklungen“ leicht umgesetzt werden.
Allerdings kann diese Art von Prototyp
nicht für alle Fragestellungen Verwendung finden. Beispielsweise sind sie
ungeeignet zur Evaluation von Detailinteraktionen mit bestimmten Controls.
Im Rahmen der Software Entwicklung
muss für ein Projekt festgelegt werden,
ob die Wiederverwendung von Prototypen ein explizites Ziel darstellt. Ist dies
der Fall, so sollte die Codequalität durch
automatisierte Tests (zum Beispiel „Unit
Tests“2) und explizite „Refactoring“3
2
3
Unit Tests (auch „Modultests“ genannt)
dienen zur automatisierten Überprüfung
der Korrektheit von Modulen in einer
Software. Nach jeder Codeänderung
werden alle Unit Tests automatisch
durchlaufen und geben so Aufschluss
darüber, ob die Software immer noch in
einem stabilen Zustand ist.
Mit „Refactoring“ bezeichnet man Änderungen am Quellcode einer Software, die
nur dessen Lesbarkeit und Struktur verbessern, ohne jedoch sein Verhalten zu
ändern. Fest eingeplantes und durch
Tests gesichertes Refactoring, senkt die
„Hemmschwelle“ bei Entwicklern, Imple-
Phasen gesichert werden. Zumindest
auf der User Interface Schicht sollte
hierbei nicht der klassische „Test First“4
Ansatz verfolgt werden – das Erstellen
von Tests kurz vor dem Refactoring bietet eine hinreichende Absicherung und
erlaubt ein viel agileres Reagieren auf
veränderte Anforderungen an den Prototyp.
Ist die Wiederverwendung von Prototypen ein Ziel, so sollte zunächst festgelegt werden, ob Wiederverwendung über
verschiedene Einsatzphasen von Prototypen im Entwicklungszyklus hinweg
oder Wiederverwendung des Prototyps
hinsichtlich des letztendlich implementierten Systems oder beides gemeint ist.
Bezüglich des ersten Aspekts sollte der
Einflussfaktor der Kopplung des User
Interface Prototyps mit konkreten Daten
des Backend betrachtet werden. Durch
eine feste „Verdrahtung“ kann die Ursache für bestimmte Effekte im User Interface unter Umständen nur unzureichend
isoliert werden, oder aber bestimmte
Effekte treten aufgrund einer konkreten
Daten-Konstellation gar nicht erst auf,
wodurch Probleme des User Interface
lange unentdeckt bleiben. Wenn möglich, so empfiehlt es sich, die Entwicklung des User Interface möglichst abgekoppelt von der Backend Entwicklung zu
betreiben, um die genannten Effekte zu
verhindern.
Für den zweiten Aspekt der Wiederverwertbarkeit ist es bedeutsam, dass die
technische Plattform für den Prototyp
weitestgehend mit derjenigen des Endproduktes identisch ist, da ansonsten ein
4
mentierungen in mehr oder weniger großen Teilen zu verwerfen und verhindert
somit idealerweise das „Mitschleppen“
von minderwertigen oder nicht nachhaltig
getesteten Entwicklungsarbeiten.
„Test First“ bezeichnet einen Ansatz, bei
dem zunächst Unit Tests geschrieben
werden und dann erst mit der Entwicklung des eigentlichen Systems begonnen
wird.
Transfer der prototypischen Entwicklungen für das Endprodukt nicht nahtlos durchgeführt werden kann. Ein
derartiger Ansatz, bei dem das Produkt quasi nahtlos aus Prototypen
entsteht, beziehungsweise bei dem
der Prototyp zu jeder Phase des Prozesses das Produkt ist, wird im Allgemeinen in agilen Ansätzen verfolgt.
3.4
Abbildung von Interaktionen
und Workflows
Das User Interface eines Systems
dient in der Regel dazu, dem Anwender die Erledigung von Arbeitsaufgaben im Rahmen von Interaktionen und
Workflows zu ermöglichen. Workflows
stellen dabei umfassendere Sammlungen von Arbeitsschritten im Dienste
einer bestimmten Zielsetzung dar.
Interaktionen sind kleinere Arbeitseinheiten, bei denen der Anwender mit
dem System interagiert und die wiederum Bestandteil mehrerer unterschiedlicher Workflows sein können.
So kann etwa die Interaktion „Eingabe
einer Adresse in ein Formular“ in einem System Teil der Workflows „Anlegen eines neuen Kunden“ sowie „Ergänzen eines Kundendatensatzes“
sein. In Prototypen sind die möglichen
Interaktionen und Workflows mehr
oder weniger umfänglich abgebildet.
Im Usability Engineering muss vorab
geklärt werden, inwieweit Interaktionen
und Workflows im Prototyp fokussiert
werden sollen, da dies unmittelbar
Technik und Gestaltung des Prototyps
beeinflusst. Steht beispielsweise die
Evaluation von Workflows im Vordergrund, so können hierfür Papierprototypen in Frage kommen, mit denen
dem Anwender bestimmte Screensequenzen präsentiert werden können.
Für die Evaluation von Detailinteraktionen sind Papierprototypen dagegen
nicht geeignet, da sie keine ausreichend hohe Interaktivität zur Verfügung stellen können. Werden Papier-
prototypen unreflektiert eingesetzt, so
kann die Betrachtungsebene der Detailinteraktionen zu kurz kommen, da diese
für Testteilnehmer nur unzureichend
greifbar wird. Für derartige Evaluationen
können beispielsweise HTML- oder
technisch noch aufwändigere Prototypen
zum Einsatz kommen.
Für die Software Entwicklung kann die
Unterscheidung zwischen Workflows
und Interaktionen beispielsweise deshalb bedeutsam sein, weil für die Evaluation von Workflows reale Datenumgebungen zu simulieren sind und diese
erst nach Bereitstellung entsprechender
Informationen (realistische Daten) durch
Domänenexperten umgesetzt werden
können. Für Interaktionen anhand bestimmter Controls müssen realistische
Datenstrukturen dagegen nicht unbedingt eine Rolle spielen. Je nach Fokus
der Evaluation muss eventuell also berücksichtigt werden, dass den Entwicklern tiefergehende Information zur Verfügung gestellt werden muss und entsprechende Ressourcen dafür eingeplant werden sollten.
4.0
Zusammenspiel von Usability
Engineering und Software Entwicklung
Die vorangegangenen Erläuterungen zeigen, dass sich die Probleme, die
beim praktischen Einsatz von Prototypen in Usability Engineering und Software Entwicklung auftreten, in vergleichbaren Problembereichen abspielen, wobei die konkrete Erscheinungsform eines Problems abhängig ist davon, ob das Ziel des Prototyps eher in
einer Usability Evaluation oder einer
technischen Evaluation besteht.
Es stellt sich die Frage, wie Synergien
von Usability Engineering und Software
Entwicklung geschaffen werden können,
so dass der Einsatz von Prototypen in
beiden Bereichen effizienter erfolgt.
43
Die Grundlage für derartige Synergieeffekte ist die Kommunikation zwischen
Usability Engineer und Software Entwickler. Diese ist in der Praxis durchaus
nicht selbstverständlich, da aufgrund
von Projektstrukturen nicht immer ein
direkter Austausch gegeben ist und die
Kommunikation daher oft indirekt
und/oder implizit erfolgt, beispielsweise
durch die Begutachtung von Prototypen
des jeweils anderen Teams. In diesem
Kontext sollte auf eine direkte und explizite Kommunikation hingearbeitet werden, beispielsweise im Rahmen regelmäßiger Teammeetings, bei denen relevante Themen besprochen und Entscheidungen getroffen werden. Auf diese Weise können negative Effekte impliziter Kommunikation vermieden werden,
die zum Beispiel auftreten können, wenn
der Software Entwickler „seinen“ Prototyp erheblich ausdifferenziert, um „vorzuarbeiten“, weil er einen visuell sehr
detaillierten Prototyp fälschlicherweise
als User Interface Spezifikation erachtet.
Umgekehrt kann auch der Einblick des
Usability Engineers in die Arbeit des
Software Entwicklers nützlich sein, etwa
wenn der Usability Engineer hierdurch
erkennt, dass er einen Prototyp des
Software Entwicklers ganz oder in Teilen
für seine Zwecke einsetzen kann. Unter
Umständen kann sogar ein Prototyp, der
vom Software Entwickler bereits verworfen wurde (da dieser beispielsweise
überholte Architekturen nutzt) für den
Usability Engineer hilfreich sein, da er
Funktionalitäten enthält, die im Fokus
eines Usability Tests stehen – unabhängig davon, wie diese Funktionalitäten
technologisch umgesetzt sind.
Im Rahmen der Kommunikation kann
auch geklärt werden, inwieweit gemeinsame Prototypen für beide Bereiche
sinnvoll sind. In agilen Umfeldern wird
44
oft eine durch Tests (siehe oben) abgesicherte Entwicklung praktiziert, so
dass durch Refactoring Maßnahmen
aus dem Prototyp ohne Weiteres das
eigentliche Produkt entstehen kann.
Hier muss daher keine zusätzliche Zeit
für die Erstellung von „Wegwerf“Prototypen eingeplant werden. Dies
kann aber auch bedeuten, dass der
Usability Engineer aufgrund der Zeitpläne keine Ressourcen hat, dedizierte
Prototypen für Usability Testing zu
erstellen. Hier muss er jeweils im Einzelfall prüfen, ob die akuten Fragestellungen mit den verfügbaren Prototypen
verfolgt werden können, oder ob zumindest ein basales Prototyping von
seiner Seite (beispielsweise in Form
von Papierprototypen) angebracht und
möglich ist. Außerdem sollte er im
Rahmen der oben erwähnten Teammeetings ein Bewusstsein für Usability
Engineering im Gesamtteam schaffen,
um auf diese Weise indirekt Einfluss
auf die Erstellung von Prototypen zu
nehmen und so darauf hinzuarbeiten,
dass Prototypen erstellt werden, die
auch zur Bewertung von Usability Fragestellungen dienen können.
Werden unterschiedliche Prototypen
von Usability Engineer und Software
Entwickler eingesetzt und gibt es
Überschneidungen in den Rezipientengruppen (zum Beispiel bei Vorstandspräsentationen) kann ein gemeinsames Erwartungsmanagement
der beiden Teams nach außen sinnvoll
sein. Auf diese Weise können die Rezipienten über den Stellenwert von
Divergenzen zwischen den Prototypen
informiert werden, damit beispielsweise der Software Entwickler nicht unter
Druck gerät, wenn der Prototyp des
Usability Engineers aufgrund der visuellen Ausgestaltung den Eindruck eines fast fertigen Systems erweckt,
obwohl die technische Umsetzung bei
weitem noch nicht abgeschlossen ist.
Auch bei separaten Prototypen kann der
Informationsaustausch zwischen Usability Engineer und Software Entwickler die
Effizienz des Gesamtprojekts verbessern. Dies ist beispielweise dann der
Fall, wenn vom Usability Engineer Informationen zu Workflows und Datenstrukturen aus User Task Analysen oder
Interviews mit Domänenexperten geliefert werden können, die der Software
Entwickler für die Simulationen realer
Daten-Umgebungen und DatenManipulationen benötigt. In einem solchen Fall liegt die Information bereits „im
Team“ vor und der Entwickler muss sie
nicht extra von „außerhalb“ anfordern.
Schließlich können Synergien auch dadurch gefördert werden, dass die Entwicklung des User Interface explizit von
anderen Entwicklungsarbeiten abgekoppelt wird und spezialisierte User Interface Entwickler zum Einsatz kommen.
Auf diese Weise rückt die Tätigkeit dieser Entwickler näher an diejenige des
Usability Engineers und der Entwickler
ist weniger durch Programmierarbeiten
belastet, die nicht unmittelbar mit dem
User Interface in Verbindung stehen.
Durch die hierdurch entstehende größere inhaltliche Schnittmenge zwischen
Usability Engineer und Software Entwickler sowie durch die Expertise und
die Werkzeuge (beziehungsweise Technologien) des spezialisierten User Interface Entwicklers kann die Erstellung von
Prototypen gefördert werden, die für
beide Parteien sinnvoll einsetzbar sind.
Zumindest jedoch wird der Aufwand für
Prototyping Aktivitäten, die nur für einen
der beiden Bereiche nützlich sind, im
Vergleich zur „herkömmlichen“ Zusammenarbeit von Usability Engineer und
Software Entwickler reduziert.
Methoden, Notationen und Werkzeuge zur Übersetzung von
Anforderungen in User Interface Spezifikationen
Thomas Memmel
Mensch-Computer Interaktion
Universität Konstanz
Universitätsstrasse 10, Box 73
78457 Konstanz
[email protected]
http://hci.uni-konstanz.de
Thomas Geis
ProContext GmbH
Deutzer Freiheit 77-79
50679 Köln
[email protected]
www.procontext.com
Prof. Dr. Harald Reiterer
78457 Konstanz
[email protected]
Abstract
In diesem Workshop wollen wir unterschiedliche Methoden und Werkzeuge
vorstellen und diskutieren, mit denen
kreative Prozesse bei der Übersetzung
von Anforderungen in benutzerfreundliche und innovative Benutzungsschnittstellen angetrieben und unterstützt werden. Dabei betrachten wir auf Text ba-
1.0
Einleitung
Der aktuelle „Chaos Report“ der
Standish Group aus dem Jahr 2007
zeigt auf, dass die Softwareentwicklung
auch weiterhin vor großen Herausforderungen steht. Nur 35% der IT Projekte
werden erfolgreich abgeschlossen in
Hinblick auf Projektlaufzeit, Budget und
Umsetzung definierter Anforderungen.
46% der Projekte haben dagegen die
Zeit- und Budgetvorgaben signifikant
überschritten und 19% der Projekte
scheitern im Durchschnitt gänzlich ohne
Projektergebnis. Als primäre Ursache
sind dabei besonders die frühen Phasen
des Entwicklungsprozesses zu sehen, in
denen die „Richtung“ für das zu entwickelnde Produkt festgelegt wird. Wer zu
spät testet, muss mit in späteren Projektphasen mit teuren Problemen und
Rückschlägen rechnen. Das US-amerikanische National Institute of Standards
and Technology hat in einer 20021 veröffentlichten Studie erhoben, dass etwa
70% der Mängel im Entwicklungsprozess in der Phase der Anforderungserhebung entstehen. Entdeckt werden
1
http://www.nist.gov/public_affairs/
releases/n2-10.htm
sierende Notationsformen und Werkzeugketten ebenso wie spezielle
Werkzeuge für Interaktionsdesigner.
Als neue und zukunftsweisende Unterstützung von User Interface Entwicklungsprozessen stellen wir unsere Idee
von interaktiven Spezifikationen vor.
Keywords
Anforderungsanalyse, Spezifikation,
Usability Engineering, User Interface
Design
diese meist erst während der Abnahmetests. Um einen Mangel während
einer späteren Projektphase noch zu
beheben muss das 50- bis 100-fache
der ursprünglichen Kosten kalkuliert
werden.
derungskonform umsetzen, wird von den
meisten bekannten Usability Engineering (UE) Vorgehensmodellen offen gelassen. Doch gerade wenn der Auftraggeber eine hohe UI Qualität sicherstellen
will, muss der Entwicklungsprozess eine
explizite Art der UI Spezifikation vorsehen (Memmel et al., 2007a).
In diesem Workshop beleuchten wir
diese Problematik in Hinblick auf die
Entwicklung der Benutzungsschnittstelle (im Folgenden als User Interface, kurz „UI“ bezeichnet). Die UI
Entwicklung nimmt in den meisten IT
Organisationen inzwischen einen hohen Stellenwert ein und ist faktisch Teil
des gesamten Entwicklungsprozesses.
Spätestens bei der UI Spezifikation
und UI Visualisierung können noch
übersehene oder missverstandene
Anforderungen systematisch erkannt
werden, wenn für die UI Spezifikation
eine entsprechende Systematik zugrunde gelegt wird.
Die Spezifikation des UI kann sowohl
als Teil der Anforderungsspezifikation
als auch als Teil der Softwarespezifikation verstanden werden. Wie jedoch
gerade dieser sensible Teil einer Softwareanwendung spezifiziert werden
muss, damit Entwickler das UI anfor-
Wir wollen daher Methoden, Notationen
und Werkzeuge diskutieren, mit deren
Hilfe kreative Prozesse entlang des UI
Entwicklungsprozesses bis hin zur UI
Spezifikation unterstützt werden können.
2.0
Struktur von UI Spezifikationsprozessen
Industrielle UI Entwicklungsprojekte
starten in der Regel mit einer Anforderungsspezifikation. Vor und nach der
Übersetzung in ein Fachkonzept werden
die Anforderungen geprüft und gegebenenfalls modifiziert. Erst nach einer Abnahme der Anforderungen und des Konzepts wird eine Systemspezifikation erzeugt. Diese ist meist die Grundlage für
die Implementierung erster UI Prototypen und des finalen UI.
Anforderungen und Anforderungen sind
jedoch bereits „zwei paar Schuhe“. So
45
gibt es immer die Anforderungen aus
Sicht des Kunden („Stakeholder requirements“) und Anforderungen an das
System zur Umsetzung der Anforderungen des Kunden („System requirements“)2.
Eine intensive Anforderungsphase wird
dann problematisch, wenn sie nicht ausreichend Spielraum für Prototyping und
Evaluierung vorsieht, um so natürliche
Unsicherheiten bei den Anforderungen
durch das Ausprobieren passender
Lösungen ausräumen zu können. Grade
in Entwicklungsprojekten, bei denen ein
IT Dienstleister ab der Anforderungsspezifikation das Zepter übernimmt, sind
interaktive Prototypen in der Regel vorher nicht verfügbar. In einer rein durch
Spezifikation getriebenen Entwicklungskultur kann viel Zeit vergehen, bis Fachexperten und Endbenutzer zum ersten
Mal das Ergebnis ihrer textuell formulierten Anforderungen ausprobieren und
beurteilen können. Je größer dann die
Diskrepanz zwischen Qualität und Funktionalität von Entwürfen einerseits und
den Erwartungen der „Stakeholder“ andererseits ist, umso wahrscheinlicher ist
es, dass die Nutzung für alle Stakeholder unbefriedigend wird.
Probleme treten bereits dann auf, wenn
beteiligte Personen ihre Anforderungen
nicht ausreichend gut zum Ausdruck
bringen können. Viele Arbeitsprozesse
laufen unbewusst ab und deren Dokumentation selbst fehlt häufig in der Anforderungserfassung. Später versuchen
Experten, die lückenhaften und beliebig
sortierten Anforderungen mit einem Management-Werkzeug in eine Struktur zu
bringen. Das Kommunikations- und Verständnisproblem zwischen IT und Fachabteilung verstärkt sich, wenn die Projektbeteiligten sich in unterschiedlichen
Sprachstilen und Abstraktionsniveaus
2
ISO IEC 15288 „Systems and software
engineering - System life cycle processes“
46
ausdrücken. Anforderungsspezifikationen werden dann nicht mehr verstanden und Konflikte nicht transparent.
Damit dies gelingt und letztlich auch
eine vertragsbindende Anforderungsspezifikation entsteht, sind mehrere
Schritte notwendig. In Abschnitt 3 betrachten wir dazu zunächst Notationen
zur Erfassung und Dokumentation von
Erfordernissen von Benutzern und
deren Übertragung in Nutzungsanforderungen. Da es für die erfolgreiche UI
Entwicklung entscheidend ist, dass
Umsetzungsmöglichkeiten für erhobene Anforderungen möglichst schnell
visualisiert und getestet werden können, stellen wir in Abschnitt 4 spezielle
und einfach zu nutzende Werkzeuge
zum UI Prototyping vor. Mit deren Hilfe
soll der IT Entwicklungsorganisation
der Wandel vom rein Spezifikationsgetriebenen Prototyping zur Prototyping-getriebenen Spezifikation gelingen. Dazu diskutieren wir die Möglichkeiten zu einer Verschmelzung von
Anforderungsmodellen und UI Prototypen zu sogenannten interaktiven UI
Spezifikationen. In diesen sehen wir
die Möglichkeit, textbasierte Spezifikationsdokumente durch erlebbare Artefakte zu ersetzen. Dazu stellen wir
schließlich kurz ein experimentell entwickeltes Werkzeug vor.
3.0
Anforderungsgetriebenes Spezifizieren von UIs
Um Anforderungen an ein UI festlegen zu können, müssen diese in
Form von Nutzungsanforderungen
expliziert werden. Nutzungsanforderungen sind nicht gleichzusetzen mit
fachlichen Anforderungen, die primär
Regeln darstellen, die ein fachlich korrekt erzieltes Arbeitsergebnis mit Hilfe
des Software-Erzeugnisses / interaktiven Systems vorsehen. Nutzungsanforderungen sind auch keine „Nutzeranforderungen“. Nutzungsanforderun-
gen sind Anforderungen an die effiziente
Nutzung eines Systems, die primär aus
dem Nutzungskontext in dem das interaktive System eingesetzt wird hergeleitet werden müssen. Der Leitfaden Usability3 der Deutschen Akkreditierungsstelle Technik (DATech) liefert hierzu ein
Schema zur Darlegung der Kontextdaten selbst („Kontextszenario“), das auf
der Basis von Kontextinterviews mit echten Repräsentanten der Ziel-Nutzergruppe entsteht. Die Auswertung solcher
Kontextszenarien in Hinblick auf implizite Erfordernisse und hieraus ableitbare
Nutzungsanforderungen geschieht mit
dem Schema des „ausgewerteten Kontextszenarios“). Das Schema wurde
zunächst für die Herleitung von Prüfkriterien auf der Basis von DIN EN ISO
9241-11 und DIN EN ISO 9241-110 im
Rahmen von Gebrauchstauglichkeitsprüfungen entwickelt, ist jedoch gleichermaßen für die Herleitung von Nutzungsanforderungen in frühen Projektphasen geeignet. Für die Nutzung des
Schemas ist ein normales Textverarbeitungssystem völlig ausreichend. Die
eigentliche Herausforderung liegt im
methodischen Erkennen und Darlegen
von impliziten Erfordernissen im Nutzungskontext. Dies erfordert einen
geschulten Anforderungsanalytiker, der
die Syntaxregeln für Erfordernisse und
für Nutzungsanforderungen beherrscht,
und die Empfehlungen der DIN EN ISO
9241-110 „Grundsätze der Dialoggestaltung“ anwenden kann.
Auf der Basis einer ausreichenden Anzahl ausgewerteter Kontextszenarien
wird im Anschluss mit Hilfe eines zweiten Schemas, des „Nutzungsszenarios“
die Ausführung der zu unterstützenden
Aufgaben im Nutzungskontext aus Sicht
des Nutzers spezifiziert.
Diese Form der Spezifikation kann man
durchaus als „Interaktionsdesign“ auf
3
http://www.datech.de/share/files/
Leitfaden-Usability.pdf
der Basis von Nutzungsanforderungen
verstehen, die die Brücke zwischen
Anforderungsspezifikation und Prototyping darstellt. Auch hierfür reicht ein
Textverarbeitungssystem.
Wesentlich für den erfolgreichen Einsatz
des Schemas für das Nutzungsszenario
ist wiederum die Professionalität des
menschlichen „Editors“, um die Interaktion zwischen Nutzer und System in
Hinblick auf zu erfüllende Nutzungsanforderungen zu spezifizieren. Nutzungsanforderungen und Nutzungsszenarien,
die methodisch sauber hergeleitet und
dokumentiert sind, bieten eine ideale
Grundlage für das Prototyping, da wichtige Fragen bereits vor dem Prototyping
adressiert wurden und so „vorhersehbare Überraschungen“ beim Prototyping
und Entwicklungsbegleitenden Usability
Testing bereits im Vorfeld ausgeräumt
werden können.
4.0
Protoyping-getriebenes Spezifizieren von UI’s
Nachdem Nutzungsszenarien und
Nutzungsanforderungen erzeugt worden
sind, können erste Prototypen erzeugt
werden. Prototyping ist eine essentielle
Methode im UE Prozess, um Anforderungen zu simulieren und ein UI Design
bereits sehr früh im Entwicklungsprozess mit Nutzern evaluieren zu können.
In Projektsituationen mit einer hohen
Beteiligung von Stakeholdern, die keine
IT Experten sind, muss das Erzeugen
von Prototypen einfach möglich sein.
Dies ist eine Voraussetzung für einen
kollaborativen Prozess. Umgekehrt
erzeugen innovative Prototypen, die
eine magnetisierende Wirkung haben
und Enthusiasmus verbreiten können,
auch innovative Teams (Schrage, 1999).
Paper Prototyping reicht jedoch in vielen
Situationen dazu nicht aus, da Stakeholder sehr häufig alle Ergebnisse (auch
in frühen Phasen) bereits in einem „erlebbaren“ Format kennen lernen möch-
ten. Es besteht daher eine enorme
Nachfrage nach Prototyping-Werkzeugen, die detaillierte Simulationen erzeugen können, aber dennoch für alle
Stakeholder zu benutzen sind (Memmel et al., 2007a/b).
Wir stellen das sehr neue und im europäischen Raum noch weniger bekannte Werkzeug iRise vor. iRise Studio knüpft an die Erfahrungen der
meisten Stakeholder mit Office-Anwendungen wie PowerPoint an. Dem
Nutzer stehen alle gängigen UI Elemente zur Verfügung. Diese können
leicht auf der „UI Zeichenfläche“ zusammengestellt werden. Auch ActiveX
Komponenten wie z.B. Flash Filme,
können zum Bau visuell ansprechender Prototypen integriert werden. Mit
Hilfe von Templates und MasterKomponenten sind generische Änderungen leicht möglich. Durch die Verbindung mehrerer kreierter UIs entsteht ein Storyboard. Per Knopfdruck
wird hieraus eine UI Simulation erzeugt, die in einem Feedback-Verfahren mit Annotationen versehen
werden kann. Das iRise Datenformat
erlaubt das gepackte Weiterleiten der
erzeugten Prototypen an Dritte und
bietet sich damit auch als nützliche
Beigabe zu jeder textuell ausgearbeiteten Spezifikation an.
Zusätzlich integriert iRise auch selbst
die Möglichkeit, Texte zu hinterlegen.
Dadurch können einzelne UI Elemente
mit den ihnen zugrunde liegenden Use
Case Narrationen oder auch Anforderungen für Designentscheidungen verbunden werden. Im Unterschied zu
Styleguides stellen iRise Simulationen
daher eine erlebbare Dokumentation
der UI Design Rationale dar. UIStandards sowie der Look einer Anwendung werden nicht nur textuell
beschrieben, sondern auch als erlebbares Artefakt bereitgestellt. Damit
kann auch das Feel einer Anwendung
besser weitervermittelt werden.
Die mit Prototypen erzielten Ergebnisse
werden oft in Styleguides dokumentiert
und treiben den weiteren UI Entwicklungsprozess an (Mayhew 1999). Styleguides stellen keine UI Spezifikationen
dar, da sie in der Regel keine Kontextspezifischen Abbildungen oder Interaktionsbeschreibungen enthalten. Vor allem
wenn die Implementierung eines UI
durch eine dritte Partei vorgenommen
wird, muss zusätzlich zum Styleguide
eine Spezifikation angefertigt werden.
Mayhew (1999) erläutert, dass eine solche UI Spezifikation in erster Linie aus
Abbildungen besteht und nur an solchen
Stellen Text enthält, an denen eine Abbildung alleine nicht ausreicht. Aus unserer Erfahrung heraus trifft dies vor
allem dann zu, wenn das interaktive
Verhalten eines UI im Detail beschreiben werden soll. Wir stellen im Workshop daher unsere Idee interaktiver UI
Spezifikationen vor.
5.0
Interaktive UI Spezifikationen
Eine interaktive UI Spezifikation
verbindet die Grundidee von Styleguides
mit dem Zweck einer Spezifikation. Sie
speichert wichtige Designvisionen sowie
-entscheidungen und dokumentiert
Standards und Testergebnisse. Die textuelle Information wird durch UI Prototypen unterschiedlichen Detailgrads (low-,
medium-, high-fidelity) angereichert.
Zusätzlich enthält diese interaktive UI
Spezifikation auch die am Beginn des
Prozesses hergeleiteten Nutzungsanforderungen und -szenarien. Darauf aufbauend werden unterschiedliche (agile)
Anforderungsmodelle als visuelle Notationen integriert, darunter z.B. Use Cases oder Aktivitätsdiagramme (Memmel
et al., 2007c). Die interaktive UI Spezifikation, die in einem XML-basierten Format gespeichert und mit Dritten ausgetauscht werden kann, erlaubt somit den
einfachen Wechsel von abstrakten Beschreibungen (Text), graphischen Nota-
47
tionen (Modelle) und UI Prototypen (Design).
Mit einem experimentellen Werkzeug
namens INSPECTOR (Memmel et al.,
2008a/b/c/d) bauen wir auf vielversprechenden Werkzeugen wie iRise auf und
ergänzen diese um eine Unterstützung
von Anforderungsermittlung und UI Modellierung. Durch die Integration von
Text, Modellen und Design können alle
für eine UI Spezifikation notwendigen
Informationen mit einem innovativen
Zoom-Konzept zusammengeführt werden. Dies sorgt für eine leichte Nachvollziehbarkeit und starke Transparenz
sowohl hinsichtlich der Topologie des
Spezifikationsraums, als auch hinsichtlich der Entwicklungsaufgabe selbst.
6.0
Zusammenfassung
In unserem Workshop zeigen und
diskutieren wir ausgewählte Papierbasierte und interaktive UI Spezifikationstechniken. Diese unterstützen den
Usability Professional bei der Identifikation von Erfordernissen und Anforderungen. Darüber hinaus helfen sie bei der
Übersetzung von Anforderungen in graphische Notationen und UI Prototypen.
Mit interaktiven UI Spezifikationen stellen wir eine Herangehensweise vor, die
in Verbindung mit textuell ausgearbeiteten Anforderungs- und Interaktionsspezifikationen eine frühzeitige Veranschaulichung und Validierung von Lösungskonzepten fördern und so das Risiko minimieren, das wichtige textuell dargelegte
Sachverhalte mangels Veranschaulichung schlichtweg übersehen werden.
7.0
DIN EN ISO 9241-11: Anforderungen an die
Gebrauchstauglichkeit; Leitsätze, Beuth Verlag, Berlin 1998.
DIN EN ISO 9241-110: Grundsätze der Dialoggestaltung, Beuth Verlag, Berlin 2006.
48
ISO IEC 15288: Systems and software
engineering - System life cycle processes,
Beuth Verlag, Berlin 2008.
Workshop on the Design, Verification and
Specification of Interactive Systems (DSV-IS
2008), S. 43-57. Springer: Kingston, Canada.
Deutsche Akkreditierungsstelle Technik in
der TGA GmbH (2007): Leitfaden Usability.
http://www.datech.de/share/files/LeitfadenUsability.pdf [01.08.2008].
Memmel, T.; Geyer, F.; Rinn, J.; Reiterer, H.
(2008b): Tool-Support for Interdisciplinary
and Collaborative User Interface Specification. In Proc. of the IADIS International Conference on Interfaces and Human Computer
Interaction (IHCI 2008), Amsterdam, Niederlande, S. 51-60
Deutsche Informatik-Akademie 2003 2008, Seminar „Nutzungsanforderungen an
Anwendungssoftware identifizieren und
spezifizieren”, http://www.diabonn.de/seminare/nutzungsanforderungen.
html [01.08.2008].
Deutsche Informatik-Akademie 2003 2008, Seminar „User Interfaces für Anwendungssoftware - Entwurf und Prototyping”,
http://www.diabonn.de/seminare/user_interf
ace.html [01.08.2008]..
Dzida, W.; Freitag, R. (1998): Making use
of scenarios for validating analysis and
design, in IEEE Transactions on SoftwareEngineering, 0098-5589, 24(1998)12, S.
1182–1196.
Dzida, W.; Hofmann, B.; Freitag, R.; Redtenbacher, W.; Baggen, R.; Zurheiden, C.;
Geis, T.; Beimel, J.; Hartwig, R.; HampeNeteler, W.; Peters, H. (2000): Gebrauchstauglichkeit von Software. ErgoNorm: Ein
Verfahren zur Konformitätsprüfung von
Software auf der Grundlage von DIN EN
ISO 9241 Teile 10 und 11. Bremerhaven:
Wirtschaftsverlag NW.
Dzida, W.; Freitag, R. (2001): Usability
Testing – The DATech Standard, in M.
Wieczorek, D. Meyerhoff (Hrsg.): Software
Quality – State of the Art in Management,
Testing And Tools. Berlin: Springer, 3-54041441-X, S. 160–177.
Geis, T.; Dzida, W.; Redtenbacher, W.
(2004): Specifying usability requirements
and test criteria for interactive systems.
Consequences for new releases of software-related standards within the ISO 9241
series. Bremerhaven: Wirtschaftsverl. NW.
Mayhew, D. J. (1999): The usability engineering lifecycle - A Practicioners Handbook for User Interface Design, San Francisco: Morgan Kaufmann.
Memmel, T.; Vanderdonckt, J.; Reiterer, H.
(2008a): Multi-fidelity User Interface Specifications. In Proc. of the 15th International
Memmel, T.; Geyer, F.; Rinn, J.; Reiterer, H.
(2008c): A Zoom-Based Specification Tool for
Corporate User Interface Development. In
Proc. of the IADIS International Conference
on Interfaces and Human Computer Interaction (IHCI 2008), Amsterdam, Niederlande, S.
368-370
Memmel, T.; Reiterer, H. (2008d): Inspector:
Interactive UI Specification Tool. In Proc. of
the 7th International Conference On Computer Aided Design of User Interfaces (CADUI) 2008, Albacete, Spanien, S. 161 - 174
Memmel, T.; Reiterer, H.; Ziegler, H.; Oed, R.
(2007a): Visuelle Spezifikation zur Stärkung
der Auftraggeberkompetenz bei der Gestaltung interaktiver Systeme. In Proceedings of
5th Workshop of the German Chapter of the
Usability Professionals Association e.V., in:
Kerstin Roese, Henning Brau, Frauenhofer
IRB Verlag, Stuttgart, S. 99-104.
Memmel, T.; Heilig, M.; Schwarz, T.; Reiterer,
H. (2007b): Visuelle Spezifikation interaktiver
Softwaresysteme. In Proceedings of the 7th
Mensch & Computer conference (MCI 2007,
Weimar, Germany), in: Tom Gross: Mensch &
Computer 2007, Oldenbourg Verlag, S. 307310.
Memmel, T.; Gundelsweiler, F.; Reiterer, H.
(2007c): Agile Human-Centered Software
Engineering. In Proc. of 21st BCS HCI Group
conference (HCI 2007, UK), in: Linden J. Ball,
M. Angela Sasse, Corina Sas, Thomas C.
Ormerod, Alan Dix, Peter Bagnall and Tom
Mc Ewan: "HCI...but as we know it", British
Computer Society, S. 167-175.
Schrage, M. (1999): Serious Play - How the
World's Best Companies Simulate to Innovate
Harvard Business School Press.
The Standish Group International (2007):
CHAOS Report 2007: The Laws of CHAOS.
The Standish Group International Inc, Boston.
Formulargestaltung für Dummies: Die häufigsten Fehler
erkennen, beheben und zukünftig vermeiden
Iris Niedermann
soultank AG
Alpenstrasse 11
CH-6304 Zug
[email protected]
www.soultank.ch
Michael Hatscher
Google Switzerland GmbH
Brandschenkestr. 110
CH-8002 Zürich
[email protected]
www.google.ch
Abstract
Formulare sind im Web das Bindeglied
zwischen Nutzer und Anbieter, sei es im
E-Commerce-Bereich, bei Social Software oder anderen Webapplikationen.
Wenn der Nutzer die Formulare unvollständig ausfüllt oder frustriert abbricht,
weil nicht klar wurde, welche Informationen erwartet werden, so bleiben die
1.0
Einleitung
Nicht realisierter Umsatz aufgrund
hoher Abbruchquoten und erhöhte Kosten durch unvollständige oder fehlerhafte Datensätze, die durch notwendige
Nachkontrollen personelle Ressourcen
binden, sind Gründe dafür, sich mit der
Gestaltung von internetbasierten Formularen auseinander zu setzen.
Wenn ein Nutzer eine Testversion einer
Software herunterladen möchte, muss er
sich oft zuerst durch ein langes Formular
quälen. Obwohl dies für den Nutzer eine
Hürde darstellt, ist das Einloggen für die
Unternehmung attraktiv: Man kennt den
Nutzer, man kann zählen, wie oft er die
Seite besucht und was genau er auf der
Seite tut. So können auch Informationen
wie Billing-Daten und vorher bestellte
Artikel des Nutzers eingesehen werden.
Zudem ermöglicht es dem Unternehmen, die eingeloggten Nutzer mit passenden Informationen zu versorgen.
Obwohl die oben genannten Gründe
wichtig für den Anbieter sind, scheint die
Bedeutung der Formulargestaltung im
B2C-Umfeld oft unterschätzt zu werden.
Gerade im E-Commerce-Bereich geschieht die Kontaktaufnahme des Kunden mit dem Anbieter oft über ein Formular. Dies unterstreicht die Bedeutung
Interessenten beider Seiten auf der
Strecke: die der Nutzer und die der
Anbieter. Deswegen ist es wichtig, sich
mit den Grundregeln der Formulargestaltung auseinander zu setzen und sie
anzuwenden. Bereits kleine Änderungen erzielen die gewünschte Wirkung
– den zufriedenen und treuen Nutzer.
Keywords
der ansprechenden und benutzertauglichen Gestaltung eines Formulars:
Der Kunde soll Vertrauen behalten
oder gewinnen, der „Gast zum
Stammbesucher mutieren“.
empfohlen, ungleich lange Labels linksbündig anzuordnen, während gleich
lange Labels rechtsbündig darzustellen
sind. Die Empfehlungen dieser Norm
sind aber nicht unumstritten. So weist
Luke Wroblewski (2007a) darauf hin,
dass es die Lesbarkeit erhöhe, gerade
ungleich lange Labels linksbündig auszurichten, erklärt aber gleichzeitig, dass
so die Zusammengehörigkeit von Label
und Eingabefeld reduziert werde.
Die Usability der verwendeten Formulare stellt eine wichtige Einflussgröße
auf den Geschäftsprozess dar. Dennoch vernachlässigen viele Websites
(Anbieter von Produkten und Dienstleistungen) ihre Formulare, d.h. ihre
eigentlichen Kernapplikationen.
Schlechte Usability lässt die Nutzer
das Vertrauen in den Prozess und das
Produkt verlieren und führt aufgrund
von Nutzerfehlern zu Frustrationen
und unter Umständen zum Abbruch
des Prozesses und zum Wechsel zum
nächsten Anbieter.
2.0
2.1
Formular Usability, ISO-Norm, ECommerce, RIA
Ungleich lange Labels rechtsbündig
auszurichten, führt zu hoher wahrgenommener Zusammengehörigkeit von
Label und Feld, aber auch zu schlechter
Lesbarkeit. Ein guter visueller Hintergrund, der die Zugehörigkeit unterstützt,
kann dem Problem des weit entfernten
Labelings entgegenwirken (Abb. 2.1.1
und Abb. 2.1.2)
Der Weg zum guten Formular
Norm vs. Realität
Für die Gestaltung von Formularen
wurde eigens die EN ISO 9241-17
„Dialogführung mittels Bildschirmformularen“ entwickelt, in der die Grundregeln der Formulargestaltung dargestellt werden. Das Grundproblem der
Norm zeigt sich in ihrer allgemeinen
Umschreibung der Gestaltung von
Formularen. So wird beispielsweise
Abb. 2.1.1: Vorher – keine Zusammengehörigkeit
49
3.1
Abb. 2.1.2: Nachher – Zusammengehörigkeit
durch Farbhinterlegung erreicht.
Grundsätzlich erscheint fraglich, inwieweit es sinnvoll ist, die Länge der Labels
zur Grundlage einer Empfehlung zu machen. Unter Umständen führt dies dazu,
dass beim Einblenden von zusätzlichen
Feldern in dynamischen Formularen, bei
Revisionen bestehender Formulare oder
bei der Internationalisierung von Formularen das gesamte Formularlayout geändert werden muß – oder auch Formulare innerhalb einer Site unterschiedlich
gestaltet werden. Hier scheinen grundsätzliche, für eine Site dann verbindliche
Empfehlungen sinnvoll, wie sie z.B. die
Apple Human Interface Guidelines
(1993) ausspricht.
Dass die Norm relativ „weich“ formuliert
ist und wenig klare Anweisungen zur
Gestaltung von Formularen beinhaltet,
so dass man sie nicht bei technischen
Neuerungen anpassen muss, kann –
aus der Sicht der Normenautoren – als
Vorteil gesehen werden. Der große
Nachteil ihrer geringen normativen Kraft
liegt jedoch darin, dass sie dem Benutzer der Norm sehr wenig klare Handlungsanweisungen an die Hand geben –
sei es, wie man optimal Pflichtfelder
hervorhebt oder wie man Fehler anzeigen sollte.
3.0
Hauptprobleme bei der Gestaltung von Formularen
Die folgenden Hauptprobleme, geordnet
nach Design, Navigation und Content,
sind bei Online-Formularen häufig zu
beobachten:
50
Design
Im Kapitel „Design“ wird die grafische Gestaltung der Formulare aufgezeigt. Das Aussehen der Interaktionselemente und Dialoge, die Anordnung
der Elemente und die verwendete Typografie stehen dabei im Zentrum des
Interesses. Die beiden häufigsten Fehler sind einerseits, dass Formulare
visuell mangelhaft gestaltet, d.h. überladen, sind und andererseits, dass
Fehlermeldungen mangelhaft dargestellt werden.
3.1.1
Grafische Aspekte
Wroblewski (2007b) schlägt vor,
dass für den Nutzer ein „vertical
alignment“ als besonders günstig angesehen wird, d.h. die Feldbeschriftung soll oberhalb des Eingabefelds
stehen (Abb. 3.1.1). Bei längeren Formularen ist dies nicht günstig, da der
Nutzer auf den ersten Blick überfordert
und das Formular künstlich in die Länge gezogen wird. Außerdem rutscht es
oft unter die Scrollgrenze (Fold), was
die Orientierung erschwert. Dies geschieht besonders oft bei OnlineEinkaufsprozessen, die über mehrere
Schritte gehen (Anmelden, Eingabe
von Zahlungsmodalitäten wie Kreditkarte oder Paypal, Abschluss).
Möglichkeiten, Pflichtfelder darzustellen:
Sternchen (*), farbliche Abgrenzung etc.
Gelegentlich kommt es leider auch vor,
dass freiwillig auszufüllende Felder die
Sternchenmarkierung aufweisen. Die
Unternehmung sollte sich auch genau
überlegen, welche Daten sie wirklich
braucht: Es ärgert den Nutzer alle Eingabefelder eines langen Formulars ausfüllen zu müssen.
3.1.3
Fehlermeldung
Fehlermeldungen sollten verständlich und auf einen Blick erkennbar und
eindeutig zuordenbar sein – oder wie
Wroblewski (2007b) schreibt: „visually
distinguish errors from the rest of a
form“. Dem Nutzer sollte die Möglichkeit
gegeben sein, schnell und gezielt Fehler
zu korrigieren.
Bei einigen Formularen (Abb. 3.1.2) wird
die Fehlermeldung oberhalb des gesamten Formulars eingeblendet, was zu
einem „verblödenden“ Hin- und Herspringen zwischen der Fehlermeldung
und dem zu korrigierenden Feld führt
(das manchmal sogar unterhalb der
Scrollgrenze liegt!).
Abb. 3.1.1: Feldbeschriftung oberhalb des
Eingabefeldes.
3.1.2
Pflichtfeldermarkierung
Für den Nutzer soll gleich ersichtlich sein, welche Felder ausgefüllt
werden müssen. Es gibt verschiedene
Abb. 3.1.2: Umständliches Fehlersuchen ist
vorprogrammiert.
Effektiver ist es, den Nutzer in der unmittelbaren Nähe des Eingabefeldes mit
grafischen Mitteln auf den Fehler hinzuweisen, z.B. mittels Farbe und Beschreibung: „Bitte geben Sie Ihren
Nachnamen ein“. So ist auf den ersten
Blick ersichtlich, wo eine fehlerhafte
Eingabe gemacht wurde und wie diese
korrigiert werden kann (Abb. 3.1.3). Nutzer sollten bei fehlerhafter Eingabe nur
die Quelle des Fehlers bearbeiten müssen.
Statusleiste ist dafür unerlässlich (Abb.
3.2.1). Dabei sollte die Möglichkeit
bestehen, über die Statusleiste zurückzunavigieren und allfällige Änderungen anzubringen, ohne dass die
vorher mühsam eingegebenen Angaben zurückgesetzt werden. Im Mindesten soll es möglich sein, über den
Browser zurückzunavigieren. Denn
gerade der Abschluss eines Zahlungsprozesses ist für Unternehmen, die
ihre Produkte vorwiegend über das
Internet vertreiben, essenziell.
Abb. 3.2.1: Statusleiste.
Abb. 3.1.3: Nutzer sieht auf den ersten Blick,
wo Korrekturen anzubringen sind.
Ein glücklicherweise immer seltener zu
sehendes Phänomen ist, dass bei einer
Fehlermeldung der bisher eingegebene
Inhalt verschwindet.
3.2
Eingabeformat
Der Nutzer sollte wissen, was und
vor allem wie er die Eingabe machen
soll. So hilft die Angabe des Eingabeformats eines Geburtsdatums mittels
TT.MM.JJJJ oder DD/MM/YYYY etc.
(Abb. 3.2.2).
Abb. 3.2.3: Der Nutzer wird erst nach Eingabe seines Anliegens mit einer „Eingabebegrenzung“ überrascht.
Hier können RIAs (Rich Internet Applications), die auf Technologien wie Ajax
oder Adobe Flex beruhen, helfen, da der
Client laufend Daten mit dem Server
austauschen und zwischenspeichern
kann.
Die Eingabevalidierung zeigt dem Nutzer während der Eingabe an, ob er
bspw. die Eingabegrenze in einem Textfeld überschritten hat (Abb. 3.2.4).
Navigation
Der folgende Abschnitt beschäftigt
sich mit der Navigation. Der Fokus liegt
dabei auf den Interaktionsprozessen,
der Benutzerführung und der Bedienphilosophie von Formularen. Es soll auf die
Orientierung während eines Anmeldeprozesses mittels Formularen eingegangen werden sowie auf die adäquate
Rückmeldung während einer Angabe.
3.2.1
3.2.2
die entsprechenden Informationen entweder innerhalb des Formulars oder
durch die Benutzer extern abrufbar zur
Verfügung gestellt werden.
Statusleiste
Nutzer ärgern sich, wenn sie nicht
wissen, aus wie vielen Schritten sich der
Online-Zahlungsprozess zusammensetzt und wenn sie bei jedem „Weiter“Button mit jeweils einem neuen Formular überrascht werden, ohne eine Idee
zu haben, wann sie endlich den Einkaufprozess für das gewünschte Produkt
zum Abschluss bringen können. Eine
Abb. 3.2.4: Zeigt an, wie viele Zeichen noch
eingegeben werden können.
Abb. 3.2.2: Eingabeformat ist vorgegeben.
3.2.3
Eingabegrenzen
Es ist sicher schon vielen Nutzern
passiert, dass ihre Eingaben aus nicht
ersichtlichen Gründen verworfen wurden (Abb. 3.2.3). Wroblewski (2007a)
sieht die Lösung folgendermaßen:
„When input fields have a high potential for errors, consider providing inline
validation”. Dies impliziert die Rückmeldung via Rich Internet Applications
(RIA).
Wenn für die Verarbeitung von Informationen nur bestimmte Eingabewerte
zulässig sind, sollten den Benutzern
Dieses direkte Feedback hilft dem Nutzer die Eingabe zu kürzen, sobald er zu
viele Zeichen verwendet: „Provide adequate feedback to people filling in your
forms” (Spool 2008).
3.3
Content
In diesem Abschnitt geht es um die
Inhalte von Formularen. Nützlichkeit und
Menge der Information, Sprachstil sowie
die Gestaltung von Hilfe- und HinweisTexten stehen im Zentrum des Interesses. Oft steht die Menge der erfragten
Angaben in keinem Verhältnis zum Nutzen für den User: Es werden zu viele
Informationen erfragt.
51
Dem Nutzer muss klar sein, wofür die
Formulareingaben nützlich sind – oder
wie es Wroblewski (2007a) ausdrückt:
„your customer’s interests are clearly
aligned, explain why you are asking for
data that may not seem relevant“
(Wroblewski 2007). Spool (2008) betont
auch, dass der häufigste Fehler darin
liege, dass der Nutzer nicht wisse, wofür
er seine Adresse eingeben soll, wenn er
nur eine Freeware downloaden möchte:
„Remove unnecessary inputs“, macht
Wroblewski die klare Ansage.
4.0
Fazit
Es gibt eine Vielzahl weiterer Verbesserungspotenziale, die jedoch im
Rahmen dieser Arbeit nicht berücksichtigt werden können. Es wurde aus der
Erfahrung auf einige wichtige und oft
gesehene, zum Teil auch einfach lösbare Probleme in der Formulargestaltung
hingewiesen. Der Erfolg von OnlineGeschäftsprozessen wird durch die Reduktion der Formulare auf das Wesentliche nach dem KISS-Prinzip gesteigert
(„Keep it simple stupid“). Dies kann
durch die frühzeitige Einbindung des
Nutzers in den iterativen Entwicklungsprozess gewährleistet werden. So werden einerseits mehr Interessenten zu
Kunden konvertiert, und bestehende
Kunden werden zu loyalen Stammkunden. Obwohl Formulare eine alt bekannte Form der Kommunikation zwischen
Nutzern im Web sind und eine ISONorm zu dem Thema existiert, sind heute noch fehlerhafte Darstellungen und
schwierig verständliche Beschriftung
vorhanden. Um zu gewährleisten, dass
ein geschäftsrelevantes Formular (-workflow) funktioniert, sollte jede Formularapplikation aus der Sicht des Nutzers
gestaltet werden, d.h. bei der Gestaltung
des Workflows sollte man sich immer
Gedanken machen, was der Nutzer bei
diesem und beim nächsten Schritt erwartet. Dieser Ansatz verhilft zu einer
besseren Usability und erhöht wiederum
52
das Vertrauen in das Unternehmen
und das Produkt.
4.1
Quellenverweise
Apple Computer, Inc. (1993). Macintosh
Human Interface Guidelines. Readin, MA:
Addison-Wesley Publishing Co.
Spool, J. (2008). Account Sign-in: 8 Design
Mistakes to Avoid.
http://www.uie.com/articles/account_design
_mistakes/ (Letzter Zugriff: 05.06.2008)
Wroblewski, L. (2007a). Web Form Design
in the Wild, Part 1.
http://www.uie.com/articles/forms-fairmonthotel/ (Letzter Zugriff: 05.05.2008).
Wroblewski, L. (2007b). Web Application
Form Design.
http://www.uie.com/articles/web_forms/
(Letzter Zugriff: 04.05.2008)
4.2
Weiterführende Literatur
Bucher, S. (2003). Web-Formulare verstehen und benutzen.
http://www.stefanbucher.net/tutorial/formula
re (Letzter Zugriff: 13.09.2007).
Fowler, S.; Stanwick, V. (2004). Web Application Design Handbook: Best Practices for
Web-Based Software. San Francisco: Elsevier Inc.
Friedmann, V. (2006). Formulare und Umfragen: Moderne Lösungen
http://www.drweb.de/weblog/weblog/?p=70
8 (Letzter Zugriff: 24.09.2007).
Jacobsen, J. (2007). Website-Konzeption:
Erfolgreiche Websites planen und umsetzen. München: Addison-Wesley.
Krug, S. (2006): Don't make me think! Web
Usability – Das intuitive Web. Heidelberg:
Redline GmbH.
Nielsen Norman Group (2000). Trust: Design Guidelines for E-Commerce User Experience.
http://www.nngroup.com/reports/ecommerc
e/trust.html (Letzter Zugriff: 25.09.2007).
E yetracking
53
54
Visuelle Orientierung auf einer Website – Vergleich von
Sehbehinderten und Normalsichtigen mittels Eye Tracking
Sabrina Duda
eye square GmbH
Schlesische Str. 29-30
10997 Berlin
[email protected]
www.eye-square.de
Matthias Saur
Friedenstr. 61
10249 Berlin
[email protected]
Abstract
In einer immer älter werdenden Gesellschaft nimmt auch die Zahl der Menschen zu, die altersbedingt an Sehstörungen leiden. Umso wichtiger ist es zu
untersuchen, ob es Unterschiede in der
1.0
Einleitung
Das Internet ist für Menschen in jedem Alter zu einer wichtigen Quelle von
Information und Unterhaltung geworden.
Das vielleicht spannendste Ergebnis im
(N)ONLINER Atlas 2007 war, dass gerade in den höheren Altersgruppen ein
großer Zuwachs an neuen Internetnutzern zu verzeichnen ist. Demnach sind
58,3 Prozent der Deutschen zwischen
50 und 59 „online“. Bei den über 60jährigen sind immerhin 35,5 Prozent im
Internet aktiv. Keine andere Generation
hat in den letzten Jahren eine vergleichbare Wandlung vollzogen – und der
Trend scheint anzuhalten.
Altersbedingt leiden einige dieser Nutzer
an Sehbehinderungen, die über eine
einfache Sehstörung hinausgehen. Um
ihnen das Lesen von Webhinhalten zu
vereinfachen, gibt es spezielle Vergrößerungssoftware, die wie eine Lupe für
Websites funktioniert. Der Bildschirm
kann bis zu dreißigfach vergrößert werden. Die Nutzer scrollen dabei in Ausschnitten über die Seite oder benutzen
Shortcuts auf der Tastatur, um auf der
Seite zu navigieren.
In der vorliegenden Studie nutzten alle
Testpersonen ausschließlich eine Vergrößerungssoftware. Somit sind die Ergebnisse auf diese spezielle Art der
Orientierung auf Websites zwischen
Sehbehinderten und Nichtsehbehinderten gibt. eye square hat mittels Eye
Tracking grundlegende Unterschiede
untersucht und analysiert.
Keywords
Webnutzung bezogen, Screen Reader
Nutzung wurde nicht untersucht.
nik bereits seit dem Jahr 2001 bei Studien zur Web-Usability ein. Speziell von
eye square entwickelte Software unterstützt die Datenauswertung und Visualisierung.
Nur wenige Websites sind auf die Nutzung mit Vergrößerungssoftware ausgerichtet. Aus diesem Grund gilt es,
eine wichtige Frage zu klären: Orientieren sich sehbehinderte Menschen
auf Websites anders als Nichtsehbehinderte? Und wenn ja – welche Unterschiede sind feststellbar? Bisher
gab es kaum Forschung auf diesem
Gebiet, so dass es noch ein weites
Feld zu explorieren gilt.
Abb. 1: Usability Lab mit Eye Tracking Monitor und Einwegscheibe
Die Analyse der visuellen Orientierung
geschah im Rahmen einer Usability
Studie mit Eye Tracking. In dieser Untersuchung unter Laborbedingungen
wurde die Technik des Eye Tracking
dazu genutzt, um mögliche Unterschiede im Blickverhalten von Sehbehinderten und Nichtsehbehinderten zu
messen. eye square setzt diese Tech-
Eye Tracking, Blickbewegung, Visuelle
Orientierung, Bildschirmvergrößerung,
Sehbehinderung.
1.1
Untersuchte Aspekte und Hypothesen
Drei Hauptaspekte der visuellen Orientierung sollen im Rahmen der Studie
erforscht werden:
Die allgemeine visuelle Orientierung –
man kann hierbei auch von einer Blickstrategie sprechen. Beim Betrachten
einer Website haben Nutzer eine bestimmte Strategie, um die für sie relevanten Informationen zu finden. Die
Website wird sozusagen „gescannt“.
Dadurch ergibt sich ein Blickpfad. Es
wird angenommen, dass Sehbehinderte
und Nichtsehbehinderte hierbei verschiedene Strategien und somit verschiedene Blickpfade nutzen.
Die visuelle Orientierung an Bildern und
Text. Durch die Vergrößerung durch die
Software werden auf der Website eingebundene Bilder weniger scharf dargestellt. Das heißt, dass Sehbehinderte
deutlich unschärfere Bilder erhalten. Bei
starker Vergrößerung wird das Bild zudem nur in Ausschnitten sichtbar. Daher
wird erwartet, dass Sehbehinderte sich
weniger stark an Bildern orientieren und
55
dafür mehr am Text. Entscheidend ist
hierbei das Verhältnis, in dem Text und
Bild von jeder Gruppe betrachtet werden.
Die allgemeine strategische Orientierung
auf der Website. Dies wird an der Anzahl der Seitenaufrufe festgemacht, die
eine Testperson benötigt, um eine gewünschte Information zu finden. In einer
früheren Studie von Coyne & Nielsen
wurde festgestellt, dass sehbehinderte
Menschen eine höhere Anzahl von Seitenaufrufen benötigen, um an ihr Ziel zu
kommen (Coyne & Nielsen 2001). Daher
wird auch in dieser Studie bei den Sehbehinderten eine höhere Anzahl von
Seitenbesuchen erwartet als in der Kontrollgruppe.
2.0
Testdurchführung
2.1
Stimulus und Testmaterial
Die Website, mit der die Studie
durchgeführt wurde, sollte möglichst
lebensnah sein und für die Teilnehmer
eine gewisse persönliche Relevanz haben. Um dies zu gewährleisten, wurde
die Website eines lokalen Radiosenders
ausgewählt (Radio Eins). Damit der persönliche Bezug gesichert werden konnte, wurden ausschließlich Testpersonen
ausgewählt, die Radionutzer sind. Der
Großteil der Testteilnehmer zählte sich
laut Vorbefragung sogar zur Stammhörerschaft des Senders. Die Untersuchung wurde mit der live Website des
Radiosenders durchgeführt.
Abb. 2: Radio Eins Website
Die Testpersonen lösten acht Aufgaben,
die ebenfalls einen starken Alltagsbezug
56
aufwiesen. So suchten sie zum Beispiel nach der Radiofrequenz für eine
bestimmte Region oder nach dem Interpreten eines gerade gespielten Musiktitels.
In einer Vorbefragung wurden demografische Daten sowie Radionutzung
und Computer- und Interneterfahrung
der Teilnehmer erhoben.
2.2
Untersuchungsgruppen
N=12 Personen nahmen an der
Studie teil. Davon hatten sechs eine
Sehbehinderung, sechs Teilnehmer
waren normalsichtig.
Um Aussagen über die kognitive Aufnahme einer Information treffen zu können, werden weitere Daten benötigt.
Von einer kognitiven Aufnahme geht
man nur während einer Fixierung der
Pupille aus. Es muss also festgestellt
werden, wann die Pupille einen Punkt
fixiert hat und wann sie die Blickrichtung
wechselte. Dazu wird die Geschwindigkeit der Pupille zwischen zwei gemessenen Blickpunkten aufgenommen. Bewegt sich diese unterhalb eines spezifisch festgelegten Grenzwertes, kann in
dem betreffenden Blickabschnitt von
einer Fixierung ausgegangen werden.
In der Vorbefragung bewerteten die
Teilnehmer ihre Computer- und Interneterfahrung auf einer Skala von 1 bis
5 (1 = „sehr gering“ und 5 = „sehr
hoch“). Im Durchschnitt bewerteten die
Tester sich selbst mit 3,9 – also als
routinierte Nutzer.
Das Durchschnittsalter der Sehbehinderten lag bei 48 Jahren. Die Gruppe
der Nichtsehbehinderten war mit einem Schnitt von 45,3 Jahren nur unwesentlich jünger.
2.3
Die Eye Tracking Technik
Hauptbestandteil der Untersuchung
war die Registrierung der Blickbewegung mit der Eye Tracking Technik.
Eine Grundannahme dieser Technik
ist, dass die kognitive Aufnahme und
Verarbeitung einer Information im ersten Schritt durch das scharfe Sehen
eines Objektes möglich wird. Es gibt
nur einen kleinen Bereich auf der
Netzhaut im menschlichen Auge, in
dem scharfes Sehen möglich ist. Mit
der Technik des Eye Tracking kann
der Winkel gemessen werden, in dem
die Pupille auf ein bestimmtes Objekt
gerichtet ist. Dadurch ist es möglich
auszurechnen, welcher Punkt vom
Auge scharf wahrgenommen werden
konnte.
Abb. 3: Testsituation im Usability Lab mit Eye
Tracking Monitor
Der Eye Tracker wird auf jeden Probanden individuell eingestellt (Kalibrierung).
Dabei wird das Gesichtsfeld der Testperson ausgemessen. Die Blickbewegung kann nicht zwingend Aussagen
darüber treffen, welche Reizinformationen vom Gehirn tatsächlich verarbeitet
werden. Die Betrachtung von Objekten
ist keine hinreichende, allerdings eine
notwendige Bedingung dafür, dass Reize verarbeitet werden. Das Eye Tracking
liefert verlässliche Informationen über
nicht beachtete Bereiche und Objekte,
sowie über Blickhäufigkeiten und Blickreihenfolgen.
3.0
Ergebnisse
3.1
Daten
Die gemessenen Daten aus der
Gruppe der Nichtsehbehinderten wurden
mit der von eye square entwickelten
Software „Visualizer“ ausgewertet.
Aufgrund des veränderten Bildschirmausschnitts durch die Vergrößerungssoftware war eine automatisierte Datenverarbeitung bei der Gruppe der sehbehinderten Personen nicht möglich. Die
aufgenommenen Blickbewegungen wurden daher im ersten Schritt manuell kodiert. Danach konnte eine Weiterverarbeitung durch den „Visualizer“ erfolgen.
Für den Vergleich der Orientierung an
Bild oder Text wurde für beide Bereiche je eine kumulierte Fixationsdauer
berechnet. Der eye square „Visualizer“
gibt hierzu die Verweildauer in Millisekunden aus. Auf der jeweiligen Webseite werden mit Hilfe des „Visualizers“
so genannte „Areas of Interest“ definiert. In diesem Fall wurden die Seiten
in Bild- und Textbereiche eingeteilt.
Die Hypothese, ob Sehbehinderte
insgesamt mehr Seiten aufrufen müssen, um ans Ziel zu gelangen, wurde
durch einen Vergleich der Gesamtanzahl von Seitenaufrufen pro Gruppe
geprüft.
länge
Blickpfadfläche
Übergangsdichte
Text-Bild-Verhältnis
Abb. 4: Darstellung der Blickdichteverteilung
mit dem eye square „Visualizer“
3.2
Auswertung
Für jede der drei Hypothesen wurden
spezifische Parameter festgelegt, an
denen die Bestätigung der Hypothesen
oder deren Ablehnung abzulesen sind:
Die visuelle Orientierung, beziehungsweise die Blickstrategien der Gruppen,
wurden anhand der gemessenen Blickpfadlänge, Blickpfadfläche und der
Übergangsdichte verglichen.
20000
15000
15739
10000
6602
5000
0
Normalsichtige Sehbehinderte
Abb. 6.: Blickpfadlänge (Mittelwerte in Pixel)
Blickpfadfläche in Pixel
200000
180000
160000
158666
147330
140000
120000
Blickpfad-
Da die getestete Website während der
Durchführung redaktionell verändert
wurde und die Tester teilweise verschiedene Seiten aufgerufen haben, wurden
für jeden Parameter bestimmte Webseiten ausgewählt, die von allen Testern
besucht worden waren und deren Inhalt
konstant geblieben war.
Blickpfadlänge in Pixel
Seitenbesuche
pro Aufgabe
Kumulierte Distanz zwischen
den Fixationen eines Blickpfads
Fläche, die gebildet werden
kann, wenn die äußersten
Fixationen eines Blickpfads
miteinander verbunden werden
Normalsichtige
Übergangsdichte in Prozent
50
40
Kumulierte Fixationsdauer in
den Bildbereichen in Prozent
zum gesamten Inhaltsbereich
(Bildbereiche und Textbereiche)
10
Anzahl der Seiten, die bis zur
Lösung einer Aufgabe besucht
wurden
Ergebnisse zu den Hypothesen
Die erste Hypothese konnte nicht
bestätigt werden. Bezüglich der Blickpfadlänge, Blickpfadfläche und Übergangsdichte auf den Webseiten gab es
keine signifikanten Unterschiede zwischen Sehbehinderten und Nichtsehbehinderten. Die Werte fallen bei der
Gruppe der Sehbehinderten jedoch
tendenziell etwas niedriger aus.
Sehbehinderte
Abb. 7: Blickpfadfläche (Mittelwerte in Pixel)
Anzahl der Übergänge zwischen Bereichen in Prozent zu
den möglichen Übergängen
Abb. 5: Parameter Definitionen
3.3
100000
30
20
16
10
0
Normalsichtige
Sehbehinderte
Abb. 8: Übergangsdichte (Mittelwerte in Prozent)
Die zweite Hypothese, dass Sehbehinderte sich weniger an der Bebilderung
einer Website orientieren, konnte bestätigt werden. Die kumulierte Fixationsdauer auf den Bildern ist bei dieser
Gruppe signifikant geringer als bei der
Gruppe der Nichtsehbehinderten.
57
Verhältnis Bild-Gesamtinhalt in Prozent
50
40
30
23
20
18
10
0
Normalsichtige
Sehbehinderte
Abb. 9: Verhältnis Bild-Gesamtinhalt (Mittelwerte in Prozent)
Abb.10: Darstellung der Wahrnehmungsdauer auf den verschiedenen Areas
Die Datenlage zur dritten Hypothese
überraschte: Entgegen der Annahme
benötigten die sehbehinderten Testpersonen signifikant weniger Seitenaufrufe,
um die Aufgaben zu lösen. Die Hypothese, dass sich Sehbehinderte schlechter auf einer Website orientieren können,
muss somit verworfen werden. Dieses
Ergebnis ist umso erstaunlicher, da es
der Studie von Coyne & Nielsen von
2001 widerspricht. In deren Studie war
die Anzahl von aufgerufenen Seiten bis
zur Lösung bei Sehbehinderten deutlich
höher als bei der Kontrollgruppe.
Anzahl Seitenbesuche pro Aufgabe
10
8
6
4,5
4
3,9
2
0
Normalsichtige
Sehbehinderte
Abb.11: Seitenbesuche (durchschnittliche
Anzahl pro Aufgabe)
58
4.0
Diskussion
Das visuelle Verhalten von Sehbehinderten und Nichtsehbehinderten
scheint hinsichtlich der untersuchten
Aspekte sehr ähnlich zu sein. Jedoch
ist damit nicht gesagt, dass es generell
keine Unterschiede gibt. Es traten vereinzelt Signifikanzen bezüglich der
Blickpfadparameter auf. Diese könnten
in weiteren Studien zum Aufbau der
getesteten Website ins Verhältnis gesetzt werden. In dieser Studie war es
nicht das Ziel, konkrete Bezüge zur
Gestaltung der Website herzustellen.
Dieser Forschungsfrage könnte in weiteren Studien nachgegangen werden.
Die Frage nach dem Bezug zum
Aufbau einer Website stellt sich auch
in Hinsicht auf die Bildorientierung von
Sehbehinderten. Da Sehbehinderte
Bilder auf Websites weniger stark betrachten, könnte bei der Entwicklung
von zielgruppenspezifischen Websites
auf eine starke Bebilderung verzichtet
werden.
länger als die Teilnehmer der Kontrollgruppe. Dies könnte durch den engen
inhaltlichen Zusammenhang vom Text
mit der Vorstellung des Mitarbeiters und
dessen Bild begründet sein: Das Bild
trägt hier Informationen, die nicht im
Text dargestellt werden können. Ist das
Bild nur visuelle Unterstützung, wie auf
den anderen untersuchten Seiten, enthält das Bild keinen Mehrwert.
Die geringere Anzahl von Seitenbesuchen bei Sehbehinderten lässt vermuten, dass sie mit dem Aufbau der Website, beziehungsweise mit der Aufgabelösung, besser zu Recht kamen. Zu bedenken ist hierbei, dass die Sehbehinderten mehr Zeit zum Lösen der Aufgabe benötigen. Möglicherweise sahen
sich die Testpersonen die Webseite
länger und somit gründlicher an, bevor
sie die nächste Seite wählten. Nichtsehbehinderte könnten eine Tendenz dazu
haben, die Seiten eher zu überfliegen
und rasch den ersten möglichen Link
auszuwählen, der zum gewünschten Ziel
führen könnte.
4.1
Fazit
Es lässt sich zusammenfassen, dass
die Untersuchung des Orientierungsverhaltens von Sehbehinderten einen ersten Schritt auf dem Weg der weiteren
Forschung darstellt. Auf den Ergebnissen dieser Studie können weitere Untersuchungen aufbauen, die auf die einzelnen Punkte noch gezielter eingehen.
Abb. 12: Verweildauer auf einzelnen Areas
Bei der Auswertung der Daten zu dieser Hypothese deutete sich ein weiterer interessanter Zusammenhang an:
Während Sehbehinderte auf den meisten Unterseiten der Radio Eins Website die Bebilderung, die nur Zusatzinformationen zum Text lieferte, weniger
beachteten als Nichtsehbehinderte,
trat auf der Website „Mitarbeiter“ eine
Abweichung auf. Sehbehinderte betrachteten die Bilder der Mitarbeiter
Am spannendsten und aussichtsreichsten scheint die Frage nach den Zusammenhängen von Bild und Text und deren
Auswirkungen auf die Beachtung durch
Sehbehinderte zu sein.
Ziel der Forschung sollte sein, Internetseiten besser auf die Bedürfnisse von
Sehbehinderten zuzuschneiden; denn in
Zukunft werden noch mehr Menschen
das Internet nutzen, die selbst mit Sehhilfen nicht mehr 100% Sehschärfe erreichen.
5.0
Coyne, K. P.; Nielsen, J. (2001): Beyond
alt text: Making the web easy to use for
users with disabilities. Fremont: Nielsen
Norman Group.
Saur, M. (2007): Analyse der visuellen
Orientierung auf einer Website mittels
Eye Tracking. Diplomarbeit im Studiengang Kommunikationspsychologie,
Hochschule Zittau (Görlitz).
TNS Infratest: (N)ONLINER Atlas 2007.
59
Software-ergonomische Evaluation eines Buchungsportals
für Flugtickets mittels Blickbewegungsanalyse
Ludger Schmidt
Mensch-Maschine-Systemtechnik
Universität Kassel
Mönchebergstraße 7
34125 Kassel
[email protected]
www.mensch-maschinesystemtechnik.de
Elena Simeonova
Manager Online Sales,
Development and Operation
FRA XD/E
Deutsche Lufthansa AG
Lufthansa Aviation Center
60546 Frankfurt/Main
[email protected]
Abstract
Gegenstand dieses Beitrags ist die empirische Untersuchung eines webbasierten Buchungsportals für Flugtickets.
Zunächst wird die Methodik der Blickbewegungsanalyse kurz vorgestellt, die
als Evaluationsverfahren eingesetzt
wurde. Damit stehen zusätzlich zu Leistungsdaten (wie Ausführungszeiten und
Fehler) weitere verhaltensbeschreibende objektive Daten zur Verfügung, die
durch in Benutzerbefragungen erhobene, subjektive software-ergonomische
Bewertungen ergänzt werden. Ziel der
Untersuchung war es, durch diese Methodenkombination Gebrauchstauglich-
1.0
Einleitung
In diesem Beitrag wird die softwareergonomische Evaluation eines webbasierten Buchungsportals für Flugtickets
vorgestellt, bei der über eine Blickbewegungsmessung der Versuchspersonen
objektive Verhaltensdaten erhoben wurden. Die Blickbewegungsanalyse erfolgte in Kombination mit einem Fragebogen
und bei der Aufgabenbearbeitung erhobenen Leistungsdaten. Anhand von
konkreten Ticket-Buchungsaufgaben
sollte so auch der Frage nachgegangen
werden, ob sich subjektive und objektive
Daten sinnvoll gegenseitig ergänzen, so
dass im Ergebnis besser auf Benutzbarkeitsdefizite geschlossen werden kann.
2.0
Methodik
Als Blickbewegungsmessung wird
eine indirekte Beobachtungsmethode
60
keitsdefizite der Buchungsoberfläche
aufzudecken und daraus Gestaltungshinweise zur software-ergonomischen
Verbesserung abzuleiten. Am Experiment nahmen 20 Probanden teil, die
jeweils drei repräsentative Buchungsaufgaben lösen mussten. Die Analyse
der Blickbewegungs- und Leistungsdaten sowie die Fragebogenauswertung
identifizierten teilweise übereinstimmende Problembereiche, ein Teil der
Defizite konnte jedoch nur anhand der
Blickbewegungsdaten aufgedeckt werden.
Keywords
bezeichnet, mit der sowohl Bewegungen als auch das Verharren der Blicke
des Benutzers in einer offenen oder
verdeckten Weise erfasst und lokalisiert werden. Dadurch wird versucht,
Rückschlüsse auf die Prozesse der
Aufnahme, Verarbeitung und Speicherung von Informationen auf kognitiver
Ebene zu ziehen (Leven 1991). Bei
dem im Rahmen dieser Untersuchung
eingesetzten Gerät wird Infrarotlicht
auf das Auge der Versuchsperson
gestrahlt und die resultierenden Cornea-Reflexe erfasst und ausgewertet.
Auf diese Weise werden dynamische
Informationen über Blickbewegungen
gewonnen und mit Bildern von einer
Szenenkamera, die das jeweilige Bild
vor den Augen der Person aufnimmt,
überlagert. Das Ergebnis ist ein Szenenbild mit einer Markierung der momentanen Blickposition. Die Messung
liefert damit eine objektive Protokollie-
rung des Benutzerverhaltens hinsichtlich
der visuellen Wahrnehmung einer Benutzungsschnittstelle und Daten über
den örtlichen und zeitlichen Verlauf der
menschlichen Aufmerksamkeit.
Head Mounted Eye Tracking, SoftwareErgonomie, Webseitenuntersuchung,
Evaluationsmethodenmix
Die Blickregistrierungsparameter geben
Hinweise zur kognitiven Beanspruchung
der Anwender bei der Interaktion mit
einem System, so dass die Erkenntnisse
auch zur software-ergonomischen Bewertung benutzt werden können. So ist
es z. B. möglich, Aussagen über die
Sichtbarkeit und Verständlichkeit einzelner Bereiche der Benutzungsschnittstelle abzuleiten und damit die Effektivität
eines Layouts zu evaluieren. Allerdings
ist der technische, methodische und
auswertungsbezogene Aufwand insbesondere bei dynamischen Webseiten
und/oder Bildschirm-Scrollbedarf relativ
hoch. Die Methode eignet sich dafür, in
Kombination mit anderen Datenerhebungsverfahren (z. B. Interviews, Frage-
bögen und Leistungsmessungen) verwendet zu werden (Karn et al. 2000),
wie es auch in dem hier vorgestellten
Evaluationsansatz erfolgen soll.
Zur Erfassung und Analyse von Blickbewegungen haben sich verschiedene
Kennzahlen etabliert. Die Anwendung
bestimmter Größen für die Untersuchung einer grafischen Benutzungsschnittstelle hängt jedoch stark vom jeweiligen Untersuchungsziel und
-gegenstand sowie von den technischen
Gegebenheiten des verwendeten Blickregistrierungssystems ab. In einem literaturanalytischen Vorgehen wurden
mögliche Blickbewegungsparameter,
typische Wertebereiche und deren Eignung für die Aufdeckung softwareergonomischer Probleme identifiziert.
Zentrale Parameter lassen sich aus Fixationen und Sakkaden der Blicke ableiten:
x
x
x
x
x
Durchschnittliche Fixationsdauer als
Maß für die visuelle Aufmerksamkeit
bezogen auf das fixierte Objekt,
Anzahl Fixationen als Maß für die
Beanspruchung durch Informationssuche und -aufnahme,
Verweildauer innerhalb einer Area of
Interest (AoI) als Maß für die kognitive Beanspruchung bei der Informationsaufnahme,
durchschnittliche Anzahl Sakkaden
pro Zeiteinheit als Maß für die Anforderungen einer visuellen Aufgabe
mit stark eingeschränkter Informationsaufnahme und
Anzahl Sakkaden als Maß für die
Effektivität der Oberflächengestaltung, insbesondere der räumlichen
Anordnung.
Für einen detaillierten Überblick weiterer
Kenngrößen und ihrer software-ergonomischen Interpretation sei auf Goldberg
& Kotval (1998), Rötting (2001), Jacob &
Karn (2003), Poole & Ball (2004) sowie
Link et al. (2008) verwiesen.
3.0
Versuchsdurchführung
An der Untersuchung nahmen insgesamt 20 Probanden im Alter von 25
bis 56 Jahren teil (Durchschnittsalter
35 Jahre, 14 männlich, 6 weiblich, alle
mit Deutsch als Muttersprache). Sie
nutzten regelmäßig das Internet und
hatten teilweise erste Erfahrungen mit
Online-Flugbuchungen (max. 5 Buchungen).
Die Untersuchung fand unter Laborbedingungen statt, um gleich bleibende
Umgebungsbedingungen zu gewährleisten. Die Versuchsperson saß mit
dem am Kopf befestigten Blickbewegungsmessgerät (Fa. SensoMotoric
Instruments; mit Infrarotdiode, halbdurchlässigem Spiegel, Augenkamera
und Szenenkamera) vor einem PC mit
Internetzugang zum Buchungsportal.
Auf einem zweiten PC, der von der
Versuchsleitung genutzt wurde, war
die Software zur Kalibrierung und
Auswertung der Blickbewegungsmessung installiert. An diesem war neben
dem Blickbewegungsmessgerät auch
eine zusätzliche Videokamera angeschlossen, die die mit einem Fadenkreuz überlagerten Szenenbilder aufnahm. Diese Videoaufzeichnungen
dienten später der Blickbewegungsanalyse und der Auswertung der Leistungsdaten (Zeiten, Fehler).
Vor Versuchsbeginn wurden den Probanden der Versuchsablauf und die
Funktionsweise der Blickbewegungsmessung erläutert. Nach selbstständigem Ausfüllen des Fragebogens zu
den demographischen Angaben wurde
das Blickbewegungsmessgerät kalibriert. Dieser Prozess nahm zwischen 5
und 45 Minuten in Anspruch. Anschließend wurde den Versuchspersonen eine Buchungsaufgabe vorgelesen und ein Hilfsblatt mit den wichtigsten Buchungsdaten ausgehändigt. Die
Person bearbeitete dann die Aufgabe
mit der zu untersuchenden Buchungs-
oberfläche mittels eines Web-Browsers.
Dann wurden in gleicher Art und Weise
zwei weitere Aufgaben gestellt und bearbeitet, deren Reihenfolge insgesamt
randomisiert war, um Reihenfolgeeffekte
zu vermeiden. Die Aufgaben (Buchung
einer Hin- und Rückreise, einer einfachen Reise und eines Sonderangebotes) sind repräsentativ für bestimmte
Kundengruppen und wurden auf Basis
einer vorherigen Nutzungsanalyse ausgewählt und gestaltet. Sie umfassen
jeweils sieben Buchungsschritte (Strecke, Datum, Flugmöglichkeiten, Preis,
Passagierangaben, Bezahlung und Buchungsbestätigung). Nach Abschluss
der letzten Aufgabe wurden die Versuchsteilnehmer gebeten, einen Ergebnis- und Bewertungsfragebogen auszufüllen. Die Beurteilung verschiedener
software-ergonomischer Kriterien erfolgte im Bewertungsteil dabei anhand einer
fünfstufigen Likertskala (1 = sehr gut, 2
= gut, 3 = befriedigend, 4 = ausreichend, 5 = mangelhaft).
Der Versuch dauerte je Person zwischen 50 und 90 Minuten; die Zeit war
im Wesentlichen von der Kalibrierungsdauer abhängig. Aufgrund eines technischen Defekts der Blickregistrierung
standen diesbezüglich für die Auswertung nur die Daten von 16 der 20 Probanden zur Verfügung; bei den Fragebögen und Leistungsmaßen wurden alle
20 Teilnehmer berücksichtigt.
4.0
Ergebnisse und Gestaltungsvorschläge
Die Auswertung der Blickbewegungs- und Leistungsdaten sowie der
Fragebögen lieferte trotz des hohen
Erprobungsgrades der Buchungsschnittstelle und ihrer Vorgängerversionen
insgesamt zahlreiche Hinweise, die im
Sinne einer formativen Evaluation für die
Überarbeitung der Buchungsoberfläche
genutzt werden konnten. Im Folgenden
61
könnte Abhilfe schaffen (Abb. 1 rechts).
Abb. 1: Untersuchte Eingabemaske für den ersten Buchungsschritt (links) und umgestaltete Variante (rechts)
werden einige exemplarische Resultate
aufgeführt.
bar über Destination und Reisedatum
positioniert worden (Abb. 1 rechts).
In Abb. 1 ist links die generelle Eingabemaske gezeigt, die als Einstieg in die
Buchungsaufgaben „Hin- und Rückreise“
sowie „Einfache Reise“ genutzt wurde.
Im Fragebogen wurde zwar von über
70 % der Teilnehmer eine alternative
Beschriftung mit „Hin- und Rückflug“
(AoI 1a) bzw. „Nur Hinflug“ (AoI 1b) bevorzugt, insgesamt wurde die Maske
aber bei beiden Buchungsarten als hilfreich empfunden (Median der Bewertung: 2). Die objektiven Beobachtungsdaten zeigten jedoch, dass im Falle einer Einfachreise 20 % der Versuchspersonen die entsprechende (nicht vorselektierte) Option in der AoI 1b nicht ausgewählt haben. Obwohl bei der Einfachreise gegenüber der Hin-/Rückreise zwei
Felder weniger ausgefüllt werden mussten, was sich auch in der 3 % kürzeren
mittleren Bearbeitungszeit niederschlug,
war die durchschnittliche Anzahl der
Sakkaden mit 43,2 um 6 % höher als bei
der Hin- und Rückreise. Dies kann mit
erhöhtem visuellem Suchaufwand bei
der Einfachreise durch die ungünstige
Anordnung des Auswahlfeldes erklärt
werden. Dieses Defizit aufgreifend ist in
der überarbeiteten Version der Eingabemaske neben der Beschriftungsänderung die Auswahl der Reiseart unmittel-
Die Ergebnisse aus der Befragung
deckten auf, dass nur die Hälfte der
Versuchsteilnehmer die Funktion des
Feldes „Ihre Buchungsklasse“ (AoI 2 in
Abbildung 1 links) richtig erkannt hat.
Die Blickbewegungsdaten belegten,
dass 30 % der Falschbeantworter dieses Feld gar nicht betrachtet haben.
Insgesamt lag die durchschnittliche
Fixationsdauer bei den Falschbeantwortern knapp 25 % niedriger als bei
den Richtigbeantwortern. Dies spricht
gegen Interpretationsprobleme und für
ein niedriges Niveau der zugeteilten
visuellen und kognitiven Aufmerksamkeit; eine auffälligere Gestaltung des
Buchungsklassenfeldes bzw. eine
übersichtlichere Strukturierung im Bearbeitungsverlauf von oben nach unten
62
Im zweiten Schritt sollte bei einer Buchungsaufgabe das Hin- und Rückreisedatum ausgewählt werden (Abb. 2 links).
Die Darstellung mit dem gelben Rahmen
konnte den Teilnehmern laut Fragebogen gut beim schnellen Auffinden ihrer
ursprünglich gewünschten Flugtage helfen (Median: 2). Die Analyse der durchschnittlichen Anzahl Sakkaden pro Zeiteinheit für „Hinflug“ (AoI 2) und „Rückflug“ (AoI 1) ergab aber überraschenderweise einen um 26 % höheren Wert
innerhalb der AoI 1, so dass zumindest
teilweise erhöhte visuelle Anforderungen
bei der Suche nach den ursprünglich
eingegebenen Tagen vermutet werden
müssen. Die subjektive Beurteilung der
zweidimensionalen Darstellung in der
Tabelle lag an der Schwelle zwischen
„gut“ und „befriedigend“ (Median: 2,5).
Die Auswertung der freitextlichen Kommentare ergab, dass rund 35 % der Versuchspersonen ein Problem mit der
Darstellung der Flüge in dieser Tabelle
hatten: Unübersichtlichkeit und Schwierigkeiten mit der Darstellung von Flugund Preisdaten waren oft erwähnte
Stichpunkte.
Der Verbesserungsvorschlag (Abb. 2
rechts) bestand darin, die ursprünglichen Flugtage in Spalte, Zeile und
Schnittpunkt dezent farbig zu hinterlegen und diese Farbe in einer Legende
zu erläutern. Um nicht von den ebenfalls
farbig gelb-orange markierten günstigs-
Abb. 2: Datumsauswahl und Anzeige der günstigsten Preise im zweiten Buchungsschritt
(untersuchte Version links, Verbesserungsvorschlag rechts)
Abb. 3: Neugestaltete Variante zur Datumsauswahl und Anzeige der günstigsten Preise
ten Tarifen (AoI 3) abzulenken, wurde
die Hervorhebung in der Umsetzung
jedoch dann nur bei den Flugtagen und
in weiß mit einem Pfeil vorgenommen
(Abb. 3). Eine mögliche Lösung zum
Problem der Unübersichtlichkeit und der
Preistransparenz könnte das Anbringen
einer zusätzlichen Reihe bzw. Spalte mit
der Aufschrift „Rückflug“ und „Hinflug“
sein, die die jeweiligen Flugtage übergreifend zusammenfasst (Abb. 2 rechts).
Zusätzlich kann diese Aufteilung farblich
oder mit einem größeren Schriftgrad
unterstrichen werden. Ferner werden die
Zellen mit den Datumsangaben um einen Inhalt reduziert, was die restliche
Information visuell und kognitiv zugänglicher macht.
Ein Großteil der Befragten (75 %) hat die
Funktion der gelb-orangen Markierung
(AoI 3) richtig erkannt, obwohl nur 10 %
der Teilnehmer auf die erklärenden Zeilen am Anfang der Seite (AoI 4) gesehen
haben. Die Verweildauer innerhalb der
AoI (Maß für die kognitive Beanspruchung) liegt mit 500 ms eher im unteren
Bereich, so dass für die Benutzer offenbar keine Interpretationsschwierigkeiten
bestanden. Dieses Gestaltungsmerkmal
wurde daher im Verbesserungsvorschlag (Abb. 2 rechts) und der nachfolgenden Umsetzung (Abb. 3) mit einer
verkürzten Farberläuterung als Legende ansonsten ohne weitere Änderung
beibehalten.
Im nächsten Buchungsschritt werden
die Flugmöglichkeiten und Preise für
die ausgewählte Hin- und Rückflugkombination angezeigt. Rund 45 % der
Versuchsteilnehmer wussten hier
nicht, dass der nach der Flugselektion
angezeigte Preis nicht der Gesamtpreis ist und dass noch zusätzliche
Gebühren anfallen würden. Die Analy-
se der Blickbewegungen zeigte, dass
die Hälfte der Teilnehmer die erklärende
Fußnote nicht gelesen hat. Ein ähnlicher
Effekt konnte für eine „Datum ändern“Funktion festgestellt werden, die von
mehr als der Hälfte der Versuchspersonen nicht gefunden wurde. Die Blickbewegungsdaten belegten, dass lediglich
19 % der Teilnehmer dieses Seitenelement überhaupt anvisiert hatten, was
ebenfalls auf eine schlechte Sichtbarkeit
des „Datum ändern“-Links hindeutet. Die
Probanden, die mit der Funktion gearbeitet haben, empfanden die Selektion
eines anderen Datums so als bequem
(Median: 2,0). Als Verbesserungsvorschläge wurden eine auffälligere, aufgrund der Fluglistenlänge sogar doppelte Angabe des Preises für Hin- und
Rückflug sowie eine bessere Sichtbarkeit der „Datum ändern“-Funktion durch
eine Veränderung der Schriftart und eine
klarere Zuordnung zu den Flugzeiten
aufgegriffen.
Nach zusammenfassender Anzeige der
Details zur ausgewählten Flugkombination und der Darstellung des Gesamtpreises und seiner Bestandteile im
nächsten Schritt sollten die Benutzer
zwischen „Login“ für bereits registrierte
Abb. 4: Auswahl zwischen Login und Buchung ohne Registrierung (untersuchte Version
oben, neugestaltete Variante unten)
63
Personen und „Buchung ohne Registrierung“ auswählen (Abb. 4 oben). 85 %
der Versuchsteilnehmer wussten zwar,
dass diese beiden Optionen komplementär zueinander sind, die Blickbewegungsanalyse lieferte jedoch Daten, die
für eine große visuelle Belastung in diesem Bereich sprechen. Die durchschnittliche Anzahl der Sakkaden war nahezu
doppelt so groß wie in anderen Bereichen, woraus auf Schwierigkeiten bei
der visuellen Suche durch eine suboptimale Gestaltung dieser Elemente (unbewusste Trennung durch zwei dunkler
grau unterlegte Überschriften mit Aufzählungspunkt) geschlossen wurde. In
der verbesserten Version (Abb. 4 unten)
wurde durch das geänderte Layout mit
einer gemeinsamen dunkel unterlegten
Überschrift und der Darstellung der beiden alternativen Optionen als nebeneinander stehende Spalten versucht, diesem Problem zu begegnen.
In den nächsten beiden Buchungsschritten sollten die erforderlichen persönlichen Daten als Passagierangaben und
die Zahlungsinformationen eingegeben
werden. In diesen Bereichen konnten
keine Schwierigkeiten identifiziert werden. Obwohl es nach den Eintragungen
zur Zahlungsweise angezeigt wurde, war
es einem Großteil der Versuchsteilnehmer (60 %) nicht bewusst, welche Ausstellungsform das Ticket hat. Die Auswertung der Blickregistrierungsdaten
zeigte, dass rund 31 % von ihnen den
Hinweis nicht gelesen hatten. Bei den
restlichen Personen, die keine richtige
Antwort gegeben hatten, deutete eine
normale durchschnittliche Fixationsdauer von 780 ms auf keine Besonderheiten
hin. Das könnte ein Hinweis darauf sein,
64
dass diese Probanden die Information
zwar gelesen haben, mit dem Begriff
„etix®-Ticket“ jedoch wenig verbinden
konnten. Als Gestaltungsvorschlag zur
besseren Wahrnehmbarkeit der TicketForm könnte hier mittels Schriftgröße
und -schnitt eine stärkere Hervorhebung erfolgen. Die Umwandlung des
Begriffs in einen anklickbaren Link zur
näheren Erläuterung könnte bei Unklarheiten zusätzliche Informationen
bereitstellen.
Im Fall der Buchungsaufgaben „einfache Reise“ und „Sonderangebot“ wurden vergleichbare Schritte durchlaufen, wobei die Darstellung teilweise
abweichend war, z. B. erfolgt die Flugauswahl bei der einfachen Reise über
eine Liste mit Karteikartenreitern für
unterschiedliche Flugtage statt mit der
Tabelle aus Abb. 2 bzw. 3. Auch bei
dieser Darstellungsart traten jedoch in
ähnlichem Umfang Benutzungsschwierigkeiten auf.
5.0
Fazit
Insgesamt konnten als Ergebnis
der software-ergonomischen Evaluation Probleme bei der Benutzbarkeit in
mehreren Buchungsschritten sowie
Schwierigkeiten durch eine ungünstige
Anordnung bestimmter Eingabefelder
aufgedeckt werden. Durch die detaillierten Ergebnisse der Blickbewegungsanalyse konnten daraus unmittelbar Verbesserungsvorschläge bezüglich der graphischen Gestaltung
abgeleitet werden. Methodisch konnte
gezeigt werden, dass sich die eingesetzten Methoden in ihren Vor- und
Nachteilen sehr gut ergänzen und eine
solide und konstruktive Basis für die
Evaluierung der Benutzbarkeit von
Mensch-Maschine-Schnittstellen aus
subjektiver und objektiver Sicht bilden.
6.0
Goldberg, J. H.; Kotval, X. P. (1998): Eye
Movement-Based Evaluation of the Computer
Interface. In: Kumar, S. K. (Hrsg.): Advances
in Occupational Ergonomics and Safety, Amsterdam: IOS, S. 529-532.
Jacob, R.; Karn, K. (2003): Eye Tracking in
Human-Computer Interaction and Usability
Research: Ready to Deliver the Promisses
(Sectionary Comment). In: Hyona, J.; Radach, R.; Deubel, H. (Hrsg.): The Mind's Eyes:
Cognitive and Applied Aspects of Eye Movements. Oxford: Elsevier Science.
Karn, K.; Ellis, S.; Juliano, C. (2000): The
Hunt for Usability: Tracking Eye Movements.
SIGCHI Bulletin. Association for Computing
Machinery, Nov./Dec., S. 11.
Leven, W. (1991): Blickverhalten von Konsumenten, Grundlagen, Messung und Anwendung in der Werbeforschung. Heidelberg:
Physica.
Link, D.; Tietze, H.; Schmidt, L.; Sievert, A.;
Gorges, W.; Leyk, D.: Berührungslose Augenund Blickbewegungsmessung. In: Schmidt,
L.; Schlick, C. M.; Grosche, J. (Hrsg.): Ergonomie und Mensch-Maschine-Systeme. Berlin: Springer, 2008, S. 371-391.
Poole, A.; Ball, L. J. (2004): Eye Tracking in
Human-Computer Interaction and Usability
Research: Current Status and Future Prospects. In: Ghaoui, C. (Hrsg.). Encyclopedia of
Human Computer Interaction. Pennsylvania:
Idea.
Rötting, M. (2001): Parametersystematik der
Augen- und Blickbewegungen für arbeitswissenschaftliche Untersuchungen. Schriftenreihe Rationalisierung und Humanisierung, Aachen: Shaker.
GoodGaze: Eine Technologie aus der Hirnforschung
analysiert Webseiten auf ihre Aufmerksamkeitswirkung
Nicolas Höning
Peter König
Fabian Stelzer
Johannes Steger
Niklas Wilming
Torsten Betz
Cornell Schreiber
Marion Schmitz
Universität Osnabrück
Albrechtstr. 28
49069 Osnabrück
http://www.goodgaze.de
Abstract
GoodGaze ist eine neurowissenschaftliche Software, welche die Aufmerksamkeitswirkung von Webseiten analysiert.
Über eine Computermodellierung
menschlicher Aufmerksamkeitsprozesse
berechnet GoodGaze innerhalb von ca.
20 Sekunden die aufmerksamkeitsstärksten und -schwächsten Bereiche
einer eingespeisten Webseite und visua-
1.0
Einleitung
Die Modellierung neuronaler Prozesse hat in der Hirnforschung der letzten Jahre zunehmend an Bedeutung
gewonnen. Ihre wissenschaftliche Relevanz schöpfen die mathematischen Modelle hierbei primär aus ihrer Vorhersagekraft: Je besser ein Modell Verhalten
vorhersagen kann, desto wahrscheinlicher ist es, über das Modell einen tatsächlichen Einblick in die Funktionsweisen des Gehirns zu erlangen.
Das Labor für Neurobiopsychologie des
Instituts für Kognitionswissenschaft an
der Universität Osnabrück1 hat sich in
diesem Bereich auf die Modellierung
menschlicher Aufmerksamkeitsprozesse
spezialisiert. Im Kern handelt es sich bei
1
Die Arbeitsgruppe Neurobiopsychologie um
Prof. Dr. König hat insgesamt etwa einhundert Artikel zu den relevanten Themen in international angesehenen und
peer-reviewed Journalen veröffentlicht.
Die Arbeitsgruppe ist kürzlich bei der
Evaluation der wissenschaftlichen Kommission Niedersachsens hervorragend
beurteilt worden und ist eines der weltweit
führenden Labore im Bereich der Aufmerksamkeitsforschung.
lisiert die Ergebnisse in Form verschiedener Heatmaps. GoodGaze wird
von der Universität Osnabrück als
Webservice angeboten. Nutzer laden
ihre zu analysierenden Entwürfe einfach hoch oder geben die URL einer
bestehenden Webseite an. Im Usability-Bereich bietet GoodGaze Agenturen
und Beratern die Möglichkeit, bereits
frühe Entwürfe innerhalb weniger Sekunden auf deren Aufmerksamkeitswirkung zu testen.
GoodGaze um ein ebensolches Modell
menschlicher Aufmerksamkeit, welches aber der spezifischen Vorhersage von Blickbewegungen über Webseiten dient.
Der Vorteil gegenüber klassischen Methoden wie dem Eye-Tracking oder dem
Attention-Tracking liegt auf der Hand:
Statt bis zu mehreren Wochen auf die
Ergebnisse einer Studie zu warten, für
die nicht nur das entsprechende Personal und Equipment, sondern vor allem
genügend Probanden benötigt werden,
liefert GoodGaze vergleichbare Ergebnisse innerhalb weniger Sekunden.
Ausgehend von der Frage, welche
Eigenschaften einer Webseite Blickbewegungen am stärksten anziehen,
werden im GoodGaze-Projekt statistischen Analysen dieser Eigenschaften
mit empirischen Daten aus EyeTracking Studien kombiniert. Die hierbei gewonnen Ergebnisse werden in
einem Aufmerksamkeitsmodell implementiert, welches für neu eingespeiste
Stimuli nun innerhalb von Sekunden
Voraussagen über deren Aufmerksamkeitswirkung treffen kann. Diese
Voraussagen lassen sich wiederum
durch vom Modell unabhängige EyeTracking Daten evaluieren.
Neben der Anwendung in der Wissenschaft, in welcher das Modell wertvolle
Einblicke in die Funktionsweisen
menschlicher Aufmerksamkeitsprozesse liefert, eröffnet GoodGaze' Spezialisierung auf Webseiten auch Anwendungsfelder im Usability-Bereich.
Keywords
Aufmerksamkeit, Web-Design, DatenAnalyse
Neben einer ergänzenden oder gar teilweise ersetzenden Funktion zu gängigen Eye-Tracking Methoden kommt
GoodGaze zudem auch für Anwendungsbereiche in Frage, für welche genannte klassische Methoden bislang
einfach zu teuer und zeitaufwendig waren. Interessant ist dies z. B. dann, wenn
sich das Design einer Webseite noch im
Entwicklungsstadium befindet. So können mit GoodGaze erstmalig bereits
frühe Design-Prototypen, für welche
eine Eye-Tracking Studie zu zeit- und
kostenaufwendig wäre, auf ihre Aufmerksamkeitswirkung untersucht werden. Es lassen sich somit umgehend
und in allen Entwurfphasen Schwachstellen aufdecken und entsprechende
Optimierungen implementieren.
65
Dieses Paper erläutert in Kapitel 2, welche Analysen GoodGaze anbietet. Kapitel 3 beschäftigt sich mit den möglichen
Einsatzbereichen der Software. Kapitel 4
liefert eine Einführung in den wissenschaftlichen Hintergrund, welcher in
Kapitel 5 im Kontext erster Evaluationsergebnisse vertieft wird. Eine Zusammenfassung folgt in Kapitel 6.
2.0
Quantitative und qualitative Datenanalyse
Bei der Erhebung und Interpretation
empirischer Daten im Bereich der Webseiten-Usability lässt sich grob zwischen
zwei Arten von Daten und entsprechenden Interpretationsmodi unterscheiden:
Eine qualitative Studie setzt den Fokus
auf das individuelle Nutzerverhalten, aus
welchem in direkter Weise Optimierungsempfehlungen abgeleitet werden
können. Qualitative Usability-Studien
kommen dabei in der Regel mit einer
relativ geringen Anzahl an Probanden
aus. Um die Usability eines Designs
jedoch auf möglichst repräsentative Art
und Weise zu evaluieren, benötigt es
quantitative Erhebungen, die das Verhalten größerer Nutzergruppen in systematischer und statistisch abbildbarer
Weise analysieren. Jacob Nielsen empfiehlt für quantitative Studien eine Mindestanzahl von 20 aus der jeweiligen
Zielgruppe rekrutierten Probanden,
problematisiert jedoch den hiermit verbundenen dramatischen Kosten- und
Ressourcenaufwand (Nielsen 2006).
GoodGaze bietet hierbei zumindest im
Bereich der Aufmerksamkeitsanalyse
Abhilfe. Der Service ermöglicht, quantitative Untersuchungen innerhalb von
Sekunden und ohne Probanden durchzuführen.
Durch den Einsatz neurowissenschaftlicher, rechnergestützter Methoden extrapoliert GoodGaze vom Aufmerksamkeitsverhalten demographisch trennbarer Versuchspersonengruppen auf das
wahrscheinlichste Blickverhalten anderer Menschen mit demselben demographischen Hintergrund. Für Usability-Berater und Agenturen entfällt somit
ein beträchtlicher Teil des Aufwands,
den quantitative Erhebungen (im EyeTracking Bereich) mit sich bringen.
Gleichzeitig ermöglicht GoodGaze
auch dort die Verwendung quantitativer Methoden, wo diese bisher aus
genannten Gründen eher gescheut
werden.
2.1
Die gesamte GoodGazeFunktionalität ist über einen Webservice erreichbar. Auf der GoodGazeWebseite2 laden Nutzer Entwürfe, die
analysiert werden sollen, einfach hoch.
Alternativ kann auch die Adresse einer
bestehenden Webseite angegeben
werden.
Im nächsten Schritt können Nutzer das
Aufmerksamkeitsmodell, welches für
die Analysen verwendet werden soll,
spezifizieren. Jedes Aufmerksamkeitsmodell entspricht hierbei einer
bestimmten demographischen Gruppe,
deren Aufmerksamkeitssignatur im
Modell implementiert ist. Aktuell stehen zwei Modelle zur Verfügung: Das
Standardmodell basiert auf Erhebungen mit Studenten, das Modell für
Rot/Grün-Schwäche simuliert das
Blickverhalten von Studenten mit selbiger Einschränkung. Eine Erweiterung
der Modellpalette um andere demographische Gruppen (z. B. Schüler und
Senioren) ist in den kommenden Monaten geplant.
Nutzer können ihre Analysen bequem
in einer Ordnerstruktur selbst verwalten. Daneben ist es möglich, Analysen
für andere Nutzer zugänglich zu machen und zu kommentieren, um so
Erfahrungen und Tipps auszutau-
2
66
Nutzung der Website
schen. Die GoodGaze Webseite ist in
Deutsch und Englisch lokalisiert.
2.2
Analysen
Aktuell stellt GoodGaze Nutzern folgende Analyse- und Visualisierungsmodi
zur Verfügung.
2.2.1
Aufmerksamkeitskarte
Die Aufmerksamkeitskarte (oft als
„Heatmap“ bekannt) zeigt die aufmerksamkeitsstärksten und -schwächsten
Bereiche der Webseite. Dies ist die direkteste Darstellung einer GoodGazeAnalyse. Rote Bereiche haben eine hohe Wahrscheinlichkeit, von einem Nutzer betrachtet zu werden, blaue Bereiche werden von der Mehrheit der Nutzer
ignoriert.
Abb. 1: Die Aufmerksamkeitskarte: Aufmerksamkeitsrelevante Bereiche werden rot eingefärbt, weniger relevante Bereiche blau.
Ein Blick auf die Aufmerksamkeitskarte
kann auch hilfreich sein, um die Ergebnisse, die den anderen Auswertungstools entnommen werden können, besser zu verstehen. Wenn z.B. aus der
Wahrnehmungskarte hervorgeht, dass
ein bestimmter Bereich nicht fixiert wird,
kann man auf der Aufmerksamkeitskarte
sofort erkennen, mit welchen anderen
Bereichen er konkurriert und wo evtl.
Änderungen am Design vorgenommen
werden sollten.
http://www.goodgaze.de
2.2.2
Wahrnehmungskarte
Die Wahrnehmungskarte zeigt, welche Bereiche einer Webseite vom Benutzer in den ersten Sekunden wahrgenommen werden.
Anhand der Fixationskarte kann beurteilt werden, ob der Aufbau der Seite
für Nutzer intuitiv ersichtlich ist und ihr
Blick entsprechend gelenkt wird, oder
ob sie zwischen inhaltlich nicht zusammenhängenden Bereichen hinund herspringen.
wird. Ein hoher Wert bedeutet, dass ein
großer Teil der Seite irgendwann in den
ersten Sekunden fixiert wird, während
niedrige Werte darauf schließen lassen,
dass sich die Aufmerksamkeit eines
Besuchers auf einige wenige Bereiche
beschränkt.
Alle Karten können über einen Regler
über das Originalbild eingeblendet
werden. Die Anzeige der Fixationsvorhersage kann mit der Aufmerksamkeitskarte oder der Wahrnehmungskarte kombiniert werden.
Intro
2.2.4
Abb. 2: Die Wahrnehmungskarte: Bereiche,
die in den ersten Sekunden nicht wahrgenommen werden, sind verdunkelt dargestellt.
Die Interpretation der Wahrnehmungskarte ist sehr einfach. Transparente Bereiche werden betrachtet; alles, was im
schwarzen Bereich liegt, wird von den
meisten Nutzern übersehen. Sollten sich
wichtige Informationen außerhalb des
wahrgenommenen Teils Ihrer Webseite
befinden, sollte das Design überdacht
werden.
Statistische Maße
Zusätzlich zu grafischen Auswertungen bietet GoodGaze verschiedene
Statistiken an, die unsere Ergebnisse
in verschiedenen Werten zusammenfassen.
Zurzeit bietet der Service drei Maße
an, aber diese Liste wird sich im Lauf
der Zeit vergrößern. Im sprichwörtlichen Sinne ‚maßgeblich’ sind hierbei
auch die Ansprüche der Nutzer an den
Service.
Performance
2.2.3
Fixationsreihenfolge
Die Fixationsvorhersage zeigt die
zehn aufmerksamkeitsrelevantesten
Punkte in abfallender Reihenfolge. Der
Einstiegspunkt ist hierbei durch einen
Kreis markiert, spätere Fixationen erhalten ein Kreuz.
Performance ist insbesondere für Seiten mit einer klaren und einfachen
Botschaft, die schnell übermittelt werden soll, von Bedeutung. Der Wert gibt
Auskunft darüber, wie konzentriert sich
die Aufmerksamkeit auf Ihrer Seite
verteilt. Ein hoher Performance-Wert
bedeutet, dass es einige wenige Bereiche gibt, welche die gesamte Aufmerksamkeit innerhalb der ersten Sekunden auf sich ziehen. Niedrigere
Werte bedeuten, dass sich die Aufmerksamkeit gleichmäßiger über die
Seite verteilt.
Absolute Coverage
Abb. 3: Die Fixationsreihenfolge
Absolute Coverage ermöglicht, auf
einen Blick zu sehen, wie viel der gesamten Seitenfläche innerhalb der
ersten Sekunden wahrgenommen
Intro gibt Aufschluss darüber, ob die
Seite einen klaren Einstiegspunkt hat,
der mit hoher Wahrscheinlichkeit zuerst
fixiert werden wird. Ein hoher Wert bedeutet, dass die meisten Nutzer denselben Bereich zuerst fixieren werden. In
der Fixationsvorhersage ist ersichtlich,
welcher Bereich dies ist. Ein niedriger
Intro-Wert deutet darauf hin, dass es
unsicher ist, welche der vorausgesagten
Fixationen tatsächlich die erste sein
wird.
3.0
Einsatzbereich
Quantitative Nutzeranalysen im
Eye-Tracking Bereich nehmen wochenlange Arbeit in Anspruch. Sie sind dadurch sehr kostspielig und deshalb bisher auch nur einer kleinen Klientel zugänglich. GoodGaze Analysen sind innerhalb von Sekunden verfügbar und
deutlich günstiger (und somit zugänglich
und erschwinglich für einen wesentlich
größeren Nutzerkreis). Zudem sind
GoodGaze Analysen reproduzierbar und
damit erstmalig auch objektiv vergleichbar. Weiterhin sind sie gegenüber der
manuellen Datenanalyse weniger fehleranfällig.
Diese Eigenschaften vergrößern auch
den Einsatzbereich der Technologie
gegenüber klassischen Methoden: Es
eröffnet sich sowohl die Nutzung bereits
in frühen Prototyping-Phasen als auch
die Integration in ein iteratives Entwicklungsmodell mit extrem kurzen Evaluationszyklen. Durch den Wegfall der Rohdatenanalyse ist die Technologie auch
einem drastisch erweiterten Nutzerkreis
67
zugänglich und transferiert so das Wissen um Aufmerksamkeitsphänomene in
wesentlich breitere Zielgruppen.
Weiterhin ermöglicht die Auswahl verschiedener Aufmerksamkeitsmodelle
zielgruppenrelevante Analysen.
In größeren Firmen wie Werbeagenturen
(vor allem mit Schwerpunkten im OnlineMarketing), Usability-Firmen und Unternehmensberatungen ist GoodGaze für
alle am Prozess beteiligten Personen
von Vorteil: Es können sowohl Gestalter
von Webseiten als auch Entscheider von
Projektetats von GoodGaze profitieren.
Gestalter können das Tool in ihren Arbeitsprozess einbinden, Entscheider
machen ihre Projekte besser planbar.
Beide gewinnen ein objektives Tool, um
ihre Kommunikation mit Kunden und
untereinander zu verbessern.
Weiterhin beschäftigt sich eine Vielzahl
von semi-professionellen Foren und
Blogs mit der Frage, wie die Effektivität
der eigenen Bannerwerbung weiter verbessert werden kann. Diskutiert werden
hierbei insbesondere Fragen in Bezug
auf die günstigste Platzierung und Farbgebung und Form einer Werbeanzeige –
statt sich hierbei nun aber lediglich auf
subjektive Einschätzungen zu verlassen,
bietet GoodGaze nun die Möglichkeit,
basierend auf neurowissenschaftlich
fundierten Aufmerksamkeitsvorhersagen
Verbesserungen zu implementieren.
4.0
Wissenschaftlicher Hintergrund
Der GoodGaze-Service wurde im
Labor für Neurobiopsychologie des Instituts für Kognitionswissenschaften der
Universität Osnabrück entwickelt. Dort
wird seit 2003 an menschlicher visueller
Aufmerksamkeit geforscht, indem EyeTracking Studien mit Computersimulationen des menschlichen Gehirns kombiniert werden.
Das GoodGaze-Projekt umfasst das
Design und die Durchführung von Eye-
68
Tracking Experimenten und Hintergrundbefragungen der Versuchspersonen, die kombinierte Auswertung
dieser Daten, sowie die Nutzung der
gewonnenen Ergebnisse in Form von
Aufmerksamkeitssignaturen in parametrisierbaren Simulationen zur Vorhersage von Aufmerksamkeitsprozessen. Die Implementierung der Simulation erfolgt im Labor-eigenen Softwareframework für Aufmerksamkeitsmodelle.
4.1
Aufmerksamkeitssignatur
In Eyetrackingexperimenten wurden Augenbewegungen von Versuchspersonen über visuellen Stimuli aus
verschiedenen Kategorien gemessen.
In diesen generellen Experimenten, an
denen in den letzten Jahren einige
Hundert Versuchspersonen teilgenommen haben, wurden systematisch
bestimmte Eigenschaften der gezeigten Stimuli variiert, um festzustellen,
welche Eigenschaften die Aufmerksamkeit von Versuchpersonen in welchem Ausmaß anziehen.
Zusammen mit separat erhobenen
Blickbewegungsdaten auf Webseiten
(96 studentische Versuchspersonen)
lässt sich dadurch eine für die untersuchte Gruppe charakteristische Aufmerksamkeitssignatur errechnen, die
als Basis für die Aufmerksamkeitsvorhersagen dient.
4.2
Aufgabenabhängigkeit/Demografie
Neben den rein stimulusabhängigen Einflussfaktoren werden
Aufmerksamkeitssignaturen wesentlich
von der aktuellen Aufgabe oder Zielsetzung der Versuchsperson bestimmt. Zudem spielen neben dem
Alter der Probanden möglicherweise
auch noch einige weitere demographische Aspekte eine große Rolle.
Aus diesem Grund wurden eigene EyeTracking Studien entworfen und neue
experimentelle Paradigmen für unterschiedliche Aufgabenstellungen entwickelt.
Ziel ist hier eine massive Verbreiterung
der Datenbasis um relevante demographische Gruppen. Es wurden Fragebögen entwickelt und eingesetzt, die Aufschlüsse über die sozialen Hintergründe
und Internetgewohnheiten der Versuchspersonen geben. Die anonymisierten Antworten werden strukturiert abgelegt und wiederum durch statistische
Verfahren mit den Aufmerksamkeitssignaturen verknüpft. Anhand dieser Verknüpfungen können dann später in der
Simulation online virtuelle Versuchspersonengruppen zusammengestellt werden.
5.0
Empirische Vorhersagekraft
Um die Qualität der Modelle zu evaluieren, wurden in einem weiteren Experiment GoodGaze-Vorhersagen mit empirisch gewonnenen Eye-Tracking Daten
verglichen. In Labor-internen Studien
wurden dafür 21 Versuchspersonen 90
Webseiten aus den Kategorien Nachrichtenseiten, Unternehmensseiten,
Landing Pages, Informationsseiten,
Blogs und Online-Shops gezeigt. Insgesamt wurden dabei über 61.000 Blickpunkte (Fixationen) gesammelt um ein
belastbares Verhältnis zwischen Aufmerksamkeitsverläufen und Stimuli zu
erreichen. Es folgen einige Ergebnisse
aus diesem Experiment vom Frühjahr
2008.
5.1
Salienz fixierter Punkte
Ein Punkt auf einer Webseite wird
als salient bezeichnet, wenn er viele
Fixationen auf sich zieht. Die Verteilung
der tatsächlichen Fixationen wird mit
den durch das GoodGaze-Modell berechneten Salienzwerten verglichen. Als
Kennzahl gilt hierbei die Fähigkeit, wie
zuverlässig die vorausgesagten Salienzwerte die 10% der am meisten fixierten Punkte von alle anderen fixierten
Punkten trennen3.
Um der Realität zu entsprechen, sollte
das GoodGaze Modell oft fixierten Punkte einen hohen Salienzwert und selten
fixierten Punkte einen niedrigen Salienzwert zuweisen. Abbildung 4 verdeutlicht, dass die von GoodGaze berechneten Salienzwerte stark mit den
tatsächlich fixierten Punkten korrelieren.
Die Skala ist so normiert, dass 1 eine
perfekte Trennung darstellt (nur oft fixierte Punkte bekommen einen hohen
Salienzwert). Ein Wert von 0,5 bedeutet
hierbei, dass sich oft fixierte Punkte
nicht von selten fixierten Punkten trennen lassen (dies entspricht zufälliger
Zuweisung von Salienzwerten), während
ein Wert von 0 anzeigt, dass selten fixierte Punkte fälschlicherweise einen
hohen, oft fixierte Punkte einen niedrigen Salienzwert erhalten.
Abb. 4: Voraussagefähigkeit des GoodGaze
Modells in der Free-Viewing Task
Im Mittel liegt die Voraussagekraft bei
einem Wert von 0,8 – d. h. dass GoodGaze mit 80% Wahrscheinlichkeit einen
zufällig ausgewählten fixierten Punkt von
einem zufällig ausgewählten nicht fixier-
3
Es wurde hier die Fläche berechnet, unter
der die Receiver-Operator-Characteristics
(ROC) - Kurve die Salienzwerte im obersten 10er-Perzentil der empirischen Fixationsdichtekarte von allen anderen Salienzwerten trennt.
ten Punkt unterscheiden kann. Zwar
reichen die Whisker4 im Plot teilweise
unter die 60% Schwelle, doch zeigen
die Whisker nur milde Ausreißer an.
Das Gros der vorhergesagten Werte
(75%, blaues Rechteck + oberer Teil
der Whisker) liegt konstant über der
70% - Marke. In den Kategorien Landing Pages und Unternehmensseiten
überschreitet GoodGaze die 80% Marke sogar deutlich.
5.2
Fixationsflächen
Eine Fixation hat zwar im Prinzip
eine genaue X/Y Koordinate - aber der
Anspruch, diese ganz genau vorherzusagen, wäre fehlgeleitet. Ein Objekt
wird vom menschlichen Auge immer
so fixiert, dass sein Abbild genau in
der Fovea Centralis liegt, um die
höchste Auflösung zu erreichen. In
diesem Bereich der Netzhaut befinden
sich die meisten Zapfen. Doch auch in
der Peripherie der Fovea, dem gelben
Fleck, ist die Zapfendichte noch sehr
hoch. Ein Betrachter nimmt also eine
bestimmte Fläche um eine Fixation
herum aktiv wahr.
In der Wahrnehmungskarte markiert
GoodGaze Flächen, die mit hoher
Wahrscheinlichkeit durch die ersten
Fixationen abgedeckt werden. Dementsprechend sollten in diesem Evaluationsexperiment möglichst viele Probanden die von GoodGaze markierten
Flächen auch tatsächlich fixiert haben.
Ausgehend davon wurde untersucht,
welches Verhältnis zwischen von
GoodGaze markierten Bereichen und
tatsächlichen Fixationen besteht. Hierbei ist es wünschenswert, mit möglichst wenig markierter Fläche möglichst viele tatsächliche Fixationen
4
vorauszusagen. Die Ergebnisse verdeutlicht Abbildung 5. Auf der X-Achse ist die
markierte Fläche notiert, während die YAchse den Anteil an vorausgesagten
Fixationen zeigt. Rein zufällige Voraussagen würden sich entlang der blauen
Linie befinden. Die gefetteten Kreuze
zeigen die Mediane einer Kategorie an.
Abb. 5: Verhältnis von markierter Fläche zu
gemessenen Fixationen aufgrund der GoodGaze Vorhersage.
Daraus folgt, dass GoodGaze derzeit im
Mittel mit 50-60% markierter Fläche ~7580% der Fixationen abdecken kann.
Dies allein ist ein wenig sinnvolles Maß,
ohne zu kontrollieren, wie gut diese Vorhersage denn überhaupt werden könnte.
Schließlich kann die Varianz angeschauter Punkte zwischen Probanden relativ
hoch sein. Deshalb ist sogar für jemanden, der alle Fixationen kennt, eine gewisse Fläche unbedingt nötig, um x Prozent aller Fixationen abzudecken.
Daraus ergibt sich eine obere Machbarkeitsgrenze für eine solche Vorhersage.
Abbildung 6 zeigt dasselbe Verhältnis,
wenn man tatsächliche Aufmerksamkeitskarten zugrunde legt.
In Boxplots werden die vertikalen Linien
als „Whisker“ bezeichnet. Die Länge
der Whisker beträgt maximal das 1,5fache des Interquartilsabstands
(1,5×IQR).
69
durch Eye-Tracking Daten gewonnene
Heatmap.
6.0
Abb. 6: Verhältnis von markierter Fläche zu
tatsächlichen Fixationen aufgrund empirischer Aufmerksamkeitskarten.
Hierbei zeigt sich, dass GoodGaze im
Mittel in den Kategorien Landing Pages,
Unternehmensseiten und Onlineshops
genauso gut abschneidet wie eine direkt
70
Zusammenfassung
In diesem Paper wurde der vom
Labor für Neurobiopsychologie der
Universität Osnabrück entwickelte
Webservice GoodGaze vorgestellt.
GoodGaze analysiert Webseiten innerhalb von Sekunden auf deren Aufmerksamkeitswirkung und erzielt damit
für bestimmte Seitentypen (Landing
Pages, Firmenseiten und OnlineShops) Ergebnisse, die mit denen
klassischer apparativer Methoden wie
dem Eye-Tracking vergleichbar sind.
Als Prozessinnovation könnte sich
GoodGaze damit insbesondere im
Bereich quantitativer Usability-Studien
etablieren, indem Daten zur Aufmerksamkeitswirkung einer Webseite schnell
und vor allem bereits in frühestens Entwurfsphasen nahezu aufwandslos erhoben werden können. Vorliegendes Paper beinhaltet neben einer Einführung zu
den wichtigsten Funktionen der GoodGaze-Webseite weiterhin einige Erläuterungen zum wissenschaftlichen Hintergrund, den Evaluationsergebnissen und
der diesen zugrundeliegenden Methodik.
7.0
Nielsen, J. (2006): Quantitative Studies: How
Many Users to Test? In: Alertbox 26. Juni,
2006:
www.useit.com/alertbox/quantitative_testing.h
tm
Jen seits von Us a b i l i t y
71
72
Jenseits von Usability: Website-Ästhetik
Meinald T. Thielsch
Universität Münster
Psychologisches Institut 1
Fliednerstr. 21
48149 Münster
[email protected]
http://www.meinald.de
Abstract
Lange Zeit stand Usability im Fokus der
Forschung zur Wahrnehmung und Nutzung von Websites. Heutzutage werden
neben Usability zunehmend emotionale
Konstrukte diskutiert (Hassenzahl,
2008). Das gerade Ästhetik eine besondere Bedeutung haben könnte, zeigen
verschiedene Autoren (z. B. Tarasewich,
2001; Thielsch, in Druck; Tractinsky &
Hassenzahl, 2005). Dieser Beitrag gibt
einen Überblick zum aktuellen Forschungsstand der Website-Ästhetik.
1.0
Einleitung
Beim Surfen durch das World Wide Web
besuchen Webnutzer viele verschiedene
Websites. Die Wahrnehmung dieser
Seiten ist dabei zum einen durch den
Inhalt bestimmt, der sicherlich die zentrale Rolle einnimmt (siehe Thielsch, in
Druck). Auch die Usability der besuchten
Websites ist wichtig, um ein entspanntes
und möglichst störungsfreies Handeln im
Web zu ermöglichen. Diese beiden Aspekte alleine reichen aber nicht aus, um
das Surfverhalten und -erleben eines
Webnutzers zu erklären. In den letzten
Jahren werden daher zunehmend
Neben Definition, Nutzen und Erfassung von Ästhetik werden hier die verschiedenen Ansätze (mathematische,
deskriptive und experimentelle) dargestellt. Ebenso wird der Zusammenhang zwischen Ästhetik und anderen
Konstrukten wie Usability und Inhalt,
sowie die Beziehung zu Persönlichkeitsmerkmalen thematisiert. Abschließend erfolgt eine thesenartige
Zusammenfassung des vorhandenen
Wissenstands.
Keywords
Konstrukte jenseits der Usability erforscht. Hinzu kommen somit weitere
Aspekte, die vor allem durch die designerische Gestaltung einer Website
bestimmt sind. Diese eher emotionalen
Anteile des Weberlebens werden oft
unter dem Begriff der „Ästhetik“ gefasst.
2.0
Die Wahrnehmung von Inhalt, Usability
und Ästhetik kann von weiteren Faktoren beeinflusst sein, wie z. B. Persönlichkeitseigenschaften des Betrachters
oder Kontextvariablen wie z. B. die
genutzte Hard- oder Software (siehe
Abbildung 1).
Abb 1: Zentrale Variablen der Website-Wahrnehmung (aus Thielsch, 2008)
Ästhetik, Webästhetik, Website-Ästhetik,
Usability, Website
Was ist Website-Ästhetik?
Die Frage nach der inhaltlichen Definition von Ästhetik ist nicht so leicht zu
beantworten. Zwar findet sich eine Fülle
von Arbeiten zur Ästhetik in den verschiedensten Wissenschaften und entsprechend vielfältig erscheinen die Zugänge zu einer Website-Ästhetik, nur
wenige Forscher definieren aber klar
das von Ihnen beforschte Konstrukt.
Konsens scheint lediglich dahingehend
zu bestehen, Ästhetik über subjektive
Wahrnehmungen und Einschätzungen
der Nutzer zu definieren, oftmals im Sinne visueller Schönheit. Zwar beschränkt
sich die Ästhetik von Websites nicht
unbedingt auf eine Sinnesmodalität,
theoretisch bezieht sich diese auf alle
Sinne. Im Moment ist aber vor allem die
visuelle Wahrnehmung von Websites
bedeutsam, da die anderen Sinneskanäle zumeist (noch) nicht intensiv angesprochen werden.
Einen guten Überblick über diese Annahmen liefern Tractinsky und Lowengart (2007), ihre Übersicht zur
73
chend werden bei der Bewertung von
Ästhetik zumeist die subjektiven Wahrnehmungen und Urteile der Nutzer erfasst. Hierbei ergeben sich drei Vorgehensweisen (für eine detaillierte Übersicht siehe Thielsch, 2008, S. 53 ff.):
1.
2.
3.
Abb. 2: Die inhaltliche Bedeutung von „Ästhetik“ nach Tractinsky und Lowengart (2007).
Die in der HCI behandelte Form der Ästhetik folgt dabei dem rechten Pfad.
inhaltlichen Bedeutung von Ästhetik ist
in Abbildung 2 dargestellt. Definitionen
von Ästhetik im HCI-Bereich (siehe Hassenzahl, 2008; Thielsch, 2008) umfassen die Annahme, dass subjektiv empfundenes Wohlgefallen durch affektive
und kognitive Prozesse bestimmt wird,
die von Gestaltungseigenschaften eines
Objektes ausgelöst werden.
Was jedoch genau die ÄsthetikWahrnehmungen, in welcher Form beeinflusst, ist weitgehend unklar. Zwar
können hierzu kognitive Modelle aus der
experimentellen Ästhetik entlehnt werden (z. B. das Modell von Leder et al.,
2004), die determinierenden Variablen
einer Website-Ästhetik sind aber wenig
untersucht (siehe auch nachfolgender
Punkt 5.). Dies bedarf dringend weiterer
Diskussion und Forschung.
3.0
Warum überhaupt Ästhetik?
Antworten auf die Frage warum Ästhetik für die Gestaltung von Produkten
oder GUI’s wichtig sein sollte, werden
meist theoretisch abgeleitet (siehe z. B.
Tractinsky & Hassenzahl, 2005). Es
finden sich eine Reihe überzeugender
Argumente in denen beispielsweise dargestellt wird, inwieweit Ästhetik als
menschliches Grundbedürfnis anzusehen ist und ästhetische Objekte zur
74
Selbstdefinition dienen. Überzeugend
auch die Argumentation von Bloch et
al. (2003), dass in vollen Märkten mit
ähnlich funktionalen Produkten Ästhetik zum entscheidenden Merkmal werden kann. Norman (2004) geht sogar
soweit und sagt „Attractive things work
better“.
Es finden sich zudem empirische Arbeiten zur Bedeutung der Ästhetik (z.
B. Tarasewich et al., 2001, zur Übersicht Hassenzahl, 2008). Thielsch (in
Druck) zeigt, dass Ästhetik eine gewisse Relevanz für Webuser hat und
sich sehr hohe Korrelationen zwischen
Ästhetik-Einschätzung und der Gesamtbewertung einer Website finden.
Bei der ersten Variante ergeben sich
offensichtlich Probleme der Messgenauigkeit (Reliabilität); diese verbessert sich
deutlich beim Einsatz von Skalen oder
standardisierten Fragebogeninstrumenten (siehe Schmidt & Hunter, 1996, insbesondere S. 202f.). Besonderes Augenmerk muss jedoch bei der metrischen Erfassung von Website-Ästhetik
in Zukunft auf die Bestimmung der Validität gelegt werden, hier finden sich bisher nur wenige Ansätze.
Weitere Verfahren und klassische Methoden wie z. B. Paarvergleich, Cognitive Walkthrough oder ChecklistenEvaluationen sind bisher nur an wenigen
Stellen in der Forschung dokumentiert
und wahrscheinlich seltener im Einsatz.
5.0
4.0
Wie kann man Webästhetik erfassen?
Zur Erfassung von UsabilityBewertungen finden sich eine Reihe
von etablierten Methoden (zur Übersicht siehe Gediga & Hamborg, 2002),
hierbei ist eine Trennung zwischen
objektiven Merkmalen eines Interfaces
und subjektiven Eindrücken gut umsetzbar. Letzteres fällt in der Forschung zur Webästhetik schwer: Die
Erkenntnisse zu determinierenden
Variablen sind bisher nicht ausreichend um objektive Messmethoden
aus diesen abzuleiten. Dementspre-
Einschätzung der Ästhetik über einzelne Fragen,
Einschätzung der Ästhetik über Fragebogenskalen,
Einschätzung der Ästhetik über
standardisierte Fragebogeninstrumente.
Aktuelle Forschung zur Ästhetik
von Websites
Lässt man die Vielzahl der Arbeiten
zum Verhältnis von Website-Ästhetik
und anderen Konstrukten (insbesondere
Usability) zunächst außen vor, so können die verbliebenen Forschungen grob
in drei Richtungen eingeteilt werden:
Mathematische, deskriptive und experimentelle Ansätze.
5.1
Mathematische Ansätze
In Informatik und Mathematik findet
sich seit langem ein Forschungsinteresse bezüglich der Ästhetik (siehe z. B.
Fishwick, 2006, Kap. 12-17). Mehrere
Forscher versuchen die Ästhetik eines
GUI’s in mathematischen Formeln auszudrücken, erstmalig findet sich diese
Idee bezüglich Websites bei Ngo et al.
(2000). Diese leiten Formeln auf Basis
von Regeln aus der Gestaltpsychologie
ab. Die empirische Prüfung fällt jedoch
eher knapp aus, vor allem experimentelle Belege zur Korrektheit der postulierten Formeln fehlen. Die mathematischen
Ansätze sind zwar grundsätzlich interessant, scheinen aber noch weit von ihrem
letztendlichen Ziel, einer Formel für ein
automatisch erstellte ästhetische Website, entfernt.
5.2
Deskriptive Ansätze
Eine Reihe von Autoren versucht
über deskriptive Zugänge die Ästhetik
von Websites zu beschreiben. Es finden
sich erfahrungsbasierte Ansätze, in denen Wissen über gute Gestaltung in
Checklisten überführt wird (z. B. Sutcliffe, 2001). Seltener werden DesignExperten direkt zu einer Beschreibung
von Webästhetik herangezogen (siehe
z. B. Kim et al., 2003). Auch empirischqualitative Arbeiten sind rar, bisher liegen nur zwei derartige Studien vor
(Lindgaard & Dudek, 2003; Thielsch,
2008). In beiden Arbeiten ist Ästhetik ein
substanzieller Teil der Wahrnehmung
der Nutzer. Thielsch (2008, S. 165 ff.)
betont die große Diversität und Differenziertheit der qualitativen Äußerungen der
in seiner Arbeit befragten Webnutzer.
Zentrale Ästhetik-Aspekte sind hier
Farb-, Bild- und Schriftgestaltung.
Zu teilweise ähnlichen Dimensionen wie
die qualitativen Arbeiten kommen auch
empirisch-deskriptive Studien (z. B.
Schenkman & Jönsson, 2000; Moshagen & Thielsch, 2005) bei denen Befragungsdaten von Webnutzern ausgewertet werden. Insgesamt ist jedoch Webästhetik über einen rein deskriptiven Zugang schwer fassbar, zur näheren Eingrenzung des Konstrukts sind experi-
mentelle Untersuchungen besser geeignet.
5.3
Experimentelle Ansätze
Die bisherigen experimentellen
Untersuchungen zur Website-Ästhetik
lassen sich in zwei Gruppen teilen. Auf
der einen Seite finden sich Experimente zum Einfluss der Betrachtungsdauer
auf die wahrgenommene Ästhetik (z.
B. Lindgaard et al., 2006; Tractinsky et
al., 2006). In diesen Arbeiten werden
Screenshots von Websites sehr kurz
dargeboten (50 ms), es finden sich
hohe Korrelationen zu Versuchsbedingungen mit längerer Darbietungszeit
(500 ms oder 10 s). Die Autoren
schließen hieraus auf eine schnelle
Bildung und hohe Stabilität des ästhetischen Urteils.
Eine zweite Gruppe von Experimenten
befasst sich mit der konkreten Gestaltung einer Website (z. B. Haig, 2002;
Thielsch, 2008). Hierbei zeigt sich zum
einen die Bevorzugung von Websites
mit umfangreichen Designelementen
wie Animation, Bilder und Sound
(Haig, 2002), zum anderen können
signifikante Effekte der Farbgestaltung
auf ästhetische Urteile in einem mittleren Effektgrößenbereich gezeigt werden (Thielsch, 2008). In letzterer Arbeit
finden sich auch empirische Hinweise
zur Wirkung von Bild- und (in geringerer Intensität) Schriftgestaltung auf die
ästhetische Bewertung einer Website.
6.0
Website-Ästhetik und andere
Konstrukte
6.1
Ästhetik und Inhalt
Insgesamt existieren nur wenige
Arbeiten zum Zusammenhang von
Ästhetik und Inhalt. Einige Autoren
berichten schwach negative Korrelationen (z. B. De Angeli et al., 2006;
Tractinsky et al., 2000), an anderer
Stelle finden sich positive Korrelatio-
nen (Aladwani & Palvia, 2002; Thielsch,
2008). In einem Experiment mit N = 364
Befragten findet Thielsch (2008) keinen
Einfluss von ästhetischen Manipulationen einer Website auf die Inhaltsbewertung.
Interessant und wert weiterzuverfolgen
sind die Ergebnisse von Sutcliffe und De
Angeli (2005), die eine schlechtere Erinnerungsleistung bezüglich inhaltlicher
Aspekte bei der Nutzung einer ästhetischen im Vergleich zu einer wenig ästhetischen Website finden. Leider wurde
dieses Experiment mit nur N = 25 Probanden durchgeführt, eine Replikation
ist dringend wünschenswert.
6.2
Ästhetik und Usability
Die Frage nach dem Verhältnis von
Gestaltung und Funktionalität ist so alt
wie die experimentelle Ästhetik selbst;
bereits ihr Begründer Gustav Theodor
Fechner diskutiert dieses ausgiebig
(Fechner, 1876). Ausgehend von den
ersten Arbeiten von Kurosu und Kashimura (1995) und Tractinsky (1997) findet sich auch im HCI-Bereich eine Vielzahl von Studien, in denen fast ausschließlich positive Korrelationen zwischen beiden Konstrukten berichtet
werden (für eine Übersicht siehe
Thielsch, 2008, S. 60 ff.).
Es gibt bisher jedoch nur zwei Experimente die explizit das Verhältnis von
Website-Ästhetik und Usability behandeln (Moshagen et al., in preparation;
Thielsch, 2008). In beiden zeigt sich
keine Beeinflussung der wahrgenommenen Usability durch ÄsthetikVariationen. Dies spricht eher gegen
den oft vermuteten Halo-Effekts des
einen Konstrukts auf das andere oder
der Wirkung eines Attraktivitätsstereotyps bei der Website-Wahrnehmung.
Für die gefundenen hohen Zusammenhänge zwischen Ästhetik und Usability
müssen neben einem möglichen Common-Method-Bias (Podsakoff et al.,
75
2003) weitere Erklärungen gefunden
werden. Anzunehmen sind beispielsweise bisher nicht untersuchte Gestaltungsvariablen, die auf beide Konstrukte einen Einfluss haben. Vielversprechend
wären hier Forschungsmethoden die
sich am Multitrait-Multimethod-Ansatz
(Cambell & Fiske, 1959) orientieren, um
mögliche Wirkungen eines CommonMethod-Bias zu eliminieren.
6.3
Ästhetik und Persönlichkeit
Oftmals wird gesagt Schönheit läge
im Auge des Betrachters – dementsprechend starke Zusammenhänge zwischen ästhetischen Urteilen und Persönlichkeitsmerkmalen werden erwartet.
Empirisch beinhalten neuere Arbeiten
hierzu kaum Hinweise. In einzelnen Studien findet sich ein Effekt der Expertise
bezüglich Webdesign (Haig, 2002;
Hartmann et al., 2007), in anderen Untersuchungen tritt dieser Effekt nicht auf
(Moshagen et al., in preparation;
Thielsch, 2008).
Thielsch (2008) betrachtet eine ganze
Reihe von Persönlichkeitsmerkmalen,
neben demographischen Eigenschaften
beispielsweise auch die Big Five. Er
findet signifikante Zusammenhänge in
einer relevanten Effektgröße nur bei
einer Variable: Die Probanden in dieser
Untersuchung beurteilen die Ästhetik
einer Website mit zunehmendem Alter
etwas positiver. Hier zeigt sich eine Mildetendenz in mittlerer Effektgröße, die
Stichprobe (N = 362) war bezüglich des
Alters repräsentativ geschichtet und
reichte von 14 bis 81 Jahren.
7.0
Zusammenfassender Überblick
Was kann im Moment zur WebsiteÄsthetik gesagt werden? Abschließend
soll ein zusammenfassender Überblick
gegeben werden, wobei einige der nachfolgenden Punkte in der Forschung eher
postuliert als empirisch belegt werden:
76
1. Der wichtigste Aspekt für den Nutzer stellt der Inhalt einer Website
dar, Ästhetik ist aber dennoch bedeutsam (Tarasewich et al., 2001;
Thielsch, in Druck).
2. Abgesehen vom Inhalt ergibt sich
die visuelle Attraktivität einer Website aus der Nutzer-Wahrnehmung
von Ästhetik und Usability (van der
Heijden, 2003). Beide Konstrukte
stehen in einer Beziehung zueinander; der genaue Zusammenhang
ist empirisch noch nicht geklärt.
3. Ästhetik kann empirisch erfasst
werden.
4. Webnutzer nehmen Ästhetik differenziert wahr, die Nutzer besitzen
die Fähigkeit, ihre WebsiteWahrnehmung adäquat einzuschätzen und zu verbalisieren
(Lindgaard & Dudek, 2003;
Thielsch, 2008). Die ästhetische
Wahrnehmung ist subjektiv, aber
statistisch über verschiedene Nutzer hinweg vergleichbar.
5. Um wahrgenommen zu werden,
müssen ästhetische Reize in ihrer
Intensität eine gewisse Schwelle
überschreiten. Die Wahrnehmung
dieser Reize kann sowohl bewusst
als auch vorbewusst oder unbewusst erfolgen (Leder et al., 2004).
6. Entsprechend dem Assoziationsprinzip können Erinnerungen in
Form von Top-down-Prozessen zu
ästhetischen Wahrnehmungen beitragen (Fechner, 1876; Leder et al.,
2004; Norman, 2004).
7. Das ästhetische Urteil erfolgt unmittelbar (Leder et al., 2004). Diese
sehr schnell getroffenen ÄsthetikEinschätzungen sind möglicherweise stabil (siehe Punkt 5.3). Ästhetik hat folglich besondere Bedeutung für den Ersteindruck und
kann womöglich als Alleinstellungsmerkmal dienen, letztere Annahme muss allerdings noch
empirisch überprüft werden.
8. Die Ästhetik beeinflusst die Präferenz der Nutzer für eine Website
(Schenkman & Jönsson, 2000; van
der Heijden, 2003); auch zu dieser
Annahme gibt es bisher keinen experimentellen Nachweis.
9. Die ästhetische Wirkung einer Website setzt sich aus mehreren Variablen zusammen; das Konstrukt ist
wahrscheinlich als mehrdimensional
zu betrachten (Lavie & Tractinsky,
2004; Moshagen, 2005). Bei Websites von Unternehmen und Institutionen hat die Farbgestaltung eine besondere Bedeutung.
10. Die Wahrnehmung von WebsiteÄsthetik scheint durch Personenvariablen eher unbeeinflusst, das Alter
spielt aber eine Rolle im Sinne einer
Mildetendenz mit steigendem Alter
(Thielsch, 2008).
Mit dieser Zusammenfassung des Forschungsstands zur Website-Ästhetik
wird klar: Es gibt viel zu tun! Wenig ist
bisher bekannt zu den determinierenden
Variablen und dem Zusammenhang
zwischen den verschiedenen Konstrukten. Auf der anderen Seite zeigt sich
Webästhetik als ein lebhaftes und vielversprechendes Forschungsfeld, in dem
bereits gute Grundlagen gelegt sind.
8.0
Aladwani, A. M., & Palvia, P. C. (2002): Developing and validating an instrument for
measuring user-perceived web quality. Information & Management, 39(6), 467-476.
Bloch, P. H., Brunel, F. F., & Arnold, T. J.
(2003): Individual differences in the centrality
of visual product aesthetics: Concept and
measurement. Journal of Consumer Research, 29, 551 - 565.
Campbell, D. T., & Fiske, D. W. (1959): Convergent and discriminant validation by the
multitrait-multimethod matrix. Psychological
Bulletin, 56(2), 81-105.
De Angeli, A., Sutcliffe, A., & Hartmann, J.
(2006): Interaction, usability and aesthetics:
What influences users' preferences. In Pro
ceedings of the 6th ACM conference on designing interactive systems (pp. 271-280).
New York: ACM Press.
Fechner, G. T. (1876): Vorschule der Ästhetik. Leipzig: Breitkopf & Härtel.
Fishwick, P. (2006): Aesthetic computing.
Cambridge: MIT Press.
Gediga, G., & Hamborg, K.-C. (2002): Evaluation in der Software Ergonomie: Methoden
und Modelle im Software-Entwicklungsprozess. Zeitschrift für Psychologie, 210(1),
40-57.
Haig, A. (2002): The design & aesthetic performance of web sites. Unpublished master‘s
thesis, Swinburne University of Technology.
Hassenzahl, M. (2008): Aesthetics in interactive products: Correlates and consequences
of beauty. In H. N. J. Schifferstein & P. Hekkert (Eds.): Product experience. Amsterdam:
Elsevier, S. 287-302.
Hartmann, J., Sutcliffe, A., & De Angeli, A.
(2007): Investigating attractiveness in web
user interfaces. In Chi2007 proceedings of
the sigchi conference on human factors in
computing systems (pp. 387-396). New York:
ACM Press.
Kim, J., Lee, J., & Choi, D. (2003): Designing
emotionally evocative homepages: An empirical study of the quantitative relations between
design factors and emotional dimensions.
International Journal of Human-Computer
Studies, 59, 899-940.
Kurosu, M., & Kashimura, K. (1995): Apparent usability vs. Inherent usability: Experimental analysis on the determinants of the apparent usability. In Conference companion on
human factors in computing systems (pp.
292-293). New York: ACM Press.
Lavie, T., & Tractinsky, N. (2004): Assessing
dimensions of perceived visual aesthetics of
web sites. International Journal of Human Computer Studies, 60, 269 - 298.
Leder, H., Belke, B., Oeberst, A., & Augustin,
D. (2004): A model of aesthetic appreciation
and aesthetic judgements. British Journal of
Psychology, 95, 489-508.
Lindgaard, G., & Dudek, C. (2003): What is
this evasive beast we call user satisfaction?
Interacting with Computers, 15, 429-452.
Lindgaard, G., Fernandes, G., Dudek, C. &
Browñ, J. (2006): Attention web designers:
You have 50 milliseconds to make a good
first impression! Behaviour & Information
Technology, 25, 2, 115-126.
Moshagen, M. F. (2005): Konstruktion eines
Instrumentes zur Erfassung der visuellen
Ästhetik von Webseiten. Unveröffentlichte
Diplomarbeit, Westfälische WilhelmUniversität Münster.
Moshagen, M., Musch, J., & Göritz, A. S. (in
preparation): When aesthetics fosters performance: Experimental evidence for beneficial effects of visual aesthetics on performance.
Moshagen, M. F. & Thielsch, M. T. (2005):
Aspects underlying the aesthetic quality of
websites. 7th General Online Research
(GOR05). Zurich, Switzerland.
Ngo, D. C. L., & Teo, L. S. (2000): A mathematical theory of interface aesthetics.
Visual mathematics, 2 (4).
Norman, D. A. (2004): Emotional design:
Why we love (or hate) everyday things.
New York, USA: Basic Books.
Podsakoff, P. M., MacKenzie, S. B., Lee, J.
Y., & Podsakoff, N. P. (2003): Common
method biases in behavioral research: A
critical review of the literature and recommended remedies. Journal of Applied Psychology, 88(5), 879-903.
Schenkman, B. N., & Jönsson, F. U. (2000):
Aesthetics and preferences of web pages.
Behaviour & Information Technology, 19(5),
367-377.
Schmidt, F. L., & Hunter, J. E. (1996): Measurement error in psychological research:
Lessons from 26 research scenarios. Psychological Methods, 1(2), 199-223.
Sutcliffe, A. (2001): Heuristic evaluation of
website attractiveness and usability. In C.
W. Johnson (Ed.), Proceedings: 8th workshop on design, specification and verification of interactive systems (pp. 188-199).
Berlin: Springer.
interaction - interact 2005 (pp. 405-417). Berlin: Springer.
Tarasewich, P., Daniel, H. Z. & Griffin, H. E.
(2001): Aesthetics and web site design. Quarterly Journal of Electronic Commerce, 2(1),
67-81.
Thielsch, M. T. (2008): Ästhetik von Websites: Wahrnehmung von Ästhetik und deren
Beziehung zu Inhalt, Usability und Persönlichkeitsmerkmalen. Münster: MV Wissenschaft.
Thielsch, M. T. (in Druck): Inhalt, Usability
und Ästhetik in der Bewertung durch Webnutzer. Mensch & Computer 2008. München:
Oldenbourg
Tractinsky, N. (1997): Aesthetics and apparent usability: Empirically assessing cultural
and methodological issues. In S. Pemberton
(Ed.), Proceedings of the SIGCHI conference
on human factors in computing systems (pp.
115-122). New York: ACM Press.
Tractinsky, N., Cokhavi, A., Kirschenbaum,
M. & Sharfi, T. (2006): Evaluating the consistency of immediate aesthetic perceptions of
web pages. International Journal of Human Computer Studies, 64(11), 1071-1083.
Tractinsky, N. & Hassenzahl, M. (2005): Arguing for aesthetics in human-computer interaction. i-com, 3/2005, 66-68.
Tractinsky, N., Katz, A. S., & Ikar, D. (2000):
What is beautiful is usable. Interacting with
Computers, 13(2), 127-145.
Tractinsky, N., & Lowengart, O. (2007): Webstore aesthetics in e- retailing: A conceptual
framework and some theoretical implications.
Academy of Marketing Science Review [Online-Journal], 11(1).
Van der Heijden, H. (2003): Factors influencing the usage of websites: The case of a
generic portal in the netherlands. Information
& Management, 40, 541-549.
Sutcliffe, A., & De Angeli, A. (2005): Assessing interaction styles in web user interfaces. In M. F. Costabile & F. Paternò
(Eds.), Proceedings of human computer
77
Der User Experience (UX) auf der Spur: Zum Einsatz von
www.attrakdiff.de
Marc Hassenzahl
Fortstraße 7
76829 Landau
www.marc-hassenzahl.de
Michael Burmester
Hochschule der Medien
Informationsdesign
Wolframstraße 32
70191 Stuttgart
[email protected]
Franz Koller
Martin-Luther-Straße 57-59
71636 Ludwigsburg,
[email protected]
Abstract
User Experience (UX), das positive Nutzer- oder besser Nutzungserleben, stellt
eine deutliche Erweiterung und Veränderung des klassischen usability-Begriffs
dar. UX betont ganz besonders die
ganzheitliche Sicht auf subjektiv erlebte
Produktqualität. Das semantische Differenzial AttrakDiff2 bietet die Möglichkeit,
1.0
Einleitung
Langsam aber sicher wird der Begriff usability durch User Experience (UX,
Nutzererleben oder besser Nutzungserleben) ersetzt. Eingeführt von Don
Norman und Kollegen (1995) um die
Arbeit der Human Interface-Gruppe bei
Apple zu beschreiben, findet sich 2008
kaum ein größeres Unternehmen mehr
ohne UX-Spezialisten – von Microsoft,
über SAP bis Sun und Siemens.
Selbst die Standardisierung im Bereich
usability hat sich diesem Thema angenommen – einem Thema, dass noch vor
einiger Zeit wie eine Provokation wirkte
und dem eigentlichen Ansatz unter Umständen sogar zuwider läuft (Meyer,
2007). Der aktuelle Entwurf der ISO CD
9241-210 (die Nachfolgenorm der ISO
13407 zur benutzerzentrierten Gestaltung) definiert UX als "all aspects of the
user’s experience when interacting with
the product, service, environment or
facility. […] It includes all aspects of usability and desirability of a product, system or service from the user’s perspective" (Stewart, 2008).
78
UX-relevante Produktwahrnehmungen
und Bewertungen zu erfassen. Es ist
als Forschungs- und Evaluationsinstrument über www.attrakdiff.de frei
nutzbar. Dort können Beurteilungsprojekte geplant, durchgeführt und automatisch ausgewertet werden. Der vorliegende Beitrag führt kurz in das
Themenfeld UX ein, präsentiert das AttrakDiff2, die Möglichkeiten von
www.attrakdiff.de und zukünftige Entwicklungen.
In dieser etwas hilflos wirkenden Definition werden usability und ein neues
Konzept, die desirability getrennt aufgeführt. Dies impliziert, dass usability
allein ein Produkt nicht begehrenswert
macht. Eine ähnliche Annahme zeigt
sich auch in der Erklärung von Nokia
(2005): "[mobility] is about the delivery
of personalized experiences, which
add value and pleasure to daily lives".
Das UX-Team von OpenOffice.org
nennt als ihre Gestaltungsziele "usability, productivity and enjoyment"
(http://ux.openoffice.org/). Auch hier ist
usability nur ein Ziel unter dreien.
in der Industrie und unter Praktikern
meinen lässt. Zwar gibt es ein Reihe
unterschiedlicher Ansätze (siehe Hassenzahl & Tractinsky, 2006; Schifferstein
& Hekkert, 2008), aber alle betonen
mindesten eine der folgenden drei Charakteristiken von UX.
Bislang sind es aber nur wenige Unternehmen und Personen, die UX als
eine Art usability plus verstehen. In
vielen Fällen, wie z.B. bei SAP, aber
auch in vielen industriellen Forschungsarbeiten, wird UX immer noch
gleichbedeutend mit usability bzw.
user-centred design verstanden.
x
2.0
Das UX-Programm
Interessanterweise ist die akademische Diskussion zu UX deutlich weiter fortgeschritten, als die Unsicherheit
Keywords
User Experience, Hedonische Qualität,
Attraktivität, Evaluation, Fragebogen
x
Ganzheitlich: Usability konzentriert
sich auf die Aufgaben der Benutzer.
UX nimmt eine breitere Sicht ein.
UX sucht nach der Balance zwischen instrumentellen und nichtinstrumentellen Qualitäten, wie
Schönheit, Neuartigkeit, Herausforderung oder Selbstausdruck.
Subjektiv: Mit seinen Ursprüngen in
der Arbeitswissenschaft und psychologie legt usability Wert auf
Objektivität. Das Betonen der Beobachtung beim Testen von usability
oder der Einsatz von eye tracking
zeigt den Wunsch, von den "Meinungen" der Benutzer unabhängig
zu sein. UX hingegen betont gerade
die Subjektivität, das heißt die
wahrgenommene Qualität eines
Produktes. Ein Grund dafür ist, dass
die Qualitätswahrnehmung – egal
x
ob "richtig" oder "falsch" – sowohl
die zukünftige Nutzung als auch die
Kommunikation über das Produkt
bestimmt.
Positiv: Usability fokussiert auf das
Reduzieren von Stress und dem
Beseitigen von Barrieren. Im "Leitfaden Usability" (DATech, 2008)
beispielsweise findet sich 83 Mal
das Wort "Mängel" und 205 Mal das
Wort "Problem" (auf wohlgemerkt
insgesamt 239 Seiten). Begriffe wie
Freude, Spaß, Attraktivität, Herausforderung oder Schönheit erwähnt
der Leitfaden nicht.
Natürlich ist und bleibt das Vermeiden
und Beheben von Nutzungsproblemen
eine wichtige Aufgabe der Technikgestaltung. Den Fokus aber ausschließlich
auf das Beseitigen des Negativen zu
legen, greift aus UX-Perspektive zu
kurz. Vielmehr kann man in Anlehnung
an Herzberg und Kollegen (1959) von
einer Zwei-Faktoren-Theorie der Zufriedenheit ausgehen: Das Fehlen von usability führt zwar zur Unzufriedenheit,
aber ihre Anwesenheit nicht zur Zufriedenheit, sondern nur zu einem neutralen
Zustand. Der Übergang zur Zufriedenheit wird durch andere Aspekte hervorgerufen. Diese "Motivatoren" explizit zu
benennen und ihr Zusammenspiel mit
usability zu erforschen, ist ein wichtiges
Anliegen von UX.
3.0
Das Modell hedonischer und
pragmatischer Qualitäten
Es wurden bislang eine ganze Reihen unterschiedlicher UX-Modelle vorgeschlagen (z.B. Forlizzi & Battarbee,
2004; McCarthy & Wright, 2004). Spezifische Workshops diskutieren diese Ansätze auf der Suche nach einer akzeptablen Definition (Law et al., 2008).
Einer der vorgeschlagenen Ansätze ist
das Modell der hedonischen und pragmatischen Qualitätswahrnehmungen
(z.B. Hassenzahl, 2003; Hassenzahl,
2007). Zunächst einmal betont dieses
Modell die Subjektivität, indem es
durchgängig von Qualitätswahrnehmungen und nicht von objektiven Qualitäten spricht. Bevan (2008) ordnet
dieses Modell im ISO-Kontext dementsprechend auch ganz richtig der Zufriedenstellung (satisfaction) zu.
Das Modell unterscheidet zwei Arten
von Qualitätswahrnehmungen: pragmatische und hedonische. Diese kann
man sich als zwei unterschiedliche
Brillen vorstellen, durch die der Nutzer
ein interaktives Produkt betrachtet. Die
pragmatische Brille betont, was man
mit einem Produkt tut, beispielsweise
zu telefonieren. Das ist ein sehr konkreter und greifbarer Nutzen. Die hedonische Brille betont das, was das
Produkt symbolisiert oder an neuen
Möglichkeiten bereithält. Wird man als
Benutzer von Anderen bewundert?
Wird mich das Produkt erstaunen und
überraschen? Wird es mein Leben
durch seine Funktionen verändern?
Dies ist zunächst ein eher abstrakter,
wenig greifbarer Nutzen. Allerdings
adressiert Hedonisches unsere Bedürfnisse viel direkter: Wir lieben
schöne Dinge; wir wollen Neues kennen lernen; es ist uns wichtig, was
andere über uns denken. Im Vergleich
zur pragmatischen Funktion eines
Produkts berührt uns die hedonische
Funktion viel direkter. Das pragmatische Produkt bleibt blass, das hedonische erzeugt Bindung und Emotion.
Studien (z.B. Hassenzahl, 2001) zeigen, dass hedonische und pragmatische Qualitätswahrnehmungen unabhängig voneinander sind. Benutzer
sind fähig, beide Dimensionen getrennt voneinander einzuschätzen. Es
finden sich sowohl Produkte, die beide
der Qualitäten in ähnlichem Ausmaß
besitzen als auch Produkte die überwiegend pragmatisch oder hedonisch
sind. Beide Dimensionen haben einen
Einfluss auf die Produktbewertung. Sie
sind im Schnitt gleichermaßen wichtig.
Die jeweilige Wichtigkeit der Dimensionen wird allerdings durch die Nutzungssituation moderiert.
Das Modell macht eine ganze Reihe
überprüfbarer Vorhersagen. Beispielsweise sollten hedonische Qualitätswahrnehmungen stabiler sein als pragmatische, da erstere direkt mit universellen
psychologischen Bedürfnissen des Benutzers zusammen hängen, während
letztere stark von den jeweiligen Aufgaben und der Nutzungssituation abhängen. Diese Annahme wurde bereits empirisch bestätigt (z.B. van Schaik & Ling,
2008).
Alles in allem ist das vorgestellte Modell
zumindest aus Forschungssicht ein anregendes. Hedonische Qualitäten sind
abgrenzbar und messbar. Sie adressieren psychologische Bedürfnisse, die
über die eigentliche Aufgabebearbeitung
hinausgehen. Das macht sie zu Quellen
positiver Produktbewertungen.
4.0
AttrakDiff2
Ein Modell ist zwar eine notwendige
Grundlage für systematisches Arbeiten,
die Praxis der benutzerzentrierten Produktentwicklung fordert aber auch handhabbare Werkzeuge, mit denen sich
Qualitäten gestalten oder eben bewerten
lassen.
Ein solches Bewertungswerkzeug ist der
AttrakDiff2-Fragebogen (Hassenzahl et
al., 2003). Das Attrakdiff2 gehört zur
Klasse der semantischen Differenziale.
Es besteht aus 28 bipolaren, siebenstufigen Items. Diese 28 einzelnen Items
werden zu vier Skalen mit jeweils sieben
Items zusammengefasst. Sie operationalisieren die folgenden Konstrukte:
x
Pragmatische Qualität (PQ): Die
wahrgenommene Fähigkeit eines
Produkts, Handlungsziele zu erreichen, indem es nützliche und benutzbare Funktionen bereitstellt. Ty-
79
x
x
x
pische Produktattribute sind: praktisch, voraussagbar, übersichtlich.
Hedonische Qualität – Stimulation (HQS): Die Fähigkeit eines Produkts, das Bedürfnis nach Verbesserung der eigenen Kenntnisse und
Fertigkeiten zu befriedigen. Produktattribute: kreativ, originell, herausfordernd.
Hedonische Qualität – Identität
(HQI): Die Fähigkeit eines Produkts,
relevanten Anderen selbstwertdienliche Botschaften zu kommunizieren. Produktattribute: bringt mich
den Leuten näher, fachmännisch,
verbindend.
Attraktivität (ATT): Globale positivnegativ Bewertung des Produkts:
gut, attraktiv, angenehm.
Bei einem Fragebogen spielen natürlich
Zuverlässigkeit und Gültigkeit eine entscheidende Rolle. Für das AttrakDiff2
zeigten sich in einer Reihe von Studien
angemessene interne Konsistenzen der
einzelnen Konstrukte und niedrige bis
mittlere Korrelationen zwischen den
Konstrukten, wobei die Überlappung von
HQI und HQS noch ungeklärt ist. (Für
weitere Information siehe
www.attrakdiff.de, Hassenzahl, 2001,
Hassenzahl et al., 2003). Bis zur Verfügbarkeit besserer Fragebögen zur
Operationalisierung UX-relevanter Konstrukte stellt AttrakDiff2 einen handhabaren und theoretisch verankerten Ansatz
zur Berücksichtigung von UX in der benutzerzentrierter Produktentwicklung
dar.
5.0
5.1
beurteilt und können dann verglichen werden.
In den meisten, über www.attrakdiff.de
abgewickelten Projekten (80%) wird das
Produkt nur einmal beurteilt. Bei weiteren 15% werden zwei verschiedenen
Produkte (oder Varianten) miteinander
verglichen und nur in den restlichen 5%
wird ein Produkt zu zwei unterschiedlichen Zeitpunkten beurteilt (z.B. vor und
nach der eigentlichen Nutzung).
Es gibt nehmen dem Projekttyp
noch vier zentrale Entscheidungen beim
Anlegen eines Projektes:
1.
AttrakDiff2 nutzen
Die Nutzung des AttrakDiff2 erfordert eine Projektanmeldung. Zunächst
kann dabei zwischen drei verschiedenen Projekttypen gewählt werden:
1.
2.
www.attrakdiff.de
Über www.attrakdiff.de kann das
AttrakDiff2 bereits seit fünf Jahren kostenfrei online genutzt werden. Allein
diese Möglichkeit wurde bereits von
mehr als 2300 Beurteilern im Rahmen
von 302 Forschungs- und Praxisprojekten in Anspruch genommen (Stand Ende
2007).
80
Ein Großteil der AttrakDiff2-Projekte
sind praxisorientierte Evaluationen
interaktiver Produkte. Ein großer Vorteil des AttrakDiff2 ist dabei, dass es
sich auch als standardisierter Nachbefragungsbogen zum Abschluss von
usability tests eignet. Dies ist möglich,
da der AttrakDiff2 abstraktere, erlebensorientierte Attribute (z.B., Neuartigkeit) und keine konkreten Merkmale
("Haben Sie die Fehlermeldungen verstanden?") zur Qualitätsmessung verwendet. So können Teilnehmer bereits
nach kurzer Erfahrung mit einem Produkt dessen Eigenschaften beurteilen
(z.B. als einen "ersten Eindruck"). Eine
weitere Anwendungsmöglichkeit des
AttrakDiff2 ist der Vergleich von interaktiven Produkten, im Sinne eines
benchmarkings. Beispielsweise lässt
sich die Website einer Firma mit der
eines Mitbewerbers vergleichen.
3.
Projekttyp „Einzelauswertung“:
Das Produkt wird durch die Untersuchungsteilnehmer einmal beurteilt.
Projekttyp „Vergleich vorher –
nachher“: Ein Produkt wird zu unterschiedlichen Zeitpunkten wahlweise von den gleichen oder unterschiedlichen Teilnehmern beurteilt, z.B. zur Prüfung, ob Gestaltungsmaßnahmen die gewünschten Effekte hatten. Aber auch der
Vergleich eines "ersten Eindrucks"
mit der Beurteilung nach einer bestimmten Nutzungsdauer kann
aufschlussreich sein.
Projekttyp „Vergleich Produkt A
- Produkt B“: Zwei Produkte
(Gestaltungsvarianten) werden
wahlweise von unterschiedlichen
oder den gleichen Teilnehmern
2.
3.
4.
5.2
Wer? Untersuchungsteilnehmer
können unspezifisch eingeladen
werden (z.B. durch einen Link auf
der Homepage) und ihre Beurteilung anonym abgeben. Teilnehmer
können aber auch gezielt eingeladen werden (z.B. im Rahmen eines
"friendly user trials"). Dabei bekommt jeder Teilnehmer ein persönliches Kennwort, mit dem sie oder
er sich identifiziert. Das persönliche
Kennwort und der Link zur Untersuchung kann per E-Mail direkt über
die Website zugestellt werden.
Wieviele? Es können zunächst bis
zu 20 Personen befragt werden.
Wird bei Vergleichsuntersuchungen
entschieden, dass unterschiedliche
Teilnehmer befragt werden, so sind
pro Abfrage 20 Teilnehmer möglich.
Wann? Mit dem Startdatum der
Untersuchung wird festgelegt ab
welchem Zeitpunkt Teilnehmer ihre
Beurteilungen abgeben können. Die
maximale Laufzeit ab Startdatum
beträgt 3 Monate.
Was? Produktname und Branche
können für das bzw. die zu beurteilenden Produkte angegeben werden.
Anpassungen und Flexibilität
Die Abwicklung von AttrakDiff2Untersuchungen ist relativ flexibel. Teil-
nehmer können auch während der laufenden Umfrage hinzugefügt und benannt werden. Außerdem kann der eigentliche Fragebogen angepasst werden, indem ein individueller Studientitel
vergeben werden kann, sowie eine Begrüßungsformel und/oder Angaben zum
Projektverantwortlichen eingefügt werden können.
Sollen mehr als 20 Untersuchungsteilnehmer befragt werden, die Studie länger als 3 Monate laufen oder spezifischere Anpassungen vorgenommen
werden, dann ist dies im Rahmen der
"Premium Services" möglich. Die speziellen Wünsche müssen in diesem Fall
mit den Betreibern von www.attrakdiff.de
abgestimmt werden. Eine kurze Anfrage
per E-Mail genügt.
5.3
Bereich des Rechtecks fallen würde.
Je größer ein Konfidenzrechteck desto
heterogener sind die Beurteilungen der
Teilnehmer. Große Konfidenzrechtecke sind bei kleinen oder heterogen
zusammengesetzten Stichproben
wahrscheinlich. Der Mittelwert als solcher sollte immer unter Bezugnahme
auf die Grenzen des Konfidenzrechtecks interpretiert werden.
Ergebnisdarstellung
Die Beurteilung durch die Teilnehmer erfolgt online und wird automatisch
ausgewertet. Die Ergebnisse können
auch bei laufender Untersuchung abgerufen werden. Sie werden in einem Bericht präsentiert. Den Kern bilden dabei
drei grafische Darstellungen: Portfolio,
Diagramm der Skalenmittelwerte und
Attributprofil. Im Folgenden soll die Portfoliodarstellung etwas ausführlicher beschrieben werden. Die übrigen Formen
lassen sich in einem Beispielbericht auf
www.attrakdiff.de nachlesen.
Die Portfoliodarstellung (siehe Abbildung
1) fasst die Ergebnisse für die pragmatischen Qualität (PQ) und die hedonischen Qualität (HQ, gemittelte Werte für
Identität [HQI] und Stimulation [HQS])
zusammen.
Für PQ und HQ werden Konfidenzintervalle berechnet, die in der Portfoliodarstellung zusammen ein Konfidenzrechteck ergeben. Das Konfidenzrechteck
gibt an, dass der Mittelwert von PQ und
HQ bei einer weiteren Studie unter gleichen Bedingungen mit einer Wahrscheinlichkeit von 95% wieder in den
fidenzrechteck komplett in einem Portfoliofeld liegen. Bei A ist das der Fall. Es
kann dem neutralen Produktcharakter
zugeordnet werden, d.h. es wird als
durchschnittlich wahrgenommen. B kann
nicht eindeutig zugeordnet werden.
Das AttrakDiff2 erfasst die individuelle
Wahrnehmung und Bewertung eines
Produkts. Somit können beispielsweise
auch durch unterschiedliche Vorerfahrung bedingte Beurteilungsunterschiede
zwischen Personen abgebildet werden.
Auch können sich Beurteilungen über
die Zeit verändern. Beurteilungen, die
Vergleichsstandards explizit machen,
wie "Vorher - nachher" oder "Produkt A Produkt B" sind der Einzelbewertung
also vorzuziehen (werden aber leider
noch zu selten durchgeführt).
6.0
Abb. 1: Portfoliodarstellung des Projekttyps
„Vergleich Produkt A - Produkt B“
Abbildung 1 zeigt eine Portfoliodarstellung mit einem Produkt A und einem
Produkt B. Beide unterscheiden sich
signifikant in Bezug auf PQ. Das erkennt man daran, dass sich die Konfidenzrechtecke in der Horizontalen
nicht überlappen. In Bezug auf HQ ist
der Unterschied nicht signifikant. In der
Vertikalen kommt es zu einer Überlappung (wenn man die beiden Rechtecke in der Horizontalen auf dieselbe
Position bringt wird es deutlich). Auch
sind sich die Teilnehmer bei der Beurteilung von A etwas weniger einig als
bei B, und zwar hauptsächlich in Bezug auf PQ. Das Rechteck von A ist
breiter, aber fast genauso hoch wie
das von B.
Weiterhin kann man einem Produkt
einen Produktcharakter zuweisen (z.B.
„begehrt“ oder „selbstorientiert“, mehr
dazu bei Burmester et al., 2007, S.
137f.). Dazu muss es mit seinem Kon-
Ausblick
Das AttrakDiff2 und das zugrunde
liegende Modell verstehen sich als eine
erste und grobe Konzeptionalisierung
von UX. Die Auseinandersetzung mit
alternativen Ansätzen, wie beispielsweise das wieder stärker auf Aufgaben bezogene e4-Modell (Harbich et al., 2007),
wird dabei helfen, die Bedeutung von
UX für die benutzerzentrierte Produktgestaltung besser zu definieren.
Aber auch die Arbeit am AttrakDiff ist bei
weitem nicht abgeschlossen. Momentan
arbeiten wir an einer verkürzten Version
des Differentials, dem AttrakDiff mini mit
nur noch 10 Items (vier pragmatischen,
vier hedonischen und zwei Attraktivitätsitems). Diese verkürzte Version soll das
wiederholte Messen von Wahrnehmungen und Bewertungen beispielsweise
während eines usability tests ermöglichen. So kann zum einen zuverlässiger
gemessen werden als mit der üblichen
Einzelmessung zum Abschluss eines
Tests, zum anderen ermöglicht das wiederholte Messen das Aufzeigen von
Veränderungen in Wahrnehmung und
Bewertung über die Zeit. Unter Umstän-
81
den sind es gerade die Veränderungen,
die die Einstellung zum Produkt prägen.
Das AttrakDiff mini und die Möglichkeit
zum wiederholten Messen werden als
kostenfreie Erweiterung von
www.attrakdiff.de allen Interessierten
zugänglich gemacht.
Wir sind der Überzeugung, dass komplexe technische Produkte systematisch
und methodisch entwickelt werden müssen. Dazu gehört auch die Evaluation,
das "Messen" oder "Beurteilen" von
Qualität. Eine vorherrschende Meinung
war, dass solche Dinge wie "Freude",
"Emotionen", oder "Hedonisches" zu
wenig greifbar sind, um sie systematisch
zu berücksichtigen – oder dass man es
nicht tun sollte, um dem "Anliegen" nicht
zu schaden. Ahmet Cakir formuliert in
einer schon etwas älteren, aber interessanten Debatte seine diesbezügliche
Sorge: "Manches regelt sich besser,
wenn es nicht geregelt wird."
(http://www.ekphorie.de/engramm/swerg
o_fun.html). Das mag sein. Aber manches wird auch ignoriert und vergessen,
wenn es nicht geregelt wird. Und das
möchten wir vermeiden.
7.0
Literatur
Bevan, N. (2008). UX, usability and ISO standards. Now let's do it in practice: User experience evaluation methods in product development.Proceedings of the workshop on CHI
2008 [Online]. Available:
www.cs.tut.fi/ihte/CHI08_workshop/papers/Be
van_UXEM_CHI08_06April08.pdf
Burmester, M., Hassenzahl, M., Koller, F.
(2007). Engineering attraktiver Produkte
AttrakDiff. In: J. Ziegler & W. Beinhauer
(Hrsg.), Interaktion mit komplexen Informationsräumen (S. 127 – 141). München: Oldenburg.
DATech (2008). Leitfaden Usability.
www.datech.de [Online].
Forlizzi, J. & Battarbee, K. (2004). Understanding experience in interactive systems.
In Proceedings of the 2004 conference on
Designing interactive systems (DIS 04):
processes, practices, methods, and techniques (pp. 261-268) New York: ACM.
Harbich, S., Hassenzahl, M., & Kinzel, K.
(2007). e4 - Ein neuer Ansatz zur Messung
der Qualität interaktiver Produkte für den
Arbeitskontext. In T. Gross (Ed.), Mensch &
Computer 2007. Interaktion im Plural (pp.
39-48). München, Wien: Oldenbourg.
Hassenzahl, M. (2001). The effect of perceived hedonic quality on product appealingness. International Journal of HumanComputer Interaction, 13, 479-497.
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 (Eds.),
Funology: From Usability to Enjoyment (pp.
31-42). Dordrecht: Kluwer.
Hassenzahl, M. (2007). The hedonic/pragmatic model of user experience.
In E.Law, A. Vermeeren, M. Hassenzahl, &
M. Blythe (Eds.), Towards a UX Manifesto Proceedings of a cost294-affiliated workshop on HCI 2008 (pp. 10-14).
Hassenzahl, M., Burmester, M., & Koller, F.
(2003). AttrakDiff: Ein Fragebogen zur Messung wahrgenommener hedonischer und
pragmatischer Qualität. In J. Ziegler & G.
Szwillus (Eds.), Mensch & Computer 2003.
Interaktion in Bewegung (pp. 187-196).
Stuttgart, Leipzig: B.G. Teubner.
red definition of user experience. In Proceedings of the CHI 2008 Conference on
Human Factors in Computing. Extended abstracts. (pp. 2395-2398). New York: ACM
Press.
McCarthy, J. & Wright, P. C. (2004). Technology as Experience. Cambridge, USA: MIT
Press.
Meyer, H. A. (2007). User Experience und
Zeitschätzung. In M.Rötting, G. Wozny, A.
Klostermann, & J. Huss (Eds.), Prospektive
Gestaltung von Mensch-Technik-Interaktion
(pp. 251-256). Düsseldorf: VDI-Verlag.
Nokia Corporation (2005). Inspired Human
Technology (White paper). www.nokia.com
[Online]. Available:
http://www.nokia.com/NOKIA_COM_1/About_
Nokia/Press/White_Papers/pdf_files/background
er_inspired_human_technology.pdf
Norman, D. A., Miller, J., & Henderson, A.
(1995). What you see, some of what's in the
future, and how we go about doing it: HI at
Apple Computer. In Conference companion
on Human factors in computing systems (CHI
'95) (pp. 155). New York: ACM Press.
Schifferstein, H. N. J. & Hekkert, P. (2008).
Product experience. (vols. 11) San Diego,
CA: Elsevier.
Stewart, T. (2008). Usability or user experience - what's the difference? System concepts [Online]. Available: http://www.systemcon-cepts.com/articles/.
van Schaik, P. & Ling, J. (2008). Modelling
user experience with web sites: usability,
hedonic value, beauty and goodness. Interacting with Computers
Hassenzahl, M. & Tractinsky, N. (2006).
User Experience - a research agenda [Editorial]. Behaviour & Information Technology,
25, 91-97.
Herzberg, F., Mausner, B., & BlochSnyderman, B. (1959). The Motivation to
Work. New York: Wiley.
Law, E., Roto, V., Vermeeren, A., Korte, J.,
& Hassenzahl, M. (2008). Towards a sha-
82
Softwareentwickler als Interaktionsgestalter: Erfahrungen zu
Einsatz und Verwendung von Interaktionspattern
Kerstin Klöckner
Fraunhofer Institut für Experimentelles
Software Engineering (IESE)
Fraunhofer-Platz 1
[email protected]
Kirstin Kohler
Fraunhofer-Platz 1
[email protected]
Abstract
In den letzten Jahren hat die Verwendung von Interaktionspattern im Umfeld
der User-Interface-Gestaltung zunehmend an Bedeutung gewonnnen. Interaktionspattern dokumentieren bewährte
Lösungen zu definierten Problemen der
Interaktionsgestaltung. Damit dienen sie
insbesondere für unerfahrene Gestalter
als ideales Werkzeug zur Unterstützung
bei der Entwicklung von Benutzungsschnittstellen. In wie weit es gelingt, die
Entwicklung von Benutzungsschnittstellen durch Pattern zu unterstützen,
1.0
Einleitung
Seit Mitte der 90er Jahre finden Pattern zunehmend bei der Entwicklung von
Software-Systemen Verwendung. Während Pattern anfänglich primär zur Gestaltung der Software-Architektur herangezogen wurden, gewinnen sie in den
letzten Jahren mehr und mehr auch im
Bereich der Interaktionsgestaltung an
Bedeutung (Dearden & Finlay 2006).
Dieser Trend zeigt sich sowohl im wissenschaftlichen Umfeld als auch im industriellen Kontext. Interaktionspattern
dienen als vielversprechendes Medium,
um die Lücke zwischen SoftwareEngineering und Usability-Engineering
zu überwinden, da sie es ermöglichen,
Wissen über interaktive Gestaltung zu
dokumentieren und damit auch Software-Entwicklern näher zu bringen. Eine
Gegebenheit, unter der heute viele Projekte leiden: Die Interaktionsgestaltung
wird von Software-Ingenieuren durchgeführt, die durch ihre Ausbildung nur allzu
hängt zu einem erheblichen Teil von
der Qualität der Patternbeschreibungen ab. Wichtige Qualitätsaspekte sind
beispielsweise die für die Zielgruppe
verständliche Beschreibung sowie die
Vollständigkeit der für die Ausgestaltung notwendigen Information. Dieser
Beitrag zeigt, welche Faktoren zu einer
Erhöhung der Verständlichkeit einer
Patternbeschreibung führen und wie
die Vollständigkeit der notwendigen
Information gewährleistet werden
kann.
Weiterhin werden die Ergebnisse einer
empirischen Untersuchung aus dem
industriellen Kontext vorgestellt. Im
Rahmen dieser Untersuchung wurde
eine Patternbeschreibung von verschiedenen Software-Entwicklern in ein konkretes Interaktionskonzept in Form eines
Papierprototyps umgesetzt.
häufig keine Kenntnisse in der Interaktiongestaltung mitbringen.
onsgestaltung tatsächlich unterstützten.
Das FUN-Projekt (Fun-of-Use für Geschäftsanwendungen, http//www.funof-use,de) beschäftigt sich mit einer
speziellen Sorte von Interaktionspattern: Das wissenschaftliche Ziel dieses
Projekts ist es, Pattern zu beschreiben, die es ermöglichen, Geschäftsanwendungen motivierender und attraktiver zu gestalten, also sogenannte
hedonische Aspekte adressiert. Beispiele für bisher beschriebene Pattern
können den folgenden Beiträgen entnommen werden: Niebuhr et at. 2007;
Nass & Kohler 2008.
Obwohl Interaktionspattern vielfach
auch im industriellen Kontext Verwendung finden – beispielsweise bei SAP
(Wozorek & Eberleh 2008) oder Yahoo
(Yahoo 2008) –, gibt es weder Empfehlungen oder Standards zur Beschreibung guter Pattern (Seffah et al.
2005), noch aussagekräftige Studien
darüber, wie gut Pattern die Interakti-
Keywords
Pattern, Interaktionspattern, Verständlichkeit, Evaluation, fun-of-use
Im folgenden Beitrag werden wir von
einer Fallstudie berichten, die wir mit
Software-Entwicklern durchgeführt haben, um die Qualität unserer FUNPatternbeschreibungen (im Folgenden
auch Pattern oder Patternbeschreibung
genannt) zu bewerten und zu verbessern. In Abschnitt 2 wird erläutert, welche Anforderungen wir im FUN-Projekt
an die Qualität der Patternbeschreibungen aufgestellt haben und wie wir sie
adressiert haben. Anschließend wird in
Abschnitt 3 von den empirischen Untersuchungen berichtet, in deren Rahmen
eine Patternbeschreibung bewertet wurde. Eine Zusammenfassung der Ergebnisse ist in Abschnitt 4 dargestellt. Abschnitt 5 schließt mit einer Zusammenfassung und einem Ausblick.
2.0
Unser Qualitätsverständnis von
Pattern
Als Pattern bezeichnet man einen
bewährten Lösungsansatz für wieder-
83
kehrende Probleme mit konkreten Umsetzungsbeispielen. Vereinfacht betrachtet beschreibt ein Pattern also ein Tupel
bestehend aus Problem und Lösung,
das in einem bestimmten Kontext angewendet werden kann. Prominentes Beispiel ist das Pattern der „abwechselnden
Zeilenfarben“ (engl. Alternating Row
Colors). Das Problem, das durch dieses
Pattern adressiert wird, ist die Lesbarkeit
von langen Listen. Die Lösung, die das
Pattern vorgibt, ist die abwechselnde
Hinterlegung der verschiedenen Zeilen
mit kontrastierenden Farben.
Die Anforderungen an die Qualität einer
Patternbeschreibung ergeben sich aus
deren Nutzungsszenario. Abbildung 1
verdeutlich dieses schematisch. Wir
gehen davon aus, dass ein Interaktionsgestalter (darunter wollen wir im Folgenden die Rolle in einem Softwareentwicklungsprojekt subsumieren, welche die
Interaktion des Endanwenders mit dem
System gestaltet) ein Pattern aus einer
Sammlung von Pattern entnimmt, um
ein bekanntes Interaktionsproblem der
Software zu beheben. Das zu lösende
Problem wird durch den dunklen runden
Kreis symbolisiert. Um das Problem mit
Hilfe eines Patterns erfolgreich zu beheben, muss der Interaktionsgestalter die
folgenden, in Abbildung 1 gezeigten
Schritte durchführen.
Er/sie muss das geeignete Pattern aus
der Sammlung von Pattern ausfindig
machen (Schritt 1: Finden). Bei diesem
Schritt ist es besonders wichtig, dass
das Problem, das durch das Pattern
adressiert wird, zu dem Problem in der
Software passt. Da Pattern allgemeingültige Lösungen beschreiben, kann
man davon ausgehen, dass das Pattern
abstrakter beschrieben ist als das zu
behebende Problem in der Software.
Er/sie muss die Patternbeschreibung
verstehen (Schritt 2: Verstehen), um
anschließend die im Pattern aufgeführte
Lösung auf den Kontext der Software zu
84
übertragen und damit eine konkrete
Lösung zu erarbeiten. Um bei dem
Pattern der „abwechselnden Zeilenfarben“ zu bleiben: Es sollten für die konkrete Software Farben gewählt werden, die zum Look and Feel der Software passen. Da in diesem Schritt
etwas Abstraktes (nämlich die Lösung
der Patternbeschreibung) auf etwas
Konkretes übertragen wird (auf die
Lösung des Problems in der Software),
bezeichnen wir diesen Schritt als Konkretisieren (Schritt 3: Konkretisieren).
Interaktionsgestalter
2. Verstehen
Software
mit Problem
Patternbeschreibung
Software
ohne Problem
Problem
1. Finden
Lösung
sollen. Die Fallstudie dient dazu, die
Güte dieser Richtlinien zu bewerten.
In den nächsten beiden Abschnitten
werden wir näher auf diese beiden Qualitätseigenschaften eingehen.
2.1
Verständlichkeit von Pattern
In Anlehnung an das Hamburger
Verständlichkeitskonzept (Wikipedia_1
2008) ist Verständlichkeit die Eigenschaft von Texten, Veröffentlichungen
oder sonstigen Botschaften, vom Empfänger richtig und schnell verstanden zu
werden.
Übertragen auf Pattern bedeutet das,
dass der Inhalt und die Struktur der Patternbeschreibung so gestaltet sein
muss, dass der Interaktionsgestalter den
beschriebenen Sachverhalt nicht nur zur
Kenntnis nimmt, sondern auch die
intellektuelle Erfassung des
Zusammenhangs unterstützt wird (siehe
auch Wikipedia_2 2008).
3. Konkretisieren
Abb 1: Die verschiedenen Schritte bei der
Verwendung eines Patterns zur Unterstützung der Interaktionsgestaltung
Geht man davon aus, dass ein Pattern
korrekt ist, also die dort beschriebene
Lösung auch wirklich das beschriebenen Problem adressiert, hängt es allein von der Güte der oben beschriebenen drei Schritte ab, ob eine Patternbeschreibung überhaupt zur Unterstützung der Interaktionsgestaltung
hilfreich ist. Wir gehen davon aus,
dass das Finden durch eine intelligente Suchmaschine unterstützt werden
kann und haben uns im Folgenden
insbesondere auf die Punkte des Verstehens und Konkretisierens fokussiert. Die Qualität der Patternbeschreibung definiert, wie gut diese Schritte
unterstützt werden. Wir haben im Verlaufe des Projekts Richtlinien für „Patternschreiber“ erstellt, die das Verstehen und Konkretisieren unterstützen
Wir haben versucht, die Verständlichkeit
der Patternbeschreibung unter anderem
in Anlehnung an das Hamburger Verständlichkeitsmodell (Langer et al. 2006)
zu optimieren, indem wir beispielsweise
darauf geachtet haben, einfache, der
Zielgruppe geläufige Wörter zu verwenden, die Sätze einfach aufzubauen und
auf Schachtelsätze zu verzichten. Weiterhin haben wir die Informationen in der
Patternbeschreibung auch innerhalb der
gängigen Kategorien (siehe z.B. Tidwell
2005; Borchers 2001) gegliedert, übersichtlich angeordnet und Wichtiges hervorgehoben. Zudem wurde der Inhalt
durch Beispiele und Abbildungen lebendig gestaltet und der Leser persönlich
angesprochen (z.B. „Welche Informationen werden dargestellt?“).
Abbildung 2 zeigt einen Auszug aus
dem Lösungsteil der in der Fallstudie
benutzten Patternbeschreibung.
Welche Informationen werden dargestellt?
Die Darstellung besteht aus
x
x
x
x
Qualitätskriterien
Ist-Feedback
Soll-Feedback
Tipp
Wie finde ich diese Informationen?
Qualitätskriterium
Qualitätskriterien stellen alle wichtigen Aspekte der
Aufgabenbearbeitung dar, die die Güte der Aufgabenbearbeitung
definieren. Jedes Qualitätskriterium wird durch ein Ist- und ein SollFeedback dargestellt.
Ist- und Soll-Feedback
Feedback über die Arbeitsleistung erhält man, indem man die
Qualität der Aufgabenabarbeitung bezüglich eines
Qualitätskriteriums untersucht. Dies sollte mit Hilfe der Software
berechnet/bewerten werden können.
x Das Ist-Feedback repräsentiert die Qualität, die der Benutzer
bezüglich eines Qualitätskriteriums aktuell erbringt, um die
Aufgabe zu bearbeiten.
Beispiel: Beim Autofahren bestimmen Geschwindigkeit und
Einfahrtswinkel in die Kurve, wie gut ein Rennfahrer in die
Kurve fährt.
x Das Soll-Feedback repräsentiert die Qualität der
Aufgabenbearbeitung eines Anderen bezüglich desselben
Qualitätskriteriums.
Die andere Leistung kann sein:
o die ideale Aufgabenbearbeitung
o die Leistung des Besten
o die Bestleistung des Benutzers
Beispiel: Ein „Geisterfahrer“ gibt die Ideallinie bezüglich
Geschwindigkeit und Einfahrtswinkel vor.
Tipp
dem Kontext belegt werden sollen. Um
auch hier wieder das Beispiel mit den
„abwechselnden Zeilenfarben“ aufzugreifen, wären die beiden Hintergrundfarben solche Variablen.
erläuterten Richtlinien beschrieben wurde, im industriellen Kontext validiert haben.
Eine weitere Richtlinie zur Erstellung
der Patternbeschreibung betrifft die
Gliederung der Patternlösung in drei
Abschnitte:
Ziel der Fallstudie ist es herauszufinden, ob Interaktionsgestalter in der
Lage sind, ein bestehendes Problem
einer Software mit Hilfe einer Patternbeschreibung zu lösen.
x
x
Für jedes Qualitätskriterium der Aufgabenbearbeitung beschreibt
der Tipp Hinweise, wie die Aufgabenbearbeitung hinsichtlich des
Qualitätskriteriums optimiert werden kann.
Abb. 2: Auszug aus dem Lösungsteil einer
FUN-Patternbeschreibung
2.2
Konkretisierung von Pattern
Ein Pattern muss so gestaltet sein,
dass die abstrakte Beschreibung der
Lösung auf eine konkrete Lösung übertragen werden kann. Die Herausforderung dabei besteht darin, den Lösungsraum nicht zu stark und nicht zu wenig
einzuschränken (siehe Abbildung 3):
Wird der Lösungsraum zu stark einschränkt, wird es genau eine Lösung
geben (1), was der Idee eines Patterns
widerspricht. Wird der Lösungsraum zu
wenig einschränkt, ist es wahrscheinlich,
dass eine schlechte Lösung erarbeitet
wird (2). Erwünscht ist, dass sich die
Lösung auf viele verschiedene Situationen übertragen lässt und die Lösung
Platz für Kreativität lässt (3).
Wir begegnen dieser Herausforderung
damit, dass wir die Pattern in semiformaler, natürlicher Sprache beschreiben.
Semiformal insofern, dass alle Informationen, die im Pattern dargestellt werden, ähnlich wie Variablen zu verstehen
sind. Durch die Patternbeschreibung
wird dem Interaktionsgestalter vermittelt,
wie diese Variablen durch Werte aus
x
Welche Information muss ich darstellen? In diesem Abschnitt werden alle Variablen beschrieben, die
für die konkrete Interaktion mit
Werten belegt werden müssen
Wie finde ich diese Information? In
diesem Abschnitt wird erläutert, wie
der Interaktionsgestalter die Information aus seinem Kontext ermitteln kann.
Was muss ich bei der Darstellung
der Information beachten? Dieser
Abschnitt gibt Richtlinien zur visuellen Ausgestaltung, die den Interaktionsgestalter dabei unterstützen
sollen, eine Lösung mit guter Usability zu erarbeiten.
3
1
2
Abb. 3: Die Art der Lösung hängt davon ab,
wie stark der Lösungsraum durch die Beschreibung eingeengt wird.
Im folgenden Abschnitt wird die Fallstudie beschrieben, in deren Rahmen
wir ein Pattern, das nach den oben
3.0
3.1
Fallstudie
Messziel
Im Folgenden wird das Messziel
formuliert, das sich auf die Qualitätseigenschaften Verständlichkeit und Konkretisierung eines Patterns bezieht. Da
diese beiden Qualitätseigenschaften in
der Fallstudie nur schwer von einander
getrennt werden können, umfasst das
Messziel beide Eigenschaften.
Messziel: Das Pattern ist für Interaktionsgestalter in einer Art und Weise beschrieben, dass diese eine Interaktionsgestaltung zu einem gegebenen, zum
Pattern passenden Kontext erarbeiten
können, so dass diese Lösung die im
Problem-Teil der Patternbeschreibung
spezifizierten Qualitätsaspekte korrekt
adressiert.
Wir glauben, dass FUN-Pattern die Zielgruppe der Interaktionsgestalter adressiert, die das Konzept von Pattern kennen und Erfahrung im Einsatz von Pattern haben.
3.2
Ablauf der Fallstudie
Nach einer allgemeinen Einführung
in Pattern und der Erklärung des groben
Ablaufs der Fallstudie wurde der Proband in eine „Entwurfssituation“ versetzt,
in der ihm der Kontext einer Software
erklärt wurde, die eine Schwachstelle
aufweist. Seine Aufgabe war es, mithilfe
eines Patterns ein Interaktionskonzept in
Form eines Papierprototyps zu erstellen,
das die Schwachstelle behebt. Das Pattern wurde im Vorfeld von Experten so
85
ausgewählt, dass es das Problem auch
tatsächlich löst.
Nachdem der Proband mit dem Kontext
und der Aufgabe vertraut war, wurde
ihm die Patternbeschreibung ausgehändigt, die er so lange lesen durfte, bis er
sie verstanden hatte. Danach hatte er
die Möglichkeit, Unklarheiten bezüglich
der Patternbeschreibung durch Rückfragen an den Versuchleiter zu klären. Generell hatte der Proband immer die Möglichkeit, den Versuchleiter bei Unklarheiten zu befragen.
Im Anschluss daran erstellte der Proband ohne Zeitdruck ein Interaktionskonzept, das er danach dem Versuchsleiter erklärte. Zuletzt fand ein Abschlussinterview statt, in dem der Proband unter anderem gebeten wurde,
den Problem- und den Lösungsteil der
Patternbeschreibung mit seinen eigenen
Worten wiederzugeben.
Danach wurde das vom Proband erstellte Interaktionskonzept von zwei Experten bewertet.
3.2.1
Messinstrumente
Zur Überprüfung der Messziele
diente vor allem die Bewertung des Interaktionskonzepts durch Experten.
Weiterhin wurden die Rückfragen zur
Verständlichkeit der Patternbeschreibung oder sonstiger Zwischenfragen
ausgewertet, ebenso die Ergebnisse des
Abschlussinterviews, das neben der
Bitte um Wiedergabe der Patternbeschreibung mit eigenen Worten auch
einen Fragebogen zur Bewertung der
Verständlichkeit (Langer et al. 2006) der
Patternbeschreibung beinhaltete.
Des Weiteren wurde gemessen wie viel
Zeit jeder Proband braucht, um das Pattern zu lesen.
3.2.2
Probanden
Die bisherigen Probanden bestanden einerseits aus Mitarbeitern einer der
86
Firmen des FUN-Projektkonsortiums
und andererseits aus Mitarbeitern des
Fraunhofer IESE. Bis auf einen Probanden hatten die Probanden keine
größeren Kenntnisse über das FUNProjekt bzw. über FUN-Pattern.
4.0
Erste Ergebnisse
Bisher wurde die Studie mit fünf
Probanden durchgeführt. Von den fünf
erstellten Interaktionskonzepten wurden zwei Lösungen schlecht und drei
Lösungen gut bewertet.
Was genau unterscheidet eine gute
von einer schlechten Lösung? Gute
Lösungen adressieren die in der Patternbeschreibung spezifizierten Qualitätsaspekte korrekt: Alle Elemente, die
laut Patternbeschreibung vorkommen
müssen, sind auch in der Lösung zu
finden. Beispielsweise gibt es in dem
in der Fallstudie verwendeten Kontext
der Software verschiedene Qualitätskriterien, anhand derer die Arbeitsweise eines Mitarbeiters bewertet werden
kann. Laut Patternbeschreibung muss
zu jedem Qualitätskriterium ein Istund ein Soll-Feedback gegeben werden. Eine Lösung wird unter anderem
dann als gut bewertet, wenn sie zu
jedem Qualitätskriterium sowohl ein
Ist- als auch ein Soll-Feedback enthält.
Gute Lösungen beachten weiterhin
alle Hinweise zur Darstellung der Information, zum Beispiel, dass das
Feedback in Echtzeit gegeben werden
muss.
der Patternbeschreibung oder sonstige
Fragen.
Die Ergebnisse des Verständlichkeitsfragebogens waren wenig auffällig. Von
den fünf Probanden gaben vier Probanden den Inhalt der Patternbeschreibung
korrekt wieder, ein Proband nur unvollständig. Die für das Lesen des Patterns
benötigten Zeiten variierten zwischen
fünf und 15 Minuten und korrelieren
nicht zur Qualität der Lösung.
4.1.1
Erklärung der Ergebnisse
Wie lassen sich die beiden schlechten Lösungen erklären, obwohl alle Probanden die Patternbeschreibung verstanden haben? Das heißt es gab keine
Verständlichkeitsfragen, die Ergebnisse
des Verständlichkeitsfragebogens waren
wenig auffällig und die Probanden waren
größtenteils in der Lage, den Inhalt der
Patternbeschreibung korrekt wiederzugeben.
Zur Klärung der Frage wurden die Profile der Probanden betrachtet, die mit
Hilfe eines Fragebogens erhoben wurden und unter anderem Angaben zu
ihren beruflichen Aufgaben und ihrem
Kenntnisstand bezüglich Pattern beinhaltet.
Die beiden Probanden, welche schlechte Lösungen erarbeitet haben, gaben an
zu wissen, was Pattern sind, hatten aber
keine bis genau eine Erfahrung mit der
Verwendung von Pattern zur Interaktionsgestaltung bzw. in der Architekturentwicklung.
Im Gegensatz dazu gab es bei den
schlechten Lösungen gravierende
Mängel, die vor allem die korrekte und
vollständige Umsetzung der notwenigen Elementen betreffen, so z.B.,
wenn es nicht zu jedem Qualitätskriterium ein Ist- und ein Soll-Feedback
gab.
Die drei Probanden, welche gute Lösungen erarbeitet haben, gaben ebenfalls
an zu wissen, was Pattern sind, hatten
aber im Gegensatz zu den beiden anderen Probanden bereits eine gewisse
Erfahrung mit der Verwendung von Pattern in der Architekturentwicklung.
Grundsätzlich hatten die Probanden
keine Rückfragen zur Verständlichkeit
Dies lässt vermuten, dass der Einfluss
der Erfahrung mit der Verwendung von
Pattern tatsächlich eine große Rolle
spielt, sei es bei der Interaktionsgestaltung oder in der Architekturentwicklung.
Weniger wichtig scheint zu sein, ob Gestaltung oder Entwicklung von Benutzeroberflächen zu den Aufgaben des
Probanden gehören, da es diesbezüglich keine Korrelation zu der Qualität der
erarbeiteten Lösung gab.
5.0
Zusammenfassung und Ausblick
Die Fallstudie hat gezeigt, dass alle
Probanden die FUN-Patternbeschreibung verstanden haben. Drei der
fünf Probanden waren darüber hinaus in
der Lage, eine Interaktionsgestaltung
zum gegebenen, zum Pattern passenden Kontext zu erarbeiten, so dass die
Lösung die in der Patternbeschreibung
spezifizierten Qualitätsaspekte korrekt
adressiert – allerdings nur, wenn die
Probanden mit der Verwendung von
Pattern erfahren sind.
Es ist geplant, die Fallstudie mit zusätzlichen Probanden durchzuführen. Weiterhin ist angedacht, die Fallstudie mit
einem anderen FUN-Pattern zu wiederholen.
Darüber hinaus wird über einen alternativen Versuchsaufbau nachgedacht, der
dem bisherigen entspricht, außer dass
der Proband zuerst das Problem ohne
Pattern lösen muss. Nachdem er diese
Lösung präsentiert hat, bekommt er die
Patternbeschreibung ausgehändigt und
muss darauf basierend eine neue Lösung erarbeiten. Mit diesem Versuchsaufbau ist es möglich festzustel-
len, ob es einen (qualitativen) Unterschied gibt zwischen der der Lösung,
die ohne Pattern erarbeitet wurde, und
der Lösung, die unter Zuhilfenahme
eines Pattern erarbeitet wurde.
Danksagung
Wir danken der Firma a3 systems GmbH,
deren Mitarbeiter sich für diese Fallstudie
zur Verfügung gestellt haben.
Die Arbeiten werden durch das vom BMBF
geförderte Projekt FUN finanziert (Förderkennzeichen: 01 IS E06 A)
6.0
Alexander, C. (1979): A Timeless Way of
Building. Oxford University Press.
Borchers, J. (2001): A Pattern Approach to
Interaction Design. Wiley.
Dearden, A.; Finlay, J. (2006): Pattern Languages in HCI: A Critical Review. In: Human Computer Interaction. Vol. 21, S. 49102.
Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. (1995): Design Patterns: Elements
of Reusable Object Oriented Software.
Addison-Wesley.
Langer, I.; Schulz von Thun, F.; Tausch, R.
(2006): Sich verständlich ausdrücken. München: Ernst Reinhardt Verlag.
ves Nutzererleben mit ernsthafter Software!
In: Rötting, M.; Wozny, G.; Klostermann, A.;
Huss, J. (Hrsg.): Prospektive Gestaltung von
Mensch-Technik-Interaktion. Reihe 22, Nr.
25. Düsseldorf: VDI Verlag GmbH. S. 233238.
Seffah, A.; Desmarais, M. C.; Metzker, E.
(2005): HCI, Usability and Software Engineering Integration: Present and Future. In: Seffah, A.; Gulliksen, J.; Desmarais, M. C.
(Hrsg.): Human-Centered Software Engineering - Integrating Usability in the Software
Development Lifecycle. Vol. 8. Niederlande:
Springer. S. 37-57.
Tidwell, J (2005): Designing Interfaces: Patterns for Effective Interaction Design. O'Reilly
Media, Inc.
http://designinginterfaces.com/
Waloszek, G.; Eberleh, E. (2008): Introduction to User Interface Patterns at SAP
http://www.sapdesignguild.org/community/des
ign/patterns_sap.asp (28.05.08)
Wikipedia_1 (2008): Verständlichkeit
http://de.wikipedia.org/w/index.php?title=Ham
burger_Verst%C3%A4ndlichkeitskonzept&oldid=
44528345 (02.06.2008)
Wikipedia_2 (2008): Verstehen
http://de.wikipedia.org/w/index.php?title=Verst
ehen&oldid=44660903 (02.06.2008)
Yahoo 2008: Yahoo! Design Pattern Library
http://developer.yahoo.com/ypatterns/
(02.06.2008)
Nass, C.; Kohler, K. (2008) Exploration –
ein Pattern für Engagement, Einprägsamkeit und positive Emotionen. In: Röse, K.;
Brau, H. (Hrsg.): Usability Professionals
2008.
Niebuhr, S.; Graf, C.; Klöckner, K.; Baldi,
F.; Kohler, K. (2007): Gewusst wie: Positi-
87
Exploration – ein Pattern zur Steigerung des Engagements
Claudia Nass
Fraunhofer Platz 1
[email protected]
Kirstin Kohler
Fraunhofer Platz 1
[email protected]
Abstract
Dieser Artikel präsentiert die Ergebnisse einer Untersuchung aus dem
Forschungsprojekt FUN, das sich
mit der Verbesserung der User Experience von Geschäftsanwendungen beschäftigt. Eines der Resultate
von FUN sind die so genannten
1.0
Einleitung
Die Forschung der letzten Jahre hat
gezeigt, dass positives Nutzererleben
(engl. User Experience) sowohl auf
pragmatischen als auch auf hedonischen Eigenschaften beruht (Hassenzahl et al. 2003). Speziell im Hinblick auf
die hedonischen Eigenschaften von
Software im Umfeld von professionellen
Software-Anwendungen eröffnet sich
damit ein bisher wenig genutztes Optimierungspotenzial. Doch noch ist weder
viel darüber bekannt, welche Bedeutung
die verschiedenen Eigenschaften für
unterschiedliche Typen von Systemen
haben, noch wie sie gezielt in Systeme
„hinein entwickelt“ werden können.
Das vom Bundesministeriums für Bildung und Forschung BMBF geförderte
Projekt FUN (www.fun-of.use.org) versucht, Antworten auf diese Fragenstellung zu erarbeiten. Es verfolgt das Ziel,
Interaktionspattern für Geschäftanwendungen zu beschreiben, die zu positivem Nutzererleben führen. Dabei werden Pattern unterschieden, die motivierend wirken, zu Verhaltensänderung
führen oder zum Explorieren anregen
sollen (vgl. das von Harbich et al 2007
vorgeschlagene Qualitätsmodell).
Mit der vorliegenden Arbeit wollen wir
ein Pattern vorstellen, dass den Anwen-
88
FUN Interaktions-Pattern. "Exploration" ist ein solche Pattern. Es fasst
Interaktionskonzepte zusammen,
die das Interesse und Engagement
des Anwenders für eine Web-Seite
stärken soll. Der Beitrag stellt das
Exploration-Pattern vor und be-
der dazu anregen soll, sich stärker mit
einer Web-Seite auseinander zu setzten und sie zu erkunden. Das Pattern
ist in die Projektseite des Projektes
FUN integriert. In Abschnitt 2 werden
die wissenschaftlichen Hintergrundtheorien vorgestellt, die dem Pattern
zu Grunde liegen. Abschnitt 3 stellt
das Pattern und seine Ausgestaltung
in Form der Projekt-Webseite vor. Anschließend werden in Abschnitt 4 die
Ergebnisse einer Pilotstudie erläutern,
die zur empirischen Validierung des
Patterns beiträgt.
2.0
Wissenschaftliche Hintergrundtheorien
Zurzeit wird das Thema "Exploration" im Kontext des interaktiven Lernens diskutiert, speziell im Zusammenhang mit dem Konstruktivismus im
Rahmen der Lernpsychologie (Ackerman 2007; Rosatelli 2000). Nach der
Theorie des Konstruktivismus geben
wir der Welt erst ihre Bedeutung. Bedeutung existiert nicht unabhängig von
uns.
Piaget, einer der Vorläufer des Konstruktivismus, sagt, dass Wissen nicht
etwas ist, das eingepackt, adressiert
und verschickt werden kann. Wissen
ist Erfahrung, die aktiv durch die direk-
schreibt Ergebnisse einer Pilotstudie.
Keywords
User Experience, FUN, Exploration,
Engagement, AttrakDiff, Hedonische
Qualität.
te Interaktion mit der Welt aufgebaut
wird (Piaget 1967).
Nach Piagets funktionaler Theorie über
die Intelligenz haben Individuen die Fähigkeit, die Balance zwischen Stabilität
und Änderung, Passivität und Aktivität in
seinen Worten Akkommodation und
Assimilation zu bewahren (Piaget 1967).
Das bedeutet, dass eine Person sich
manchmal aktiv auf die Suche nach Information begibt, während sie im nächsten Moment nur passiv Information aufnimmt.
Kegan (1992) postuliert etwas Analoges.
Er sagt, Wissen ist Beziehung. Beziehung heißt, den Austausch und die Balance zwischen Außen- und Innenwelt
herzustellen. Ebenso werden in einer
Beziehung Dinge erfragt, aufgenommen
oder erzählt.
Es ist auch bekannt, dass die Zuhörer
das Interesse verlieren, wenn man viel
über sich selbst erzählt. Dann gibt es
keinen Raum mehr für Interpretationen.
Ebenso wird Desinteresse erzeugt,
wenn man nicht genug erzählt oder das
Erzählte Widersprüchliche ergibt. In beiden Fälle findet die Exploration nicht
statt. Nur zwischen dem Spannungsbogen von Akkommodation und Assimilation gibt es eine „ideale Anpassungszone“
in der die Aufnahme und Verknüpfung
von Informationen unterstützt wird (Ackerman 2007).
So kann man sagen, dass die Exploration es dem Individuum erlaubt, seine
eigenen Wege zu gestalten, neue Grenzen zu erreichen, Informationen zu interpretieren, neue Verbindungen zu verknüpfen und seine eigenen Erfahrungen
zu machen.
Diese Aktionen sind möglich, wenn die
Umgebung das Individuum dazu ermutigt. Für Winnicott (1989) ist die ideale
Umgebung für das Sammeln dieser Erfahrung eine Übergangszone zwischen
dem Ich und der Welt, wo die Leute
proaktiv und sicher explorieren können. In dieser Umgebung kann man
Ideen verwirklichen und Risiken eingehen ohne negative Nebenwirkung hervorzurufen.
3.0
Exploration-Pattern
Basierend auf den Erkenntnissen
dieser Theorien wurde eine Liste von
Eigenschaften abgeleitet, die in einem
Software-System dazu beitragen könnten, Engagement bei dem Benutzer zu
fördern. Diese Eigenschaften wurden in
Interaktionskonzepte umgesetzt und im
Konzept des FUN-Patterns "Exploration"
zusammengefasst.
3.1
Konzepte des ExplorationPatterns
Das Exploration-Pattern ist ein Navigationsmodus. Vier wesentliche Eigenschaften bestimmen die Darstellung
einer Grafischen Benutzungsoberfläche
(GUI) mit diesem Pattern:
1.
2.
Die Präsentation des Inhaltes soll
eine Spannung bezüglich der Interpretation des Wahrgenommen erzeugen. Diese interpretative Spannung bildet der Anreiz etwas zu
entdecken.
Die dynamische Gestaltung der
GUI-Elemente soll den Benutzer
3.
4.
dazu anregen, den Raum spielerisch zu entdecken.
Indem der Anwender die Spuren
seiner Interaktionen hinterlässt,
wird die Schnittstelle ad hoc personalisiert. Dies soll beim Anwender die Identifikation mit der Software unterstützen.
Der Benutzer kann den Interaktionsprozess, so oft er will, erneut
beginnen, was zum spielerischen
Umgang mit der Software ermutigen soll.
Jede dieser Eigenschaften besteht aus
einem oder mehreren Interaktionskonzepten, die in die graphische Oberfläche integriert werden können (Tab. 1).
Die interpretative Spannung wird durch
das Konzept der Erkennungszeichen
(1) umgesetzt. Mit Erkennungszeichen
sind Grafikelemente gemeint, die den
Aufbau und den Inhalt der Anwendung
darstellen. Die Nutzung von Farben,
Symbole und die Gruppierung von
Informationen können als Erkennungszeichen interpretiert werden.
Die interpretative Spannung wird in
Kombination mit einer anderen Eigenschaft des Patterns verursacht, dem
spielerischen Entdecken. Spieleri-
sches Entdecken wird durch zwei Interaktionskonzepte umgesetzt: die Beweglichkeit (3) des Interfaces und die Wegewahl (4). Unter der Beweglichkeit des
Interfaces wird es verstanden, dass sich
das Interface bei den Benutzungen in
alle vier Himmelrichtungen (horizontal
und vertikal) bewegen lässt und dass
Annährung und Entfernung dargstellt
werden können (Zoom). Dadurch wird
dem Benutzer ermöglicht, vom Ganzen
ins Detail oder in die Übersicht zu navigieren. Das Fenster der Anwendung ist
nicht mehr eine Grenze für die Navigation, sondern es funktioniert als ein Ausschnitt, der den Benutzer beim Navigieren unterstützt.
Die Wegewahl unterstützt die interpretative Spannung und das spielerische
Entdecken in dem Maße, dass sie dem
Benutzer erlauben, seine eigenen Wege
zur Information oder Aktion zu finden,
sein eigenes Wissen aufzubauen und
sich dadurch besser die Information
merken oder die Aktion zu durchführen
zu können.
Die Identifikation wird dadurch gefördert,
dass jede Aktion des Benutzers auf der
Schnittstelle aufgezeichnet wird, so dass
er den Pfad seiner bisherigen Interaktion
beobachten kann (5). Eine grafische
Eigenschaften
Interaktionskonzepte
Interpretative
Spannung
Erkennungszeichen (1) (2)
Beweglichkeit (3)
Spielerisches
Entdecken
Wegewahl (4)
Identifikation
Verfolgbarkeit > Personalisierung (5)
Ermutigung
Zurücksetzen (6)
Bedeutung
Der Inhalt ist präsentiert als
konsistente Erkennungszeichen.
Der Bildschirm funktioniert als
Ausschnitt für die Navigation.
Man hat verschiedene Möglichkeiten, ein Ziel zu erreichen.
Indem der Anwender die Spuren seiner Interaktionen hinterlässt, wird die Schnittstelle
personalisiert.
Der Benutzer kann den Interaktionsprozess so oft er will,
erneut beginnen.
Tab. 1: Beziehung zwischen Eigenschaften und Interaktionskonzepte des Patterns
89
Darstellung des bereits zurückgelegten
Wegs personalisiert die Benutzungsoberfläche und verstärkt die Beziehung
des Benutzers zu der Anwendung.
Für eine erfolgreiche Exploration ist es
wichtig, dass der Benutzer sich sicher
fühlt. Die Möglichkeit des Zurücksetzens
(6) erlaubt dem Benutzern das Löschen
des personalisierten Pfades und damit
das Beginnen einer neue Exploration.
3.2
Eine beispielhafte Umsetzung des
Exploration-Patterns
Das Exploration-Pattern wurde in
der Web-Seite des Forschungsprojektes
FUN (Abb. 1) exemplarisch realisiert
(www.fun-of-use.org).
Die erläuterten sechs Interaktionskonzepte wurden dabei in der Seite umgesetzt. Das Erkennungszeichen wurde
durch zwei Elemente realisiert: (1) Symbole repräsentieren die Links der Hauptnavigation. Sie werden auf der ersten
Seite im Hauptmenü gezeigt. Der Wechsel zwischen den verschiedenen Unterlinks deutet dem Benutzer an, dass es
mehr zu sehen gibt. Dies soll ihn dazu
motivieren, weiter zu schauen (2). Der
Wechsel zwischen zwei Seiten erzeugt
ein Rutschen in der Horizontalen. In
diesem kurzen Augenblick des Übergangs kann der Benutzer andere Teile
der Fun Seite erkennen.
Auf der Startseite im Zentrum des Interfaces wird das Hauptmenu gezeigt.
Durch die Bewegung der Maus auf diesen Bereich erzeugt man eine Beweglichkeit von links nach rechts und von
rechts nach links. Durch die Dynamik
bekommt der Anwender Zugriff auf alle
Menüpunkte. Auch auf die, die sich vorher außerhalb des sichtbaren Bereichs
befunden haben. Durch diese Lösung
wird das Interaktionskonzept der Beweglichkeit aufgegriffen.
Jedes Mal, wenn einer dieser Links gewählt wurde, erscheint eine Miniatur des
90
Abb 1: Fun Seite mit Exploration-Pattern. Die Zahlen (1) bis (6) entsprechen den Interaktionskonzepten von Tab 1.
entsprechenden Symbols im Oberen
Teil der GUI. In dem der Anwender
mehr und mehr Unterpunkte besucht,
baut er sein eigenes Menü auf. Dieses
Menü (wir bezeichnen es als Nebenmenü) erlaubt ebenfalls die Navigation
über alle existierenden Seiten (4). Es
setzt das Prinzip der Wegewahl um.
Der Aufbau des eigenen Menüs repräsentiert gleichzeitig ein weiteres Interaktionskonzept, das der Personalisierung (5). Da der Aufbau für jeden Benutzer gesondert erfolgt und von dessen Interaktion abhängt, wird die WebSeite personalisiert.
Das Interaktionskonzept des Zurücksetzens (6) wird durch einen Button
angeboten, der es dem Benutzer erlaubt das Nebenmenü zu löschen und
wieder mit dem originalen Interface zu
beginnen.
4.0
Pilotstudie des ExplorationPatterns
Im Rahmen einer Pilotstudie wurde
die Wirkung des Patterns auf Benutzer
beobachtet.
Die Wirkung des Patterns wurde bezüglich dreier Aspekte betrachtet:
1.
2.
3.
Engagement: Dies bezieht sich auf
die Beteiligung einer Person oder
deren Interesse an einem Inhalt
oder Ablauf des Erlebens, unabhängig vom Medium (Dow et al.
2007).
Hedonische Qualität: Der Benutzer
wird durch visuelle Gestaltung und
neuartige Interaktionsformen stimuliert, besitzt die Anwendung hedonische Qualität (Hassenzahl 2003).
Pragmatische Qualität: Die Anwendung erlaubt es dem Benutzer, seine Aufgabe zu erledigen. Die Software besitzt pragmatische Qualität,
wenn der Benutzer das wahrnimmt
(Hassenzahl 2003).
Von den 15 Teilnehmern wurden die
Ergebnisse von 14 Versuchungen ausgewertet, da sich das Verhaltensmuster
einer der Teilnehmer von dem gesamt
Gruppe (mit und ohne Pattern) sehr unterschieden hat. Die Verhaltensindikatoren und subjektiven Maße über die Wirkung des Patterns werden in den folgenden Abschnitten erläutert.
4.1
Verhaltensindikatoren
Der Zwischengruppen-Vergleich
zeigt interessante Verhaltensunterschiede, sowohl im Bezug auf die Dauer, die
sich Anwender mit der Seite beschäftigen, als auch im Bezug auf die Anzahl
der betrachteten Inhaltsseiten.
Für die Untersuchung wurden zwei verschiedene Versionen der Web-Seite des
Projekts FUN (www.fun-of-use.org) entwickelt. Beide Web-Seiten haben den
gleichen Inhalt, die gleichen Farben und
eine ähnliche Informationsarchitektur.
In einer der Seiten ist das ExplorationPattern implementiert und stellt damit
ein unkonventionelles und dynamisches
Interface mit Animationen und Multimediaelementen dar (Abb. 1). Der Zugang
zu dieser Seite erfolgt über eine animierter Einleitung gefolgt von einer Seite
(Hauptmenü), die die Verknüpfungen für
die anderen acht Seiten zugänglich
macht. Details zu dieser Web-Seite wurden in Abschnitt 3.2 erläutern.
Die andere Web-Seite ist im traditionellen textbasierten Stil (Abb 2). Die Startseite beinhaltet die Beschreibung des
Projektes. Die anderen acht Seiten sind
durch das Menü auf der linken Seite mit
jeweils einem Klick erreichbar.
Im Rahmen der Pilotstudie wurden Teilnehmer zufällig der Web-Seite mit Pattern und ohne Pattern zugeordnet.
Die Tests wurden in einer kontrollierten Laborumgebung durchgeführt. Es
wurden verschiedene Testmethoden
und Instruktionen ausprobiert, bis
schließlich für jeweils sieben Teilnehmer mit Pattern (Gruppe 1) und acht
Teilnehmer ohne Pattern (Gruppe 2)
Daten erhoben wurden. Zu Beginn
wurden die Teilnehmer kurz über eingeführt. Gleich danach wurde dem
Teilnehmer die FUN-Seite gezeigt und
er/sie wurde in den Aktionsmodus
(Hassenzahl et al. 2002) versetzt. Das
bedeutet, dass ihm/ihr kein Instrumentalziel gegeben wurde, sondern die
Instruktion "Schauen Sie sich auf der
FUN-Seite an, wozu Sie Lust haben.
Nehmen Sie sich so viel Zeit, wie Sie
mögen...“ , so dass die Teilnehmer
ihre eigene Ziele setzen konnten. Der
Aktionsmodus wurde deshalb gewählt,
weil das Pattern genau die Anwender
in den Bann der Web-Seite ziehen soll,
die etwas unspezifisch im Internet umhersuchen, also gerade kein festes
Ziel im Auge haben.
Anzahl der besuchten Seite
Abb. 2: Fun Seite ohne Pattern
Wie in Abbildung 3 dargestellt, besuchten die Teilnehmer mit Pattern (Gruppe
1) mehr Inhaltsseiten als die Teilnehmer
ohne Pattern (Gruppe 2). In Gruppe 1
wurden im Mittel 24 Seiten besucht,
während sich die Teilnehmer der Gruppe 2 im Mittel 14 Seiten ansahen, MannWhitney-U-Test, U = 6.5, p = 0.02
40
35
30
25
20
15
10
5
mit Pattern
ohne Pattern
Bedingung
Abb. 1: Anzahl der besuchten Seiten
Außerdem fällt auf, dass die Varianz der
Seitenbenutzung für die Gruppe mit Pattern deutlich höher ist. Die Benutzer
navigieren also im Schnitt mehr in der
Seite zu, allerdings sind die Reaktion
der Benutzer auf das Pattern recht unterschiedlich.
91
7=hoch), Mann-Whitney-U-Test, U =
3.0, p = 0.004.
Nutzungszeit - Minuten
32:00
28:00
Dagegen sind keine Unterschiede zwischen den Gruppen in der Beurteilung
der pragmatischen Qualität zu beobachten. Die mittleren Skalenwerte
des PQ liegen bei 5,28 für die Seite
mit Pattern und 5,86 für die Seite ohne
Pattern.
24:00
20:00
16:00
12:00
08:00
04:00
mit Pattern ohne Pattern
Bedingung
Abb. 2: Nutzungszeit
Des Weiteren ist ein Effekt des Patterns
auf die Nutzungszeit der Seite erkennbar. Teilnehmer der Gruppe 1 haben im
Mittel 20,13 Minuten auf der Seite mit
Pattern verbracht, stattdessen haben
Teilnehmer der Gruppe 2 nur 8,5 Minuten auf der Seite ohne Pattern verbracht,
Mann-Whitney-U-Test, U = 9.0, p = 0.05.
4.2
Subjektive Bewertung
Neben den Verhaltensindikatoren
zeigt auch die subjektive Bewertung der
Web-Seite durch die Benutzer interessante Unterschiede. Die Daten zeigen,
dass das Exploration-Pattern von den
Anwendern als deutlich stimulierender,
neuartiger und motivierender empfunden
wird, als die Web-Seite ohne Pattern.
Mit Hilfe des AttrakDiff (Hassenzahl
2003), wurde die wahrgenommene hedonische und pragmatische Qualität der
Software ermittelt. Der mittlere Skalenwerte des HQS (Hedonische Qualität Stimulation) liegt bei 5,29 für die Fun
Seite mit Pattern und 3,43 für die Fun
Seite ohne Pattern (Skala 1=niedrig bis
92
5.0
Zusammenfassung
Eine längere und intensivere Auseinandersetzung der Anwender mit der
Web-Seite mit Pattern könnte als Indiz
dafür gedeutet werden, dass das Pattern wirklich das Interesse der Anwender erhöhen kann, im Vergleich zu
einem traditionellen Web-Layout. Weitere Experimente sollen diesen Zusammenhang tiefer beleuchten. Wir
wollen untersuchen, in wiefern auf
diese Weise auch mehr Inhalte übermittelt werden können, oder in welchen Situationen das Interaktionskonzept des Patterns sinnvoll eingesetzt
werden kann.
Danksagung
Wir danken Felice Baldi, Steffen Hess und
Felix Kiefer, die die Durchführung des Experiments unterstützt haben.
Die Arbeiten werden durch das vom BMBF
geförderte Projekt FUN finanziert (Förderkennzeichen: 01 IS E06 A)
6.0
Ackermann, E. (1996): Perspective Taking
and Object Construction. In: Kafai, Y.; Resnick, M. (Hrsg.) Constructionism in Practice:
Designing, Thinking and Learning in a Digital Word. Mahwah, New Jersey: Lawrence
Erlbaum Associates. Teil 1, Kap. 2 S. 25-37.
Ackermann, E. (2007): Experiences of artifacts: People’s appropriation, objects’ affordances. In: Larochelle, M. (Hrsg.): Key works
on radical constructivism. Ernst von Glasersfeld. Rotterdam. NL. Sense Publishers, S.
149-159.
Dow, S.; Mehta, M.; Harmon, E.; MacIntyre,
B.; & Mateas, M. (2007): Presence and Engagement in an Interactive Drama. In Proc.
CHI 2007, ACM Press, S. 1475 - 1484.
Harbich, S.; Hassenzahl, M.; Kinzel, K.
(2007): e4 – Ein neuer Ansatz zur Messung
der Qualität interaktiver Produkte für den
Arbeitskontext T.Gross (Hrsg.). Mensch &
Computer 2007: Konferenz für interaktive und
kooperative Medien: Oldenbourg Verlag, S.
39-48.
Hassenzahl, M.; Kekez, R.; Burmester, M.
(2002): The importance of a software’s pragmatic quality depends on usage modes. In:
Luczak, H., Cakir, A.E., Cakir, G. (Hrsg.),
Proceedings of the 6th international conference on Work With Display Units (WWDU
2002). ERGONOMIC Institut für Arbeits- und
Sozialforschung, Berlin, S. 275–276.
Hassenzahl, M.; Burmester, M.; Koller, F.
(2003): AttrakDiff: Ein Fragebogen zur Messung wahrgenommener hedonischer und
pragmatischer Qualität. In Ziegler, J.; Szwillus, G. (Hrsg.), Mensch & Computer 2003.
Interaktion in Bewegung. Stuttgart: B.G.
Teubner, S. 187-196.
Kegan, R. (1993): The Evolving Self. Cambridge: Harvard University Press.
Piaget, J.; Inhelder, B. (1967): The child’s
conception of space. New York: Norton & Co.
Rosatelli, M.C. (2000). Novas tendências da
pesquisa em inteligência artificial na
educação. In Nunes, R.C. (Hrsg.), VIII Escola
de Informática da SBC Sul. Porto Alegre:
Editora da UFRGS, S. 179-210.
Winnicott, D. (1971): Playing and Reality.
London: Tavistock Publishers.
Yo u ng Profe s s i o n a l s
93
94
Season of Usability – Studenten sammeln Erfahrungen in
Open Source Projekten
Ellen Reitmayr
Freiberufliche Usability Beraterin
Schlesische Str. 29-30
Aufgang M
10997 Berlin
[email protected]
Abstract
Die Season of Usability ist ein Weiterbildungs-Programm, bei dem Studenten
mit dem Berufsziel Usability unter Anleitung eines erfahrenen Mentors die Usability von Open Source Software (OSS)
Projekten verbessern.
Diese bieten ideale Voraussetzungen,
um die im Studium erworbenen Fähigkeiten in einem interdisziplinären und
internationalen Software-Team auszuweiten und praktisch anzuwenden.
Für die Dauer von drei Monaten werden
die Studenten durch einen UsabilityMentor und einen leitenden Entwickler
des OSS Projektes dabei unterstützt,
eine eng umrissene Usability-Aufgabe
durchzuführen.
Sie lernen, wie Design-Lösungen in
Abstimmung mit dem gesamten Entwicklungsteam entstehen. Das Ziel ist
es, möglichst anwendungsorientierte
Lösungen zu entwickeln. Auch Diplomoder Studienarbeiten wurden in diesem Rahmen erfolgreich vermittelt.
Einleitung
Season of Usability ist ein Mentoring-Programm für Studenten mit dem
Berufsziel Usability oder User-Interface
Design. In enger Zusammenarbeit mit
einem erfahrenen Usability Professional
verbessern sie die Nutzungsfreundlichkeit einer Open Source Software (OSS),
während sie tiefe Einblicke in die Arbeitsweise ihres Mentors erhalten.
Die Season of Usability wird von
dem Verein Open Usability e.V. organisiert, einer Initiative die hauptsächlich
zwei Ziele verfolgt:
•
Die Förderung der Benutzungsfreundlichkeit von Open Source
Software.
Young Professionals, Ausbildung, Open
Source, Open Usability
Die Season of Usability wird von dem
Verein Open Usability e.V. organisiert,
dessen Ziele die Förderung der Benutzungsfreundlichkeit von Open Source
Software und der Zugänglichkeit von
Usability-Wissen sind.
•
1.0
Keywords
Die Förderung der allgemeinen
Zugänglichkeit von UsabilityWissen, -Verfahren, -Methoden
und -Instrumenten.
Die Season of Usability ist ein Instrumt, diese Ziele zu verwirklichen.
2.0
Ausbildung zum Usability Professional
Die Usability Professionals’ Association (UPA) definiert einen Usability
Professional als “anyone who works
on, or advocates for the usability of
their products” (UPA, 2008a) – also
frei übersetzt jeden, der an der Benutzungsfreundlichkeit eines Produktes
direkt oder als Vermittler beteiligt ist.
Entsprechend dieser Definition ist
das Arbeitsfeld der Usability Professionals sehr breit. Grob unterscheidet man
die Bereiche User Research, Evaluation
und Design (UPA, 2008a).
In Deutschland erhalten nur wenige
ihre Qualifikation aus der akademischen
Ausbildung. Obwohl eine Umfrage unter
Usability Professionals im Jahre 2007
ergab, dass 84% ein abgeschlossenes
Studium vorzuweisen haben, gaben nur
etwa 50% an, sich bereits dort für Usabiity qualifiziert zu haben (Diefenbach &
Hassenzahl, 2007).
Umso höher ist der Stellenwert „informeller“ Trainings – Literaturrecherche, Lernen „on the Job“ oder durch
Kollegen wurde von fast allen Teilnehmern genannt (Diefenbach & Hassenzahl, 2007). Die Anwendbarkeit ist je-
95
doch eingeschränkt: Literaturrecherche
fördert zwar das theoretische Wissen,
eine praktische Vorbereitung auf den
Berufseinstieg kann hierdurch jedoch
nur bedingt vermittelt werden. Lernen
„on the job“ oder die Weiterbildung
durch Kollegen haben zwar einen höheren praktischen Nutzen, doch setzen
beide voraus, dass ein Arbeitsverhältnis
bereits besteht – zumindest im Rahmen
eines Praktikums oder eines Werkstudentenvertrags. Die Verfügbarkeit eines
solchen Verhältnisses ist oft an den
Standort eines Studenten gebunden.
3.0
Das Mentoring-Programm der UPA
Um die Möglichkeiten der Weiterbildung für Studenten auszubauen, und
um den Berufseinstieg zu erleichtern,
bildete die UPA den Interessensbereich
“Young Professionals“. Teil dessen ist
ein Mentoring-Programm, bei dem Berufseinsteiger auf eigene Initiative hin
von einem erfahrenen Professional gecoacht werden. Neben dem Erfahrungsaustausch werden Networking und die
Vertiefung von Führungsqualitäten –
sowohl für den Mentor als auch den
Mentee – bezweckt (UPA, 2008b).
Außerdem bietet Mentoring gegenüber eines herkömmlichen Praktikums
den Vorteil des informellen Verhältnisses: Ein berufstätiger Usability Professional kann sozusagen „nebenbei“ einen
Studenten betreuen. Auf Antragstellung
oder Verwaltungsgänge, die bei der Einstellung von Praktikanten oft notwendig
sind, kann verzichtet werden.
Auch für den Studenten bietet das
Mentoring Vorteile, da ein StandortWechsel in der Regel nicht notwendig
ist. Mentoring kann „virtuell“, also über
Email, Telefon oder Chat stattfinden,
während ein Betriebspraktikum in der
Regel die Anwesenheit bei dem Arbeitgeber vor Ort vorsieht.
96
4.0
Mentoring-Prozesse in OSS Projekten
In erster Linie bezeichnet „Open
Source“ eine Philosophie der Lizenzgestaltung für Software, die die Offenheit des Quellcodes zum freien Kopieren, Verbreiten, Nutzen und Modifizieren fordert. „Open Source „ kann sich
jedoch auch auf Entwicklungsmethoden beziehen, bei denen die Transparenz der Entwicklung und CommunityProzesse im Vordergrund stehen
(Open Source Initiative, 2007).
„Peer Review“, also eine Art der
Software Review, bei der ein Stück
Quellcode, Spezifikation oder Dokumentation durch Kollegen inspiziert
und evaluiert wird, wird als einer der
größten Vorteile der Open Source
Entwicklung gewertet. Die bekannte
Aussage „ Given enough eyeballs, all
bugs are shallow “ des Open Source
Evangelisten Eric S. Raymond (1999)
bringt die Motivation auf den Punkt –
nämlich die Qualität des Codes zu
verbessern.
Für junge Entwickler hat die Peer
Review jedoch vornehmlich einen anderen Vorteil: Von erfahrenen Entwicklern konstruktive Kritik bezüglich der
eigenen Programmierfähigkeiten zu
erhalten.
Auch im Bericht der Europäischen
Kommission zum Einfluss von OSS
auf Innovation und Wettbewerbsfähikgeit in Europa wird dieser Aspekt besonders hervorgehoben. OSS Communities seien wie „informelle Ausbildungen – aber die Auszubildenden/Studenten und ihre Ausbilder/Lehrer liefern ihren Beitrag umsonst, ohne für die Ausbildung eine
monetäre Vergütung zu erhalten.“ (frei
übersetzt aus MERIT, 2006, Seite 63)
Das Mentoring und die konstruktive Kritik sind möglicherweise das, was
Open Source unter jungen Entwicklern
so beliebt macht – im Jahre 2002 waren
41% der aktiven Mitglieder in der OSS
Community zwischen 14 und 23 Jahren.
(MERIT, 2006, p64)
5.0
Junge Usability Professionals in
OSS Projekten
Programmieren ist nur ein Aspekt
dessen, was junge Entwickler in Open
Source Projekten lernen. In einer Umfrage im Rahmen des oben genannten
Berichts wurden OSS Entwickler mit
universitärer Ausbildung gefragt, welche
Fähigkeiten sie in OSS Projekten besser
gelernt hätten als in formellen Kursen.
Unter den fünf meistgenannten Antworten betrafen drei soziale Fertigkeiten
und Projekt-Management:
•
Kritik von anderen akzeptieren und
entsprechend reagieren zu können,
•
die eigene Arbeit mit der der anderen koordinieren zu können,
•
die Arbeit anderer bewerten zu können.
(MERIT, 2006, Seite 64)
Auch junge Usability Professionals
können von diesen „soft skills“ profitieren.
Bezüglich der Weiterbildung der
professionellen Fertigkeiten haben junge
Usability Professionals in OSS Projekten
jedoch einen eindeutigen Nachteil gegenüber jungen Entwicklern. Der generelle Mangel an Usability Professionals
in OSS erschwert die Möglichkeiten zum
Erfahrungsaustausch und Wissenstransfer. Auch werden Feedback und Kritik
meist von Entwicklern statt qualifizierten
Usability Professionals geäußert.
Während junge Usability Professionals also ihre sozialen Fertigkeiten in
OSS Projekten ausbauen können, fehlt
häufig die Möglichkeit zum Erfahrungsaustausch und Wissenstransfer, was
den Ausbau der professionellen Fertigkeiten im Vergleich zu jungen Entwicklern bremst.
Dies ist umso bedauerlicher, da
OSS Projekte das Potenzial haben,
ganz spezifische Usability-Fähigkeiten
zu fördern. Wie durch die berühmte
Aussage “release early, release often''
des Open Source Evangelisten Eric S.
Raymond (1999) verdeutlicht, verfolgen
viele OSS Projekte ein Entwicklungsmodell mit sehr kurzen Release-Zyklen. Die
Usability-Techniken, die hierbei eingesetzt werden, ähneln denen, die in der
agilen Software-Entwicklung eingesetzt
werden. Auch fördern die flachen Hierarchien, die in vielen OSS Projekte vorgefunden werden, die Umsetzung innovativer Lösungen.
OSS Projekte bieten hier also eine
Spielwiese, um die eigenen Fähigkeiten
weiter auszubauen.
6.0
Die Season of Usability
Um jungen Usability Professionals
eine effektive Weiterbildung in OSS Projekten zu ermöglichen, bietet Open Usability e.V. seit 2006 ein MentoringProgramm an, die Season of Usability.
Studenten mit dem Berufsziel Usability
oder User-Interface Design wirken für
drei Monate an einem Open Source
Projekt mit, und werden dabei durch
einen erfahrenen Mentor betreut.
Nach einem Pilotprojekt findet die
Season of Usability seit 2007 jährlich
zwischen April und August statt. Im ersten Jahr konnten sechs Projekte erfolgreich abgeschlossen werden. In diesem
Jahr wurde die Zahl der Projekte auf 10
ausgebaut.
Die Themen der Studentenprojekte
sind so vielseitig wie das Berufsbild
selbst und umschließen User Research,
Evaluation, Design, Prototyping oder die
Gestaltung von Human Interface Guidelines. Auch die angebotenen OSS
Projekte sind breit gefächert: WebAnwendungen sind genauso vertreten
wie Java-Applikationen oder komplette
Desktop Environments. Die Anwendungsfelder umspannen ein ProjektManagement-Tool, Bild-Management
und -Bearbeitungs-Software, ein Office
Suite, ein 3D-Editing-Tool und einen
Instant Messenger. Das wohl bekannteste Projekt der Season of Usability
2008 ist der One Laptop per Child
Desktop, ehemals bekannt als das 100
Dollar Laptop.
Rolle als die überzeugende Darstellung
des Berufsziels. Dies steht im Einklang
mit den Zielen der Season of Usability,
nämlich Studenten, die kurz vor dem
Berufseinstieg stehen, beim Sammeln
praktischer Erfahrungen zu unterstützen.
Von den Studenten wird ein wöchentliches Engagement von mindestens einem Arbeitstag pro Woche verlangt. Sie arbeiten selbständig, die Mentoren stehen ihnen jedoch jederzeit beratend zur Seite. Einmal pro Woche wird
eine Besprechung zur Durchsicht der
erzielten Ergebnisse und zur Festlegung
der nächsten Schritte durchgeführt.
Nach erfolgreichem Abschluss des
Projektes erhalten die Studenten ein
Stipendium von $1000 USD.
8.0
7.0
Mentoring-Philosophie
Während bei dem MentoringProgramm der UPA die Initiative auf
Seiten des Mentees liegt (UPA, 2008b)
– hier arbeitet er selbst das Ziel und
die Meilensteine des Mentorings aus –
gibt die Season of Usability die Richtung des Studentenprojektes vor. Die
zu bearbeitende Aufgabe wird im
Rahmen einer Ausschreibung grob
definiert, so dass Studenten sich gezielt auf die Projekte bewerben können, die ihrem Berufsziel am ehesten
entsprechen. Während die Season of
Usability 2007 beispielsweise eine
starke Ausrichtung auf User Research
und Evalution hatte, wurden 2008 einige Design-Projekte hinzugefügt.
Auch bei der Auswahl der Bewerber spielt deren Ausrichtung eine Rolle: Sie müssen nicht nur überzeugend
kommunizieren, dass „Usability Professional“ ihr wahres Berufsziel ist,
sondern auch erläutern, warum sie
sich für ein bestimmtes Projekt entschieden haben. Vorkenntnisse spielen bei der Auswahl eine geringere
Kommunikation zwischen den
Projekt-Mitgliedern
Die Kollaboration und Kommunikaton zwischen Usability Professional und
Entwicklern wird in OSS Projekten als
eine der größten Herausforderungen
empfunden (Reitmayr et al., 2006). Da
persönliche Treffen in der Regel nicht
vorgesehen sind, erfolgt die Kommunikation über die etablierten Medien der
OSS Entwicklung wie Internet Relay
Chat (IRC), Voice over IP (VoIP), Mailinglisten und Wikis.
In Mailinglisten, die häufig von mehr
als 20 Personen abonniert werden, wird
die Diskussion von Usability-Tätigkeiten
oft als schwierig eingestuft, da leicht ein
Überlauf an E-Mail-Verkehr entsteht, der
nicht nur beobachtet sondern auch beantwortet werden möchte.
Die Season of Usability sucht deshalb auf Projektseite nach einem Ansprechpartner, der eine führende Rolle
im Projekt einnimmt. Statt Entscheidungen mit allen Mitgliedern der Mailingliste
zu treffen, wird ein Vertreter gewählt, der
sowohl die technischen Anforderungen
kennt, als auch die grundlegenden Ziele
des Projektes vertritt. Dieser „technische
97
Mentor“ wird in die wöchentlichen Besprechungen mit einbezogen.
Um dennoch der Anforderung einer
„offenen“ Usability nachzukommen, deren Prozesse und Ergebnisse für die
Allgemeinheit zugänglich sind, werden
die Arbeitsergebnisse in einem öffentlichen zugänglichen Raum dokumentiert.
Hierzu bieten sich Wikis an, die zur Vorbereitung und Auswertung von User
Surveys, zur Skizzierung von Use Cases, zum Ablegen von Mockups und
ähnlichem genutzt werden.
Sobald ein Meilenstein abgeschlossen ist, werden die Ergebnisse auf der
Mailingliste veröffentlicht und zur Diskussion gestellt. Bei Design-Projekten
kann der Vorteil der direkten Interaktion
mit den Entwicklern ausgenutzt werden,
indem das neue Design noch im Zeitrahmen des Studentenprojektes implementiert wird, während dieser sich einer
neuen Unteraufgabe zuwendet. Neben
der Möglichkeit zur iterativen Weiterverbesserung des Designs wird so die Verständlichkeit der Spezifikation des Studenten geprüft.
9.0
Bisher befasste sich dieses Paper
vornehmlich mit den Vorteilen des
Mentorings für Studenten. Aber auch
Senior Usability Professionals profitieren von einer Mentorstelle, indem sie
ihre Führungsqualitäten ausbauen.
Außerdem bieten die im Rahmen der
Season of Usability angebotenen OSS
Projekte eine Spielwiese für innovative
Entwicklungen, die in kommerziellen
Projekten oft nicht in dieser Art durchgesetzt werden können.
Usability Professionals, die Interesse an einer Mentorstelle haben,
können sich auf der Webseite der
Season of Usability unverbindlich registrieren.
10.0
Project Information
Season of Usability Website:
http://season.openusability.org
OpenUsability:
www.openusability.org
Ausblick
Die Season of Usability ist momentan in ihrem zweiten Jahr und erfährt
einen starken Zulauf an Studenten. Im
Jahr 2008 bewarben sich um die 150
hoch qualifizierten Studenten auf nur 10
offene Projekte. Um dieser wachsenden
98
Popularität besser gerecht zu werden,
ist es das Ziel, die Season of Usability
2009 weiter auszubauen.
Danksagung
Wir danken unseren Platin Sponsoren
Google, Open Society Institute und Trolltech.
11.0
Diefenbach, S.; Hassenzahl, M. (2007). Usability als Beruf. Ergebnisse einer Umfrage
unter Usability Professionals.
http://www.gc-upa.de/images/
pdfs/branchenreport%20usability%2007.pdf
(Mai 2008)
MERIT (2006). Study on the: Economic impact of open source software on innovation
and the competitiveness of the Information
and Communication Technologies (ICT) sector in the EU.
http://ec.europa.eu/enterprise/ict/policy/doc/2
006-11-20-flossimpact.pdf (Mai 2008)
Open Source Initiative (2007). About Open
Source. Open Source Initiative Homepage.
http://www.opensource.org/ (Mai 2008).
UPA (2008a). About Usability. UPA Homepage.
http://www.upassoc.org/usability_resources/a
bout_usability/about_usability_professionals.h
tml (Mai 2008)
UPA (2008b). Mentoring Basics. UPA Homepage.
http://www.upassoc.org/usability_resources/p
d/mentor.html (Mai 2008)
Raymond, E.S. (1999). The Cathedral & the
Bazaar. O'Reilly.
Reitmayr, E., Balazs, B., und Mühlig, J.
(2006). Integrating Usability with Open
Source Software Development: Case Studies
from the Initiative OpenUsability. In the proceedings of tOSSad 2006:Workshop on Governmental, Educational, Public, Legal and
Usability Practices. Pp 65-72.
U sability Pra x i s I
99
100
Usability und/oder Security?
Markus Dahm
Software-Ergonomie
Fachbereich Medien
FH Düsseldorf
40474 Düsseldorf
[email protected]
www.medien.fh-duesseldorf.de/dahm
Christoph Thiel
IT-Sicherheit
Fachbereich Medien
FH Düsseldorf
40474 Düsseldorf
[email protected]
www.medien.fh-duesseldorf.de/thiel
Abstract
In der Usability-Community liegt der
Focus (natürlich) vor allem darauf, dem
Benutzer die Arbeit mit der Software
oder dem elektronischen Gerät so einfach wie möglich zu machen. Eine
Randbedingung, die dabei nicht sehr
häufig behandelt wird, ist die Sicherheit
der Anwendung. Mit „Sicherheit“ ist hier
im Wesentlichen der Schutz vor Missbrauch bzw. Manipulation von Daten
oder Ressourcen gemeint.
1.0
Überblick
1.1
Usability und Security
Die Informatik-Disziplinen „Security“
und „Usability“ haben beide das gleiche
Ziel: Das Beste für den Benutzer. Security schützt den Benutzer vor Nachteilen
bei der Verwendung von Software, Usability möchte die Verwendung so einfach
wie möglich machen.
Leider stehen beide Zielrichtungen häufig im Widerspruch zueinander:
x
x
x
Alleine das Einrichten einer möglichst sicheren Infrastruktur stellt bereits ein Hindernis für das einfache
Benutzen von Software dar, wie die
meisten bestätigen können, die
selbst ein WLAN-Netzwerk in einer
homogenen Umgebung eingerichtet
haben.
Aber auch Techniken wie die Sicherung von E-Mails durch Zertifikate
sind sowohl in der Einrichtung als
auch der Verwendung meistens
sehr aufwändig und damit nicht aufgabenangemessen.
Beim online-Banking ist der Widerspruch ebenfalls eklatant: Jeder
möchte natürlich maximale Sicher-
Es scheint so zu sein, dass sich die
beiden Ziele Gebrauchstauglichkeit
und Sicherheit sehr häufig in der Umsetzung gegenseitig ausschließen:
Eine sehr sichere Anwendung ist meistens eher aufwändiger zu benutzen
und zu warten, eine einfach zu benutzende Anwendung vernachlässigt häufig die Sicherheit. Können diese Ziele
miteinander in Einklang gebracht werden?
x
1.2
heit seiner Kontodaten, die wenigsten Kunden gönnen sich aber
die Sicherheit des HBCIVerfahrens durch Anschaffung,
Einrichtung und Benutzung eines
zusätzlichen Kartenlesers.
Die ständigen Nachfragen der
User Account Control (UAC) von
Windows Vista bei der Installation
oder Modifikation von Software
erhöhen zweifelsfrei die Sicherheit, gehen dem Benutzer aber
sehr schnell auf die Nerven.
Sicheres oder Benutzbares Internet ?
Aufgrund der weiten Verbreitung
und Wichtigkeit auch im beruflichen
Einsatz sind sowohl Sicherheit als
auch Usability ein wesentlicher Bestandteil der Anforderungen und natürlich auch jeder ernsthaft eingesetzten
Software.
Die werbewirksam eingesetzten Techniken von „Web 2.0“ stellen durch ihre
direkten Interaktionsmöglichkeiten des
Benutzers erhöhte Anforderungen an
die Gestalter der Software, wiederum
Keywords
Usability, Security, Widersprüchliche
Anforderungen, Gesundheitskarte,
HBCI, RFID, Software-Engineering
sowohl in Hinsicht auf ihre Usability als
auch ihre Security.
1.3
Wie beide Aspekte verbinden?
Mit diesem Beitrag soll vor allem
darauf aufmerksam gemacht werden,
dass sich Anforderungen bezüglich der
Sicherheit und der Usability häufig zunächst wiedersprechen. Lösungen können daher prinzipiell nicht in einer bloßen Kosmetik der Oberfläche oder in
nachträglich eingefügten Prozessen
bestehen. Vielmehr muss nicht nur das
Interaktionskonzept explizit beide Ziele
(Sicherheit und Ergonomie) ansprechen
–beide Anforderungsbereiche müssen
fast immer auch im Design und der Architektur der Software berücksichtigt
werden.
1.4
Beispiele
In den folgenden Kapiteln werden
wir die Probleme der Widersprüchlichkeit der Anforderungen im Detail einiger
Beispiele erörtern.
101
2.0
Vertraulichkeit
Ein wichtiger Grundwert der ITSicherheit ist die Vertraulichkeit der ausgetauschten Informationen: Niemand
außer Sender und Empfänger sollte die
Informationen entziffern können. Ein
Lauscher mag die Sendung vielleicht
lesen, soll sie aber nicht verwenden
können.
2.1
WLAN
Wer heute einen DSL-Anschluss
bestellt, bekommt meistens einen
WLAN-Router für kleines Geld oder gar
gratis dazu. WLAN ist ja auch sehr bequem: das lästige Verkabeln entfällt,
trotzdem ist in der ganzen Wohnung der
Internetzugang verfügbar.
solchen Zwecken löse Prüf- und Handlungspflichten aus. Zumutbar sei es
auch, fachliche Hilfe in Anspruch zu
nehmen“ (heise.de WLAN).
Das bedeutet, dass der typische HeimAnwender sich einige bis viele Stunden mit der sicherheitstechnisch korrekten Einrichtung seines HeimWLANs befassen muss.
Dabei sind häufig sowohl die Anleitung
als auch die sind Durchführung kompliziert, um sowohl den Router als
auch jedes Gerät im Netzwerk korrekt
zu konfigurieren.
Einige Hersteller bieten zwar technische Unterstützung mittels USBSticks, aber auch dafür wird einiges an
Erfahrung benötigt.
Î Mit den entsprechenden Konfigurationen können WLAN-Netze
ausreichend sicher betrieben werden. Leider ist die Konfiguration
sehr häufig aufwändig.
2.2
Abb 1: WLAN-Router (Bild: AVM)
Wer allerdings sein WLAN offen und
ungeschützt betreibt, muss mit verheerenden Folgen rechnen: Wenn sich z.B.
Unbekannte über dieses WLAN an einer
illegalen Tauschbörse beteiligen, haftet
der WLAN-Betreiber, bis zu einigen
Tausend Euro. Aus einer Urteilsbegründung des LG Hamburg1: „Gemäß § 1004
BGB habe die Anschlussinhaberin als
Störer für Schutzrechtsverletzungen zu
haften“. „Weiter ist allgemein bekannt,
dass ungeschützte WLAN-Verbindungen
von Dritten missbraucht werden können,
um über einen fremden Internetanschluss ins Internet zu gelangen". „Die
Verwendung der WLAN-Verbindung zu
1 LG HH, Aktenzeichen 308 O 407 / 06
102
Verschlüsselung
Nur mit Hilfe von Verschlüsselungslösungen kann die Vertraulichkeit von
Informationen allgemein sichergestellt
werden. Für die Sicherung interner
Datenbestände eines Unternehmens
können dazu File/ Folder-Encryption
(FFE), Festplattenverschlüsselung
oder Containerverschlüsselung eingesetzt werden.
Grundsätzlich muss man zwischen
rein clientbasierten Lösungen und
Client-Server-Anwendungen unterscheiden. Erstere benötigen für die
Verwaltung der kryptografischen
Schlüssel meist zusätzliche Datenbanken, welche hohe Zusatzanforderungen an Installation und Betrieb stellen.
Zudem sind rein clientbasierte Systeme in der Regel nicht in der Lage,
zeitnah auf Änderungen der Verschlüsselungspolicy, z. B. den Entzug
von Entschlüsselungsrechten für Be-
nutzer, zu reagieren. Hingegen haben
Client-Server-Systeme den Vorteil, dass
Konfigurations- und Schlüsselmanagement durch eine Serverkomponente
automatisch erledigt werden und keine
zusätzlichen Datenbanken benötigen.
Schlüsselverwaltung und Authentifizierung basieren überwiegend auf Public
Key Mechanismen und benötigen für
den sicheren Betrieb eine Public-Key
Infrastruktur (PKI). Eine gebrauchstaugliche Verschlüsselungslösung sollte sowohl benötigte PKI-Komponenten selbst
beinhalten, als auch mit bereits bestehenden PKIs zusammenarbeiten können. Hierbei ist auch darauf zu achten,
dass eine Standardschnittstelle für Sicherheitstoken unterstützt wird, damit
man nicht eine unangenehme und teure
Überraschung erlebt, wenn die Verschlüsselungssoftware nicht mit der
verwendeten Chipkarte zusammenarbeitet. Zur Reduktion des Aufwandes bei
der Benutzerverwaltung ist es ein Muss,
dass die Lösung sich an externe Verzeichnisdienste wie z. B. Microsoft Active Directory oder Novell eDirectory andocken kann.
Sehr nützlich ist es, wenn aus verschlüsselten Dateien automatisch verschlüsselte E-Mail-Anhänge erzeugt
werden können, welche beim E-MailEmpfänger über ein mitgeteiltes Passwort und evtl. mithilfe einer kostenlos zur
Verfügung gestellten Software entschlüsselt werden können.
Der GAU der Verschlüsselung sind verschlüsselte Daten, an die auch der
rechtmäßige Besitzer nicht mehr herankommt, z. B. aufgrund von Schlüsselverlust o.ä. Selbst im Fall eines Totalausfalls des Security-Servers oder einer
anderen schlüsselverwaltenden Instanz,
z. B. nach einem Brandschaden, müssen verschlüsselte Dateien noch entschlüsselt werden können.
Eine im größeren Stil einsatzfähige Lösung muss hier eine schnelle und un-
komplizierte Lösung bieten. Im Sinne
der schnellen Datenverfügbarkeit und
der Business Continuity ist eine solche
Option unverzichtbar.
Neben der in der Natur der Sache liegenden Forderung nach Sicherheit,
muss eine solche Verschlüsselungslösung weitere Anforderungen erfüllen, um
praxistauglich zu sein: Es sollte eine
transparente Verschlüsselung eingesetzt
werden, so dass der Benutzer keinerlei
Auswirkungen spürt, die Verschlüsselung weder manuell anstoßen, noch sich
darüber Gedanken machen muss, ob
überhaupt verschlüsselt werden soll.
Schließlich sollte eine Rollentrennung
zwischen IT und Sicherheitsverwaltung
möglich sein.
Î Dazu muss eine Lösung über eine
zentrale „einfache“ Administration
und über sinnvolle Identifizierungsund Authentisierungsmechanismen
verfügen. Auch Nicht-Techniker ohne Experten-Know-how über Kryptografie sollten die Rolle des Sicherheitsadministrators übernehmen können. Sie sollen jederzeit in
der Lage sein, die Verschlüsselungsregeln festzulegen und der
„Policy“ (den Richtlinien) gemäß
anzupassen.
3.0
3.1
Identifikation und
Authentifizierung
RFID-Tags auf einzelnen Artikeln
Um die Verkaufskette (supply chain)
möglichst durchgängig zu automatisieren, gehen Bestrebungen dahin, die
Barcodes auf allen Produkten durch
RFID-Tags zu ergänzen oder zu ersetzen. Das ermöglicht sowohl zeitnahes
Materialmanagement als auch ein berührungsfreies Kassieren (Metro).
Für den Verbraucher bedeutet das einerseits Vorteile, da Schlangen an der
Kasse so vermieden werden könnten.
Für die Filial-Mitarbeiter bedeutet das
sind andererseits mit erheblichen
Sicherheitsbedenken verbunden.
eine Entlastung, sowohl an der Kasse
als auch bei der Warendisposition.
3.2
Biometrie
Wäre es nicht sehr einfach, wenn
man sich nicht beliebig viele Benutzernamen und nicht zu erratende Passworte merken müsste? Wenn statt dessen
„man selbst“ immer alle Daten zur Authentifizierung bei sich, sogar in sich
tragen würde? Genau das ist die Idee
bei der Identifizierung und gleichzeitiger
Authentifizierung durch körperliche Eigenschaften.
Abb 2: RFID-Tag an der Ware (Bild: Metro)
Nachteile bezüglich der Sicherheit
ergeben sich für den Verbraucher
durch die Möglichkeit, die RFID-Tags
nicht nur an der Kasse sondern auch
durch beliebige andere RFID-Leser
auszulesen. Dadurch lassen sich Käufer fast beliebig nach ihren Gewohnheiten ausspähen.
Als fast unwirkliche Kulmination erscheint in diesem Zusammenhang das
Tagging von Menschen. Ende 2005
hat die Food and Drug Administration
(FDA) der USA grünes Licht für implantierbare Tags gegeben: "Die FDA
hat den Weg für den so genannten
"VeriChip" der US-Firma Applied Digital Solutions [ADS] frei gegeben. Dieser etwa reiskorngroße Chip wird unter
der Haut eingepflanzt und kann diverse Informationen speichern, die über
einen speziellen Scanner ausgelesen
werden können. (hae) Als Anwendung
wird dabei die schnelle Identifikation
von Kindern und Häftlingen aber auch
von Patienten in großen Krankenhäusern genannt.
Î RFID-Tags sind eine hervorragende technische Unterstützung
für berührungslose Informationsübermittlung auch sehr vieler kleiner Objekte (Waren). Die damit
verbundenen Annehmlichkeiten
und Vorteile für viele Beteiligte
Die Gebrauchstauglichkeit ist dadurch
sehr hoch, da der Prozess der Erkennung, je nach Verfahren und Merkmal,
sehr einfach und schnell gemacht werden kann.
Verfahren wie Iris-Erkennung sind mit
erhöhtem technischem Aufwand verbunden und haben auch eine hohe Akzeptanzhürde. Nicht selten sind dagegen Scanner für Fingerabdrücke in Laptops oder auch auf USB-Speichersticks.
Abb 3: Fingersensoren (Bild: Visortech, Acer)
Damit kann im Prinzip sehr einfach und
ohne mentale Belastung des Benutzers
eine Zugriffskontrolle und Authentifizierung durchgeführt werden. Allerdings
sind die einfachen Ausführungen, wie
sie in Consumer-Geräten eingesetzt
werden, auch relativ einfach zu überlisten - teilweise durch Anhauchen oder
mit Tesafilm oder Gummibärchen übertragene Fingerabdrücke (Uni B) oder,
etwas aufwändiger: „Um einen Fingerabdruck nachzumachen braucht man
nur einen Deckel einer Plastikflasche,
etwas Sekundenkleber, eine Digitalka-
103
mera, sowie Holzleim und einen speziellen, hautfreundlichen Kleber.“ (CCC).
Î Biometrische Sensoren könnten
Authentifizierungen sehr einfach in
der Benutzung machen. Sie sind
aber auch eher einfach bei einem
ernsthaften Angriff zu überlisten.
4.0
Kombination von Geheimhaltung,
Identifikation und Authentifizierung
4.1
HBCI-Kartenleser
Sehr viele Bankkunden verwalten
Ihre Konten online: Überweisungen,
Kontostand oder Daueraufträge sind
schnell und bequem von zu Hause zu
bearbeiten. Dass dabei privateste Daten
wie Kontonummern und Geheimzahlen
über öffentliche Netze, oder gar über ein
ungeschütztes WLAN, gesendet werden, ist den meisten nicht mehr täglich
bewusst. Bei der Sicherheit verlässt man
sich dabei gerne auf die Verschlüsselung der Daten. Dabei ist auch die für
Angriffe anfällig, da die gleiche Hardware sowohl die Banking-Applikation als
auch ggf. die Schadsoftware betreibt.
„70% der Kunden sind stark an Sicherheitsmaßnahmen interessiert, die
hinter den Kulissen angewendet werden (z.B. risikobasierte Authentifizierung); 81% der Kunden würden sich
wohler fühlen, wenn ihre Bank eine
derartige Technologie implementiert
hätte
87% sind an Site-to-UserAuthentifizierung interessiert; mehr als
50% wünschen dies sogar zusätzlich
zu oben genannter Technologie“
(hbi.de 2006).
Immerhin hat auch der Urheber der
Studie, RSA.com, bereits erkannt,
dass Sicherheit nicht nur mit technisch
orientierten Mitteln, wie Verschlüsselung, erreicht wird; zusätzlich muss
der Benutzer als ein Glied in der Sicherheitskette mit einbezogen werden:
„Consumers value better security, but
financial institutions need to provide it
with a minimum level of perceived distraction.
Consistency of process increases the
perception of ease-of-use and reduces
the perceived distraction in performing
security measures online.
It is important to consistently reassure
users as to the security of their online
information without needlessly alarming them“2
Î Der Sicherheitsgewinn gegenüber
Attacken wäre beträchtlich, die
Anschaffung, Installation und Integration von HBCI-Kartenlesern
scheint jedoch zu aufwändig zu
sein.
4.2
Abb 4: Kartenleser der Klasse 3 (Bild: SCM)
Dabei würden sich viele mehr Sicherheit
wünschen, wenn sie nicht selber damit
befasst wären, wie eine Studie der ITSicherheits-Firma RSA.com in 2006
ergeben hat:
104
und müssen Ärzte und Zahnärzte in
Zukunft die von ihnen in Form „elektronischer Rezepte“ ausgestellter Verordnungen mit qualifizierten elektronischen
Signaturen versehen. Apotheker müssen dann als Gegenstelle die dispensierten Verordnungen mit ihrem HBA ebenfalls elektronisch signieren.
Die Gesundheitskarte
Die elektronische Gesundheitskarte kommt - und mit ihr der Heilberufsausweis (HBA). Mit diesem können
2 Interessant ist hier auch die Unterscheidung zwischen „echter Ablenkung“ und
„wahrgenommener Einfachheit“.
Abb 5: Die Gesundheitskarte (Bild: BMG)
Der HBA dient also insbesondere als
Signaturkarte für die Erstellung qualifizierter elektronischer Signaturen. Dabei
werden dem Benutzer (Arzt, Zahnarzt,
Apotheker) gemäß Signaturgesetzgebung zunächst die zu signierenden Daten angezeigt, bevor er nach erfolgreicher Eingabe einer PIN (Signatur-PIN)
die Erzeugung genau einer Signatur
auslösen kann. Die PIN-Eingabe muss
dabei lokal erfolgen, d.h. direkt an einem
HBA-Kartenterminal.
So sinnvoll dieses Vorgehen aus Sicherheitssicht für qualifizierte elektronische Signaturen sein mag, so stellt die
Vorstellung, dass Ärzte und Apotheker
gezwungen sein könnten, täglich unzählige Male ihre PIN an einem festen Kartenterminal einzugeben, um pro PINEingabe jeweils ein einziges elektronisches Rezept gegenzuzeichnen, die
Gebrauchstauglichkeit des HBA und
damit der elektronischen Gesundheitskarte akut in Frage.
Um den täglichen Umgang mit der elektronischen Signatur in Praxen, Kliniken
und Apotheken zu erleichtern, hat das
Bundesamt für Sicherheit in der Informationstechnik (BSI) technische Richtlinien
für Stapel- und Komfortsignaturen herausgegeben. Diese sollen „Vielsignierern“ nach Eingabe der Signatur-PIN
mehrere Signaturen ermöglichen, ohne
dass dadurch die Sicherheit und rechtliche Bedeutung der Signatur gefährdet
wird.
Die Stapelsignatur erlaubt die Erzeugung mehrerer Signaturen unmittelbar
hintereinander - nach dem Anzeigen der
zu signierenden Dokumente (Stapel)
und der daran anschließenden einmaligen Eingabe der PIN.
Die Komfortsignatur erfordert noch weniger Aufwand des Benutzers als die
Stapelsignatur: Zunächst erfolgt die PINEingabe, anschließend kann über einen
längeren Zeitraum (z. B. Öffnungsdauer
der Praxis) signiert werden. Dabei muss
sich der Benutzer jedoch vor Signieren
eines Dokuments oder Dokumentenstapels mittels eines RFID-Tokens oder
eines Biometriemoduls authentisieren.
Um sicherzustellen, dass der Token nur
vom rechtmäßigen Besitzer verwendet
werden kann, sind folgende Möglichkeiten vorgesehen:
x
x
x
Die Aktivierung des Tokens durch
eine 4stellige PIN
Die Aktivierung des Tokens durch
ein biometrisches Merkmal des Besitzers
Andere geeignete Sicherheitsmaßnahmen, die einen Verlust oder die
unkontrollierte Nutzung verhindern.
Die Verwendung einer Token-PIN wäre
aus Sicherheitssicht wünschenswert,
widerspricht aber wiederum dem Komfortgedanken. Es wird daher dem Benutzer auch erlaubt, seine Token-PIN zu
deaktivieren, d.h. den RFID-Token ohne
Authentisierung zu nutzen. Dabei bleibt
aus Usability-Sicht offen, ob und ggf. wie
der Nutzer in die Lage versetzt werden
kann, die Tragweite dieser Entscheidung
zu verstehen und die entsprechende
Verantwortung zu übernehmen.
Die Nutzung eines Biometriemoduls
stößt auf rechtliche und sicherheitstechnische Probleme. Biometrische
Verfahren, die zusätzlich zur wissensbasierten Benutzerauthentisierung
angewendet werden, müssen gemäß
Signaturgesetzgebung einer Bewertung gemäß Sicherheitsmechanismenstärke "mittel" genügen. Bisher
sind Biometriekomponenten nicht entsprechend zertifizierbar. Dazu müsste
zunächst eine Methodik zur Bewertung
des Angriffspotentials biometrischer
Verfahren entwickelt werden.
Î Auch bei der Anwendung der Gesundheitskarte ist es nicht einfach,
einen Kompromiss zwischen Usability und Sicherheit zu finden.
Beide Anforderungen sind jedoch
entscheidend für den Erfolg dieses Konzepts in der Praxis.
5.0
Fazit
Als Fazit kann (wieder einmal)
darauf hingewiesen werden, dass „gute“ Software mehr ist als lediglich funktionierende Software. Im gesamten
Entwicklungsprozess müssen vielfältige funktionale und nicht-funktionale
Anforderungen, wie die der Sicherheit
und Gebrauchstauglichkeit, berücksichtigt werden, um allen, auch sich
zunächst widersprechenden, Anforderungen gerecht zu werden.
Wird aber eine Anwendung primär als
möglichst einfach zu benutzen gestaltet, werden dabei gegebenenfalls Sicherheitsaspekte übersehen.
Im Nachhinein eingebrachte Sicherheitsanforderungen führen wiederum
typischerweise zu zusätzlichen Prozessschritten, die die normale Abfolge
unterbrechen. Beispiele dafür sind
Programme zur Ver- und Entschlüsselung, die nachträglich auf Dateien angewandt werden oder mehrfache Ein-
gaben von verschiedenen Passworten.
Dieses führt mit Sicherheit zu einer
schlechteren Usability der Anwendungen.
Für beide Anforderungsgebiete, Usability und Security gilt sicher, dass die jeweiligen Anforderungen so früh wie
möglich im Software-Entwicklungsprozess ermittelt werden sollten, um in
der Umsetzung angemessen berücksichtigt zu werden.
6.0
6.1
Bücher
Cranor, F.; Garfinkel, S. (2005): Security and
Usability, Sebastopol: O‘ Reilly
6.2
Weblinks – Stand 26.5.2008
BSI: http://www.bsi.bund.de/literat/studien/BioFinger/BioFinger_I_I.pdf - BSI-Studie zur
Fingerabdrucksensoren
CCC: http://chaosradio.ccc.de/ctv001.html Anleitung zum Nachmachen von Fingerabdrücken
DGK: http://www.die-gesundheitskarte.de
hae: http://www.haefely.info – Implantierbarer
RFID-Chip
hbi.de: http://www.hbi.de/clients/ RSA/info/0717-06_Usability_Concept_Testing_Release.doc (Bereich Infomaterial: „RSA SecurityStudie über Sicherheit von online-Banking“)
Metro: http://www.metrogroup.de/servlet/PB/menu/1155070_l1/index.html RFID-Tags
RFID: http://www.heise.de/tp/r4/artikel/18/18845/1.html Gefahren von RFID
Uni B: http://www.informatik.uni-bremen.de/
~lechner/SoftwareTrends-Web/index.htm Fingerabdrucksensoren
WLAN: http://www.heise.de/newsticker/meldung/77921 - Urteil gegen Betreiber von
ungesichertem WLAN
105
Dann macht es doch selbst! –
Entwickler als Usability-Experten
Ronald Hartwig, Maren Mäuselein
Hansastraße 7-11
44137 Dortmund
[email protected];
[email protected]
www.uid.com
Sabine Özalp, Bernd Kieseler
Verwaltungs-Berufsgenossenschaft
DV/I
Deelbögenkamp 4
22287 Hamburg
[email protected];
[email protected]
Abstract
Der Beitrag schildert einen Praxisfall, in
dem Entwickler im Laufe eines Projektes
von Skeptikern zu echten UsabilityStakeholdern wurden. Der Weg von „Wir
machen das doch schon 10 Jahre“ bis
zum „Wir werden einen Vortrag über
1.0
Motivation
Usability hat in den letzten Jahren in
der Entwicklung interaktiver Systeme
(erfreulicherweise) einen immer
größeren Stellenwert eingenommen.
Software-Entwicklungs-Unternehmen
haben dabei in der Regel die Wahl
zwischen zwei Alternativen:
1.
2.
1.1
Eine eigenen Usability-Abteilung
aufbauen
Einen externen Dienstleister
beauftragen
Eine eigene Usability-Abteilung
aufbauen
Diese Variante ist bei einigen
wenigen sehr großen Konzernen
anzutreffen. Um eine solche Abteilung
zu rechtfertigen, muss ein hoher
Durchsatz an Projekten vorhanden sein,
um diese Gruppe dann auszulasten.
Die Herausforderung bei dieser
Konstruktion besteht zum einen darin,
dass die „Propheten im eigenen Land“
grundsätzlich auch den Kosten- und
Zeitdruck des Mutterunternehmens
mitverantworten müssen und so
aufwandsbehaftete Entscheidungen
schwierig zu begründen sein können.
106
Usability auf dem WUD 2008 halten“
soll zeigen, wie man Usability
Engineering nachhaltig verankert,
auch und gerade in der Zeit, in der die
externen Dienstleister längst zur
nächsten Aufgabe weitergezogen sind
Keywords
Ein weiteres potenzielles Problem ist
oft die einseitige Ausrichtung des
Unternehmens, die dann über kurz
oder lang auch bei den eigenen
Usability-Kräften eine gewisse
Betriebsblindheit mit sich bringen
kann.
projektbegleitende Expertise für einen
definierten Zeitraum hinzugeholt.
Für sehr viele mittelständische und
kleinere Software-Unternehmen
kommt eine solche Konstruktion schon
aus Kostengründen nicht in Frage –
etwa weil Entwicklungen am User
Interface nur gelegentlich und
zeitweise im Vordergrund stehen.
1.2
Einen externer Dienstleister
beauftragen
Um die beschriebene Lücke zu
füllen, hat sich eine ganze Reihe von
Dienstleistern etabliert, die
Unternehmen in den Bereichen
Design, Usability Engineering, User
Experience und Software-Entwicklung
unterstützen. Der UPA-Branchenreport
zeigt, wie vielfältig der Markt in diesem
Bereich geworden ist.
User Experience, UPA, Coaching,
Training, User Centered Design,
Consulting
Die Herausforderungen bei diesem
Vorgehen liegen in zwei Faktoren: Zeit
und Geld. Da externe Dienstleister
preislich auf dem Niveau von
Unternehmensberatungen agieren
(müssen), stehen diese Preise schnell in
Diskussion – auch und gerade im
Vergleich zu internen Ressourcen.
Insbesondere die Dauer der
Unterstützung wird aus diesem Grunde
so minimal wie möglich gehalten.
Daraus kann ein Problem bei der
Nachhaltigkeit der Verbesserung
entstehen: Ein begrenztes Vorgehen
steht im Widerspruch zu den Ideen
eines Lifecycle-orientierten,
ganzheitlichen Vorgehens, bei dem
Nutzerfeedback und
Weiterentwicklungen genauso
nutzerzentriert vorgenommen werden
sollen, wie die bereits erfolgten
Arbeitspakete.
2.0
Externe Unterstützung wird dabei
entweder in Form konkreter
Untersuchungs- und
Gestaltungsaufträge oder als
Lösungsansatz „Consulting &
Training“
Ein möglicher Weg zwischen diesen
beiden Alternativen mit ihren jeweiligen
Nachteilen ist die Vermittlung von
Usability-Wissen parallel zur
Projektarbeit, also Consulting (konkrete
Beratung) und Training (Know-howTransfer an die Beteiligten des Kunden).
bestehenden System auch ein
nachhaltiger Know-How-Transfer zum
Auftraggeber vereinbart.
Ein erfolgreiches Beispiel für ein
solches Projekt findet aktuell im Bereich
Versicherungen statt.
Als Vermittlungsmethode bot sich das
didaktische Konzept des Cognitive
Apprenticeship an. Dieses Modell ist
vergleichbar mit der praktischen
Ausbildung in Handwerksberufen und
bestand in diesem Fall aus vier Stufen:
2.1
Ausgangslage
Die größte deutsche gesetzliche
Krankenversicherung, die
Verwaltungsberufsgenossenschaft
(VBG), mit 2.000 Mitarbeitern und rund
6,5 Mio Versicherten betreibt und pflegt
ein eigenes ERP-System. Die
Umsetzung wird dabei in gemeinsamen
Projektteams aus Auftraggeber
(Versicherung) und Auftragnehmer
(Software-Dienstleister) koordiniert,
geplant und umgesetzt.
Die User Interface Design Gmbh (UID)
wurde beauftragt, bei der
Weiterentwicklung projektbegleitend zu
unterstützen.
2.2
Kein klassisches „Hit & Run“
Schnell zeigte sich, dass in einem
System mit einer Komplexität, die an
Branchenriesen wie SAP heranreicht,
mit einem einmaligen Einsatz nur mit
sehr hohem Aufwand mehrerer
Personenjahre Usability Engineering
konventionell extern durchgeführt
werden könnte.
Allein 5.000 verschiedene Vorgänge und
Masken und mehrere hundert
Aufgabenszenarien, die über einen
Zeitraum von über 15 Jahren entstanden
waren, konnten nicht in der
bereitstehenden Zeit und mit
vertretbarem Personaleinsatz extern
bewältigt werden. Der Engpass liegt in
diesem Fall dann insbesondere in der
monetären Ausstattung des
Gesamtprojektes und des für Usability
generell bereitgestellten Anteils.
2.3
Cognitive Apprenticeship als
Lehrmodell
Die Lösung ist ein Team aus
Mitarbeitern des Auftraggebers
(Versicherung), seines Auftragnehmers
(Software-Dienstleister) und des
Usability-Unternehmens.
Als Ziel des Projektes wurde neben
konkreten Verbesserungen am
x
x
x
x
Der Dienstleister schafft
gemeinsam mit dem Kunden eine
Grundlage.
Der Dienstleister legt vor, der
Kunde sieht zu.
Der Kunde arbeitet unter
Begleitung des Dienstleisters.
Der Kunde arbeitet weitgehend
eigenständig, der Dienstleister
steht für Fragen und zur
Qualitätssicherung der Ergebnisse
zur Verfügung.
Konkret bedeutete dies, dass UID das
Team zunächst in kurzen intensiven
Schulungen mit den Grundlagen des
Themas Usability vertraut gemacht
hat. So entstand eine gemeinsame
Sprache für den weiteren Verlauf des
Projekts. Dabei wurden zentrale
Tätigkeiten wie die
Nutzungskontextanalyse,
teilnehmende Beobachtungen,
Usability Testing und
Requirementsengineering zunächst
besprochen und geschult.
Im weiteren Projektverlauf wurden
diese Tätigkeiten dann zunächst vom
Kunden begleitet und intensiv
besprochen. Dies stellte schnell den
Bezug zu seinem konkreten
Anwendungsfall her. So entstand eine
Motivation für die Wissensaufnahme.
Schließlich gibt es im Bereich der
Software-Entwicklung bis heute
Vorbehalte und eine unterschwellige
Trennung zwischen Software
Engineering und Usability. Um diese
zu überwinden ist es essentiell, schnell
und glaubwürdig die Relevanz des
Themas am konkreten Fall zu
demonstrieren.
2.4
Do-it-yourself
Im nächsten Schritt führten die
Entwickler und Projektmanager selbst
die Erhebungen und Tests vor Ort bei
ihren Nutzern durch. Waren die
Schulungen und auch das ausführliche
Erläutern des Usability Engineering noch
selbstverständliche Bestandteile des
„normalen“ Vorgehens, so war diese
Phase neu für die Beteiligten.
So erprobte und hinterfragte der Kunde
die bisherigen Lehr- bzw. Lernerfolge in
der realen Arbeitswelt. Vieles, was in
Übungen oder beim Zusehen noch trivial
aussah („Wie frage ich einen Nutzer?“),
wurden zu echten Herausforderungen
für die angehenden Inhouse-UsabilityEngineers. Anders als bei einer
einmaligen Schulung war der UsabilityDienstleister im gesamten Verlauf
verfügbar. Er konnte helfend und
korrigierend eingreifen, wenn Entwickler
begannen, mit dem Nutzer zu
debattieren, dass er sich an dieser Stelle
doch anders verhalten solle.
Es blieb an dieser Stelle nicht aus, dass
nicht alle Untersuchungsergebnisse am
Ende gleichermaßen belastbar waren.
Um diesem (erwarteten) Fakt Rechnung
zu tragen, waren die untersuchten
Stichproben bewusst großzügig gewählt.
So konnten eventuelle Datenlücken im
Nutzungskontext leicht gefüllt werden.
2.5
Seeing is believing
Zu diesem Zeitpunkt ein besonders
wirksamer Effekt: Die Entwickler waren
selbst gezwungen, die Mängel des
Systems aus der Sicht des Nutzers zu
dokumentieren. Statt einer punktuellen
oder unpopulären externen Stelle, deren
Glaubwürdigkeit zum Selbstschutz
angezweifelt werden konnte, haben die
Betroffenen selbst nun direkt mit den
Beteiligten gesprochen.
An diesem Punkt kippte die bis dahin
eher abwartend, skeptische Stimmung
bei den Entwicklern zugunsten eines
ehrlichen Engagements. Im Sinne der
Nachhaltigkeit des Projektes war dies
die entscheidende Wendung. Seit dieser
Phase wurde aus einem eher durch
Führungsebenen verordneten Prozess
ein als sinnvoll empfundenes nützliches
Vorgehen, das auch freiwillig gelebt
wird.
Die Begeisterung geht inzwischen so
weit, dass Mitglieder des Projektteams
sich nun selbst als Usability-Experten
auf dem nächsten World-Usability-Day
präsentieren wollen.
107
Aus Sicht UID besteht die Dienstleistung
im Bereich Usability nun in der
personellen Unterstützung und
Qualitätssicherung. Schließlich ist die
Erfahrung des externen Dienstleisters
auch weiterhin eine wertvolle
Ergänzung.
3.0
Vergleich und Fazit
Im Vergleich zu den Alternativen
einer punktuellen Unterstützung oder
aber einer eigenen Usability-Abteilung
hat dieser Mittelweg für den Kunden
einige Vorteile gebracht:
x
x
Kosten: Statt einer dezidierten und
schwer auszulastenden UsabilityGruppe im Unternehmen, gibt es
jetzt eine ausreichende Zahl von
Know-How-Trägern, die das Wissen
in verschiedenen Projekten parallel
zu ihrer Hauptaufgabe
(Projektleitung, Implementierung)
anwenden können. Dies spart
insbesondere im Bereich der
Projektkommunikation wertvolle
Zeit.
Nachhaltigkeit: Die positiven
Auswirkungen des Projektes
überdauern den eigentlichen
Projektzeitraum. Die jetzt im Bereich
Usability motivierten und
sensibilisierten Mitarbeiter wenden
das Wissen nun selbstständig weiter
an, selbst wenn es in den
Projektplänen nicht explizit
vorgesehen ist.
Dzida,W.; Hofmann,B.; Freitag, R.;
Redtenbacher, W.; Baggen,R.; Geis,T.;
Beimel, J.; Zurheiden, C.; HampeNeteler,W.; Hartwig, R.; Peters, H.:
Gebrauchstauglichkeit von Software Ergo
Norm: Ein Verfahren zur
und 11. Bremerhaven: Verlag für neue
Wissenschaft.
Hartwig, R. (2005): Usability Standards,
Gesetze und Entwicklungsprozesse.
Information Management & Consulting
20(3), 2005, S. 64-67. http://www.imc.de/im/pages/abstracts32005.htm
Hartwig, R.; Darolti, C; Herczeg, M. (2003):
Lightweight Usability Engineering Scaling
Usability-Evaluation to a Minimum? In
Jacko, J., Stephanidis, C. (Hrsg.): Human
Computer Interaction - Theory and Practice
(Part I). London: Lawrence Erlbaum
Associates Publishers. S. 474-478.
ISO (Hrsg.) (1996): ISO 9241 - Ergonomic
requirements for office work with visual
display terminals. Internationaler Standard.
Berlin: Beuth Verlag.
ISO (Hrsg.) (1999): ISO 13407 - Benutzerund aufgabenorientierte
Herstellungsprozesse – 1999E.
Internationaler Standard. Berlin: Beuth
Verlag.
Kowallik, P. ; Müller-Prove, M., Strauß, F.
(2005): Requirements-Engineering im
Spannungsfeld von Individual- und
Produktsoftware. i-com (3)2005.
http://www.mprove.de/script/05/icom/
Natürlich besteht auch in einem solchen
Projekt weiterhin Potenzial zur
Verbesserung. So positiv die Motivation
der Einzelnen zu sehen ist, so viel Weg
liegt bei der Umsetzung eines echten
nutzerund aufgabenzentrierten
Entwicklungsprozesses noch vor allen
Beteiligten. Hier ist ein Umdenken bei
Auftraggeber und Auftragnehmer
notwendig, dass in der Praxis dann
gelegentlich wieder engen Zeitplänen
und hohem Kostendruck nachgeben
muss.
4.0
Weiterführende Literatur
Boehm, B.; Egyed, A.; Kwan, J.; Port, D.;
Shah, A.; Madachy, R. (1998): Using the
WinWin Spiral Model: A Case Study. IEEE
Computer 31(7), 1998, S. 33-44.
108
U sability für SA P B u siness By De s i gn
SAP Busi ness ByDesi gn i st ei n e v o lls t ä n d ige on-demand Geschäftsl ösung f ü r
mi ttel ständi sche Unter nehmen. Pr o d u k t iv ität der Benutzer i st ei n wi chti ge s Z ie l b e i
der Pr oduktentwi ckl ung. Um die An f o r d e r ungen von Benutzer n sehr fr üh im En t wi ckl ungspr ozess zu ber ücksi c h t ig e n u n d
i ter ati ve Ver besser ungen der L ö s u n g zu
er mögl i chen wur de ei n benutze r - ze n t r ie r t e r
Entwi ckl ungspr ozess etabl i er t. Un t e r s t ü t zend wur de ei n patter n-basi er t e s UI- Ko n zept entwi ckel t und di e UI Gui d e lin e s in d ie
Desi gn- und Entwi ckl ungswer k ze u g e imp le menti er t.
Di e Aufgaben des User Exper i e n c e Te a ms
i n SAP Busi ness ByDesi gn umf a s s e n d ie
Entwi ckl ung der UI Gui -del i nes , d a s De s ig n
al l er Benutzer ober fl ächen und d ie Be r e it stel l ung ei ner gl obal en I nfr astru k t u r zu r
Dur chführ ung von Akti vi täten mit Be n u t zer n. Di e fol genden dr ei Bei tr ä g e v e r t ie f e n
di e Aspekte UI Patter ns, i nter k u lt u r e lle
Zusammenar bei t und Pr ototypi n g im
Kontext von SAP Busi ness ByD e s ig n .
Andreas Hauser
Vi c e P r e s i d e n t U s e r E x p e r i e n c e
SAP Business ByDesign
SAP AG
6 9 1 9 0 Wa l l d o r f
[email protected]
w w w. s a p . c o m
109
110
User Interface Konstrukte und Key Innovations in SAP
Business ByDesign
Udo Arend
ByD Solution Management
SAP AG
69190 Walldorf
[email protected]
www.sap.com
Johan Christiaan Peters
SAP AG
69190 Walldorf
[email protected]
Abstract
Das komplette User Interface von SAP
Business by Design basiert auf Konstrukten, sogenannten generischen UI
Pattern und UI Floorplans, die aufgrund
von grundlegenden Usability Überlegungen entwickelt wurden. User Interface
Entwickler konfigurieren das User Interface von ByDesign mit speziellen Entwicklungswerkzeugen.
1.0
Der Beitrag beschreibt neben dem für
ERP-Anwendungen neuartigen Interaktionsparadigma die zugrundeliegenden Designprinzipien und die Bausteine, aus denen sich das User Interface
zusammensetzt. Dabei werden auch
einige der Schlüsselinnovationen von
ByDesign dargestellt.
Keywords
User Experience, UPA, UI Patterns,
Floorplans, SAP Business ByDesign
Einleitung – User Interface Patterns
Die Verwendung von sogenannten
„User Interface Design Pattern“ zur Konstruktion von Benutzungsoberflächen
sind keine neue Idee mehr. Seitdem
Christopher Alexander (1977) wiederkehrende Patterns im Architekturbereich
beschrieb, wurde dieser Typ von Patterns auch in die Welt der Informatik
übertragen.
Borchers (2001) hat den PatternGedanken vom Bereich der Softwareentwicklung in den Bereich des User
Interface Designs übertragen und die
Möglichkeiten an Beispielen demonstriert („Music Exhibits“). Eine Reihe von
sogenannten Pattern Bibliotheken wurden in den letzten Jahren erstellt wie
diejenigen von van Welie (2003)
(http://www.welie.com/) oder Jenifer
Tidwell (1999)
(http://designinginterfaces.com/).
Nachteil dieser Bibliotheken sind, dass
sie ein Sammelsurium von unterschiedlichen Konzepten und Ideen auf
unterschiedlichem Abstraktionsniveau
beschreiben. Außerdem ist oft das da-
Abb. 1: Ein allgemeines Dekompositionskonzept für UI Design Patterns (Arend, 2004)
hinterliegende theoretische Konzept
unklar.
Bei SAP starteten wir bereits in 2001
mit der Herleitung eines allgemeinen
Konzeptes für User Interface Patterns.
Die Ergebnisse wurden von Arend
(2004) berichtet.
Wesentlich für den gewählten Ansatz
war die Unterscheidung der Aufgabenhierarchie von der User Interface Hierarchie. Als wesentliche Bausteine wurden
dabei die sogenannten „Floorplans“ und
die „generischen UI Pattern“ identifiziert.
111
Basierend auf dem damaligen Ansatz
wurde 2003 ein erstes Produkt bei SAP
entwickelt, ein CRM System. Allerdings
beschränkte sich damals die Zahl der
Grundrisse auf zwei ApplikationsFloorplans.
Im Jahre 2002 bekamen wir dann die
Möglichkeit, das Gesamtkonzept eines
User Interfaces für ein komplett neu zu
entwickelndes ERP-System zu erstellen. Im Rahmen eines zweiwöchigen
geschlossenen Workshops wurde die
wesentliche Vision erstellt. Die Vision
ging weit über die Verwendung von Design Patterns für Applikationsgrundrisse
hinaus und entwickelte ein komplett
neues Anwendungsparadigma. Die generellen Anforderungen an ein neuartiges ERP-Sytem wurden damals zusammen mit der globalen Marketingabteilung formuliert. Daraus wurde eine
Vision erarbeitet, die den Benutzer als
„Information Worker“ in den Vordergrund
stellt, und davon ausgeht, dass der Benutzer von Dateneingabetätigkeiten
weitgehend befreit ist und nur mehr kontrollierend in den Ablauf von Prozessen
eingreift. Die Vision entstand also bevor
auch nur eine Anwendung programmiert
war. In den folgenden zwei Jahren wurde die Vision schrittweise verfeinert und
ergänzt. Die Implementierung des Produktes „SAP ByDesign“ dauerte dann
noch bis 2007.
In diesem Beitrag werden die Grundideen dieses neuartigen Paradigmas
erörtert und einige der Schlüsselinnovationen vorgestellt.
2.0
Wie sind Grundrisse (Floor Plans)
aufgebaut?
Ein Grundriss ist ein abtraktes Layout bestehend aus UI Pattern, die in
einer räumlichen Beziehung auf dem
User Interface stehen. Dabei gibt es UI
Pattern, die einen bestimmten Grundriss
konstituieren und UI Pattern, die entsprechend der Aktivität des Benutzers
112
an dafür vorgesehenen Bereiche eingefügt werden (Content Pattern). Abb.
2 zeigt wie der Grundriss eines Workcenters aus den konstituierenden Pattern „Portal Header“ und „Contextual
Navigation“ und dem Content Pattern
„Object Worklist (OWL)“ aufgebaut ist.
Die Bedürfnisse des Benutzers, seine Aufgaben effektiv und effizient durchführen zu können, leiteten die Entwicklung der Bausteine für das User Interface.
Abb. 2: Pattern konstituieren einen Workcenter Grundriss
3.0
Grundannahmen für den Entwurf der Benutzungsoberfläche
von ByDesign
Die Enterprise Service Architecture von SAP Business byDesign trennt
das User Interface von der Applikationslogik. Dabei verhalten sich die Business Objekte aufgrund von standardisierten Interfaces konsistent zum
Frontend. Diese Backend Services
können in vielen Business Szenarien
wiederverwendet werden. Das eigentliche User Interface wird für einen bestimmten Business Process nur noch
aus den Services einerseits und den
Grundrissen und UI Pattern andererseits konfiguriert.
Die Vorteile der Verwendung von
standardisierten Konstrukten liegen darin, dass für vergleichbare Situationen
auch gleiche Grundrisse und UI Pattern
verwendet werden. Damit läßt sich ein
hohes Maß an Konsistenz innerhalb
eines komplexen Produktes erzielen.
Darüberhinaus läßt sich das Navigationsmodell innerhalb des Systems vereinheitlichen. Wenn die „richtigen“
Grundrisse definiert wurden und in einen
sinnvollen Ablauf gestellt werden (Navigation), lassen sich die einzelnen Bestandteile vereinfachen und dem jeweiligen Benutzungskontext anpassen. Damit läßt sich eine Flexibilisierung und
Individualisierung der Abläufe erreichen,
da Folgeschritte sich durch die jeweilige
Aktivität des Benutzers bestimmen.
4.0
Die wesentlichen Konstrukte von
ByDesign
Die folgende Abb. zeigt die wesentlichen Grundrisse von ByD.
Konzeptuell sind Grundrisse auf der
Portalebene von denen auf der Anwendungsebene zu unterscheiden. Grundrisse auf der Portalebene, das sind
„MyHome“ (Control Center) und eine
rollenspezifische Anzahl von Workcentern dienen dazu, dass der Benutzer
seine ihm zugewiesene Aufgabe oder
sein Arbeitsobjekt auswählt. Darüberhinaus werden dem Benutzer weitere Informationen zur Verfügung gestellt, die
er braucht, um sich für eine Folgeaktivität entscheiden zu können (z.B. Reporting Snippets). Grundrisse auf der Anwendungsebene (unten im Bild) erlauben dem Benutzer bestimmte wohldefinierte Aktivitäten auszuführen. Entsprechend eines Aktivitätstyps werden dem
Benutzer bestimmte Grundrisse angeboten.
4.1
Factsheets
Factsheets stellen eine Art 360° Sicht
auf oder von einem Business Objekt
dar. Wesentliche Informationen werden dem Benutzer auf einem Blatt
(read-only) zur Verfügung gestellt.
Entweder kann der Benutzer mit dieser
Information seine Aufgabe bereits abschließen („Information Worker“) oder
er kann gezielt zu einer Bearbeitung
verzweigen.
4.2
renter gemacht werden, wenn sie in
einen sequentiellen Ablauf abgebildet
werden. So besteht der Prozess aus
Aufgabenschritten, durch die das System den Benutzer führen kann (vgl. Wizards). Werden noch Möglichkeiten geboten, Aufgabenschritte zu überspringen
bzw. dynamisch zur Laufzeit neue
Schritte einzublenden, vereinfacht sich
der Ablauf für den Benutzer dramatisch.
Quick Activity
Traditionell riefen Benutzer aus einem
Anwendungsbaum eine komplexe
“Allzweck”-Applikation auf um sich
dann zu überlegen, wo und wie dort
Daten einzugeben oder zu verarbeiten
seien. Die Quick Activity stellt dagegen
einen stark vereinfachten Grundriss
dar, der einem Benutzer im Kontext
einer Aufgabe genau die Informationen
oder Daten liefert, die er verarbeiten
bzw. eingeben muß. Sie ist damit Teil
eines Business Processes. Idealerweise können 80% der Aufgaben bereits
hier erledigt werden.
4.3
Guided Activity
Komplexere Business Prozesse können dem Benutzer dadurch transpa-
Abb. 1: Generische und spezifische Task
Pattern
4.4
Object Instance
Manchmal müssen alle Aspekte eines
Business Objektes auch zusammenhängend dargestellt werden. Der Object
Instance Floorplan stellt also gewissermaßen eine traditionelle Applikation dar. Die Unterteilung in sinnvolle
Sichten kann dabei die Übersichtlichkeit
drastich verbessern. In diesen
Grundrisstyp sollten die Benutzer aber
nur noch in Ausnahmefällen gelangen.
4.5
Anzahl benötigter UI Pattern
Die Zahl der Floorplans ist wie man gesehen hat deutlich kleiner als zehn.
Wieviele Patterns sind dabei notwendig?
Neben den generischen UI Pattern unterschieden wir auch spezifische Pattern, wie z.B. ein Addresspattern.
Man sieht, dass sich die Zahl der generischen Pattern zwanzig nähert, die Zahl
der spezifischen Pattern liegt zur Zeit bei
zehn. Die Liste ist nach oben offen und
weitere Pattern sind bereits in Planung.
Neben Pattern, die unterschiedliche
Dateneingabeformate unterstützen, fin-
Abb. 3: Wesentliche Grundrisse von SAP ByDesign
113
Business Task Management (BTM)
ermöglicht es, Benutzern auf eine einfache und effiziente Weise Aufgaben
zu erzeugen, zu bearbeiten und zu
verwalten. Es ist damit die Basis für
eine flexible Arbeitsteilung zwischen
verschiedenen Personen oder sogar
Unternehmen, in dem das System
Aufgaben einzelnen Benutzern zuordnet oder automatisch in bestimmten
Workcentern anzeigt, wo die Aufgaben
dann vom Benutzer erledigt werden
det man auch Pattern zur Navigation,
zur Darstellung von Arbeitsobjekten
bzw. –aufgaben. Dazu gesellen sich
Reporting-Pattern (ICP) oder auch Wertehilfepattern (OVS, EVS).
4.6
Progressive Disclosure und flexible Navigation
Wesentlich für das Gesamtkonzept ist
das Prinzip des „Progressive Disclosure“. Darunter versteht man, dass ein
Benutzer bereits in einer Startsicht einfache Aktionen ausführen kann und von
dort zu immer detaillierteren Aktionen
fortschreiten kann. Unterstützt wird das
Konzept in der Möglichkeit flexibel zu
folgenden Floor Plans navigieren zu
können. Dazu stehen unterschiedliche
Konstrukte (Function Buttons, Hyperlinks, Common Task Menu, You Can
Also Menu) zur Verfügung. Durch diese
Konzepte kann sich der Benutzer sehr
flexibel durch das System bewegen und
immer einen sinnvollen Folgeschritt finden.
5.0
Die Schlüsselinnovationen im
User Interface von ByDesign
SAP Business ByDesign beinhaltet viele
neue Konzepte, die zusammengenommen ein neues UI Paradigma für ERP
Applikationen bedingen. Einige der Innovationen sollen hier kurz dargestellt
werden:
• Business Task Management
• Embedded Analytics
• Collaboration Window
5.1
Business Task Management
Da Benutzer in mittelstandischen Unternehmen haufig einen sehr breiten Aufgabenbereich haben, brauchen sie Unterstützung bei der Organisation ihrer
Aufgaben. Diese Unterstützung wird von
ByDesign mittels Business Task Management angeboten.
114
Incoming
Payment
Trytomap
Payment
toDueItems
AutomaticClearing(95%)
Excepti
on
Done
AutomaticClearingnotsuccessfulManual
Clearing(5%)
Accountant
können.
Abb. 2: Beispiel Clearing Ablauf
Ein gutes Beispiel ist „Clearing“ in Financials. Hier werden Zahlungseingänge mit noch offen Posten verbunden. In 95% der Fälle geschieht das
automatisch, in den verbleibenden
Fällen muß ein Buchhalter die Zuordung machen. Der zuständige Benutzer wird automatisch vom System ermittelt und bekommt die Aufgaben in
seiner Workinbox des Due Management Workcenters angezeigt. Der
Benutzer kann direkt aus dem Workcenter heraus den zugehörigen
Floorplan öffnen und die Zuordnungen
durchführen.
Business Task Management unterstützt unterschiedliche Aufgabentypen:
Fertigstellung, Ausnahmeverwaltung,
Alarm und Eskalation, Genehmigung,
Mitteilung / Information, oder benutzerinitierte Aufgaben. Jeder Aufgabentyp
ist ein eigenes Pattern, das vom System zu Verfügung gestellt wird und
mittels welchem auf konsistente Weise
und mit geringem Entwicklungsaufwand
ein entsprechendes User Interface angeboten wird.
5.2
Embedded Analytics
SAP Business ByDesign bietet den Benutzern unterschiedliche Analysewerkzeuge an. Sehr innovativ ist dabei vor
allem das Konzept der „Embedded Analytics“, das es ermöglicht, in den Applikations Workcentern Datenanalysen
basierend auf (fast) Real Time Daten
auszuführen. Damit können Benutzer
alle für sie relevanten Daten aus dem
ganzen Unternehmen direkt einsehen.
Üblicherweise ist das sonst nur mit separaten Analysetools möglich, die aber
keine Real Time Daten anzeigen können.
Bei dem Design der Embeded Analytics
hat Markforschung und User Research
ergeben, dass mittelständische Unternehmen wenig Geld und Zeit haben,
sich Analysetools selbst zu konfigurieren. Sie brauchen deswegen eine
schnelle und intuitive Implementierung
ohne weiteren Wartungsaufwand.
Abb. 3: Die Auswahl einer vordefinierten
Analyse Funktionalität
Das Collaboration Window wird unter
anderem als Call Center Ersatz benutzt
und bietet dann mittels automatischer
Anrufererkennung direkten Zugriff zu
den wichtigsten Daten der anrufenden
Partei und zu relevanten Funktionen.
Diese sind im Business Context gesammelt und werden je nach Benutzungskontext geändert.
Abb. 5: Collaboration Window Contacts
5.3
Vorteile des gewählten Ansatzes
In idealer Weise verbinden sich durch
dieses integrierte UI Konzept die Vorteile für den Benutzer (hohe Konsistenz,
einfache Bedienung, transparenter Benutzungskontext) mit den Vorteilen für
ein Unternehmen. Die folgende Abb.
zeigt, wie sich einzelne Vorteile für den
Benutzer auch positiv auf Geschäftsabläufe auswirken.
Abb. 4: Embedded Analytics in Form eines
eingebetteten Berichtes (rechts oben) und
eine Reportliste (links unten)
Das wird durch das sogennante „Scoping UI“ ermöglicht, in dem der Benutzer
sich Analysepakete auswählen kann.
Damit wird automatisch die benötigte
Funktionalität für die Benutzung von
Embedded Analytics aktiviert und vordefinierte Reports und kleine eingebettete Reports werden zur Verfügung gestellt. Durch Benutzeranalysen hat sich
ergeben, dass Mitarbeiter meistens einen sehr breiten Aufgabenbereich abdecken müssen und dazu integrierte Daten
brauchen, die Informationen aus dem
ganzen Unternehmen direkt im Applikations User Interface anbieten.
6.0
Abb. 6: Collaboration Window Tasks
Toastertypealerts
Automaticanmanual
BusinessPartnerlookUp
Collaboration Window
Sehr wichtig in SAP Business ByDesign
ist die Unterstützung von kooperativen
Szenarien, in denen mehrere Personen
interagieren. Das Collaboration Window
spielt dabei eine zentrale Rolle und integriert den Zugriff auf Geschäftspartner
und ihre Kontaktdaten (s. Abb. en 8 und
9). Abb. 10 zeigt eine Liste von offenen
Business Task Management Meldungen
und den möglichen Folgeaktivitäten.
Contextawareaccessto
businessfunctions
PhoneFunctions
DirectAccesstotheBusinessByDesign
system
Abb. 7: BTM Meldung mit Collaboration Window und Applikationsscreen
115
Eine Grundeigenschaft des gewählten
Ansatzes ist natürlich die Erweiterbarkeit
um neue Floorplans und neue UI Pattern. Außerdem lassen sich vorhandene
Konstrukte leicht ändern.Wir sind überzeugt, mit dem gewählten Ansatz eine
völlig neue Generation von ERPSystemen ermöglicht zu haben, die wirklich den Benutzer und seine Aufgaben in
den Mittelpunkt stellt.
7.0
Alexander C. (1977). A Pattern Language:
Towns, Buildings, Construction. Oxford University Press, New York.
Arend U. (2004). Effiziente Konstruktion von
Benutzungsoberflächen aus konfigurierbaren
Bausteinen. In Hassenzahl, M.,Peissner, M.
Eds, Usability Professionals 2004.
Borchers J. (2001). A Pattern Approach to
Interaction Design, Willey Series in Software
Design Patterns, Wiley.
Tidwell J. (1999) Common Ground: A Pattern
Language for Human-Computer Interface
Design.
http://www.mit.edu/~jtidwell/ui_patterns_essa
y.html
Tidwell J. (2005). Designing Interfaces: Patterns for Effective Interaction Design. O'Reilly
Media, Inc. (November 21, 2005).
Van Welie M. (2003). Web Design Patterns.
http://www.welie.com/patterns/index.htm
Abb. 11: Vorteile sowohl für den Benutzer als auch für die Abläufe
116
Designing for People: Integration des User Centered Design
(UCD) in den globalen Entwicklungsprozess in SAP
BusinessByDesign
Daniel Markwig
SAP AG
69190 Walldorf
[email protected]
Sabine Finke
SAP AG
69190 Walldorf
[email protected]
Isabel Weissbrodt
SAP AG
69190 Walldorf
[email protected]
Abstract
Die über mehrere Länder und verschiedene Teams verteilte Projektstruktur der
neuen Produktentwicklung SAP Business ByDesign stellt Anforderungen
sowohl an die Definition des Entwicklungsprozesses als auch an die Arbeitsweise in den Teams.
1.0
Einleitung
Im Umfeld der Entwicklung der neuen integrierten Software zur Planung
und Steuerung von Unternehmensfunktionen SAP Business ByDesign ergaben
sich für SAP vielfältige Herausforderungen, die es nötig machten, den Gestaltungsprozess für Software an die Gegebenheiten anzupassen:
x
x
x
x
SAP Business ByDesign soll den
Markt für mittelständische Unternehmen ansprechen, in dem SAP
bisher wenig Erfahrung hat.
SAP Business ByDesign verfolgt ein
für SAP neues Businesskonzept
(“Software as a Service”).
An der Entwicklung der Software
sind drei voneinander unabhängige
Entwicklungsorganisationen innerhalb SAP beteiligt.
Die an der Entwicklung der Software
beteiligten Organisationen sind über
sechs Länder mit unterschiedlichen
Zeitzonen verteilt (USA, Irland,
Deutschland, Israel, Indien, China).
Der Beitrag beschreibt den speziellen
SAP Business ByDesign Entwicklungsprozess, der sowohl die Integration des User Centred Design Prozesses gewährleistet als auch die Belange
von Entwicklung, Produktdefinition und
Knowledge Management berücksichtigt. Ebenso werden die Aspekte eines
interkulturell aufgestellten UI Design
Teams beleuchtet.
Keywords
x
beit von Mitarbeitern aus vielen verschiedenen Ländern und Kulturen beruht. Dies gilt auch für UI Design Teams.
Das neue Produkt soll gleichzeitig
in mehreren Zielmärkten (u.a.
Deutschland, USA und China) mit
unterschiedlichen (Geschäfts-)
Kulturen und Gesetzgebungen
eingeführt werden.
All diese Voraussetzungen machen
deutlich, dass bei der Entwicklung
eines benutzerorientierten Gestaltungsprozesses drei zentrale Ziele
erreicht werden müssen:
Die Kunden und die Benutzer der neuen Software müssen genau erforscht
und ihr Kontext verstanden werden.
Der dabei angewendete Prozess muss
skalierbar und dokumentierbar sein,
um in einem derart komplexen Entwicklungsumfeld funktionieren zu können. Und schließlich muss der Prozess
von allen beteiligten Parteien verstanden und akzeptiert werden, um effektiv
wirken zu können.
User Centered Design, UPA, Interkulturelles Team, SAP Business ByDesign
Die tägliche Arbeit eines UI Designers
im globalen Umfeld spielt sich im Kommunikationskreuz von Produktdefinition,
User Interface Entwicklern und User
Interface Designern ab. Ein globales UI
Design-Team kann verschiede kulturelle
Aspekte eines UI Designs abdecken und
den direkten Kontakt mit Anwendern vor
Ort nutzen.
Erfahrungsberichte aus der Praxis zeigen, wie Kommunikation optimiert und
gepflegt werden kann, wie mit kulturellen Differenzen umgangen werden soll,
und wie Team Building ein global verstreutes Team zusammenschweißt.
Hinzu kommt, dass die Arbeit in einem Unternehmen wie SAP sehr stark
auf einer erfolgreichen Zusammenar-
117
2.0
User Centered Design
Dazu wurden zunächst einige Pilotprojekte durchgeführt, mithilfe deren Erfahrungen die Prozessdefinition iterativ
erarbeitet wurde. Hierbei standen zwei
Kernelemente im Fokus:
User Centered Design (abgekürzt
„UCD“, zu Deutsch etwa „Benutzerorientierte Gestaltung“) ist zunächst eine Philosophie, die den Benutzer ins Zentrum
des Gestaltungsprozesses für ein Produkt stellt.
User Centered Design versucht den
„Schöpfern“ eines Produktes wie Produktdefinition, Designern, Ingenieuren,
Programmierern oder anderen Beteiligten zu erklären, wer der Benutzer ihres
Produktes ist, was dessen Anforderungen sind und für welche Zwecke er es
einsetzen wird. Desweiteren will UCD
erreichen, dass diese Erkenntnisse über
den Benutzer und seine Anforderungen
in der weiteren Entwicklung des Produkts berücksichtigt werden.
Am Ende soll UCD zu einer verbesserten Brauchbarkeit („Usefullness“) und
Benutzbarkeit („Usability“) des Produktes führen [Nielsen].
Dazu werden verschiedene Phasen im
Entwicklungsprozess durchlaufen, die
zunächst zu einem besseren Verständnis des Benutzers, seines Umfeldes und
seiner Tätigkeit durch (möglichst) alle an
der Produktentwicklung beteiligten Personen führen sollen. Dieses Verständnis
wird nun im Gestaltungsprozess angewendet und das Produkt im Laufe seiner
Entwicklung immer wieder mit den festgestellten Anforderungen des Benutzers
abgeglichen. Dieser Entwicklungsprozess soll iterativ durchlaufen werden.
1.
2.
Abb. 1: Der UCD Process
1.
2.
3.
4.
5.
Plan: Projektkonzept festlegen
Research: Nutzungskontext
verstehen
Design: Anforderungen spezifizieren
Adapt: Lösungen produzieren
Measure: Lösungen bewerten
Im Idealfall werden die Schritte 2 bis 5
dieses Prozesses iterativ durchgeführt,
d.h. mehrfach auf das Produkt angewendet, um eine iterationsweise Steigerung der Produktqualität zu erreichen.
3.0
UCD im Prozess
Um User Centered Design im Entwicklungsumfeld von SAP Business ByDesign zu verwurzeln, musste der in der
ISO 13407 vorgeschlagene Prozess
an die produktspezifischen Gegebenheiten angepasst werden.
Die Erarbeitung eines praktikablen
Prozesses unter Berücksichtigung
der organisatorischen Begebenheiten.
Definition von verpflichtenden Ergebnisdokumenten („deliverables“)
und deren Revisionsprozessen („reviews“).
Das Ergebnis der ersten Pilotprojekte
war, dass die Teamstruktur für eine erfolgreiche Anwendung von User Centered Design verändert werden musste.
Anstatt wie bisher mehrere Entwicklungsorganisationen, Produktdefinition,
Interface Design und Knowledge Management parallel nebeneinander her arbeiten zu lassen und nur gelegentliche
Abgleiche der Projektstatus durchzuführen, wurde ein Ein-Team-Ansatz („Joint
Team Approach“) als äußerst wichtig für
die Effizienz und Effektivität des Prozesses erkannt.
Einzelne Entwicklungsprojekte in SAP
Business byDesign werden also von
einem Projektteam bearbeitet, das zumindest Vertreter von Projektmanagment („Solution Management“), UI Entwicklung, Plattformentwicklung und User
Eine genormte Variante des User Centered Designs ist in der DIN EN ISO
13407 Benutzer-orientierte Gestaltung
interaktiver Systeme festgehalten. Dort
werden folgende Phasen für einen Benutzerorientierten Entwicklungsprozess
vorgeschlagen:
Abb. 2: Der SAP Business ByDesign Entwicklungsprozess
118
Interface Design, sowie Knowledge Management umfassen soll. Diese Teammitglieder begleiten das Projekt über die
gesamte Projektlaufzeit und sind für die
Ergebnisse verantwortlich. Zwar werden
viele Arbeiten während des Prozesses
weiterhin parallel in den einzelnen Abteilungen durchgeführt, aber auf umfassende Abstimmung der Teammitglieder
wird Wert gelegt.
Der Prozess als solcher läuft grob entlang der Phasen der DIN/ISO 13407
vorgeschlagenen Linien, allerdings mit
Veränderungen, die den Anforderungen
eines komplexen Projektteams entsprechen.
Am Ende jeder Phase des Prozesses
findet ein Review der Ergebnisdokumente statt, die dann gleichzeitig die Voraussetzung für die nächste Entwicklungsphase darstellen. In jeder einzelnen Phase finden (mindestens wöchentlich) Teamsitzungen statt, die für ein
iteratives Erarbeiten der Ergebnisse
benötigt werden.
Wichtig ist hierbei anzumerken, dass die
Phase der Produktdefinition (inklusive
User Research, Site Visits, Use Case
Verification) vom Team gemeinsam
durchgeführt und idealerweise in Form
eines mehrtägigen Workshops ausgewertet wird.
3.1
Ergebnisdokumente
Um eine gleichbleibende Qualität
und Dokumentierbarkeit des Prozesses
zu erreichen, wurden für die einzelnen
Phasen im Entwicklungsprozess standardisierte Ergebnisdokumente erarbeitet:
1.
2.
Bucket Approval: Abgestimmter und
bestätigter Projektauftrag
Product Definition: Solution Blueprint (beinhaltet User Roles, Prozessfluss-Diagram, Use Case Portfolio, high-level Use Cases, Interaction Model, evtl. technische
Zusatzinformationen)
3.
4.
5.
6.
3.2
Specification Phase: Software
Requirements Specification (detaillierte Use Cases, Software Requirements, Interaction Model, UI
Specifications, Wireframes)
Software Design: Implementierbare Mockups und DesignDokumente (inkl. Detaildesigns,
Implementierungshinweise und
Testanleitungen)
Implementation: Implementierte
Screens
Solution Test: TestergebnisDokument
Solution Blueprint
User Roles: Textuelle Kurzbeschreibung der wichtigsten Benutzerrolle(n).
Benutzer möglichst optimale Lösung
darstellt.
Technische Restriktionen werden bis
hierher nur insoweit betrachtet, als es
absehbar ist, dass dieses oder jenes
Konzept auch langfristig nicht umsetzbar
sein wird.
Use Case Portfolio: Qualitative Bewertung der Bedeutung der Use Cases in
graphischer Form (Bedeutung für den
Prozess gegen Häufigkeit des Auftretens).
Interaction Model: erste graphische Darstellung der Interaktionen des Benutzers
mit dem System.
3.4
Prozessfluss-Diagramm: Grafische
Darstellung des im Projekt bearbeiteten Geschäftsprozesses.
High Level Use Case: Grobe Beschreibung der einzelnen Use Cases
im Prozess des Projektes.
3.3
Software Requirement Specification
Detaillierte Use Cases: weitere Ausgestaltung der oben definierten Use
Cases.
Interaction Model: weitere Ausarbeitung des oben eingeführten Models.
Wireframes: grobe Darstellung des
User Interfaces der zu entwickelnden
Software.
UI Specification: textuelle Beschreibung der User Interface-Funktionen
und Interaktionen.
Software Requirements: Anforderungsliste an die Programmierung
Wichtig ist anzumerken, dass die bis
hier beschriebenen Lösungen noch ein
so genanntes Zieldesign darstellen.
Das bedeutet, dass bis hierher keine
kurzfristigen technischen Probleme
berücksichtigt werden, sondern ein
Design erstellt wird, dass eine für den
Software Design
Implementierbare Mockups: interaktive
Mockups, die technische Restriktionen
berücksichtigen.
Detaildesigns: detaillierte Ausarbeitung
der Designs.
Testcases: Testfälle, die aus den SRS
generiert werden.
Am Ende jeder Designphase findet ein
Review der erstellten Dokumente durch
alle Teammitglieder und benannte Stakeholders statt.
Die genannten Ergebnisdokumente
wurden nicht nur im Hinblick auf eine
bessere Dokumentierbarkeit des Entwicklungsprozesses erarbeitet, sondern
sollen vor allem auch einem besseren
Verständnis der einzelnen Teammitglieder und ihrer Arbeit untereinander dienen.
3.5
Benutzerfeedback
Um die entwickelten Lösungen immer wieder mit den Anforderungen der
Benutzer abzugleichen werden im Laufe
des gesamten Prozesses Feedbackmöglichkeiten gegeben.
119
1.
2.
3.
4.
5.
User Research, Site Visits
Use Case Validierungen
UI Validierungen
Systemtests
Kundenbefragungen und –besuche
Einführung des Prozesses
4.0
Die Einführung eines neuen Prozesses verlangt erheblichen Aufwand
und oftmals auch eine Umstellung in den
Methoden und Gewohnheiten der Mitarbeiter. Deshalb war und ist es für uns
v.a. wichtig, den Mitarbeitern zu vermitteln, warum dieser Prozess mit all seinen Dokumenten notwendig ist und wie
dadurch ihre Arbeit erleichtert und die
Ergebnisse verbessert werden können.
Zur Prozesseinführung werden wir weitere Pilotprojekte durchführen, um möglichst vielen Mitarbeitern im Rahmen
ihrer normalen Tätigkeit aufzuzeigen,
wie der Prozess angewendet wird und
was seine Ergebnisse sind. Daneben
wird es Workshops mit exemplarischen
Übungen zum Prozess geben, Vorträge
und Vorstellungen in den wichtigsten
Team- und Projektmeetings und eine
zentrale Prozess-Seite im SAP-Intranet,
wo Vorlagen für Dokumente, Prozessbeschreibungen, Tipps zur Durchführung Best Practices und Real Life Reports gesammelt zur Verfügung gestellt
werden.
in voller Ausprägung nur für die wichtigsten Projekte durchgeführt werden.
Als unwichtiger eingestufte Projekte
müssen sich bemühen, die zur Verfügung stehenden Ressourcen auf eine
Art und Weise anzuwenden, die es
ihnen ermöglicht, zumindest die
Grundaspekte des UCD zu verwirkliche.
Der wichtigste Faktor ist hierbei das
„Buy-In“ aller beteiligten Projektmitglieder. Wenn den einzelnen Teilnehmern an der Projektarbeit klar vermittelt werden kann, welche Vorzüge diese Art der Softwareentwicklung auch
für sie hat, ist es meist ein Leichtes,
User Centered Design umzusetzen.
5.0
Globales Teamsetting
Bei SAP als einem global agierenden Unternehmen gehören verteilte
Teams zum Alltag.
Davon ist auch die Arbeit der UI Designer nicht ausgenommen. Die SAP
Business ByDesign User Experience
Gruppe ist über drei Standorte verteilt
und arbeitet dabei eng mit Produktdefinition und Entwicklung zusammen,
die wiederum auf vier Standorten verteilt arbeitet.
Beispiele von SAP Business ByDesign
Teams:
UI Designer in Deutschland, China und
Indien
Produktdefinition in Deutschland, China
Entwicklung in Deutschland, China und
Israel.
6.0
Vorteile und Herausforderungen
Ein global agierendes Team von UI
Designern bringt einige Vorteile mit sich.
Menschen aus verschiedenen Kulturen
gehen unterschiedlich an Problemstellungen heran und bringen frische, innovative Ideen in ein Design-Projekt ein.
Ein internationales Team bietet die Gelegenheit, „über den Tellerrand“ zu
schauen und offener über Dinge nachzudenken.
Ebenso erhöht die Zusammenarbeit mit
Kollegen aus Ländern wie z. B. China,
Indien, USA und Israel die Sensibilität
für kulturelle Unterschiede, die sich u.a.
auch in der Gestaltung von Softwareoberflächen und Interaktionsmustern
niederschlagen.
Der bei SAP Business byDesign entwickelte Prozess beinhaltet alle wesentlichen Prinzipien der User Centered Design Philosophie:
x
x
x
Frühes Fokussieren auf den Endbenutzer, seine Aufgaben und Anforderungen
Iterative Entwicklung
Ständige Evaluierung der Zwischenergebnisse im Entwicklungsprozess
unter Beteiligung von Endnutzern
Natürlich unterliegt er, wie fast alle Entwicklungsprozesse ständigem Zeit- und
Kostendruck. Deshalb kann der Prozess
120
Abb. 3: Das globale SAP Business ByDesign UI Designer Team
Der benutzerzentrierte Designprozess
wird optimal durch die Durchführung von
Site Visits und UI Valididerungen in verschiedenen Ländern unterstützt. Kundenbesuche in China, Usability Tests in
den USA oder Benchmark Tests in Indien: UI Designer vor Ort erstellen entsprechende Prototypen und kümmern
sich um Planung, Durchführung und
Nachbereitung.
Da bei SAP auch die Entwicklungteams
auf verschiedene Standorte verteilt sind,
ist es besonders wichtig, UI Designer
direkt vor Ort zu haben. Diese können
UI Entwürfe, UI Guidelines und Ergebnisse von Usability Tests direkt an die
Entwickler herantragen, wodurch die
Akzeptanz stark erhöht wird. Ebenso
können auftauchende Implementierungsprobleme direkt mit den betroffenen Entwicklern gelöst werden.
Neben den genannten Vorteilen gibt es
natürlich auch einige Herausforderungen, die in einem internationalen Designerteam bewältigt werden müssen.
Da es sich faktisch um virtuelle Teams
handelt, muss die Kommunikation größtenteils über E-Mail abgewickelt werden.
Diese asynchrone Art der Kommunikation führt leicht zu Verzögerungen und
Missverständnissen. Die unterschiedlichen Zeitzonen ermöglichen teilweise
nur eine auf ein bis zwei Stunden begrenzte gemeinsame Arbeitszeit. Aufkommende Designfragen können so
nicht zeitnah gelöst werden oder müssen von den Designern vor Ort abgefangen werden.
Gerade die Anfangsphase eines UI Design Projektes, in der es noch sehr kreativ und ungeordnet zugeht, ist in einem
virtuellen Team kaum machbar. Lebhafte Diskussionen und das Arbeiten am
Whiteboard während der Durchführung
von Designsessions vertragen sich nicht
mit Telefonkonferenz und Netmeeting.
Neben der eigentlichen Projektarbeit ist
die Sicherstellung einer reibungslosen
Kommunikation und die Herstellung
eines gemeinsamen Teamgeistes ein
schwieriges Unterfangen.
Die Koordination der Teammitglieder
muss ohne persönlichen Kontakt, nur
über Telefon und E-Mail erfolgen. Die
Geschäftssprache ist Englisch, aber
trotzdem ist die Kommunikation oft
mühsam und es entstehen Missverständnisse, da kaum jemand ein englischer Muttersprachler ist.
Wenn es unumgänglich ist, ein Projekt
über verschiedene Lokationen zu verteilen, dann sollte diese Verteilung
nach Möglichkeit nur über zwei Länder
erfolgen. Die Zusammenarbeit zwischen zwei Zeitzonen ist machbar,
sobald jedoch eine dritte oder gar vierte hinzukommt, kann dies im
schlimmsten Fall zu einer Lähmung
des gesamten Teams führen.
7.0
Teamwork
Ein Team beschreibt eine Gruppe
von Personen, die sich gemeinsam für
eine Aufgabe einsetzen. Teamwork
beschreibt die Zusammenarbeit von
mehreren Personen an einer gemeinsamen Aufgabe [vgl. Der Duden; Bd.
10; 1985 ].
Wie kann mit global verteilten UI Designern ein Team aufgebaut und erhalten werden?
Wie kann ein Teamgeist entfacht werden, welcher die räumliche Distanz
vergessen lässt?
Kommunikation und Transparenz sind
hier die Schlüsselworte.
7.1
Interkulturelle Kommunikation
Interkultureller Kommunikation beschreibt das Aufeinandertreffen von
Menschen aus unterschiedlichen Kulturen. Hierbei können Probleme und
Missverständnisse auftreten, da die
Kommunikationsgewohnheiten des
jeweiligen Gegenübers oft nicht voll-
ständig bekannt sind. Diese Missverständnisse kommen sowohl in der verbalen als auch umso häufiger in der
nonverbalen Kommunikation zum Tragen.
Im heimischen Büro kommunizieren
Mitarbeiter direkt miteinander, Themen
können auf Zuruf diskutiert werden,
Rückfragen können unmittelbar beantwortet werden. Auch ein gemeinsames
Mittagessen oder ein Kaffee am Mittag
ist üblich. Gerade diese Möglichkeiten
der direkten Kommunikation sind im
global verteilten Team sehr selten und
kostbar.
Die Erfahrung zeigt, dass aufgrund der
räumlichen Distanz die Kommunikation
in der Hauptsache über online Werkzeuge wie E-Mail und Remote DesktopSharing wie Netmeeting, Interwise, sowie Videokonferenzen und Telefon reduziert ist.
Um den Kommunikationsfluss unter diesen erschwerten Rahmenbedingungen,
wie räumliche Distanz und Zeitzonen
erfolgreich aufzubauen, ist besonders
das Verstehen der anderen Kultur der
erste Schritt zur guten Kommunikation.
Ein Interkulturelles Training ist für alle
Teammitglieder empfehlenswert. Verhaltensmuster und Kommunikationsgewohnheiten sind in jeder Kultur unterschiedlich, auch im Businesskontext. Ein
interkulturelles Training hilft, diese Unterschiede frühzeitig zu erkennen und
offen mit ihnen umzugehen. E-Mails
könnten beispielsweise anders formuliert
werden, um beim Kollegen die gewünschte Information oder Reaktion zu
erhalten. Arbeitsanweisungen, Projektmeilensteine, müssen möglicherweise
auf eine andere Art und Weise kommuniziert werden.
Das persönliche Kennenlernen ist besonders zu Beginn eines Projekts sehr
wichtig. Zumindest der Teamleiter sollte
alle Teammitglieder persönlich kennen
lernen. Hier können soziale Kontakte
121
geknüpft werden, die Nähe schaffen und
nachhaltig das Zusammenarbeiten erleichtern. Der Zusammenhalt des Teams
wird durch regelmäßige Ereignisse gestärkt.
Folgend werden einige Maßnahmen
beschrieben die im SCM UI Designer
Team (SAP BusinessBy Design) erfolgreich durchgeführt werden.
Regelmäßige wöchentliche Teammeetings (1,5 Stunden) fördert den Austausch zwischen den Teammitgliedern.
Die Inhalte können von allen Teammitgliedern gleichberechtigt beigesteuert
werden. Beispielsweise könnte in einen
globalen UI Designer Team, Designfragen im Team diskutiert werden, oder
auch besondere Projekte des Standortes vorgestellt werden. Nach Möglichkeit
sollten der Tag und die Zeit für dieses
Meeting stabil bleiben. Als besonders
verbindend haben sich Videokonferenzen in Verbindung mit Remote DesktopSharing wie Netmeeting oder Interwise,
erwiesen.
Regelmäßige wöchentliche Status Meetings (30 Minuten-1 Stunde) fokussiert
auf den Projektstatus, hier kann von
jedem Teammitglied der aktuelle Stand
zum Projekt erfahren werden, mögliche
122
Stillstände analysiert werden, Andere
Teammitglieder können Lösungsvorschläge oder Erfahrungen einbringen.
Regelmäßige halbjährliche Team Lesson-Learned Workshops(1-2 Tage)
fördern die Transparenz, Stimmungen
und Wünsche der Teammitglieder
können im Team diskutiert werden.
Daraus folgende Teamziele oder nötige Änderungen in der Teamstruktur
können thematisiert und adressiert
werden.
7.2
Transparenz unter den Teammitgliedern
zeichnet sich durch offene Kommunikation und Teilen der Erfahrungen oder
Problemen aus.
Wie vorher beschrieben, können regelmäßige Status Meetings und Team Lessons Learned die Transparenz im Team
steigen. Wie sich in den vergangen Jahren herauskristallisiert hat, ist mangelnde oder gar fehlende Transparenz einer
der Schlüsselfaktoren für Unzufriedenheit in einem globalen Team.
Transparenz im Team
Transparenz definieren wir in unserem UI Designer Team zum einen
vom Teamleiter zum Team und zum
anderen zwischen den Teammitgliedern untereinander.
Transparenz vom Teamleiter zum
Team zeichnet sich durch klare Kommunikation aus. Klarheit in Bezug auf
Erwartungen, die an Kollegen gestellt
werden, sowie Klarheit in Bezug auf
die zu erreichenden Ziele. Ebenso
muss der Teamleiter jederzeit Klarheit
über den aktuellen Stand des Projekts
haben, ob es unerwartete Probleme
oder andere Faktoren gibt die das Projekt beeinflussen können.
Rolle und Einfluss von Prototyping Tools in einem
industrialisierten, pattern-basierten UI-Enwicklungsprozess
Thomas Uhl
SAP AG
69190 Walldorf
[email protected]
www.sap.com
Abstract
Der Beitrag will Erfahrungen aus der
Tool-gestützen Mockup-Entwicklung bei
SAP Business ByDesign beleuchten.
Rolle und Einfluss der genutzten Tools
in verschiedenen Projektphasen sollen
aufgezeigt werden.
2005 entstand auf Basis der Erfahrung
1.0
Einleitung
mit diversen extern verfügbaren Tools
sowie ersten SAP-eigenen MockupTools der Ansatz für ein Patternbasiertes UI Design-Tool. Stärken und
Schwächen dieses Ansatzes werden
kritisch beleuchtet. Zudem wird ein
Ausblick in aktuelle Weiterentwick-
lungsansätze gegeben. Abgerundet wird
der Beitrag mit einer Demonstration des
aktuell im Einsatz befindlichen Tools.
len Stellen der Applikation anwenden
zu können (Preece 2002).
zur kritischen Diskussion dieses Ansatzes beitragen. Abschließend werden die
momentan bei SAP diskutierten und
teilweise bereits in Entwicklung befindlichen Erweiterungen und Neuausrichtungen des Tools aufgezeigt.
Ein industrialiserter User Interface
Entstehungsprozess agiert im Spannungsbogen zwischen der gewollten
Freitheit des Designs sowie den ebenso
notwendigen wie gewollten Einschränkungen aufgrund architektonischtechnischer Randbedingungen und kostenorientierter Prozessabläufe.
Die Nutzung von Pattern soll einen
effektiven, industrialisierten UI Entwicklungsprozess unterstützen. Zudem
wird das Erreichen eines gerade für
anspruchvolle und umfassende Applikationen erforderlichen Konsistenzgrades der Benutzeroberflächen wesentlich unterstützt.
Für die Erstellung des neuen SoftwareProdukts SAP Business ByDesign hat
man sich für einen Pattern-basierten UI
Grundentwurf entschieden. Dieser Pattern-basierte Ansatz (Arend 2004) verfolgt das Ziel, unterschiedliche Interaktions-Paradigmen über spezifische konfigurierbare User Interface Bausteine
(Pattern) abzubilden. Dabei wird zwischen Grundriss-Pattern und ContentPattern unterschieden. GrundrissPattern legen das grundsätzliche Layout
(Framework) für eine spezifische NutzerInteraktion fest, wohingegen ContentPattern den zentralen Inhaltsbereich der
Benutzeroberfläche spezifizieren.
Das im Folgenden näher beleuchtete
SAP-eigene Tool „UI Wizard“ verfolgt
das Ziel, den Pattern-basierten UI
Grundentwurf auf ein Pattern-basiertes
Prototyping-Tool umzusetzen.
Pattern sollen dazu beitragen, die gewonnenen Erfahrungen bezüglich benutzerfreundlicher Problemlösungen zu
persistieren und „out of the box“ an vie-
Die sich hieraus ergebende Frage ist,
wie sich die bei SAP definierten User
Centered Design-Prozessschritte und
Methoden mit einem solchen Tool vereinbaren lassen und wie dadurch die
Erwartungen insbesondere in Bezug
auf industrialiserte Spezifikationsprozesse vernünftig in Einklang gebracht
werden können.
Im Folgenden werden kurz die wesentlichen Funktionalitäten des bei SAP
Business ByDesign genutzen Prototyping-Tools „UI Wizard“ dargestellt.
Danach sollen einige Fragestellungen
Keywords
User Experience, Prototyping Tools,
SAP, Pattern-based UI
2.0
Kernmerkmale des Prototyping
Tools „UI Wizard“
Folgende Merkmale beschreiben die
Grundfunktionalitäten des „UI Wizard“
2.1
Hauseigene Entwicklung
Das Prototyping-Tool „UI Wizard“ ist
eine hauseigene Entwicklung der SAP
AG.
2.2
Online-Anwendung
„UI Wizard“ steht als OnlineApplikation im Intranet der SAP zur Erstellung von SAP Business ByDesign
Prototypes und Mockups zu Verfügung.
Alle erstellten Mockups stehen zentral
zur Verfügung. Eine lokal lauffähige Variante des Tools zur Erstellung von Mockups existiert nicht.
123
2.3
Assistenten-Ansatz
Im „UI Wizard“ können mit Hilfe vielzähliger Assistenten Pattern-basierte
UIs konfiguriert werden. Die Konfigurationen werden in einer zentralen WebDatenbank erfasst. Diese Konfigurationen werden genutzt, um über eine Render-Engine HTML-Seiten zu generieren.
Diese Render-Engine nutzt dieselbe UI
Control-Bibliothek, die auch für die Erstellung der „Echtanwendung“ herangezogen wird.
2.4
High-Fidelity Mockups
Die erstellten Mockups zeichnen
sich durch eine hohe Realitätsnähe zur
Echtanwendung aus. Auf Grund der
Nutzung derselben UI Elemente und und
der Tatsache, dass auch Business byDesign als SAP Portal Lösung eine
Web-Anwendung darstellt, kann man bei
den im UI Wizard erstellten Mockups in
jedem Fall von High-Fidelity-Mockups
sprechen.
2.5
Tool-gesteuerte Konsistenz
(„consistency out-of-the-box“)
Die Pattern-basiserte UI Mockup
Erstellung im „UI Wizard“ steuert die
konsequente Einhaltung vieler Festlegungen aus den Business ByDesign UI
Richtlinien. Nach der Auswahl aus den
vorhandenen Framework-Pattern
(Floorplans) erfolgt auch auf den einzelnen Screenbereichen (Identification
Area, Contextual Navigation Panel, Content Area) eine klare Benutzerführung zu
den wesentlichen Bestandteilen in den
einzelnen Bereichen.
Als Beispiel sei die Button Area angeführt. Hier folgt die Reihenfolge und
Gruppierung einzelner Action Buttons
klaren Richtlinien aus den UI Guidelines.
Kein Grund also, im Tool mehr Freiheitsgrade als nötig zu gewähren – im
Gegenteil: Die Konsistenz dieses Bereiches wird durch die automatische Gene-
124
rierung im UI Wizard wesentlich positiv
beeinflusst.
2.6
Zentraler Zugriff
Die auf Basis der Konfigurationen
durch Rendering erstellten HTMLSeiten liegen auf einem zentralen Server zur Verfügung.
2.7
Erstellung und gemeinsame
Nutzung von Feldlisten
Im Tool können neben den
Screenkonfigurationen auch Feldlisten
(Screen Objects) hinterlegt werden,
die bei systematischer Nutzung anwendungsweit konsistente Feldbezeichungen unterstützen. Feldlisten können auch Referenzen zu anderen
Feldlisten enthalten. Dadurch kann ein
relationales Datenbankmodel mit (1:1)
und (1:N) Beziehungen nachgebildet
werden.
2.8
Demodaten
Zusätzlich können auch DemoDaten für hinterlegte Feldlisten gespeichert werden, die vor allem bei
größeren abzubildenden Szenarien zu
durchgängiger Demodaten-Anzeige
führt. Solche realistische und durchgängig genutze Demodaten fördern
merklich das Verständis der SystemFunktionalitäten sowie die Abbildung
konkreter Use Cases auf den Prototypen.
2.9
Keine Laufzeit-Datenerzeugung
Im Tool können Daten erfasst und
als Demodaten für alle erstellten Mockups genutzt werden. Zur Laufzeit
können jedoch keine Daten generiert
und weitergenutzt werden (z.B. während einer Validierung).
2.10
Navigationsmöglichkeiten
Die ausgerenderten HTMLPrototypes können mittels Navigationselementen miteinander verbunden
werden. Buttons, Links oder andere Absprung-Komponenten können mit Zielen
versehen werden, die auf weitere im
Tool erstellte Screens verweisen.
2.11
Mockup-Repository
Durch die zahlreich vorhandenen
Navigationselemente zwischen einzelnen Screens entsteht ein MockupRepository, das die Gesamtanwendung
bereits vor Beginn der ersten realen
Entwicklung in erstaunlich realitätsnaher
Art und Weise zeigt.
2.12
Versionierung
Durch eine Versionenverwaltung der
Konfigurationen werden Übergabeprozesse an Entwicklungsabteilungen unterstützt. Dies spielt insbesondere aufgrund des globalen Projektansatzes bei
Business ByDesign eine entscheidende
Rolle. Mockups entstehen im Solution
Management von Business ByDesign,
das sich mehrheitlich in Deutschland (St.
Leon-Rot) befindet, wogegen die Entwicklung der Produkt-UIs in Indien
(Bangalore) stattfindet.
2.13
Verbindung zu Business ByDesign Entwicklungssystemen
Momentan bestehen nur wenig direkte Verbindungen zu den Entwicklungssystemen. Die im UI Wizard erstellten Feldlisten können jedoch über eine
„Mapping-Funktion“ mit dem Enterprise
Service Repository, in dem sich die Business Objekte der Echtanwendung befinden, abgeglichen werden. Export/
Import-Funktionen zum „Visual Composer“, dem UI Entwicklungstool für die
Erstellung der realen Business ByDesign Anwendung, existieren momentan
nicht.
3.0
Drei Fragestellungen
Im Folgenden werden drei Fragestellungen in Zusammenhang mit der
Nutzung des „UI Wizard“ im UI Design
Prozess bei Business ByDesign aufgezeigt und zur Diskussion gestellt.
3.1
Ab welchem Zeitpunkt im Gesamtprozess macht die Nutzung
eines Pattern-basierten Prototyping-Tools Sinn?
Die Wahl des entsprechenden Prototyping-Tools für entsprechende Phasen folgt dem Wunsch, möglichst schnell
und einfach das erforderliche Ziel zu
erreichen (Arnowitz 2007). Für sehr frühe hoch-iterative Konzeptphasen macht
die Nutzung des UI Wizard trotz der zur
Verfügung Stellung der gewünschten
Pattern wenig Sinn.
Hier sind Papier-Prototyping, Powerpoint-Skizzen oder Excel-Tabellen nach
wie vor häufig genutzte Hilfsmittel.
Beim Einholen von EndbenutzerFeedback in diesen frühen Phasen
kommt zudem der Aspekt hinzu, dass
die zu hohe Detailgenauigkeit der UI
Wizard Mockups (High-Fidelity) Probanden in ihrer Kritikfähigkeit hemmen
kann. Das endproduktnahe Erscheinungsbild der Screens kann dazu führen, dass die vom Probanden erhaltenen
Aussagen nur noch oberflächliche, kleinere Änderungen betreffen. Umfassendere, grundsätzliche Schwierigkeiten,
die der Proband eventuell mit der konzeptuellen Lösungsidee hat, erscheinen
ihm auf Grund der bereits detailgenau
ausgeprägten Screens möglicherweise
nicht mehr diskussionswürdig.
Für die späteren Phasen des UI Design
Prozesses sowie der Spezifikationsphase und Übergabe an die Entwicklung hat
sich der Ansatz hingegen bewährt. Gerade die einfache Erzeugung und Integration von Demodaten stellt ein wichtiges Hilfsmittel dar. Die Diskussion der
zu erwartenden Funktionalitäten der UIs
lässt sich mit konsequent durchgängigen
Demodaten sehr effektiv untermauern.
Auch spät im Prozess angesiedelte UI
Validierungen lassen sich mit den im UI
Wizard erstellten „clickable“ Prototypes
sehr gut durchführen. Hier ist die endproduktnahe Ausprägung im Gegensatz zu den Konzeptvalidierungen ja
gerade erwünscht.
3.2
Wie können unterschiedliche
Rollen in der Organisation durch
entsprechende Toolunterstützung an Usability-Methoden herangeführt werden?
SAP ordnet bei der Entwicklung
von Business ByDesign die Gruppe
der Usability Experten und User Interface Designer organisatorisch dem
Bereich Solution Management zu. Die
Usability Professionals arbeiten mit
Solution Managern an der Erstellung
aller Business ByDesign Mockups
sowie den UI Spezifikation. Die Solution Manager bringen die notwendigen
Business Skills einzelner Anwendungsbereiche wie Customer Relationship Management (CRM), Supply
Chain Management (SCM), Human
Capital Management (HCM) oder Financials mit. Die Usability Professionals sind für die Einhaltung und Durchführung von Usability Methoden verantwortlich, die durch den SAP User
Centered Design-Prozess festgelegt
sind.
Das komplette Solution Management
wiederum steht im regen Austausch
mit den Produktentwicklern. Die Entwicklergruppe ist aufgeteilt in einen
Gruppe der „Application Plattform“
Entwickler (AP), die für die Generierung des Enterprise Service Repositories mit allen Business Objekt Daten
sowie allen Backend-Funktionalitäten
wie Berechnungen, DatenbankQueries usw. verantwortlich sind sowie
einer Gruppe von UI Entwicklern in
Indien.
Aus dieser Rollenverteilung läßt sich
unschwer erkennen, dass eine der
großen Herausforderungen in diesem
Projekt die konsequente Nutzung und
Durchführung methodischer UCD Prozesse ist. Es gilt, allen Nicht-UsabilityProfessionals die Notwendigkeit und
Nützlichkeit der UCD Aktivitäten ständig
auf’s Neue aufzuzeigen und dadurch
mehr und mehr zu institutionaliseren.
Genau hier können durch konsequenten
Nutzung eines Mockup-Tools entscheidende Fortschritte gemacht werden. So
kann es gelingen, Usability Methoden
durch die Tool-Nutung nicht zwanghaft
zu indoktrinieren, sondern vielmehr mittels der Tool-gestützten Prozesssteuerung deren Nutzung positiv zu motivieren.
Dies ist eine Entwicklung der kleinen
Schritte, während derer der Usability
Professional oftmals von seiner „optimalen“ Methodensicht Abstriche macht und
sich mit Kompromissen zufrieden geben
muss. Nichtsdestotrotz führen auch solche bewusst in Kauf genommene Kompromisse zu einer zwar langsamen, aber
steten und positiv motivierten Durchsetzung von Usability-Methoden in der Gesamtorganisation.
Das genutzte Tool kann versuchen, wie
ein roter Faden durch den UCD Prozess
zu leiten. Dies geht dann über den originären Ansatz eines Prototyping Tools
weit hinaus.
3.3
Industrialisierter UI Entwicklungsprozess versus klassische User
Interface Designer Rolle
Eine häufig in der Gruppe der Usability Professionals diskutierte Thematik
ist der Wegfall von Freiheitsgraden bei
der Entwicklung von Prototypes durch
die Nutzung des konkret Patternbasiserten UI Wizard.
Dieser Wegfall von Freiheitsgraden (im
Vergleich zur Nutzung offener Tools wie
Photoshop, Visio oder Excel) wird direkt
in Verbindung gebracht mit dem Risiko,
durch die zu schnelle Konzentration auf
Pattern-basierte UI Entwicklung gerade
die Weiterentwicklung der Pattern oder
125
auch die notwendige ständige kritische
Hinterfragung der Pattern zu unterbinden. Eine konsequente Nutzung der
Tool-gestützen Pattern-basiserten UI
Entwicklung sei also am Ende innovationshemmend.
Für die weitere Entwicklung des Tools
werden folgende Zielsetzungen anvisiert:
Dem Gegenüber steht die Position, dass
gerade die Nutzung des Tools zur Erstellung Pattern-basierter Mockups mit
allen damit verbundenen prozessunterstützenden Elementen zu mehr Freiheitsgraden für die Verfolgung neuer
Pattern-Ideen sowie für bewusste, kontrollierte Ausbrüche aus der Pattern-Welt
(Freestyle) führen.
Viele SAP-interne Nutzerbefragungen sowie Workshops haben gezeigt, dass die Usability des Tools
durch Verfolgung neuer InteraktionsParadigmen nachhaltig verbessert
werden kann. Der zunächst gewählte
Assistenten-Ansatz (Wizard) wird zugunsten einer WYSIWYG-Oberfläche
und umfassender Nutzung von
Drag&Drop sowie Direkt-EditierMöglichkeiten aufgegeben.
Um dies zu erreichen, muss in den frühen UI Design Phasen eine aktive Entscheidung herbeigeführt werden. Es
wird entschieden, ob die gewünschten
Funktionalitäten nach momentaner
Sachlage problemlos mit den vorhandenen Floorplans und Pattern umgesetzt
werden können (Pattern-Check), oder
ob bereits von Beginn an Alternativen
zur strikten Pattern-Nutzung gesucht
und verfolgt werden müssen, um Benutzeranforderungen vernünftig befriedigen
zu können.
In diesem Falle kann gerade das bewusste Verlassen der MainstreamProzesse und eine bezüglich des personellen Setups und der zu erwartenden
Mehraufwände angepasste Prozessvariante zu einer qualitativ hochwertigen
und zu einer äußerst innovationsfördernden Umgebung führen.
4.0
Weiterentwicklung des „UI Wizard“
Die im Zuge der SAP Business ByDesign Entwicklung bisher gesammelten
Erfahrungen zeigen bereits deutlich die
Vorteile der konsequenten, überlegten
Nutzung eines Pattern-basierten UI Mockup Tools.
126
4.1
4.2
Usability-Verbesserungen für die
Tool-Nutzung
Bessere Unterstützung früher
UCD Phasen
Es ist eine klare Zielsetzung,
durch die Ausweitung des Tools die
frühen UCD Phasen besser zu unterstützen. Es soll erreicht werden, möglichst früh Tool-unterstütze Prozesse
zu nutzen, ohne die notwendigen Freiheitsgrade der frühen Phasen zu eliminieren (s.o.). U.a. sind folgende
Maßnahmen geplant bzw. bereits in
Entwicklung:
Es soll die Möglichkeit bestehen,
Screen-Konfigurationen auch ohne
vorherige Erstellung von Screen Objekten (Feldlisten) zu erstellen. Später
im Prozess kann dann selbstverständlich eine Verknüpfung der erstellten UI
Felder zu vorhandenen Feldlisten hergestellt werden, um die für die Übergabe an die Entwicklung wichtigen
Informationen weiterhin generieren zu
können.
Use Cases, Use Case Portfolios sowie
Interaktions-Diagramme sollen Toolgestützt erfasst werden können. Ziel
ist hierbei die konsequente Durchgängigkeit all dieser Informationen durch
den kompletten UI Design Prozess.
Von einem fertigen Screen aus sollen
beispielsweise immer im direkten Zugriff
Informationen zu den mit diesem Screen
unterstützten Use Cases sowie deren
spezifische Priorität erkennbar sein.
Auch die Erfassung und das zur Verfügung stellen von Validierungsergebnissen ist hierbei eine wichtige Komponente.
Eine erweiterte CollaborationsUnterstützung soll helfen, die im interdisziplinären Team entstehenden UI
Mockups einer ständigen Diskussion zu
unterwerfen und diese Diskussion über
das zentrale Tool allen Beteiligten zur
Verfügung zu stellen. Insbesondere aufgrund der globalen Aufstellung bei SAP
wird diesem Punkt hohe Bedeutung beigefügt.
Die Unterstützung von „low-fidelity“ Prototypes soll dazu beitragen, dass auch
die früh im Prozess angesiedelten Konzeptvalidierungen oder Focus-Groups
erste im Tool erstellte Mockups, Skizzen
oder Interaktionsdiagramme nutzen können.
4.3
Prozess-Unterstützung
Die konsequente Anlehnung an definierte Produkt-Definitionsprozesse soll
die tägliche, selbstverständliche Nutzung des Tool durch die unterschiedlichen involvierten Rollen unterstützen.
Hierzu gehören u.a. Versionierungsanforderungen sowie die Reflektion des
„One-Team“-Ansatzes.
5.0
Ausblick
Die Weiterentwicklung des Tools
sowie die zu erwartenden vielfältigen
neuen Erfahrungen stellen eine sehr
interessante Herausforderung für die
Umsetzung von Usability-Methoden in
großen Organisationen dar und können
sicherlich eine organisationsweite
Verbreitung von Usability-Methoden und
deren konsequente Nutzung positiv beeinflussen.
Schon deshalb werden wir diese begonnene Entwicklung auch für die Zukunft
mit großem Interesse weiterverfolgen
und aktiv unterstützen.
6.0
Literatur
Arend, U. (2004): Effiziente Konstruktion von
Benutzungsoberflächen aus konfigurierbaren
Bausteinen. In Hassenzahl, M.,Peissner, M.
Eds, Usability Professionals 2004.
Buxton, B. (2008): Sketching User Experiences – Getting the Design Right and the
Right Design. Morgan Kaufmann.
Beyer, H.; Holtzblatt, K. (1997): Contextual
Design: A Customer-Centered Approach to
Systems Designs. Academic Press.
Preece, J.; Sharp, H.; Rogers, Y. (2002):
Interaction Design: Beyond Human-Computer
Interaction. John Wiley & Sons
Arnowitz,J.; Arent,M.; Berger,N. (2007): Effective Prototyping for Software Makers. Morgan Kaufmann.
User Centered Design Process at SAP:
http://www. sapdesignguild.org.
127
128
B erufsbild
U sability Pro f e s s i o n a l
129
130
Arbeitskreis: Berufsbild und Broschüre
Ein Statusbericht
Christian Bogner
TU Kaiserslautern
FB Sozialwissenschaften
Gottlieb-Daimler-Straße
[email protected]
www.sowi.uni-kl.de/wcms
Thomas Geis
ProContext GmbH
50679 Köln
[email protected]
www.procontext.com
Patrick Huber
Premiere GmbH & Co. KG
Platform Strategy & Innovations
Betastr. 5
85774 Unterföhring
[email protected]
www.premiere.de
Kostanija Petrovic
User Experience
SAP AG
Dietmar-Hopp-Alee 16
69190 Walldorf
[email protected]
www.sap.com
Henning Brau
Daimler Chrysler AG
GR/EPD, PsyE
Postfach 2360
89013 Ulm
[email protected]
www.daimler.com
Matthias Harbusch
SAP AG
SAP User Experience – Applications
69190 Walldorf Germany
[email protected]
www.sap.com
Clemens Lutsch
Microsoft Deutschland GmbH
DPE
Konrad-Zuse Str. 1
85716 Unterschleißheim
[email protected]
www.microsoft.com
Knut Polkehn
Humbold Universität zu Berlin
Institut für Psychologie
Rudower Chaussee 18
12489 Berlin
[email protected]
www.psychologie.huberlin.de/prof/ingpsy
Abstract
Der AK Berufsbild & Broschüre orientiert
sich bei der Beschreibung der Tätigkeiten eines Usability Professionals an der
ISO 13407 und erarbeitet anhand von
Prozessrollen, Aktivitäten und Artefakten
eine Veröffentlichung. Zur Zeit ausgeklammert hat der Arbeitskreis die Implikationen auf Aus- und Fortbildung.
1.0
Einleitung
Ausgehend von dem Bedarf, eine neue
und überarbeitete Broschüre zum Berufsbild „Usability Professional“ zu
erstellen, hat sich der Arbeitskreis darauf konzentriert ein kohärentes Bild der
Tätigkeiten und Prozesse in diesem
Berufsfeld zu beschreiben. Um diesem
Anspruch gerecht zu werden, wurde
zunächst entschieden, die Implikationen
auf Aus- und Weiterbildung nicht explizit
zu beleuchten.
Um der Diskussion zu den Tätigkeiten
und Ergebnissen eine Basis zu geben,
orientiert sich der Arbeitskreis an der
ISO 13407: Human-centred design processes for interactive systems (nach
erfolgter Überarbeitung soll diese Norm
die Nummer 9241-210 erhalten). Ausgehend von dieser Grundlage soll am
Ende der Arbeit des Gremiums eine
Veröffentlichung stehen, die die folgenden Themen adressiert.
Keywords
HCD, ISO 13407, Berufsbild, Prozessrollen
2.0
Definition „Usability Professional“
Was macht den Usability Professional
aus, welche Ziele verfolgt dieser Berufsstand? Hier wird eine griffige und
belastbare Definition erarbeitet, die
wiederum in das Selbstbild des German Chapters der UPA ausstrahlen
soll.
3.0
Kompetenzen
Neben den fachlichen Kompetenzen
eines Usability Professionals werden
hier auch die erforderlichen sozialen
Kompetenzen („soft skills“) erläutert.
4.0
ISO 13407 niedergelegt ist. Anhand der
Prozessschritte werden die einzelnen
Prozessrollen beschrieben, die der Usability Professional entsprechend seinen
Tätigkeitsschwerpunkten einnehmen
kann. Auch die Arbeitsergebnisse (Artefakte) und deren Einbindung in die Entwicklungsprozesse werden thematisiert.
5.0
Usability Professionals in der
Praxis
Anhand von Referenzberichten aus der
Wirtschaft soll die Arbeitswelt der Usability Professionals beschrieben werden.
Neben der Zusammenarbeit im Entwicklungsprozess werden auch die Herausforderungen der Usability-Praxis thematisiert.
Erforderlicher Prozess
Grundlage der professionellen Arbeit
im Bereich Human centred design ist
der gleichnamige Prozess der in der
6.0
Glossar
Um das umfangreichen Vokabular des
Berufsbildes „Usability Professional“ zu
131
erfassen und im Zuge einer Professionalisierung der Tätigkeit, wird ein umfassendes Glossar erarbeitet. Hierbei wird,
so weit wie möglich, auf Definitionen aus
den relevanten Normenreihen Bezug
genommen, die den aktuellen internationalen Konsens der Begriffsdefinition
dokumentieren.
132
7.0
Quellen
erläutert und mit Teilnehmern diskutiert.
Die Veröffentlichung wird abgerundet
durch die Nennung aller relevanter
Quellen und Referenzen.
8.0
Diskussion
Während des Workshops zum Thema
„Berufsbild & Broschüre“ im Rahmen
der UP2008 wird der Stand der Arbeit
9.0
Referenzen
German Chapter der Usability Professionals
Association e.V. (o.J.): Was Sie schon immer
über Usability erfahren wollten. Stuttgart:
Eigenverlag
DIN EN ISO 13407: Benutzerorientierte Gestaltung interaktiver Systeme, Berlin: Beuth
Verlag, 1999.
Arbeitskreis: Ausbildung und Curriculum - Statusbericht
Kerstin Röse
AG use
TU Kaiserslautern
FB Maschinenbau und
Verfahrenstechnik
Gottlieb-Daimler-Str. 42
[email protected]
www.uni-kl.de/use
Jana Löffler
artop - Institut an der Humboldt
Universität zu Berlin
Christburger Str. 4
10405 Berlin
[email protected]
www.artop.de
Abstract
Der AK Ausbildung und Curriculum hat
die Aufgaben, Qualitätsrichtlinien für die
Usability-Ausbildung zu erstellen sowie
ein Usability-Curriculum zu erarbeiten,
welches den breiten Anwendungskontext von Usability berücksichtigt.
1.0
Einleitung
Der AK Ausbildung und Curriculum
hat die Aufgaben, Qualitätsrichtlinien für
die Usability-Ausbildung zu erstellen
sowie ein Usability-Curriculum zu erarbeiten, welches den breiten Anwendungskontext von Usability berücksichtigt.
Um systematisch an die Aufgaben zu
gehen, wurde entschieden, sich zuerst
vorrangig dem Curriculum zu widmen.
D.h. in einem ersten Schritt sollen die
inhaltlichen Aspekte einer UsabilityAusbildung geklärt werden.
2.0
Vorgehensweise
2.1
Ausbildungsaspekte sammeln
Grundsätzlich gibt es die Diskussion, warum ein Curriculum für Usability,
wenn es eine Curriculum für HCI von der
Gesellschaft für Informatik e.V. (GI)gibt.
Um das vorhandene Curriculum der GI
zu berücksichtigen, aber gleichzeitig die
Breite der Usability-Ausbildung aufzuzeigen, wurde folgende Vorgehensweise
gewählt.
Es wurde das Curriculum der GI genutzt,
um darauf aufbauend folgende Ergänzungen vornehmen zu können.
Aktuell arbeitet der Arbeitskreis am
Curriculum der Usability-Ausbildung.
Keywords
Die Ergänzungen beziehen sich dabei
auf folgende Schwerpunkte:
Aufgaben der Experten bzw. Usability-Professionals ist die Ergänzung und
Bewertung (Ranking) der Ausbildungsinhalte und –schwerpunkte.
x
x
x
x
x
Einbindung verschiedener
Anwendungsbereiche
Ergänzung um Softskills
Ergänzung von Methoden
Ergänzung von Ausbildungsschwerpunkten
Ergänzung von Ausbildungsrichtungen/-berufen
Die Inhalte wurden in Form eines
Fragebogens zusammen gestellt und
als digitale Version und als Papierversion zur Verfügung gestellt.
2.2
Expertenbefragung
Die Verteilung der Fragebögen
und somit die Befragung per se, erfolgt
in zwei Stufen. In einer ersten Phase
werden Ausbilder an deutschen Hochschulen (Universitäten, Fachhochschulen, private Hochschulen) befragt. Somit soll die Sicht der Ausbilder erfasst
werden, welche eher eine konzeptionell-inhaltliche Sichtweise vertreten.
In einem zweiten Schritt werden
Usability Professionals befragt, d.h.
ehemalige Auszubildende. Von Ihnen
wird eine praxisorientierte Sichtweise
auf die Ausbildungsinhalte erwartet
Usability, Ausbildung, Arbeitskreis,
Usability-Engineering, UsabilityMethoden
Die Umfrage wird außerdem genutzt, um erste Hinweise auf qualitative
Aspekte der Usability-Ausbildung zu
sammeln.
Der Aufruf zum Ausfüllen des Fragebogens an die Ausbilder wurde über
direktes Email-Anschreiben versand.
Eine erste Auswertung der Ergebnisse
soll zur Usability Professionals vorgestellt werden und zur Diskussion gestellt
werden.
Außerdem wird die UP 2008 genutzt, um
weitere Fragebögen in Papierform an die
Usability Professionals zu verteilen. D.h.
die zweite Phase der Befragung findet
zur UP 2008 in Lübeck statt.
3.0
Weitere Planungen
Die gesammelten Ergebnisse aus
den beiden Befragungsphasen werden
dann zusammen getragen und in einer
ersten Version, einer Alpha-Version eines Usability-Curriculums zusammen
gestellt.
Die partizipatorisch gewonnene erste Version des Curriculum wird dann
133
einem erweiterten Kreis aus UsabilityAusbildern und Usability-Praktikern zur
Bewertung vorgesellt. Die dabei gesammelten Kommentare und Ergänzungen werden in eine weitere Version eingearbeitet.
134
Dann wird es eine Beta-Version
geben, die 2009 auf dem GC-upaServer online gestellt wird, damit jedes
Mitglied seine Kommentare und Ergänzungen einbringen kann. Zur UP
2009 wird es dann ein UsabilityCurriculum geben.
Usability Professionals – ein Rollenspiel
Michael Hatscher
Google Switzerland GmbH
Brandschenkestr. 110
8032 Zürich
Schweiz
[email protected]
Iris Niedermann
soultank AG
Alpenstrasse 11
6304 Zug
Schweiz
[email protected]
Abstract
Bei der beruflichen Um- oder Erstorientierung wird häufig lediglich auf die Unternehmensgröße als Entscheidungskriterium fokussiert. Andere Kriterien spielen jedoch eine ebenso große Rolle,
wenn es um langfristige Zufriedenheit in
der neuen Position geht, beispielsweise
Interaction Design vs. Usability Engineering oder Beratung vs. In-HouseUsability.
1.0
Einleitung
Wenn eine berufliche (Um-) Orientierung ansteht, stellt man sich oft zunächst die Frage: Will ich in einem großen oder eher in einem kleinen Unternehmen arbeiten? Große Unternehmen
locken mit Stabilität und (relativer) Arbeitsplatzsicherheit, internen Fortbildungsangeboten und der Möglichkeit,
sich ins Ausland versetzen lassen zu
können; gleichzeitig klingen aber auch
Bürokratie, langsame Prozesse, lange
Release-Zyklen und Eintönigkeit an.
Kleinere Unternehmen verheißen mehr
Verantwortung in kürzerer Zeit, mehr
Abwechslung und Selbstverwirklichung,
scheinen aber oft weniger Entwicklungsmöglichkeiten zu bieten und verfügen häufig nicht über eine interne professionelle Community, in der fachlicher
Austausch gewährleistet ist.
Vergleicht man jedoch die Tätigkeitscharakteristika und die Anforderungsprofile
der verschiedenen Rollen miteinander,
so stellt man fest, dass die Frage „großes vs. kleines Unternehmen“ in den
Hintergrund tritt zugunsten anderer Fragen:
Dieses Papier stellt die Rollen und
Charakteristika der möglichen Positionen einander gegenüber und gibt Hinweise darauf, wie man bereits im Bewerbungsgespräch wichtige Informationen einholt.
Keywords
x
nen durchschnittlich €57.298, Frauen
€42.528; parallelisiert über Berufsjahre
Männer €70.439, Frauen €51.000).
x
x
Usability Engineering vs. Interaction Design
Usability in der Beratung vs. InHouse-Usability
Wie ist die Position von Usability
im Unternehmen?
Wie wir dem Branchenreport Usability
2007 entnehmen können (Diefenbach
& Hassenzahl 2007), haben 84% der
Usability Professionals in Deutschland
einen akademischen Abschluss (24%
Psychologen, 14% Informatiker). Psychologinnen und Psychologen empfinden ihre Ausbildung als gute Vorbereitung für die Arbeit im Usability-Umfeld;
viele andere Berufsgruppen kommen
eher als Quereinsteiger zur Usability.
Der weitaus größte Teil der Teilnehmer an der Befragung arbeitet in einem Unternehmen mit mehr als 100
Beschäftigten (56%), während nur 9%
in einem Unternehmen mit weniger als
10 Mitarbeitern arbeiten. Für die
Mehrheit der Befragten nehmen Diefenbach und Hassenzahl an, dass es
sich bei der aktuell ausgeübten Tätigkeit „um den ersten Arbeitgeber im
Bereich Usabilty“ handle. Große geschlechtsspezifische Unterschiede gibt
es bei den Gehältern (Männer verdie-
Rollen, Usability, Berufswahl
Die Erfahrung zeigt, dass sich deutliche
Gehaltssprünge am ehesten über einen
Wechsel des Arbeitgebers erzielen lassen. Die Zeichen dafür stehen denkbar
gut: Anekdotische Evidenz lässt darauf
schließen, dass der Arbeitsmarkt für
Usability Professionals momentan so gut
aussieht wie seit Jahren nicht mehr.
Doch das Feld lässt sich schwer übersehen, was nicht nur an einer Vielzahl
von Berufsbezeichnungen liegt. Diefenbach und Hassenzahl zählen auf: „Usability Consultant“, „User Interface Designer“, „User Interface Design Spezialist“,
„User Experience Consultant“, „Usability
Engineer“, „User Experience Architect“;
„Human Factors Spezialist“, „Web Engineer“. Darüber hinaus gibt es weitere
übliche Berufsbezeichnungen, wie „User
Experience Designer“, „Interaction Designer“, „User Researcher“:
x
Sehr verschiedene Tätigkeitsfelder
verbergen sich hinter gleich oder
ähnlich klingenden Bezeichnungen:
Usability-Evaluation (formativ und
summativ), Interaction Design, Requirements Engineering, Usability
Engineering.
135
x
x
Man kann eine der Rollen in unterschiedlichen Kontexten ausüben:
Beispielsweise ist man als interner
Usability Engineer eingebunden in
die (Software-)Entwicklung, oder
man ist als externer Berater mit der
Sicherung des Aspekts „Usability“
der Produktqualität betraut.
Charakteristika des Unternehmens
bzw. der Geschäftsform unterscheiden sich stark: Als Freiberufler oder
Selbstständiger hat man ein anderes Arbeitsumfeld als als Angestellter in einem kleinen Beratungshaus
oder als Mitarbeiter in einem großen
Unternehmen.
Das vorliegende Papier zielt darauf ab,
Neueinsteigern und Kollegen in der Umorientierung eine Entscheidungshilfe an
die Hand zu geben, um eine informierte
Entscheidung bei der Wahl des ersten
oder des nächsten Arbeitgebers treffen
zu können. Es werden die eingangs
genannten Fragestellungen diskutiert
und Charakteristika und Profile dargestellt sowie mögliche Fragen für Bewerbungsgespräche formuliert, um weitergehende Informationen zu gewinnen.
2.0
Job-Anforderungen und JobCharakteristika
Für die oben genannten Fragestellungen werden verschiedene Optionen
diskutiert mit dem Ziel, mehr Klarheit für
eine berufliche Entscheidung zu schaffen.
2.1
Usability Engineering vs. Interaction Design
Grob lassen sich zwei Rollen im UXUmfeld unterscheiden, die unter unterschiedlichen Titeln ausgeführt werden:
x
136
„Interaction Designer“ (Synonyme:
„User Experience Designer“, „User
Interface Designer“): Interaction Design ist „the discipline of defining the
behavior of products and systems
that a user can interact with. The
practice typically centers around
complex technology systems such
x
as software, mobile devices, and
other electronic devices. However, it can also apply to other
types of products and services,
and even organizations themselves. Interaction design defines
the behavior (the „interaction“) of
an artifact or system in response
to its users.“ (Wikipedia 2008a).
Interaction Designer kommen häufig aus dem Design, der Informatik, den Kognitionswissenschaften
oder (in den USA) speziellen HCIProgrammen, wie dem Programm
von Carnegie Mellon
(http://www.hcii.cmu.edu) oder
Stanford (http://hci.stanford.edu).
Interaction Designer arbeiten
i.d.R. als Teil eines Entwicklungsteams in der Produktentwicklung
und vermitteln zwischen Produkmanagement und Engineering. In
der Produktkonzeption bekommen
sie viel Input von Usability Engineers oder User Researchers, die
auch für die Evaluation der erstellten Designs zuständig sind.
„Usability Engineering“ entspricht
mehr dem, was im deutschsprachigen Raum als „SoftwareErgonomie“ bekannt ist und gelehrt wird: „The term usability engineering (in contrast to interaction
design and user experience design) implies more of a focus on
usability than it does on design,
though Usability Engineers may
still engage in design to some extent, particularly design of wireframes or other prototypes. Usability Engineers conduct usability
evaluations of existing or proposed interfaces and their findings
are fed back to the Designer for
use in design or redesign. Common usability evaluation methods
include interviews, focus groups,
questionnaires, usability testing,
cognitive walkthroughs, heuristic
evaluations, cognitive task analysis and contextual inquiry“ (Wikipedia 2008b).
Usability Engineers haben häufig
einen Hintergrund in der Psychologie, aber auch in der Informatik
oder den Informationswissenschaften (auch hier spielen wieder
die HCI-Programme von Carnegie
Mellon oder Stanford eine Rolle).
Mit einem stärker sozialwissenschaftlichen Hintergrund (Ethnografie oder Anthropologie) werden sie
auch oft als User Researcher bezeichnet. Usability Engineers arbeiten in der Anforderungsanalyse, der
Produktdefinition und im Usability
Testing. Sie arbeiten mit Interaction
Designern zusammen, wenn Produktkonzepte erstellt und Verbesserungen für konkrete Designs erarbeitet werden sollen. und evaluieren
Designs.
Im Folgenden wird in einem semantischen Differenzial grob dargestellt, welche Anforderungsprofile die Rollen Interaction Designer (I) und Usability Engineer (E) aufweisen.
eher kreativ
I
E
eher analytisch
geschickt
im Aushandeln
von Ergebnissen
I
E
geschickt
im Auf-denPunktBringen
sicher in
Methoden
/ Statistik
E
I
sicher in
Designtechniken
visuelles
Denken
I
E
Denken in
Zusammenhängen
Umgang
mit Kunden
E
I
Umgang
mit Entwicklern
Anforderungsprofil Interaction Designer (I) /
Usability Engineer (E)
2.2
Usability in der Beratung vs. InHouse
Usability Engineers und Interaction
Designer arbeiten sowohl in Beratungshäusern (bzw. als Freiberufler) als auch
eingebettet in interne Entwicklungsteams.
x
Wie wird Usability bzw. der Erfolg
von Usability-Maßnahmen gemessen?
Jobcharakteristika für die Beratung (B) vs.
In-House (I)
2.4
Marketing- vs. Engineeringgetrieben?
Weitere Überlegungen beschäftigen
sich mit dem Usability-Reifegrad des
Unternehmens, der Frage, welche
Disziplin das Unternehmen treibt, und
Gedanken zur Arbeitsteiligkeit der Tätigkeit.
Ob ein Unternehmen eher Marketingoder eher Engineering-getrieben ist,
stellt einen weiteren Faktor dar. Je
nachdem, ob man als Usability Professional eher im Marketing oder im Engineering angesiedelt ist, hat man größere
oder eingeschränktere Einflussmöglichkeiten auf die Gestaltung der Produkte.
x
In der Beratung unterstützt man als
Usability Professional Kundenunternehmen dabei, gebrauchstaugliche
Systeme zu konzipieren bzw. deren
Qualität zu evaluieren und sicherzustellen. Dies findet in der Regel zumindest teilweise beim Kunden vor
Ort statt (in Workshops mit Kunden
oder eingebettet in Teams beim
Kunden). Oft übernimmt man neben
den rein fachlichen Tätigkeiten auch
Budget- und / oder Projektverantwortung.
x Als In-House Usability Professional
bietet man den Kollegen im eigenen
Unternehmen Dienstleistungen aus
dem Usability-Umfeld an oder ist integraler Bestandteil eines Produktentwicklungsteams. Der Fokus liegt
hier eher auf der fachlichen Verantwortung, da Projektführungsaufgaben meist über die Organisationsstruktur (Matrix oder Linie) des eigenen Unternehmens zugewiesen
werden.
Die folgende Grafik zeigt ein grobes
semantisches Differenzial der Jobcharakteristika für die Tätigkeit als UsabilityProfessional in der Beratung (B) und in
der In-House-Rolle (I).
Kundenkontakt
B
I
stilles Kämmerlein
viel Reisen
B
I
im eigenen
Büro
Nähe zum
Produkt
I
B
nur mittelbar
am Produkt
viele verschiedene
Tätigkeiten
B
I
konzentriert auf
eine Tätigkeit
auch Projekt-, Budgetverantwortung
B
I
eher nur fachliche Verantwortung
etablierte
Prozese
interne
Community
2.3
B
ad-hocProzesse, je
nach Projekt
B
externe Community
Usability-Reifegrad
Inzwischen haben viele Unternehmen die Bedeutung der
Gebrauchstauglichkeit für den Erfolg
ihrer Produkte verstanden und nutzen
„Ease of use“ oder „easy to use“ auch
als Marketingbotschaft. Nicht immer
stehen dieser nach außen gerichteten
Botschaft auch entsprechende Prozesse und Denkweisen im Innern gegenüber. In der Literatur unterscheidet
man verschiedene Reifegrade eines
Unternehmens in Bezug auf den Umgang mit Usability. Nielsen (2006a, b)
verweist auf ein achtstufiges Modell,
wobei Unternehmen 20 Jahre und
länger benötigen, um von Stufe 1
(„Hostility Toward Usability“) zu Stufe 7
(„Integrated User-Centered Design“)
zu kommen und wahrscheinlich weitere 20, um den letzten Schritt von Stufe
7 zu Stufe 8 („User-Driven Corporation“) zu schaffen. Der UsabilityReifegrad des Unternehmens, der für
Usability Professionals in der Beratung
für das Kundenunternehmen gilt, wirkt
sich stark auf die Inhalte und die Möglichkeiten der Tätigkeit aus.
Fragen, die man im Bewerbungsgespräch stellen könnte:
x
I
I
x
Gibt es ein dediziertes Budget für
Usabilty?
Wem „gehört“ der Bereich Usability?
x
x
In Marketing-getriebenen Unternehmen liegen häufig eher topdown-Prozesse vor; das Marketing
definiert Ziele, die mit den Mitteln
des Engineerings zu erreichen sind.
Ist man als Usability Professional im
Marketing (oder Produktmanagement) angesiedelt, kann man hier
teilweise sehr strategisch arbeiten,
ist aber häufig weit von der Technologie und der Entwicklung entfernt.
Ist man im Engineering angesiedelt,
beschränkt sich die Tätigkeit oft auf
die reine Umsetzung.
Engineering-getriebene Unternehmen gehen meist eher bottom-up
vor. Produkte werden von Ingenieuren konzipiert, und das Marketing
kümmert sich anschließend um die
Vermarktung. Hat man hier eine Tätigkeit im Engineering inne, kann
man weit reichende Produktentscheidungen mitgestalten; ist man in
einem Engineering-getriebenen Unternehmen im Marketing, besteht
die Gefahr, dass man lediglich fertige Produkte mit einem hübschen Interface versieht, ohne wirklich tiefgreifende Veränderungen vornehmen zu können.
x
x
Wem gehört das Produkt im Unternehmen?
Mit wem arbeitet man als Usability
Professional zusammen?
137
x
Welche Rolle hat das Marketing?
2.5
Wie arbeitsteilig wird gearbeitet?
Unternehmen unterscheiden sich ebenfalls im Ausmaß der Arbeitsteiligkeit der
Tätigkeit:
x
x
In manchen großen Unternehmen
mit Usability-Teams von 120 Leuten
arbeiten dennoch fast alle als Generalisten, d.h. sie üben sowohl User
Research als auch Usability Engineering und Interaction Design aus.
Andere Unternehmen mit ähnlich
großen Teams haben dedizierte
User Research- und Interaction Design-Teams mit klar definierten Rollen und Schnittstellen.
Je nach eigener Vorliebe und angestrebtem Karrierepfad kann es vorteilhaft
sein, eine eher generalistische Position
anzustreben, um Wissen in allen Bereichen aufzubauen, oder sich eher auf
einer spezialisierten Rolle zu versuchen,
um bestehendes Wissen möglichst gewinnbringend anzubringen.
eher kreativ
geschickt im Aushandeln
von Ergebnissen
sicher in Methoden / Statistik
visuelles Denken
Umgang mit Kunden
Kundenkontakt
viel Reisen
Nähe zum Produkt
verschiedene Tätigkeiten
auch Projekt-, Budgetverantwortung
etablierte Prozesse
interne Community
138
B
B
I
B
B
I
I
x
x
3.0
Mit welchem Tätigkeitenbündel
beschäftigen sich die Usability
Professionals im Unternehmen?
Welche Rollen gibt es im UsabilityUmfeld im Unternehmen für Usabilty Professionals?
4.0
Diefenbach, S.; Hassenzahl, M. (2007): Usability als Beruf – Ergebnisse einer Umfrage
unter Usability Professionals. In: Röse, K.,
Brau, H. (Hrsg.): Usability Professionals
2007.
Nielsen, J. (2006a): Corporate Usabilty Matury: Stage 1–4.
http://www.useit.com/alertbox/maturity.html.
Letzter Zugriff: 2.6.2008.
Fazit
Sich nur auf die Unternehmensgröße
als Entscheidungskriterium für die
Wahl der nächsten Tätigkeit zu konzentrieren, greift zu kurz. Andere Aspekte müssen ebenfalls berücksichtigt
werden: die Charakteristika der potenziellen Stelle, eigene Fertigkeiten im
Verhältnis zum Anforderungsprofil und
der Usability-Reifegrad des Unternehmens. Eine Wahl kann sich nur dann
mittel- und langfristig als zufriedenstellend erweisen, wenn diese Umstände
ebenfalls bei der Entscheidung berücksichtigt werden.
Nielsen, J. (2006b): Corporate Usabilty Matury: Stage 5–8.
http://www.useit.com/alertbox/process_maturi
ty.html. Letzter Zugriff: 2.6.2008.
Wikipedia (2008a): Interaction Designer.
http://en.wikipedia.org/wiki/Interaction_Design
er. Letzter Zugriff: 2.6.2008.
Wikipedia (2008b): Usability Engineering.
http://en.wikipedia.org/wiki/Usability_engineer
ing. Letzter Zugriff: 2.6.2008.
E eher analytisch
E geschickt im Auf-den-PunktBringen
I sicher in Designtechniken
E Denken in Zusammenhängen
I Umgang mit Entwicklern
I
I
E
I
E
I
I
B
I
I
stilles Kämmerlein
im eigenen Büro
nur mittelbar am Produkt
konzentriert auf eine Tätigkeit
eher nur fachliche
Verantwortung
B ad-hoc-Prozesse, je nach Projekt
B externe Community
S tandards im
U sability En g i ne e ri ng
139
140
Standards im Usability Engineering umsetzen
– was funktioniert, was nicht?
Bernard Rummel
Martin Schrepp
Theo Held
SAP AG
User Experience Application Design
69190 Walldorf
[email protected]
[email protected]
[email protected]
Thomas Geis
ProContext GmbH
50679 Köln
[email protected]
Michael Offergeld
Daimler AG
Research & Development
EE Process Deployment
Wilhelm-Runge-Strasse 11
89081 Ulm
[email protected]
Heinz Martin Scheurer
Siemens AG
Corporate Technology
User Interface Design
CT IC 7
Otto-Hahn-Ring 6
81739 München
[email protected]
Dirk Willuhn,
IBM Deutschland
Research & Development GmbH
User-Centered Design
Schönaicher Str. 220
71032 Böblingen
[email protected]
Abstract
Neben den bekannten ISO-Normen
9241 und 13407 gibt es in vielen Unternehmen weitere interne Richtlinien. Zur
praktischen Erstellung und Umsetzung
1.0
Einführung
Standards und Gestaltungsrichtlinien (Guidelines) sind scheinbar selbstverständliche Bestandteile von Usability
Engineering (UE). Bei der Umsetzung
sind jedoch in jeder Organisation Fragen
zu beantworten, und zwar hinsichtlich
ihres Geltungsbereichs, ihrer Zielsetzung, erforderlichen Prozessen der
Konsens- und Kompromissfindung, Zielgruppen, Kommunikation, Verifikation,
etc. Die Antworten können sich je nach
Organisationskontext erheblich unterscheiden.
Grundsätzlich können sich Standards
auf Produkte, Prozesse oder auch Personen/Qualifikationen beziehen. So objektiv Standards und Guidelines sein
wollen/sollen, so unübersehbar „menschelt“ es bei deren Anwendung: Interessenskonflikte, individuelle Vorlieben,
Kosten- und Zeitdruck beeinflussen die
erfolgreiche Umsetzung von Standards.
Ziel des Workshops ist es, Erfahrungsberichte aus verschiedenen Organisationen zusammenzutragen, um Erfolgs-
solcher Richtlinien wurden in einem
Workshop Erfahrungsberichte aus
verschiedenen Großorganisationen
zusammengetragen.
Keywords
faktoren und Strategien im erfolgreichen Umgang mit Standards zu identifizieren. Die Beiträge der Referenten
sind im Folgenden zusammengefasst.
Produktbezogene ISO-Normen (z.B. die
Reihe ISO 9241) legen keineswegs „genormte User Interfaces“ fest. Vielmehr
geben sie Empfehlungen, die bei Analyse, Design und Prüfung interaktiver Systeme im jeweiligen Nutzungskontext in
konkrete Nutzungsanforderungen übersetzt werden müssen.
2.0
Genormte Usability?
ISO-Normen zur Usability (Geis)
In Bezug auf Usability Engineering
gibt es bereits sowohl produkt- als
auch prozessbezogene ISO-Normen.
Alle ISO-Normen zur Usability findet
man unter www.iso.org > Products >
ISO Standards > By TC > TC 159 Ergonomics > SC 4.
ISO-Normen entstehen in formellen
Verfahren. Sie helfen dem Usability
Professional sowohl bei der Erarbeitung als auch bei der Durchsetzung
unternehmensinterner Standards, da
ihnen ein internationaler Konsens zugrunde liegt über das, was aus Nutzersicht bei der Produktgestaltung
mindestens erreicht werden muss.
Konsens im Unternehmen lässt sich so
auf der Basis allgemein akzeptierter
Empfehlungen finden.
Standards, Styleguide, Usability Engineering etablieren
Die aktuell publizierten Usability-Normen
umfassen Empfehlungen zu Dialoggestaltung, Informationsdarstellung, Benutzerführung, Menügestaltung, Eingabeformulargestaltung, Kommandogestaltung, direkter Manipulation, Accessibility
und browserbasierten Anwendungen.
Produktstandards lassen sich nur praktisch umsetzen, wenn es einen Prozess
gibt, der dies einfordert. Die Erreichung
angemessener Nutzungsqualität ist in
Entwicklungsprojekten nach wie vor ein
Risikofaktor. Die Norm ISO 13407, die
im nächsten Jahr überarbeitet als ISO
9241-210 neu erscheinen wird, gibt daher Empfehlungen für die elementaren
Prozesse:
x
x
Nutzungskontext analysieren
Nutzungsanforderungen herleiten
141
x
x
Geeignete Lösungen finden
Lösungen gegen Nutzungsanforderungen testen
Die zurzeit entstehende Norm ISO/IEC
25060 „Common industry format for
usability-related information“ wird Artefakte festlegen, welche in jeder Phase
entstehen müssen, und welche Mindestinhalte diese enthalten müssen.
Zur Qualifikation von Personen, die Aufgaben im Usability-Engineering-Prozess
wahrnehmen, gibt es zurzeit keine ISONormen. Der „Leitfaden Usability“ der
Deutschen Akkreditierungsstelle Technik
(DATech) enthält jedoch ein Rollenmodell, das die Basis für einen pragmatischen Minimalkonsens liefern kann
3.0
Kommunikation entscheidet: SAP
Business Suite (Rummel)
Durch die rapide Entwicklung von
Web-Technologien ist bei SAP inzwischen eine Vielzahl von UI-Paradigmen
entstanden. Da zunächst die technische
Innovation im Vordergrund stand, wurde
wenig Aufwand zur unternehmensweiten
Standardisierung getrieben. Da einzelne
Benutzer mutmaßlich ohnehin nicht mit
der gesamten Produktpalette arbeiteten,
wurde mehr Wert auf lokale Gebrauchstauglichkeit gelegt.
Um die resultierenden Inkonsistenzen
wieder „einzufangen“, wurde 2005 in
den USA ein UI Standards-Team gegründet, mit der Aufgabe, technologieunabhängig ein kohärentes Oberflächenkonzept zu entwickeln. Die Idee
war, die verschiedenen UI-Paradigmen
und –Technologien auf diesen „GoldStandard“ hin konvergieren zu lassen.
Die unvermeidlichen technischen und
konzeptionellen Kompromisse bei der
Realisierung sollten in produktund
technologiespezifischen Guidelines definiert werden, um insgesamt eine möglichst hohe Qualität und Konsistenz der
verschiedenen Produkte zu erzielen, die
142
heute in der SAP Business Suite gebündelt vertrieben werden.
Ein technologieunabhängiges UIDesignkonzept hat naturgemäß eine
Glaubwürdigkeitslücke, die durch die
Lokation diesseits/jenseits des Atlantiks noch verstärkt wurde. Die Legitimation des Konzepts sowie Teams
wird permanent herausgefordert.
Aufgrund dieser Erfahrung wurden die
lokalen Guidelines-Teams wesentlich
verstärkt, um mit hoher Verfügbarkeit
technische und konzeptionelle Fragen
schnell und kompetent beantworten zu
können. Diese Teams agieren dabei
nicht nur als Richtlinien-Editoren, sondern auch als Mittler zwischen Framework-Entwicklung und Anwendungsdesign.
Die Guidelines werden zunehmend in
Wikis veröffentlicht, mit Tagging und
Suchunterstützung. Das Wiki ist i.d.R.
nicht editierbar, aber jede Seite ist
kommentierbar. Die Funktion wird
nicht übermäßig genutzt; die Bereitschaft zur offenen Diskussion hat aber
entscheidend zum Erfolg der Guidelines beigetragen. Schon die erste 1:1Übertragung der Guidelines ins Wiki
wurde deutlich besser bewertet als die
ursprüngliche Intranet-Publikation.
Anfragen zu komplexeren Designfragen per Mail werden von den Guidelines-Teams typischerweise innerhalb
eines halben Tages beantwortet.
Durch diese extensive Kommunikation
entsteht eine vitale DesignCommunity, die die Guideline-Qualität
und -Weiterentwicklung vorantreibt.
Das Angebot editierbarer WikiGuidelines wird kaum genutzt. Den
Benutzern reicht offenbar die Kommentierbarkeit aus. Auch in den
Guidelines-Teams erregte die Idee
benutzergenerierter, „öffentlich
reifender“ Wiki-Guidelines wenig Begeisterung.
4.0
Systematische Entwicklung und
Verifikation: SAP CRM (Schrepp,
Held)
Das SAP Customer Relationship
Management (CRM) fördert kundenorientierte Geschäftsprozesse in Verkauf,
Service und Marketing. Die Lösung unterstützt dabei alle Kontaktkanäle zum
Kunden über Außendienst, Internet, Call
Center und Vertriebspartner. Das SAP
CRM ist ein Standardpaket, das Kunden
noch auf ihre Bedürfnisse einstellen
können. Aufgrund des großen Funktionsumfangs enthält dieses Paket hunderte unterschiedlicher Screens, von
denen in einer Kundeninstallation allerdings nur die für die jeweiligen Geschäftsprozesse relevanten sichtbar
sind. Die hohe Konfigurierbarkeit erfordert eine Konsistenz von Bildschirmaufbau und Interaktion aller Screens.
Im ersten Schritt wurde anhand einer
Vielzahl unterschiedlicher dokumentierter Nutzungsabläufe – z.B. Erfassen
neuer Kundendaten, Anlegen eines Verkaufsauftrags, Erfassen und Abwickeln
von Serviceanfragen etc. - ein einheitliches UI Konzept erarbeitet. Das Konzept definiert eine kleine Zahl von
Screen-Typen (z.B. Einstiegsseite, Suche, etc.). Für jeden Screen-Typ sind
dabei Layout und grundlegende Interaktionen über Regeln festgelegt.
Im zweiten Schritt wurde das Konzept in
einer UI Guideline festgehalten. Dabei
wurde darauf geachtet, die folgenden
Zielgruppen zu adressieren:
x
x
x
x
User Interface Designer und Produkt Manager (erstellen das Design)
Software-Entwickler (setzen das
Design um)
Tester (prüfen Funktionalität und
Einhalten der UI Guideline)
Kunden und Berater (nehmen Änderungen und Erweiterungen vor)
Die UI Guideline ist im SAP Portal als
PDF für alle Mitarbeiter verfügbar. Kun-
den und Beratern kann die Guideline zur
Verfügung gestellt werden. Für einige
Elemente des UI Konzepts stehen auch
Tutorien zur Verfügung.
Im dritten Schritt wurden aus der UI
Guideline alle testbaren Regeln extrahiert. Diese wurden in Checklisten überführt. Diese werden für jeden Screen im
System als Teil des Standardtests abgearbeitet. Dadurch werden Abweichungen von der Guideline vor der Auslieferung erkannt und behoben.
Das Einhalten der UI Guideline ist für
alle Screens im System verbindlich. Für
Sonderfälle, deren spezifische Anforderungen sich nicht innerhalb der UI Guideline abbilden lassen, muss eine Ausnahmegenehmigung beantragt werden.
Da die Guideline verbindlich ist, sind
Änderungen an bestehenden Regeln
aufwändig. Deshalb wurde ein Change
Management Prozess etabliert. Konzept-Erweiterungen, die keine Änderung
bestehender Screens erfordern, können
direkt vom Usability Team beschlossen
und in die Guideline aufgenommen werden. Alle anderen Änderungen erfordern
die Zustimmung von Solution Management und Entwicklung. Solche Änderungen können erst Teil der Guideline werden, wenn der entsprechende Aufwand
im Entwicklungsprozess eingeplant wurde.
Durch den oben beschriebenen Prozess
konnte eine hohe Konsistenz über alle
Screens des SAP CRM Systems hinweg
sichergestellt werden. Erfolgsfaktoren
waren dabei:
x
x
x
ein einheitliches UI Konzept, das
Screens und Interaktionen festlegt
Adressieren der Anforderungen aller
Zielgruppen in der UI Guideline
Verankern der UI Guideline im Entwicklungsprozess über Test und
Change Management Prozess
5.0
Standardisierung der User Interface Entwicklung: Daimler AG
(Offergeld)
Die Daimler AG hat zur Unterstützung zentraler Geschäfts- und Entwicklungsprozesse (z.B. Controlling,
Marketing, Vertrieb, Entwicklung) eine
Vielzahl von IT Systemen im Einsatz.
Die Nutzer sind zumeist interne Mitarbeiter.
Daimler tritt bei der Entwicklung der IT
Systeme in der Rolle eines Auftraggebers auf: die Funktionalität der Systeme wird intern spezifiziert und als Lastenheft an externe Dienstleister weitergegeben. Diese implementieren die
Systeme für einen Fachbereich, der es
nach Fertigstellung in den operativen
Betrieb überführt. Die Systeme werden
in der Regel in verschiedenen Versionen weiterentwickelt und an neue Anforderungen angepasst.
Ein Schwerpunkt bei Entwicklung, Einführung und Betrieb zentraler IT Systeme liegt in der Definition und Etablierung von Prozessstandards für durchgängige Usability Engineering Aktivitäten unter Einbindung der Forschung
und Vorentwicklung. Damit soll sichergestellt werden, dass
x
x
x
x
Entwicklungsprojekte effizient ablaufen (Optimierung Entwicklungskosten),
Systeme die Kerngeschäftsprozesse effektiv und effizient unterstützen (Optimierung der Prozessqualität),
Nutzer bei der Bewältigung ihrer
Aufgaben möglichst gut unterstützt
werden (Optimierung der Nutzerund Nutzungsakzeptanz) sowie
die Kernkompetenz des Usability
Engineering in die Kernprozesse
der Fachbereiche eingebracht wird
(systematische Verbesserung der
IT Entwicklungs- und Vergabeprozesse).
Bei der Umsetzung wird zwischen bereits laufenden Entwicklungsprojekten
und neu anlaufenden Projekten unterschieden. Verankerung von Usability
Engineering als Kernkompetenz der
unternehmensinternen IT Entwicklungsprozesse ist ein weiterer Schwerpunkt.
Der Einstieg bei bereits laufenden ITEntwicklungsprojekten ist eine heuristische Expertenevaluation auf der Basis
von ISO 9241-10 (110) auf Oberflächen(teile) mit bereits absehbaren Usability-Problemen. Die Evaluationsergebnisse und Maßnahmen („Oberflächenkosmetik“) werden verwendet, um Projektmanagement und Fachbereich für
Usability zu sensibilisieren. Für die Zeit
nach Einführung des Systems sowie den
nächsten Systementwicklungszyklus
wird UE-Unterstützung angeboten.
Bei neu anlaufenden Projekten muss UE
bereits in der Definitionsphase als Teilprozess eingeplant werden, beginnend
mit der Ausschreibung der Systementwicklung. Nutzerrepräsentanten werden
während der Projektlaufzeit eingebunden. Externe Dienstleister werden u.a.
nach UE Know-How ausgewählt und
über Usability-Ziele und die Beschreibung von umzusetzenden Aufgaben
gesteuert. Die Ausarbeitung von Usability-Konzepten ist Teil des DaimlerLastenhefts. Nach Einführung des Systems werden Akzeptanzanalyseergebnisse im nächsten Zyklus genutzt.
Zur Verankerung von UE als Kernkompetenz der unternehmensinternen IT
Entwicklungsprozesse wird UE als Auftraggeberkompetenz in den Fachbereichen etabliert. Dazu gehört das Sicherstellen angemessener UE Aktivitäten
über die gesamte Projektlaufzeit in jedem neu anlaufenden IT Entwicklungsprojekt, die Integration ausgewählter UE
Aktivitäten in Entwicklungsprozesse der
Fachbereiche, und der Aufbau von UE
Kompetenz z.B. durch Etablierung eines
Usability-Experten.
143
Die Durchführung von heuristischen
Expertenevaluationen hat sich bewährt,
da man so in nahezu jede Entwicklungsprojektphase einsteigen und einen
schnellen Nutzen anbieten kann. Auch
in sehr späten Projektphasen konnten
stets Mängel in den Benutzungsoberflächen mit relativ wenig Aufwand schnell
und für alle spürbar behoben werden.
Die Ergebnisdarstellung hat immer stark
zur Sensibilisierung des Durchführenden
beigetragen, so dass im nächsten Projekt die UE-Expertise von Anfang an mit
eingeplant wurde.
Als entscheidend erwies sich die Definition einer Projektrolle „Usability-Experte“
auf Seiten Daimlers. Die Tatsache, dass
sich wenigstens eine Person im Projekt
verantwortlich um Ergonomiebelange
kümmert, hat in allen so praktizierten
Projekten bewirkt, dass das Thema UE
im gesamten Projektverlauf bis zur Systemeinführung ausreichend berücksichtigt wurde. Entscheidend ist dabei, dass
es einen Verantwortlichen für dieses
Thema gibt, auch wenn er nur wenig
Kapazität im Projekt dafür zur Verfügung
hat. Unsere Erfahrungen haben gezeigt,
dass in großen Entwicklungsprojekten
pro Jahr 0,5 bis 1 Personenjahr UE Expertise ausgereicht haben.
Die Forderung von Auftraggeberseite,
dass für das zu entwickelnde System die
Usability ein zentrales Qualitätskriterium
ist, war ein ganz entscheidender Garant
dafür, dass das Thema von externen
Dienstleistern und vom Projektmanagement ernst genommen und ausreichend
Ressourcen dafür bereitgestellt wurden.
UE als Auftraggeberkompetenz (und
nicht nur als Entwicklungskompetenz)
hat sich hier vielfach bewährt.
Trotz dieser Erfolge ist UE als eigene
Disziplin noch nicht so anerkannt und
als notwendig erachtet wie etwa Projektmanagement, Risikomanagement,
etc. Der Beitrag eines konsequenten UE
zu nahezu allen „klassischen“ Software
144
Engineering Disziplinen wird unterschätzt. Eine Erfolgsstrategie kann
sein, diesen Beitrag konsequenter
herauszustellen oder relevante Aktivitäten des UE in diese EngineeringDisziplinen zu integrieren.
6.0
Unternehmensweites Best Practise Sharing: Siemens AG
(Scheurer)
Die Siemens AG (Berlin und München) unterstützt Kunden in rund 190
Ländern auf den Gebieten Industrie,
Energie und Gesundheitswesen. Die
Produktdiversität ist groß – von der
Glühbirne über bildgebende Verfahren
bis hin zum Kraftwerk.
Die zentrale Abteilung Corporate
Technology (CT) ist Dienstleister für
technologische Innovationen. Das
User Interface Design Center der CT
(CT IC 7) hat die Aufgabe, Usability
Engineering auf der Basis von ISO
9241 und 13407 zu etablieren. Sie ist
ein von der Datech akkreditiertes Prüflabor für beide Normen. An den drei
Standorten (München, Princeton und
Beijing) arbeiten über 50 Ingenieure,
Designer und Psychologen. Diese
unterstützen die Entwicklungsabteilungen in den operativen Bereichen. Insgesamt arbeiten weit mehr als 100
Experten an dem Thema.
Innerhalb des Siemens-Konzerns werden "Standards" nicht als verbindliche
Vorgaben gesehen, sondern als Gestaltungsempfehlungen im Sinne von
„Best Practices“. Einen einheitlichen
formalen Standard für alle Produkte
aus dem Hause Siemens einzufordern
ist aufgrund der heterogenen Anwendungsgebiete sehr aufwändig und vermutlich auch nicht nutzerfreundlich.
Styleguides werden für Produktfamilien erstellt, um Homogenität des Look
& Feels und hohe Entwicklungseffizienz zu erzielen. Im Fokus unserer
internen Standards steht aber die Benutzerfreundlichkeit des Produktes.
Dies gelingt umso besser, je mehr die
systematischen Vorgehensweisen des
UE als integraler Bestandteil des "Produkt Lebenszyklus Management" (PLM)
verstanden werden. Daher ist es wichtig,
das UE in die unternehmensweit vorgeschriebenen Prozesse aufzunehmen.
Prozesse müssen von Menschen gelebt
werden. Daher sind Maßnahmen etabliert worden, mit denen Usability in den
Köpfe und Herzen der Mitarbeiter verankert werden soll. Als ein wichtiges Instrument hierfür hat sich die vor drei
Jahren etablierte, unternehmensweite
Best Practise Sharing Community „Usability @ Siemens“ herausgestellt.
Einmal jährlich treffen sich Produktmanager, Verantwortliche für die Vorfeldentwicklung, Projektleiter und UsabilityExperten, um sich einen Tag lang zu
den neusten Trends im User Interface
Design und über ihre Erfahrungen zum
Thema Usability auszutauschen. Ziel ist
der Erfahrungsaustausch, das Networking und die Identifikation von Themen
gleichen Interesses. Die CT IC 7 übernimmt hier die Rolle des Organisators
und bindet neben den Fachexperten
auch das Top-Management in die Veranstaltung ein. Bedürfnisse und Wünsche der Community werden identifiziert
und umgesetzt. Beispiele hierfür sind:
x
x
x
Interne UE-Schulung für Entwickler
und Entscheider
UE-Prozessberatung durch CT IC 7,
um UE in bereichsspezifische Produktentwicklungsprozesse zu integrieren
kleinere unternehmensweite Fachkreise zu Themen wie neue Interaktionstechnologien, UI-Prototyping
Zusätzlich erfolgt ein Wissensaustausch
innerhalb Siemens durch gezielte Personalrotation in Projekten und Organisationen. Aufgrund der großen Produktdi-
versität sind die Einsatzfelder der CT IC
7 entsprechend vielfältig. Für Anforderungsanalysen fahren Experten in Zügen
mit, stehen in Operationssälen oder untersuchen die Bedienung von Leitwarten
in Kraftwerken. In der Regel wechseln
die Mitarbeiter nach einigen Jahren in
die operativen Geschäftsbereiche. Im
Gegenzug werden freie Positionen im
User Interface Design Center mit Fachexperten aus den Bereichen besetzt, die
mit ihren Erfahrungen dafür sorgen,
dass das Domänen Know-how auch in
der Zentrale auf hohem Niveau bleibt.
Dieser Austausch von Wissen und Personen lässt sich durch das unternehmensweite Best Practise Sharing und
dem daraus entstehenden UsabilityNetzwerk deutlich leichter realisieren als
zuvor.
Usability Engineering kann immer dort
erfolgreich eingeführt werden, wo die
beteiligten Menschen die Voraussetzungen dafür haben. Projekte sind erfolgreich, wenn
x
x
x
das Top-Management seine Unterstützung zeigt.
in den Projektteams gegenseitige
Akzeptanz da ist: Gegenüber der
Ausbildungs-Disziplin (Techniker –
Nicht-Techniker) und der Rolle im
Projekt (Usability-Experte – Produktmanager – Entwickler).
profundes Wissen über den Nutzungskontext in der Triade Europa,
USA, Asien vorhanden ist oder erhoben wird.
Was nicht funktioniert, sind starre Anweisungen und Muss-Standards, die
nicht auf den spezifischen Nutzungskontext passen. Solche Top Down Vorgaben werden nie zu gelebten Prozessen
oder hoher Produktqualität führen.
7.0
Über Richtlinien zur Schlüsselrolle: IBM Deutschland Research & Development GmbH
(Willuhn)
Das erste Richtlinienwerk für Produktgestaltung wurde vor fast genau
20 Jahren IBM-weit eingeführt: mit
dem „Common User Access Basic
Interface Design Guide“ wurden verbindliche Regeln und Empfehlungen
für die konsistente Gestaltung von
textbasierten Nutzungsschnittstellen
definiert. Bald darauf folgten mit „Object-Oriented Interface Design“ produktund prozessbezogene Richtlinien
für die Gestaltung grafischer Nutzungsschnittstellen. Heute kommt eine
Vielzahl von Gestaltungsrichtlinien
zum Einsatz, die für die IBM Software
Brands und Produktfamilien spezifisch
sind (z.B. Tivoli, WebSphere, Lotus),
ergänzt durch Richtlinien für webbasierte Anwendungen und barrierefreies
Design. Darauf aufbauend sind auch
User Interface Design Patterns verfügbar, die für eine weitere Vereinheitlichung der Gestaltung sorgen.
Für die Usability Praktiker erwiesen
sich diese Regelwerke anfangs als
Türöffner: als „Hüter“ dieser Regeln
konnten sie mehr Einfluss auf die Produktgestaltung nehmen als ihnen vorher zugestanden wurde. Ab Mitte der
90iger Jahre wurde diese Phase durch
die Einführung prozessbezogener
Richtlinien abgelöst: mit „UserCentered Design“ wurden Rollen, Verantwortlichkeiten und Aktivitäten für
Usability Engineering im gesamten
Entwicklungsprozess festgelegt. Seitdem wurden die Kompetenzen und
Einflussmöglichkeiten zunehmend
erweitert – resultierend aus der Erkenntnis, wie wichtig das Merkmal
Usability für den Erfolg eines Produktes ist. Die Aktivitäten fokussierten sich
zunehmend auf die Erhebung des Nutzungskontextes und der Umsetzung
dieser Erfordernisse in Gestaltung der
Nutzungsschnittstelle. Gestaltungsrichtlinien werden dabei zwar als wichtiges
Arbeitsmittel angewendet, bleiben aber
weitgehend im Hintergrund.
Wesentlich wichtiger und effektiver ist
die frühzeitige, enge Einbindung der
Usability Experten in das Entwicklungsteam. Schon in der Konzeptphase arbeiten Usability Experten mit Kunden im
Rahmen von Customer Advisory Councils oder Design Partnership Programs
zusammen, um Anforderungen zu erheben. In der Folge sind sie mitverantwortlich für die Definition des Use Case Modells und meist alleinverantwortlich für
die Spezifikation des User Interfaces.
Dies geschieht in Form von Storyboards
oder interaktiven Prototypen. Im Idealfall
liegt damit eine validierte Spezifikation
vor, bevor die erste Zeile Code geschrieben wird. Sie spielt eine wichtige
Rolle für die Planung und Kommunikation im gesamten Projektteam: Aufwände
können exakter geplant werden, Abhängigkeiten und Schnittstellen werden früher und genauer erkannt – ein Nebeneffekt, der für die Akzeptanz und den Stellenwert des Usability Engineering sehr
hilfreich ist.
Erfolgsfaktoren für Usability Engineering: zunächst ist der Stellenwert zu
nennen, den das Top Management dem
Thema Usability beimisst, und die Häufigkeit, mit der Status abgefragt und berücksichtigt wird. Die Basis bilden die in
den Prozessbeschreibungen definierten
Verantwortlichkeiten und Kompetenzen
der Usability Experten. Frühes und detailliertes Prototyping hat sich dabei als
sehr effektive und werterbringende Methode bewährt. Essenziell sind auch die
produktübergreifende Zusammenarbeit
und der Austausch in der weltweiten
Usability Community. Standards für Produktgestaltung sind zwar ein wichtiges
Arbeitsmittel für Usability Experten, spielen heute aber nur eine vergleichsweise
untergeordnete Rolle.
145
146
U sability Tool s
147
148
Auswertung von Card-Sorting-Experimenten mit C ASOLYSIS
Sebastian Emmrich
Institut für Informatik
Universität Paderborn
Fürstenallee 11
33102 Paderborn
[email protected]
Gerd Szwillus
Fürstenallee 11
33102 Paderborn
[email protected]
www.upb.de/cs/ag-szwillus
Abstract
CASOLYSIS ist eine Anwendung zur Auswertung von Card SortingExperimenten. Während es mittlerweile
gut einsetzbare Softwareunterstützung
zur Durchführung solcher Experimente
gibt, mangelte es bisher noch an effizienten Tools zur Auswertung. Casolysis
stellt verschiedene Algorithmen und
interaktive Werkzeuge zur Verfügung,
um die entstehenden Datensätze einfach und effizient auswerten zu können.
Dabei liegt der Schwerpunkt neben der
Unterstützung praktisch aller heute bekannten Zuordnungsalgorithmen (etwa
Clusteranalyse) auf hochgradiger Interaktivität: Der Benutzer kann "gefahrlos"
mit den Daten experimentieren, Teillösungen fixieren, parallele Lösungsvarianten ausprobieren, diese weiterverfolgen oder auch wieder verwerfen.
1.0
Card Sorting
Card Sorting ist eine Methode, um
auf empirischem Wege hierarchische
Strukturen in vorgegebenen Begriffsmengen zu ermitteln. Konkret können
etwa die Linkankertexte von Webauftritten mit diesem Verfahren so bestimmt
werden, dass sich die Besucher unter
den gewählten Bezeichnungen das
Richtige vorstellen können. Ähnliches
gilt für die Definition von Menüitems in
Desktopanwendungen, die so definiert
sein sollten, dass der Benutzer die Befehle, die er sucht, möglichst intuitiv und
schnell findet.
Ausgangspunkt des Card Sorting Experimentes ist eine überschaubare Menge
(bis zu 100) von Begriffen. Beim klassischen Card Sorting wird jeweils einer
Alle Verfahren sind zudem mit direkten
manuellen Eingriffen für "Problemfälle"
kombinierbar. Damit trägt CASOLYSIS
der Problematik Rechnung, dass es in
den meisten Anwendungsfällen keinen
durchgehenden Algorithmus gibt, der
alleine das Ableiten einer kompletten
Lösung erlaubt.
Offene Card Sorting-Experimente
werden darüber hinaus durch einen
Algorithmus zur Ähnlichkeitssuche von
Wörtern sowie einen komfortablen
interaktiven Prozess unterstützt, der
dem Benutzer hilft, Synonyme bei den
von den Testern angegebenen Kategorienamen aufzuspüren und zusammenzuführen.
dieser Begriffe auf eine Karteikarte
geschrieben. Der Kartenstapel wird
dann einer Gruppe von Testpersonen
zum Sortieren gegeben, wobei jede
Testperson einen kompletten Kartensatz bekommt. Man unterscheidet zwei
Varianten dieses Prozesses (Maurer &
Warfel, 2004):
1.
Offenes Card Sorting: Die Testperson muss alle Karten gruppieren und den entstandenen Gruppen selbst sinnvolle Benennungen
geben. Bei dieser Variante entstehen neben der Sortierung auch
die Namen der Kategorien; üblicherweise wird diese Methode bei
einem ersten Durchlauf angewendet.
CASOLYSIS kann beliebige Datensätze in
gängigen Formaten importieren, die
Analyseergebnisse zur Weiterverarbeitung entsprechend exportieren und kann
somit universell eingesetzt werden.
Integriert sind zusätzlich Webschnittstellen zum direkten Einlesen von Experimentdaten webbasierter Card-SortingExperiment-Umgebungen, wie etwa
WECASO von der Universität Paderborn.
Keywords
Card Sorting, Experimentauswertung,
Heatmap, Clusteranalyse
2.
Geschlossenes Card Sorting: Hierbei sind die verschiedenen Kategorien schon vorgegeben, die Testperson muss also die Karten nur
noch auf diese Kategorien verteilen.
Diese Methode eignet sich besonders dann, wenn bereits ein offenes
Card Sorting durchgeführt wurde,
und man die Brauchbarkeit der ermittelten Kategorien beurteilen
möchte.
In beiden Fällen entsteht pro Teilnehmer
eine komplette Sortierung aller Karten.
Diese müssen anschließend ausgezählt
werden in dem Sinne, dass für jedes
Kartenpaar erfasst wird, bei wie vielen
Teilnehmern dieses Paar im gleichen
Stapel eingeordnet worden ist. Das
Ergebnis ist eine Matrix mit Zahlenwerten, die die Affinität je zweier Karten
149
repräsentieren. Der Nutzen des Experimentes besteht dann in der Definition
von Begriffsgruppen basierend auf den
gefundenen Ähnlichkeitsbeziehungen.
Existierende Softwareunterstützung
2.0
In der physischen Form mit echten
Karteikarten sind die Experimente und
auch die Auswertung recht mühsam.
Daher sind Softwareanwendungen (etwa
Toro 2008, WebCAT 2008) entstanden,
mit denen die Experimente am Computer durchgeführt werden können. Auch
haben sich Dienste im Internet (wie
Optimalsort 2008, Websort 2008) etabliert, welche die Abwicklung von Card
Sorting Experimenten anbieten. Diese
Systeme umgehen das Handling von
physischen Karten und erleichtern die
Auswertung beträchtlich. In den OnlineSystemen kann der Teilnehmer zudem
das Card Sorting ohne vorherige Programminstallation direkt durchführen
und die Ergebnisse sind sofort verfügbar. An der Universität Paderborn entsteht zurzeit ebenfalls ein solcher Dienst
(Vdovkin, 2008) unter dem Namen WECASO.
Die bislang vorhandenen Softwarelösungen legen den Fokus auf die Durchführung der Experimente. Im Bereich der
Auswertung allerdings gibt es erhebliche
Defizite. Zwar werden zum Beispiel
Clusteralgorithmen und auch diverse
Auszählungstechniken angeboten, auch
existieren makrobasierte Auswertungen
auf EXCEL-Basis, aber all diese Ansätze erfordern doch einen erheblichen
manuellen Nachbearbeitungsaufwand.
3.0
Der CASOLYSIS-Ansatz
Ziel der Entwicklung von CASOLYSIS
war es, den Analysevorgang zu strukturieren, zu beschleunigen und dadurch
erheblich zu vereinfachen, bzw. bei
größeren, unhandlichen Datenmengen
überhaupt erst zu ermöglichen. Alle
gängigen Verfahren (Clusteranalyse und
150
verwandte Algorithmen) sollten anwendbar und beliebig untereinander
aber auch mit manuellen Eingriffen
kombinierbar sein.
3.1
Grundprinzip
CASOLYSIS bietet die Möglichkeit,
mit den Daten zu experimentieren. Die
Ergebnisdaten erlauben in den meisten Fällen nicht den Einsatz eines
einzigen Algorithmus, der alle Probleme auf einen Schlag löst. Wichtig ist
es daher, dass der Benutzer die Möglichkeit bekommt, verschiedene Algorithmen zu kombinieren oder auch den
gleichen Algorithmus mit verschiedenen Parametern zu starten. Die dabei
entstehenden Ergebnisse müssen
schnell vergleichbar sein, so dass
bessere Lösungen weiter bearbeitet
werden können und optimale Lösungen sofort erkennbar sind. Der Benutzer hat jederzeit die Möglichkeit, auf
einen der bereits durchgeführten
Schritte zurückzugreifen und auf „alten“ Zwischenergebnissen aufzusetzen. Es entsteht ein vom System verwalteter Baum mit verschiedenen
Versionen von Analyseergebnissen.
Um sich einen Überblick über die Daten zu verschaffen, werden die Daten
in verschiedenen Formen aufbereitet.
Der Benutzer kann detaillierten Einblick in die Daten nehmen oder sich
einen generellen Überblick verschaffen. Somit können schon sehr früh
potentielle Probleme bei der Analyse
erkannt werden.
Trotz des Angebots an verschiedenen
Algorithmen kann es doch zu Situationen kommen, bei der eine Zuordnung
durch Algorithmen nicht möglich ist.
Für diese Fällen hat der Benutzer die
Möglichkeit, manuell einzugreifen, und
Zuordnungen vorzunehmen oder rückgängig zu machen, sowie Karten und
Kategorien umzubenennen.
CASOLYSIS kann alle CSV-formatierten
(mit Komma getrennte Werte) Datensätze einlesen; nach Fertigstellung der
Analyse kann der Benutzer die Daten
wieder im CSV-Format exportieren, um
sie in anderen Applikationen zu nutzen.
3.2
Eingesetzte Techniken
3.2.1
Heatmap
Eine Heatmap (Syntagm, 2007) erfüllt zwei Funktionen: Sie zeigt an, wie
oft eine Karte einer Kategorie zugeordnet wurde und färbt die Zahl gemäß
ihres relativen Anteils aus einem Farbspektrum von blau nach rot. Damit lässt
sich auf den ersten Blick erkennen, ob
Karten gehäuft bestimmten Kategorien
zugeordnet wurden (rote „Spitzen“) oder
ob sie sehr breit verteilt wurden (blaue
Flächen).
Abb.1: Ausschnitt aus einer Heatmap
Die Heatmap des Datensatzes wird
unmittelbar nach dem Einlesen angezeigt, sodass eine erste Orientierung
ermöglicht wird.
Im folgenden stellen wir die angebotenen automatischen Verfahren vor, die
der Benutzer miteinander kombinieren
kann, um schließlich zu einem brauchbaren Ergebnis zu gelangen.
Abb. 2: Algorithmenauswahl in CASOLYSIS
3.2.2
Section Label Analysis
Dieser einfache Algorithmus (Boulton,
2006) ordnet eine Karte einer Kategorie
dann zu, wenn ein vom Benutzer festgelegter Prozentsatz von Experimentteil-
nehmern die Karte einer Kategorie zugeordnet hat.
3.2.3
Agglomerative Hierarchical Clustering
Dieser klassische ClusteringAlgorithmus (Tan et al 2006) bestimmt in
jedem Schritt Zusammengehörigkeiten
von Kartengruppen (Cluster) durch eine
Bewertungsfunktion. Bei diesem Verfahren lassen sich Rückschlüsse darauf
ziehen, welche Karten tatsächlich zusammengehören; allerdings erlaubt es
nur bedingt Rückschlüsse darauf, welcher Kategorie sie zugeordnet werden
müssen. Im Anschluss an den Algorithmus muss der Benutzer daher die Cluster den Kategorien zuordnen. Er bekommt dabei jeweils eine Empfehlung,
zu welcher Kategorie ein Cluster die
größte Affinität hat.
3.2.4
CASOLYSIS ist eine frei verfügbare,
plattformunabhängige Java-Anwendung,
mit Webschnittstellen zur webbasierten
Card Sorting Applikation WECASO
(Vdovkin 2008) der Universität Paderborn und zu Optimalsort (Optimalsort
2008).
Abb. 3: Unschärfefilter für offene Experimente
Manuelles Gruppieren
Die manuelle Zuordnung, das Umgruppieren oder Umbenennen der Karten ist jederzeit möglich und wird durch
einen komfortablen Drag-and-DropDialog unterstützt.
3.3
weg, da teils unsinnige Bezeichnungen
verwendet wurden. Die eigentliche Analyse dauerte weitere 15 Minuten. Nach
insgesamt 30 Minuten konnten fast alle
Karten zuverlässig zugeordnet werden.
Des weiteren hatten sich mehrere sinnvolle Kategorienamen herausgebildet,
die für spätere Experimente verwendet
werden konnten.
DBSCAN
Das DBSCAN-Verfahren (Tan et al
2006) bestimmt über eine Zugehörigkeitsfunktion die Nähe einer Karte zu
jeder anderen. Alle Karten innerhalb
eines bestimmten Entfernungsradius
werden der Kategorie zugewiesen. Bei
diesem Verfahren spielt sowohl die
Ähnlichkeit der Karten, als auch die
Anzahl der Zuordnungen eine Rolle.
Dieses Verfahren eignet sich besonders
bei sehr großen Experimenten mit vielen
Teilnehmern. Bei kleinen Experimenten
unterscheiden sich die Ergebnisse kaum
von der Section Label Analysis.
3.2.5
begonnen werden kann. Bedingt durch
Schreibfehler oder minimal unterschiedliche Benennungen durch die
Testpersonen entstehen oftmals unverhältnismäßig viele Kategorien. In
diesem Sinne „gleiche“ Kategorien
müssen zunächst zusammengeführt
werden. Dies ist nur bedingt automatisiert möglich; so können „sport“,
„sports“, „sport-equipment“ und „sprot“
die gleiche Bedeutung haben. Um
diese Problematik zu lösen, werden
dem Benutzer von CASOLYSIS verschiedene Werkzeuge zur Verfügung
gestellt; insbesondere steht ein variabler Unschärfefilter zur Verfügung um
Rechtschreibfehler aufzudecken.
Offenes Card-Sorting
Beim eingangs erwähnten offenen
Card Sorting treten zusätzliche Probleme auf, die behandelt werden müssen,
bevor die eigentliche Analyse sinnvoll
4.0
Erfahrungen
Wir haben u.a. ein Card Sorting
Experiment mit 20 Teilnehmer und 57
Karten analysiert. Die Daten enthielten
1.140 Datensätze sowie 400 von Benutzern erstellte Kategorien. „Gleiche“
Kategorien wurden automatisch und
über die Volltextsuche innerhalb weniger Minuten auf etwa 80 Kategorien
reduziert. Ein Großteil dieser Kategorien fiel bei der Analyse auch noch
151
Literatur
Boulton, M. (2006): Card Sorting. Part 3 Analysis and Reporting.
http://www.markboulton.co.uk/articles/detail/c
ard_sorting_part_3/, letzter Zugriff: 30.05.08
Maurer, D., Warfel, T. (2004): Card Sorting: a
Definitive Guide.
http://www.boxesandarrows.com/view/
card_sorting_a_definitive_guide, letzter Zugriff: 30. Mai 2008
Optimalsort (2008): Understand a different
point of view. http://www.optimalsort.com,
letzter Zugriff: 30. Mai 2008
152
Syntagm (2007): Design for Usability - Card
Sorting. http://www.syntagm.co.uk/design/
cardsort.shtml, letzter Zugriff: 30. Mai 2008.
Tan, P., Steinbach, M., Kumar, V. (2006):
Introduction to Data Mining, AddisonWesley.
Toro, J (2008): What is CardZort?
http://www.cardzort.com, letzter Zugriff: 30.
Mai 2008-05-30
WebCat (2008): WebCAT: Category Analysis
Tool. http://zing.ncsl.nist.gov/ WebTools/WebCAT/overview.html, letzter Zugriff:
30. Mai 2008
Websort (2008): Card Sorting: Improve the
Organization of your Site.
http://www.websort.net, letzter Zugriff: 30. Mai
2008
Vdovkin, A. (2008): Entwicklung einer
webbasierten Card-Sorting-Applikation.
Laufende Studienarbeit, Universität Paderborn, Institut für Informatik, AG Szwillus,
geplante Abgabe 01.09.2008
W-U-T: Ein interaktives Web-Usability-Tool
Eugenie Demenev
Fürstenallee 11
33102 Paderborn
[email protected]
Johannes Hillebrand
Fürstenallee 11
33102 Paderborn
[email protected]
Harald Schröder-Mänz
Fürstenallee 11
33102 Paderborn
[email protected]
Gerd Szwillus
Fürstenallee 11
33102 Paderborn
[email protected]
www.upb.de/cs/ag-szwillus
Abstract
Es existieren eine Reihe von Fragebögen und Checklisten zur systematischen
Überprüfung der Usability von Webauftritten. Teilweise werden diese in Formularform, teilweise auch als interaktive
Werkzeuge mit Auswertungsmechanismen angeboten. Durch Nutzung dieser
Technik werden auch unerfahrene Tester systematisch durch alle potentiellen
Problembereiche geführt, sodass auch
kleinere, weniger bedeutsame Webauftritte in ihrer Usability verbessert werden
können. Das W-U-Tool ist ein Werkzeug
zur Unterstützung solcher Befragungen.
Es ist speziell für die Durchführung von
Benutzerevaluationen mit kleineren
Testgruppen ausgelegt, deren Ergebnisse qualitativ ausgewertet werden und
weniger für die Durchführung umfangreicher Benutzertests.
1.0
Einleitung
Das W-U-Tool erlaubt die Untersuchung der Usability von Webseiten auf
einfache Weise interaktiv mit Hilfe von
vorgegebenen Fragebögen. Neu dabei
ist, dass W-U-T die Möglichkeit bietet,
Webseiten graphisch durch Skizzen und
im Bild platzierten Text zu annotieren.
Wir zielen mit diesem Testwerkzeug
darauf, auch unerfahrenen Personen die
Möglichkeit zu geben, Webauftritte ohne
Kosten und trotzdem – durch die Führung entlang des Fragebogens – in
fachlich angemessener Weise zu evaluieren.
Besonderer Wert wurde daher auf die
Einfachheit der Bedienung und auf das
Einfangen möglichst differenzierter
Antworten der Tester gelegt. Daher
bietet W-U-T neben den üblichen
Ja/Nein-Fragen die Möglichkeit,
Screenshots der untersuchten Webseiten in die Antworten einzubinden und
diese grafisch und textuell zu annotieren. Dadurch kann der Tester gezielt
auf gefundene Probleme aufmerksam
machen und kann somit sehr differenziert auf einzelne Fragen antworten.
Die Analyse eines Webauftritts durch
mehrere Tester wird durch W-U-T
gezielt in einem Projekt zusammengefasst und anschließend zusammenfassend ausgewertet. Das zugehörige
Auswertungswerkzeug gibt einen einfachen statistischen Überblick über
gefundene Probleme, erlaubt aber die
vergleichende Betrachtung der Antworten aller Tester zu jeder einzelnen
Frage.
2.0
Webevaluation mit Fragebögen
Es existieren diverse Fragebogentechniken, durch die Webseiten und
Benutzungsschnittstellen untersucht
werden können (Ong et al 2004, Balasz 2003, Dzida et al 2001, Nitzsche
2007, Gediga et al 1999, Harms et al
2002). Ein Vorteil dieser Evaluierungsmethode ist die einfache und
aufwandsarme Durchführbarkeit. Als
nachteilig erweist sich jedoch oft eine
zu schematische Vorgehensweise, da
die verwendeten Fragebögen möglichst viele Fälle abdecken sollen und
von daher oft zu allgemein formuliert
Durch zusätzliche Anmerkungen kann
die Fehlerliste wie eine ToDo-Liste des
Webdesigners benutzt und abgearbeitet
werden. Darüberhinaus bietet die Umgebung einen Editor, mit dem der vorhandene Fragebogen beliebig erweitert,
modifiziert oder gekürzt und damit auch
an spezielle Bedürfnisse angepasst
werden kann. Auch die Entwicklung
völlig neuer Fragebögen kann erfolgen,
sodass W-U-T in sehr vielfältiger Weise
einsetzbar ist.
Keywords
Web Usability, Fragebogentechniken,
Evaluation, Werkzeugunterstützung
und in den Antwortmöglichkeiten eingeschränkt sind. So kann der Beantworter
in manchen Methoden nur sehr grob
antworten (etwa mit „Ja“, „Nein“ oder
„Teilweise“) oder gerät in Probleme,
wenn Fragen nicht verstanden werden
oder nicht zutreffen. Zum anderen sind
die vorgeschlagenen Auswertungen oft
zu summarisch und damit wenig aussagekräftig, da sie Statistiken und Zahlenwerte widergeben, die dem Auswerter kaum Hinweise auf mögliche Problemfelder aufzeigen.
W-U-T versucht durch erheblich differenzierte Antwortmöglichkeiten und eine
153
anschauliche Auswertung vom einzelnen Beantworter möglichst viele Information einzusammeln und diese dem
Auswerter als konstruktive Handlungs-
Damit kann die Checkliste lokal nachgebessert, weitgehend verändert oder
auch völlig neu gestaltet werden.
kann er auch angeben, dass er die
Frage nicht beantworten kann, weil
er sie nicht versteht oder weil der
Gegenstand der Frage nicht zutrifft
(s. Abb. 1).
x
Abb. 1: Beispiel für eine Ja/Nein-Antwort
anweisungen anzubieten.
Die für das W-U-Tool eingesetzte Webauftritt-Checkliste wurde an der Universität Paderborn (Neuhaus 2003) entwickelt. Diese Checkliste basiert auf den
bekannten Usability-Normen und Richtlinien, berücksichtigt aber auch ökonomische Interessen und psychologische
Grundlagen. Die Fragen dieses Testbogens sind in 7 logisch zusammenhängende Kategorien gruppiert.
Das W-U-Tool erlaubt eine flexible Beantwortungsreihenfolge, bietet aber
auch eine klare Führung an, um einen
guten Überblick zu garantieren. Integriert in die Umgebung ist ein Werkzeug
zur Bearbeitung des eingesetzten Fragebogens.
3.0
Das W-U-Tool
Das W-U-Tool wird durch die Testperson, welche eine Webseite bewerten möchte, aufgerufen. Dabei wird die
Testperson systematisch durch den
Fragebogen geführt. Für jede Frage
gilt, dass dem Tester eine (positive)
Benutzungseigenschaft vorgestellt
wird und er sagen muss, ob diese
Eigenschaft gegeben ist oder nicht.
Das Tool unterscheidet zwei Arten von
Antwortmöglichkeiten:
x
Ja/Nein-Antworten bestehen wirklich nur aus der Entscheidung zwischen Ja oder Nein. Es werden
keine weiteren Informationen erfragt – derTester muss sich lediglich auf Zustimmung oder Ablehnung zur geforderten UsabilityEigenschaft festlegen. Allerdings
Annotationsantworten sind solche
bei denen der Benutzer der Usability-Eigenschaft entweder einfach zustimmen kann, oder sie als nicht erfüllt zurückweisen kann, dies aber
anschließend auch begründen
kann. Die Begründung kann aus einem Text bestehen oder der Benutzer kann einen (oder mehrere)
Screenshots der Website erzeugen
(s. Abb. 3) und diese mit zusätzlichen Anmerkungen oder Markierungen versehen (s. Abb. 2).
Abb. 2: Beispiel für grafische Annotationen
Um die Verständlichkeit von Fragen zu
erhöhen, kann der Testleiter die Fragen
durch Erläuterungen und Beispiele (etwa
auch mit Webadressen guter oder
schlechter Beispiele) ergänzen.
Das W-U-Tool wurde als DotNetAnwendung realisiert; die Fragebögen
und die Antworten werden in XMLDateien gespeichert. Somit kann die
Umgebung auf jedem Windows-System
eingesetzt werden. Da die Tools frei
verfügbar sind, bieten sie somit jedem
die Möglichkeit, seine Webseite qualitativ hochwertig und kostengünstig auf
gute Usability testen zu lassen. Aufgrund der detailierten Antworten ist es
Abb. 3: Eine ausführlich annotierte negative Antwort
154
ratsam nicht wesentlich mehr als zehn
Testpersonen einzusetzen.
4.0
Auswertung
Das Auswertungstool macht dem
Evaluator die Antworten der Testpersonen zugänglich. Neben einer einfachen
statistischen Auswertung liegt der
Schwerpunkt auf der Anzeige der durch
die Testpersonen aufgefunden Fehler
und der zugehörigen Beschreibungen.
Anschließend kann eine detaillierte Liste
der Fehler angezeigt werden. Bei
Ja/Nein-Fragen wird darin gezeigt, wie
viele der Tester einen Fehler fanden. Bei
den Annotationsfragen werden die ausführlichen Antworten und die dazugehörigen Screenshots angezeigt. Letztere
können durch Anklicken zur besseren
Darstellung in einem neuen Fenster
größer betrachtet werden. Sowohl die
Fragen selbst als auch die einzelnen
Testergebnisse werden nur angezeigt,
wenn überhaupt ein Problem bezüglich
einer Frage gefunden wurde.
bestehenden Liste ermöglicht.
Alternativ kann jede Frage einzeln
mit ihren Antworten angezeigt werden.
Somit bekommt der Evaluator mit den
beiden Listen zusammen de facto eine
ToDo-Liste, die anschließend Punkt für
Punkt abgearbeitet werden kann. Nach
Korrektur einer problematischen Usability-Eigenschaft kann dies Problem
als erledigt markiert werden. Da erledigte Fragen in beiden Bereichen
ausgeblendet werden können, wird im
Idealfall die ToDo-Liste immer kürzer.
Darüber hinaus können den erkannten
Fehlern auch Notizen hinzugefügt
werden.
So können Fragen und komplette Kategorien nach Wunsch bearbeitet, hinzugefügt oder entfernt werden (s. Abb. 4).
5.0
Fragebogeneditor UniTEQ
Um auf Probleme mit dem unterliegenden Fragebogen reagieren zu
können, wurde der Fragebogeneditor
UniTEQ (Universal Tool for Editing
Usability Questionnaires) entwickelt,
der eine beliebige Anpassung der
Existierende Fragebögen können an das
Testobjekt angepasst werden oder es
können völlig andere aus der Literatur
bekannte Fragebögen eingesetzt werden. Damit erschließt sich dem W-UTool ein erheblich erweiterter Einsatzbereich, der über reine Web UsabilityUntersuchungen weit hinausgeht.
W-U-T ist mit allen Komponenten (Befragungswerkzeug, Auswertung und
Fragebogeneditor) frei verfügbar. Es
entstand als Ergebnis von insgesamt
drei Studienarbeiten in der AG Szwillus
des Instituts für Informatik der Universität Paderborn.
Abb. 4: Der Fragebogen-Editor UniTEQ
155
Literatur
Balazs, B.: Mehr Umsatz durch Kundenzentrierung. ufos - der Usability Fragebogen für
Online-Shops, In: Unternehmen der Zukunft,
Aachen, 4 (2003) 3
Gediga, Hamborg, Düntsch (1999). The
IsoMetrics Usability Inventory: An operationalisation of ISO 9241-10, Behaviour and
Information Technology, 18
Dzida et al. (2001): Gebrauchstauglichkeit
von Software - ErgoNorm: Ein Verfahren zur
und 11. http://www.ergonorm.org.
Harms, I., Schweibenz, W., Strobel, J.
(2002): Usability Evaluation von WebAngeboten mit dem Web Usability Index.
Proceedings der 24. DGI-Online-Tagung
2002 - Content in Context. Frankfurt/Main:
DGI.
Neuhaus, J. (2003): Praxisgerechter
Check-up zur Usability-Überprüfung von-
156
Webseiten. Erschienen in: Informatiktage
2003. Fachwissenschaftlicher InformatikKongress; 07. - 08. November 2003 im Neuen Kloster Bad Schussenried
Nitzsche, S. (2007): Die ultimative UsabilityCheckliste. http://www.drweb.de/usability/
checkliste-usability.shtml.
Ong, C.-S., Lai, J.-Y., Wang, Y.-S. (2004).
Factors affecting engineers’ acceptance of
asynchronous e-learning systems in high-tech
companies. Information & Management, 41,
795-804.
Web-based Paper Prototyping mit RapidRabb.it
Ein Ansatz zum kollaborativen Prototyping
Volker Gersabeck
RapidRabb.it
Kirchhofstr. 43
12055 Berlin
[email protected]
http://rapidrabb.it
Silvan T. Golega
RapidRabb.it
Kirchhofstr. 43
12055 Berlin
[email protected]
http://rapidrabb.it
Tino Truppel
RapidRabb.it
Kirchhofstr. 43
12055 Berlin
[email protected]
http://rapidrabb.it
Abstract
Die benutzerzentrierte Entwicklung von
Software ist ein dynamischer und kreativer Prozess. Dies zeigt sich gerade in
den Phasen des Prototypings und der
Evaluation. Hier ergeben sich immer
wieder neue Herausforderungen an das
Design Team: die Vorstellungen des
Auftraggebers müssen verstanden werden, Ideen eines heterogenen Design
Teams müssen in Prototypen ausgedrückt werden, Feedback aus der verteilten Zielgruppe muss gewonnen werden, das Feedback muss in den statischen Prototyp eingearbeitet werden
und schließlich haben auch Entwickler
1.0
Startpunkt Paper Prototyping
Eine einfache Methode low-fidelity
Prototypen zu erzeugen, ist das Design
Team um einen großen Papierbogen
oder an einem Whiteboard versammeln
zu lassen, so dass jeder seine Ideen
direkt aufzeichnen kann. Diese Technik
unterstützt wesentliche Punkte des Prototyping: jeder kann den Prototyp jederzeit modifizieren, jeder kann die Änderungen der anderen sofort sehen und
vom Prototypen ist nichts verborgen.
Meinungen, welche berücksichtigt
werden sollten. Um das alles zu schaffen, ist eine Menge Kommunikations-,
Logistik- und Koordinierungsaufwand
von Nöten. Hier setzt dieser Ansatz
an, indem eine Lösung vorgeschlagen
wird, welche die Idee des PaperPrototypings in das Internet verlagert.
Dadurch werden wesentliche Vorteile
erzielt, wie die einfache Verteilbarkeit
der Prototypen, gemeinsames Arbeiten an einem Prototypen und die Verlinkung der Prototypen mit anderen
Dokumenten.
Keywords
Teile des Design Teams von verteilten
Orten aus arbeiten, kann Papier alleine keine Lösung sein. Es würde zu
aufwändig werden, die Ideen im Team
zu verteilen.
Nur so kann über Bedürfnisse, Anforderungen, Ideen, Machbarkeit und Wirtschaftlichkeit diskutiert werden. Jedoch
ist ein solcher Tisch nur schwer vorstellbar, denn nicht nur Zeitdruck und verschiedene Aufenthaltsorte der Akteure,
sondern auch unterschiedliche Anforderungen der Rollen machen eine Realisierung herausfordernd.
2.0
Rollen im Prototyping
Wesentliche Rollen während des
Prototypings sind die Nutzer, das Design Team, der Auftraggeber und die
Entwickler. Um ein erfolgreiches Produkt zu erschaffen, müssen diese Rollen an einen Tisch gebracht werden.
Jedoch bringt diese Anordnung einige
Nachteile mit sich. So wird es zunehmend schwieriger die Übersicht über
einen immer komplexer werdenden Prototyp zu bewahren und alle Teile immer
sichtbar zu halten. Auch sind Aktionen
nur schwer rückgängig zu machen. Zwar
kann leicht etwas gelöscht werden, doch
die Löschung wieder rückgängig zu machen, ist aufwändig. Wenn außerdem
Web-basiert, Kollaboration, Wireframe,
Papier-Prototypen, Evaluation
2.1
Die potenziellen Nutzer
Es ist aufwändig die Nutzer aus der
Zielgruppe in den Prozess zu integrieren, aber letztendlich können nur die
Nutzer eine qualitativ hochwertige „Quelle“ an Anforderungen sein. Während des
Prototypings geschieht dies meist durch
moderierte Usability-Tests.
2.2
Das Design Team
Das Design Team ist ein Zusammenschluss aus Rollen wie Interaction
Designer, Visual Designer, Information
Abb. 1: Rollen
157
Architect, Human Researcher, UsabilityExperten und Prototype Developer. Es
ist für den kreativen Teil der Entwicklung
und für die Gebrauchstauglichkeit verantwortlich. Um seine Ideen auszudrücken, erzeugt es kollaborativ Prototypen.
Erst hierdurch wird die Diskussion mit
anderen Rollen ermöglicht und innerhalb
des Design Teams vereinfacht.
2.3
Der Auftraggeber
Der Auftraggeber ist der Initiator des
Prozesses. Er will das Produkt letztendlich einsetzen oder verkaufen. Aus diesem Grund sind wirtschaftliche Aspekte
oft für ihn essentiell. Findet die Entwicklung intern statt, so ist er meist ein Mitglied des Managements. Um sicher zu
stellen, dass das Produkt seinen Vorstellungen entspricht, wird er in regelmäßigen Abstand die Prototypen durchsehen oder sich präsentieren lassen.
2.4
Die Entwickler
Die Entwickler implementieren das
Produkt. Sie sind eine wichtige Instanz,
welche entscheidet, ob etwas technisch
machbar ist oder nicht. Um dies zu beurteilen, brauchen sie Zugriff auf den Prototypen und eine Möglichkeit an der Diskussion teilzunehmen.
3.0
meint in diesen Kontext zweierlei: (1)
verschiedene Entwicklungsstände des
Prototypen, auf die später wieder zugegriffen werden können und (2) verschiedene Variationen des gleichen
Prototypen.
Arbeiten mehrere Personen gleichzeitig an einem Prototyp, so sind Konflikte
der Modifikationen nicht zu vermeiden.
Wünschenswert wäre, wenn eine Person ein Element des Prototypen ändert
und eine andere Person ein weiteres
Element bearbeitet, dass beide Modifikationen ohne weiteres Zutun angewandt werden. Wird ein Werkzeug
verwendet, welches EchtzeitKollaboration unterstützt, so werden
sich Konflikte auf ein Minimum reduzieren, da durch kurze Update-Zyklen
Änderungen sofort für andere sichtbar
werden. Außerdem wird die Wahrscheinlichkeit reduziert, dass Personen Elemente „gleichzeitig“ bearbeiten. Vor allem ein verteilt arbeitendes
Design Team wird auf ein solches
Feature angewiesen sein.
3.2
Prototypen im Kontext
Ein Prototyp existiert in Abhängigkeit von anderen Dokumenten. So
bestehen Anforderungen und Bedin-
gungen an das Produkt, welche zu Designentscheidungen führen. Auch sind
Referenzen auf Diskussionen, offene
Aufgaben oder andere Prototypen hilfreich. Zum Beispiel ist eine Diskussion
zwischen Entwickler und Mitgliedern des
Design Teams über einzelne Elemente
des Prototypen denkbar. Die Designer
haben Ideen, welche laut den Entwicklern nur schwer umsetzbar sind. Die
Designer liefern weitere Vorschläge, bis
ein Kompromiss gefunden wurde. Diese
Diskussion ist nicht Teil des Prototypen,
aber es wäre im späteren Prozess hilfreich, vom Prototypen auf sie zugreifen
zu können.
3.3
Präsentation der Ergebnisse
Ist ein Prototyp erzeugt, geht die eigentliche Arbeit mit ihm los. Er muss für
Usability-Tests verwendet werden, wird
für Präsentationen der Idee vor anderen
Akteuren genutzt und ist Teil der Spezifikation für Entwickler. Alle diese Akteure
benötigen Zugriff auf unterschiedliche
Sichten und Formate des Prototypen
und dies am Besten jederzeit und von
überall aus. Aus diesem Grund sollte der
Prototyp zugriffsbeschränkt im Internet
verfügbar sein. Für die Durchführung
von Usabillity- Tests muss der klickbare
Prototyp sehr einfach für den Testnutzer
Anforderungen an ein digitales
Prototyping
Sinnvoller als der erwähnte Tisch
erscheint ein virtueller Ort mit Prototypen, mit Dokumentation zu den Prototypen und mit der Möglichkeit, diese kollaborativ zu bearbeiten und darüber mit
anderen Akteuren zu kommunizieren.
Ein solcher Ort muss einige Anforderungen erfüllen. Die wichtigsten werden im
Folgenden skizziert.
3.1
Herausforderung Teamarbeit
Eine wesentliche Anforderung ist die
Möglichkeit Versionen vom gleichen
Prototyp zu verwalten. Versionierung
Abb. 2: Anforderungen
158
erreichbar sein. Am besten über einen
direkten Link. Außerdem wird für qualitative Tests ein direkter Kommunikationskanal zum Moderator benötigt.
Auch die Entwickler wollen auf den
klickbaren Prototyp zugreifen können,
um ihn „mal durchzuspielen“. Aber Entwickler sind auch auf andere Zugriffsmöglichkeiten angewiesen. So wird die
Wiederverwendung des Prototypen vereinfacht, wenn Exporte auf Zieltechnologien möglich werden. Dies würde es
Entwicklern erlauben, den Prototypen
weiter zu verwenden. Eine andere Notwendigkeit von Exporten geht vom Auftraggeber aus. Oft hat dieser nicht die
notwendige Zeit den kompletten Prototypen durchzusehen, hier würde eine
Kurzform des Prototypen als Präsentation Zeit sparen.
3.4
4.1
RapidRabb.it Prototype Creator
RapidRabb.it ein Werkzeug, wel-
5.
Beispielhafte Nutzung von
RapidRabb.it
Um die Funktionen verständlich zu
machen, wird nun im Folgenden ein
beispielhafter Prozess für die Nutzung
von RapidRabb.it aufgezeigt:
6.
7.
1.
Schnellere Iterationen
Ein wesentlicher Vorteil der digitalen
Lösung ist die Möglichkeit, schneller,
günstiger und gewinnbringendere Iterationen durchführen zu können. Jedoch
wird das nur passieren, wenn das Anpassen der Prototypen an neue Anforderungen so effizient wie möglich ist. Denn
anders als bei echten Papier-Prototypen
könnten digitale Papier-Prototypen wiederverwendet werden, so dass nicht der
Prototyp pro Iteration neu erstellt wird,
sondern nur angepasst werden muss.
Und das so, dass Elemente, welche
öfter im Prototypen vorkommen und
geändert werden sollen, nur einmal geändert werden müssen.
4.0
ches die beschriebenen Anforderungen unterstützt. Da es nicht die
benutzerzentrierte Entwicklung gibt,
gibt RapidRabb.it keinen festen Prozess vor, sondern unterstützt eine
Menge von Methoden und Rollen. Die
Reihenfolge der Methoden ist flexibel,
auch kann auf Rollen verzichtet werden.
2.
3.
4.
Der Auftraggeber und Mitglieder
des Design Teams treffen sich virtuell und diskutieren das Produkt.
Da RapidRabb.it eine webbasierte
Anwendung ist, können erste
Ideen bereits skizziert werden.
Dies hilft, ein gemeinsames Verständnis aufzubauen.
Das Design Team erarbeitet gemeinsam eine erste Version des
Prototypen. Hierbei greift jedes
Mitglied mit seinem Browser auf
den Prototypen zu. Änderungen
werden für alle sofort sichtbar.
Der Prototyp wird in einer stabilen
Version in einigen Usability-Tests
potenziellen Nutzern remote präsentiert. Diese können aus ihrer
gewohnten Umgebung (von zu
Hause oder von der Arbeit aus)
auf den Prototypen zugreifen und
direkt mit dem Moderator kommunizieren. Dies ermöglicht qualitative Tests.
Das Design Team verfeinert denselben Prototyp. Es besteht keine
Gefahr, dass Ideen versehentlich
5.0
überschrieben werden, da jederzeit
auf die vorhergehende Version zugegriffen werden kann.
Anschließend wird dem Entwicklerteam der aktuelle Stand zur Verfügung gestellt. Es greift asynchron
auf die Prototypen zu und kann
Feedback direkt im Prototypen ablegen. Das Design Team kann parallel am Prototyp weiter arbeiten,
da die Entwickler immer auf die jeweils aktuelle Version zugreifen.
Das Design Team arbeitet das
Feedback der Entwicklung durch
und fasst die Lösung in einem Prototyp zusammen.
Abschließend wird der Prototyp in
eine Präsentation exportiert und
dem Auftraggeber vorgestellt.
Fazit
Durch die Verwendung neuster
Technologien und Konzepte fördert RapidRabb.it die Grundideen einer benutzerzentrierten Entwicklung: Kollaboration, Wissensteilung, iteratives und Feedback getriebenes Vorgehen. Der Auftraggeber kann transparent auf den Prozessfortschritt zugreifen und damit diesen steuern; Entwickler werden durch
Reviews in die Entwicklung von Anfang
an mit eingebunden, was unnötige Iterationen vermeidet; potenzielle Nutzer
werden eingeladen, den Prototyp zu
testen und Feedback zu geben, ohne
dass sie ihre gewohnte Umgebung verlassen müssen; das Design Team sammelt das Feedback und verarbeitet es in
gebrauchstauglichere Prototypen. Dies
führt zu einen qualitativ hochwertigen
Produkt in weniger Iterationen, da alle
relevanten Akteure mit ihren Bedürfnissen an einen Tisch gebracht werden.
Abb. 3: Nutzung von RapidRabb.it
159
Swordfish: Eine Software zur asynchronen RemoteEvaluation der Usability von Webseiten
Prof. Dr. Norbert Gerth
Fakultät Informatik
Hochschule Augsburg
Postfach 11 06 05
86031 Augsburg
[email protected]
www.hs-augsburg.de
Thomas Krach
allevia GmbH
Rehmstraße 4
86161 Augsburg
[email protected]
www.allevia.de
Florian Pilottek
Fakultät Informatik
Hochschule Augsburg
Postfach 11 06 05
86031 Augsburg
[email protected]
www.hs-augsburg.de
Abstract
Anspruch dieses eigenen Ansatzes ist
es, das Grundprinzip des klassischen
Usability Tests im Labor in eine OnlineAnwendung zu „portieren“. Auf diese
Weise soll ein Remote-Testing ermöglicht werden, welches die Charakteristik
und die Vorteile des klassischen Labor-
1.0
Einleitung
Der Hintergrund des Konzeptes der
Software war eine Übertragung des bewährten Usability-Tests im Labor auf
das Internet. Der Ablauf sollte dabei
automatisiert werden, woraus sich ein
asynchroner Remote-Test ergibt. Aus
technischer Sicht waren die Voraussetzungen an die Software die einer Webanwendung, also kein Medienbruch zum
Testobjekt. Somit mussten einerseits
Wege gefunden werden, die Vorteile des
Labortests auf das Internet zu übertragen und dabei entstehende Nachteile
auszugleichen. Dabei standen geringe
Kosten des Tests und eine hohe Effizienz im Vordergrund.
Das Einsatzgebiet der Software sind
funktionstüchtige Prototypen oder fertige
Websites. Diese Software ermöglicht
eine permanenten Evaluation der Website und unterstützt ein iteratives Design.
Die Software stellt eine Kombination
bekannter Internet-Techniken dar, worauf das eigene Konzept beruht. Durch
die gezielte Online-Rekrutierung geeigneter Testpersonen direkt von der zu
testenden Webseite, lassen sich alle
realen Zielgruppen erreichen. Dabei gibt
160
tests weitgehend erhält und die Vorteile aus der unmittelbaren OnlineUmgebung (z.B. geringe Rekrutierungs- und Durchführungskosten, hohe Nutzeranzahl, Nutzer unmittelbar
aus der Zielgruppe) nutzt.
Keywords
es keine Einschränkung bzgl. des Aufenthaltsortes. Der Nutzungskontext
entspricht genau dem, in dem die
Webseite normalerweise auch verwendet wird.
2. Rekrutierung und Motivation
3. Beobachtung und Feedback
4. Fragebogen (ISO-Norm oder Szenario bezogen)
5. Auswertung und Ergebnisse
Da die Software selbst eine Webanwendung ist, werden außer einem
Webserver und einer Datenbank keine
weiteren Anforderungen gestellt. Somit
kann die Software sehr kostengünstig
eingesetzt werden und es bedarf keines weiteren technischen Aufwands.
Zu Beginn des Tests werden die allgemeinen Rahmenbedingungen wie Einund Ausstiegsseite, Zeitraum und Fallzahl festgelegt. Für die genaue Filterung
der gewünschten Testpersonen durch
das Online-Panel stehen technische
Informationen wie der Referrer, Browser,
Sprache, bereits besuchte Seiten der
Website oder wiederkehrende Benutzer
zur Verfügung. Im Rahmen des PreTest-Fragebogens, der bewusst auf ein
Minimum reduziert wurde, findet dann
die endgültige Auswahl anhand der Nutzerangaben bzgl. des Geschlechts, Alters, Erfahrungsstandes mit der Website, sowie des eigenen Zieles statt. Durch
die sehr gering gehaltene Einstiegshürde wird versucht, auch neue Nutzergruppen zu erreichen die, i.d.R. nicht an
Umfragen oder Tests teilnehmen, da
ihnen der Aufwand zu groß ist oder die
Motivation dazu fehlt. Genau an diesem
Punkt setzt der virtuelle Moderator an,
der die eigentliche Aufgabe des Testleiters im Labor übernimmt. Er leitet dabei
die Testperson durch den kompletten
Ziel ist es ein Tool zu erstellen, das,
ähnlich wie z.B. Google Analytics, einfach in die Zielseite einzubauen ist und
ein Webinterface für die Auswertung
bietet.
Der komplette Testablauf findet dabei
On-Site statt, so dass die Testpersonen die eigentliche Webseite nie verlassen müssen und auch weiterhin die
volle Kontrolle über den Browser und
den Besuch der Seite haben.
2.0
Testablauf
Die fünf Ablaufphasen orientieren
sich an denen eines Labortests:
1. Entwicklung Persona und Aufgabenszenario
Asynchron, Remote-Evaluation,
Usability-Test, Website-Evaluation
Test, angefangen von der Begrüßung
(es wird z.B. eine Belohnung in Form
eines 5 oder 10 € Gutscheins für Amazon in Aussicht gestellt) bis hin zum
abschließenden Fragebogen. Dieser
Moderator ist dabei eine reale Person in
Form von Bildern oder einzelnen Videosequenzen, die über Flash abgespielt
werden.
Abb 3: Feedback
x
x
x
Abb 2: Pre-Test
Abb 1: Virtueller Moderator
Somit ermöglicht die Software eine gezielte Filterung bestehender Nutzer der
Website und Rekrutierung von geeigneten Probanden, die auf der Website eine
reale Aufgabe erfüllen.
Erklärt sich der Nutzer dazu bereit, an
dem Test teilzunehmen, und erfüllt die
entsprechenden Kriterien der gewünschten Zielgruppe, erfolgt eine kleine Einweisung in den Ablauf des Tests.
Während des Tests kann der Proband
sich frei auf der Seite bewegen und seiner Aufgabe nachgehen. Der Moderator
ist dabei permanent an einer passenden
Stelle mit Hilfe eines Layers über der
Seite eingeblendet. Möchte der Proband
ein Feedback abgeben oder den Test
beenden, kann er dieses durch einen
Klick erreichen. Das Feedback ist in drei
Schritte aufgeteilt. Zuerst ordnet die
Testperson das Feedback in negativ
oder positiv ein. Die Skalierung ist dabei
ohne feste Stufen angelegt, da sich bereits in anderen Studien gezeigt hat,
dass die Einordnung der Testpersonen
nicht aussagekräftig ist (vgl. auch And
reasen et al. 2007) und dient primär
der Erfassung der gefühlten Bewertung durch den Probanden.
Im zweiten Schritt besteht die Möglichkeit, das Feedback zu kategorisieren.
Die verschiedenen Kategorien basieren dabei auf den 10 Heuristiken von
Jakob Nielsen und wurden zu sechs
Aussagen umformuliert, die sich auf
Funktionalität, Text, Sprache und Inhalt beziehen. Eine Mehrfachauswahl
ist dabei möglich. Der dritte Schritt ist
ein Freitextfeld, in dem der Proband
seine Gedanken in schriftlicher Form
abgeben kann. Das Feld ist am Anfang
drei Zeilen hoch, um einen gewissen
Umfang an Text zu fordern, aber auch
nicht größer, um den Nutzer nicht abzuschrecken. Das Feld passt die Höhe
automatisch während des Schreibens
an, falls der Proband mehr eingeben
möchte, und verhindert so ein sonst
notwendiges Scrollen innerhalb des
Textfeldes. Die Kategorien sind je
nach dem, ob positives oder negatives
Feedback abgeben wird, verschieden.
Die negativen Kategorien sind wie
folgt:
x
x
x
Direkter Link zu Seite ... fehlt
Der Inhalt ist unübersichtlich
Bedienung ist unverständlich und
kompliziert
x
Sprache unklar und unverständlich
Ich komme nicht mehr weiter
Konnte meine gewünschte Aufgabe
nicht ausführen
Sonstiges (freies Textfeld)
Jeder Nutzer, der die Website das erste
Mal besucht, wird als neuer Nutzer erkannt und mit einer eindeutigen ID versehen. Alle Seitenaufrufe werden dann
gespeichert, was einerseits für die Filterung passender Testpersonen zu Beginn
des Tests notwendig ist und während
des Tests zur Aufzeichnung des Nutzerverhaltens. Bei den Probanden werden
zusätzlich der Inhalt der Webseite und
alle Interaktionen (Maus und Tastatur)
chronologisch gespeichert. Mit Hilfe dieser Daten kann dann später eine Wiedergabe ähnlich einer Videoaufzeichnung rekonstruiert werden.
Die Software sieht zusätzlich zu dem
freiwilligen Feedback noch die Möglichkeit vor, von dem Nutzer ein Feedback
zu fordern, sofern bestimmte Kriterien
wie Verweildauer, Maus- und Scrollwege
einen definierten Sollwert überschreiten.
Damit dies nicht ständig zu einer Beeinträchtigung des Probanden führt, wirken
bereits abgegebene Feedbacks oder
Formulareingaben diesem Mechanismus
entgegen.
Hat die Testperson den Ausstiegspunkt
des Tests erreicht oder diesen selber
beendet, leitet der Moderator den Probanden durch den abschließenden Fragebogen.
161
Die Standardfragen basieren auf dem
ISO-Norm Fragebogen (Prümper & Anft
1993), der entsprechend für Websites
umformuliert wurde. Die Fragen wurden
in drei Blöcke zu je zwei Abschnitten
und je drei Fragen aufgeteilt. Ähnlich wie
der ISO-Norm Fragebogen werden dabei die jeweiligen Abschnitte immer mit
einem erklärenden Satz eingeleitet, um
dem Probanden den Hintergrund der
Fragen näher zu bringen. Dadurch soll
eine Art Dialog zwischen der Testperson
und dem Moderator vermittelt werden.
Die Beantwortung der Fragen ist in fünf
Stufen von absolut „nicht zutreffend“
bis „trifft zu“ aufgeteilt. Beantwortete
Fragen werden grau markiert, was der
Testperson eine Rückmeldung über den
Stand der Beantwortung gibt. Der Proband kann auch nach Belieben zwischen den drei Seiten des Fragebogens
vor- und zurückgehen. Die wichtigen
Begriffe in den Fragen sind hervorgehoben, was ein schnelleres Erfassen der
Aussage unterstützt.
vom Probanden abgegebenen Kommentare und Bewertungen angezeigt.
Abb 4: Post-Test Fragebogen
x
x
Content-Design
Informationsarchitektur
Bei der ersten Auswertung handelt
sich um die Ergebnisse des Fragebogens, die Rückschlüsse auf die ganze
Website zulassen.
Dabei werden der Mittelwert, die Standardabweichung, absolute und relative
Werte pro Frage ausgegeben. Die
Software bietet die Möglichkeit den
Fragebogen entsprechend anzupassen, um so bei den einzelnen Tests
genauere Ergebnisse bzgl. des Test-
Am Ende des Tests bedankt sich der
Moderator für die Teilnahme und überreicht den Gutschein. Wenn die Testperson eine Kontaktaufnahme wünscht,
kann sie an dieser Stelle auch ihre EMail Adresse hinterlassen.
Informationen wie wiederkehrende Besuche und Seitenaufrufe dieser Testperson werden auch weiterhin aufgezeichnet und ermöglichen so eine Beobachtung des konkreten Verhaltens dieses
Nutzers über den eigentlichen Test hinaus.
3.0
Auswertung und Ergebnisse
Die gesammelten Daten werden in
drei verschiedenen Auswertungen auf
bereitet, die sich an den drei Dimensionen einer Website orientieren.
x
Gesamteindruck
162
Die gesammelten Daten bzgl. Navigationswege und Bewertungen werden in
einer Baumstruktur grafisch aufbereitet.
Dabei ist die Wurzel die erste Seite des
Tests (es kann auch jede andere Seite
gewählt werden). Alle weiteren Seiten,
die von dieser aus besucht wurden,
werden je nach Zeitabstand und Häufigkeit weiter entfernt und mit einer dickeren Linie dargestellt. Zur besseren visuellen Erfassung sind die einzelnen Webseiten in Form von Thumbnails dargestellt und überwiegend positiv bewertete
Seite mit einem grünen Hacken oder
entsprechend negative mit einem roten
„X“ versehen.
Die Visualisierung findet dabei ebenfalls
im Browser mit Hilfe eines Flash-PlugIns
statt. Somit sind auch bei der Auswertung keine weiteren technischen Anforderungen notwendig und diese kann
von jedem Rechner mit Internetzugang
aus erfolgen. Wurde im Rahmen der
Entwicklung ein Navigationsmodell erstellt, kann dieses direkt mit dem tatsächlichen verglichen werden.
Abb 5: Auswertung Fragebogen
ziels zu ermitteln. Die zweite Auswertung ist der Replay-Modus, in dem der
Test ähnlich einem Video abgespielt
wird. Dabei sind die Mausbewegungen
und Tastatureingaben der Testperson
zu sehen. Mausklicks werden in Form
von immer (chronologisch) größer
werdenden Kreisen dargestellt. Zudem
können aktivierte Elemente der Webseite farblich markiert werden, um zu
erkennen, welche Bereiche genutzt
und welche nicht genutzt wurden. Unter dem Wiedergabefenster werden die
Abb 6: Auswertung Navigationswege
4.0
Technik
Um keine weiteren Anforderungen
an den Rechner der Probanden zu stellen wurden als Technik nur JavaScript
eingesetzt und aktivierte Cookies bei der
Testperson vorausgesetzt. Ein installierter Flash-Player ist optional vorgesehen.
5.0
Fazit
Die Software hat in ersten Tests gezeigt, dass Sie funktionieren kann. Interessant werden weitere Tests und eine
genaue Evaluation der Software, auch
im direkten Vergleich mit einem Labortest.
Ergonomie-Norm ISO 9241/10. FHTWBerlin, Fachgebiet Wirtschaftspsychologie.
Nielsen J. (1994): Ten Usability Heuristics.
www.useit.com/papers/heuristic.
Die gesammelten Daten können in weiteren Auswertungen noch detaillierter
visualisiert werden, um z.B. die Erstellung von Klick-Maps oder ähnliche Auswertungen darzustellen.
Der Ablauf des Tests spiegelt die Aspekte Beobachtung, Moderator und Feedback der Testperson wider. Das laute
Denken wird durch Kategorien und ein
Textfeld ersetzt. Fehlende Kontrolle
durch den Testleiter und die Möglichkeit,
Probleme in einem anschließenden Interview zu klären, werden durch die gezielte Auswahl an Probanden aus den
realen Nutzern und eine höhere Fallzahl
ausgeglichen.
Abschließend lassen sich die Nachteile
dieser Testmethode wie folgt aufführen:
x
x
x
Wenig Kontrolle über den Probanden
Interpretationsschwierigkeiten
Repräsentanzproblem
Die Vorteile dagegen sind:
x
x
x
x
x
x
x
Kosten- und Zeitersparnis
Leichte Rekrutierung
Natürliches Nutzerverhalten
Automatisierung, kein Medienbruch
Unabhängigkeit von Ort und Zeit
Konstante Testbedingungen
Verknüpfung von quantitativen und
qualitativen Daten
6.0
Andreasen, M. S.; Nielsen, H. V.; Schrøder,
S. O.; Stage, J. (2007): What Happened to
Remote Usability Testing? An Empirical Study of Three Methods. CHI 2007, San Jose,
California, USA.
Prümper, J.; Anft, M. (1993): Beurteilung von
Software auf Grundlage der Internationalen
163
Ein Tool zur Klassifikation und Auswahl von Evaluationsmethoden im User-Centred Design Prozess
Maximiliane Freymann
SirValUse Consulting GmbH
Schlossstrasse 8g
22041 Hamburg
[email protected]
Abstract
Evaluation ist ein wichtiges Prozesselement im Software Engineering sowie im
Usability Engineering. Um ein hohes
Maß an Usability sicherzustellen, sind
Evaluationsaktivitäten während der gesamten Entwicklung vonnöten. Eine
Schwierigkeit liegt darin, die jeweils geeignete Evaluationsmethode herauszufinden.
1.0
Einleitung
Verschiedene Ansätze beschäftigen sich
damit, wie User-Centred Design (UCD)
in einen existierenden Softwareentwicklungsprozess integriert werden kann. Ein
wichtiger Aspekt dabei sind Evaluationsaktivitäten, die idealerweise spezifisch für verschiedenen Arten von Anforderungen aus Software Engineering
(SE) und Usability Engineering (UE) sein
sollten.
Im SE fokussiert eine Evaluation beispielsweise auf die Überprüfung der
Vollständigkeit und Korrektheit der entwickelten Lösung, im UE dient sie hingegen zur Überprüfung der Nutzbarkeit
der entwickelten Lösung. Kriterien für
gute Nutzbarkeit liefert beispielsweise
die DIN EN ISO 9241-11, in der Effektivität, Effizienz und Zufriedenheit als
grundlegende Usability-Kriterien genannt werden (DIN EN ISO 9241-11
1999).
Um sicherstellen zu können, dass die
entwickelte Lösung jedoch vollständig,
korrekt und nutzbar ist, müssen beide
Perspektiven gleichermaßen berücksichtig werden. In diesem Beitrag wird ein
Tool vorgestellt, das die Auswahl von
164
Die Autorin präsentiert einen Ansatz
für die Auswahl geeigneter Evaluationsmethoden basierend drei Kriterien
– u.a. den Usability-Dimensionen Effektivität, Effizienz und Zufriedenheit und den Ergebnissen eines Entwicklungsprozesses.
Keywords
Evaluationsmethoden vereinfachen
soll, indem diese zum einen basierend
auf verschiedenen Kriterien klassifiziert werden und sich zum anderen am
DECIDE-Framework (Preece et al.
2002) orientieren, welches eine Anleitung zur Planung und Durchführung
von Evaluationen gibt. Das Tool ist ein
Ergebnis der Diplomarbeit der Autorin
(Freymann 2007).
methoden GOMS festgestellt werden.
Fragebogen bieten sich zur Messung
der Nutzerzufriedenheit an.
2.0
Usability-Kriterien
In der DIN EN ISO 9241-11 ist Usability definiert als "Das Ausmaß in dem
ein Produkt […] genutzt werden kann,
um bestimmte Ziele effektiv, effizient
und zufrieden stellend zu erreichen".
Es gibt in der heutigen Praxis etliche
Evaluationsmethoden, die diese drei
Usability-Kriterien adressieren.
So kann beispielsweise die Methode
des Cognitive Walkthroughs herangezogen werden, um mit Hilfe von Task
Scenarios die kognitiven Prozesse
beim Nutzer zu ermitteln und anhand
von Modellen Experten durch den Evaluationsprozess zu leiten, um so die
Effektivität einer Lösung festzustellen.
Die Effizienz einer Lösung kann beispielsweise mit Hilfe der Evaluations-
User Experience, User-Centred Design,
Evaluation, Evaluationsmethoden
Um jedoch die Usability einer Lösung
sicherstellen zu können, müssen alle
drei Kriterien evaluiert werden – beispielsweise durch einen inkrementellen
Ansatz, bei dem die Kriterien nacheinander mit den jeweils geeigneten Evaluationsmethoden überprüft werden.
3.0
Zeitpunkt der Evaluation
Der Fortschritt eines (Produkt-)Entwicklungsprozesses spiegelt sich sowohl
in der jeweiligen Prozessphase als auch
den (Zwischen-)Ergebnissen wider.
Während jeder Phase eines Produktentwicklungsprozesses werden unterschiedliche Aktivitäten durchgeführt, die
zu einer qualitativen Verbesserung oder
einem quantitativen Fortschritt führen.
Da diese Ergebnisse in einem iterativen
Prozess Teil der späteren Entwicklung
sind, folgt daraus, dass sie ebenfalls
kontinuierlich überprüft werden müssen.
Im Sinne einer ganzheitlichen Produktentwicklung, die sowohl SE als auch UE
berücksichtigt, müssen die Qualitätsansprüche beider Disziplinen bei einer
Evaluation gleichermaßen berücksichtigt
werden.
Dabei bilden Requirements den kleinsten gemeinsamen Nenner für die Entwicklung, da sie testbare Kriterien an
das System darstellen. Weiterhin wird in
der DIN EN ISO 13407 eine Evaluation
gegen Anforderungen gefordert (DIN EN
ISO 13407 1997) was bedeutet, dass
diese auch für das UE die Basis für Evaluationsaktivitäten darstellen sollten.
Jedoch unterscheiden sich im UE die
Anforderungen abhängig vom Prozessfortschritt. Zimmermann & Grötzbach
(2007) haben dazu ein Framework nutzerzentrierter Requirement-Arten entwickelt, das auf den einzelnen Phasen und
Ergebnissen des Prozessmodells der
DIN EN ISO 13407 basiert. Innerhalb
dieses Frameworks werden drei Arten
von Requirements unterschieden: Usability-, Workflow- und User Interface(UI-)Requirements. Diese drei Requirement-Arten beziehen sich auf die Ergebnisse aus den ersten drei Phasen
des Prozessmodells: Context of Use,
User Requirements und Produce Design
Solutions.
Durch die Auswahl geeigneter Evaluationsmethoden - abhängig vom Prozessfortschritt - zur Überprüfung der Arbeitsergebnisse, die den Requirement-Arten
entsprechen, kann die Usability der Lösung sichergestellt und kontinuierliche
Evaluation während des gesamten Produktentwicklungsprozesses vereinfacht
werden.
4.0
Untersuchungsgegenstand
Zusätzlich zu den Usability Kriterien und
den Requirement-Arten bildet auch die
Art des Untersuchungsgegenstandes ein
wichtiges Kriterium. Bei der Klassifikation der Evaluationsmethoden werden
drei verschiedene Kategorien von Untersuchungsgegenständen unterschieden: papierbasierte Untersuchungsgegenstände, Prototypen und Systeme.
Papierbasiert meint dabei, dass für die
Anwendung einer bestimmten Methode nicht notwendigerweise ein Prototyp oder ein lauffähiges System vorhanden sein müssen, sondern dass
beispielsweise auf Papier dargestellte
Konzepte ausreichend sind. Evaluationsmethoden auf Papier-Basis haben
den Vorteil, dass sie schnell, flexibel
und kostengünstig einsetzbar sind. Ein
Prototyp erfordert dagegen, dass
schon erste UI-Entwürfe umgesetzt
sind und die Funktionalität des späteren Systems soweit lauffähig ist, dass
erste Workflows durchgespielt werden
können. Mit System ist ein lauffähiges
System gemeint, bei dem nahezu alle
Funktionalitäten umgesetzt sind.
5.0
Nutzerbeteiligung
Durch die Integration von Nutzern bei
der Entwicklung kann sichergestellt
werden, dass ihre Sichtweisen mit
berücksichtigt werden und dass somit
das spätere System ihren Anforderungen genügt. Grundsätzlich sollte das
Ziel sein, Nutzer so früh wie möglich in
den Entwicklungsprozess mit einzubeziehen, um Probleme bei der Nutzung
früh zu entdecken und somit hohe
Kosten für eine spätere Nachbesserung zu vermeiden. Studien haben
gezeigt, dass Tests mit Nutzern Probleme aufzeigen können, die sonst nicht
entdeckt werden, und dass daher die
besten Ergebnisse durch Kombination
von empirischen Testmethoden und
Inspektionen erreicht werden (Nielsen
& Mack, 1994).
Es gibt jedoch auch Fälle, in denen
expertenbasierte Methoden die bessere Wahl sind. Bei diesen Methoden
wenden Usability Experten ihr Wissen
über Nutzer an und machen Vorhersagen darüber, wo Probleme auftauchen
können. Der Vorteil dieser Art von
Evaluationsmethoden liegt darin, dass
die Durchführung schnell und günstig
ist. Beispiele für expertenbasierte Methoden sind Heuristische Evaluation und
Cognitive Walkthrough.
6.0
Aufbau des Entscheidungsbaums
Es gibt also vier Dimensionen, die das
Grundgerüst für den Entscheidungsbaum bilden:
x
x
x
x
Usability-Kriterien aus der DIN EN
ISO 9241-11 Effektivität, Effizienz
und Zufriedenheit
Vier nutzerzentrierte RequirementArten als Indikator für den Prozessfortschritt
Art des Untersuchungsgegenstands,
d. h. ob die Methode papierbasiert
eingesetzt werden kann oder ob den
Einsatz ein Prototyp oder ein nahezu
vollständiges System benötigt wird
und
Nutzer-, bzw. Expertenbeteiligung
Anhand dieser Dimensionen wurde eine
Reihe von Evaluationsmethoden in eine
Klassifikationstabelle einsortiert. Durch
diese Darstellung lassen sich Evaluationsmethoden nach den verschiedenen
Dimensionen Usability-Kriterien, Prozessfortschritt, Untersuchungsgegenstand und Beteiligung schrittweise auswählen. Der Anwender kann damit eine
weiter verfeinerte Auswahl einer für den
jeweiligen Evaluationskontext geeigneten Methode vornehmen. Zusätzlich ist
ersichtlich, welche Methoden zur Überprüfung mehrerer Kriterien einsetzbar
sind.
Zur Vereinfachung der Verwendbarkeit
wurde anschließend aus der Klassifikationsmatrix ein Entscheidungsbaum generiert. Dieser erweitert das DECIDEFramework (Preece et al. 2002). Aus
dem Framework lässt sich bei der Planung einer Evaluation eine Reihe von
Fragen ableiten, nach deren Beantwortung eine geeignete Evaluationsmethode ausgewählt werden kann. Die Fragen, die sich aus dem DECIDEFramework ableiten lassen, sind folgende:
165
1.
Was sind die Ziele (Goals) der Evaluation?
2. Mit welchen Fragen (Questions)
lassen sich die Ziele operationalisieren?
3. Was sind einzusetzende Techniken
(Techniques)?
4. Was sind zu identifizierende Problempunkte (Practical Issues)?
Abb. 1: Entscheidungsbaum für den Untersuchungsgegenstand Prototyp
Anhand dieser Fragen und der Klassifikationsmatrix wurde der Entscheidungsbaum entwickelt, der nach Beantwortung
der Fragen die für den jeweiligen Kontext geeigneten Evaluationsmethoden
liefert.
Alle weiteren Entscheidungsbäume finden sich online in Freymann (2008).
Die Ziele (Goals) leiten die Evaluation
und können mit der Frage nach Effektivität, Effizienz und Zufriedenheit als Usability-Kriterien in Beziehung gesetzt werden. Die Fragen (Questions) machen
Ziele operational. Sie lassen sich auf die
drei nutzerzentrierten RequirementArten Usability Requirements, Workflow
Requirements und User Interface Requirements beziehen. Die einzusetzenden
Techniken (Techniques) stehen in Ver-
166
bindung mit dem Untersuchungsgegenstand, d. h. Papier, Prototyp und
System. Die Problempunkte (Practical
Issues) beinhalten Nutzerbeteiligung
und Expertise der Evaluatoren (Preece
et al. 2002).
7.0
Bewertung des Entscheidungsbaums
Die Nutzung des Entscheidungsbaums
ist durch den an den Fragen des DECIDE-Frameworks orientierten Aufbau
sehr einfach. Bei jedem Knoten im
Entscheidungsbaum kann eine Entscheidung in Form von „Trifft zu“ (Ja)
oder „Trifft nicht zu“ (Nein) erfolgen
und dem entsprechenden Pfad gefolgt
werden. Nachdem der Anwender einem Pfad durch den Entscheidungsbaum gefolgt ist, finden sich am Ende
eine oder mehrere Methoden, die für
eine Evaluation mit den vorgegeben
Kriterien geeignet sind. Findet sich am
Ende jedoch ein Kästchen mit einem
Fragezeichen, gibt es aus der Menge
der bisher betrachteten Evaluationsmethoden keine geeignete. In diesem
Fall müssen entweder andere Evaluationsmethoden zur Hand genommen
werden oder der Fokus der Evaluation
soweit angepasst werden, bis eine
Evaluationsmethode den Kriterien genügt.
Für den Anwender ist somit nach Beantwortung der aus dem Framework
abgeleiteten Fragen bereits bei der
Planung die Menge der einsetzbaren
Evaluationsmethoden zusammengefasst sichtbar. Zusätzlich ist schnell
ersichtlich, wohin der Evaluationsfokus
verschoben werden könnte, falls es für
einen speziellen Kontext keine Evalua-
tionsmethode aus der Menge der betrachteten Methoden gibt.
Im Rahmen der Diplomarbeit der Autorin
und dieses Beitrages wurden nur eine
Teilmenge aller verfügbaren Evaluationsmethoden betrachtet, wobei darauf
geachtet wurde, sowohl etablierte als
auch neu entwickelte Methoden mit einzubeziehen. Der präsentierte Ansatz
kann jedoch auch um bisher nicht untersuchte Evaluationsmethoden erweitert
werden. Die vorgestellten Dimensionen
bieten eine geeignete Grundstruktur, um
diese Methoden zu klassifizieren.
8.0
DIN EN ISO 9241-11 (1999). Ergonomische
Anforderungen für Bürotätigkeiten mit Bildschirmgeräten – Teil 11: Anforderungen an
die Gebrauchstauglichkeit. Berlin: Beuth.
DIN EN ISO 13407 (1999). Human-centered
design processes for interactive systems.
CEN - European Committee for Standardization, Brussels.
Preece, J., Rogers, Y. & Sharp, H. (2002).
Interaction Design – Beyond humancomputer interaction. New York, NY: Wiley.
Freymann, M (2007). Klassifikation nutzerzentrierter Evaluationsmethoden im User
Centered Design Prozess. Diplomarbeit. Universität Paderborn, 2007.
Freymann, M (2008). Entscheidungsbäume.
http://maxifreymann.de/Usability/Entscheidun
gsbaum/
Zimmermann, D., Grötzbach, L. (2007). A
Requirement Engineering Approach to UserCentered Design. HCII 2007. Beijing.
A r beitsmark t U s a bi l i t y
167
168
Branchenreport Usability 08
Sarah Diefenbach
Fortstraße 7
76829 Landau
[email protected]
Marc Hassenzahl
Fortstraße 7
76829 Landau
[email protected]
Abstract
Das Thema Usability erfährt wachsende
Aufmerksamkeit und Anerkennung. Jedes größere Unternehmen beschäftigt
mittlerweile Menschen mit der Aufgabe,
die Gebrauchstauglichkeit seiner Produkte zu verbessern. Mit steigender
Nachfrage nach „Usability Professionals“
auf dem Arbeitsmarkt steigt auch das
Interesse an allgemeingültigen Standards in Bezug auf Ausbildungswege,
Aufgaben und Qualitätsansprüche im
Usability-Bereich. Es zählt zu den Aufgaben eines Berufsverbands an dieser
Stelle Orientierung zu bieten.
1.0
Einleitung
Die Umfrage zum Branchenreport
Usability 08 ist bereits die dritte deutschlandweite Befragung unter Personen,
die sich beruflich mit Usability beschäftigen. Gerade bei noch relativ unbekannten Berufsbildern wie dem des „Usability
Professionals“ sind empirische Erhebungen dieser Art von großer Bedeutung. Bereits in der Branche Tätige
können ihre persönliche Arbeitssituation
besser einordnen und Personen, die
sich mit dem Gedanken beschäftigen,
später im Usability-Bereich arbeiten zu
wollen, erlangen eine realistische Einschätzung des Berufsfelds.
In erster Linie soll der Branchenreport
Usability Einblicke in mögliche berufliche
Laufbahnen, die Arbeitssituation und die
Verdienstmöglichkeiten in der Usability
Branche ermöglichen, was durch Fragen
zur Person, zur Aus- und Weiterbildung,
sowie zur momentanen Position und
Gehalt abgedeckt wurde. Außerdem
Einen Beitrag hierzu liefert der Branchenreport Usability: durch die Angaben von rund 200 Usability Professionals zu Person, Ausbildung, Arbeitssituation und Selbstverständnis kann die
„typische“ Situation von Usability Professionals in Deutschland abgebildet
werden. Dies ermöglicht den kritischen
Vergleich der eigenen momentanen
Situation mit Durchschnittswerten der
Branche. Darüberhinaus können auch
bislang nicht in der Branche Tätige
einen Überblick über die Themen und
Anforderungen der Branche erlangen.
Keywords
enthielt der Fragebogen dieses Jahr
erstmals auch einen subjektiven Teil,
in dem die Befragten durch den Grad
ihrer Zustimmung zu einzelnen Aussagen ihrer persönlichen Sicht auf die
Arbeitsweise von Usability Professionals Ausdruck verleihen konnten. Zum
Abschluss wurden die Teilnehmer gebeten, die ihrer Meinung nach bekanntesten Unternehmen der Branche zu
nennen. Insgesamt beinhaltete der
Fragebogen somit die folgenden Abschnitte:
fessionals’ Association, den Newsletter
der Usability-Gruppe in XING, weitere
Usability-Mailinglisten, sowie durch Anschreiben an Usability-Unternehmen im
deutschsprachigen Raum publik gemacht. Außerdem befand sich ein Link
auf die Umfrage auf der Website des
German Chapters der Usability Professionals’ Association (www.gc-upa.de).
x
x
x
x
x
x
Person
Ausbildung
Weiterbildung
Arbeitssituation
Selbstverständnis
Branche
2.0
Datenerhebung
Die Umfrage zum Branchenreport
erfolgte mittels Online-Erhebung von
Januar bis Mai 2008. Der Link zur Umfrage wurde über den Newsletter des
German Chapters der Usability Pro-
Usability Professionals, Ausbildung,
Arbeitssituation, Einkommen, Selbstverständnis
An der Umfrage teilgenommen haben in
diesem Jahr 223 Personen, von denen
200 Personen alle Fragen beantwortet
haben. Die Beteiligungsrate konnte somit gegenüber dem Vorjahr (185 Personen) noch einmal gesteigert werden.
Diese positive Entwicklung spiegelt
sicherlich das wachsende Interesse an
der Branche und die zunehmende Anerkennung von Usability Professionals als
eigenständigen Berufsstand wieder.
Nicht zuletzt erleichtern auch die steigenden Mitgliedszahlen im Berufsverband sowie die gute Vernetzung von in
der Branche tätigen Personen das Erreichen von potentiellen Umfrageteilnehmern.
169
Ergebnisse
3.0
Nachfolgend werden die Ergebnisse
der einzelnen Abschnitte der Befragung
beschrieben, und außerdem einige relevante Zusammenhangsanalysen dargestellt. Es wird von signifikanten Unterschieden gesprochen, wenn eine Irrtumswahrscheinlichkeit von weniger als
5% vorliegt (p < .05).
Person
3.1
Wie auch im letzten Jahr sind unter
den Befragten fast doppelt so viele Männer wie Frauen (62% vs. 38%)1. Das
Alter der Umfrageteilnehmer liegt zwischen 23 und 62 Jahren (Durchschnitt
bei 35 Jahren; md = 34). Allerdings gibt
es signifikante Altersunterschiede zwischen Frauen (m = 33,05) und Männern
(m = 35,33), dieselben Unterschiede
gibt es dementsprechend auch bei der
Berufserfahrung: Frauen sind im Durchschnitt seit 4,27 in der Usability-Branche
tätig, bei Männern sind es hingegen
bereits 6,89 Jahre.
Ausbildung
3.2
Eine wichtige Aufgabe des Branchenreports ist, Informationen über die
Ausbildungshintergründe von Usability
Professionals zusammen zu tragen.
Gerade für junge Menschen, die am
Anfang ihrer beruflichen Ausbildung
stehen und später im Usability-Bereich
arbeiten wollen, ist es natürlich wichtig
zu wissen: was muss ich tun, um in der
Usability-Branche arbeiten zu können?
Welches Studienfach erhöht die Chancen auf eine Anstellung, und welche
Rolle spielt meine Ausbildung für mein
späteres Gehalt? Es ist schwierig, hier
klare Antworten zu finden, da es, wie die
Ergebnisse dieser Befragung noch einmal verdeutlichen, (noch) keine einheitli-
1
Da die Mehrheit der Befragten männlich
ist, wird im Beitrag für Angaben zu weiblichen und männlichen Usability Professionals die männliche Form verwendet.
170
che Ausbildung für Usability Professionals gibt. Dennoch können die vorliegenden Ergebnisse Entscheidungen
vor Ausbildungsbeginn und die Einschätzung der persönlichen Chancen
und Möglichkeiten erleichtern.
Fast alle Usability Professionals (92%)
haben einen akademischen Abschluss. Spitzenreiter unter den Studienfächern ist wie auch im letzten
Jahr Psychologie (21%). Außerdem
häufig vertreten sind unterschiedliche
Design- (17%), Medien- (14%) und
Informatik-Studiengänge (11%). 26%
der Befragten haben eine Berufsausbildung gemacht, auch hier besteht
große Vielfalt: insgesamt wurden 32
verschiedene Ausbildungen genannt,
wovon sich bei einigen nur schwer ein
Bezug zur Usability-Branche erkennen
lässt. Der häufigste Ausbildungsberuf
ist mit 6 Nennungen Mediengestalter/in.
Sowohl medienwissenschaftliche
Studiengänge als auch Psychologie
scheinen als gute Vorbereitung auf
eine Berufstätigkeit in der UsabilityBranche zu dienen. 88% der Medienwissenschaftler und 77% der Psychologen geben an, Usability-Kenntnisse
bereits im Rahmen ihres Studiums
erworben zu haben; unter Designern
und Informatikern ist dieser Anteil mit
61% bzw. 57% etwas geringer. Neben
dem Studium spielen aber auch andere Möglichkeiten zum Wissenserwerb
eine wichtige Rolle: beispielsweise
„Training on the job“ (92%), die Weiterbildung in Eigenregie durch Zeitschriften und Bücher (88%) oder das
Internet (72%). 62% geben an, ihre
Usability-Kenntnisse unter anderem
durch Konferenzbesuche erworben zu
haben, 56% nennen den Austausch
mit Kollegen, und 25% nutzen spezifische Weiterbildungsangebote. Was
die alltägliche Häufigkeit der Nutzung
von Weiterbildungsangeboten angeht
(Frage nach der letzten Aktivität zur
Weiterbildung) so sind Konferenzbesuche (17%), Weiterbildung durch Fachzeitschriften/Fachbücher (16%) und der
Besuch von Schulungen oder Workshops (15%) die häufigsten Nennungen.
Abschließend kann festgehalten werden,
dass der Großteil der in der UsabilityBranche arbeitenden Personen über
einen Studienabschluss verfügt. Die
Studienfächer sind sehr vielfältig, was
beim Fehlen einer Standardausbildung
auch nicht überrascht. Umso wichtiger
ist die berufsbegleitende Aus- und Weiterbildung: neben „klassischen“ Aktivitäten wie das Lesen von Fachzeitschriften
und Büchern sind besonders Konferenzbesuche und das Internet als Quelle für
Informationsaustausch und Weiterbildung beliebt.
3.3
Momentane Position
Der Großteil der Befragten (81%)
arbeitet in einem Angestelltenverhältnis,
etwa ein Fünftel (19%) besitzt ein Unternehmen oder arbeitet freiberuflich. Der
Anteil der Arbeitszeit, der für Tätigkeiten
im Bereich Usability genutzt wird, ist bei
den Selbstständigen mit durchschnittlich
48% signifikant niedriger als bei den
Angestellten, hier sind es immerhin 69%
der Arbeitszeit. Keine signifikanten Differenzen zwischen den Angestellten und
Selbstständigen gibt es hingegen beim
Durchschnittsalter oder der Berufserfahrung im Bereich Usability.
Im Anschluss an die allgemeinen Fragen
zur Position wurden an Angestellter und
Selbstständige jeweils spezifische Fragen gerichtet. Die folgenden Ergebnisse
beziehen sich daher auf die jeweilige
Teilstichprobe.
3.3.1
Situation der Angestellten
Was die Größe des Unternehmens
angeht so arbeitet der Großteil der Angestellten entweder in einem eher kleinen Unternehmen mit weniger als 50
Angestellten oder in einem sehr großen
Unternehmen mit über 1000 Angestellten. Vergleichsweise wenige Usability
Professionals (15%) sind in Unternehmen mit zwischen 100 und 500 Angestellten tätig (siehe Abbildung 1).
Relative Häufigkeit
40%
Unternehmensgröße
30%
20%
10%
0%
1-50
51-100
1011000
>1000
Mitarbeiter
Abb.1: Unternehmensgröße
Die Unternehmenszugehörigkeit beträgt
durchschnittlich 4,28 Jahre (min: 0; max:
35; sd = 5,13). Interessant ist auch der
Vergleich von Unternehmenszugehörigkeit und Berufserfahrung im Bereich
Usability: bei gut der Hälfte (51%) übersteigt die Berufserfahrung die Dauer der
Anstellung beim jetzigen Arbeitgeber,
d.h. die Mehrheit der Angestellten hatte
vorher schon (mindestens) einem anderen Arbeitgeber in der Branche. Für 32%
handelt es sich höchstwahrscheinlich
um die erste Anstellung im UsabilityBereich (Unternehmenszugehörigkeit
und Berufserfahrung stimmen überein),
für 17% übersteigt hingegen die Unternehmenszugehörigkeit die Berufserfahrung im Usability-Bereich. In diesem Fall
zählten Usability-Tätigkeiten also nicht
schon immer zum Tätigkeitsbereich,
sondern kamen erst im Laufe der Zeit
hinzu, was die erfreulicherweise wachsende Anerkennung und Integration von
Usability bei den Unternehmen demonstriert.
31% der Angestellten tragen Personalverantwortung, wobei ein signifikanter
Zusammenhang zwischen Personalverantwortung und Geschlecht besteht:
männliche Angestellte besetzen eher
eine Position mit Personalverantwortung als weibliche Angestellte. Dieser
Zusammenhang bleibt auch dann bedeutsam, wenn der Einfluss von anderen für Personalverantwortung relevanten Variablen wie Alter, Berufserfahrung oder Unternehmenszugehörigkeit heraus gerechnet wird (partieller
Korrelationskoeffizient r = .22).
Wie auch im Branchenreport von 2007
lässt sich keine einheitliche Berufsbezeichnung der Beschäftigten der Usability Branchen erkennen. Zwar gibt es
„Klassiker“ wie „Usability Engineer“,
„Usability Consultant“ oder „User Interface Designer“, die mit Nennungen
von mehr als 10 Personen zu den verbreitetsten Bezeichnungen gehören,
insgesamt besteht mit 85 unterschiedlichen Bezeichnungen in diesem Punkt
jedoch große Vielfalt.
3.3.2
Situation der Freiberufler und Unternehmensinhaber
Die meisten der der selbstständig
tätigen Usability Professionals (68%)
arbeiten alleine oder mit 1 bis 2 Angestellten. Weitere 26% leiten ein kleines
Unternehmen mit 3 bis 15 Angestellten, Inhaber von Unternehmen mit
über 50 Angestellten bilden die Ausnahme (6% der Selbstständigen). Die
mehrheitlich genannte Unternehmensbezeichnung ist „Beratung“ (55%),
21% bezeichnen ihr Unternehmen als
„Agentur“, und 24% nannten andere
Bezeichnungen wie zum Beispiel
„Softwarehersteller“, „Design-Büro“
oder „Serviceprovider“.
Die bisherige Dauer der freiberuflichen
Tätigkeit bzw. des Unternehmensbesitzes beträgt zwischen 0 und 10
Jahren, wobei der Durchschnitt bei
4,12 Jahren liegt (sd = 3,01). Wie bei
den Angestellten, wurde auch bei den
Freiberuflern die Berufserfahrung im
Usability-Bereich mit dem Andauern
der momentanen Situation verglichen, in
diesem Fall also das Andauern des Unternehmensbesitz / der freiberuflichen
Tätigkeit bis zum heutigen Zeitpunkt: bei
21% übersteigt letzterer Wert die spezifische Berufserfahrung. Dies spricht
dafür, dass der Usability-Bereich erst
nach einigen Jahren Selbstständigkeit
als neues Tätigkeitsfeld hinzu kam und
die Beschäftigung mit Usability auch
heute noch nicht unbedingt den Hauptanteil der Arbeit ausmacht. Diese Annahme wird durch die Angaben zur
„Usability-Zeit“ gestützt, diese fällt mit
34% bei dieser Subgruppe vergleichsweise gering aus. Bei ebenfalls 21%
stimmen die Angaben zu Berufserfahrung und Dauer der Selbstständigkeit
überein, und bei 58% übersteigt die
Berufserfahrung die Dauer der Selbstständigkeit, die Differenzwerte liegen
hier zwischen 1 und 10 Jahren (m= 5,40;
sd = 3,28).
Um einen Überblick über typische Probleme und Hindernisse in der Usability
Branche zu erlangen, wurden die
Selbstständigen nach der ihrer Meinung
nach größten Herausforderung bei der
Entwicklung einer Unternehmung im
Usability Bereich gefragt. Unter den vielfältigen Antworten gehen lassen sich
drei grobe Kategorien erkennen. „Vermittlung der Relevanz von Usability“
scheint trotz wachsender Bekanntheit
des Themas noch immer ein großes
Problem zu sein, was sich beispielsweise in Äußerungen wie „zu vermitteln,
dass Usability einen geldwerten Nutzen
hat“, die Schwierigkeit „Usability in Präsentationen vor dem Kunden erfahrbar
zu machen“ oder auch dem Problem des
„beratungsresistenten Auftraggeber“
zeigt. Allerdings stellt die Vermittlung der
Bedeutung von Usability nur die erste
Hürde dar. Selbst wenn Usability in
einem Unternehmen als relevantes Thema anerkannt wurde, genießt es häufig
nur einen „vergleichsweise geringen
Stellenwert“. Für Usability steht oft nur
171
3.4
Gehaltsspiegel
Für den Gehaltsspiegel wurden die
Angaben von insgesamt 146 der Befragten berücksichtigt. Hiervon gaben 123
Personen (überwiegend Angestellte) ihr
Bruttojahresgehalt und 23 Personen
(überwiegend Selbstständige) ihren üblichen Stunden- und/oder Tagessatz an.
Darüberhinaus wurden einige Gehaltsangaben von der Analyse ausgeschlossen, da es sich um Extremwerte handelte, die zur Verfälschung der Ergebnisse
geführt hätten (z.B. Gehaltsangaben zur
Tätigkeit von Studenten als wissenschaftliche Hilfskraft). Der durchschnittliche Stundensatz der befragten Usability
Professionals liegt bei 65,60 € (n=17;
min = 25; max = 120; sd = 24,36), der
Tagessatz beträgt durchschnittlich
563,10 € (n=13; min = 200; max = 1200;
sd = 307,55), und als ungefähre Auslastung wurden 157 Tage pro Jahr angegeben (n = 14; min = 40; max = 280; sd
172
100.000
75.222
68.782
75.000
52.976
50.000
39.471
25.000
0
0-4
5-8
9-12
13-16
Berufserfahrung [Jahre]
Abb.2: Gehaltsspiegel
Neben der Berufserfahrung gibt es
auch signifikante Zusammenhänge
zwischen Einkommen und dem Alter
(r = .696) sowie Einkommen und Geschlecht (Durchschnittseinkommen der
Frauen: 45.134 €; Durchschnittseinkommen der Männer: 56.536 €). Eine
nähere Analyse deckt auf, dass geschlechtsabhängige Gehaltsunterschiede jedoch auf den bereits diskutierten Unterschied in der Berufserfahrung zwischen männlichen und weiblichen Usability Professionals zurückgeführt werden können. Der signifikante Effekt durch Altersunterschiede
bleibt hingegen auch bei Kontrolle von
Unterschieden in der Berufserfahrung
bestehen (partieller Korrelationskoeffizient r = .518). Obwohl Alter und Berufserfahrung ebenfalls positiv korreliert sind (r = .671), leisten beide
Variablen einen unabhängigen Beitrag
zur Aufklärung von Gehaltsunterschieden.
Auch in Abhängigkeit vom Unternehmensstandort lassen sich Gehaltsunterschiede feststellen: wie auch aus
anderen Branchen bekannt, liegen die
Gehälter in den neuen Bundesländern
(43.667 €) durchschnittlich fast 10.000
€ niedriger als in den alten Bundesländern (52.237 €).
Das durchschnittliche Einstiegsgehalt
(Berücksichtigung von Personen mit
Berufserfahrung 1 Jahr) liegt bei
38.228 €. Um die Bedeutung der vorherigen Ausbildung für die Verdiensthöhe
zu ermitteln, wurde das Einkommen der
Berufseinsteiger in Abhängigkeit vom
Studienfach analysiert; als Unterscheidungskategorien dienten hier die bereits
im Abschnitt „Ausbildung“ beschriebenen Studienfächer. Psychologen und
Informatiker steigen mit einem durchschnittlichen Bruttojahresgehalt von rund
45.000 € auf hohem Niveau ein. Die
Einstiegsgehälter von Designern und
Medienwissenschaftlern liegen mit rund
34.000 € bzw. 33.000 € niedriger (siehe
Abbildung 3).
60.000
Bruttojahresgehalt [€]
Insgesamt gesehen scheint die Unternehmensgründung in der UsabilityBranche nicht ganz einfach zu sein. Besonders die fehlende Anerkennung der
eigenen Dienstleistung seitens potenzieller Kunden stellt ein Problem dar.
Auch aus Unternehmerperspektive zeigt
sich also die Wichtigkeit der Vermittlung
der Relevanz von Usability über die
Usability-Branche hinaus“, wie es beispielsweise beim „World Usability Day“
geschieht.
= 68,78). Das durchschnittliche Bruttojahresgehalt beträgt 52.179 €, wobei
das Gehalt mit zunehmender Berufserfahrung signifikant ansteigt (r = .718;
siehe Abbildung 2).
Bruttojahresgehalt [€]
ein „geringes Budget des Auftraggebers“
zur Verfügung, und „bei Terminproblemen wird Usability als erstes gestrichen“. Nicht zuletzt stellt auch die unter
anderem durch das Fehlen einer einheitlichen Ausbildung begründete „Schwierigkeit der Qualitätssicherung“ ein Problem dar; dies verdeutlichen Äußerungen
wie „die eigene Professionalität darstellen zu können“, „die Sensibilisierung der
Kunden, was gute Usability ausmacht“
oder das „Pseudowissen“ der Konkurrenz.
45.500 44.775
40.000
34.250 32.750
20.000
0
Psy.
Inf.
Des.
Med.
Studienfach
Abb.3: Einstiegsgehälter
Vergleicht man diese Werte mit den für
den jeweiligen Abschluss üblichen Einstiegsgehältern, so verdienen Berufsanfänger in der Usability-Branche relativ
gut (UniSpiegel 1/2007).
3.5
Selbstverständnis
In diesem Abschnitt wurden die Befragten um Angaben zu ihrer persönlichen Sichtweise, was „gute“ Usability
Professionals ausmacht sowie um eine
Selbstbeurteilung gebeten. Hierzu war
zu insgesamt vier Aussagen der Grad
an Zustimmung auf einer fünfstufigen
Skala anzugeben. Insgesamt fanden die
meisten Aussagen eher Zustimmung als
Ablehnung: 69% bekräftigten die Aussage „In der Anwendung der von mir eingesetzten Methoden fühle ich mich absolut sicher.“ (Grad der Zustimmung 4
oder 5). Für die Aussage „Es macht einen guten Usability Professional aus,
dass er unterscheiden kann, wann es
sinnvoll ist den Nutzer einzubeziehen,
und wann nicht.“ war dies sogar bei 89%
der Fall. Auch die Aussage „Ich weiß
immer genau, an welchen Stellen der
Nutzer einbezogen werden sollte.“ fand
mit 79% breite Zustimmung. In ihren
Vorstellungen über Anforderungen an
Usability Professionals und ihrer Einschätzung der eigenen Kompetenz unterscheiden sich die Befragten also
kaum. Anders sieht es aus, wenn es um
das konkrete Vorgehen geht: Beim Item
„Es ist wichtig, den Nutzer bei allen Arbeitsschritten einzubeziehen.“ entschieden sich vergleichsweise viele für den
Skalenmittelpunkt (28%), und auch der
untere Bereich der Skala wurde stärker
genutzt als bei den anderen Items (siehe
Abbildung 4).
schätzung bekanntesten Unternehmen
erfragt. Insgesamt wurden 72 unterschiedliche Unternehmen genannt. In
Tabelle 1 sind die „Top 10“ der häufigsten Nennungen aufgelistet.
Tab. 1: Unternehmen der Usability-Branche
Relative Häufigkeit
40%
30%
x
10%
0%
1
2
3
4
5
Grad der Zustimmung
x
Abb.4: unterschiedliche Sichtweisen
3.6
Branche
Um einen Überblick über die Unternehmen der Branche in Deutschland zu
erlangen, wurden die nach eigener Ein-
Unternehmen
1
79
UI Design
2
67
SirValUse
3
34
SAP
4
19
E-Result
5
14
Siemens
6
13
Ergosign
7
11
Microsoft
8
10
Sapient
9
9
Eye Square
10
8
Phaydon
Fazit
Abschließend lässt sich die Situation von Usability Professionals in
Deutschland folgendermaßen zusammenfassen:
x
20%
Häufigkeit
4.0
x
"Es ist wichtig, den Nutzer bei
allen Arbeitsschritten
einzubeziehen."
50%
Rang
x
In der Usability-Branche arbeiten
in etwa doppelt so viele Männer
wie Frauen.
Das meist studierte Studienfach ist
Psychologie, die Bezahlung für
Psychologen in der UsabilityBranche ist im Vergleich zu ihren
ehemaligen Kommilitonen relativ
gut.
Die häufigste Arbeitssituation von
Usability Professionals in Deutschland ist eine Anstellung in einem
großen Unternehmen mit über 100
Angestellten.
Freiberufler arbeiten meist alleine
oder mit 1-2 Mitarbeitern, ihre Unternehmung bezeichnen sie meistens als „Agentur“.
Herausforderungen der Branche
sind vor allem die mangelnde Anerkennung und geringe Investitionsbereitschaft seitens der Kunden.
x
Die in der Branche üblichen Einstiegsgehälter sind mit gut 38.000€
relativ hoch.
Diese Auflistung von Merkmalen der
„typischen“ Arbeitssituation von Usability
Professionals gibt einen Überblick über
die häufigsten bzw. durchschnittlichen
Angaben der Befragten. Dem ist allerdings hinzuzufügen, dass diese prototypischen Angaben bei Weitem nicht die
Realität aller in der Branche Tätigen
abbilden können. Sie alle verbindet das
gemeinsame Thema Usability, gleichzeitig gibt es aber auch viele Unterschiede,
beispielsweise im Hinblick auf Ausbildung, Unternehmensgröße und Stellenwert des Themas innerhalb der beruflichen Tätigkeit.
Beim Usability Professional handelt es
sich um ein noch relativ junges Berufsbild; dies bringt mitunter schwierige
Bedingungen mit sich, wie die Ausführungen zu Herausforderungen der Branche verdeutlichen. Andererseits bietet
die sich im Wachstum befindende Branche auch großes Potenzial: Personen
mit verschiedenster Ausbildung können
ein neues, spannendes Tätigkeitsfeld
entdecken und (fast) von Anfang an
dabei zu sein. Für junge Menschen in
der Ausbildungsphase eröffnen sich
neue Perspektiven. Für die Zukunft wäre
natürlich eine Erhöhung der Anzahl von
Studiengängen und Ausbildungsmöglichkeiten mit spezifischer Ausrichtung
wünschenswert. Bei all diesen Aspekten
kann der Branchenreport unterstützen,
indem die Relevanz des Themas, die
Existenz des Berufsfelds und somit auch
der Bedarf an Ausbildungsmöglichkeiten
deutlich gemacht wird.
5.0
Uni SPIEGEL 1/07 (2007): http://wissen. spiegel.de/wissen/image/show.html?did=5051240
9&aref=image036/2007/02/12/ROUSP200700
100180020.pdf [01.06.2008].
173
shot is a cost. Peace on our terms is the
benefit. Battery evaluators see mostly
costs and few benefits.
4.0
Miss!
Measuring the wrong things in the
wrong place at the wrong time is hard to
value. There is no point in measuring
efficiency or effectiveness (as task completion) if they don’t matter. UX work can
be equally pointless by measuring emotions without regard for how they contribute to worthwhile outcomes within or
after interactive experiences.
comprehensive, lets us load, aim, fire
and check the result.
Designing as a human activity will always be subjective. Its norms and
ethos arise from the nature of design
outcomes, which “result from … decisions … Choice implies alternatives, in
how ends can be achieved, and for
whose advantage. … design is not
only about initial decision or concepts
by designers, but also about how
these are implemented and by what
means we can evaluate their effect or
benefit” (Heskett 2002, pp. 5-6).
There is limited, if any, summative value
in, measures of what are means to ends.
Such measures capture little of the complete means-end chains that shape how,
when and why means enable ends.
There are thus key design choices of:
Designers are often no better, also focused exclusively on means and never
firming up on ends. If designing has no
clear purpose, then so too will evaluation
focus on means, not ends.
A development process must explicitly
support and co-ordinate all four types
of design choice. If not, it does not
support designing, and at best is a
process of creative making. Support
for norms of designing can be expressed as expectations for development processes. Such expectations
can be expressed in specific contexts
as principles, which instantiate more
general meta-principles. Six such
meta-principles are necessary and
sufficient to support designing’s four
key choices:
5.0
Better by Designing?
The lessons from the artillery example are that we must not aim before
loading, and that we must be able to see
our targets and know whether we have
hit them. However, we cannot rely on a
remote battalion HQ to tell us where to
aim and whether we are hitting the target. We need to combine the battery and
the battalion HQ in an integrated approach to design management.
UX must be an integral part of development, but when integrated into the
wrong process, poor UX downstream
utility gets blamed for upstream futility
(Cockton 2007). UX can’t be expected to
fit into any development process and
deliver regardless. Development has to
be open to designing to let UX effectively support development of worthwhile
digital products. Designing, if and when
174
1.
2.
3.
4.
1.
2.
3.
4.
5.
6.
Means from alternatives
Ends (design purpose)
Beneficiaries (stakeholders)
Means of evaluation
Commitment
Receptiveness
Expressiveness
Inclusiveness
Credibility
Improvability
These meta-principles are holistic.
Commitment requires project teams to
overtly select means, ends, beneficiaries and evaluations.
Receptiveness requires being creatively open to alternative means, ends,
beneficiaries or evaluation methods.
Expressiveness requires effective representation of chosen means, ends, beneficiaries and evaluations, associations
between intermediate means, and between terminal means and ends.
Credibility needs feasible means, genuine ends for beneficiaries, relevant
evaluations, and plausible linking associations within means-end chains.
Improvability needs measurable means
and ends, evaluation instruments to
measure them, targets to hit, and
chances for more inclusiveness and
(recursively) more improvability.
Inclusiveness requires moral or ethical
justification of inclusion and exclusion of
stakeholders; for included stakeholders,
costs arising from chosen means must
be justified, as must benefits associated
with chosen ends, and also the ability of
chosen evaluations to properly assess
the balance of worth resulting from
achievable benefits given likely costs.
Project teams can partially instantiate
these six demanding meta-principles via
an appropriate framework. It is only
within specific development contexts
that principles can be fully instantiated.
A Worth-Centred Development (WCD)
framework is evolving to support partial
instantiation of the six meta-principles. It
is worth-centred, because it constructs
designing as the creation of worth, and
not just of value or of artefacts. Many
credible value propositions fail because
they do not offer sufficient value to offset
a wide range of costs. Price is one cost,
but others may be more important, such
as the cost of usage, ownership, integration of substitution. The latter two costs
are particularly important for digital products and services, which must have
good synergies within existing productservice ecosystems. Also, switching
costs must be acceptable. Together,
these costs can make even the most
apparently valuable design not worth it.
U sability Pra x i s I I
175
176
Erste methodische Erkenntnisse zur Usability-Analyse von
Video-Inhalten auf Websites mittels Eyetracking
Sven Pagel
Fachbereich Wirtschaft
Fachhochschule Düsseldorf
Universitätsstraße
40225 Düsseldorf
[email protected]
wirtschaft.fh-duesseldorf.de
Sebastian Goldstein
40225 Düsseldorf
[email protected]
Alexander Jürgens
40225 Düsseldorf
[email protected]
Abstract
Die zunehmende Verbreitung von VideoInhalten auf Websites erfordert spezifische Untersuchungen zur bewegtbildorientierten Web-Usability. Bei derartigen Inhalten ist je nach ihrem Zweck
zwischen originären und additiven
Videos zu unterscheiden.
1.0
Einleitung
Websites sind aus technischer Sicht
nicht zuletzt aufgrund wachsender Zahlen von Breitband-Anschlüssen (Van
Eimeren & Frees 2007, 365) heute
durch den zunehmenden Einsatz von
Bewegtbild-Material wie Videos, Flash
u.ä. geprägt. Darüber hinaus haben Bewegtbilder aus psychologischer Sicht
aufgrund des sog. Orientierungsreflexes
einen hohen Aufmerksamkeitswert
(Wirth 2004, 129). Dieser Artikel soll
einen Beitrag zur wissenschaftlich fundierten und zugleich praxisnahen Diskussion der akuten Anforderungen der
Web-Usability bei der Verwendung von
Bewegtbild-Inhalten leisten.
Der Text basiert auf aktuellen Forschungsergebnissen des Forschungsschwerpunkts Kommunikationsforschung der Fachhochschule Düsseldorf.
Hierbei wird auf die Erkenntnisse aus
Studien über die Wahrnehmung und
Nutzung von Bewegtbild-Stellenanzeigen in Jobbörsen, von Videos in
Online-Zeitungen und User-Videos auf
TV-Websites zurückgegriffen. Im Fokus
stehen somit technische, redaktionelle
und wahrnehmungspsychologische Er-
Ausgewählte Website-Beispiele mit
Videos aus der Medien- und Marketingkommunikation werden deshalb
hinsichtlich Angebot und Nutzung untersucht. Hierzu wird ein methodisches
Untersuchungsraster der Handlungsprozesse entwickelt.
Keywords
kenntnisse über Nutzung und Usability
von Bewegtbild-Inhalten wie Videos.
Teil des Angebots von YouTube und
anderen Video-Hostern bzw. VideoCommunities aus und sind teilweise der
Medienkommunikation zuzuordnen, da
hier Laien parajournalistisch tätig sind
(Neuberger 2002, 310).
2.0
Angebot und Nutzung von Bewegtbildern
Das Angebot an Bewegtbildern im
World Wide Web ist mannigfaltig. Aus
technischer Sicht lässt es sich u.a. in
Flash-Formate, Video-Formate wie
H.264 oder Windows Media Video
unterteilen. Videos können per Streaming oder Download abgerufen werden. Im Mittelpunkt dieser Untersuchung stehen Video-Clips. In Abhängigkeit des jeweiligen Anbieters lassen
sich redaktionelle, werbliche und nutzergenerierte Videos differenzieren,
die informativen oder unterhaltenden
Inhalt haben können.
Redaktionelle Video-Clips finden sich
beispielsweise auf den Websites von
Fernsehsendern oder Onlinezeitungen
(Medienkommunikation). Werbliche
Clips werden z.B. über Portale wie
www.autofernsehen.de zur Verfügung
gestellt, als Pre-Roll-Spot in andere
Videos auf beliebigen Websites eingebunden oder durch virale Formen verbreitet (Marketingkommunikation).
Nutzergenerierte Clips machen einen
Eyetracking, Bewegtbild, Video, Medienkommunikation, Marketingkommunikation
Hinsichtlich der Einbindung in die Websites lässt sich eine weitere Unterscheidung identifizieren. So sind originäre
Bewegtbilder der eigentliche Zweck einer Website wie z.B. bei YouTube oder
Online-Mediatheken, während additive
Bewegtbilder multimediale Zusatzinformation zu einer Textanzeige beispielsweise in einem Stellenportal darstellen.
Gesamt
weiblich
männlich
14-19 J.
20-29 J.
30-39 J.
40-49 J.
50-59 J.
ab 60 J.
Audio
Video
2006 2007 2006 2007
12
14
7
14
8
10
3
8
15
18
11
19
32
39
22
46
15
28
10
24
12
11
7
9
6
6
3
3
2
3
2
7
2
2
1
2
Basis: Onlinenutzer ab 14 Jahre in Deutschland
(2007: n=1.142)
mindestens einmal wöchentlich, in %
Abb 1: Abruf von Audio-/Videodateien (Van
Eimeren & Frees 2007, 370)
177
Die Nutzung von Videodateien im Internet hat in den vergangenen Jahren stark
zugenommen. Während 2006 erst sieben Prozent der Onliner mindestens
einmal wöchentlich Videodateien abgerufen haben, lag dieser Wert ein Jahr
später bereits bei 14 Prozent (Van Eimeren & Frees 2007, 370).
Der Handlungsprozess beim Videoabruf
auf einer Website geschieht in den folgenden drei Schritten. Zunächst muss
die reine Existenz des Videos bzw. von
dessen Icon (siehe Abbildung 4) oder
anderen Interaktionsschnittstellen auf
der Website durch den Nutzer bewusst
wahrgenommen werden. Vor der Aufmerksamkeit als aktive Zuwendung liegt
die Wahrnehmung als Erfassung der
Umwelt (Goldstein 2002, 5). Bei additiven Video-Inhalten geschieht dies vermutlich langsamer als bei originären
Video-Inhalten (1. Aufmerksamkeit auf
Video). Fühlt sich der Nutzer angesprochen, erfolgt im nächsten Schritt die
Betrachtung der Videos. Dies kann über
die Sinnesmodi Akustik und/ oder Visualisierung erfolgen. So wäre durchaus
denkbar, dass Videos nur im Hintergrund abgespielt werden. Relevant ist
zudem die Informationsverarbeitung
durch den Betrachter (2. Visuellakustische Verarbeitung des Videos).
Ergänzend ist die Navigation in den Videos entscheidend, die u.a. von der
Player-Funktionalität abhängig ist (3.
Interaktion mit Video). Zwischen der
Verarbeitung und der Interaktion bestehen reziproke Interdependenzen.
Diese Logik lehnt sich am dreistufigen
Handlungsprozess in der MenschComputer-Interaktion an, aus erstens
der Intention, ein Ziel zu erreichen, zweitens der Durchführung einer Handlung
und drittens der Steuerung der Durchführung (Dahm 2006, 88). Aus psychologischer Sicht sind Aufmerksamkeit,
Informationsselektion und Informationsverarbeitung relevant (Bente 2004, 302).
178
3.0
Methodik zum Eyetracking von
Videos
Die Untersuchung von Videos mittels Eyetracking kann an diesem Nutzungsprozess anknüpfen. Zunächst
gelten für Eyetracking Untersuchungen
von Video-Angeboten dieselben methodischen Anforderungen wie an andere Usability-Tests (Schweibenz &
Thissen 2003, 76). Neben der reinen,
quantitativen Blickregistrierungsanalyse sollten im Anschluss auch qualitative Daten (mittels Befragungen oder
Posttest-Fragebögen) erhoben, um die
jeweilige Wirkung gestützt oder ungestützt ermitteln zu können.
Von einem Methodenmix (Erhebung
qualitativer und quantitativer Daten)
während des Eyetrackings sollte möglichst abgesehen werden (Arndt 2006,
257). Qualitative Daten sollten bei Eyetracking-Untersuchungen möglichst
ex-post erhoben werden, denn periaktionale Evaluationsverfahren wie die
klassische Methode des Lauten Denkens induzieren eine verzerrende Wirkung auf die Blickdaten. Der kognitive
Aufwand dieser Methode behindert
das natürliche Nutzungsverhalten von
Web-Angeboten (Arndt 2006, 257).
Alternativ könnte die postaktionale
Methode des Lauten Denkens (auch
Retrospective Testing genannt) angewendet werden.
3.1
Technische Spezifika des Eyetrackings von Videos
3.1.1
Testvorbereitung
Sind bei Eyetracking-Studien additive Bewegtbilder Untersuchungsgegenstand, müssen zunächst ausreichend geeignete zielgruppenbezogene
Videos identifiziert werden. Bei einer
durch den Forschungsschwerpunkt
durchgeführten Untersuchung von
Video-Stellenanzeigen war beispielsweise zunächst eine Differenzierung
nach Angeboten für Wirtschaftswis-
senschaftler, Ingenieure und Sozialwissenschaftler vorgesehen, um unterschiedliche Nutzer-Charakteristika zu
erfassen. Die Berücksichtigung von sozialwissenschaftlichen Jobsuchenden
war allerdings nicht möglich, weil derartige Stellenanzeigen derzeit in den einschlägigen Job-Portalen gar nicht mit
ergänzenden Videos angeboten werden.
3.1.2
Testdurchführung
Bei der Testdurchführung ist insbesondere die kombinierte Datenaufzeichnhrunder Videos mit EyetrackingInformationen die zentrale Herausforderung. Videospezifische Probleme hierbei
sind u.a. die Größe des BewegtbildContents. Bei relativ kleinen Bewegtbildern z.B. in Thumbnail-Größe (ca.
100x80 Pixel) entspricht die Größe des
Bewegtbildes ungefähr dem fovealen
Bereich des Auges -1 bis 2 Grad um die
Sehachse oder 1 bis 5 Grad des Blickwinkels (Duchowski 2002, 17)-, also
dem Bereich auf dem Monitor,nder vom
Auge scharf gesehen wird (bei einem
normalen Sehabstand von 50 cm zum
Bildschirmgerät beträgt dieser Bereich
ungefähr 3 cm²). Diese Deckhrunhat zur
Folge,ndass für die Informationsaufnahme von Bewegtbildern keine Sakkaden
nötig sind. Folglich verlängern sich die
Fixationen auf diesen Bereich. Diese
längeren Fixationen sind jedoch hinderlich für die Auswertung. Um Fixationen
sichtbar zu machen, werden diese als
rote Punkte über den Stimuli gelegt. Der
Durchmesser der roten Fixationspunkte
entspricht dabei der Fixationslänge.
Folglich können lange Fixationen auf
eine Koordinate den dahinter liegenden,
dynamischen Inhalt so verdecken, dass
eine Auswertung nicht mehr möglich ist.
Diese Problematik ist auch bei Eyetracking-Untersuchungen von Games
(insb. Ego-Shootern und Rennspielen)
vorhanden, da bei diesen Spielen oftmals ebenfalls eine längere Fixierung
auf bestimmte Bildschirmkoordinaten
erfolgt.
Abb 2: Stellenzeige mit integriertem Video
(www.stellenanzeigen.de) (Pagel & Goldstein
2008)
Ein weiteres videospezifisches Problem
stellen die Video-Player dar. Diese externen oder integrierten Video-Player
nutzen für die Steuerung oftmals Tastatureingaben, die bereits von der Aufzeichnungs- und -steuerungssoftware
belegt sind. Beispielsweise ist bei Tobii
Studio die Esc-Taste für den Testabbruch vorgesehen. Beim Flash-Player
wird diese Taste jedoch benötigt, um
den Vollbildmodus zu verlassen. Versucht ein Proband während des Tests,
den Vollbild-Modus durch Drücken der
Esc-Taste zu verlassen, erfolgt unweigerlich der Testabbruch.
3.1.3
Testauswertung
Methodische Fragen bei der Testauswertung von Blickregistrierungsstudien von Video-Inhalten sind die folgenden. In Abhängigkeit der Größe des
Player-Fensters sind Heatmaps nur bedingt aussagefähig, weil die Fixationen
der Probanden im Video-Fenster nur
bedingt differenziert werden können.
Problematisch gestaltet sich die Auswertung von dynamischen Inhalten, wie
diese bei Bewegtbildern immanent sind.
Gängige Auswertungstools, z.B. Tobii
Studio, sind nur in der Lage, statische
Stimuli automatisch zu analysieren. So-
mit sind Gaze-Plots und Heatmaps
nicht aussagekräftig, da sich diese auf
einen statischen Content beziehen.
Gelöst werden kann diese Problematik
derzeit nur durch eine manuelle Auswertung. So kann mit Hilfe einer
Replay-Analyse ermittelt werden, welche Inhalte des Bewegtbildes ein Proband betrachtet hat. Diese Methode
gestaltet sich jedoch als überaus aufwändig, da die Probanden die Bewegtbildinhalte in der Regel zu unterschiedlichen Aufzeichnungszeitpunkten gestartet und ihre Aufmerksamkeit
mit anderen Informationsquellen geteilt
haben. Daraus folgt, dass für jeden
Probanden die Blickdaten auf das Bewegtbild Frame-für-Frame ermittelt
werden müssen. Sind diese Daten
ermittelt, können für jedes Frame die
Blickdaten entsprechend der anvisierten Zielgruppen kumuliert werden.
3.2
Redaktionelle Spezifika des Eyetrackings von Videos
Anbieter können Videos in unterschiedlichen Formen (Insite, Pop-up
oder Microsite), Abspielmechanismen
(mit und ohne Autostart), Formaten
und Bitraten in ihre Websites einbinden. Diese redaktionelle Entscheidung
liegt bei ihnen und wird nur bei der
Bereitstellung mehrerer Alternativen
teilweise an den Nutzer übertragen.
Hieraus ergeben sich Konsequenzen
für die Zielsetzung und methodische
Durchführung von EyetrackingUntersuchungen von Video-Inhalten.
Gemäß des oben dargestellten Nutzungsprozesses muss in UsabilityStudien zunächst zutage gefördert
werden, welche der Einbindungsformen von welchen Nutzern präferiert
werden. Darüber hinaus ist zu fragen,
ob die Inhalte der Videos den Nutzern
einen Mehrwert bieten.
3.3
Psychologische Aspekte des Eyetrackings von Videos
Das Nutzungsverhalten der Probanden bei Videos in Websites kann anhand des Nutzungsprozesses u.a. mit
den folgenden Kriterien untersucht werden (vgl. zu Kriterien des Eyetrackings
Bente 2004 und Kempter & Dontschewa
2007).
1. Aufmerksamkeit auf Video
x
Insbesondere bei additiven Bewegtbildern: erstmalige Wahrnehmung (in
Sekunden) als Maß der Auffälligkeit
x
Alternativ auch erstmalige Wahrnehmung (in Fixationsrang)
2. Visuell-akustische Verarbeitung
x
Durchschnittliche Betrachtungsdauer als Maß der Komplexität
x
Ausschließliche versus parallele
Nutzung mit anderen Elementen
dieser oder anderer Websites
3. Interaktion mit Video
x
Präferenz der Nutzer für Abspielmechanismen (z.B. mit versus ohne
Autostart)
x
Präferenz der Nutzer für Darstellungsformen
x
Verständnis der Nutzer für die gewählte Navigationslogik im Video
4.0
Erste Forschungsergebnisse
Da Bewegtbilder in zahlreichen
thematischen Kontexten auf unterschiedlichsten Websites angeboten
werden, wurde durch den Forschungsschwerpunkt Kommunikationsforschung
eine bewusste Auswahl getroffen. Bisherige Untersuchungen konzentrieren sich
deshalb auf Video-Inhalte in der Medienkommunikation (Online-Zeitungen,
TV-Websites, Online-Mediatheken) und
in der Marketingkommunikation (Personalmarketing mit Stellenanzeigen). Für
179
die Bewertung der Usability von Bewegtbildern scheint insbesondere von
Wichtigkeit, ob es sich um Videos mit
einem originären Informationsgehalt für
die jeweilige Website oder um additive
Bewegtbilder handelt.
4.1
Originäre Bewegtbilder
Originäre Video-Inhalte sind seltener zu finden als additive. Natürlicher
Anbieter sind die Medienunternehmen.
Als beispielhafter Untersuchungsgegenstand sind hier deshalb OnlineMediatheken von Fernsehsendern geeignet. In Vorbereitung von diesbezüglichen Usability-Tests wurde in einem
ersten Schritt die Entwicklung der Mediatheken von ARD, ARTE, ProSieben,
RTL und ZDF untersucht (Pagel 2008).
Dabei stellte sich heraus, dass nutzerspezifische Anforderungen der Usability
beim Aufbau von Mediatheken noch
keine besondere Berücksichtigung seitens der Medienunternehmen fanden.
Nach dieser ersten Analyse der vorhandenen Angebote ist in einem zweiten
Schritt die Nutzung zu untersuchen. Die
(1) Aufmerksamkeit auf die Videos tritt
hier in den Hintergrund, da der Nutzer
ohnehin entsprechende BewegtbildAngebote auf diesen Websites erwartet.
Denn diese stiften den Kernnutzen der
Mediatheken. Dies lässt auch vermuten,
dass die (2) Nutzung durch User in fokussierter Betrachtung geschieht. Bei
der (3) Interaktion werden Navigationselemente weitgehend dynamisch eingeblendet und traditionelle vom Zuschauer
gelernte Fernseh-Gewohnheiten mit den
interaktiven Möglichkeiten des Videos
kombiniert (Schmidt 2008, 161).
4.2
Additive Bewegtbilder
Additive Videos wurden sowohl in
der Medien- als auch in der Marketingkommunikation untersucht. Im Feld der
Medienkommunikation wurden redaktionelle Inhalte anhand von Videos in Onli-
180
ne-Zeitungen betrachtet sowie nutzergenerierte Inhalte anhand von User
Generated Content auf TV-Websites.
Im Feld der Marketingkommunikation
wurden als beispielhafter Untersuchungsgegenstand VideoStellenanzeigen herangezogen.
Auch bezüglich der additiven Bewegtbilder wurde zunächst das bestehende
Angebot in den Fokus genommen. So
ist der Einsatz von ergänzendem Video-Material bei Online-Zeitungen
bereits stark verbreitet. Von 123 in
einer Marktanalyse empirisch untersuchten Online-Zeitungen bieten 67
tatsächlich Video-Inhalte an (Gerhards
& Pagel 2008a, 169). Eine einheitliche
Navigationssystematik hat sich dabei
noch nicht durchgesetzt. Stattdessen
finden sich Video-Verteilseiten in der
ersten und zweiten Navigationsebene,
in der Metanavigation, als BannerTeaser, als Content-Link und in diversen Mischformen.
Navigation zum Videoangebot
0 = keine Erreichbarkeit über Startseite,
nur vereinzelte Videos
1 = Rubrik in erster Navigationsebene
2 = Rubrik in zweiter Navigationsebene
3 = Rubrik in Metanavigation
4 = Bannerteaser
5 = Link im Content-Bereich
6 = Angebot mehrerer Rubriken
7 = Sonstiges
Summe (inkl. Doppelnennungen)
Regionale
Überregionale
Anbieter
Anbieter
(n=67)
(n=8)
Absolut Relativ Absolut Relativ
0
0,0%
20 29,9%
30 44,8%
8 11,9%
20 29,9%
14 20,9%
5
7,5%
0
0,0%
97 144,8%
dung von nutzergenerierten Videos auf
TV-Websites allerdings noch zurückhaltend. Nur vier der untersuchten TVUnternehmen bieten auf ihren SenderWebsites nutzergenerierte Video-Inhalte
an (Gerhards & Pagel 2008b).
Im Feld der Marketingkommunikation
wurde beispielhaft das Personalmarketing mittels Video-Stellenanzeigen ausgewählt (Pagel & Goldstein 2008). Das
Angebot wurde im Rahmen einer unternehmensbezogenen Projektarbeit identifiziert. Die Nutzung von Videos wurde
durch den Forschungsschwerpunkt anschließend in Form einer Blickregistrierungsstudie untersucht. Im Mai und Juni
2008 wurden hierzu knapp 20 studentische Probanden aus den drei Fachbereichen Wirtschaft, Medien und Maschinenbau mit jeweils thematisch passenden Stellenanzeigen konfrontiert. Diese
waren in unterschiedlicher Form mit
Videos kombiniert. Teilweise waren die
Videos in einem Insite-Player eingebunden, teilweise auch nur mit einem Fotooder Grafik-Icon gekennzeichnet.
1 12,5%
2 25,0%
2 25,0%
2 25,0%
1 12,5%
3 37,5%
1 12,5%
0
0,0%
12 150,0%
Abb 3: Navigationswege zu Videos bei
Online-Zeitungen (Gerhards & Pagel
2008a, 172)
Neben redaktionellen und werblichen
Video-Clips sollen vor dem Hintergrund des zunehmenden Social Networkings wie oben erwähnt auch nutzergenerierte Video-Clips Berücksichtigung finden. Diese wurden auf 24
TV-Websites untersucht (Gerhards &
Pagel 2008b). Es wurde auch bei dieser Form von Video-Inhalten gemäß
der obigen Systematik die Analyse von
Bewegtbildern mit einer Auswertung
des vorhandenen Angebots begonnen.
Zum jetzigen Zeitpunkt ist die Einbin-
Abb 4: Foto-Icon (http://www.jobware.de/
Administration/view/pics/viewer_button_
jobtv.gif)
Anhand des dreigliedrigen Schemas des
Nutzungsprozesses lassen sich die Erkenntnisse darstellen. Die (1) Aufmerksamkeit auf die zusätzlichen Videos von
Text-Stellenanzeigen ist höher, wenn
seitenintegrierte Videos eingesetzt werden. Foto-Icons werden von den Probanden kaum wahrgenommen und
dementsprechend auch nicht als Symbol
für zugehörige Video-Inhalte erkannt.
Die (2) Nutzung von Bewegtbildern in
Stellenanzeigen ist gemäß dieser ersten
Untersuchung durchaus im Interesse der
Personal-Verantwortlichen in den Unter-
nehmen. Denn Bewegtbilder haben tendenziell eine positive Wirkung auf die
Einstellung der Probanden zum Unternehmen. Additive Bewegtbilder werden
somit als Informationsquelle angenommen. Zudem wird der Inhalt der Bewegtbilder bei einer Mehrzahl der Probanden
auch ungestützt erinnert, sie haben also
eine positive Erinnerungswirkung.
Auch erste Erkenntnisse zur (3) Navigation in Video-Stellenanzeigen konnten
gesammelt werden. Einige der untersuchten Stellenanzeigen wurden mit
Autostart offeriert, andere Vergleichsanzeigen ohne. Automatisch startende
Bewegtbilder wurden in diesem Test von
den Probanden in der anschließenden
Befragung mehrheitlich abgelehnt. Vermutlich werden automatisch startende
Videos als störend wahrgenommen und
behindern die Informationssuche. Viele
Probanden haben die Videos sprunghaft
genutzt, d.h. sie haben anhand der Timeline navigiert. Das Fehlen dieser Vorspulmöglichkeit in einigen Videos empfanden sie als störend. Somit erwarten
die Probanden grundlegende PlayerEigenschaften wie Start, Stop, Timeline,
Verbleibende Zeit, Lautstärke, Vollbild.
5.0
nach den drei Schritten Aufmerksamkeit auf, Verarbeitung von und Interaktion mit Videos differenziert.
Für die ausgewählten Beispiel-VideoInhalte in den spezifischen Themenfeldern lässt sich damit festhalten: Die
(1) Aufmerksamkeit auf additive VideoInhalte wird am ehesten über seitenintegrierte Videos erreicht. In der (2)
Verarbeitungsphase werden Videos
als Informationsquelle verwendet und
deren Inhalte bleiben – in einer Stellenanzeigen-Analyse – auch ungestützt in Erinnerung. Im engen Feld der
Marketingkommunikation des Personalmarketings werden hinsichtlich der
(3) Interaktion automatisch startende
Videos als störend wahrgenommen.
Die Untersuchung von Bewegtbildern
in Websites stellt ein unüberschaubares Terrain dar. Für zahlreiche thematische Anwendungsfelder und unterschiedliche Arten von Websites sind
über die hier untersuchten ausgewählten Beispiele der Medien- und Marketingkommunikation hinausgehend entsprechende Usability-Analysen erforderlich. Das hier vorgeschlagene methodische Untersuchungsraster kann
dabei von Nutzwert sein.
Fazit und Ausblick
Die zunehmende Verbreitung von
Bewegtbildern auf Websites macht auch
deren intensive Analyse im Rahmen der
Web-Usability erforderlich. Nach dem
Zweck des Einsatzes von Videos wurde
in der vorliegenden Untersuchung in
originäre und additive Videos unterschieden. Betrachtet wurden diese in
ausgewählten Beispielfeldern der Medien- sowie der Marketingkommunikation. Für alle fokussierten Beispiele wurden zunächst die Angebote von Videos
identifiziert und nach Möglichkeit in einem zweiten Schritt die Nutzung näher
analysiert. Erste methodische Erkenntnisse bei der Durchführung von VideoEyetracking-Tests wurden systematisch
Arndt, H. (2006): Integrierte Informationsarchitektur. Springer: Berlin.
Bente, G. (2004): Erfassung und Analyse
des Blickverhaltens. In: Mangold, R.; Vorderer, P.; Bente, G. (Hrsg.): Lehrbuch der
Medienpsychologie. Göttingen: Hogrefe, S.
297-324.
Dahm, M. (2006): Grundlagen der MenschComputer-Interaktion. München: Pearson.
Duchowski, A.T. (2002): Eye Tracking
Methodology. Theory and Practice.
Springer: London.
Fischer, P.; Geisler, J. (2008): Eye-Tracking
zur Unterstützung der Verdachtsmarkierung
in der Videoüberwachung. In: i-Com, Heft
1/2008, S. 34-38.
Gerhards, C.; Pagel, S. (2008a): Webcasting
von Video-Content in Online-Zeitungen. In:
Zerfaß, A.; Welker, M.; Schmidt, J. (Hrsg.):
Kommunikation, Partizipation und Wirkungen
im Social Web. Bd. 2. Köln: Herbert von Halem Verlag, S. 154-187.
Gerhards, C.; Pagel, S. (2008b): Internetfernsehen von TV-Sendern und User Generated
Content. In: Friedrich-Ebert-Stiftung (Hrsg.),
Medien Digital. Bonn: Bonner UniversitätsBuchdruckerei (i.D.)
Goldstein, B. (2002): Wahrnehmungspsychologie. 2. Aufl. Heidelberg: Spektrum.
Hürst, W.; Götz, G.; Welte, M. (2007): Ein
neues Interface zur flexiblen Navigation in
Videos auf PDAs. In: Gross, Tom (Hrsg.):
Mensch & Computer 2007: Interaktion im
Plural. München: Oldenbourg, S. 221-226.
Kempter, G.; Dontschewa, M. (2007): Historische Untersuchungen zur Psychologie der
Wahrnehmung von synthetischen Bewegtbildern. In Kempter, G.; Dontschewa, M.
(Hrsg.): Informieren mit Computeranimation.
Lengerich: Pabst, S. 9-17.
Neuberger, C. (2000): Journalismus im Internet. In: Media Perspektiven, 31. Jahrgang,
Heft 7/2000, S. 310-318.
Pagel, S. (2008): Partizipative Softwareentwicklung für das Internetfernsehen am Beispiel von Online-Mediatheken (i.V.)
Pagel, S.; Goldstein; S. (2008): Wahrnehmung und Nutzung von Bewegtbild-Content
in der Marketingkommunikation - Erkenntnisse einer Eyetracking-Untersuchung zu VideoStellenanzeigen (i.V.)
Plag, F.; Riempp, R. (2007): Interaktives Video im Internet mit Flash. Berlin: Springer.
Schmidt, J. (2008): Produktionstechnik der
ZDFmediathek. In: Fernseh- und KinoTechnik, Heft 4/2008, S. 161-167.
Schweibenz, W.; Thissen, F. (2003): Qualität
im Web, Benutzerfreundliche Webseiten
durch Usability Evaluation. Berlin: Springer.
Van Eimeren, B.; Frees, B. (2007): Internetnutzung zwischen Pragmatismus und You
Tube-Euphorie. In: Media Perspektiven, Heft
8/2007, S. 362-378.
Wirth, Th. (2004): Missing Links, 2., erweiterte Auflage. München: Carl Hanser Verlag.
181
User Experience und Social Shopping
Torsten Bartel
usability.de
Ilse-ter-Meer-Weg 4
30449 Hannover
[email protected]
www.usability.de
Gesine Quint
usability.de
Ilse-ter-Meer-Weg 4
30449 Hannover
[email protected]
www.usability.de
Sarah Nicolai
usability.de
Ilse-ter-Meer-Weg 4
30449 Hannover
[email protected]
www.usability.de
Steffen Weichert
usability.de
Ilse-ter-Meer-Weg 4
30449 Hannover
[email protected]
www.usability.de
Abstract
Social Shopping wird im Web als ein
wesentlicher Trend im E-Commerce
propagiert. Inwieweit Online-Shops, die
einen Schwerpunkt auf CommunityFeatures und damit auf den Austausch
der Benutzer untereinander legen, eine
positive User Experience mit sich bringen, wurde in der aktuellen Studie von
usability.de erhoben.
1.0
Einleitung
In einer breit angelegten Studie
wurde untersucht, wie es um die User
Experience von deutschen Social Shopping Sites steht. Bei diesem neuen
Trend des Online-Einkaufs steht neben
Produkt und Preis vor allem der Community-Gedanke und damit der Austausch der Benutzer untereinander im
Vordergrund. Wie beim Einkaufsbummel
mit Freunden, wird auch das Einkaufen
im Internet zu einem sozialen Erlebnis,
bei dem die Benutzer sich gegenseitig
austauschen und beraten. Der „Social
Shopper” bewertet und kommentiert
Artikel, veröffentlicht Listen mit seinen
Lieblingsprodukten und lässt sich von
anderen Shoppern inspirieren: „Welche
Kette soll ich meiner Freundin kaufen?“,
„Was halten andere Benutzer von der
Qualität dieses Produkts?“, „Welche
Marken finden die anderen Benutzer
gut?“, „Wer kennt den günstigsten
Preis?“
Während beim Einkaufen im Internet
zunächst vor allem die gute Produktsuche und mehr Preistransparenz im Vordergrund standen, verändern sich die
Ansprüche der Kunden zunehmend.
Die User werden zu aktiven Konsumenten, die selber bewerten, testen, emp-
182
Hierzu wurden 1000 Benutzer befragt
und 32 User Experience Tests an vier
deutschen Social-Shopping-Plattformen durchgeführt. Der vorliegende
Beitrag stellt Aufbau und ausgewählte
Ergebnisse dieser Untersuchung vor.
Keywords
fehlen, kommentieren oder eben auch
Produkte anbieten. Die Rollen sind
nicht mehr klar getrennt, die Kunden
von morgen wollen mitgestalten und
erwarten mehr und mehr ein individuelles Einkaufserlebnis. Ein Teil der
Vorteile, die eher dem stationären
Handel zugeschrieben werden, wie
gute Beratung, Interaktion und Kommunikation mit Menschen, wird immer
stärker in das Medium Internet transportiert. Die Integration von Community Features bietet Online Shops enorme Möglichkeiten.
1000 Online-Shoppern durchgeführt.
Zwei übergeordnete Fragestellungen
standen dabei im Vordergrund:
Neben dem großen Potential bringt der
aus den USA kommende Trend des
„Einkaufens mit Gemeinschaftsgefühl“
(focus.de, 12.2.2008) auch einige Herausforderungen bei der Einführung
neuer Bedienkonzepte und der Integration von Web2.0-Elementen in Online Shops mit sich. Wie sich das auf
die User Experience auswirkt, wurde in
der Studie „User Experience und Social Shopping“ von usability.de untersucht.
2.0
Studiendesign
Im Zeitraum Januar bis März 2008
wurden 32 User-Experience-Tests und
eine begleitende Online-Umfrage mit
User Experience, Social Shopping,
Community, Usability, Web 2.0, Shopping 2.0, E-Commerce, usability.de
1. Wie werden Web-2.0-Elemente wie
Tags und Bewertungsfunktionen von
deutschen Online-Shoppern bisher
wahrgenommen und genutzt?
2. Wie kommen Social Shopping Websites bei den Benutzern an und wie
können Web-2.0-Elemente in OnlineShops so umgesetzt werden, dass
sie leicht bedienbar sind und den
Nutzer optimal beim Online-Einkauf
unterstützen?
2.1
Aufbau der Online-Befragung
Um die Frage nach dem bisherigen
Shopping-Verhalten und dem Nutzen
einzelner Shop-Elemente in bestehenden Online-Shops zu klären und die
Erwartungen von Benutzern an neue
Arten des Online-Shoppings zu erheben,
wurde eine ca. 10-minütige OnlineBefragung unter 1.000 deutschen Online-Shoppern durchgeführt.
Befragt wurden Personen, die regelmäßig online einkaufen und außerdem Online Communitys nutzen. Die
Stichprobe ist damit an die Zielgruppe
der Social-Shopping-Plattformen angelehnt, bei denen es, außer auf den Ein-
kaufsprozess, vor allem auf die aktive
Beteiligung und Vernetzung der Nutzer
untereinander ankommt.
Folgende Kernfragestellungen geben
den Aufbau der Befragung wieder:
1. Online-Verhalten: Wie aktiv sind
Nutzer beim Online-Shopping und in
Online-Communitys? Welche Websites nutzen sie?
2. Kaufverhalten: Welche Strategien
verfolgt der Nutzer beim OnlineKauf? Unter welchen Voraussetzungen werden Produkte eher gezielt
gesucht, wann steht das Stöbern im
Vordergrund?
3. Wahrnehmung von Social-ShoppingElementen: Wie nimmt der Nutzer
generell Elemente wie Bewertungen,
Tagging oder Vernetzung mit anderen Shoppern wahr?
4. Für welche Produktkategorien sind
Social-Shopping-Elemente wie wichtig?
2.2
Aufbau User-Experience-Tests
Um die wirkliche Interaktion der Benutzer mit einer Social-ShoppingPlattform einzufangen, wurden zusätzlich zur Online-Befragung 32 UserExperience-Tests an vier deutschen
Social Shopping Sites im Usability Lab
von usability.de durchgeführt. Dabei
wurden neben Usability Faktoren wie
Glaubwürdigkeit, Spaß (Joy of Use) sowie emotionale und ästhetische Faktoren berücksichtigt. Bei der Auswahl der
zu testenden Websites stand im Vordergrund, dass alle Websites vergleichbare
Web-2.0-Elemente enthalten. Als die
wichtigsten oder am häufigsten eingesetzten Elemente wurden nach einer
Analyse internationaler Social-ShoppingPlattformen die Folgenden identifiziert:
•
•
•
•
•
Kommentarfunktion
Bewertungsfunktion
Produktlisten (Merk-/Wunschlisten)
Tagging (Schlagwort-Vergabe)
Profilinformationen (z.B. Fotos, Hobbys, Interessen)
•
Freundeslisten
Vor diesem Hintergrund wurden vier
innovative deutsche Social Shopping
Websites als Testobjekte ausgewählt:
• www.dawanda.de
• www.dealjäger.de
• www.edelight.de
• www.smatch.com
Bei den User-Experience-Tests wurden die Teilnehmer in Einzelsitzungen
gebeten, sechs typische Aufgaben auf
der jeweiligen Website zu bearbeiten.
Der gesamte Test wurde durch kurze
Befragungen zu Zufriedenheit, Wünschen, Kritik etc. ergänzt.
3.0
Ergebnisse der OnlineBefragung
Die Online-Befragung diente vorrangig dazu, herauszufinden, welche
Social-Shopping Sites und welche
Web2.0-Elemente bekannt sind. Zentrale Ergebnisse der Online-Befragung:
1. Online-Shopper kennen vor allem
die „klassischen“ Websites wie
Amazon oder eBay und deren Social-Shopping-Elemente. Bei den
auf diesen Seiten verwendeten
Funktionen (Kommentar- und Bewertungsfunktion) ist den Shoppern
der Nutzen klar und die Bedienkonzepte sind vertraut. Bei der
Entwicklung neuer Konzepte sollte
man sich daher an den bisherigen
Erfahrungen der Nutzer mit bekannten Websites orientieren.
2. Social Shopping ist mehr als kommentieren und bewerten. Jedoch
können gerade innovativere Web2.0-Elemente, wie Tags, nicht als
bekannt vorausgesetzt werden,
sondern müssen entsprechend erklärt werden. Sie werden auch
nicht per se als interessant und
wichtig wahrgenommen. Um Besucher einer Site zur Mitgestaltung zu
bewegen, sollte der Mehrwert innovativer Funktionen erläutert und
deren Funktionsweise erklärt werden.
3. Die Mehrheit der Online-Shopper
kauft „klassische“ Online-Produkte,
wie Bücher, CDs und Elektroartikel.
Der Anteil der Umsätze aus anderen
Kategorien, wie Mode und Lifestyle,
steigt aber stetig.
4. Die Mehrheit der Online-Shopper
weiß genau, welches Produkt sie
will. Die meisten Käufer suchen im
Internet gezielt nach bestimmten
Produkten. Auch wenn die neuartigen Social-Shoppig-Konzepte auf
den spontanen Kauf beim Einkaufsbummel im Internet setzen, sollten
Social-Shopping-Plattformen den
Nutzer bei der gezielten Suche nach
einem gewünschten Produkt unterstützen.
5. Um einen Online-Shop, bei dem der
Nutzer im Mittelpunkt steht, mit Leben zu füllen, ist es wichtig, besonders die Nutzergruppen zu bedienen,
die sich aktiv an der Plattform beteiligen. Web 2.0-Konzepte bieten hier
besonders einfache Möglichkeiten
mit niedriger Hemmschwelle: Ein anonymer Kommentar oder ein Eintrag in eine Shoutbox ist schnell geschrieben. Durch den sinnvollen Einsatz dieser „aktivierenden“ Funktionen können mehr Nutzer aktiv beteiligt werden. Der Anteil der aktiven
User, also der Nutzer, die sich mindestens gelegentlich beteiligen,
steigt damit und die Grenze zwischen aktiven und passiven Nutzern
weicht auf.
4.0
Ausgewählte Ergebnisse der
User-Experience-Tests
An dieser Stelle werden ausgewählte Erkenntnisse aus den Tests vorgestellt.
4.1
•
Produktsuche
Die Produktsuche über „herkömmliche“ Wege wie Suchfeld oder Kate-
183
•
4.2
•
•
4.3
•
•
4.4
•
•
184
gorien wird innovativen Suchmöglichkeiten wie z.B. „Suchen nach Materialart“ vorgezogen.
Neuartige Filtermöglichkeiten zum
Eingrenzen der Ergebnisse sorgten
für große Verwirrung.
neu geladen, sondern Aktionen
passieren unmittelbar, oft auch nur
an einer Stelle der Seite. Speicherten die Testteilnehmer ein Produkt
über das Produktdetailfenster, so
warteten fast alle vergeblich auf eine Reaktion der Website. Fragen
wie „Hat er das jetzt gespeichert?“oder „Jetzt ist es irgendwo
gespeichert hoffe ich!“ zeugen von
der Irritation der Testteilnehmer.
Ergebnisdarstellung
Die Qualität der Suchergebnisse ist
unzureichend. Von vielen Teilnehmern wurden die Suchergebnisse
auf drei der vier untersuchten Sites
als „wild zusammengewürfelt“ empfunden.
Die Darstellung der Trefferanzahl ist
schlecht umgesetzt und führt zu Irritationen.
Produktdarstellung
Es ist nicht offensichtlich, dass es
sich bei einigen Websites nicht direkt
um Online Shops handelt. „Der erste
Eindruck, den ich hatte, war, dass es
eine Seite ist, auf der ich direkt kaufen kann, aber scheinbar ist es nur
so eine Empfehlungsseite.“ waren
typische Kommentare an dieser Stelle.
Fenster mit weiteren Produktinformationen, die sich öffnen, wenn mit
der Maus über ein Produktbild gefahren wird, sorgten für Irritation. Einigen Testteilnehmern war die Verbindung zwischen eigener Handlung
(Mouse-Over über die Produktbilder) und der ausgelösten Aktion
(Produktdetailfenster öffnet sich)
nicht klar. Aussagen wie „Ja, ist ja
gut jetzt.“ oder „Geh mal weg da,
blödes Fenster!“ belegen dies anschaulich.
4.5
•
•
•
4.6
•
Produkte merken
Bei drei von vier Seiten lag die erste
Hürde bei dem Versuch, sich ein
Produkt zu merken, schon darin, diese Funktion zu finden. Innovative
Möglichkeit, ein Produkt einfach per
Drag&Drop auf eine Liste zu ziehen,
wurden gar nicht bemerkt.
Zu besonderen Problemen führte die
Ajax-basierte Umsetzung der Merken-Funktion. Bei dieser Technologie
werden Seiten nicht offensichtlich
•
Merkliste einem Freund zeigen
Auf drei der vier untersuchten
Websites hatten die Testteilnehmer
erhebliche Schwierigkeiten, ihre
zuvor angelegte Merkliste wiederzufinden.
Da es häufig mehr als eine Liste
gab, bereitete es Schwierigkeiten
zu entscheiden, auf welcher Liste
die zuletzt gespeicherten Produkte
gespeichert wurden: „Ist das jetzt
unter Merkliste oder unter
Wunschzettel? Oder Lieblingsliste?
Das ist zu viel. Eins reicht doch!“
Einstellung „öffentlich/privat“ zu
versteckt: Für Irritation und Unmut
sorgte bei vielen Testteilnehmern,
dass die Möglichkeit, Listen auf ‚öffentlich’ oder ‚privat’ zu stellen,
nicht ersichtlich war. Waren private
Listen gar nicht vorgesehen, wurde
dieses oft heftig kritisiert: „Das ist ja
auch dreist, dass die Liste standardmäßig öffentlich ist,das fände
ich andersrum angebrachter.“
sen, äußerten viele von ihnen trotzdem Bedenken darüber, wie glaubwürdigdiese sind. Einige befürchteten, die Kommentare könnten gefälscht sein: „Wenn da jemand gerne
seine Kette verkaufen würde, die er
noch 20 Mal auf Lager hat, dann rekrutiert er vielleicht einfach ein paar
Freunde von sich, die das als wunderbar bewerten.“
4.7
•
•
•
•
Bewertungs- und Kommentarfunktion
Fehlende Rückmeldung: Nach dem
Abgeben einer Bewertung beziehungsweise eines Kommentars
gab es auf keiner der untersuchten
Websites eine Systemrückfrage.
Aussagen wie „Hm, Bewertung hab
ich wohl abgegeben“ oder „Ist jetzt
was passiert?“ zeugen davon. Für
zusätzliche Verärgerung sorgte die
Tatsache, dass einmal abgegebene Bewertungen nicht rückgängig
gemacht oder bearbeitet werden
konnten.
Glaubwürdigkeit der Bewertungen:
Obwohl die meisten Testteilnehmer
angaben, dass die Bewertungen
und Kommentare anderer Nutzer
ihre Kaufentscheidung beeinflus-
4.8
•
•
Profil eines anderen Nutzers aufrufen
Angaben und Kurzschreibweisen im
Profil waren teilweise völlig unklar:
Angaben wie „‚Karma’ und ‚edelights’
oder Kurzschreibweisen für „abgejagte“ und „verlorene Deals“ wurden
schwer verstanden.
Zu unpersönliche Profile: Einige Nutzer wünschten sich mehr persönliche
Angaben im Profil, wie beispielsweise Angaben zum Alter oder zu Hobbys um mit Hilfe dieser Informationen
für sie interessante Personen und
deren Listen zu finden.
Erstaunlich groß war die Ablehnung
der Testteilnehmer gegenüber der
Veröffentlichung persönlicher Daten
wie Kaufgewohnheiten.
Die Glaubwürdigkeit von Nutzerprofilen war ein Balance-Akt: Einerseits
sollten die Profile ausgearbeitet sein,
um realistisch zu wirken und über
den Verdacht eines Fake-Accounts
erhaben zu sein. Andererseits kamen Zweifel an der Glaubwürdigkeit
von Empfehlungen auf, wenn ein
Nutzer zu viele Produkte auf seiner
Empfehlungsliste hatte.
Suche nach anderen Shoppern
und als Kontakt hinzufügen
Das Suchen bestimmter Nutzer nach
deren Benutzernamen ist auf zwei
von vier untersuchten Websites nicht
möglich. Generell waren die Suchmöglichkeiten nicht ausgereift. Bei
einer Site konnten zum Beispiel nur
die Listen einer Person gesucht werden und das auch nur, wenn die gesuchte Person diese auf ‚öffentlich’
gestellt hat.
Shopper mit ähnlichen Einkaufsinteressen finden ist schwierig: Auf allen
Websites fehlten Möglichkeiten, an-
•
5.0
5.1
dere Nutzer nach bestimmten Kriterien zu suchen.
Wording (Freund hinzufügen): Der
Begriff ‚Freund’ für einen Kontakt auf
einer Social-Shopping-Website wurde von einigen Testteilnehmern als
unpassend bewertet. Dies könnte ein
spezielles Phänomen der deutschen
Sprache bzw. Kultur sein, da es hierzulande einen großen Unterschied
zwischen einem Freund und einem
Bekannten gibt.
User Experience Hürden auf Social Shopping Plattformen
Wording
Eine zentrale Erkenntnis aus den
User-Experience-Tests war die mangelnde Selbstbeschreibungsfähigkeit
verschiedener Begriffe und Funktionen
auf den Websites. Viele unserer Testteilnehmer konnten nichts mit Bezeichnungen wie ‚Coloranda’, ‚Style Lab’,
‚Dealheim’, ‚Dashboard’, ‚Widget’ oder
‚Shoutbox’ anfangen.
Für Irritation sorgte zudem das Ersetzen
bereits etablierter Begrifflichkeiten durch
neue Bezeichnungen. So stolperten die
Testteilnehmer bei DaWanda darüber,
dass sie sich einen Freund oder Kontakt
‚merken’ sollten, wenn man doch üblicherweise einen Freund oder Kontakt zu
seiner Freundes- oder Kontaktliste hinzufügt oder eine Kontaktanfrage stellt.
5.2
Steuerbarkeit
Gute Usability heißt unter anderem,
dass nichts über den Kopf des Nutzers
hinweg passiert oder entschieden wird,
sondern dass der Nutzer zu jeder Zeit
die Kontrolle über alle Vorgänge behält.
Diese Kontrolle wurde dem Nutzer jedoch auf allen vier untersuchten Websites an mindestens einer Stelle genommen. Beispielsweise kann auf keiner der
Sites ein einmal abgegebener Kommentar oder eine Bewertung rückgängig
gemacht werden. Auch die Bearbeitung von Tippfehlern ist nicht vorgesehen.
5.3
Erwartungskonformität
Mangelnde Erwartungskonformität
trat auf allen untersuchten Sites in
Form fehlender „Sind Sie sicher?“Abfragen auf. Diese haben sich auch
im Web immer dann zum Standard
entwickelt, wenn der Nutzer eine Aktion nicht bearbeiten oder rückgängig
machen kann. Viele Testteilnehmer
klickten deshalb - ausgehend von diesem Standard - auf einen Link, um
herauszufinden, was sich dahinter
verbirgt. Klickten sie jedoch z.B. auf „ja
ich bin begeistert“ hatten sie sich unwiderruflich als „Fan“ des entsprechenden Produkts erklärt. Abgegebene Kommentare konnten weder zurückgenommen noch bearbeitet werden.
5.4
Ajax / Neue Technologien
Der besondere Vorteil von Ajax ist,
dass weniger Client-ServerKommunikation nötig ist: Wenn der
Nutzer eine Einstellung auf der Website gemacht hat, lädt nicht die ganze
Seite komplett neu, sondern nur der
Teil, bei dem die Einstellung vorgenommen wurde. Dies macht die Kommunikation mit einer Website insgesamt flüssiger. Dennoch traten gerade
im Zusammenhang mit dieser Technologie viele Schwierigkeiten auf. Vor
allem beim Merken eines Produktes
mit Hilfe der AjaxProduktinformationen (so genannte
Layer) beziehungsweise auf der Produktdetailseite fehlte jegliches SystemFeedback. Nachdem eine Nutzerin
über den Layer ein Produkt auf die
Liste geschoben hatte, fragte sie: „Warum ist jetzt nichts passiert?“ Das Produkt war von ihr unbemerkt auf die
Liste oben rechts auf der Seite gesetzt
worden.
Die vergrößerte Darstellung der Produkte mit Ajax wurde sehr positiv wahrgenommen. Allerdings waren die Testteilnehmer im ersten Moment überrascht,
als sich der Hintergrund abdunkelte und
dann das Produkt vergrößert erschien.
Eine Teilnehmerin meinte, dass sie „vielleicht etwas falsch gemacht“ hätte und
„etwas kaputt gegangen“ sei.
5.5
Web-2.0-Elemente und neue Konzepte
Die größte Unklarheit bestand beim
„Tagging“. Kaum einer der Testteilnehmer konnte damit etwas anfangen, obwohl es sich um aktive und Communityerfahrene Nutzer handelte. Hinter den
größeren Wörtern innerhalb einer Tagcloud vermuteten die Testteilnehmer,
dass dort „die Masse an Produkten größer ist“ beziehungsweise „die Macher
der Seite wollen, dass ich da drauf klicke“.
In Bezug auf Web-2.0-Elemente bereiteten neben Tagging vor allem Social
Bookmarks sowie neue Features wie
z.B. ein „Qual der Wahl“-Tool die größten Verständnisprobleme.
5.6
Joy of Use
Das Erkunden der einzelnen Social
Shopping-Websites bereitete den meisten Testteilnehmern durchaus Spaß.
Allerdings war dieser oft getrübt durch
eine mangelhafte Usability und eine
nicht durchgängig gesicherte Qualität
der Inhalte. „Wenn die Produktsuche
nicht funktioniert, dann hat es doch keinen Sinn.“
Der meiste Spaß entstünde auf den untersuchten Sites durch die Vernetzung
mit anderen Nutzern. Gerade hier fehlt
es jedoch an Möglichkeiten.
5.7
Vertrauen und Glaubwürdigkeit
Eine große Rolle spielte für unsere
Testteilnehmer das Thema Vertrauen.
Egal, bei welcher Aufgabe – die Frage
185
nach Vertrauen und Glaubwürdigkeit der
Website schwang bei den Testteilnehmern immer unterschwellig mit.
Wenig positiv nahmen die Testteilnehmer beispielsweise die finanzielle Beteiligung der Nutzer am Gewinn zweier
Websites auf, vor allem, wenn diese
Information nicht offen genug kommuniziert wurde. Oft warf die Frage der Gewinnbeteiligung gleichzeitig die Frage
nach der Glaubwürdigkeit der Sites auf.
Viele Nutzer fragten sich, wie echt Produktempfehlungen und -bewertungen
sein können, an denen die Nutzer verdienen: „Ach deshalb empfehlen die
Leute überhaupt. Wenn man das erst so
spät merkt, ist das natürlich etwas merkwürdig.“
Der zweitgrößte Einflussfaktor auf
Glaubwürdigkeit und Vertrauen bestand
in den Preisangaben, die entweder zu
undurchsichtig oder gar nicht dargestellt
186
wurden. Testteilnehmer kommentierten dies mit „Man will die Wahrheit
nicht häppchenweise. Ich will nicht
zwei Preise zusammenaddieren müssen.“ oder „Ja, der Stil ist schon seriös,
aber die Dinge, auf die es ankommt,
wie Produktbeschreibung, Preis, Lieferzeiten und ähnliches sind total vernachlässigt.“
6.0
Fazit
Aus den Ergebnissen der OnlineBefragung und der User-ExperienceTests ließen sich sieben „Goldene
Regeln“ ableiten, die eine gute Grundlage für eine positive User-Experience
von
E-Commerce Websites darstellen.
Verkürzt dargestellt lauten diese:
1. Heben Sie den Nutzen und Mehrwert
von Community-Features klar hervor
2. Vermitteln Sie Vertrauen und Glaubwürdigkeit
3. Halten Sie Usability-Standards ein
4. Erklären Sie neue Konzepte und
Technologien ausreichend
5. Schaffen Sie ausreichend Vernetzungsmöglichkeiten
6. Nehmen Sie dem Nutzer die Angst
vor Veröffentlichung seiner persönlichen Daten
7. Ermöglichen Sie dem Nutzer Spaß
bei der Benutzung
Die vollständigen Ergebnisse und Empfehlungen, quantitative Daten, sowie
konkrete Schritte zu positiver User Experience im Social Shopping sind der
Studie „User Experience und Social
Shopping“ zu entnehmen.
Praxistauglicher Usability-Engineering-Prozess für
Corporate-Websites
Martin Beschnitt
Usability Consultant
eResult GmbH
Planckstraße 23
37073 Göttingen
[email protected]
Tel.: + 49 (0)551/49569333
www.eresult.de
Thorsten Wilhelm
Gründer und Geschäftsführer
eResult GmbH
Planckstraße 23
37073 Göttingen
[email protected]
Tel.: + 49 (0)551/49569332
www.eresult.de
Abstract
Durch eine Befragung von Internetexperten und erfahrenen UsabilityProfessionals wurden die Spezifika und
Rahmenbedingung von CorporateWebsites identifiziert.
Zusätzlich wurde geklärt, in welchen
Phasen des Entwicklungsprozesses
Usability-Aspekte die höchste Relevanz
haben und welche Methoden verstärkt
eingesetzt werden. Anschließend wurden generische Usability-EngineeringProzesse und ausgewählte Usability-
1.0
Einleitung
Methoden in Bezug auf deren Tauglichkeit für die Entwicklung von Corporate-Websites bewertet.
Das Ergebnis bildet ein kosteneffizienter, speziell zugeschnittener Engineering-Prozess, der die einzelnen Prozessschritte und ausgewählten Methoden von Projektanfang bis zum Projektende erläutert und auch die Kosten
bzw. erforderlichen Qualifikationen
dafür aufzeigt.
von E-Commerce-Angeboten (wie z.
B. Online-Shops, Reiseportale, etc.).
Die persönliche Erfahrung aus Projekten zeigt, dass die meisten Unternehmen die Vorzüge eines systematischen Entwicklungs- und Evaluationsprozesses bei der Erstellung von Corporate-Websites leider noch nicht erkannt
haben. Bei Corporate-Websites finden
derzeit überwiegend abschließende
Usability-Tests statt, die nur als Projektbaustein kurz vor dem Launch der Website angesehen werden. Ziel ist dabei
eine finale Qualitätskontrolle und auch
eine gewisse Beruhigung für den Projektleiter. Jedoch liegt diese abschließende Maßnahme zeitlich so weit hinten, dass die Empfehlungen häufig erst
nach dem Launch umgesetzt werden
können.
Es besteht folglich auch bei Corporate-Websites der Bedarf an einen
systematischen Entwicklungsprozess,
der garantiert, dass nicht erst am
Ende Usability-Maßnahmen zum
Tragen kommen, sondern dass diese
den Entwicklungsprozess kontinuierlich begleiten. Hierbei sind kostengünstige Methoden gefragt. Zudem
bedarf es des Wissens über die Spezifika dieser Websiteart, um sie erfolgreich entwickeln und den Anforderungen der Nutzer entsprechend umsetzen zu können.
Einer der Hauptgründe für diese
Vorgehensweise ist sicherlich das begrenzte Budget für die Konzeption von
Corporate-Websites im Vergleich zu
Entwicklungs- und Evaluationsbudgets
Grundsätzlich gelten bei Corporate-Websites die gleichen UsabilityRichtlinien wie bei jeder anderen Websiteart auch. Jedoch stellt sich die Gewichtung in Bezug auf die Gestaltung
Keywords
Corporate-Websites, Konzeption,
Prozessmodell, Usability-Engineering,
Usability-Methoden
der Inhalte und die organisatorische
Voraussetzungen bei der Konzeption
einer Corporate-Website völlig anders
dar als beispielsweise bei einem OnlineShop.
Abb. 1: Studienablauf
2.0
Vorgehensweise
2.1
Expertenbefragung
Um diese charakteristischen Merkmale zu identifizieren, wurde eine Online-Befragung von Webdesignern, Projektleitern bzw. Internetverantwortlichen
kleiner und großer Unternehmen und
erfahrenen Usability-Professionals in
Form eines Fragebogens durchgeführt.
187
Die Umfrage umfasste dabei drei zentrale Fragestellungen:
x
x
x
Welche Spezifika weisen CorporateWebsites auf?
In welchen Phasen des Entwicklungsprozesses sollten UsabilityAspekte die höchste Relevanz besitzen?
Wie wichtig sind ausgewählte Methoden der Usability-Forschung bei
der der Entwicklung und Optimierung
von Corporate-Websites?
Der Aufruf zum Ausfüllen des Online-Fragebogens wurde über den ECommerce Newsletter der Industrie- und
Handelskammer Hannover und über den
eResult Newsletter veröffentlicht.
Insgesamt beteiligten sich 117 Personen an der Befragung. Nach einer
Qualitätskontrolle (Plausibilität, Bearbeitungsdauer) und einer Selektion nach
der Erfahrung der Befragten (im Bereich
Entwicklung bzw. Optimierung von Corporate Websites und dem Einsatz von
Usability-Maßnahmen) konnten 77 Datensätze in die Auswertung einfließen.
2.2
Beurteilung von UsabilityMethoden
Darüber hinaus flossen die im Rahmen
der Umfrage identifizierten Spezifika
mit in die Bewertung ein.
Somit setzen sich die Kriterien für den
Vergleich der Usability-Methoden wie
folgt zusammen:
x
x
x
x
x
x
x
x
x
x
x
Produktivität bzw. Effektivität
Flexibilität
Kosten (Material- und Zeitaufwand)
Qualifikation der Evaluatoren
Detaillierungsgrad der Ergebnisse
Einsatzzeitpunkt
Datenart (qualitativ/ quantitativ)
Evaluationsart (formativ/ summativ)
Anzahl der Testpersonen bzw.
Evaluatoren
Projektdauer
Tauglichkeit (für CorporateWebsites)
Daneben wurden die Methoden
auch nach den Kriterien der empirischen Forschung: Objektivität, Reliabilität und Validität beurteilt.
2.3
Vergleich generischer Prozessmodelle
Auf Basis der Ergebnisse aus der
Online-Befragung und der Beurteilung
der Usability-Methoden wurden zehn
generische Usability-EngineeringProzesse in Hinblick auf den Einsatz bei
der Entwicklung von Corporate-Websites
bewertet. Hierzu wurden die einzelnen
Prozessschritte miteinander verglichen,
um Gemeinsamkeiten und Unterschiede
aufzuzeigen. Zudem wurde der Aufwand
in Bezug auf Material, Zeit und Qualifikation abgeschätzt.
Dabei wurden u.a. folgende Modelle
betrachtet:
x
x
x
Allgemeiner Usability-EngineeringProzess in deutschen Unternehmen
(Braun et. al 2007)
Usability Engineering Lifecycle
(Mayhew 1999)
Usability Engineering Lifecycle (Nielsen 1993)
Das Ergebnis dieser Betrachtung
stellt eine umfangreiche Methodenmatrix dar, die die genannten Dimensionen berücksichtigt.
Neben der Expertenbefragung erfolgte eine Beurteilung bestehender
Usability-Methoden in Bezug auf deren
Tauglichkeit für Entwicklung von Corporate-Websites. Auf Basis einer umfangreichen Literaturrecherche wurden die
grundlegenden Methoden im Bereich
Web-Usability identifiziert.
Braun und Sarodnick schlagen zusätzlich zu den Kriterien Materialaufwand, Zeitaufwand und Qualifikation
Kriterien zur Bewertung von Evaluationsmethoden vor (Brau & Sarodnick
2006). Diese wurden durch weitere Kriterien ergänzt, die bei der Auswahlentscheidung von Usability-Methoden in der
Praxis eine wichtige Rolle spielen.
Abb. 2: Methodenmatrix (Ausschnitt)
188
3.0
Ergebnisse
3.1
Spezifika von Corporate-Websites
Anhand der Auswertung der qualitativen Antworten der befragten Experten
in Kombination mit einer im Vorfeld
durchgeführten Literaturrecherche und
einer Inhaltsanalyse von ausgewählten
Corporate-Websites lassen sich folgende Aussagen machen und erste
Schlussfolgerungen ziehen. Es ist anzumerken, dass es sich hierbei nur um
eine Auswahl der identifizierten Spezifika handelt:
x
„Corporate-Websites haben ein großes Spektrum an Zielgruppen mit unterschiedlichen Arten von Intentionen.“
Die Rekrutierung bzw. die Befragung
von Internetnutzern ist aufgrund der
Heterogenität der Nutzerschaft nicht
einfach. Es gilt, geeignete Methoden
und Verfahren einzusetzen, die das
Abbilden von schwer erreichbaren
Zielgruppen ermöglichen.
x
„Das zur Verfügung stehende Budget
einer Corporate-Website ist deutlich
geringer im Vergleich zu einem reinen E-Commerce-Angebot, da sie
nur indirekt verkaufsfördernd ist.“
Diese Budgetrestriktion erfordert
günstige und effektive Methoden bei
der Entwicklung.
x
„Für die Konzeption werden Menschen aus dem Vertrieb, Marketing,
Kundenservice, der EDV / IT und der
Führungsebene benötigt.“
Diese multidisziplinären Teams erfordern einen hohen Abstimmungsbedarf und eine allgemein verständliche Dokumentation aller Aktivitäten.
x
„Corporate-Websites sind informationsorientiert.“
Aufgrund fehlender komplexer Handlungsprozesse bedarf es hier nicht
unbedingt einer Evaluation durch
Nutzer. Solch einfache Seitenstrukturen lassen sich durch Experten (mit
Branchenkenntnissen) begutachten.
3.2
Bedeutung von Usability im
Entwicklungsprozess
Im Rahmen der Online-Befragung
wurden die Internetexperten gebeten,
die einzelnen Entwicklungsphasen:
Analyse, Konzeption, Umsetzung, Betrieb in eine Rangreihe zu bringen,
abhängig von der Bedeutung von
Usability-Aspekten innerhalb der jeweiligen Phase.
Es zeigt sich, dass nach Meinung
der Experten bei der Entwicklung und
Optimierung von Corporate-Websites
Usability-Maßnahmen vor allem in der
Konzeptionsphase zum Einsatz kommen sollten. In der eigentlichen Betriebsphase wird Usability-Aspekten
die geringste Relevanz zugewiesen.
D.h. ist die Website erst einmal „online“, werden Usability-Analysen zur
Qualitäts- bzw. Erfolgskontrolle als
relativ unwichtig erachtet. Die Bedeutung von Usability in der Phase der
programmiertechnischen Umsetzung
kann als durchschnittlich eingestuft
werden. Uneinigkeit besteht dagegen
bei der Einschätzung der Bedeutung
von Usability-Methoden in der Analysephase: 23,4% der insgesamt 77
befragten Experten sind der Meinung,
dass gerade in der Analysephase Usability-Methoden eingesetzt werden sollten.
Jedoch weisen 35,1% der Teilnehmer
Maßnahmen zur Gewährleistung einer
hohen Usability in dieser Phase eine
geringe Bedeutung zu.
3.3
Verbreitung und Relevanz von
Usability-Methoden
Neben den Spezifika des Websitegenres Corporate-Website wurde die
Bedeutung von 16 in der Praxis gängigen Usability-Methoden in Erfahrung
gebracht. Dabei wurde auf eine allgemein verständliche Methodenbezeichnung geachtet. Zudem konnten die Befragten nur dann die Relevanz einer
Methode einschätzen, wenn sie die betreffende Methode kannten bzw. schon
eingesetzt haben.
Die Auswertung der Befragungsergebnisse ergab, dass sich unter den Top
4-Methoden drei in frühen Phasen der
Entwicklung einer Corporate-Website
zum Einsatz kommende Methoden befinden: Die Aufgabenanalyse, das Prototyping und die Anforderungsanalyse
über Zielgruppenbefragung in einem
Panel. Logfile- bzw. ClickstreamAnalysen, die eher in der Betriebsphase
Abb. 3: Bedeutung von Usability im Entwicklungsprozess
189
zum Einsatz kommen, gehören ebenfalls
zu den Top 4-Methoden. Expertenevaluationen und Nutzerbefragungen - angelegt als Onsite-Befragungen - stellen
weitere Methoden bzw. Verfahren dar,
die bei der Entwicklung und Optimierung
von Corporate Websites eingesetzt werden. Als weniger relevant werden EyeTracking-Studien, Nutzerbeobachtungen
vor Ort und Card Sorting-Tests von den
77 befragten Internetexperten angesehen.
Überraschend ist, dass Nutzertests
im Usability-Lab und Remote UsabilityTests, die derzeit dominierenden Methoden bei der Evaluation und Optimierung von Websites, in Bezug auf Corporate-Websites eine eher unterdurchschnittliche Bedeutung aufweisen. Dies
kann sicherlich damit erklärt werden,
dass mit diesen beiden Methoden vor
allem Interaktionsprozesse analysiert
und optimiert werden. Zudem handelt es
sich bei beiden Verfahren um die kos-
tenintensivsten ihrer Art.
3.4
Eignung generischer Prozessmodelle
Bei genauer Betrachtung lässt
sich feststellen, dass sich die betrachteten Modelle in ihren Grundsätzen
kaum unterscheiden. Ihr Bezug zum
Software-Engineering ist klar zu erkennen. Der iterative Prozesscharakter des Usability-Engineering wird in
jedem Prozessmodell betont.
Unterschiede zwischen den Prozessen gibt es jedoch in der Gewichtung der Designaktivitäten in Bezug auf den damit verbundenen Aufwand und in der Reichweite der Prozesse, d.h. nicht alle Prozesse umfassen den gesamten Entwicklungsprozess eines Produktes. Vergleicht
man die Art und den Umfang der Nutzerinvolvierung in den verschiedenen
Modellen, so ergeben sich ebenfalls
erhebliche Unterschiede.
Letztendlich existiert kein allgemeingültiger Prozess, der alle Aspekte
abdeckt. Sowohl die nutzer- als auch die
modellgetriebenen Ansätze haben ihre
Gültigkeit, schließen sich aber gegenseitig aus.
Ein Vergleich aufgrund der Erfolge
von Usability-Engineering-Prozessen in
der Praxis lässt sich ebenfalls schwer
anstellen. Quantitative Daten für einen
Vergleich auf der Basis solcher Kriterien
sind Mangelware. Zudem befassen sich
die in der Literatur beschriebenen Prozesse meist nur mit großen Softwareprojekten, bei denen sich die Kosten für das
Usability-Engineering im sechsstelligen
Bereich bewegen.
4.0
Spezifisches Prozessmodell
Das Ergebnis der gesamten Unter-
Abb. 4: spezifischer Usability-Engineering-Prozess für Corporate-Websites
190
suchung bildet ein kosteneffizienter,
speziell auf die Spezifika von CorporateWebsites zugeschnittener, EngineeringProzess, der die einzelnen Prozessschritte in Form eines eigenständigen
Prozesshandbuches erläutert und die
einzelnen Kosten für ein exemplarisches
Website-Projekt aufzeigt.
Als Ausgangsbasis dienten die Prozessmodelle von Mayhew (Mayhew
1999) und Nielsen (Nielsen 1993). Zusätzlich wurden einzelne Schritte der
anderen Prozessmodelle adaptiert. Um
eine Integration in die typische Vorgehensweise bei der Website-Konzeption
zu gewährleisten, wurden deren Aktivitäten ebenfalls im Prozess berücksichtigt.
Hinzu kamen die Daten bzw. Ergebnisse
der eigenen Analysen.
Die vier Phasen (Analyse, Konzeption, Umsetzung und Betrieb) wurden
um eine einführende Planungsphase
ergänzt. Der Schwerpunkt der Aktivitäten liegt auf der Konzeptionsphase, dicht
gefolgt von der Analysephase.
Statt am Ende des gesamten Projektes das Design- und Interaktionskonzept durch eine größere Nutzergruppe
testen zu lassen, werden in jeder Projektphase vom Umfang her beschränkte,
aber qualitative Test mit Nutzern bzw.
Expertentests durchgeführt. Zudem wurden Befragungsvarianten eingesetzt, die
keine hohe Incentivierung von zu rekrutierenden Testpersonen erfordern. So
wird die Usability in jeder einzelnen Projektphase kostengünstig überprüft. Nach
Inbetriebnahme der Website gilt es, diesen Qualitätsprozess zu erhalten.
Die Kosten für einen solchen systematischen Usability-EngineeringProzess belaufen sich auf insgesamt ca.
60.000 € (reine Usability-Maßnahmen,
bei einem Tagessatz von 600 €) zuzüg-
lich der Kosten, die für die Erstellung
des Prototyps, der Websiteinhalte
(Texte, Grafiken, etc.), der Durchführung der Workshops und für die benötigte Technik erforderlich sind. Besondere Bedeutung kommt bei diesem
Entwicklungsprozess der Bildung von
sog. Personas zu. Bei den zahlreichen
Zielgruppen mit unterschiedlichen Intentionen und Erwartungen auf einer
Corporate-Website ist der PersonaAnsatz (Cooper & Reimann 2003), d.h.
die Erstellung archetypischer Nutzer,
maßgeblich am Erfolg der nutzerzentrierten Entwicklung einer Corporate-Website beteiligt. Leider hat sich
diese Methode im Bereich der Website-Konzeption noch nicht fest etabliert.
5.0
Fazit und Ausblick
Die Aufarbeitung der theoretischen Grundlagen und die Daten der
Expertenbefragung zeigen, wie wichtig
ein spezifischer Prozess ist, der den
Einsatz von Usability-Maßnahmen
entlang der gesamten Entwicklung
einer Corporate-Website von der Planung bis hin zum Live-Betrieb beschreibt.
Neben dem eigentlichen Prozessmodell bietet die Beschreibung
seiner Durchführung in Form des Prozesshandbuchs eine hervorragende
Grundlage für die Konzeption einer
benutzerfreundlichen CorporateWebsite. Es ist anzumerken, dass das
Prozessmodell ungeachtet seines engen Praxis-bezuges einen idealtypischen Ablauf beschreibt, der selbstverständlich an einigen Stellen an das
jeweilige Website-Projekt angepasst
werden muss.
Fortan gilt es diesen Lifecycle im
Rahmen von Fallstudien zu evaluieren
bzw. zu validieren und ggf. anzupassen.
Derzeit besteht eine Kooperation mit der
Bosch Rexroth AG in dieser Hinsicht.
Fokus des systematischen Entwicklungsprozesses ist hierbei die Abbildung
der Websitenutzer durch Personas infolge einer Nutzerbefragung auf dem Internetangebot (Onsite-Befragung), auf deren Basis die weiteren Entwicklungsschritte folgen.
Die komplette Studie war Teil einer
Diplomarbeit an der Technischen Universität Ilmenau im Studiengang Medientechnologie in Zusammenarbeit mit
der eResult GmbH. Weitere Informationen sind auf Anfrage bei den Autoren
erhältlich.
6.0
Brau, H.; Sarodnick, F. (2006): Methoden der
Usability Evaluation : wissenschaftliche
Grundlagen und praktische Anwendung.
Bern: Huber.
Braun, B.; Miao, M.; Röse, K. (2007): Integration von Usability-Engineering in die Produktentwicklung : Ergebnisse einer Expertenfokusgruppe. In: Braun, B.; Röse, K. (Hrsg.):
Usability Professionals 2007 - Berichtband
des fünften Workshops des German Chapters
der Usability Professional Association e.V..
Stuttgart: Fraunhofer IRB Verlag, S.131-134.
Cooper, A.; Reimann, R. (2003): About face
2.0 : The essentials of interaction design.
Indianapolis: Wiley & Sons.
eResult GmbH: eResult-Newsletter.
http://eresult.de/newsletter.htm
IHK Hannover: Online-Infoservice (Newsletter). http://www.hannover.ihk.de/?id=592
Mayhew, D. J. (1999): The usability engineering lifecycle : a practitioner's handbook for
user interface design. San Francisco: Kaufmann.
Nielsen, J. (1993): Usability Engineering. San
Diego: Academic Press.
191
192
F al lstudien
193
194
Innovative Maschinen brauchen innovative
Entwicklungsprozesse
– Usability, Design und Software optimal verzahnen
Franz Koller
Martin-Luther Str. 57 - 59
71636 Ludwigsburg
[email protected]
www.uid.com
Abstract
Am Beispiel der Entwicklung einer
Touch-Bedienoberfläche zur Steuerung
von Maschinen für die Kabelverarbeitung wird gezeigt wie der benutzerzentrierte Entwicklungsprozess in der Praxis
genutzt wurde.
1.0
Dieser Anforderung sollte durch ein attraktives Design erreicht werden, das
auch in der Gestaltung als ästhetisch
hochwertig und überzeugend wahrgenommen wird. Deshalb stellte sich zu
Beginn des Projekts die wesentliche
Frage, wie sichergestellt werden kann,
dass Konzept und Design auch in der
geplanten Qualität von der Softwareentwicklung umgesetzt wird.
Vorgehen
Das Vorgehen orientierte sich am
benutzerzentrierten Entwicklungsprozess wie er auch in der ISO13407 (DIN
EN ISO 13407, 2000) beschrieben ist.
Keywords
Benutzerzentrierte Entwicklung, User
Experience, Entwicklungsprozess,
XAML
ationen. Die Vor-Ort-Erhebung wurde
später ergänzt durch Beispiele und Demonstrationen an Werkzeugmaschinen
in der Fertigung. Diese Informationen
lieferten wesentliche, wertvolle Grundlagen für die folgenden Gestaltungsarbeiten.
Einleitung
Ziel bei der Entwicklung einer
Touch-Bedienoberfläche zur Steuerung
von Maschinen für die Kabelverarbeitung war nicht nur eine sichere, ergonomische Bedienung. Vielmehr sollte die
technische Innovationskraft der Maschine durch eine angemessene visuelle
Gestaltung erfahrbar gemacht werden.
2.0
Der Beitrag beschreibt das Vorgehen
und legt einen Schwerpunkt auf die
Darstellung der Zusammenarbeit zwischen Usability, Design und Software
Entwicklung.
2.2
Abb. 1: UCD benutzerzentrierter Entwicklungsprozess bei UID
2.1
Anforderungserhebung
Durch intensive Gespräche, Diskussionen und Workshops mit Teilnehmern aus mehreren Ländern
machten sich die Usability Engineers
zunächst ein Bild vom Nutzungskontext. Wie tatsächlich gearbeitet wird
und welche physischen und sozialen
Bedingungen am Arbeitsplatz herrschen, kann oft nur im direkten Kontakt mit dem eigentlichen Anwender
erfasst werden (Beyer & Holtzblatt
1998, S. 42f., S. 113). Deshalb beobachtete zusätzlich ein Usability Engineer bei einem Vor-Ort-Termin die
Aktivitäten von Maschinenbedienern
sowie ihre Umgebung. Die Anwender
erläuterten dabei ihre relevanten Tätigkeiten, Vorgehensweisen oder Situ-
Konzeptentwurf
In mehreren Gestaltungsworkshops
wurde das User Interface Konzept gemeinsam mit dem Entwicklungsteam der
Schäfer Werkzeug- und Sondermaschinenbau GmbH entworfen. Ausgangspunkt waren Konzeptideen, die mit den
Anforderungen abgeglichen, aus Usability-Sicht erweitert und konkretisiert wurden. Wichtig war, dass im Entwicklungsteam auch Vertreter aus verschiedenen
internationalen Niederlassungen beteiligt
waren und zusätzliche regionale Besonderheiten einbringen konnten.
Um die Konzeptideen zu visualisieren
wurden zu Beginn sehr viel mit Handskizzen gearbeitet, die dann in Wireframes überführt wurden. So konnten die
Beteiligten Arbeitsabläufe anschaulich
skizzieren und in Workshops anschließend diskutieren und optimieren.
195
präsentieren, ihre Funktionsfähigkeit
testen und das Interface den späteren
Nutzern zeigen.
Die folgenden drei Abbildungen geben
einen Einblick in die realisierte Bedienung zur Maschinensteuerung.
Abb. 2: Erste Wireframes der geplanten
Steuerung
Auf der Basis der ersten Wireframes
gestalteten die UID-Designer erste grafische Entwürfe. Hierbei war es wichtig,
dass die Bedienelemente für den Einsatz auf dem Touch-Screen entsprechend gestaltet wurden.
Abb. 3: Grafikentwurf für die Gestaltung
2.3
Prototyping
Um sicher zu stellen, dass die Entwürfe der Benutzungsoberfläche auf der
Maschine exakt in ein funktionierendes,
dynamisches Interface umgesetzt werden, wurde der Entwurf mit XAML (eXtensible Application Markup Language)
und "Microsoft Expression Blend", realisiert. Dadurch konnte der Entwurf interaktiv visualisiert und damit für den Kunden frühzeitig "greifbar" gemacht werden. Die Schäfer Werkzeug- und Sondermaschinenbau GmbH konnte so die
interaktive Oberfläche ihren Vertriebspartnern und ausgewählten Kunden
196
Abb. 4: Prototyping mit XAML Blend
2.4
Abb. 5: Screenshot des Produzieren Screens
Iterative Weiterentwicklung
Das erfolgreiche Ergebnis dieses
Prototypings bildete die Basis für die
eigentliche Softwareentwicklung und
die visuelle Optimierung der Benutzungsoberfläche.
Eng verzahnt mit dem Kunden haben
Usability Engineering, Design und
Softwareentwicklung das Konzept weiterentwickelt und auf die verschiedenen Bereiche übertragen. In gemeinsamen Workshops wurden die jeweiligen Neuerungen besprochen und weitere Alternativen geklärt. Nachdem das
Grundkonzept entwickelt war, beschränkte sich die Rolle des Usability
Engineering immer mehr auf die Rolle
der Qualitätssicherung.
Im Anschluss trieben Design und
Softwareentwicklung gemeinsam die
Entwicklung voran. Usability Engineers
wurden dabei immer wieder punktuell
zu Rate gezogen. Diese übergreifende
Zusammenarbeit war sehr fruchtbar.
Denn sowohl Designer als auch der
Softwareentwickler sind es bei UID
gewohnt in interdisziplinären Teams
User Interface Konzepte zu entwickeln, die sowohl eine hohe
Gebrauchstauglichkeit als auch eine
hohe ästhetische Qualität haben.
Abb. 6: Screenshot der Konfiguration eines
Kabels
Abb. 7: Screenshot der Maschinenkonfiguration
2.5
Evaluation
Eine systematische Evaluation mit
Usability Tests ist noch nicht erfolgt.
Strukturiertes Feedback von Nutzern der
ersten Vorserienmaschinen liegt hingegen vor. Diese Nutzer bestätigen zum
einen die sehr positive Entwicklung des
Designs bestätigen. Zum anderen zeigen sie weiteres Optimierungspotential
in bestimmten Bereichen auf.
3.0
Zusammenarbeit zwischen Usability, Software und Design
Durch eine gute interdisziplinäre
Zusammenarbeit zwischen Usability,
Software und Design sollen intuitiv bedienbare, funktional ausgewogene Produkte mit eine hohen ästhetischen Qualität entstehen. Das gemeinsame Ziel –
die optimale Verbindung von Usability,
Ästhetik und Realisierbarkeit – setzt
gegenseitiges Verständnis voraus. Die
unterschiedliche Ausbildungen und Erfahrungen von Usability Engineers, Designern und Softwareentwicklern führen
bei der Gestaltung von Benutzungsoberflächen oft zu Diskussionen. Die besten
Lösungen entstehen häufig dann, wenn
alle Disziplinen für ihren Standpunkt
eintreten und tragfähige belastbare Konzepte erarbeiten, die aus der gemeinsamen Sicht möglichst optimal ist.
Eine effiziente Zusammenarbeit zwischen den Disziplinen ist leicht propagiert und gewünscht, aber nicht so einfach gelebt. Jede Disziplin besitzt ihre
eigene Fachsprache und hat ihren geschulten Blick auf ein System. Der benutzerzentrierte Gestaltungsprozess
liefert eine gute Grundlage um das gemeinsame Ziel zu erreichen. Das Handwerkszeug für effizientes Arbeiten in
einem multidisziplinären Team muss
jedoch einfach in der täglichen Praxis
geübt werden. Dazu zählt die Kommunikation miteinander, der kontinuierlicher
Austausch sowie gegenseitiges Respek-
tieren und Verstehen über die Fachgrenzen hinweg.
3.1
Hilft Toolunterstützung?
Um die Kommunikation zwischen
den Disziplinen zu verbessern und
Missverständnisse zu vermeiden, helfen auch gemeinsame Tools. Ein Tool,
das sowohl Usability Engineer, Designer und Softwareentwickler zusammen
bringen möchte, ist Expression Blend
von Microsoft (Leete 2007).
In der Praxis sieht es anders aus: Designer gestalten ihre grafischen Entwürfe weiterhin in Adobe Photoshop oder
Illustrator. Die Gründe sind einfach
nachvollziehbar. Die Designer haben
sehr viel Erfahrung mit ihren bisherigen
Tools, die alle für sie relevanten Funktionalitäten für ein professionelles Design
bereit stellen. Expression Blend bietet
hier nicht das komplette Spektrum an
Designmöglichkeiten.
Die Grundidee ist einfach: Layout und
Logik werden getrennt betrachtet. Der
Designer entwickelt das Design in Expression Blend und der Software Entwickler erstellt die Programmierlogik
mit Visual Studio.
Abb. 9: Tatsächliche Arbeitsteilung zwischen
Software und Design
3.2
Abb. 8: Theoretische Arbeitsteilung zwischen Software und Design
Die Zusammenarbeit ist dabei so konzipiert, dass der Software Entwickler
die zwei Komponenten zu einer Anwendung zusammenführen kann. Dabei bestimmt der XAML-Code die grafische Oberfläche und der C#-Code
stellt die Anwendungslogik bereit.
Zusätzlich gibt es eine gewisse Grauzone in Expression Blend, in der sowohl Designer, Usability Engineer und
Software Entwickler in Expression
Blend ebenfalls Bedienlogik einbringen
und Bedienelemente interaktiv machen
können – etwa um verschiedene
Screens miteinander zu verknüpfen,
Animationen zu starten oder zu beschreiben. Mit Hilfe dieser Funktionalität können prototypisch Bedienkonzepte visualisiert werden.
Wie geht es dann?
Auch wenn die theoretische Arbeitsteilung in der Praxis so noch nicht angekommen ist, hat sich in der Zusammenarbeit zwischen den Disziplinen mehr
geändert, als auf es auf den ersten Blick
scheint.
Der Austausch zwischen den Disziplinen
ist deutlich intensiver geworden. Um
Design- und Lösungsansätze zu optimieren, finden Diskussionen immer häufiger gemeinsam am Rechner statt –
statt wie vorher häufig mit Flipchart und
Screenausdrucken umständlich zu hantieren.
Die unterschiedlichen Toolwelten existieren auch weiterhin. Aber IllustratorDateien werden nach XAML exportiert
und in Blend direkt verwendet. Dadurch,
aber vor allem durch den Versuch der
Designer, direkt in Blend zu arbeiten, ist
ein besserer Austausch entstanden.
197
Die verschiedenen Disziplinen setzen
sich intensiver mit den Möglichkeiten
und Anforderungen der jeweils anderen
Tools auseinander und haben dadurch
ein besseres Verständnis für einander
entwickelt.
4.0
Fazit
Die Klammer für das gemeinsame
Ziel – die optimale Verbindung von Usability, Ästhetik und Realisierbarkeit – ist
nach wie vor der benutzerzentrierte
Entwicklungsprozess, der unterschiedli-
198
che Disziplinen zusammenarbeiten
lässt. Durch die Entwicklungen im
Toolbereich sind wir wieder einen
wichtigen Schritt weiter gekommen. So
können wir die multidisziplinäre Zusammenarbeit intensiver in der Praxis
leben und dadurch zu besseren Lösungen für den Nutzer kommen.
5.0
Beyer, H.; Holtzblatt, K (1998).: Contextual
Design- Defining Customer-Centered Systems. San Francisco: Morgan Kaufmann
Publishers, 1998
DIN EN ISO 13407 (2000): Benutzerorientierte Gestaltung interaktiver Systeme, Beuth
Verlag, 2000.
Leete, G; Leete, M. (2007): Microsoft Expression Blend Bible: The Book you need to succeed!, Wiley & Sons 2007
Mayhew, D.L. (1999): The UsabilityEngineering lifecycle. A practitioner's handbook for user interface design. San Francisco, CA: Morgan Kaufmann, 1999.
Stropek, R.; Huber, K. (2007): WPF und
XAML Programmierhandbuch, entwickler.press 2007
Web Globalization balanced by User Experience
Arne Kittler
Fork Unstable Media GmbH
Juliusstr. 25
22769 Hamburg
[email protected]
Rainer Gibbert
SirValuse Consulting GmbH
Schlossstrasse 8g
22041 Hamburg
[email protected]
Christiane Ehlers
SirValuse Consulting GmbH
Schlossstrasse 8g
22041 Hamburg
[email protected]
Abstract
Eine gelungene Balance aus international übergreifender Standardisierung und
einem Angebot, das Nutzer mit ihren
jeweiligen lokalen Bedürfnissen anspricht, ist eine wesentliche Herausforderung für internationale Markenwebsites. Bislang fehlt es an anwendbaren
Informationen, die Unternehmen und
ihren Agenturen beim Erreichen dieser
Balance unterstützen.
1.0
Einleitung
Im Rahmen der Web Globalization,
also den Aktivitäten eines Unternehmens, seine internationalen Webpräsenzen einzurichten und zu betreiben,
ist ein hohes Maß an internationaler
Standardisierung der empfohlene und
weit verbreitete Ansatz (vgl. Yunker
2008; Kittler 2006). So haben in einer
aktuellen Studie von Bytelevel Research
(Yunker 2008) die am besten internationalisierten Websites eines gemein: Den
länderübergreifenden Einsatz globaler
Templates. Mit anderen Worten: Weltweit sind alle Websites einer Marke
mehr oder weniger gleich.
Auf der anderen Seite erscheint es aus
User Experience-Sicht gewagt, Nutzer
aus unterschiedlichen Kulturkreisen mit
einer im Wesentlichen standardisierten
Website optimal ansprechen zu wollen.
Gerade bei emotionalen Botschaften,
die bei Markenwebsites eine wichtige
Rolle spielen oder auch bei Funktionen,
die ein gesteigertes Maß an Nutzeraktion erfordern, kann diese Standardisierung zu einem Wettbewerbsnachteil
gegenüber Angeboten führen, die explizit für bestimmte Märkte entwickelt wurden. Nach einer Phase der Standardisie-
Dieser Artikel leistet einen entsprechenden Beitrag: Anhand einer vergleichenden User Experience Analyse
der weitgehend standardisierten Markenwebsite von NIVEA mit deutschen
und chinesischen Nutzern wird untersucht, in welchen Bereichen und Funktionen Standardisierung unproblematisch ist und wo lokalspezifischere
Gestaltungen sinnvoll sind.
Keywords:
rung von globalen (Marken-) Websites
steht deshalb nun eine Phase bevor, in
der Unternehmen sorgfältig ausbalancieren müssen, wie weit sie mit der
Standardisierung gehen und wo individuellere Lösungen für bestimmte Länder erforderlich sind, um eine bestmögliche User Experience zu gewährleisten.
für internationale Markenwebsites verantwortlichen Teams auf Agentur- und
Kundenseite aber nur wenig anwendbare Hilfestellungen.
Für dieses Ausbalancieren aus Standardisierung und individuelleren lokalen Lösungen fehlt es bisher an anwendbaren Erkenntnissen und Lösungen. Dieser Artikel leistet einen (sicherlich nicht abschließenden) Beitrag
zu dieser Fragestellung.
2.0
Suche nach anwendbaren Erkenntnissen
In Beiträgen zu internationaler
Usability und internationaler Markenkommunikation fehlt es nicht an Beispielen für Probleme, die ein allzu starres Übertragen von Kommunikationsbotschaften auf unterschiedliche Kulturkreise haben kann (vgl. Anholt
2000; Aykin & Milewski 2005). Diese
Beiträge, haben leider in vielen Fällen
eines gemein: Sie werfen zwar Licht
auf punktuelle Probleme und sensibilisieren somit zur Vorsicht – geben den
User Experience, Branding, Web Globalization, Internationalisierung, China
Selbst wenn man beispielsweise weiß,
dass ein bestimmter Icon-Stil in einigen
Kulturen Probleme bereitet, kann man
nicht sicher sein, dass entsprechend
entwickelte Alternativen in wiederum
anderen Ländern oder Kulturen nicht
ihrerseits Probleme bereiten. Bei den
Websites internationaler Marken ist der
Handlungsraum dabei global und entsprechend komplex: Die Durchschnittliche Anzahl von Sprachen auf internationalen Websites ist 2008 auf 20 gestiegen (Yunker 2008) und erfolgreiche
Websites wie die hier untersuchte NIVEA Website sind in 50 oder mehr Ländern auf allen Kontinenten präsent.
3.0
Der Ansatz: Web Globalization
balanced by User Experience
Statt sich darum zu sorgen, ob ein
einzelnes Detail einer Website in allen
Zielmärkten funktionieren wird, suchen
wir deshalb nach einer allgemeingültigeren Lösung: Einer Systematisierung der
sinnvollen Balance zwischen global konsistenten und lokalspezifischen Bereichen und Inhalten von Markenwebsites.
199
3.1
Untersuchung typischer Bereiche
und Funktionen auf Standardisierbarkeit
Zur Systematisierung untersuchen
wir typische Bereiche und Inhalte von
Markenwebsites daraufhin, in welchem
Maße sie international divergierenden
Anforderungen in Bezug auf die User
Experience ausgesetzt sind.
Bereiche und Funktionen, bei denen nur
ein geringes Maß an internationaler Divergenz festgestellt wird, können einigermaßen bedenkenlos standardisiert
werden. Sie werden idealerweise lediglich sprachlich übersetzt. Hierdurch kann
mehr Augenmerk auf jene Bereiche der
Website gelegt werden, bei denen die
Nutzerbedürfnisse für eine optimale
User Experience international stärker
variieren.
3.2
Vorgehensweisen bei weniger
standardisierbaren Bereiche und
Funktionen
Für Bereiche, in denen eine hohe internationale Divergenz festgestellt wird,
gibt es drei mögliche Vorgehensweisen:
3.2.1
Modulare Internationalisierung
Das Internationalisierungsteam entwickelt modulare Lösungen, die im
Rahmen des Lokalisierungsprozesses
einfach an lokale Bedürfnisse angepasst
werden können. In den Content Management Systemen, mit denen internationale Websites lokalisiert werden, können hierfür entsprechende Optionen
vorgesehen werden. Dieses Vorgehen
eignet sich besonders für Inhalte, deren
lokale Ausprägung sich in stabilen Regeln abbilden lässt. Zum Beispiel können lokale Besonderheiten wie Maßeinheiten oder Adressformate auf diese Art
und Weise gut berücksichtigt werden.
Idealerweise können Best PracticeBeispiele identifiziert werden, an denen
sich Web Globalization Teams bei der
Entwicklung orientieren können.
200
3.2.2
Lokale Eigenentwicklungen
In dedizierten Bereichen der Website (und sinnvollerweise geleitet durch
entsprechende Styleguides, Vorlagen
und Qualitätssicherungsmechanismen)
können genuin lokale Inhalte integriert
werden. Diese Inhalte sind spezifisch
auf die jeweiligen lokalen Nutzer ausgerichtet und werden üblicherweise
von lokalen Teams entwickelt. Dieses
Vorgehen ist besonders gut geeignet
für sehr emotionale Inhalte, Humor,
Ironie usw.
3.2.3
Keine lokalen Ausnahmen
Ob die beiden oben genannten
Vorgehensweisen angewandt werden,
hängt letzten Endes auch davon ab,
ob die erwarteten Verbesserungen der
User Experience in einem angemessenen Verhältnis zu den damit verbundenen Mehraufwänden steht (im
Gegensatz zu einer einfachen Übersetzung international standardisierter
Lösungen). Falls die Aufwände unangemessen hoch erscheinen, kann es
ratsam sein, Abstand von diesen Lösungen zu nehmen. Naturgemäß kann
die Wirkung einer verbesserten User
Experience nicht in demselben Maße
quantifiziert werden wie Zusatzkosten.
Nichtsdestotrotz kann auch eine qualifizierte Abschätzung entsprechend
dieser Systematik die Entscheidungsfindung von Web Globalization Teams
bei ihrer Arbeit erleichtern.
4.0
Methodisches Vorgehen zur Evaluation der Deutschen und Chinesischen NIVEA-Website
Nur in wenigen Fällen ist es möglich, allein aufgrund der Inhalte einer
Website Bereiche zu identifizieren, bei
denen ein hohes Maß an Standardisierung die User Experience in globaler
Hinsicht beeinflusst. Dies gilt für jene
Inhalte, die direkt von divergierenden
Standards außerhalb der Online-
Kommunikation betroffen sind, wie etwa
Adressformulare.
Für eine aussagekräftige Bewertung
weiterer Bereiche ist es dagegen erforderlich, vergleichende Untersuchungen
zur User Experience mit internationalem
Kontext anzustellen, idealer Weise mit
Nutzern aus den unterschiedlichen Kulturkreisen.
4.1
Expertenevaluation
Zur vergleichenden Untersuchung
der User Experience der NIVEA-Website
in Deutschland und China wurde zunächst ein Expertengutachten beider
Websites durchgeführt. Hierzu evaluierten User Experience-Experten aus
Deutschland und China die jeweilige
Landeswebsite hinsichtlich folgender
Faktoren für den Erfolg von Markenwebsites (vgl. Schwab, Wörmann, Wolf
2005):
4.1.1
Anmutung und Design
Die internationale Standardisierung
der NIVEA-Websites zeigt sich insbesondere an dem länderübergreifend
einheitlichen Design. Ein zentrales Content Management System mit standardisierten Templates und einem internationalen Styleguide sorgen auf den ersten
Blick für ein einheitliches „Look and
Feel“ der Seite beider Ländern.
Anmutung und Design der Sites werden
von den Experten in beiden Ländern als
passend zur Marke NIVEA bewertet;
besonders das durchgängig verwendete
blaue Farbschema sorgt für einen hohen
Wiedererkennungswert.
Während die Models auf der deutschen
Website als passend und ansprechend
bewertet werden, kritisiert der chinesische Experte, dass die auf der chinesischen NIVEA Website eingesetzten
(überwiegend asiatischen) Models zu
europäisch aussehen und befürchtet
Identifikationsprobleme chinesischer
Nutzer mit diesen Models. Neben dieser
generellen Kritik wird vom chinesichen
Experten insbesondere das Keyvisual
als nicht aussagekräftig kritisiert, da
hierin kein spezielles Produkt dargestellt
wird – eine in Deutschland dagegen
übliche und somit unkritische Präsentation.
könnte hingegen der Eindruck entstehen, dass auf der Seite wenige Informationen angeboten werden und nicht
viel zu tun sei.
Auch die Schriftgestaltung auf der chinesischen Website wird als teilweise
schwierig bewertet. Da die chinesischen Schriftzeichen größer und komplexer sind als unsere Buchstaben,
wird die Lesbarkeit in Teilen der Website kritisiert, obwohl in den eingesetzten Templates die Schrittgröße für
chinesisch gegenüber deutschen Texten bereits bewusst erhöht wurde.
4.1.2
Abb 1: Startseite der deutschen NIVEAWebsite
Usability
Die Benutzbarkeit von Markenwebsites hat weniger direkte (und vor
allem weniger quantifizierbare) Auswirkungen auf den Erfolg der Site als
z.B. bei einem Online-Shop, bei dem
ein Usability-Problem direkt zu einem
Kaufabbruch führen kann. Trotzdem
beeinflusst die Benutzbarkeit maßgeblich das Anwendungserlebnis auf einer
Seite und kann somit positiven oder
negativen Einfluss auf das Markenbild
insgesamt haben.
ten werden, mit der Seite zu interagieren
(z.B. durch Beratungs-, oder Community-ähnliche Funktionen sowie Spiele),
wird durch den chinesischen Experten
bemängelt, dass im Bereich „Unterhaltung“ kaum interessante Funktionen
angeboten werden. Insbesondere eine
Community zum Austausch über NIVEA
oder Schönheitsprodukte würde hier aus
chinesischer Sicht Sinn machen.
Die in „Unterhaltung“ angebotenen Spielen werden in beiden Ländern als langweilig und zu wenig kosmetikbezogen
kritisiert, es zeigt sich darüber hinaus
aber auch die Bedeutung kultureller Referenzen: Die vom chinesischen Experten vorgeschlagenen alternativen Spielprinzipien „Chinese Poker“ und „Majiang“ sind in Europa weitgehend unbekannt und würden von in Europa ansässigen Entwicklungsteams sicher kaum
als Inspiration für neue Spiele herangezogen werden. Dies unterstreicht die
unter 3.2.2 geäußerte Vermutung, dass
gerade derart unterhaltende Inhalte mit
lokalen Eigenentwicklungen besser auf
lokale Bedürfnisse eingehen können.
4.1.4
Grundlegende Unterschiede hinsichtlich der Benutzbarkeit der beiden Länderwebsites konnten in dem Expertengutachten nicht identifiziert werden.
Dies sollte jedoch nochmals in einem
Test mit echten Anwendern verifiziert
werden.
Abb 2: Startseite der chinesischen NIVEAWebsite
Insgesamt wird vom chinesischen Experten angemerkt, dass besonders die
Startseite der NIVEA-Website zu leer
und aufgeräumt erscheint. Was in
Deutschland und westlichen Ländern als
Vorteil gesehen wird, wird vom chinesischen Experten als möglicherweise
problematisch gekennzeichnet, da chinesische Websites eher voll und mit
vielen Informationen versehen sind.
Durch ein zu aufgeräumtes Design
4.1.3
User Engagement
Die Einbeziehung und Einbindung
von Anwendern auf einer Markenwebsite ist wichtig, um die potentiellen
Kunden möglichst lange mit Marke und
Produkten in Kontakt zu halten und ein
positives Erlebnis zu generieren.
Der NIVEA-Website gelingt dies in den
beiden untersuchten Ländern unterschiedlich. Während aus deutscher
Sicht vielfältige Möglichkeiten angebo-
Wissenswertes / authentische Informationen
Informationen über Produkte zu bieten ist eine wichtige Anforderung an eine
Markenwebsite (je nach Art der angebotenen Produkte). Für die NIVEA-Website
bedeutet dies, dass hierauf zu den verschiedensten Produkte Informationen zu
Anwendung, Inhaltsstoffen u.v.m. geboten werden sollten.
Während das Informationsangebot aus
Sicht des deutschen Experten als
grundsätzlich umfangreich, nützlich und
meist leicht verständlich bewertet wird,
werden die Informationen von dem chinesischen Experten als nicht ausreichend kritisiert. Chinesische Konsumenten vermissen laut dem Experten auf
Websites europäischer Hersteller generell länder- und kulturspezifische Infor-
201
mationen und Ansprachen. Auf der chinesischen Website von NIVEA fehlen
aus Expertensicht insbesondere Informationen, wie und wozu spezielle Produkte genutzt werden können. So fehlen
beispielsweise Tipps zur Nutzung von
Sonnenschutz speziell für chinesische
Hauttypen oder auch Informationen,
warum man Deodorants benutzt – eine
in Deutschland sicher unnötige, in China
aber relevante Information.
4.1.5
Markenadäquanz
Wie schon angesprochen, wird die
generelle Anmutung und das Design der
NIVEA-Website von den Experten beider Länder als passend zur Marke bewertet. Insbesondere in Deutschland, wo
NIVEA eine bekannte Marke mit langer
Tradition ist, kann durch die Gestaltung
der Seite ein direkter Bezug zur Marke
hergestellt werden.
Marken-Loyalität war hingegen in China
historisch ein weniger wichtiges Thema.
Laut dem Experten etabliert sich erst
seit einiger Zeit ein gewisses Bewusstsein für bestimmte Marken. Westliche
und insbesondere auch deutsche Marken werden in China dabei besonders
positiv wahrgenommen, da diese dort für
Qualität stehen. Trotzdem sind viele
deutsche Marken nur teilweise bekannt.
Laut dem chinesischen Expertengutachten liegt hierin ein weiteres Optimierungspotential hinsichtlich der chinesischen NIVEA-Website, da die Informationen zur Marke nicht offensichtlich genug kommuniziert werden. So gibt es
zwar wie auf der deutschen Site auch
einen allgemeinen Bereich „Die Marke“,
die wichtigsten Informationen sollten
jedoch prägnanter und direkt auf der
Startseite kommuniziert werden. Hierzu
zählen vor allem, dass NIVEA eine
deutsche Marke mit langjähriger Tradition ist und dass NIVEA eine international
angesehene und benutzte Marke ist.
202
4.1.6
Sicherheit und Fairness
Markenwebsites sollten bei allen
Daten, die von den Nutzern z.B. zur
Newsletter-Bestellung oder für Gewinnspiele erfragt werden, ein hohes
Maß an Sicherheit und Fairness gewährleisten (Sicherheit im Sinne, dass
sämtliche angegebenen Daten vertraulich behandelt werden und Fairness,
dass keine unnötigen Daten erfragt
werden), da sich beide Faktoren negativ auf das Image der gesamten Marke
niederschlagen können.
Aus Sicht der Usability-Experten gibt
es auf den beiden Ländersites von
NIVEA keine schwerwiegenden Problemstellen hinsichtlich der Sicherheit
und Fairness. Der chinesische Experte
merkt jedoch an, dass in China generell ein anderes Sicherheitsbewusstsein herrscht (aufgrund der politischen
Lage in der Vergangenheit und der
Gegenwart), weshalb chinesische Nutzer im Gegensatz zu westlichen Nutzern weniger gewillt sind, persönliche
Daten preiszugeben. Stattdessen werden hier häufiger falsche oder fiktive
Daten in Webformularen angegeben,
als dies z.B. in Deutschland der Fall
ist. Dies sollte also entsprechend bei
der Gestaltung von Formularen auf
Markenwebsites und deren Fehlertoleranz hinsichtlich der Eingaben berücksichtigt werden.
4.1.7
Technik
Die technische Implementierung
und insbesondere deren Performance
sind weitere kritische Faktoren für die
Wahrnehmung und den Erfolg einer
Website und insbesondere einer Markenwebsite (vgl. Meyer, Vogt & Glier
2005 und Schwab, Wörmann, Wolf
2005). Daher sollte bei der Gestaltung
einer entsprechenden Website immer
auch das Wissen über die technische
Ausrüstung der Zielgruppe eine Rollte
spielen.
Während in Deutschland mittlerweile
mehr als 60% der Internetnutzer über
einen DSL- oder anderen Breitbandanschluss verfügen, ist die Anzahl von
Breitbandanschlüssen in China derzeit
noch vergleichsweise niedrig. Hinzu
kommt laut chinesischem Experten,
dass die Verbindung zu in anderen Ländern gehosteten Internetsites aus China
heraus ebenfalls niedriger ist, als in
westlichen Ländern, was im Falle von
NIVEA durch zusätzliches Hosting in
Hongkong allerdings nicht der Fall ist.
Dies hat zur Folge, dass Websites mit
relativ aufwendigen Grafiken, Filmen
und anderen interaktiven Elementen
(wie den auf NIVEA verwendeten FlashFilmen) teilweise deutlich langsamer
laden. Hinzu kommt, dass die Verbreitung von neusten Software-Versionen
wie der auf der NIVEA-Website erforderliche Flash Player 8 in China ebenfalls
deutlich geringer ist als in westlichen
Ländern.
Insgesamt könnten diese technischen
Anforderungen laut chinesischem Experten dazu führen, dass Nutzer entmutigt
werden, die Website in ihrem vollen Umfang zu nutzen.
4.2
Weitere geplante Methoden
Auf Grundlage dieser ersten Ergebnisse sind weitere vergleichende Untersuchungen vorgesehen, deren Ergebnisse aber noch nicht vorliegen.
Dabei soll zunächst eine OnlineBefragung auf den jeweiligen Landeswebsites durchgeführt werden. Ziel ist
es, zum einen die Erkenntnisse aus den
Expertengutachten durch quantitative
Nutzerdaten zu belegen und zum anderen weitere Informationen über die tatsächlichen Anwender sowie deren Bedürfnissen in den Ländern zu erheben.
Die Ergebnisse aus Expertengutachten
sowie Online-Befragung sollen anschließend als Fragestellungen in einen
internationalen User Experience Test mit
Nutzern aus den beiden Ländern einfließen. Hierzu werden Testpersonen aus
Deutschland und China zu einem User
Experience Test im Labor eingeladen
und bei der Bearbeitung typischer Nutzungsszenarien (identifiziert aus den in
der Online-Befragung angegebenen
Besuchsgründen) beobachtet.
Ziel der Studie insgesamt ist es, in Expertengutachten, Online-Befragung und
User Experience Test Erkenntnisse zu
generieren, die einerseits in die Optimierung und Weiterentwicklung der NIVEAWebsite einfließen sollen. Darüber hinaus sollen grundlegende Richtlinien extrahiert werden, die für die Gestaltung
internationaler Markenwebsites global
und lokal relevant sind.
5.0
Erste Schlussfolgerungen
Obwohl die Ergebnisse der OnlineBefragung und der User Experience
Tests noch ausstehen, geben die Expertenevaluationen bereits einige erste Indikationen für Elemente von Markenwebsites, bei denen eine lokale Ausprägung wichtig für eine adäquate lokale
User Experience ist:
5.1
Schwerpunkt für europäische Märkte
produziert werden.
5.2
Lokale Relevanz der Homepage
In der Evaluation wurden sehr
spezifische Anforderungen chinesischer Nutzer an die Homepage festgestellt: Sowohl hinsichtlich der vermittelten Informationsfülle als auch hinsichtlich der generellen Einführung der
Marke wurden lokale Bedürfnisse geäußert, die mit globalen Templates
kaum abzudecken sind. Aus diesem
Grund empfiehlt sich auch für die Homepage (und vermutlich auch weitere
Seiten, die als Einstiegspunkt für neue
Nutzer fungieren sollen) wiederum
eine lokale Lösung. Ob eine Modularisierung der entsprechenden Templates hierbei sinnvoll ist, muss durch
einen Abgleich mit anderen lokalen
Bedürfnissen an die Homepage ermittelt werden: Zeichnen sich dabei entsprechende Parallelen in den Bedürfnissen unterschiedlicher Länder ab,
können diese entsprechend modular
berücksichtigt werden. Falls es sich
andererseits um rein chinesische Bedürfnisse handelt, wäre eine chinesische Ausnahmeregelung sinnvollerWeg.
Lokale Bildwahl
Um die Darstellung lokal akzeptierter Bildwelten zu ermöglichen, ist im
Sinne von 3.2.1 eine modulare Anlage
aller international entwickelten WebsiteBereiche in Hinblick auf die eingesetzten
Bilder empfehlenswert. Das untersuchte
Beispiel NIVEA zeigt allerdings, dass
diese Modularität bei Markenwebsites
nicht automatisch zu optimalen Ergebnissen führt: Im Falle der NIVEA Website sind zwar alle Bilder lokal wählbar,
aber die Auswahl an chinesischen Motiven ist sehr eingeschränkt. Grund hierfür
ist, dass auf der NIVEA Website Bilder
aus anderen Kommunikationsmaßnahmen der Marke (u.a. Werbung und PR)
eingesetzt werden, die bislang im
5.3
Lokale Unterhaltungen
Die Evaluation bestätigt die im
Vorfeld nahe liegende Vermutung,
dass unterhaltsame Inhalte und Community-Formate aus Sicht der User
Experience optimalerweise lokal entwickelt werden. Da es sich bei diesen
Inhalten häufig um kostspielige Entwicklungen handelt, besteht die Herausforderung in diesem Fall darin,
sinnvolle Synergien zwischen ähnlichen Märkten herzustellen, oder von
Seiten der zentralen Entwicklung mit
entsprechender Infrastruktur zu unterstützen (z.B. Bereitstellen von serverseitigen Community-Funktionen).
6.0
Fazit
Bereits die ersten Ergebnisse im
Rahmen dieser Studie bestätigen die
eingangs aufgestellte These, dass es
sinnvoll ist, in Web Globalization Projekten für bestimmte Inhalte und Bereiche
andere Vorgehensweisen als eine vollständige Standardisierung zu wählen,
um in den jeweiligen Zielmärkten eine
optimale User Experience zu gewährleisten. Weitere Untersuchungen werden
die bisherigen Ergebnisse ausdifferenzieren und es ermöglichen, weitere Bereiche zu identifizieren, die eine auf lokale Märkte abgestimmte Vorgehensweise erfordern. Wichtig hierbei ist jedoch immer die Einbeziehung von Nutzern aus den relevanten Ländern und
Märkten. Auf diesem Wege können anwendbare Erkenntnisse für eine erfolgreiche Balance von lokalspezifischen
und international standardisierten Inhalten von internationalen Markenwebsites
entwickelt werden.
7.0
Literatur
Anholt, S. (2000): Another one bites the
Grass: Making Sense of International Advertising. New Jersey: John Wiley & Sons
Aykin, N.; Milewski, A. (2005): Practical Issues and Guidelines for International Information Display. In: Aykin, N. (Hrsg.): Usability
and Internationalization of Information Technology. New Jersey: LEA
Kittler, A. (2006): Usability bei der Internationalisierung von Markenwebsites. Stuttgart:
Fraunhofer IRB Verlag
Meyer, H.A., Vogt, P. & Glier, M. (2005). Performance und Usability. i-com, Zeitschrift für
interaktive und kooperative Medien, Heft
3/2005, S. 62-65.
Schwab, K.; Wörmann, M.; Wolf, M. (2005):
Erfolgsfaktoren von Markenwebsites. Herunterzuladen unter http://argonauten 360.de/
(Stand: 02.06.2008)
Yunker, J. (2008): The Web Globalization
Report Card 2008. San Diego: Bytelevel Research
203
NEW HMI
Möglichkeiten und Grenzen abstrakt-geographischer
Visualisierung in Bereich der Anlagensteuerung
Thomas Hofmann
Institut für Arbeitswissenschaft
TU Darmstadt
Petersenstraße 30
64287 Darmstadt
[email protected]
Peter Holzkämper
SIG Combibloc Systems GmbH
Rurstrasse 58
D-52441 Linnich
[email protected]
Abstract
Die funktionale Komplexität aktueller
und zukünftiger Leitwarten erfordert ergonomisch optimierte Schnittstellen.
Die Firma SIG Combibloc GmbH ist sich
der Notwendigkeit nutzerangepasster
Interfacegestaltung im industriellen Umfeld bewusst und strebte die Neuentwicklung des existierenden Systems an.
Im Rahmen des Forschungs- und Entwicklungsprojektes NEW HMI wurde ein
komplett neues Mensch-Maschine Interface entwickelt,
1.0
Einleitung
Idealerweise bedient hoch qualifiziertes Personal entsprechend komplexe
Produktionsanlagen, wodurch eine gewisse Interfacekomplexität akzeptabel
scheint. In der Realität erfolgt die Kontrolle und Manipulation laufender Prozesse jedoch häufig auch durch angelernte und gering qualifizierte Arbeitskräfte, zumeist unter Zeitdruck. In Zukunft
wird diese Situation aufgrund ökonomischer Faktoren zunehmend zum Normalzustand werden.
Mit steigenden Komplexität von Fertigungsstraßen und Produktionslinien wird
es allerdings auch für hochqualifiziertes
Personal immer schwieriger die Menge
an Informationen zu analysieren und
entsprechend effektiv zu handeln.
Entsprechend müssen die Schnittstellen
zukünftig wesentlich besser an die je-
204
welches die Kontrolle und Anpassung
der laufenden Produktion ermöglicht.
Des Weiteren dient die Schnittstelle
der Systemadministration zur Modifikation Rezept unabhängiger Maschinenparameter.
Keywords
Integrative Hard- und Softwareentwicklung, Designsprache, nutzerund kontextzentrierte Gestaltung
Das Interface wird sowohl von Maschinenbedienern, als auch von Personen aus der Systementwicklung
bedient.
weiligen Interaktionsprozesse zwischen Nutzer und Technik angepasst
werden.
Diese Situation stellte die Entwickler
des HMI vor die Aufgabe, eine Systemschnittstelle zu gestalten, die einerseits auch ohne Verständnis der
Gesamtkomplexität sicher und effektiv
zu bedienen ist, andererseits bestimmten Nutzern komfortabel die Möglichkeit gibt, tief in das System einzugreifen und grundlegende Veränderungen
vorzunehmen.
2.0
Grundlagen der Entwicklung
Motivation zur Entwicklung eines
neuen MMI liegt in zwei Faktoren begründet.
Eine Produktionslinie zur Abfüllung
von Verbundverpackungen setzt sich
üblicherweise aus unterschiedlichen
Produktionsschritten zusammen. Die
eigentliche Füllanlage wird ergänzt
durch Arbeitsschritte wie Anbringen von
Ausgießern, Trinkhalmen, Bedrucken
mit MHD oder der Pallettierung. Diese
Produktionsschritte werden an eigenständigen Systemen durchgeführt, welche entsprechend individuelle MMI besitzen.
Dieser Umstand bedingt eine entsprechend längere Lernphase durch den
Nutzer (Operator). Ebenso ist die Reaktionsfähigkeit im Fehlerfall aufgrund unterschiedlichen Bedienphilosophien und
Designs beeinträchtigt. Aus diesem
Grund sollte ein homogenes MMI entwickelt werden, über welches alle Produktionsschritte und angeschlossenen Systeme zentral kontrolliert und gesteuert
werden können.
Der zweite Grund für die Neukonzeption
des Interfaces war, die Neuformulierung
der zukünftigen Nutzergruppen. Das
zukünftige MMI sollte anders als das
existierende den Ansprüchen zweier
unterschiedlicher Nutzergruppen entsprechen. Zum einen dem Operator
(Maschinenbediener im täglichen Produktionsprozess), zum anderen dem
Systementwickler.
Der Operator zeichnet sich dadurch aus,
dass er nur einen sehr geringen Interaktionsumfang besitzt. Seine Aufgaben
bestehen neben der Auswahl eines bestimmten Rezeptes vor allem in der
Überwachung der laufenden Produktion
und Beseitigung von Fehlern, die zum
Produktionsausfall führen oder führen
könnten. Dazu muss der Operator in der
Lage sein, auftretende Systemmeldungen (Fehler und Störungen) sofort auf
dem Bildschirm zu sehen und deren
Ursache lokalisieren zu können. Die
Interaktion mit dem Interface beschränkt
sich vor allem auf die Behebung von
Fehlern, beziehungsweise die Bestätigung behobener Fehler.
Der Systementwickler hat im Gegensatz
zum Operator nicht den eigentlichen
Produktionsprozess im Fokus, sondern
Systemeinstellungen. Diese Einstellungen dienen der Optimierung der Füllrezepte und davon unabhängigen Systemmodifikationen. Da diese Arbeitsschritte massiven Einfluss auf die Funktionalität der Produktionsanlage haben,
werden sie nur von hochqualifiziertem
Personal durchgeführt. Der Zugang zu
diesen Funktionen ist dem normalen
Operator nicht möglich.
2.1
Abb. 3: MMI Roboter
Abb. 1: Bisheriges Haupt MMI (Touchscreen)
Die ergänzenden MMI basieren auf
anderen Plattformen, in ihrer Hardware, wie in ihrer Software.
Wie aus den Abbildungen ersichtlich,
stellt sich die MMI Landschaft einer
Produktionsanlage als sehr heterogen
dar. Weder die Bediensystematik,
noch die Darstellung unterliegen einer
durchgängigen Systematik. Es existieren hintergundbeleuchtete LCD, TFT
Touchscreens, sowie konventionelle
LCD. Die Bedienung erfolgt über Folientasten, Hardkeys oder Touchscreen. Die Bedienung durch das Personal erfordert erhöhten Lern- und
Anpassungsaufwand.
Status Quo
Derzeit existiert ein MMI zur Steuerung
und Manipulation der Fülleinheit. Dieses
Interface basiert auf den konventionellen
MMI Authoring Werkzeugen. Die Architektur und das Interface Design sind
nicht an die unterschiedlichen Bedürfnisse der Nutzergruppen angepasst, die
Bedienung ist nicht an den Produktionsprozess abgestimmt.
3.0
Architektur
Der Gestaltung des Interfaces liegt
das Konzept zugrunde, eine Repräsentation des physikalisch existierenden
Systems darzustellen. Das Interface
sollte in allen Darstellungsebenen reale
Zusammenhänge widerspiegeln. Dies
bietet dem Nutzer eine einfache und
konsistente Orientierungshilfe. Dieses
Prinzip sollte auch bei der Navigation
zwischen den einzelnen Screens des
Interfaces Anwendung finden.
Zudem sollte das Interface dem Nutzer
kontinuierlich alle Systemmeldungen
visualisieren. Eine komplette Produktionslinie ist allerdings mit mehreren hundert Signalgebern ausgestattet, eine
entsprechend übersichtliche vollständige
Darstellung ist nicht realisierbar. Aus
diesem Grund wurde zur Visualisierung
der Ansatz der Substitution und Kondensierung verfolgt. Systemmeldungen
einer funktionalen Einheit sollten in der
nächst höhern Organisationseinheit zu
einer abstrahierten Systemmeldung zusammengefasst dargestellt sein. Dadurch wird gewährleistet, dass alle Meldungen eine graphische Repräsentation
erfahren und die Übersichtlichkeit trotzdem gewahrt ist.
Abb. 2: MMI Drucker für MHD
205
Abb. 4: Das Prinzip der substituierenden
Signaldarstellung
Um eine für den Nutzer plausible
Darstellungs- und Interaktionsform zu
entwickeln wurden darauf aufbauend
zahlreiche unterschiedliche konzeptionelle Ansätze entwickelt und prototypenhaft realisiert.
Als Gestaltungshilfe wurde von mathematischen Modellen der Selbstähnlichkeit und unendlichen Wiederholbarkeit
ausgegangen. Es wurde von Seiten der
Maschinenkonstruktion überlegt, die
Systemarchitektur zu überarbeiten. Man
hatte zu diesem Zeitpunkt die Möglichkeit, uneingeschränkt von bestehenden
Restriktionen, ein Interfacedesign Konzept zu gestalten. Aus diesem Grund
wurde auf sehr abstrakte Modelle zurückgegriffen.
Abb. 5: Darstellung selbstähnlicher Elemente
nach Mandelbrot
206
Abb. 6: Vereinfachtes Modell selbstähnlicher Elemente
Die ersten Ansätze basierten auf Darstellungsprinzipien, die auf einer homogenen Verteilung von Informationen
und Unterinformationen basieren.
Die Schwierigkeit der Umsetzung lag
darin, dass es sich bei dem vorliegenden technischen System um ein sehr
heterogenes Produkt handelt. Die einzelnen Systemmeldungen sind in ihrer
Menge und Verteilung zu funktionalen
Einheiten nicht gleichmäßig. So ließen
sich zunächst keine befriedigenden
Darstellungsformen realisieren.
3.1
Ansatz 1
In der ersten Phase wurde überlegt, Informationsmelder konzentrisch
um die übergeordente Informationseinheit zu gruppieren (Abb 7), welcher
wiederum Teil einer übergeordneten
Einheit ist.
Dieses Model, wie auch die daraus
entwickelten Varianten stellten sich als
nicht praktikabel heraus – die Menge
der Unterinformationen je Einheit war
zu unterschiedlich, eine geeignete
Darstellungsform lies sich nicht finden.
Die Darstellung der Informationen lies
sich nicht wie in Abbildung 7 entwickeln, es entstand ein sehr unübersichtliches Gesamtbild, welches die
Gesamtarchitektur negativ geprägt
hätte.
Abb. 7: Darstellungsvariante 1
3.2
Ansatz 2
In einer weiteren Iterationsstufe
wurde mehr Rücksicht auf die physikalische Struktur der Maschine genommen.
So wurde auch die Darstellungsform
weniger geometrisch und bot mehr Platz
für die entsprechenden Systemmelder.
Dabei stellte sich im Rahmen von Simulationen heraus, dass die Wahrnehmbarkeit der Systemmeldungen nicht ausreichend gewährleistet war (Abb 8). Das
Gesamtdesign wirkte auch hier zu verstreut und verhinderte eine klare Zuordnung der Systemmeldungen zu physikalischen Einheiten.
Abb. 8: Darstellungsvariante 2
3.3
Ansatz 3
Da die Wahrnehmbarkeit und Rückverfolgbarkeit individueller Fehlermeldungen zu den wichtigsten Funktionali-
täten gehören sollte, wurde das System
kompakter aufgebaut. Dabei half ein
mentales Modell aus der Architektur. Im
Rahmen des Projektes wurde es OpenDoor Prinzip genannt. In einigen Ausgestaltungen erinnerte es an den Grundriss von Gebäude- oder Raumplänen
(Abb 10).
Produktionsanlage, als in den zuvor
konzipierten Designs.
Die Übertragung idealisierter Modells
war nicht befriedigend möglich. Diese
Modelle waren nicht ausreichend in
der Lage, die tatsächliche Anforderung
der Übersichtlichkeit mit einer ergonomischen Bedienbarkeit zu kombinieren. Es musste entsprechend ein anderer Ansatz der Darstellung gewählt
werden.
Die Zieldefinition, dem Nutzer ein möglichst übersichtliches Interface zu präsentieren, führte schließlich dazu, dass
sich die Darstellung an der Geographie der Produktionsanlage anlehnt.
Der Ansatz einer physikalischen oder
geographischen Repräsentanz wird in
zahlreichen Interfacedesigns verfolgt.
Die Differenzierung zwischen dem
NEW HMI und den konventionellen
Formen besteht darin, dass man sich
hier auf sehr rudimentäre Gestaltungselemente beschränkte und die
Darstellung stark abstrahierte.
Abb. 9: Modell für die OpenDoor Idee
Der Nutzer gelangt zu den individuellen
Fehlermeldungen, indem er wie durch
Flure zu einzelnen Zimmern geht. Der
Weg zu dem Zimmer (Systemmeldung)
wird ihm optisch klar signalisiert.
Als Gestaltungselemente wurde auf
sehr wenige Charakteristika zurückgegriffen:
•
•
•
Abb. 10: Darstellungsvariante des OpenDoor
Prinzips mit farblicher Hervorhebung
4.0
Design
Das finale Design orientiert sich schließlich stärker an der realen Physik der
die Nähe von zusammengehörigen Funktionen
die zeitliche Abfolge von Arbeitsschritten
farbliche Kennzeichnung von Systemzustandsänderungen
Das gesamte Interface ist grundsätzlich monochrom gehalten. Bis auf
Temperaturwerte in der Skalendarstellung werden farblichen Hervorhebungen lediglich zur Visualisierung von
Warnungen genutzt. Dadurch bekommen kritische Systemveränderungen
die notwendige prominente Darstellung.
Das Interface ist zweigeteilt. Es existiert ein Navigationsbereich, der ständig alle Systemmeldungen substituiert
darstellt. Ergänzt wird dieser Bereich
durch den Interaktionsbereich, der dem
Nutzer den Zugriff auf die zu einem
funktionalen Bereich gehörenden Manipulatoren repräsentiert.
In den Bereichen sind die Funktionselemente so zueinander gruppiert, wie an
der realen Produktionslinie (Abb 11). Es
gibt hier einen zweireihigen Aufbau,
wobei die obere Reihe übergeordnete
Funktionen beinhaltet, welche sich auf
die gesamte Produktionslinie beziehen,
im unteren Bereich ist eine Zweiteilung
in die untergeordneten physikalisch getrennten Einheiten (Dornradteil und Kettenteil) vorgenommen.
Während aus Platzgründen in der Navigationsansicht alle funktionalen Einheiten eine identische Größe aufweisen,
unterliegt die Gestaltung im Manipulationsbereich einem anderen Prinzip (Abb
12).
Die Abfüllung an den Maschinen der
SIG Combibloc erfolgt parallel in mehreren Bahnen. Je nach Modell werden die
Verpackungen zwei- bis sechsbahnig
verarbeitet – analog erfolgt auch die
Darstellung im MMI. Weiterhin gibt es
funktionale Einheiten, die nicht an eine
einzelne Bahn gebunden sind. Diese
Funktionalitäten sind entsprechend
oberhalb der bahnbezogenen Melder
angeordnet. Ihre Größe richtet sich nach
dem Einflussbereich in der Produktion.
Aufgrund dieser gestalterischen Besonderheiten ist der Nutzer jederzeit in der
Lage unmittelbar zu sehen, wo, in welchem Kontext und mit welcher Dringlichkeit eine Fehlfunktion vorliegt.
Das Ergebnis ist eine Gestaltung, die
eine effektive Orientierung ermöglicht
redundante graphischen Elemente werden vermieden.
Die Größe der Elemente resultiert aus
der Bedienung per Touchscreen.
207
Abb. 11: Beispiel Navigationsansicht
Das Interface ermöglicht in seiner
Ausgestaltung ein Höchstmaß an Übersichtlichkeit, kombiniert mit einer schnellen und effektiven Bedienbarkeit.
Usabilityuntersuchungen im Vorfeld
zeigten zahlreiche Defizite konventioneller Schnittstellen. Ein signifikantes
Charakteristikum für die schlechte
Bedienbarkeit existierender Interfaces
ist die nur unzureichende Anpassung
des Designs an den realen Arbeitsprozess. Der Bildschirm ist häufig aufgrund standardisierter graphischer
Elemente mit Informationen überlastet,
die für den Nutzer nicht relevant oder
in ihrer Hierarchisierung falsch sortiert
sind. Hier war es möglich auf ein sehr
flexibles und modernes Werkzeug zur
Interfacedesign Entwicklung zurückzugreifen und somit neue effektive Lösungen zu generieren.
5.0
Abb. 12: Finales Design
4.1
Gründe für das finale Design
Ein leistungsstarkes Authoring
Werkzeug zur Entwicklung Maschinensteuerungen eröffnete die Chance, konventionelle Darstellungsformen zu hinterfragen und neue Konzepte zu verfolgen. Auf dieser Basis entstanden zahlreiche Designs, welche auf Relevanz
und Bedienbarkeit hin untersucht wurden.
Aufgrund des Gestaltungsspielraumes
von Seiten der Software, sowie der Offenheit der Firma SIG Combibloc war es
möglich, ein Interaktionskonzept zu entwickeln, welches sich deutlich von den
bekannten Designs im Bereich der Investitionsgüter abhebt.
208
Restriktionen bei der Designentwicklung
Obwohl das Entwicklungswerkzeug die Umsetzung vieler graphischer
und funktionaler Gestaltungselemente
unterstütze, waren zahlreiche Wünsche von Seiten des Designs und der
Usability noch nicht umsetzbar. Die
enge Zusammenarbeit mit dem Werkzeughersteller ermöglicht in Zukunft
allerdings mehr Spielraum.
6.0
Usability & Design
Das Design wurde auf Basis vorgeschalteter Usabilitytests entwickelt.
Die Designentwicklung fand iterativ
statt. Das Design ersetzte sukzessive
das bestehende Design an existierenden Maschinen. Aufgrund kontinuierlichen Feedbacks zwischen Nutzern,
Entwicklungsabteilung und Design
existierte ein sehr konstruktiver Entwicklungsprozess. Diese Faktoren
unterstützen die Entwicklung eines effektiv funktionierenden Interfaces.
Der Einsatz des Interfaces im realen
Produktionsumfeld zeigt ein hohes Maß
an Akzeptanz durch die Nutzer. Nicht
nur aufgrund der hohen Funktionalität,
sondern der Visualisierung.
Bisherige Interfaces in diesem Sektor
waren designtechnisch, wie ergonomisch nicht optimal auf den Anwender
abgestimmt. Das nun vorliegende MMI
funktioniert nicht nur effektiv, es zeigt
dies auch durch ein modernes und funktionales Design, was bei den Nutzern zu
einer sichtlich höheren Motivation führt,
das System zu erlernen und zu bedienen.
7.0
Holland, John (2000): Emergence: From
Chaos to Order, Oxford University Press
Miller, John H. (2007): Complex Adaptive
Systems: An Introduction to Computational
Models of Social Life, University Presses of
California
Stankowski, A.; Duschek, K (1994): Visuelle
Kommunikation. Reimer Verlag, Berlin
Shannon, C.E., Weaver, W. (1949): The
Mathematical Theory of Communication,
Urbana Ill.
Tufte, Edward R. (1994): Envisioning Information, Graphics Press USA
U n ternehme ns s t ra t e g i e
U ser-Centere d - D e s i g n
209
210
Interdisziplinär: User-Centered Design im Großunternehmen
Kostanija Petrovic
User Experience
SAP AG
69190 Walldorf
[email protected]
www.sap.com
Matthias Harbusch
User Experience
SAP AG
69190 Walldorf
[email protected]
www.sap.com
Carola Fellenz Thompson
User Experience
SAP Labs LLC
Palo Alto
United States CA
[email protected]
www.sap.com
Abstract
Die erfolgreiche Gestaltung nutzergerechter Produkte ist nur unter Beteiligung aller betroffenen Disziplinen möglich. Diese ist ihrerseits an bestimmte
Voraussetzungen geknüpft. Wir von
SAP verfolgen nun seit mehreren Jahren
den Ansatz, Methodenwissen breiten
Teilen der Organisation zur Verfügung
zu stellen. Dies geschieht durch das
Angebot von Methodentrainings, die
Publikation von Prozessdokumentation,
Tools und Vorlagen einerseits sowie
durch Projektarbeit andererseits. Wir
stellen in diesem Beitrag unsere Erfahrungen mit der Vermittlung von
1.0
Einleitung
User-Centered Design (UCD), oder
zu deutsch benutzerzentrierte Produktgestaltung, beschreibt den Prozess der
Erhebung und Definition von Benutzeranforderungen sowie deren Umsetzung
im Produkt. Für den Prozess finden sich
Beschreibungen bei verschiedenen Autoren, u. a. bei Hix und Hartson (1993)
oder Beyer und Holtzblatt (1998) um nur
wenige zu nennen, sowie in der DIN EN
ISO 13407 Benutzerzentrierte Gestaltung interaktiver Systeme (1999). Der
Prozess des UCD beinhaltet:
x
x
x
x
Methoden sowie ihrer erfolgreichen
Anwendung in Projekten vor. In der
Kommunikation des User-Centered
Design Prozesses (UCD) und dessen
Anwendung bedarf es der Nutzerzentrierung! Eine Botschaft, die keiner versteht, ist keine Botschaft. Sowohl die
Zusammenarbeit unterschiedlicher
Disziplinen als auch der gezielte Einsatz von User Experience Experten
sind notwendige Voraussetzungen
erfolgreicher Projekte.
Keywords
zer und deren Anforderungen, iteratives Vorgehen sowie die empirische
Überprüfung der Entwürfe seitens der
Benutzer.
Seitens der User Experience Abteilung
bei SAP wurde für SAP ein UserCentered Design Prozess definiert, der
die folgenden Phasen umfasst:
Wie Burmester et al. (2005) betonen,
bedeutet benutzerzentrierte Produktgestaltung mehr, als lediglich die Berücksichtigung von Belangen potentieller Benutzer, vielmehr ist die „direkte
Benutzerbeteiligung am Gestaltungsprozess von zentraler Bedeutung“.
Plan for UCD – Projektplanung unter
Berücksichtigung der erforderlichen
Ressourcen für UCD Aktivitäten.
Research – Erhebung von Nutzeranforderungen durch Felduntersuchungen
und Analyse bestehender Ergebnisse
aus vergangenen Projekten.
Design – Entwicklung von Use cases,
basierend auf den Ergebnissen der vorangegangenen Phase, Übersetzen der
Use cases in User Interfaces, beginnend
mit groben Entwürfen, die mit mehreren
Iterationen durch Endbenutzerfeedback
immer weiter verfeinert werden.
Analyse von Anforderungen, Aufgaben- und Zielbeschreibung aus Benutzersicht
Definition von Benutzeranforderungen
Konzeption und Entwurf
Evaluation
Prinzipien des User-Centered Designs
sind die frühe Fokussierung auf Benut-
User-Centered Design, Methodentraining, Interdisziplinarität, Business Software
Adapt – Anpassen der UI Designs an
die Möglichkeiten der technischen Umsetzung.
Abb. 1: User-Centered Design bei SAP
211
Measure – Summativer Test der Software – Überprüfung, ob das Produkt die
erhobenen Anforderungen erfüllt.
1.1
Interdisziplinarität – Bereicherung
oder Hindernis?
Wie bereits Seffah und Metzker
(2004) in ihrem Beitrag zur Integration
des Usability Engineerings in das Software Engineering herausgestellt haben,
gilt es bei der erfolgreichen Integration
von benutzerorientierten Produktentwicklungsmethoden in einen Produktlebenszyklus einige Hürden zu überwinden, welche nicht zwingend technischer
Natur sind.
Neben den organisatorischen Herausforderungen spielt vor allem die Kommunikation und Zusammenarbeit zwischen den Disziplinen eine große Rolle.
Ein Grundverständnis für die jeweils
andere Disziplin muss auf beiden Seiten
vorhanden sein. Da zumeist die Ausbildung von Entwicklern technisch orientiert ist, während Ausbildungen im Bereich User Experience eher im gestalterischen oder arbeitspsychologischen
Umfeld stattfinden, entstehen Kommunikationshürden.
In der Praxis scheitert die Kommunikation oftmals bereits an recht populären
Konzepten, wie beispielsweise Use cases – was ist ein Use case, was ein
Szenario? Ein Use case nach dem Ansatz von Cockburn (2001) deckt sich
nicht zwingend mit einem Use case auf
Ebene eines Business Szenarios. Ein
Use case im Cockburn-Format beschreibt eine Abfolge von Interaktionsschritten aus Benutzersicht, ein Business Szenario hingegen beschreibt den
Ablauf eines Geschäftsprozesses. Trotzdem wird für letzteres oftmals ebenfalls
der Begriff Use case verwendet.
Wie also stellt man sicher, dass man,
wenn man vom Gleichen spricht, auch
das Gleiche meint? In dem man grundlegende Konzepte der Methoden des
212
User-Centered Design im Rahmen von
Trainings vermittelt.
Wenn innerhalb einer Disziplin Meinungsverschiedenheiten über Namen
und Konzepte bestehen – und das ist
bei dem Thema UCD mit Sicherheit
der Fall – stellt dies besondere Anforderungen an die Kommunikation.
Ein standardisierter Prozess, wie er
bei der SAP AG angewendet wird, hilft
dabei, die Begrifflichkeiten zu vereinheitlichen und reduziert dadurch das
„Rauschen“.
Darüber hinaus muss der Mehrwert,
welcher durch den Einsatz von UCDMethoden im Produkt entsteht, überzeugend vermittelt werden. Wenn dieser Zugewinn an Produktqualität erfolgreich kommuniziert wird und die
Methoden des UCD fester und allseits
akzeptierter Bestandteil des Requirements Engineering und des Entwicklungsprozesses sind, ergibt sich daraus eine verbesserte Zusammenarbeit
der verschiedenen Disziplinen. So
können die Beteiligten ihr gemeinsames Ziel erreichen: qualitativ hochwertige Software zu erstellen, die gerne
von den Benutzern verwendet wird
und diese optimal bei ihrer Arbeit
unterstützt.
1.2
Möglichkeiten und Grenzen von
Trainings
Im ersten Teil unseres Beitrags
gehen wir näher auf die Erfahrungen
aus zwei Jahren Methodentraining für
fachfremde Zielgruppen, konkret Produktmanager und Entwickler, ein.
Hier hat sich gezeigt, dass zwar einige
Schwierigkeiten bei der Methodenvermittlung auf kommunikativen Hürden basieren, die es zu überwinden
gilt, andere jedoch darauf schließen
lassen, dass bestimmte Aufgaben im
UCD Prozess nur durch Experten ausgeführt werden sollten. Denn nur die
Experten verfügen über die notwendigen
Kenntnisse und Erfahrungen, um die
standardisierten Methoden effizient einzusetzen und somit zur erfolgreichen
Projektdurchführung beizutragen.
1.3
Erfolgreich mit UCD - Entdecke
die Möglichkeiten!
Im zweiten Teil unseres Beitrags
stellen wir Erfahrungen aus erfolgreichen Projekten vor. Wir berichten über
hilfreiche (Kommunikations-)Strategien
sowie Projektmanagementanforderungen. Hier hat sich gezeigt, dass das
Prinzip der Nutzerperspektive in vielerlei
Hinsicht Anwendung findet.
2.0
Teaching UCD – Ein Erfahrungsbericht
Im Zuge der organisatorischen Zusammenlegung verschiedener User Interface Design Bereiche, die erstmals
vor wenigen Jahre erfolgte, entstand
eine erste Version von Methodentraininings. Die organisationsweit angebotenen Kurse deckten folgende Themen ab:
1.
2.
3.
Understanding Users – Durchführung von Site Visits.
Use Cases – Erstellung von Use
cases
Formative Usability Evaluation –
standardisierte Durchführung von
formativen Evaluationen.
Der Beitrag konzentriert sich auf die
Erfahrungen aus den ersten beiden Trainings.
2.1
Understanding Users
Ziel des eintägigen „Understanding
Users“ Trainings war es, Grundlagen der
Durchführung von Feldstudien mit Endbenutzern, sogenannter „Site Visits“, zu
vermitteln.
Hierbei wurden thematisch von der Definition des Zielnutzerprofils bis zur Fragebogenerstellung und Interviewdurchführung Grundlagen abgehandelt sowie in
praktischen Einheiten eingeübt. In einer
weiteren Version des Trainings wurde
an einem einfachen Beispiel eine Aufgabenanalyse anhand von im Training
erhobener Daten durchgeführt.
Der Erfolg des Kurses bestand, neben
der Grundlagenvermittlung, in erster
Linie darin, den Kollegen eine Möglichkeit zum Perspektivwechsel zu geben,
einen ungewohnten Blick auf den Menschen vor der Maschine statt auf Systemfunktionalität zu werfen.
Die Rückmeldung aus den Kursen zeigt,
dass die Idee der benutzerzentrierten
Produktgestaltung auch für Fachfremde
von Interesse und ein solcher Ansatz
wünschenswert ist.
Es zeigte sich aber auch, dass organisatorische Änderungen und das Engagement von übergeordneten Managementebenen notwendig sind, um den
Prozess tatsächlich zu leben.
setzung des Prozesses in Projekten
von der Anwesenheit eines UCDExperten mit geeigneter methodischer
Ausbildung (bspw. Psychologie) abhängig ist, da insbesondere die Auswertung der gesammelten Daten nur
von solchen effizient durchgeführt werden kann.
Des Weiteren ist eine kontextgerechte
Wissensvermittlung notwendig; die
Methoden müssen im Projektzusammenhang dargestellt werden und gemeinsam mit Grundlagen des Projektmanagements vermittelt werden.
Als Konsequenz wurde von der Erstautorin ein neues Training entwickelt,
das die Methodenvermittlung eng an
die Projektplanung und -durchführung
knüpft und Beispiele zur Aufwandsschätzung und Aufgabenverteilung
gibt.
2.2
Einige der Trainingsteilnehmer zeigten
sich überrascht vom Trainingsinhalt.
Waren sie hier nicht in einem Training,
bei dem es um User Interfaces ging?
Erstaunlicherweise kam kein einziger
Bildschirminhalt im ganzen Kurs vor.
Und Nutzerbedürfnisse? Stellte man hier
nicht Standardsoftware her, deren Ziel
es niemals sein konnte, individuelle Bedürfnisse und Vorlieben zu befriedigen.
Aufgabenziele? Was hatte das mit dem
Businessprozess zu tun, den doch die
ganze Funktionalität abbilden sollte?
Und was war jetzt eigentlich genau eine
Aufgabe? Was hatte das jetzt alles mit
Dialoggestaltung („Screendesign“) zu
tun?
Als Reaktion auf das Feedback aus den
Kursen wurde ein eigener Überblickskurs geschaffen, der UCD direkt in den
Kontext der Anforderungsdefinition stellt.
Selbst wenn Grundlagen des UCD erfolgreich vermittelt wurden, zeigt die
Erfahrung, dass eine erfolgreiche Um-
Use cases
Eines der Schlüsseldokumente im
UCD Prozess ist die Erstellung von
Use cases im Cockburn-Format
(2001).
In einem eintägigen Training wurden
Grundlagen der Use case-Erstellung
im Textformat vermittelt. Diese Grundlagen umfassten die Benennung von
Nutzern, die Identifikation von Nutzerzielen sowie die Erstellung von einfachen Use cases.
Im Fokus stand dabei die Erstellung
von Use cases auf Nutzerziel-Ebene.
Dieses Vorgehen setzt voraus, dass
bei der tatsächlichen Projektdurchführung ebendiese Nutzerziele auch erhoben wurden.
Gerade bei den ersten zu schreibenden Use cases herrscht große Verunsicherung darüber, wie genau diese
definiert sein müssen. Was ist die richtige Granularität? Woher weiß ich, wie
die Use cases miteinander zusammenhängen?
Eine Projektbegleitung durch User Experience Experten hilft, Verunsicherung zu
reduzieren und effizient erste Use cases
zu erstellen.
3.0
User-Centered Design meets
Reality
Es reicht nicht, einen guten Ansatz
zu verfolgen, den Wenige kennen bzw.
verstehen.
Die Frage, die man sich und seinen Kollegen zunächst stellen muss, ist: Wann
ist ein Produkt erfolgreich am Markt? Die
Antwort scheint auf der Hand zu liegen:
Das Produkt trifft die Bedürfnisse der
Kunden, denn es ist attraktiv und benutzbar.
Doch wie erreicht man diese Eigenschaften eines Produkts – wie sieht der
zugehörige Produktentwicklungsprozess
aus? Nach eingehender Marktanalyse,
Ideensammlung und Kundeninterviews
wird zu einem bestimmten Zeitpunkt das
Produkt definiert (Produktdefinition).
Handelt es sich bei dem Produkt um
Software, arbeiten hier Produktmanager,
Entwickler und im besten Falle auch
User Interface Designer zusammen.
Jeder der Beteiligten verfügt über eigene
Vorstellungen davon, wie der ideale
Produktentwicklungsprozess auszusehen hat, was mittelfristig den Kommunikationsbedarf, wie oben dargestellt, erheblich steigert.
Aus Sicht der User Experience Kollegen,
bedeutet das oft Aufklärungsarbeit an
vorderster Front, im englischen Sprachgebrauch auch gerne als „Evangelisieren“ bezeichnet.
Basierend auf Erfahrungen aus zahlreichen Projekten wird aufgezeigt, dass
Überzeugen durch „Predigen“ nicht der
Schlüssel zum Erfolg ist. Vielmehr gilt es
213
auch hier, die Sprache seiner Nutzer zu
sprechen und Lösungen anzubieten, die
auf die Bedürfnisse, Fähigkeiten und
Kenntnisse der Benutzer eingehen. Also
in diesem Falle von Produktmanagern,
Entwicklern und Entwicklungsarchitekten, die alle „UCD-Prozess-Benutzer“
sind.
Der Schlüssel ist, das gemeinsame Ziel
in den Vordergrund zu stellen. Das Ziel
von UCD ist, ein besseres Produkt zu
schaffen und nicht, noch mehr Projektdokumente auszufüllen. UCD dient zur
besseren „Ziel-“ also Produktdefinition
und führt so zu neuen, besseren Produkten, die sich folglich besser verkaufen lassen.
Jetzt wurden die erhobenen Daten
noch nicht ausgewertet – pro Interviewstunde kann man mit einem vielfachen an Auswertungsaufwand rechnen. Einem Tag Durchführung stehen
drei bis vier Tage Auswertung gegenüber, und das gilt für das gesamte
Projektteam. Hier zeigt sich bereits
eine der ersten Herausforderungen –
ein solcher Aufwand muss sich am
Ende auch rechnen. Denn tatsächlich
sind, je nach Projektumfang, mehrmonatige Erhebungs-aktivitäten in der
Produktdefinitionsphase nötig, um alle
erforderlichen Prozesse zu untersuchen.
3.2
3.1
UCD und Projektmanagement
Die Durchführung eines konkreten
UCD-Projekts beginnt bereits vor dem
eigentlichen Projekt mit dessen Planung.
Schon hier müssen die Kolleginnen aus
den Bereichen Entwicklung und Produktmanagement konkret unterstützt
werden, um die wichtigen Schritte des
UCD umsetzen zu können.
Wie sieht das im Einzelnen aus? Für
eine erfolgreiche UCD-Planung müssen
realistische Aufwandschätzungen zur
Verfügung gestellt werden – bspw.
Manntage für die Durchführung und
Auswertung eines Nutzerinterviews im
Arbeitskontext. Zusätzlich muss der Gesamtbedarf an solchen Aktivitäten für
das Projekt geschätzt werden.
Ein konkretes Beispiel: Für die Durchführung von zwei aufeinanderfolgenden
Nutzerinterviews an einem Arbeitsplatz
braucht man zwei Projektmitarbeiter und
einen Tag – entsprechend zwei Manntage. In der Regel werden jedoch jeweils
zwei Interviews parallel durchgeführt –
also vier Interviews insgesamt – in
Summe vier Manntage usw.
214
UCD und Kommunikation
Aus einer solchen Konstellation
ergibt sich eine besondere Anforderung an die Kommunikation innerhalb
des Projektteams. Wichtig ist es hier
immer wieder das Ziel, nämlich ein
benutzerfreundliches Produkt zu
schaffen, in den Fokus zu rücken.
Zunächst muss ein gemeinsames Verständnis vom „Problemraum“ geschaffen werden. Als hilfreiches Instrument
erweist sich die offene, nicht-direktive
Fragetechnik. Diese kann in Projektgruppentreffen angewendet werden,
um alle notwendigen Informationen
über das Projekt zu erhalten. Oftmals
gehen die Projektbeteiligten von Annahmen aus, ohne diese zu konkretisieren und mit Teamkollegen auszutauschen.
Dabei handelt es sich um eine ähnliche Vorgehensweise, wie im Nutzerinterview, nur mit einer anderen Zielsetzung. Die Frage lautet: „Wie siehst Du
das?“ Nur durch Offenheit gegenüber
anderen Perspektiven ist es möglich,
eine gemeinsame Problemlösung zu
finden. Konkret bedeutet das, erst eine
gemeinsame Sicht auf die Projektsituation zu erarbeiten.
Im nächsten Schritt können die Vorteile
des UCD-Prozesses aufgezeigt werden.
Ein Aufzeigen bedeutet, dass ohne Belehrung anhand gemeinsamer Ziele ein
Vorgehen herausgearbeitet wird, das im
Interesse aller Beteiligten ist.
Durch einen solchen partizipativen Ansatz sind alle Projektbeteiligten „Inhaber“
der Lösung, die Ihnen nicht durch einen
„predigenden“ Experten diktiert wird.
Nachdem eine Einigung über die Ziele
und die weitere Vorgehensweise erreicht
wurde, können die ersten Schritte im
UCD-Prozess durchgeführt werden. Die
sind erfahrungsgemäß oft ein wenig
holprig, doch je weiter das Projekt fortschreitet, umso eingespielter ist das
Team und umso besser funktioniert der
Prozess.
4.0
Literatur
Beyer, H.; Holtzblatt, K. (1998): Contextual
Design – Defining Customer-Centered Systems. San Francisco: Morgan Kaufmann
Publishers.
Burmester, M.; Machate, J.; Sandweg, N.
(2005): Integration benutzerzentrierter Methoden in die Software-Entwicklung. In: i-com,
Zeitschrift für interaktive und kooperative
Medien. 3/2005. München: Oldenbourg.
Cockburn, A. (2001): Writing Effective Use
Cases, Boston: Addison Wesley.
DIN EN ISO 13407 (1999): Benutzerorientierte Gestaltung interaktiver Systeme, Berlin:
Beuth Verlag.
Hix, D.; Hartson, H. R. (1993): Developing
User Interfaces: ensuring usability through
product and process. New York: Wiley.
Seffah, A.; Metzker, E. (2004): The Obstacles
and Myths of Usability and Software Engineering. In: Proceedings of the ACM, 47, 12.
Human-Centered Design als Unternehmensstrategie:
Ein Arbeitsbericht
Clemens Lutsch
Microsoft Deutschland GmbH
DPE
Konrad-Zuse Str. 1
85716 Unterschleißheim
[email protected]
www.microsoft.com
Kostanija Petrovic
User Experience
SAP AG
69190 Walldorf
[email protected]
www.sap.com
Abstract
Die Einführung von Human-Centered
Design Prozessen nach ISO 13407
hängt von vielen Einflussgrößen ab, die
für Unternehmen schwer einzuschätzen
sind. Der Erfolg eines solchen HCDProzesses ist aber entscheidend mit der
Frage verbunden, ob das Management
die Ziele des HCD teilt und diese als
unternehmerische Zielgrößen (Key Performance Indicators – KPI) formuliert
hat. Doch selbst wenn die Formulierung
der KPI Kriterien wie Usability
1.0
Einleitung
Obwohl der Begriff User-Centered
Design (UCD) nun bereits seit 1985
(Gould & Lewis) die Entwicklung von
gebrauchstauglichen Systemen beschreibt, nicht nur innerhalb der Expertengemeinschaft Übereinkunft darüber
besteht, das Gebrauchstauglichkeit
(engl. Usability) durch UCD erreicht wird
(bspw. Karat 1997) und der Prozess
unter dem Namen Human-Centered
Design (HCD) durch die 13407 (1999)
Eingang in den internationalen Standard
gefunden hat, ergeben sich bei der tatsächlichen Prozessein- und -durchführung in vielen Bereichen nach wie vor
Herausforderungen, die es zu meistern
gilt.
Sowohl die Einführung als auch die Anwendung eines HCD-Prozesses leiden
unter mehreren Schwachpunkten, für die
keine einfachen Lösungen greifbar sind.
Bei der Beratung von Unternehmen, die
interaktive Lösungen produzieren, wurde
(die durch den HCD Prozess erreicht
werden soll) benennt, so bleibt weiterhin deren Umsetzung und Interpretation abhängig von verschiedenen Faktoren, wie bspw. Verfügbarkeit von qualifiziertem Personal, Integration von
HCD in den Entwicklungsprozess usw.
In diesem Beitrag werden die verschiedenen Bereiche basierend auf
aktuellen Erfahrungen diskutiert und
Implikationen für die erfolgreiche Umsetzung des HCD erörtert.
Keywords
daher oft festgestellt, dass ein HCD
Prozess nicht in ausreichender Konsequenz eingeführt wurde und/oder
eine leblose Hülle darstellt. Die Folge
ist eine weitgehende Frustration der
Beteiligten bis hin zur offenen Distanzierung des Managements zum Thema HCD. Hier sollen die Ursachen
dieses Zustandes beleuchtet und Wege erschlossen werden, wie HCD als
werthaltige Bereicherung der (Software-)Produktentwicklung anwendbar
ist.
und die User Experience (wie wird das
Produkt von Nutzer erlebt?). Um diesem
Druck zu begegnen, sind die Anbieter
bestrebt, der Idee des HCD folgend
User Experience im Entwicklungsprozess zu adressieren.
2.0
Die Situation
Anbieter interaktiver Lösungen
sind einem starken Wettbewerb ausgesetzt. In der Wahrnehmung des
Marktes geht es allerdings nicht mehr
alleine um die technologische und
funktionale Leistungsfähigkeit der Lösung, sondern auch immer mehr um
die Gebrauchstauglichkeit (unterstützt
das Produkt einen bestimmten Nutzer
im festgelegten Nutzungskontext?)
HCD, User Experience, Management,
KPI, ISO 13407, Unternehmensstrategie.
2.1
Problemfeld Personal
Der HCD Prozess verlangt nach
qualifiziertem Personal. Es wurde beobachtet, dass oft im Unternehmen geeignetes Personal vorhanden ist aber
die organisationale Zuordnung die
„Schlagkraft“ dieser Experten vermindert. Ein weiterer beobachteter Fall ist,
dass kein geeignetes Personal vorhanden ist. Die Beschaffung von geeignetem Personal zieht einigen Aufwand
nach sich: Es müssen neue Stellen geschaffen werden, die das gesuchte Profil
besitzen. Die Schaffung von neuen Stellen ist ihrerseits mit folgenden organisatorischen Determinanten versehen: Gibt
es Ressourcen für diese neue Stellen?
Wem werden sie zugeordnet? Wer ist in
215
der Lage zu erkennen, ob die Bewerber
zur Stelle passen? Über das Thema „Zuordnung von Personalressourcen“ werden unternehmerische Verantwortlichkeiten berührt und das Thema HCD wird
in einer Art und Weise politisiert, die den
Einfluss des jeweils Verantwortlichen in
den Vordergrund stellt – zu Ungunsten
der eigentlichen, inhaltlichen Prozessaufgabe: der Entwicklung eines besseren Produkts.
2.2
Problemfeld Dokumentation
Die Etablierung des HCD als Bereicherung des gängigen Entwicklungsprozesses gelingt nur, wenn er an definierten Punkten mit diesem verwachsen
kann. So wurde bei der SAP AG bspw.
der UCD-Prozess in den Software Engineering Prozess integriert (Petrovic &
Weissenberger, 2008). Hier sind Use
cases die Schlüsseldokumentation, die
eine Einpassung von Nutzeranforderungen in den Produktentwicklungsprozess
ermöglicht. Use cases, verfasst auf Nutzerzielebene (Cockburn, 2001) repräsentieren gesammelte Nutzeranforderungen. Voraussetzung für eine solche
Integration des HCD in den Entwicklungsprozess ist die Standardisierung
des letzteren. Oft sind aber die etablierten Entwicklungsprozesse weder definiert noch standardisiert. So hängt im
schlimmsten Fall der HCD Prozess in
der Luft. Wird er dann dennoch ausdefiniert, erscheint er als abgehobenes
Konstrukt: ein Konzept aus dem Elfenbeinturm, das mit dem realen Leben
wenig Berührung hat und die Nöte des
betroffenen Unternehmens nicht wirklich
konstruktiv lösen kann. Der HCD Prozess landet in der Ablage, versehen mit
den bedauernden Worten: „Tja, er wäre
toll gewesen, aber das kann man ja leider nicht umsetzen“.
2.3
Problemfeld Ergebnisse
Wenn der HCD Prozess von
„Documents“ spricht, also von Ergebnissen, die im Prozessgefüge von Dritten weiterverwertet werden sollen und
können, so ist es leider oftmals nicht
klar, wie genau diese Dokumente aussehen sollen. Hier findet jedes Unternehmen seine eigene Lösung. Vergleicht man bspw. UI Konzepte verschiedener Firmen so findet man kaum
Dokumente, die sich gleichen. Dies gilt
auch für UI Spezifikationen oder die
Beschreibungen von Nutzeranforderungen. Hier gab und gibt es Bestrebungen der internationalen Normung,
mit dem Common Industry Format
(CIF - ISO/IEC 25062:2006) Abhilfe zu
schaffen. Ob und auf welche Weise
dies gelingt und in wieweit sich hier
CIF in der Industrie etablieren kann,
muss sich in den nächsten Jahren
klären.
2.4
Problemfeld Evidenz
Die häufigsten Fragen zum Thema
HCD werden zur Bewertung der erreichten Qualität gestellt. Hiermit ist
nicht die ergonomische Qualität der
Lösung gemeint, sondern die ProzessQualität, der Mehrwert für die Zusammenarbeit und die Effizienzsteigerung
für den Entwicklungsprozess. Gestandenen Prozessplanern in Unternehmen sind Key Performance Indikatoren
(KPIs) zum Thema HCD häufig fremd
und die Norm ISO 13407 schweigt
hierzu.
Wird HCD eingeführt, muss der Berater also auch Wege aufzeigen, wie
Evidenz des Mehrwertes (und damit
der Return on Investment – ROI) festzustellen ist.
2.5
Problemfeld Anforderungen
Das Requirements Engineering bezeichnet die Erhebung und Dokumentation von Anforderungen.
Laut IEEE 610.12 – 1990 ist eine Anforderung:
x
Die Beschaffenheit oder Fähigkeit
eines Systems, die von einem Benutzer zur Lösung eines Problems
oder zur Erreichung eines Ziels benötigt wird.
x
Die Beschaffenheit oder Fähigkeit,
die ein System oder Systemteile erfüllen oder besitzen muss, um einen
Vertrag, eine Norm, eine Spezifikation oder andere formell vorgegebene Dokumente zu erfüllen.
Softwarequalität wird unter anderem in
der ISO/IEC 9126 beschrieben. Hauptqualitätsmerkmale sind Funktionalität,
Zuverlässigkeit, Gebrauchstauglichkeit,
Effizienz, Änderbarkeit und Übertragbarkeit.
Gebrauchstauglichkeit (engl. Usability;
dt. auch: Benutzbarkeit) bezeichnet laut
ISO 9241-110 (2006), die Eignung eines
Produktes bei der Nutzung durch bestimmte Benutzer in einem bestimmten
Benutzungskontext, die vorgegebenen
Ziele effektiv, effizient und zufriedenstellend zu erreichen. Es bedarf also der
Berücksichtigung des Endbenutzers im
tatsächlichen Nutzungskontext, um das
Qualitätsmerkmal Benutzbarkeit zu
erfüllen.
Bei der Feststellung dieses Qualitätsmerkmals ist die fehlende Einheitlichkeit
der Definitionen von Gebrauchstauglichkeit innerhalb der verschiedenen Normen eine weitere Hürde bei der Umsetzung im Produkt (Seffah & Metzker,
2004).
Bereits die oben genannte Unterscheidung zwischen der Benutzer- und der
Systemperspektive verdeutlicht, dass
beim Requirements Engineering im her-
216
kömmlichen Sinne zwar vom Nutzer und
dessen Bedürfnissen die Rede ist, jedoch der Bogen von Nutzerbedürfnissen
zu Systemanforderungen leider noch zu
selten geschlagen wird. Ähnlich verhält
es sich in einschlägiger Literatur (bspw.
Ebert, 2005), wenn von Stakeholdern,
also Interessenvertretern oder auch Anspruchsberechtigten, die Rede ist – selten findet sich der Endbenutzer in dieser
Auflistung, obwohl mittels Methoden der
benutzerzentrierten Produktgestaltung
eine gute Benutzbarkeit definiert und im
Endprodukt sichergestellt werden kann.
Nutzeranforderungen (User Requirements) sind ein essentieller Bestandteil
des HCD. Wird der Prozess eingeführt,
sind Unternehmen mit der Tatsache
konfrontiert, diese Anforderungen zu
erheben oder erheben zu lassen. Dies
geschieht mittels User Research und
bedeutet eine ggf. umfangreiche Allokation von Ressourcen, die zu den Aufwendungen für die Prozesseinführung
hinzukommen. Auch sind diese keine
einmaligen Kosten, denn User Research
beschränkt sich nur selten auf eine Momentaufnahme. Nachhaltige Produktentwicklung über mehrere Produktgenerationen hinweg bedarf gepflegter User
Requirements. Das bedeutet, dass stattfindende Aktivitäten angemessen dokumentiert werden müssen. Auf der anderen Seite hingegen sinkt der Aufwand,
wenn Prozesse etabliert und Ergebnisse
angemessen dokumentiert sind – Wissen wird über Projektgrenzen hinaus
verfügbar gemacht und der Einsatz zahlt
sich in mehrfacher Hinsicht aus.
2.6
Requirements-Management
Die Einführung eines HCD Prozesses wird umso erfolgreicher, wenn dieser Prozess an ein bestehendes Requirements-Management angebunden werden kann. Fehlt dieses oder ist es nur
unzureichend implementiert (falsches
Tooling, keine Verantwortlichkeiten,
dezentrale Verwaltung), ist die Berück-
sichtigung der Requirements-Typen
eines HCD Prozesses sehr schwer.
Die folgende Abbildung 1 benennt
einige dieser Requirements-Typen, die
sich inhaltlich auch überlappen können.
Abb1: Requirements-Typen des HCD Prozesses
Ein gewichtiger Teil des Requirements-Managements im Rahmen des
HCD Prozesses ist die Hoheit über
Priorisierung und Gewichtung der Requirements aus den oben genannten
Typen. Priorisierung (wie wichtig ist
diese Anforderung für die Zielerreichung) und Gewichtung (wie aufwändig ist die Bereitstellung / Entwicklung)
bilden die Basis der Verhandlung der
Auseinandersetzung mit anderen Beteiligten (z.B. Marketing, Entwicklung,
Projektmanagement), die dann zu
einer konzertierten Kompromissbildung führen soll, die auch im Sinne
der Nutzer ist – also zur besten möglichen Lösung unter den gegebenen
Umständen.
2.7
Ein Beispiel: Eine bestehende eCommerce-Lösung für Musik wird hinsichtlich
der Transaktionsrate (Verhältnis von
Usern zu tatsächlichen Käufern), Abbruchrate (also User, die einen Einkauf
abbrechen), Verweildauern und Umsatzsteigerungen nach Werbekampagnen analysiert. Diese Basiswerte sollen
durch eine neue Lösung die gemäß
HCD konzipiert und hergestellt wird,
verbessert werden. Um dies nachzuweisen, werden nach Einführung der neuen
Lösung die gleichen Kennwerte analysiert.
Kennt man diese Basiswerte nicht, kann
man keine Evidenz für HCD belegen.
Das bedeutet auch, dass der ROI nicht
belegbar ist und für zukünftige Projekte
keine Referenzzahlen für den einzusetzenden Aufwand zur Verfügung stehen.
In vielen Unternehmen gibt es zwar diese Zahlen, jedoch bergen sie eine gewisse Brisanz, so dass sie selbst Managern oft nicht bekannt sind.
2.8
Ein erfolgreicher HCD Prozess
kommt nicht ohne Unterstützung des
Managements aus. Dazu zählen:
x
Empowerment: Die Verantwortlichen des HCD Prozesses müssen
in der Lage sein, die Mitwirkung am
Prozess einzufordern. Ähnlich wie in
vergleichbaren Qualitätsprozessen
ist der Prozessbesitzer weisungsbefugt gegenüber Dritten, insofern
diese essentielle Aktoren im Prozessgefüge sind und Dokumente /
Deliverables liefern.
x
Ziele: Das Management sollte in der
Lage sein, Zielvorstellungen zu formulieren, die eine Begründung für
die Einführung des HCD Prozesses
und die daraus erhofften Mehrwerte,
Verbesserungen und/oder Innovationen beinhalten. Diese Rahmenbedingungen bestimmen die Ausprä-
Evidenzbasierte Planung und
Kontrolle
Um den Mehrwert von HCD festzustellen und auch um Kostenplanungen und –aufwände besser erarbeiten
zu können, sollte eine Bestandsanalyse erfolgen, welche eine aktuelle Leistungsfähigkeit bestehender Systeme in
Bezug auf Gebrauchstauglichkeit und
Wirtschaftlichkeit feststellt.
Einbindung des Managements
217
sich eine „grüne Scorecard“, also
eine zufriedenstellendere Erreichung der persönlichen Ziele sowohl der Mitarbeiter, wie auch des
Managements.
gung des HCD Prozesses im Unternehmen.
x
Key Performance Indicators: Das
Management ist aufgefordert, Kriterien zu definieren, die Aussagen
darüber erlauben, ob und wie ein
Ziel erreicht worden ist. Diese KPIs
müssen in den Kernbereichen des
Prozesses verwurzelt sein, also bei
der Kompetenz der Verantwortlichen und Beteiligten, den eingesetzten Ressourcen, den erzeugten Deliverables und Dokumenten, dem
erzielten Ergebnis und der Evidenz
für HCD.
Ein KPI sollte dem SMART Modell
folgen (Hersey, Blanchard & Johnson, 2007): Er muss spezifisch (klar
beschrieben), messbar, angemessen (er muss erreichbar sein), relevant (er muss sich auf die Evidenz
auszahlen) und terminiert sein (mit
einem zeitlichen Bezugsrahmen
verstehen).
2.9
HCD als Unternehmensstrategie
Wie bei so vielen unternehmensweiten Themen steht und fällt der Erfolg eines Prozesses mit der strategischen Bedeutung, die ihm zugemessen wird. Das Thema HCD ist ein
komplexes Gefüge, welches verschiedene Unternehmensbereiche und
-prozesse berührt sowie verändert.
Entsprechend groß sind die Auswirkungen auf die gesamte Unternehmenskultur, wenn der Prozess tatsächlich etabliert ist: von der Anforderungsanalyse und -definition über erste Versionen von Schnittstellen (sowohl Nutzer- als auch Systemschnittstellen),
deren Evaluation, Sammlung weiterer
Anforderungen, Anpassung und Weiterentwicklung von bestehenden
Technologien bis hin zum interaktiven
Austausch mit Kunden. Hier bekommt
Kundenorientierung eine zusätzliche,
tiefere Dimension.
Insbesondere in Zeiten, in denen
Unternehmen ihre Endkunden als
Innovationsmotor entdeckt haben,
bedeutet der Verzicht auf das Thema
HCD in der Unternehmensstrategie
einen Verzicht auf Innovation.
Abb.2: Ziele und KPIs im Wirkungsgefüge
x
Transparenz der KPIs: Die Indikatoren des HCD Prozesses werden von
„unten nach oben“ durchgereicht.
Das bedeutet, dass die Ziele und
KPIs des Managements mit denen
der untergeordneten Mitarbeiter deckungsgleich sind und der Erfolg des
HCD Prozesses im Zentrum der
Aufmerksamkeit des Managements
bleibt. Wird also der Prozess angewendet und führt dieser zu nachweisbaren Verbesserungen, ergibt
218
3.0
Zusammenfassung
Es fällt leicht, die zähe Verbreitung
von HCD Prozessen bei Herstellern
interaktiver Systeme auf eine augenscheinlich schwer lesbare Norm und
mangelnde Ressourcen zu schieben.
Aber dies ist nur die halbe Wahrheit:
Solange das Management nicht integrativer Bestandteil des Prozesses
und somit zum aktiven „Kümmerer“
wird, kommt HCD nicht wirklich im
täglichen Leben an. Eckpunkte für die
Beteiligung des Managements gibt es,
wie gezeigt, zur Genüge: Requirements,
Ziele, KPIs, ROI und Evidenz.
Wenn es jedoch auch schon an einem
Bewusstsein mangelt, dass diese Faktoren überhaupt eine Relevanz haben, so
müssen Anstrengungen zum HCD ins
Leere laufen. Daraus ergibt sich als
zwingender Schluss die Erhebung des
HCD Prozesses zur Unternehmensstrategie, da durch ihn eine Strahlwirkung
auf das gesamte Ressourcenmanagement und auf evidenzbasierte Projektplanung entwickelt werden kann. Unternehmensstrategie bedeutet verbindliches Engagement des Managements
und beinhaltet auch das Überlassen von
Entscheidungskompetenz, Ressourcenhoheit und Weisungshoheit an die Prozessverantwortlichen.
4.0
Cockburn, A. (2001): Writing Effective Use
Cases. Boston: Addison Wesley.
DIN EN ISO 13407: Benutzerorientierte Gestaltung interaktiver Systeme, Berlin: Beuth
Verlag, 1999.
Ebert, C. (2005): Systematisches Requirements Management, Heidelberg:
dpunkt.verlag.
Gould, J. D.; Lewis, C. (1985): Designing for
Usability: Key principles and what designers
think. Communications of the ACM 28 (3), S.
300-311.
Hersey, P.; Blanchard, K.; Johnson, D.
(2007): Management of organizational behavth
ior: Leading Human Resources, 9 edition.
Upper Saddle River: Prentice Hall.
Karat, J. (1997): Evolving the scope of usercentered design. Communications of the
ACM, 40 (7), S. 33-38.
Petrovic, K.; Weißenberger, U. (2008): User
Centered Design als Teil des Requirements
Engineering Prozesses. Vortrag beim Workshop der GI-Fachgruppe Software-Ergonomie
des Fachbereichs Mensch-ComputerInteraktion: „Integration von
Usability-Engineering und SoftwareEngineering“, Esslingen, 6.-7. März 2008).
ISO/IEC 25062:2006-04: SoftwareEngineering - Qualitätskriterien und Bewertung von Softwareprodukten (SQuaRE) Gemeinsames Industrieformat (CIF) für Berichte über Gebrauchstauglichkeitsprüfungen.
Berlin: Beuth Verlag, 2006.
ISO/IEC 9126-1:2001-06 : SoftwareEngineering - Qualität von SoftwareProdukten - Teil 1: Qualitätsmodell. Berlin:
Beuth Verlag, 2001.
ISO 9241 – 110: Ergonomie der MenschSystem-Interaktion –Teil 110: Grundsätze der
Dialoggestaltung (ISO 9241-110:2006)
IEEE 610.12 – 1990. IEEE Standard Glossary
of Software Engineering Terminology. IEEE,
New York, 1998
Seffah, A.; Metzker, E. (2004): The Obstacles
and Myths of Usability and Software Engineering. In: Proceedings of the ACM, 47 (12),
S.71-76.
SMART (Projektmanagement) (2008):
http://de.wikipedia.org/wiki/SMART_%28Proje
ktmanagement%29: retrieved 2008:05:30
.
219
220
A g iles User- Ce nt e re d - D e s i g n
221
222
Agile nutzerzentrierte Softwareentwicklung mit
leichtgewichtigen Usability Methoden – Mythos oder
strategischer Erfolgsfaktor?
Thomas Memmel
78457 Konstanz
[email protected]
Henning Brau
Daimler AG
Data and Process Management
Team Psychology in Engineering
89013 Ulm
[email protected]
Dirk Zimmermann
Eigelstein 27
50668 Köln
[email protected]
Abstract
In diesem Beitrag stellen wir Möglichkeiten zur Verzahnung von Usability Engineering und agiler Softwareentwicklung
vor. Dabei beleuchten wir zunächst die
Gemeinsamkeiten und Unterschiede
beider Vorgehensweisen. Hinsichtlich
einer dringend erforderlichen Best Practice für eine agile, nutzerzentrierte Softwareentwicklung erläutern wir Möglichkeiten für ein Down-Stripping von Usability Engineering Techniken. Schließlich
schlagen wir konkrete Strategien zur
1.0
Einleitung
Die Wichtigkeit des User Interface
(UI) wird bereits in vielen zukunftsorientierten Entwicklungs- und Fachabteilungen erkannt. Daher erhalten grundsätzliche Methoden des Usability Engineering
ebenso Einzug in Entwicklungsprozesse
wie eine Sensibilisierung für das UI Design. Gleichzeitig herrscht jedoch ein
enormer Zeit- und Kostendruck vor.
Produktentwicklungszeiten werden verkürzt, Softwaresysteme müssen günstiger hergestellt werden und deren Entwicklung wird daher zunehmend auch
ins Ausland verlagert. In diesem Kontext
besteht die Gefahr, dass Usability Engineering Methoden auch schnell wieder
in den Hintergrund rücken.
Zahlreiche Faktoren können dazu beitragen, dass Softwareprojekte angesichts dieses enormen Spannungsfelds
scheitern oder nur mit unzureichender
Integration von leichtgewichtigen Usability Engineering Methoden in agile
Entwicklungsprozesse vor. Ziel eines
Hybrid-Vorgehensmodells muss dabei
weiterhin die Entwicklung von User
Interfaces mit hoher Usability und User
Experience Qualität sein. Daher müssen Methoden beider Welten mit Bedacht ausgewählt, verschmolzen und
intelligent im iterativen Entwicklungszyklus eingesetzt werden. Erst dann
kann trotz knapper Budgets und ambi-
tionierter Zeitplanung eine hohe User
Interface Qualität sichergestellt werden.
IT-Organisationen, die den Brückenschlag der Disziplinen schaffen und in
der methodischen Praxis umsetzen,
können so einen strategischen Wettbewerbsvorteil erreichen.
UI Qualität abgeschlossen werden.
Dazu gehören:
liebtheit bei der Entwicklung von Softwaresystemen. Auch für Usability Experten, deren angewandte Methoden nach
wie vor von vielen Softwareentwicklern
als zeit- und kostenintensiv angesehen
werden, sind agile Methode sehr interessant. Jedoch müssen einige Mythen,
Vorurteile und Hindernisse überwunden
werden,
wenn
eine
HybridVorgehensweise im Sinne von Agile
Usability Engineering eingeführt werden
soll.
1.
Die Anforderung trotz straffer
Rahmenbedingungen gebrauchstaugliche Softwareprodukte zu
entwickeln.
2.
Der Anspruch eine hohe UI Qualität zu gewährleisten, die der Organisation auch eine strategisch
wichtige User bzw. Customer Experience sicherstellt.
3.
Der Einfluss von Akteuren aus
weitestgehend separierten Disziplinen, darunter vor allem Softwareentwickler, Usability Experten
und Business Analysten.
4.
Das Fehlen geeigneter Methoden
und Vorgehensmodelle, die solchen Herausforderungen angemessen Rechnung tragen.
Agile Methoden erfreuen sich in diesem Kontext einer zunehmenden Be-
Keywords: Agile, User Interface, Usability Engineering
2.0
Bist Du schon agil oder dokumentierst Du noch?
Durch eine inkrementelle Implementierung, zahlreiche Iterationen und
schnelle Release-Zyklen wird mit agilen
Methoden eine deutliche Flexibilisierung
bei gleichbleibend hohen Qualitätsansprüchen ermöglicht. Auf diese Weise
kann eine deutlich kürzere Time-toMarket erreicht werden. In keinster Weise korrekt ist jedoch die immer noch weit
verbreitete Annahme, dass damit eine
223
Eliminierung jeglicher Dokumentation
verbunden ist.
Die Motivation hinter den agilen Modellen unterscheidet sich sicherlich von
klassischen Modellen in vielerlei Hinsicht. Es gibt keine monolithischen Phasen und natürlich wird auch weniger
Wert auf eine umfangreiche Anfertigung
unterschiedlicher Artefakte gelegt. Dabei
kann das „Einsparen“ jedoch vor allem
auf leitende agile Prinzipien zurückgeführt werden, darunter Model with a purpose oder Travel Light. Diese Maximen
sehen beispielsweise vor, nur unbedingt
erforderliche Modelle aufzubauen und
zu pflegen. Vielmehr als in anderen
Entwicklungsmethoden
kommt
es
gleichzeitig auch auf Kommunikation
und die Interaktion aller Projektbeteiligten an (Schwaber 2004).
Entwicklungsmodelle des Usability Engineering und agile Methoden, wie z.B.
eXtreme Programming (XP), verfolgen
im Grunde ein und dieselbe Zielstellung:
Leistungsstarke und stabile Anwendungen mit hohem Nutzwert und Anwenderakzeptanz hervorzubringen. Um solche Applikationen erfolgreich zu entwickeln, müssen unabhängig vom Entwicklungsvorgehen die Bedürfnisse der
späteren Nutzer im Anwendungskontext
verstanden werden.
Mitunter befürchten Usability Experten
jedoch, dass im Mahlstrom der engen
Release Planung, die vornehmlich auf
die Erzeugung lauffähiger Features abzielt, die konkreten Nutzeranforderungen
zu wenig Beachtung erhalten. Die Erfolge agiler Softwareprojekte beziehen sich
tatsächlich oft auf Systeme, bei denen
die Entwicklung und Qualität des UI
nicht im Vordergrund stehen. Derartige
Bedenken müssen analysiert und verstanden werden, wenn über Agile Usability Engineering nachgedacht wird.
224
3.0
Der gemeinsame Nenner
Der Blick auf wichtigste Prinzipien
und Praktiken von XP oder Agile Modeling (AM) zeigt, dass es viele Gemeinsamkeiten gibt (Gundelsweiler et
al. 2004; Memmel et al. 2007; Nebe et
al. 2007).
So kennt XP mit Story Cards und Task
Cards ähnliche Artefakte wie das Usability Engineering mit User Profiles
oder Task Models. Das grundsätzliche
Erfordernis von XP Prozessen, in häufigen Zyklen schnell vorzeig- und testbare Ergebnisse zu erzielen, ist mit
Usability Prozessen vereinbar. Hier
sind ebenfalls frühe Prototypen vorgesehen, um Feedback in die weitere UI
Entwicklung zu integrieren. Die dazu
notwendige Einbeziehung von Stakeholdern als permanente Quelle für
neue Anforderungen und Feedback ist
dem aus im Usability Engineering bekannten Prinzip des kollaborativen
Designs ähnlich (Gundelsweiler et al.
2004).
Sicherlich existieren neben den leicht
festellbaren Übereinstimmungen auch
grundlegende Konflikte. So wird der
agile Entwicklungsprozess in kleine,
überschaubare
Problemstellungen
zerlegt (Small Releases) und zügig
inkrementell ausgeführt. Dabei ist es
nicht erforderlich, dass alle Anforderungen bereits zu Beginn verstanden
und erfasst worden sind. Während der
Projektlaufzeit muss es zudem möglich
sein, Anpassungen in verschiedenem
Umfang vorzunehmen (Refactoring).
Im Gegensatz zu dieser Philosophie
wird im Usability Engineering zu Beginn relativ viel Zeit für die Anforderungsermittlung und die UI Konzeption
genutzt. In die eigentliche Entwicklung
soll erst eingestiegen werden, wenn
genügend Wissen bezüglich des Nutzungskontextes vorhanden ist und
eine vollständige Architektur des UI
entwickelt worden ist. Ein permanen-
tes Redesign des UI kann schnell zu
massiven Benutzungsproblemen führen.
So würde eine grundsätzliche Veränderung des Navigationskonzeptes, der
Organisation der Informationspräsentation oder der gewählten Interaktionstechniken von Small Release zu Small
Release dazu führen, dass grundlegende Dialogprinzipien wie Erwartungskonformität, Selbstbeschreibungsfähigkeit
oder Erlernbarkeit verletzt würden (Gundelsweiler et al. 2004).
In agilen Methoden ist es auch nicht
zwangsläufig der Endbenutzer, der während der kurzen Anforderungsanalyse zu
Beginn befragt wird (Memmel et al.
2007; Nebe et al. 2007). So können
sich einige offene Fragen bei der Erstellung von User Stories durch Dritte ergeben. Ähnliches gilt für abschließend
durchgeführte Akzeptanztests, die nicht
etwa die Bewertung durch Endnutzer
erhebt, sondern die Erfüllung der vereinbarten Projektumfänge mit dem Auftraggeber. Somit vernachlässigen die
agilen
Softwareentwicklungsprozesse
aus Sicht des Usability Engineering eine
Reihe wichtiger Vorgehensweisen zur
Entwicklung gebrauchstauglicher Software.
4.0
Flexible Rollenverteilung
Eine Grundannahme agiler Methoden ist, dass die Projektmitglieder vergleichbare Qualifikationen haben und
somit in einem homogenen Team entwickelt wird. Dies lässt sich schlecht mit
Usability Engineering vereinbaren: In
DIN EN ISO 13407 für nutzerzentrierte
Entwicklung werden explizit multidisziplinäre Teams eingefordert, in denen
neben Programmierern auch Designer,
Stakeholder und Usability Experten vertreten sein sollen. Zudem sind Usability
Experten, die zusätzlich über profunde
Softwareentwickler Kompetenzen verfügen eher selten. Gleiches gilt für den
umgekehrten, eher noch exotischeren
Fall. Traditionelle Rollen müssen daher
insgesamt durchbrochen werden, so
dass beispielsweise auch Entwickler am
Designvorgang beteiligt sind und Usability Experten an der Architekturfestlegung. Gerade wenn sich das Agile Usability Engineering an XP anlehnt, kann
die interdisziplinäre Vermischung der
Akteure im Rahmen von Pair Programming erfolgen (Gundelsweiler et al.,
2007). Die offene Kooperation selbst
ermöglicht dann durch das konstruktive
(auch soziale) Miteinander der verschiedenen Disziplinen und Perspektiven eine
gegenseitige Annäherung.
Kernkompetenzen der multidisziplinären agilen Projektarbeit
Anforderungen an Usability Experten:
x
Kompetenzen in der Agilen Systementwicklung
aufbauen
–
Grundlagen, Prinzipien und Methoden der agilen Systementwicklung sollten ihnen zumindest
bekannt sein.
x
Im Entwicklungsteam positionieren – Anstelle der Trennung zwischen Entwicklungs-, Designund Usability-Aufgaben sind stetige Kommunikation und Kooperation notwendig.
x
Anforderungen an Entwickler:
x
x
x
UI-Kompetenzen aufbauen –
Grundlagen, Prinzipien und Methoden
des
UsabilityEngineerings sollten ihnen zumindest bekannt sein.
Usability als gewichtigen Qualitätsfaktor verstehen – Qualitätsabsicherung ist ein wichtiger
Punkt der Agilen Systementwicklung. Für viele Systemeigenschaften gibt es definierte Absicherungsmechanismen. Warum
also nicht für Usability?
Styleguides respektieren – Gute
Programmierer sind gewöhnt,
den Konventionen der Programmierung und Systemarchitektur
zu folgen, gleiches sollte auch für
die Einhaltung der Styleguides
bei der UI-Gestaltung gelten.
5.0
Vorurteile abbauen – Selbst das
viel gescholtene XP ist weitaus
strukturierter und auch anforderungsorientierter als sein Ruf. Die
agilen Methoden sind adaptierbar
an die jeweiligen aktuellen Bedarfe, ebenso die UsabilityEngineering Methoden.
Agile Usability Engineering
Aufbauend auf den bisherigen
Überlegungen können für die unterschiedlichen Entwicklungsphasen konkrete Methoden für ein Agile Usability
Engineering herauskristallisiert werden. Im folgenden Beispiel orientieren
wir uns dazu am XP Prozess ergänzt
um Anteile aus der Scrum Methodik
und erweitern diese um Bestandteile
des Usability Engineerings. Zeitintensive Maßnahmen haben dabei keinen
Platz, so dass tiefgehende Verhaltensund Prozessanalysen von Nutzern und
Nutzungskontext, langwierige Interviewserien oder auch aufwändige Evaluationsverfahren kaum in Betracht
kommen.
5.1
Anforderungsphase (Iteration 0)
In dieser Phase ist der direkte Kontakt von Entwicklern und Stakeholdern
für den Gesamterfolg der Entwicklung
sehr hilfreich. Methoden, die sich für
eine Nutzeranalyse empfehlen sind
beispielsweise offene Interviews, Fokusgruppen, teilnehmende Beobachtungen, Strukturlegetechniken (Card
Sorting) sowie das Aufzeichnen von
Storyboards und Personas zusammen
mit den Stakeholdern.
Der gewonnenen Anforderungen können sehr gut mit Role Models und Role
Maps (Constantine & Lockwood, 1999)
festgehalten werden. Dokumentiert
werden sollen die für die Anwendung
wichtigen Charakteristika der Rollen,
sowie erforderliche Interaktionsschemata. Anschließend werden die Benutzerrollen mit Prioritäten versehen (Focal
User Roles) und nach Relevanz für den
Produkterfolg sortiert.
Essentiell sind auch die Aufgaben der
Benutzer, die durch Szenarien, Essential Use Cases und Use Case Maps
(Constantine & Lockwood, 1999) oder
auch User Stories (Cohn, 2004) beschrieben werden können. Wie schon
die Benutzerrollen werden auch die
Task Cases sortiert, wobei man sich an
der aus XP (Beck, 1999) bekannten
Einteilung orientieren kann (Required do first, Desired - do if time, Deferred do next time). Ergänzt wird diese Einteilung um essentielle Task Cases, die
besonders komplex oder neuartig sind.
Diese werden zu Szenarien ausformuliert, um das Verständnis im Team besser zu kommunizieren. Um Dokumentationsarbeit einzusparen reicht es aus,
die ausformulierten Szenarien direkt auf
einer Indexkarte festzuhalten. Sind die
Aufgaben alle erfasst, ist es möglich,
Cluster zu bilden, die innerhalb eines
Anwendungsbereichs
wichtige
Programmteile aufzeigen.
225
Der wesentliche Vorteil der Role Models/Role Maps und Essential Uses Cases/Use Case Maps aus agiler Modellierungssicht besteht darin, dass sie gut
zur agilen Philosophie passen (z.B. Nutzung von Indexkarten, Fokussierung auf
das Essentielle).
Es hat sich ebenfalls für agiles UI Design bewährt, verschiedene Ergebnisse
des Usability Engineerings jeweils als
einzelne Anforderungen zu dokumentieren (Nebe et al., 2007). Aus den Ebenen
„Nutzungskontext“, „Nutzungsanforderungen“ und „Konzeption/Design“ lassen
sich so sowohl allgemeine UsabilityAnforderungen modellieren (Effektivität,
Effizienz und Zufriedenheit), wie auch
Workflow-Anforderungen (im Sinne der
ISO 9241 Dialogprinzipien) und nicht
zuletzt Anforderungen des UI, entsprechend den InformationsdarstellungsKriterien der DIN EN ISO 9241 (Zimmermann & Groetzbach, 2007) modellieren. Durch die feine Granularität lassen
sich einzelne Anforderungen leicht auf
mehrere Teams aufteilen, stellen aber
gleichzeitig durch ihre Ableitung aus und
ihren Bezug zu den Analyseartefakten
eine verlässliche Richtschnur für die
Evaluation in der verteilten Entwicklung
dar.
Bei agilen Ansätzen werden Design
Prinzipien und Style Guides kaum erwähnt. Vor allem in größeren Firmen mit
ausgeprägter Corporate Identity (CI)
existieren oft umfassende firmenweit
geltende Style Guides, die nicht nur das
Look and Feel, sondern auch die CIspezifischen Aspekte des UI regeln. Als
Alternative zur Erstellung eines Style
Guides schlagen wir eher einen Prototyping-getriebenen Spezifikationsprozess
für das UI vor, bei dem die wichtigsten
Informationen zum System zusammen
mit dem UI Design als Simulation bereitgestellt werden (Memmel et al. 2008).
Durch sogenannte interaktive UI Spezifikationen kann auch die Zusammenarbeit
mit einem (internen oder externen) Zu-
226
lieferer verbessert werden, der in vielen Fällen für die Implementierung
verantwortlich ist.
5.2
Konzeptionsphase
In der Anforderungsphase wird bereits die Grundlage für eine Aufteilung
von Funktions- und UI-Entwicklung
gelegt, in der ab der Konzeptionsphase die gemeinsamen Ansätze unabhängig voneinander ausdifferenziert
werden. Dies ist vor allem bei größeren Projekten sinnvoll. Voraussetzung
ist allerdings, dass sich die Programmierung einfach in Funktionalität und
UI aufteilen lässt. Eine solche Trennung kann mit Hilfe von Software Patterns erreicht werden. Es ist jedoch
Fakt, dass der Einfluss der Benutzeroberfläche auf die Architektur mit steigendem Maß an Interaktivität zunimmt.
Daher ist eine enge Zusammenarbeit
und laufende Abstimmung dieser
Stränge unerlässlich, um die spätere
Systemintegration reibungslos zu ermöglichen. Dazu muss eine minimalistische UI-Spezifikation erstellt werden
(Constantine & Lockwood 2002), die
den Entwicklern der Systemarchitektur
als Vorlage für die Schnittstellen der
abhängigen Komponenten dient.
Insbesondere für den UI-bezogenen
Entwicklungszweig sollten Prototypen
erzeugt oder weiterentwickelt werden.
Papierprototypen können für das
schnelle Testen erster Ideen genutzt
werden, während elaboriert den
Workflow abbildende Prototypen (beispielsweise in Adobe Flash erstellt)
ideal für Präsentationen vor Publikum
und die Simulation der Interaktion sind.
Die Erstellung von realistischen Prototypen ist zwar aufwändiger, diese können jedoch in der Konstruktionsphase
weiterverwendet werden und als Spezifikation dienen (Memmel et al. 2008).
Auch erste Evaluationen können
schon in der konzeptionellen Phase
durchgeführt werden. Agile Usability
Techniken, die mit wenig Aufwand eingesetzt werden können sind, zum Beispiel User und Expert Reviews sowie
Usability Inspektionen. Durch eine Beteiligung von Stakeholdern kann die Kooperative Heuristische Evaluation (Brau
2004) die Nutzer- und Expertensicht
zusammenführen. Dazu werden realistische Anwendungsszenarien für den zu
inspizierenden Funktionsumfang entwickelt. Jeweils ein Usability Experte bearbeitet die Anwendungsszenarien zusammen mit einem Nutzer. Dieser wird
aufgefordert die jeweiligen Handlungsschritte zu kommentieren, bzw. der
Usability Experte stellt ihm Verständnisfragen zum realen Nutzungskontext.
Dies hilft dem Usability Experten, die
Sichtweise der Nutzer zu verstehen und
entsprechend seine eigenen Ergebnisse
auf die Nutzeranforderungen auszurichten. Auch für Entwickler kann es sehr
aufschlussreich sein, an einer solchen
Sitzung als stiller Beobachter teilzuhaben.
5.3
Konstruktionsphase
Bevor die Programmierung beginnen kann, ist ein Iteration Planning (XP)
oder Sprint Planning (Scrum) empfehlenswert. Neben den funktionalen Unitbzw. Acceptance-Tests (XP), die später
automatisiert ablaufen können, können
jetzt auch weitere Usability Testfälle für
das ausgereifte System (z.B. anhand
möglicher Testaufgaben) überlegt werden, sowie Evaluationskriterien und
Zielgrößen für die User Acceptance
Tests im Sprint Review innerhalb des
Scrum Ansatzes.
In dieser Phase findet die teilweise parallel ablaufende Implementierung des
UI und der Systemarchitektur statt. UIKomponenten, die für die Implementierung der Systemarchitektur schnell angeliefert werden müssen, können zunächst mit geringer Genauigkeit umgesetzt und in späteren Iterationen verfei-
nert werden. Dies ist unkritisch, solange
das konzeptuelle Modell nicht verändert
wird.
Wie auch in der Konzeptionsphase können Usability Studien angewendet werden, um die Gebrauchstauglichkeit des
UI sicherzustellen. Funktionstest sollten
parallel verlaufen, um Zeit einzusparen.
Testergebnisse können auf sogenannten Defect Cards (Gundelsweiler et al.,
2004) festgehalten, priorisiert und die
Behebung für folgende Iterationen eingeplant werden.
6.0
Übergreifende Koordination
Um gerade in größeren Organisationen, in denen viele kleinere Teams
parallel arbeiten, die Kohärenz und Konsistenz der Lösung zu gewährleisten,
hat sich parallel zu den XP-Ansätzen
innerhalb der Scrum-Methodik (Schwaber, 2004) für teamübergreifende Themen das Konzept der „Scrum of
Scrums“ bewährt (Larman, 2004). Während die Scrum-Teams in kurzen Inkrementen mit täglichen Abstimmungstreffen und schnellen Iterationen die eigentliche Lösung entwickeln, treffen sich
Vertreter jedes der Scrum-Teams in
größeren Anständen zu speziellen übergreifenden Themen, wie etwa der Architektur, Datenbankmodellierung, usw.
Ein „Usability Scrum of Scrums“ greift
diese Methodik auf und hilft den in einzelnen Teams verteilten UI Designern,
ihre Ergebnisse regelmäßig miteinander
abzugleichen,
Evaluationsergebnisse
auszutauschen und Ideen und Modelle
für Folgethemen zu generieren. So werden die Ideen aus der Analysephase
auch durch das gesamte Projekt in regelmäßigen Abständen überprüft und
gegebenenfalls modifiziert, jedoch nicht
lokal, sondern über die einzelnen Teams
hinweg.
7.0
Zusammenfassung
Agile Prozesse und Usability Engineering haben grundlegend abweichende Herangehensweisen an das
Software Engineering. Beide sehen
aber den Einsatz von Methoden zur
Nutzer- und Kontextanalyse vor. Agile
Methoden erfordern insgesamt ein
deutlich flexibleres und schlankeres
Usability Engineering, Für eine HybridVorgehensweise ist ein hohes Maß an
multidisziplinärer Kooperation und
organisationalem Umdenken notwendig. Gelingt eine strukturierte Verknüpfung der beiden Entwicklungsparadigmen, können viele Prozesse parallelisiert werden, so dass in kürzerer
Zeit gebrauchstaugliche Anwendungen
entwickelt werden können.
Im Vergleich zum ursprünglichen XP
und Scrum Prozess führen die im
Beitrag skizzierten Methoden sicherlich zu weniger „Agilität“. Dafür ermöglicht die Erweiterung aber, eine
gebrauchstaugliche Software zu entwickeln. Insgesamt erscheint es uns
aber noch mehr als gerechtfertigt, von
einem agilen Hybrid-Vorgehensmodell
zu sprechen.
8.0
Brau, H. & Schulze, H. (2004): Kooperative
Evaluation: Usability Inspektion in komplexen und verteilten Anwendungsdomänen.
In: Peissner, M. & Hassenzahl, M. (Hrsg.).
Usability Professionals 2004. Fraunhofer
IRB Verlag: Stuttgart.
Cohn M. (2004). User Stories Applied – For
Agile Software Development, AddisonWesley:Boston.
Gundelsweiler, Fredrik; Memmel, Thomas;
Reiterer Harald (2004): Agile Usability Engineering. Proceedings of the 4th Mensch &
Computer conference (MCI 2007, Paderborn,
Germany), In: Keil-Slawik, R.; Selke, H.;
Szwillus, G.: Mensch & Computer 2004: Allgegenwärtige Interaktion, Oldenbourg Verlag,
München, S. 33-42
Larman C. (2004). Agile & Iterative Development – A Manager's Guide, Addison-Wesley:
Boston.
Memmel, T.; Gundelsweiler, F.; Reiterer, H.
(2007): Agile Human-Centered Software Engineering. In Proc. of 21st BCS HCI Group
conference (HCI 2007, UK), in: Linden J. Ball,
M. Angela Sasse, Corina Sas, Thomas C.
Ormerod, Alan Dix, Peter Bagnall and Tom
Mc Ewan: "HCI...but as we know it", British
Computer Society, S. 167-175
Memmel, T.; Geis, T.; Reiterer, H. (2008):
Methoden, Notationen und Werkzeuge zur
Übersetzung von Anforderungen in User
Interface Spezifikationen. In: Brau, H., Diefenbach, S., Hassenzahl, M., Koller, F.,
Peissner, M. & Röse, K. (Hrsg.). Usability
Professionals 2008. Fraunhofer IRB Verlag:
Stuttgart.
Nebe, K., Düchting, M. & Zimmermann, D.
(2007). Integration von User Centred Design
Aktivitäten in Agile Softwareentwicklung. In:
H. Brau & K. Röse (Hrsg.): Usability Professionals 2007. Fraunhofer IRB Verlag: Stuttgart.
Schwaber, K. & Beedle., M. (2002). Agile
Software Development with Scrum. Prentice
Hall: Upper Saddle River.
Schwaber, K. (2004): Agile Project Management with Scrum. Redmond: Microsoft Press.
Zimmermann, D. & Groetzbach, L. (2007). A
Requirement Engineering Approach to User
Centered Design. In: Proceedings of the 2007
HCI International Conference (Beijing, P.R.
China, July 22-27, 2007)..
Constantine, Larry L. (2002): Process Agility and Software Usability: Toward Lightweight Usage-Centered Design. Information
Age.
Constantine, Larry L.; Lockwood, Lucy A.
D. (1999): Software for Use: A Practical
Guide to the Methods of Usage-Centered
Design. Addison-Wesley Professional.
227
Integration von User Centered Design in agilen
Entwicklungsprozessen
Markus Düchting
Siemens IT Solutions
C-LAB
Fürstenallee 11
33102 Paderborn
[email protected]
Petra Kowallik
Open Text Corp.
Product Design
Werner-von-Siemens Ring 20
85630 Grasbrunn b. München
[email protected]
Karsten Nebe
C-LAB
Fürstenallee 11
33102 Paderborn
[email protected]
Abstract
Der vorliegende Beitrag behandelt die
Integration von User Centered Design
und agiler Softwareentwicklung. Es wurden existierende Ansätze betrachtet und
gemeinsame Kernaspekte dargelegt.
Diese werden im Bezug zur Praxis an
einem konkreten Anwendungsfall verdeutlicht.
1.0
Einleitung
Die agile Softwareentwicklung gewinnt in den letzten Jahren immer mehr
Aufmerksamkeit, sowohl seitens der
Softwareindustrie als auch der Wissenschaft. Dies zeigen beispielsweise die
zahlreichen Konferenzen bzw. die öffentlichen Bekundungen vieler Unternehmen agile Entwicklungsprozesse
einzusetzen.
Die wachsende Verbreitung von agilen
Vorgehensweisen in der Softwareentwicklung zieht auch die Aufmerksamkeit
der HCI Community auf sich. So resultiert daraus die Frage, ob Softwaresysteme die agil erstellt werden, gebrauchstauglich sind? Vielleicht bietet das Agile
sogar dafür eine besondere Chance?
Könnten sich Probleme, die in der klassischen Softwareentwicklung existieren,
vielleicht im Agilen auflösen? Rigide
definierte, lineare Projektpläne, monolithische Phasen, umfangreiche Artefakte /
Dokumentation werden z. B. gegenüber
der Interaktion mit den Kunden in den
Hintergrund gestellt. Viele dieser Aspekte werden auch bereits durch Vorgehensweisen des UCD adressiert.
228
Im Praxisteil wird Open Text’s Agile
Design-Methode beschrieben, bei der
der Nutzungskontext in frühen Research Phasen evaluiert und mit Hilfe
der Persona Methode dargestellt wird.
Der iterative Entwicklungsprozess bildet den Rahmen für ein agiles Design,
das eine hervorragende User Experience liefert.
Keywords
In der Literatur existiert zudem eine
Vielzahl von Integrationsansätzen, die
UCD und agile Vorgehensweisen kombinieren. Es besteht offensichtlich ein
Handlungsbedarf seitens der UCD
Community auf diese Entwicklung angemessen zu reagieren und die Chance zu nutzen, qualitativ hochwertige
und gebrauchstaugliche Produkte agil
zu entwickeln.
stellt und anschließend mit Beispielen
aus dem Vergleich verdeutlicht. Die daraus resultierenden Forderungen werden
im Anschluss gesammelt vorgestellt und
der Bezug zur Praxis an einem konkreten Anwendungsfall verdeutlicht.
Der Fragestellung, inwieweit agile Modelle bereits Aspekte des Usability
Engineering berücksichtigen, haben
die Autoren bereits im Rahmen einer
vorhergehenden Betrachtung diskutiert
(Nebe et al 2007). Daraus entstand die
Motivation die existierenden Integrationsansätze genauer zu betrachten
und einander gegenüber zu stellen.
2.0
Integrationsaspekte
Im Folgenden werden Kernaspekte aufgeführt, welche auf die wesentlichen Gemeinsamkeiten der unterschiedlichen Ansätze abzielen. Dazu
werden zunächst die identifizierten
Kernaspekte allgemein beschrieben,
schließlich einige spezifische Besonderheiten bei der Integration vorge-
Agile Software Engineering, Agile Design, User Centered Design
2.1
Analyse
In der Softwareentwicklung werden
in einer Analysephase Informationen
über den zukünftigen Nutzer gesammelt
und zusammengefasst. Dazu zählen die
Aufgaben und Ziele der Nutzer, die Arbeitsabläufe und der Nutzungskontext,
einschließlich eventueller Umwelteinflüsse oder technischer Rahmenbedingungen.
Im User Centered Design wird es als
unerlässlich angesehen, die zukünftigen
Nutzer eines Systems so gut wie möglich zu kennen, bevor mit der Entwicklung von Designs und der Implementierung begonnen wird. Unterschied zum
Agilen ist, dass i.d.R. keine explizite,
vorgelagerte Analysephase durchgeführt
wird. Dies wird versucht, durch die permanente Anwesenheit eines Customer
Stakeholder, auszugleichen. Bei einigen
der betrachteten Integrationsansätze
wurde die Analyse des Nutzungskontexts auch in Kombination mit dem Agilen beibehalten. Diese Analysen sind
jedoch nicht so umfangreich, wie sie in
klassischen UCD Prozessen vorgesehen werden. Vielmehr wird die Idee der
agilen Entwicklung aufgegriffen, nur so
viel Wissen zu sammeln, wie für die
nächste Iteration entscheidend ist. Dabei
entstehen schlankere Dokumente und
das Wissen wird oft persönlich weitergegeben. Unterschiede in den Ansätzen
existieren darin, wie lang diese Phasen
sind, die Art der Dokumentation, wer die
Aktivitäten durchführt, ob sie parallel zur
Entwicklung stattfinden oder in einem
zeitlich versetzten Zyklus durchgeführt
werden (Chamberlain et al 2006; Detweiler 2007; Sy 2007).
Im Ansatz von Beyer et al. (2004) wird
beispielsweise eine Kontextanalyse
(Contextual Inquiry) mit mindestens drei
Personen in unterschiedlichen Nutzerrollen durchgeführt, die ca. eine Woche
dauern soll. Um den Aufwand für den
Wissenstransfer gering zu halten, wird
die Analyse von einem interdisziplinären
Team aus UI Designern, Entwicklern,
Marketing Repräsentanten, etc. durchgeführt.
Generell ist das Konzept der Analyse,
wie es im UCD verstanden wird, nicht
konsistent mit dem iterativen Vorgehen
bei einer agilen Vorgehensweise. Auf
der einen Seite wird im UCD ein iteratives Vorgehen propagiert und auf der
anderen Seite eine monolithische und
lineare Phase am Anfang des Prozesses
eingefordert. Für einen schnellen Entwicklungsprozess wäre es von Vorteil,
wenn die Analyse aus dem Produktentwicklungsprozess heraus gelöst wird
und bereits vorher von Experten durchgeführt würde. Wichtig aus Sicht des
UCD ist es, dass dieses Wissen im Vorfeld vorhanden ist und nicht, ob dies im
selben Entwicklungsprozess stattfindet
[Norman 2006].
Haikara (2007) beschreibt in einer
Fallstudie mehrere agile Projekte, in
denen die Entwicklung durch PersonaBeschreibungen unterstützt wurde.
Dabei zeigte sich, dass die zeitintensive Erstellung von umfangreichen Personas die agile Entwicklung aufzuhalten drohte.
Dies kann als Indiz dafür gewertet
werden, dass es Sinn macht, die Analyse vom eigentlichen Entwicklungsprozess zu entkoppeln. um diesen
nicht auszubremsen.
2.2
Modellierung
Bei der Modellierung geht es in
erster Linie darum, Rollen, Aufgaben,
Ziele und Anforderungen im (größeren) Zusammenhang darzustellen, um
von der Abbildung eines ISTZustandes zu einem verbesserten
SOLL-Zustand zu gelangen.
Die kleinschrittige, inkrementelle Entwicklung im Agilen erschwert eine
ganzheitliche Modellierung von Interaktion und Arbeitsabläufen. Es besteht
die Gefahr, dass Anforderungen bzgl.
des Workflows der Nutzer nicht in ihrem Gesamtkontext gesehen werden,
wenn sie lediglich in Form von User
Stories oder Backlog Einträgen festgehalten werden. In der Umsetzung
muss daher sichergestellt sein, dass
nicht nur einzelne Arbeitsabläufe der
Nutzer erfasst und implementiert werden, sondern auch dass die Beziehungen zwischen den Arbeitsabläufen der
Nutzer im konkreten Handlungskontext
berücksichtigt werden.
In den untersuchten Integrationsansätzen wurden dafür unterschiedliche
Artefakte, wie Use Cases, Scenarios,
Task Models und auch Personas verwendet (Chamberlain et al 2006
;Patton 2002; Wolkerstorfer et al
2008).
Constantine & Lockwood (2003) schlagen beispielsweise vor, die Tasks der
Nutzer in Form von Use Case Szenarien
auf Index-Karten zu formulieren, diese
zu gruppieren und zu priorisieren. Wolkerstorfer et al. (2008) beschreibt hingegen in einer Fallstudie, wie die Entwicklung durch Persona-Beschreibungen
unterstützt wurden. Die (Extreme)Personas in diesem Beispiel zeichnen
sich durch ihre inkrementelle Entwicklung und Refaktorisierung aus. Daher
auch die Bezeichnung Extreme Persona.
2.3
Testing und Prototyping
Das kontinuierliche und detaillierte
Testen von Teil-Lösungen, ist im Agilen
mit dem Ziel verankert, weitestgehend
fehlerfreie Software sicherstellen zu
können. Dies wird auf technischer Seite
durch automatisierte Unit-Tests realisiert
und aus Kunden/Nutzer-Sicht durch sog.
Acceptance Tests, bei denen ein Softwaresystem gegen die im Vorfeld definierten Anforderungen evaluiert wird.
Aus Usability Sicht sind solche automatisierten Test nur schwer möglich und
beschränken sich z. B. auf die Prüfung
der Konformität des UI (z. B. der richtigen Beschriftung von Interfaceelementen). Das automatisierte Testen komplexer Workflows ist jedoch kaum möglich.
In agilen Modellen ist i.d.R. nicht verankert während einer Prozessiteration Zwischenergebnisse, die noch nicht in Code
umgesetzt wurden, mit Nutzern oder
anderen Stakeholdern zu überprüfen.
Die Betrachtung der Ansätze hat gezeigt, dass gerade für die Entwicklung
einer
gebrauchstauglichen
Nutzerschnittstelle die kontinuierliche Evaluation mit Nutzern maßgeblich ist und Teil
des Modells sein sollte. Eine häufig angewandte Methode scheint das Paper
Prototyping. Der Vorteil ist ein schnelles
Feedback ohne den Ballast eines formalen Tests.
229
Im Rapid Contextual Design Ansatz
(Beyer et al. 2004) werden Paper MockUps verwendet, um erste Designentwürfe mit Nutzern zu überprüfen, bevor diese in Code umgesetzt werden. Patton
(2008) sieht einen deutlichen Mehrwert
in unformalen Tests mit Papierprototypen und beschreibt, wie ein solcher Validierungs-Prozess in einen DesignProzess übergeht. Ein Papierprototyp
bietet ihm die Möglichkeit, auf Feedback
direkt einzugehen, in dem unmittelbar
Veränderungen vorgenommen werden
können, um diese wiederum zu validieren. Kane (2003) befürwortet ein Szenario-basiertes Prototyping, auf Grund der
geringen Kosten und weil es nicht von
lauffähiger Software abhängig ist.
2.4
Verortung von Aktivitäten (Parallelität, Nebenläufigkeit)
In der traditionellen Softwareentwicklung werden Aktivitäten oft schrittoder phasenweise, meist auch sequentiell, abgearbeitet. Der Entwurf startet
meist nach der Analyse, und die Implementierung nach dem Entwurf. Abschließend wird die entwickelte TeilLösung getestet. Dies führt dann zu einer Release-Version, die an Kunden
ausgeliefert wird. In der agilen inkrementellen Entwicklung wird das Ergebnis
einer jeden Prozessiteration als potentielles Mini-Release verstanden. Dabei
werden vergleichbare Aktivitäten wie in
der traditionellen Softwareentwicklung
durchgeführt, aber kleinschrittiger; die
Lösungserarbeitung erfolgt sukzessive.
Die Software, die am Ende einer Iteration vorliegt, soll nur aus vollständig getesteten und lauffähigen Features bestehen.
In einer Fallstudie beschreibt Sy (2007)
den agilen Design und Entwicklungsprozess bei der Firma Autodesk Inc. Hierbei
arbeiten das User Experience-Team
(UX) und das Development-Team parallel, aber zeitlich versetzt. Das UX Team
führt Usability Tests auf Basis des Mini-
230
Release der vorherigen Iteration
durch. Designs zur Implementierung
für die nächste Iteration werden entworfen und validiert und Requirement
Engineering Aktivitäten für den übernächsten Zyklus durchgeführt. Durch
diesen Vorsprung gegenüber der Entwicklung, bietet sich die Möglichkeit
Designs zu validieren, bevor sie implementiert werden. Es kann mehr Zeit
in die Analyse und Anforderungsermittlung investiert werden. Dieses Prinzip
wird in ähnlicher Weise auch von anderen Autoren aufgegriffen, wie beispielsweise Ambler (2007), Nummiaho
(2006), Ungar & White (2008). Dabei
ist es wichtig nicht „zu weit“ für die
Zukunft zu designen, da während der
Entwicklung immer wieder Änderungen aufkommen (Ferreira 2007).
2.5
Rollenmodell
Die Definition von verschiedenen
Rollen innerhalb eines Projektteams
zielt darauf, alle Kompetenzbereiche
der Softwareentwicklung, mit entsprechen ausgebildeten Personen abzudecken.
In agilen Teams, wie sie in der Literatur beschrieben werden, gibt es keine
feste Rollenzuteilung. Im Idealfall sind
alle Teammitglieder in der Lage zu
designen, zu programmieren und zu
testen. Für Projekte bei denen UI und
Interaktion nicht der wesentliche Erfolgsfaktor ist, mag das möglich sein.
Andernfalls hat sich gezeigt, dass es
notwendig ist, die entsprechenden
Entwicklungsteams explizit um Personen mit Erfahrung im Bereich UI Design und/oder User Centered Design
zu ergänzen, um die Gebrauchstauglichkeit sicherzustellen (Ferreira 2007;
Lee 2006; Sy 2007). Kane hält es wiederum auch für möglich, dass Entwickler, mit einem Minimum an Training,
leichtgewichtige „discount“ Usability
Methoden anwenden können, wenn
sie durch Interfaces Design Patterns,
Style Guides und Evaluation durch Heuristiken ergänzt werden (Kane 2003).
2.6
Folgerungen für die Praxis
Resultierend aus der Betrachtung
der Integrationsansätze lassen sich einige Kernaspekte identifizieren, welche
die offensichtlich wesentlichen Punkte
sind, die über ein erfolgreiches Zusammenspiel von UCD und agiler Softwareentwicklung entscheiden.
Eine Folgerung für die Analyse ist, dass
genügend Wissen über die Nutzer vorhanden sein muss, bevor mit dem Design begonnen wird. Die Form der Analyse, also ob diese sehr umfangreich,
vor Beginn eines Entwicklungsprojektes
oder eher kurz am Anfang durchgeführt
und dann inkrementell verfeinert wird,
muss an die Komplexität der zu entwickelnden Software angepasst werden.
Aus UCD Sicht ist ein ausreichend umfangreiches
Basiswissen
qualitätsentscheidend. Aus agiler Sicht ist es
wichtig, dass zur Dokumentation leichtgewichtige Artefakte genutzt werden und
ein Großteil des Wissens mit allen
Teammitgliedern geteilt wird.
Usability Engineers und UI Designer
sollten integraler Bestandteil der interdisziplinären Teams sein. Dies ist eine
Grundvorrausetzung, damit übergeordnete Usability Anforderungen berücksichtigt, sowie das entsprechende Analyse-Aktivitäten (aus UE Sicht) richtig
durchgeführt werden können. Für gewisse, einfache Usability Methoden können das auch Entwickler machen, die im
Vorfeld darin unterrichtet werden und
das nötige Bewusstsein dafür mitbringen. Das UI Design sollte ebenfalls von
Personen mit Erfahrung und entsprechender Ausbildung entwickelt werden.
Es scheint sich bewährt zu haben, ein
Team mit expliziten UCD- und UIDesign- Kenntnissen für die Analyse,
Entwurf und Validierung bereitzustellen.
Dieses Team erarbeitet Anforderungen
und Designs mit einem gewissen Vorsprung gegenüber der Implementierung.
So können Designs vor der Entwicklung
evaluiert werden, ohne den Entwicklungsprozess auszubremsen. Der Vorsprung sollte jedoch nicht zu groß sein,
damit im Falle von Schwierigkeiten, z. B.
bei der Implementierung, nicht zu viel
Aufwand in spätere Änderungen investiert werden muss bzw. Konzepte entwickelt werden, die später keine Beachtung mehr finden.
Eine Folgerung bezüglich der Modellierung ganzheitlicher Arbeitsabläufe ist,
dass in der Durchführung sichergestellt
sein muss, dass nicht nur einzelne Arbeitsabläufe der Nutzer dokumentiert
und implementiert, sondern auch die
Beziehungen zwischen den Abläufen im
konkreten Handlungskontext berücksichtigt werden. Die Verwendung von Artefakten, wie z. B. Use Cases, Szenarios,
Task Maps und auch PersonaBeschreibungen stellen offensichtlich
einen effektiven Weg dar, den Analysten, Produktmanagern und Nutzern ein
ganzheitliches Bild von der Anwendung
zu vermitteln und dadurch Anknüpfungspunkte und Problembereiche einfacher lokalisieren zu können.
Bezüglich des UI muss sichergestellt
werden, dass Entwürfe mit Nutzern evaluiert werden, noch bevor sie implementiert werden. Um auf Änderungen und
wechselnde Anforderungen schnell reagieren zu können, scheinen sich Papierprototypen als ideale Ergänzung zum
Toolkit der agilen Softwareentwicklung
erwiesen zu haben. Darüber hinaus
müssen regelmäßige Usability Tests, mit
allen Vertretern der Zielgruppe, im Prozess verankert werden.
Für die Analyse und das Testen ist die
Zusammenarbeit mit echten Nutzern aus
UCD Sicht unerlässlich. Deshalb muss
sichergestellt werden, dass Endnutzer in
der Gruppe der Customer Stakeholder
vertreten sind und für diese Aktivitäten
herangezogen werden können.
3.0
Anwendungsfall: Open Text’s
Agile Design
Dass sich die identifizierten Kernaspekte in der Praxis wiederfinden,
wird an dem iterativen Entwicklungsprozess (IDP) von Open Text gezeigt.
Durch den iterativen Ansatz von
Design und Entwicklung und eine enge
Kundenbeteiligung in allen Phasen des
Projektes, ist es möglich eine hervorragende
Customer
bzw.
User
Experience zu liefern. Dabei liefert
eine frühe Customer Research Phase
den (Nutzungs-) Kontext.
Der agile Prozess schafft den Rahmen
für die Zusammenarbeit: festgelegte
Feedback-Loops zwischen den externen Stakeholdern (Kunden, Endbenutzer) auf der einen Seite und den internen Beteiligten bei Open Text (Entwicklung, Produkt Management, Product Design, Sales und Services) erreichen, dass möglichst früh im Produkterstellungsprozess klar wird, was
gebraucht wird und was nicht. DesignEntscheidungen werden iterativ getroffen, Kundenfeedback möglichst bis zur
letzten Minute vor der eigentlichen
Implementierung berücksichtigt.
3.1
IDP Artefakte
Folgende IDP Artefakte basieren
auf Research Aktivitäten:
x
x
x
x
x
Vision. Die High Level Sicht, das
Ziel eines Releases.
Persona.
Rock. High Level Feature, typische Roadmap-Inhalte.
User Story. Beschreibt eine Tätigkeit einer Persona und ihre
zugrunde liegende Motivation.
Macro Story. Beschreibt einen
Schritt in oder ein Detail der User
Story. Beispielsweise eine UX
Spezifikation. Die technische Umsetzung wird von der Entwicklung
in Form von Micro Stories spezifiziert.
Die Anwendung der Persona Methode
von Alan Cooper garantiert eine äußerst
benutzerfokussierte Entwicklung, da die
Requirements (User Stories) aus dem
Blickwinkel des Benutzers formuliert
werden. Sowohl das User Interface Design als auch das User Interaction Design werden mit Hilfe diese Stories erläutert und definiert. Die für die Produkte
erarbeiteten Persona Sets ergänzen die
User Stories in idealer Weise.
3.2
IDP Projektstruktur
Das Projektteam ist in ein ‚Core Development Team‘ und ein erweitertes
‚Product Team‘ aufgeteilt. Dabei besteht
das Core Development Team aus
Product Designer, Poject Manager, Developer, Quality Engineer, Technical
Writer. Das Product Team bezieht zusätzlich die externen und internen Stakeholder mit ein.
3.3
Iterativer Entwicklungsprozess
Der IDP bricht die Produktentwicklung in Iterationen von 2-4 Wochen Länge. Jede Iteration startet mit einem
Planning Game und endet mit einem
End Game. Landmarks fassen das Ergebnis mehrerer Iterationen zusammen,
idealerweise bearbeiten sie wenigstens
einen Rock. Landmarks werden wie
‚kleine interne Releases‘ behandelt. In
Landmark Demos wird der aktuelle
Stand vorgeführt; sie finden alle 2-3 Monate in einem größeren Rahmen vor
dem gesamtem Produkt Team statt.
Während der Landmark Demo erhält
das Entwicklungsteam Feedback von
allen Beteiligten. Die kurzen Zeitzyklen
garantieren, dass das Feedback noch in
der aktuellen Produktversion implementiert werden kann.
3.4
Agile Design-Methode
Die Ergebnisse der Research Aktivitäten durch die Product Designer liefern
231
das Fundament für das Design der User
Experience für das laufende Projekt:
Personas und Stories. Die Bedürfnisse
und Aufgaben der Personas helfen, richtige Design-Entscheidungen im Hinblick
auf die User Experience zu treffen und
die Features zu priorisieren. Sie liefern
zudem den Kontext um internen und
externen Beteiligten die Software zu
erläutern.
User Interface und User Interaction Design werden iterativ erarbeitet. DesignEntwürfe werden ausgewählten Stakeholdern (Design Partnern) präsentiert
und von diesen bewertet. Deren Feedback dient als Grundlage für die nächste
Design-Iteration. Auf diese Weise werden die Stakeholder involviert, bevor die
eigentliche Implementierung begonnen
hat bzw. möglicherweise schon erste
Fehlentscheidungen getroffen wurden.
3.5
Verbesserte Usability
Die Integration von UCD Aktivitäten
in allen Phasen des iterativen Entwicklungsprozess erhöht eine flexiblere Anwendung der Methoden und damit die
Usability eines Produktes. DesignIterationen während des gesamten Entwicklungsprozesses ermöglichen es,
Feedback oder anderweitig gesammelte
Erkenntnisse während der gesamten
Entwicklungsphasen zu berücksichtigen.
Durch die vorgeschaltete ResearchPhase ist es garantiert, dass eine klare
Vision formuliert wird, an der während
der gesamten Projektlaufzeit kontinuierlich gearbeitet wird. Schließlich garantiert die intensive Kundenbeteiligung,
dass die Features so entwickelt werden,
wie sie die Endbenutzer wirklich brauchen.
4.0
Fazit
In dem vorliegenden Paper wurde
das Wissen aus unterschiedlichen Integrationsansätzen des UCD und der agilen
Softwareentwicklung angewandt, und
232
deren wesentliche Gemeinsamkeiten
als Kernaspekte identifiziert und beschrieben. Die resultierenden Folgerungen aus dem Vergleich wurden
anhand eines Anwendungsfalles beschrieben und nun zur Diskussion gestellt. Die Folgerungen stellen keinen
Anspruch auf Vollständigkeit, sondern
sollen bei der Auswahl und Anwendung in der Praxis eine Hilfestellung
bieten.
5.0
Beyer , H.; Holtzblatt, K.; Baker, L. (2004):
An Agile User-Centered Method: Rapid
Contextual Design. In: Lecture Notes in
Computer Science [Extreme Programming
and Agile Methods - XP/Agile Universe
2004]. Heidelberg / Berlin: Springer Verlag.
Buxton, B. (2007) Sketching User Experiences: Getting the Design Right and the
Right Design. Morgan Kaufmann Publ.
Chamberlain, S.; Sharp, H.; Maiden, N.
(2006): Towards a framework for integrating
agile development and user-centered design. Proc. In: Lecture Notes in Computer
Science [Extreme Programming and Agile
Processes in Software Engineering 2006].
Heidelberg / Berlin: Springer Verlag.
Cherry P. (2006): Questions that Sell: The
Powerful Process for Discovering What
Your Customer Really Wants. Mcgraw-Hill
Professional.
Constantine, L. (2002): Process Agility and
Software Usability: Toward Lightweight
Usage-Centered Design. [WWW]
http://www.for
use.com/articles/agiledesign.pdf
[31.05.2008]
ence [8th International Conference on Agile
Processes in Software Engineering and eXtreme Programming]. Heidelberg / Berlin:
Springer Verlag
Kane, D. (2003): Finding a place for discount
usability engineering in agile development:
throwing down the gauntlet. In: Proceedings
of the Agile Development Conference 2003.
IEEE Computer Society
Norman, D. (2006): Why doing user observations first is wrong. In: Interactions Volume 13
(2006). New York: ACM Press.
Patton, J. (2008). Getting Software RITE. In:
Software, IEEE 2008 Volumen 25. IEEE
Computer Society
Patton, J. (2002) Designing Requirements:
Incorporating Usage-Centered Design into an
Agile SW Development Process. In: Lecture
Notes in Computer Science [Extreme programming and agile methods: XP/Agile Universe 2002]. Heidelberg / Berlin: Springer
Verlag.
Pruitt, J.; Adlin, T. (2006): The Persona Lifecycle - Keeping People in Mind Throughout
Product Design. Morgan Kaufmann Publishers
Sy, D. (2007): Adapting Usability Investigations for Agile User-Centered Design. Journal
of Usability Studies
Ungar, J. M.; White, J. A. (20080: Agile user
centered design: enter the design studio-a
case study. In: CHI '08 extended abstracts on
Human factors in computing systems.New
York: ACM Pres
Wolkerstorfer, P.; Tscheligi, M.; Sefelin, R.;
Milchrahm, H.; Hussain, Z.; Lechner, M.;
Shahzad, S. (2008): Probing an agile usability
process. In: CHI '08 extended abstracts on
Human factors in computing systems.New
York: AC
Cooper, A.; Reimann, R. (2007): About
Face 3.0 The Essentials of Interaction Design. Indianapolis: Wiley Publishing Inc
Detweiler, M. (2007): Managing UCD within
agile projects. In: Interactions Volume 14
SPECIAL ISSUE: UX Management (2007).
New York: ACM Press.
Ferreira, J.; Noble, J.; Biddle, R. (2007) UpFront Interaction Design in Agile Development In: Lecture Notes in Computer Sci-
Extreme Gebrauchstauglichkeit: Agile Prozess- und
Softwareentwicklung mit den Mitteln des Usability
Engineering
Hartmut Obendorf
C1 WorkPlace Solutions
Vogt-Kölln-Str. 30
22769 Hamburg
[email protected]
Ronald Naumann
Deutscher Ring
Ludwig-Erhard-Straße 22
20459 Hamburg
[email protected]
Abstract
Agile Entwicklungsmethoden versprechen durch die iterative Entwicklung von
Anforderungen, Bedürfnisse von Kunden
genauer treffen zu können als Ansätze
des „klassischen“ Software-Engineering.
Ausgehend von drei verschiedenen Pro
1.0
Einleitung
Agile Entwicklungsmethoden versprechen nicht nur eine im Gegensatz
zu klassischen Softwareprozessen erhöhte Produktivität, sondern auch die
Ausrichtung von Softwaregestaltung an
Wünschen und Nöten von Kunden und
Endanwendern. Dabei sagen agile Methoden häufig nur wenig darüber aus,
wie diese Anforderungen ausgehandelt
und festgehalten werden oder wie daraus eine Vision für die Systemgestaltung
abgeleitet werden kann. So bleibt den
Anwendern agiler Entwicklungsmethoden viel Interpretationsspielraum.
Gerade für die Kommunikation mit Endanwendern und die Konsolidierung unterschiedlicher Nutzungsvorstellungen
bietet das Usability Engineering (UE)
eine Vielzahl von Methoden an. Das
gewachsene organisatorische Umfeld in
Versicherungen garantiert uns eine Vielzahl technischer Randbedingungen, so
dass ein nicht mit der technischen Umsetzung rückgekoppeltes Design in den
meisten Fällen nicht realisierbar ist – die
Softwareentwicklung schafft so Rahmenbedingungen für das Usability Engineering. Damit wird die enge Integration
von Usability- und Softwareentwicklung,
jekten bei einem deutschen Versicherer berichten wir über unsere Erfahrungen mit der Ermittlung und Entwicklung von Anforderungen. Wir beschreiben das Fördern von Verbindlichkeit
im erweiterten Entwicklungsteam und
den Einsatz von Szenarien.
neben der intensiven Kommunikation
mit den Anwendern die Anpassung
technischer Prototypen im Arbeitskontext notwendig.
der Vollständigkeit (von Spezifikationen)
kommen, der in der Praxis nicht eingehalten werden kann, und im ungünstigsten Fall wird das Einsatzumfeld statisch
betrachtet – und so für Nutzer entwickelt, die es nach dem Ende der Entwicklung nicht mehr gibt, da sich die
Anforderungen durch den Softwareeeinsatz geändert haben.
1.1
Agile Methoden
Mit der Softwarekrise in den
1960er Jahren – die Kosten für Software überstiegen erstmals die von
Hardware – wurde klar, dass die Entwicklung von Software ein sehr teures
und in seiner Komplexität herausforderndes Unterfangen ist. Die Qualität
von Software wurde wichtig (DIN ISO
55350) – zunächst vor allem die innere, die die Beschaffenheit der Software
selbst betrifft, dann auch die äußere,
die die Nutzung und den Einsatz bestimmt.
„Traditionelles“ Software-Engineering,
wie es nicht zuletzt in großen Unternehmen bis heute umgesetzt wird, legt
Wert auf einen geordneten Entwicklungsprozess, der formale Hilfsmittel
einsetzt, um zu dokumentieren, wie
Anforderungen in Software umgesetzt
werden. Vorteile sind damit eine hohe
Nachvollziehbarkeit und Planbarkeit
des Entwicklungsprozesses. Es kann
aber zu Geschwindigkeits- und Reibungsverlusten, zu einem Anspruch
Keywords
Agiles Usability Engineering, Extreme
Programming, Szenarien
„Leichtgewichtige“ oder agile Methoden
legen demgegenüber ein größeres Gewicht auf informelle Kommunikationswege (Beck 1999). Damit versprechen sie
nicht nur eine schnellere Entwicklung,
sondern vor allem schnelle erste Ergebnisse, die Scheitern oder Erfolg eines
Projektes bereits frühzeitig erkennen
lassen. Agile Methoden sind immer iterativ und setzen oft auf evolutionäres
Prototyping, in dem Entwicklung und
Einsatz verschränkt sind. Die praktische
Relevanz agiler Methoden wird immer
größer, neben Scrum (Schwaber 2001)
und FDD (de Luca 2008) hat vor allem
XP (Beck 1999, 2004) eine wichtige
Rolle in der Softwareentwicklung erreicht.
233
1.2
Extreme Gebrauchstauglichkeit –
UE-Techniken und agile Prozesse
Die Kombination von Usability Engineering (UE) und agiler Softwareentwicklung liegt aufgrund der zunehmenden Bedeutung der agilen Methoden
nahe und wird intensiv diskutiert. UE
wird dabei oft als vorbereitende Phase
für die Entwicklung gesehen (z.B.
(Memmel et al. 2006)) – dies birgt jedoch die Risiken des Zeitverlustes für
die Ausführung des UE und des Ausbremsens der agilen Softwareentwicklung (Obendorf & Finck 2007). Die
Integration von UE-Techniken in agile
Methoden ist aufgrund der Phasenbezogenheit des UE nicht trivial (Nebe et al.
2007).
In diesem Beitrag leiten wir aus Schwierigkeiten bei der Umsetzung unserer
Implementation von XP und UE unsere
Forderung nach einer höheren Verbindlichkeit der Anforderungen ab und beschreiben den Einsatz von Szenarien,
um dem zu begegnen. Als Basis dient
ein Prozessmuster, welches auf Szenariotechniken aufsetzt, um die „Stories“
von Extreme Programming (XP) im Kontext zu verankern und die „Konversation
mit dem Kunden“ zu moderieren (Obendorf et al. 2005, Obendorf & Finck
2008).
2.0
Fallbeispiele für agile Entwicklung beim Deutschen Ring
Der Deutsche Ring ist ein traditionelles Versicherungsunternehmen mit
Stammsitz in Hamburg. Zur Unternehmensgruppe gehören neben der Lebens-, Kranken-, Unfall- und Sachversicherung die MoneyMaXX AG, die Deutscher Ring Bausparkasse, die Fondsgesellschaft Financial Services, die Maklermanagement AG, der Deutsche Pensionsring sowie einige große Vertriebsgesellschaften. 2008 belegte der Deutsche Ring Krankenversicherungsverein
a.G. beim Wettbewerb "Deutschlands
234
kundenorientiertester Dienstleister"
den 3. Platz und ist damit Deutschlands kundenorientiertester Versicherer (Handelsblatt vom 28.5.2008).
Versicherungsnehmer oder versicherte
Person beteiligt ist, kundenbezogen und
spartenübergreifend in ihrem aktuellen
Zustand dargestellt werden können.
In der Entwicklung webbasierter Anwendungen wird vom Deutschen Ring
seit zwei Jahren intensiv XP als agile
Vorgehensmethode eingesetzt, wobei
wie in jedem traditionsreichen Unternehmen sehr verschiedene Entwicklungsparadigmen nebeneinander stehen, und so z.B. auch weiterhin in vielen Bereichen Großrechnertechnik und
klassische Softwareentwicklungsmodelle betrieben werden. Dies bringt
mehrere Besonderheiten mit sich, die
eine Anpassung des XP-Prozesses an
die Organisationskultur erforderlich
machen: Projekte werden aufgrund
sehr global formulierter Anforderungen
geplant und beauftragt, oftmals sind
viele verschiedene Abteilungen an
einem Projekt beteiligt und auch die
Kundenrolle ist zumeist auf verschiedene Organisationseinheiten verteilt.
Das Maklerportal ist ein Informationssystem, welches auf die Informationen
von MACS und der elektronischen Kundenakte zugreift und die Bestandsdaten
einzelner Makler für diese bereitstellt.
Damit können Verarbeitungszustand wie
Vertragsdetails aller beim Deutschen
Ring eingereichten Anträge und Verträge vom Makler angefordert werden. Im
Maklerportal ist außerdem noch der
Zugriff auf Werbemittel und Angebotsrechner möglich, um den Makler im Vertrieb zu unterstützen.
Die hier beschriebenen Erfahrungen
stammen aus drei verschiedenen Projekten, die kurz skizziert werden sollen: Das Makler-Auskunft- und Controllingsystem (MACS) ist die zentrale
Informationsplattform für die Betreuer
und Servicemitarbeiter des Maklervertriebs des Deutschen Rings. Stamm-,
Kontakt- und Provisionsdaten der Makler werden aus einer Vielzahl anderer
Systeme und Datenbanken gesammelt
und in MACS angezeigt. Die verschiedenen Bearbeitungsstände der vom
Makler eingereichten Versicherungsanträge und die Aufgaben des Maklerservice bezogen auf die einzelnen
Anträge werden in MACS verwaltet.
Die elektronische Kundenakte (eAkte)
ist als Hauptarbeitsmittel für die Kundenbetreuung im Servicemanagement
angelegt. Es handelt sich dabei um ein
Informationssystem, in dem Daten
aller Verträge, an denen ein Kunde als
Bei MACS wie der eAkte handelt es sich
um Komponenten der hausinternen Informationsplattform iKontakt, das Maklerportal ist eine moderne Eigenentwicklung. Alle drei Anwendungen basieren
trotz sehr unterschiedlicher FrontendTechnologien auf einer gemeinsamen
Serviceschicht, die den Zugriff auf verschiedene Datenbanken und die beim
Deutschen Ring im Einsatz befindlichen
Hostrechnersysteme kapselt.
3.0
Verbindlichkeit
Beim Deutschen Ring wurde und
wird ein großer Teil der Softwareentwicklung nach klassischen Methoden
durchgeführt. Die beschriebenen Projekte waren die ersten, die agil ausgelegt
waren und sich im Vorgehen an einer
Kombination von XP mit Szenariotechniken orientierten (vgl. Obendorf & Finck
2008). Das iterative Vorgehen mit vierwöchigen Iterationsmeetings mit Projektleiter, Auftraggeber, Kunden und Entwickler bedeutete eine Umstellung für
alle Beteiligten. Nach jeder Iteration
wurde eine neue Softwareversion zum
Testen zur Verfügung gestellt und nach
Behebung der aufgetretenen Fehler produktiv eingesetzt. In der konkreten Umsetzung von XP setzen wir den XPlan-
ner1 (www.xplanner.org) für die Verwaltung der Stories und die daraus abgeleiteten Tasks ein, in einem Wiki können
Kunden, Nutzer und Entwickler gleichberechtigt aktuelle und historische Stände
der Stories einsehen und bearbeiten.
Alle beschriebenen Projekte wurden
hausintern mit externer Unterstützung
entwickelt, weshalb die Entwicklungskapazität von Beginn an festgelegt war.
Damit stellt sich jeweils nicht die Frage
nach der Umsetzung aller erfassten Anforderungen, sondern nur danach, welche Anforderungen im Projektrahmen
umgesetzt werden können. Die Herausforderung für unseren Kunden besteht
also darin, die einzelnen Stories zur
Umsetzung im Rahmen der Iterationen
"richtig" zu priorisieren, damit am Ende
die Funktionalität umgesetzt wird, die
wirklich am dringendsten benötigt wird.
Für unsere Kunden macht dieses für sie
neue Vorgehen zunächst Vieles einfacher. Sie können auch noch während
des Projektes Anforderungen beschreiben und zu jeder Iteration in Abhängigkeit vom erreichten Entwicklungsstand
neu priorisieren. Die Folgen von Entscheidungen werden durch die unmittelbare Rückmeldung sichtbar und Korrekturen erfolgen zu Beginn einer jeden
Iteration fast zwangsläufig.
Der Projektstand insgesamt ist für alle
Beteiligten nachvollziehbar, Zeitüberschreitungen sind früher erkennbar. Geeignete Gegenmaßnahmen (Verschiebung einzelner Stories in spätere Releases, Anforderung zusätzlicher Ressourcen) können zielgenauer erfolgen.
Eines der anfänglichen Probleme innerhalb des Projektes MACS bezogen auf
die Vorgehensweise war das heterogene Auftreten der Kunden. So wurden in
den ersten Wochen von unseren Kunden besondere Suchfunktionen und die
1
Auch die Zuweisung der Entwickler zu einzelnen Tasks, Aufwandsschätzungen und
Verbuchung angefallender Aufwände
werden hier vorgenommen.
sehr differenzierte Darstellung von
Kommunikationsdaten der Makler sehr
hoch priorisiert. Im Laufe des Projektes hat sich herausgestellt, dass diese
Funktionen nur von einem engen Nutzerkreis und sehr selten verwandt werden. Gemeinsam mit dem Kunden
konnten wir das Verhältnis der Nutzer
ausgleichen und so die Prioritäten den
Bedeutungen der einzelnen Anforderungen annähern.
3.1
Verbindlichkeit: Vollständigkeit
Die fortlaufende Beschreibung und
Priorisierung von Anforderungen hat
aber auch Nachteile: Unser Kunde
begann, gerade zu wichtigen und damit scheinbar klaren Anforderungen
eine Konsumentenhaltung einzunehmen und die Beschreibung der Anforderung nicht ausreichend auszuführen:
Unser Kunde hat z.B. anstelle einer
vollständigen Beschreibung einer
Funktion lediglich einige wenige Ideen
beschrieben und anhand der erfolgten
Umsetzung im Anschluss seine Beschreibung weiter komplettiert. Notwendiger Klärungsbedarf ging oft zu
Lasten der Entwickler, da die Vollständigkeit der Anforderungen durch deren
Nachfragen und spätere Beschreibung
sichergestellt werden musste.
Vorgehenskonforme, später zu beschreibende Anforderungen ließen
sich in einigen Fällen nicht mehr von
Change Requests (also nachträglichen
Anforderungen) abgrenzen. Damit
nahm die Umsetzung einiger Funktionen ein Vielfaches der geplanten Zeit
in Anspruch. Hinzu kamen weitere
Abstimmungs- und Testaufwände.
Eine wichtige Schlussfolgerung für die
weitere Arbeit mit leichtgewichtigen
Methoden beim Deutschen Ring ist
daher, dass Anforderungen zwar in
anderer Form (Story) und in einem
anderen Kontext (kleinteilig und wo
möglich auch unabhängig voneinander) beschrieben werden sowie zu
einem anderen Zeitpunkt (z.T. nach Beginn des Projektes).
Jede einzelne Story sollte, bevor sie zur
Umsetzung priorisiert wird, so vollständig wie möglich und unter Berücksichtigung aller denkbaren Ausnahmen beschrieben worden sein. In einem traditionellen Entwicklungsprozess entspricht
dies einem Quality Gate; in agilen Prozessen ist die größte Herausforderung
die Identifikation der Kandidaten für
neue Stories, denn für diese muss vor
der Iterationsplanung mit dem Kunden
ein Klärungsprozess eingeleitet werden.
3.2
Erweitertes Entwicklungsteam
Nach unseren Erfahrungen – bestimmt durch die hohe Komplexität des
Projektumfeldes und vielen beteiligten
Stakeholdern – ist die Rollenverteilung
Entwicklerteam vs. Kunde, wie sie in XP
vorgesehen ist, nicht ausreichend. Der
„Kunde vor Ort“, wie er noch in der ersten Version von XP beschrieben wurde,
ist als ein Hauptdefizit von XP ausgemacht worden (z.B. McBreen 2002) und
drückt eine unrealistische Vorstellung
aus. Stattdessen schlagen wir vor, ein je
nach Aufgabe variabel aufgestelltes
erweitertes Entwicklungsteam zu definieren, in dem Kunde und Benutzer
wichtige Rollen ausfüllen: Der Auftraggeber kommt bei uns aus dem gleichen
Bereich wie die Mehrzahl der Benutzer,
ist aber entfernt von den eigentlichen
operativen Anforderungen.
Abb. 1: Erweitertes Entwicklungsteam
235
Der Nutzer erfährt die Fachlichkeit im
Rahmen seiner täglichen Arbeit sehr
genau, kann aber wenig zur zukünftigen
Ausrichtung des Bereichs sagen und
besitzt nicht die Entscheidungskompetenz des Auftraggebers.
Der Spezialist kennt die Fachlichkeit
sehr genau, inkl. aller Ausnahmen,
rechtlicher Bedeutung etc. Er ist aber
nicht Zielgruppe der Software und wird
nicht oder selten damit arbeiten.
Ziel des erweiterten Entwicklungsteams
ist es, für die Beschreibung von Anforderungen eine hohe Verbindlichkeit herzustellen, so dass der Kunde, Anwender
und Spezialist gleichermaßen das Gefühl bekommen, dass ihre Anforderungen berücksichtigt werden.
Mitglieder in diesem Team sind neben
den jeweiligen Entwicklern Vertreter der
drei skizzierten Gruppen. Sie alle haben
gleichberechtigt Zugriff auf die Stories.
Im Vorfeld stellt der Nutzer eine Reihe
von Anforderungen aus Sicht seiner
täglichen Arbeit auf. Er benennt diese
Abläufe und Funktionalitäten. Der Auftraggeber sammelt, priorisiert und fordert von den Entwicklern eine erste grobe Aufwandsschätzung für die aus seiner Sicht wichtigen Punkte an.
Zur inhaltlichen Abstimmung einer konkreten Anforderung treffen sich Auftraggeber, Nutzer, Spezialist und Entwickler
und beginnen, die Story gemeinsam und
detailliert zu beschreiben. Dabei wird
darauf geachtet, dass die Beschreibungen entweder direkt im Wiki vorgenommen werden oder unmittelbar im Anschluss dort erfolgen. Anhand dieser
Beschreibungen wird ein Autor-Kritiker
Zyklus in Gang gesetzt, mit dem Ziel
eine möglichst vollständige Beschreibung der Story zu bekommen.
Das Entwicklungsteam konkretisiert die
Aufwände für die Umsetzung anhand
der detaillierteren Beschreibung und
schafft somit die Voraussetzung, die
236
Abb. 2: Das implementierte Prozessmuster (vgl. Obendorf & Finck 2008)
jeweilige Story in der kommenden Iterationsplanung zu berücksichtigen.
4.0
Anforderungserhebung: Szenarien und Stories
Mittel der Wahl für die Dokumentation von Anforderungen sind in XP
Stories, der Idee nach kurze Geschichten, die eine benötigte Funktionalität
beschreiben (z.B. „ich melde mich an).
Stories sind bewusst unvollständig
gehalten, ihre genaue Ausgestaltung
soll erst im Laufe der Entwicklung und
im Dialog von Kunde / Anwender und
Entwicklerteam verhandelt werden.
Dabei gibt es zwei prinzipielle Schwierigkeiten: zum einen ist die Trennung
der Rollen Kunde / Anwender in XP
nicht konsequent: Da die Verantwortung für die Anforderungen beim Kunden liegt, besteht die Gefahr, an den
Anwendern vorbei zu entwickeln. Auch
ist der Gesamtzusammenhang einer
Story oft unklar, ihr fehlt die Verbindung zur Gesamtvision.
4.1
Entwicklung der Anforderungen
mit Stories
Daher beschreiben wir hier, wie
wir die gemeinsame Erstellung von
Stories und Szenarien einsetzen, um
Anforderungen zu entwickeln und im
Nutzungskontext zu verorten.
XP schlägt vor, die wichtigsten Funktionen eines Systems zu realisieren, um
dann Funktionalität sinnvoll zu ergänzen. Dies birgt aber die Gefahr, keine
ganzheitliche Vorstellung zu entwickeln
und so nur lokal sinnvolle Ergebnisse zu
erreichen (Obendorf & Finck 2008).
Eine einfache Übertragung von UETechniken würde vor dem Beginn eines
XP-Prozesses versuchen, Anforderungen möglichst vollständig zu erfassen.
Will man agil bleiben – und sollen Nutzer
und Entwickler im erweiterten Entwicklungsteam mitwirken, kann aber dabei
nicht einmal annähernde Vollständigkeit
erreicht werden, sondern Kontextanalyse und das Design müssen ebenso iterativ und schrittweise erfolgen. Damit
wird es notwendig, neben den Rohstories, die als „promise for conversation“
(Beck 1999) dienen und eine erste Planung ermöglichen, konsolidierte Stories
als Grundlage für die Entwicklung und
ggf. auch Szenarien für die Kontextualisierung der Stories einzusetzen.
Beim Deutschen Ring gibt es einige
zusätzliche Rahmenbedingungen, die
die Nutzung von Stories bestimmen:
Dadurch, dass nicht alle beteiligten Abteilungen ein agiles Prozessmodell verfolgen, setzte der XP-Prozess immer auf
vorangehenden Planungsschritten auf.
So war die Grobplanung der Projekte
z.T. bei Start schon abgeschlossen; es
lag zwar nie ein vollständiges Anforde-
rungsdokument vor, für das MACSProjekt existierte aber z.B. eine Anforderungsdatenbank, für die sehr grob Aufwände geschätzt worden waren. Für das
Projekt eAkte gab es dagegen nur detaillierte und oft fehlerhafte inhaltliche
Vorgaben, die Spezifikation der Stories
wurde vor Projektbeginn durch die Kunden durchgeführt.
Wir haben ein mehrstufiges Verfahren
zum Erheben und Klären der Anforderungen eingesetzt: von rohen Geschichten, die oftmals nur stichpunktartig die
Vorstellungen der Kundenvertreter beschreiben (und damit bereits die im Vorfeld erhobenen Benutzerwünsche interpretieren und filtern), versuchen wir iterativ und gemeinsam mit den zukünftigen Anwendern zu konsolidierten Stories zu gelangen, die dann nicht nur die
Anforderungen beschreiben, sondern
auch Grundlage für die Abnahme und
Dokumentation des entwickelten Systems sind.
4.2
Arbeitskontext und Gesamtzusammenhang: Stories und Szenarien
Eine wichtige Eigenart unseres XPProzesses ist die Entwicklung von Stories aus einem Rohzustand hin zu einer
brauchbaren Umsetzungsvorgabe und dokumentation. Eine zentrale Rolle
kommt so Szenarien zu, die als kontextuelle Beschreibung der Nutzung von
zukünftiger Funktionalität nicht nur für
die Umsetzung wichtige Details beinhalten, sondern vor allem Nutzungsumfeld und Hintergründe der Nutzung
transportieren. So geben sie einzelnen
Funktionalitäten einen Rahmen, illustrieren gegenseitige Abhängigkeiten und
erhöhen so die Planbarkeit. Ein Szenario kann dabei mit mehreren Stories
verbunden sein und beschreibt Tätigkeiten, die benötigte Funktionalitäten begründen und bestimmen.
Abb. 3: Bezug von Szenarien und Stories.
An anderer Stelle setzen wir Szenarien
ein, um gezielt Defizite, die in Rohstories offensichtlich werden, zu beschreiben. Im Rahmen des Projekts
eAkte nutzt ein Sachbearbeiter z.B. bis
zu fünf verschiedene Auskunftssysteme, in den ursprünglichen Stories waren aber nur die Anforderungen für das
neue System beschrieben. In diesen
Fällen dienen Szenarien vor allem
dazu, den Workflow zu beschreiben
und so die Rationalität von Designentscheidungen offen zu legen.
Nicht immer ist der Einsatz von Szenarien erforderlich – sind etwa nur wenige Stakeholder an einer Entscheidung
beteiligt und hat neue Funktionalität
nur sehr lokale Auswirkungen, belassen wir die mögliche Ausdifferenzierung in der direkten, mündlichen Aushandlung mit dem Benutzer.
5.0
Fazit
Der Einsatz des vorgestellten Vorgehens wird von allen Beteiligten –
auch den Kunden – sehr positiv eingeschätzt. Dennoch sind wir auf Probleme gestoßen, für die wir teilweise Gegenmaßnahmen gefunden haben.
Dazu gehört die Gefahr, dass die stetige Entwicklung zu einem Eindruck
der Unverbindlichkeit führt. Hier haben
wir uns zum einen entschieden, Kunden und Benutzer in einem erweiterten
Entwicklungsteam einzubinden, zum
anderen Qualitätsanforderungen für
die einzelnen Dokumente aufzustellen
und im Entwicklungsprozess Zeitpunkte festzulegen, zu denen eine Mindestqualität erreicht sein muss (Quality
Gates).
Szenarien ergänzen für uns den XPProzess, einerseits, indem sie Stories
verorten und die Planbarkeit erhöhen,
andererseits, indem sie den gemeinsamen Aushandlungsprozess für Anforderungen unterstützen und die Qualität der
Stories nachhaltig verbessern.
5.1
Beck, K. & Andres, C. (2004). Extreme Programming Explained : Embrace Change (2nd
Ed.). Addison-Wesley Professional.
Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison Wesley.
Beck, K., Beedle et al. (2001). Agile Manifesto. http://www.agilemanifesto.org.
Cohn, M. (2004). User Stories Applied: For
Agile Software Development. Addison Wesley.
de Luca, J. (2002). FDD processes.
http://www.nebulon.com/articles/fdd/.
Gundelsweiler, F., Memmel, T., & Reiterer, H.
(2004). Agile Usability Engineering. Mensch &
Computer 2004, München, 33-42.
McBreen, P. (2002). Questioning Extreme
Programming. Pearson Education.
Nebe, K., Düchting, M. & Zimmermann, D.:
Integration von User Centred Design Aktivitäten in Agile Softwareentwicklung. Usability
Professionals 2007.
Obendorf, H. & Finck, M. (2008). ScenarioBased Usability Engineering Techniques in
Agile Development Processes. CHI '08: ACM
Conference on Human Factors in Computing
Systems, Florence, 2159-2166.
Obendorf, H.; Finck, M.; (2007). Szenariotechniken & Agile Softwareentwicklung.
Mensch & Computer 2007 - Interaktion im
Plural. München, 19-28.
Obendorf, H., Finck, M., & Schmolitzky, A.
(2005). Teaching balance and respect. Interactions, 12(5), 36-37.
Schwaber, K. & Beedle, M. (2001). Agile Software Development with SCRUM. Prentice
Hall.
237
238
E loquenz in de r I nt e ra k t i o n
239
240
Wie sag ich’s meinem Anwender?
Vorgehen und Empfehlungen für die Gestaltung von
Meldungen
Richard Oed
Daimler AG
GR/ESP, Prozessgestaltung
Postfach 2360
89013 Ulm
[email protected]
Heiko Ziegler
Daimler TSS GmbH
Bereich Consulting
Wilhelm-Runge-Str. 11
89081 Ulm
[email protected]
Abstract
Das richtige Feedback an den Anwender
kann die Usability eines Systems deutlich beeinflussen. Leider wird diesem
Aspekt bei der Softwareentwicklung
häufig zu wenig Beachtung geschenkt.
Welche Erfahrungen wir dabei in einem
aktuellen Projekt gemacht haben und
welche Lösungsmöglichkeiten erarbeitet
1.0
Motivation
Wer soll das verstehen? Das war
die Frage eines Anwenders an das Projektteam bezogen auf die folgende Fehlermeldung:
Die ausgeführte Aktion führte zu
folgendem Ergebnis:
Die an der Quell-Verwendungsversion
hängende Quell-Stammversion ist keine
Version des der Ziel-Verwendung zugeordneten (Ziel-)Stamms (BATTERIE
SENSOR). Kopieren daher nicht möglich. Bitte selektieren Sie eine Verwendungsversion, die eine korrekte Stammversion referenziert.
Wie konnte das passieren?
Fachexperten, Anwendungsprogrammierer und andere Personen ohne ausreichende Usability-Erfahrung hatten
nach bestem Wissen und Gewissen
Meldungen und Fehlermeldungen für
eine umfangreiche und komplexe Anwendung geschrieben. Aus ihrer Sicht
fachlich korrekt, völlig klar und verständlich und alle Eventualitäten bedenkend.
wurden, zeigt dieser Erfahrungsbericht
auf. Erarbeitet wurden Guidelines zur
Erstellung von Meldungen sowie ein
Gestaltungskonzept zur textuellen und
grafischen Gestaltung aller Hinweis-,
Warn- und Fehlermeldungen im zu
entwickelnden System.
Keywords
Die Anwender verstanden allerdings
nur „Bahnhof“.
x
x
x
Da erst wurde dem Projektteam bewusst, dass dem Aspekt der Anwendungsmeldungen zu wenig Beachtung
geschenkt wurde, die Ersteller der
Meldungstexte völlig allein gelassen
wurden und im Projekt keinerlei Vorgaben für die Erstellung von Meldungstexten existierten, bzw. nicht
bekannt waren.
So erhielten die Autoren den Auftrag,
sich um dieses Thema zu kümmern
und einen Vorschlag für die Erstellung
und Gestaltung von Fehlermeldungen
auszuarbeiten.
2.0
Erfahrungen
Die Erfahrung aus verschiedenen
Projekten zeigt, dass bei der Erstellung von Anwendungen das Feedback
in Form von Meldungen ein häufig
vernachlässigtes Element darstellt.
Hierzu gehören insbesondere Hinweis-, Warn- und Fehlermeldungen die
an den Anwender gerichtet sind.
Diese Meldungen sind oft
Feedback, Fehlermeldungen, Guidelines, Styleguide, Usability Engineering
x
in der Wortwahl inkonsistent,
in der Gestaltung uneinheitlich.
in schlechtem Deutsch geschrieben
und deshalb
nicht oder kaum verständlich.
In den Entwicklungsprojekten wird oft
der Fehler gemacht, dass die Erstellung
der Meldungen erst
x
x
x
in letzter Minute angegangen,
dem Programmier allein überlassen
und
der Inhalt praktisch keinem Review
unterzogen wird.
Das Outsourcing der Softwareentwicklung bringt eine weitere Herausforderung mit sich. So werden Meldungstexte
oft während der Programmentwicklung
von Nicht-Muttersprachlern in Englisch
erstellt und anschließend ins Deutsche
rückübersetzt. Auch dabei kann es zu
erheblichen Verständnisproblemen
kommen.
3.0
Lessons Learned
Dieses wiederkehrende Problem
und unser Lösungsbeitrag in einem aktuellen Projekt, werden in diesem Erfahrungsbericht adressiert.
241
Unsere grundsätzlichen Lessons Learned sind:
x
Es ist wichtig, in einem Projekt frühzeitig das Vorgehen und die Regeln
für das Verfassen von Meldungen
zu definieren und zu kommunizieren.
Von Anfang an ein Glossar aufzusetzen und durchgängig zu verwenden vermeidet unterschiedliche Begrifflichkeiten.
Ab der (fachlichen) Konzeptionsphase sollten Meldungen standardisiert erfasst werden.
Die Überprüfung sowohl der fachlichen als auch der Systemmeldungen sollte sowohl durch UsabilityExperten als auch durch Experten
aus der Anwendungsdomäne erfolgen.
x
x
x
4.0
Erstellung eines Meldungskonzepts
Grundsätzlich empfehlen wir, einen
Prozess zur Erstellung von Meldungen
frühzeitig zu definieren und den beteiligten Rollen zu kommunizieren.
4.1
Rollen
x
x
4.2
1.
2.
3.
x
x
242
4.
Fachbereich
Er kennt die fachlichen Anforderungen und aus seinem Kreise kommen oft die System-Anwender. Er
ist während der Erhebung der
Fachanforderungen beteiligt. Dabei
entstehen oft bereits fachliche Meldungen. Auch steht er bei den späteren Reviews der Meldungen ggf.
für Rückfragen zur Verfügung.
Requirements Engineer
Er entwickelt die Systemanforderungen in Abstimmung mit dem
Fachbereich und erstellt dabei oft
auch Systemkonzepte. In dieser
Phase entstehen mit die meisten
Meldungen.
Implementierer/IT-Dienstleister
Er implementiert das System. Während der Spezifikation und der Imp-
Prozess
Der Usability Engineer hat u.a. die
Aufgabe, im Entwicklungsprojekt einen
Prozess zur Erstellung von Meldungen
aufzusetzen und auf seine Einhaltung
zu achten. Dabei hat sich folgendes
Vorgehen bewährt:
In großen Projekten sind oft die folgenden Rollen beteiligt:
x
lementierung entstehen technische System-Meldungen.
Usability Engineer
Er ist verantwortlich für die Qualitätsabsicherung der Meldungen
und erarbeitet daher das Meldungskonzept und die Guidelines.
Er führt das Review der erarbeiteten Meldungen durch.
Endanwender oder deren Vertreter
Stehen zur Nutzerabsicherung bei
den späteren Reviews der Meldungen für Usability Tests und
ggf. Rückfragen zur Verfügung.
5.
Erarbeitung eines projektspezifischen Meldungskonzepts und Erstellung von Guidelines
Aufsetzen von Glossar und Meldungs-Tabelle/Datenbank
Kommunikation der verbindlichen
Vorgehensweise an alle beteiligten Rollen
Schulung der beteiligten Rollen
(insb. Requirements Engineer)
Planung und Durchführung der
Reviews der Meldungsdatenbank
Exemplarisch sei hier der in unseren
Projekten empfohlene Prozess skizziert:
x
x
x
Standardisierte Erfassung von
Meldungen ab der Erhebung der
Fachanforderungen
Meldungen durch den Requirements Engineer während der Entwicklung der Systemanforderungen unter Berücksichtigung des
Glossars
technischen Systemmeldungen
während der Systemspezifikation
und der Umsetzung durch den IT-
x
5.0
Dienstleister unter Berücksichtigung
des Glossars
Review der Meldungen durch den
Usability Engineer auf die Einhaltung der Guidelines. Ggf. Rückgriff
auf Experten aus der Anwendungsdomäne (Fachbereich), Requirements Engineer oder Endanwender.
Anforderungen an die Benutzerführung insbesondere Meldungen
In der Norm DIN EN ISO 9241-13
[ISO9241-13] werden Verfahren zur
Benutzerführung und Anforderungen an
gute Meldungen beschrieben. Sie enthält Empfehlungen zur:
x
x
x
x
x
x
x
Benutzerführung allgemein
sprachlichen Gestaltung der Benutzerführung
Eingabeaufforderung
Rückmeldung
Statusinformation
Fehlermanagement
Online-Hilfe
Alle diese Aspekte der Benutzerführung
müssen beim Entwurf des Interaktionskonzepts berücksichtigt werden. Wegen
ihrer speziellen Problematik beschränken wir uns in diesem Beitrag auf die
Gestaltung von Meldungen. Unsere
Empfehlungen basieren auf den Normen, der Literatur und unseren Erfahrungen aus zahlreichen Projekten.
5.1
Allgemeine Empfehlungen
Benutzerführung sollte den Benutzer
nicht bei der Aufgabenerledigung stören
oder den Fluss des Dialogs unterbrechen. Grundsätzlich sollten so wenige
Meldungen wie möglich und so viele wie
nötig generiert werden. Dabei ist auf
folgendes zu achten:
x
x
Klare Unterscheidbarkeit zwischen
unterschiedlichen Systemmeldungstypen Æ Abgrenzung: Hinweis/Warn-/Fehlermeldungen
Systemweit einheitlicher Aufbau und
Verhalten. Æ Interaktionskonzept
und Styleguide
x
x
5.2
Systemweit einheitliche Syntax und
Semantik Æ Glossar und Formulierungsleitfaden
Die Formulierung der Meldungen
muss möglichst konkret, präzise,
spezifisch und trotzdem verständlich
sein. Æ Nutzerabsicherung
Grundsätzlicher Aufbau
Eine Systemmeldung an den Nutzer
sollte grundsätzlich kommunizieren:
x
x
x
5.3
Was ist los?
Die Meldung, Beschreibung des Ereignisses bzw. des Zustandes.
Warum?
Erläuterung der Gründe oder möglicher Gründe.
Was kann ich tun?
Mögliche Handlungsoptionen des
Anwenders, falls der Zustand ein
Problem darstellt.
Sprachliche Formulierungen
In der Norm und der Literatur [Heinke 2004] werden zahlreiche Beispiele für
die sprachliche Formulierung von Meldungen gegeben. Dazu gehören u.a.:
x
x
x
x
Das Ergebnis einer Aktion sollte
angegeben werden, bevor beschrieben wird, wie die Aktion ausgeführt wird.
Bsp.: „Um die Eingaben zu verwerfen, drücken Sie die Esc-Taste.“
anstelle von
„Drücken Sie die Esc-Taste, um die
Eingaben zu verwerfen.“
Meldungen der Benutzerführung
sollten so formuliert sein, dass sie
mehr die Benutzerkontrolle als die
Systemkontrolle betonen.
Bsp.: „Zum Speichern Ihrer Änderungen bitte [OK]-Taste drücken.“
anstelle von
„Das System speichert Ihre Änderungen nur, wenn die [OK]-Taste
gedrückt wird.“
Im Allgemeinen sollten Nachrichten
der Benutzerführung positiv formuliert werden und betonen, was zu
tun ist, statt was zu vermeiden ist.
Meldungen sollten grammatikalisch
einheitlich, in kurzen einfachen Sät-
x
5.4
zen und emotional neutralen Worten formuliert werden.
Meldungen sollten entsprechend
der Terminologie formuliert werden, die Benutzer bei der Erledigung der Arbeitsaufgaben typischerweise verwenden.
Einheitliches Vokabular: Glossar
Qualitätsaspekte wie Lernförderlichkeit oder Erwartungskonformität
erfordern Konsistenz in Syntax und
Semantik an der Bedienschnittstelle.
Ein einheitlich verwendetes Vokabular
ist eine Grundvoraussetzung dafür,
und zwar nicht nur für die Anwender
sondern auch für das gemeinsame
Verständnis in größeren Entwicklungsteams. Ein Glossar ist eine Liste von
Wörtern mit Erklärungen, definiert dieses Vokabular zentral und ermöglicht
so eine einheitliche Begriffsverwendung.
6.0
Meldungen
Die in Kapitel 5.2 aufgeführten Bestandteile einer Meldung (Ereignis,
Gründe, Handlungsoptionen) sind jeweils sehr fachspezifisch und können
nachträglich nicht oder nur sehr
schwer nacherhoben werden.
Aus diesem Grund muss bereits bei
der Erhebung der Meldungen diese
Struktur berücksichtigt werden.
6.1
Meldungsdatenbank
Hierfür erweist sich die zentrale und
standardisierte Erfassung aller Meldungen in einem einheitlichen Format
in einer Meldungstabelle oder Meldungsdatenbank als nützlich.
Da bereits bei der Erhebung von fachlichen Anforderungen Fehlerfälle und
damit Gründe und Lösungsmöglichkeiten beschrieben werden, sollte mit der
standardisierten Erfassung von Meldungen bereits mit der Anforderungsanalyse
begonnen werden. Gegebenenfalls werden diese früh erfassten Meldungen im
Laufe der Entwicklung auf mehrere Systemmeldungen aufgeteilt oder umformuliert. Jedoch liegt dann zumindest der
fachliche Hintergrund bereits vor.
Bei der Formulierung der Texte können
Platzhalter sinnvoll sein (z.B. „Datei %1
konnte nicht geöffnet werden.“). Hierfür
ist ein einheitliches Format zur Verwendung von Platzhaltern in den Texten zu
definieren. Dies schließt eine Erläuterung der verwendeten Platzhalter mit ein
(z.B. „%1 = Dateiname der Datei inklusive vollständiger Pfadangabe und Dateityp-Suffix“).
In allen entwicklungsrelevanten Dokumenten (z.B. Lasten-/Pflichtenheft, ITSpezifikation, Schulungsunterlagen)
sollte auf diese Meldungen mit einer
Meldungs-ID referenziert werden. Dies
gewährleistet die Rückverfolgbarkeit
(Traceability) der Meldung zu ihrem Vorkommen im Anwendungskontext. Diese
Information kann bei geplanten Änderungen an den Meldungstexten oder der
Übersetzung in weitere Sprachen sehr
wertvoll sein.
Die standardisierte Erfassung der Meldungen an zentraler Stelle bietet auch
Vorteile bei der Qualitätssicherung, da
der Stand der Reviews bzw. dessen
Ergebnisse direkt in der Datenbank abgelegt werden kann.
6.2
Beispielhafte Struktur
Im Folgenden werden die möglichen
Attribute einer Meldungsdatenbank beschrieben, wie sie sich bewährt hat.
x
x
x
Meldungs-ID
Meldung

Text der Ereignismeldung

Text der Gründe

Text der Handlungsoptionen
Variablendefinition (Platzhalter)
243
x
Schweregrad der Meldung [Fehler,
Warnung, Information]
direkte Interaktion oder sofortige
Aufmerksamkeit durch den Nutzer
erforderlich
Autor/Fachlicher Ansprechpartner
Review-Status [OK, Beanstandet
durch Nutzer/Fachbereich, Korrigiert]
Review Gegenvorschlag
x
x
x
x
Wird das System mehrsprachig entwickelt, empfiehlt es sich, für jede Sprache
in der Datenbank eine eigene Spalte für
den Meldungstext vorzusehen.
7.0
Interaktionskonzept
Unterschiedliche Kategorien von
Meldungen erfordern unterschiedliche
Behandlung durch den Anwender.
Grob kann man Systemrückmeldungen
in folgende Kategorien unterteilen:
x
x
Meldungen in Folge von Aktionen/Funktionsaufrufen oder durch
Änderungen am Systemzustand (die
klassische „Fehlermeldung“)
Meldungen in Folge von Nutzereingaben (schon während der Eingabe)

x
x
durch Formatprüfungen (z.B.
Telefonnummer, Autokennzeichen)
Meldungen in Folge von Pflichtfeldprüfungen.
Hier kann es auch komplexere
Formen geben, z.B. mit Abhängigkeiten zu anderen Attributen,
mit Abhängigkeiten zum Anwendungskontext.
Bestätigungsaufforderungen
Statusinformationen, die den aktuellen Zustand von Systemkomponenten anzeigen.
Zusätzlich zu den Kategorien muss auch
der Schweregrad der Meldungen berücksichtigt werden. Üblicherweise unterscheidet man Fehler, Warnungen und
Hinweise.
244
Auch kann zwischen Meldungen unterschieden werden, die die sofortige
Aufmerksamkeit oder Interaktion des
Anwenders erfordern oder im Ablauf
auch später behandelt werden können.
Die Umsetzung im Interaktionskonzept
der Anwendung ist oft abhängig von
der verwendeten Client-Technologie.
So erfordern z.B. klassische WebAnwendungen zur Auswertung der
Nutzereingabe einen RequestResponse-Zyklus mit dem Server,
wohingegen geeignet programmierte
Web-Anwendungen oder Rich-Clients
dem Nutzer schon während der Eingabe Rückmeldung geben können.
Verwendet man Client-Frameworks
lohnt ein Blick in die entsprechende
Dokumentation oder Guidelines des
Frameworks. Exemplarisch seien hier
die „Eclipse User Interface Guidelines”
[Eclipse UI Guidelines] genannt. Diese
empfehlen die Kommunikation von
Fehlern, die eine explizite Nutzereingabe oder sofortige Aufmerksamkeit
des Nutzers erfordern, mit einem modalen Dialog. Dies zwingt den Nutzer,
davon Notiz zu nehmen und sich dem
Problem anzunehmen. Fehler die dies
nicht erfordern, werden in einer Fehlerliste zusammengestellt. Der Nutzer
kann sich zu geeigneter Zeit darum
kümmern.
8.0
Styleguide und Guidelines zur
Erstellung von Meldungen
Um allen beteiligten Erstellern von
Meldungen konkrete Hilfen an die
Hand zu geben, wurde für das Projekt
ein Styleguide und eine Reihe von
Empfehlungen für die Formulierung
von Meldungen fachlicher Art und für
Systemmeldungen entwickelt und
kommuniziert.
Ziel ist es, die visuelle und sprachliche
Konsistenz und damit verbunden die
Selbsterklärungsfähigkeit und Lernför-
derlichkeit des Systems sicherzustellen.
8.1
Styleguide
Der Styleguide soll die visuelle Konsistenz und den einheitlichen Aufbau der
Meldungen an der Benutzungsoberfläche sicherstellen.
In jedem Fall sollten Schweregrad, Meldung, Grund und Lösungsmöglichkeiten
kommuniziert werden
8.1.1 Syntax
der Meldungen
Jede Nachricht ist nach folgender Struktur aufgebaut:
x
x
x
x
Icon
Meldung
Grund
Lösungsmöglichkeit
Für jedes dieser Strukturelemente gibt
es entsprechende Empfehlungen zur
Gestaltung und zur Syntax.
Icon
Das Icon visualisiert auf den ersten
Blick, um welche Art von Meldung es
sich handelt:
Hinweis
Für reine Mitteilungen und Systemfeedback an den Anwender.
Warnung
Für Meldungen des Anwendungsprogramms, die eine Reaktion des Anwenders benötigen.
Fehler
Für Systemfehler und Anwendungsfehler, die ein Weiterarbeiten ohne Eingriffe
des Anwenders nicht erlauben.
Meldung
[Objekt] [Qualifizierer] [negierte Beziehung].
Beispiel:
Kopieren von „Batterie Sensor“ nicht
möglich.
Grund
[Objekt] [Qualifizierer] [negierte Beziehung].
Beispiel:
Es ist nicht möglich, eine Komponente
zu kopieren, die zu einem anderen
Stamm gehört.
8.2
Den Entwicklern wurden einige
wenige „Goldene Regeln“ zum Verfassen von Meldungen vorgegeben.

Lösungsmöglichkeit:

[Optional] [Lösungsmöglichkeit] [Objekt]
[Qualifizierer] [muss Aktion]

Beispiel:
Bitte wählen Sie eine Version von „Batterie Sensor“ aus, die zum gleichen
Stamm gehört.

8.1.2
GUI
Auch hier gilt, wie beim Interaktionskonzept, dass die grafische Gestaltung oft von der verwendeten ClientTechnologie abhängig ist. Verwendet
man Client-Frameworks lohnt sich daher
ein Blick in die entsprechende Dokumentation oder in die Guidelines des
Frameworks.
Für die aktuelle Anwendung wurde die
klassische Form der Meldung gewählt
und im Styleguide wie folgt dokumentiert:
Guidelines zur Formulierung
der Meldungen

9.0
Im Aktiv, nicht im Passiv formulieren.
Keine doppelte Verneinung.
Einfache Konstruktion der Sätze
(Subjekt, Prädikat, Objekt).
einheitliche Syntax (nicht: „SNR“,
„Sachnummer“, „SNr.“), Glossar
beachten.
Grammatikalisch richtige und vollständige Sätze schreiben. Satzzeichen, Rechtschreibung beachten.
Keine Anzeige von im Kontext
überflüssigen Informationen.
Besonders relevante Merkmale
konsistent hervorheben bzw.
kennzeichnen (beispielsweise
Sachnummern in „Anführungszeichen“ setzen).
Sowohl Meldung, Ursache als
auch die Lösungsmöglichkeit jeweils in einem eigenen Satz beschreiben.
Fazit
Gute und verständliche Meldungen
und Fehlermeldungen unterstützen
und verbessern die Interaktion zwischen Mensch und Maschine. Dabei
ist es besonders wichtig, bereits zur
Anforderungsanalyse das Meldungs-
konzept zu entwerfen und an die Projektbeteiligten zu kommunizieren.
Das in diesem Beitrag vorgestellte Konzept könnte dafür die Basis bilden und
kann projektspezifisch adaptiert werden.
Die Guidelines zur Formulierung von
Meldungen sind allgemein gültig und
stellen eine Best Practice dar.
Häufig sind durch die Wahl der ClientTechnologie, z.B. Java-Swing, .NET
oder Web, das Interaktionskonzept und
der Styleguide schon vorgezeichnet.
Dann kann es aus Gründen der Erwartungskonformität wichtig sein, wesentliche Teile davon zu übernehmen.
Das Schreiben der Meldungen wird einem aber von keinem System abgenommen. Da sind die Kreativität und das
Einfühlungsvermögen der Mitarbeiter
gefragt. Wenn wir versuchen, uns in die
Lage des Anwenders zu versetzen, werden wir Meldungen auch so formulieren,
dass sie für den Anwender verständlich
sind.
10.0
Eclipse UI Guidelines, 2008,
http://wiki.eclipse.org/User_Interface_Guidelin
es
Heineke, A. M. (2004): Mensch-ComputerInteraktion. Leipzig: Fachbuchverlag Leipzig.
ISO 9241-13, Ergonomische Anforderungen
für Bürotätigkeiten mit Bildschirmgeräten, Teil
13: Benutzerführung, Beuth Verlag, 1000-08
Abb. 1: Beispiel einer Warnmeldung mit einfacher Interaktion.
245
Eloquent Design of Human-Computer Interaction
Michael Marek M.A.
ergonomic::on
Biesingerstraße 2
72070 Tübingen
[email protected]
Abstract
Der nachfolgende Artikel beschreibt
einen Ansatz, wie strategische Kommunikationsziele von interaktiven Systemen
während ihrer Entwicklung und Gestaltung identifiziert und definiert werden
können. Strategische Kommunikationsziele zu erreichen, zumindest ihre Erfolgsbedingungen zu beschreiben, ist
nach Auffassung des Autors eine der
zentralen Aufgaben für Konzepter, Designer und Applikationsentwickler.
Die Bewältigung dieser Aufgabe unter
einer rhetorikwissenschaftlichen Perspektive zu systematisieren und die
Ergebnisse für die praktische Verwendung zugänglich zu machen, bildet
den Ausgangspunkt respektive erläutert die Absicht von „Eloquent Design
of Human-Computer Interaction“.
Keywords
Allgemeine Rhetorik, Persuasive Kommunikation, Eloquent Design, User Experience Design, Human-Computer Interaction Design.
-
1.0
Einleitung
Für den Autor beabsichtigen und
ermöglichen interaktive Systeme durch
ihre Benutzungsoberflächen und Interaktionsflächen eine Kommunikation zwischen „Designern“ und „Anwendern“ mit
Hilfe textueller, optischer, akustischer
und haptischer Ausdrucksformen. Im
Fokus einer strategischen
Kommunikation steht dabei ihre Wirkungsintentionalität; Also die Absicht
des „Designers“, die Menschen, die derartige Systeme (be-)nutzen von etwas
zu überzeugen und sie in ihren Meinungen, Einstellungen und Handlungen - im
Sinne der persuasiven Prozessualität zu beeinflussen.
Ob durch das Design der Ausdrucksformen die Emotionen direkt angesprochen
werden können (Norman 2004), oder
Bezeichnungen der Ausdrucksformen
aufgrund empirischer Erhebungen antizipiert und in einem „mentalen Modell“
dokumentiert werden (Garrett 2003),
oder das konzeptionelle Modell hinter
den Ausdrucksformen mittels Hilfetexten
erklärt wird (de Souza 2005), oder persuasive Computertechnologien auf den
Benutzungskontext eingehen (Fogg
246
2003) - Konzepter, Designer und Applikationsentwickler stehen täglich vor
den Herausforderungen zahlreiche
intellektuelle Artefakte und künstliche
Konstruktionen mit den beabsichtigten
Wirkungsintentionen zu vereinen und
diese überzeugend zu vermitteln.
Dazu werden unter Anderem Stilmittel
eingesetzt, die durch persönliche Erfahrungen erlangt wurden, um - mehr
oder weniger - gezielt respektive persuasiv zu kommunizieren. Diese Stilmittel für die praktische Verwendung
zu katalogisieren und zu bewerten,
das heißt ihnen einen Wert im Hinblick
auf bestimmte Kommunikationsziele
und beabsichtigte Wirkungsintentionen
zuzuschreiben, ist die Absicht von
„Eloquent Design“.
Design wird dabei sowohl als Bezeichnung für den (Design-)Prozess, wie für
das (Design-)Ergebnis bei der Entwicklung und Gestaltung von interaktiven Systemen gesehen und Eloquenz
bezeichnet allgemein die Kenntnis und
richtige Anwendung komplexer
(Sprach- und) Stilmittel.
2.0
Kurze Einführung in die Rhetorik
„Der systematische Forschungsgegenstand der Rhetorik sind die mit der
Handlungsrolle Orator verbundenen
humankommunikativen Probleme, und
die Fragestellung ist ausschließlich auf
die Erfolgsbedingungen menschlicher
Kommunikation gerichtet. [...] Unter dem
theoretischen Konstrukt Orator wird dabei ein auf erfolgreiche Kommunikation
eingestellter Kommunikator verstanden.“
(Knape 2005, S. 17).
Folglich ist die rhetorische Praxis die
Beherrschung erfolgsorientierter strategischer Kommunikationsverfahren. Der
als Orator handelnde Mensch kommuniziert, um einem eigenen Anliegen beziehungsweise einem Ziel Geltung zu verschaffen. Die Instanz des Orators ist
nicht mehr an einen einzelnen Menschen und nicht mehr an die mündliche
Redesituation gebunden (Knape 2000).
Unternehmen, Verbände und öffentliche
Institutionen kommunizieren mit stellvertretenden Instanzen als Orator in öffentlichen, privaten oder medialen Räumen.
Räume auf die sie nur bedingt oder gar
keinen Einfluss nehmen können und
insofern hochgradig daran interessiert
sind, sich über ihre Wirkungsintentionen
und das Ergebnis ihrer Kommunikationsbemühungen Klarheit zu verschaffen.
Der Orator wird nachfolgend ebenso als
Instanz der Gemeinschaft von Menschen gesehen, die mit der Entwicklung
und Gestaltung von interaktiven Systemen betreut beziehungsweise beauftragt
werden.
Die Gemeinsamkeit jeglicher wirkungsbedachter Formen der Präsentation von
Informationen mit rhetorisch-orientierten
Reden wird wie folgt gekennzeichnet:
„Rhetorisch wird Rede durch ihre Wirkungsintentionalität, so dass mit ihr nicht
allein der zweckhaft-pragmatisch und
ästhetisch geformte Sprechakt gemeint,
sondern auch die Beziehung zwischen
der sprachlichen Produktion und ihren
Adressaten eingeschlossen ist. Das
bedeutet auch Einbezug der ganzen
Vielfalt von Präsentations- und Schauelementen, also des audiovisuellen [sic!]
Bereichs [...], der [...] eine traditionelle
Domäne der Rhetorik darstellt, rhetorischer Analyse also auch ohne semiotische Hilfskonstruktion zugänglich ist,
weil die Sprache der grundlegende
symbolische Ausdruck des Menschen ist
und alle anderen bewusst gehandhabten
Kommunikationssysteme von ihr abgeleitet sind und sie voraussetzen.” (Ue1
ding & Steinbrink 1994, S. 203f)
Dass es sich zum Beispiel bei einer
Website mit ihrer Repräsentation von
1
Die in der Definition zur Rhetorik auffällige Betonung von wirkungsorientierter, also auf die Überzeugung des Adressaten
hin ausgerichteter Kommunikation, wird
im Zusammenhang mit dem Begriff Persuasion näher erläutert: Die im alltäglichen Sprachgebrauch, besonders im
deutschsprachigen Raum, vorhandene
Unterscheidung zwischen „überreden“
(negativ konnotiert) und „überzeugen“
(positiv konnotiert) spielt in der Rhetorik
keine Rolle, da es sich im günstigsten
Fall immer um wirkungsbedachte, persuasive Sprechakte handelt.
Informationen (Web als HypertextSystem, vgl. Garret 2003) um eine
„sprachliche Produktion” handelt, dass
für deren Produktion die „ganze Vielfalt
[...] des audiovisuellen Bereichs” zu
berücksichtigen ist, dass sie eine auf
Wirkung bedachte Übermittlung von
Informationen, insbesondere mit Hilfe
von Interaktionselementen, darstellt
und dass sie sich als „bewusst gehandhabte(s) Kommunikationssystem”
von der „Sprache als grundlegendem
symbolischen Ausdruck des Menschen
ableitet”, setzt der Autor dieses Artikels voraus und belegt dies unter rhetorikwissenschaflichen Gesichtspunkten (Marek 1999).
3.0
Rhetorik im Kontext
Im Kontext des vorliegenden Artikels wird auf eine detaillierte Rezeption von vorherrschenden Modellen aus
den Disziplinen User Centered Design
(UCD), User Experience Design (UXD)
und Human Computer Interaction Design (HCI) verzichtet, wobei im Folgenden einige Zitate stellvertretend
herausgegriffen und erläutert werden,
die die Verbindungen zur Rhetorik und
somit wesentliche Kreuzungspunkte
für „Eloquent Design“ demonstrieren.
3.1
Rhetorik und UCD
„I have long maintained that the
appropriate way to design a complex
system is to develop a clear, coherent
conceptual model (ideally the same as
the designer's conceptual model) and
to design the system so that the user's
mental model would coincide. I had
always assumed this would be done
through the design of the 'System Image': the artifact plus any auxiliary material, such as manuals and help systems.“ (Norman 2006)
Norman betont die Schwierigkeiten,
intellektuelle Artefakte und künstliche
Konstruktionen dem Anwender zu vermitteln. Rückgriffe auf Hilfsmittel, wie
Benutzungshandbücher und HilfeSysteme, scheinen ihm unumgänglich.
In seiner Rezension von de Souzas
„Semiotic Engineering“ erwähnt er zudem, dass Interaktionen zwischen Personen und Technologien „üblicherweise“
als Kommunikation zwischen Mensch
und Technik gesehen werden:
“It is common to think of interaction between a person and technology as communicating with the technology. De
Souza shows that the real communication is between designer and person,
where the technology is the medium.
Once designs are thought of as shared
communication and technologies as
media, the entire design philosophy
changes radically, but in a positive and
constructive way.“(Norman 2006)
Mit Semiotic Engineering bietet de Souza einen weiteren, rhetorikwissenschaftlich relevanten Anhaltspunkt:
„The ideal of UCD is that the user model
captures the essence of the design model, projected in the system image. The
ideal of semiotic engineering is that designer and user understand each other,
and that users find the designer’s vision
useful and enjoyable.” (Sieckenius de
Souza 2005, S. 7f)
Die Förderung des Verständnisses zwischen den Kommunikationsbeteiligten
und die Akzeptanz (useful and enjoyable) der Absichten des Orators (designer's vision) auf Seiten des Adressaten (user) bedingt für das Design von
interaktiven Systemen unter Anderem
gemeinsame, auf beiden Seiten bekannte und anerkannte Symbole und Zeichen. Das Wissen um diese Symbole
und Zeichen und die „zielreflektierenden
Selektionen und Kombinationen von
semiotischen Mitteln“ markieren einen
wesentlichen Aufgabenbereich für die
rhetorische Praxis:
„Es geht [...] um die theoretisch zu trennenden , analytischen Ebenen von Kode
und Textur. Kodes sind die Symbol- und
247
Zeichenvorräte einer Kommunikationsgemeinschaft, einschließlich ihres Verwendungsregelwerkes. Im Sinne eines
erweiterten Textbegriffs ist eine Text ein
begrenzter und geordneter Zeichenkomplex. Was sich im Bereich der Semiotik solcherart auf zwei diskreten theoretischen Ebenen ansiedeln lässt,
muss für den rhetorischen Zusammenhang handlungstheoretisch transformiert
und in eine produktionstheoretische Betrachtungsweise überführt werden. Der
Grund ist in den operativen Anforderungen der rhetorischen Praxis zu suchen.“
(Knape 2005, S. 19f.)
De Souzas Ansatz ist im wesentlichen
der Theorie verpflichtet und zeigt in den
Beschreibungen weitreichende Möglichkeiten, die sich im Kern auf ausgebaute
Menüführungen und erweiterte HilfeSysteme fokussieren. Eloquent Design
versucht nicht allein das Verständnis für
ein System auf Seiten der Anwender zu
fördern, sondern die Wirkungsintention,
das strategisches Kommunikationsziel
zu vermitteln. Dazu kommen neben textuellen auch andere, eingangs bereits
erwähnte Ausdrucksformen in Betracht.
3.2
Die Wahrnehmung eines Produktes ist
immer subjektiv und von den Normen
und Erwartungen des Benutzers ab-
x
hängig (Hassenzahl 2003). Diese
x
Normen und Erwartungen der Zielgruppe im Vorfeld zu kennen und zu
benennen, ist von zentraler Bedeutung
für den „persuasiven Akt“, der die Änderung von Meinungen, Einstellungen
und Verhalten auf Seiten der Anwender beabsichtigt.
Weiterhin existieren zur Gestaltung
von Produkten mit „gezielter Wirkung“
Methoden, von denen hier exemplarisch Jordans „Kansei Engineering“
aufgegriffen wird; Durch intensive
Marktforschung sollen archetypische
Gestaltungsmerkmale von Produkten
mit ihrer jeweiligen emotionalen Wirkung identifiziert und katalogisiert werden, um sie im Gestaltungsprozess als
Rahmen und Orientierungshilfe für die
Erzielung einer bestimmten Wirkung
zur Verfügung zu haben. Kansei Engineering bildet im Produktdesign seit
längerem eine Grundlage, im Interface- respektive Interaktionsdesign ist
es bisher nur Ansatzweise verwendet
worden (Jordan 2002).
Rhetorik und UXD
Das es sich bei interaktiven Systemen im übergreifenden Sinne immer
auch um „Produkte“ handeln kann, ist
eine etablierte und nachvollziehbare
Annahme. Ein Produkt wiederum ist das
Medium mit dem eine Organisation ein
beabsichtigtes Erlebnis zum Benutzer
transportiert (Kuniavsky 2007).
Nach Einschätzung des Autors ist das
„beabsichtigte Erlebnis“ nicht das Ziel
einer strategischen Kommunikation,
sondern Mittel zum Zweck. Dieses Mittel
so zu gestalten, dass es das originäre
Kommunikationsziel nicht „verdrängt“
oder „überlagert“, erfordert neben dem
Design zusätzliches Wissen über persuasive Techniken und die Reaktionen
darauf auf Seiten der Anwender.
248
Zudem sollten intensive Marktforschungen zur Identifizierung und Katalogisierung archetypischer Gestaltungsmerkmale nach Ansicht des Autors bestehende Kataloge heranziehen, insbesondere im Hinblick auf rhetorikwissenschaftliche und somit erfahrungswissenschaftlich belegte Systematisierungen und Kategorisierungen
von Stilmitteln.
3.3
Rhetorik und Captology
Computertechnologien können
nach Fogg unterschiedliche persuasive Rollen einnehmen, wobei eine Rolle
nicht exklusiv eingenommen werden
muss, sondern eine Überschneidung
der Rollen möglich und beabsichtigt
ist:
x
„tool“ - increases capability
(Werkzeug - steigert Befähigung)
„medium“ - provides experience
(Medium - vermittelt Erlebnis)
„social actor“ - creates relationship
(Akteur - erzeugt Beziehung)
Foggs anschließende Aufzählung von
Wirkungsbereichen - motivation, attitude
change, change in worldview, behavior
change und compliance - dürfen nicht
als singuläre, getrennt voneinander zu
betrachtende Ziele der Überzeugungsverfahren gesehen werden, sondern
immer auch als Abfolge von Änderungen
unter dem Aspekt der „persuasiven Prozessualität“ von Carl Hovland (Kopperschmidt 2000, S. 179f):
1. Änderung der Meinung,
2. der Einstellung und
3. des Verhaltens.
Die „Schnittmenge“ zwischen Computertechnologien und Persuasion bezeichnet
Fogg als „CAPTOLOGY - Computer As
Persuasive TechnOLOGY“ (Fogg 2003).
3.4
Rhetorik und HCI
Buchanan und Boyarski betrachten
HCI unter dem Gesichtspunkt der „persuasiven Rede“. Allerdings grenzen sie
den persuasiven Akt auf die Kommunikation zwischen Mensch und Computer
ein (analog zu Normans „überholter Annahme“ s.o.) und erweitern ihn nicht auf
den Aspekt der Kommunikation zwischen Menschen mit Hilfe des Mediums
Computer: “In other words, HCI is like a
persuasive speech. The user is led into
the computer system and provided with
every support deemed valuable for its
use. A balance of reasoning, implied
voice, and feeling (haptic as well as
emotional) is critical to effective humancomputer communication.” (Buchanan &
Boyarski 1994)
3.5
Zwischenfazit
x
Interaktive Systeme offerieren Kommunikationsschnittstellen zwischen
Menschen.
x
x
x
Interaktive Systeme fungieren zur
Übermittlung von Kommunikationsinhalten als Medien.
Interaktive Systeme agieren zur Erreichung von Kommunikationszielen
persuasiv.
Interaktive Systeme sind somit potentieller Forschungsgegenstand der
Allgemeinen Rhetorik und mit ihrer
Hilfe analysierbar und gestaltbar.
ist es, einen Eindruck seiner Person,
seine Ansichten und seine Handlungsempfehlungen über ein fremdbestimmtes Medium und trotz einem mediumbedingten Widerstandsfaktor gegenüber den Adressaten zu vermitteln.
Setting: Zeitungsartikel, Radio- oder
TV-Sendung, Web als Hypertext.
4.3
4.0
Kommunikative Settings
Medien sind ein zentraler Forschungsgegenstand der Rhetorik, da sie
die „Tragflächen“ für die situationsüberschreitende Kommunikation bieten und
als Bestandteil kommunikativer Settings
betrachtet werden:
„Die klassische Rhetoriktheorie ging
[...] von einem Basis-Setting aus, auf
das sich all ihre Überlegungen konzentrierten: die kommunikative Situation.
Dabei wird vorausgesetzt, dass alle
Kommunikationspartner sich in einer auf
einen Ort konzentrierten Face to faceBeziehung befinden. Die moderne Rhetoriktheorie muss demgegenüber ein
zweites Basis-Setting abstrahieren, um
der Entwicklung der Kommunikationsbedingungen Rechnung zu tragen. Es
handelt sich dabei um die situationsüberschreitende Kommunikation, für die
sich der Begriff Dimission anbietet.“
(Knape 2005, S. 30)
4.1
Unmittelbare Kommunikation
Die Aufgabe des Orators und das
strategische Ziel seiner Kommunikation
ist es, seine Persönlichkeit, seine Ansichten und seine Handlungsempfehlungen vor Ort und in einer selbstbestimmten Situation gegenüber den Adressaten
zu präsentieren und zu vermitteln. Setting: Mündlicher Vortrag, Rede, Diskussion.
4.2
(Multi-)Mediale Kommunikation
strategische Ziel seiner Kommunikation
Multimodale Kommunikation
strategische Ziel seiner Kommunikation ist es, einen Ausdruck seiner Person, seine Ansichten und seine Handlungsempfehlungen über ein mitbestimmtes Medium gegenüber den Adressaten zu repräsentieren und zu
vermitteln bzw. den Anforderungen der
Anwender an eine Applikation zu entsprechen und wenn möglich ihre Meinungen, Einstellungen und Handlungen zu verändern. Setting: Interaktive
Systeme respektive Produkte mit informationstechnologisch basierten
Benutzungsoberflächen.
Ein Medium zu Instrumentalisieren, es
als Mittel zum Zweck einzusetzen,
heißt im Fall von interaktiven Systemen unter Berücksichtigung der Medienkonvergenz nicht allein ein einzelnes, medienformatspezifisches Leistungsprofil für ein kommunikatives Ziel
zu verwenden, sondern eine Kombination von Leistungsprofilen und Ausdrucksformen. Diese Aspekte führen
zum eingangs formulierten Postulat
„[...] Interaktionsflächen (beabsichtigen
und ermöglichen) eine Kommunikation
zwischen „Designern“ und „Anwendern“ mit Hilfe textueller, optischer,
akustischer und haptischer Ausdrucksformen.“
5.0
Rhetorik und Eloquent Design
Die Aufklärung des 18. Jahrhunderts brachte die Nationalisierung der
bisher lateinischsprachigen Rhetorik in
allen europäischen Ländern. So festigte sich in Deutschland der Sprach-
gebrauch "Beredsamkeit", oder "Eloquenz" für die Praxis und "Redekunst",
oder "Rhetorik" für die Theorie der Rede.
(Ueding / Steinbrink 1994)
„Schon die klassische Rhetoriktheorie
konzentrierte sich systematisch auf jene
Probleme, die mit der Erfolg versprechenden Ausarbeitung und Performanz
von Äußerungen des kommunikativ
handelnden verbunden sind. In den textlich kodierten Äußerungen des Orator
sah man von Anfang an das Hauptinstrument der rhetorischen Interventionen.“ (Knape 2005, S. 18)
Betrachtet man Teilaspekte der Performanz, wie zum Beispiel die
Selbstdarstellungs- und Interaktionskompetenz und ihren maßgeblichen
Einfluss auf den persuasiven und erfolgreichen Vortrag innerhalb der „unmittelbaren Kommunikation“, ergeben sich im
Vergleich mit den Überlegungen zur
Entwicklung von interaktiven Systemen
erkennbare Analogien (Kopperschmidt
2000).
Die Momente der ersten Wahrnehmung
werden durch das äußere Erscheinungsbild, das Design geprägt. Zudem
müssen sich Gestaltungsprinzipien auf
Konventionen beziehen, um eine Akzeptanz und ein Verständnis beim Anwender zu erreichen (Hassenzahl 2003) und
um den mediumbedingten Widerstandsfaktors weitestgehend zu reduzieren
(Knape 2000).
Neben dem Design spielen bei interaktiven Systemen die technischen Funktionalitäten eine entscheidende Rolle; Diese als Ausdruck von Kompetenz gegenüber einem Anwender zu demonstrieren,
ist eine weitere Herausforderung für
Konzepter, Designer und Applikationsentwickler. Und diese Demonstration zu
unterstützen und zu betonen, geschieht
wiederum im Zusammenspiel mit dem
Design der Interaktionsflächen. Daraus
lässt sich folgende Dualität formulieren:
Funktion agiert als Ausdruck von Kom-
249
petenz, Design als Ausdruck von Performanz.
5.1
Produktionsstadien einer Rede
Zur Veranschaulichung an welchem
Punkt die Eloquenz eine entscheidende
Rolle spielt, werden nachfolgend die
„klassischen“ fünf Produktionsstadien
einer Rede aufgeführt:
1. Inventio
Auffinden aller nötigen Argumente
und Materialien
2. Dispositio
Gliederung des Stoffes
3. Elocutio (!)
Sprachlich-stilistische Produktion
4. Memoria
Einprägen der Rede
5. Actio
Verwirklichung der Rede
Diese Produktionsstadien bilden das
wichtigste systematische Einteilungsprinzip der Rhetorik. Diese Arbeitsschritte sind grundlegend für jede Art menschlicher Kommunikation und regeln die
Ausarbeitung eines Kommunikationsaktes vom Auffinden der Gedanken bis
zum medialen Vortrag. (Ueding /
Steinbrink 2004).
„Ein wesentlicher Teil der rhetorischen
Theorieanstrengungen ist also zunächst
einmal auf Fragen der Vertextung gerichtet. Verlangt wird dabei vom geschulten Orator ein reflektiertes Produktionskalkül, das sich auf die geschulte Kompetenz zum Einschätzen der Adressaten
und zum Ausschöpfen der Möglichkeiten
aller in Betracht kommenden Textsorten
stützt.“ (Knape 2005, S. 18)
Durch die Rhetorik als eine Erfahrungswissenschaft, die auf kontrollierter und
empirisch nachweisbarer Beobachtung
rhetorischer Sprechakte beruht und die
Geltung der aus ihr gewonnenen Erkenntnisse durch historische Rekonstruktion und die Bildung von Hypothesen über die Systematik und die Regeln
rhetorischen Sprechens zu sichern ver-
250
sucht, kam es zur Katalogisierung
zahlreicher „Mittel“ und „Elemente“
respektive rhetorischer Figuren im
Bereich der „Elocutio“, deren Systematik und Kategorien nach Ansicht des
Autors für „eloquentes Design“ herangezogen werden können.
5.2
Elocutio - Stilprinzipien
Ziel der Elocutio ist die Einkleidung der in der Inventio gefundenen
und in der Disposition geordneten Gedanken (res) durch solche Worte (verba), die den Sprachgebrauchsprinzipien (Tugenden) der Rhetorik entsprechen. (Till & Meuthen 2003) Zu den
elokutionären Tugenden zählen (Ottmers 1996):
1.
Grammatikalisch korrekte Sprache
(Latinitas)
2. Deutlichkeit / Verständlichkeit im
sprachlichen Ausdruck (Perspicuitas)
3. Der „Redeschmuck“ mit spezieller
rhetorischer Figurenlehre (Ornatus)
!
4. Die Angemessenheit der sprachlichen Ausdrucksweise gegenüber
den Inhalten der Rede (Inneres Aptum) und gegenüber der Redesituation (Äußeres Aptum)
Verkürzt zusammengefasst und zur
Einordnung des vorliegenden Ansatzes lägen nach Ansicht des Autors
Latinitas und Perspicuitas im Aufgabenbereich des UCD und insbesondere der Usability, das Aptum im Fokus
des UXD und der Ornatus, mit einer
systematischen Erfassung verschiedener Figuren und Stilmittel, im Bereich des Eloquent Design.
5.3
indem er den Adressaten „angenehm
unterhält“ und seinen Willen durch Einwirkung auf die Affekte beeinflusst.
(Lausberg in Till & Meuthen 2003)
Für diesen Artikel wird lediglich eine
Kategorie von Figuren erwähnt; Beispiele für „Substitutionsfiguren“ sind im Austausch semantischer Ähnlichkeiten Synonym, Metapher, Metonymie, Synekdoche und Antonomasie. Im folgenden
werden zwei dieser Figuren exemplarisch erläutert:
“Synonyme sind als Substitutionsfiguren
nicht die Wiederholung semantisch sehr
ähnlicher Begriffe, sondern meint tatsächlich die Ersetzung eines Wortes
durch ein gleichbedeutendes: Buch >
Werk > Schmöker > Publikation > etc.“
“Eine Metapher basiert auf der Ähnlichkeit zweier Begriffe, wobei es nicht (wie
im Fall der Synonyme) zu einem einfachen, direkten Austausch der Begriffe
kommt, sondern die Übertragung den
bezeichneten Sachverhalt oder Gegenstand in einem neuen, bisher unbekannten oder unbedachten Licht erscheinen
lässt: 'Die Sonne lacht' als Ausdruck für
'angenehm vom wolkenfreien Himmel
scheinend' und 'Wärme' und 'Wohlbehagen' ausstrahlt.“ (Ottmers 1996 S. 166ff)
Die beiden aufgeführten Substitutionsfiguren dienen als stellvertretende Illustration für das umfangreichen Repertoire,
welches die rhetorische Figurenlehre
bietet. Für die Ausarbeitung des vorgestellten Ansatzes wird die Katalogisierung entsprechend zahlreicher Figuren
auf die im Eloquent Design einsetzbaren
Ausdrucksformen und Kommunikationselemente transponiert.
Elocutio - Stilfiguren
Die rhetorische Figurenlehre und
die Theorie der Prosakomposition
werden unter dem Oberbegriff des
Ornatus zusammengefasst. Der Ornatus unterstützt die Wirkungsintention,
6.0
Fazit
Durch die Einflussnahme in der
Produktion von medialen Tragflächen
respektive Benutzungsoberflächen und
Interaktionsflächen kann der Orator mit
seinem Wissen über die Erwartungshaltungen der Anwender einen Beitrag zur
Reduktion eines mediumbedingten Widerstandsfaktors leisten und strategische Kommunikationsziele von interaktiven Systemen auch in einer situationsüberschreitenden Kommunikation erreichen.
Neben den wachsenden Erfahrungen,
welche die an der Entwicklung und Gestaltung von interaktiven Systemen beteiligten Personen im Laufe ihre Berufszeit
immer weiter befähigt auf die Anwender
„einzugehen“ und deren Erwartungshaltungen frühzeitig im Verlauf eines Projekts zu antizipieren, bedarf es nach
Ansicht des Autors einer systematisierten Dokumentation und Katalogisierung
dieser Erfahrungen entlang eines
sprachwissenschaftlich ausgerichteten,
etablierten Kanons.
Eloquent Design kann somit eine methodische Grundlage zur Aus- und Weiterbildung von Konzeptern, Designern
und Applikationsentwicklern bieten und
sie durch einen Katalog von Stilmitteln in
der alltäglichen Arbeit unterstützen. Dabei setzt sich Eloquent Design mit der
geeigneten Anwendung von Stilmittel
auseinander und erleichtert es, die Erfolgsbedingungen zum Erreichen strategische Kommunikationsziele im Sinne
der Persuasion während der Entwicklung und Gestaltung von Interaktionsflächen mit ihren intellektuellen Artefakten
und wirkungsorientierten Botschaften zu
beschrieben.
Zu den in diesem Artikel nicht aufgeführten weiteren Aspekten zählen eine historische Betrachtung der Entwicklung von
Benutzungsoberflächen und Interaktionsflächen wie sie heute im Einsatz sind
und ein Ausblick auf zukünftige Entwicklungen, wenn „Flächen“ immer mehr zu
„Räumen“ werden und sich Kommunikation über diese Medien dann nicht allein
an 2-zweidimensionalen Artefakten oder
dem WIMP-Paradigma entlang vollzieht.
Literaturangaben
Buchanan, R.; Boyarski, D. (1994): Exploring the Rhetoric of HCI. In: Interactions,
Volume 1, Issue 2, New York, USA: ACM,
S. 25-35.
Fogg, B. J. (2003): Persuasive Technology
- Using Computers to Change What We
think and Do. San Francisco, USA: Morgan
Kaufmann Publishers.
Garrett, J.J. (2003): The Elements Of User
Experience - User-Centered design for the
web. New York, USA: AIGA / New Riders.
action. Acting with Technology, Cambridge,
Massachusetts, USA: The MIT Press.
Till, D.; Meuthen, E. (2003): Artikel ›Rhetorische Figur‹. In: Reallexikon der deutschen
Literaturwissenschaft. Hrsg. v. Braungart G.,
Fricke H., Grubmüller K., et al. Bd. 3. Berlin /
NewYork: S. 295-300.
Ueding, G.; Steinbrink, B (1994): Grundriss
der Rhetorik. 3. überarbeitete und erweiterte
Auflage, Stuttgart / Weimar: Metzler.
Hassenzahl, M. (2003): The Thing and I:
Understanding the Relationship Between
User and Product. In: Blythe M., Overbeeke
K. et al. (Hrsg.): Funology - From Usability
to Enjoyment, Dordrecht, NL: Kluwer Academic Publishers, S. 31-42.
Jordan, P. (2002): Designing Pleasurable
Products. London, UK: Taylor & Francis.
Knape, J. (2000): Was ist Rhetorik?. Stuttgart: Reclam.
Knape, J. (Hrsg.) (2005): Medienrhetorik.
Tübingen: Attempto Verlag.
Kopperschmidt, J. (2000): Rhetorische
Anthropologie: Darin: Knape, J. Persuasion
und Kommunikation, W. Fink Verlag, S.
171-181.
Kuniavsky, M. (2007): User Experience and
HCI. Human Computer Interaction Handbook, Lawrence Erlbaum Associates. Entwurf URL:
http://www.orangecone.com/hci_UX_chapte
r_0.7a.pdf.
Marek, M. (1999): Die Rhetorik der Website. Universität Tübingen: Seminar für Allgemeine Rhetorik.
Norman, D. A. (2004): Emotional Design Why We Love (Or Hate) Everyday Things.
New York, USA: Basic Books.
Norman, D. A. (2006): Design as Communication. URL:
http://www.jnd.org/dn.mss/design_as_comu
n.html.
Ottmers, C. (1996): Rhetorik. Sammlung
Metzler, Bd. 283, Stuttgart / Weimar: Metzler.
Sieckenius de Souza, C. (2005): The Semiotic Engineering of Human-Computer Inter-
251
Sprachapplikationen: Qualität durch Standardisierung
Cornelia Hipp
Fraunhofer IAO
Nobelstraße 12
70569 Stuttgart
[email protected]
www.iao.fraunhofer.de
Matthias Peissner
Fraunhofer IAO
Nobelstraße 12
70569 Stuttgart
[email protected]
www.iao.fraunhofer.de
Abstract
Die Branche der Sprachtechnologie entdeckt ein Defizit an standardisierter
Qualitätssicherung von Sprachapplikationen. Unter der Leitung von Fraunhofer
IAO und Initiative Voice Business wurde
eine Qualitätsoffensive ins Leben gerufen, um gemeinsam mit führenden
1.0
Einleitung
Im Rahmen eines Verbundprojekts unter
der Leitung von Fraunhofer IAO und
mind Business Consultants ist ein offener Qualitätsstandard für Sprachapplikationen erarbeitet worden. In einem
interdisziplinären Team von 22 anerkannten Experten wurden Kriterien
sowie Maße und Verfahren zur Erhebung und Optimierung der Qualität von
Sprachapplikationen definiert und beschrieben. Die erarbeiteten Ergebnisse
entsprechen damit einem breiten Konsens innerhalb der deutschsprachigen
Fachszene. Aktuelle Erkenntnisse aus
Wissenschaft und Forschung wurden
dabei ebenso berücksichtigt wie die Anforderungen der Industrie nach Praxistauglichkeit und Wirtschaftlichkeit.
Sprachapplikationen haben ein hohes
Potential, da sie nutzbar im mobilen
Kontext sind, lediglich ein Telefon von
überall als Eingabemedium ist erforderlich und theoretisch bietet Sprachinterkation eine schnelle und intuitive Nutzung, da mittels Sprache direkt gesagt
werden kann, was das Anliegen des
User ist. Weiterhin bietet die Sprachinteraktion für alte Menschen & visuell
eingeschränkte Personengruppen, sowie in Nutzungskontexten, wenn keine
Hände frei sind, ein großes Potential für
252
Experten der deutschsprachigen Fachszene Kriterien, Maße und Verfahren
zur Messung und Optimierung der
Qualität von Sprachapplikationen zu
definieren. Konzepte und Methoden
der Usability spielen dabei eine zentrale Rolle.
Keywords
die Nutzung, sprich wenn die Bedienung eines grafischen User Interfaces
schwer fällt. Doch trotz des großen
Potentials ist die Nutzung in Deutschland hinter ihren Erwartungen geblieben. Eine Studie des Fraunhofer IAO
zeigt diesbezüglich auch die geringe
Akzeptanz von Sprachapplikationen
auf (Peissner, et al., 2006). Ein Ansatz
um die Akzeptanz zu verbessern, ist
die Qualität von Sprachapplikationen
zu erhöhen. Doch anders als in Bereichen der Softwaretechnik oder Ingenieur-Fachdisziplinen, ist innerhalb der
Sprachtechnologie noch keine strukturierte Qualitätssicherung verankert.
Die Frage, welche Besonderheiten
innerhalb eines Entwicklungsprozesses für Sprachapplikationen bestehen
und wie dieser mit hoher Prozess- und
Produktqualität gemeistert werden
kann, fängt die Branche erst an zu
überlegen. Es gibt zwar vereinzelt Literatur zu dieser Thematik (Möller
(2005), Hempel (2008), Dybkiaer et al.
(2007)), dahingegen startet die Branche der Sprachtechnologie nun hingegen gemeinschaftlich diese Thematik
aufzugreifen und hat den Wunsch einen gemeinschaftlichen Konsens zu
bilden. Damit ist die Bestrebung verknüpft eigene Sprachapplikationen von
schlechten Applikationen abzugrenzen
und nach außen mit einer Norm be-
werten zu können. Weiterhin soll mit
Hilfe der Qualitätskriterien eigene
Sprachapplikationen im Vergleich zu
anderen eingeordnet werden können.
Sprachinteraktion, Qualitätskriterien,
Maß, Testverfahren, Voice User Interface
2.0
Vorgehensweise
Um eine hohe Qualität, Realisierbarkeit
und Validität der erarbeiteten Ergebnisse zu gewährleisten und um von Beginn
an eine hohe Akzeptanz im Markt zu
sichern, wurden im Rahmen eines 2tägigen Workshops Experten aus einschlägigen deutschen Unternehmen
beteiligt, die innerhalb der Sprachtechnologie tätig sind.
Zur Vorbereitung des Workshops reichten die beteiligten Experten Position
Papers ein, in denen Qualitätskriterien,
entsprechende Messgrößen sowie Evaluations- und Optimierungsverfahren
beschrieben wurden. Weiterhin konnten
die Experten Dokumente, die aus anderen Projektzusammenhängen oder Publikationen bereits zur Verfügung standen, einreichen, soweit sie für die behandelten Fragestellungen relevant
schienen.
Die Experteneinreichungen wurden von
Fraunhofer IAO ausgewertet, mit dem
Ziel, die folgenden Expertenworkshops
vorzubereiten und eine inhaltliche
Grundlage für die angestrebte Publikation zu schaffen. Die weitere Vorgehensweise zur Konsolidierung der Inhalte des
Dokuments gestaltete sich wie folgt:
2.1
x
Qualitätskriterien
Fraunhofer IAO erarbeitete auf Grundlage der Experteneinreichungen einen
Vorschlag, der während des Workshops
im Plenum diskutiert und verabschiedet
wurde.
2.2
Komponenten einer Sprachapplikation
Im Vorfeld des Workshops kristallisierte
sich Diskussionsbedarf bezüglich einer
Einigung zu den Applikationskomponenten heraus. Verschiedene technische
Realisierungen wurden innerhalb einer
speziell dafür gebildeten Arbeitsgruppe
beleuchtet. Der resultierende Konsens
war, dass die Zuordnung der Maße und
Verfahren mit Hilfe einer funktionalen
Beschreibung erfolgen soll, die unter 3.2
beschrieben ist.
2.3
Themenbereiche
Sehr elementar wurden zu Beginn die
Themenbereiche identifiziert, die relevant für die Qualitätssicherung waren –
stets aus Sicht von Sprachapplikationen:
x
x
Strategie & Business Logik:
Ein wesentliches Erfolgskriterium
einer Sprachapplikation ist deren
wirtschaftlicher Ertrag. Dessen
Messbarkeit sowie die Abschätzung
von zukünftigen Investitionen und
Einsparungspotenzialen sind wesentliche Gesichtspunkte dieses
Themenschwerpunkts.
Sprachtechnologie und Linguistik:
Die Qualität der Sprachtechnologie
ist ein essenzieller Aspekt in der
Nutzung von Sprachapplikationen.
Die zuverlässige Erkennung der gesprochenen Benutzereingaben und
eine verständliche sowie angenehme Sprachausgabe sind zentrale
x
Voraussetzungen für eine komfortable Interaktion.
Dialogplattformen und Integration:
Die Nutzung einer Sprachapplikation setzt deren Erreichbarkeit
grundlegend voraus. Dafür ist die
korrekte Integration der Sprachapplikation und der einzelnen Systemkomponenten in das Gesamtsystem erforderlich. Zusätzlich
lassen Aspekte wie geringe Latenzzeiten oder die Nutzbarkeit
der Sprachapplikationen auch bei
Spitzenbelastungen auf eine sinnvolle technische Umsetzung
schließen.
Voice User Interface und Usability:
Die erfolgreiche und angenehme
Nutzung einer Sprachapplikation
hängt insbesondere auch von der
angemessenen Gestaltung der
Benutzungsoberfläche, dem Voice
User Interface, ab. Aspekte wie
z.B. Wortwahl und Formulierungen
der Systemausgaben oder das
Management von Fehlern sind
dabei relevant.
Diese Gliederung verdeutlicht den
ganzheitlichen Ansatz, welcher innerhalb des Projektes genutzt wurde,
allerdings mit den Prämissen, dass es
sich um Telefoniersprachanwendungen handelt und somit nicht anwendbar auf multimodale Anwendungen ist.
Eine Zuordnung zu einzelnen Applikationstypen wurde ebenfalls noch nicht
vollzogen und als Option für weitere
Schritte aufgenommen.
2.4
Entwicklungsphasen
Um die erarbeiteten Maße und Verfahren dem Entwicklungsprozess zuzuordnen einigte man sich im Vorfeld auf
einzelnen Phasen. Der gewonnene
Konsens war, dass die Erstellung einer
Sprachapplikationen sich in verschiedene Schritte unterteilen lässt, die
folgende Phasen umfasst:
x
x
x
x
Projektvorbereitung & Analyse
Konzept & Design
Implementierung
Integration & Inbetriebnahme
x
Betrieb
Diese einzelnen Phasen sind nicht
streng voneinander getrennt, sondern
werden in einem iterativen Prozess
mehrfach (je nach Bedarf) durchlaufen.
Der Grund hierfür ist die schwere Realisierbarkeit einer linearen Abfolge von
Prozessschritten, da verschiedene Aspekte der einzelnen Phasen erst bei
späteren Schritten aufgedeckt werden.
Durch den iterativen Prozess können
sukzessive Teilergebnisse verbessert
und korrigiert werden. Während aller
Prozessphasen werden zusätzlich kontinuierlich Tests durchgeführt, deren Ergebnisse direkt in die Entwicklung mit
aufgenommen werden. Die Testung
bereits in frühen Phasen verhindert ein
zu spätes Aufdecken von Fehlern.
3.0
Erarbeitete Ergebnisse
Als zentrales Projektergebnis wurden
die wichtigsten qualitätsrelevanten Maße
und Verfahren zur Erhebung und Optimierung der Qualität von Sprachapplikationen identifiziert und beschrieben. In
einer strukturierten Form wurden die
beschriebenen Maße und Verfahren
eingehend charakterisiert und bezüglich
ihres Potenzials für den Praxiseinsatz
und ihrer Wirtschaftlichkeit bewertet.
Diese Übersicht soll dem Profi als Nachschlagewerk dienen und dem interessierten Laien einen umfassenden Überblick bieten.
Ein weiteres Ergebnis des beschriebenen Projekts ist die Verständigung auf
eine gemeinsame Terminologie für zentrale Konzepte im Umfeld der Entwicklung und Qualität von Sprachapplikationen. Zur Förderung eines gemeinsamen
Sprachgebrauchs und zur Steigerung
der Transparenz auch für Laien und
potenzielle Kunden wurde eine generische Systemarchitektur mit den Komponenten einer Sprachapplikation entwickelt. Darüber hinaus wurden die Pha-
253
sen eines Standardentwicklungsprozesses definiert.
Darüber hinaus sind die einzelnen
Qualitätskriterien je nach Zielsetzung
und Applikationsausrichtung unterschiedlich zu priorisieren. Je nach
dem, ob bestehende Dienste automatisiert werden, oder ob durch einen
Mehrwertdienst neue Businesskomponenten eingeführt werden, treten beispielsweise unterschiedliche Kriterien
mehr oder weniger stark in den Vordergrund. Ebenso können sich die
Betreiberziele bezüglich der Gesprächsdauer unterscheiden je nach
dem ob eine effiziente und schnelle
Bearbeitung gewünscht wird oder ob
das Geschäftsmodell einer Entertainment Anwendung auf längere Gesprächsdauer ausgerichtet ist.
Nachfolgend werden die identifizierten
Qualitätskriterien aufgeführt:
x
Abb 1: Leitfaden Qualitätskriterien, Maße und
Verfahren für Sprachapplikationen Qualitätskriterien
Die in diesem Abschnitt aufgeführten
Kriterien zielen auf eine ganzheitliche
Qualitätsbewertung von Sprachapplikationen. Sowohl wirtschaftliche Aspekte
als auch die Qualität der Sprachtechnologie, die Integration einzelner Komponenten sowie die Gestaltung des Voice
User Interfaces werden abgedeckt. Die
Kriterien beziehen sich nicht auf einzelne Komponenten, sondern sind auf die
Bewertung des Gesamtsystems ausgelegt.
Die einzelnen Qualitätskriterien stehen
in engen Wechselbeziehungen. Daraus
ergeben sich teilweise Zielkonflikte, welche die gleichzeitige Erfüllung aller resultierenden Anforderungen einschränken. So kann beispielsweise ein umfangreiches Funktionsangebot zu einer
komplexen Navigationsstruktur führen
und damit die schnelle Zielerreichung
einschränken.
254
x
x
x
x
x
Angemessener Funktionsumfang
und Inhaltsangebot:
»Eine Sprachapplikation ist gut,
wenn die Sprachapplikation durch
ein attraktives und vollständiges
Funktionsangebot einen Mehrwert
für die Kunden schafft.«
Einwandfreie Funktionsfähigkeit
und Leistungsfähigkeit:
wenn ein sicheres, performantes
und fehlerfreies Funktionieren des
Systems gewährleistet ist – auch
bei zu erwartenden Belastungsspitzen.«
Administrierbarkeit und effizienter
Betrieb:
wenn technische Aufwände nach
Inbetriebnahme des Systems minimal gehalten werden können.«
Erweiterbarkeit und Skalierbarkeit:
wenn die Systemarchitektur zukünftige Erweiterungen und Veränderungen leicht ermöglicht.«
Wirtschaftlichkeit:
wenn der Betrieb der Sprachapplikation wirtschaftlich rentabel ist.«
Zuverlässige Erkennung der Benutzeräußerungen:
x
x
x
x
3.1
wenn die Spracherkennung einen
angemessenen Umfang zu erwartender Benutzeräußerungen zuverlässig erkennt.«
Effektives Fehlermanagement:
wenn Erkennungsfehler und Bedienfehler keinen großen Schaden anrichten.«
Effektive und flexible Dialogabläufe:
wenn die Navigationsstruktur die
Benutzer unterstützt, schnell und sicher ihr Ziel zu erreichen.«
Verständliche und zielführende Systemausgaben:
wenn die akustischen Systemausgaben den Benutzer bei der Orientierung und der Formulierung zielführender Äußerungen unterstützen.«
Anmutung und emotionale Adressierung:
wenn eine positive und angemessene Einstellung des Benutzers gegenüber der Sprachapplikation, ihrer
Nutzung und ihres Betreibers erzielt
wird.«
Die Realisierung einer Sprachapplikation
stellt das Zusammenspiel verschiedener
Teilkomponenten dar, die für unterschiedliche Funktionsbereiche innerhalb
der Sprachapplikation verantwortlich
sind. Diese Komponenten wurden innerhalb dieser Qualitätsoffensive nach dem
etablierten Software-Architekturmuster
»Model-View-Control« nach funktionalen
Kriterien aufgeteilt. Dabei wurde bei
Auflistung der Maße und Verfahren angegeben, welchen logischen Bereichen
des Model-View-Control Entwurfsmusters sie zugeordnet sind. Es erfolgte
keine Zuordnung zu einzelnen technischen Komponenten, da diese teilweise
mit der konkreten Implementierung und
der verwendeten technischen Plattform
eng zusammenhängen und deshalb
nicht immer zugeordnet werden können.
Zusätzlich wurde das Model-ViewControl-Konzept für die Bedürfnisse von
Sprachapplikationen erweitert um die
Komponente »Access«. Diese stellt die
Telefonie-Funktionalität dar, welche für
die Verbindungs-Erstellung von einer
Sprachapplikation mit Hilfe des Telefonnetzwerkes notwendig ist.
3.2
Maße
Es wurden gemeinsam 32 Maße erarbeitet, welche den in 2.3 genannten
Themenschwerpunkten »Strategie und
Business Logik«, »Sprachtechnologie
und Linguistik«, »Dialogplattformen und
Integration« und »Voice User Interface
und Usability« zugeordnet wurden. Dabei konnten einzelne Maße auch verschiedenen Themenbereichen zugeordnet werden. Weiterhin wurden bei den
Maßen folgende Beschreibungsmerkmale erfasst:
x
x
x
x
x
x
x
x
Synonyme
Kurzbeschreibung
Auf welche Qualitätskriterien Bezug
genommen wird
Zuordnung zu Applikationskomponenten
Aktueller Praxiseinsatz
Potenzial für Praxiseinsatz
Verfahren, um das Maß zu erheben
Bewertung der Wirtschaftlichkeit
Auszugsweise wird anhand von einem
Beispiel diese Beschreibungsstruktur
verdeutlicht:
3.2.1 Effektives
x
x
x
Fehlermanagement
Synonyme:
Keine
Kurzbeschreibung:
Dieses Maß bewertet die Fehlerrobustheit des Sprachdialogs. Trotz
auftretender Erkennungsfehler kann
das Ziel sicher und mit nur geringem
zusätzlichem Zeitaufwand erreicht
werden.
Zur Erhebung des Maßes werden
die Effizienzeinbußen berechnet, die
sich ergeben, wenn sich ein zusätzlicher Fehler in der Sprachapplikation befindet. Diese Effizienzeinbu-
x
x
x
x
x
x
3.3
ßen werden für alle Fehler berechnet und anschließend aufsummiert. Letztlich wird der Durchschnitt von allen unterschiedlichen
Effizienzeinbußen berechnet, indem die gewonnene Summe
durch die Anzahl der Erkennungsfehler dividiert wird.
Auf welche Qualitätskriterien Bezug genommen wird:
Fehlermanagement, Effektive &
flexible Dialogabläufe
Zuordnung zu Applikationskomponenten:
View
Relevanz Themenschwerpunkte:
Strategie und Business Logik,
Voice User Interface und Usability
Aktueller Praxis-einsatz:
gelegentlich, selten
Potenzial für Praxiseinsatz:
mittel
Verfahren, um das Maß zu erheben:
Logfile-Analyse, unter dem Vorbehalt der verlässlichen Erhebung
der Task Completion. Die erforderlichen Zahlen lassen sich (in kleinerem Maßstab) auch bereits aus
Usability Tests und aus Friendly
User Tests gewinnen. Weitere relevante Verfahren sind das Rapid
Prototyping und der Wizard of Oz
Test.
Bewertung der Wirtschaftlichkeit:
Note 3
Verfahren
Im Rahmen des Workshops wurden
von den Experten 23 Verfahren erarbeitet, mit Hilfe deren die Maße erhoben werden können, welche im vorangegangenen Unterkapitel 3.3 dargestellt sind. Bei der Definition der Verfahren wurde darauf geachtet, alle
Entwicklungsphasen (vgl. Unterkapitel
2.4) einer Sprachapplikationen mit
einzuschließen und auch alle Themenbereiche (vgl. Unterpunkt 2.3). Die
Beschreibungsmerkmale der Verfahren wurden im Vergleich zu denen der
Maße um die folgenden Punkte erweitert:
x
x
x
x
Welche Maße können erfasst bzw.
optimiert werden?
Zuordnung zu Entwicklungsphasen
Reifegrad des Verfahrens
Anforderungen des Verfahrens
Auszugsweise wird analog zu den Maßen nachfolgend eines der insgesamt 23
Verfahren aufgeführt:
3.3.1 Friendly
x
x
x
x
x
x
User Test
Synonyme:
keine
Kurzbeschreibung:
Potentielle Nutzer testen das
System vor Betrieb und agieren
dabei kooperativ. Dieser Test erbringt erste Nutzungsdaten und
Feedback vor der Live Schaltung.
Hier können gravierende Fehler
im Betrieb rechtzeitig erkannt und
behoben werden.
Welche Maße können erfasst
bzw. optimiert werden:
Die gesamte Applikation und alle
Funktionalitäten und Qualitäten
werden getestet, also auch die
Anbindung an Backendsysteme
und beispielsweise Transaktionen. Gegebenenfalls können
auch Teilbereiche bereits in einem frühen Stadium getestet
werden. Zusätzlich können das
Effizienzmaß der Bedienung und
das Maß für effektives Fehlermanagement gemessen werden.
Auf welche Qualitätskriterien Bezug genommen wird:
Funktionalität und Inhaltsangebot, Funktions- und Leistungsfähigkeit, Administrierbarkeit und
Betrieb, Zuverlässige Erkennung,
Fehlermanagement, Effektive &
flexible Dialogabläufe, Verständlichkeit & Zielführung, Anmutung
und Emotion
Zuordnung zu Appliakationskomponente:
Betroffen sind die Spracherkennung, die semantische Analyse,
die Ausgabegenerierung und der
Content & Daten; somit sind Model, View und Control betroffen
Relevanz Themenschwerpunkte:
Strategie und Business Logik,
Voice User Interface und Usabili-
255
x
x
x
x
x
x
4.0
ty; Sprachtechnologie und Linguistik
Zuordnung zu Entwicklungsphasen:
Projektvorbereitung & Analyse,
Konzept & Design sowie Implementierung
Kommentar dazu ist, dass dieses
Verfahren in unterschiedlichen
Projektphasen einsetzbar ist, in
der Regel aber vor dem Live Betrieb eingesetzt wird.
Reifegrad des Verfahrens:
hoch
Aktueller Praxiseinsatz:
immer, Standard
Potenzial für Praxiseinsatz:
hoch
Anforderungen des Verfahrens:
Es muss ein funktionsfähiger Prototyp vorhanden sein. Tests können auf unterschiedlichen Ebenen in unterschiedlichen Stadien
durchgeführt werden: auf reiner
Spracherkennungsebene (Vokabular), auf Dialogebene, auf Anwendungsebene (inklusive
Transaktionen und Interaktion mit
Fremdsystemen).
Bewertung der Wirtschaftlichkeit:
Note 1-2: Allumfassend; Ergebnisse sind wichtig, bevor System
abgenommen werden kann.
Danksagung
Das Verbundprojekt unter der Leitung
Fraunhofer IAO und mind Business
Consultants ist mit freundlicher Unterstützung von Semantic Edge, Sikom,
Sympalog, Telenet und VMA entstanden. Zum erfolgreichen Gelingen möchten wir uns bei den mitwirkenden Experten bedanken: Ludovica De Sio (IBM
Entwicklung GmbH), Dr. Christian Du-
256
gast (zum Zeitpunkt selbstständig), Dr.
Carsten Günther (zum Zeitpunkt IBM
Entwicklung GmbH), Mark Gutmann
(STRATECO GmbH & Co. KG), Dr.
Jürgen Haas (Sympalog Voice Solutions GmbH), Tom Houwing (Voiceandvision B.V.), Markus Kesting (Telenet
GmbH Kommunikationssysteme),
Dietmar Kneidl (Sikom Software
GmbH), Jörn Kreutel (SemanticEdge
GmbH), Dr. Guntbert Markefka (TMobile Deutschland GmbH, VMA), Dr.
Marion Mast (zum Zeitpunkt IBM Entwicklung GmbH), Jürgen Mehring
(Sparda Bank Hamburg eG), Prof. Dr.
Sebastian Möller (Deutsche Telekom
AG Laboratories, TU Berlin), Frank
Oberle (T-Systems Enterprise Services GmbH), Dr. Lupo Pape (SemanticEdge GmbH), Andreas Schaub (Unisys Deutschland GmbH, VMA), Bernhard Steimel (mind Business Consultants), Paul Hubert Vossen (Voice &
Visual Design), Dr. Frank Wanning
(HFN Medien GmbH, VMA)
5.0
Ausblick
Um bestehende Forschungslücken
weiterhin zu schließen und den Nutzwert des ersten Projekts für die Praxis
weiter zu erhöhen, haben sich die Projektbeteiligten entschieden, ihr Vorhaben 2008 weiter voranzubringen und
haben sich bereits auf die thematischen Schwerpunkte der zweiten Forschungsphase geeinigt. Im Mittelpunkt
steht dabei die eingehende Betrachtung unterschiedlicher Applikationstypen und die Erarbeitung eines ent-
sprechenden Merkmalkatalogs. Anschließend soll erarbeitet werden, welche der in der ersten Forschungsphase
identifizierten Methoden sich zur Qualitätsoptimierung für die verschiedenen
Applikationstypen am besten eignen.
Wie bereits im ersten Jahr ist das Ziel
zahlreiche Experten zu gewinnen und
dadurch unter Beteiligung eines möglichst breit aufgestellten Expertenkreises
die Akzeptanz in der Praxis zu erhöhen.
6.0
Dybkjaer, L.; Hemsen, H.; Minker, W.
(2007). Evaluation of Text and Speech
Systems. Dordrecht: Springer.
Hempel, T (Ed.). (2008). Usability of
Speech Dialog Systems. Berlin: Springer-Verlag.
Möller, S. (2005). Quality of TelephoneBased Spoken Dialogue Systems. New
York: Springer Sciene + Business Media.
Peissner, M.; Sell, D.; Steimel, B.
(2006). Akzeptanz von Sprachapplikationen. Stuttgart: Fraunhofer-Institut für
Arbeitswirtschaft und Organisation IAO.
Peissner, M.; Hipp, C.; Steimel, B.
(2007). Qualitätskriterien, Maße und
Verfahren für Sprachapplikationen.
Stuttgart: Fraunhofer-Institut für Arbeitswirtschaft und Organisation IAO.
http://www.hci.iao.fraunhofer.de/de/proje
kte/qualitatskritrien_masse_und_verfahre
n_fur_ sprachapplikationen/index.html
In t eraktion v o n M o rg e n
257
258
Umsetzung von neuen Interaktionskonzepten mit Hilfe der
Wii-Remote – Wii interagiere ich?
Margeritta von WilamowitzMoellendorff
TU Darmstadt
Petersenstraße 30
64287 Darmstadt
[email protected]
www.arbeitswissenschaft.de
Michael Schreiber
TU Darmstadt
Petersenstraße 30
64287 Darmstadt
[email protected]
Ralph Bruder
TU Darmstadt
Petersenstraße 30
64287 Darmstadt
[email protected]
Abstract
Die Spielekonsole Wii wurde schon kurz
nach ihrer Einführung nicht nur zum
Spielen verwendet, sondern hat Wissenschaftler aus aller Welt angeregt die
neuartige Interaktion zwischen Mensch
und Computer in weiteren Anwendungsgebieten zu untersuchen. Durch die diversen technischen Schnittstellen und
die vielfältigen Eingabemöglichkeiten
der Wii-Remote ergeben sich neue Möglichkeiten der Interaktion mit technischen
Systemen. Diese Formen der Interaktion
bieten nicht nur Verbesserungspotenziale hinsichtlich der Intuitivität, sondern
sollen auch den Spielspaß der Wii in
andere Einsatzgebiete transportieren.
1.0
Motivation
Wenn man der Vorhersage von Donald Norman (2007) glauben darf, so
wird einer der neuen Trends für die Zukunft des User Interfaces das „tangible
interface“ und somit eine Rückkehr zu
physikalischen Bedienelementen sein.
Analog zu unserer Umgebung, in der wir
mit physikalischen Gegenständen interagieren, sollen dadurch auch komplexe
Systeme besser zu steuern sein.
Ein Beispiel dafür, wie der Trend von
Graphical User Interfaces hin zur Steuerung über „tangible interfaces“ geht, ist
die Spielekonsole Wii von Nintendo. Bei
diesem neuen Spielekonzept wird die
Steuerung des Spiels alleine durch Bewegungen und Klicks einer Art Fernbedienung, der Wii-Remote, durchgeführt.
Am Institut für Arbeitswissenschaft der
TU Darmstadt wurden verschiedene
Projekte durchgeführt, bei denen die
Wii-Remote eingesetzt wird. Unter
anderem wurde ein interaktives Whiteboard basierend auf der Idee von
Johnny Lee (www.cs.cmu.edu/
~johnny/projects/wii/) gestaltet, durch
Usability-Tests evaluiert und das Eingabegerät in Form eines druckempfindlichen Stifts verbessert. In einem
weiteren Schritt wurde die Möglichkeit
der Gestensteuerung von Software mit
Hilfe der Wii-Remote implementiert.
Diese soll in weitergehenden UsabilityStudien untersucht werden.
2.0
Die Wii-Remote
Die Wii Spielekonsole von Nintendo kam 2006 auf den Markt und revolutionierte den Spielemarkt, indem sie
nicht durch immer realitätsnähere
Graphiken auf sich aufmerksam machte, sondern durch ein völlig neues Interaktionskonzept. Gesteuert wird über
die Wii-Remote, einen „game controller“, der zum einen die Position des
Eingabegerätes in Relation zu zwei
infraroten Lichtquellen (Wii Sensorbar)
bestimmen kann und zum anderen mit
Sensoren ausgestattet ist, welche die
Beschleunigungen in die drei Richtungen eines xyz-Koordinatensystems
aufnehmen können. Durch die WiiRemote ist eine sehr intuitive Steuerung möglich und ein immersives
In dem Beitrag sollen neue Interaktionsformen, die durch die Wii-Remote realisierbar sind, vorgestellt und diskutiert
werden, was unter anderem die Gestensteuerung durch die Wii-Remote beinhaltet. Aktuelle Projekte und UsabilityUntersuchungen und ihre Ergebnisse
werden präsentiert. Die entwickelten
Systeme werden im Vortrag demonstriert und verwendet.
Keywords
Wii-Remote, Gestensteuerung, Whiteboard, Interaktionskonzepte
Spielgefühl entsteht, nicht nur bei Sportarten wie Tennis und Bowling.
Die Wii-Remote ist kabellos und mit
Bluetooth ausgestattet, um Kontakt mit
der Spielekonsole oder einem PC aufzunehmen. Insgesamt sind auf dem
Controller ein „directional pad“1 und weitere acht Knöpfe angebracht, um im
Spiel bestimmte Aktionen zu initiieren.
Zum Einsatz kommt aber insbesondere
der 3-Achsen-Beschleunigungssensor
des Geräts, welcher die Beschleunigung
in die drei Koordinatenrichtungen messen kann. Eine Infrarot-Kamera im Controller errechnet im Bezug zur auf dem
Fernseher/Computer stehenden SensorBar (mit Infrarot-Signal) die Position.
1
Als „directional pad“ wird das Steuerungskreuz genannt, das in die vier Richtungen „hoch“, „runter“, „links“ und
„rechts“ betätigt werden kann.
259
Die Wii-Remote eignet sich insbesondere deshalb für den Einsatz außerhalb
des Spielekontextes, da durch den Zugriff auf eine Vielzahl an Sensoren, die
drahtlose Datenübertragungsmöglichkeit
und die Ein- und Ausgabeschnittstellen
eine einfach Anpassung an Arbeitsumgebungen gegeben ist. So kann durch
die Kamera die Ortung erfolgen, Beschleunigungssensoren sind vorhanden,
die Übertragung der Daten erfolgt kabellos, und dies alles zu einem vergleichsweise geringen Preis.
In einer Reihe von Projekten wurde die
Wii-Remote aus diesen Gründen bereits
auch von Wissenschaftern eingesetzt
und die Möglichkeiten, die sich durch
dieses Gerät ergeben, untersucht. Darunter fallen Projekte, die Wii-Remote in
der Rehabilitation von Patienten einzusetzen oder im künstlerischen Bereich
damit zu experimentieren (Lee et al.
2008). Um die Wii-Remote ist mittlerweile eine ganze Internet-Community entstanden, die neue Anwendungen entwickelt und ihre Erfahrungen und Programme anderen zur Verfügung stellt,
mit Johnny Chung Lee von der Carnegie
Mellon University (http://www.cs.cmu.
edu/~johnny/) als einem der bekanntesten Vertreter.
Gallo et al. (2008) verwenden beispielsweise die Wii-Remote als Werkzeug, um
in 3D-Umgebungen in einem medizinischen Kontext zu interagieren. Eingesetzt wurde die Wii-Remote für die Analyse von drei-dimensional rekonstruierten Organen, die beispielsweise aus
Bildern von Computer-Tomo-graphen
entstehen. Das System wurde jedoch
noch nicht in der Praxis getestet.
Ein weiteres Beispiel ist der Einsatz der
Wii-Remote in einem Multi-Wall Virtual
Reality Theatre (Schou & Gardner
2007), ähnlich einem Cave. In einer
Spiele-Umgebung (Half Life 2) wurde
getestet, wie die Wii Remote eingesetzt
260
werden kann, um sich in einer virtuellen Realität zu bewegen und zu zielen.
Schlömer et al. (2008) setzten die WiiRemote zur Gestensteuerung ein und
beziehen sich dabei auf Vorarbeiten
von Hofmann et al. (2004). Dabei verwendeten sie Hidden-Markov-Modelle,
um vom Nutzer gewählte Gesten zu
trainieren und zu erkennen, die durch
charakteristische Muster von Beschleunigungsdaten identifiziert werden. Schon nach einer kurzen Reihe
von Training-Samples konnten bei
einer Studie mit sechs Probanden
Gesten mit einer Wahrscheinlichkeit
von 90% richtig erkannt werden. Die
Ergebnisse dieser Forschergruppe
werden auch anderen Wissenschaftlern über eine Gesten-Datenbank zur
Verfügung gestellt.
Castelluci und MacKenzie (2008) beschäftigten sich insbesondere mit der
Eingabe von Buchstaben beispielsweise bei Präsentationen oder Entertainment-Situationen. Dafür nutzten sie
das Unistrokes Gesten-Alphabet
(Goldberg & Richardson 1993), bei
dem die besonders häufigen Buchstaben durch eine gerade Linie und die
übrigen Buchstaben durch einen Strich
(auch mit Krümmung) dargestellt werden. Diese Gesten wurden bei der WiiRemote durch das Drücken der BTaste an der Unterseite, die Durchführung der Geste und dann das Loslassen der Taste markiert. In einer webbasierten Studie nahmen 18 Probanden teil, die das System testeten. Dabei wurden die Buchstaben, die mit der
Wii-Remote per Geste gezeichnet
werden sollten nacheinander präsentiert und die entsprechenden Zeiten
pro Buchstabe gemessen. Dabei zeigt
sich, dass die Eingabezeiten sehr kurz
waren und bei 296 bis 481 ms lagen.
Die Ergebnisse waren unabhängig von
der Erfahrung mit der Wii.
3.0
Das Wii-Whiteboard
Für die Präsentation von unterschiedlichen Sachverhalten bei Meetings kommen immer häufiger interaktive
Whiteboards zu Einsatz, auf denen
durch die Projektion eines Beamers die
Präsentation (oder auch die normale
Desktop-Oberfläche) auf einem berührungssensitiven Display zu sehen ist.
Die Interaktion erfolgt in der Regel über
Stifte mit denen das Whiteboard berührt
und gesteuert wird. Diese interaktiven
Whiteboards haben jedoch den Nachteil,
dass sie zum einen mit hohen Anschaffungskosten (ab 800 Euro) verbunden
sind und dass sie zum anderen eine
stark eingeschränkte Mobilität besitzen.
Durch die umfangreiche technische
Ausstattung der Wii-Remote gibt es eine
Möglichkeit, genau ein solches interaktives Whiteboard nachzubauen, wobei die
Kosten nur ein Bruchteil der kommerziellen Lösungen betragen und das System
fast an allen Orten eingesetzt werden
kann. Hierfür sind neben der Software
nur eine Wii-Remote und eine frei bewegliche Quelle, die infrarotes Licht emittiert, erforderlich.
Die Idee für dieses interaktive Whiteboard stammt von Johnny Chung Lee
(www.cs.cmu.edu/~johnny/projects/wii/).
Ziel der Studien am IAD der TUDarmstadt war es, dieses interaktive
Whiteboard nachzubauen, mit Probanden zu testen und ergonomische Verbesserungen umzusetzen.
Dafür wurde zunächst von Tobias
Röglin, Jochen Zaunert und Stefan Zettl
in einem studentischen Design-Projekt
ein Whiteboard nach den im Internet
verfügbaren Plänen gebaut. Das Prinzip
beruht darauf, dass mit einem selbstgebauten Stift, der an der Spitze mit einer
Infrarot-Lichtquelle (IR) ausgestattet ist,
auf einer Fläche, auf der die Projektion
des Beamers zu sehen ist (dies kann ein
Whiteboard, ein Tisch, oder eine andere
Fläche sein) geschrieben werden kann.
Die Reflektion des IR-Lichtpunktes wird
von der Infrarot-Kamera der WiiRemote, die leicht entfernt auf der Seite
steht, detektiert und als Koordinaten an
den Computer via Bluetooth gesandt.
Durch eine vorherige Kalibrierung (ähnlich der eines Touchdisplays) ist das von
Johnny Chung Lee geschriebene Programm in der Lage, den Mauszeiger an
die Stelle, an der der IR-Lichtpunkt erscheint, zu setzen und dort einen Klick
der linken Maustaste zu emulieren. Dafür muss in dieser Version jedoch immer
der Schalter am IR-Stift gedrückt werden, um das Licht zu aktivieren. Denn
wäre dieses immer eingeschaltet, würde
es versehentlich zu Fehlauslösungen
kommen.
Zur Verbesserung der Handhabbarkeit
wurde eine 2.Version des Infrarot-Stifts
entwickelt. Hierbei wurden erstens mehrere IR-LEDs verwendet, die somit für
die Remote-IR-Kamera besser zu registrieren waren. Zweitens wurde der Stift
dahingehend verbessert, dass kein
Druck mehr auf den Schalter nötig war,
um die IR-LEDs zu aktivieren. Es wurde
vielmehr ein Druckschalter vorne in der
Stiftspitze angebracht, der bei Aufdrücken des Stifts auf einer Fläche den
Kontakt herstellte und das Licht aktivierte (siehe Abb.1). So war eine einfachere
Bedienung analog zu einem Stift oder
einem Stück Kreide möglich.
Abb.1: IR-Stift mit druckempfindlicher Spitze
(Stift 2)
Die Benutzerfreundlichkeit des WiiWhiteboards in der herkömmlichen
Form (Stift 1) und in der Erweiterung
mit dem druckempfindlichen Stift (Stift
2) wurden in einer Probandenstudie
(siehe Abb. 2) getestet. Dafür wurden
Aufgaben ausgewählt, wie sie in einem
Meeting auftreten können, bei dem
das interaktive Whiteboard als virtuelles Flipchart fungiert. Aufgaben waren
beispielsweise das Abzeichnen von
einem Graphen und das Aufschreiben
einer kurzen Nachricht. Insgesamt
nahmen 15 Personen (Altersdurchschnitt 28 Jahre, 4 Frauen) teil, 9 testeten die herkömmliche Variante und 6
den druckempfindlichen Stift. Abgefragt wurden nach dem etwa
15minütigen Test eine Reihe von
selbstentwickelten Fragen und Teile
des IsoMetrics-Fragebogens (Gediga
& Hamborg 1999).
nicht lange gedauert, bis ich die Bedienung des Wii-Whiteboards erlernt hatte“
(Stift 1: 3,88; Stift 2: 4,80). Oder „Ich
würde gerne mit dem Wii-Whiteboard
arbeiten“ (Stift 1: 3,63; Stift 2: 4,60).
Insgesamt war das Ergebnis, dass sich
mit sehr einfachen und günstigen Mitteln
ein interaktives Whiteboard mit der WiiRemote nachbauen ließ, welches portabel und für den Einsatz in Meetings geeignet ist. In einer Studie konnte gezeigt
werden, dass die Probanden das System gut beurteilten und akzeptierten,
insbesondere mit der Erweiterung eines
druckempfindlichen Stifts. In einem PilotProjekt konnte das Wii-Whiteboard am
Institut für Arbeitswissenschaft auch
bereits multitouch fähig gemacht werden, da die Wii-Remote bis zu vier IRLichtpunkte unterscheiden kann. Weitere Projekte dazu laufen.
4.0
Abb. 2: Proband bei der Usability-Studie
Die Ergebnisse zeigen, dass das WiiWhiteboard bei den Probanden auf
große Zustimmung stieß. In dieser
ersten Studie können aufgrund der
relativ geringen Anzahl von Probanden
keine statistischen Aussagen getroffen
werden, jedoch zeigen sich klare Tendenzen. Auf einer Skala von 1-5 (mit 5
als beste Ausprägung) wurden die
meisten Items des selbstentwickelten
Fragebogens als sehr positiv beurteilt.
Sehr deutlich war auch die positivere
Beurteilung der ergonomisch verbesserten Stifts mit der druckempfindlichen Spitze. Beispielsweise: „Es hat
Die Wii-Gestensteuerung
Ein zweiter Schritt war es, zu untersuchen, welche weiteren Möglichkeiten
der Steuerung von Systemen mit der
Wii-Remote sich noch ergeben. In vielen
der für die Wii erhältlichen Spiele ist die
Steuerung, beispielsweise eines Tennisschlägers, durch die Simulation der Bewegung (gemessen durch die Beschleunigung und teilweise auch die Position
des Spielers) durch die Wii möglich.
Diese Interaktion durch Bewegung der
Wii-Remote kann als sehr intuitiv bezeichnet werden und ist für die Spieler
leicht zu erlernen, da sie entweder die
Bewegung aus der Realität kennen
(Bsp. Tennis) oder nach einen sehr kurzen Erklärung diese leicht nachahmen
und auch behalten können. Daher war
die Idee, durch die Wii-Remote auch mit
einem Rechner durch Gesten interagieren zu können und diesen darüber zu
steuern. Für diese Art der Interaktion
gibt es bereits erste Projekte (siehe Kapitel 1.1), die eine Reihe von Gesten
261
umgesetzt haben, wie beispielsweise
Schlömer et al. (2008).
Gesten werden von Menschen zum
Zweck der nonverbalen Kommunikation
eingesetzt und sind, anders als Gesichtsausdrücke, nicht angeboren, sondern erlernt und somit abhängig vom
kulturellen Hintergrund. Gesten werden
hier, in dem Kontext der Gestensteuerung, verstanden als eine zeichenhafte
Bewegung der Hand, mit der ein Befehl
gegeben wird, den das System umsetzen soll. Dabei ist die Wii-Remote in der
Hand zu halten und dient als Übermittler
eines Bewegungsmusters im Gegensatz
zu anderen Arbeiten, in denen beispielsweise die Form der Hand die Geste definiert (Zobl et al. 2003). Der Einsatz von Gesten zur Steuerung von Systemen wird in unterschiedlichen Bereichen diskutiert, beispielsweise zur Steuerung für In-Car Devices (Zobl et al.
2003), oder in virtuellen Umgebungen.
Ein weiteres Gebiet kann die Steuerung
von Computersystemen sein, insbesondere die Steuerung von Multimediasystemen (am Computer, oder am Fernseher). Hierauf soll im Folgenden näher
eingegangen werden.
Um eine Gestensteuerung für Computersysteme zu entwickeln wurde von den
Studenten Benjamin Franz und Nils
Schader zunächst analysiert, welche
Tätigkeiten Nutzer bei der Interaktion mit
unterschiedlicher Software durchführen,
so unter anderem bei der Nutzung von
Word, PowerPoint und der Nutzung eines Internet-Browsers. Neben der Befragung von Personen wurden eine Reihe von Probanden auch beobachtet und
die durchgeführten außer-beruflichen
Tätigkeiten am Computer ausgezählt.
262
Abb. 3: Verteilung der außer-beruflichen
Tätigkeiten am Computer
Dabei zeigte sich, dass neben dem
Schreiben mit etwa einem Drittel die
häufigste Tätigkeit das Surfen im Internet (43%) ist (siehe Abb. 3) und
immer wieder gleiche Tätigkeiten, wie
„hoch scrollen“, „runter scrollen“, „Seite
vor“ „Seite zurück“ , „lauter“ und „leiser“ durchgeführt werden, die gut
durch eine Gestensteuerung bedient
werden könnten.
Um Gesten zu gewinnen, die besonders intuitiv sind, wurde eine Studie
durchgeführt, in der Probanden ein
Szenario vorgegeben wurde, in dem
sie mit der Wii-Remote in der Hand
verschiedene Tätigkeiten durch eine
frei gewählte Geste steuern sollten.
Beispielsweise war eine Aufgabe „machen Sie bitte den Ton lauter“, oder
„stoppen Sie die Musik“ oder auch
schwierige Aufgaben wie „kopieren Sie
bitte eine Datei“. Insgesamt wurden 18
aus der Beobachtung und Befragung
als besonders häufig erkannte Tätigkeiten als Aufgabe gegeben. Die 20
Probanden wurden auf Video aufgezeichnet (siehe Abb. 4) und die Bewegungen, die die Leute intuitiv zur Steuerung einer solchen Tätigkeit gewählt
hatten, ausgewertet.
Abb. 4: Aufnahme eines Probanden bei der
Durchführung der Versuche
Bei der Auswertung und Kategorisierung
der Bewegungen zeigt sich beispielsweise bei der Geste für die Tätigkeit
„machen Sie bitte den Ton lauter“, dass
8 Versuchspersonen (40%) eine translatorische Bewegung des Eingabegerätes
nach oben (+Z Richtung, Abb. 5, zweites
Bild von oben), 4 (20%) eine Rotationsbewegung um die Hochachse nach
rechts (-θz-Richtung; Schnicken nach
rechts, Abb. 5, zweites Bild von unten)
und 4 Probanden (20%) eine Kippbewegung nach oben (Abb. 5, unteres Bild)
ausführten. Insgesamt zeigte sich ein
mehr oder weniger konsistentes Bild, bei
dem fast die Hälfe der Probanden die
Aufgabe mit einer translatorischen Bewegung nach oben steuern würden.
Andere Tätigkeiten dagegen zeigten ein
weitaus breiteres Spektrum an Gesten,
die von den Probanden gezeigt wurden,
wie beispielsweise das „Stoppen der
Musik“. 36% der Probanden bewegten
die Wii-Remote in positive z-Richtung
und wieder zurück, was einem kurzen
Antippen, ähnlich der Bedienung eines
Druckschalters, gleich kommt. Die restlichen Probanden zeigten jedoch sehr
unterschiedlichen Gesten, beispielsweise das Zeichnen eines „X“ (wie das
Schließen eines Programms in Windows), andere das Zeichnen eines
Quadrats, wie die Stopp-Taste auf einem Player.
Schritt sollen sie in einer UsabilityStudie mit Nutzern getestet werden.
Dabei soll evaluiert werden, wie intuitiv
und leicht sie zu lernen sind. Die aktuellen Ergebnisse sind auf
www.arbeitswissenschaft.de zu finden.
5.0
Fazit
Mit diesem Artikel soll ein Überblick gegeben werden, welche neuen
Interaktionsarten durch die WiiRemote möglich werden. Dafür sollen
zwei Studien stehen, bei denen die
Wii-Remote eingesetzt wurde, um Systeme zu steuern und eine andere Art
von Interaktion als über Maus und
Tastatur möglich zu machen.
Das interaktive Whiteboard und die
Gestensteuerung mit der Wii-Remote
zeigen, dass mit einfachen Mitteln
Systeme bedient werden können und
ein Bedienelemente aus dem Spielekontext eingesetzt werden kann, um
eine intuitive Bedienung von Systemen
möglich zu machen.
Abb. 5: Oberes Bild: Wii-Remote mit Koordinatensystem, zweites Bild von oben: translatorische Bewegung in z-Richtung, zweites
Bild von unten: Rotation nach rechts, unteres
Bild: Kippbewegung nach oben
Es zeigte sich jedoch deutlich, dass die
meisten Gesten ähnlich waren wie die
Interaktion mit dem Rechner oder mit
anderen elektronischen Geräten und
dass der kulturelle Einfluss eine bedeutende Rolle spielt. Ältere Probanden
zeigten auch ein anderes Verhalten als
jüngere, beispielsweise war bei ihnen
das imaginäre Drehen eines Knopfes
beim Lauter und Leiser stellen, häufiger
verbreitet.
Die von den Probanden am häufigsten
verwendeten Gesten werden zum jetzigen Zeitpunkt modelliert. Im nächsten
Weitere Forschungen in diese Richtung sind natürlich notwendig und weitere Studien sollen Aufschluss über
Effizienz und Akzeptanz der Interaktionskonzepte geben. Interessant ist
auch die Verknüpfung mit weiteren
Eingabe-Modalitäten, sowie die Erweiterung um Ausgabemodi wie Vibration
und Sound, über die die Wii-Remote
verfügt.
Danksagung
Wir danken Tobias Röglin, Jochen Zaunert,
Stefan Zettl, Nils Schader und Benjamin
Franz für ihre Mithilfe an den Projekten.
6.0
Castelluci, S.J.; MacKenzie, I.S. (2008):
UniGest: Text Entry Using Three Degress
of Motion. Extended Abstracts of the ACM
Conference on Human Factors in Comput-
ing Systems – CHI 2008. New York: ACM, S.
3549-3554.
Gallo, L.; De Pietro, G.; Marra, I. (2008): 3D
interaction with Volumetric Medical Data:
experiencing the Wiimote. Proceedings of the
1st international conference on Ambient media and systems, Article No. 14.
Gediga, G.; Hamborg, K.-C. (1999): IsoMetrics: Ein Verfahren zur Evaluation von
Software nach ISO 9241-10. In: Holling, H.;
Gediga, G. (Hrsg.): Evaluationsforschung (S.
195 - 234). Göttingen: Hogrefe.
Goldberg, D.; Richardson, C. (1993): Touchtyping with stylus. Proceedings Interact 1993
and Proceedings CHI 1993, ACM Press, S.
80-87.
Hofmann, F.; Heyer, P.; Hommel G. (2004):
Velocity Profile Based Recognition of Dynamic Gestures with Discrete Hidden Markov
Models. Proceedings of the International
Gesture Workshop on Gesture and Sign Language in Human-Computer Interaction.
Springer: London, S. 81-95.
Lee, J. C.: http://www.cs.cmu.edu/~johnny/
projects/wii/ (letzter Zugriff: 26.5.2008).
Lee, H.-J.; Kim H.; Gupta, G.; Mazalek, A.
(2008): WiiArts: Creating collaborative art
experience with WiiRemote interaction. Proceedings of the 2nd International Conference
on Tangible and Embedded Interaction
(TEI'08), ACM, New York, S. 33-36.
Norman, D. (2007): The next UI breakthrough, Part 2: Physicality. Interactions 14,
4, S. 46-47.
Schou, T.; Gardner, H. J. (2007): A Wii Remote, a Game Engine, Five Sensor Bard and
a Virtual Reality Theatre. OzCHI Proceedings. S. 231-234.
Schlömer, T.; Poppinga, B.; Henze, N.; Boll,
S. (2008): Gesture Recognition with a wii
controller.Tangible and Embedded interaction
2008. S. 11-14.
Zobl, M.; Geiger, M.; Schuller, B.; Rigoll, G.;
Lang, M. (2003): A Realtime System for
Hand-Gesture Controlled Operation of In-Car
Devices. Proceedings of ICME 2003, 4th
International Conference on Multimedia and
Expo, IEEE, Multimedia Human-Machine
Interface and Interaction I, S. 541-544.
263
Gestaltung einer haptischen Navigationshilfe für den
mobilen Bereich
Romy Kniewel
Fraunhofer IAO
Competence-Center HumanComputer Interaction
Nobelstraße 12
70569 Stuttgart
[email protected]
Cornelia Hipp
Fraunhofer IAO
Competence-Center HumanComputer Interaction
Nobelstraße 12
70569 Stuttgart
[email protected]
Abstract
Dieser Beitrag beschreibt relevante Arbeitsergebnisse bezüglich des Konzepts
eines haptischen User Interfaces, das im
Rahmen des EU-Projektes ASK-IT
angefertigt wurde. Es wurde eine mobile
haptische Navigationshilfe für Blinde
konzipiert, ein Prototyp entwickelt und
dieser in Nutzertests evaluiert. Das System basiert auf einem vibrotaktilen
Multidisplay als Interaktionsschnittstelle,
welches an den Handgelenken des Nutzers angebracht wird. Der Ursprung des
1.0
Einleitung
Es gibt Situationen, in denen existierende mobile Navigationshilfen den Bedürfnissen der Nutzer im vorliegenden
Kontext nicht gerecht werden. Die meisten Systeme für körperlich unbeeinträchtige Menschen bieten ihre Informationen
hauptsächlich auf grafischem Wege an.
Der visuelle Sinneskanal ist in der reizintensiven Verkehrsumgebung des Fußgängers jedoch stark beansprucht, und
die Informationsverarbeitung wie auch
die Fortbewegung gehen infolgedessen
oft gehemmt vonstatten.
Alternativ können jene Navigationsgeräte akustische Hinweise geben. Mobilitätshilfen für Blinde kommunizieren
ebenso in dieser Form. Problematisch
wird das jedoch an viel befahrenen
Straßen, wo sprachliche Hinweise
schwerer verstanden werden. Kopfhörer
stellen nur eine bedingte Lösung dar, da
sie den Nutzer von seiner akustischen
Umgebung abschirmen. Für Blinde sind
264
Konzepts liegt in der Unzulänglichkeit
vieler existierender mobiler Navigationsgeräte, die ausschließlich den visuellen und auditiven Sinneskanal
ansprechen, obwohl beide im Nutzungskontext des Fußgängers der
Gefahr der Reizüberflutung ausgesetzt
sind. Für die Erarbeitung der haptischen Schnittstelle wurden Designguidelines zusammengetragen, welche
auch bei der Entwicklung
Anwendung fanden. Die Ergebnisse des
Projektes zeigen eine prinzipiell gute
Erfolgschance einer derartigen haptischen Interaktionsschnittstelle – und das
auch über die Zielgruppe der visuell
beeinträchtigten Nutzer hinaus.
Kopfhörer fast ausgeschlossen, weil
sie sich beim Orientieren stark auf
Umgebungsgeräusche verlassen.
Auch visuell nicht beeinträchtigte Menschen sollten zu ihrer Sicherheit im
Straßenverkehr nicht von dieser Informationsquelle abgeschnitten werden.
tet“ auf Input, ohne die kognitiven Prozesse unnötig zu belasten. Auch lässt
der Tastsinn ungestört das parallele
Arbeiten der anderen Sinne zu. Er ist
resistenter gegenüber Störreizen von
außen als Augen und Ohren. Das sicherlich auch, weil taktile Information in
der Natur des Menschen eine eher untergeordnete Funktion hat und überhaupt seltener vorkommt.
Der beschriebene, im Straßenverkehr
vorherrschende Nutzungskontext initiierte die Berücksichtigung des haptischen Informationskanals für die konzipierte mobile Navigationshilfe. Es
wurde ein haptisches Interface erarbeitet, das Navigationshinweise in vibrotaktiler1 Form ausgibt.
Der Vorteil des haptischen Sinneskanals gegenüber den anderen ist, dass
er auch dann aktiv ist, wenn gerade
keine Reize eintreffen. Die Haut „war-
1
„Vibrotaktil“ sind haptische Reize, die
durch an der Haut induzierte Vibration
verursacht werden, wohingegen „haptisch“ alle Arten der mechanischen Reize, Temperaturreize und Schmerzlokalisation umfasst.
Keywords
Vibrotaktiles Feedback, mobile Navigation, Haptik-Designguidelines, haptische
Interaktionsschnittstelle
2.0
Designguidelines für haptische
Interfaces
Zu Beginn der Idee, eine mobile
haptische Navigationsunterstützung zu
erarbeiten, wurde klar, dass die Haut
ebenso Gesetzmäßigkeiten unterliegt,
wie beispielsweise die Augen. Aus diesem Grund wurden haptische Designrichtlinien zusammengetragen, um dem
Benutzer bei der Konzeption des haptischen Interfaces mit vibrotaktilem Feedback gerecht zu werden. Nachfolgend
werden die wichtigsten davon aufgeführt.
2.1
Empfindungsschwelle und Reizstärke
Ein Vibrationsreiz muss eine bestimmte Intensität aufweisen, damit er
erkannt wird. Seine Empfindungsschwelle ist von verschiedenen Faktoren abhängig (Verillo 1962, 1963, 1965, 1966;
Van Doren 1990), wie beispielsweise
von der Frequenz der Vibration und von
der Körperstelle, an die der Reiz wirkt.
Pauschal kann die Haut – alle Hautpartien zusammengefasst – Frequenzen
zwischen 20 und 500 Hz spüren. Davon
besitzen die Frequenzen von 200 bis
250 Hz die niedrigsten Empfindungsschwellen; werden also am ehesten
wahrgenommen. Am sensibelsten sind
Körperstellen mit unbehaarter Haut, wie
sie an Händen und Fingern vorzufinden
ist. Beispielsweise werden an den Fingerspitzen sinusförmige Vibrationsreize
im optimalen Frequenzbereich von 200
bis 300 Hz bei Hauteindellungen von nur
etwa 1μm erkannt. An Wade und Bauch
beträgt die nötige Reizfläche dagegen 5
bis 6 μm (Deetjen & Speeckmann 1999).
Der Rumpf verlangt eine Frequenz von
mindestens 200 Hz (Sherrik & Cholewiak 1986). Prinzipiell nimmt die Sensibilität für Vibrationsreize in Richtung der
Gelenke gegenüber dem Rest des jeweiligen Körperteils zu.
Ebenso beeinflusst die Wellenform der
Vibration ihre gefühlte Intensität. Am
stärksten wirkt die Rechteck-Wellenform, gefolgt von der Dreieck- und der
Sinus-Wellenform. Der Vibrationsreiz
wird jeweils immer am besten übertragen, wenn sich der Vibrationsmotor in
einer festen Verankerung befindet.
2.2
Vibrotaktile Informationskodierung
Um komplexe Informationen durch
Vibration zu kodieren, ist die Modifikation von Frequenz, Amplitude und Zeitintervall der Vibration möglich, ebenso wie
den Wechsel der Reizstelle.
2.2.1
Subjektiv wahrgenommene Reizstärke
Je höher die Amplitude einer Vibrationsfrequenz ist, als umso stärker
wird die Vibration subjektiv empfunden. Nach Craig (1972) können verschiedene Reizstärken zur Informationskodierung eingesetzt werden. Jedoch sollten nicht mehr als vier Intensitäten, zwischen Wahrnehmungs- und
Schmerzschwelle gelegen, verwendet
werden (ebenda). Es gibt zwei Möglichkeiten die wahrgenommene Reizstärke zu steigern:
x
x
2.2.2
die Verstärkung der Intensität nahe
der Schwelle (Verrillo et al. 1969),
die Vergrößerung der Stimulusfläche (Cholewiak 1979).
Frequenz
Vibrationsreize mit gleicher Amplitude aber verschiedenen Frequenzen
werden als unterschiedlich stark empfunden (Goff 1967). Für die Informationskodierung sollten nicht mehr als
neun verschiedene Frequenzen benutzt werden, wobei der Unterschied
zwischen zwei Frequenzen mindestens 20% betragen sollte.
2.2.3
Zeitintervall
Die Haut besitzt eine hohe Sensibilität gegenüber zeitlich versetzt induzierten Reizen. Sie ist ähnlich stark
wie die des auditiven Systems und
größer als die des visuellen Systems.
Durch den Einsatz eines Aktuators
(z.B. einen Vibrationsmotor) kann man
demnach mittels Vibrationsmuster
Informationen kodieren. Diese Art
Muster werden nach Van Erp et al.
(2002) als „touchstones“ bezeichnet.
Die Pause zwischen Vibrationsreizen
muss mindestens 10 ms betragen, um
die einzelnen Reize gut voneinander
unterscheidbar zu machen (Gescheider 1974, Petrosino & Fucci 1989).
Man sollte dabei nicht vergessen, dass
Vibrationsmotoren einige Zeit benötigen,
bis sie in der gewünschten Frequenz
rotieren.
2.2.4
Platzierung am Körper
Ein System mit mehreren Aktuatoren kann Informationen kodieren, indem
Reize an verschiedenen Stellen des
Körpers induziert werden. In diesen taktilen Mehrfachdisplays spielt die Dichte
der Aktuatoren eine entscheidende Rolle. Eine besonders hohe räumliche Auflösung für taktile Reize haben zum Beispiel die Finger, die Hände und das Gesicht. Grundsätzlich hat der menschliche
Körper eine pauschale räumliche Auflösung von ca. 4 cm, ohne Rücksicht auf
die Körperstelle. Für trainierte Benutzer
(z.B. Blinde) ist die Auflösung tendenziell höher.
2.3
Die Verständlichkeit vibrotaktiler
Interfaces
Taktile Nachrichten müssen selbsterklärend sein. In diesem Sinne führte
Van Erp (2001) den Begriff „vibrocon“
ein. Einem taktilen Reiz Bedeutung einzuverleiben, ist allerdings schwierig,
denn die meisten Menschen sind mit
taktilen Signalen nicht vertraut. Weitere
Schwierigkeiten werden dadurch erzeugt, dass Menschen nicht dazu fähig
sind, taktile Signale über einen längeren
Zeitraum hinweg gleichstark wahrzunehmen. Beim Einsatz vibrotaktiler Multidisplays ist es besonders ratsam, darauf zu achten, dass es nicht zu einer
Überlagerung und Beeinflussung von
Signalen sowie Reizüberflutung kommt
(Van Erp 2002). Des Weiteren gibt es für
Menschen nur begrenzte Möglichkeiten,
die Bedeutung von taktilen Nachrichten
zu erlernen. Entwickelt man vibrotaktile
Nachrichten, ist es daher ratsam, diese
aus bereits bekannten und mit Bedeutung belegten Komponenten aufzubauen.
265
Die Behaglichkeit von vibrotaktilen Reizen
2.4
Taktile Displays wirken naturgemäß
direkt an der Haut. Es ist daher äußerst
notwendig, dass sie einen hohen Tragekomfort über einen längeren Zeitraum
hinweg gewährleisten können, dass sie
ergonomisch und dezent sind. Beim
Design vibrotaktiler Schnittstellen zu
beachten ist, dass Vibrationsmotoren
eine starke Hitze generieren können und
so Schmerzen oder gar Verbrennungen
verursachen könnten. Auf Grund der
Tatsache, dass es kaum möglich ist,
vibrotaktile Stimuli zu ignorieren, sind
gewisse Behaglichkeitsregeln einzuhalten:
x
x
x
x
x
x
Ein zu starker taktiler Reiz kann zu
Unbehagen und Schmerz führen.
Angenehme Stimuli liegen 15 bis 20
dB über der absoluten Reizschwelle.
Amplituden von 0,6 bis 0,8 mm werden als Schmerz wahrgenommen.
Vibrationen an Hand und Arm angelegt sollten immer reduziert sein.
Die kritischsten Frequenzen liegen
um 12 Hz, zwischen 1 und 5 m/s².
Eine Überbelastung mit starker Vibration kann gesundheitsschädlich
sein.
3.0
3.1
Grundaufbau
Die konzipierte Navigationshilfe
besitzt drei Komponenten (Abb 1), die
sich ergänzen und über Bluetooth miteinander kommunizieren:
x
ein Handy, mit
Navigationssoftware, GPS und
digitalem Kompass,
x
x
zwei Armbänder mit je zwei
vibrotaktilen Einheiten,
ein Schrittsensor-Clip zur
Befestigung am Schuh.
Das Handy stellt die intelligente Schaltzentrale des Systems dar. Seine Navigationssoftware wird durch Daten aus
GPS, Kompass und Schrittsensor gespeist. Die Software veranlasst, je nach
Position und Bewegung des Benutzers,
die notwendigen Navigationshinweise an
den vibrotaktilen Einheiten der Armbänder. Die Armbänder werden in einer
vorgegebenen Weise angelegt, da die
Navigationssoftware die fixierte Position
der Vibrationseinheiten voraussetzt. Sie
stellen das eigentliche haptische Interface dar. Ihre Aufgabe ist es, Richtungswechselhinweise durch Vibrationsnachrichten zu übermitteln, so dass der
Nutzer zum gewünschten Zielort manöv-
Konzept der mobilen haptischen
Navigationshilfe
Die im Folgenden beschriebene
konzipierte haptische Navigationshilfe
für den mobilen Bereich wurde am
Fraunhofer IAO – Competence Center
Human-Computer Interaction im Rahmen des EU-Projektes ASK-IT erarbeitet. In ASK-IT wurden verschiedene
Technologien für Menschen mit körperlichen und geistigen Beeinträchtigungen
prototypisch entwickelt, um sie in ihrem
mobilen Leben zu unterstützen. Die ursprüngliche Zielgruppe der Navigationshilfe sind Sehbeeinträchtigte, für die bis
dato keine haptischen Mobilitätstechnologien marktreif entwickelt wurden, die
266
über eine erweiterte Blindenstockfunktion hinausgehen. Nichtsdestotrotz
lagen auch körperlich unbeeinträchtigte Menschen im Blickwinkel dieser
Arbeit. Die durchgeführten InitialEvaluationen wurden vorerst nur mit
sehenden Testpersonen durchgeführt.
Wie bereits erwähnt, könnten auch
körperlich unbeeinträchtigte Menschen
durch den im Straßenverkehr herrschenden Nutzungskontext von einer
haptischen Navigationshilfe profitieren.
Abb. 1: Übersicht über die Komponenten der mobilen haptischen Navigationshilfe
rieren kann. Die Entscheidung für die
physikalische Form der Armbänder basierte auf verschiedenen Gründen:
x
x
x
x
3.2
sie wirken immer direkt auf der Haut,
egal welche Kleidung der Nutzer
trägt,
das Handgelenk hat eine hohe räumliche Auflösung und ist sensibel für
vibrotaktile Reize,
die Platzierung der Reize an den
Extremitäten ist ideal für die Kodierung von Richtungen,
sie sind optisch dezent.
Funktionsweise des vibrotaktilen
Interface
Die Navigationshinweise beruhen
zum großen Teil auf einer Informationskodierung mittels Platzierung am Körper.
Weil das System nicht dazu in der Lage
wäre, automatisch zu erkennen, wo welche Vibrationseinheit sitzt, muss das
Formdesign eindeutig auf das korrekte
Anlegen der Armbänder hinweisen.
Ebenso sollte es ein Verrutschen verhindern. Die Vibrationseinheiten befinden sich, wie in Abbildung 1 erkennbar,
je Arm an der Stelle einer Armbanduhr
und direkt gegenüber, bei den Pulsadern.
Aufgrund der fixierten Position der Vibrationseinheiten, lassen sich insgesamt
acht direkte Bewegungsrichtungen
durch ein einfaches Vibrationsmuster
darstellen (siehe Abb 2). Um beispielsweise darauf hinzuweisen, dass in einem Winkel von 90 Grad nach links abgebogen werden soll, müssen die Vibrationseinheiten 1 und 2 gleichzeitig für
einen bestimmten Moment aktiviert sein.
Um, neben der Veranlassung eines
Richtungswechsels, weitere komplexe
Informationen darzustellen, wurde im
Konzept die Kodierung mittels Zeitintervalle verwendet. Es stellt im Vergleich
zu den anderen Möglichkeiten, wie beispielsweise die Kodierung durch
Abb. 2: Kodierung der Richtungswechselinformationen mittels Platzierung am Körper
unterschiedliche Frequenz, eine geringe Herausforderung für den Nutzer
dar.
In dem entwickelten Konzept wird dem
Nutzer ein Countdown für das Abbiegen in eine andere Richtung angeboten. Der Schrittsensor liefert die notwendigen Daten, damit die Vibrationsintervalle mit der Schrittgeschwindigkeit des Benutzers beginnen können.
Bei Annäherung an die Kreuzung verändert sich das Tempo der Intervalle.
Am Abbiegepunkt angelangt, vibrieren
die entsprechenden Motoren dauerhaft, und das so lange bis der Abbiegevorgang abgeschlossen ist. Das
korrekte Abbiegen wird danach bestätigt, indem die Richtung „geradeaus“
(Vibrationseinheit 1 und 3) angezeigt
wird. Das hier zum Einsatz kommende
Prinzip der Richtungswechselanzeige
mit abschließender Bestätigung, entspricht den von Arthur und Passini
(1990) propagierten und bestätigten
Richtlinien für gutes Design von Orientierungssystemen.
Des Weiteren schlägt das Navigationssystem Alarm, sobald sich der Nutzer in
eine falsche Richtung bewegt. Der Benutzer muss die Erkenntnis des Alarmes
durch Betätigung eines Tasters bestätigen. Erst danach folgen Richtungswechselhinweise zum Durchführen der
Wegkorrektur. Die Bestätigung gewährleistet eine saubere Trennung der unterschiedlichen Handlungen. Es ermöglicht
die einfache Trennung zwischen passiver Informationsaufnahme (z.B. Navigieren mittels Hinweise) und aktiver Informationsabfrage (z.B. Wegkorrektur).
Prinzipiell könnte der Taster mit weiteren
Funktionen belegt werden. Er befindet
sich beim Prototyp auf der linken äußeren Vibrationseinheit.
4.0
Prototyp und Evaluation
Im Rahmen des Projektes wurde
nur das vibrotaktile Interface, genauer
die Navigationsarmbänder, prototypisch
umgesetzt. Es folgen eine Beschreibung
der technischen Umsetzung und ein
Umriss der Evaluation.
267
4.1
Prototyp
Für den Bau der Armbänder wurden
existierende Technologien verwertet, um
sie in den gewünschten Prototyp zu
transformieren. Es wurde ein Wizard-OfOz-Prototyp angefertigt, bei dem der
Testleiter die Funktion der Navigationssoftware übernimmt und die Navigationshinweise manuell von einem Laptop
aus steuert. Außerdem soll erwähnt
werden, dass die Methode des Rapid
Prototyping als Vorbild diente: es sollten
zeitlich und finanziell ökonomisch genügend Erkenntnisse zusammengetragen
werden. Grundsätzlich sollte die Funktionalität des konzipierten haptischen
Interfaces geprüft, und die Resultate für
weitere Entwicklungsschritte bereitgestellt werden.
Die Vibrationseinheiten bestehen aus
einfachen Plastikgehäusen, in denen
jeweils ein Vibrationsmotor, wie er in
handelsüblichen Mobiltelefonen vorkommt, eingefasst wurde. Die Bänder
sind aus elastischem Material gefertigt
und ihr Umfang justierbar.
4.2
Um herauszufinden, inwieweit der
Prototyp dazu in der Lage ist, Fußgänger bei der Wegfindung und Navigation durch die Stadt zu unterstützen,
wurde ein Wizard-Of-Oz Test mit fünf
visuell nicht beeinträchtigten Personen
durchgeführt. Der Test fand im verkehrsberuhigten Außengelände der
Universität Stuttgart (Vaihingen) und
der Universität Weimar statt. Das
Testgelände wurde so gewählt, dass
von den Probanden keine Rückschlüsse auf die korrekte Durchführung der
Aufgaben gezogen werden konnten;
bei der Aufgabe nach links abzubiegen, führte im Augenblick des Abbiegens kein Weg nach links.
Die Fragestellungen der Evaluation
umfassten hauptsächlich:
x
x
x
x
x
Abb. 3: Die prototypischen Navigationsarmbänder, von einer Testperson getragen
Um eine kabellose Kommunikation zwischen dem Prototyp und dem TestleiterLaptop zu ermöglichen, wurde auf eine
433-MHZ-Funkverbindung zurückgegriffen, wie sie in Steuergeräten von Spielkonsolen vorkommt.
268
Evaluation
5.0
Können die Vibrationseinheiten
voneinander differenziert werden?
Ist die Richtungskodierung intuitiv
verständlich oder schnell erlernbar?
Können einzelnen Vibrationsmustern bestimmte Bedeutungen (z.B.
Alarm) zugeordnet werden?
Können die Testpersonen mit Hilfe
der vibrotaktilen Navigationshinweise navigieren? Unterstützt dabei der Abbiege-Countdown?
Welche Probleme treten hinsichtlich der Verständlichkeit und Nutzbarkeit der Navigationshinweise
auf?
Ergebnisse und Ausblick
Während des Projektes und im
Zuge der Evaluation zeigte sich, dass
weitere Design- und Entwicklungsarbeit nötig ist, um die konzipierten Navigationsarmbänder zu einem ausgereiften Stadium zu bringen. Insbesondere im Produktdesign schlummert
noch einiges Potenzial zur Verbesserung der Ergonomie und des Trage-
komforts, der Robustheit sowie der
Übertragung der Vibration auf die Haut.
Ferner stellte sich heraus, dass die Vibrationsstärke vom Benutzer veränderbar
sein muss. Er sollte auch die Funktionalität des Navigationssystems entsprechend seiner Wünsche anpassen können. Des Weiteren scheint eine individuelle Auswahl der zu verwendenden
Vibrationsmuster möglich. Beispielsweise scheint es höchst angebracht, dass
der Abbiege-Countdown ein- oder ausgeschaltet werden kann, denn die Meinungen der Testpersonen darüber variierten sehr. Das Alarmsignal wurde
durch seine Ähnlichkeit zu akustischen
Alarmen (abwechselnd Vibration an und
aus) sofort verstanden, was darauf hinweist, dass bekannte Muster aus anderen Wahrnehmungsbereichen beim Design von Vibrationsmustern zu Rate gezogen werden können.
Nichtsdestotrotz konnte die Evaluation
zeigen, dass das Konzept der haptischen Navigationshilfe grundsätzlich
funktioniert. Die Vibrationseinheiten
konnten größtenteils differenziert werden. Auch die Richtungskodierung wurde verstanden und als nachvollziehbar
bewertet. Zudem hat sich offenbart,
dass, auch wenn Vibrationsmuster nicht
sofort verstanden werden, ihre Bedeutung erlernt werden kann. Prinzipiell
könnten noch komplexere „vibrocons“
entwickelt werden. Wichtig dabei ist,
dass die Muster ausreichend verschieden sind und die Anzahl nicht die Erinnerungs- und Leistungsfähigkeit des
Nutzers übersteigt.
Die freie Navigation gemäß der Navigationshinweise bedurfte einiger Übung,
jedoch verbesserte sich die Performance der Probanden mit jedem Durchgang,
so dass auf eine erlernbare Nutzung
geschlossen werden kann.
Da als Testpersonen nicht-blinde Menschen eingesetzt wurden, bedarf es weiterer Evaluation mit Blinden, um die Gül-
tigkeit der Ergebnisse für diese Zielgruppe auszudehnen. Trotzdem wurde
deutlich, dass selbst Menschen, die taktile Informationen normalerweise nicht
verwenden, ihre Nutzung erlernen könnten.
Schlussendlich ist zu sagen, dass dieses Projekt nur den Anfang der Entwicklung einer haptischen Navigationshilfe
darstellt. Weitere Entwicklungsschritte
sind erforderlich. So scheint die Zielgruppe der Fahrradfahrer, aufgrund ihres Nutzungskontextes, ebenso möglich.
Danksagung
Ich danke dem Fraunhofer IAO für die Ermöglichung des Projektes und Cornelia Hipp für
die Betreuung. Zudem danke ich Prof. Jens
Geelhaar für die Unterstützung seitens der
Bauhaus-Universität Weimar.
6.0
Arthur, P.; Passini, R. (1990): Wayfinding:
People, Signs, and Architecture. Toronto:
McGraw-Hill Ryerson.
Cholewiak, R.W. (1979): Spatial factors in the
perceived intensity of vibrotactile patterns.
Sensory Processes, Vol. 3, S. 141-156.
Craig, J.C. (1972): Difference threshold for
intensity of tactile stimuli. Perception & Psychophysics, Vol. 11, Nr. 2, S. 150-152.
Deetjen, P.(Hrsg.); Speckmann, E.-J.(Hrsg.)
(1999): Physiologie. 3. Auflage. München:
Urban & Fischer.
Gescheider, G.A.; Bolanowski, S.J.; Verillo,
R.T.M Arpajian, D.J.; & Ryan, T.F. (1990):
Vibrotactile intensity discrimination measured by three methods. Journal of the
Acoustical Society of America, Vol. 87, Nr.
1, S. 330-338.
Goff, G.D. (1967): Differential discrimination
of frequency of cutaneous mechanical vibration. Journal of Experimental Psychology, Vol. 74, Nr. 2, S.294-299.
Johnson, K.O. & Phillips, J.R. (1981): Tactile spatial resolution. I. Two point discrimination, gap detection, grating resolution,
and letter recognition. Journal of Neurophysiology, Vol. 46, Nr. 6, S. 1177-1191.
Petrosino, L.; Fucci, D. (1989): Temporal
resolution of the aging tactile sensory system. Perceptual and Motor Skills, Vol. 68,
S. 288-290.
Sherrick, C.A.; Cholewiak, R.W. (1986):
Cutaneous sensitivity. In Boff, K.R., Kaufman, L. & Thomas, J.P.: Handbook of perception and human performance. S. 12.
New York: John Wiley and sons.
Spence, C.; Driver, J. (1997): Cross-Modal
Links in Attention Between Audition, Vision,
and Touch: Implications for interface Design. International Journal of Cognitive
Ergonomics, Vol. 1, Nr. 4, S. 351-373.
Van Doren, C.L. (1990): The effects of a
surround on vibrotactile thresholds: evidence for spatial and temporal independence in the non-Pacinian I channel. Journal
of Acoustical Society of America, Vol. 87,
Nr. 6, S. 2655-2661.
Van Erp, J.B.F.; Veltman, J.A.; Van Veen,
H.A.H.C.; Oving, A. (2002): Tactile Torso
Display as Countermeasure to Reduce Night
Vision Goggles Induced Drift. NATO RTO.
conference on spatial disorientation. 15-17
April, Lacoruña, Spanien.
Verrillo, R.T. (1962): Investigation of some
parameters of the cutaneous threshold for
vibration. Journal of Acoustical Society of
America, Vol. 34, Nr. 11, S. 1768-1773.
Verrillo, R.T. (1963): Effect of contactor area
on the vibrotactile threshold. Journal of
Acoustical Society of America, Vol. 35, Nr.
12, S. 1962-1966.
Verrillo, R.T. (1965): Temporal summation in
vibrotactile sensitivity. Journal of Acoustical
Society of America, Vol. 37, Nr. 5, S. 843846.
Verrillo, R.T. (1966). Vibrotactile thresholds
for hairy skin. Journal of Experimental Psychology, Vol. 72, Nr. 1, S. 47-50.
Verrillo, R.T.; Fraioli, A.J.; Smith, R.L. (1969):
Sensation magnitude of vibrotactile stimuli.
Perception & Psychophysics, Vol. 6, S. 366372.
Weinstein, S. (1968): Intensive and extensive
aspects of tactile sensitivity as a function of
body-part, sex and laterality. In: The Skin
Senses, edited by D.R. Kenshalo. Springfield,
C.C.Thomas, S. 195-218.
Van Erp, J.B.F.; VAN Veen, H.A.H.C.
(2001): Vibro-Tactile Information Presentation in Automobiles. Eurohaptics 2001 conference. Birmingham: University of Birmingham.
269
"Luftmäuse" – berührungslose „Multipointing-Interaktion“
Paul Chojecki
Fraunhofer-Institut für Nachrichtentechnik, Heinrich-Hertz-Institut
Interactive Media - Human Factors
Einsteinufer 37
10587 Berlin
[email protected]
www.iPointPresenter.de
Ulrich Leiner
Fraunhofer-Institut für Nachrichtentechnik, Heinrich-Hertz-Institut
Interactive Media - Human Factors
Einsteinufer 37
10587 Berlin
[email protected]
www.hhi.fraunhofer.de/im
Abstract
Heutzutage stehen dem Nutzer bereits
viele verschiedene Möglichkeiten der
Mensch-Computer-Interaktion zur Verfügung. Dennoch wird weiterhin nach
neuen Lösungen gesucht, da immer
noch Aufgaben und Nutzungskontexte
bestehen, für die keine optimalen Eingabegeräte vorhanden sind.
Ein Trend der letzten Zeit sind sicherlich
Multi-Touch-Benutzerschnittstellen. Diese Technologie wurde nicht ausschließlich von Apple vorangetrieben, ist aber
durch die Einführung von Apples jüngster Produktlinie in hohem Maße bekannt
geworden. Doch was könnte der nächste Schritt sein, der über das Berühren
1.0
Einleitung
Um 1964 erfand das Team um
Douglas C. Engelbart und William English den „X-Y-Positions-Anzeiger für ein
Bildschirmsystem“ und veränderte damit
maßgeblich die Interaktion zwischen
Menschen und Computern. Durch das
Gerät, das heute als (Computer-) Maus
bekannt ist, sind wir es gewohnt, einen
Mauszeiger bzw. Cursor auf dem Bildschirm durch Bewegungen der Maus zu
steuern. In Verbindung mit Maustasten
können Eingaben wie Klicken, Greifen,
Verschieben und Scrollen ausgelöst
werden. Diese Grundfunktionen haben
bereits mehrere Generationen von
Mensch-Maschine-Schnittstellen geprägt
und die Entwicklung von grafischen
User-Interfaces (GUI) vorangetrieben.
Durch neue Anforderungen, Ideen und
technologische Möglichkeiten kann seit
1964 nicht nur eine Evolution der Com-
270
von Bildschirmen hinausgeht, um eine
bessere Mensch-Computer-Interaktion
zu ermöglichen?
In diesem Beitrag wird ein Ansatz des
Fraunhofer-Instituts für Nachrichtentechnik / Heinrich-Hertz-Institut vorgestellt: Videokameras und Algorithmen
zur Bildanalyse und Objekterkennung
ermöglichen eine nicht-invasive, also
berührungs-, und markerlose Interaktion zwischen Anwender und Computer.
Der Nutzer kann Eingaben durch einfache Handgesten tätigen, da das System die Raumkoordinaten eines oder
mehrerer Finger des Nutzers erkennt.
Mit solchen „Multipointing“-
Eingabedaten kann einerseits die MausBedienung substituiert werden, darüber
hinaus eröffnen diese viele neue Optionen für die Mensch-MaschineInteraktion.
Die hier vorgestellte Untersuchung beschäftigt sich mit einer für „Luftmäuse“
grundlegenden Fragestellung: Welche
Geste ersetzt den Mausklick besser, ein
Zeitschwellwert oder eine Vorwärtsbewegung des zeigenden Fingers?
Keywords
Mensch-Computer-Schnittstellen, Eingabegeräte, berührungslos, Multipointing, Mausersatz
putermaus, sondern auch die Entwicklung von neuen Eingabe-, bzw. Zeigegeräten beobachtet werden. Ein UITrend der letzten Jahre waren (Multi-)
Touchscreens wie zuletzt der „Surface“ von Microsoft oder das iPhone von
Apple. Touchscreens haben im Vergleich zur Mausinteraktion den Vorteil,
dass die Eingabefunktion direkt in den
Bildschirm integriert ist. Ein- und Ausgabebereich verschmelzen; es ist keine verzerrende Abbildung der Maus- in
die Cursorbewegung nötig, ja ein zusätzliches Eingabegerät fällt komplett
weg.
Geräte bedienen müssen, ohne sie wegen der Sterilitätsanforderung berühren
zu dürfen. Hier, wie auch in einigen anderen Szenarien, wäre eine berührungslose (Gesten-) Steuerung eine gute Eingabemöglichkeit. Daher beschäftigt sich
das Team "Interaktive Medien - Human
Factors" des Fraunhofer-Instituts für
Nachrichtentechnik seit längerem mit
dieser Fragestellung und hat mehrere
einsatzreife Lösungen realisiert. In diesem Paper vergleichen wir erstmals
zwei dieser Interaktionskonzepte bezüglich ihrer Usability in einem Nutzertest.
Doch auch diese Lösung birgt Bediennachteile und deckt nicht alle Anforderungen und Nutzungsszenarien ab.
Die Suche nach neuen Arten der Interaktion für GUIs geht weiter.
2.0
Untersuchungsgegenstand: Berührungslose Interaktion
2.1
Technische Umsetzung
Stellen wir uns den Nutzungskontext
OP-Saal vor, in dem Ärzte komplexe
Unsere Arbeiten basieren auf dem
HHI Handtracker, einem nicht-invasiven,
videobasierten System zur schnellen
und robusten Erkennung und Verfolgung
von Fingern. Der HHI Handtracker ist in
der Grundversion mit 2 Kameras ausgestattet, die orthogonal zum Bildschirm
angebracht sind, also die Hand von oben oder unten aufnehmen. Seine Bildverarbeitungs-Software erkennt aus den
Kamerabildern in Echtzeit die Position
eines oder mehrerer Finger im Raum.
Diese zeitabhängigen 3D-Koordinaten
können dann an beliebige Applikationen
weitergegeben und von diesen interpretiert werden.
Abb. 1: Handtracker-Hardware mit 2 Kameras
Dabei können sowohl die aktuellsten
Datensätze als auch ganze Zeitreihen
verwendet werden. Letztere ermöglichen
die Beschreibung und Analyse komplexer Gesten.
2.2
Interaktionskonzepte
Auf diesen Koordinatendaten haben wir
verschiedene Bedienaktionen aufgesetzt, die von der Computermaus oder
dem Touchscreen her etabliert sind:
Die Grundaktion ist die Steuerung des
Mauszeigers. Der Nutzer kann den Cursor per Fingerzeig bewegen. Bewegungen zum Bildschirm hin oder von ihm
weg werden nicht ausgewertet. Eine
Translation und Skalierung der Rohdaten ist möglich und hat sich als wesentlich für eine ermüdungsarme Bedienung erwiesen.
Die Auswahl, die typischerweise mit
einem Klick der linken Maustaste durchgeführt wird, haben wir auf zwei unterschiedliche Arten modelliert: Durch Zeitsteuerung, d.h. der Cursor muss eine
bestimmte Mindestzeit über einem selektierbaren Element gehalten werden,
oder durch Klicken in der Luft, wobei der
Finger in einer bestimmten Zeit eine
Mindestbewegung in Richtung Bildschirm über einem selektierbaren Objekt ausführen muss. Diese beiden
Methoden wurden in dem Test verglichen und näher untersucht.
Darüber hinaus haben wir komplexere
Interaktionen wie Klick, Grab und Release bzw. Drag & Drop in Luftgesten
übertragen.
Das Interaktionskonzept beruht dabei
auf einer Metapher aus der natürlichen
Umwelt, in der Objekte wie z.B. Fotos
auf einem Tisch liegen. In der virtuellen Umgebung werden die Objekte auf
einem Display dargestellt. Streckt der
Nutzer seine(n) Finger aus, kann er
auf diese Objekte - mit dem Mauszeiger - zeigen. Wird der Finger nach
vorne, also in Richtung des Objektes
auf dem Bildschirm bewegt, kann dieses Objekt berührt werden, genauso
wie wenn man ein Objekt auf einem
realen Schreibtisch berühren würde.
Damit kann man das Objekt über den
Tisch bewegen und wieder loslassen.
Die virtuelle Berührung erfolgt, indem
der Nutzer mit seinem Finger eine
virtuelle Wand durchsticht und damit
vom Zeige-Modus in den Greif-Modus
wechselt. Diese Aktion wird durch ein
auditives und visuelles Feedback unterstützt.
Abb. 2: Aufbau des Testsystems mit einem
63“ Plasmabildschirm und dem HHI
Handtracker über der Hand des Nutzers.
Schließlich haben wir auch das Erkennen und Zusammenwirken mehrerer
Finger genutzt, um Rotations- und Skalierungsaktionen ähnlich wie bei Apples
iPhone zu implementieren.
Dazu haben wir die Greif-Geste mit der
Erkennung zweier Finger kombiniert.
Das so gegriffene Objekt kann durch die
Relativbewegung der Finger zueinander
skaliert oder rotiert werden.
3.0
Untersuchung
3.1
Ziele
Das Klicken ist bei GUIs eine der
wichtigsten Funktionen. In unserem Interaktionskonzept werden durch Mausklicks Buttons aktiviert bzw. Objekte
über sensitive Bereiche „berührt“.
Ziel dieser Untersuchung ist ein erster
empirischer Vergleich zwischen zwei
„Gesten“ (Klicken durch Warten vs. Klicken durch Bewegen), die unserer Meinung nach für den Mausklick geeignet
sind.
3.2
Methode
Um die beiden Klickvarianten zu untersuchen wurde ein Messwiederholungsdesign mit randomisierter Abfolge
der Bedingungen angewandt. Jede Versuchsperson (VP) hat beide Klickvarianten nacheinander getestet und bewertet.
Im ersten Durchgang haben zwölf VPN
durch Warten, acht VPN durch Bewegen
geklickt. Im zweiten Durchgang entsprechend umgekehrt. Jede VP sollte vor der
Untersuchung und Einweisung in die zu
testende Technologie zunächst schildern, wie sie einen auf dem Bildschirm
gezeigten Button berührungslos drücken
würde. Folgende abhängigen Variablen
wurden erfasst:
1.
Lernzeit: Jeder VP wurde die jeweilige Klickvariante erklärt, bevor die
VP selbst diese Variante solange
testen konnte, bis sie der Meinung
271
2.
3.
4.
272
war, dass Sie dieses Klickkonzept
verstanden hat. Die Dauer des Explorierens bzw. Lernens wurde dabei erfasst.
Genauigkeit: Auf dem Bildschirm
waren fünf rechteckige Buttons dargestellt. Diese Buttons zeigten ein
Kreuz und befanden sich in der Mitte, sowie in den vier Ecken des
Bildschirms. Die VP hatte die Aufgabe, genau in die Mitte des Buttons zu klicken. Es wurde der Radius der Abweichung vom Mittelpunkt
des Buttons in Pixel erfasst.
Minimale Buttongröße: Auf dem
Bildschirm wurden Gruppen von
Buttons (3 x 3 Buttons) in 11 verschiedenen Größen gezeigt. Die
kleinsten Buttons waren 10 x 10 Pixel, die größten waren 60 x 60 Pixel
groß. Der Unterschied zwischen
den Buttons zweier benachbarter
Gruppen betrug immer genau fünf
Pixel. Die VP hatten die Aufgabe,
die Buttongruppe zu benennen, bei
welcher sie den mittleren Button a)
noch bequem mit dem Mauszeiger
treffen konnte (Bedingung Zielen)
und b) noch bequem anklicken
konnte. Es sollte jeweils die Gruppe
mit der minimal-akzeptablen Buttongröße genannt werden.
Subjektive Zufriedenheit: nach beiden Durchgängen musste jede VP
einen Fragebogen zur subjektiven
Zufriedenheit mit der soeben ausprobierten Klickvariante ausfüllen.
Der Fragebogen enthielt Aussagen
wie: „Es war mühsam, auf die Buttons zu klicken“, oder „Diese Bedienart würde ich auch bei anderen
Diensten wieder nutzen“, die auf einer Skala von 1 (trifft zu) bis 7 (trifft
nicht zu) bewertet werden sollten.
Das neunte Item war eine siebenstufige Kunin-Skala (Kunin, 1955).
Auf dieser Skala werden mit Smilies
sieben verschiedenen Gesichtsaudrücken dargestellt, die verschiedene Zufriedenheiten ausdrücken sol-
5.
3.3
len. Ursprünglich wurde diese
Skala für eine „Ein-Item“ Erfassung der Arbeitszufriedenheit
konzipiert, wird heute aber auch in
anderen Bereichen reliabel angewandt. In dieser Untersuchung erfassen wir damit die Gesamtzufriedenheit der VP mit einem Versuchsdurchgang.
Dauer der Aufgabenbearbeitung:
Dauer für die Bearbeitung einer
einfachen Klickaufgabe, bei der
die VP in einem Hauptmenü ein
Untermenü öffnen und den zweiten Untermenüpunkt anklicken
sollte.
Versuchspersonen
Fünf Frauen und 15 Männer haben an der Untersuchung teilgenommen. Die jüngste VP war 21 Jahre alt,
die älteste 61 Jahre alt. Der Altersdurchschnitt lag bei 32 Jahren (SD =
11,32). Die Versuchspersonen hatten
leicht überdurchschnittliche Computerkenntnisse. Für die Teilnahme an der
30-minütigen Untersuchung wurde
keinerlei Aufwandsentschädigung geleistet.
4.0
Ergebnisse
4.1
Signifikante Unterschiede
4.1.1
Lernzeit
Bezüglich der AV Lernzeit konnte
ein signifikanter Unterschied zwischen
den beiden Klickvarianten festgestellt
werden (t = -2,109; p = .048; df = 19).
Die VPN lernten das Klicken durch
Warten (M = 31,60; SD = 26,84) ca. 20
Sekunden schneller als das Klicken
durch Bewegen (M = 51,80; SD =
30,98).
4.1.2
Genauigkeit
nifikant genauer (t = 4,558; p = .000; df
= 18) als beim Klicken durch Bewegung
(M = 16,32; SD = 4,02).
4.1.3
Minimale Buttongröße beim Klicken
Die Angaben zu der minimalen Buttongröße für das Klicken waren in der
Bedingung Klicken durch Warten (M =
2,95; SD = 1,05) mit ca. 20 x 20 Pixel
signifikant kleiner (t = -7,033; p = .000;
df =19) als in der Bedingung Klicken
durch Bewegen (M = 4,65; SD = 1,46)
mit ca. 30 x 30 Pixel.
4.1.4
Subjektive Zufriedenheit
Ein hoch signifikanter Unterschied (t
= 5,311; p = .000; df =19) konnte hinsichtlich der subjektiven Zufriedenheit
beobachtet werden. Auf der siebenstufigen Skala lag die mittlere Zufriedenheit
in der Bedingung Klicken durch Warten
mit M = 5,35 (SD = 1,09) höher als die
Zufriedenheit mit dem Klicken durch
Bewegen (M = 4,00; SD = 1,52).
4.2
Keine (signifikanten) Unterschiede
4.2.1
Zeit für die Aufgabenbearbeitung
Hinsichtlich der Zeit für die Aufgabenbearbeitung gab es keinen Unterschied zwischen den Klickvarianten.
Beim Klicken durch Warten brauchten
die VPN durchschnittlich M = 6,1 Sekunden (SD = 2,10), beim Klicken durch
Bewegen durchschnittlich 7,1 Sekunden
(SD = 3,17).
4.2.2
Minimale Buttongröße beim Zielen
Die Angaben zu der minimalen Buttongröße für das Zielen waren in der
Bedingung Klicken durch Warten (M =
2,95; SD = 1,15) mit ca. 20 x 20 Pixel
nicht unterschiedlich von der Bedingung
Klicken durch Bewegen (M = 2,95; SD =
0,76).
Beim Klicken durch Warten (M =
12,43; SD = 3,30) waren die VPN sig-
4.3
Weitere Ergebnisse
4.3.1
Die intuitive Klickgeste
Im Hinblick auf die erste Frage nach
einer „intuitiven“ Geste für das berührungslose Drücken eines WindowsButtons haben 12 VPN eine Geste gezeigt, die genauso oder sehr ähnlich wie
die o.g. Klickart „Klicken durch Warten“
aussah. Drei VPN haben eine Geste
gezeigt, die der o.g. „Klicken durch Bewegen“-Variante entsprach. Fünf Personen haben andere Gesten gezeigt.
4.3.2
Reihenfolgeeffekte
Da bei dem zugrunde liegenden Untersuchungsdesign Reihenfolgeeffekte
erwartet werden können, wurden die
Daten auf solche Effekte hin untersucht.
Es konnten fünf signifikante Effekte gefunden werden.
Die Lernzeit für das Klicken durch Bewegen fiel um 32,42 Sekunden länger
aus (t = -2,624 p = .012; df = 18), wenn
die VPN diese bereits im ersten Durchgang lernten (M = 71,25; SD = 24,81).
Für die Angabe über die minimale Buttongröße beim Zielen für die Klickart
Warten konnte ein positiver „Lerneffekt“
gefunden werden (t = 2,527; p = .021;
df = 18). Haben die VPN die Klickart
Warten im ersten Durchgang ausprobiert, fiel deren Einschätzung der minimalen Buttongröße fürs Zielen größer
aus (M = 3,42; SD = 1,08) als bei den
VPN, die bereits einen Durchgang mit
der anderen Klickart hinter sich hatten
(M = 2,25; SD = 0,89).
Dieser Effekt kann ebenfalls für die Angaben zur minimalen Buttongröße für
das Klicken mit der Klickart Warten (t =
2,856; p = .010; df = 18) festgestellt
werden. Die VPN ohne vorherige Übung
mit der anderen Klickart wollten größere
Buttons fürs Klicken (M = 3,42; SD = 1)
als die VPN, die bereits einen Durchgang hinter sich hatten (M = 2,25; SD =
0,71).
Für die minimale Buttongröße fürs
Klicken mit der Klickart Bewegen gibt
es einen umgekehrten Effekt (t =
2,556; p = .020; df = 18). Die VPN, die
im ersten Durchgang mit der Klickart
Waten beginnen und erst danach die
Klickart Bewegen kennen lernen, wünschen sich größere Buttons (M = 5,25;
SD = 1,48) als die VPN, die direkt mit
der Klickart Bewegen beginnen (M =
3,75; SD = 0,89).
Bei der Gesamtzufriedenheit mit der
Klickart Bewegen konnte ebenfalls ein
signifikanter Reihenfolgeeffekt gefunden werden (t = -2,798; p = .012; df =
18). Haben die VPN zuerst das Klicken
durch Warten kennen gelernt, so bewerteten sie das Klicken durch Bewegen deutlich schlechter (M = 3,33; SD
= 1,371) als die VPN, die im ersten
Durchgang mit der Klickart Bewegen
begonnen haben (M = 5,00; SD =
1,195), also keine Vorerfahrungen mit
der anderen Klickart hatten.
5.0
Diskussion
In vier von sechs erfassten Variablen konnten signifikante Unterschiede
zwischen den beiden Klickvarianten
festgestellt werden. In diesen vier Fällen schneidet die Variante Klicken
durch Warten immer besser ab als das
Klicken durch Bewegen. Der gravierendste Unterschied besteht, unserer
Meinung nach in der Lernzeit. Um mit
der Variante Klicken durch Bewegen
zurecht zu kommen, brauchten die
VPN durchschnittlich 20 Sekunden
länger. Das entspricht auch unserer
Erfahrung und dem von uns vorgeschlagenen Einsatzgebiet für die beiden Gesten. Das Klicken durch Warten
ist einfacher zu verstehen und auch
genauer, insbesondere für Novizen.
Wir haben deshalb diese Variante für
Systeme vorgeschlagen und realisiert,
die z.B. im öffentlichen Bereich verwendet werden. In dem Kontext sind
die Nutzer meist Novizen und die Lernzeit sollte so gering wie möglich sein,
um eine effektive, effiziente und zufriedenstellende Nutzung zu ermöglichen.
Die Bearbeitungszeit der einfachen
Klickaufgabe zeigt jedoch, dass, wenn
die Nutzer das Konzept des Klickens
durch Bewegen verstanden haben, es
bei einfachen Aufgaben genauso gut
angewendet werden kann.
Die gefundenen Reihenfolgeeffekte deuten auf die bekannte Problematik des
Messwiederholungsdesigns hin. Inhaltlich unterstützen diese Effekte aber die
bereits erwähnten Vorteile des Klickens
durch Warten. Beispielweise ist die subjektive Zufriedenheit der VPN mit dem
Klicken durch Bewegen deutlich geringer, wenn diese VPN bereits die allgemein favorisierte Klickart durch Warten
kennen gelernt haben. Andererseits
kann aber nicht behauptet werden, dass
die Kenntnis der Klickart durch Bewegen
die subjektive Zufriedenheit mit dem
Klicken durch warten beeinflussen würde.
Der Reihenfolgeeffekt hinsichtlich der
minimalen Buttongröße fürs Klicken (Klicken durch Bewegen) deutet darauf hin,
dass diese Klickart möglicherweise
durch das Messwiederholungsdesign
schlechter bewertet wurde, als es tatsächlich der Fall ist. Hier scheinen sich
die VPN, die diese Klickart im ersten
Durchgang kennen lernen sicherer zu
fühlen da sie kleinere Buttons wählen
als VPN, die erst das Klicken durch Warten ausprobieren. Die Kenntnis der
„besseren“ Klickgeste (Klicken durch
Warten), scheint die negativen Wertungen der „schlechteren“ Klickgeste (Klicken durch Bewegen) zu verstärken.
Das Klicken durch Bewegen hat zudem
in der Bewertung unter einigen technisch-ergonomischen Problemen gelitten, die in der nächsten Version des
Systems behoben werden sollten. Das
Klicken durch Bewegen sollte z.B. nicht
273
auf einer Linie, senkrecht zum Display,
sondern auf einem Bogen geschehen,
dessen Mittelpunkt der Nutzer ist. Das
ist ergonomischer bzw. entspricht einer
natürlichen Bewegung. Weiterhin sollte
der Nutzer bzgl. der unsichtbaren Bereiche in denen er klicken oder nur den
Mauszeiger bewegen kann, ein eindeutiges Feedback erhalten.
Unserer Ansicht nach, ist das Klicken
durch Warten einfacher zu erlernen und
zunächst auch genauer. Es scheint
auch, zumindest für einfache Klickoperationen auch intuitiver zu sein als das
Klicken durch Bewegen (siehe Absatz
4.3.1 Die intuitive Klickgeste). Das Klicken durch Bewegen hat allerdings den
Vorteil, dass der Nutzer eine aktive Eingabe macht (bewegen vs. warten) um
einen Befehl auszuführen. Das entspricht eher den bekannten Konzepten
aus der Computerwelt (Drücken einer
Maus-, Tastaturtaste) aber auch aus
unserer natürlichen Umwelt (Drücken
eines Lichtschalters). Weiterhin ist solch
eine aktive Eingabe besser um Fehlbedienungen zu vermeiden. Aus diesem
Grund sind wir der Meinung, dass das
Klicken durch Bewegen weiterhin verfolgt werden sollte und in einigen Nutzungskontexten, z.B. in Expertensystemen, die eine komplexere Interaktion
erfordern ggf. vorteilhafter sein könnte.
Diese und weitere Fragestellung, die
aus den ersten Ergebnissen resultieren,
als auch die hier erwähnten methodischen und konzeptionellen Probleme
werden in weiteren Arbeiten evaluiert.
274
Weiterhin ist uns bewusst, dass der
hier untersuchte Lösungsansatz erst
einen Bruchteil der Interaktionsmöglichkeiten durch berührungslose Gesten abdeckt. Unser Ziel war es zunächst eine der wichtigsten Nutzeraktionen, den Klick, genauer zu untersuchen. Der Ansatz der berührungslosen
Interaktion hat jedoch ein über den
Transfer von Maus- und Touchaktionen weit hinausgehendes Potential.
Z.B. können die Zahl der ausgestreckten Finger und deren Bewegung zur
Basis einer umfangreichen Gestensprache ausgebaut werden. Aus diesem Grund werden wir dieses Thema
sowohl hinsichtlich der Verbesserung
der Technik als auch der Usability weiter vorantreiben.
Danksagung
Für die tatkräftige Unterstützung bei der
Untersuchung bedanken uns herzlich bei
Jasmin Heumann, Christian Gali, Wolfgang
Reiner und Dr. Lothar Mühlbach.
6.0
Engelbart, D.; English, W. (1968): A Research Center for Augmenting Humans
Intellect. AFIPS Conference Proceedings,
Vol. 33, S. 395-410.
7.0
Weiterführende Literatur und
Links
Hopf, K.; Chojecki, P.; Neumann, F.; Przewozny, D. (2006): Novel autostereoscopic
single-user displays with user interaction.
Proceedings of SPIE, Vol. 6392, October
2006.
Maggioni, C. (1995): Gesture Computer New Ways of Operating a Computer. Proceedings of International Conference on
Automatic Face and Gesture Recognition, S.
166–171.
Nickel, K.; Stiefelhagen, R. (2007): Visual
recognition of pointing gestures for humanrobot interaction. Image and Vision Computing, Vol. 25, Nr. 12, S. 1875-1884.
Yamamoto, Y. et al. (2004): Arm-Pointing
Gesture Interface Using Surrounded Stereo
Cameras System. Proceedings of the Pattern
Recognition, 17th International Conference
on (ICPR'04), Vol. 4, S. 965-970.
http://www.hhi.fraunhofer.de/de/abteilungen/i
m/produkte-unddienstleistungen/beruehrungsloseinteraktion.html
http://www.igesture.org/: A General Gesture
Recognition Framework
http://www.healthypointers.no/confluence/disp
lay/hp/Home
http://naturalinteraction.org
Kunin, T. (1955), The construction of a new
type of attitude measure. Personal Psychology 8 (1955) 39-47
U ser-Centere d - D e s i g n un d
S o ftw are Ent w i c k l u n g
275
276
Erfahrungen zur praktischen Anwendung eines
ganzheitlichen Usability Engineering im Kontext der
klassischen IT Systementwicklung und Prozessreifung
Michael T. Offergeld
Daimler AG,
Research & Development
89081 Ulm
[email protected]
Abstract
Usability Engineering (UE) versteht sich
weitläufig als eigenständige Disziplin mit
einer Vielzahl an Methoden und Verfahren zur Entwicklung nutzergerechter und
gebrauchstauglicher IT Systeme. Nach
eigenen langjährigen Erfahrungen mangelt es aber immer noch an ausreichend
Akzeptanz sowohl im Kontext klassischer System- und Softwareentwicklungsprojekte, als auch im Kontext der
Reifung von Entwicklungsorganisationen.
1.0
Einleitung
Usability Engineering (UE) bietet als
eigenständige Disziplin eine Vielzahl an
Methoden und Verfahren zur Entwicklung informationstechnischer (IT) Systeme. Wendet man diese Methoden im
Kontext großer IT Entwicklungsprojekte
konsequent über den gesamten Systementstehungs- und Lebenszyklus an,
wie innerhalb der Daimler AG in den
vergangenen 15 Jahren geschehen, so
bieten sie in ihrer Gesamtheit einen enormen Nutzen sowohl für die Qualität
des finalen Systems, für die Qualität des
zugehörigen Entwicklungsprojekts als
auch für die Reife der zugehörigen Entwicklungsorganisation.
Dennoch fällt es auch heute noch
schwer, UE als anerkannte Kompetenz
im Unternehmen zu verankern. Häufig
werden die Möglichkeiten von Usability
Engineering schon von der Begrifflichkeit her unterschätzt oder missverstanden.
Hier beherrschen Themen wie Projektund Qualitätsmanagement, Requirements Engineering, Software Realisierung, Produktintegration und Test die
Szene und die Aufmerksamkeit von
Entscheidern. Einen Ausweg aus diesem Dilemma könnte die Betrachtung
von UE genau aus diesem Blickwinkel
klassischer Management und Engineering Themen sein:
Usability Engineering – einmal aus
einem anderen Blickwinkel betrachtet
Keywords
Der vorliegende Beitrag beleuchtet
wesentliche Erkenntnisse, vermittelt
Eindrücke und Beobachtungen, gibt
Erklärungen und zeigt mögliche Wege
für die Zukunft von UE im industriellen
Umfeld auf. Dabei wird ausgehend von
eigenen Erfahrungen auf folgende
Schwerpunkte eingegangen:
UE in unternehmensinternen Entscheiderkreisen wirksamer als Lieferant von
Lösungen für zahlreiche Projektmanagement und Engineering Aspekte aufzugreifen. Aber nicht als gesondert bzw.
losgelöst zu betrachtende Disziplin,
sondern als Ergänzung klassischer Management- und Engineering Themen.
x
x
x
x
x
x
Begrifflichkeiten rund um Usability,
beobachtete Missverständnisse
Beitrag und Nutzen eines ganzheitlichen und durchgängigen UE
Die Querschnittlichkeit von UE –
und Konsequenzen daraus
Die weitläufig bekannte Welt der
System- und Softwareentwicklung
Reifung von Entwicklungsorganisationen
UE aus dem Blickwinkel klassischer System Management und
Engineering Themen
Ziel ist es, den Lesern die Bedeutung
und Einsatzbreite des Themas UE im
Kontext von Systementwicklungsprojekten darzulegen. Es soll vor allem
ein Anstoß dafür gegeben werden, das
Usability Engineering, Gebrauchstauglichkeit, Ergonomie, System und Software Engineering, Entwicklung von IT
Systemen, V-Modell XT, Prozessreife,
CMMI, Systemqualität
2.0
Systems Engineering: typische
Phasen der Systementwicklung
Als Basis für die weitere Diskussion
werden nachfolgend die typischen Phasen und Aktivitäten einer Systementwicklung genannt:
x
x
x
Produktidee mit Kosten/Nutzenanalyse, Ist-Stand-Analyse
(z.B. Betrachtung von Altsystemen,
Wettbewerbersystemen)
Projektvorbereitung mit Vorprojektphase zur Lastenhefterstellung, Projektausschreibung, Projektplanung
Anforderungsspezifikation auf Basis
des Lastenhefts (= Grobanforderungen des Auftraggebers), Erstellung
277
des Pflichtenhefts durch den Auftragnehmer (Entwicklungsbereich)
Systemgrob- und -feinentwurf (HW
und SW) mit Definition von Leistungsmerkmalen/Systemarchitektur
Implementierung und Test
Systemintegration, Integrationstests
Überleitung in die Nutzung mit Pilotierung, Schulung, Rollout
Operativer Systembetrieb/-pflege
x
x
x
x
x
Darüber hinaus seien noch projektübergreifende Unterstützungsaktivitäten wie
Projektmanagement, Lieferantenmanagement, Qualitätsmanagement und Dokumentation genannt.
Usability Engineering (UE)
3.0
Unter UE verstehen wir hier ein Referenzmodell für die systematische,
ganzheitliche und durchgängige Entwicklung und Pflege nutzerund aufgabengerechter, gebrauchstauglicher interaktiver Systeme. Es beinhaltet eine
Vielzahl an Methoden und Verfahren,
die sich an den eben genannten klassischen Systementwicklungsphasen orientieren (DATech 2008). In dieser Form
ist UE in zahlreichen Anwendungsdomänen innerhalb der Daimler AG zur
Unterstützung von IT Systementwicklungsprojekten eingeführt und praktiziert
worden. Dabei sind vielfältige Erfahrungen gemacht worden.
Ergonomie, Usability & Co.
3.1
Es existiert eine Vielzahl an Begrifflichkeiten rund um das Thema UE. Versucht man, zu beschreiben, worum es
sich hier handelt, ist etwa die Rede von
Dingen wie
x
x
x
x
x
x
Gestaltung ergonomischer Systeme
Sicherstellung der Gebrauchstauglichkeit von Systemen
Entwicklung nutzergerechter und
Aufgaben-angemessener Systeme
Gewährleistung möglichst hoher
Nutzer- und Nutzungsakzeptanz
Erhebung von User Requirements
Absicherung der Qualität durch entwicklungsbegleitende Usability Tests
278
x
Benutzerbeteiligung
UE wird leider häufig auf eine „weiche“
Disziplin reduziert, die sich mit Themen wie „Nutzer zufrieden stellen“,
„Knöpfchen rot oder grün färben“,
„Wünsche der Anwender abfragen und
berücksichtigen“ und „Grafiken oben
oder unten positionieren“ befasst.
Themen also, die in der „harten“ Welt
der Systementwicklung, in der es um
Entwicklungsressourcen, Zieltermine,
Meilensteine und Systemqualitäten
geht, eher nachrangige Bedeutung
haben, jedenfalls dann, wenn es im
Projekt „eng“ wird.
Wir haben hier also ggf. ein Begrifflichkeitsproblem: „Usability Engineering“ ist als eigene Disziplin vom Wording her nicht so bekannt, prominent /
anerkannt wie etwa die Themen Projektmanagement, Qualitätsmanagement, Risikomanagement, Lieferantenmanagement, Änderungsmanagement, Requirements Engineering, SWRealisierung, Systemintegration und
Systemtest.
3.2
Ganzheitliches und durchgängiges Usability Engineering
In zahlreichen Projekten haben wir
es nach gewisser Zeit geschafft, UE
als ganzheitliche und durchgängige
Unterstützung der IT Projekte einzuführen. Eine interessante Erkenntnis
war vor allem, dass UE als Referenzmodell für die Entwicklung interaktiver
IT Systeme nicht nur Methoden und
Verfahren für Entwicklungs- / Herstellerorganisationen, sondern auch für
klassische Auftraggeberorganisationen
(und dazu zählen viele DaimlerFachbereiche, die IT Systementwicklung nach Extern beauftragen) zur
Verfügung stellt. UE liefert für nahezu
alle in Abschnitt 2.0 genannten Phasen und Aktivitäten der Systementwicklung sehr wertvolle Unterstützung.
In der operativen Praxis (vor allem,
wenn das Thema an neue Fachbereiche
ohne UE Vorkenntnisse herangetragen
wurde) werden aber Usability Experten
typischerweise eher zu Themen der
User Interface Gestaltung gefordert, und
das oft erst in späten Phasen des Projekts, wenn schon fast alle Benutzungsoberflächen implementiert wurden oder
gar das System schon in den operativen
Betrieb überführt wurde.
Den Idealzustand eines ganzheitlichen
und durchgängigen UE kennzeichnet
daher eine kontinuierliche Projektunterstützung durch UE Aktivitäten beginnend
schon bei der Projektvorbereitung, über
die Anforderungsanalyse, den Systementwurf, die Implementierung, den Modul- und Systemtest bis hin zur Überleitung in die Nutzung und sogar Unterstützung der operativen Phase des eigentlichen Systembetriebs. Aber: Einen
verantwortlichen Fachbereich dazu zu
bringen, UE ganzheitlich in diesem Sinne zu leben, ist ein harter und steiniger
Weg. Nicht selten wird schon in Folgeprojekten alles wieder vergessen, wenn
nicht explizit wieder ein Usability Experte
den Finger hebt und das Thema beim
(Projekt) Management deutlich adressiert. Liegt das nicht vielleicht auch an
der Denke „Ich biete Dir ein Komplettpaket Usability Engineering an“?
3.3
Die Querschnittlichkeit von
UE ist aus Sicht eines Entwicklungsprojekts eine hochgradig
querschnittliche Disziplin, die wertvolle
Beiträge zu vielen Einzelthemen leistet.
Diese Querschnittlichkeit hat sich in der
Praxis insofern als problematisch erwiesen, als dass man sich damit nur schwer
fokussieren kann. Aus Sicht eines IT
Projekts entsteht der Eindruck, dass
man als Usability Experte überall ein
bisschen mit dabei, aber nirgends zentraler Stakeholder ist. Man kümmert sich
nicht nur um Qualitätssicherung, son-
dern auch um Anforderungserhebung,
Gestaltung, Test etc. Das macht das
Leben eines Vollblut Usability Experten
im Projekt und auch in der Organisation
z.T. recht schwer, da man sich mit verschiedenen unterschiedlichen Verantwortlichen im Projekt abstimmen muss
(z.B. mit Requirements Engineer, Qualitätsmanagement-Beauftragten, Projektleiter, Test-Experten, Schulungsbereich).
4.0
1.
2.
3.
Was sind denn klassische Themen des Systems Engineering?
Diese Frage zu beantworten, fällt
nicht sonderlich schwer, gibt es doch
dazu in der Systems Engineering Community genügend Stoff.
4.1
Beispiel V-Modell XT
Das V-Modell XT steht für einen
Leitfaden zum Planen und Durchführen
von Projekten. Es ist seit Februar 2005
für die Planung und Durchführung von IT
Projekten des Bundes verbindlich vorgeschrieben (IABG 2007). Mit einer VModell-konformen Durchführung werden
folgende Ziele verfolgt:
x
x
x
x
Minimierung der Projektrisiken,
Verbesserung und Gewährleistung
der Qualität,
Eindämmung der Gesamtkosten
über den gesamten Projekt- und
Systemlebenszyklus sowie
Verbesserung der Kommunikation
zwischen allen Beteiligten.
Wenn wir also UE im Management verankern wollen, sollten wir zu diesen Zielen erhebliche Beiträge leisten und auch
darstellen können.
Ein Kernelement des V-Modells XT sind
die so genannten Vorgehensbausteine.
Sie fassen unterschiedliche Aktivitätsbausteine jeweils zu einer modularen
Einheit zusammen. Alles, was in Projekten thematisch abzudecken ist, ist über
folgende Vorgehensbausteine abgesichert:
Relevant für alle V-ModellProjekte: Projektmanagement,
Konfigurationsmanagement, Qualitätssicherung, Problem- und Änderungsmanagement, Messung
und Analyse
Relevant für die Auftraggeber
(AG) / Auftragnehmer (AN)
Schnittstelle: Vertragsschluss, Lieferung und Abnahme
Relevant für die Systementwicklung: Anforderungsfestlegung,
Multiprojektmanagement, Systemerstellung, Systemsicherheit,
Evaluierung von Fertigprodukten,
Logistikkonzeption, SWEntwicklung, HW-Entwicklung,
Weiterentwicklung und Migration
von Altsystemen sowie Benutzbarkeit und Ergonomie.
Der einzige Begriff, der hier annähernd
mit Usability Engineering in Verbindung gebracht werden kann, ist der
Baustein „Benutzbarkeit und Ergonomie“. Etwas mager, oder?
4.2
Beispiel CMMI
CMMI (Capability Maturity Model
Integration) ist ein am Software Engineering Institute (SEI) der Carnegie
Mellon University (CMU) im Auftrag
des Department of Defense (DoD)
entwickeltes und weltweit als Standard
anerkanntes Referenzmodell für die
Analyse und Verbesserung von System Entwicklungsprozessen (Beth,
Konrad & Shrum 2006).
Will man die Reife einer Entwicklungsorganisation auf der Basis von CMMI
systematisch steigern, so fokussiert
man in verschiedenen Reifegrad Leveln (i.w. Level 2 bis 5) in Summe auf
22 so genannte Prozessgebiete (Process Areas). Die für die Reifegrad
Level 2 und 3 relevanten Prozessgebiete sind u.a.:
1. Level 2: Requirements Management, Project Planning, Project
Monitoring and Control, Supplier
Agreement Management, Measurement and Analysis, Process and
Product Quality Assurance sowie
Configuration Management
2. Level 3: Requirements Development,
Technical Solution, Product Integration, Verification, Validation, Organizational Process Definition, Organizational Training sowie Risk Management
Das sind die zentralen Management und
Engineering Themen, die für die Reifung
von Entwicklungsorganisationen mit
dem Management diskutiert und im
Rahmen einer Prozessreifung angegangen werden. Auf den ersten Blick weit
und breit nichts von Usability Engineering zu sehen.
5.0
Die mögliche Lösung: UE aus
einem anderen Blickwinkel
Wie die Beispiele V-Modell XT und
CMMI zeigen, ist auf der Landkarte der
Top-Management und Engineering
Themen nicht wirklich etwas von Usability Engineering zu spüren. Aber, mal
etwas genauer durchleuchtet, bietet das
ganzheitliche und durchgängige UE eine
ganze Menge an Beiträgen zu vielen
dieser Themen.
Der wesentliche Appell dieses Beitrags
lautet daher, UE viel stärker aus dem
Blickwinkel dieser Projektmanagement
und Engineering Themen zu betrachten
und vor allem Management und Entscheidern darzustellen.
Vielleicht sollte man Usability Engineering nicht so sehr als weitere Einzeldisziplin, sondern vielmehr als eine
querschnittliche Disziplin darstellen, die
in einem IT Entwicklungsprojekt zu allen
oben genannten klassischen Themen
einen wertvollen Beitrag leistet. Genau
das soll im weiteren Verlauf dieses Beitrags getan werden (Abschnitt 5.3). Vor-
279
her aber noch zwei zentrale Erfahrungen
im Umgang mit UE.
5.1
Die entscheidende Frage
Das alles entscheidende Kriterium
dafür, ob UE überhaupt für ein IT Projekt
relevant ist, ist die Frage, ob es sich
beim zu entwickelnden System um ein
interaktives System handelt. Sobald dies
der Fall ist, muss man den Qualitätskriterien, die bisher als für das System
relevant erachtet wurden, noch das der
Gebrauchstauglichkeit (Usability) hinzufügen. Das ist sozusagen das Eintrittsticket für die Integration von UE ins Projektgeschehen. Die Relevanz dieses
Qualitätsziels wird aus meiner Erfahrung
heraus in der Regel von allen Beteiligten
bestätigt, denn eine nicht ausreichende
oder gar nicht vorhandene Anwenderakzeptanz des Systems kann sich zumindest auf Dauer kein Fachbereich als
Systembetreiber leisten.
5.2
5.3
Setzen wir also nun eine andere
Brille auf, eben die der klassischen
und in aller Munde befindlichen Management und Engineering Themen im
IT Systementwicklungskontext – und
reden wir über wertvolle Beiträge eines
ganzheitlichen und durchgängigen UE.
Dazu werden sortiert nach oben genannten klassischen Themen des VModell XT und des CMMI zugehörige
UE Aktivitäten aufgezählt. Alle genannten Aktivitäten wurden in der Vergangenheit in verschiedenen Projekten
innerhalb von Daimler Fachbereichen
intensiv erprobt und gelebt.
5.3.1
Projektvorbereitung, Vertragsschluss
x
Mitwirkung bei der Ausschreibung
der Systementwicklung (UE auf
Seiten des AGs) durch: Vorgabe
von Usability als ein zentrales Qualitätskriterium des Zielsystems;
Forderung nach Entwicklung des IT
Systems nach Prinzipien des UE
(z.B. durchgängige Nutzerbeteiligung, Analyse des Nutzungskontext, Durchführung von Usability
Tests); Forderung der namentlichen Benennung eines Usability
Verantwortlichen auf AG- und ANSeite;
Bewertung der eingehenden Entwicklungsangebote externer
Dienstleister bzgl. der geforderten
Qualitäten und Leistungen
Beteiligung bei der Auswahl des
Dienstleisters, der den Zuschlag für
die Systementwicklung erhält
Beteiligung beim Vertragsschluss
durch verbindliche Festlegung des
groben Vorgehens und der Verantwortlichen im Kontext UE
Der richtige Zeitpunkt
Aus Sicht eines IT Entwicklungsprojekts gibt es einen optimalen Zeitpunkt
(Phase im Projekt), um das Thema Ergonomie und Usability zu verankern: die
Phase der Projektvorbereitung. Schafft
man es hier nicht, Usability als zentralen
Qualitätsaspekt für das zu entwickelnde
System zu fordern (z.B. im Rahmen
einer Ausschreibung) und damit zu verankern, wird es im weiteren Verlauf des
Projekts sehr schwer, dies noch wirksam
und prominent zu tun (Oed & Offergeld
2006). Der Hauptgrund liegt darin, dass
ganzheitliches und durchgängiges UE
sauber geplant und mit entsprechenden
Ressourcen auszustatten sind (z.B. Personal, Budget, Infrastruktur). Und diese
Planungen erfolgen zu Projektbeginn,
wo Budget, Laufzeit etc. in der Regel
fürs Projekt gefixt werden.
280
Die andere Brille
x
x
x
5.3.2
Project Planning, Projektmanagement, Project Monitoring and Control
x
Definition von für UE Aktivitäten
relevante Rollen im Projekt (z.B.
Usability Agent auf AG-Seite, Usability Engineer auf AN-Seite, Nut-
x
x
x
x
zerrepräsentanten, UI Designer, UI
Developer)
Planung von Arbeitspaketen und
Ressourcen für z.B. UE Personal,
Befragungen, Usability Tests, Usability Workshops, User Group Treffen
und Integration in den Gesamtprojektplan
Planung von Usability Equipment wie
Labore, Kameras, Räumlichkeiten
und Rechnerausstattung
Planung der Beteiligung von Nutzerrepräsentanten, ggf. auch unter
Rückgriff auf spezielle Agenturen zur
Akquisition
Fortlaufendes Controlling aller UE
Aktivitäten (Status, Fortschritt)
5.3.3
Supplier Management, Risk Management
x
Aus Sicht des AG Ausgestaltung der
Zusammenarbeit mit den externen
und internen Dienstleistern und Zulieferern z.B. bei der Erhebung von
Anforderungen, der Verfolgung von
Usability Qualitätszielen, der Durchführung von Usability Tests
Berücksichtigung von Projektrisiken
im Zusammenhang mit Aktivitäten
des UE und der ergonomischen
Qualität des Systems (z.B. drohende
Akzeptanzprobleme, nicht verfügbare Nutzerrepräsentanten, Zeitverzug
in UE Aktivitäten)
x
5.3.4
Anforderungsfestlegung, Requirements Development, Requirements
Management, Evaluierung von Fertigprodukten
x
Mitwirkung bei der Festlegung und
Berücksichtigung von Geschäftsund Einsatzzielen des Systems
Analyse eines vorhandenen IstStandes durch heuristische Usability
Expertenevaluationen auf der Basis
von ISO 9241-110 (z.B. auf noch im
Einsatz befindliche Altsysteme oder
verfügbare Wettbewerbersysteme)
Durchführung einer Kontextanalyse
bestehend aus Benutzerprofilanalyse
(wer sind die Nutzer des Systems?
Welche Rollen soll das System unterstützen? Welche Eigenschaften
haben die Nutzer in ihren Rollen?),
Aufgabenanalyse (welche Aufgaben
x
x
x
5.3.5
x
x
x
x
x
x
haben die Nutzer in ihren verschiedenen Rollen mit Hilfe des Systems
später zu erledigen?) und der Analyse des Nutzungskontext (unter welchen Umgebungsbedingungen wird
das System genutzt?)
Berücksichtigung von HW-/SWRandbedingungen und Einschränkungen für die Systemgestaltung
(z.B. intranetbasierte Anwendung mit
Web-2.0-Technologie)
Systemerstellung, SW-Entwicklung,
HW-Entwicklung, Benutzbarkeit und
Ergonomie, Problem- und Änderungsmanagement
Workflow Reengineering (Änderung
von Prozessabläufen, die durch das
neue IT System bewirkt werden, Anpassung an die erhobenen Nutzeraufgaben der Zukunft)
Erstellung eines konzeptionellen
User Interface (UI) Modells (Grobes
GUI-Konzept)
Erstellung früher UI Mockups (z.B.
Papierprototypen)
Erstellung elektronischer UI Prototypen
Definition von Styleguide Regeln ggf.
unter Berücksichtigung schon etablierter Styleguides und Gestaltungsrichtlinien
Beratung der Entwickler bei der Umsetzung/Implementierung der Nutzungsoberflächen auf der Zielplattform (z.B. Entscheidung von Alternativen bei nicht ausreichend möglicher
technischer Umsetzbarkeit)
5.3.6
Process and Product Quality Assurance, Qualitätssicherung, Messung
und Analyse, Verification, Validation,
Product Integration
x
Definition von qualitativen und quantitativen Usability Zielen als Rahmenvorgabe für GUI Gestaltung,
Testfokus, Abnahme und Akzeptanztest
Durchführung von heuristischen Usability Expertenevaluationen auf
Zwischenstände der Entwicklung
Durchführung von Iterativen UI
Walkthroughs auf UI Mockups (pa-
x
x
x
x
x
x
x
piergestützte UI Reviews und Inspektionen)
Durchführung klassischer Usability
Tests auf verfügbare elektronische
Oberflächenprototypen von Teilsystemen
Durchführung von IntegrationsUsability Tests auf das Gesamtsystem (nach Zusammenführung aller
Einzeldialoge; z.B. Test von Antwortzeitverhalten und effiziente
Bearbeitbarkeit übergreifender Arbeitsaufgaben über Teilsystemgrenzen hinweg)
Durchführung von Abnahmetests
auf der Basis der vorgegebenen
Usability Ziele und Nutzeraufgaben
Durchführung von NutzerAkzeptanztests nach Überführung
des Systems in den operativen Betrieb
Durchführung von UsabilityVergleichstests mit Vorgänger bzw.
Wettbewerbersystemen
5.3.7
Lieferung und Abnahme, Organizational Training
x
Unterstützung der Abnahme des
Systems vor Auslieferung an den
AG durch Fokussierung auf die
vorgegebenen Usability Ziele
Unterstützung bei der Erstellung
von Bedienanleitungen durch Dokumentation von zentralen Gestaltungsregeln (Styleguide) und Beschreibung der Systembedienung
anhand zentraler Nutzerrollen und
zugehöriger Aufgaben
Unterstützung bei der Schulung
des Systems (Fokus der Systembedienung mit Darstellung von
zentralen Gestaltungsregeln (Styleguide) und Beschreibung der
Systembedienung anhand zentraler Nutzerrollen und zugehöriger
Aufgaben)
x
x
5.3.8
x
Weiterentwicklung und Migration
von Altsystemen, operativer Betrieb
Abfrage von NutzerRückmeldungen nach einer gewissen Zeit der Nutzung
x
x
x
6.0
Identifikation von Systemverbesserungen (z.B. Nutzer-Rückmeldungen
zu Bedienproblemen)
Identifikation von Systemerweiterungen (z.B. Nutzer-Rückmeldungen zu
neuen Funktionen)
Vorbereitung des nächsten System
Releases z.B. durch Planung neuer
Funktionalitäten und Systemoptimierungen
Schlusswort
UE als Einzeldisziplin in IT Projekte
eingebracht bringt schon einen gewaltigen Mehrwert und Nutzen für die Systemqualität und Projektgüte. Aber man
kämpft mitunter in jedem neu startenden
Projekt erneut um eine Beachtung von
UE. Durch die Betrachtung von UE als
integraler Teil der klassischen Management und Engineering Themen in einem
IT Projekt besteht die Chance, zu einer
automatischen Berücksichtigung der
Methoden und Aktivitäten zu gelangen.
Dies setzt voraus, dass man UE in die
zentral in der Organisation definierten
Entwicklungsprozesse integriert.
7.0
Beth Chrissis, M.; Konrad, M.; Shrum, S.
(2006): CMMI for Development, Version 1.2;
Guidelines for Process Integration and Product Improvement; Second Edition, San Francisco, New York: Addison-Wesley.
DATech in der TGA GmbH (2008): Deutsche
Akkreditierungsstelle Technik - Leitfaden
Usability, Version 1.1 vom 28.1.08.; Kap. 2
(Gestaltungsrahmen für den UsabilityEngineering-Prozess).
http://www.datech.de
IABG (2007): Industrieanlagen Betriebsgesellschaft mbH – V-Modell XT Gesamt 1.2.1
vom 16.11.07.
http://v-modell.iabg.de
Oed, R.; Offergeld, M. (2006): Usability Engineering als Auftraggeberkompetenz. Usability
Professionals 2006.
281
Qualitätsaspekte bei der Integration von User Centered
Design Aktivitäten in Softwareentwicklungsprozesse
Karsten Nebe
Universität Paderborn, C-LAB
Fürstenallee 11
33102 Paderborn
[email protected]
www.c-lab.de/usability.de
Markus Düchting
Siemens IT Solutions, C-LAB
Fürstenallee 11
33102 Paderborn
[email protected]
Dirk Zimmermann
T-Mobile Deutschland
User Centred Design &
Process Configuration
Landgrabenweg 151
53227 Bonn
[email protected]
Volker Paelke
Leibniz University Hannover, IKG
Institut für Kartographie und
Geoinformatik
Appelstrasse 9a,
30167 Hannover
[email protected]
Abstract
Die vorliegende Untersuchung zielt auf
eine verbesserte Integration von Software Engineering (SE) und Usability
Engineering (UE) Aktivitäten in Entwicklungsprozessen. Dazu wurden Schnittstellen zwischen den Bereichen identifiziert und in Experteninterviews Qualitätsmerkmale und Kriterien für die entsprechenden UE Aktivitäten erhoben.
1.0
Einleitung
Die Gebrauchstauglichkeit (Usability) von Produkten nimmt einen wachsenden Stellenwert bei der Entwicklung
von Software ein – nicht nur für den
Endnutzer, sondern auch für die entwickelnden Organisationen. Insbesondere
für den Wettbewerb bedarf es eines
systematischen, wiederholbaren Vorgehens zur Erstellung und Sicherstellung
gebrauchstauglicher Produkte.
In der Praxis erweist sich die Umsetzung
jedoch nicht selten als Herausforderung.
Eine Schwierigkeit beseht meist darin,
die Methoden, Aktivitäten und Artefakte
des Usability Engineering (UE) in die
bestehenden Strukturen einer Organisation einfließen zu lassen, welche bereits
über ein etabliertes Vorgehensmodell
verfügt und in dem die entsprechenden
Prozesse fest verankert sind. Alleinstehende, oft punktuell durchgeführte oder
parallel zum Prozess existierende Aktivitäten, wie sie in der Praxis häufiger auftreten, haben meist nur einen geringen
Einfluss auf die Usability des zu erstellenden Produktes. Nicht selten gehen
282
Die Auswertung belegt die Bedeutung
einer engen Verzahnung von UE und
SE und kann als Grundlage für die
usability-orientierte Weiterentwicklung
von SE Prozessen in Unternehmen
dienen.
diese Aktivitäten im Geschehen des
Entwicklungsprozesses unter. Die angewandten Aktivitäten, Prozesse und
Modelle sind in der Regel jene, die
vom Software Engineering (SE) vorgegeben werden (Granollers 2002).
Nichtsdestotrotz hat das Usability Engineering seine Berechtigung in der
Entwicklung und bedarf einer angemessenen Berücksichtigung.
Um die beiden Disziplinen SE und UE
einander näher zu bringen ist es notwendig nach entsprechenden Schnittstellen und Anknüpfungsbereichen zu
suchen, an denen die dahinter stehenden Aktivitäten und Artefakte reibungslos in den Prozess der Entwicklung
eigebettet werden können. Das Ziel ist
es, Usability Engineering mit den systematischen und planbaren Vorgehensweisen des Software Engineering
zu vereinen.
Bei der Suche nach entsprechenden
Anknüpfungsbereichen, ist eine Betrachtung auf unterschiedlichen Abstraktionsebenen möglich:
x
Keywords
Software Engineering, Usability Engineering, Entwicklungsprozesse, Prozessmodelle
x
x
Rahmen zur Sicherstellung und
Wahrung von Konsistenz und Qualität, innerhalb und über die Grenzen
einer Organisation hinweg genutzt
werden.
Auf der Ebene von Modellen, also in
der Definition des Vorgehens, welche als Vorlage für die Durchführung dient.
Und auf der operativen Ebene (dem
Prozess), also der praktischen
Durchführung von Aktivitäten und
der Verarbeitung von Ergebnissen
innerhalb der Organisation.
In existierenden Arbeiten wurden diese
Abstraktionsebnen im Hinblick auf Anknüpfungsbereiche bereits untersucht
(Nebe 2007a, Nebe 2007b). So wurde
beispielsweise auf Ebene der Standards
ein gemeinsamer Rahmenprozess von
Aktivitäten (sog. „Common Activities“)
identifiziert, die den Entwicklungsprozess, sowohl aus Sichtweise des Software Engineering als auch aus Sicht des
Usability Engineering repräsentieren.
Dieser Rahmenprozess kann als gemeinsame Grundlage für die darunter
liegende Ebene der Modelle herangezogen werden.
Auf der abstrakten, übergeordneten Ebene von Standards, die als
2.0
Integration von SE und UE
Um der Frage nachzugehen, inwieweit existierende Software Engineering
Modelle bereits User Centered Design
(UCD) bzw. Usability Engineering Aktivitäten unterstützen (oder integrieren)
wurde eine Analyse ausgewählter Modelle durchgeführt (Nebe 2007a, Nebe
2007b). Die Standards DIN EN ISO
13407 (1999) und ISO/PAS 18152
(2003) dienten dabei als Grundlage. Die
in der ISO/PAS 18152 enthaltenen Best
Practices wurden als Bewertungskritierien herangezogen und mit den Dokumentationen unterschiedlicher Software
Engineering Modelle verglichen. Als
Ergebnis wurden jedoch nicht nur die
Lücken der SE Modelle bezogen auf die
Erfüllung der Base Practices untersucht,
sondern gleichermaßen Potentiale für
die Integration zwischen SE und UE
identifiziert die auf der nächsten Ebene,
der Umsetzungsebene im operativen
Prozess, Berücksichtigung finden.
Für eine differenziertere Bewertung und
die gezielte Ableitung von Empfehlungen ist es wichtig, die Qualitätseigenschaften von Aktivitäten, Methoden und
Deliverables des UE zu hinterfragen.
Um diese grundlegenden Eigenschaften
zu erheben wurden insgesamt sechs
UE-Experten befragt, zunächst mittels
halbstrukturierter Interviews, im Folgenden mit einem Fragebogen. In der Auswertung wurden daraus übergeordnete
Prozess- und Qualitätseigenschaften
ermittelt, welche Aussagen über die
Relevanz, den Einsatz und die Notwendigkeit von Usability Engineering Aktivitäten, Methoden und Deliverables im
Software Engineering zulassen.
Dieser Beitrag stellt einen ersten Auszug
der Ergebnisse, insbesondere in Bezug
auf die Qualitätseigenschaften von UEAktivitäten dar. Die Ergebnisse spiegeln
grundlegende Tendenzen und Meinungen der Experten wieder und sind somit
nicht direkt verallgemeinerbar.
3.0
Qualitätsaspekte im UE
Ein wesentlicher Teil der Interviews bezog sich explizit auf Qualitätseigenschaften der vier Aktivitäten
der DIN EN ISO 13407: Context of
Use, User Requirements, Produce
Design Solutions und Evaluation of
Use. Ziel war es herauszufinden, was
aus Sicht der Experten die Qualität
einer bestimmten Aktivität ausmacht,
was die Erfolgs- und Qualitätskriterien
sind, die für die Durchführung der Aktivität angelegt werden können.
Gesamt betrachtet lässt sich bereits
sagen, dass aus Sicht der Experten
die Qualität der vier Aktivitäten im wesentlichen von der Erstellung und Weiterverarbeitung des jeweils generierten
Ergebnisses abhängt. Es geht also
nicht zwangsläufig darum, wie etwas
durchgeführt wird, sondern vielmehr
darum, die Qualität des Ergebnisses
sicherzustellen. Um die Frage zu beantworten, was diese Qualität ausmacht, werden nachfolgend die analysierten Aussagen der Experten zu den
jeweiligen Aktivitäten dargestellt. Es
wird beschrieben was die Kerneigenschaft (Essenz) der jeweiligen Aktivität
darstellt, gefolgt von inhaltlichen Anforderungen, (messbaren) Qualitätsund Erfolgsmerkmalen und einer Auflistung operativer Maßnahmen als
Empfehlung für die Umsetzung und
Sicherstellung der Qualität.
3.1.1
Context of Use
Laut übereinstimmender Aussage
der Experten ist das grundlegende Ziel
der Kontextanalyse die Schaffung eines tiefen Verständnisses über die
Nutzer, deren Ziele, Bedürfnisse und
den tatsächlichen Arbeitskontext. Es
gilt sowohl, eine Arbeitsgrundlage zu
schaffen für das Erarbeiten von Anforderungen sowie eine Grundlage für die
Validierung von Nutzungsanforderungen, als auch für spätere Lösungen
bereitzustellen. Der Fokus der Kontextanalyse sollte auf den originären Arbeitsaufgaben liegen, also unabhängig
von einer konkreten Lösung (oder unterstützenden Systemen) sein.
Neben der Dokumentation bzw. Kommunikation des analysierten Wissens ist
die Verankerung der Aktivität Kontextanalyse im Prozess entscheidend. Sie
bildet die Arbeitsgrundlage für den gesamten Prozess, insbesondere für das
Ableiten von Nutzungsanforderungen,
was die Verknüpfung zum nächsten
Prozessschritt darstellt. Generell gilt,
dass innerhalb eines Prozesses ein
Output nur in dem Maße wertvoll ist, wie
er als Input für einen folgenden Teilprozess dient. Die Kontextanalyse muss
daher ausreichend früh im Prozess stattfinden, also vor einer umfassenden
Spezifikation, etwa in einer Pre-studyphase des Projektes, in der noch nicht
über die technische Plattform und die
Details der Umsetzung entschieden
wurde. Die Qualität der Kontextanalyse
und resultierend deren Ergebnis ist zudem abhängig von organisationalen
Rahmenbedingungen. So bedarf es der
Bereitstellung von ausreichenden Ressourcen und ein ausreichendes ZeitBudget, um die Kontextanalyse in einer
angemessenen Form durchführen zu
können, sowie der Unterstützung durch
das Management und der Organisation.
Wie bereits erwähnt ist das Ergebnis
maßgeblich für die Qualität der Kontextanalyse. Die meisten Experten fokussierten dabei auf die Dokumentation der
Analyseergebnisse (in klassischer
Form), jedoch zeigte sich, dass dies
nicht zwangsläufig so sein muss. Das
Entscheidende ist, dass die Ergebnisse
in einer kommunizierbaren Form vorliegen und zwar so, dass alle Projektbeteiligten die Inhalte zugreifen, verstehen,
nachvollziehen und verarbeiten können.
Kontextbeschreibung im Weiteren meint
daher nicht ausschließlich dokumentiertes Wissen.
283
Bei der Beschreibung bzw. der Kommunikation der Kontextinformationen wurden zwei zentrale Punkte identifiziert,
die beachtet und unterschieden werden
müssen: Kontextdaten müssen so vermittelt werden, dass sie durch Menschen, die nicht an der Erhebung beteiligt waren, verstehbar sind. Außerdem
sollten sie widerspruchsfrei und vollständig sein. Das heißt zum einen es
werden nur sinnvolle und kontextbezogene Daten beschrieben und zum anderen wird Vollständigkeit in Bezug auf die
Systeme, die bei der Aufgabenbewältigung erforderlich sind, sichergestellt.
Ein wesentliches Qualitätsmerkmal für
eine erfolgreiche Kontextanalyse ist laut
Expertenaussagen, dass die Kontextbeschreibung das Erkennen von sogenannten „Implied Needs“ [in DATech
(2008) formuliert, als “Identifizieren der
Erfordernisse”] ermöglicht. D.h. eine
gute Kontextbeschreibung enthält die,
für die Herleitung der Nutzungsanforderungen, erforderlichen Informationen.
Die Experten stimmten darin überein,
dass in der Praxis die Qualität der Ergebnisse sehr stark von der Erfahrung
und Qualifikation der Analysten abhängt.
Die Fokussierung auf das Wesentliche
und das Erheben von Fakten und nicht
deren Interpretation ist dabei in dieser
Phase entscheidend. Weiterhin sind die
Erfahrungen der Nutzer qualitätsentscheidend (Repräsentativität, Fähigkeit
der Nutzer sich auszudrücken, Validität
der Aussagen, etc.).
Ein messbares Qualitätskriterium für
eine Kontextbeschreibung ist, dass die
Gesamtheit der vorhersehbaren Nutzungsanforderungen auf Basis der Kontextbeschreibung ermittelt werden kann.
Befragt man beispielsweise fünf Experten unabhängig voneinander und bittet
diese, auf Grundlage der Kontextbeschreibung, alle Nutzungsanforderungen
abzuleiten die darin enthalten sind, und
kämen alle fünf zu einem vergleichbaren
284
Satz an Nutzungsanforderungen was
Menge und Inhalt angeht, so wäre dies
eine erfolgreiche Kontextbeschreibung. Dies impliziert, dass die Gesamtheit der vorhersehbaren Nutzungsanforderungen auf Basis der
Kontextbeschreibung hergeleitet werden können.
Erfolgskriterien während der Durchführung sind laut Expertenmeinung das
Erkennen schlüssiger Muster. Ein Negativbeispiel ist, wenn bei jedem Interview ein anderer Arbeitsablauf herauskommt, was als ein sicheres Indiz für
die Notwendigkeit weiterer Erhebungen gewertet werden muss bzw. ein
tiefergehendes Verständnis erfordert.
Ein weiteres Erfolgskriterium ist die
Präsentation der Analyseergebnisse,
und zwar nicht nur den Projektbeteiligten, sondern auch der Organisation mit
der bei der Analyse zusammengearbeitet wurde. Die Ergebnisse und Aussagen einer solchen Präsentation sind
ebenfalls Qualitätskriterien.
Eine erfolgreiche Kontextanalyse lässt
sich oft erst im Nachhinein bewerten
und zwar dann, wenn die Nutzer keine
Lücken in der Anwendung finden und
gute messbare Kriterien für das Anwender-erleben abgeleitet werden
können. Eine summative Evaluation ist
ein geeignetes Mittel um dies zu überprüfen.
Ein weiteres, jedoch schwieriger messbares Qualitätskriterium ist die Akzeptanz und der Nutzen der Ergebnisse
im weiteren Prozess und in der Organisation. Ist es möglich, auf Grundlage
der Kontextbeschreibung die Anforderungen zu definieren und ein „gutes
Interaktionsdesign“ zu erstellen, waren
die Analysedaten offensichtlich gut.
Entscheidend ist, dass die Fragen, die
während des Designprozess entstehen, durch die Kontextinformationen
beantwortet werden können.
Eine wichtige Maßnahme zur Sicherstellung der Qualität ist eine Ausbildung der
Durchführenden in der anzuwendenden
Methodik bzw. Methode. Die Qualifizierung der Durchzuführenden bestimmt
maßgeblich die Ergebnisqualität. Qualifikation heißt hier nicht nur Wissen (theoretisch erlernt), sondern auch Können
(praktisch erprobt).
Die Kontextanalyse ist der Grundstein
für die nutzerzentrierte Entwicklung und
ist entscheidend für den Erfolg einer
Lösung. Für die Sicherstellung der Qualität bedarf es sowohl einer Verankerung
der Aktivität(en) und Ergebnisse (Deliverables) im Gesamtprozess, der Bereitstellung ausreichender und qualifizierter
Ressourcen sowie der Einplanung einer
angemessener Zeit zur Durchführung
einer vollständigen Analyse im Projektplan. Dafür ist laut Expertenaussagen
die Unterstützung durch das Management und die Organisation notwendig
und entscheidend.
3.1.2
User Requirements
Das wesentliche Ziel der Aktivität
User Requirements ist, ein tiefgehendes
Verständnis über die organisationalen
und technischen Anforderungen, die
Arbeitsabläufe, Wünsche und Ziele der
Nutzer des zukünftigen Systems zu erarbeiten. Dieses liefert die Basis für valide Systemspezifikationen. Entscheidend
ist dabei der Wechsel von einer rein
technisch getriebenen Sichtweise, hin zu
einer nutzungs- und situationsbezogenen Sicht.
Der Großteil der Experten beschreibt
den Kern dieser Aktivität mit der Spezifikation und Dokumentation von Anforderungen. Es gilt aber zu beachten, dass
das Ergebnis nicht immer in der Form
feingranularer Anforderungen vorliegen
muss. Wesentlich ist vielmehr, dieses
Wissen erfolgreich in den Entwicklungsprozess zu tragen. Entscheidend ist
auch hier, wie schon bei der Kontext-
analyse, sowohl die Erfahrung und
Kompetenz der Analysten bei der Durchführung der Methode, ihre Kenntnis der
Methodik, als auch die Repräsentativität
und Kompetenz der befragten Personen.
Laut Aussagen der Experten lassen sich
eine Reihe an Qualitätskriterien definieren die sowohl auf die Durchführung der
Aktivität, als auch auf das Ergebnis
selbst zielen. So sollten Nutzeranforderungen eine bestimmte Formulierungsqualität (Lesbarkeit, Verständlichkeit,
Konsistenz, etc.) aufweisen und dabei
systemneutral formuliert sein. Sie sollten
auf einem Erfordernis basieren, wodurch
zwangsläufig die Validität sichergestellt
ist – was ein wichtiger Argumentationspunkt sein kann. Nutzeranforderungen
müssen ausreichend präzise sein, d.h.
sie sind auf Ebene der Aufgabe formuliert. Ein Negativ-Beispiel wäre: „Das
System muss benutzbar sein“ – diese
Anforderung ist nicht an einer Aufgabe
verankert, sondern lediglich an einem
abstrakten Ziel. Gute Nutzeranforderungen sind als solche nicht interpretierbar.
Die daraus abgeleitete Lösung unterliegt
selbstverständlich der Interpretation,
nicht aber die Anforderung selbst.
Als ein Erfolgskriterium wird von den
Experten insbesondere die Berücksichtigung von Nutzerzielen und Anforderungen, aber auch die Abstimmung mit
den übergeordneten Geschäftszielen
der Organisation und damit verbundenen Produktzielen angesehen. Ähnliches gilt für die Sicherstellung der Verständlichkeit, Nachvollziehbarkeit und
Verwendbarkeit der Ergebnisse (Requirements) im Prozessverlauf.
Um diese Qualität zu erreichen empfehlen die Experten eine Reihe an Maßnahmen, wie z. B. ein iteratives Vorgehen sowohl bei der Erhebung, als auch
bei dem Ableiten von Anforderungen.
Die Einbeziehung aller am Prozess beteiligten Stakeholder (Nutzer, Auftraggeber, Management, Entwicklung, etc.) ist
unumgänglich. Insbesondere die Vorstellung der Nutzeranforderungen gegenüber dem Management gilt als ein
wichtiges Mittel zur Sensibilisierung.
Dedizierte und qualifizierte Rollen sind
ebenfalls erfolgsentscheidend für den
gesamten Prozess (z.B. sollte kein
Entwickler die Spezifikation schreiben).
3.1.3
Produce Design Solution
Bei der Aktivität Produce Design
Solution geht es um den kreativen
Prozess der Überführung von User
Requirements und dem Wissen über
die Nutzerdomäne und Businessperspektive in ein Konzept für eine neue
Lösung. Dabei werden unterschiedliche Ideen untersucht und verfolgt. Es
ist eine Art Problemlösen mit unterschiedlichen Lösungen. Das Ziel ist,
aus Nutzersicht eine Benutzungsschnittstelle bereitzustellen, die so
effizient und zufriedenstellend wie
möglich ist (alle Informationen, keine
Fehler, keine überflüssigen Schritte,
etc.), also die 7 Grundsätze der Dialoggestaltung erfüllt.
Zentral ist dabei, dass die entwickelte
Lösung zum einen den erhobenen
Anforderungen entspricht (Validität)
aber auch, dass sich die Nutzer sicher
und zufrieden mit den Ergebnissen
fühlen. Für die Entwicklung bedeutet
eine gute Qualität, dass ein Detaillevel
erreicht wurde, der für die Umsetzung
als nützlich erachtet wird. Dabei ist die
Form der Dokumentation nicht das
Entscheidende. Sichergestellt werden
muss aber auch hier, dass die Lösung
erfolgreich kommuniziert wird.
Alternative Design- bzw. Lösungsvorschläge, die zur Überprüfung mit Nutzern herangezogen werden, werden
als sinnvoll und wichtig erachtet. Verständnisfragen der Nutzer - aber auch
seitens der Entwicklung - zu den jeweiligen Lösungsvorschlägen, können ein
Indiz für die Notwendigkeit weiterer Analysen und einer Überarbeitung sein.
Die Qualität der Lösungsvorschläge ist
ebenfalls (aber hier besonders) von den
Erfahrungen und Kenntnissen der Personen abhängig, die diese erarbeiten.
Multidisziplinarität, jedoch unter Berücksichtung klarer Rollen- und Kompetenztrennung (Entwickler, Analyst, Designer,
etc.) wird als qualitätsentscheidend erachtet.
Erfolgskriterien und messbare Qualitätskriterien sind hier nicht trennscharf. Was
jedoch überprüft und gemessen werden
kann, sind beispielsweise die Erfüllung
der Nutzeranforderungen durch das
Design, die Übereinstimmung der Designs mit den Dialogprinzipien [DIN EN
ISO 9241-110(2008)] und denen der
Informationsdarstellung [DIN EN ISO
9241-Teil 12(1998)], vergleichende Untersuchungen alternativer Designs, etc.
Geeignete Maßnahmen zur Qualitätssicherung sind die Verzahnung mit den
benachbarten Prozessaktivitäten, User
Requirements und der Evaluation of Use
sowie das Befolgen einer iterativen Vorgehensweise mit alternativen Lösungsvorschlägen. Um das kreative Potential
zu nutzen, sollten unterschiedliche Rollen im Entwicklungsprozess in die Lösungsfindung einbezogen werden. Dabei ist es aber entscheidend, dass die
Führung bei einem entsprechend qualifizierten Userinterfacedesigner liegt, dessen Rolle explizit ausgewiesen ist und
der in dieser Aktivität das letzte Wort
hat. Diese Notwendigkeit muss dem
Management kommuniziert und von
diesem entsprechend unterstützt werden.
3.1.4
Evaluation of Use
Das Ziel der Aktivität Evaluation of
Use ist es, Feedback über den praktischen Einsatz zu erhalten, um auf dieser
Grundlage das Design und Produkt zu
verbessern. Dabei werden Nutzungs-
285
probleme identifiziert und in der Folge
behoben. Entscheidend dabei ist, dass
Evaluation etwas Kontinuierliches ist
und während des gesamten Prozesses,
in Abhängigkeit der unterschiedlichen
Reifestufen der Ergebnisse, eingesetzt
werden sollte. Viele Evaluationsmethoden fokussieren darauf Probleme zu
finden, zeigen aber keine Lösungsansätze für die gefundenen Probleme auf.
Es ist nicht nur wichtig Probleme zu identifizieren, sondern auch herauszufinden, wie diese Probleme gelöst werden
können. Dies sollte durch den Prozess
reflektiert werden. Wichtig dabei ist,
dass die Ergebnisse weiter verwendbar
und für die Verantwortlichen verständlich
umsetzbar sind.
Die Qualität der Aktivität Evaluation of
Use ist in erster Linie auf das Ergebnis
bezogen. Es wird evaluiert, was vorher
analysiert, gestaltet und umgesetzt wurde. Entscheidend ist, dass dabei die
signifikanten Nutzungsprobleme identifiziert werden. Signifikant sind Dinge die
aus Nutzersicht als störend empfunden
werden. Es gibt darüber hinaus natürlich
Probleme, die valide sind, jedoch nicht
zwangsläufig Störungen für die Nutzer
darstellen. Das bedeutet auch, dass die
Aktivität abgeschlossen ist, sobald keine
signifikanten Probleme mehr gefunden
werden.
Ebenso entscheidend für die Qualität bei
der Durchführung ist das Commitment
aller Beteiligten, die Expertise der Usability Experten sowie die Fähigkeit aller
Beteiligten, Kritik anzunehmen und diese konstruktiv umzusetzen. Messbare
Qualitätskriterien leiten sich aus der
Auswahl und den Einsatz existierenden
Evaluationsmethoden ab (Freymann,
2007). Entscheidende Maßnahmen zur
Qualitätssicherung sind insbesondere
die Qualifizierung der Personen, die
Explikation der Evaluation als essentielle
Tätigkeit im Prozess sowie die Bereitstellung ausreichender Zeit zur mehrfachen Durchführung im Projektplan.
286
4.0
Zusammenfassung & Fazit
Die Usability eines Softwareproduktes ist heute ein entscheidendes
Qualitätskriterium bei der Erstellung
und in der Vermarktung. Die Unterschiede der Unternehmensstrukturen,
Entwicklungsprozesse und organisationalen Rahmenbedingungen macht es
jedoch schwierig dieses Wissen in den
Projektalltag zu übertragen. Dies ist
sicherlich ein Grund, warum in der
Praxis und Theorie eine Vielzahl an
unterschiedlichen Integrationsansätzen von Usability- und SoftwareEngineering existiert. Einige dieser
Ansätze fokussieren sehr spezifisch
auf diese Gegebenheiten, andere wiederum sind sehr allgemein und abstrakt formuliert.
Zwar existiert auf Seiten der Usability
Experten sicherlich ein relativ einheitliches Verständnis darüber was Usability Engineering ausmacht. Standards,
wie die DIN EN ISO 13407, tun dies,
durch Definition allgemeiner Prinzipien
und Aktivitäten, allerdings auf einer
bewusst abstrakten Ebene.
Um zu ermitteln, was aus Sicht der
Experten das Entscheidende am Usability Engineering ist, wurden Experteninterviews durchgeführt und Fragebogen angewandt, die auf die Qualitätsaspekte des Usability Engineering
abzielen. Die Befragung erfolgte unabhängig von einem zugrunde liegenden Entwicklungsmodells oder der
praktischen Umsetzung.
Die daraus resultierenden Qualitätsanforderungen und -eigenschaften sind
zum Teil einheitliche, zum Teil ergänzende Aussagen unterschiedlicher UEExperten, die unabhängig voneinander
befragt wurden und deren Antworten
einander gegenüber gestellt wurden.
Sie verdeutlichen die Bedeutung einer
engen Verzahnung von UE und SE
sowie einer Weiterverwendung von
UE-Ergebnissen im Entwicklungspro-
zess und können als Referenz herangezogen werden wenn es darum geht,
Usability Engineering in einem Unternehmen zu etablieren.
5.0
Granollers, T., Lorès, J. & Perdrix, F. (2002):
Usability Engineering Process Model. – Integration with Software Engineering. In Proceedings of HCI International 2003. New
Jersey, USA: Lawrence Erlbaum Associates
DIN EN ISO 13407 (1999). Human-centered
design processes for interactive systems.
Brussels: CEN - European Committee for
Standardization
ISO/PAS 18152 (2003). Ergonomics of human-system interaction — Specification for
the process assessment of human-system
issues. First Edition 2003-10-01. Switzerland:
ISO copyright office
Nebe, K. & Zimmermann, D. (2007): Suitability of Software Engineering Models for the
Production of Usable Software. In: Engineering Interactive Systems 2007, IFIP WG 13.2
1st Conference on Human Centred Software
Engineering 2007
Nebe, K. & Zimmermann, D. (2007): Aspects
of Integrating User Centered Design to Software Engineering Processes. In: Proceedings
of the HCII International 2007. Springer
DATech (2008): Leitfaden Usability. Frankfurt
am Main, Germany: Deutschen Akkreditierungsstelle Technik e.V in der TGA GmbH
DIN EN ISO 9241-12 (1998): Ergonomie der
Mensch-System-Interaktion. Ergonomische
Anforderungen für Bürotätigkeiten mit Bildschirmgeräten. Teil 12: Informationsdarstellung. Berlin: Beuth
DIN EN ISO 9241-110:2006(E) (2006): Ergonomie der Mensch-System-Interaktion. Teil
110: Grundsätze der Dialoggestaltung. Switzerland: ISO copyright office
Freymann, M. (2007): Klassifikation nutzerzentrierter Evaluationsmethoden im User
Centered Design Prozess. Diplomarbeit. Paderborn: Universität Paderborn.
Faktoren zur erfolgreichen Umsetzung von
User-Centred-Design-Aktivitäten – Beispiele aus der Praxis
Dirk Zimmermann
T-Mobile Deutschland GmbH
Landgrabenweg 151
53227 Bonn
[email protected]
Markus van Ballegooy
Landgrabenweg 151
53227 Bonn
[email protected]
Kathrin Jepsen
Landgrabenweg 151
53227 Bonn
[email protected]
Dagmar Wehr
Gartenstrasse 217
48153 Münster
[email protected]
Abstract
Zur erfolgreichen Umsetzung von User
Centred Design Aktivitäten in größeren
Entwicklungsorganisationen ist es nicht
ausreichend, die gängigen Methoden
und Ansätze zu kennen und zu beherrschen. Vielmehr spielen Fragen der internen PR, der Projektanbahnung und
Planung, des richtigen Timings von Aktivitäten und Ergebnissen sowie eine den
Bedürfnissen der Organisation ange-
messene Aufbereitung eine entscheidende Rolle. Ergebnisse aller UCDAktivitäten sind letzen Endes nutzlos,
wenn sie keinen Einfluss auf die Entwicklung der Produkte erzielen. In diesem Beitrag werden, basierend auf
Erfahrungen aus verschiedenen Projekten der Autoren, einige dieser Faktoren benannt und diskutiert. Sowohl
Positiv- wie Negativ-Beispiele
verdeutlichen, dass die genannten Faktoren gerade in größeren Entwicklungsorganisationen für eine erfolgreiche
UCD Umsetzung relevant sind.
Ein aktuelles Thema, mit dem sich
die Human-Computer Interaction (HCI)
Gemeinschaft beschäftigt, ist die Integration von User Centred Design (UCD)
Aktivitäten in die Entwicklungsprozesse
von Unternehmen sowie die verbesserte
Verankerung des UCD-Themas in der
Organisation (Rosenbaum et al. 1999;
Nebe & Zimmermann, 2007). Dazu zählen u. a. die durchgängige Beteiligung
von Usability-Experten an Entscheidungsprozessen sowie die Gleichberechtigung von technischen und Nutzeranforderungen in der Planung und
Durchführung
von
ITEntwicklungsprojekten.
UCD und Entwicklung gegeben. Dennoch gibt es einige Ansätze, die dies in
Form von integrierten Modellen versuchen, wie beispielsweise Mayhew
(1999), Cooper (2003) oder IBM
(1996). In diesen Modellen wird beschrieben, welche UCD-Methoden zu
welchem Zeitpunkt der SoftwareEntwicklung geeignet sind, um Nutzungsanforderungen und NutzerFeedback in der Analyse und Gestaltung von IT-Systemen angemessen zu
berücksichtigen. Der Schwerpunkt wird
dabei allerdings immer noch stark auf
konkrete UCD-Methoden und -Modelle
gelegt, die Rahmenbedingungen in der
jeweiligen Organisation bleiben auch
dort größtenteils unbetrachtet.
Ergebnisaufbereitung eine entscheidende Rolle bei der Frage, welchen Einfluss
die UCD-Ergebnisse auf die Entwicklung
und somit die Usability der resultierenden Produkte erzielen.
UCD stellt eine Reihe von Modellen und
Methoden zur Sicherstellung der Nutzerorientierung in der Softwareentwicklung zur Verfügung. In der Praxis orientiert sich der Einsatz dieser Methoden
und den verbundenen Aktivitäten meist
stark an allgemeinen SoftwareEntwicklungs-Modellen. Die UCDAktivitäten finden häufig nebenläufig zur
Software-Entwicklung statt und demzufolge ist nicht immer eine Integration von
Zur erfolgreichen Umsetzung der Ergebnisse von UCD-Aktivitäten im Sinne von Usability-Verbesserungen ist
es in der Regel nicht ausreichend, die
gängigen UCD-Methoden und Ansätze
zu kennen, zu beherrschen und anzuwenden. Vielmehr spielen Fragen der
internen PR, der Projektanbahnung
und –planung, des richtigen Timings
von Aktivitäten sowie eine den Bedürfnissen der Organisation angemessene
1.0
Einleitung
Keywords
User Centred Design, Prozesse, Organisationale Integration, Erfolgsfaktoren
Die Autoren berichten über die praktischen Erfahrungen, die sie zu diesem
Aspekt in ihrer Organisation gemacht
haben. Es handelt sich hierbei um den
IT-Bereich der T-Mobile Deutschland
GmbH, in dem die UCD-Abteilung sich
schwerpunktmäßig um die Gebrauchstauglichkeit der eigenen IT-Systeme des
Unternehmens kümmert. Dies sind sowohl Vertriebs- und KundenpflegeSysteme zur Nutzung durch interne Mitarbeiter, wie auch E-Business und
Selbstadministrations-Systeme für Endkunden. Entwicklungsprojekte werden in
unterschiedlichen Phasen durch UCD
unterstützt, so z.B. in frühen Machbarkeits-Studien mit grundlegenden Kontext- und Workflowanalysen oder Evaluationen von Bestandssystemen. In späteren Phasen, wie z.B. dem detaillierten
Systemdesign, wird durch Erhebung von
konkreten Informations- und Interaktionsanforderungen sowie durch Konzeption und Layout in verschiedenen For-
287
men sichergestellt, dass die Ziellösung
sowohl dem Kontext, wie auch den konkreten Aufgaben der Nutzer genügt.
In diesem Beitrag werden, basierend auf
Erfahrungen aus verschiedenen Projekten der Abteilung, einige der förderlichen
oder hinderlichen Faktoren bei der Integration von UCD in Entwicklungsprozesse
benannt und diskutiert.
2.0
Relevante Faktoren zur Integration
von UCD in Organisationen
Etablierung und interne Werbung
Beim Aufsetzen und Etablieren der
UCD-Abteilung hat die Erfahrung gezeigt, dass verschiedene Faktoren den
Erfolg beeinflussen können. Gerade in
den letzten Jahren findet der Begriff
"Usability" immer breitere Verwendung.
Allerdings zeigt sich häufig, dass Projektpartner damit eine falsche Erwartung
bezüglich der Aufgaben und Ergebnisse
der Abteilung verbinden. Immer wieder
musste klargestellt werden, dass die
Hauptaufgabe und der Mehrwert des
UCD nicht in der nachträglichen Bewertung von Produkteigenschaften oder der
visuellen Ausgestaltung einer Oberfläche liegt, sondern dass der UCD-Ansatz
ein umfassenderes Set an Analyse-,
Gestaltungs- und Evaluations-Aktivitäten
erfordert.
Ebenso hat die Verwendung von UCDTermini wie z. B. "Anforderungsanalyse"
bei benachbarten Abteilungen Verwirrung erzeugt, da der Begriff dort mit anderen Aufgaben und Rollen besetzt war
und die Sorge bestand, dass deren Tätigkeitsspektrum beschnitten werden
sollte.
Bei der Einführung des Themas stellt
also die Tätigkeit des Erklärens und
Verkaufens von UCD in der Regel sowohl für die operativ Arbeitenden, wie
auch für die Führungskraft eine ständige
Aufgabe dar. Für Führungskräfte bedeu-
288
tet dies, dass sie zum einen innerhalb
der Abteilung den projektübergreifenden Austausch fordern und fördern
und die Wissensvermittlung bei Projektpartnern ihren Mitarbeitern als
ständige Aufgabe mitgeben. Zum anderen heißt es aber auch, dass über
die konkrete Projektarbeit hinaus die
Aufmerksamkeit für und Anerkennung
von UCD kontinuierlich aufrechterhalten werden muss, etwa durch Veröffentlichung von Erfolgsgeschichten,
dem Aufsetzen von expliziten Usability-Projekten oder der Eskalation von
Anforderungskonflikten.
Organisationale Zuordnung
UCD-Teams, die innerhalb der ITSeite einer Entwicklungsorganisation
angesiedelt sind, verfügen durch die
„räumliche“ und prozessbedingte Nähe
über eine tiefere Einsicht und bessere
Zugriffsmöglichkeiten auf den Entwicklungsteil von IT-Projekten. Ergebnisse
von UCD-Aktivitäten können hier
schneller und unkomplizierter in die
Software-Entwicklung
eingebracht
werden. Die bessere Einsicht in die ITinternen Prozesse eröffnet dem UCDTeam bessere Möglichkeiten, Ergebnisse an der richtigen Stelle unter Berücksichtigung der jeweiligen Projektphasen direkt in die Softwareentwicklung einzuspeisen. Innerhalb einer
Organisation mit mehreren Fachseiten
ist eine zentral in der IT angesiedelte
UCD-Abteilung zu empfehlen, um
fachübergreifende Themen zu identifizieren, Synergien zwischen Projekten
zu nutzen und ggf. redundante Aktivitäten aufzudecken.
Auf der anderen Seite bietet eine Zuordnung des UCD-Teams zur Business-Seite eines Unternehmens die
Möglichkeit, die Formulierung von Business-Anforderungen durch UCDAktivitäten zu unterstützen – noch vor
dem Start der IT-Entwicklung. Für Or-
ganisationen, in denen es nur eine zentrale Fachseite gibt, könnte dies die besser geeignete Wahl darstellen
Nach der Erfahrung der Abteilung ist
eine organisational virtuell zwischen
Business und IT angesiedelte Rolle ideal
zur erfolgreichen Umsetzung von UCDAktivitäten. Als sehr günstig hat sich
dabei im Projektalltag erwiesen, insbesondere bei Neuentwicklungen, IT und
Business frühzeitig in UCD-Aktivitäten
einzubeziehen und zum Beispiel bei der
Definition von Use Cases für eine neue
Anwendung eine Zusammenarbeit zu
initiieren: In einigen Projekten war festzustellen, dass die zusätzlichen Ergebnisse der UCD-Aktivitäten sowohl fachlichen als auch IT-seitigen Systemsverantwortlichen wertvolle Informationen
sowie eine bessere und vollständigere
Vorstellung davon geben konnten, wie
die eigentlichen Anwender mit den Systemen arbeiten.
Verankerung von UCD-Aktivitäten im
Entwicklungsprozess
Neben einer günstigen organisationalen Ansiedlung ist auch die prozessbezogene Verankerung für eine erfolgreiche Arbeit von UCD-Tams wichtig.
Zusätzlich zur grundsätzlichen Zielsetzung, sich möglichst früh an Projekten
zu beteiligen, hat sich in der Erfahrung
der Autoren als günstig erwiesen, zu
Beginn eines Projektes klare Aufgabendefinitionen für die Arbeit des UCDTeams vorzunehmen. Dabei sollte den
Projektverantwortlichen idealerweise für
den gesamten Projekthorizont verdeutlicht werden, welche UCD-Aufgaben
wann und wo im Entwicklungsprozess
geleistet werden können und welchen
Beitrag diese für einzelne Meilensteine
und das Gesamtergebnis des Projektes
liefern. In Organisationen, in denen UCD
noch nicht als üblicher Standard etabliert
ist, bietet dieses Vorgehen den Vorteil,
das eigentliche Ziel, aber auch die
Grenzen von UCD aufzeigen zu können
und so die Erwartungen der Projektbeteiligten sinnvoll zu steuern.
Es hat sich zudem als zielführend erwiesen, auch die Übernahme von Dokumentations- und Koordinationsaufgaben
im Prozess anzustreben, wie zum Beispiel die UI-Spezifikation oder auch die
Moderation von (Design-)Workshops der
Projektbeteiligten. In den Projekten, in
denen dies gelang, zeigte sich letztlich,
dass das Einbringen von UCDErgebnissen deutlich einfacher und integrierter möglich war als in Projekten,
bei denen lediglich Ergebnisse zu einzelnen Deliverables beigetragen wurden. Zudem sollte beim Aufsetzen eines
Projektes die Rolle eines UCDVerantwortlichen aus dem eigenen
Team benannt werden, der – idealerweise auch längerfristig -- im Sinne eines Key-Account-Managers als Ansprechpartner für Fach- und IT-Seite
fungiert und alle UCD-relevanten Aktivitäten innerhalb des Projektes koordiniert
sowie deren Umsetzung verantwortet.
Das Anerkennen der organisationalen
und technischen Rahmenbedingungen
ist in der Erfahrung der Autoren unumgänglich, um eine Mitsprache bei Entwicklungsprojekten zu haben. Hier ist
Verhandlungsgeschick und Kompromissfähigkeit essentiell, um die Umsetzung von UCD-Ergebnissen zu verwirklichen.
Abgleich mit Entwicklungszyklen der
Organisation
Große Organisationen verfügen in
der Regel über eine zyklisch organisierte
IT-Entwicklung, bei der für die einzelnen
Phasen des Entwicklungsprozesses und
dem Roll-Out der System-Releases zeitliche Vorgaben bestehen.
Für die Arbeit von UCD-Teams bedeutet
dies, dass sie die Durchführung und
Ergebnisse ihrer Aktivitäten in der Regel
in diese Zeitfenster einpassen müssen. Dies ist nicht nur als Erschwernis
zu sehen, die eine proaktive Projektplanung und eine große Flexibilität
beim Ressourceneinsatz erfordert. Auf
der anderen Seite existiert nämlich in
den meisten Fällen auch die Möglichkeit, UCD-Ergebnisse über mehrere
Releases einer Anwendung hinweg
umzusetzen. Die iterative Weiterentwicklung von Systemen erlaubt es
unter anderem, hoch priorisierte Anforderungen sofort, und nachgelagerte
Anforderungen in einem Folgerelease
einzubringen. Um dieses zu gewährleisten, ist eine releaseübergreifende
Einbindung des UCD-Teams in die ITProjekte erforderlich, so dass Nutzungsanforderungen nachverfolgt und
laufend in die passenden Prozessphasen eingespeist werden können.
Darüber hinaus hat es sich bewährt,
das UCD-Team auch in die Reviewphase zu integrieren – idealerweise sollte es auch zur Abnahme berechtigt sein. In der Praxis zeigte sich,
dass ein zeitnahes Treffen während
der Reviewphase bei Verständnisproblemen oder abgelehnten Kommentaren zielführend ist. Eine Voraussetzung ist hier, dass auf der Basis zuvor
priorisierter und kommunizierter Ergebnisse diskutiert wird.
Interner Support durch andere Abteilungen im Unternehmen
UCD-Teams sind bei ihrer Arbeit
in hohem Maße auf Information und
operative Unterstützung durch andere
Fach- und IT-Abteilungen angewiesen.
Wird diese nicht durch Vereinbarungen
und ggf. auch in der allgemeinen Projektplanung zu Beginn von Projekten
sichergestellt, kann es nach unserer
Erfahrung zu Effizienzeinbußen bei der
Durchführung von UCD-Aktivitäten
kommen.
Folgende Aspekte haben sich für die
Abteilung als kritisch für einen Projekterfolg erwiesen und sollten bei der Planung von UCD-Projekten bedacht werden:
Ein hinreichender Überblick über die
derzeitige Systemlandschaft, innerhalb
der ein neues System entwickelt werden
soll, sowie die fachseitige Sicht auf die
Systemnutzung sind für das Aufsetzen
von UCD-Aktivitäten essentiell. In großen Unternehmen müssen die benötigten Informationen in der Regel von mehreren Personen (aus Fach- und IT-Seite)
zusammengetragen werden.
Informationen über vorangegangene
UCD-relevante Untersuchungen (Marktforschung, Kundenzufriedenheitsbefragungen, Ergebnisse aus Fokusgruppen)
sind, ebenso wie Informationen über
Management-Interviews,
z. T. sehr
nützlich, um eine erste Vorstellung der
derzeitigen Schwachstellen eines Systems zu bekommen, um zu ermitteln,
welche Unternehmensziele durch das
System erreicht werden sollen und um
die Schwerpunkte von UCD-Aktivitäten
nach diesen ausrichten zu können. Diese Informationen müssen bei den entsprechenden Ansprechpartnern aus den
Fachabteilungen angefragt werden können.
Fachliche Fragen, z.B. zu Geschäftsprozessen, relevanten Nutzergruppen, Vertriebsstrukturen, Rechtekonzepten, Produkten
und
zukünftigen
MarktEntwicklungen kommen immer wieder
auf. Hier sollte sichergestellt werden,
dass über die gesamte Projektlaufzeit
entsprechende Ansprechpartner aus
den Fachabteilungen zur Verfügung
stehen.
Kontakte zu echten Kunden/Nutzern für
Befragungen und Nutzertests sind ebenfalls oft nur über andere Abteilungen
effizient herzustellen, da diese in der
Regel die Steuerungshoheit über Kundenkontakte haben (zur Vermeidung von
289
mehrfachem oder unberechtigtem Ansprechen der Kunden). Bei unternehmensinternen Nutzern ist zu berücksichtigen, dass Befragungen bzw. Untersuchungen an deren Arbeitsplätzen zum
einen einer Freistellung von der eigentlichen Aufgabe bedürfen und zum anderen durch betriebliche Vereinbarungen
mit der Arbeitnehmervertretung des Unternehmens geregelt sein können und
ggf. eine entsprechende, oft nicht zeitnah zu erhaltende Genehmigung erfordern. Hierbei ist auch zu beachten, dass
Begriffe wie "Befragung" oder "Nutzertest" bei Probanden oder Arbeitnehmervertretern nachvollziehbare Befindlichkeiten auslösen können. Sie sollten
vermieden werden und eine proaktive,
rechtzeitige Aufklärung zu Sinn und
Zweck der Untersuchung seitens der
UCD-Abteilung erfolgen.
Erfolgreiche Nutzenargumentation für
Usability Anteile
Ein zentraler Aspekt der Akzeptanz
von UCD-Ergebnissen ist, dass diese
nicht nur die Anforderungen von und
den Nutzen für den Endanwender, sondern auch die Business-Interessen des
Unternehmens berücksichtigen.
Bei der Implementierung von UCD muss
man auf das Argument vorbereitet sein,
dass die durch UCD ermittelten Anforderungen zusätzlichen Aufwand zu den
Business-Anforderungen erzeugen. In
unserer Erfahrung hat sich der durch die
Abteilung gewählte Ansatz bewährt, bei
Projektbeginn zu verdeutlichen, dass
das UCD zur Verwirklichung der Business Interessen einen essentiellen Beitrag liefert – z.B. indem Abhängigkeiten
zwischen den Zielen der Endnutzer und
dem Konzernziel transparent gemacht
werden. So ist die BusinessAnforderung einer Umsatzsteigerung am
Point of Sale (PoS), welche bei der Systemidee eines konzernübergreifenden
Vertriebsportal maßgeblich ist, identisch
290
mit dem Ziel der Endnutzer, deren
Entlohnung ebenfalls über erfolgreiche
Verkäufe beeinflusst wird. Herausforderung des UCD-Teams ist es zu verdeutlichen, dass die systemseitigen
Prozesse mittels UCD-Methoden so
ausgestaltet werden können, dass
Ziele der Nutzer unter Berücksichtigung der technischen Rahmenbedingungen und der konzerninternen Prozesse effizienter verwirklicht werden
können.
Die aktive und frühzeitige Einbeziehung der Endnutzer liefert dem Entwicklungsprojekt Informationen über
die „Pain Points“ aktuell verwendeter
Systeme. Diesen kann dann bei der
Optimierung vorhandener Prozesse
gezielt nachgegangen werden kann.
Workflowanalysen zeigen auf, welche
Prozesse vorrangig durch ein zukünftiges System unterstützt werden sollen.
In diesem Zusammenhang sollte auch
das Argument, dass aufgrund der Einbeziehung der Nutzer in die Systementwicklung zusätzliche Aufwände
entstehen, entkräftet werden: Inhouse
UCD bei T-Mobile agiert nie losgelöst
von den technischen und organisationalen Rahmenbedingungen und liefert
eine realistische frühzeitige Priorisierung der systemseitig zu unterstützenden Prozesse. UCD Ergebnisse werden demzufolge als zielführend hinsichtlich der unmittelbar umzusetzenden Prozesse dargestellt, statt nur den
Charakter einer „Wunschliste“ der Anwender zu haben.
Die Praxis bestätigt sogar den umgekehrten Fall: Durch UCD können Aufwände reduziert werden, wenn sich
ursprüngliche Anforderungen aus Nutzersicht als nicht sinnvoll oder notwendig erweisen. So war es z.B. bei
einer Entwicklung für Mitarbeiter am
PoS essentiell, das Telefonieverhalten
der Kunden zu kennen, um auf dieser
Basis eine bedarfsgerechte Kundenbe-
ratung durchführen zu können. Eine
hierfür zunächst angedachte aggregierte
Aufbereitung des Telefonieverhaltens
hätte einen erheblichen Entwicklungsaufwand zur Folge gehabt. Mittels der
Kontextanalyse wurde jedoch offenkundig, dass eine Einsicht in die Kundenrechnung für die Berater ausreichend ist
– guten Gewissens konnten sich die
Projektbeteiligten auf die kostengünstigere Umsetzungs-Variante einigen.
Ein Mehrwert für die Einbeziehung von
UCD bei Entwicklungsprojekten ist in
den Erfahrungen der Autoren die integrative Rolle, die das UCD-Team im
Gesamtprojekt einnehmen kann. So wird
bei komplexen Projekten häufig offenkundig, dass die beteiligten Fachseiten
Spezialisten in ihrem Themenbereich
sind. Bei Systemen, die Prozesse verschiedener Facheinheiten integrieren, ist
aber eine umfassende Sicht auf die systemübergreifenden Prozesse notwendig.
So liefern vom UCD-Team durchgeführte Kontextanalysen und Site Visits eine
Gesamtsicht, die wesentlich für die effiziente Erstellung und Ausgestaltung der
Use Cases ist. Oftmals wurden zuvor
unbekannte Gemeinsamkeiten zwischen
Nutzergruppen entdeckt und somit Speziallösungen reduziert.
Insbesondere komplexe Projekte, bei
denen auch Interessenskonflikte der
Stakeholder auftreten können, profitieren von folgender Vorgehensweise: Auf
Basis der vom UCD-Team eingebrachten Ideen zur Ausgestaltung können die
Beteiligten gemeinsam Lösungen entwickeln, statt eigens entwickelte Lösungsvorschläge zu vergleichen und zu verhandeln.
Ein Mehrwert der Integration von UCDMethoden resultiert in der Erfahrung der
Autoren auch aus dem Prototyping, also
der visuellen Umsetzung der Projektergebnisse und Zwischenstände während
der Systementwicklung: Prototyping
liefert in diesem Kontext „greifbare“ Dis-
kussionsgrundlagen und fördert die sukzessiven Abstimmungsprozesse unter
Berücksichtigung der Abhängigkeiten
der Nutzungsanforderungen. Die iterative Vertestung von Prototypen stellt sicher, dass das Systemziel verfolgt wird.
Die zeitnahe Evaluation der Prototypen
liefert den Beteiligten wertvolle Hinweise, welche Designalternativen konsolidiert werden können. Da valide erhobene Evaluationsergebnisse auf mehrere
Systembereiche übertragbar sind, können diese auch bei nicht unmittelbar zur
Umsetzung geplanten Folgereleases
eine Richtschnur darstellen.
Das im Rahmen des UCD betriebene
systematische Nachverfolgen von Nutzungsanforderungen ist ein Bestandteil
des insbesondere in großen Organisationen erforderlichen Requirement Managements. So können die vom UCDTeam angefertigten Dokumentationen
und Priorisierungen der Nutzungsanforderungen die Fachseiten bei der Stellung von Change Requests unterstützen.
Die Integration von UCD bei der Systementwicklung liefert meistens nicht nur
auf ein konkretes System bzw. die dort
abzubildenden Prozesse bezogenen
Input von Endnutzern. Eine Vielzahl der
Ergebnisse können bei vergleichbaren
Businessanforderungen für alternative
Systeme oder prozessübergreifende
Optimierungen genutzt werden oder
sogar Kontextprobleme aufdecken, deren Lösung nicht durch die IT allein angegangen werden müsste. Durch den
proaktiven Umgang mit diesem Input
profitieren auch andere Projekte von den
Ergebnissen des UCD.
3.0
Bewertung und Ausblick
Die Abteilung hat in der Umsetzung
von UCD die Erfahrung gemacht, dass
trotz anerkannter Expertise der Mitarbeiter, korrekter Auswahl und Anwendung
von Methoden und fachlich valider Auf-
bereitung der Ergebnisse der Projekterfolg im Sinne einer Usabilityoptimierten Lösung oftmals nicht erreicht werden konnte. Einen merklichen Impact gab es erst dann, wenn
die in diesem Beitrag beschriebenen
Erfolgsfaktoren erfüllt waren: Organisationale
und
prozesstechnische
Rahmenbedingungen wurden mit aufgegriffen,
Methodenauswahl
und
Durchführung orientierte sich an übergreifenden Anforderungen aus Business und IT, Ergebnisse wurden so
aufbereitet, dass nachfolgende Projektbeteiligte einfach damit weiterarbeiten konnten und der Mehrwert einer
UCD-Beteiligung wurde kontinuierlich
herausgearbeitet.
Die dargestellten Ansätze und Beispiele haben allesamt gemein, dass sie
letztendlich die Position der UCDAbteilung sowie Akzeptanz und Weiterverwendung der Ergebnisse fördern. Sie flankieren den effizienten
Einsatz und die qualitativ hochwertige
Durchführung von Methoden, um die
Berücksichtigung der Ergebnisse im
Unternehmen im Alltag zu etablieren.
Hierbei ist im Sinne einer nachhaltigen
Verankerung natürlich auch wichtig,
dass die Ergebnisse auch auf Dauer
zuverlässig, zutreffend und im Hinblick
auf Unternehmensziele förderlich sind.
Entscheidungen, die auf fehlerhaften
Ergebnissen basieren, können einen
erzielten Reputationsgewinn schnell
wieder zunichte machen.
auf beliebige Firmenkontexte wäre aufgrund des Fallbeispiel-Charakters der
einzelnen Aspekte nicht angemessen.
4.0
Danksagung
Die Autoren bedanken sich beim ITManagement der T-Mobile Deutschland
GmbH für das Ermöglichen dieses Beitrags. Zusätzlich danken wir unserer
Abteilungsleiterin Claudia Roennefahrt
für die konstruktiven Rückmeldungen bei
der Zusammenstellung des Beitrags,
ebenso wie für die Möglichkeit, zu den
beschriebenen Faktoren sowohl in Projekten wie auch übergreifend Erfahrungen sammeln und unsere UCD-Arbeit
dadurch stetig optimieren zu können.
5.0
Literaturquellen
Cooper, A. (2003): About Face 2.0. Wiley
Publishing Inc., Indianapolis, US.
IBM (1996). Ease of Use Model. abgerufen
von http://www3.ibm.com/ibm/easy/
eou_ext.nsf/publish/1996, (11/2004).
Mayhew, D. (1999): Usability Engineering
Lifecycle. San Francisco: Morgan Kaufmann.
Nebe, K & Zimmermann, D (2007): Aspects
of Integrating User Centered Design into
Software Engineering Processes. In: Jacko,
J. (Hrsg.): Proceedings of HCI 2007. Heidelberg: Springer Verlag.
Rosenbaum, S., Rohn, J. & Humburg, J.
(1999): What Makes Strategic Usability Fail?
Lessons Learned from the Field. In: Proceedings of CHI 1999, 93-9
Die in diesem Beitrag gesammelten
Erfahrungen können nur eine subjektive Zusammenstellung darstellen, deren Validität auch von den lokalen Gegebenheiten im Unternehmen abhängt. Die Autoren verstehen die einzelnen Abschnitte als Anregungen, die
von interessierten Lesern in ähnlichen
Organisationen aufgegriffen, durchdacht und ggf. umzusetzen versucht
werden können. Eine Generalisierung
291
292
Methoden un d Proz e s s e
293
294
Evaluation eines Human-Machine-Interfaces für TowerFluglotsen unter Einsatz eines Simulators
Christina König
Technische Universität Darmstadt
Petersenstraße 30
64287 Darmstadt
[email protected]
Thomas Hofmann
Petersenstraße 30
64287 Darmstadt
[email protected]
Jörg Bergner
Forschung und Entwicklung
DFS Deutsche Flugsicherung GmbH
Am DFS-Campus 10
63225 Langen
[email protected]
www.dfs.de
Ralph Bruder
Petersenstraße 30
64287 Darmstadt
[email protected]
Abstract
Zur Unterstützung der Arbeitsaufgabe
bei steigenden Anforderungen im Luftverkehr wurde ein neuartiges HMI für
Tower-Fluglotsen entwickelt und in einer
Reihe von Simulationen während des
Gestaltungsprozesses evaluiert.
Der Beitrag zeigt den Nutzen einer
formativen Evaluation in einem iterativen Designprozess und geht dabei
besonders auf die Möglichkeiten der
Datenerfassung in einer EchtzeitSimulation ein.
Keywords
aufbereiten und präsentieren. Je besser diese Daten auf die anstehenden
Entscheidungen und Handlungen des
Lotsen abgestimmt sind, desto effizienter und sicherer kann er seiner
Arbeit nachgehen. Dies war ein Ziel
des hier vorgestellten Projekts.
Die Herausforderung lag darin, eine für
die Arbeitsaufgabe und -situation optimal angepasste Gestaltungslösung zu
entwickeln, die sowohl ergonomischen
und betrieblichen Anforderungen genügt
als auch die Akzeptanz der Lotsen besitzt. Die Expertise der Lotsen wurde
daher ebenso in den Gestaltungsprozess einbezogen wie die der Psychologen, Designer und Ingenieure. Die Eignung des Interfaces für die Arbeitsaufgabe sowie die Akzeptanz seitens der
Lotsen sollte projektbegleitend evaluiert
werden.
Simulation, Beobachtungsinterview,
iterativer Gestaltungsprozess,
Arbeitswissenschaft, Flugsicherung
Um der hoch komplexen Arbeitssituation
gerecht zu werden und Ergebnisse auf
den realen Tower-Betrieb übertragen zu
können, kam dazu ein Tower-Simulator
zum Einsatz, in dem mehrere Lotsen in
einer höchst realistischen Umgebung
Szenarien bearbeiten.
1.0
Einleitung
Der Beruf des Fluglotsen ist eine
hoch beanspruchende Tätigkeit. Ein
hohes Maß an Verantwortung verbunden mit extrem kurzen Entscheidungsphasen führt zu einer starken Arbeitsbelastung. Zunehmender Luftverkehr und
die immer komplexeren Entscheidungsketten steigern diese zusätzlich (Leonhardt 2005; Manning 2005).
1.1
Arbeitsplatz Tower-Lotse
Diese hohe Anforderung gilt auch
für den Arbeitsplatz des Tower-Lotsen,
zu dessen Aufgaben die Koordination
der Starts und Landungen gehört. Besonders in Phasen hohen Flugverkehrsaufkommens muss er in kurzer Zeit
eine Vielzahl unterschiedlicher Informationen verarbeiten sowie schnell und
sicher handeln.
Die Arbeitsmittel der Lotsen sollen sie
bei der Informationsverarbeitung optimal
unterstützen. Sie sollten dem Lotsen
entscheidungsrelevante Daten effizient
1.2
Beschreibung des Projekts
In einem interdisziplinären Team
aus Arbeitswissenschaftlern, Designern, Ingenieuren und Lotsen wurde
vom Institut für Arbeitswissenschaft
gemeinsam mit der DFS Deutsche
Flugsicherung GmbH und delair Air
Traffic Systems GmbH ein HumanMachine-Interface (HMI) für einen
Towerlotsen-Arbeitsplatz entwickelt.
Das Projekt fand im Rahmen des vom
Bundesministerium für Wirtschaft und
Technologie geförderten 4. Luftfahrtforschungsprogramms im Verbundvorhaben Wettbewerbsfähiger Flughafen
(WFF) statt, das u. a. eine effizientere
Abwicklung des Flugverkehrs an deutschen Großflughäfen zum Ziel hat.
2.0
Projektablauf
Die Entwicklung eines HMI für Fluglotsen stellt besondere Anforderungen
an das Entwicklungs- und Evaluationsteam. Konventionelle Gestaltungsprinzipien (z.B. DIN EN ISO 9241-110) können nur zum Teil angewandt werden.
Die äußeren Bedingungen im Tower wie
hoher Entscheidungsdruck oder schwierigen Umgebungsbedingungen führen
einerseits zu Einschränkungen, der ho-
295
he Trainingsgrad der Benutzer andererseits aber auch zu neuen Gestaltungsmöglichkeiten.
2.1
Iterativer Designprozess
Das Vorgehen im Projekt folgte dem
Prinzip des iterativen Designs (Genov
2005): Nach Analyse der bestehenden
Arbeitssituation, der Arbeitsaufgaben
sowie aktueller Bedienkonzepte wurden
Soll-Kriterien für das Interface definiert.
Auf der Basis dieser grundlegenden
Erkenntnisse wurden nun mehrere iterative Schleifen im Vorgehen begangen:
Nach der Programmierung aktueller
HMI-Entwürfe und -varianten wurden
diese im 3D-Realzeit-Tower-Simulator
der DFS eingesetzt. Die sich aus den
Erkenntnissen der Simulation ergebenden Veränderungsvorschläge führten
jeweils zu einer weiteren Schleife mit
einem verbesserten HMI.
tung. Daher wurde als Testumgebung
der 3D-Echtzeit-Tower-Simulator der
DFS ausgewählt. Dieser stellt den
Arbeitsplatz des Lotsen realitätsgetreu
inklusive einer nahezu vollständigen
Rundumsicht dar und bietet damit eine
ähnliche Situation wie im realen Tower.
Die Simulationsumgebung umfasst die
Arbeitsplätze von Anflugkontrolle,
Tower und Vorfeldkontrolle. Alle diese
Arbeitsplätze werden besetzt, um Eingaben und Funkverkehr analog zum
normalen Tower-Betrieb durchzuführen. Reale Personen übernehmen
außerdem als so genannte „Pseudopiloten“ die Rolle der Piloten, führen
Anweisungen der Lotsen aus, steuern
die Flugzeuge und vermitteln so einen
noch realistischeren Eindruck im Tower-Simulator.
3.2
Das endgültige Interface ist somit ein
Produkt einer verdichtenden Gestaltung
und eine schrittweise Annäherung an ein
für diesen Arbeitsplatz optimales Human-Machine-Interface.
2.2
Beteiligung der Nutzer
Der Tower-Lotse als späterer Benutzer des Systems wurde von Beginn
der Entwicklung an beteiligt. So erhält
man frühzeitig nicht nur Hinweise auf
Bedienprobleme, sondern auch auf
sinnvolle Konzepte und Funktionen.
Diese können dann direkt in die Entwicklung mit eingehen. Gleichzeitig kann so
die Akzeptanz der Nutzer verstärkt werden, sofern deren Vorschläge auch tatsächlich sichtbare Anwendung in der
Gestaltung finden.
3.0
Simulation
3.1
Tower-Simulator der DFS
Für die Evaluation war die Realitätstreue der Simulation von großer Bedeu-
296
Ablauf der Simulation
In den Simulationen wurden HMIEntwürfe in unterschiedlichen Entwicklungsstadien eingesetzt, wobei der
Lotse ständig arbeitswissenschaftlich
begleitet und seine Bedienhandlungen
und -schwierigkeiten protokolliert wurden.
Der Lotse erhielt zu Beginn eine kurze
Einführung in die Bedienlogik des Interfaces sowie seine eigenen Aufgaben. In der anschließenden Simulation
wurde eine alltägliche Situation am
Tower nachgestellt, wobei der Lotse
angewiesen wurde, sich möglichst
realitätsnah zu verhalten.
Zusätzlich erfolgte die Anweisung,
Gedanken und Überlegungen bezüglich des verwendeten Interfaces laut zu
äußern, um sie so den Beobachtern
zugänglich zu machen (Methode des
lauten Denkens, vgl. Bortz & Döring
2002). Der Schwerpunkt der Instruktion lag jedoch auf der korrekten Erfüllung der Arbeitsaufgabe, um so eine
dem normalen Tower-Betrieb annä-
hernd gleiche Arbeitsweise zu erhalten.
3.3
Beobachtungsinterview
Um strukturierte und verlässliche
Daten zu erhalten, wurde die Methode
des Beobachtungsinterviews gewählt
(vgl. Dunckel 1999). Der Beobachter
kann damit seine Erkenntnisse direkt mit
dem Nutzer besprechen, offene Fragen
und Unklarheiten beantworten und so
die eigenen Beobachtungen direkt zu
verifizieren. Auch nicht direkt beobachtbare Informationen wie beispielsweise
die Einschätzungen und Meinungen der
Lotsen bezüglich des HMI konnten so
erfasst werden.
Zwar stellt diese Methode, wie generell
die Verwendung einer Simulationsumgebung, auch einen größeren Eingriff
in den natürlichen Arbeitsablauf des
Lotsen ein. Hier kommt aber eine Besonderheit der Benutzergruppe zum
Tragen: Die Arbeit im Tower-Simulator
ist Lotsen vertraut, da sie auch in ihre
Aus- und Weiterbildung integriert ist.
Auch die Interaktion mit anderen Personen, über Funk oder persönlich, ist im
Arbeitsalltag der Lotsen üblich. Daher
wurde die Beeinträchtigung durch die
Befragung während der Arbeit im Vergleich zum großen Nutzen der gewonnenen Daten als gering eingeschätzt.
Zur Ergänzung der während der Simulation erhaltenen Daten wurde anschließend ein weiteres, strukturiertes Interview zu Aspekten der HMI-Gestaltung
und -Bedienung durchgeführt.
3.4
Bewertung der Methode
Der Einsatz von Simulationen zur
Erfassung der Usability hat sich im Projekt bewährt. Unter aktiver Beteiligung
der Lotsen erhielt das Projektteam wertvolle Hinweise zur Gestaltung, die zu
einer deutlichen Veränderung der folgenden Entwürfe führten. Gleichzeitig
bestätigten die ersten Simulationsläufe
die prinzipiellen Interaktionskonzepte
und grundsätzliche Akzeptanz der Lotsen des entwickelten HMI. Die Simulation diente damit als sinnvolles Werkzeug, um die Entwicklung des Interfaces
zu begleiten, Konzepte zu überprüfen
und in realitätsnaher Umgebung zu validieren.
Die Kombination aus Beobachtung und
Befragung erwies sich ebenfalls als
sinnvoll. Es hat sich gezeigt, dass reine
Beobachtungen für solche komplexen
mentalen Prozesse nicht ausreichen.
Durch das gleichzeitige Befragen konnten arbeitswissenschaftliche Beobachtungen direkt mit den subjektiven Einschätzungen der Lotsen in Beziehung
gesetzt werden.
Die Simulationssituation an sich wurde
von den Lotsen als sehr realistisch empfunden. Allerdings gibt es auch Hinweise, dass das Verhalten im Simulator
einige Abweichungen vom alltäglichen,
im Tower gezeigten Verhalten aufwies.
Hier zeigen sich die Grenzen der Simulatorforschung, denn der Simulator
kann immer nur einen Ausschnitt der
Sinneseindrücke und Anforderungen
aus der realen Situation bieten. Der
Frage der Übertragbarkeit der Ergebnisse vom Simulator in den Tower soll
im weiteren Verlauf der Studie nachgegangen werden.
4.0
Bortz, J. & Döring, N. (2002): Forschungsmethoden und Evaluation für Human- und
Sozialwissenschaftler. Berlin: Springer.
DIN EN ISO 9241-110:2006. Ergonomie
der Mensch-System-Interaktion - Teil 110:
Grundsätze der Dialoggestaltung.
Dunckel, H. (1999): Handbuch psychologischer Arbeitsanalyseverfahren. Zürich: vdf,
Hochschulverl. an der ETH Zürich.
Genov, A. (2005): Iterative Usability Testing
as Continuous Feedback: A Control Systems
perspective. In: Journal of Usability Studies,
Vol. 1, Nr. 1, S. 18-27.
Leonhardt, J. (2005): Implementation of Critical Incident Stress Management at the German Air Navigation Services. In: Kirwan, B.;
Rodgers, M. & Schäfer, D. (Hrsg.): Human
Factors Impacts in Air Traffic Management.
Hampshire: Ashgate Publishing Limited,
S. 207-225.
Manning, C. & Stein, E. (2005): Measuring Air
Traffic Controller Performance in the 21st
Century. In: Kirwan, B.; Rodgers, M. &
Schäfer, D. (Hrsg.): Human Factors Impacts
in Air Traffic Management. Hampshire: Ashgate Publishing Limited, S. 283-31.
297
Usability Tests bei Immobilienscout24 – Aktuelle
Herausforderungen im User Experience Design
Monika Denk
ImmobilienScout24
Andreasstraße 10
10243 Berlin
[email protected]
Anja Kimm
ImmobilienScout24
Andreasstraße 10
10243 Berlin
[email protected]
Dr. Steffen Klein
ImmobilienScout24
Andreasstraße 10
10243 Berlin
[email protected]
Abstract
Mit der Entwicklung der Informationstechnologie zu einem Massenmarkt haben sich auch die Anforderungen an das
User Experience Design verändert. Die
heutigen Entwicklungszyklen bringen
hohe Erwartungen hinsichtlich Effizienz
und Flexibilität mit sich, die ohne eine
laufende, praxisnahe Anpassung der
Einleitung
1.0
Die Entwicklung des User Experien1
ce Design (UX) hängt eng mit dem
Wandel der Computernutzung zusammen. Während die Nutzung zu Beginn
nur wenigen Experten vorbehalten war,
ist sie heute – zumindest in den Industrieländern – ein alltägliches Gut. Die
Veränderungen auf Seiten der Anwender und die damit einher gehenden Anforderungen hinsichtlich Gebrauchstauglichkeit, Verständlichkeit, emotionaler
Bindung usw. sind ein wesentlicher
Treiber für die kontinuierliche Weiterentwicklung der Designdisziplin. In dem
Maße, wie Softwareprodukte zu Konsumartikeln werden, wächst auch die
Bedeutung von Design als Differenzierungsfaktor (Klein 2001).
Mit der massenhaften Computernutzung
vor allem auch im Onlinebereich ist aber
nicht nur ein Wandel bei den Anwendern
einhergegangen. Gleichzeitig haben sich
auch die Produktionsbedingungen wesentlich verändert. War die individuelle
1
Der Begriff User Experience Design oder
UX wird hier und im gesamten Artikel als
Klammer für die unterschiedlichen Tätigkeitsbereiche User Interface Design,
Usability Engineering usw. verwendet.
298
Werkzeuge und Methoden kaum zu
erfüllen sind. Im vorliegenden Beitrag
werden einige aktuelle Herausforderungen beschrieben. Am Beispiel der
internen Usability Tests bei ImmobilienScout24 wird gezeigt, wie die Anforderungen durch ein pragmatisches
Vorgehen erfüllt werden können.
Keywords
Entwicklung von Computerprogrammen von und für Spezialisten im Wesentlichen ein „handwerklicher“ Prozess (im Sinne der Produktion von
Einzellösungen), so haben sich heute
in vielen Bereichen der Softwareentwicklung industrielle Entwicklungsprozesse etabliert. User Experience Design wird dabei oft zum integralen Bestandteil der Produktentwicklung.
denentwicklung (Rogers 2004). Die aktuellen Herausforderungen des User
Experience Design lassen sich an folgenden Themengebieten festmachen.
2.0
Aktuelle Anforderungen an das
User Experience Design
Vor allem im B2C Bereich wird die
Qualität der „User Experience“ heute
als kritischer Erfolgsfaktor für das extrem wettbewerbsintensive Geschäft
wahrgenommen. In einem Markt, der
von schnellem Wachstum und kurzen
Innovationszyklen geprägt ist, werden
dabei hohe Erwartungen an Produktivität und Ergebnisorientierung der UX
Teams gestellt.
Zugleich passen die im akademischen
Umfeld entwickelten Methoden und
Werkzeuge in vielen Fällen nicht zu
der spezifischen Situation einer „industriellen Produktgestaltung“. In der Praxis profitiert das User Experience Design daher nicht im gewünschten Maße von der wissenschaftlichen Metho-
User Interface Design, User Experience,
Usability, Internet
2.1
Organisation und Prozesse
Die Frage, wie sich ein UX Team
zusammensetzt, wie es in die Organisation eingebettet ist und wie die Schnittstellen z. B. zu Produktmanagement und
Entwicklung definiert sind, ist ein bedeutender Erfolgsfaktor für das User Experience Design. Auch wenn die Aufgaben
und Verantwortlichkeiten nominell über
den Entwicklungsprozess festgelegt
werden, so entscheidet doch oft die Art
der Aufbauorganisation mit über die
tatsächlichen Arbeitsbeziehungen.
Vielfach ist der Entwicklungsprozess –
wenn überhaupt – nur informell definiert.
Das erschwert die Anwendung von formalen Prozessmodellen, wie sie in der
Literatur beschrieben sind. Zudem treffen diese Modelle bei der Anwendung im
Unternehmen vielfach auf historisch
gewachsene Gegebenheiten, die berücksichtigt werden müssen und die
Anpassungen und Kompromisse erfordert.
2.2
Kommunikation
Gerade in heterogenen Teams fällt
es oft schwer, geeignete Kommunikations- und Darstellungsformen zu finden,
die einerseits den jeweiligen fachlichen
Anforderungen entsprechen (Vollständigkeit, Widerspruchsfreiheit, Konsistenz, …) und die andererseits von allen
Mitgliedern eines Projektteams verstanden und selbst kompetent angewandt
werden können. Darstellungsstandards,
die das richtige Zusammenspiel von
formaler Beschreibung und erlebbarer
Darstellung ermöglichen, haben sich im
UX Design bisher nicht etablieren können. Die Dokumentation von Arbeitsergebnissen hat oft eher illustrativen als
formalen Charakter oder erfolgt ebenso
ungenau in Prosaform.
Aus vermeidlichen Zeitgründen wird
vielfach – vor allem in der Konzeption –
auf eine hinreichende Dokumentation
verzichtet, statt nach effizienteren Formen der Dokumentation und Darstellung
zu suchen, die beispielsweise die Formalisierung bietet. Nicht selten führt
dann dieser Mangel an Formalisierung
dazu, dass Lücken und Inkonsistenzen
im Konzept erst spät aufgedeckt werden
und dann zu zusätzlichen Kosten und
Verzögerungen führen.
2.3
Wissensbasis
Im Hinblick auf die Informationsbasis der Gestaltung zeigt sich ein Vorteil
der internen Arbeit gegenüber der rein
projektbezogenen Zusammenarbeit
(z. B. mit Agenturen): Die kontinuierliche
Arbeit innerhalb des Unternehmens ermöglicht die sukzessive Entwicklung
einer Wissensbasis (z. B. hinsichtlich
der Zielgruppe und des Nutzungskontextes) und passender unternehmensinterner Standards (Styleguide, Design Patterns, etc.). Der projektspezifische Aufwand wird dadurch reduziert und der
Nutzen für andere Bereiche des Unternehmens erlebbar.
Gleichzeitig stellen der Aufbau und die
Vermittlung solcher Ressourcen vor
dem Hintergrund der zeitlichen Anspannung eine gewaltige Herausforderung dar. Da es gerade im Bereich der
Anforderungsanalyse vielfach inhaltliche Überlappungen mit anderen Bereichen gibt (Produktmanagement,
Marktforschung, Produktmarketing),
besteht immer auch die Gefahr von
Abgrenzungsdiskussionen, die den
Informationsfluss blockieren statt die
unterschiedlichen Perspektiven produktiv zu nutzen.
3.0
Usability Tests bei ImmobilienScout24
Die beschriebenen Herausforderungen betreffen prinzipiell alle Phasen
und Tätigkeitsbereiche des User Experience Design. Die verschiedenen Bereiche sind aber in unterschiedlichem
Maße auf diese Herausforderungen
vorbereitet. In der Usability ist der
Wunsch nach schnellen und flexiblen
Ansätzen frühzeitig erkannt worden
(Nielsen, 1990) und hat mittlerweile zu
einer Reihe von Veröffentlichungen zu
diesem Thema geführt (Krug 2000).
Nichtsdestotrotz stellt die erfolgreiche
Integration von Usability Tests innerhalb eines Unternehmens eine stete
Herausforderung dar. Im Folgenden
wird am Beispiel unserer eigenen Erfahrungen dargestellt, wie wir bei ImmobilienScout24 den Herausforderungen im Bereich Usability Tests begegnen.
In den Usability-Tests werden Prototypen in verschiedenen Projektstadien
evaluiert, aber auch die bestehenden
Website und die Angebote von Mitbewerbern. Mit den Tests werden Handlungsbedarfe identifiziert und Designentscheidungen abgesichert. Die Zielgruppen von ImmobilienScout24 können in zwei Bereiche unterteilt werden:
Immobiliensuchende einerseits und
private oder gewerbliche Anbieter von
Immobilien andererseits. Eine der Herausforderungen bei beiden Zielgruppen
ist es, den Aufwand für die Tests in einem vertretbaren Rahmen zu halten und
gleichzeitig flexibel auf die Anforderungen hinsichtlich zeitlicher Planung und
zu testender Produkte zu reagieren.
Aufgrund der unterschiedlichen Rahmenbedingungen werden die Usability
Tests mit diesen beiden Probandengruppen auf unterschiedliche Art und
Weise durchgeführt.
Die Usability Tests mit Immobiliensuchenden (und teilweise auch privaten
Anbietern) werden im Haus durchgeführt. Auf Grund der räumlichen Situation im Unternehmen existiert kein Usabilitylabor. Die Tests finden stattdessen in
einem normalen Besprechungsraum
statt. Die notwendige technische Ausstattung wird kurz vor Beginn der Tests
im Raum aufgebaut. Neben dem Versuchsleiter, der zugleich Protokollant ist,
und dem Probanden befinden sich teilweise zusätzliche Besucher mit im
Raum, die die Tests mitverfolgen. Alle
Tests werden für nachträgliche Auswertungen per Video und Mirkofon aufgezeichnet.
Die Tests finden in einem 14-tägigen
Rhythmus statt. Hierfür wird von den
registrierten Usern des Portals monatlich
eine passende Stichprobe von ca. 400
Personen ausgewählt und per E-Mail
angeschrieben. Von dieser Auswahl
melden sich in der Regel 8-30 Interessenten zurück, die dann zu den jeweiligen Testterminen eingeladen werden.
Mit diesem Verfahren ist sichergestellt,
dass die richtige Zielgruppe für den jeweiligen Test eingeladen wird. Durch
den regelmäßigen Rhythmus können
Tests zuverlässig im Designprozess
eingeplant und ggf. mehrere Varianten
in relativ kurzen Abständen getestet
werden.
299
Die Tests mit gewerblichen Anbietern
werden in den Büros der Anbieter
durchgeführt. Die zu testenden Anwendungen sind dabei auf einem Laptop
installiert, welches vom Versuchsleiter
mitgebracht wird. Diese mobile Testausstattung erleichtert die Tests vor Ort,
ohne dass dadurch die Qualität der
Testergebnisse leidet (vgl. Nielsen 1993,
S. 202). Bei der Untersuchung sind der
Versuchsleiter und oft zusätzlich ein
Projektleiter anwesend. Letzterer übernimmt dabei häufig die Aufgabe des
Protokollanten und erfährt zeitgleich,
welche Prozesse bereits besonders gut
funktionieren und an welchen Stellen
noch Schwachpunkte existieren.
Auch die Probanden der Anbieterbezogenen Tests werden anhand eines Mailings rekrutiert. Zusätzlich werden Seminare und Veranstaltungen genutzt, um
weitere Anbieter als Probanden zu gewinnen. Um den notwendigen Reiseaufwand in Grenzen zu halten, ist die
Durchführung der Tests in der Regel auf
den Raum Berlin beschränkt. Auf Grund
der begrenzten Zahl verfügbarer Probanden lassen sich häufige Testiterationen jedoch bei den gewerblichen Anbietern schwieriger realisieren als bei den
Nachfragern. Infolgedessen werden
zunehmend auch Remote-Tests durchgeführt.
Für Remote-Tests wird die Software
Netviewer verwendet. Netviewer erlaubt
es, dem Probanden ein so genanntes
Fernsteuerungsrecht zu erteilen. In der
Untersuchungssituation befindet sich der
zu testende Prototyp auf dem PC des
Versuchsleiters – der Proband sieht auf
seinem PC den Bildschirm des Versuchsleiters und hat über die Fernsteuerung die Möglichkeit, den Prototypen
über seine eigene Tatstatur und Maus
zu bedienen. Die verbale Kommunikation läuft parallel via Telefon. Obwohl sich
das Remote-Testing bei ImmobilienScout24 noch in der Anfangsphase befindet, haben wir schon jetzt sehr gute Er-
300
fahrungen gesammelt. Besonders
durch den Wegfall regionaler Beschränkungen und die enormen Zeitersparnis ist das Verfahren vor allem
für den B2B-Bereich eine sehr interessante Ergänzung zu den Tests vor Ort.
3.1
Methodische Fragen
Die beschriebene Vorgehensweise für unsere internen Usability Tests
erfordert minimalen zeitlichen und
technischen Aufwand. Bei der Durchführung der Tests wird die Thinking
Aloud Methode verwendet. Diese Methode hilft uns, das mentale Modell
des Nutzers zu verstehen und auch
solche Usability Probleme aufzudecken, die nicht unmittelbar im Verhalten des Probanden zum Ausdruck
kommen. Unsere Erfahrungen zeigen,
dass auch die Probanden kaum Probleme haben, sich auf diese Methode
einzulassen – selbst dann, wenn zusätzliche Besucher im Raum sind.
Eine Erweiterung der technischen
Ausstattungen, z. B. für das Eyetracking, bietet unseres Erachtens keinen
wesentlichen Mehrwert. Die hohen
Anschaffungskosten stehen in keinem
Verhältnis zum praktischen Nutzen,
den solchen Verfahren für die Gestaltung bieten (vgl. Burmester, 2006,
S.8). Für Fragestellungen, die sich
dieser Methodik bedienen (z.B. Reihenfolge der Wahrnehmung von bestimmten Elementen) wird auf externe
Dienstleister zurückgegriffen. Gleiches
gilt für umfangreiche Projekte (z.B.
bundesweite Usability-Tests).
4.0
Zusammenfassung
Interne User Experience Teams,
die Teil des Produktentwicklungsprozesses sind, stehen einer doppelten
Herausforderung gegenüber. Sie müssen mit der notwendigen Pragmatik
den hohen Anforderungen hinsichtlich
Effizienz und Flexibilität entsprechen,
die ein industrieller Entwicklungsprozess
mit sich bringt. Zugleich müssen sie die
Werkzeuge und Methoden mit denen sie
arbeiten kontinuierlich weiterentwickeln
und an die Erfordernisse der Praxis anpassen.
Im Bezug auf die Usability-Tests hat uns
die Literatur maßgeblich unterstützt, den
Grundstein für die unternehmensinterne
Durchführung zu legen. In der Praxis
mussten wir uns jedoch an die uns zur
Verfügung stehenden Möglichkeiten
halten, um die internen Untersuchungen
in den notwendigen Zeitabständen sowie natürlich auch rentabel durchzuführen. Dennoch sind wir überzeugt, mit
den angepassten Vorgehensweisen die
Zielsetzung des Usability Testings zu
erfüllen.
Ziel des Beitrags ist es auch, auf die
spezifischen Anforderungen hinzuweisen, die heute an interne UX Teams
gestellt werden und damit einen erneuten Anstoß zu geben, diese Herausforderungen in Ausbildung und Forschung
stärker zu adressieren und, wo möglich,
den Austausch zwischen den Akteuren
zu verstärken.
5.0
Burmester, M. (2006): Einführung in die Blickregistrierung. Unveröffentlichtes Skript.
Klein, S. (2001): Differenz und Kohärenz:
Gestaltung und Wahrnehmung elektronischer
Medien. Heidelberg: Synchron.
Krug, S. (2000): Don’t make me think! : A
common sense approach to Web usability.
Indianapolis: Que.
Nielsen, J. (1994): Guerrilla HCI: Using Discount Usability Engineering to Penetrate the
Intimidation Barrier.
www.useit.com/papers/guerrilla_hci.html
Nielsen, J. (1993): Usability-Engineering.
Boston: Academic.
Rogers (2004): New Theoretical Aproaches
for HCI. In: ARIST: Annual Review of Information Science and Technology, Nr. 3
Strategisches User Experience Design
Wertorientierte Entwicklung von Interfaces
David Gilbert
Emser Straße 59
65195 Wiesbaden
[email protected]
Abstract
Das User Experience Konzept hat aufgrund seiner holistischen Betrachtungsweise das Potential strategisch zu
wirken und übergreifend die Entwicklung
von Interfaces zu führen. Herausforderungen sind jedoch die praktische
1.0
Der Begriff User Experience
Unter der aktuellen Diskussion von
User Experience sind besonders das
Verständnis nach Hassenzahl und das
Modell nach Jetter&Gerken hervorzuheben.
Hassenzahl weist hierbei besonders auf
folgende Facetten hin: (Hassenzahl
2006)
x
x
x
Non-instrumentelle Qualitäten von
Produktqualität.
Fokus auf positive, emotionale Ereignisse.
Perspektive der Situationsbezogenheit und Zeitweiligkeit.
Anwendung und die Bestimmung strategischer Werte. Daher soll das User
Experience Konzept hier als Design
betrachtet und durch strategische Werte aus Bunsiness- und Nutzersicht
fundiert werden.
Keywords
Aufgabe (Kontext des Subjekts) stattfindet. (Bonsiepe 1996)
vor einiger Zeit in seinem „Experience
Design“ Konzept aufgegriffen.
In Bezug auf das User Experience
Konzept, erscheint es jedoch sinnvoll,
diese Definition zu erweitern. Für die
praxisnahe Anwendung sollte in Anlehnung an das Modell nach Jetter/Gerken dem Nutzer auch die Organisation als Element gegenüber gesetzt werden. Bezüglich des Objektes
sollte neben dem Werkzeug und Produktcharakter auch explizit auf seine
kommunikative, semiotische Seite
hingewiesen werden. (Gilbert 2007)
User Experience, Design, Strategie,
Wertorientierung
1.1
Ökonomischer Rahmen
In der aktuellen ökonomischen Theorie
werden unter dem Stichwort „Emotion
Economy“ die beiden Ansätze „Experience Economy“ und „Value Economy“
diskutiert. (Nijs 2003)
„Experience Economy“ betont dabei die
Inszenierung einprägsamer Erlebnisse,
sowie die Betrachtung der Inszenierung
als eigentliches Produkt.
Die „Value Economy“ verweist auf die
Bedeutung übergreifender Geschichten,
die eine Organisation erzählt und die
aus Kundensicht im. Als strategische
Quelle fließen diese in die gesamte Unternehmenspolitik mit ein.
Das Modell nach Jetter&Gerken integriert neben dem Nutzer noch die Organisationsperspektive. Hierdurch wird eine
hohe Praxisnähe für die Anwendung
geschaffen. (Jetter&Gerken 2006)
Beide Ansätze finden sich auch im
Customer Experience Management
(CEM) wieder. Dieses hat sich im Bereich des Beziehungsmarketings als
Managementansatz herausgebildet.
Diese beiden Modelle sollen als inhaltliche Basis für ein strategisches User
Experience Konzept stehen. In diesem
Zusammenhang ist jedoch noch der
Begriff von Interface zu definieren.
Abb. 1: Interface
Interface, als Raum für effektives Handeln definiert sich nach bisherigem Verständnis als Dimension, in der die Interaktion zwischen den Elementen Benutzer (Subjekt), Werkzeug (Objekt) und
Hieraus kann abgeleitet werden, dass
für die praktische Anwendung Produktund Kommunikationsdesign integriert
werden sollten. Der amerikanische
Designverband AIGA hat dieses schon
Inhaltlich wurde hier eine Antwort auf die
nicht vorhandene Prozessorientierung
bei Kundenzufriedenheit und die nicht
vorhandene non-funktionale Betrachtung
der Kundenbedürfnisse des Customer
Relationship Managements gegeben.
Allgemein definiert sich CEM als „Prozess des strategischen Managements
301
aller Kundenerlebnisse mit einer Marke
an sämtlichen Kontaktpunkten“. Die
Umsetzung erfolgt durch die Gestaltung
relevanter Erlebnistreiber.
(Schmitt&Mangold 2004)
Aus diesem Selbstverständnis heraus,
kann das Design folgende drei Kernaufgaben der praktischen Anwendung
des User Experience Konzeptes erfüllen:
Bei der Analyse des Kundenerlebnisses
sollte neben der Zielgruppenanalyse und
der Kontaktpunkt-Evaluation eine Erlebnisschichten-Analyse durchgeführt werden. Die Erlebniswelt besteht hierbei
aus drei Schichten:
1.
x
x
x
Erlebnis der Marke.
Erlebnis der Nutzungs- bzw. Konsumsituation.
Erlebnis im soziokulturellen Kontext.
2.
3.
Moderation und Koordination der
verschiedenen Qualifikationen, die
im Bereich User Experience gesehen werden (User Experience
Umbrella).
Kritische Vermittlung und Integration der Nutzer-Perspektive, gegenüber der BusinessPerspektive.
Gestaltung der non-funktionalen
Qualitäten von Interfaces, als wesentlichen Experience Faktor.
Die Gestaltung des Erlebniswertes für
Kunden erfolgt durch fünf Erlebnismodule:
2.1
x
x
x
x
x
Sensorische Erlebnisse.
Affektive Erlebnisse.
Kognitive Erlebnisse.
Verhaltensbezogene Erlebnisse.
Soziale Erlebnisse.
Die praktische Anwendung von
User Experience durch das Design
erfordert einen Maßstab für „Gutes
Design“. Hier sind primär die in Kapitel
3 abgeleiteten Werte zu sehen.
Das User Experience Konzept spiegelt
die verschiedenen ökonomischen Bezugskonzepte durch die Erlebnisbetonung und die durch CEM definierten
aktuellen Anforderungen des Beziehungsmanagement wieder. Darüber
hinaus liefert es dabei einen Brückenschlag hin zur praktischen Anwendung
im Bereich von Interfaces.
Daneben ist aber auch die geplante
methodische Einbindung von User
Experience in den Entwicklungsprozess notwendig. Hierzu stehen für alle
Stufen des Entwurfsprozesses Methoden zur Verfügung. (Gilbert 2007)
2.0
Gutes Design (Anwendung)
Daneben bietet sich die Analyse vorhandener Entwurfsmuster (Design
Pattern) an. (van Welie&van der Veer
2003)
Die Rolle des Designs
Die praktische Anwendung des User
Experience Konzeptes soll durch das
Design erfolgen. Basis hierfür ist das
folgende Verständnis von Design nach
Bonsiepe:
„Design is an indepedendent category.
Located at the interface of industry, the
market, technology and culture (living
practise), design is eminently suited for
engaging in culturally critical exercises
that focus on the symbolic function of
products.” (Bonsiepe 2007)
2.2
x
x
3.0
Der „Problem-Raum“ wird aus einer
bestimmten Perspektive betrachtet,
welche das Hervortreten von DesignIdeen fördert.
Der gesamte ProblemLösungsprozess und enthaltene
Schwierigkeiten können in einer systemischen Art und Weise überblickt
werden.
Strategische Wertorientierung
Basierend auf dem erweiterten Verständnis von Interface sollen im Folgenden aus den Perspektiven Business
(Organisation) und Nutzer heraus Werte
als Maßstab abgeleitet werden.
Der Begriff Wert wird hier definiert als
quantitativ oder qualitativ abgeleiteter
Wert, der sich an Standards oder Zwecken als Maßstab orientiert.
3.1
Business-Perspektive
Als zentrale Zielgröße aus wirtschaftlicher Unternehmenssicht gilt die
Maximierung des monetären Unternehmenswertes. Wertbringend für den Unternehmenswert sind Investitionen, die
einen positiven Economic Profit aufweisen.
Zwei strategische Anknüpfungspunkte
liefern hier der Customer Value und der
Markenwert. Diese sind nach dem Verständnis des integrierten Marken- und
Kundenwertmanagement zu harmonisieren. (Göttgens&Wirtz 2004)
Gute Designer (Anwender)
Weiterhin erfordert die effektive
praktische Anwendung von User Experience „Gute Designer“. Im Hinblick
auf die Frage, was einen guten Designer ausmacht, konnten Lawson und
Cross folgende Erkenntnisse gewinnen (Cross 2007):
x
Sowohl bei der Entstehung, als
auch Ausformulierung von Konzepten wird an leitenden „Richtlinien“
festgehalten.
Abb. 2: Business-Perspektive
302
Während der Customer Value über die
Hebel Kundenzufriedenheit und Phasenbezug im Kundenlebenszyklus verfügt, hat der Markenwert die Hebel Umsatzprofitibilität, werbliche Unterstützung
und Image.
Bei der Integration von Kunden- und
Markenwertmanagement ist festzustellen, dass die Instrumente des Markenwertmanagements in der Kaufentscheidungsphase eine höhere Relevanz haben, während in den Phasen Kauf und
Loyalität die Relevanz der Instrumente
des Kundenwertmanagements höher ist.
Aufgrund der beschriebenen Wertfaktoren ist für die praktische Anwendung von
User Experience eine intensive Auseinandersetzung mit dem Businessmodel
und der Markenstrategie notwendig.
3.2
Nutzer-Perspektive
Der Wert eines Produktes aus Sicht
des Nutzers zeigt sich allgemein im Erleben von Qualität. An dieser Stelle soll
auf die Definition von McNamera und
Kirakowski zurückgegriffen werden, welche die Grundwerte Funcionality, Usability und Experience integriert. (McNamera&Kirakowski 2006)
funktion nach Bürdek auch auf Softwareprodukte übertragen werden.
(Bürdek 2005; Bürdek 2002)
Die formalästhetische Funktion bezeichnet Aspekte, die unabhängig von
ihrer inhaltlichen Bedeutung betrachtet
werden können. Hierunter fallen im
Wesentlichen die Gestaltgesetze als
Syntax.
Die Anzeichenfunktion bringt Produkt
und Benutzer zusammen. Sie bezieht
sich auf die praktischen Funktionen
eines Produktes, erläutert Handhabung und Bedienung und macht primär
den Gebrauchswert aus.
Die Symbolfunktion verweist als subjektive Interpretation des Benutzers
auf unterschiedliche soziokulturelle
Kontexte, in denen wir ein Produkt
wahrnehmen. Sie befasst sich mit Aspekten die besonders unter dem
Grundwert Experience zu finden sind.
4.0
Fazit
Für die praktische Anwendung des
User Experience Konzeptes bietet sich
das Design als Träger an.
Bedingung ist jedoch das Sicherstellen
einer wertorientierten Entwicklung.
Hierzu muss klar sein, was „Gutes
Design“ ist, das der „Gute Designer“
gestalten und entwerfen kann.
Quellenverzeichnis
Bonsiepe, G. (1996): Interface – Design
neu begreifen. Köln: Bollmann.
Bonsiepe, G. (2007): The Uneasy Relationship between Design and Design Research.
In: Michel, R. (Ed.): Design Research Now.
Basel: Birkhäuser, S. 25-39.
Abb. 2: Business-Perspektive
Im Hinblick auf die Gestaltung von Interfaces können die beschriebenen produktsprachlichen Kategorien Formalästethik sowie Anzeichen- und Symbol-
Bürdek, B. (2002): Vom analogen zum
digitalen Design. In: i-com - Zeitschrift für
interaktive und kooperative Medien, Ausgabe 01, Jahrgang 2002. München: Oldenbourg.
Bürdek, B. (2005): Design – Geschichte,
Theorie und Praxis der Produktgestaltung, 3.
Aufl. Basel: Birkhäuser.
Cross, N. (2007): From a Design Science to a
Design Discipline: Understanding Designerly
Ways of Knowing. In: Michel, R. (Ed.): Design
Research Now. Basel: Birkhäuser, S. 41-53.
Gilbert, D. (2007): Strategisches User Experience Design. Saarbrücken: VDM.
Göttgens, O. & Wirtz, B. (2004): Integriertes
Marken- und Kundenwertmanagement: Strategien, Konzepte und Best Practices. Wiesbaden: Gabler.
Hassenzahl, M. & Tractinsky, N. (2006): User
experience – a research agenda. In: Behaviour & Information Technology, Vol. 25, No. 2,
March-April 2006: S. 91 - 97. London: Taylor
and Francis.
Jetter, H.-Ch. & Gerken, J. (2006b): A Simplified Model of User Experience for Practical
Application. In: NordiCHI 2006, Oslo. International Open Workshop "User eXperience Towards a unified view", Oktober 2006. New
York: ACM.
McNamera, N. & Kirakowski, J. (2006): Functionality, Usability, and User Experience –
Three Areas of Concern. In: Interactions November / Dezember: S. 26-28. New York:
ACM.
Nijs, D. (2003): Creating a fascinating world.
Breda: NHTV University of Professional Education.
Schmitt, B. & Mangold, M. (2004): Kundenerlebnis als Wettbewerbsvorteil - mit Customer
Experience Management Marken und Märkte
Gewinn bringend gestalten. Wiesbaden: Gabler.
van Welie, M. & van der Veer, G.C. (2003):
Pattern Languages in Interaction Design Structure and Organization. In: Proceedings
of Interact '03, 1-5 September. Amsterdam:
IOS Press.
Danksagung:
Für seine Unterstützung und sein Vertrauen danke ich ganz besonders Professor Stephan Schwarz von der FHWiesbaden.
303
Webdesign und Usability-Evaluierung: Ein Methodenmix für
die Neugestaltung des Webauftritts der Auto 5000 GmbH
(Volkswagen AG)
Inga Rill
Wolfsburg AG /
InnovationsCampus
Major-Hirst-Str. 11
38442 Wolfsburg
Folker Caroli, Thomas Mandl
Informationswissenschaft
Universität Hildesheim
31141 Hildesheim
[email protected]
Abstract
Der Beitrag beschreibt den Aufbau der
Website eines Unternehmens der Automobilbranche unter Berücksichtigung
von Usability-Kriterien. Der Aufbau erfolgte schrittweise im Rahmen des
Usability Engineerings und unter Anwendung von unterschiedlichen Usability-Evaluierungsmethoden.
1.0
Einleitung
Die Auto 5000 GmbH ist eine Gesellschaft der Volkswagen AG in Wolfsburg. Bei der Gründung im Jahr 2001
war die Grundidee, 5000 Arbeitsplätze
mit jeweils 5000 DM Einkommen zu
schaffen. Heute produziert Auto 5000
die Modelle Touran und Tiguan und
setzt auf innovative Qualifizierungskonzepte für seine Mitarbeiter.
Die Website der Auto 5000 GmbH wurde 2007 völlig neu aufgebaut und sollte
mit wissenschaftlichen Methoden benut1
zerangemessen gestaltet werden . Die
Gebrauchstauglichkeit stellt gerade im
Web ein zentrales Qualitätsmerkmal dar.
Sie kann nur durch empirische Methoden überprüft und verbessert werden.
In dem hier beschriebenen Projekt kam
ein Methodenmix zum Einsatz, der drei
empirische Methoden kombinierte: Card
Sorting, Logfile Analyse und Benutzertests. Diese Methoden wurden zu unterschiedlichen Phasen im Lebenszyklus
der Website angewandt. Card Sorting
dient der benutzerorientierten Optimierung der grundlegenden Informationsar1
http://www.auto5000.de
304
Die gründliche Analyse der Unternehmensziele, die mit der Website verfolgt
werden, eine Analyse von Webauftritten vergleichbarer Unternehmen aus
der Automobilbranche sowie Card
Sorting, Logfile Analyse und Benutzertests führten in mehreren Schritten zu
einem optimierten Design.
Mit dieser Kombination von Methoden
ließen sich unterschiedliche Usability
Probleme erkennen.
chitektur. Benutzertests sind eine aussagekräftige Methode, um nach der
Entwicklung die schwerwiegendsten
Fehler aufzudecken. Danach ist ein
Re-Design vor der Onlineschaltung
sinnvoll. Die Logfile Analyse muss im
laufenden Betrieb erfolgen und kann
dazu dienen, die Maßnahmen des ReDesigns zu bewerten.
handen sind. Dazu zählen Unternehmensvisionen oder Leitbilder, Struktur
des Unternehmens, historische Entwicklung, wirtschaftliche Fakten, Stellenanzeigen, Besucher- und Kontaktinformationen.
Ausgangspunkt der Bearbeitung war
die Website des Unternehmens Auto
5000 GmbH. Die Ziele und Zielgruppen der Website haben sich aufgrund
von unternehmenspolitischen Entwicklungen verändert und führten somit zu
grundlegenden Veränderungen der
Inhalte, Informationsarchitektur und
der visuellen Gestaltung der einzelnen
Webseiten.
Als erstes musste für die vom Unternehmen für relevant erachteten Informationen eine benutzerangepasste
Struktur gefunden werden. Die auf der
Website darzustellenden Informationen
sollten so angeordnet werden, wie es
den Bedürfnissen und dem intuitiven
Zugang der Benutzer entspricht. Ziel war
daher die Erhebung des "mentalen Modells" des Benutzers, um daraus eine
intuitive und verständliche Navigationsstruktur abzuleiten.
Als erster Schritt erfolgte eine Wettbewerbsanalyse, um den state of the art
eines Webauftritts von vergleichbaren
Unternehmen zu erfassen. Die Ergebnisse dieser Analyse lieferten einen
Rahmen für die Auswahl der Informationen, die auf der Unternehmenswebsite dargestellt werden sollten. Dieser
Benchmark zeigte, dass gewisse Standardinformationen auf fast allen Internetpräsenzen von Konkurrenten vor-
Keywords
Auto 5000, Website, Relaunch, Card
Sorting, Logfile-Analyse, Web-Design
2.0
Grundlegende Informationsarchitektur
Um dieses Ziel zu erreichen, wurde die
Usability-Evaluierungsmethode Card
Sorting angewandt. Den Benutzern werden dabei die Menüpunkte der künftigen
Website auf Karteikarten vorgelegt. Sie
werden gebeten, diese aus Ihrer Sicht in
eine logische Ordnung zu bringen. Auf
diese Weise wurde die Gesamtnavigation nach den Ergebnissen eines
zweifachen Durchgangs durch diese
Methode festgelegt. Als Teilnehmer
wurden ein Unternehmensmitarbeiter
und zwei andere Personen gewählt, um
die heterogenen Zielgruppen widerzuspiegeln. Bei Card Sorting handelt es
sich um eine im Wesentlichen qualitativ
orientierte Methode, so dass nicht mehr
Teilnehmer pro Zyklus nötig waren. Aufgrund der zweifachen Durchführung
waren insgesamt sechs Testpersonen
beteiligt. Der zweite Durchgang erbrachte wenig Änderungsbedarf, so dass auf
weitere Testpersonen bzw. Phasen verzichtet wurde. In jedem Zyklus mussten
die Begriffe der Menüpunkte einigen
Oberbegriffen zugeordnet werden, um
zu überprüfen, ob die konzipierte hierarchische Struktur sich tatsächlich für die
Navigation eignet. Anhand der Ergebnisse des ersten Durchlaufs modifizierte
die Testleiterin die Oberbegriffe. Geringe
Übereinstimmungen sowie Zögern der
Testpersonen wiesen auf Schwachpunkte hin. So konnten zahlreiche Schwächen erkannt werden. Die Hauptnavigationspunkte Innovation und Dialog wurden kaum verstanden und dem Oberbegriff Unternehmen ordneten die Testpersonen eher willkürlich Karten zu. Als
Konsequenz wurden letztendlich vier
Leitfragen gewählt (Wer wir sind, was
wir machen, was uns ausmacht, der
Weg zu uns). Im zweiten Zyklus ergab
sich eine korrekte Zuordnung von 87%
der Menüpunkte zu den vom Design
vorgesehenen Phrasen.
3.0
Interaktion mit der Website
Die Konzeption des Internetangebots erfolgte unter Berücksichtigung von
Standards und Heuristiken aus der
Mensch-Maschine Interaktion. Das ästhetische Design wurde mit dem Unternehmen abgestimmt. Die Entwicklung
führte eine Agentur durch.
Nach vollständiger Entwicklung der
Website erfolgte ein Benutzertest. Ziel
der Benutzertests war die Erhebung von
Problemen, die potentielle Benutzer
beim Umgang mit der konkreten Website haben könnten. Die Benutzertests
wurden in einer kontrollierten Testumgebung durchgeführt. Dabei wurden
ausschließlich qualitative Fragestellungen berücksichtigt. Aufgrund der
Ergebnisse dieser Benutzertests wurde die Website im Rahmen eines ReDesigns modifiziert, mit dem Ziel die
Bereiche, die die Testpersonen beim
Test als problematisch empfanden, zu
optimieren. Erst nach der Durchführung des Re-Designs erfolgte die Online-Schaltung der Website der Auto
5000 GmbH.
Die Tests wurden mit der Software
MORAE aufgezeichnet, um eine
gründliche Auswertung zu erleichtern.
Ein Pretest gab Aufschluss über die
Durchführbarkeit des Tests in der vorgesehenen Zeit. Eine Befragung vor
dem Test erhob demographische Daten und ein Fragebogen nach dem
Test sollte über die subjektive Wirkung
des neuen Internetangebots Aufschluss geben.
Folgende Aspekte sollten besonders
untersucht werden:
•
•
•
die neu gestaltete Navigationsstruktur
einige innovative, interaktive Elemente (z.B. interaktiver Lageplan)
Lesbarkeit und Verständlichkeit
der Inhalte
Das folgende Szenario bildete den
Rahmen für die acht Testaufgaben:
Die Testperson sucht nach einem Arbeitsplatz und möchte sich umfassend
über Auto 5000 informieren. Dabei
wurden den Testpersonen Wissensfragen gestellt, die mit Hilfe der Site zu
beantworten waren. Im Folgenden
werden einige wichtige Erkenntnisse
exemplarisch vorgestellt. Eine ausführliche Herleitung der Aufgaben, die
damit jeweils überprüften Usability
Aspekte sowie die Ergebnisse findet
sich in Rill (2007). Die Gliederung der
Ergebnisse folgt dabei der Einteilung in
Site, Page und Content Design (Lynch &
Horton 1999).
Die ersten drei Aufgaben konnten von
allen acht Testpersonen bzw. eine weitere von sieben Testpersonen auf Anhieb richtig gelöst werden. Somit scheint
die Navigationsstruktur für wichtige Informationen gut gewählt zu sein. Als
problematisch im Site Design erwiesen
sich externe Links auf die Homepage
der Volkswagen AG, die jedoch aus
firmenpolitischen Gründen angeboten
werden müssen. Solche Verweise wie
beispielsweise bei den Stellenangeboten
verwirrten die Testpersonen und erschwerten die weitere Navigation auf der
Site der Auto 5000 GmbH. Auch die
fehlende Verlinkung von Bildern störte
Aufgrund der eindeutigen Testergebnisse konnte eine Handlungsempfehlung
ausgesprochen werden.
Beim Page Design zeigten sich Schwierigkeiten bei der Interaktion der Benutzer
mit einer Zeitleiste, welche zur Navigation in der Geschichte des Unternehmens
dient. Nicht alle Teile dieses Designelementes führten beim Anklicken zu einer
neuen Seite. Die Verlinkung wurde danach korrigiert. Die Logfile-Analyse zeigte, dass dieses Vorgehen vermutlich
erfolgreich war (siehe unten).
Die Beobachtung der Testbenutzer zeigte, dass in dem gewählten Design Links
nicht eindeutig identifiziert werden konnten. Die Benutzer klicken häufig auf
Überschriften der Kurzfassungen von
Informationen und erwarteten, dass sie
zu der Langfassung kommen würden.
Dafür war aber ein anderer Link vorgesehen, der ähnlich wie die Überschrift
gestaltet war. Das Design der Überschrift wurde als Konsequenz modifiziert. Ebenso klicken die Benutzer auf
das Firmenlogo auf den Seiten und erwarteten, so auf die Startseite zu gelangen. Daraus wurde eine Handlungsempfehlung abgeleitet, das Corporate De-
305
sign der Website entsprechend zu ändern.
wurden aus den Ergebnissen weitere
Handlungsempfehlungen abgeleitet.
Im Rahmen des Content Design konnten
zahlreiche Details bei der Benennung
von Elementen und Inhalten verbessert
werden. Teils verstieß das Design auch
gegen verbreitete de-fakto Standards.
So war bei den Schlagzeilen die aktuellste Meldung nicht oben einsortiert.
Aufgrund mehrerer vergeblicher Suchen
wurden auf der Job-Seite noch Kontaktinformationen eingefügt.
Die Logfiles des ersten Monats der
Onlineschaltung der Site wiesen
700.000 Hits auf. Diese weisen natürlich nicht auf eine gleiche Anzahl von
Nutzern hin (Heindl 2003). Die Auswertung erfolgte mit Hilfe der Software
ClickTracks (siehe auch Bartel 2004),
die 6.470 Seitenabrufe verzeichnete.
Tab 1: Ergebnisse des Posttest-Fragebogens. Bewertung erfolgte mit Schulnoten
Frageziel
Durchschn.
Bewertung
Erscheinungsbild
1,8
Orientierung auf der Site
2,9
Auffinden von Informationen
auf der Site
3,1
Interaktive Elemente
2,1
Verlinkung
2,1
Der Posttest-Fragebogen sollte die subjektive Einschätzung der Benutzer abfragen. Solche Aspekte sind im Sinne
einer Analyse der ganzheitlichen User
Experience sehr bedeutsam. Besonders
das Erscheinungsbild der Website wurde sehr positiv bewertet. Auch die anderen Aspekte schnitten auf einer Schulnotenskala mindestens mit befriedigend
ab, wie Tabelle 1 zeigt.
4.0
Beobachtung des laufenden Betriebs
Als letzte Evaluierungsmethode
wurde nach online-Schaltung der Website eine Logfile-Analyse durchgeführt.
Um aussagekräftige Ergebnisse zu erzielen, wurden einen Monat lang die
Logfiles gesammelt und ausgewertet.
Ziel war die Bestätigung der im Benutzertest gefundenen Probleme bzw. der
Überprüfung der Optimierungen. Zusätzlich sollten weitere Usability-Probleme
erhoben werden. Für ihre Behebung
306
Gezielte Maßnahmen der internen und
externen Kommunikation sorgten anfangs für sehr großes Interesse an der
Site. Allerdings nahm die Anzahl der
Besucher im Lauf des Monats allmählich ab. In einer weiteren Woche führten die Tarifverhandlungen als externes Ereignis zu einem spürbaren Ausreißer nach oben. Am populärsten
waren nach der Startseite die Jobs
gefolgt von Tiguan und Touran. Da die
Jobs-Seite auf die Volkswagen Internetpräsenz verweist, stellt sie auch die
häufigste Ausstiegsseite dar. Dies
bestätigt die Erkenntnis aus dem Benutzertest, dass der externe Link auf
die VW Stellenbörse eher störend ist.
Durch das Verlassen der Auto5000
Website entstehen Probleme bei der
Orientierung.
Die mittlere Verweildauer lag bei Jobs
mit Abstand am höchsten; sie betrug
fast 80 Sekunden. Die Startseite nahm
noch etwa 40 Sekunden in Anspruch,
die übrigen mittleren Verweildauern
lagen unter 30 Sekunden.
Die Analyse der Verweildauer bewies,
dass ein Film „Das Werk von innen“
mit einer Laufzeit von fünf Minuten von
kaum einem Benutzer vollständig betrachtet wurde. Daraus folgte die
Handlungsempfehlung, diesen Beitrag
zu kürzen.
Die Analyse der Klickpfade zeigte ein
Phänomen, das sich auf die erst kurz
vorher erfolgte Onlineschaltung zurückzuführen lässt. Zahlreiche Benutzer navigieren systematisch durch alle
Menüpunkte und verlassen dann das
Angebot. Hierbei handelt es sich vermutlich um Mitarbeiter, die aus Neugier den
Umfang der neuen Internet-Präsenz
explorieren, ohne ein konkretes Informationsbedürfnis und eine konkrete Zielseite zu haben. Diese Klickpfade sind für
das reale Benutzerverhalten kaum repräsentativ und geben keine Hinweise
für die Verbesserung der Usability.
Mit Hilfe der Logfile-Analyse konnte die
Wirksamkeit einiger Änderungen überprüft werden, die nach dem Benutzertest
vorgenommen wurden. Auf der Startseite waren Abkürzungen zu Seiten auf
tieferen hierarchischen Ebenen eingefügt worden (Quicklinks). Insbesondere
der Quicklink zu der Jobs-Seite kam
nach dem Benutzertest dazu. Diese
Maßnahme wirkte sehr positiv. Der
Klickpfad von der Homepage zur JobsSeite war einer der am häufigsten
durchschrittenen Pfade. Für die Benutzer mit dem Ziel Jobs-Seite konnte also
die Interaktion sehr effizient gestaltet
werden.
Probleme beim Benutzertest hatten sich
mit der Zeitleiste ergeben, die das Navigieren durch die Historie des Unternehmens erlaubt. Das Re-Design hatte dies
berücksichtigt und eine fast vollständige
Verlinkung aller Elemente der Zeitleiste
vorgenommen. Die Logfile-Analyse
deckte auf, dass 93% der Benutzer,
welche die Seite Meilensteine anklicken,
auch die Zeitleiste aufrufen. Somit wird
die Zeitleiste jetzt zumindest als Interaktionselement erkannt und das Problem
ist vermutlich behoben. Eine ausführlichere Darstellung bietet Rill (2007).
5.0
Zusammenfassung
In dem vorgestellten Projekt wurde
ein Methodenmix zur strukturierten
Durchführung des Usability Engineering
eingesetzt. Dieser beinhaltete unterschiedliche Evaluierungsmaßnahmen in
unterschiedlichen Phasen der Entwicklung unter Berücksichtigung objektiver
und subjektiver Datenmengen. Basis
dieser Evaluierungsmaßnahmen waren
Inhalte, die mit unterschiedlichen Bereichen des Unternehmens abgestimmt
waren, um somit den Ansprüchen der
praktischen Umsetzung und der tatsächlichen Online-Schaltung zu genügen.
Die verwendeten Methoden im Rahmen
des Methodenmix erwiesen sich für die
Umsetzung der gesetzten Ziele als sinnvoll. Zum einen wurden jeweils unterschiedliche Usability-Probleme aufgedeckt und zum andern nahm die Zahl
der gefundenen Usability-Probleme mit
der steigenden Anzahl an Evaluierungsmaßnahmen stetig ab. Weiterhin
hat sich der gewählte Methodenmix als
überzeugend erwiesen, da die gefunde-
nen Probleme tatsächlich auch in der
praktischen Durchführung behoben
wurden. Dies ist darauf zurückzuführen, dass auch dem Unternehmen der
Mehrwert der Umsetzung bewusst
wurde.
6.0
Bartel, T. (2004): Die Verbesserung der
Usability von WebSites: Auf der Basis von
Web Styleguides, Usability Testing und
Logfile-Analysen. Köln: Wiku.
Dahm, M. (2005): Grundlagen der MenschComputer-Interaktion. München: Pearson
Studium
Heindl, E. (2003): Logfiles richtig nutzen.
Webstatistiken erstellen und auswerten.
Bonn: Galileo.
Lynch, P.; Horton, S. (1999): Erfolgreiches
Web- Design. Planegg/München: KochMedia.
Rill, I. (2007): Webdesign und UsabilityEvaluierung: Benutzertests und LogfileAnalysen für die Neugestaltung des Webauftritts der Auto 5000 GmbH (Volkswagen AG)
Magisterarbeit, Internationales Informationsmanagement (IIM) Universität Hildesheim.
Schweibenz, W.; Thissen, F. (2002): Qualität
im Web: Benutzerfreundliche Webseiten
durch Usability-Evaluation. Berlin: Springer.
307
Business Centered Design: Erfolgsfaktoren im E-Business
Christian Becker
Usability Engineer
Christian Fernandez
Creative Director
kuehlhaus AG
N7, 5-6
68161 Mannheim
[email protected]
kuehlhaus AG
N7, 5-6
68161 Mannheim
[email protected]
Abstract
Business Centered Design ist ein Modell, das den Erfolg von Webprojekten
garantieren soll. Neben den Interessen
der Anwender werden zusätzlich die
wirtschaftlichen Anforderungen der
Betreiber durch alle Entwicklungsphasen
hinweg berücksichtigt.
1.0
Einleitung
Mit der Erfahrung aus mehr als 12
Jahren und unzähligen Projekten entwickelt die kuehlhaus AG webbasierte
Anwendungen in den Bereichen B2B
und B2C mit dem Schwerpunkt auf EBusiness Angeboten und Unternehmensportalen.
Neue oder optimierte Technologien erlauben es, immer komplexere Prozesse
und Transaktionen im Internet abzubilden.
Ziel ist eine Harmonie der diversen
Einflussfaktoren zu erreichen und dem
Spannungsfeld Internet gerecht zu
werden. Hierfür wurde von der kuehlhaus AG ein phasenbasierter Prozess
mit speziellen Methoden entwickelt.
3. Wirtschaftlichkeit:
Die Anwendungen müssen einen
optimalen Return on Invest für den
Betreiber der Seite erzielen, also
die Marketing- und Vertriebsziele
erfüllen.
Auf diesen grundsätzlichen Annahmen
beruht das von kuehlhaus entwickelte
Business Centered Design Modell für
ein optimales Ergebnis im E-Business.
Keywords
User Centered Design im Web, Business Centered Design, Joy-of-Use,
Wirtschaftlichkeit, E-Business, Design,
Usability, Phasenmodell, UCD, Interaktionsdesign
2.0
Business Centered Design markiert
den nächsten Level des User Centered
Design von Internet-Anwendungen. Mit
diesem einzigartigen Konzept stellt die
kuehlhaus AG sicher, dass die entwickelte Online-Shops, OnlineBuchungssysteme oder Unternehmensportale
•
Neben der technisch einwandfreien Basis fokusiert sich kuehlhaus bei der Entwicklung von Internet-Anwendungen auf
drei Ziele (vgl. Abbildung1):
•
1.
•
2.
308
Usability:
Die Internetangebote müssen für
den Nutzer leicht verständlich und
intuitiv bedienbar sein, also den Ansprüchen an eine optimale Usability
gerecht werden.
Design:
Häufig entscheidet nur ein kurzer
Blick, ob das Angebot wahrgenommen und anschließend akzeptiert
wird oder nicht. Ein ansprechendes
visuelles Design und innovative
Ideen sind daher ausschlaggebend.
•
Abb 1: Usability, Design und Wirtschaftlichkeit im Business Centered Design Modell
der kuehlhaus AG
Business Centered Design: Am
Beispiel eines Prozesses der
kuehlhaus AG
für jedermann einfach zu verstehen
sind
eine hohe grafische Qualität besitzen
dem Nutzer eine optimale Interaktion bieten, Leads generieren und
somit
die gesetzten Marketing- und Vertriebsziele erreichen.
Das Business Centered Design Modell ist eine von kuehlhaus entwickelte
Methode, mit der über die Usability hinaus, sämtliche Aspekte des zugrunde
liegenden Businessmodells von Portalen
oder Shops verwirklicht werden. Die
praxiserprobte Herangehensweise für
die Entwicklung von Internetanwendungen nutzt die bewährten Standards aus
dem User Centered Design, betrachtet
aber neben dem Benutzer von Anfang
an zusätzlich die Marketing- und Ver-
triebsziele der Anwendung und berücksichtigt diese durch alle Phasen der
Entwicklung (siehe Abbildung 2). Das
Business Centered Design Modell der
kuehlhaus AG definiert sich durch vier
aufeinander folgende Phasen, deren
Produkte zyklisch mit dem Auftraggeber
abgestimmt bzw. mit dem Endanwender
getestet werden. So wird eine hohe
Qualität gewährleistet und das Projekt
aufgrund der methodenbasierten Struktur kalkulier- und steuerbar.
Joy-of-Use ist ein weiterer Faktor, der
durch die parallele Entwicklung des grafischen Designs und der Interaktionen
berücksichtigt wird. So ist es bereits früh
möglich, innovative Konzepte einfließen
zu lassen und diese auch zu testen.
Abb 2: Die Phasen des Business Centered
Design Modells der kuehlhaus AG
2.1
Strategie und Technik: Ziele und
Anforderungen festlegen
In der ersten Phase der Entwicklung
anspruchsvoller Internet-Anwendungen
wird eine eingehende Anforderungsanalyse durchgeführt. Die grundsätzlichen
Ziele für das geplante Projekt werden so
gemeinsam erörtert und festgesetzt. Das
Business Centered Design Modell berücksichtigt dabei neben einer Betrachtung der Nutzeranforderungen, also den
Mehrwerten für die späteren Nutzer,
auch die geschäftlichen Ziele des Auftraggebers und die gewünschten Marketingeffekte des Angebots. Außerdem
wird das bestehende Marktumfeld betrachtet und die Stärken und Schwächen
des Wettbewerbs analysiert, um sich
gezielt von diesen absetzen zu können.
Schon in dieser frühen Phase werden
daher die Marketing- und Vertriebsabteilungen des Auftraggebers direkt in
die Konzeption mit einbezogen. Gemeinsam werden die geschäftlichen
Ziele und deren Vereinbarkeit mit den
Nutzeranforderungen analysiert.
•
•
•
•
•
•
Nach dieser Phase ist klar, was der
Anwender und der Kunde von d