Page 1

Henning Brau, Andreas Lehmann, Kostanija Petrovic, Matthias C. Schroeder

Usability Professionals 2012

Wir arbeiten daran. Arbeiten Sie mit.


Sponsoren

Konferenzsponsoren

German UPA Fรถrderkreis

2


Inhaltsverzeichnis

Tutorials 10

mConcAppt Methode

Felix Kiefer; Steffen Hess

18

User Centered Business Model Design

Tobias Limbach

22

Von der Idee zum Prototypen

Eva-Maria Holt; Dominique Winter; Jörg Thomaschewski

28

Dem UX-Professional zugeworfene Themen gekonnt auffangen: HCD-Aktivitäten maßschneidern

Knut Polkehn; Jens Hüttner

34

Aktuelle Trends im Bereich interkultureller UX – Roadmap for Intercultural User Interface Design

Dr.-Ing. Kerstin Röse; Dr. Rüdiger Heimgärtner

38

Analog = Digital – Über den Sinn und Unsinn von UXD- und DT-Modellbauaktivitäten

Oliver Gerstheimer

Praxisberichte 44

Kaufempfehlungen in Onlineshops

Martin Beschnitt; Sascha Küchler

52

Einfach besser lernen!

Christiane Schmidt; Gerrit Prager; Maria Mory

60

Icon Design im großen Stil – Erfahrungen zu Gestaltung und Einsatz von umfangreichen Icon-Bibliotheken

Evelina Kirstein; Nadine Schoenherr; Ulf Schubert

3


Workshops 68

Workshop des Arbeitskreises „Usability in der Medizintechnik”

72

Wie testet man soziale Software und deren soziale Mechanik?

Melanie Aust; Oliver Jacobs; Tobias Walke

Dr. Theo Held; Jürgen D. Mangerich

Methoden + Messung 78

Konstruktion eines Fragebogens für jugendliche

Personen zur Messung der User Experience

Andreas Hinderks; Martin Schrepp; Maria Rauschenberger; Siegfried Olschner; Jörg Thomaschewski

84

Das Usability-Experiment als Ergänzung zu typischen Usability- und A/B-Tests

Heinrich R. Liesefeld

90

HUX – Measuring Holistic User Experience

Claude Toussaint; Marc Toussaint; Stefan Ulrich

Nutzerwissen wissen und nutzen 96 Online-Fokusgruppen

Dr. Siegfried Olschner; Heidi Hoffmann; Ulf Schubert

102 User Experience Wissen recyclen

Markus Flückiger; Stephanie Föhrenbach

108 Wissensmanagement für Usability

4

Ben Heuwing; Steffen Weichert; Thomas Mandl


Usability Professionals 2011 Inhalt

Zielgruppen im Kontext 118 Wissensmanagement für Usability

Cornelia Wendt; Dr. Christoph Nedopil; Dr.-Ing. Sebastian Glende

126 Inclusive Gaming – Spieleentwicklung neu denken!

Janine Liebal

132 Milieubeschreibungen als Meta-Personas

Henning Brau; Malte Krökel; Tobias Limbach

Arbeitskreise German UPA 138 User-eXperience (UX) meets Return-on-Investment (RoI)

Elena Gocheva; Katharina Göring; Andreas Hinderks,; Boris Oliver Kneisel; Christine Krämer; Oliver Siegmund

144 Wie gut ist mein Unternehmen im Usability Engineering und wie kann es (noch) besser werden? Berit Leiking; Charlene Beavers; Desdemona Strauß; Dr. Natalie Woletz; Marius Wolf; Nicole Charlier 148 Barrierefreiheit 101 für Websites

Brigitte Bornemann; Nicole Charlier ; Petra Kowallik

150 mobile, responsive, accessible

Alexander Götze; Rebecca Rothfuß; Stefan Farnetani; Stefanie C. Zürn; Thomas Heilmann

156 Nachhaltige Barrierefreiheit in Websites

Brigitte Bornemann; Harald Weber

160 Der Qualitätsstandard für Usability Engineering der German UPA Holger Fischer; Knut Polkehn; Oliver Kluge; Thomas Geis; Christian Bogner 166 Usability Professionals Nachwuchs fördern mit Sozialen Medien Anja Wipfler; Astrid Beck; Kostanija Petrovic 5


Von Anforderungen zum Produkt 170 Die Brücke zwischen Anforderungen und Design schlagen

Andreas Maier; Diana Löffler; Jörn Hurtienne

176 Bridging the Gap Between Analysis and Design

Dr. Dennis Krannich

182 Design mit Nicht-Designern

Lennart Hennigs

User Experience 190 „Das ist ein gewachsenes Produkt“ – User Interface Balkonitis

Guido Tesch

196 Usability (Re-) Engineering von Legacy Systemen

Christian Wolff; Isabella Hastreiter; Markus Heckner; Tim Schneidermeier

202 Interaktive Kommunikation für Ausstellungen gestalten

Thomas Willis

208 Die papierlose Haltestelle

Paul Müller; Benjamin Laukenmann; Oliver Siegmund

212 Cross Plattform Mobile Application Design

Björn Oltmanns

222 Multiscreen Experience Design

Wolfram Nagel

230 Best Practice „Automobilbranche“ Service- und Informationsportal Gesa Nolte; Oliver Gerstheimer; Sebastian Ammermüller

6


Usability Professionals 2011 Inhalt

236 Anforderungen an HMI in industriellen Kontexten

Jan Groenefeld; Markus Kühner; Natalie Oster

244 Mobile User Experience Engineering – Mit Methodik und der richtigen Technologie zu erfolgreichen Apps Dr. Thomas Memmel; Katja Neumann; Mischa Demarmels 250 Alle schreiben SMS – aber wer füllt gerne Formulare aus?

Sandra Schuster

254 Nur weil es viele Retweets kriegt, ist es noch lange nicht richtig Dr. Markus Weber 258 Privacy UX – Was ist datenschutzbezogene User Experience? Michael Hatscher; Sebastian Schnorf; Martin Ortlieb; Kalle Kormann-Philipson 264 Accessible Content Strategy – Inhalte für die Zukunft fit machen Markus Erle 268 Agil und kundenorientiert? Arbeiten bei AutoScout24

Susanne Hanst

274 UX in den frühen Phasen des Innovationsprozesses

Dominique Winter; Jens Pietschmann

280 Sehen, Aussehen, Sichten

Herbert Baumberger; Manja Kurzak

288 Branchenreport Usability 2012

Daniel Ullrich; Nina Kolb; Sarah Diefenbach

7


Kurzvorträge 296 Entwicklung und Erprobung von Prototypen zur taktilen Warnung von Menschen in schwierigen Arbeitsbedingungen Jurij Wakula; Michael Schultheis; Ralph Bruder; Sinja Röbig 302 308

Using Eye Tracking in Usability Testing of Mobile Interfaces Alexander Rösler

Usability-Analyse ausgewählter HbbTV-Mediatheken im Mehr-Methoden-Design Daniel Mertens; Prof. Dr. Sven Pagel

314 Einführung eines Rahmenwerks zur Etablierung eines nutzerorientierten Vorgehens in Marketing-Projekten der adidas Group

Lucie Grudno; Leo Glomann

318 Die nachhaltige Einführung und Verankerung von User Experience in Unternehmen Christian Hauri; Stefania Rosati

Referenten 324 Referenten

Impressum 352 Impressum

8


Tutorials

9


mConcAppt Methode UX und Interaktionsdesign für mobile Business Apps

Steffen Hess Fraunhofer IESE Fraunhofer-Platz 1 67663 Kaiserslautern steffen.hess@iese.fraunhofer.de

Felix Kiefer Fraunhofer IESE Fraunhofer-Platz 1 67663 Kaiserslautern felix.kiefer@iese.fraunhofer.de

Abstract Unternehmen haben längst das Potential von mobilen Anwendungen (Apps) erkannt. Gerade mobile Mitarbeiter können ihre Effizienz und den Komfort ihrer Workflows durch die Nutzung von Apps steigern. Die Entwicklung solcher Business Apps ist mit speziellen Herausforderungen verbunden. Beispielsweise hohe Usability und User Experience, kurze Produkteinführungszeit, klar definierter Funktionsumfang, Integration in die bestehende IT Infrastruktur und die Berücksichtigung verschiedener Geräte und Geräteplattformen. Diese Herausforderungen müssen schon während der Konzeption von Business Apps durch Usability Professionals adressiert werden. Das Tutorial vermittelt anhand eines durchgängigen Beispiels die Anwendung der mConcAppt Methode unter der Benutzung von praktisch erprobten Templates. Die Methode wurde bereits mehrfach bei der Erstellung von konkreten Business Apps angewendet und hat als Resultat ein fertiges Interaktionskonzept. Teilnehmer des Tutorials erlernen unter anderem die Erstellung von Personas, Interaction Cases, Rapid Prototypes und Screen Flows für mobile Business Apps.

1. Einleitung Ohne Zweifel haben mobile Apps den Konsumentenmarkt erobert und Einzug ins tägliche Leben der Menschen erhalten. Aber auch im geschäftlichen Umfeld wird das Potential von mobilen Geschäftsapplikationen (sog. Mobile Business Apps) erkannt. Mehr und mehr Unternehmen versuchen ihr eigenes mobiles Potential zu entdecken und dieses für sich zu nutzen. Ziele der Unternehmen sind dabei einerseits die Steigerung von Arbeitseffizienz und Arbeitskomfort der Angestellten (interne Nutzung von Apps), aber auch die Erweiterung des bestehenden Produktportfolios durch Apps (Produktion von Apps). Mobile Business Apps bieten darüber hinaus ein hohes Potential, bestehende Geschäftsprozesse nicht nur zu unterstützen, sondern vielmehr diese zu erweitern bzw. signifikant zu vereinfachen.

10

Bei der Entwicklung von Mobile Business Apps sehen sich Unternehmen mit neuen Herausforderungen konfrontiert, denn die Konzeption und Entwicklung von mobilen Applikationen unterscheidet sich von der herkömmlicher Informationssysteme. So müssen bei der Konzeption von Mobile Business Apps nachstehende mobile spezifische Herausforderungen von Usability Professionals berücksichtigt werden: –– Hohe Usability und User Experience: Usability und User Experience sind sehr wichtige Qualitätsattribute für Mobile Business Apps. Für die Akzeptanz einer Applikation erwarten Nutzer diese direkt produktiv einsetzen zu können. Typischerweise lesen sie keine Anleitungen oder benutzen Hilfesysteme. Viel mehr werden Anwendungen, die die Erwartung der Anwender nicht erfüllen abgelehnt und nicht weiter eingesetzt. Es wird eine einzigartige User Experience erwartet, die insbesondere auf die zugrundeliegende Plattform

Keywords: /// Mobile Business Apps /// User Experience /// Interaktionsdesign /// Requirements Engineering

zugeschnitten ist. Zur Erhöhung der User Experience sollten unter anderem besondere Features der Geräte (z. B. Sensordaten, Multitouch, Kamera, Mikrophon) verwendet werden. Insbesondere die bei Mobile Business Apps in der Regel benötigte Kommunikation mit einem Backend ist für Usability und User Experience relevant. –– Klarer und limitierter Funktionsumfang: Ein weiterer kritischer Erfolgsfaktor für Mobile Business Apps, den wir in der Praxis beobachten konnten, ist ein klarer und limitierter Funktionsumfang. Optimale Produktivität kann in der Regel erreicht werden, wenn die App auf eine bestimmte Geschäftsaktivität für eine bestimmte Rolle zugeschnitten ist und keine allesumfassende Lösung darstellt. –– Erweiterung existierender Geschäftsprozesse: Zunächst müssen Organisationseinheiten und existierende Geschäftsprozesse


Usability Professionals 2012 Tutorials

identifiziert werden, die sinnvoll durch Mobile Business Apps unterstützt werden [Yuan, 2005] können. Diese Identifikation muss dann direkt mit der Konzeption verbunden sein. Dabei sollten kreative Lösungen gefunden werden, wie der Geschäftsprozess nicht nur unterstützt sondern ggf. auch vereinfacht werden kann. –– Nutzungskontext und Nutzungsumgebung: Herausforderungen bezüglich des Nutzungskontexts sind schon bei der traditionellen Anwendungskonzeption sehr vielfältig. Neben Faktoren, wie Temperatur, Lichtverhältnisse, Geräusche, Ablenkung, Mobilität des Nutzers, kognitive Belastung und physische Einschränkungen [Looije, 2007] muss für Mobile Business Apps der konkrete Nutzungskontext erhoben werden. Da Mobile Business Apps auf einem konkreten Unternehmenstask basieren, ist der Nutzungskontext besser bestimmbar als vergleichsweise bei Konsumenten-Apps. –– Durchführung von frühen Usability Tests im Nutzungskontext: Bezüglich Usability Testing besteht eine der Hauptherausforderungen in der Durchführung von frühen Nutzertests im aktuellen Nutzungskontext auf dem Endgerät. Mitunter sind Nutzer von Mobilen Business Apps nur schwer verfügbar (z. B. Piloten), da diese in geschäftskritische Aktivitäten eingebunden sind und eine Freistellung oft mit hohen Kosten für das Unternehmen verbunden ist. Außerdem involviert der Nutzungskontext oft Kunden des Endnutzers (z. B. Passagiere), die aus verschiedenen Gründen nicht in die Konzeption der App involviert werden können. –– Konsistentes Look & Feel: Aus dem klaren und limitierten Funktionsumfang einer Mobile Business App ergibt sich für Unternehmen die Konsequenz ein sog. App-Portfolio mit mehreren maßgeschneiderten Anwendungen aufzubauen. Für dieses Gesamtportfolio an Mobile Business Apps, ist es wichtig, ein konsistentes

Look & Feel zu gewährleisten. Durch ein konsistentes Look & Feel können erlernte Konzepte vom Anwender über das gesamte App-Portfolio angewendet werden. Eine weitere Herausforderung für das Look & Feel von Mobile Business Apps besteht darin, dass bereits existierende sonstige Software im Unternehmen beachtet werden muss, um somit ein konsistentes Look & Feel über die gesamte Unternehmenssoftware zu erhalten. –– Limitierte Nutzeraufmerksamkeit: Da die Nutzung von Mobilen Business Apps oft in einem ständig wechselnden, mobilen Kontext stattfindet haben Nutzer nur eine limitierte Aufmerksamkeit für die Interaktion. Ein Großteil der Aufmerksamkeit muss von den Anwendern auf den wechselnden Kontext der Benutzung oder weiteren ‚Tasks‘ (bspw. gehen) aufgewendet werden. Der Umstand, dass die App in einem primären oder sekundären Task benutzt wird muss bei der Konzeption der Mobile Business Apps beachtet werden. Neben diesen spezifischen Herausforderungen gibt es aber auch noch generelle Herausforderungen, die einen Einfluss auf die Konzeption von Mobilen Business Apps haben: –– Kurze Markteinführungszeit und limitiertes Budget: Entwicklungen von Mobile Business Apps müssen schnell sein und haben in der Regel ein sehr limitiertes Budget. Dennoch müssen sie ein hohes Maß an Softwarequalität bereitstellen. Daher ist eine leichtgewichtige Vorgehensweise in der Praxis notwendig, die es ermöglicht schnell hochwertige Apps zu erstellen. –– Integration in eine existierende IT-Infrastruktur: Grundlage für Mobile Business Apps stellt in der Regel die Kommunikation mit einem Backend System dar. Häufig werden benötigte Informationen aus einer bereits im Unternehmen existierenden Infrastruktur an die Mobile Business

App übertragen. Die Integration von Mobile Business Apps hat oft Modifikationen im Backend zur Folge. Hieraus ergibt sich ein besonderer Abstimmungsbedarf zwischen den Bereichen des Interaktionsdesigns der Applikation und der Architektur des Gesamtsystems. Bereits in frühen Konzeptionsphase müssen sich beide Bereiche intensiv miteinander auseinander setzen, da sich hier entscheidet, welche Funktionalität in der eigentlichen App und welche auf dem Backend realisiert wird und welche Auswirkungen diese Entscheidungen auf die User Experience haben. –– Unterstützung verschiedener Geräte und Geräteplattformen: Schon bei der Konzeption von Mobile Business Apps muss berücksichtigt werden, dass die spätere Business App auf verschiedenen Geräten und Geräteplattformen eingesetzt werden kann. Dies beinhaltet aktuell vor allem die Unterscheidung zwischen Android und iOS-Systemen und zwischen Smartphone und Tablet. Um den Herausforderungen an Mobile Business Apps gerecht zu werden und diese in ihrer Gesamtheit adressierbar zu machen, müssen sie mit einem methodischen Engineering Ansatz erstellt werden. Dieser muss auf der einen Seite sehr nutzerzentriert sein, um die Ziele der Benutzer zu erfüllen, auf der anderen Seite leichtgewichtig und integriert sein, um die Ziele der Unternehmen und der übrigen im Softwareentwicklungsprozess beteiligten Rollen zu erfüllen. Dieser Artikel stellt die mConcAppt Methode vor – eine Methode zur Konzeption von Mobilen Business Apps. Konzeption umfasst in diesem Fall sowohl Requirements Engineering Aktivitäten, als auch Interaktionsdesign und dessen Evaluation. Diese integrierte Sichtweise stammt aus dem TORE Ansatz zum task-orientierten Requirements Engineering [Adam, 2009]. Die mConcAppt Methode verwendet weitestgehend traditionelle Konzepte des Requirements und Usability Engineering.

11


Communicate Interaction Design und Validate Interaction Design. Bevor ein App Konzept erstellt wird, gibt es vorgelagerte Aktivitäten. Als Ausgangspunkt wird hierbei der Bedarf nach mobiler Unterstützung oder eine App-Idee innerhalb eines Unternehmens angenommen. Basierend darauf muss zunächst ein initiales Projektbudget allokiert und ein Projektteam zusammengestellt werden.

Abb. 1. Überblick der mConcAppt Methode

Diese sind jedoch auf die besonderen Herausforderungen und Bedürfnisse von Mobile Business Apps angepasst. Die Methode ist nutzerzentriert, um hohe Usability und User Experience, sowie einen klaren und limitierten Funktionsumfang zu gewährleisten. Sie ist leichtgewichtig, um die Anforderungen von Organisationen an effiziente App Entwicklung und kurze Markteinführungszeiten zu realisieren. Außerdem bietet mConcAppt Schnittstellen zu sämtliche Aktivitäten des Software Engineering Prozesses und ist somit in diesen vollständig integriert. Das folgende Kapitel gibt einen Überblick über die mConcAppt Methode und die darin verwendeten Templates und Ansätze.

2. mConcAppt Methode Im nachstehenden Kapitel wird zunächst ein genereller Überblick über die mConcAppt Methode aufgezeigt. Darauf folgend werden die einzelnen Phasen der Methode im Detail beschrieben. 2.1. Überblick Die mConcAppt Methode besteht aus vier Phasen (vgl. Abbildung 1): Elicit Requirements, Specify Interaction Design,

12

Danach beginnt die eigentliche Durchführung der mConcAppt Methode – entscheidend dabei ist die enge Kommunikation mit den umliegenden Entwicklungsaktivitäten. Vor allem die Schnittstelle zu Business Analyse und zu Architektur sind wichtige Quellen für Anforderungen an das Interaktionsdesign. Aber auch frühe Kommunikation zu Entwicklung, Testen und Visual Design sind notwendig, um z. B. Testfälle zu planen, technische Konzepte zu erproben und visuelle Designs vorzubereiten. Nachgelagerte Aktivitäten der Methode umfassen vor allem die eigentliche Entwicklung von App und Backend, sowie die in-house-Distribution bzw. die Distribution in den App-Stores. [Abb. 1] Zunächst werden in der Elicit Requirements Phase die Requirements für das Interaktionskonzept erhoben. Darauf aufbauend wird das eigentliche Interaktionskonzept spezifiziert und anschließend zu den übrigen Stakeholdern kommuniziert. Es ist sehr wichtig, dass bereits frühe Versionen des Interaktionskonzeptes zu sämtlichen Mitgliedern des Projektteams und übrigen Stakeholdern kommuniziert werden, da deren Feedback bzgl. Machbarkeit und die Auswirkungen auf deren Bereiche Einfluss auf das Interaktionsdesign haben. Eine genaue Struktur der Informationsschnittstellen zwischen der mConcAppt Methode und den anderen SE-Rollen ist ausführlicher in [Hess, 2012] beschrieben. Eine Validation des Konzeptes in Form von Endnutzertests erfolgt nur zu bestimmten Zeitpunkten in Absprache mit dem Projektmanagement. Gerade bei Business Apps ist es notwendig, dass die Produktverantwortlichen entscheiden können, an welchem Punkt im Entwicklungsprozess Nutzer involviert werden

können, da frühe Entwicklungsstadien von Produkten oft kritisch sind bzgl. der öffentlichen Bekanntmachung. Wichtig für die Durchführung der Methode ist, dass sie keinen sukzessiver Ablauf, sondern ein iteratives Vorgehen beschreibt. Input und Output aus den verschiedenen Phasen gehen jeweils in die übrigen Phasen ein. Die folgenden Unterkapitel zeigen, wie die Phasen im Detail aussehen, unter der Annahme, dass diese einmal komplett durchlaufen werden. Für jede Aktivität der Phasen existieren Templates, die die Anwendung der Methode operationalisieren. 2.3. Elicit Requirements Die Elicit Requirements Phase fasst die initiale Erhebung von Anforderungen für das Interaktionsdesign zusammen. Sämtliche Aktivitäten dieser Phase und deren geschätzte Dauer sind in Abbildung 2 dargestellt. Zentraler Baustein hierbei ist ein Workshop, der sowohl Endnutzer als auch übrige relevante Stakeholder inkludiert. [Abb. 2] Workshop Preparation beinhaltet hierbei alle Planungstätigkeiten, die notwendig sind um den Workshop durchzuführen. Hierzu zählt vor allem die Auswahl der Teilnehmer des Workshops. Wir haben beste Erfahrungen damit gemacht, die Gruppe möglichst klein zu halten und die Rollen der Teilnehmer klar zu spezifizieren (vgl. Tabelle 2). [Tab. 1]

Die eigentliche Durchführung und Dokumentation des Workshops ist in Abbildung 3 dargestellt. Zunächst werden die Stakeholder und Nutzerrollen der künftigen App erhoben. Darauf aufbauend wird für die Hauptnutzergruppe gemeinsam eine User Persona [Cooper, 1999] erstellt. Die gewählte Persona sollte hierbei eine Instanziierung der Nutzergruppe sein, die dem 80%-Nutzer am nächsten kommt. Sie beschreibt die verschiedenen Ziele und Verhaltensweisen des Nutzers, sowie persönliche Eigenschaften und Charakteristika. Zusätzlich kapselt und erklärt sie kritische Verhaltensweisen und stellt diese personifiziert dar. Dies ermöglicht es


Usability Professionals 2012 Tutorials

Abb. 2. Elicit Requirements Phase

Die Beschreibung der künftigen Situation (to-be Situation) enthält die zuvor definierten Szenarien der as-is Situation inklusive der Unterstützung durch die künftige App. Hierbei wird insbesondere darauf eingegangen, wie existierende Geschäftsprozesse durch die App verbessert bzw. erweitert werden können. Sowohl die as-is Situation als auch die to-be Situation werden mit einem standardisierten Template beschrieben (siehe Tabelle 3). Es enthält in einer leichtgewichtigen Form die wichtigsten Schritte einer Szenariobeschreibung. Abschließend werden im Workshop bereits gemeinsam die wichtigsten Systemfunktionen (Main System Functions) skizziert und priorisiert. Diese werden aus den beschriebenen to-be Szenarien abgeleitet und bilden den Kern der App. Durch die frühe Skizzierung der Kernfunktionalitäten wird bereits ein wichtiger Grundstein für einen kleinen Umfang von Features gelegt. Diese Features fokussieren dabei genau auf die zuvor definierten Lösungen und verhindern einen zu breitgefächerten Funktionsumfang einer einzelnen Applikation. Während des Workshops können die erhobenen

Artefakte oft nur skizzenhaft dokumentiert werden. Um auch die Dokumentationsarbeiten, die im Nachgang durchgeführt werden müssen, leichtgewichtig zu halten, bietet die mConcAppt Methode auch für diesen Schritt geeignete Templates und Vorlagen. [Tab. 2] Praktische Erfahrungen zeigen, dass in der Tat nur ein Workshop benötigt wird, um die initialen Anforderungen zu erheben. Dennoch sollten im Nachgang kurze Kommunikationswege (bspw. E-Mail oder Telefon) eingesetzt werden um durch Gespräche mit vorher bestimmten Ansprechpartnern etwaige Unklarheiten beseitigen zu können. Dennoch ist es wichtig, so viele Informationen wie möglich bereits im Voraus zu erheben. Um eine möglichst vollständigen Informationsfluss zu erhalten ist es notwendig, dass alle zuvor definierten Rollen am Workshop teilnehmen. Unsere Erfahrung zeigt auch, dass die Qualität der Ergebnisse des Workshops erheblich durch die Qualitäten und Erfahrungen des Moderators bestimmt werden.

Abb. 3. Workshop Durchführung

anderen Projekt-Stakeholder diese Eigenschaften zu verstehen, sich an sie erinnern und sich bei Designentscheidungen darauf beziehen zu können. Die Persona wird auch genutzt, um die aktuelle Situation des Nutzers in Form von Szenarien zu beschreiben. Die Szenarien beinhalten die vorab identifizierte App-Idee oder den identifizierten Bedarf nach mobiler Unterstützung. Ein wichtiger Fokus bei der Beschreibung liegt hierbei auf der Identifikation von Problemen in der aktuellen Situation (as-is Situation), die durch den Einsatz einer App gelöst oder gemindert werden können. [Abb. 3]

Tab. 1. Workshop Teilnehmer und deren Rolle im Workshop

Tab. 2. Template zur Beschreibung von as-is und to-be Situation

13


Abb. 4. Interaction Design Specification Phase

2.3. Specify Interaction Design Input für die eigentliche Spezifikation des Interaktionskonzeptes (siehe Abbildung 4) sind sämtliche Informationen, die während des Workshops erhoben und nachfolgend dokumentiert wurden. Für die Spezifikation des Interaktionskonzeptes wird zunächst die Key Funktionality bestimmt. Sie wird mit Hilfe der to-be Szenarien und den im Workshop bereits definierten Systemfunktionen abgeleitet. Im Gegensatz zu den Systemfunktionen, die mit einem höheren Abstraktionsgrad beschrieben werden, legt die Key Funktionality konkrete Schritte zur Erfüllung der angestrebten Systemfunktion fest. Es wird explizit festgehalten, welche Schritte im Szenario tatsächliche mobile Unterstützung benötigen. Durch die Beschreibung der Key Funktionality wird auch der letztendliche Umfang der Business App bestimmt. [Abb. 4]

die mConcAppt Methode ein Template (siehe Tabelle 3) zur Verfügung. Diese Template beinhaltet wenige Items um dem leichtgewichtigen Anspruch der Methode gerecht zu werden. Allerdings wird bereits hier explizit zwischen Benutzeraktion (Human Action) und Systemaktion (System Action) unterschieden um einen möglichst hohen Grad von Nutzerzentriertheit wiederzugeben. Die Human Action beschreibt die konkrete Form der Interaktion (z. B. die konkrete Geste, mit der der Benutzer die Eingabe tätigt) – die System Action beschreibt die explizite Systemreaktion auf die Eingabe des Benutzers. Bei der Beschreibung der System Action gibt das Template vor, explizit zwischen Eingabefeedback und eigentlicher Systemausgabe zu unterscheiden. [Tab. 3] In der Regel ist der Interaction Case so geschnitten, dass jeweils eine Human Action und eine System Action als User Story abgebildet werden können. Nachdem sämtliche Interaction Cases spezifiziert wurden, werden diese in einem Interaction Case Flow arrangiert. Der Interaction Case Flow zeigt Abhängigkeiten und Navigationsmöglichkeiten zwischen den verschiedenen Interaktionen auf. Mit Hilfe des Interaction Case Flow wird der momentane Skopus der Applikation in einer übersichtlichen Form dargestellt. Diese Darstellung dient als Grundlage der

Zur Beschreibung der Key Functionality werden Interaction Cases spezifiziert. Interaction Cases sind leichtgewichtige Use Cases, die einen sehr starken Fokus auf die Benutzerinteraktion haben. Für die Dokumentation der Interaction Cases stellt

Tab. 3. Beschreibungstemplate für Interaction Cases

14

finale Entscheidung über den Umfang der App. Beinhaltet sie zu viele Bereiche oder zu viele Interaction Cases, ist der Skopus womöglich zu groß gewählt und es sollte untersucht werden, ob sich dieser sinnvoll in mehrere kleinere Apps unterteilen lässt. Anschließend werden für die Interaction Cases Wireframes erstellt. Hierbei wird in der Regel jedes Paar aus Human Action und System Action durch ein Wireframe dargestellt (vgl. Abbildung 5). Für das Interaktionskonzept ist es ausreichend, diese mit Papier und Stift zu erstellen – oder ein leichtgewichtiges Tool wie z. B. Balsamiq (http://www.balsamiq.com) zu verwenden. Da die Wireframes untereinander semantisch verknüpft sind, wird parallel zu ihnen auch der Screen Flow (siehe Abbildung 6) erstellt. In ihm wird dargestellt, wie der Benutzer durch die Wireframes navigieren kann. Neben den Navigationswegen wird auch angegeben, welche Screenübergänge (Transitionen) zwischen den Screens eingesetzt werden. [Abb. 5], [Abb. 6] Praktische Erfahrungen zeigen, dass es von Vorteil ist, wenn der Interaktionsdesigner selbst extensiver Nutzer der Zielplattform ist. Somit ist garantiert, dass plattformspezifische Interaktionsformen bekannt sind und auch im Interaktionskonzept der Applikation berücksichtigt werden. Neben direkten Entscheidungen


Usability Professionals 2012 Tutorials

Abb. 5. Abbildung verschiedener Evolutionsstadien von Wireframes

des Interaktionsdesigners haben auch Entscheidungen die gemeinsam mit anderen SE-Rollen getroffen werden starke Bedeutung für das App-Verhalten. So haben gerade die Entscheidungen, die bestimmen, welche Funktionalität auf dem Backend und welche auf dem Frontend (der eigentlichen App) realisiert wird großen Einfluss auf die Usability und User Experience und somit auch auf den Erfolg einer Applikation haben. Werden bspw. zu rechenintensive Funktionen in der Applikation ausgeführt oder stehen benötigte Informationen nicht zum gewünschten Zeitpunkt in der Applikation zur Verfügung leidet die User Experience und somit auch die Akzeptanz der Applikation beim Endnutzer. Um falsche Entscheidungen in diesem, aber auch in anderen Bereichen der App-Entwicklung vorzubeugen ist eine frühe Kommunikation von Ideen und Sketches zu den entsprechenden Stakeholdern notwendig. Durch eine permanente Kommunikation wird signifikant die Qualität des Resultates verbessert. Unsere Erfahrung hat gezeigt, dass gerade das Interaktionsdesign und die SoftwareArchitektur sich erheblich beeinflussen. Die angesprochene Problematik der Backend/Frontend-Beziehung wird maßgeblich von der Architektur beeinflusst. Das App-Frontend hängt dabei sehr von der Performanz im Backend ab.

Abb. 6. Abbildung eines Screen Flows einer Beispielanwendung

2.4. Communicate Interaction Design In der Communicate Interaction Design Phase wird das Interaktionsdesign zu den übrigen Projekt Stakeholdern kommuniziert (Vergleiche Abb.9). Unsere Erfahrungen zeigen, dass die Erstellung eines Videos, in dem das Interaktionskonzept beschrieben wird eine gute Lösung ist, um das Verständnis der Konzepte und Ideen des Interaktionsdesigners zu kommunizieren. Dies ist insbesondere der Fall, wenn es sich um ein lokal verteiltes Projektteam handelt. Sollte das Projektteam nicht lokal verteilt sein, ist die Erstellung des Videos als optionaler Schritt zu sehen. Auch wenn unsere Erfahrung gezeigt hat, dass es gerade bei nicht technischen Stakeholdern ein sehr gutes Kommunikationsmedium darstellt. Der Fokus des Videos sollte darauf liegen, die Informationen zwischen allen beteiligten Stakeholdern auszutauschen und Feedback einzuholen. Dieses kann dann bei der Gestaltung des Interaktionskonzeptes Berücksichtigung werden. Um das Video zu erstellen, sollte insbesondere der unerfahrene Interaktiondesigner zunächst ein Drehbuch (Presentation Script) schreiben. Basierend auf diesem Drehbuch werden Clips aufgenommen, die sich an den zuvor erstellten Interaction

Cases orientieren. Bei der Erstellung der Clips ist es wichtig jeden einzelnen Schritt im Video nicht nur zu zeigen sondern auch mit kurzen und prägnanten Worten zu erklären. Aus diesen Clips wird nachfolgend ein komplettes Video erstellt, das im gesamten Projektteam verteilt werden kann. Dieses Video ermöglicht es insbesondere fachfremden Personen, das Interaktionskonzept schnell und in einfacher Weise zu verstehen, ohne ein umfassende Dokumentation lesen zu müssen. [Abb. 7]

Abb. 7. Communicate Interaction Design Phase

15


Im Presentation Script wird die Interaktion mit der Mobile Business App anhand der erstellten Wireframes in Form von Szenarien erfasst. Dabei ist es wichtig, vor allem Hintergrundinformationen bzgl. Designentscheidungen, die man nicht auf den ersten Blick sehen kann, zu geben (z. B. Screen Transitionen, Gesten, Eingabefeedback und besonders innovatives oder nicht standardisiertes Verhalten der Applikation). Erfahrene Interaktionsdesigner können auf die Erstellung des Presentation Script verzichten und direkt das Video drehen. Die Erstellung des Presentation Script ist dennoch ratsam, da es eine wichtige Dokumentationsquelle auch für die weiterführenden Arbeiten darstellt.

Präsentationssoftware für Mobilgeräte verwendet werden. Wichtig ist dabei, dass die Präsentationen nicht-linear ablaufen müssen (z. B. Presentation Link – http:// www.presentation-link.com). Dieser Ansatz erfordert nur geringfügig mehr Aufwand als beispielsweise das Wizard-Of-Oz Testing [Kelley, 1983] mit echten Papierprototypen. Zudem ermöglicht es der Einsatz von mobilen Präsentationstools, den Prototyp in der tatsächlichen Nutzungsumgebung auf dem Endgerät zu testen. Da sowohl der Nutzungskontext wie auch das Endgerät großen Einfluss auf die Mobile Business Apps haben, ist ein Test unter möglichst realen Bedingungen unbedingt erforderlich. [Abb. 8]

2.5. Validate Interaction Design

3. Zusammenfassung und Ausblick

Wie in Abbildung 1 zu sehen ist, wird die Validierungsphase erstmals am Ende einer kompletten Iteration der Methode durchgeführt. Abbildung 8 zeigt einen Überblick der durchzuführenden Aktivitäten. Basierend auf den Interaction Cases werden konkrete Nutzungsszenarien [Carrol, 2000] erstellt, die die Basis für die Durchführung der Nutzertests darstellen. Zusätzlich wird ein interaktiver Prototyp erzeugt. Hierzu können einfach Tools wie

Die mConcAppt Methode unterstützt ihren Anwender bei der systematischen Durchführung von Requirements Engineering und Interaktionsdesign für Mobile Business Apps. Sie hilft dabei vor allem, die für Mobile Business Apps genannten spezifischen Herausforderungen zu adressieren. So wird beispielsweise eine hohe Usability und User Experience durch den nutzerzentrierten Ansatz und die Verwendung existierender anerkannter Konzepte garantiert. Ein klarer und limitierter Funktionsumfang wird explizit während der Spezifikation des Interaktionsdesigns berücksichtigt. Erweiterung existierender Geschäftsprozesse, explizite Beachtung des Nutzungskontextes sowie die Sicherstellung eines konsistenten Look & Feels sind durch die systematische Erhebung von as-is und to-be Situation in Kombination mit den künftigen Endbenutzern ein zentraler Teil der Methode. Frühes Usability Testing im Nutzungskontext ist durch die Durchführung von Nutzertest in jeder Iteration der Methode ermöglicht.

komplette mConcAppt Methode adressiert.

Literatur 1. Adam, S.; Doerr, J.; Eisenbarth, M.; Groß, A. Using Task-oriented Requirements Engineering. In Proc. RE 2009, (2009) 267-272. 2. J.M. Carroll, “Making use: Scenario-based design of human-computer interactions” Cambridge, MA: The MIT Press, 2000. 3. A. Cooper, “The Inmates Are Running the Asylum : Why High-Tech Products Drive Us Crazy and How to Restore the Sanity” Indianapolis, USA, 1999. 4. S. Hess, and F. Kiefer, “Quality by Construction through mConcAppt – Towards Using UI-Construction as Driver for High Quality Mobile App Engineering” in Proc. of QUATIC 2012. 5. J.F. Kelley, “An empirical methodology for writing user-friendly natural language

Abb. 8. Validate Interaction Design Phase

16

Die limitierte Aufmerksamkeit der Benutzer ist bisher nicht explizit adressiert und ist eine der künftigen Arbeiten zur Weiterentwicklung der Methode. Die generellen Herausforderungen, die im ersten Kapitel beschrieben wurden, werden implizit durch die

computer applications” Proc. of ACM SIG-CHI ’83 Human Factors in Computing systems, Boston, 1983, New York: ACM, pp. 193-196. 6. R. Looije, and G. te Brake, “Neerincx, M.; Usability engineering for mobile maps” in Proc. of Mobility ’07,. ACM, New York, NY, USA, 2007, pp. 532-539. 7. Y. Yuan, and W. Zheng, “From Stationary Work Support to Mobile Work Support: A Theoretical Framework” Proc. of the International Conference on Mobile Business (ICMB ‚05). IEEE Computer Society, Washington, DC, USA, 2005, pp. 315-321.


Usability Professionals 2012 Tutorials

17


User Centered Business Model Design

Tobias Limbach User Interface Design GmbH Claudius-Keller-Str. 3c 81669 München tobias.limbach@uid.com www.uid.com

Abstract Mit einem Geschäftsmodell beschreibt ein Unternehmen, wie es für einen Kunden einen Nutzen erschafft, diesen verteilt und dafür einen Erlös erzielt. Viele Unternehmen stellen dabei den Kunden in den Mittelpunkt der Entwicklung. Als User Experience Designer verfügen wir über die Methoden, um den Dialog zwischen Kunde (Nutzer!) und Hersteller zu ermöglichen. Dieser Artikel gibt einen kurzen Einblick in die Grundbestandteile eines Geschäftsmodells und mögliche Beitragspunkte für User Experience Designer (UxD).

1. Einleitung Geschäftsmodell beziehungsweise Business-Modell ist seit dem Internet-Boom der Jahrtausendwende geradezu ein Buzzword geworden. Bis jetzt fehlt zwar immer noch eine allgemein akzeptierte Definition (Shafer et al., 2005), trotzdem wird der Begriff in Management und Praxis weitgehend eingesetzt. Hier wird es allerdings häufig als Synonym für Ertragsmodell oder Geschäftsplan verwendet – also für die finanzielle Planung der langfristigen Ertragssituation eines Unternehmens. Umgangssprachlich gesprochen wird hier eine Excel-Liste erstellt, in die man oben x Euro rein wirft und unten y Euro rauskommen. Dabei wird vorausgesetzt, dass das Produkt/der Service, welches/r angeboten wird, auch (für x Euro) gekauft wird. Gekauft wird in der Regel von Menschen. Meistens nutzen diese Käufer auch das Gekaufte, d. h., sie benutzen es. Ein Produkt / Service wird aber (zumindest langfristig beziehungsweise wiederkehrend) nur benutzt, wenn es / er für die individuellen Käufer einen Nutzen bietet und einen Mehrwert verspricht.

18

Vor der Planung der Ertragssituation sollte also erst einmal ein „Nutzen“ eines Produkts / Services bestehen. Folgend der Definition von Osterwalder und Pigneur (2011) können wir als Geschäftsmodell auch wie folgt definieren: „Ein Geschäftsmodell beschreibt das Grundprinzip, nach dem eine Organisation Werte schafft, vermittelt und erfasst.“ Diese Definition trifft eine wichtige Unterscheidung zwischen dem Erschaffen und Erfassen von Werten. Es ist also wichtig, dass ein Geschäftsmodell erklärt, wie Werte für den Kunden erschaffen werden (value in use) und wie dieser gestiftete Nutzen in Erträgen erfasst wird (value in exchange, also Monetarisierung). Die Definition von Osterwalder und Pigneur (2011) lässt Begriffe wie Ertrag, Profit, Finanzierung etc. komplett außen vor. Natürlich sind sie auch Bestandteile eines Geschäftsmodells, und langfristig werden sich auch nur Geschäftsmodelle am Markt durchsetzen, die profitabel sind. Aber Grundlage bleibt das Schaffen, Vermitteln und Erfassen von Werten, also Tätigkeiten, die im Austausch zwischen Menschen stattfinden. Damit sind diese Tätigkeiten gestaltbar, d. h., sie können als erweiterter Teil eines User-Centered-Design-Prozesses gesehen werden.

Keywords: /// Geschäftsmodelle /// Kundenzentrierte Entwicklung /// Nutzungskontext /// Design /// UCD

2. Bestandteile eines Geschäftsmodells Geschäftsmodelle bestehen immer aus mehreren Bausteinen, die untereinander in Beziehung stehen. Mindestens vorhanden ist der Hersteller und der Käufer, je nach Ausprägung und Intention des Geschäftsmodells kann es hier beliebig komplex werden. Osterwalder und Pigneur (2011) schlagen zum Zweck der Diskussion und Entwicklung eines Geschäftsmodells vier Komponenten vor, welche aus insgesamt neun Bausteinen bestehen. In der Praxis haben sich diese Komponenten als Einstieg für den kreativen Gestaltungs- und Moderationsprozess eines Geschäftsmodells bewährt. 3. Angebot und Nutzenversprechen Hier wird beschrieben, welche Produkte und Services Teil des Geschäftsmodells sind. Danach wird diskutiert, welchen Mehrwert und Nutzen sie für ein oder mehrere Kundensegmente haben können. Dies ist der zentrale Teil eines Geschäftsmodells. Ohne einen wirklichen Nutzen werden sich auch keine Nutzer finden lassen.


Usability Professionals 2012 Tutorials

Kunde

Diese Komponente definiert die verschiedenen Gruppen von Menschen oder Organisationen, die ein Unternehmen erreichen und bedienen möchte. Weiterhin wird erörtert, wie der/die Kunde/n erreicht werden sollen und welche Art von Beziehung mit den Kunden eingegangen werden soll. Infrastruktur

Die Komponente Infrastruktur beschreibt die wichtigsten Aktivposten, die ein Unternehmen hat und die es für das Geschäftsmodell in irgendeiner Weise nutzen möchte. Dazu gehören entsprechend auch etwaige Partner, Zulieferer oder auch Konkurrenten, die alle durch ihr Verhalten Einfluss auf das Geschäftsmodell nehmen können. Finanzen

Wie viel Geld von den Kundensegmenten eingenommen werden kann und wie viel für die Erstellung des Angebots ausgegeben wird, repräsentieren die finanzielle Komponente. Als Einstieg in die Diskussion und Ideenfindung eignet sich der von Osterwalder und Pigneur vorgeschlagene Businesss Modell Canvas. Es wird mit den neun Bausteinen eine flexible, minimale Struktur angeboten die in Iterationen aufgefüllt werden kann. [Abb. 1] Man kann Geschäftsmodelle sehr gut als Externalisierung der Geschäftsstrategie verstehen. Sie beschreiben die verschiedenen Beziehungen und Abhängigkeiten, die ein Unternehmen mit den verschiedenen Akteuren innerhalb eines Ökosystems / Wertschöpfungsnetzwerkes hat (Sorbaka & Nenonen, 2010). In diesem Sinne sind sie also die Verbindung, die zwischen dem Unternehmen und dem Ökosystem der Zulieferer, Partner, Konkurrenten, Konsumenten und der Infrastruktur besteht. Natürlich sind Geschäftsmodelle noch von einer ganzen Reihe weiterer externer und interner Faktoren abhängig, wie zum

Abb. 1. Business Model Canvas (Osterwalder & Pigneur 2011)

Beispiel dem ordnungspolitischen Rahmen, sozialen Normen oder auch internen, organisationsspezifischen „Do’s and Don’ts“. Diese bilden den Rahmen und die Barrieren für die weitere Entwicklung. 3. Nutzerzentrierte Geschäftsmodelle „Geschäftsleute müssen Designer nicht nur besser verstehen; sie müssen Designer werden.“ Dieses Zitat von Roger Martin, aktuell Dekan der Rotman School of Management in Toronto (Zitat aus Osterwalder und Pigneur, 2011), verdeutlicht den Umbruch von einer organisationszentrierten Gestaltung hin zu einer kundenzentrierten Gestaltung von Geschäftsmodellen. Bei der organisationszentrierten Gestaltung wird eher gefragt, –– was man dem Kunden verkaufen kann –– welche Kanäle am effizientesten eingesetzt werden können –– welche Beziehungen zu den Kundengruppen aufgebaut werden können etc.

Diese Fragen werden bei der Kundenzentrierten Gestaltung natürlich auch noch gestellt, vorher wird aber gefragt: –– Welche Aufgaben / Vorhaben haben unsere Kunden und was kann dabei unterstützen? –– Welche Ansprüche an sich selbst und ihre Umwelt haben unsere Kunden? Wie können wir bei ihrer Erfüllung behilflich sein? –– Wie möchten unsere Kunden angesprochen werden? Wie passt unser Unternehmen am besten in den Alltag unserer Kunden? Welche Auswirkungen hat dies auf den Alltag? –– Welche Art von Beziehungen erwarten unsere Kunden, welche können positive oder negative Auswirkungen auf den Alltag, die Aufgaben oder Ansprüche haben? –– Für was, das heißt für welche Werte, sind unsere Kunden wirklich bereit zu zahlen? Hier ergeben sich sehr schöne Parallelen zur Analysephase des Benutzerzentrierten Gestaltungsprozess. Sei es in Nutzungskontextanalysen, Tagebuchstudien, Fokusgruppen oder ähnlich strukturiertem

19


qualitativen Dialog mit dem Konsumenten: Wir als Usability Professionals/User Experience Designer sitzen direkt an der Quelle, um zentralen Input für kundenzentrierte Geschäftsmodelle zu liefern.

und den Unternehmer bei seiner Produkt-/ Serviceerstellung zu unterstützen. Dadurch wird das Risiko eines falschen Geschäftsmodells gesenkt und sowohl Kunde als auch Unternehmer profitieren.

Im weiteren Verlauf der GeschäftsmodellEntwicklung ist dann eher die gestalterische und später die Moderationskompetenz gefragt.

Henry Chesbrough, Direktor des “Center for Open Innovation” der University of Berkely sagt hierzu:

Visualisierung oder Szenarien, um zum Beispiel den Mitarbeiter des Herstellers an der Entwicklung teilhaben zu lassen und mit ihrer Fachkompetenz neue Ideen zu generieren können als Design Methoden eingesetzt werden. Da der Hersteller sicher die beste Kenntnis über Infrastruktur, Finanzen und andere Produkteigenschaften hat, sollte hier der UxD das Visualisieren von Zusammenhängen und das Ermöglichen neuer Perspektiven fokussieren. Szenariotechniken wiederum machen komplexe Zusammenhänge allen an der Entwicklung Beteiligten verständlich– und halten gleichzeitig die Kundenzentrierung aufrecht.

“[…] technology by itself has no single objective value. The economic value of a technology remains latent until it is commercialized in some way via a business model.” (2006, p. 64) Literatur 1. Osterwalder, A., Pigneur, Y. (2011): Business Model Generation. Deutsche Auflage, Campus Verlag. 2. Nenonen, S., Storbacka, K. (2010): Business Model Design: Conceptualizing Networked Value Co-Creation, International Journal of Quality and Service Sciences, Vol. 2 Iss: 1, pp.43– 59. 3. Casadesus-Masanell, R., Ricart, J.E. (2011): How to Design a Winning Business Model. Harvard Business Review 89, pp. 100–107.

Geschäftsmodelle sind natürlich flexible, quasi lebende Objekte, die unterschiedlichen Interessen durch die beteiligten Personen unterliegen. Hier kann der UxD die Fähigkeit zur Moderation und wiederum zum Erkennen neuer Perspektiven einsetzen. Beispielsweise erarbeitet er in Workshops mit Konsumenten und Herstellern, was denn der wirkliche Nutzen eines Produktes ist, ob es mit einer Veränderung noch anderen Nutzen stiften könnte etc. Hersteller und Zulieferer können sich mit Hilfe eines Moderators klar machen, in welcher Beziehung sie sich gerade befinden, und wo zum beiderseitigen Nutzen noch Potenzial besteht. 4. Ausblick In vielen Bereichen ist der Nutzer auch gleichzeitig der (potenzielle) Käufer. Im Zuge des benutzerzentrierten Gestaltungsprozesses erfahren wir viel über diesen Käufer, ohne dass es uns bewusst wird. Es gilt, sich dieses Wissen nutzbar zu machen

20

4. Shafer, S.M., Smith, J.E., Linder, J.E. (2005): The Power of Business Models. Business Horizons, Volume 48, Issue 3, May–June 2005, pp. 199–207. 5. Chesbrough, H.M. (2006): Open Innovation – The New Imperative for Creating and Profiting from Technology. Harvard Business Press.


Usability Professionals 2012 Tutorials

21


Von der Idee zum Prototypen Werkzeuge für die agile Welt

Eva-Maria Holt 7P Solutions & Consulting AG Calor-Emag-Straße 1 40878 Ratingen eva-maria.holt@7p-group.com

Dominique Winter GreenPocket GmbH Siegburger Str. 215 50679 Köln dominique.winter@greenpocket.de

Abstract Damit in agilen Entwicklungsprojekten, basierend auf einer Idee, ein nutzerzentrierter Low-Fidelity Prototyp entwickelt werden kann, bietet es sich an, die Idee zunächst zu einer Vision zu konkretisieren. Hierbei handelt es sich um einen iterativen Prozess, für den im Human Centered Design unterschiedliche Werkzeuge zur Verfügung stehen. Der vorliegende Beitrag stellt eine Auswahl von Werkzeugen zur Konkretisierung der Vision vor, die sich in agilen Prozessen als Best Practices bewährt haben. Dabei werden konkrete Vorlagen und Einsatzmöglichkeiten für diese Werkzeuge erörtert.

1. Einleitung Zu Beginn eines Entwicklungsprojektes steht meist eine Idee zur Diskussion, ohne dass eine durchdachte Vision vorliegt. In diesem Zusammenhang wird der Begriff Vision als Beschreibung für die neue (Arbeits-)Umgebung des Benutzers verwendet. Sie kann sowohl mögliche Änderungen in der Technologie als auch funktionale und nicht-funktionale Anforderungen umfassen (Holtzblatt et al., 2005).

die weitere Entwicklung orientieren kann. Wenn Scrum verwendet wird, stellt die Visioning Phase den Sprint 0 dar. Dieser wird vorgelagert zum eigentlichen ScrumProzess durchgeführt (Beyer, 2010), um ausreichend vorbereitet mit der Entwicklung zu beginnen. [vgl. Abb. 1] Die Visioning Phase umfasst dabei drei wesentliche Aufgaben (vgl. Abbildung 1): Die Definition der Zielgruppe, die Definition des Nutzungskontextes und die Abgrenzung des Umfangs. Zur praktischen

Zur Einschätzung des Umfangs und der Risiken der Realisierung wird jedoch eine Konzeption auf Grundlage einer Vision benötigt, welche die notwendigen Features des späteren Softwareprodukts enthält und miteinander in Zusammenhang stellt. In der Praxis wird jedoch häufig ohne eine klare Vision mit der Entwicklung von Prototypen und ersten Programmbestandteilen begonnen. Damit bereits am Anfang der Produktentwicklung die Bedürfnisse und Erwartungen der späteren Benutzer berücksichtigt werden können, ist es sinnvoll, die Idee für ein Produkt zunächst in einer Visioning Phase zu einer Vision zu konkretisieren (Holtzblatt et al., 2005). Dadurch steht ein umfassendes Gesamtbild der Idee zur Verfügung, an dem sich

Abb. 1. Visioning Phase

22

Jörg Thomaschewski Hochschule Emden/Leer Constantiaplatz 4 26723 Emden joerg.thomaschewski@hs-emden-leer.de

Keywords: /// Scrum /// Human Centered Design /// Personas, Storyboards /// User Stories

Durchführung dieser Aufgaben bieten sich die aus dem User Centered Design bzw. dem Human Centered Design bekannten Werkzeuge Personas, Storyboards und Persona-driven User Stories an. Diese Zwischenergebnisse (Artefakte) unterstützen aufgrund ihrer visuellen Darstellung die Diskussion und das gemeinsame Verständnis innerhalb des Teams. Da sich Ergebnisse des einen Schrittes auf die Rahmenbedingungen der anderen auswirken, werden die Aufgaben iterativ wiederholt, bis ein zufriedenstellendes


Usability Professionals 2012 Tutorials

Im Folgenden werden die Werkzeuge zur Konkretisierung der Vision vorgestellt. 2.1. Personas Zur Definition der Zielgruppe stellt die Verwendung von Personas (Cooper et al., 2007) eine praktikable Lösung dar. Eine Persona stellt ein fiktives Modell eines Benutzers dar und repräsentiert diesen während des Entwicklungsprozesses. Anstatt selbstreferenzierte Annahmen über mentale Modelle des zukünftigen Benutzers als Basis für die Entwicklung zu verwenden, rücken die Bedürfnisse des Benutzers in den Fokus (Holt et al., 2011). Bei der Verwendung von Personas wird eine Teilmenge der gesamten Zielgruppe durch eine Persona konkretisiert. Dies hat den Vorteil, dass die Projektbeteiligten während der Entwicklung keine anonymen Mitglieder der Zielgruppe vor Augen haben, sondern eine konkrete Persona [vgl. Abb. 2].

Abb. 2. Vorlage Persona

Gesamtergebnis (Vision) vorhanden ist. Die Verwendung der Artefakte Personas, Storyboards und Persona-driven User Stories bieten dabei den Vorteil, dass Erkenntnisse dieser frühen Entwicklungsphase dokumentiert und somit nachhaltig für weitere Entwicklungsphasen festgehalten werden können. Auf Basis der Vision kann anschließend mit der Konzeption des neuen Produktes begonnen werden. 2. Werkzeuge für den Sprint 0 im Scrum-Prozess Agiles Projektmanagement basiert auf der Erkenntnis, dass ein Softwareentwicklungsprojekt zu Beginn nicht vollständig geplant werden kann. Ausgehend vom Agilen Manifest (Beck et al., 2001) sind mehrere Vorgehensmodelle, wie beispielsweise Extreme Programming oder Scrum, entwickelt worden. Scrum ist ein Rahmenwerk, das zur Durchführung eines agilen Projektmanagements eingesetzt werden kann. Das Rahmenwerk umfasst wenige Regeln und sieht eine geringe

Anzahl an Rollen vor. Aufgrund des überschaubaren Regelwerks lässt sich Scrum schnell erlernen. Den wichtigsten Vorteil von Scrum stellt die schnelle Anpassung des Vorgehens an sich ändernde Anforderungen dar (Friis et al., 2011). Eine Frage beim Einsatz von Scrum in der Praxis stellt sich bereits vor Beginn eines Projektes. Das Vorgehensmodell gibt weder Vorgaben in Bezug auf die Integration von User Centered Design-Methoden (Beyer, 2010) noch Hinweise darauf, wie Anforderungen für die Erstellung des Product Backlogs erhoben und priorisiert werden. Diese Probleme können behoben werden, indem ausgewählte Werkzeuge zum Einsatz kommen. In Analogie zum klassischen Requirements Engineering werden während des Sprint 0 konkrete Artefakte erstellt und im Laufe des gesamten Entwicklungsprozesses iterativ weiterentwickelt. Die Verwendung von definierten Artefakten bietet den Vorteil, dass Ideen und Erkenntnisse während der Laufzeit eines Projektes nicht verloren gehen und allen Projektbeteiligten zugänglich gemacht werden können.

Da in frühen Phasen der Produktentwicklung noch keine eindeutige Zielgruppe vorhanden ist, bietet es sich an, zunächst Ad-Hoc Personas (Norman, 2004) zu entwickeln. Diese werden gemeinsam vom Team entwickelt und können in späteren Phasen mit Daten aus Interviews und Recherchen zu realen Personas weiterentwickelt werden. Mit Hilfe einer geeigneten Vorlage [vgl. Abb. 2] können die gesammelten Informationen dokumentiert und weiteren Projektbeteiligten zugänglich gemacht werden. Die in Abbildung 2 dargestellte Vorlage zur Erstellung einer Persona fördert aufgrund ihrer strukturierten Darstellungsform das schnelle Erfassen der wichtigsten Punkte. Des Weiteren wird die Motivation zum Lesen der Inhalte durch die steckbriefartige Aufbereitung gesteigert. Die alleinige Erstellung von Personas sichert jedoch noch nicht die erfolgreiche Fokussierung auf die Bedürfnisse der Benutzer. Nicht jeder Projektbeteiligte versteht die Vorteile, die der Einsatz

23


dieser Methode mit sich bringt. Damit die Methode Personas erfolgreich in ein Projekt eingebunden werden kann, ist es notwendig, die entwickelten Personas bereits zu Projektbeginn im gesamten Team zu kommunizieren. Eine Möglichkeit zur erfolgreichen Einführung der Methode stellt die gemeinsame Entwicklung der Personas mit dem Projektteam dar (Blomquist und Arvola, 2002). Die nötigen Interviews und Recherchearbeiten in Bezug auf die Bedürfnisse und Merkmale zukünftiger Benutzer können durch den UX-Spezialisten durchgeführt werden. In kleiner Runde (z. B. Marketing, Produktmanagement und UX-Spezialisten) kann dann ein Satz relevanter Personas vorbereitet und anschließend mit dem gesamten Projektteam diskutiert werden.

Abb. 3. Vorlage Storyboard

24

Die Anzahl der für ein Projekt zu entwickelnden Personas hängt zum einem von dem Umfang des zu entwickelnden Produktes und zum anderen von dem Kontext, in dem die Personas verwendet werden, ab. In der Praxis hat sich die Entwicklung von drei bis sechs Personas bewährt (Pruitt und Grudin, 2003). Die Anzahl kann sich erhöhen, wenn Personas einfließen, die die Interessen verschiedener Stakeholder repräsentieren. Dies kann zum Beispiel eine Persona sein, die das Produkt zwar nicht direkt nutzt, aufgrund ihrer Entscheidungsbefugnis aber mit dem Kauf des Produktes und der Einführung im Unternehmen eine große Anzahl an Benutzern zur Nutzung bewegt. Damit die Personas während des Entwicklungsprozesses nicht in Vergessenheit

geraten, ist es notwendig, sie auf unterschiedliche Art und Weise im Projekt transparent zu machen. Grudin und Pruitt (2002) beschreiben hierfür mehrere Wege, wie beispielweise die Darstellung der Personas auf Postern, Flyern, Handouts und Give-aways. Empfehlenswert ist ebenso die Integration der Personas in weitere Artefakte, die in frühen Phasen der Produktentwicklung entstehen. Eine Möglichkeit dessen stellt z. B. der Einsatz von Personas in Persona-driven User Stories (Winter et al., 2012) dar. Des Weiteren können Personas direkt in das Product Backlog integriert werden (Innes, 2012). Das Product Backlog besteht aus einer Liste von priorisierten User Stories, die der Product Owner auf dem aktuellen Stand hält. Die Integration der


Usability Professionals 2012 Tutorials

Personas kann vorgenommen werden, indem im Product Backlog die Verbindung zwischen User Stories und Personas hinzugefügt wird. Diese Zuordnung lässt einen Rückschluss darauf zu, wie häufig eine Funktionalität von den Zielgruppen verwendet wird (vgl. Innes, 2012). Der Product Owner kann diese Information verwenden, um die Priorisierung der User Stories unter Berücksichtigung der Benutzergruppen (Cooper et al., 2007) durchzuführen. 2.2. Storyboards Storyboards beschreiben auf eine abstrakte Art und Weise, wie ein Benutzer zukünftig seine Aufgaben erledigen wird. Sie bestehen aus einzelnen Sequenzen von Bildern, die eine Abfolge der Arbeitsschritte visualisieren. Diese muss ein Benutzer erledigen, um seine Aufgabe erfolgreich zu beenden. Dabei können sie sowohl manuelle Schritte als auch grobe Komponenten des Softwareprodukts umfassen (Holtzblatt et al., 2005). Storyboards beinhalten keine detaillierte Darstellung des Interfacedesigns, sondern visualisieren den Ablauf der Arbeit eines Benutzers. Demzufolge kann ein Storyboard neben der Nutzungssituation auch Arbeitsschritte visualisieren, die unabhängig von einem Produkt sind. Des Weiteren fördert die Verwendung von Storyboards im Vergleich zu textuell beschriebenen Szenarien das visuelle Denken und regt somit den Kreativprozess an (Branham et al., 2007). Anhand von Storyboards lässt sich der Nutzungskontext somit visuell darstellen. Nach der ISO 9241-210:2010 ist der Nutzungskontext durch „Benutzer, Arbeitsaufgaben, Ausrüstung (Hardware, Software und Materialien) sowie die physische und soziale Umgebung, in der das Produkt genutzt wird.“ definiert (ISO 9241-210:2010). [Abb. 3] Da bei einem Storyboard der Benutzer samt seinen Emotionen und Aufgaben im Fokus steht, ist die Zuordnung eines Storyboards zu einer Persona naheliegend. Falls ein Storyboard mehreren Personas

zugeordnet werden kann, sollte überprüft werden, ob die Anzahl der Personas korrekt ist oder ob mehrere Personas mit gleichen Aufgaben zu einer Persona zusammengeführt werden sollten. Abb. 3 zeigt eine Vorlage für ein Storyboard. Die Vorlage ist in drei Bereiche geteilt: In der oberen Hälfte können Informationen in Bezug auf die zugehörige Persona (hier: „Emma“) und den Titel des Storyboards eingetragen werden. In der rechten Ecke befinden sich Icons, die zur Beschreibung der physischen Umgebung genutzt werden können. Der mittlere Bereich ist für Sketches vorgesehen, die einen Ablauf von Arbeitsschritten visualisieren. Im unteren Bereich der Vorlage können Do-Goals und Be-Goals eingetragen werden. Damit in frühen Phasen der Produktentwicklung die hedonische Qualität (Hassenzahl und Roto, 2007) mit einbezogen werden kann, ist es wichtig die Be-Goals zu berücksichtigen und den Fokus nicht ausschließlich auf die Do-Goals zu legen. Die Erfüllung von BeGoals wird durch Attribute wie z. B. schön, originell und cool signalisiert und fördert die emotionale Bindung des Benutzers zum Produkt. Im Vergleich hierzu deuten Attribute wie z. B. leicht, durchschaubar und vorhersagbar auf die Erfüllung von Do-Goals hin (Hassenzahl und Roto, 2007). Die Erfassung der notwendigen Arbeitsaufgaben kann mit Hilfe von Beobachtungen, Interviews und Dokumentenanalysen erfolgen. Dabei ist es wichtig festzustellen, welche Aufgaben wirklich im Fokus des Produkts stehen werden und welche nicht. Hardware, Software und Materialien beschreiben die produktexternen Komponenten, welche nicht vom Softwareproduktanbieter bereitgestellt werden. Darunter fallen das Zielsystem (Hard- und Software) sowie weitere Materialien, beispielsweise Büromaterialien. Die Berücksichtigung der physischen Umgebung ist dahingehend wichtig, da es entscheidende Unterschiede bezüglich der Anforderungen an die Interaktionsschnittstellen gibt. Wird ein Produkt zum Beispiel draußen eingesetzt, können hohe Kontrast-Anforderungen bestehen, damit die dargestellten Informationen auch

bei Gegenlicht oder schlechter Beleuchtung einfach abgelesen werden können. Um die zuvor genannten Eigenschaften in ihren jeweiligen Ausprägungen zu erfassen, bieten sich eine morphologische Analyse und die Erstellung eines morphologischen Kastens an (Hauschildt und Salomo, 2011). Die Kreativitätstechnik der morphologischen Analyse kann zur Generierung multipler Alternativen genutzt werden. Hierfür werden alle Parameter (Benutzer, Arbeitsaufgaben, Hardware, Software, Materialien, physische Umgebung und soziale Umgebung) durch eine Auflistung der jeweils möglichen Ausprägung ermittelt und in Form eines morphologischen Kastens visualisiert. Durch den Einsatz des morphologischen Kastens werden die verschiedenen Kombinationsmöglichkeiten klarer visualisiert. Dadurch können diejenigen Kombinationen ausgewählt werden, die für das zu entwickelnde Produkt relevant erscheinen. Für je eine Auswahl der Kombinationen wird anschließend ein Storyboard erstellt. Zu diesem Zweck lassen sich die einzelnen Eigenschaften für die Darstellung in den Storyboards durch Sketching (Greenberg et al., 2012) erarbeiten. Durch die Eigenschaft der Ungenauigkeit (Buxton, 2008) ermöglicht das Sketching es, gerade für Darstellungen der Eigenschaften des Nutzungskontextes, kreativ und innovativ an die Ermittlung der Ausprägungen heranzugehen. Mittels Sketching können in einem Kreativprozess sehr einfach und kostengünstig mehrere Elemente für die Storyboards entwickelt werden (Patton, 2008). Diese bieten den Vorteil, dass Ideen gegeneinander abgewogen werden können und in einer Diskussion die bestmögliche Alternative weiter ausgestaltet wird. Anschließend kann diese zu einem Storyboard ausgearbeitet werden. Die grafische Darstellung eines Storyboards hilft, technische Details für alle Projektbeteiligten leichter verständlich zu machen und somit Sprachbarrieren zu verringern (Kühn et al., 2011), die durch unterschiedliche (Domänen-)Sprachen auftreten können. Insbesondere in internationalen Teams

25


Um die Verbindung zwischen User Story und zukünftigen Benutzern zu stärken, empfiehlt sich der Einsatz von Personadriven User Stories. Diese zeichnen sich dadurch aus, dass anstelle der Rolle eine Persona als Benutzer integriert wird (Cohn, 2004). Dadurch werden die Bedürfnisse des Anwenders von der Ermittlung der Zielgruppe bis zur Definition des Umfangs eingebracht (Winter et al., 2012). [Abb. 4] In Abb. 4 ist eine Vorlage einer Personadriven User Story dargestellt. In der oberen Hälfte befinden sich die folgenden allgemeinen Informationen: –– Persona, die eine beschriebene Funktionalität nutzt (hier: „Emma“) –– Zuordnung der User Story zu einem Storyboard (hier: „Emma bestellt über ihren Kühlschrank Eis“) –– Textuelle Beschreibung der User Story –– Der Business Value ist der Geschäftswert einer User Story und beschreibt den Zugewinn am Wert des Produkts durch diese Story (Gloger, 2011). Die Gegenüberstellung von Story Points und Business Value ermöglicht eine Aussage, wie mit geringem Aufwand eine maximale Wertsteigerung des Produktes erreicht werden kann. Dies ist für die Priorisierung des Product Backlogs von großer Bedeutung. Abb. 4. Vorlage Persona-driven User Story

sind Storyboards daher geeignet, um ein gemeinsames Verständnis der zukünftigen Abfolge der Arbeitsschritte zu fördern. 2.3. Persona-driven User Stories Eine Abgrenzung des Produktumfangs kann durch den Einsatz von User Stories vorgenommen werden. Eine User Story beschreibt die Funktionalität aus der Sicht des Benutzers (Wirdemann, 2011). Sie besteht zum einen aus einer textuellen Beschreibung, die für Planungen und als Erinnerung genutzt wird. Ein weiterer Bestandteil ist die Diskussion über die

26

Details der Umsetzung und Rahmenbedingungen und schließlich die Akzeptanzkriterien, die beschreiben, wann die Story abgenommen werden kann und wann nicht (Cohn, 2004). Besonders durch die Diskussion zwischen dem inhaltlich Verantwortlichen (z.B dem Product Owner) und dem Entwicklerteam wird die User Story detailliert und präzisiert. So entstehen die Akzeptanzkriterien gemeinschaftlich, um ein gemeinsames Verständnis über den Umfang der User Story zu bekommen. Dadurch wissen alle Beteiligten, was diese Story beinhaltet und welche Ziele erreicht werden sollen (Nazzaro und Suscheck, 2010).

Auf der unteren Hälfte der Vorlage befinden sich die Details der User Story. Hierzu gehören: –– Akzeptanzkriterien, die zusammen mit der „Definition of Done“ für die Abnahme der User Story wichtig sind –– Story Points, mit denen eine Bewertung des Aufwandes dargestellt wird –– Abhängigkeiten von weiteren User Stories


Usability Professionals 2012 Tutorials

3. Fazit

6. Cohn, M. (2004): User stories applied.

Damit in agilen Entwicklungsprojekten eine Idee zu einer Vision konkretisiert werden kann, ist es sinnvoll, einen Sprint 0 vor dem ersten Entwicklungssprint durchzuführen. In diesem Sprint 0 wird eine Visioning Phase durchgeführt, die als Ergebnis die Vision des zu entwickelnden Softwareproduktes hervorbringt. Die Visioning Phase umfasst drei Aufgaben, die unter Zuhilfenahme der aus dem Human Centered Design bekannten Vorgehensweisen erledigt werden können: –– Definition der Zielgruppe mit Personas –– Definition des Nutzungskontextes mit Storyboards –– Abgrenzung des Umfangs mit Personadriven User Stories

7. Cooper, A., Reimann, R., & Cronin, D. (2007).

For agile software development. Boston: Addison-Wesley. About face 3. The Essentials of Interaction Design. Indianapolis: Wiley. 8. Friis, D., Ostergaard, J. & Sutherland, J. (2011). Virtual Reality Meets Scrum: How a Senior Team Moved from Management to Leadership. In: 44th Hawaii International Conference on System Sciences. 9. Gloger, B. (2011). Scrum. Produkte zuverlässig

User Stories? SrumAlliance. Indianapolis. 20. Norman, D. (2004). Ad-Hoc Personas & Empathetic Focus. 21. Patton, J. (2008). Consider multiple solutions. In: Software, IEEE 25 (5), 72–73. 22. Pruitt, J., & Grudin, J. (2003). Personas: Practice and Theory. In: Proceedings of the 2003 conference on Designing for user experiences, 1–15. 23. Winter, D., Holt, E.-M., & Thomaschewski, J. (2012). Persona driven agile development. Build up a vision with personas, sketches and

und schnell entwickeln. 3. Aufl. München:

persona driven user stories. In: Proceedings

Hanser, Carl.

of the 7th Conference on Information

10. Greenberg, S., Carpendale, S., Marquardt,

Systems and Technologies (CISTI).

N., & Buxton, B. (2012). Sketching user

24. Wirdemann, R. (2011). Scrum mit User

experiences. The workbook. San Francisco:

Stories. 2., erweiterte Auflage. München:

Morgan Kaufmann.

Hanser, Carl.

11. Grudin, J., & Pruitt, J. (2002): Personas, Participatory Design and Product Development: An Infrastructure for

Im Rahmen dieses Artikels konnten Vorund Nachteile der einzelnen Werkzeuge zur Erstellung der Artefakte (Personas, Storyboards, Persona-driven User Stories) erläutert werden. Des Weiteren sind sowohl Vorlagen zur Erstellung der Artefakte vorgestellt als auch praktische Einsatzmöglichkeiten zur Einbindung dieser Artefakte aufgezeigt worden.

Engagement. In: The Participatory Design Conference, Malmö, Schweden, 144–161. 12. Hauschildt, J., & Salomo, S. (2011): Innovationsmanagement. 5. Aufl. München: Vahlen. 13. Hassenzahl, M., & Roto, V. (2007): Being and doing. A perspective on User Experience and its measurement. In: Interfaces 72, 10–12. 14. Holt, E.-M., Winter, D., & Thomaschewski, J. (2011). Personas als Werkzeug in modernen

Literatur

Softwareprojekten. Die Humanisierung

1. Beck, K., Beedle, M., van Bennekum, A.,

des Anwenders. In: Henning Brau, Andreas

Cockburn, A., Cunningham, W., Fowler, M.

Lehmann, Kostanija Petrovic und Matthias

et al. (2001). Manifesto for Agile Software

C. Schroeder (Hrsg.): Usability Professionals

Development.

2011. Chemnitz. German UPA. Stuttgart,

2. Beyer, H. (2010). User-centered agile methods. San Francisco, Calif: Morgan & Claypool. 3. Blomquist, Å., & Arvola, M. (2002). Personas in action: ethnography in an interaction design team. In: Proceedings of the second Nordic conference on Human-computer interaction, 197–200. 4. Branham, S. M., Wahid, S., & McCrickard, D. S. (2007). Channeling Creativity: Using

40–44. 15. Holtzblatt, K., Wendell, J. B., & Wood, S. (2005). Rapid contextual design. A how-to guide to key techniques for user-centered design. San Francisco: Elsevier/Morgan Kaufmann. 16. Innes, J. (2012). Integrating UX into the Product Backlog. The User Experience Integration Matrix. 17. ISO 9241-210:2010, 2011: Ergonomie der

Storyboards and Claims to Encourage

Mensch-System-Interaktion – Teil 210:

Collaborative Design. In: Workshop on Tools

Prozess zur Gestaltung gebrauchstauglicher

in Support of Creative Collaboration (part of Creativity & Cognition 2007), 1–4. 5. Buxton, B. (2008). Sketching user experiences. Getting the design right and the right design. 3. printing. Amsterdam: Morgan Kaufmann.

interaktiver Systeme. Berlin: Beuth. 18. Kühn, R., Keller, C., & Schlegel, T. (2011). From Model-Based Storyboards to ContextAware Interaction-Cases. In: i-com 10 (3), 12–18. 19. Nazzaro, W. F., & Suscheck, C. (2010). New to

27


Dem UX-Professional zugeworfene Themen gekonnt auffangen: HCD-Aktivitäten maßschneidern Knut Polkehn artop GmbH – Institut an der Humboldt-Universität Berlin Christburger Str. 4 10405 Berlin polkehn@artop.de

Jens Hüttner artop GmbH – Institut an der Humboldt-Universität Berlin Christburger Str. 4 10405 Berlin huettner@artop.de

Abstract UX-Professionals sind in unterschiedlichster Art und Weise an der Entwicklung interaktiver Produkte, Systeme oder Dienstleistungen beteiligt. Eine häufige Ausgangssituation ist der Auftrag „mal eben Usability zu machen“, eine konkrete Methode anzuwenden („sollten wir nicht einen Test machen“, „müssen wir Personas erstellen“, …) oder sich zu einem Thema aus UX-Sicht zu äußern. Die Argumentation für oder gegen eine bestimmte UX-Aktivität, die Auswahl einer Methode oder die Planung eines menschzentrierten Vorgehens fällt vielen UX-Professionals schwer. Erst recht, weil wichtige Rahmenbedingungen zu bedenken sind – von den Anforderungen strategisch wichtiger Stakeholder, über verfügbare Ressourcen, bis zur Notwendigkeit, die Ergebnisse eigener Arbeit in Entwicklungsprozesse zu integrieren. Im Tutorial sollen die Teilnehmer befähigt werden, hinter einem Auftrag die eigentliche Fragestellung zu entdecken und für diese ein menschzentriertes Vorgehen festzulegen, welches die gewünschte Antwort auf eine passende Art und Weise geben kann, welche weder von eigenen Methodenpräferenzen, noch den unscharfen Vorgaben des Auftraggebers dominiert wird. Nach einer Einführung in die dazu notwendigen Konzepte werden HCD-Vorgehensweisen für verschiedene Teilnehmer-Fragestellungen erarbeitet und diskutiert. Dabei steht nicht die Lösung selbst, sondern das Vorgehen im Mittelpunkt, um einen Transfer in den eigenen Arbeitsalltag zu ermöglichen.

1. Einführung

Aber worauf kommt es an, wovon hängt die Antwort ab?

Wir wissen aus unserer Arbeit sowohl in Beratungsprojekten als auch in der Aus- und Weiterbildung von UX-Professionals, die in den verschiedensten Rollen und Branchen unterwegs sind, das die Sicherheit im eigenen Handeln immer wieder hinterfragt wird. –– Welche Methode soll ich einsetzen? –– Welches Buch sollte ich unbedingt kaufen? –– Welches Vorgehensmodell welchen Autors ist zu empfehlen? –– Muss man nicht immer Personas und Szenarien entwickeln? –– …

Vor allem hängt das eigene sichere professionelle Handeln von einer Reihe von Rahmenbedingungen ab, die die Arbeitswelt von UX-Professionals maßgeblich beeinflussen: 1. Für welche Art von technischer Umgebung soll die User Experience optimiert werden? Es macht einen Unterschied ob es sich um komplexe technische Systeme (z. B. das UI zur Steuerung einer chemischen Anlage), um Einzelgeräte (z. B. eine Uhr oder ein Handy) oder den webbasierten Zugriff auf Services (z. B. eine Fahrplanauskunft) handelt. 2. In welchem Anwendungsbereich erfolgt die Benutzung von interaktiven Systemen, Produkten oder Services? Es macht einen Unterschied, ob die

Als Antwort auf diese Fragen muss man häufig auf das schon so lange bekannte „it depends“, „es kommt darauf an“, ausweichen.

28

Keywords: /// menschzentriertes Design /// Perspektiven /// Methoden /// Konzeptarbeit /// Professionalität

User Experience für Anwender oder Anbieter in/für private Kontexte oder für professionelle Verwender optimiert werden muss. Über welche Domain-Expertise hinsichtlich privater, gewerblicher oder industrieller Anwendungsbereiche muss der UX-Professional für eine gute Arbeit verfügen? 3. Mit welchen Professionen wird gemeinsam an der Optimierung der User Experience gearbeitet? Es macht einen Unterschied, ob mit Ingenieuren, Informatikern, Designern, Psychologen, Produktmanagern, Betriebswirtschaftlern, … an der Optimierung der User Experience gearbeitet wird. Welche (Fach-) Sprache wird gesprochen? Welche unterschiedlichen Grundannahmen über erfolgreiche Produktgestaltung bestehen?


Usability Professionals 2012 Tutorials

4. Was ist der Ausgangspunkt in einem konkreten UX-Projekt? Es macht einen Unterschied, ob ein interaktives Produkt, System oder Service neu „auf der grünen Wiese“ entwickelt wird, ob es um eine Erweiterung des Funktionsund Informationsangebots oder um ein Redesign des UIs auf Basis des Bestehenden geht. Lassen sich neue Funktionen mit bestehenden UI-Konzepten abbilden? Müssen neue Lösungen und entsprechende Patterns entwickelt werden? Erzeugen neue Konzepte neue technische Anforderungen? 5. In welcher Konstellation wird das UX-Projekt bearbeitet? Es macht einen Unterschied, in welcher Projektkonstellation die Beauftragung und Umsetzung eines UX-Projekts stattfindet. Wer ist der interne oder externe Auftraggeber? Wer ist der Sponsor des Projekts? Werden weitere Dienstleister eingebunden? Wo sitzt die Projektleitung? Wie kann man sich abstimmen? Welche Anforderung anderer Stakeholder gibt es? Welche zeitlichen, finanziellen und personellen Ressourcen stehen zur Verfügung? Wie sehen die Schnittstellen zu anderen Prozessen (z. B. Innovationsmanagement, Systementwicklung, Geschäftsmodellentwicklung, …) aus? Diese Fragestellungen sind es, welche in der täglichen Arbeit beachtet werden müssen. Abbildung 1 zeigt sehr eindrucksvoll, welche Herausforderungen sich für Usability-Professionals daraus ergeben. Sie wurde dem Abschlussbericht des BMWi-Projekts „Usability in Germany“ (Woywode et al., 2012) entnommen, in welchem mögliche Ausprägungen des Arbeitsumfelds von Usability-Professionals anhand eines eigenen, aus der Literatur abgeleiteten, Reifegrad-Modells beschrieben und anschließend die Ergebnisse von Interviews in kleinen und mittleren Unternehmen (KMUs) in Deutschland zugeordnet wurden.

Abb. 1. Ist-Situation der Usability-Reife in der deutschen Softwareindustrie (nach Woywode et al., 2012)

Auch wenn sich die Ergebnisse der Studie in KMUs nicht auf alle Unternehmen übertragen lassen (haben doch viele größere Unternehmen schon lange Anstrengungen zur Etablierung von UX unternommen), so wissen wir, dass die sehr heterogenen Ausprägungen nach wie vor typisch für viele Unternehmen sind. Gibt es interne UX-Experten, so gibt es nicht immer die passenden Projektbudgets oder umgekehrt. Gibt es interne UX-Experten und Projektbudgets für UX, fehlt häufig die Zeit für vorgelagerte Gestaltungsaufgaben. Mit den Möglichkeiten und Beschränkungen sinnvoll umzugehen, stellt eine große Herausforderung für UX-Professionals dar, die so häufig in der Frage nach der Methode oder dem Buch resultiert. [Abb. 1] Um als UX-Professional souverän und sicher mit den geschilderten Herausforderungen umgehen zu können, halten wir die Kenntnis und das Verständnis der im folgenden Abschnitt dargestellten Perspektiven für sehr wichtig, um ein eigenes Vorgehen gezielt maßschneidern zu können.

Im Tutorial werden diese Perspektiven als Basis der Bearbeitung eigener Fragestellungen eingeführt. 2. Perspektiven 2.1. User Experience auf Basis menschzentrierten Designs Als wichtige Voraussetzung für das Erzielen einer hohen Qualität hinsichtlich der Qualitätsmerkmale Usability und User Experience wird im Tutorial das menschzentrierte Design nach DIN EN ISO 9241/210 eingeführt und diskutiert. Grundsätze menschzentrierten Designs: –– die Gestaltung beruht auf einem umfassenden Verständnis der Benutzer, Arbeitsaufgaben und Arbeitsumgebungen –– die Benutzer sind während der Gestaltung und Entwicklung einbezogen

29


–– den Usability Engineering Prozess organisieren (überwachen und steuern) Für jedes Handlungsfeld sind im aktuell herausgegebenen „German UPA Qualitätsstandard Usability Engineering“ (Behrenbruch et al., 2012) mindestens notwendige Aktivitäten beschrieben und zu beteiligende professionelle Rollen (siehe auch Bogner et al., 2011) zugeordnet. Damit ist ein UX-Professional prinzipiell in der Lage, die für ihn relevanten Handlungsfelder sowie die zu einem bestimmten Projektstatus notwendigen Aktivitäten zu identifizieren. 2.2. Gegenstand menschzentrierten Designs: iterative konzeptuelle Arbeit

Abb. 2. Menschzentrierte Gestaltungsaktivitäten (DIN EN ISO 9241-210)

–– das Verfeinern und Anpassen von Gestaltungslösungen wird fortlaufend auf der Basis benutzerzentrierter Evaluierung vorangetrieben –– der Prozess ist iterativ –– bei der Gestaltung wird die gesamte User Experience berücksichtigt –– im Gestaltungsteam sind fachübergreifende Kenntnisse und Perspektiven vertreten Ausgehend von den Grundsätzen menschzentrierten Designs wird in der DIN EN ISO 9241-210 ein Referenzmodell zur Gestaltung gebrauchstauglicher interaktiver Produkte, Systeme oder Services definiert. [Abb. 2] Der im Referenzmodell beschriebene idealtypische Prozess lässt sich mit verschiedenen Schwerpunkten in vielen der in der Literatur beschriebenen Vorgehensmodellen wiederfinden, von „Usability Engineering Lifecycle“ (Mayhew, 1999), über „Usability Engineering: scenariobased development of human-computer interaction“ (Rosson & Carroll, 2002), „The Elements of User Experience“ (Garrett,

30

2002), bis hin zum „Usability Leitfaden“ (DAkkS, 2010). Unterscheidbar sind die Vorgehensmodelle vor allem hinsichtlich der für UX-Professionals schwerpunktmäßig empfohlenen Aktivitäten und den dafür vorgeschlagenen Methoden. Im Arbeitskreis „Qualitätsstandards“ der German UPA (Geis et al., 2010) wurden basierend auf dem Referenzmodell acht Handlungsfelder von Usability Professionals identifiziert: –– Planung der menschzentrierten Gestaltung –– den Nutzungskontext verstehen und beschreiben –– die Nutzungsanforderungen spezifizieren –– Gestaltungslösungen entwerfen, die die Nutzungsanforderungen erfüllen –– Gestaltungslösungen aus der Benutzerperspektive evaluieren und verwerten –– das Produkt bei den Benutzern einführen –– Langzeitbeobachtungen

Im Tutorial wird eingeführt, dass die Iteration durch eine Anzahl von Konzeptaufgaben der zentrale Gegenstand menschzentrierten Designs ist. Jede Konzeptaufgabe kann jedoch nur auf Basis von erhobenen Anforderungen optimal erledigt werden. Das Ergebnis der Konzeptarbeit muss gegen die Anforderungen bewertet werden (Prinzip iterativen Arbeitens). Ausgehend vom Modell „The Elements of User Experience“ von Garret (2002) werden folgende Konzeptaufgaben unterschieden: –– Spezifikation der späteren Nutzung (Nutzungskonzept) –– Spezifikation der Anwendungsfunktionen (Funktionsangebot) –– Spezifikation der Inhalte (Informationsangebot) –– Spezifikation der Interaktionsprinzipien (Interaktionskonzept) –– Spezifikation der Strukturierung von Information (Informationsarchitektur) –– Spezifikation der Darstellung von Information (Informationsdesign) –– Spezifikation von Oberflächen (Interfacedesign) –– Spezifikation der Navigation (Navigationsdesign) –– Spezifikation des visuellen (sensorischen) Layouts (visuelles Design)


Usability Professionals 2012 Tutorials

Unabhängig davon, wie viele Iterationen gemacht werden – es wird zu jeder Konzeptaufgabe eine Entscheidung getroffen. Manchmal explizit, manchmal auch nur implizit – irgendjemand (im Zweifelsfall der Entwickler) trifft eine konzeptuelle Entscheidung. Die konzeptuelle Entscheidung ist umso besser, je klarer die Anforderungen an die Konzeptaufgabe sind. Ausgangspunkt von Konzeptarbeit sind die aus dem Verstehen des Nutzungskontextes abgeleiteten Nutzungsanforderungen. Jede konzeptuelle Entscheidung kann neue Anforderungen an weitere Konzeptaufgaben stellen. Iteratives Vorgehen heißt Anforderungen an ein Konzept zu erheben, ein passendes Konzept zu entwickeln und das Konzept hinsichtlich der Anforderungen (Nutzungsanforderungen und weitere konzeptuelle Anforderungen) zu bewerten.

menschzentrierten Designs (DIN EN ISO 9241-210) ist ein guter Ausgangspunkt, um die Qualitätsmerkmale Usability und User Experience zu berücksichtigen. Im Alltag eines UX-Professionals spielen jedoch nicht nur die auf die Benutzer ausgerichteten Qualitätsziele eine Rolle, sondern es sind gleichermaßen die Ziele anderer Beteiligter, im Sinne von weiteren Anforderungen und Rahmenbedingungen, zu berücksichtigen. [Abb. 3] Für eine hohe Qualität interaktiver Produkte, Systeme oder Services müssen die Ziele der verschiedenen Interessengruppen Business, Technologie und Mensch in Übereinstimmung gebracht werden. Der UX-Professional als „Anwalt der Benutzer“ (bzw. der benutzerspezifischen Ziele) sieht sich mit „Anwälten“ aus dem BusinessKontext (Management-Ziele) und Technologiekontext (Ziele bzgl. Forschung und Entwicklung) konfrontiert.

Zusätzlich können aufgrund konzeptueller Arbeit weitere Abstimmungsbedarfe entstehen (z. B. hinsichtlich zusätzlicher Systemanforderungen, die eine Lösung nach sich zieht).

Auch dort werden Referenzprozesse definiert, um eine hohe Qualität sicherzustellen: Wie werden Geschäftsmodelle entwickelt? Wie erfolgt Innovationsmanagement? Wie ist der Produktentwicklungsprozess definiert?

Üblicherweise werden Konzeptaufgaben „gebündelt“ bearbeitet (es ist in der Praxis nicht möglich, für jede Konzeptaufgabe eine eigene Iteration einzuplanen).

Ein erfolgreiches Produkt entsteht dann, wenn die verschiedenen Anwälte gut zusammengearbeitet haben, wenn konfligierende Ziele optimal ausgehandelt

wurden – eher im Sinne von Mediation als von „Recht haben“. Um das zu erreichen, ist für den UX-Professional die Arbeit an den Schnittstellen zu den anderen Bereichen besonders wichtig: Erarbeitete Anforderungen, entwickelte Konzepte und Ergebnisse von Konzeptoder Produktbewertungen müssen auch für die anderen Interessengruppen erfahrbar und diskutierbar sein. Dafür braucht es neben der Integration der Aktivitäten des menschzentrierten Designs in die definierten Unternehmensprozesse (z. B. einen Systementwicklungsprozess) besondere Aktivitäten, die gleichfalls mit eingeplant sein müssen. Dabei ist es notwendig, die konzeptuellen Aktivitäten soweit möglich aus den eigentlichen Entwicklungsprozessen herauszunehmen („vorgelagerte Gestaltung“) und Orte/Ressourcen zu definieren, die eine Dokumentation von Anforderungen, Konzepten, Design-Patterns sowie Ergebnissen von Bewertungen in einer Art und Weise sichern, die eine nachhaltige Wirkung der in UX investierten personellen, zeitlichen und finanziellen Ressourcen sichert. 2.4. UX-Aktivitäten maßschneidern Als UX-Professional professionell zu handeln bedeutet vor allem über eine Sicht auf das eigene Business zu verfügen, die

Abhängig von der Art des interaktiven Produkts, Systems oder Services können hinsichtlich jeder oder vieler dieser Konzeptaufgaben Design-Patterns bzw. Vorgaben für eine konsistente Gestaltung entwickelt werden. Im Tutorial werden die oben dargestellten Aspekte iterativen konzeptuellen Arbeitens eingeführt und praxisnah diskutiert. 2.3. Integration menschzentrierten Designs Die Berücksichtigung der Anforderungen und Vorgehensweisen des

Abb. 3. mögliche (Qualitäts-)Ziele verschiedener Interessengruppen bei der Konzeption

31


es erlaubt, in einer gegeben Situation Kriterien zu definieren, die das oben angesprochene „it depends“ so beschreiben, dass ein maßgeschneidertes Vorgehen hinsichtlich notwendiger Aktivitäten und Methoden abgeleitet und gegenüber anderen Beteiligten begründet vertreten werden kann. Beispiel: „Nachdem wir in einer Kombination aus ‚Shadowing‘ und qualitativen Interviews in den verschiedenen Nutzungskontexten x, y, z beobachtet haben, bestimmen wir in einem StakeholderWorkshop den intendierten Nutzungskontext. Wir setzen die Methoden „Personas“ und „Schreiben von Szenarien“ ein, um die für diesen Nutzungskontext abgeleiteten Nutzungsanforderungen für alle Projektbeteiligten erfahrbar zu machen. Das ist wichtig, um Konzepte zu entwickeln, die die Nutzungsanforderungen berücksichtigen, und hilft uns darüber hinaus Konzepte, Entwürfe oder Prototypen gegen diese Anforderungen testen zu können. In einem Wallwalk mit Vertretern der Projektgruppe und weiteren Stakeholdern werden Konzepte und Evaluationsergebnisse dargestellt, lösungsorientiert diskutiert und weitere Anforderungen abgeleitet …“

Ergebnissen von Bewertungen für andere Interessengruppen sicherzustellen.

Lutsch, C., Petrovic, K. & Polkehn, K. Usability / User Experience – Rollen und Aufgaben von Usability Professionals im benutzerorientierten Entwicklungsprozess.

Im Tutorial erfolgt zunächst eine gemeinsame Erarbeitung des menschzentrierten Ansatzes (DIN EN ISO 9241-210), um die Grundkonstrukte zu verstehen, die sich letztlich in fast jedem der in der Literatur zitierten UX/Usability-Vorgehensmodelle wiederfinden. Dabei werden die oben angesprochenen verschiedenen Perspektiven eingeführt und diskutiert.

German UPA e.V., Arbeitskreis Berufsfeld. http://germanupa.de/german-upa/ berufsfeld-usability-ux 2. Behrenbruch, K., Bogner, C., Fischer, H., Geis, T., Geitner, C., Heimgärtner, R., Hofmann, B., Hunkirchen, P., Kluge, O., Litzenberg, B,. Polkehn, K., Pysarenko, Y., Zimmermann, D. (2012) German UPA Qualitätsstandard für Usability Engineering. German UPA e.V., Arbeitskreis Qualitätsstandards

Anschließend soll das Gelernte anhand mitgebrachter Teilnehmer-Fragestellungen in Kleingruppenarbeit ausprobiert werden. Die Kleingruppen entwickeln dazu unter Anleitung der Durchführenden ein methodisches Vorgehen zu den eigenen Fragestellungen (Planung von HCD-Aktivitäten und Methoden). Die Ergebnisse werden dann allen Teilnehmern vorgestellt und hinsichtlich wichtiger Aspekte diskutiert.

3. Deutsche Akkreditierungsstelle GmbH (DAkkS) (2010). Leitfaden Usability, Version 1.3. http://www.dakks.de/sites/default/ files/71-SD-2-007_Leitfaden%20Usability%20 1.3.pdf 4. DIN EN ISO 9241-210 (2010). Ergonomie der Mensch-System-Interaktion – Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme. Beuth Verlag. 5. Garrett, J. (2002). The elements of user experience: user-centered design for the

Das Tutorial wird in einem Fotoprotokoll dokumentiert, welches allen Teilnehmern zur Verfügung gestellt wird.

web. New Riders. 6. Geis, T., Hofmann, B., Bogner, C. & Polkehn, K. (2010). (Qualitäts-)Standards für Usability Professionals – welche sind das

Organisatorisches

32

1. Bogner, C., Brau, H., Geis, T., Huber, P., (2011). Beschreibung des Berufsfelds

3. Das Tutorial

Zusammengefasst

In einer Situation, in der einem UX-Professional ein neues Thema zugeworfen wird, heißt es „gekonnt aufzufangen“: –– zu verstehen, was die eigentliche Frage bzw. der Auftrag ist (Anforderungen ermitteln? Konzepte entwickeln oder bewerten? Bewertungen in Anforderungen überführen? Anderen helfen Anforderungen und Konzepte in ihre eigene Arbeit zu integrieren? ...), –– ausgehend von den oben angeführten Perspektiven unbedingt notwendige UX-Aktivitäten zu planen, –– die passenden Methoden zur Durchführung der Aktivtäten auszuwählen, –– dabei die Anforderungen anderer (auch interner) Interessengruppen zu berücksichtigen, sowie –– die Erfahrbarkeit von erarbeiteten Anforderungen, Konzepten und

Literatur

eigentlich?. i-com Zeitschrift für interaktive und kooperative Medien, Ausgabe 1-2010.

Die Teilnehmer müssen sich für das Tutorial anmelden.

München: Oldenbourg Wissenschaftsverlag. 7. Mayhew, D. J. (1999). The Usability Engineering Lifecycle – A Practitioner‘s

Zur Vorbereitung sollen angemeldete Teilnehmer den Durchführenden des Tutorials per E-Mail Kurzbeschreibungen (wenige Sätze) typischer Fragestellungen aus dem Berufsalltag zusenden.

Handbook for User Interface Design. Morgan Kaufmann. 8. Rosson M. B. & Carroll J. M. (2002). Usability Engineering – Scenario-based Development of Human Computer Interaction. Morgan Kaufmann. 9. Woywode, M., Mädche, A., Wallach, D. & Plach, M. (2012). Abschlussbericht des Forschungsprojektes „Gebrauchstauglichkeit von Anwendungssoftware als Wettbewerbsfaktor für kleine und mittlere Unternehmen“ im Auftrag des BMWi.


Usability Professionals 2012 Tutorials

33


Aktuelle Trends im Bereich interkultureller UX – Roadmap for Intercultural User Interface Design Dr.-Ing. Kerstin Röse Siemens AG, Corporate Technology, CT RTC SYE UID-DE San-Carlos-Str. 7 91058 Erlangen, Deutschland kerstin.roese@siemens.com

Dr. Rüdiger Heimgärtner Intercultural User Interface Consulting (IUIC), IUIC R&D HCI Lindenstraße 9 93152 Undorf ruediger.heimgaertner@iuic.de www.iuic.de

Abstract In diesem Workshop beschreiben und diskutieren die Teilnehmer die aktuelle Forschungs- und Projektlandschaft im Themenbereich ‚Interkulturelle Human-Computer Interaction (HCI) im deutschsprachigen Raum. Die daraus ableitbaren Herausforderungen für die nächsten 5 Jahre sollen in Form einer Roadmap für interkulturelle HCI münden, welche als Empfehlung für den deutschsprachigen Raum dienen und Akzente im internationalen Raum setzen kann.

1. Einleitung Im Moment arbeiten ca. 100 Forscher in Deutschland an interkulturellen Themen im HCI-Design. Insbesondere im Bereich interkulturelles User Interface Design und Usability Engineering gibt es sowohl Arbeiten und Veröffentlichungen (vgl. Honold 2000, Röse 2002, Vöhringer-Kuhnt 2002, Heimgärtner 2012 etc.) als auch Konferenzen (z. B. M&C, Technik & Kultur etc.). Das Wissen in diesem Bereich sollte gebündelt werden, damit Parallelarbeit vermieden und durch gezielte Ressourcennutzung ein Wissensvorsprung erarbeitet werden kann. Dieses kann dann auf internationaler Ebene präsentiert und weiterentwickelt werden. Ähnlich wie der Qualitätsstandard der GUPA für den Usability Engineering Prozess, auf Basis dessen ein internationaler Qualitätsstandard (ISO) für den Usabiltiy Engineering Prozess etabliert werden kann, soll dieser Workshop eine Forschungs-Roadmap für interkulturelles HCI schaffen, welche als Basis für internationale Standards und Manifeste in diesem Bereich dienen könnte (vgl. auch Bevan 2008). Zum einen soll dadurch sichergestellt werden, dass die deutschsprachige Usability-Community gestärkt wird, zum anderen aber auch, dass diese international bekannt wird und eng in die internationale Community integriert wird,

34

um weltweite Synergie-Effekte für Forschung und Entwicklung im Bereich des interkulturellen HCI Designs zu erzielen. Ein ähnlicher Ansatz war bereits auf der Interact 2011 im Rahmen des Workshops „Reframing HCI through indigenous perspectives“ erfolgreich, die Tiefe und Weite der Reflektion der Forschungsmethoden und das Bewusstsein für zusätzliche Perspektiven innerhalb des HCI-Designs und der HCI-Forschung zu erweitern. 2. Warum Interkulturelles HCI Design? Die zunehmende Globalisierung erfordert neue Sichtweisen auf das User Interface Design. Kulturelle Präferenzen müssen bei der Produktentwicklung berücksichtigt werden, um interkulturelle Überschneidungssituationen von Produktdefinition und Produktnutzung herstellen zu können (vgl. Honold 2002). Dadurch können kulturell geprägte Benutzererwartungen erfüllt werden und so eine erhöhte Gebrauchsfähigkeit des Produktes durch eine vertraute Bedienbarkeit erzielt werden. Dies erfordert, dass das Produkt auf die kulturellen Bedürfnisse der Benutzer ausgelegt wird. Globalisierung und wachsende Märkte erfordern die Entwicklung dieser Produkte derart, dass sie ohne aufwändige Änderungen im Programmcode in allen gewünschten Ländern verwendet werden können

Keywords: /// Interkulturelles User Interface Design /// Intercultural HCI /// Roadmap /// State-of-Research /// State-of-the-Art /// Kultur

(= Internationalisierung). Um das Produkt in einem speziellen Land verwenden zu können, sollten nur noch die entsprechenden Parameter gesetzt werden müssen (= Lokalisierung) (vgl. VMDA 2009). Je höher der Grad der Modularisierung in der Softwarearchitektur, desto: –– geringer ist die Entwicklungszeit –– höher ist der Grad der Systemgeneralisierung –– geringer ist der Programmieraufwand –– besser ist die Systemrobustheit für künftige Projekte und Plattformen. Dadurch wird die Zeit bis zur Markteinführung verkürzt. Turnover und Markt nehmen zu, was den Rücklauf der Investitionen (ROI) beschleunigt. Eine Anpassung des Produktes an die gewünschten Kulturen führt zu Vorteilen für Techniker (Wartung), Kunden (Usability), Produktmanagement (Prozesssteuerung) und Marketing (Verkaufszahlen) (vgl. Sturm 2005). Das Produkt wird verständlich und somit einfacher zu benutzen, was zu kürzeren Trainingszeiten führt (vgl. Honold 2000; Jürgensohn et al. 2001; Röse 2002 und Sun 2001). Darüber hinaus steigt die Wahrscheinlichkeit, dass ein Benutzer ein Gerät desselben Herstellers wieder kauft mit entsprechender Funktionalität und Gebrauchstauglichkeit. Ziel ist es letztlich, ein möglichst „globalisiertes Produkt für alle“ zu schaffen (UI4All, Stephanidis 2001) – insbesondere die


Usability Professionals 2012 Tutorials

Funktionalität und die Benutzungsschnittstelle betreffend. Allerdings können kulturelle Aspekte nur dann berücksichtigt werden, wenn die Designer bzw. Entwickler Grundsätze und Empfehlungen für das interkulturelle HCI-Design im Produktentwicklungszyklus kennen und anwenden. Dabei ist es insbesondere erforderlich, die Produktanforderungen und die Bedürfnisse der Benutzer zu erheben also auch den Kontext der Produktverwendung zu kennen. Dies kann auf verschiedenen Ebenen durch Beratung Schulung und Unterstützung von „Konzeptern“, Designern, Entwicklern und Managern von Produkten geschehen (vgl. Abbildung 1). [Abb. 1] 3. Stand der Forschung im Bereich des interkulturellen HCI-Designs Zunächst werden im Workshop die Erfahrungen der Autoren dargelegt und ihre Sicht auf den aktuellen Stand der Forschung im Bereich interkulturelles HCI Design basierend auf Literaturrecherchen präsentiert und für den deutschsprachigen Raum vervollständigt. Das dabei gezeichnete Bild umfasst vielfältige Themenbereiche angefangen von der Gestaltung von interkulturellen Sprachdialogen und Benutzeroberflächen über die Analyse kultureller Interaktionsunterschiede bis hin zu Usability Engineering und Prozessanpassung im interkulturellen Kontext innerhalb der Produktentwicklung (z. B. auch im Automotive-Bereich). Ausgehend von der Eisbergmetapher der kulturellen Einflüsse auf das User Interface Design (vgl. Röse 2001), werden insbesondere die visuellen Aspekte des User Interface Designs kulturell angepasst, weniger aber Aspekte der Navigation und der Interaktion (vgl. Abbildung 2). [Abb. 2] Bis heute werden Systemarchitekturen eher auf die Anpassung von Sprache, Farben und Icons ausgelegt, weniger aber auf die Adaption von Interaktionsgeschwindigkeit, Informationsdichte oder Dialogstruktur – wenngleich auch diese Aspekte allmählich in den Fokus rücken (vgl. Heimgärtner 2012).

Abb. 1. Einflussebenen auf interkulturelles User Interface Design

Abb. 2. Fehlen theoretischer und empirischer Arbeiten hinsichtlich kultureller Mensch-Computer-Interaktion (angelehnt an Röse 2001: 161; modifiziert und erweitert von Heimgärtner 2012: der wissenschaftliche Fortschritt entwickelt sich immer noch sehr langsam von der hellrot zur dunkelrot markierten Ebene).

35


Bisher ist noch nicht systematisch erforscht, wie sich die Design- und Entwicklungsprozesse von Benutzungsschnittstellen als auch das Usability Engineering mit all den einschlägigen Methoden im Einsatz in verschiedenen Kulturen unterscheiden und welchen Einfluss dies sowohl auf das HCI-Design als auch auf die Verwendung der Produkte und damit auf deren Usability und die User Experience hat (vgl. Röbig et al. 2010). Zwar gibt es einzelne Untersuchungen im deutschsprachigen Raum (z. B. André 2004, Biesterfeldt 2011, Heimgärtner 2012, Knapp 2007, Kralisch 2006, Leiber 2010, Mandl 2005, Ressin 2010, Röbig 2010, Rösch 2005, Röse 2002, Rößger 2002, Vöhringer-Kuhnt 2002) und natürlich auch im internationalen Bereich (z. B., Abdelnour-Nocera et al. 2011, Bidwell et al. 2011, Clemmensen 2010, u. a.). Aber eine komplette Zusammenschau und systematische Ergebnisdarstellung und letztliche Verbindung aller Ergebnisse in einem möglichen Modell für kulturell beeinflusste HCI stehen noch aus – auch wenn bereits hier erste Versuche unternommen werden (z. B. Clemmensen 2009, Clemmensen & Röse 2010, Heimgärtner 2012). 4. Zielsetzung und zu erzielende Ergebnisse des Workshops Es soll aufgezeigt werden, was bisher in der deutschsprachigen HCI-Community zum Thema ‚Intercultural HCI’ geforscht wurde und welche Projekte im Bereich ‚Interkulturelle UX’ aktuell in der deutschsprachigen HCI-Community bearbeitet werden. Danach sollen aktuelle Arbeitsschwerpunkte analysiert und anstehende thematische Herausforderungen in den nächsten 5 Jahren identifiziert werden. Wir wollen herausfinden, wo unsere Kompetenzen liegen und wo wir uns im internationalen Kontext einordnen können. Daraus ableitend soll eine Übersicht zu Experten und Schwerpunktthemen für den deutschsprachigen Raum erstellt werden. Abschließend wollen wir Maßnahmen definieren, wie wir unsere Stärke in diesem Themenbereich besser in der internationalen HCI-Community einbringen und darstellen können. Durch Nutzung der

36

Ergebnisse heutiger Networking-Möglichkeiten und Austauschplattformen der Experten und anhand von Dialogen zu geplanten Ereignissen, sollen nach einem halben Tag Workshop folgende Ergebnisse erarbeitet sein: –– Übersicht zu aktuellen Themen, Kompetenzen und Experten im deutschsprachigen Raum. –– Roadmap zu den kurz- und mittelfristigen Herausforderungen im Bereich Interkulturelle HCI (z. B. Themen / Personen / Termine + Ereignisse / geplante Ergebnisse für die nächsten 5 Jahre). Für die tägliche Arbeit sollen im Hinblick auf Design, Methodik, Prozess und notwendige Kompetenzen praktische Empfehlungen abgeleitet werden. Die Workshop-Teilnehmer erhalten einen Überblick zum aktuellen ‚State of Art’ im Bereich Interkulturelle UX im deutschsprachigen Raum. Dabei wird der Austausch mit Kollegen, die am gleichen Thema arbeiten gefördert und ein Überblick zu individuellen Schwerpunktthemen ermöglicht. Daraus erfolgt dann die Erstellung einer ‚Landkarte’ mit Themenschwerpunkten und Experten im Bereich ‚Interkulturelle User Experience’ für den deutschsprachigen Raum. Der Workshop soll damit als Plattform für Dialog und Networking dienen und so die Diskussion, den Austausch zu aktuellen Ansätzen und Projekterfahrungen und der Festigung von persönlichen Kontakten und Kooperationsbeziehungen fördern, was zur Stärkung der Lobby und Gemeinschaftsprojekte der deutschsprachigen HCI-Community beitragen soll. Dieser Effekt kann noch weiter verstärkt werden, indem darüber hinaus die Ergebnisse des Workshops künftig auf internationalem Parkett präsentiert werden (z. B. Interact/CHI/UPA/ HCII), um den erarbeiteten Synergie-Effekt im deutschsprachigen Raum auch in den internationalen Raum zu projizieren und die Ergebnisse auch auf internationaler Ebene zu integrieren.

5. Zielgruppe Als Teilnehmer dieses Workshops sind HCI-Experten und Usability Professionals mit Berufserfahrung und entsprechendem Interesse am Thema ‚Interkulturelle HCI‘ sowie Experten aus dem Bereich interkulturelle HCI selbst angesprochen. Vor dem Workshop eingereichte zweiseitige Positionspapiere werden im Workshop diskutiert. Zusätzlich wurden den Moderatoren bekannte Experten für interkulturelle HCI aus dem deutschsprachigen Raum persönlich zum Workshop eingeladen. Generell waren alle am Thema Interessierten der UP-Community als Zuhörer eingeladen. 6. Verlauf des Workshops Die Autoren steuern selbst einen entscheidenden Beitrag als Grundlage für diesen Workshop bei (siehe Abschnitt 3), da beide Autoren seit 1995 bzw. seit 2003 intensiv im Bereich interkultureller HCI forschen und wirken. Die weiteren Inhalte des Workshops werden überwiegend durch die Beiträge und Statements der Teilnehmenden bestimmt. Im Workshop werden die Themenfelder voneinander abgegrenzt und eine Roadmap anhand der Ergebnisse bisheriger Forschung erstellt. Daraus werden analytisch mögliche Antworten auf die Forschungsfragen ermittelt und begründet. Diese können im Rahmen der Diskussion innerhalb des erfahrenen Expertenplenums einer ersten Evaluation unterzogen werden. Die Einführung, Moderation und Zusammenführung der Beiträge in der Diskussion und die abschließende Ergebnisaufbereitung übernehmen die Workshop-Autoren.


Usability Professionals 2012 Tutorials

Literatur

in Human Computer Interaction – Towards

1. Abdelnour-Nocera, J., Kurosu, M.,

Culturally Adaptive Human Machine

– unterschiedliche Wege? Über die

Clemmensen, T., Bidwell, N., Vatrapu,

Interaction. Dissertation. University of

Gleichzeitigkeit des Ungleichzeitigen in

R., Winschiers-Theophilus, H., Evers,

Regensburg. Oldenbourg Verlag. München.

der deutsch-russischen Zusammenarbeit “

V., Heimgärtner, R., and Yeo, A. (2011).

9. Honold, P. (2000). Interkulturelles usability

18. Rösch, O. (2005) “Gemeinsame Ziele

TRANS – internet journal for cultural sciences

Re-framing HCI through local and indigenous

engineering: Eine Untersuchung zu kulturellen

perspectives. In Proceedings of the 13th

Einflüssen auf die Gestaltung und Nutzung

19. Röse, K. L. L. Z. D. (2001). Design Issues in

technischer Produkte. Düsseldorf, VDI Verl.

Mainland China: Demands for a Localized

IFIP TC 13 international conference on Human-computer interaction – Volume Part

10. Jürgensohn, T., K.-P. Timpe, et al. (2001).

14/2005, DOI:

Human-Machine-Interaction Design. 8th IFAC/

IV (INTERACT‘11), Pedro Campos, Nuno

Kraftfahrzeugführung: [Gedenkband für Prof.

IFIPS/IFORS/IEA Symposium on Analysis,

Nunes, Nicholas Graham, Joaquim Jorge,

Dr. Hans-Peter Willumeit]. Berlin, Springer.

Design, and Evaluation of Human-Machine

and Philippe Palanque (Eds.), Vol. Part IV. Springer-Verlag, Berlin, Heidelberg, 738-739. 2. André, E., M. Rehm, et al. (2004). Endowing

11. Kamentz, E. & T. Mandl (2003). Culture and E-Learning: Automatic Detection of a Users’ Culture from Survey Data. Proceedings

Systems. G. Johannsen. Kassel, Preprints: 17-22. 20. Röse, K. (2002). Methodik zur Gestaltung

Spoken Language Dialogue Systems with

of the Fifth International Workshop on

Emotional Intelligence. Affective Dialogue

Internationalisation of Products and

Systems, Tutorial and Research Workshop,

Systems. V. R. K. H. P. C. J. D. D. Evers. IWIPS

ADS 2004, Kloster Irsee, Germany, June 14-16,

2003, Germany, Berlin, 17-19 July 2003.

Differences in the Interaction between

2004, Proceedings. A. Elisabeth and H. Laila

Kaiserslautern, University of Kaiserslautern:

Drivers and Driver-Information-Systems. SAE

Dybkjær and Wolfgang Minker and Paul:

189-210.

178-187. 3. Bevan, N. (2008). Classifying and selecting UX

12. Knapp, B. (2007). „Mental Models of Chinese and German Users and Their Implications

and usability measures. In: COST294-MAUSE

for MMI: Experiences from the Case Study

Workshop: Meaningful Measures: Valid Useful

Navigation System.“ Lecture Notes in

User Experience Measurement. June 2008 4. Bidwell, N., Winschiers-Theophilus, Heike,

Computer Science 4550: 882. 13. Kralisch, A. (2006). The Impact of Culture and

Koch Kapuire, G., Rehm, M.,. (2011). Pushing

Language on the Use of the Internet Empirical

Personhood into Place: Situating Media in

Analyses of Behaviour and Attitudes, Berlin.

the Transfer of Rural Knowledge in Africa. Int.

14. Leiber, P. (2010). Ergonomische

interkultureller Mensch-Maschine-Systeme in der Produktionstechnik. Univ., Kaiserslautern. 21. Rößger, P. & I. Rosendahl (2002). Intercultural

World Congress. 22. Stephanidis, C. (2001). User interfaces for all: Concepts, methods, and tools. Mahwah, NJ, Lawrence Erlbaum Assoc. 23. Sturm, C. (2005). Approaches for a Successful Product Localization. In. Workshop – Proceedings der 5. Konferenz Mensch und Computer. Linz, Österreich. 24. Sun, H. (2001). Building a culturallycompetent corporate web site: an

Journal of Human-Computer Studies. Eds.

Produktgestaltung am Beispiel mobiler

exploratory study of cultural markers in

Cheverst, K., Willis, K., In Press. (Special Issue

Geräte im interkulturellen Vergleich:

multilingual web design. Proceedings of

on Locative Media.).

China – Deutschland – USA. Dissertation.

the 19th annual international conference on

Technische Universität Chemnitz. URL=http://

Computer documentation. Sante Fe, New

5. Biesterfeldt, J., Capra, M. (2011). Leading International UX Research Projects.

www.qucosa.de/recherche/frontdoor/?tx_

In: Marcus, A. (Hrsg.): Design, User

slubopus4frontend[id]=6258. Stand:

Experience, and Usability. Theory, Methods, Tools and Practice. Proceedings of the HCI

29.07.2012. 15. Mandl, T. (2005). „IWIPS Workshop

Mexico, USA, ACM: 95-102. 25. VDMA (2009). Software-Internationalisierung Leitfaden. Frankfurt a.M., VDMA Fachverband Software.

International 2011, S. 368-377. Heidelberg:

discusses Internationalisation of Products

Springer.

and Systems7-9 July 2005, Amsterdam, The

Culture on Usability, Freie Universität Berlin.

Netherlands.“ Inf. Serv. Use 25(3,4): 197-198.

M.A.

6. Clemmensen, T. (2009). Towards a Theory of Cultural Usability: A Comparison of ADA

16. Ressin, M. and Abdelnour-Nocera, J. (2010).

and CMU Theory (awarded best paper of the

Localization and Agile Development. In

conference). HCD 2009, Held as Part of HCI

V. Evers, J. Abdelnour-Nocera and E. del

International 2009, San Diego, CA, USA, July

Galdo (Eds.) Designing for Global Markets 9:

19-24.

Proceedings of the International Workshop of

7. Clemmensen, T., Röse, K. (2010). An Overview

Products and Systems 2010.

of a Decade of Journal Publications about

17. Röbig, Sinja ; Didier, Muriel ; Bruder, Ralph

Culture and Human-Computer Interaction

(2010): Internationales Verständnis von

(HCI). In: Human Work Interaction Design:

Usability sowie Methodenanwendung im

Usability in Social, Cultural and Organization

Bereich der Usability. In: Grundlagen –

Contexts. IFIP Advances in Information

Methoden – Technologien, 5. VDI Fachtagung

and Communication Technology, Volume

USEWARE 2010, 13. – 14. Oktober 2010,

316/2010, 98-112 (2010).

Baden-Baden. In: VDI-Berichte , 2099 .

8. Heimgärtner, R. (2012). Cultural Differences

26. Vöhringer-Kuhnt, T. (2002). The Influence of

Düsseldorf.

37


Analog = Digital Über den Sinn und Unsinn von Modellbau-Aktivitäten im Spannungsfeld von Design Thinking und User-Centered-Design Oliver Gerstheimer chilli mind GmbH Königstor 23 34117 Kassel www.chilli-mind.com gerstheimer@chilli-mind.com

Abstract Design oder das Entwerfen als Problemlösungsdisziplin ist das konstruktive Vorausdenken durch die Visualisierung multipler Zukunftsalternativen. Modellbau ist dabei essenzieller Bestandteil und roter Faden im Prozess der zielführenden Lösungsgenerierung. Modelldarstellungen oder auch Produkt-/Service-Simulationen schaffen die Sicherstellung des systematischen Zweifelns im Projekt, um aus entwickelten Alternativen die „richtige Lösung aus Kundensicht“ weiter zu entwickeln und die Treffgenauigkeit von Produkten im Markt zu erhöhen. Ein dem Kontext der Fragestellung umfassender Modellbau, analog wie digital garantiert konstruktiven sowie marktgerechten Projektfortschritt und ist Beschleuniger in explorativen und multivariaten Entscheidungssituationen der Produktoder Servicekonkretisierung. Es bleibt die Frage zu klären: Was ist guter Modellbau und wer kann eigentlich guten und projektspezifischen Modellbau realisieren? Und: Welche Visualisierungs- und Darstellungsarten von Modellbau gibt es, welche sind wann und für welche Projektierung adäquat oder falsch, bzw. nicht zielführend und unnütz?

Fokus des Tutorials Das Tutorial hat puren Praxisbezug und ist eine entwerferische und damit argumentative Anleitung, mit Lust und Spaß an der zynischen und kritischen Auseinandersetzung zu den Themen Modellbau bei New Business sowie User-Experience- und Usability-Projektierungen. Es geht dabei um das Zweifeln, Scheitern, die Relevanz, Frequenz und Wahrnehmung und weshalb Modellbau in Projekten überhaupt und wie angewendet werden sollte. Als Diskussionsanreiz werden 7 BusinessStories aus 10 Jahren User-Experience und Design-Thinking-Projekten aufgezeigt. Gemeinsame Diskussionen zwischen dem real stattfinden und prototypischen Methodenalltag schaffen eine reibunsgeladene Plattform für Auseinandersetzung und die gemeinsame Entwicklung einer Gebrauchsanleitung für projektspezifische Modellbauaktivitäten. Der Tutorial-Exkurs zwischen Analog = Digital endet mit 10 Faustregeln zum erfolgreichen Modellbau.

38

Kritische Evaluation und Hinterfragung wird erwartet. Konstruktive Nörgler, Skeptiker und Besserwisser sind ausdrücklich erwünscht und ermuntert zur Teilnahme! Apéro Jeder ist ein Problemlöser, Designer, Künstler, Usability-Profi und Design Thinker. Jeder kann Modelle bauen. Aber nicht jeder ist darin ein guter und objektiver Kritiker seiner Möglichkeiten der Lösungserzeugung und hat Erfahrung darin, was und warum er es so macht, wie er es macht. Planerischer und entwerferischer Modellbau hilft bei der Darstellung folgender Fragen: –– WAS? Es geht um das leidvolle Finden und das exakte Stellen der *Richtigen Frage. –– WESHALB? Es geht um die passenden *Frage-Lösungs-Methodik die keinem Dogma oder der Beliebigkeit folgen darf, ähnlich einer „One-Method-FitsAll“, sondern dem individuellen und budgeterreichbaren Projekterfolg.

Keywords: /// Modellbau /// Entwurfspraxis /// Skepsis & Zynismus /// Design Thinking (DT) /// User-Experience-Design (UXD)

–– WARUM? Es geht um den „Objektiven und Systematischen Zweifel“ an manifestierten Lösungsergebnissen, aber auch an sich selbst, dem Team, am Methodendesigns und dem Projekt – dauerwährend. –– WIE? Es geht um das Wissen der effizenten Werkzeuge, deren Sinnhaftigkeit im praktischen Einsatz und um das Tempi und Timing im Projektrhythmus. –– WIESO? Es geht um das Maximierungsprinzip vor dem Hintergrund der Kostenabschätzung: Wie kann im Spannungsfeld geringer Budgets ein optimales und professionelles Lösungsverhältnis zwischen Top und Flop erreicht werden.

Die Tutorial-Thesen: Anleitungen zum Konflikt 1. Ein Problemlöser ist ein darstellender und im Team kollaborierender Denkhandwerker, der mit guter Planung und visualisierten Entwürfen


Usability Professionals 2012 Tutorials

unscharfe Aufgabenstellungen erfasst, in einen argumentativen (visuellen) Lösungsweg überführt und vorantreibt. Gute Problemlöser (auch Teams) sind nur diejenigen, die jeden Tag planen, entwerfen und visuelle Modelle in mannigfaltiger und projektspezifischer Form bauen – und dies mit allen Tücken beherrschen. 2. Wer keine Erfahrung hat macht Fehler, kreiert „zu einfache“ Ergebnisse und lässt den Auftragskunden im Glauben alles richtig nämlich ein Modell gemacht zu haben. Jeder Modellbau erzeugt Begreifbarkeit und ein Ergebnis, aber nicht unbedingt das Richtige. 3. Modelle zu bauen klingt einfach, ist es aber nicht. Modellbau hat viel mehr Gesichter, Facetten und Darstellungsvarianten als gemeinhin angenommen oder überhaupt bekannt. 4. Es gibt keine Modellbaukultur, aber viele, gefährlich nett aussehende Werkzeuge für schlechten und ineffizienten Produkt-/ Service-Modellbau. Modellbau ist Mittel zum Zweck und benötigt ein hohes Maß an Erfahrung welche sinnvolle Darstellung zu welchem Zeitpunkt die Richtige ist – Stift oder Balsamico ;) kann eine Frage sein. 5. Wer den zu groben oder zu detaillierten Modellbau zum falschen Entwurfsund Konkretisierungs-Zeitpunkt wählt, beeinflusst das Projektergebnis erheblich negativ oder verharmlost die Aufgabenkomplexität zu Ungunsten der Lösungskreativität. 6. Modellbau ist keine „One-ShotOperation“ (zum Ende des Projekts), sondern ein durchgängig erfolgskritischer Faktor in der argumentativ-interpretatorischen Entwurfsverfeinerung und Selektion von Beginn an. Die Darstellung von Modellen basiert immer auf einer stufenweisen und projektspezifischen Variantenverfeinerung. Diese wird aber in der Regel mit monolithischen Werkzeugen umgesetzt. Man nimmt eben die Instrumente die man „grad da hat“ oder „die bekannt sind“. 7. Modellbau wird als Aufwands- und Leistungsposition in Projektierungen generell unterschätzt und nicht

adäquat im Sinne der Flopvermeidung budgetiert, so dass eher eine ProformaPosition“ oder „Cover-Your-Ant-Activity“ unterstellt werden kann. 8. Modellbau ist Entwerferhandwerk und wird in der entsprechenden Profession aktuell nur in der Ausbildung bei Gestaltungsberufen gelehrt und praktiziert, wie z. B. bei Produktdesignern und (Informations)Architekten. Andere Fakultäten und Professionen sind zunächst Modellbauautodidakten und zumeist Instrument-Laien. Ein gesundes Maß an systematischem Zweifel in einem „Problemlösungsteam“ ist daher in jedem Projekt im Bezug auf die existierende Modellbaukompetenz zur Anwendung zu bringen. Über die *Richtige Frage und das *Neugierige Zweifeln an Modellen für den guten Zweck – 7 Geschichten Design- und Entwurfsprobleme sind nach Horst Rittel (1972) als „bösartig“ kategorisiert und unterliegen in jeder *Frage-/ Erscheinungsform bei der Lösungsausgestaltung der Einzigartigkeit und der Manufaktur – sei es allein oder im Team. Dies meint auch die Anwendung und den Einsatz von erprobten und passgenauen Werkzeugen im Projektlösungsverlauf. Modellbau ist eine darstellende Querschnittsfunktion in der vorausschauenden Konkretisierung und Evaluation von Neuem. Die nachfolgende Auswahl an typische Business Stories soll zur Diskussion anreizen und zeigt Einblicke in die variantenreiche Praxis des Modellbaus und die praktische Hinterfragungen von Projekten an Modellen:

Business Story Nr. 01: „Maßstab 1/10: Apps = Häusermodellbau“ Oder: Die Kunst mit sokratischer Fragetechnik (Dialogtechnik: Mäeutik = Hebammenkunst), Skizzen und InfoGrundrissen zur budget- und kundengerechten Lösungen zu kommen.

Kunde (Anruf): „Ich brauche kurzfristig eine App für unseren Produktkatalog, können Sie mir sagen was das so grob kostet?“. Informationsarchitekt: Applikationen zu bauen ist wie Häuserbau. Was planen Sie denn zu bauen und für wen? Ein Einfamilienhaus, eine Villa oder eher ein Baumhaus oder eine Industriehalle … die Anforderungen, Herausforderungen und Kosten sind dabei sehr verschieden. Was werden die beteiligten Menschen dort machen und wie viele werden dort wohnen, ein- und ausgehen? Welche Funktionen und welchen Standard soll es denn erfüllen? Kunde: Sie müssen mir doch aufgrund Ihrer Erfahrung sagen können, was eine typische Applikation/ein Einfamilienhaus kostet. Informationsarchitekt: Natürlich, zwischen 150 – 750 Tausend Euro kann man schon was anständiges planen und bauen – für Apps nehmen Sie einfach 1/10 des Preises, also 15 – 75 Tausende Euro. Das ist in der Regel realistisch für 80 % der typischen nativen Applikationen. Kunde: Das ist ja unglaublich. Ich habe eine Agentur die setzt es für 5 – 20 Tausend Euro direkt um.

Abb. 1. 1/10: Apps sind wie Häuser“

39


Informationsarchitekt: Ja, so was gibt es. Manche Bauherren brauchen beim Hausbau auch keinen Architekten und verzichten damit auf professionelle Entwurfsuntersuchungen und Vormodelle, an denen man die zur Umsetzung geplanten Anforderungen und Restriktionen überprüft und optimiert. Dieser Typ Bauherr plant selbst und bestellt „hemdsärmlig“ die Realisierungsgewerke/Programmierer auf die Baustelle und los geht’s. Bedenken Sie einfach: Häuserbau ist eine „One-Shot-Operation“ und das ist für Sie kein Planungsalltag. Fehler sind nur schwer und kostenaufwändig rückgängig zu machen, wenn es fertig gebaut ist. ( > mehr dazu im Tutorial ...) Business Story Nr. 02: „Frage-Antwort-Modellbau“ Oder: Die Kunst im Umgang mit dem Unwohlseins, und der gefühlten Notwendigkeit einer Neu-Projektierung, die richtige und „offene“ Frage zu formulieren

Abb. 2. „Lösungsfokussierung durch Hinterfragung“

– „Moment of Truth“ oder auch „Magic Moment“ genannt.

Bild: „Wer sich am Bahnhof in den falschen Zug setzt ist zwar mit voller Tatkraft und beschleunigten 200 Sachen unterwegs, sein Ziel zu erreichen. Eine Ankunft ist damit auch gegeben, aber nicht unbedingt eine planvolle, erfolgreiche Zielerfüllung. Und noch schlimmer: Wer gar kein genaues Zielbild hat sitzt immer im falschen Zug und spielt Ergebnislotto.

40

Kunde (Meeting für Projektanfrage): „Ich habe von meinem Management eine Budgetfreigabe bekommen und brauche nun für ein besseres Marketing eine komplett neue, bedienfreundliche Websiteauftritt mit Social-Media-Aktivitäten. Wir müssen uns vom Wettbewerb abgrenzen und uns besser positionieren. Dieses Projekt werden wir ausschreiben. Können Sie mir ein Angebot machen und sagen wie Sie vorgehen würden? Design Thinker: Gerne, spannende Ausgangssituation. Kurze Frage: Woher wissen Sie denn, dass eine neue Website auf die von Ihnen gesetzten Ziele überhaupt einzahlt? Ist nicht die eigentliche Frage die Folgende: Wie schaffe ich das größte Differenzierungspotenzial und den besten Marketinghebel für meine Produkte mit dem verfügbaren Budget? Und vielleicht ist die Lösung dann gar keine Website mit Social-Media-Aktivitäten sondern eine radikale Produkt-, Service- und/oder Geschäftsmodellinnovation, die all das viel erfolgreicher erfüllt. Verstehen Sie mich richtig: Wenn Sie nun exakt eine „Website + Social Media“ ausschreiben bin ich ja gezwungen Ihnen genau dafür auch ein Angebot zu machen, ohne vielleicht treffgenauere Lösungen mit Ihnen zu entwickeln. Das macht mir einige Kopfschmerzen, weil ich nicht daran glaube, dass Ihre Lösung die einzige und Beste ist? Glaube SIE denn daran, dass es klappt? ( > mehr dazu im Tutorial ...) Business Story Nr. 03: „Format-Modellbau“ Oder: Warum in alten Formaten („Schläuchen“) häufig nichts Neues oder unbedingt Besseres entwickeln wird. Und warum eine Organisation meist nur 1-2 Ausdrucks- und Darstellungsmittel beherrscht.

Bild: „Versuchen Sie mal das Design, also die Form, das Material, die Maße und die Gesamtästhetik einer schönen und ergonomisch optimalen Thermoskanne im Format eines Pflichtenhefts zu beschreiben – ohne Modell oder Skizze! Vorweggenommen:

Abb. 3. Portfolio-Modellbau

das geht nicht und ergibt auch keinen Sinn. Sie werden kläglich scheitern und erstaunt sein, wie viele unterschiedliche Thermoskannen-Bilder in den Köpfen Ihres Teams ist. Sprache als Anforderungskonkretisierung ist mangelhaft und ineffizient.“ Kunde: Wir haben jetzt im Produktmanagement und mit der IT in 4 Monaten ein über 160 Seiten langes Lastenheft oder Pflichtenheft geschrieben und sind fertig mit der Anforderungsbeschreibung unserer neuen Web-Anwendung. Wir brauchen jetzt noch einen Designer, der das Interface schön macht und einen Prototypen baut, den wir dann direkt an Kunden vor dem Launch testen. Können Sie mir dazu ein Angebot machen? Designer: Na klar, ich hätte aber noch ein paar Fragen zum Projekt. Sind Sie sich denn sicher, dass alle im Lasten- oder Pflichtenheft beschrieben Funktionen und Details so für den Nutzer passen und umgesetzt werden müssen? Sind es nicht vielleicht zu viele oder zu wenige? Haben Sie die neuen Anforderungen schon mal in irgendeiner Form am Endnutzer getestet oder ist das jetzige Dokument am internen, „grünen“ Planungstisch entstanden? Kunde: Nein. ( > mehr dazu im Tutorial ...) 1.4. Business Story Nr. 04: „Portfolio-Modellbau“ Oder: Die Kunst wie man ein komplettes digitales Produktportfolio re-designed und als Modell begreifbar visualisiert,


Usability Professionals 2012 Tutorials

um Teams auf dem Weg partizipierend mitzunehmen.

Bild: „Wer das analoge Leben und damit die Verhaltensmuster und Limitationen der menschlichen Wahrnehmung (= Perzeption: (gedankliches) erfassen, er- und begreifen) nicht geübt und entwerferisch ableitet, kann auch keine digitalen Verhaltensweisen und -muster kundengerecht ausgestalten.“ Kunde: Aus der Vergangenheit heraus haben wir ein sehr heterogenes, gewachsenes Angebot an digitalen Dienstleistungen. Wir haben dies mit unserem Team bereits neu geclustert. Es sind nun ca. 5 Bereiche mit je über 45 Unterleistungen entstanden. Nun sind wir an dem Punkt, dass weder Sales noch Geschäftsführung oder Mitarbeiter in den Kundenprojekten einen Überblick haben, was wir eigentlich am Markt anbieten und wie wir das kommunizieren sollen. Wie können Sie uns helfen?

Nun zum Vorgehen und der Lösung: Die Erfolgsformel dahinter heißt „Analog = Digital“. ( > mehr dazu im Tutorial ...) Business Story Nr. 05: „(Gieß-)Kannen-Modellbau“ Oder: Warum nur durch Varianz wirkliche Evaluation an Modellen erwirkt werden kann.

Bild: Das entwerferische Gießkannenprinzip der Alternativenbildung schafft Thesen zur Evaluation und optimiert Treffgenauigkeiten.

UX-Designer: Kein Problem, das Muster der Portfolioverwässerung ereilt irgendwann fast Jeden. Stellen Sie sich vor, Ihr Leistungsangebot wäre ein „Laden um die Ecke“ und sie wären genau der gleiche Softwaredienstleister. Dann hätten Sie ein „Schaufenster“ und im Geschäft ein Regal um Ihre Produkte in einem chicken Verkaufsumfeld kundengerecht zu präsentieren. Sie als Verkäufer wissen sehr genau, wenn Lauf- oder Stammkundschaft vorbei kommen, dass die Hauptaufmerksamkeit kundenseitig nach spätestens 3-5 Minuten vorbei ist. Dann gehen Sie auf den potenziellen Käufer normalerweise im Ladengeschäft zu und fragen, was Sie für Ihn im Detail tun können. Denn sonst geht der Kunde „unbedient“ wieder weg.

würde er immer weiter gehen – unendlich. Ich habe noch 50 Sekunden Restzeit, daher nur noch die Zeichnung zum Gedankenmodell als erste skizzenhafter Darstellung. Den Rest dann im Tutorial – „Face-2Face“. Sorry und *Thanks for the Fish. ( > mehr dazu im Tutorial ...)

Man nehme die Firma AEG vor ca. 100 Jahren. Dort war Peter Behrends, einer der ersten Industriedesigner Deutschlands, als Gestalter unter anderem für das Design der elektrischen Tee- und Wasserkessel von AEG verantwortlich. Sein Entwurfsund Gestaltungsvorgehen war wie folgt geprägt – examplarische Rekonstruktion: Entwurfs-/Modellbaustufe 1 bis 5 ( > mehr dazu im Tutorial ...)

Abb. 4. Thermoskannen-Prinzip

Abb. 5. Geschäftsmodell-Ba

Ergebnis: 100 Jahre Produkt- und Industriedesign und die existierenden Erkenntnisse von Designern und der Entwurfstheorie zum Modellbau sind kein Garant für den Produkterfolgt, aber ein Hoffnungsträger, dem Visuellen und der modellbauenden Produkt-Simulation mehr Aufmerksamkeit, Respekt und Übung zukommen zu lassen. Business Story Nr. 06: „Geschäftsmodell-Bau“ Oder: Warum die Darstellung und Simulation von Geschäftsmodellen nur durch trickreichen Modellbau einen wirklichen Mehrwert generiert.

Information: Der textentwerfende Autor hat sich hier zu viel vorgenommen und übersteuert. Er schafft es nicht mehr diese Business Story Nr. 06 auszuformulieren. Die Zeit der Abgabe ist gekommen. Jeder Entwurf wird durch die Zeit beendet, sonst

Business Story Nr. 07: „Ideenmodellbau“ Oder: Warum die Fragestellung „Wie verdienen wir an jedem unserer Bestandskunden 2 Euro mehr pro Monat?“ eine entscheidende Modellbauherausforderung ist, wenn man 40 Mio. Kunden mit dem richtigen Ergebnis erfolgreich adressieren will.

Kunde: Wir haben nun in einem IdeenProzess über 250 Ideen entwickelt. Diese wurden in einem ersten Selektionsschritt auf TOP 100 Ideen reduziert. Wie kann ich nun dem Management diese Ideen visualisieren, um für die Realisation und für weitere Projektschritte das Budget zu rechtfertigen? Desing-Thinker: Der Ideen-Modellbau ist ein entscheidender Faktor für das Schnellverständnis zukünftiger Produkt- oder Service-Ideen. Die „Lese-Usability“ und die „First Impression“ stehen dabei im Fokus. Ähnlich dem „5-Sekunden-Test“ in der Usability wird im Produktplanungsalltag einer präsentierten Idee nur wenig zeitliche Aufmerksamkeit gewidmet. Ideenauswahl ist nicht nur politisch sensibel sondern meist durch das limbische Ich-EntscheiderSystem „gefällt mir oder nicht“, „schwarz oder weiß“ geprägt. Das bedeutet, das „Muster“ bei Entscheidern in Ideenauswahlsitzungen ist wie mit Scheuklappen

41


auf die Einzelidee beschränkt und stark mit persönlichen Interessen und Wissenshintergründen durchsetzt. Um diese Erkenntnis im Hinblick auf eine Objektivierung der Entscheidung zu verbessern ist der Ideenmodellbau die erfolgskritische Größe welches Produkt „weiter“ kommt. Je nach Menge und Relevanz der Aufgabenstellung muss ein spezifisches Ideenkatalogformat designed werden, was die zügige, aber objektive und trotzdem aussagekräftige Entscheidungsfindung beim „Schnellbetrachter“ zulässt. ( > mehr dazu im Tutorial ...) Schlussplädoyer: Design Thinking als Methode ≠ UXD X-Design-Y: User-Interface-Design, HumanCentered-Design, User-Experience-Design, Innovation-Design, Design-Management, Nageldesign, New-Business-Design, Business-Model-Design (...) und nun auch noch Design-Thinking. Die Rettung der Welt durch Gruppenkreativität und ach so erstaunlich neue Problemlösungsmethoden im Schnellformat des „Bastelmodellbaus“ ist bei Vorständen gut angekommen. So einfach ist die „Heilsbringung“ also – anscheinend. Aber: Zu aller Erstaunmotivation, dass jeder Akteur seine EINE EIGENE Methodik dafür hat und diese natürlich die BESTE und EINZIG WAHRE ist, wird Design Thinking, als Methode, Prozess, Dogma oder Philosophie auch noch überwiegend von Teams ohne ausgebildete Entwerferund Modellbauprofis – also Designer – angewendet und verkommt damit meist zum modischen, aber ineffizienten und viel zu teuren Management-Tool, ähnlich einem Klopfstaubsauger der viel Staub und Material aufgewirbelt, um Ihn dann in eine Management-Summary-Tüte wieder einzusaugen und danach wegzuwerfen

Fin Das gutes und alte Entwerfen und ein offenes Hinterfragen eines Produkts, der Marktpositionierung und der gestaltbaren Parameter, die zu Neuem, einer hohen Akzeptanz und sogar zu einem Weitererzählungsfaktor bei den Benutzern führt, ist

42

keine Kunst sondern ein grundlegendes Denk- und Problemlösungshandwerk, was schon lange und erprobt existiert. Design ist eine analoge wie digitale und hochkollaborative Teamdisziplin mit nützlichen Werkzeugen und Instrumenten zur Kreation und Visualisierung von Neuem. Hierzu eine abschließende Gedankenreihe zum Selbsttest, entworfen zur 2-fach-Iteration – klappt auch mit Design-Thinking statt Modellbau, u. a. bei Punkt 5: 1. Jede Frage bekommt eine Antwort. Ob Sie die richtige Frage zur Problemerkennung war, ist die Kunst. 2. Jedes Modell und auch jeder Prototyp taugt zur Iteration und erwirkt Feedback. Ob es die richtige Form und Konkretisierung der Darstellung ist, ist die Kunst. 3. Jede Hinterfragung einer Benutzbarkeit ist gut. Ob Sie frühzeitig, tief und weit genug ist, ist die Kunst. 4. Jederzeit kann ich potenzielle Anwender befragen. Ob man den Antworten glaubt und die Entscheider die Richtigen sind, ist die Kunst. 5. Jeder der Modellbau macht kann es. Ob er der Richtige ist, ist keine Kunst sondern die Frage. >>> Go to 1. Last but not least: Summary and conclusion for our international participants: –– Modelling matters – much more than you can even imagine. –– Design is a constructive forethought by visualising future. –– In every creation of new xy it is strongly recommended to integrate designers. “Do, or do not. There is no try!” (Yoda – The Empire Strikes Back, Star Wars)


Praxisberichte

43


Kaufempfehlungen in Onlineshops Cross-Selling erfolgreich eingesetzt

Sascha Küchler eResult GmbH Ludwig-Erhard-Straße 18 20459 Hamburg sascha.kuechler@eresult.de

Martin Beschnitt eResult GmbH Ludwig-Erhard-Straße 18 20459 Hamburg Tel.: +49 40 36166-7981 martin.beschnitt@eresult.de

Abstract Die Positionierung, die Art und die Benennung von Kaufempfehlungen haben einen hohen Einfluss auf die Annahme dieser durch den Kunden. Im Rahmen der Grundlagenstudie, die dieser Beitrag vorstellt, wurden mithilfe einer Methodenkombination (OnlineBefragung (n=600) und Usabilitytest (n=20) mit Eye-Tracking) allgemeingültige Handlungsempfehlungen für den Einsatz von Kaufempfehlungen in Onlineshops erarbeitet. Die Studie wurde in Kooperation mit einem Onlineshop („Vollsortimenter“) durchgeführt, der die Handlungsempfehlungen im Anschluss in seinem Shop umsetzte, um so den Erfolg zu überprüfen. Die Stärke der Ergebnisse liegt in der Methodenkombination, die Widersprüche aufdecken konnte und so die Handlungsempfehlungen zu einer universell geeigneten Synthese für Kaufempfehlungen machte, die mit A-/B-Testing überprüft wurde.

1. Einleitung Kaufempfehlungen werden von vielen Onlineshops eingesetzt und gehören mittlerweile zum guten Ton. Nicht immer werden sie jedoch in der eingesetzten Form vom Kunden gut angenommen. Dabei ist das Potenzial groß: Pohlkamp (2009, S. 2) zeigt auf, dass der Kunde bereits akquiriert ist und so für zusätzlichen Umsatz sorgt. Die Abwicklungskosten für den Shopbetreiber bleiben beinahe gleich. Das erfolgreiche Unterbreiten von Zusatzprodukten (sog. Cross-Sellings) sorgt demnach für gesteigerten Umsatz und ist auch für den Kunden vorteilhaft, da dieser mehr Produkte aus einer einzigen Quelle bezieht und daher einen geringeren Aufwand hat (vgl. Malms & Schmitz 2008, S. 30). Je besser die Cross-Sellings umgesetzt sind, desto eher wird der Kunde ihnen Beachtung schenken und auf dort gemachte Empfehlungen reagieren. Hierbei wird dem Wording, der Positionierung und der Art der empfohlenen Artikel (z. B. Zubehör oder Produktalternativen) besondere Bedeutung unterstellt. Davon ausgehend wurden folgende Hypothesen

44

aufgestellt, die mit den eingesetzten Methoden geprüft wurden: –– Die Benennung von Kaufempfehlungen hat einen entscheidenden Einfluss auf die Annahme durch den Kunden. –– Die Positionierung (auf der Seite selbst und an den verschiedenen Stellen im Kaufprozess) hat einen Einfluss auf die Annahme durch den Kunden. –– Die Annahme von Empfehlungen wird dadurch beeinflusst, wie gut sie zum Sortiment passen, zu dem sie angezeigt werden. Sie müssen in Art und Benennung an die Präferenzen bei der derzeit betrachteten Sortimentsart angepasst sein, um die Annahme zu steigern. Öffentlich gemachte Forschungsergebnisse zu dieser Thematik sind eher rar, sodass dieser Beitrag als transparenter Einblick in einen Forschungsansatz dienen soll. eResult hat hiermit das Ziel verfolgt, allgemeingültige Erkenntnisse für diesen wichtigen Bereich zu erarbeiten und sich zur Absicherung mehrerer Methoden bedient: Eine repräsentative Onlinebefragung (n=600) und ein Usability-Test (n=20) am kooperierenden Onlineshop führten

Keywords: /// Onlineshop /// Kaufempfehlung /// Cross-Selling /// Querverkauf /// Recommendations

in Kombination verlässliche Erkenntnisse zutage, die vom Kooperationspartner plus.de bei der Umgestaltung des Shops berücksichtigt wurden. 2. Eingesetzte Methoden Für diese Studie wurden zwei Methoden kombiniert, und zwar eine OnlineBefragung und ein Usability-Test mit Eyetrackinig. Das Ziel der Kombination zweier Methoden war die Absicherung der Ergebnisse: Die Online-Befragung konnte komplett losgelöst von einem Fallbeispiel erfolgen und ist daher als allgemeingültig anzusehen. Denn die Abbildungen, mit denen die Nutzer hier zu ihren Empfehlungspräferenzen befragt wurden, waren einfache Wireframes, die keinen speziellen Onlineshop repräsentierten. So konnte die Nutzermeinung unbeeinflusst vom Shopnamen und der Shopart erfasst werden. Mit ihr wurde die Untersuchung eingeleitet und eine grundlegende und idealtypische Datensammlung angefertigt. Der Usability-Test fand zwar an einem


Usability Professionals 2012 Praxisberichte

konkreten Onlineshop statt, zielte aber ebenso auf allgemeingültige Erkenntnisse ab und baute auf den bereits vorhandenen Erkenntnissen der Online-Befragung auf, die so nochmals überprüft werden konnten und um ausführliche Begründungen von Probanden ergänzt wurden. Die Kombination der Methoden erwies sich als sinnvoll, da die Erkenntnisse für ein Gesamtergebnis zusammengestellt wurden und im Labortest bereits auf ihre Praktikabilität hin überprüft werden konnten. 2.1. Online-Befragung Die am repräsentativen Online-Panel der Firma eResult (bonopolis.de) durchgeführte Online-Befragung (n=600) bildet die deutsche Online-Nutzerschaft nach den Vorgaben der AGOF internet facts ab. Die Nutzer wurden für drei verschiedene Sortimentsarten (Technik, Mode, Medien) nach den jeweils bevorzugten Empfehlungsarten und Empfehlungsbenennungen in den drei Kaufprozessschritten Artikeldetailseite, Warenkorb-Zwischenseite und Warenkorb befragt und gaben außerdem Präferenzen an, wo im Kaufprozess sie sich Empfehlungen wünschen oder ablehnen. Bei den Empfehlungsarten war aus vorgegebenen per Radio-Button zu wählen (vgl. Abb. 1), bei den Benennungen durften mehrere Varianten per Checkbox angekreuzt werden (vgl. Abb. 2). Auch freie Eingaben waren bei beiden Fragen zulässig. [Abb. 1], [Abb. 2]

Abb. 1. Wahl der gewünschten Empfehlungsart für die Artikeldetailseite eines Technikprodukts.

2.2. Usability-Test im Labor Der Usability-Test (n=20) bewertete den Onlineshop von plus.de. Hier kam auch Eye-Tracking zum Einsatz, um ergänzende Erkenntnisse zur Wahrnehmung der Empfehlungen zu erhalten. Verglichen wurde der aktuelle Onlineshop mit einer abgeänderten Variante, die als funktionsfähiger Prototyp, umgesetzt mit der PrototypingSoftware Axure, getestet wurde. Die Rückmeldungen der Nutzer zur neuen Variante wurden hier eingeholt, bevor diese live geschaltet wurde. Mögliche Umsatzeinbußen konnten so vorab ausgeschlossen Abb. 2. Wahl der bevorzugten Empfehlungsbenennungen für die zuvor ausgewählte Empfehlungsart im Warenkorb mit einem Medienprodukt.

45


Abb. 3. Wichtigkeit von Kaufempfehlungen.

werden, da diese Korrekturschleife in Form des Usability-Tests vorgeschaltet war. Unterschiede waren in beiden Varianten die Platzierung, Benennung und Art der Empfehlungen und Abwandlungen im Hinblick auf die Positionierung von Schaltflächen. Für den Vergleich wurde allen Probanden jeweils die alte und die überarbeitete Variante vorgeführt, um hierzu subjektive Einschätzungen zu den Cross-Sellings zu erhalten. Um zusätzlich die Wahrnehmung der Cross-Sellings zu messen, erfolgte die Messung per Eyetracking, da die Nutzer hierzu selten korrekte Angaben machen, wenn sie danach gefragt werden, ob und wie intensiv sie einen bestimmten Seitenbereich (hier: die Empfehlungseinblendungen) wahrgenommen haben. In beiden Shopversionen wurde der Einkaufsprozess simuliert und von der Artikelauswahl bis zum Ende des Checkoutprozesses getestet. In den einstündigen Labortests wurde in der überarbeiteten Variante stets mit den identischen Produkten gearbeitet, da eine Trennung nach Sortimenten mit verschiedenen Produkten zu geringen Häufigkeiten bei den Eindrücken zum Produkt geführt hätte und daher die Interpretation erschwert hätte. So wurde hier nicht das Konzept der Onlinebefragung (Betrachtung dreier verschiedener Sortimente) übernommen.

46

3. Ergebnisse Die Online-Befragung, deren vollständige Ergebnisse im eResult-Downloadbereich („Grundlagenstudie zu Cross- und UpSelling“, Chartband mit 58 Folien) abrufbar sind, wies eine relativ hohe Wichtigkeit von Kaufempfehlungen bei den Nutzern nach: Die Wichtigkeit wird hoch eingeschätzt (vgl. Abb. 3). [Abb. 3] Abb. 3: Wichtigkeit von Kaufempfehlungen. Weiterhin wünschen sich 71,8 Prozent der Nutzer Empfehlungen auf der Artikeldetailseite, auf der Warenkorb-Zwischenseite 28,7 Prozent, im Warenkorb 16,3 Prozent und im Bezahlprozess 8,5 Prozent der Nutzer. Hieraus ist zu schließen, dass die Artikeldetailseite der anerkannteste Ort für Kaufempfehlungen ist. Der Warenkorb und v. a. auch der Bezahlprozess sind eher umstritten. Empfehlungen auf der Warenkorb-Zwischenseite werden zwar auch als verhältnismäßig unwichtig eingestuft, deren Potenzial darf jedoch nicht unterschätzt werden: Schließlich hat der Kunde dort seine Kaufentscheidung bereits gefällt und ist empfänglich für ein Zubehörprodukt, ohne vom bereits gewählten Produkt wieder abzulassen. Dies zeigte sich in dieser Studie anhand vereinzelter Äußerungen der Probanden im Labor und lässt sich auch durch eine Reihe von Kundenstudien belegen, die eResult bereits durchgeführt hat. Auch Eberhard-Yom (2010, S. 75) weist

die Warenkorb-Zwischenseite als zielführenden Platzierungsort für Kaufempfehlungen aus. Abhängig vom umgebenden Sortiment äußerten die Teilnehmer unterschiedliche Präferenzen im Hinblick auf die zu empfehlenden Produkte. So sind es bei Technikprodukten Zubehörartikel auf den drei Seitenarten Artikeldetailseite (45,3 %), Warenkorb-Zwischenseite (49,2 %) und Warenkorb (42,5 %), die empfohlen werden sollen (vgl. Abb. 4). Die anderen Empfehlungsarten erreichen deutlich geringere Werte. Die bevorzugte Benennung für diese Empfehlungen lautet „Passend dazu“ (Zustimmung mindestens 29,5 %), je nach Prozessschritt dicht gefolgt von „Gleich mitbestellen“ (vgl. Abb. 5). [Abb. 4], [Abb. 5] Bei Medien und Büchern werden Bücher desselben Genres auf den drei Seitenarten als Empfehlungen gewünscht (48,6 % auf der Artikeldetailseite, 45,4 % auf der Warenkorb-Zwischenseite und 38,4 % im Warenkorb), im Warenkorb werden auch zuletzt angesehene Produkte mit 21,6 % bewertet, was zwar ein deutlich niedrigerer Wert ist, aber dennoch an dieser Stelle auffällt. Die Benennung sollte für Bücher desselben Genres in den drei Prozessschritten „Das könnte Sie auch interessieren“ sein (Zustimmung mindestens 38,1 %).


Usability Professionals 2012 Praxisberichte

Bei Modeprodukten werden ähnliche Produkte auf der Artikeldetailseite mit 32,3 % gut bewertet. Auf der WarenkorbZwischenseite und im Warenkorb sollten es eher Kombinationsmöglichkeiten sein (nach Ansicht von 44,9 bzw. 36 % der Befragten). Als Benennung für ähnliche Produkte auf der Artikeldetailseite wird „Folgende Produkte könnten Sie auch interessieren“ (30,3 %) mit „Das könnte Sie auch interessieren“ (28,9 %) beinahe gleich gut bewertet. Für die Kombinationsmöglichkeiten wird „Passend dazu“ auf der Warenkorb-Zwischenseite mit 41,5 % eindeutig bevorzugt. „Kombinationsartikel“ genießt mit 35,5 % vor „Passend dazu“ mit 32,9 % im Warenkorb den Vorzug. Die ausgezählten Häufigkeiten für die einzelnen Sortimente lassen eine eindeutige Präferenz für jedes Sortiment und jede Seitenart hinsichtlich der Benennung und Art erkennen. So sind Zubehörprodukte relativ unkompliziert auswählbar und können daher mit einer kurzen Empfehlungsüberschrift beworben werden („Passend dazu“). Bei Büchern, deren Kauf Geschmacksfrage ist, darf die Empfehlungsbenennung dann eher zurückhaltender sein. Modeprodukte verhalten sich hier fast ähnlich. Bemerkenswert ist, dass die Nutzer Artikel, die andere Kunden kauften bzw. die so betitelt sind, meist weniger interessant finden. Diese Benennungen erhielten auch nicht sehr wenig Zuspruch, setzen sich aber bei keiner Produkt- und Seitenart an die Spitze. Dies ist eine der wichtigen Erkenntnisse der Online-Befragung. Denn viele Onlineshops preisen Cross-SellingProdukte aufgrund des Einkaufsverhaltens anderer Kunden an. Viele Nutzer wollen aber nach eigener Vorliebe kaufen und z. B. bei Mode nicht „herumlaufen“, wie viele andere es bereits tun. Die Herkunft der empfohlenen Produkte wird in beiden Fällen identisch sein und von der Recommendation Engine aufgrund des Einkaufsverhaltens der bisherigen Kunden ermittelt worden sein, da dann die Kaufwahrscheinlichkeit einfach höher ist. Dennoch würden Benennungen ohne den Wortbestandteil „Kunden“ sehr wahrscheinlich besser performen.

Abb. 4. Gewählte Empfehlungsarten bei technischen Produkten.

Abb. 5. Bevorzugte Benennungen für Zubehörempfehlungen auf der WarenkorbZwischenseite beim Kauf eines Technikprodukts.

Ausgehend von den Ergebnissen der Online-Befragung wurden die Abwandlungen für den Prototyp des Onlineshops umgesetzt. Aufgrund der begrenzten Anzahl an Probanden wurde mit einem zu kaufenden Produkt getestet, für das im Warenkorb und auf der

Warenkorb-Zwischenseite Zubehörprodukte eingeblendet wurden. Zum Vergleich wurde die Resonanz der Probanden zu den derzeit verwendeten Empfehlungseinblendungen im untersuchten Onlineshop abgefragt, um einen Vergleich der beiden Versionen zu erhalten. Die folgenden Abbildungen (Abb.

47


Abb. 6. Artikeldetailseite von Originalshop (links) und Prototyp (rechts) mit abgewandelten Empfehlungen (ZubehĂśr), die anders Ăźberschrieben und platziert wurden. Die Auswertung dieser Areas of Interest aus der Eyetracking-Untersuchung ergab Folgendes: Die Empfehlungen im Prototyp wurden von 100 % der Nutzer innerhalb von sechs Sekunden wahrgenommen, die Empfehlungen auf der bisherigen Artikeldetailseite von 80 % nach durchschnittlich 12 Sekunden.

Abb. 7. Warenkorb-Zwischenseite von Original (links) und Prototyp (rechts) mit getauschten Buttonpositionen und anderen Empfehlungen mit neuer Benennung.

Abb. 8. Umgestalteter Warenkorb des Prototyps mit zwei Empfehlungsreihen im unteren Seitenbereich.

48


Usability Professionals 2012 Praxisberichte

6, Abb. 7, Abb. 8) zeigen die jeweiligen Veränderungen, mit denen getestet wurde. [Abb. 6], [Abb. 7], [Abb. 8] Die Resonanz der Nutzer war insgesamt positiv, jedoch gab es teilweise Beschwerden, wenn in verschiedenen Prozessschritten die Empfehlungen mehrfach angezeigt werden, auf die der Nutzer schon im vorherigen Schritt nicht reagiert hatte. Dies wird dann als aufdringlich empfunden. Wird auf eine Empfehlung beim ersten Mal nicht reagiert, möchten die Nutzer diese Empfehlungen nicht nochmals angezeigt bekommen. Hierbei gilt es jedoch zu beachten, dass verschiedene Nutzertypen an unterschiedlichen Stellen angesprochen werden müssen. Es ist dann ggf. über eine leichte Abwandlung der Empfehlungen in den Schritten nachzudenken, sodass zumindest etwas andere Produktbilder zu sehen sind, um den Nutzer nicht zu verärgern, sondern das Cross-Selling-Potenzial möglichst gut mit verschiedenen Nutzertypen auszuschöpfen. Die Zufriedenheit mit den Kaufempfehlungen hängt auch von der Seite ab, auf der sie eingeblendet werden. Auf der Artikeldetailseite können prominent platzierte Empfehlungen auch vom eigentlichen Kauf des Hauptprodukts ablenken. Auf der Warenkorb-Zwischenseite wurde das eingeblendete Zubehör sehr gut bewertet, denn die Kaufentscheidung wurde bereits gefällt, sodass der Kopf der Nutzer jetzt frei ist für den Kauf eines interessanten Zusatzprodukts. Die im Warenkorb verwendete Empfehlungsplatzierung war sehr dezent, sodass sich nur wenige Nutzer davon gestört fühlten, aber auch nur verhältnismäßig wenige hier überhaupt noch darauf reagieren, da die meisten von hier aus den Kaufprozess nur noch abschließen wollen. Der Kritikpunkt der Probanden hinsichtlich der Buttonplatzierung auf der WarenkorbZwischenseite wurde durch expertenbasierte Betrachtung noch aufgelöst bzw. abgeändert, sodass das Potenzial noch gesteigert werden konnte. Mit der Umgestaltung im Prototyp wurde das Ziel verfolgt, den Kunden nicht direkt zur Kasse zu schicken, sondern zum weiteren Stöbern

anzuregen. Dies wurde von den Kunden mit den getauschten Buttons jedoch etwas zu negativ aufgefasst. Die Variante wurde noch insofern entschärft, als eine erneute Umgestaltung mit räumlich nah beieinander liegenden Buttons den Vorzug erhielt. So haben beide Shopping-Wege in etwa den gleichen Rang erhalten und sind beide rechtsbündig angeordnet sind, was dem natürlichen Nutzerverhalten entgegenkommt.

erhalten, um nicht den Entscheidungsprozess für das Produkt zu stören und später nicht vom Gang zur Kasse abzuhalten. Das Potenzial der Warenkorb-Zwischenseite sollte in jedem Fall ausgeschöpft werden. Hier wurde auch vom Betreiber durch eine überdachte Positionierung (vgl. Abschnitt 3) der Buttons („Zur Kasse“/„Weiter shoppen“) eine bewusstere Lenkung des Nutzerverhaltens erreicht (vgl. Abb. 9). [Abb. 9]

Dass die Akzeptanz für die getestete Empfehlungsumstellung im Hinblick auf die Position auf der Artikeldetailseite gut angenommen wurde, belegten die Äußerungen der Probanden. Auch die Eyetracking-Ergebnisse wiesen eine gute Wahrnehmung der horizontal dargestellten Empfehlungen nach. Der vermeintliche Bruch in der Produktdarstellung störte also die Probanden nicht. Auch ist die Wahrnehmung höher gewesen als für die rechts platzierten Empfehlungen (vgl. Abb. 6). Dies kann auf eine gelernte Banner-Blindness zurückgeführt werden, da im rechten Seitenbereich häufig Werbeeinblendungen platziert sind.

Die dem kooperierenden Onlineshop gegebenen Empfehlungen lassen sich auch für andere Onlineshops adaptieren und entsprechend einsetzen. Dies muss natürlich angepasst an die jeweilige Shoparchitektur und dessen Gestaltung geschehen. Solange die Umsetzungsempfehlungen berücksichtigt werden, ist mit einer gesteigerten Annahme der Empfehlungen zu rechnen.

4. Umsetzung Vom Betreiber wurden letztlich folgende Anpassungen vorgenommen: Die Benennungen der Empfehlungen wurden angepasst und die Warenkorb-Zwischenseite umgestaltet. Der begrenzten Funktionalität der Recommendation Engine bleibt es geschuldet, dass nicht alle Erkenntnisse in einen vollumfänglichen Betrieb umgesetzt werden können. So ist eine Unterteilung in Sortimente technisch schwierig umzusetzen und bleibt daher eher ein Ideal für Shops mit einem breiten Sortiment. Auch auf eine weitere Platzierung von Empfehlungen im Warenkorb wurde in der Live-Variante bislang verzichtet. Oberste Priorität genießt zuallererst die Verwendung passender Benennungen und die korrekte Positionierung in den Schritten des Bestellprozesses. Eine dezente Einblendung sollte auf der Artikeldetailseite und im Warenkorb den Vorzug

Der A-/B-Test am Fallbeispiel wies eine signifikante Steigerung der durchschnittlichen Artikelanzahl im Warenkorb nach. Insbesondere die Stärke der neuen Warenkorb-Zwischenseite konnte deutlich gemacht werden. 5. Diskussion Bei den erhaltenen Findings handelt es sich zunächst um idealtypische Befunde, die eine separate Betrachtung der drei verschiedenen Sortimente als Fokus hatten. Für Vollsortimenter ist die vollständige Umsetzung daher schwierig zu realisieren. Special-Interest-Shops werden es leichter haben und können gemäß der erfassten Mehrheitsmeinung, die im Labor überprüft wurde, ideale Cross-Selling-Empfehlungen abgeben, bei denen mit einer guten Resonanz zu rechnen ist. Für andere Shops (Vollsortimenter) oder Shops, deren Recommendation Engine bestimmte Konstellationen nicht bewerkstelligen kann, kann in jedem Fall über die von den Kunden gewünschten Benennungen eine größere Akzeptanz erreicht werden, die sich positiv auswirkt.

49


Abb. 9. Aktuelle WarenkorbZwischenseite von plus.de mit finaler Buttonpositionierung.

Selbstverständlich muss die Benennung auch die eingeblendeten Artikel treffend beschreiben, d. h. es darf nur die am besten akzeptierte Benennung für die zuvor bestimmte Art an Empfehlungen gewählt werden. Die Benennung „Passend dazu“ ist etwa bei alternativen Artikeln absolut ungeeignet und wird die Chance zur Annahme sogar deutlich verschlechtern.

Literatur 1. Eberhard-Yom, M. (2010). Usability als Erfolgsfaktor : Grundregeln, User Centered Design, Umsetzung. Berlin : Cornelsen. 2. eResult GmbH: Grundlagenstudie zu Crossund Up-Selling. eResult Downloadbereich. http://www.eresult.de/downloads/ downloads/eResult_Grundlagenstudie_ Cross-Selling_Up-Selling.pdf 3. Malms, O. & Schmitz, C. (2008). Cross-

Das Potenzial für Cross-Selling ist in jedem Shop ausbaufähig. Es wurde mit dieser Studie nachgewiesen, dass Empfehlungen besser sind als ihr Ruf und von vielen Kunden akzeptiert werden. Dass nicht jeder Kunde darauf reagiert, dürfte auch klar sein. Wichtig ist aber, dass die Kunden sich davon nicht gestört fühlen und im Zweifel eher keinen Zusatzkauf tätigen. Cross-Sellings sollen eben nur den Zusatzkauf anregen. Dafür muss ohnehin erstmal ein Kauf des ersten Produkts zustande kommen. Dann kann allerdings an den betreffenden Stellen der Kunde für weitere Produkte begeistert werden, und zwar noch eher wenn diese Handlungsempfehlungen Beachtung finden. Die Verfasser sind überzeugt, dass jeder Shop hiermit Steigerungen erreicht und freuen sich auch über Rückmeldungen zu den erzielten Erfolgen.

50

Selling-Potenziale – Nachhaltiges Wachstum realisieren. Marketing Review St. Gallen, 3, 30-36. 4. Pohlkamp, A. (2009). Identifikation und Ausschöpfung von Up-Selling-Potenzialen: ein Beitrag zur Segmentierung von Aufsteigern. Wiesbaden : Gabler.


Usability Professionals 2012 Praxisberichte

51


Einfach besser lernen! Usability als Designthema im Schulbuchverlag

Maria Mory Cornelsen Verlag Mecklenburgische Straße 53 14197 Berlin maria.mory@cornelsen.de 030/89785-170

Gerrit Prager Cornelsen Verlag Mecklenburgische Straße 53 14197 Berlin gerrit.prager@cornelsen.de 030/89785-769

Abstract Als Gestalterinnen eines Bildungsverlages steht für uns die Frage im Vordergrund, wie Lernende heute und in Zukunft „einfach besser lernen“ können. Um diese Frage zu beantworten, haben wir uns mit dem Lernumfeld, den Lernmöglichkeiten und der gesellschaftlichen sowie technischen Entwicklung beschäftigt. Es hat sich gezeigt, dass sich der Bereich Bildung in einem großen Umwälzungsprozess befindet. Durch die zunehmende Technologisierung der Bildungsmedien ergeben sich neue Tätigkeitsfelder, in denen die Methoden und Verfahren des Usability Engineering sinnvoll und wirksam für viele Menschen eingesetzt werden können. Wir skizzieren in unserem Beitrag, welche neuen Anforderungen an digitale Bildungsprodukte es bereits gibt, und beschreiben, wie man in der Praxis darauf reagieren kann. Anhand eines Modellprojektes zeigen wir, welche Maßnahmen wir im Verlag ergreifen, um auf die Veränderungen des Bildungsbereiches vorbereitet zu sein.

1. Spannungsfeld Lernen Lernprozesse sind wie gesellschaftliche Prozesse einem ständigen Wandel unterlegen. Das Lernen per Wissensspeicher Buch, das formale, institutionalisierte Lernen weicht zunehmend dem selbstgesteuerten, informellen lebenslangen Lernen. Auf diesen Wandel stellen sich Bildungsinstitutionen ein. Der Fokus hat sich bereits verschoben: Statt Rahmenrichtlinien für den Unterricht zu formulieren, werden verstärkt Schlüsselqualifikationen wie soziale und methodische Kompetenz als Leitlinien für den Unterricht definiert. Schulformen und Lerngruppen werden neu zusammengesetzt. Ehemals homogene, altersgleiche Klassen werden nun mit anderen Klassen zusammengelegt, Realschüler werden mit Hauptschülern gemischt und gemeinsam unterrichtet. In diesem Kontext entstehen neue Anforderungen an Produkte die das Lernen unterstützen: Die individuellen Kompetenzen jedes einzelnen Schülers müssen stärker als zuvor durch eine immer größere methodische Vielfalt, an jedem Ort und zu

52

jeder Zeit, gefördert werden. Diese Vielfalt und Flexibilität potenziert sich in der Gruppe. Jeder Schüler lernt nach seinem Bedarf, Methodik, Material, Lernort und Lernzeit unterscheiden sich. Diese Heterogenität der Lern- und Lehrsituationen benötigt flexible, modulare Produkte, deren Qualität sich durch die Passgenauigkeit zum sich verändernden Nutzungskontext auszeichnet. Digitale Produkte würden diesen Bedarf gut abdecken, wenn da nicht einige technische Hürden wären. 2. Spannungsfeld Technik Eine Bitkom-Umfrage zur technischen Ausstattung der Schulen und Schüler hat 2010 gezeigt, dass Computer im Unterricht entweder gar nicht oder seltener als einmal pro Woche zum Einsatz kommen. Die geringe Nutzung von Computern in den Schulen spiegelt die Schwierigkeiten der Lehrenden wieder: Drei Viertel aller Lehrer stehen den elektronischen Medien positiv gegenüber, scheitern aber häufig

Christiane Schmidt Cornelsen Verlag Mecklenburgische Straße 53 14197 Berlin christiane.schmidt@cornelsen.de 030/89785-624

Keywords: /// Lernen /// Bildungsmedien /// Human Centered Design Prozeß /// Produktentwicklung /// Werkzeug

an der schlechten technischen Ausstattung in der Schule und vermeiden deshalb den Umgang mit den elektronischen Medien (vgl. Bitcom). In der Freizeitgestaltung der Schüler sieht die Affinität zu den Neuen Medien völlig anders aus. Fast alle (86%) Jugendlichen besitzen ein Smartphone, surfen mobil, nutzen hauptsächlich Facebook und StudiVZ. Die Hälfte der kleineren Kinder verfügt über Spiele auf Konsolen und Computern, ein Viertel der Kinder nutzt das Internet mehrmals pro Woche und besucht Seiten wie toggo.de, kika.de, nick.de, wasistwas.de, mickymaus.de, etc. (vgl. Bitcom). Obwohl die „digital natives“ virtuos mit digitalen Medien umgehen, beweist das nicht eine umfangreiche Medien- oder Informationskompetenz. Die Bereitschaft zu kollaborieren bezieht sich derzeit lediglich auf den privaten Gebrauch und findet sich nicht im edukativen Kontext wieder. Auch die Kompetenzen der Lernmethoden und Informationsbeschaffung werden auf Grund der mangelhaften technischen Ausstattung der Schulen digital nicht gefördert.


Usability Professionals 2012 Praxisberichte

Geht man von einer Veränderung des Lernverhaltens in Richtung informelles Lernen aus und berücksichtigt die Umgebungsfaktoren wie Ausstattung etc., können Nutzer nur dann “einfach besser lernen”, wenn wir uns in Zukunft auf folgende Anforderungen einstellen: –– Lernen kann überall möglich sein. –– die passenden Hilfsmittel und Werkzeuge müssen den Lernenden und Lehrenden zur Verfügung stehen. –– die technischen Hürden werden tendenziell abnehmen. Um mit flexiblen und passgenauen Produkten auf diese Anforderungen reagieren zu können, sollte man den genauen Nutzungskontext, die Lernumgebungen und Lernziele kennen und analysieren. 3. Herausforderungen für einen Bildungsverlag Das gesamte Programm des Cornelsen Verlags umfasst knapp 18000 Titel aus rund 40 Fachrichtungen mit mehr als 1.500 jährlichen Neuerscheinungen. Davon sind ungefähr 10% digitale Produkte. Innerhalb der letzten Jahre ist der Anteil der digitalen Produkte auf 10% angewachsen. Noch ist das Medium Buch das zentrale Produkt im Schulbuchverlag. Es steht im Zentrum eines Angebotes aus analogen und digitalen Medien, die sich ergänzend um das Schulbuch gruppieren. Das digitale Portfolio umfasst Anwendungen für verschiedene Endgeräte im Lern- und Lehrkontext – vom Smartphone bis zum interactive Whiteboard. Im Gegensatz zur sich schnell ändernden Technik, beträgt die Lebenszeit der Cornelsen Anwendungen bis zu 10 Jahre. Die digitalen Produkte richten sich an 3 verschiedene Zielgruppen: Lehrer, Eltern und Lerner (Kinder, Jugendliche und Erwachsene). Diese Zielgruppen unterscheiden sich stark: die Schüler sind die Endnutzer der Produkte, die Eltern sind die Käufer der Produkte, die Lehrer sind die Empfehler und letztlich Kaufentscheider. Aus diesem Grund fokussiert sich ein Schulbuchverlag immer auf die besondere

Ansprache der Lehrerschaft, diese steht im Zentrum der Bemühungen. Diese Zielgruppe ist zum Großteil nicht die Nutzergruppe der Produkte. Für diese Zielgruppe steht deshalb, aus Sicht des Verlages, die Gebrauchstauglichkeit der Produkte nicht im Zentrum. 4. Status der nutzerzentrierten Produktentwicklung Die Schulbuchproduktion folgt bewährten Arbeitsprozessen, es gibt hohe Qualitätsmaßstäbe, deren Einhaltung durch inhaltliche wie technische Qualitätsprüfungen und durch ein staatliches Genehmigungsverfahren (Kultusministerien der Länder) gesichert wird. Dagegen sind die Entstehungsprozesse der digitalen Produkte von der Art des Mediums sowie von der technischen Entwicklung geprägt, somit ständigen Veränderungen unterworfen. So unterscheiden sich z. B. die Arbeitsabläufe einer App-Entwicklung von denen einer älteren CD-ROM Produktion. Die meisten digitalen Produkte entstehen als Ergänzungsprodukte zum Printwerk. Die Anforderungen an das digitale Werk werden vom Printprodukt bestimmt, nicht vom Nutzer. Die Spezifik des digitalen Mediums (Mobilität, Kollaboration etc.) und seine didaktischen Vorteile können nicht sinnvoll genutzt werden. Gebrauchstauglichkeit war bisher kein Qualitätsmerkmal, das es zu überprüfen galt. Um den Bedarf, nach nutzerzentriertem Vorgehen zu begründen und Qualitätskriterien für die Gebrauchstauglichkeit in den Verlag zu kommunizieren, nutzen wir die bewährten Mittel der nutzerzentrierten Produktgestaltung: Augen öffnen

Schnell erzeugte Highlight-Videos aus pragmatischen Usability-Tests zur Demonstration, wie ein Nutzer tatsächlich mit einer Cornelsen-Anwendung interagiert, haben sich als guter Augenöffner erwiesen.

Methoden implementieren

Wir bieten Workshops an, um gemeinsam mit Kollegen Ad-Hoc Personas zu entwickeln. Mithilfe dieser Methode zeigen wir den Bedarf an User-Research und können den Human-Centered-Design-Process (HCD) einführen. Wissen kommunizieren

Die Beteiligung an Entscheidergremien, Konferenzen, Seminaren und Diskussionsrunden im Verlag gibt uns Gelegenheit unser Wissen zu kommunizieren und die Stakeholder für dieses Thema zu sensibilisieren. Zusätzlich bieten wir Schulungen zum Thema Usability innerhalb des Verlages an. Unterstützend zu den Workshopmaßnahmen erstellen wir begleitendes Informationsmaterial. Mit geeigneten Werkzeugen den Prozess unterstützen

In der ISO-Norm 13407 wird der HumanCentered-Design-Prozess für interaktive Produkte genau beschrieben. Anlehnend an diese Beschreibung und mit Methoden des Usability Engineering, analysieren wir unsere bisherigen Produktionsprozesse und Produkte. Der Verlag publiziert viele verschiedene Produkte für unterschiedliche Nutzergruppen und Medientypen. Alle Produkte entstehen in Einzelprojekten, die von 9 Verlagsabteilungen getrennt gesteuert werden. Wiederkehrende Muster aus den Projekten können nicht genutzt werden. Es fehlt der Überblick und es findet kein Austausch statt. Genauso vielfältig wie die Produktpalette ist die Funktionsweise der Benutzeroberflächen und der interaktiven Elemente. Für diese Vielfalt benötigen wir übergreifende Standards, um eine einheitliche User Experience, wie z. B. gleiche Funktionalität für gleiche Interaktionen, zu schaffen. Für uns entstand der Bedarf nach Lösungen, die das vorhandene Wissen mit den Methoden des Usability-Engineering verknüpfen. Wichtig war uns, dieses Wissen

53


direkt bei der Produktentwicklung nutzen zu können. So entstand die Idee eines Werkzeuges für den HCD-Prozess – LOUIS. 5. LOUIS – Ein Werkzeug für den HCD-Prozess LOUIS ist eine Bibliothek von Übungen, die bereits in digitalen Anwendungen eingesetzt wurden. Die beschriebenen Übungen werden nur in die Bibliothek aufgenommen, wenn sie den Qualitätskriterien usability-geprüfter Software entsprechen. Der Arbeitstitel der Bibliothek lautet: LOUIS = library of usable interaction styles. 5.1. Warum eine Bibliothek für digitale Übungen? Zwei Anforderungen haben sich schon seit längerem aus den Projekten ergeben: Der Produktentwicklungsprozess soll effizienter werden, die Produkte müssen mehr Qualität haben. Das bedeutet, es muss eine Möglichkeit geschaffen werden, die fachlichen Erfahrungen und die erhobenen Nutzeranforderungen einsetzen zu können und so effizienter zu arbeiten.

Abb. 1. HCD-Prozess mit LOUIS

Abb. 2. Persona – Produktionsmanagerin digital

54

Um gebrauchstaugliche, digitale Lernmedien zu schaffen braucht es einen iterativen, kollaborativen Produktionsprozess, mit dem Nutzer im Zentrum – den HCDProzess. Alle Projektteilnehmer sollten miteinander kommunizieren können, die gleiche Sprache sprechen. Nutzungsanforderungen müssen am Beginn eines Projektes erhoben werden, während der Produktentwicklung immer wieder präsent sein und überprüft werden können. Um diesen Anforderungen gerecht zu werden, bedarf es einer digitalen Bibliothek. Die Bibliothek LOUIS unterstützt folgende Schritte des HCD Prozess: –– Schritt 1: Planen des menschzentrierten Gestaltungsprozesses In diesem ersten Schritt des HCDProzesses werden die Usability-Ziele des Projektes festgelegt. Da in der Bibliothek alle Übungsformen nach Zielgruppe und Kontext gefiltert


Usability Professionals 2012 Praxisberichte

5.2. Was erwarten die Projektbeteiligten von einer Bibliothek? In der ersten Projektphase von LOUIS analysierten wir unsere eigenen Produkte sowie Konkurrenzprodukte, um den groben Rahmen der zukünftigen Anwendung abzustecken. In der zweiten Projektphase ergaben sich weitere Anforderungen aus der Betrachtung des bisherigen Produktionsprozesses im Verlag. Mit dem Anspruch diesen Prozess nutzerorientiert zu gestalten, entwickelten wir Personas, die unserem Tätigkeitsprofil (Designberater) entsprachen.

Abb. 2. Kontext-Szenario – Produktionsmanagerin digital

werden können, ist es möglich, in dieser Phase mithilfe von LOUIS die Besonderheiten der ausgewählten Zielgruppe zu ermitteln und zu vergleichen. Diese Ergebnisse können sehr hilfreich bei der Erstellung des Nutzerprofils sein. –– Schritt 2: Verstehen und festlegen des Nutzungskontextes In der Bibliothek sind alle Übungsformen genau beschrieben: bezüglich des Mediums, der Nutzergruppe und entsprechend der didaktischen Anforderungen. Mithilfe dieser Informationen können die Kriterien und Möglichkeiten dem Nutzungskontext zugeordnet werden. –– Schritt 3: Festlegen der Nutzungsanforderungen Die Übungen in der Bibliothek sind Fach- und Medienspezifisch geordnet. Es wird genau beschrieben, welches Ziel mit welcher Übung erreicht werden kann. Dies unterstützt im Konzept die Festlegung der Nutzungsanforderungen. –– Schritt 4: Erarbeiten von Gestaltungslösungen

Nachdem die Nutzungsanforderungen festgelegt wurden, können mithilfe von LOUIS die passenden Übungen zusammengestellt werden. Die neue Kombination von verschiedenen Interaktionsformen innerhalb einer Übung gibt die Möglichkeit, Übungen passgenau den Nutzungsanforderungen anzupassen. –– Schritt 5: Evaluieren von Gestaltungslösungen Zum einen müssen an dieser Stelle die gewählten Gestaltungslösungen mithilfe der Nutzungsanforderungen überprüft werden, zum anderen kann mithilfe der Qualitätsanforderungen der Bibliothek, die Qualität der Gestaltungslösungen überprüft werden. –– Schritt 6: Gestaltungslösung erfüllt die Nutzeranforderungen Ist eine neue Lösung oder Übungsform entstanden und entspricht die Lösung den Qualitätskriterien der Bibliothek, kann sie als Best Practice-Beispiel und zur Dokumentation in die Bibliothek aufgenommen werden. [Abb. 1]

Da sich die Nutzung der Bibliothek nicht nur auf uns Gestalter beschränkt, führten wir Interviews mit verschiedenen Kollegen anderer Bereiche (Produktionsmanager, Redakteure) und erstellten weitere Personas (siehe Abbildung 2). –– Gestalterin: „Ich wünsche mir schon seit Jahren ein Hilfsmittel, um den Redakteuren nicht immer dasselbe erklären zu müssen und besser mit ihnen diskutieren zu können.“ –– Redakteur, Fachbereich Mathematik: „Wie schaffe ich es, Print-Inhalte mit minimalen Mitteln interaktiv zu machen?“ –– Produktionsmanagerin für digitale Produkte: „Die Redaktion kommt oft mit einem Referenzprodukt und möchte eine Software so oder ähnlich gestaltet haben.” [Abb. 2] In den Interviews entwickelten wir mit den Kollegen gemeinsam Kontext-Szenarien. Mithilfe dieser Szenarien (Abbildung 3) konnten wir beispielhaft den Nutzungskontext von LOUIS im Arbeitsalltag der Befragten ermitteln. [Abb. 3] Mehrere Anforderungen wurden in den Interviews mit Redakteuren, Produktionsmanagern und Gestaltern besonders deutlich: –– der Wunsch nach einer verständlichen Beschreibung und Dokumentation der vorhandenen Übungen,

55


Abb. 4. Übungsaufbau

–– nach einheitlicher Benennung der Interaktionsformen, –– die Möglichkeit des Vergleichens und Zuordnens, –– die Zusammenführung interaktiver und didaktischer Muster. 5.3. Erfüllt eine Muster-Bibliothek diese Anforderungen? Uns stellte sich die Frage, welches Medium erfüllt diese Anforderungen am besten. Ist es ein Wiki, ein Blog oder eine Muster-Bibliothek? Die Verbesserung der Kommunikation zwischen den Projektbeteiligten und den verschiedenen Verlagsbereichen ist eine der wichtigsten Anforderungen. –– Wir entschieden uns für eine Bibliothek, die die Kommunikation unterstützt. –– Was genau ist eine digitale Bibliothek? Eine digitale Bibliothek (Pattern-Library) ist eine strukturierte Sammlung verschiedener Informationen zu einem Themengebiet, die den Nutzern durch ein bestimmtes Ordnungsprinzip zugänglich gemacht werden.

56

Abb. 5. Übungsstruktur

5.4. Wie muss eine Bibliothek für digitale Übungen aufgebaut sein? In der Bibliothek werden digitale Übungen: –– medienübergreifend (Screen, SmartPhone, E-Reader, Tablet, Whiteboard), –– betriebssystemübergreifend –– fachübergreifend (von Mathematik bis zu den Sprachen) –– dokumentiert und durch verschiedene Filterfunktionen vergleichbar gemacht. Um festzulegen welche Inhalte, unter welchen Begriffen und mit welchem Muster in die Bibliothek aufgenommen werden, analysierten wir digitale Lernanwendungen und die Klassifikation von Lerntypen, Lerntheorien und Lernansätzen. Die am häufigsten genutzte Lernstrategie, die in den vorhandenen Medien des Cornelsen-Verlags eingesetzt wird, ist das Üben. Geübt wird, indem das im Unterricht erworbene Wissen wiederholt wird. Da unsere Bibliothek keine digitale Bibliothek für Software-Muster ist, sondern Gestaltungs-Muster für digitale Übungen enthält, die nicht direkt in Softwarecode umgewandelt werden können, legten wir fest, dass unser Gestaltungs-Muster dem

Begriff und dem Aufbau einer Übung entspricht. Eine Übung setzt sich aus folgenden Elementen zusammen: i Instruktion ii Interaktionen a Drag and Drop b Multiple choice c Point and Click d Texteingabe e Freitext f Audio-Sequenz iii Auswertung a direktes Feedback b Auswertung c Lösung iv Lernstandsanzeige (Gesamtauswertung aller Übungen) [Abb. 4] Abbildung 5 zeigt die Grundstruktur. Es wird dargestellt, dass bestimmte Elemente einer Übung immer vorhanden sind: Instruktion, Interaktion und Auswertung. Innerhalb einer Übung kann es mehrere verschiedene Interaktionen geben. Zu jeder Interaktion gibt es eine Auswertung und eine Instruktion. [Abb. 5]


Usability Professionals 2012 Praxisberichte

Aus dieser Form ergibt sich die Struktur der Beschreibung in unserer Bibliothek. 5.5. Louis als Werkzeug Wir legten die Struktur der Beschreibung, die Begriffe für die Elemente und eine Filterstruktur zur Zuordnung der Entwurfsmuster fest. Um unsere theoretischen Überlegungen praktisch zu überprüfen, erstellten wir einen Prototyp. Mithilfe unserer erstellten Personas und Nutzungsszenarien haben wir ihn, wie nachfolgend beschrieben, verfeinert.

KickOff-Meeting wird in die Bibliothek LOUIS geschaut, um der Redakteurin verschiedene Übungsformen anhand der Best Practice-Beispiele zu zeigen [Abb. 6]. Es ist hilfreich für alle Projektbeteiligten, dass die Bezeichnung der Übungsformen und Interaktionen mithilfe der Abbildungen und Beschreibungen selbsterklärend ist. Die Redakteurin verlässt das KickOffMeeting mit einer genauen Vorstellung der verschiedenen Übungen und Interaktionen [Abb. 7].

UseCase: Redakteurin Grundschule, erstes Whiteboard-Projekt, Deutsch für Klasse 5 – 6, Zeit zur Umsetzung: 4 Monate

Sie kann nun die Anforderungen ihrer Zielgruppe gemeinsam mit dem UsabilityExperten erheben. Gemeinsam werten sie die Nutzungsanforderungen der Zielgruppe aus. Es entsteht ein erstes Grobkonzept. Die Redakteurin sucht nun in der Bibliothek die passenden Übungen und Interaktionen aus [Abb. 8]:

Es findet ein erstes KickOff-Meeting statt. Gemeinsam mit allen Projektbeteiligten wird über das Vorhaben, eine InteractiveWhiteboard-Software (IWB) für das Fach Englisch (Grundschule), gesprochen. Die Redakteurin hat noch nie ein Konzept für eine IWB-Software entwickelt. Sie hat aber das Print-Lehrwerk, das als inhaltliche Vorlage dienen soll, gemeinsam mit einer Autorin konzipiert. Schon in diesem

An den Stellen des Konzeptes, an denen sie sich unsicher ist, berät sie sich mit dem Usability-Experten. Anhand des Grobkonzeptes wird ein erster Prototyp erstellt. Der Prototyp wird dem Technischen Hersteller, dem Produktionsmanager und dem externen Programmierer erklärt. Sie können nun einschätzen, wie hoch der technische Aufwand für die Umsetzung ist. Der UsabilityExperte, die Redakteurin und der Designer

Mögliches Szenario mit LOUIS:

prüfen mithilfe der Personas ob der Prototyp den Nutzungsanforderungen entspricht. Dank der Best-Practice-Beispiele in der Bibliothek, kann die Redakteurin ihre Vorstellungen von der Gestaltung der Software genau beschreiben. In der nächsten Iterationsstufe werden die Anforderungen, die im UsabilityTest festgestellt wurden, eingepflegt. Der Prototyp bekommt ein verfeinertes User-Interface entsprechend den Gestaltungsanforderungen. Die Testergebnisse aus dem zweiten Usability-Test dienen als Grundlage für die letzten Anpassungen. Sie bespricht mit dem Usability-Experten und dem Gestalter, welche Übungen neu entstanden sind. Die beschriebenen Übungen werden nur in dieser Bibliothek (Abbildung 9) aufgenommen, wenn sie den Qualitätskriterien usability-geprüfter Software entsprechen. [Abb. 9] Als Bibliothek dient LOUIS der zuverlässigen Dokumentation von Übungen mit didaktisch eingesetzten Interaktionstypen und zur Neu- und Weiterentwicklung digitaler Lernprodukte. LOUIS ist somit ein Werkzeug, das die Qualität der Lernmedien im Cornelsen

Abb. 6. LOUIS: Best-PracticeBeispiele Abb. 7. Beschreibung der Übungsbestandteile in LOUIS

57


Schlusszitat

“Designers do need to know more about science and engineering, but without becoming scientists or engineers. We must not lose the special talents of designers to make our lives more pleasurable. It is time for a change. We, the design community, must lead this change.”(Norman) Literatur 1. (BITKOM_Praesentation_Lehrerumfrage_IT_ in_Schulen_09_05_2011_final.pdf) 2. HCD- Prozess ISO-Norm 13407, DIN Deutsches Institut für Normung e.V. (2003), Abb. 8. Suche und Filter in LOUIS

DIN – Taschenbuch 354, Berlin Wien Zürich: Beuth Verlag 3. Krug, S. (2009), Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Problems. New Riders Press 4. Norman, D. (04.07.12), Why Design Education Must Change. http://www.core77.com/blog/ columns/why_design_education_must_ change_17993.asp 5. Richter, M. & Flückiger, M. (2010). Usability Engineering kompakt. Heidelberg: Spektrum Akademischer Verlag 6. Wikipedia (19.06.2012). Digitale Bibliothek. http://de.wikipedia.org/wiki/ Digitale_Bibliothek#cite_ref-DLRM_0-0

Abb. 9. Suche und Filter in LOUIS

Verlag sichert. Indem alle digitalen Produkte im Bereich Üben dieser Qualität entsprechen, entsteht eine fächerübergreifende Cornelsen-User-Experience. Lernmedien zu gestalten, bedeutet für uns Produkte zu entwickeln: –– die passgenau auf die Bedürfnisse der Nutzer abgestimmt sind, –– die redaktions- und lehrwerksübergreifend ähnlich funktionieren und damit die Effizienz der Benutzung erhöhen, –– die medienspezifisch konzipiert werden,

58

–– die die Vorteile des jeweiligen Mediums nutzen, –– die Lernen mit Motivation und Flow verbinden, –– deren User Experience eine Lernerfahrung darstellt, die das gesamte Lehr- und Lernumfeld mit einschließt, –– die auf der Grundlage nutzerzentrierter Produktentwicklungsprozesse entstehen.


Usability Professionals 2012 Praxisberichte

59


Icon Design im großen Stil – Erfahrungen zu Gestaltung und Einsatz von umfangreichen Icon-Bibliotheken Evelina Kirstein DATEV eG Südliche Fürther Straße 18-20 90429 Nürnberg evelina.kirstein@datev.de

Nadine Schoenherr Freie Grafikerin Geibelstraße 4 90459 Nürnberg pink@jetzt-auch-in-farbe.tv

Abstract Icons sind aktuell ein wichtiges Element bei der Gestaltung von Software-Bedienoberflächen. Sie sollen Informationen und Emotionen transportieren, bei der schnellen Orientierung helfen, den Zugang zu Funktionen schaffen und zu einer hohen visuellen Qualität beitragen. Diese Ziele zu erreichen, ist schon bei einer Icon-Bibliothek, die „nur“ in einem Software-Produkt verwendet werden soll, eine Herausforderung. Was aber, wenn eine Icon-Bibliothek konsistent in zahlreichen fachlich komplexen Software-Produkten zum Einsatz kommen soll? Wie kann eine Icon-Bibliothek in diesem Ausmaß gestalterisch hochwertig und trotzdem kosteneffizient konzipiert und umgesetzt werden? Wie lässt sich eine konsistente Verwendung sicherstellen? Wir stellen in diesem Beitrag unsere Erfahrungen bei der Konzeption, Gestaltung und Einführung einer Icon-Bibliothek mit ca. 700 Einzelsymbolen für eine Produktlinie mit zahlreichen Einzelanwendungen vor. Wir benennen Erfolgsfaktoren sowie Risiken und geben Tipps zur Planung und Konzeption derartiger Projekte.

1. Einleitung In den Anfangsjahren der grafischen Bedienoberflächen waren Icons auf den grauen Masken von Business-Software eines der wenigen Mittel für die visuelle Gestaltung. Sie wurden in erster Linie eingesetzt um Funktionsaufrufe in kompakter Form auf den Bedienoberflächen zu positionieren. Durch die technischen Einschränkungen (z. B. Farbtiefe, Dateigröße) hielten sich sowohl die Gestaltungsmöglichkeiten als auch der Aufwand und das notwendige Know-How in Grenzen. Mit der Zunahme der Farbtiefe und den verbesserten technischen Gestaltungsmöglichkeiten gewann das Gestaltungsmittel „Icons“ an Bedeutung. Icons sollen heute nicht mehr nur Funktionsaufrufe oder Statusinformationen darstellen, sondern gleichzeitig auch Emotionen wecken und Markenwerte kommunizieren. Mit der ansteigenden Bedeutung der Icons und den Gestaltungsmöglichkeiten stieg auch der Anspruch an deren visuelle Qualität.

60

Konnten Icons in den Anfangsjahren auch von Nicht-Gestaltern gepixelt werden, bedarf es heute eines umfangreichen Wissens und Erfahrungen sowie geeigneten Gestaltungswerkzeugen, um diesen Ansprüchen gerecht zu werden. Gleichzeitig nahm auch die Anzahl der Funktionen in Softwareprodukten stetig zu. Da sich die Auflösung der Bildschirme nicht in gleicher Weise mitentwickelte, führte es dazu, dass Icons auch einen wichtigen Beitrag zur Verdichtung der Funktionsaufrufe an der Oberfläche leisten mussten. Ein Programm, welches in den 90er Jahren noch mit 50 Icons auskam, weist heute schnell eine Iconanzahl von mehr als 100 Icons auf. Die DATEV eG stellt heute über 200 Anwendungen für Steuerberater, Wirtschaftsprüfer, Rechtsanwälte und deren Mandanten bereit, die sich über Jahrzehnte hinweg entwickelt haben – von den angesprochenen Anfängen der grafischen Bedienoberflächen bis hin zu heutigen modernen User Interfaces für unterschiedliche Geräte. In

Ulf Schubert DATEV eG Südliche Fürther Straße 18-20 90429 Nürnberg ulf.schubert@datev.de

Keywords: /// Icon /// Icon Design /// Symbole

dieser Zeit veränderte sich natürlich auch bei DATEV das Gestaltungsmittel „Icons“ und dessen Erstellung. Am Anfang war die Icon Bibliothek, welche in den Anwendungen zum Einsatz kam, recht überschaubar. Die Gestaltung übernahmen damals die Entwickler der Anwendung in welcher die Icons zum Einsatz kommen sollten. Da neben neuen Funktionen auch neue Programme hinzukamen, wuchs die Icon Bibliothek mit der Zeit stetig an. Durch das „natürliche“ Wachsen der Icon Bibliothek und die vielen unterschiedlichen „Icon-Ersteller“ wuchs auch die Anzahl der unterschiedlichen Designstile in der Icon Bibliothek. Zuletzt beinhaltete die Icon Bibliothek der DATEV ca. 2.000 verschiedene Symbole in unterschiedlichen Designstilen. Um den gestiegenen Ansprüchen hinsichtlich der visuellen Qualität und dem Ziel der Kommunikation von Markenwerten gerecht zu werden, wurde diese Icon Bibliothek in einem großangelegten Projekt neugestaltet und in nahezu allen DATEV Anwendungen eingeführt.


Usability Professionals 2012 Praxisberichte

2. IST-Analyse Bei der Analyse der ca. 2.000 unterschiedlichen Icons fiel auf, dass es für die gleiche Funktion mehrere unterschiedliche Icons gab. Dies führte dazu, dass ein Anwender für ein und dieselbe Funktion bzw. Information in unterschiedlichen Anwendungen auch oft unterschiedliche Icons erlernen musste. Daher war es ein zentrales Ziel der neuen Icon Bibliothek die Anzahl der eingesetzten Icons durch die Vermeidung von Redundanzen zu verringern. Die Icons in den DATEV Anwendungen sollten vereinheitlicht werden – sowohl im Stil als auch in der Bedeutung. In allen DATEV Anwendungen sollen die gleichen Icons für gleiche Funktionen eingesetzt werden, um den Lernfaktor beim Anwender gering zu halten und eine einfache Wiedererkennung zu ermöglichen. Durch den stark kontextbezogenen Einsatz von Symbolen sollen diese ein sinnvoller Bestandteil der Bedienoberfläche werden und keinen Ballast in Form von visuellem Rauschen darstellen. Da die Icons oft aus unterschiedlichen „Zeitepochen“ und von unterschiedlichen „Icon-Erstellern“ stammten, wiesen die Icons einen sehr unterschiedlichen Grad an Erkennbarkeit auf. Neben den visuellen Unterschieden von „einfach gepixelten“ und „professionell gestalteten“ Icons war auch ein deutlicher Unterschied bei der Informationsdichte der Icons erkennbar. Einige Icons beinhalteten lediglich ein Symbol. Andere beinhalteten bis zu 6 Einzelsymbole. Daher war ein weiteres Ziel der Neugestaltung die Verbesserung der Erkennbarkeit der Icons. Weniger, aber klar bebilderte Icons sollen die Erkennbarkeit verbessern und eine schnelle Erfassung unterstützen. [Abb. 1], [Abb. 2]

Abb. 1. alte Icons

Abb. 2. neue Icons

Die unterschiedliche visuelle Qualität der Icons erschwerte weiterhin eine zielgerichtete Kommunikation von Werten und Emotionen im Sinne der Marke DATEV. Daher war ein weiteres Ziel über ein einheitliches Erscheinungsbild der Icons und eine gestalterische Orientierung an der Marke DATEV zielgerichtet Markenwerte und Emotionen in die Gestaltung der Bedienoberflächen einfließen zu lassen. 3. Die neue DATEV Icon Bibliothek Das Iconkonzept für die DATEV Icon Bibliothek basiert auf einer einfachen Formel: Semantik + Syntax + visueller Stil = Icon Durch diese Formel soll erreicht werden, dass die Icons eine einheitliche hohe visuelle Qualität aufweisen und langfristig zum Einsatz kommen können. Die Semantik und die Syntax bestimmen den dauerhaften Grundaufbau sowie den Inhalt der Icons. Der visuelle Stil bestimmt die aktuelle Gestaltungsausprägung, die sich an der Marke orientiert. 3.1. Semantik Die Semantik beschreibt die inhaltliche Bedeutung der Icons. In ihr werden bestimmte Metaphern, beispielsweise ein gelber Pfeil nach unten, einer konkreten Bedeutung, wie z. B. „Importieren“, zugeordnet. [Abb. 3]

Abb. 3. Stammdaten importieren

Die Metaphern stellen einen Bezug zum realen Objekt oder Vorgang her. Durch einheitlich und einmalig verwendete Metaphern und deren Kombination entsteht eine einfach verständliche, klare und wiedererkennbare inhaltliche Bedeutung aller Icons. Für die Semantik wurden zu Beginn der Erstellung der DATEV Icon Bibliothek ca. 200 Grundbedeutungen abgeleitet und festgelegt. Häufig vorkommende oder zentrale Funktionen wurden auf einen gemeinsamen Bedeutungsnenner gebracht und zur Vereinfachung abstrahiert ohne jedoch den Bezug zur Anwendung zu verlieren. Die wesentlichen Herausforderungen bestanden darin, zum einen bestehende Metaphern soweit wie sinnvoll zu übernehmen, damit der Lernaufwand seitens der Anwender möglichst gering bleibt, und zum anderen für komplexe betriebswirtschaftliche Sachverhalte neue eindeutige Metaphern zu entwickeln. 3.2. Syntax

Abb. 4. Syntax

Die Syntax beschreibt den Grundaufbau und die Kombinationsmöglichkeiten der Icons. Sie bildet die Basis für eine einfache Gestaltungssprache. Bei der Kombination mehrerer Symbole innerhalb eines Icons werden so wenig Elemente wie möglich und so viele wie nötig abgebildet. Ist beispielsweise für den Anwender aus dem Kontext bereits eindeutig erkennbar, worauf sich ein einfaches Symbol bezieht, wird auch nur dieses verwendet und auf zusätzliche Symbole verzichtet. [Abb. 4]

61


Die Kombination von Bedeutungen wurde von Anfang an auf eine Anzahl von zwei Symbolen pro Icon beschränkt. Bis auf wenige Ausnahmen konnte diese Regel umgesetzt werden. Ist eine Kombination mehrerer Symbole nötig, „gewinnt“ die für den Anwender dominierende Bedeutung in der am bestmöglichen nachvollziehbaren Kombination. Hierbei wird das Icon in ein Haupt- und ein Zusatzsymbol unterteilt. So können mehrere Haupticons gelistet werden, deren unterschiedliche Funktionen über das Zusatzicon vermittelt werden. 3.2. Visueller Stil Der visuelle Stil beschreibt die aktuellen Gestaltungsmerkmale, wie Farben, Formen und Materialität. Der visuelle Stil wurde in Zusammenarbeit mit der Designagentur designaffairs vom Erscheinungsbild der Marke DATEV abgeleitet.

prägnante Aussage zu unterstützen. Die Darstellung ist zweidimensional und folgt einer fest definierten Farbpalette, die eine realitätsnahe Abbildung von Objekten erlaubt. Sie treten durch leichte visuelle Effekte aus der zweidimensionalen Oberfläche hervor, sind aber niemals aufdringlich. [Abb. 6]

Abb. 6. Funktionsicons

Statusicons dienen lediglich der Informations- oder Statusanzeige und der Typisierung von Elementen, führen aber keine Funktion aus. Sie unterscheiden sich von den Funktionsicons durch weniger haptische Effekte, da sie an der Bedienoberfläche nicht klickbar sind. [Abb. 7]

In der Icon Bibliothek werden 3 visuelle Stile unterschieden: Programmicons, Funktionsicons und Statusicons. Programmicons kennzeichnen ein DATEV Produkt und stehen beispielsweise für den Aufruf einer DATEV Anwendung. Sie besitzen eine markante Grundform, eine Hochglanz-Optik und sind 2-farbig. Die Programmicons zeigen einen ausgeprägten Reihencharakter mit hohem Bezug zur Marke und starkem Wiedererkennungseffekt. [Abb. 5]

Abb. 5. Programmicons

Funktionsicons kennzeichnen Funktionsaufrufe innerhalb einer Anwendung. Sie sind einfach und klar gehalten. Die Kanten sind stark konturiert, um ihre klare und

62

Abb. 7. Statussicons

4. Einführung der neuen DATEV Icon Bibliothek 4.1. Stufenkonzept Für die Einführung der neuen DATEV Icon Bibliothek war eine nahezu gleichzeitige Umstellung der Icons in allen DATEV Anwendungen notwendig. Die Einführung der neuen Icons trat dadurch in direkte Konkurrenz zu anderen Entwicklungsaufgaben. Um diese Umstellung bewerkstelligen zu können war es notwendig, im Vorfeld eine klare Entscheidungslage herbeizuführen. Daher wurde zu Beginn auf hoher

Managementebene festgelegt, in welchen Schritten die Umstellung durchgeführt werden soll und wer gestalterische Entscheidungen bzgl. der Icons treffen darf. Dieser Schritt war besonders wichtig, da das Icon Design in der Vergangenheit in den Entwicklungsteams teilweise zu subjektiven Geschmacksdiskussionen geführt hat. Die Hauptverantwortung für Designentscheidungen lag im Wesentlichen bei der UX Design- und der Marketingabteilung. Den einzelnen Abteilungen wurde durch diese Vorgehensweise zwar eine wichtige Möglichkeit zur Mitsprache in Sachen Fachlichkeit gegeben, zugleich sollten Diskussionen rein geschmacklicher Natur von vornherein unterbunden werden, um den Abstimmaufwand in einem wirtschaftlich sinnvollen Umfang zu halten. Weiterhin wurde die Umstellung in drei Stufen durchgeführt. In der ersten Stufe wurden alle Icons ausgetauscht, die direkt nach dem Öffnen einer DATEV Anwendung sichtbar sind und/oder häufig genutzte Funktionen symbolisieren. In der zweiten Stufe wurden alle Icons umgestellt, die sekundäre Funktionen symbolisieren oder auf der zweiten Interaktionsebene positioniert sind. In der dritten Stufe wurden die restlichen Icons umgestellt. Die Schritte wurden auf die Releasepläne der Anwendungen abgestimmt. Für eine erfolgreiche Umstellung war es wichtig, frühzeitig alle betroffenen Produktverantwortlichen zu informieren. Darüber hinaus war es hilfreich auch die Kollegen in den indirekt betroffenen Fachabteilungen, wie z. B. Service, zu informieren. Zur Vorbereitung der ersten Stufe entwickelte ein kleines internes Designteam zusammen mit dem Designdienstleister designaffairs die Semantik, die Syntax und den visuellen Stil. Dieser wurde an einem kleinen Ausschnitt der Icon Bibliothek verprobt. Anschließend wurden die Abteilungen aufgefordert, eine kategorisierte Bedarfsanalyse der Icons ihrer Anwendung für die Designabteilung zu erstellen und diese mit kurzen Funktionsbeschreibungen zu versehen. Die Umstellung erfolgte dann in direkter Absprache zwischen Designteam und Fachabteilung.


Usability Professionals 2012 Praxisberichte

4.2. Prozessdefinition Die Erfahrung zeigte, dass es nicht nur wichtig ist, die Verantwortlichkeiten im hohen Management zu vereinbaren, sondern ebenso wichtig ist eine Definition des Prozesses für die Erstellung von Icons und den Umgang mit Konfliktfällen. Wird dies zu spät berücksichtigt, kann es zu erhöhten Aufwänden und Motivationsverlusten kommen. –– Icons für die DATEV Icon Bibliothek werden in folgenden Schritten erstellt: –– Die Fachabteilung listet alle notwendigen Funktionen für die DATEV Anwendung in einer Iconliste auf. Diese beinhaltet das alte Icon, Name und eine kurze Beschreibung der Funktion. –– Der verantwortliche Designer lässt sich von der Fachabteilung die Anwendung und/oder die Funktionen genau erklären. –– Die Funktionsbeschreibungen werden ggf. von den Designern zum jeweiligen Icon in der Iconliste ergänzt. –– In der Semantikrunde wird durch alle Icon Designer geprüft, ob: –– ein Icon für den Kontext sinnvoll und notwendig ist, –– passende vorhandene Icons zugewiesen werden können oder –– eine neues Icon bzw. eine neue Semantik entwickelt werden muss. –– Die neuen Icons werden umgesetzt und zentral abgelegt. –– Die zugewiesenen und neuerstellten Icons werden in der Iconliste der Fachabteilung mit Links zum Ablageverzeichnis ergänzt. Bei Bedarf werden Erläuterungen zur Zuordnung oder Verbesserungsvorschläge zur Vermeidung des Icons gegeben. –– Mit Hilfe der Iconliste wird das Feedback der Fachabteilung eingeholt. –– Bei Kritik, wird geprüft ob es sich um einen fachlich berechtigten Einwand oder Geschmacksdiskussion handelt. –– Bei fachlichen Einwänden wird das Icon überarbeitet. –– Vor der Freigabe werden die Icons im Rahmen einer Pilotphase von Anwendern im Praxiseinsatz evaluiert.

Abb. 8. Ausschnitt der Semantikbibliothek im Styleguide

Bei der Prozessdefinition kann nicht nur der Erstellungsprozess isoliert betrachtet werden. Wenn die Fachabteilungen für sich keine Schnittstellen zu diesem Prozess definieren, steigen die Abstimmaufwände allein durch die Suche nach einem verantwortlichen Entscheider. Daher ist es wichtig, dass die Icon Designer immer einen fachlichen Ansprechpartner pro Anwendung haben. 4.3. Iconerstellung Im Gegensatz zu früher werden Icons nicht mehr mit pixelorientierten Werkzeugen, wie z. B. Paint oder Microangelo, sondern mit Adobe Photoshop erstellt. Um eine effiziente Erstellung in den unterschiedlichen Größen zu erreichen, werden die Icons in Photoshop zuerst mit Vektorpfaden angelegt und ausgearbeitet. Danach werden die Vektorformen mit Ebeneffekten coloriert und für das Pixelraster optimiert. Abschließend werden die Icons in den gängigen Größen und benötigten Formaten mit Hilfe eines Icon DesignPlugins aus Photoshop exportiert.

4.4. Dokumentation Die Icons für DATEV Anwendungen werden an zwei Stellen dokumentiert. Zum einen im Styleguide für DATEV Produkte und zum anderen im zentralen Dateisystem der DATEV. Die Dokumentation im Styleguide beinhaltet die Semantik und beschreibt die Gestaltungsregeln für die Erstellung von Icons. Weiterhin werden dort Empfehlungen zur Auswahl des richtigen Icons und zur Verwendung von Icons auf Masken für Entwickler gegeben. [Abb. 8] Die Ablage der Icons im zentralen Dateisystem folgt einer bestimmten Nomenklatur, um ein einfaches Auffinden der Icons sicherzustellen. Um diese unabhängig von Anwendungen und spezifischen Funktionen zu halten, knüpfen wir die Benennung der Icons an die Semantik der Icons. Jede Kombination wurde mit der Kombination dieser Bezeichnungen benannt. In den Ordnern selbst werden die Icons in den Icon-Standardgrößen bereitgestellt. [Abb. 9]

63


Abb. 9. Ausschnitt des zentralen Ablageverzeichnisses

Abb. 10. Ausschnitt aus der neuen Semantikbibliothek

Diese Nomenklatur hat sich auch bei der aktuellen Größe von 700 Icons als nutzbringend erwiesen. Jedoch reicht sie nicht aus, um die wachsende Anzahl an Icons und deren Zuweisung an die Fachabteilungen zu kommunizieren. Dafür wird momentan ein neuer Ansatz der Dokumentation/ Semantikbibliothek aufgesetzt. Diese Ablage beinhaltet detaillierte Informationen, zu: –– Icon Design Prozess –– Einsatzbereich und -ort der Icons –– Alphabetische Auflistung der Icons mit einer integrierten Suchfunktion –– Name, Bedeutung, Metadaten und Beschreibung –– Link zu dem zentralen Ablageort Ausschnitt der neuen Semantikbibliothek [Abb. 10] 4.5. Zeit und Kosten Im Vorfeld wurde mit einem durchschnittlichen Erstellungsaufwand pro Icon von

64

ca. 0,5 Tagen gerechnet. Hier zeigte sich, dass der Aufwand für hochqualitative Icons zu gering kalkuliert war. Im Projektverlauf erwies sich, dass der durchschnittliche Erstellungsaufwand pro Icon ca. 1 Tag beträgt. Zu diesem Erstellungsaufwand kam dann noch die Zeit für die Bestimmung der Semantik von ca. 2 Stunden und die Abstimmung mit den Fachabteilungen von ca. 0,5-1 Tag hinzu. Somit ist es ratsam bei Projekten mit diesem Umfang und mit einer hohen fachlichen Komplexität der Anwendungen mit einem Gesamtaufwand für die Erstellung eines durchschnittlichen Icons von ca. 2 Tagen zu rechnen. Zuweisung und Kombination von bestehenden Icons sind natürlich deutlich weniger aufwändig. Obwohl die erste Umstellungsphase relativ planmäßig abgeschlossen werden konnte, zeigte sich im weiteren Verlauf, dass vor allem für die Übersetzung der Funktionen in die Semantik mehr Zeit benötigt wurde, als zum Beginn des Projekts. Die reine Erstellung der Icons blieb dagegen

konstant planbar. Die Gründe dafür waren teilweise nachvollziehbar, teilweise sehr unerwartet. Ein besonders einflussreicher Grund war der, dass die Prämisse „So wenig Icons wie möglich, so viel wie nötig“ dazu geführt hat, dass sich die Icon Designer nicht nur auf die Erstellung von Icons konzentrieren konnten, sondern auch Entwürfe für die Bedienoberfläche erstellen mussten. Immer da, wo auf ein Icon verzichtet oder die Komplexität der Icons niedrig gehalten werden sollte, musste die Bedienoberfläche angepasst werden. Nach der Iconanzahl von 700 Icons und der Erstellung der Grundfunktionen, werden auch die Anforderungen an Icons immer spezifischer und komplexer. Zudem sind die inhaltlichen Gestaltungsmöglichkeiten der Semantik nahezu ausgeschöpft. Das bedeutet, die Iconerstellung geht mit der Erfahrung immer leichter von der Hand, jedoch wird die Aufgabe mit zunehmender Anzahl immer komplexer und die Semantik-Bestimmungen beanspruchen immer mehr Zeit.


Usability Professionals 2012 Praxisberichte

4.6. Einbeziehen von Anwendern

„Prozessdefinition“), durch die das Thema „Icons“ in den Hintergrund gerät.

bzw. soll, dass Bedienoberflächen neugestaltet werden müssen.

Es war von Anfang an abzusehen, dass die Umstellung der DATEV Anwendungen auf die neue Icon Bibliothek auch eine Auswirkung auf die Ergonomie haben würde. Um diese möglichst positiv zu gestalten, wurden zum einen bewährte Metaphern soweit wie möglich aufgegriffen und zum anderen Anwenderfeedback zu den neuen Icons eingeholt. Da es finanziell nicht tragbar ist jedes Icon einzeln mittels quantitativer bzw. qualitativer Erhebungsmethoden zu evaluieren, erfolgt die Evaluation im Rahmen der Pilotphasen. Pilotphasen gehen bei DATEV immer der Marktfreigabe voraus und haben das Ziel, Änderungen in den Produkten im Praxiseinsatz zu testen. In den Pilotphasen arbeiten ausgewählte Anwender produktiv mit den Systemen und geben intensiv Feedback.

Es ist daher hilfreich, dass der zuständige Designer eng in Kontakt mit den Fachabteilungen steht und Feedback zum Umstellungsfortschritt einholt. Außerdem ist es sinnvoll, wenn der zuständige Designer die Nutzung der Icons in den Anwendungen in regelmäßigen Abständen überprüft und ggf. Verbesserungsvorschläge unterbreitet.

Es ist ratsam vor der großangelegten Umstellung einer Icon-Bibliothek ein kleineres Pilotprojekt durchzuführen, in der mit wenigen Beteiligten die Umstellung im kleinen Rahmen testweise durchgeführt wird. Dadurch wird zum einen die Zeitschätzung konkreter und zum anderen kann der Prozess der Zusammenarbeit leichter definiert werden.

4.8. Gegenseitiges Verständnis

5.2. Gute Icons entstehen nicht nebenbei

Nicht zuletzt sei daraus abschließend unter den gemachten Erfahrungen formuliert: Es ist wichtig, dass Designer und Entwickler ein gemeinsames Verständnis für die Ziele einer Icon-Umstellung haben. Das gegenseitige Verständnis für die Ziele und Herausforderungen des Anderen macht es leichter Hürden für die Einführung von neuen Icons aus dem Weg zu räumen.

Es ist eine große Herausforderung bei der Umstellung von Icons im großen Stil eine Vereinheitlichung und Erneuerung des Iconkonzeptes zu erreichen, ohne zu viel Zeit für Geschmacksdiskussionen zu verschwenden. Da die Umstellung nur in Zusammenarbeit mit den Entwicklungsteams möglich ist, müssen vorab die Rollen und Entscheidungskompetenzen klar definiert werden. Diese Struktur muss auf höchster Ebene vereinbart werden. Hier sollte die Verantwortung und der Prozess der inhaltlichen und gestalterischen Neugestaltung definiert werden. Die Verantwortung für Semantik und die gestalterische Umsetzung sollte ausschließlich bei den Icon Designern liegen, um eine einheitliche Bebilderung von Funktionen zu erreichen und die gestalterische Qualität zu unterstützen. Auch im Designteam selbst sollte ein Projektleiter definiert werden. Dieser koordiniert das Projekt von zentraler Stelle und behält den Überblick über alle Icons und deren Einsatz. Weiterhin ist der Projektleiter für die konzeptionelle Weiterentwicklung des Themas zuständig.

Durch Übernahme von bewährten Metaphern fiel das Anwenderfeedback positiv aus. Von den 700 Symbolen mussten im Nachgang nur ca. 2% der Icons überarbeitet werden. Das Anwenderfeedback fiel erwartungsgemäß sehr gering aus. Die wenigen Rückmeldungen beschränkten sich im Wesentlichen auf Kritiken zu den 2% Icons. Lediglich die stufenweise Umstellung der Icons führt vereinzelt zu gesonderter Kritik. Hier hätten sich einzelne Anwender eine Umstellung in einem Schritt gewünscht. Im Fazit können wir sagen, dass das beschriebene Vorgehen gut geeignet ist, um großangelegte Umstellung von Icons in mehreren Anwendungen durchzuführen. Es ist aus unserer Sicht nicht notwendig Anwender auf eine Icon-Umstellung gesondert vorzubereiten. 4.7. Nachhalten der Umstellung und Qualitätsprüfung Ein Erfolgsfaktor war die manuelle Überprüfung der Umstellung in den Anwendungen. Oft ergeben sich nämlich bei der Entwicklung von Anwendungen für die Fachabteilung unerwartete Hürden (siehe

5. Best Practices 5.1. Analyse ist wichtig Noch vor der Festlegung der Rollen muss eine Analysephase stattfinden. Diese Phase ist wichtig für die Kosten und Aufwandserhebung. In dieser müssen folgende Punkte betrachtet werden: –– Ziel der Icon Bibliothek –– Umfang (Was kann übernommen werden? Was muss erneuert werden?) –– Zeit- und Kostenschätzung –– Anzahl Icon Designer –– Einbeziehen externer Dienstleister Diese Punkte klingen auf den ersten Blick einfach, sind jedoch bei genauer Betrachtung schwierig abzuschätzen. Vor allem die Zeitschätzung für die Erstellung von Icons ist schwierig. Bei der Zeitschätzung sind nicht nur die reine Erstellungszeit, sondern auch die Zeiten für Abstimmung und Bestimmung der Semantik einzuplanen. Weiterhin ist zu überlegen, ob eine Icon-Umstellung auch dazu führen kann

5.3. Große Icon-Bibliotheken brauchen Regeln Für den nutzbringenden Einsatz von Icon Bibliotheken müssen deren Einsatz und die Gestaltungsregeln klar definiert werden. Es ist notwendig, diese Gestaltungsrichtlinien regelmäßig zu überprüfen und ggf. zu detaillieren. Das Regelwerk ist notwendig,

65


um unnötige Diskussionen und damit Iterationen zu vermeiden.

5.5. Auch Designer brauchen Anleitung

Da Icons sehr beliebt sind, um einfach mal schnell eine etwas zu langweilig geratene Bedienoberfläche „aufzuhübschen“, ist ein Styleguide notwendig, der auch die Aufgaben und den Zweck der Icons klar kommuniziert. Im Styleguide sollte auch definiert sein, wie bei der Oberflächengestaltung mit Icons umgegangen werden soll: Wo machen sie Sinn bzw. wo verzichtet man besser darauf? Bei einer Umstellung von Icons sollte aber nicht nur ein Regelwerk geschaffen werden, sondern auch Zeit für die Beratung und Betreuung hinsichtlich der Oberflächengestaltung eingeplant werden.

Noch eine ergänzende Empfehlung ist die Dokumentation und die Wissensverteilung im Designteam. Die Gestaltungsregeln für Icons müssen auch unter den Icon Designern kommuniziert werden. Sie sollten gemeinsam auf demselben Wissensstand sein bzw. stets in Kommunikation stehen. Es ist empfehlenswert, dass die Semantik nicht von jedem Designer allein, sondern in Zusammenarbeit mit den anderen Icon Designern erstellt wird. Die Zuweisung von Icons im Team ist leichter, da das Team gemeinsam den vollständigen Überblick über die komplette Icon-Bibliothek hat. Zusätzlich sollte dokumentiert werden, welches Icon welcher Bedeutung und welcher Funktion zugeordnet wurde. Es ist auch sinnvoll die Gründe für eine derartige Zuordnung zu dokumentieren. Diese Dokumentation hilft die Konsistenz der Icon-Bibliothek zu erhalten.

Designer müssen sich die Zeit nehmen und den nötigen fachlichen Input der Anwendungen einholen, um die Funktion und dessen Einsatz beurteilen zu können. Nur so ist es möglich, die richtige Metapher zu finden und das richtige Icon auszuwählen oder zu erstellen. 5.4. Entwicklerorientierte Bereitstellung Überlegungen zu Ablage- und Suchsystemen sind von Anfang an wichtig. Die Einführung eines eigenen Ablagesystems für Icons ist aber nicht zwingend notwendig. Das Ablagesystem für die Icons muss sich an der Arbeitsweise der Entwickler und deren Entwicklungswerkzeugen orientieren. Bei der Auswahl eines speziellen Ablagesystems für Icons sollten folgende Aspekte berücksichtigt werden: –– Icons müssen für die Entwickler schnell und einfach zugänglich sein. –– Das Ablagesystem muss unterschiedliche Größen und Formate verwalten können. –– Regelungen für die Verwendung von Icons sollten hinterlegt werden können. –– Die Icons sollten anhand von Bedeutung, zugeordneter Funktion und Einsatzort durchsuchbar sein.

66

6. Ausblick Icons werden auch in Zukunft ein wichtiges Gestaltungselement für Bedienoberflächen sein. Allerdings werden sich Einsatzzweck und Häufigkeit verändern. Icons werden zukünftig stärker kontext- und nutzungsorientiert eingesetzt. „So viel wie nötig und so wenig wie möglich“ ist der Leitsatz der neuen Gestaltung. Der aktuell häufig zu beobachtende Ansatz, dass Icons zur Verdichtung und Platzgewinnung auf Oberflächen eingesetzt werden, ist zukünftig nicht mehr tragfähig. Der Trend in der Oberflächengestaltung geht generell in Richtung Vereinfachung und Spezialisierung. Im Mittelpunkt stehen nicht mehr Funktionsvielfalt, sondern die Arbeitsprozesse der Anwender. Aber nicht nur der Einsatzzweck und die Häufigkeit von Icons werden sich stärker dem Nutzen beugen und dadurch das Arbeiten einfacher gestalten. Auch die

visuelle Gestaltung von Icons wird sich wandeln. Sie werden stärker als visuelles Hilfsmittel verwendet, welches die Aufmerksamkeit der Anwender leiten und lenken soll. Die Positionierung und der Einsatz der Icons müssen daher kritischer bewertet und der visuelle Stil eher vereinfacht werden. Die Wichtigkeit von Haptik und Materialität bei der Gestaltung von Icons nimmt ab. Die Emotionalisierung von Bedienoberflächen wird zukünftig nicht über Icons zu bewerkstelligen sein, sondern ergibt sich aus der gesamten Interaktionsgestaltung einer Anwendung. Ein schönes Beispiel an dem man diese Entwicklung nachvollziehen kann, ist die Designsprache Metro von Microsoft. Bei dieser werden Icons häufig einfarbig und ohne jeglichen Effekte dargestellt. Hervorhebungen mit Farbakzenten und Animationen werden zur Aufmerksamkeitssteuerung oder Informationsvermittlung verwendet. Icons bleiben wichtig, jedoch dominieren sie in Zukunft nicht mehr den Arbeitsbereich sondern finden ihre Rolle unscheinbar im Nutzungskontext der Anwendung. Sie wandeln sich vom Schmuckelement zum nutzenstiftenden Gestaltungsmittel.


Workshops

67


Workshop des Arbeitskreises „Usability in der Medizintechnik” Melanie Aust QIAGEN GmbH melanie.aust@qiagen.com

Oliver Jacobs ergonomics. oliver.jacobs@mac.com

Abstract Bei der Entwicklung von Medizinprodukten ist die Anwendung eines Usability Engineering Prozesses per Normen vorgeschrieben. Dadurch sollen Gefährdungen hervorgerufen durch Benutzungsfehler durch Patienten, Anwender und Dritte minimiert werden. Der neu gegründete Arbeitskreis „Usability in der Medizintechnik“ versteht sich als Austauschplattform für Medizinprodukte-Hersteller und Usability Dienstleister und möchte somit praktische Tipps für die Umsetzung der Normen liefern.

1. Usability in der Medizintechnik? Usability Engineering ist für Medizinprodukte (auch In-vitro-Diagnostikum (IVD) Produkte1) in Europa verpflichtend gemäß DIN ISO 62366 (Usability Engineering to medical devices). Neben der Tatsache, dass eine gute Usability nicht nur ein herausstellendes Qualitätsmerkmal darstellt (Abgrenzung zu Konkurrenzprodukten), führt Usability Engineering vor allem zu <FETT> sichereren Medizinprodukten. Eine schlechte Usability kann bei Medizinprodukten unter Umständen tödlich sein. Das Usability Engineering für Medizinprodukte soll zum einen eine effektive, effiziente und zufriedenstellende Anwendung (auch für ungelernte Kräfte oder den Patienten selbst) sicherstellen, zum anderen die Risiken für Benutzer, Patient und Umgebung auf Grund von Benutzungsfehlern minimieren. Zusätzlich gilt: –– Usability ist Erwartung der Benutzer (Kunden) –– Usability beeinflusst in wieweit Kunden eine Marke wahrnehmen. –– Usability Engineering kann dabei helfen,

68

–– sich von Wettbewerbern zu unterscheiden, abzuheben. –– Entwicklungskosten zu sparen. –– Kundenreklamationen und Serviceaktivitäten zu reduzieren. –– Usability Engineering macht ein Produkt erfolgreich und steigert den Verkauf und ROI (Return on Investment) Ein Beispiel für ein erfolgreiches Usability Engineering in der Medizintechnik stellt die Entwicklung der Automatisierten Externen Defibrillatoren (AED) dar. Sie zeigt, wie aus einem professionellen Apparat, der für die Benutzung durch ausgebildetes Personal ausgelegt ist, durch Reduktion der Funktionen und benutzerzentriertes Design ein Gerät entwickelt wurde, das von Laien effizient benutzt werden kann, um Leben zu retten. Allerdings haben einige Untersuchungen (z. B. Polikaitis, A., 2005 [2]) gezeigt, dass es auch bei den AEDs Unterschiede in der Usability gibt, die zum Beispiel auf die Bezeichnung der Knöpfe, Art der Sprachanweisungen oder Anordnung der Anzeigeleuchten zurückzuführen ist. Für den Benutzer verständliche und eindeutige Anweisungen bzw. Anzeigen vereinfachen die Bedienung, vermeiden

Tobias Walke User Interface Design GmbH tobias.walke@uid.com

Keywords: /// Medizinprodukte /// Usability Engineering /// Risikomanagement /// DIN EN 60601-1-6 /// DIN EN 62366

Fehler und verkürzen die Zeit bis zur erfolgreichen Benutzung. Zeit, die in diesem Fall überlebenswichtig ist. 2. Das Zusammenspiel mit dem Risikomanagement Die Idee der oben genannten Normen ist, dass Usability Engineering und Risikomanagement eng verzahnt miteinander arbeiten sollen. Im Risikomanagement geht es darum, Risiken zu identifizieren und nach deren Schweregrad und Auftretenswahrscheinlichkeit zu bewerten. Durch Konzeptarbeit werden im Usability Engineering geeignete Maßnahmen zu definiert, um sie zu beseitigen oder soweit wie möglich zu minimieren, falls sie nicht gänzlich zu beseitigen sind. Umgekehrt kann Usability Engineering dazu dienen, noch nicht bekannte Gefährdungen aufzudecken, beispielsweise durch Beobachtung der Benutzer in ihrem typischen Nutzungskontext. Risikomanagement ermöglicht, Risiken früh zu erkennen bevor sie zu einer Gefährdung für Patienten, Benutzer oder auch Dritten zu werden. Da Änderungen im Entwicklungsprozess mit voranschreitender Zeit exponentiell teurer werden, hilft Risikomanagement Kosten zu


Usability Professionals 2012 Workshops

reduzieren und nicht zuletzt die Qualität insbesondere bezüglich Sicherheit – zu erhöhen. Gerade bei der Entwicklung von Medizinprodukten ist es äußerst relevant, Risiken aufzuzeigen und mit ihnen umzugehen, auch um die Zulassung des Produkts zu gewährleisten. Deswegen ist ein ausführliches Risikomanagement hier weitgehend implementiert. Die Zusammenarbeit von Usability Engineering und Risikomanagement funktioniert in beide Richtungen: Auf der einen Seite bereichert das Usability Engineering durch Identifikation der Benutzer und des Nutzungskontextes das Risikomanagement in einer frühen Phase, indem es Risiken in Form von möglichen Fehlbedienungen erkennt. In einer späteren Phase (in der Usability Verifikation und Usability Validierung) gibt das Risikomanagement die Grundlage für die Prüfung, ob die Risikominimierung bzw. -beseitigung erfolgreich umgesetzt wurde oder ob durch ein fehlerhaftes Bedienkonzept neue Risiken entstanden sind, die es zu beseitigen gilt. Die Kombination von Risikomanagement und Usability Engineering ist damit notwendig, um letztendlich ein sicheres und qualitativ hochwertiges Produkt zu schaffen. 3. Ziel des Arbeitskreises Der Arbeitskreis bietet zunächst eine Austauschplattform für Hersteller, Dienstleister, Usability Experten, Benannte Stellen und sonstige Interessenten, die in die Entwicklung von Medizinprodukten eingebunden sind. Erfahrene genauso wie unerfahrene Arbeitskreis-Mitglieder können hier über typische Themenfelder des Usability Engineering bei Medizinprodukten, wie zum Beispiel verwendete Methoden, normative Vorgaben oder die Abstimmung mit dem Risiko Management diskutieren. Ein vorrangiges Ziel des Arbeitskreises ist es dabei, einen kompakten Leitfaden zu veröffentlichen, der zu den sehr theoretischen Inhalten der Normen DIN EN

60601-1-6 und DIN EN 62366 praktische Beispiele zur Umsetzung liefert. 4. Warum ein Leitfaden? Die beiden Normen zum Usability Engineering bei Medizinprodukten zeigen einen Prozess auf und nennen beispielhaft Methoden, die angewendet werden können, um den Benutzer in die Entwicklung mit einzubeziehen. Diese Beispiele werden allerdings nur sehr rudimentär beschrieben und lassen deshalb für Hersteller, die zum ersten Mal mit diesem Thema in Kontakt kommen, sehr viele Fragen offen. Ebenso sind die Artefakte (Spezifikation der Anwendung, Hauptbedienfunktionen, Spezifikation der Gebrauchstauglichkeit etc.) beispielhaft an einem Fieberthermometer dokumentiert. Da viele Medizinprodukte aber wesentlich komplexer sind und Software und Displays enthalten, ist es für die meisten Hersteller kaum möglich hiervon etwas auf die Entwicklung ihrer eigenen Medizinprodukte zu übertragen.

Der im Arbeitskreis entstehende Leitfaden soll die Vorgaben der Normen mit den Erfahrungen aus der Praxis der Mitglieder anreichern, um so zusammengefasst und auf den Punkt gebracht einen schnellen Ein- und Überblick über Methoden und Dokumentation des Usability Engineering zu liefern. Der Leitfaden soll dabei unterstützen die entsprechenden Usability Engineering Aktivitäten an den entsprechenden Stellen im Produktentwicklungszyklus zu integrieren. Des Weiteren soll die Frage gestellt werden, was der Unterschied zwischen Usability Verifikation und Usability Validierung ist. Es soll kein zweites umfangreiches Regelwerk parallel zu den Normen entstehen, sondern eine kompakte Broschüre, die vieles, sofern möglich, visuell darstellt, statt in vielen Worten beschreibt. 5. Was sind die Themen? Der Leitfaden soll vor allem die geforderten Inhalte und Prozess-Meilensteine der

69


Normen DIN EN 60601-1-6 und DIN EN 62366 aufgreifen, deshalb wurde von den Mitgliedern des Arbeitskreises vorab die folgende Struktur beschlossen: –– Warum dieser Leitfaden? –– Welche Vorteile bringt gute Usability? –– Wieso benötige ich Usability Experten? –– Wie integriere ich Usability Engineering in bestehende Prozesse? –– Spezifikation der Anwendung – Die Benutzer kennen lernen –– Hauptbedienfunktionen – Was sind die tagtäglichen Aufgaben? –– Spezifikation der Usability – die Anforderungen festlegen –– Verifizierung der Usability – die Anforderungen prüfen –– Validierungsplan der Usability – die Prüfung planen –– Begleitdokumente – alles was der Benutzer zum Lesen bekommt –– Validierung der Usability – die Kür am Schluss –– Das UEF als physikalisch vorhandenes Dokument –– Literatur zum Thema –– Glossar –– Autoren Diese Struktur lebt von der Mitarbeit der Mitglieder und deren Erfahrungsschatz. Die einzelnen Punkte werden während der Entstehung des Leitfadens immer wieder diskutiert, weshalb sie sich noch weiterentwickeln werden und Inhalte hinzukommen oder wegfallen können. 6. Wie geht es weiter? Die Erstellung des Leitfadens erfolgt kollaborativ über ein Google Docs Dokument, das allen Mitgliedern ermöglicht, Inhalte zu schreiben, zu kommentieren oder auch zu ändern. Der Arbeitskreis trifft sich in regelmäßigen Abständen virtuell in Webkonferenzen, um bereits vorhandene Inhalte zu diskutieren, die nächsten Schritte zu planen oder sich ganz allgemein über Usability Methoden bei der Entwicklung von Medizinprodukten zu unterhalten.

70

Hierbei sollen typische Fragen diskutiert und beantwortet werden, wie zum Beispiel –– Welche Methoden setze ich für ein effizientes Usability Engineering ein? –– Ist es wichtiger zu dokumentieren oder sich an den Prozess selbst zu halten? –– Wie kann ich als Usability Experte mit dem Risiko Manager zusammen arbeiten? –– Wie setze ich Akzeptanzkriterien für die Validierung auf? –– Wie viele Teilnehmer lade ich zur Validierung ein? –– Wie validiere ich die Begleitdokumente? –– … Solche und ähnliche Fragen waren auch Gegenstand des auf der UP 12 veranstalteten Workshops zum gleichnamigen Thema. Dieser wurde von den Arbeitskreis Mitgliedern durchgeführt um auch NichtMitgliedern die Möglichkeit zu geben, diese Themenfelder zu diskutieren und einen Austausch in einer größeren Gruppe als dem Arbeitskreis zu ermöglichen. Die Ersteller des Leitfadens hatten somit die Möglichkeit weitere Vorgehens- und Sichtweisen beim Usability Engineering in der Medizintechnik zu erfahren. Die Ergebnisse fließen somit direkt und auch indirekt in die Erstellung des Leitfadens mit ein. Interessenten, die an einer Mitarbeit im Arbeitskreis und dem Leitfaden interessiert sind können sich gerne beim AK Leiter Tobias Walke unter tw@germanupa.de melden.

Literatur 1. Europäisches Parlament (1998), Richtlinie 98/79/EG des Europäischen Parlaments und des Rates über In-vitro-Diagnostika, Straßburg 2. Polikaitis,A (2005), The Usability of Five Automated External Defibrillators by Minimal Trained Bystanders, University of Illinois Medical Center, Chicago

1

IVD (In-vitro Diagnostikum)

aus Richtlinie 98/79/EG Als In-vitro-Diagnostikum im Sinne der Richtlinie gilt jedes „Medizinprodukt“, das als Reagenz, Reagenzprodukt, Kalibriermaterial, Kontrollmaterial, Kit, Instrument, Apparat, Gerät oder System — einzeln oder in Verbindung miteinander — nach der vom Hersteller festgelegten Zweckbestimmung zur In-vitro-Untersuchung von aus dem menschlichen Körper stammenden Proben, einschließlich Blut- und Gewebespenden, verwendet wird und ausschließlich oder hauptsächlich dazu dient, Informationen zu liefern: –– über physiologische oder pathologische Zustände oder –– über angeborene Anomalien oder –– zur Prüfung auf Unbedenklichkeit und Verträglichkeit bei den potentiellen Empfängern oder –– zur Überwachung therapeutischer Maßnahmen.


Usability Professionals 2012 Workshops

71


Wie testet man soziale Software und deren soziale Mechanik? Neue methodische Aspekte und Diskussion eines komplexen Untersuchungsgegenstandes. Dr. Theo Held SAP AG, UX Dietmar-Hopp-Allee 16 69190 Walldorf theo.held@sap.com

Jürgen D. Mangerich SAP AG, UX Dietmar-Hopp-Allee 16 69190 Walldorf j.mangerich@sap.com

Abstract Soziale Software und die ihr zugrundeliegenden interaktiven Prinzipien sozialer Mechanik gewinnen in nahezu allen Bereichen der Softwareindustrie zunehmend an Bedeutung. Neben der Frage nach einem attraktiven und gut nutzbaren Design solcher Software gewinnt natürlich auch eine dem Gegenstand angemessene Evaluation immer mehr an Bedeutung. Schon bei oberflächlicher Betrachtung wird klar, dass klassische Untersuchungsverfahren wie formative Usability Tests nur in erweiterter oder modifizierter Form die Spielarten sozialer Mechanik erfassen und zugrundeliegende Fragestellungen beantworten können. In unserem Beitrag stellen wir einen methodischen Ansatz vor, der weitgehend auf spezielle Aspekte sozialer Software abgestimmt ist. Die Anwendung des Ansatzes illustrieren wir an einem praktischen Beispiel. Wesentlicher Bestandteil des Workshops soll es aber sein, weitere Aspekte zu dieser Thematik zu sammeln und zu diskutieren und darauf aufbauend das einschlägige Methodenrepertoire zu erweitern und somit Praktikern unmittelbar verwendbare Werkzeuge zur Evaluation sozialer Software an die Hand zu geben.

1. Einführung und Fragestellung

menschliches Sozialverhalten zu übertragen (Ward, 1900; Winarski, 1900).

Mit der enormen Verbreitung und dem großen Erfolg „Sozialer Software“ liegt es nahe, typische Elemente sozialer Software in Business Software zu integrieren. Unter Sozialer Software verstehen wir in diesem Rahmen alle Softwareprodukte oder deren Bestandteile, die die Kommunikation oder Kollaboration von Nutzern fördern oder unterstützen. Der Begriff „soziale Mechanik“ steht in diesem Kontext für die Grundprinzipien sozialer Interaktion, die innerhalb sozialer Software zum Tragen kommen und diese letztendlich zu sozialer Software machen. Beispiele für solche Prinzipien sind „Teilen von Information“, „Kollaboration mit sozialen Kontaktpersonen“ oder auch „Belohnung von Verhalten“. Interessanterweise wurde der Begriff „soziale Mechanik“ von den Soziologen Leon Winiarski und Lester Frank Ward geprägt, die bereits Anfang des zwanzigsten Jahrhunderts versuchten, die Prinzipien der Thermodynamik in Analogie auf

Zu typischen Elementen Sozialer Software, die von Prinzipien sozialer Mechanik Gebrauch machen, zählen kollaborative Funktionen wie virtuelle Diskussionsräume oder auch dynamische Kommunikationsmöglichkeiten wie Feeds (d. h. automatisch aktualisierte Listen von Informationseinheiten und Kommunikationsbeiträgen). Mit der Verwendung solcher Funktionen geht stets die Frage einher, wie diese Funktionen und deren fundamentale Konzepte in sinnvoller und realitätsnaher (d. h. ökologisch valider) Weise empirisch evaluiert werden können. Insbesondere muss überlegt werden, ob neue Evaluationsmethoden oder Modifikationen von Standardmethoden erforderlich werden.

72

In klassischen formativen Verfahren wird üblicherweise ausgehend von einer Reihe inhaltlicher Fragestellungen eine Menge von Aufgaben konstruiert, deren Anforderungen und Lösungswege Aufschluss

Keywords: /// Soziale Software /// Soziale Mechanik /// Usability Test /// Paper Prototyping /// kollaborative Szenarien

über die Fragestellungen geben sollen. Typischerweise liegt ein wohl definierter Ausgangszustand vor, der mit Hilfe der zu testenden Software in einen ebenfalls bekannten Endzustand überführt werden soll. Der Ansatz eines klassischen formativen Tests ist somit grundsätzlich determiniert. Für den Weg vom Ausgangszustand zum Ziel existiert meist eine kleine Menge möglicher Alternativen. Es liegt nun nahe, die Sachlage aus dem Blickwinkel der traditionellen Problemlöseforschung zu betrachten. Im Sinne der Problemtypen nach Dörner (1987) liegt bei solchen Tests lediglich eine Synthesebarriere vor, d. h. die Mittel der Zielerreichung sind – im Gegensatz zum Ziel – zunächst unbekannt. Im Falle sozialer Software hingegen werden Faktoren wirksam, die im klassischen formativen Test nicht berücksichtigt werden (können). In kollaborativen Szenarien oder auch bei den unterschiedlichen Formen dynamischer Kommunikation kommt es häufig zu nicht vorhersehbaren Ereignissen, die eine unmittelbare Reaktion des


Usability Professionals 2012 Workshops

Nutzers erforderlich machen und die – in Abhängigkeit von dieser Reaktion – den Ablauf einer Interaktionssequenz erheblich beeinflussen. Der entsprechende TestAnsatz muss somit dem indeterminierten, probabilistischen Charakter der Situation Rechnung tragen. Typische Ereignisse sind z. B. Anfragen über einen Kommunikationsfeed oder mehr oder weniger beliebige Aktionen von Teilnehmern einer Kollaboration. Unabhängig von der wichtigen Frage, wie solche Ereignisse innerhalb eines Tests simuliert werden können, führen die Ereignisse auch dazu, dass man in solchen Szenarien mit einem völlig anderen Problemtypus wie in klassischen formativen Tests zu tun hat; lediglich der Ausgangspunkt ist üblicherweise – aber nicht zwingend – wohl definiert. Bedingt durch die nicht vorhersehbare Wirkung dynamischer Ereignisse hat man es jedoch mit einer sehr großen Menge möglicher Wege zu einem insgesamt deutlich weniger klar definierbarem Zielzustand zu tun. Üblicherweise kann als Ziel nur die prinzipielle Erledigung einer bestimmten Aufgabe dargestellt werden, wobei nicht klar vorhergesagt werden kann, in welchem Zustand sich das benutzte System nach Erledigung befindet und auf welchem Weg die Erledigung bewerkstelligt wurde. In der Terminologie von Dörner (1987) ist von einer Kombination von Synthesebarriere und dialektischer Barriere (d. h. die Präzisierung des Ziels erfolgt erst während der Bearbeitung einer Aufgabe) auszugehen. Unsere hauptsächliche Frage ist somit, wie diesem für Usability-Tests speziellen Problemtyp methodisch Rechnung getragen werden kann. Im folgenden Abschnitt schlagen wir einige Ansätze vor. 2. Elemente einer Testprozedur für soziale Software In dem vorgeschlagenen Ansatz zum Testen sozialer Software wird berücksichtigt, dass –– für den Nutzer unvorhergesehene Ereignisse während des Tests auftreten können,

–– der Nutzer in nicht (genau) vorhersehbarer Weise auf diese Ereignisse reagiert, –– das zu untersuchende System während der Testprozedur sehr unterschiedliche und zum Teil unvorhersehbare Zustände annehmen kann, –– der Testmoderator auf alle neuen Situationen in angemessener Weise reagieren muss und somit verschiedene situationsbezogene Varianten von Untersuchungsmaterial verfügbar sein müssen. Typische unvorhergesehene Ereignisse während des Tests sozialer Software sind das Erscheinen von Nachrichtentexten, die automatische Aktualisierung von Kommunikationsfeeds, das Erscheinen visueller Indikatoren, die z. B. auf neue Informationen hinweisen oder direkte Reaktionen sozialer Kontaktpersonen auf Aktionen des Nutzers. Die Simulation solcher Ereignisse und Interaktionen ist aus Wizzard-Of-Oz Experimenten bekannt. In solchen Experimenten werden Ereignisse, deren Verursachung einem Computersystem zugeschrieben wird, von einer unsichtbaren Person in Abhängigkeit von den Aktionen des Probanden an dafür vorgesehenen Stellen erzeugt. In dem von uns beschriebenen Fall ist jedoch für den Probanden üblicherweise klar, dass die Ereignisse durch eine soziale Kontaktperson bedingt sind. Für die von uns vorgeschlagene Vorgehensweise ist es somit auch nicht erforderlich, die Ereignisse „verdeckt“ zu simulieren. Sofern ein funktionaler elektronischer Prototyp in der Testprozedur verwendet wird, ist es aber prinzipiell möglich, dass eine Person außerhalb des Testraums die benötigten Ereignisse und Reaktionen auf die Aktionen des Probanden direkt erzeugt. Diese Vorgehensweise erfordert jedoch einen bereits umfangreich entwickelten Prototyp, da es möglich sein muss, mit ihm alle benötigten Systemzustände (als Reaktion auf die Aktionen des Probanden oder auch des Eventers) zu erzeugen. Befindet sich ein Softwareprodukt oder die ihm zugrundeliegenden Interaktionskonzepte noch in der Entwurfsphase(auf die wir mit unserem Ansatz hauptsächlich abzielen), ist diese Vorgehensweise somit keine Option.

Um möglichst passend auf (Re-)Aktionen des Probanden eingehen zu können und auch einen möglichst hohen Erkenntnisgewinn aus der Testprozedur sicher zu stellen, schlagen wir vor, statt elektronischer Prototypen ausgedruckte Materialien für den Test sozialer Software zu verwenden. Zum einen bietet sich eine Vorgehensweise im Sinne des klassischen Paper-Prototypings an. Ein großer Vorteil der Verwendung von Papier-Prototypen ist die hohe Flexibilität, die dem Versuchsleiter gegeben ist und die es ihm ermöglicht, sehr dynamisch und hoch adaptiv auf alle Aktionen des Versuchsteilnehmers zu reagieren. Eine sehr gelungene und praxisorientierte Einführung in das Thema gibt Snyder (2003). In unserem Ansatz verwenden wir Papierprototypen, deren Erscheinungsbild noch relativ weit vom realen Aussehen eines Bildschirminhalts entfernt ist, sogenannte „low-fidelity Prototypen“. Vorteile dieser eher abstrakten Darstellungsweise sind die niedrigen Entwicklungskosten und die klare Fokussierung auf Interaktion und Informationsarchitektur. Auch versetzt ein „unfertiges“ und skizzenartiges Erscheinungsbild des Reizmaterials erfahrungsgemäß den Probanden in die Lage leichter und freier auf sein kognitives Modell zu assoziieren. Die Verwendung der teureren „high-fidelity Prototypen“ birgt häufig die Gefahr, dass ein weitgehend ausgearbeitetes visuelles Design von den zu einem frühen Zeitpunkt zu untersuchenden kritischen Eigenschaften eines Konzeptes ablenkt. Ein übersichtlicher Vergleich von low vs. high fidelity Prototypen findet sich z. B. bei Rudd, Stern & Isensee (1996). Wie bei Papierprototypen üblich, werden für unsere Vorgehensweise komplette Bildschirminhalte und deren mögliche Bestandteile vor einem Test hergestellt, um sie dann innerhalb der Testprozedur in Abhängigkeit von den (System-) Ereignissen und den Reaktionen der Probanden darzubieten und zu kombinieren. Die wesentlichen vorgedachten Interaktionssequenzen werden üblicherweise in einer Art „Drehbuch“ festgehalten, dessen Inhalte zumindest der Moderator sehr genau kennen muss. Die Erzeugung spezieller Ereignisse wird vom Moderator oder einer

73


Abb. 1. Materialien für eine Untersuchung

direkt in die Testprozedur eingebundenen weiteren Person (dem sogenannten „Eventer“) übernommen. Das bedeutet, dass die Simulation der Ereignisse durch Austausch oder Modifikation von Bildschirminhalten direkt innerhalb der laufenden Prozedur durchgeführt wird. Da der Proband auch diese Aktionen zur Kenntnis nimmt, ist auch von seiner Seite eine gewisse Abstraktionsleistung erforderlich.

Usability-Tests – neben dem Moderator auch ein trainierter Protokollant zwingend erforderlich. Außerdem sollte jede Sitzung zusätzlich per Video aufgezeichnet werden. Die entstehenden Artefakte (Kombinationen vorgefertigter Bildschirmelemente sowie speziell angefertigte Skizzen) sollten digitalisiert werden. In vielen Fällen können sie direkt in der Konzeptionsphase der Software weiterverwendet werden.

Die zur Erledigung einer gegeben Aufgabe erforderlichen Aktionen und Systemzustände sind teilweise so wenig vorhersagbar, dass auch die Arbeit mit vorgefertigten Elementen einer Nutzungsoberfläche nicht mehr möglich ist. Für diesen Fall schlagen wir vor, die erforderlichen, von Probanden erwarteten Systemzustände unmittelbar in Form handschriftlicher Skizzen herzustellen und mit dem Probanden abzustimmen, ob ein Entwurf seinen Erwartungen entspricht.

3. Ein konkretes Beispiel

Für eine erschöpfende Erfassung eines Versuchsablaufs ist – wie in regulären

74

Der skizzierte Ansatz zum Testen sozialer Software kam in einer Testreihe mit 12 Probanden erstmals zum Einsatz. Testgegenstand waren Konzepte für eine Integration von Nutzerkollaboration, Posteingangsfach und Kommunikationsfeeds. Die Konzepte bzw. Ideen zu deren Zusammenspiel befanden sich zum Zeitpunkt des Tests noch in einer frühen Entwurfsphase. Die Arbeit mit einem elektronischen Prototyp war somit nicht indiziert. Die Testmaterialien lagen als Papierprototypen sowie als

„Blankobildschirme“ zur Erzeugung neuer Systemzustände vor. Abbildung 1 zeigt Beispiele für die verwendeten Materialien. [Abb. 1] Neben den Papierprototypen hatte jeder Proband einen Pfeil aus Pappe zur Verfügung, um die aktuelle Position des MausCursors („Wo würden Sie klicken?“), sowie um den aktuellen visuellen Fokusbereich anzuzeigen. Selbstklebende „Post-Its“ wurden verwendet, um Anregungen und Kommentare der Probanden direkt auf den jeweiligen Seiten zu vermerken. Weitere vorbereitete Elemente wie selbstklebende Ziffern wurden für das Erzeugen von Ereignissen eingesetzt, z. B. um für eine nicht sichtbare Seite anzuzeigen, dass eine neue Nachricht oder ein neuer Feed-Eintrag vorliegt. Abbildung 2 zeigt schematisch den Ablauf für eine Aufgabe, wobei in diesem Beispiel keine während der Prozedur angefertigten Zustände enthalten sind. [Abb. 2] Die Untersuchung wurde von einem Moderator, der auch die Rolle des Eventers


Usability Professionals 2012 Workshops

übernahm, und einer Protokollantin durchgeführt. Die verwendeten Events bestanden zum einen im „Einblenden“ neuer Feed-Nachrichten und im Anbringen visueller Indikatoren für neue Nachrichten oder Feed-Einträge. Die Aufgaben waren als allgemeine Handlungsziele formuliert, ohne in irgendeiner Weise auf das geplante System oder die geplanten Konzepte einzugehen. Die Formulierungen der Aufgaben waren wie folgt: Aufgabe 1: Gerade erscheint eine eMail, dass die Registrierung für die DSAG eröffnet ist. Vielleicht können Sie die Gelegenheit nutzen, und ein paar alte Kollegen treffen. Finden Sie heraus, wer von Ihren Kollegen auch hinfährt. Aufgabe 2: Na prima, es scheinen ja doch ein paar mitzukommen. Um Ihren gemeinsamen Aufenthalt in Leipzig zu planen, führen Sie alle vorhandenen Personen und Informationen zusammen. Aufgabe 3: Martin ist dafür bekannt, dass er immer die besten und günstigsten Hotels findet. Er bekommt deswegen von Ihnen den Auftrag sich um das Hotel zu kümmern. Aufgabe 4: Da warnt Pit vor einem bestimmten Hotel. Stellen Sie sicher, dass Martin über Pits Hinweis informiert wird. Insgesamt wurde die Vorgehensweise von den Probanden sehr gut aufgenommen und das Konzept der intermittierenden Ereignisse wurde gut verstanden. Es war

in jeder der 11 Testsitzungen erforderlich, vom vorgedachten Pfad abzuweichen und ad hoc neue Bildschirm-Varianten herzustellen um den jeweiligen Erwartungen der Nutzer entgegen zu kommen. Die Ergebnisse konnten zum großen Teil direkt in der Weiterentwicklung der Konzepte verwendet werden. Es zeigte sich, dass die Verbindung von Moderation und gleichzeitigem Eventing eine relativ große Herausforderung für den Moderator darstellt. Sofern möglich, ist die Einbeziehung einer Person, die ausschließlich für das Eventing zuständig ist, zu empfehlen. Eine weitere Herausforderung stellt die effiziente Verwendung der vorbereiteten Materialien dar. Da die Verwendung einzelner Seiten oder Seitenelemente schwer vorhersagbar ist, ist eine gute Zugänglichkeit und Organisation der Materialien unbedingt erforderlich.

Unser empirisches Beispiel verwendet nur einen Teil der denkbaren und praktikablen methodischen Vorgehensweisen. Ein Schritt zur Erweiterung des Ansatzes soll der Workshop auf der gUPA 2012 sein. Wir erwarten uns sowohl neue Sichtweisen in Richtung des Untersuchungsgegenstands und in Richtung der möglichen Fragestellungen beim Testen sozialer Software, als auch Erkenntnisse zur Erweiterung der methodischen Herangehensweise. Literatur 1. Dörner, D. (1987). Problemlösen als Informationsverarbeitung (3. Auflage). Stuttgart: Kohlhammer. 2. Rudd, J., Stern, K., & Isensee, S. (1996). Low vs. high-fidelity prototyping debate. Interactions, 3(1), S. 76-85. 3. Snyder, C. (2003). Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces (1. Auflage). San Francisco: Morgan

4. Fazit und nächste Schritte

Kaufmann Publishers. 4. Ward, L. F. (1900). Social Mechanics, Sociology at the Paris Exposition of 1900 (pp.

Der beschriebene methodische Ansatz ist im Wesentlichen eine Kombination bewährter Verfahren, die in ihrer Kombination sehr gut für das Testen sozialer Software geeignet zu sein scheinen. Die Notwendigkeit für die Verwendung dieser speziellen methodischen Kombination ergibt sich insbesondere aus der besonderen Art von Problem mit dem Nutzer bei der Arbeit mit sozialer Software konfrontiert sind. Die meisten Aktionen hängen unmittelbar von den Handlungen, Reaktionen, Signalen oder Entscheidungen anderer Nutzer ab – die Wirkungsprinzipien sozialer Mechanik haben hier einen unmittelbaren Einfluss auf das beobachtbare Verhalten.

1579-1593), Government Printing Office. 5. Winiarski, L. (1900). The Teaching of Pure Political Economy and Social Mechanics in Switzerland, Sociology at the Paris Exposition of 1900 (pp. 1497-1500), Government Printing Office.

Abb. 2. Beispiel für die Bildschirmfolge für eine Aufgabe. Die Ziffern in Kreisen stehen für spezifische Events, die vor dem Übergang zum nächsten Bildschirminhalt erzeugt wurden.

75


76


Methoden + Messung

77


Konstruktion eines Fragebogens für jugendliche Personen zur Messung der User Experience Andreas Hinderks RMT Soft GmbH & Co. KG Carl-Zeiss-Str. 14 28816 Stuhr andreas@hinderks.org

Maria Rauschenberger MSP Medien-Systempartner GmbH & Co. KG Peterstraße 28-34 26121 Oldenburg maria.rauschenberger@medien-systempartner.de

Martin Schrepp SAP AG – User Experience Dietmar-Hopp-Allee 16 69190 Walldorf martin.schrepp@sap.com

Siegfried Olschner DATEV eG 90329 Nürnberg siegfried.olschner@datev.de

Abstract Der User Experience Questionnaire (UEQ) ist ein etablierter Fragebogen zur Messung des Nutzungserlebens, der als semantisches Differential mit 26 Gegensatzpaaren realisiert ist. Fragebögen dieses Typs setzen ein genaues Verständnis der verwendeten Items durch die befragten Personen voraus. Beim Einsatz des UEQ zur Befragung von jugendlichen Nutzern einer Web-Seite wurden Probleme in Bezug auf die Verständlichkeit einiger Begriffe durch diese Zielgruppe beobachtet. Hauptprobleme waren Fremdwörter und Begriffe, deren konkrete Interpretation im gegebenen Befragungskontext ein höheres Maß an Abstraktionsfähigkeit voraussetzt. Um diese Probleme zu beheben, wurde eine spezielle Version des UEQ in einfacher Sprache konstruiert. Wir beschreiben in diesem Beitrag den Konstruktionsprozess und erste Evaluationsstudien dieser Version.

1. Einleitung

Produkts schnell, einfach und kostengünstig messen zu können.

User Experience fasst alle Aspekte zusammen, die für die subjektive Bewertung eines Produkts durch seine Nutzer von Bedeutung sind. Dazu zählen neben klassischen Usability-Aspekten, wie z. B. Effizienz, Steuerbarkeit, Fehlertoleranz oder Erlernbarkeit (siehe z. B. Molich & Nielsen, 1990 oder ISO 9241-110), auch Aspekte wie Joy of Use (Hatscher, 2001; Norman, 2003) oder ästhetisches Design (Kurosu & Kashimura, 1995; Tractinsky, 1997). Die User Experience ist dabei laut Hassenzahl (2010) ein Zusammenspiel aus pragmatischer und hedonischer Qualität, die vor, während oder nach der Benutzung eines Produktes erlebt wird.

Da es sich beim Konzept der User Experience um eine rein subjektive Einschätzung eines Produkts durch seine Nutzer handelt, bieten sich Fragebögen als einfache und kostengünstige Messmethode an. Es existieren hierzu im deutschsprachigen Raum insbesondere die Fragebögen UEQ – User Experience Questionnaire (Laugwitz, Schrepp & Held, 2006) und AttrakDiff (Hassenzahl, Burmester & Koller, 2003).

Eine gute User Experience (=Nutzungserlebnis) ist ein zentraler Faktor für den Markterfolg eines Produkts. Falls hier Probleme bestehen, müssen diese deshalb schnell erkannt und behoben werden. Aus diesem Grund ist es eine wichtige Anforderung, die User Experience eines

78

Wir beschreiben in diesem Beitrag die Konstruktion einer Variante des UEQ für die Zielgruppe jugendlicher Nutzer. Ziel des UEQ ist eine effiziente Messung des Gesamteindrucks, den ein Benutzer in Bezug auf die Interaktion mit einem Produkt entwickelt hat. Der UEQ besteht aus 26 bipolaren Begriffen (Gegensatzpaare), die die Form eines 7-stufigen semantischen Differentials haben, z. B.: kompliziert

einfach

Jörg Thomaschewski Hochschule Emden/Leer Constantiaplatz 4 26723 Emden joerg.thomaschewski@hs-emden-leer.de

Keywords: /// UEQ /// User Experience /// UX Evaluation /// UX Beurteilung

Die Items sind den folgenden sechs Skalen zugeordnet: Effektivität, Durchschaubarkeit, Vorhersagbarkeit, Stimulation, Originalität (jeweils 4 Items), sowie Attraktivität (6 Items). Die Skalen Durchschaubarkeit, Effizienz, und Steuerbarkeit beschreiben aufgabenbezogene (pragmatische) Qualitätsmerkmale eines Produkts. Die Skalen Stimulation und Originalität beschreiben nicht aufgabenbezogene (hedonische) Qualitätsmerkmale. Die Skala Attraktivität ist eine reine Valenzdimension, die eine positive, bzw. negative Einstellung/Befindlichkeit gegenüber dem Produkt darstellt. [Abb. 1] Zusätzlich zur deutschen Originalversion des UEQ sind auch Versionen in englischer, spanischer (Rauschenberger et al., 2012), französischer und italienischer Sprache verfügbar. In mehreren Validierungs-Studien zur deutschen und englischen Version konnte


Usability Professionals 2012 Methoden + Messung

Personengruppen mit eingeschränkterem Wortschatz. Bei Versuchen den UEQ zur Evaluation einer Web-Seite (www.stayblue. de) durch überwiegend jugendliche Nutzer einzusetzen, wurden Schwierigkeiten hinsichtlich der Verständlichkeit einiger Items festgestellt.

Abb. 1. Skalen des UEQ und ihre Beziehung untereinander.

gezeigt werden, dass die Skalen des UEQ eine hohe Reliabilität bzw. Zuverlässigkeit aufweisen. Weiterhin deuten die bisher durchgeführten Validierungs-Studien auf eine zufriedenstellende Konstruktvalidität hin (z. B. Laugwitz, Schrepp & Held, 2006 oder Laugwitz, Held & Schrepp, 2008). Die Items des UEQ wurden über eine Faktorenanalyse aus einem großen Pool von potentiellen Items extrahiert. Details zur Konstruktion des Fragebogens sind in Laugwitz, Schrepp & Held (2006) und Laugwitz, Held & Schrepp (2008) beschrieben. Informationen zum Einsatz des UEQ in verschiedenen Evaluationsszenarien finden sich in z. B. in Laugwitz, Schubert, Ilmberger, Tamm, Held & Schrepp (2009), Rauschenberger, Hinderks & Thomaschewski (2011), Hartmann (2011), Dicke, Jakus, Tomazic & Sodnik (2012), Ebner, Stickel, Scerbakov & Holzinger (2009) oder Wieschnowsky & Paulheim (2011). 2. Probleme beim Einsatz des UEQ mit jugendlichen Nutzern Eine Anwendungsvoraussetzung von semantischen Differentialen ist es, dass die Teilnehmer einer Befragung die Bedeutung der Gegensatzpaare relativ gut verstehen müssen, um ein gutes Ergebnis zu erzielen. Das erschwert den Einsatz bei Nicht-Muttersprachlern oder bei

gründlichen inhaltlichen Analyse durch die Autoren und einem Lehrer unterzogen. Hierbei wurde in mehreren Diskussionen eine Reihe von potentiell problematischen Items identifiziert, d. h. Items bei denen vermutet wurde, dass diese Probleme für Personen den intendierten Zielgruppe bereiten können.

Die beobachteten Schwierigkeiten jugendlicher Nutzer bei der Fragebogenanwendung können dabei in zwei Kategorien eingeteilt werden: –– Das Item enthält Fremdwörter, deren exakte Bedeutung den Nutzern nicht bekannt ist. Beispiele waren die Begriffspaare konservativ – innovativ oder erwartungskonform – nicht erwartungskonform, etc. –– Die Gegensatzpaare des Items sind zwar gängig, aber die Übertragung auf den Kontext der Bewertung eines interaktiven Produkts erfordert ein hohes Maß an Abstraktion und kann daher leicht zu Fehlinterpretationen führen. Ein Beispiel war das Begriffspaar wertvoll – minderwertig.

Alternative Items erzeugen

Diese Überlegungen zeigen, dass der im UEQ verwendete Sprachgebrauch für die intendierte Zielgruppe problematisch ist. Es besteht daher die Gefahr, dass das Ergebnis einer Evaluation durch diese Probleme mit der Verständlichkeit der Items zu stark beeinflusst wird.

Im zweiten Schritt wurden in mehreren Diskussionsrunden der Autoren Alternativen zu den problematischen Items erzeugt. Bei der Konstruktion der alternativen Items wurde versucht, die oben genannten Probleme (Fremdwörter, schwieriger Transfer) zu vermeiden.

3. Erzeugen einer UEQ-Version in vereinfachter Sprache

Insgesamt wurden 27 neue, zusätzliche Items erzeugt. Aus diesen 27 neuen Items und den vorhandenen alten 26 Items wurde eine initiale Version eines Fragebogens erstellt. Die Reihenfolge der Items wurde randomisiert. Pro Item wurde zusätzlich die Reihenfolge des Gegensatzpaares randomisiert.

Das Ziel ist die Konstruktion einer Variante des UEQ, der ohne Verständnisprobleme für die Zielgruppe jugendlicher Nutzer eingesetzt werden kann. In dieser Variante sollen nur diejenigen Items, die für die Zielgruppe potentiell schwer verständlich sind, durch einfacher zu verstehende Items ersetzt werden. Die neuen Items sollen dabei die gleichen Dimensionen messen, wie die ersetzten Items. Analyse des bestehenden Fragebogens

In einem ersten Schritt wurden alle Items des UEQ (siehe Appendix) einer

Insgesamt wurden für die Skala Attraktivität eines von 6 Items als potentiell problematisch identifiziert (attraktiv/unattraktiv). Für die 4 Items der anderen Skalen wurden jeweils folgende Anzahlen von Items als problematisch identifiziert: Effizienz 3 (unpragmatisch/pragmatisch, ineffizient/ effizient, aufgeräumt/überladen), Steuerbarkeit 3 (erwartungskonform/nicht erwartungskonform, sicher/unsicher, behindernd/unterstützend), Durchschaubarkeit 0, Stimulation 2 (wertvoll/minderwertig, aktivierend/einschläfernd) und Originalität 3 (originell/konventionell, konservativ/innovativ, herkömmlich/neuartig).

Dieser initiale Fragebogen wurde in mehreren Erhebungen zur Bewertung interaktiver Produkte verwendet. Datenerhebung

Die Datenerhebung des initialen Fragebogens wurde mit einem Online-Tool innerhalb von zwei Monaten durchgeführt. Zusätzlich zu den Items wurden

79


Bewertetes Produkt

Gesamtanzahl

Verwertbar

Eclipse

8

7

EMP Onlineshop

10

10

KO.PAS

8

8

MS Word

35

29

Visual Studio

13

10

Keine Angaben

11

2

85

66

Tab. 1. Anzahl der ausgefüllten Fragebögen

soziologische Daten, wie Alter, Geschlecht und Ausbildung abgefragt, die in diesem Artikel keine weitere Verwendung finden. Innerhalb des Fragebogens wurde explizit darauf hingewiesen, dass unverständliche Items bzw. nicht intuitiv anwendbare Items übergangen werden sollten.

analysiert, um die am besten passenden neuen Items zu identifizieren. In einem ersten Schritt wurden alle Skalen einzeln über eine Faktorenanalyse betrachtet.

Datenanalyse und Erzeugung einer neuen UEQ Version

Für die Skalen Attraktivität, Durchschaubarkeit und Originalität ergab eine Analyse mit dem Kaiser-Guttmann Kriterium, dass ein einzelner Faktor die Daten bereits ausreichend gut erklärt. In diesem Fall wurden diejenigen neuen Items als Ersatz für die als problematisch markierten Items ausgewählt, die auf diesem Faktor die höchsten Ladungen zeigten. Abbildung 2 zeigt als Beispiel den entsprechenden Scree-Plot der Dimension Attraktivität. [Abb. 2]

Die 66 erhobenen Datensätze wurden in einer mehrstufigen Vorgehensweise

Bei den Skalen Effizienz, Steuerbarkeit und Stimulation ergab die Analyse mit

Der Fragebogen wurde mit 85 Probanden an 5 verschiedenen Produkten angewendet. Von den insgesamt 85 erhobenen Fragebögen waren 66 vollständig bearbeitet und konnten für die Datenanalyse verwendet werden, wie in Tabelle 1 dargestellt. [Tab. 1]

Abb. 2. Scree-Plot für die Items der Dimension Attraktivität (6 Items des UEQ und 2 alternative Items)

80

dem Kaiser-Guttmann Kriterium, dass durch die zusätzlichen Items ein neuer Aspekt in die Skala kam, so dass eine Lösung mit zwei Faktoren besser passte. Abbildung 3 zeigt als Beispiel den ScreePlot der Skala [Abb. 3] In diesem Fall wurde geprüft, auf welcher dieser beiden Dimensionen die Items aus der alten UEQ Skala die höchsten Ladungen zeigten, d. h. dieser Faktor wurde als Repräsentant der alten Dimension betrachtet. Danach wurden die neuen Items, die auf diesem Faktor die höchsten Ladungen aufwiesen, als Ersatz für die zu streichenden Items gewählt. Im zweiten Schritt wurde untersucht, welche Items sehr hohe Korrelationen mit anderen Skalen aufwiesen, d. h. nicht einen abgrenzbaren Faktor repräsentieren, sondern eher unspezifisch auf mehreren Qualitätsaspekten laden. Dies war bei zwei der neuen Items der Fall, die daraufhin durch andere alternative Items aus dem ersten Schritt ersetzt wurden. Als Resultat der Analyse wurden folgende Items der Originalversion ersetzt: –– Skala Attraktivität: –– attraktiv/unattraktiv ersetzt durch schön/hässlich –– Skala Effizienz: –– ineffizient/effizient ersetzt durch zeitraubend/zeitsparend –– unpragmatisch/pragmatisch ersetzt durch stockend/flüssig

Abb. 3. Scree-Plots für die Items der Dimension Steuerbarkeit (4 Items des UEQ und 7 alternative Items).


Usability Professionals 2012 Methoden + Messung

–– Skala Steuerbarkeit: –– behindernd/unterstützend ersetzt durch unbedienbar/bedienbar –– sicher/unsicher ersetzt durch vorhersagbar/unvorhersagbar –– erwartungskonform/nicht erwartungskonform ersetzt durch zuverlässig/unzuverlässig –– Skala Stimulation: –– wertvoll/minderwertig ersetzt durch erfrischend/einschläfernd –– aktivierend/einschläfernd ersetzt durch abwechslungsreich/eintönig –– Skala Originalität: –– originell/konventionell ersetzt durch neu/alt –– herkömmlich/neuartig ersetzt durch veraltet/modern –– konservativ/innovativ ersetzt durch unauffällig/auffällig Das Item aufgeräumt/überladen der Skala Effizienz konnte nicht ersetzt werden, da nur zwei der neuen Items für diese Skala geeignete Ladungen auf dem entsprechenden Faktor zeigten. 4. Items der Version in vereinfachter Sprache Nach diesen Analysen ergab sich folgende neue Version des UEQ für den Einsatz in der Zielgruppe jugendlicher Nutzer interaktiver Produkte. Die gegenüber der Originalversion veränderten Items sind durch fette Formatierung hervorgehoben. [Tab. 2]

1

2

3

4

5

6

7 erfreulich

1

unverständlich

verständlich

2

kreativ

phantasielos

3

schwer zu lernen

4

einschläfernd

5

spannend

6

interessant

7

voraussagbar

8

langsam

9

alt

10

bedienbar

11

schlecht

12

kompliziert

einfach

13

abstoßend

anziehend

14

modern

15

unangenehm

angenehm

16

vorhersagbar

unvorhersagbar

17

eintönig

18

unzuverlässig

19

zeitraubend

zeitsparend

20

übersichtlich

verwirrend

21

flüssig

22

überladen

23

hässlich

24

unsympathisch

25

auffällig

26

unerfreulich

leicht zu lernen erfrischend langweilig uninteressant unberechenbar schnell neu unbedienbar gut

veraltet

abwechslungsreich zuverlässig

stockend aufgeräumt schön sympathisch

5. Validierung

unauffällig

Tab. 2.

Die Verständlichkeit der Items wurde durch einen Experten geprüft. Dieser kam wie erwartet zu der Ansicht, dass die neuen Items wesentlich einfacher zu verstehen sind, was natürlich aufgrund der bei der Konstruktion der Items zugrundeliegenden Grundidee auch zu erwarten war.

Studie 1

In einer ersten kleinen Studie beurteilten 44 Studenten (Studienfach Informatik, Erstsemester) ein soziales Netzwerk (Facebook) bezüglich seiner User Experience. 25 Studenten benutzten die Originalversion des UEQ, während 19 Studenten den neu erstellten Fragebogen nutzten. Wegen der geringen Größe der

Stichprobe, kann diese erste Untersuchung natürlich nur grobe Hinweise bzgl. der Qualität der neuen Version liefern. [Abb. 4] Abbildung 4 zeigt die Skalenmittelwerte der alten und neuen Version des UEQ. Mit Ausnahme der Dimension Steuerbarkeit waren die Unterschiede der Mittelwerte auf dem 5% Niveau nicht signifikant.

81


Abb. 4. Skalenmittelwerte der alten und neuen Version des UEQ anhand von Facebook.

In Bezug auf die Konsistenz der Skalen wurden folgende Werte für Cronbachs Alpha-Koeffizient beobachtet (originale Version/neue Version): –– Attraktivität: 0,94 / 0,93 –– Durchschaubarkeit: 0,80 / 0,77 –– Effizienz: 0,73 / 0,67 –– Steuerbarkeit: 0,68 / 0,83 –– Stimulation: 0,77 / 0,79 –– Originalität: 0,51 / 0,58 Hier unterscheiden sich die beiden Versionen also nicht gravierend. Die Konsistenz der Skalen ist zufriedenstellend, wobei man hier die geringe Stichprobengröße berücksichtigen muss. Einzige Ausnahme ist die Skala Originalität, die bei beiden Versionen einen relativ geringen Wert des Alpha- Koeffizient zeigt. Dies könnte daran liegen, dass dieser Faktor für die Teilnehmer in Bezug auf das bewertete soziale Netzwerk (Facebook) nicht wirklich relevant erschien. Die Unterschiede in der Skala Steuerbarkeit resultierten im Wesentlichen aus einer stark negativen Bewertung des alten Items sicher/unsicher im Vergleich zu den anderen Items der Skala. Hier liegt der Schluss nahe, dass dies im Kontext von sozialen Netzwerken anders interpretiert wurde als intendiert. Dies wurde in Nachgesprächen auch von einigen Teilnehmern explizit angesprochen.

82

Abb. 5. Skalenmittelwerte der alten und neuen Version des UEQ anhand einer Buchhaltungs-Software.

Ein weiteres Problem ergab sich bei dem Item zeitraubend/zeitsparend der neuen Version. Dieses unterschied sich bzgl. seines Mittelwerts (-1,3) gravierend von allen anderen Items der Skala Effizienz. Auch hier liegt nahe, dass dieses Item im Kontext sozialer Netzwerke anders als gedacht (z. B. als soziale Netzwerke rauben mir meine Zeit, da ich mich dort zu oft aufhalte) interpretiert wurde. Dies wurde ebenfalls von einigen Teilnehmern nach der Untersuchung explizit erwähnt. Als Konsequenz aus dieser Beobachtung wurde dieses Item durch das alte Item ineffizient/effizient aus dem Originalfragebogen ersetzt.

In Bezug auf die Konsistenz der Skalen wurden folgende Werte für Cronbachs Alpha-Koeffizient beobachtet (originale Version/neue Version): –– Attraktivität: 0,83 / 0,82 –– Durchschaubarkeit: 0,82 / 0,82 –– Effizienz: 0,28 / 0,43 –– Steuerbarkeit: 0,73 / 0,67 –– Stimulation: 0,82 / 0,83 –– Originalität: 0,86 / 0,77

Studie 2

6. Zusammenfassung

In einer zweiten Studie beurteilten 31 Nutzer einer Buchhaltungs-Software für Altenpflegeeinrichtungen die Anwendung mit einem Fragebogen, der die Items der alten und der neuen UEQ Version enthielt. Abbildung 5 zeigt die Skalenmittelwerte der alten und neuen Version des UEQ, d. h. für die Items des kombinierten Fragebogens wurden zwei Auswertungen erstellt (Item der alten Version / Items der neuen Version). [Abb. 5] Die Unterschiede sind auf dem 5% Niveau nicht signifikant.

Bis auf die Skala Effizienz sind die beobachteten Werte durchaus zufriedenstellend. Woraus die geringe Reliabilität der Effizienz-Skala in beiden Versionen resultiert, war nicht schlüssig zu klären.

Aufgrund beobachteter Verständnisprobleme jugendlicher Nutzer wurde eine Version des UEQ in einfacher Sprache erstellt. Hierzu wurde für jedes der als schwer verständlich identifizierten Items des UEQ eine Reihe von alternativen Items erstellt. Diese neuen Items wurden zusammen mit den originalen Items einer Stichprobe von Personen zur Bewertung verschiedener interaktiver Produkte vorgegeben. Die Ergebnisse dieser Studie wurden verwendet, um die als problematisch erkannten Items durch die am besten passenden alternativen Items zu ersetzen.


Usability Professionals 2012 Methoden + Messung

Einschätzungen durch Experten weisen darauf hin, dass der neue Fragebogen für die angestrebte Zielgruppe besser verständlich ist. Dies muss aber zusätzlich noch durch weitere empirische Untersuchungen, die den neuen Fragebogen in der Zielgruppe jugendlicher Nutzer einsetzen, verifiziert werden. Generell entsteht durch die Vereinfachung der Begriffe ein Verlust an sprachlicher Trennschärfe, d. h. hier ist theoretisch immer die Gefahr gegeben, dass sich beide Versionen bzgl. einzelner Skalen unterschiedlich verhalten.

Literatur 1. Dicke, C., Jakus, G., Tomazic, S. & Sodnik,

Bis solche Ergebnisse vorliegen, sollte der neue Fragebogen nur in der Zielgruppe jugendlicher Nutzer eingesetzt werden bzw. in Situationen, in denen man davon ausgehen muss, dass viele Nutzer nur über einen eingeschränkten Wortschatz verfügen. In anderen Zielgruppen sollte weiterhin die Originalversion verwendet werden, da im Moment noch nicht hinreichend belegt ist, ob durch die Vereinfachung der Begriffe evtl. die Bedeutung der einzelnen Skalen verändert wurde.

Springer-Verlag.

J. (2012). On the Evaluation of Auditory and

11. Laugwitz, B., Schubert, U., Ilmberger, W.,

Head-up Displays while Driving. ACHI 2012.

Tamm, N., Held, T. & Schrepp, M. (2009).

2. DIN EN ISO 9241-11 (1999): Ergonomische

Subjektive Benutzerzufriedenheit quantitativ

Anforderungen für Bürotätigkeiten mit

erfassen: Erfahrungen mit dem User

Bildschirmgeräten. Teil 11: Anforderungen an

Experience Questionnaire UEQ. In: Brau, H.,

die Gebrauchstauglichkeit – Leitsätze. Berlin:

Diefenbach, S., Hassenzahl, M., Kohler, F.,

Beuth Verlag.

Peissner, M., Petrovic, K., Thielsch, M.,Ulrich,

3. Ebner, M., Stickel, C., Scerbakov, N. & Holzinger, A. (2009). A study on the Compatibility of Ubiquitous Learning (u-Learning) Systems at University Level. In:

D. & Zimmermann, D. (Eds.), Usability Professionals 2009, S. 220 – 225, Fraunhofer Verlag. 12. Molich, R. & Nielsen, J. (1990): Improving a

Shumaker, R. (Ed.): Virtual and Mixed Reality.

human-computer dialog: What Designers

Lecture Notes in Computer Science 5622, S.

know about traditional interface design.

34-43, Springer-Verlag.

Erste empirische Validierungen mit studentischen Teilnehmern und Nutzern von betriebswirtschaftlicher Software (d. h. außerhalb der intendierten Zielgruppe) zeigen, dass sich der neue Fragebogen ähnlich verhält, wie das Original. In weiteren Validierungsstudien mit größeren Stichproben, muss dies zukünftig noch detaillierter untersucht werden. Falls sich hier zeigt, dass beide Versionen weitgehend parallel sind, kann in Zukunft evtl. die neue Version generell anstatt der Originalversion verwendet werden. Es sind weitere Studien, auch mit jugendlichen Nutzern geplant, um die Verständlichkeit der Items für die Zielgruppe empirisch zu belegen.

in Computer Science 5298, S. 63-76,

4. Hassenzahl, M., Burmester, M., Koller, F. (2003): AttrakDiff: Ein Fragebogen zur Messung wahrgenommener hedonischer und pragmatischer Qualität. In: J.Ziegler, G.

Communications of the ACM, 33, S. 338-348. 13. Norman, D. (2003): Emotional Design: Why We Love (Or Hate) Everyday Things. Boulder Colorado: Basic Books. 14. Rauschenberger, M., Hinderks, A. &

Szwillus (Hrsg.): Mensch & Computer 2003.

Thomaschewski, J. (2011). Benutzererlebnis

Interaktion in Bewegung. Stuttgart: Teubner.

bei Unternehmenssoftware. In: Brau, H.,

S. 187-196.

Lehmann, A., Petrovic, K. & Schroeder, C.

5. Hassenzahl, M. (2010): Experience design. Technology for all the right reasons. San Rafael: Morgan & Claypool. 6. Hartmann, J. (2011). User Experience

(Eds.), Usability Professionals 2011, S. 158 – 164, German UPA e.V., Stuttgart. 15. Rauschenberger, M., Schrepp, M., Olschner, S., Thomaschewski, J. & Cota, M.P. (2012).

Monitoring: Über die Notwendigkeit

Measurement of User Experience. A Spanish

geschäftskritische Online-Prozesse

Language Version of the User Experience

permanent zu überwachen. iCom, Vol. 10,

Questionnaire (UEQ). In: Rocha, A., Calvo-

No. 3, S. 59-62.

Manzano, J.A., Reis, L.P. & Cota, M.P. (Eds.),

7. Hatscher, M. (2001). Joy of use –

Sistemas y Tecnologías de Información

Determinanten der Freude bei der Software-

– Actas de la 7a Conferencia Ibérica de

Nutzung. In: Oberquelle, H., Oppermann,

Sistemas y Tecnologías de Información –

R. & Krause, J. (Hrsg.): Mensch & Computer

Madrid, Espana, 20 al 23 de Junio de 2012.

2001: 1 Fachübergreifende Konferenz. Stuttgart: B.G. Teubner, S. 445-446. 8. Kurosu, M. & Kashimura, K. (1995): Apparent

ISBN 978-989-96247-6-4. 16. Tractinsky, N. (1997): Aesthetics and Apparent Usability: Empirical Assessing Cultural and

usability vs. inherent usability: experimental

Methodological Issues. CHI’97 Electronic

analysis of the determinants of the apparent

Publications, Available URL http://www.acm.

usability. Denver, Colorado: Conference Companion of human factors in computing systems, S. 292–293. 9. Laugwitz, B., Schrepp, M. & Held, T.

org/sigchi/chi97/proceedings/paper/nt.htm. 17. Wieschnowsky, T. & Heiko Paulheim, H. (2011). A Visual Tool for Supporting Developers in Ontology-based Application

(2006). Konstruktion eines Fragebogens

Integration, in: 7th International Workshop

zur Messung der User Experience von

on Semantic Web Enabled Software

Softwareprodukten. In: Heinecke A.M. &

Engineering, 2011.

Paul, H. (Hrsg.): Mensch & Computer 2006 – Mensch und Computer im Strukturwandel.

Danksagung: Wir danken Herrn Marcel Lauten-

Oldenbourg Verlag, S. 125 – 134.

bach für die Durchführung der zweiten Studie.

10. Laugwitz, B., Held, T. & Schrepp, M. (2008). Construction and evaluation of a user experience questionnaire. In: Holzinger, A. (Hrsg.): USAB 2008, Lecture Notes

83


Das Usability-Experiment als Ergänzung zu typischen Usability- und A/B-Tests Inferenzstatistisch abgesicherte Ergebnisse in kleinen Stichproben Heinrich R. Liesefeld Centigrade GmbH Science Park 2 66123 Saarbrücken rene.liesefeld@centigrade.de

Abstract A/B-Tests ermöglichen es, Design-Varianten zu vergleichen und die Ergebnisse inferenzstatistisch abzusichern. Usability-Tests helfen zwar, effizient die gröbsten UsabilityProbleme eines Interfaces aufzudecken, ermöglichen aber normalerweise keine solche inferenzstatistische Absicherung. Dieser Artikel macht deutlich, dass Inferenzstatistik für Usability-Engineers von größerer Bedeutung ist als gemeinhin angenommen: Es geht um nichts Geringeres als die Vermeidung berechtigten Misstrauens, also um Glaubwürdigkeit. Dafür benötigen A/B-Tests eine große Teilnehmerzahl und sind daher meist auf eine Testung über das Web angewiesen. Da dies in vielen Projekten (z. B. weil besondere Hardware benötigt wird) nicht möglich ist, soll mit dem Usability-Experiment eine Lücke im Methoden-Portfolio von Usability-Engineers geschlossen werden. Das Usability-Experiment wendet die über 100-jährige Erfahrung experimenteller Psychologen mit der Messung menschlichen Verhaltens auf Usability-Fragestellungen an. Es erlaubt (im Gegensatz zu Usability-Tests) den inferenzstatistisch abgesicherten Vergleich von Design-Alternativen mit (im Vergleich zu A/B-Tests) relativ kleinen Stichproben (ab ca. 10 Teilnehmern). Zudem eröffnet es eine Reihe interessanter neuer Einblicke ins Nutzerverhalten.

1. Misstrauen in die Ergebnisse typischer Usability-Tests Lassen Sie mich mit einem typischen Ergebnis aus einem typischen Usability-Test beginnen: Angenommen, Sie wollen entscheiden, ob Checkbox A in Abbildung 1 funktioniert, d. h. ob Nutzer die einzelnen Zustände verstehen und die Checkbox korrekt bedienen. Es stellt sich heraus, dass 4 der 5 Test-Teilnehmer direkt und ohne Ihre Hilfe mit Checkbox A umgehen können. Im nächsten Teammeeting präsentieren Sie stolz dieses eindeutige Ergebnis. Womit Sie nicht gerechnet haben, ist, dass Peter Meier, ein motivierter Kollege, seine eigenen Tests durchgeführt hat. Peter war maßgeblich an der Entwicklung von Checkbox B beteiligt. Sein Test hat nun ergeben, dass nur 2 von 5 Teilnehmern Checkbox A auf Anhieb verstehen, während 4 von 5 Teilnehmer Checkbox B direkt verstehen. Wer hat nun Recht? Welche Checkbox ist besser? Hat Peter vielleicht die Daten manipuliert, um seine präferierte Checkbox durchzusetzen? [Abb. 1]

84

Keywords: /// Usability-Testing /// A/B-Tests /// Inferenzstatistik /// Experimentaldesign /// kognitive Psychologie

sich damit abfinden? Nein! Diese Gefahren bestehen zwar für typische Usability-Tests (s. Kasten 1) können aber durch andere Methoden abgefangen werden1.

Abb. 1. Checkboxen A und B. Links im „Unchecked“- und rechts im „Checked“-Zustand.

Besonders die Vermutung, dass Daten manipuliert werden, schürt das Misstrauen in Tests und Umfragen und führt zu der Empfehlung: „Traue keiner Statistik, die du nicht selbst gefälscht hast!“ – offensichtlich ein ernstzunehmendes Problem für Usability-Engineers; diese sind ja schließlich darauf angewiesen, dass Entscheidungsträger ihren Empfehlungen vertrauen. Ist dieses Misstrauen gerechtfertigt? Hier offensichtlich ja! Das Schließen von einer Stichprobe (einige Nutzer) auf die Population (alle Nutzer) birgt Gefahren. Muss man

2. Sich gegen den Zufall absichern: Inferenzstatistik Glücklicherweise sind Usability-Engineers nicht die ersten, die allgemeingültige Aussagen auf Grund begrenzter Stichproben treffen müssen. Fast jeder, der empirisch arbeitet, steht vor diesem Problem. Die angestrebte Gültigkeit kann z. B. alle Wirbeltiere umfassen oder sich auf die Nutzer einer Website für professionelle Unterwasser-Fotografen beschränken. Leider kann – selbst in den sehr speziellen Fällen – selten jedes einzelne Individuum der Ziel-Population an dem Test teilnehmen. Nähern wir uns den sich daraus ergebenden Problemen mit einer allgemeingültigen Aussage über eine mittelgroße Population von aktuell in etwa sieben Milliarden


Usability Professionals 2012 Methoden + Messung

Kasten 1: Abgrenzung des UsabilityExperiments zu anderen Verfahren

Bei typischen Usability-Tests interagieren repräsentative Nutzer unter der Anleitung eines Usability-Engineers mit einem Interface. Sie bekommen bestimmte Aufgaben und werden bei deren Bearbeitung beobachtet und aufgefordert zu verbalisieren, was sie tun. Häufig werden ihre Interaktionen mit dem Interface und Äußerungen aufgezeichnet (teilweise ergänzt durch z. B. Mimik oder Augenbewegungen). Stellen, an denen die Interaktion nicht reibungslos funktioniert, werden als Usability-Probleme identifiziert (s. Shneiderman & Plaisant, 2005, S. 144-147). Typische A/B-Tests, für die unter anderem Amazon und Google bekannt sind, vergleichen das Verhalten von Nutzern, die mit unterschiedlichen Designs konfrontiert werden. Um den Unterschied in der Usability zweier Checkboxen zu untersuchen, wird jeder Nutzer zufällig Gruppe A oder Gruppe B zugeordnet. Nutzer der Gruppe A bekommen Checkbox A und Nutzer der Gruppe B bekommen Checkbox B. Gemessen wird, bei welcher der Checkboxen mehr Nutzer ein gewünschtes Verhalten zeigen, z. B. den Zustand der Checkbox verändern, um die AGBs zu akzeptieren (s. Tullis & Albert, 2008, S. 216-217). Ein weiteres, dem Usability-Experiment verwandtes, Verfahren ist die experimentelle Evaluation. Auch hier kommen experimentelle und inferenzstatistische Techniken zum Einsatz. Bei experimentellen Evaluationen wird aber meistens das Verhalten von Programmen oder Maschinen untersucht. Beim Usability-Experiment hingegen soll das Verhalten von Nutzern Aufschluss über die Usability eines Interfaces geben. Die Messung menschlichen Verhaltens birgt besondere Schwierigkeiten, die andere Methoden erfordern als die Messung maschinellen Verhaltens.

Individuen (die Menschheit): Männer sind größer als Frauen. Natürlich sind die Damen der Basketball-Nationalmannschaft größer als die Herren Bodenturner. Wenn

Sie allerdings die Körpergröße der nächsten Frau und des nächsten Mannes, die/der Ihnen über den Weg läuft, messen, werden Sie mit einiger Wahrscheinlichkeit feststellen, dass der Mann größer ist als die Frau. Der Vorteil einer solchen Zufallsziehung ist, dass das Ergebnis nicht durch die Wahl der Stichprobe verfälscht wird. Mit einiger Wahrscheinlichkeit haben Sie allerdings zufälligerweise eine relativ große Frau oder einen relativ kleinen Mann getroffen. Messen Sie die Körpergröße von noch 5 Frauen und 5 Männern und mitteln Sie diese jeweils sechs Werte pro Gruppe! Sie sind jetzt bei der Stichprobengröße eines typischen Usability-Tests. Dass der Mittelwert der Männer größer ist als der der Frauen ist schon wesentlich wahrscheinlicher. Das ist der Vorteil einer Mittelung. Was hat es zu bedeuten, wenn das in Ihrer Stichprobe nicht der Fall ist? Haben Sie bewiesen, dass die Annahme, Männer wären größer als Frauen, ein dummes Vorurteil ist? Natürlich nicht. Es bleibt eine Restwahrscheinlichkeit, dass Sie ausgerechnet besonders große Frauen oder besonders kleine Männer getroffen haben. Eine gewisse Irrtumswahrscheinlichkeit ist unvermeidbar, sie kann aber zumindest berechnet und den Anforderungen entsprechend verringert werden. Für jede derartige Fragestellung gibt es Tests zur Bestimmung der Wahrscheinlichkeit, dass ein in der Stichprobe beobachteter Unterschied auch in der Population vorhanden ist. Im aktuellen Beispiel ist dies ein t-Test für unabhängige Stichproben (s. Bortz & Schuster, 2010, S. 120; Tullis & Albert, 2008, S. 28-29). Üblicherweise akzeptiert man eine Irrtumswahrscheinlichkeit von etwa fünf Prozent (p (probability) < 0,05). Es geht um die Wahrscheinlichkeit, den beobachteten Unterschied zu beobachten, obwohl sich die beiden Gruppen eigentlich nicht unterscheiden. Wenn diese Irrtumswahrscheinlichkeit unter fünf Prozent liegt, spricht man davon, dass die beiden Gruppen sich signifikant unterscheiden. Dieses Vorgehen ermöglicht es, von einer Stichprobe (mit einer gewissen Wahrscheinlichkeit) auf die Population zu schließen, also allgemeingültige Aussagen zu treffen. Einige Variablen nehmen Einfluss auf diese Wahrscheinlichkeit: Je größer die Stichprobe, je genauer die Messung und

je größer der tatsächliche Unterschied (der Effekt) ist, desto kleiner wird die Wahrscheinlichkeit daneben zu liegen. Die ersten beiden Variablen können Sie (bedingt) beeinflussen. Auf den Effekt haben Sie keinen Einfluss. Wenn der Effekt, wie beim Körpergrößenunterschied zwischen Männern und Frauen, extrem groß ist, haben Sie leichtes Spiel: Sie brauchen weder eine besonders große Stichprobe, noch eine besonders genaue Messung. Solche klaren Effekte sind aber leider eher spärlich gesät. Um Ergebnisse interferenzstatistisch abzusichern, brauchen Usability-Engineers also große Stichproben oder sehr genaue Messungen. 3. Große Stichproben: Typische A/B-Tests A/B-Tests (s. Kasten 1) nehmen den Weg über die Stichprobengröße: Angenommen, bei insgesamt 50 Nutzern pro Gruppe benutzen 45 Nutzer der Gruppe A und 40 Nutzer der Gruppe B ihre jeweilige Checkbox richtig. Man könnte hier stehen bleiben und feststellen, dass Checkbox A besser funktioniert; immerhin war die Erfolgsquote um 10% höher als für Checkbox B. Diese naive Art der Dateninterpretation, wie man sie auch aus den Medien gewohnt ist (z. B. vom ARD-Deutschlandtrend oder vom Politbarometer im ZDF), verschließt ganz einfach die Augen vor dem Problem, dass man nicht ohne weiteres allgemeingültige Aussagen auf Grund einer Stichprobe machen kann. Diese Naivität führt zu einem berechtigten Misstrauen gegenüber Statistiken. Vereinfacht und plakativ ausgedrückt: Nur inferenzstatistische Laien behaupten, dass 40 weniger sei als 45, dass 3% weniger sei als 5% oder dass 2,1 Punkte weniger seien als 2,3 Punkte…; und sie schaden damit dem Ansehen und Einfluss seriöser Empiriker. Es kann nämlich auch sein, dass diese Ergebnisse rein zufällig sind und die Stichprobenunterschiede keine Populationsunterschiede widerspiegeln. Wären andere Nutzer getestet worden, hätte vielleicht Checkbox B die Nase vorn.

Um dem Rechnung zu tragen, muss man die Irrtumswahrscheinlichkeit kennen. Dazu berechnet man zunächst eine Teststatistik und vergleicht diese mit der entsprechenden Verteilung. Die in diesem Fall

85


Gruppe

Richtig

Falsch

Summe

A

a=2

b=3

B

c=4

d=1

5

Summe

6

4

N = 10

χ²

p

1,67

0,197

1,96

0,161

3,92

0,048

Peters Stichrobe 5

Mittelgroße Stichprobe A

a = 45

b=5

B

c = 40

d = 10

50

Summe

85

15

N = 100

A

a = 90

b = 10

B

c = 80

d = 20

100

Summe

170

30

N = 200

50

Große Stichprobe 100

Anm. In den jeweils inneren Zellen ist angegeben, wie viele Nutzer einer Gruppe mit der jeweiligen Checkbox richtig (a, c) bzw. falsch (b, d) interagiert haben. Die zur Berechnung von χ² relevanten Werte (a, b, c, d und N) sind kursiv und fett gedruckt. Tab. 1. A/B-Test von Checkbox A gegen Checkbox B mit unterschiedlichen Stichprobengrößen

angemessene Teststatistik heißt χ² (chiQuadrat, vgl. Bortz & Schuster, 2010, S. 138; Tullis & Albert, 2008, S. 33-35). Tabelle 1 zeigt die Ergebnisse aus drei fiktiven A/B-Tests der Checkboxen aus Abbildung 1 in unterschiedlich großen Stichproben. [Tab. 1] Für die mittelgroße Stichprobe ergibt sich:

Ein Vergleich mit der χ²-Verteilung liefert p = 0,161, also eine Irrtumswahrscheinlichkeit von 16%; diese ist zu hoch, um aus den Daten eine zuverlässige Aussage darüber abzuleiten, welche Checkbox besser ist. Angenommen, der hier beobachtete Trend würde sich genauso fortsetzen (eine eher gewagte Annahme, die ich hier nur zur Illustration treffe!), bräuchte man eine in etwa doppelt so große Stichprobe, um eine statistisch abgesicherte Aussage machen zu können. Für diese große Stichprobe (s. Tabelle 1) ist p < 0,05. Man kann also auf Grund der großen Stichprobe mit einer vertretbaren Irrtumswahrscheinlichkeit von unter 5% sagen, dass Checkbox A besser funktioniert als Checkbox B.

86

Zum Vergleich enthält Tabelle 1 noch das oben erwähnte „deutliche“ Ergebnis Ihres Kollegen Peter Meier, der schon der Datenmanipulation verdächtigt wurde. Obwohl mehr als die Hälfte von Peters Teilnehmern Checkbox A falsch und fast alle Checkbox B richtig benutzt haben, nimmt er eine 19,7% Irrtumswahrscheinlichkeit in Kauf, wenn er dieses Ergebnis zugunsten von Checkbox B interpretiert. Weder Sie noch Peter haben Ihre Statistiken gefälscht und kommen doch zu unterschiedlichen Ergebnissen; Sie beide haben einfach unterschiedliche Stichproben aus derselben Population gezogen und die Irrtumswahrscheinlichkeit ignoriert. 4. Genaue Messungen: Das Usability-Experiment Hier tritt ein praktisches Problem zu Tage: Je kleiner ein Usability-Unterschied (ein Effekt) ist, desto mehr Nutzer müssen getestet werden, um ein Ergebnis inferenzstatistisch abzusichern. Da man in der (guten) Praxis aber schlechte Konzepte möglichst von vornherein aussortiert und nur vielversprechende Bedienkonzepte gegeneinander testet, sind potentiell vorhandene Usability-Unterschiede üblicherweise eher klein. Um mit typischen A/B-Tests Ergebnisse inferenzstatistisch abzusichern, muss

man also Zugang zu einer enorm großen Anzahl an Nutzern haben. Das bedeutet in der Praxis, dass diese Art der Testung nur über das Web möglich ist. Interfaces, für die das Web nicht in Frage kommt – z. B. aus Gründen der Geheimhaltung oder weil besondere Hardware benötigt wird –, wären praktisch von den Segnungen der Inferenzstatistik ausgeschlossen. Es kann außerdem häufig nur eine sehr geringe Anzahl repräsentativer Nutzer rekrutiert werden. Dies ist problematisch für Tests von Designs, bei denen Eigenschaften der Zielpopulation (z. B. Domänenwissen) eine Rolle spielen. Glücklicherweise bleibt aber die oben erwähnte zweite Stellschraube der Messgenauigkeit. Wenn die Messgenauigkeit nur hoch genug ist, lassen sich auch in kleinen Stichproben Ergebnisse inferenzstatistisch absichern. Eine Möglichkeit, das Verhalten eines Menschen genau zu messen, ist, ihn dieses Verhalten so oft wie möglich wiederholen zu lassen. Der Mittelwert aus diesen wiederholten Beobachtungen hat ein gutes Signal-Rausch-Verhältnis, d. h. dieser Mittelwert ist eine genaue Messung. Hier kommt das Usability-Experiment ins Spiel. Durch die Verwendung von Experimentaldesigns, wie sie in der experimentellen Psychologie entwickelt wurden, ist es möglich solch genaue Daten zu erheben und somit auch kleine Effekte in kleinen Stichproben inferenzstatistisch abzusichern. Es handelt sich hierbei um eine Reihe von Techniken, denen eine über mehr als 100 Jahre gewachsene Menge an theoretisch-methodischen Überlegungen und praktischer Erfahrungen zu Grunde liegen. Da eine angemessene Darstellung den Umfang dieses Artikels sprengen würde, beschränke ich mich im Folgenden auf ein Beispiel aus meiner Arbeit bei Centigrade. 5. Ein Usability-Experiment: Vergleich zweier Navigationsprototypen Für die Hauptnavigation der neuen Software-Generation eines Kunden hatten meine Kollegen und ich zwei vielversprechende Prototypen entwickelt, die in Abbildung 2 dargestellt sind. Beim ersten Prototyp, dem Swipe-Navigator, erfolgte die Navigation entweder über eine Wischgeste (Swipe) mit zwei Fingern oder über


Usability Professionals 2012 Methoden + Messung

eine Navigationslandkarte (Navi-Map), die durch Berührung des Bildschirms mit drei Fingern geöffnet wurde und in der der gewünschte Screen dann mittels eines Taps auf das entsprechende Icon ausgewählt wurde. Beim zweiten Prototyp, dem TwoWay-Slider, führte das Auflegen von zwei Fingern zum Öffnen einer Art Pie-Menü, in dem entweder durch einen Slide oder einen Tap auf das entsprechende Icon zum gewünschten Screen navigiert wurde. Die Frage war, ob der Swipe-Navigator oder der Two-Way-Slider effizienter ist, d. h. mit welchem der beiden Prototypen die Nutzer schneller zum Ziel gelangen würden. [Abb. 2]

Abb. 3. Ein Durchgang (Navigationsweg) mit der Methode „Swipe“ des Prototypen „Swipe-Navigator“. Teilnehmer bestätigten die Aufgabe (Navigation zum Screen „Musik“) durch einen Tap auf den Button in der Mitte des Bildschirms, navigierten und bestätigten dann das Erreichen des Ziel-Screens durch einen Tap auf den Button „Bestätigen“. Die interessierende Navigationszeit ist die Zeit von der Bestätigung der Aufgabe bis zum Erreichen des Zielscreens.

daher aus pragmatischen Gründen aus 14 Angehörigen der Universität des Saarlandes (9 Frauen, Median Alter = 23,5 Jahre), die jeweils 8 EUR für ihre Teilnahme erhielten. Alle waren Rechtshänder mit normaler oder einer auf Normalniveau korrigierten Sehstärke und ohne Farbenblindheit und gaben ihre Einwilligung zur Teilnahme nach erfolgter Aufklärung. 5.1.2. Studiendesign

Abb. 2. Die beiden Navigationsprototypen mit ihren jeweils zwei Methoden. Bei Navi-Map und Tap wird der Ziel-Screen durch einen Tap ausgewählt. Die Pfeile beim ersten Schritt von Swipe und Slide zeigen die Bewegungsrichtung der jeweiligen Geste an und waren während des Experiments natürlich nicht zu sehen.

5.1. Methoden 5.1.1. Teilnehmer Da die untersuchte Navigation kein Domänenwissen erfordert, sondern eher nur relativ grundlegende kognitive und motorische Prozesse eine Rolle spielen, war es nicht notwendig, repräsentative Teilnehmer mit Domänenexpertise zu rekrutieren. Unsere Stichprobe bestand

Die Prototypen und das Experimentalprogramm wurden mit Expression Blend 4 (Microsoft Inc.) erstellt und von den Teilnehmern über einen Touch-Monitor (M2256PW, 3M Touch Systems Inc.) bearbeitet. Der Touch-Monitor war so angebracht, dass er bequem aus dem Stand erreicht werden konnte. Teilnehmer bearbeiteten insgesamt 12 Blöcke à 20 Durchgänge, jeweils 6 Blöcke mit einem Navigationsprotypen. Innerhalb eines Blockes navigierten sie von jedem der fünf Screens zu jedem anderen Screen, d. h. sie bewältigten jeden der möglichen 20 Navigationswege. Alle Teilnehmer bearbeiteten die Navigationswege in der gleichen pseudorandomisierten Reihenfolge. Die Pseudorandomisierung unterlag der Einschränkung, dass der Start-Screen eines Durchgangs immer der Ziel-Screen des vorhergehenden Durchgangs war. Die Reihenfolge der Navigationsprototypen wurde über die Teilnehmer hinweg balanciert: Die Hälfte der Teilnehmer begann mit dem Swipe-Navigator und die andere Hälfte begann mit dem Two-Way-Slider. Direkt nach der Bearbeitung eines jeden Prototyps füllten die Teilnehmer einen Fragebogen zur User-Experience aus. Am Ende des Experiments machten sie einige

Angaben zu ihrer Person (Alter, Geschlecht, Touchscreen-Erfahrung etc.). Eine Sitzung dauerte inklusive Vor- und Nachgespräch, Bearbeitung beider Prototypen und der Fragebögen in etwa eine Stunde. 5.1.3. Material Screens enthielten nur die zur Navigation notwendigen Informationen. Die Bezeichnungen der Screens waren so gewählt, dass sie jedem Teilnehmer geläufig waren. Das Programm konnte als eine Art Medienverwaltung interpretiert werden (vgl. Abb. 2). 5.1.4. Prozedur Zu Beginn eines Durchgangs erschien in der Mitte des Bildschirms der Name des Ziel-Screens. Teilnehmer bestätigten diese Anweisung (indem sie darauf tappten) und navigierten dann so schnell wie möglich zu dem in der Anweisung gezeigten Ziel-Screen. Die Teilnehmer zeigten durch einen Tap auf einen Button unten links im Bildschirm an, dass die Navigation beendet ist. Die im Folgenden analysierte Navigationszeit ist die Zeit der Bestätigung der Anweisung bis zum Erreichen des ZielScreens. [Abb. 3]

87


Teilnehmer

Swipe-Navigator

Two-Way-Slider

di

(di – md)2

1 2 3 4 5 6 7 8 9 10 11 12 13 14

3,58 2,03 3,09 1,95 3,35 2,14 1,76 1,59 2,06 1,98 2,02 1,69 1,38 1,47

1,45 2,49 1,48 1,61 2,88 1,45 0,67 0,93 0,68 2,48 0,83 1,33 0,79 1,20

2,13 -0,46 1,61 0,35 0,47 0,70 1,09 0,66 1,38 -0,50 1,19 0,36 0,59 0,27

2,04 1,35 0,83 0,12 0,05 0,00 0,15 0,00 0,46 1,44 0,24 0,12 0,01 0,18

Mittelwert

2,15

1,45

0,70

0,50

Anm.

Summe

30,11

20,27

9,83

7,00

(md und ∑ ni =1(di-md ) 2 )sind kursiv und fett gedruckt.

Tab. 2. Mittlere Navigationszeiten (in s pro Navigationsweg) pro Teilnehmer und Prototyp. Zur einfacheren Berechnung der Teststatistik t ist zusätzlich pro Teilnehmer i die Differenz zwischen den beiden Prototypen (di) sowie das Quadrat der Abweichung dieser Differenz von der mittleren Differenz (di – md)2 angegeben.

Die beiden für die Berechnung von t relevanten Werte

Aus Tabelle 2 ergibt sich:

mit n = Stichprobengröße, di = Differenz in der Navigationszeit zwischen den beiden Prototypen für Teilnehmer i, md = Mittelwert der Differenzen, sd = Standardabweichung der Differenzen

5.2. Ergebnisse und Diskussion 5.2.1. Inferenzstatistische Absicherung des Navigationszeit-Unterschieds Analysiert wurden Navigationszeiten bei erfolgreicher Navigation. Wie zu erwarten, gab es kaum Navigationsfehler (98% korrekt für beide Navigationsprototypen). Es standen also für jeden der in Tabelle 2 aufgelisteten Mittelwerte (pro Teilnehmer und Prototyp) durchschnittlich 20*6*0,98 ≈ 118 Messwerte zur Verfügung. Die inferenzstatistischen Absicherung des Geschwindigkeitsvorteils des Two-Way-Sliders (1,45s/ Weg) gegenüber dem Swipe-Navigator (2,15s/Weg) erlaubt ein t-Test für abhängige Stichproben (vgl. Bortz & Schuster, 2010, S. 125; Tullis & Albert, 2008, S. 29-30): [Tab. 2] Ein Blick auf die t-Verteilung zeigt, dass dieses t(13) = 3,59 einem p = 0,003 entspricht. Das bedeutet, mit einer sehr

88

geringen Irrtumswahrscheinlichkeit von 0,3% ist die Navigation mit dem SwipeNavigator tatsächlich langsamer als die Navigation mit dem Two-Way-Slider. 5.2.2. Bestimmung des Gewinns Um anzudeuten, was mit derart erhobenen Daten außerdem möglich ist, berechne ich im Folgenden noch exemplarisch den Gewinn, der sich daraus ergeben würde den Two-Way-Slider anstatt des SwipeNavigators zu verwenden.

Genauso falsch und irreführend wie einen Mittelwerts-Unterschied in einer Stichprobe mit einem Unterschied in der Population gleichzusetzen, wäre es, auf Basis eines Mittelwert-Unterschieds den zu erwartenden Gewinn zu bestimmen. Man kann allerdings aus den Daten einer Stichprobe berechnen, in welchem Bereich der Gewinn mit einer gewissen Wahrscheinlichkeit liegt. Dieses Konfidenzintervall ist hier (vgl. Bortz & Schuster, 2010, S. 119):

mit α = gewünschte Irrtumswahrscheinlichkeit = 0,05


Usability Professionals 2012 Methoden + Messung

Unter der Annahme, dass alle Navigationswege gleich häufig sind, werden bei Verwendung des Two-Way-Sliders anstatt des Swipe-Navigators pro Navigationsweg zwischen 0,28s und 1,12s eingespart. Dies macht bei angenommenen 50 Navigationswegen pro Arbeitsstunde in etwa zwischen 13,90s und 56,10s aus. Bei einer täglichen Bedienung des Interfaces von 6h und 220 Arbeitstagen pro Jahr werden dann, bei einem Stundenlohn von 20 EUR und 100 Mitarbeitern, in etwa zwischen 10.200 EUR und 41.100 EUR pro Jahr eingespart. Dies gilt mit einer vertretbaren Irrtumswahrscheinlichkeit von 5%. Wer auf Grund der mittleren Differenz von 0,7s pro Navigationsschritt behauptet, es würden 25.700 EUR pro Jahr eingespart, ist im besten Fall naiv. Zugegebenermaßen ist das Konfidenzintervall in dem aktuellen Beispiel relativ breit, also die Schätzung relativ ungenau. Für eine nahezu beliebig genaue Schätzung muss einfach die Teilnehmerzahl oder die Menge an Messwerten pro Teilnehmer erhöht werden.2 5.2.3. Weitere Ergebnisse Die erhobenen Daten erlauben außerdem eine Reihe weiterer interessanter Analysen. Diese führten unter anderem zu folgenden Aussagen: –– Wenn man nur die häufigsten Navigationswege (zwischen Texte und E-Mails, s. Abb. 2) betrachtet, ist der Swipe-Navigator genauso schnell wie der Two-Way-Slider (beide 1,34s; p = 0,997). –– Teilnehmer werden (auch noch nachdem sie sich an das Experiment und die Architektur des Interfaces gewöhnt haben – also bei der Bearbeitung des zweiten Prototypen) mit etwas Übung schneller (2,13s in Block 1 gegen 1,28s in Block 6; p = 0,001). Sie erreichen aber nach einigen Blöcken ein stabiles Niveau (1,42s in Block 5 gegen 1,28s in Block 6; p = 0,30). –– Die allgemeine User-Experience unterscheidet sich laut den eingesetzten Fragebögen nicht zwischen den Prototypen (p = 0,21). Die beiden Navigationsmethoden des Swipe-Navigators werden allerdings als besser integriert empfunden (p = 0,008).

–– In Einklang damit wurden beim Swipe-Navigator beide Methoden gleich häufig benutzt (Swipe: 52% vs. Navi-Map, 47%, p = 0,78), während beim Two-Way-Slider hauptsächlich getappt wurde (Tap: 62% vs. Slide: 6%, p < 0,001). Entsprechend der DesignIntention wurde nämlich beim SwipeNavigator das Swipe für kurze Wege (ein Swipe; p = 0,06) und die Navi-Map für weite Wege (wenn mehr als drei Swipes notwendig gewesen wären; p < 0,001) bevorzugt.

Methoden einsetzen. Hier kommt es sicherlich auf die Zielsetzung des Produktes an, ob die Experience nach der ersten Nutzung oder die Experience nach der hundertsten Nutzung das interessantere Maß ist. Literatur 1. Bortz, J. & Schuster, C. (2010). Statistik für Human- und Sozialwissenschaftler (7. Auflage). Berlin, Deutschland: Springer. 2. Tullis, T. & Albert, B. (2008). Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics. Burlington, MA: Morgan Kaufmann.

6. Schlussfolgerungen und Ausblick

3. Shneiderman, B. & Plaisant, C. (2005). Designing the User Interface: Strategies for Effective Human-Computer Interaction (4.

Wie unser Navigationsexperiment zeigt, ist es mit Hilfe des Usability-Experiments möglich, Ergebnisse auch in kleinen Stichproben inferenzstatistisch abzusichern. Inferenzstatistik ist notwendig, da es beträchtliche Gefahren birgt, aufgrund einer Stichprobe (einige Nutzer) allgemeingültige Aussagen (über alle Nutzer) zu treffen. Auf lange Sicht erzeugt das Ignorieren der Irrtumswahrscheinlichkeit berechtigtes Misstrauen und schadet damit dem Ansehen von Usability-Engineers.

Ausg.). Boston, MA u. a.: Pearson Education.

1

Diese Verfahren sollen Usability-Tests ergänzen und nicht ersetzen (s. hierzu auch die Diskussion im letzten Absatz dieses Artikels).

2

Die Annahmen zur (relativen) Häufigkeit der Navigationswege und Nutzungsdauer des Interfaces sind relativ willkürlich und sollten durch empirische Daten ersetzt werden. In der Praxis verlängern sicherlich noch zusätzliche Einflussfaktoren die Navigationszeiten. Wenn

Natürlich soll das Usability-Experiment kein Ersatz für Usability-Tests sein. Usability-Tests sind äußerst effizient beim Aufdecken grober Usability-Probleme, wohingegen sich das Usability-Experiment auf die Beantwortung einiger weniger konkreter Fragen beschränken muss. Diese Methoden sind also eher ergänzend als konkurrierend gedacht. Es bietet sich zum Beispiel bei wichtigen Entscheidungen an, Ergebnisse eines Usability-Tests in einem Usability-Experiment abzusichern. Welches der beiden Verfahren besser geeignet ist hängt auch von der Fragestellung ab. Um zu untersuchen, wie intuitiv ein Interface bedienbar ist, sind Usability-Experimente mit ihren vielen Wiederholungen eher ungeeignet. Allerdings werden viele Interfaces über einen längeren Zeitraum und sehr intensiv benutzt; Nutzer erlernen also den Umgang damit. Der Lernfortschritt über die vielen Wiederholungen lässt sich in UsabilityExperimenten gut erfassen wird aber in Usability-Tests normalerweise nicht abgebildet. Fragebögen oder Befragungen zur UserExperience lassen sich ergänzend zu beiden

diese Faktoren nicht unverhältnismäßig stark auf die effizientere Variante wirken (dies wäre eine Interaktion, s. z. B. Bortz & Schuster, 2010), bleibt der Nettovorteil jedoch bestehen. Die nicht-perfekte Präzision jeder empirischen Messung wird bei der Berechnung des Konfidenzintervalls automatisch berücksichtigt.

89


HUX – Measuring Holistic User Experience HUX misst, welchen Einfluss die Beschaffenheit von Produktmerkmalen auf das holisitsche Produkterlebnis der Nutzer hat und berechnet deren Bedeutung für das Gesamterlebnis. Claude Toussaint designaffairs group Rosenheimerstraße 145 b 81671 München clau-de.toussaint@designaffairs.com

Stefan Ulrich designaffairs group Rosenheimerstraße 145 b 81671 München ste-fan.ulrich@designaffairs.com

Abstract Welchen Einfluss haben einzelne Produktmerkmale auf die User Experience? In welche Produktmerkmale lohnt es sich, zu investieren? Welche sind die Mindestansprüche an einzelne Merkmale in einer Produktkategorie, die erfüllt werden müssen, damit die Nutzer das Produkt noch akzeptieren? Welche Qualitäten begeistern die Nutzer? Um verlässliche Antworten auf diese entscheidenden Fragen in der Produktstrategie zu finden, hat designaffairs das Tool HUX (Holistic User Experience) entwickelt. Für eine vollständige Beschreibung der User Experience berücksichtigt HUX 21 Merkmale. Neben reinen Produktmerkmalen wie Design oder Materialqualität, werden auch Kontextmerkmale wie beispielsweise Markenwahrnehmung oder Produktpräsentation abgefragt. Im Rahmen der Messung, werden die Merkmale in einem umfangreichen Panel unabhängig von einander bewertet und anschließend in einem statistischen Verfahren analysiert. Der Vorteil von HUX gegenüber etablierten UX-Messverfahren, liegt darin, dass als Ergebnis der Messungen, konkrete Handlungsanweisungen für einzelne Produktmerkmale erzielt werden. Es wird deutlich, in welche Merkmale es sich lohnt zu investieren, um das Produkt erfolgreich zu machen. Hierbei werden sogar nichtlineare Zusammenhänge wie beispielsweise Hygiene- oder Begeisterungsfaktoren inklusive kritischer Grenzwerte ermittelt. Am Ende werden klare Entscheidungsgrundlagen für die strategische Produktplanung geliefert.

1. User Experience designaffairs entwickelt seit 20 Jahren Strategien und Design für Produkte in den Bereichen Hardware, Software und Services. Mit weltweit mehr als 70 Experten bietet das Unternehmen Leistungen in Research, Strategie, Design und Engineering an. Dabei wird erfolgreich Kreativität mit wissenschaftlichen Methoden kombiniert.

die Kunden nicht erkenn- und messbar, da beispielsweise eine schlechte System- und Softwarearchitektur erst dann in Erscheinung tritt, wenn das Produkt längerfristig im Einsatz ist. Daher wird die subjektiv wahrgenommene Produktqualität für die Kaufentscheidung und die spätere Kundenzufriedenheit immer wichtiger – und das nicht nur bei Konsumer-Produkten sondern auch zunehmend in allen Branchen bis hin zu Investitionsgütern und Medizintechnik.

User Experience ist das Schlagwort der Zeit. Apples Erfolg begründet sich ebenso darauf wie BlackBerrys Misserfolg. Zu Recht, denn der Begriff User Experience subsummiert das vom Kunden wahrgenommene ganzheitliche Produkterlebnis. Die Funktionen von Produkten an sich, sind unter den Wettbewerbern vergleichbar und damit für den Kunden kaum noch zu unterscheiden. Die objektive Qualität der Produkte ist für

User Experience ist genormt! (DIN EN ISO 9241-210: Ergonomie der MenschSystem-Interaktion Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme; Ausgabe:2010-03). Hervorzuheben ist dabei, dass unter User Experience ein holistischer interdisziplinärer Ansatz zu verstehen ist, der ebenfalls die subjektive ganzheitliche Wahrnehmung inklusive der Markenwerte betrachtet.

90

Marc Toussaint Prof. Dr., FU Berlin Arminallee 7 14195 Berlin Germa-nymarc.toussaint@fu-berlin.de

Keywords: /// User Experience /// UX-Design /// Messen /// Methode /// design to value /// design to cost /// Produktstrategie /// Hygienefaktor /// Begeisterungsfaktor /// nonlineare Regressionsanalyse

Auch in den Wirtschaftswissenschaften ist User Experience als Schlüsselfaktor angekommen: Clayton Christensen, Harvard Business Professor schreibt für Forbes: “a relentless focus on the user experience, not profit, is what is driving today’s best companies like Amazon, Apple, and Salesforce. …these companies are constantly searching for better ways to delight their customers” (Porter 11). Roland Berger und Mc Kinsey proklamieren Strategien hinsichtlich design-to-value und design-tocost, wobei mit „value“ meist alle Werte subsumiert werden, die die User Experience Definition enthalten (Berger 10). 2. Kosten und Nutzen von User Experience Entwicklungsbudgets sind begrenzt und Kunden aus allen Branchen fragen uns


Usability Professionals 2012 Methoden + Messung

regelmäßig, wie sie eine gute User Experience (UX) am effizientesten erreichen können. Dabei entstehen konkrete Fragen wie beispielsweise: Zahlt sich das Investment in ein größeres Display mehr aus als der Invest in einen schnelleren Prozessor? Oder: Was verbessert die User Experience nachhaltiger, ein neues Design? Oder reicht der Einsatz eines hochwertigeren Materials? Verbesserungen dieser Art steigern ja nicht die Funktionsfähigkeit des Produkts an sich. Manche dieser Invests haben aus Sicht des Vertriebes keinen direkten bzw. leicht kommunizierbaren Mehrwert als Verkaufsargument gegenüber den Mitbewerbern. Somit sind sie schwer zu verargumentieren. Qualitätsverbesserungen von Produkten gehen meist mit erheblichen Kosten einher, die, weil nicht verargumentierbar, allzu oft, dem Rotstift zum Opfer fallen. Die Produktentwicklung ist dabei abhängig von unterschiedlichen Disziplinen innerhalb eines Unternehmens. Das bedeutet, die Abteilung die in einem Unternehmen das Sagen hat, bestimmt üblicherweise, in welches Produktmerkmal in erster Linie investiert wird. In vielen Firmen liegt der Fokus auf den Funktionalitäten des Produkts (Sales getrieben), bei anderen auf der technischen Qualität (Entwicklung) oder auf Marke und Design (Marketing). Entscheidungen über Produktverbesserungen werden von den Verantwortlichen meist ohne eine solide Wissens-Basis getroffen und der Mehrwert, der am Ende durch die Investitionen erzielt wird, ist schwer messbar. designaffairs bietet mit dem Tool HUX erstmals die Möglichkeit an, valide quantitative Aussagen über die Relevanz einzelner Produktmerkmale für die ganzheitliche User Experience zu treffen. Darüber hinaus ist es möglich, die Relevanz in Abhängigkeit der Qualität der Merkmalsausprägungen als dynamische Faktoren zu betrachten. Daraus resultiert eine zuverlässige Aussage darüber, wie wichtig dem Nutzer einzelne Produktmerkmale sind und ob die Akzeptanz eines höheren Kaufpreises bei verbesserter Produktqualität vorhanden ist.

3. Warum alles neu? – Etablierte Messverfahren und deren Grenzen Auf dem Markt existieren zum einen Methoden, die die User Experience auf Nutzerseite messen wie beispielsweise Attraktdiff (Hassenzahl et al. 08) oder User Experience Questionaire (UEQ) (Langwitz,et al. 09). Zum anderen gibt es etablierte Messverfahren, um die Relevanz einzelner Produktmerkmale zu ermitteln wie die Conjoint-Analyse und die Kano Analyse. Die beiden Methoden Attraktidiff (Hassenzahl) und User Experience Questionaire (SAP) wurden beide explizit dazu entwickelt, die User Experience von Softwaresystemen zu messen. Diese betrachten die hedonischen und pragmatischen Qualitäten, genauer die Wirkung auf Nutzerseite, durch die Software. So wird bei Attraktdiff erfragt, wie praktisch, voraussagbar, übersichtlich, kreativ, originell, herausfordernd, fachmännisch, verbindend, gut, attraktiv und angenehm die Software für den Anwender ist. Basierend auf etablierten psychologischen Modellen, zeigen diese daher ein sehr zuverlässiges Bild über die subjektive Wahrnehmung der Software. Besonders im Produktvergleich oder einer Längsschnitt Studie lassen sich sehr dedizierte Aussagen darüber machen, wie sich die wahrgenommenen Qualitäten unterscheiden. Beide Verfahren untersuchen jedoch nicht, welche der vielen unterschiedlichen Produktmerkmale letztendlich diese subjektive Wahrnehmung hervorrufen. Das Produkterlebnis ist individuell und lässt sich lediglich indirekt beeinflussen. Der Hersteller kann „nur“ verschiedene Produktparameter gestalten und möchte wissen, wie diese das ganzheitliche Produkterlebnis verändern. Das Problem in der Praxis ist, dass der Hersteller durch die Messung mit den etablierten Test-Verfahren keine Rückschlüsse darauf ziehen kann, warum der Nutzer das Produkt gerade so erlebt wie er es erlebt. Zudem bleibt unberücksichtigt, wie wichtig die einzelnen Attribute für den Nutzer tatsächlich sind. Dadurch bleibt die wichtigste Frage unbeantwortet: In welche Produktmerkmale

muss investiert werden, um erfolgreichere Produkte zu gestalten? Statt auf der Nutzerseite sollte man also besser auf der Produktseite messen. Ansätze hierfür liefern andere Analyse-Methoden. Die Conjoint-Analyse (CONsidered JOINTly – „ganzheitlich betrachtet“) ist ein etabliertes Messverfahren, um den Anteil einzelner Produktmerkmale am Gesamtnutzen zu ermitteln (Backhaus et al. 00). Hierbei wird beispielsweise gefragt, ob dem Probanden ein Porsche mit 250 PS lieber ist, oder ein BMW mit 300 PS. In vielen Varianten werden die gewünschten Produktmerkmale so gegeneinander abgefragt. Aus den Antworten wird berechnet, welchen Stellenwert die Merkmale (hier Marke und Motorleistung) bei dem Probanden haben. Dieses Verfahren ist bei komplexeren Fragestellungen sehr aufwändig und liefert lediglich lineare Zusammenhänge. Daher erzielt es nicht die gewünschten Ergebnisse. Aufbauend auf Herzbergs Zwei-FaktorenTheorie (Herzberg 59) wissen wir, dass die Gewichtung einzelner Merkmale von deren Qualität abhängig ist. Herzberg unterscheidet hier zwischen Hygiene- und Motivationsfaktoren. So ist eine geringe Materialqualität für manche Produkte eventuell nicht relevant. Wird aber eine gerade noch akzeptable Mindestgrenze der Materialqualität unterschritten, fließt diese beim Nutzer überproportional stark in die Gewichtung bei der Gesamtbewertung des Produktes. Das etablierte Kano Verfahren unterscheidet zwischen drei Faktoren Begeisterungsmerkmale = Begeisterungsfaktor, Basismerkmale = Hygienefaktor und Leistungsmerkmale = Motivationsfaktor (Kano 84). Jedoch werden wie beim Conjoint-Verfahren nur theoretische Produktvarianten und keine tatsächliche Produkterlebnisse (User Experience) gemessen. Zudem geht das Modell von linearen Gewichtungsverhältnissen innerhalb der drei Faktoren aus. Es kann auch keine Aussagen darüber treffen, bei welchem Qualitätsniveau eines

91


Produktmerkmals eine Akzeptanzschwelle der Kunden unterschritten wird. 4. HUX, Measuring Holistic User Experience Keines der etablierten Messverfahren liefert die gewünschten und vom Hersteller benötigten Aussagen. Daher entwickelte designaffairs das eigene Tool HUX. Als Prämisse für das Tool wurden folgende Aussagen getroffen: 1. UX beschreibt die holistische Produkterfahrung welche sich aus den Einzelerfahrungen der einzelnen Produktfaktoren durch den aktiven Nutzer zusammensetzt. 2. Die UX ergibt sich aus dem Zusammenspiel mehrerer sehr heterogener Erlebnis-Faktoren, die durch die einzelnen Produktmerkmale geprägt werden. 3. Die Bewertung der einzelnen Produktmerkmale fließen unterbewusst und, je nach Produktkategorie unterschiedlich gewichtet, in die Gesamtbewertung des Produkts ein. 4. Die UX-Qualität ist ein holistisches Maß für eine Produktqualität. 5. Die Qualität der holistischen User Experience lässt sich aus der Qualität der einzelnen Produktmerkmale mit ihren Gewichtungen ableiten und voraussagen.

Im Gegensatz zu den oben genannten Verfahren, werden keine theoretischen zukünftigen Produktvarianten oder erste Eindrücke von Produkten oder Produktkonzepten gemessen, sondern die nachhaltige längerfristige Erfahrung mit einem konkreten existierenden Produkt: Der Proband bewertet sein eigenes Produkt, das er aktiv benutzt. Nur so wird gewährleistet, dass alle, für den Käufer nachhaltig relevanten, Aspekte wie beispielsweise die Qualität im Gebrauch, in die Bewertung mit einfließen und nicht nur die ersten oberflächlichen Eindrücke. Bei der Entwicklung des Tools wurden zunächst in mehreren iterativen interdisziplinären Experten-Runden die entscheidenden Merkmale identifiziert, die eine Gesamt-Produktqualität ausmachen. Für die vollständige Beschreibung der User Experience wurden 21 Merkmale benannt: Neben reinen Produktmerkmalen wie Design oder Materialqualität, auch Kontextmerkmale wie beispielsweise Markenwahrnehmung oder Produktpräsentation. Schnell wurde klar, dass die Relevanz und die Erwartungen der Nutzer an die einzelnen Qualitäten von der jeweiligen Produktkategorie abhängen. Bei der Erhebung der Daten wird der Nutzer nicht direkt danach gefragt, wie relevant er die einzelnen Produktmerkmale empfindet. Denn wird die Aufmerksamkeit bei der Befragung auf ein Merkmal gelenkt, besteht

die Gefahr, dass dieses durch den Nutzer schon alleine dadurch stärker gewichtet wird, obwohl es vielleicht bei einer Gesamtbewertung unterbewusst viel geringer in seine Bewertung einfließen würde. Die Idee und Innovation des HUX-Messverfahrens ist daher, die unterbewusste Gewichtung indirekt rechnerisch zu ermitteln. Indem sowohl die Gesamtbewertung als auch die qualitative Bewertung einzelner Merkmale abgefragt werden. Mittels einer Regressionsanalyse wird die Gewichtung, die der Mensch den einzelnen Merkmalen unterbewusst gibt, berechnet. Das neue Messverfahren liefert nicht nur Aussagen über eine einfache lineare Gewichtung der einzelnen Produktmerkmale wie dies die linearen Regressionen tun, es erlaubt auch, die Gewichtung der einzelnen Merkmale in Abhängigkeit der Merkmalsqualität zu beurteilen. [Abb. 1] Um komplexe Modelle wie Hygiene-, Motivations- und Begeisterungsfaktoren zu berücksichtigen und zu evaluieren, wurden gemeinsam mit dem Fachbereich Mathematik und Informatik der FU Berlin ein nonlineares statistisches Verfahren entwickelt. Dieses bildet das psychologische Modell, sowie zusätzliche Abhängigkeiten der Faktoren untereinander mit Hilfe von Kostenfunktionen ab und liefert entsprechende Ergebnisse. [Abb. 2]

Abb. 1. HUX-Diagramm: Bildet die Gewichtung (horizontale Achse) und Bewertung (vertikale Achse) der einzelnen Produktmerkmale ab. Die horizontale Linie zeigt die durchschnittliche Gesamtbewertung der Produkte. Die vertikale Linie definiert die durchschnittliche Gewichtung über alle Produktmerkmale. Die Punkte geben die durchschnittliche Bewertung und Gewichtung einzelner Produktmerkmale an. Die Linien zeigen den Verlauf, in dem sich die Gewichtung mit zu- bzw. abnehmender Merkmalsqualität verändert.

92


Usability Professionals 2012 Methoden + Messung

Darüber hinaus wurde das Institut für Statistik der LMU München als weiterer Externer zu Rate gezogen. 5. Theoretischer Hintergrund Es gibt Produktmerkmale, die einen „must have“-Charakter haben und andere, die einen „nice to have“-Charakter besitzen. Die Zwei-Faktoren-Theorie von Frederick Herzberg unterscheidet entsprechend zwischen Hygiene-Faktoren und Motivations-Faktoren. Beispiel: Usability ist tendenziell ein Hygienefaktor (must have). Das heißt, eine schlechte Bewertung, unter einem bestimmten Schwellenwert dieses Features, hat alleine einen sehr hohen Einfluss auf die Gesamtbewertung des Produkts. Eine sehr gute Bewertung kann im Gegensatz dazu die Gesamtbewertung des Produkts nicht stark heben. Design, ist eher ein Motivationsfaktor. Eine schlechte oder gute Bewertung hat einen gleichmäßigen linearen Einfluss auf die Gesamtbewertung. Je nach Produkt-Kategorie ist die Gewichtung unterschiedlich. So kann beispielsweise ein gutes Design alleine die Gesamtbewertung maßgeblich beeinflussen. Wie bei der Kano Analyse, gehen wir von einem dritten möglichen Faktor aus, dem Begeisterungsfaktor. So beeinflusst eine Marke mit mittlerer Bewertung die Gesamtbewertung des Produkts mittelstark. Wird das Markenimage aber als besonders herausragend bewertet, beeinflusst diese Markenbewertung die Gesamtbewertung des Produkts überproportional stark. In der Praxis sind alle Features mehr oder weniger Mischformen der drei oben beschriebenen Extreme.

6. Vorgehensweise beim HUX-Verfahren Zu Beginn einer Untersuchung wird zunächst der Testraum exakt festgelegt. Es wird die genaue Produktkategorie definiert, sowie von welchen Marken die ProduktDaten erwünscht werden. Abhängig von der Produktkategorie werden die 21 Produktmerkmale vorgefiltert oder angepasst. So ist z. B. der Parameter „Geschmack“ für SmartPhones nicht relevant. Die Zielgruppen und Zielmärkte werden festgelegt. Deren spätere Auswertung ergibt besonders aufschlussreiche Ergebnisse. Etwa, dass Frauen bestimmte Merkmale anders gewichten als Männer. Oder sich die Akzeptanzschwellen der Geschlechter deutlich voneineder unterscheiden. Pro Produktmerkmal werden bis zu 4 Parameter ermittelt. Entsprechend groß muss die Anzahl der Probanden für die Befragung sein, ab ca. n=400. Am effizientesten ist die Form der online-Befragung. Die Probanden müssen ein Produkt in der definierten Kategorie bereits besitzen und länger nutzen. Zunächst werden sie nach der Gesamtbewertung ihres Produkts befragt. Als Grundlage hierfür wird die Einstellung zum Produkt mittels einer 4-Item Skala ermittelt. (Moreau et al. 01). Neben emotionalen und kognitiven Aspekten wird der Gebrauch an sich, so wie die Weiterempfehlungs-Bereitschaft abgefragt. Die Gesamtbewertung des Produkts dient als Referenz für die spätere Regressionsanalyse.

Abb. 2. Korrelations-Diagramm: Bildet die Korrelation einzelner Produktmerkmale zu einander sowie zur Gesamt-Bewertung (HUX) ab.

User Experience ist gegeben (Cronbachs-α Überprüfung =0,9). Anschließend findet die statistische Auswertung der Daten statt. Um die Güte der Ergebnisse zu bewerten, wird jeweils sowohl der quadratische Fehler als auch eine Kreuzvalidierung und Varianz-Betrachtung durchgeführt. Hierdurch kann bewertet werden, wie genau die Ergebnisse und ob noch weitere Probanden befragt werden müssen, um stabile Ergebnissen zu erhalten. 7. Beispiel Smartphones

Nachdem die personenbezogenen Aspekte im Fragebogen erhoben werden, müssen die Probanden im randomisierten Verfahren die einzelnen Produktmerkmale (bis zu 21 Items) bewerten. Hierzu wird eine 7-Punkt-Likert Skala benutzt (7 = „stimme voll und ganz zu“).

Um das Konzept und Messverfahren zu testen, hat designaffairs zwei eigene Studien (n=300 bzw. n= 500) zur Untersuchung der Holistic User Experience von Smart Phones und Waschmaschinen durchgeführt. Dazu haben die Probanden ihre jeweils bekannten und im Alltag genutzten Produkte bewertet.

Der Fragebogen an sich wird von designaffairs als objektiv (Experteninterviews), valide (Face & Content Validity) und reliabel eingeschätzt. Die interne Konsistenz der Skala zur Messung der holistischen

Die Analyse der ersten Stichproben bestätigte unsere Thesen: Für die ganzheitliche User Experience sind die einzelnen Produktmerkmale unterschiedlich stark relevant, und zwar auch abhängig von der

93


Produktkategorie. Bei den Smart Phones sind die relevanten Merkmale demnach andere als bei den Waschmaschinen. Das Ergebnis von HUX zeigt unter anderem, dass bei Smart Phones die 3 Faktoren Funktionalität, Interaktivität und das Design der Hardware, alleine 60% der Gesamt User Experience ausmachen. Bei Waschmaschinen sind die 4 Merkmale Bedienbarkeit, Design Hardware, mechanische Qualität und Funktionsumfang zusammen für 80% der Gesamtbewertung des Produkts verantwortlich.

ist HUX eine optimale Möglichkeit, einer Design-to-Value Strategie, valide quantitative Daten zu liefern. Die vorhandenen Ergebnisse bestärken uns in der Annahme, dass das Tool HUX valide und differenzierte Empfehlungen für Produktmanager und UX-Designer liefert. Wir arbeiten nun an der Ausweitung unserer Datenbasis und der weitergehenden Verfeinerung und Validierung unserer Methodik bzw. der mathematischen Modelle. Literatur

Die Befragten wurden in dieser Studie zusätzlich direkt nach Ihrer persönlichen Einschätzung der Relevanz der einzelnen Merkmale befragt und die Ergebnisse mit der statistisch ermittelten Gewichtung verglichen. Wie erwartet, konnte die persönliche Einschätzung der Probanden nicht für produktstrategische Entscheidungen herangezogen werden, da bei den Stichproben alle Merkmale mehr oder weniger als gleich gewichtig bewertet wurden. So ist der quadratische Fehler bei der durch HUX berechneten Gewichtung um 26% geringer als bei der von den Probanden angegebenen.

1. Herzberg, Frederick; Mausner, Bernard; Snyderman, Barbara Bloch (1959): The Motivation to Work. 2. Aufl. New York: Wiley. 2. Backhaus, K., Erichson, B., Plinke, W. & R. Weiber (2000). Multivariate Analysemethoden. Berlin:Springer. 3. Berger, R. (Hrsg.) (2010). Design-to-Value. In Berger, R. (2010): think:act Business, COO Insights.http://www.rolandberger. com/media/pdf/Roland_Berger_COO_ Insights_D_20100716.pdf (25.06.2012). 4. Hassenzahl, M., Burmester,M. & F. Koller (2008). Der User Experience auf der Spur: Zum Einsatz von www.attrakdiff.de. In H. Brau, S. Diefenbach, M. Hassenzahl, F., Koller, M. Peissner & K. Röse (Hrsg.): Usability

Die Daten wurden zudem nach den verschiedenen Herstellern ausgewertet. Pro Hersteller konnten in Folge konkrete Aussagen darüber getroffen werden, mit welchem Aufwand der beste Return of Invest erzielt wird. So sollte beispielsweise Motorola in ein besseres Hardware Design investieren, wohingegen BlackBerry zunächst die Interaktivität seiner Produkte verbessern sollte.

Professionals 2008 (78-82). Stuttgart: IRB. 5. Kano, N., Seraku, N., Takashi, F. & S.Tsuji (1984). Attractive quality and must-be quality. The Journal for Japanese Society for Quality Control, 14, 147-156. 6. Langwitz, B., Schubert, U., Ilmberger, W., Tamm, N., Held, T. & M. Schrepp (2009). Subjektive Benutzerzufriedenheit quantitativ erfassen: Erfahrungen mit dem User Experience Questionnaire UEQ. In H. Brau & S. Diefenbach (Hrsg.): Usability Professionals

Zu allen gemessenen Produkten wurde der Marktpreis ermittelt, um ein Preismodell der Produktkategorie Smart Phones zu erstellen, das die gemessene User Experience mit dem Marktpreis in Bezug setzt. Mit Hilfe dieses Modells können Vorhersagen darüber getroffen werden, welche Marktpreise mit welcher User Experience erzielt werden. In Kombination mit dem Modell aus HUX werden daher nachvollziehbare Vorhersagen darüber getroffen welcher Invest in welches Produktmerkmal den besten Return of Invest erzielt. Damit

94

2009 (220-225). Berlin: Frauenhofer Verlag. 7. Moreau, P. C:, Markman, A. B., & Lehmann, D. R.(2001). „What is it?“ Categorization flexibility and consumers’ responses to really new products. Journal of Consumer Research, 27, 489-498. 8. Porter, J. (2011). IS UX the key to a longlasting business?. In 52 weeks of UX. A discourse on the process of designing for real people. http://52weeksofux.com/ post/20775808797/is-ux-the-key-to-a-longlasting-business (25.06.2012).


Nutzerwissen wissen und nutzen

95


Online-Fokusgruppen Einsatzgebiete und praktische Erfahrungen

Heidi Hoffmann GfK SirValUse Consulting GmbH Kaiser-Wilhelm-Ring 38 50672 Köln hoffmann@sirvaluse.de

Dr. Siegfried Olschner DATEV eG Südliche Fürther Straße 212 90429 Nürnberg siegfried.olschner@datev.de

Abstract In diesem Beitrag stellen wir unsere Erfahrungen beim Einsatz von Online-Fokusgruppen im Bereich Unternehmenssoftware vor. Zuerst beschreiben wir einen Methodenvergleich, den die DATEV eG mit Hilfe des Dienstleisters ForschungsWerk GmbH durchgeführt hat. Bei diesem wurden jeweils eine klassische Fokusgruppe, eine synchrone Online-Fokusgruppe und eine asynchrone Online-Fokusgruppe mit vergleichbaren Teilnehmern und gleicher Fragestellung durchgeführt. Die Ergebnisse des Vergleichs werden vorgestellt und Vorschläge für den Einsatz der Methoden aufgelistet. Anschließend gehen wir im Detail auf eine konkrete Projekterfahrung beim Einsatz der Methode asynchrone OnlineFokusgruppe ein. Diese wurde von der DATEV eG zusammen mit der GfK SirValUse Consulting GmbH durchgeführt. Wir beschreiben das methodische Vorgehen, zeigen aus Sicht eines IT-Dienstleisters und einer User Experience-Beratung die Vorteile und Grenzen der Methode auf und geben Tipps zur Anwendung.

1. Einleitung Klassische Fokusgruppen sind im Rahmen des User Centered Designs ein gängiges und oft genutztes Werkzeug. Sie eignen sich besonders dazu Fragen rund um Produkte und deren Nutzungskontext sowie Meinungen und Erfahrungen zu einem Produkt gemeinsam mit Anwendern zu diskutieren. Aus den Ergebnissen lassen sich dann Ideen für Innovationen und Maßnahmen zu Produktverbesserungen ableiten. Die Methode ist aber nicht nur mit Vorteilen, sondern auch mit einigen Nachteilen verbunden. Da klassische Fokusgruppen in einem Labor durchgeführt werden, können sie zum einen nur bei Zielgruppen eingesetzt werden, die im Umkreis des Labors in ausreichender Zahl verfügbar sind. Außerdem bedarf es bei bestimmten Zielgruppen oft einer führenden Moderation, damit alle Teilnehmer zu Wort kommen und die Themen vollständig bearbeitet werden. Weiterhin lassen sich Themen, mit denen die Teilnehmer nur sehr selten in Kontakt kommen, nur schwer

96

in klassischen Fokusgruppen diskutieren, da die Erinnerung an das Erlebte meist zu wenig präsent ist. Um diesen Herausforderungen zu begegnen, sind wir der Frage nachgegangen, ob Online-Fokusgruppen ein adäquates Mittel sind um diese Herausforderungen zu adressieren. Dazu haben wir zuerst einen Methodenvergleich zwischen einer klassischen Fokusgruppe, einer synchronen Online-Fokusgruppe sowie einer asynchronen Online-Fokusgruppe durchgeführt. Mit Hilfe dieses Vergleichs sollte geklärt werden, ob und unter welchen Rahmenbedingungen die klassische Methode durch eine Online-Methode ersetzt werden könnte um die onlinespezifischen Vorteile, wie z. B. größere Verfügbarkeit von Teilnehmern oder Kostenersparnis, zu nutzen. Die Erkenntnisse aus dieser Vergleichsstudie werden im Abschnitt 2 geschildert. Es werden unter Einbezug unserer Erfahrung mit anderen Fokusgruppen Empfehlungen für den Einsatz ausgesprochen. Als zweites behandelt dieser Artikel neben dem Methodenvergleich die Durchführung

Ulf Schubert DATEV eG Südliche Fürther Straße212 90429 Nürnberg ulf.schubert@datev.de

Keywords: /// Fokusgruppe /// Online-Fokusgruppe /// Asynchron /// Synchron /// Revelation /// Methodenvergleich /// Praxiseinsatz /// Erfahrungsbericht

einer weiteren Online-Fokusgruppe mit einer sehr konkreten anwendungsbezogenen Fragestellung. Diese wurde in Zusammenarbeit von DATEV eG und GfK SirValUse umgesetzt. Neben den Kernfragestellungen ging es hierbei auch um die Praktikabilität der Methode und die Frage, wie wohl ein durchschnittlicher DATEV-Software-Nutzer mit einer derartigen Online-Methode zurechtkommen würde. Abschnitt 3 listet hierzu die DATEV-spezifischen Erfahrungen auf und geht dabei auch auf Teilnehmer-Feedback zur Methode ein. Die praxisrelevanten Erfahrungen aus der Sicht von GfK SirValUse zur Vorbereitung, Durchführung und Auswertung dieser Fokusgruppe werden im vierten Abschnitt dargestellt. 2. Fokusgruppen-Variantenvergleich 2.1. Aufbau der Studie Um zu bewerten, ob Online-Fokusgruppen die DATEV-Anforderungen erfüllen und klassische Fokusgruppen ersetzen können, hat DATEV eG gemeinsam mit


Usability Professionals 2012 Nutzerwissen wissen und nutzen

dem Marktforschungsinstitut ForschungsWerk GmbH einen Variantenvergleich durchgeführt. Dabei wurden drei Fokusgruppen (eine klassische Fokusgruppe, eine synchrone Online-Fokusgruppe und eine asynchrone Online-Fokusgruppe) mit dem gleichen Thema und vergleichbaren Testpersonen (SteuerberaterInnen und AnwenderInnen von DATEV-Software) durchgeführt. Die klassische Fokusgruppe (n=7) wurde auf konventionelle Weise in einem Labor durchgeführt und im persönlichen Kontakt von einem Moderator geleitet. Die synchrone Fokusgruppe (n=15) wurde mit Hilfe eines Online-Chatsystems durchgeführt. Die Testpersonen nahmen von zuhause bzw. vom Arbeitsplatz teil. Die asynchrone Fokusgruppe (n=12) wurde mit einem Online-Forum durchgeführt. Die Dauer erstreckte sich über einen Zeitraum von 3 Wochen. Die Teilnehmer nahmen auch hier von zuhause bzw. vom Arbeitsplatz teil. 2.2. Beobachtete Unterschiede Im folgenden Abschnitt werden die relevanten beobachteten Unterschiede zwischen den drei Fokusgruppen dargestellt. 2.2.1. Umgang der Testpersonen untereinander In der klassischen Fokusgruppe konnten wir beobachten, dass die Testpersonen ernst und respektvoll miteinander umgingen. Das direkte Gegenübersitzen der Testpersonen bewirkte aber auch, dass die unterschiedlichen Persönlichkeitstypen stärker zum Tragen kamen. Beispielsweise war zu beobachten, dass „Selbstdarsteller“ die Diskussionsrunde gern als Bühne verstanden, während „Schüchterne“ sich davon beeinflussen ließen. Auffällig war auch, dass die Testpersonen nur wenig aufeinander Bezug nahmen. In den beiden Online-Fokusgruppen zeigte sich eine deutlich stärkere Bezugnahme unter den Testpersonen. Die

Teilnehmer griffen die Themenstellungen der anderen auf und entwickelten sie deutlich intensiver weiter als bei der klassischen Fokusgruppe. Am deutlichsten war dies bei der synchronen OnlineFokusgruppe zu beobachten. Auch wenn der Umgang der Teilnehmer untereinander teilweise sehr empathisch war, ergaben sich hier jedoch vereinzelte Diskussionsbeiträge, die man als „persönlichen Angriff“ bezeichnen kann. 2.2.2. Tiefe der Diskussion In der klassischen Fokusgruppe neigten die Teilnehmer zu längeren Monologen. Es war zu beobachten, dass es den Teilnehmern dabei auch weniger um die gegenseitige Inspiration oder die Weitergabe von Gelerntem ging. Die Diskussion konnte am ehesten als Meinungsaustausch beschrieben werden. Die synchrone Online-Fokusgruppe lieferte eine bessere Diskussionstiefe als die klassische Fokusgruppe. Es war zu beobachten, dass nicht nur der Meinungsaustausch, sondern auch die Weitergabe von Gelerntem im Mittelpunkt stand. Die beste Diskussionstiefe konnten wir bei der asynchronen Online-Fokusgruppe beobachten. Hierbei fand ein detaillierter Informationsaustausch mit intensiver Beleuchtung unterschiedlicher Aspekte statt. Die Teilnehmer bezogen in die Diskussion nicht nur ihre Erinnerungen ein, sondern bereiteten bestimmte Themen auch außerhalb der Fokusgruppe vor. Dadurch kamen sehr viele Detailaspekte zur Sprache. 2.2.3. Gruppendynamik In der klassischen Fokusgruppe war generell die Tendenz zu beobachten, dass Themen von Meinungsführern bestimmt wurden. Um ein möglichst gutes Bild von der Gruppe zu bekommen, musste bei der Moderation dem entgegengewirkt werden. In der synchronen Fokusgruppe wurden Themen stärker von der Mehrheit

bestimmt. War die Mehrheit der Meinung, dass die Frage des Moderators unpassend war, wurde diese ggf. ignoriert oder im Extremfall direkt als „das ist jetzt unpassend“ kommentiert. Insgesamt entstanden in der synchronen Fokusgruppe sehr schnell mehrere Kleingruppen, die unterschiedliche Diskussionsstränge verfolgten. Die beste Themensteuerung war in den asynchronen Online-Fokusgruppen möglich. Hier waren weder starke Effekte durch Meinungsführer noch durch Bildung von Kleingruppen zu beobachten. 2.2.4. Unterschiede bei den Ergebnissen Die verschiedenen Methoden lieferten vergleichbare Ergebnisse zu den vorgegebenen Fragestellungen, wiesen aber im Detail Unterschiede auf: In der klassischen Online-Fokusgruppe konnte oft ein sprunghafter Wechsel der Themen beobachtet werden. Dadurch wurden bestimmte Themen nicht so detailliert betrachtet. Die synchrone Online-Fokusgruppen erbrachte rationale und emotionale Erkenntnisse und war eher problemorientiert. Die asynchrone Online-Fokusgruppe war durch ihre hohe Diskussionstiefe sehr ergiebig und aus unserer Sicht die beste Methode zur Generierung von Detailerkenntnissen zu einem Thema. Allerdings fehlte es an Emotionalität, es herrschte eindeutig eine Faktenorientierung vor. 2.3. Empfehlungen auf Basis des vorgestellten Methodenvergleichs und der Erfahrung mit anderen Fokusgruppen-Projekten 2.3.1. Auswahl von Fragestellungen Klassische Fokusgruppen sind unserer Erfahrung nach gut geeignet zur Untersuchung von Themen aus den Bereichen Unternehmensbild, Service,

97


Werbewirksamkeit und Evaluation von Produktideen. Sie haben immer dann Vorteile, wenn es um emotionale Aspekte geht oder wenn Themen diskutiert werden, die für die Teilnehmer neu sind. Hierbei sollten nicht mehr als zwei unterschiedliche große Themenblöcke mit Unterthemen behandelt werden. Auf die Entwicklung von Software bezogen heißt dies, dass vor allem in frühen konzeptionellen EntwicklungsPhasen – wenn das Potenzial einer Idee abgeschätzt werden soll – die klassische Form der Fokusgruppe vorzuziehen ist. Man kann aber bei detailreichen Themen wie z. B. der Besprechung von Anwendungen nicht zu viel Tiefe erwarten. Synchrone Online-Fokusgruppen sind dazu geeignet, zusätzlich zu den emotionalen Aspekten auch „rationale“ Informationen liefern zu können. Eine Herausforderung ist es, die „schreibfaulen“ Teilnehmer zu aktivieren und die Bildung einer Gruppe von Schnellschreibern zu verhindern. Wie bei der klassischen Fokusgruppe sollten auch hier nicht mehr als zwei große Themenblöcke diskutiert werden. Es besteht die Gefahr, dass die emotionalen Aspekte die Oberhand gewinnen und ein verzerrtes Bild ergeben. Dies ist besonders dann der Fall, wenn sich einzelne Teilnehmer zu starken Meinungsmachern entwickeln und eher aus dem „Bauch heraus argumentieren“. Um diese Effekte zu kontrollieren, empfehlen wir beim Einsatz von synchronen Fokusgruppen mindestens zwei Diskussionen mit gleicher Stichprobenauswahl und gleicher Fragestellung durchzuführen. Asynchrone Online-Fokusgruppen sind in unseren Augen sehr flexibel einsetzbar und können viele Informationen zu rationalen Beweggründen und klare Analysen liefern. Neben Image- und Servicefragestellungen können Fragen zu Software-Anwendungen diskutiert werden. Heißblütige Diskussionen sind jedoch nicht zu erwarten. Die Ergebnisse können unserer Meinung nach vor allem bei der Weiterentwicklung von Produkten helfen. Durch eine Erhöhung der Durchführungszeit kann die Anzahl der angesprochenen Themen erhöht werden, wobei bis zu drei Wochen Felddauer denkbar sind. Hierbei können die Teilnehmer

98

durch das Vorlegen von entsprechenden Stimuli und der individuell aufteilbaren Zeit sehr tief in die Materie einsteigen. Dabei ist darauf zu achten, dass die Themen hinreichend unterschiedlich sind, sonst lässt der Elan schnell nach. 2.3.2. Anforderungen an die Moderation Von den drei Fokusgruppentypen benötigte die synchrone Online-Fokusgruppe wohl die stärkste führende Moderation. Aufgrund der Gruppendynamik war ein leichtes Abdriften möglich. Die einfachste Moderation war bei der asynchronen Online-Fokusgruppe möglich. Auch wenn die Teilnehmer hier kontrovers diskutierten, wurde über die vorgegebene Aufgaben- und Fragenstruktur die Gruppe gut auf das Thema fokussiert. Bei allen drei Fokusgruppenmethoden ist unserer Meinung nach die Präsentation von gutem Stimulus-Material von Vorteil. Zum einen wirkte dieses aktivierend und steuernd, zum anderen ermöglichte es den Teilnehmern „konkrete“ Diskussionsbeiträge zu liefern. 3. Praktikabilitätstest der Methode „asynchrone Online-Fokusgruppe“ Im Rahmen der allgemeinen Überprüfung der Tauglichkeit von Online-Methoden konzipierte die DATEV eG in Kooperation mit dem Dienstleister GfK SirValUse Consulting GmbH eine weitere asynchrone Online-Fokusgruppe. Geplant und umgesetzt wurde eine Befragung zu einer aktuellen Anwendungssoftware. Insgesamt beantworteten 26 SachbearbeiterInnen von Steuerkanzleien (Anfänger, Power-User und Abbrecher) über 5 Tage hinweg ihre allgemeinen und gruppenspezifischen Fragestellungen. Für die Durchführung wurde von GfK SirValUse das Tool Revelation eingesetzt, welches im Nachgang der Studie ebenfalls evaluiert wurde. Informationen zum Tool finden sich auf der Webseite des Herstellers (www.revelationglobal. com). Die Vorteile, die Nachteile sowie

die praktische Relevanz der Methode für die DATEV eG werden im Folgenden kurz beschrieben. 3.1. Bewertung der asynchronen OnlineFokusgruppe aus Sicht der DATEV eG 3.1.1. Kosteneinsparung In der Literatur wird als Argument für den Einsatz von Online-Verfahren oft die potenzielle Kosteneinsparung genannt. Auch wir können dies nach dem praktischen Einsatz bestätigen. Im Vergleich zu klassischen Fokusgruppen sind Kosteneinsparungen möglich. 3.1.2. Verbesserung der Verfügbarkeit von potenziellen Teilnehmern Bedeutsamer als die Kosteneinsparungen war für uns im aktuellen Fall jedoch die Verfügbarkeit von Teilnehmern, die durch ein Anwerben im gesamten Bundesgebiet drastisch erhöht wurde. Vor allem ist die Tatsache hervorzuheben, dass eine spezielle Teilnehmergruppe mit ehemaligen Anwendern gebildet werden konnte, die die Verwendung des betreffenden Produkts eingestellt hatten. 3.1.3. Hervorragende Beantwortung fachspezifischer Fragestellungen Wie in Abschnitt 2.3.1 erläutert, ermöglichen asynchrone Online-Fokusgruppen im Vergleich zur klassischen Fokusgruppe aufgrund der verwendeten Methode neben allgemeinen Fragen auch die Vorgabe von nüchternen und sehr anwendungsspezifischen Fragestellungen. Theoretisch könnte man sogar die Ebene der Diskussion verlassen und den Teilnehmern konkrete Aufgabenstellungen vorgeben und die vorgeschlagenen Lösungswege erheben. 3.1.4. Hohes Niveau der Teilnehmerantworten Die Qualität des Teilnehmerfeedbacks war hierbei durch die den Teilnehmern


Usability Professionals 2012 Nutzerwissen wissen und nutzen

zur Verfügung stehende Zeit hoch. Die Antworten ließen darauf schlussfolgern, dass die Anwender bestimmte Diskussionspunkte bzw. Fragen mit der Ihnen zur Verfügung stehenden Software nochmals durchgespielt haben. 3.1.5. Gute Steuerbarkeit des Studienverlaufs Da in dem verwendeten Forum aufgrund der umfangreichen Report-Funktionen des Revelation-Tools alles sehr transparent und ohne große Zeitverzögerung ablief, konnte die Antwortrate durch geeignete Moderation auf hohem Niveau gehalten werden. 3.1.6. Einfache Partizipation der Entwicklungsabteilung Ein weiterer großer Pluspunkt ist die Tatsache, dass alle an der SoftwareEntwicklung beteiligten Personen an einer derartigen Fokusgruppe als Beobachter partizipieren können. Revelation ermöglicht eine leichte Freischaltung von Beobachter-Zugängen. Auf diese Weise können Fachentwickler sich direkt mit den Gedankengängen von Endanwendern auseinandersetzen. Nebenbei kann so auch das Konzept dieser User Centered Design-Methode direkt im Entwicklungsteam bekannt gemacht werden. 3.1.7. Erhöhter Organisations- und Durchführungsaufwand für die Projektverantwortlichen Innerhalb der DATEV UX-Abteilung entsteht im Vergleich zur klassischen Fokusgruppe ein leicht erhöhter Organisationsaufwand zur Vorbereitung einer Studie. Merklich mehr Aufwand entsteht jedoch bei den Projektverantwortlichen der DATEV Fachabteilung – dem Auftraggeber derartiger Studien. Während bei normalen Fokusgruppen die Interviewleitfäden für ca. 1,5 h Diskussionsstoff bieten müssen und die Fragestellungen auch eher umgangssprachlich formuliert sein können, ist es bei asynchronen Online-Fokusgruppen notwendig, ein

präzises Szenario mit Fragen für mehrere Tage zu erstellen. Die Fragen müssen dabei klar und verständlich formuliert sein. Werden Screenshots zur Erläuterung eingesetzt, müssen auch diese eine gewisse Qualität haben und ggf. auch per se aussagekräftig sein. Ferner muss der Projektverantwortliche der Fachabteilung einen merklichen Teil seiner Arbeitszeit für Beobachtertätigkeiten aufwenden. Bei klassischen Fokusgruppen ist diese Zeit viel kürzer. 3.1.8. Nüchterne Informationen statt reger Diskussionen Betreffend der erwünschten Ergebnisse besteht ebenfalls eine Einschränkung: Die verwendete Methode eignet sich gut für Befragungen zu Anwendungsproblemen bezüglich einer bereits existierenden Software. Diskussionen hingegen waren trotz kreativer Anregung durch die Moderatorin schwer in Gang gekommen und flachten nach kurzer Zeit ab. 3.2. Bewertung aus Sicht der Teilnehmer Um die Praxistauglichkeit der Methode bewerten zu können wurde im Anschluss an die Fokusgruppe eine kurze Nachbefragung mittels Online-Fragebogen bei den Teilnehmern durchgeführt. 22 der insgesamt 26 End-Teilnehmer haben ihre Beurteilungen bezüglich Einladungsprozedur, Qualität des verwendeten Tools, Weiterempfehlungsbereitschaft und Zeitbedarf geäußert. Zur Beurteilung wurden die Teilnehmer dazu aufgefordert Schulnoten oder Werte für Ihre Zustimmung zu vergeben. 3.2.1. Problemloser Einstieg in das Forum Kein Teilnehmer hatte Probleme mit der Verständlichkeit der vorbereitenden Informationen und dem Erstellen eines Benutzer-Logins. Nur vereinzelt gab es Probleme mit der Weiterleitung von E-Mails. Für die beiden Bereiche wurden die Noten „Sehr gut“ bis „Gut“ vergeben.

3.2.2. Gute Noten für Revelation Auch die Kurzbeurteilung des RevelationTools fiel erfreulich aus. Im Vorfeld war innerhalb der DATEV eG kritisch diskutiert worden, wie wohl DATEV-Softwarenutzer auf ein derartiges Internetforum reagieren würden. Die Sorgen erwiesen sich jedoch als unbegründet: Die Benotung bewegt sich im „guten“ Bereich, zumeist deutlich über der Note 2 und auch während des Studienverlaufs hatte kein Teilnehmer Beschwerden über das Tool geäußert. 3.2.3. Akzeptanz der Online-Fokusgruppe als geeignetes Instrument Im Mittel gaben die 22 Teilnehmer der Nachbefragung deutlich positive Zustimmungswerte zur Methode ab. Die Beurteilungen bewegten sich im Bereich von 1,4 bis 2,67 bei einer Spanne von 1 bis 5. Es wurde bejaht, dass die Zeit sinnvoll genutzt war, dass die Teilnahme an der Online-Fokusgruppe „Spaß gemacht“ hat, und dass die Online-Fokusgruppe ein geeignetes Instrument ist, um Verbesserungsvorschläge zu sammeln. Erfreulich war vor allem, dass die wichtige Weiterempfehlungsbereitschaft zu einer Teilnahme hoch war. 3.2.4. Zu viele Fragen, zu viel Aufwandszeit In der durchgeführten asynchronen OnlineFokusgruppe konnte die angepeilte durchschnittliche Zeit von maximal 25 Min., die die Teilnehmer zu Beantwortung der Fragen aufwenden sollten, nicht eingehalten werden. Im Nachhinein war klar, dass zu viele Fragen gestellt wurden und die Teilnehmer sich teilweise sehr ausführlich mit der Materie beschäftigt hatten. Letzteres lag sicherlich auch an den DATEV-Rahmenbedingungen. Aufgrund der Genossenschaftsstruktur sind Steuerberater (oder deren Mitarbeiter) – die ja Mitglieder der DATEV eG sind – teilweise hoch motiviert bei Produktverbesserungen mitzuwirken. Im Mittel haben die 22 Teilnehmer der Nachbefragung ca. 2,5 h Gesamtzeit in die

99


Durchführung der asynchronen OnlineFokusgruppe investiert. Dies ist im Schnitt eine halbe Stunde mehr als bei der Durchführung einer Fokusgruppe im Teststudio. Gleichzeitig heißt dies auch, dass einzelne beträchtlich mehr Zeit investiert haben (6 Teilnehmer lagen im Bereich von 35 bis 50 Min.). Der Vorteil durch die entfallenden Reise-Aufwände wird hierdurch relativiert. Einzelne Teilnehmer haben hierzu auch Kritik geäußert. 4. Wichtige Punkte bei der Durchführung aus Sicht von GfK SirValUse Nicht nur für das beauftragende Unternehmen, sondern auch für den durchführenden Dienstleister bedeutet eine asynchrone Fokusgruppe einen erhöhten Arbeitsaufwand. Dieser schlägt sich in allen Phasen des Projektes nieder. Neben einer umfangreichen Dokumentation und disziplinierten Organisation ist jedoch die besondere Herausforderung, die Teilnehmer zu motivieren und zu bewegen, dauerhaft Beiträge zu erstellen und sich untereinander auszutauschen. 4.1. Vorbereitung 4.1.1. Einladung der Probanden Bereits bei der Rekrutierung ist es wichtig, den potentiellen Teilnehmern Informationen über die Methode zu geben, damit diese sich bewusst für oder gegen eine Teilnahme entscheiden können. Reicht bei face-to-face-Methoden ein einfaches Einladungsschreiben, welches Ort, Zeit und Datum enthält, ist dies bei Online-Fokusgruppen nicht ausreichend. Unsicherheiten, beispielsweise über den genauen Ablauf, können nicht vor Ort im Gespräch geklärt werden, da es kein menschliches Gegenüber gibt. Deshalb verschickte GfK SirValUse Consulting im Vorfeld der Studie an alle Teilnehmer eine detaillierte Ablaufbeschreibung. Neben einer verständlichen Darstellung der Informationen – welche von den Teilnehmern im Nachgang positiv bewertet wurde – war

100

dabei ein wichtiger Punkt, den Teilnehmern aufzuzeigen, dass hinter der virtuellen Methode reale Personen stehen, die ernsthaft an den Beiträgen interessiert sind. Das sollte der Studie einen verbindlichen Charakter verleihen und verhindern, dass sich die Teilnehmer während der Laufzeit aus der Fokusgruppe herausziehen. So beinhaltete das Anschreiben neben praktischen Hinweisen auch eine Vorstellung der Moderatorin mit Foto und Kurzbeschreibung. Besonderes Augenmerk wurde auf eine persönliche Ansprache gelegt, um den Mangel an persönlichem Kontakt zu kompensieren. 4.1.2. Vorbereitung der Studiendurchführung und -inhalte Die Fragestellungen, welche von der Studie beantwortet werden sollen, waren – wie bei jeder Nutzerstudie – vom Auftraggeber vorgegeben. Die zuständige Fachabteilung der DATEV eG hatte bereits eine hohe Anzahl an Einzelfragen detailliert ausformuliert. Diese galt es zunächst auf Verständlichkeit und OnlineTauglichkeit zu prüfen. Da bei asynchronen Fokusgruppen keine Möglichkeit der direkten Nachfrage besteht, müssen die gestellten Fragen und Aufgaben leicht verständlich sein und sollten keinen Spielraum für Interpretationen offen lassen. In der durchgeführten Studie ging es hauptsächlich um die Erhebung von Erfahrungen mit einer Software, weniger um die Diskussion neuer Konzepte. Dadurch war es möglich, viele Fragen in einem hohen Detailgrad an die Teilnehmer weiterzugeben. Bei dem eingesetzten Tool Revelation kann vom Moderator für jede Frage entschieden werden, ob die Antworten privat sind, also nicht von den anderen Teilnehmern gesehen werden können, ober ob die Antworten den anderen zugänglich gemacht werden sollen. Das Einsehen der Antworten anderer Teilnehmer kann in zwei Abstufungen geschehen: Entweder kann ein Teilnehmer die Antworten der anderen sofort sehen oder erst, wenn er selbst eine Antwort abgegeben hat. Letzteres ist eine gute Möglichkeit, um unbeeinflusste Antworten zu erhalten und dadurch

eine – möglicherweise auch kontroverse – Diskussion entstehen zu lassen. Dies ist in face-to-face-Fokusgruppen nicht ohne weiteres möglich, da sich Antworten oft an dem zuvor Gesagten orientieren und es leicht zu Meinungsführerschaften Einzelner kommen kann. Die Entscheidung, welcher Antworttyp bei der Online-Fokusgruppe eingesetzt wird, wurde vom Inhalt der Frage abhängig gemacht. Wenn es beispielsweise darum ging, Wissen über bestimmte Bereiche abzufragen oder herauszufinden, was die Teilnehmer persönlich als schwierig empfanden, wurde der private Antworttyp gewählt. Dadurch wurde die Hemmschwelle gesenkt, ehrliche Antworten zu geben, ohne bei den Teilnehmern das Gefühl persönlicher Unzulänglichkeit zu erzeugen, wenn sie zugeben, etwas nicht zu verstehen. Da es sich jedoch bei der Methode nicht um eine klassische Onlinebefragung handelte sondern um eine OnlineFokusgruppe, wurden auch bewusst Elemente eingesetzt, die zum Austausch untereinander anregen sollten. Dies waren beispielsweise Fragen zur gemeinsamen Ideengenerierung. Um den Mangel an direktem Kontakt bei der virtuellen Methode zu kompensieren, wurde auch beim Erstellen der Fragen bewusst auf eine persönliche Formulierung geachtet. Die Teilnehmer sollten das Gefühl haben, ihre Erlebnisse einer realen Person zu erzählen. So gab es jeden Tag eine persönliche Begrüßung und – sofern möglich – waren Fragen in der Ich-Form geschrieben. 4.2. Durchführung Die Fragen waren bereits im Vorfeld in das Revelation-Tool eingepflegt worden, so dass diese während der Feldphase automatisch an die Teilnehmer ausgeliefert wurden. Die Haupttätigkeit des Moderators in dieser Zeit war zu beobachten, ob sich alle


Usability Professionals 2012 Nutzerwissen wissen und nutzen

Probanden an der Fokusgruppe beteiligen, sich mit der Fachabteilung über gezielte Nachfragen abzustimmen, weitere Fragen in Revelation einzupflegen und Fragen/E-Mails von den Teilnehmern zu beantworten. Bei Onlinestudien, welche über einen längeren Zeitraum laufen, nimmt im Verlauf der Zeit die Antwortrate ab. Dies sollte durch das gezielte Eingehen auf Antworten jedes einzelnen Teilnehmers bis zum zweiten bzw. dritten Tag verhindert werden. Mit diesem Ansatz kann verdeutlicht werden, dass die Teilnehmer ihre Antworten nicht nur einem Tool geben, sondern einer tatsächlichen Moderatorin, welche auf sie reagiert. Es wurde im Verlauf der Diskussion deutlich, dass, je öfter und persönlicher die einzelnen Teilnehmer angesprochen wurden, auch deren Beiträge umfangreicher wurden. Aus der reinen Abarbeitung der Fragen wurde ein Mitteilen von Informationen. Das Teilziel, alle Teilnehmer anzusprechen, erfordert gerade bei parallelen Gruppen und/oder hohen Teilnehmerzahlen eine disziplinierte Organisation und Dokumentation. 4.3. Auswertung Für die Auswertung von asynchronen Online-Fokusgruppen muss ein erhöhter Zeitaufwand einkalkuliert werden. Im Gegensatz zu face-to-face-Fokusgruppen hat der Moderator nach Abschluss der Feldphase nicht alle Aussagen bereits einmal gehört und sich darüber ein Gesamtbild verschaffen können. Obwohl täglich die Rückmeldungen betrachtet wurden, war die Beschäftigung mit den Daten eher organisatorischer als analytischer Art. Die inhaltliche Betrachtung oblag den Beobachtern der DATEV-Fachabteilung. Die Aussagen müssen somit nach Ende der Feldphase einzeln gesichtet und analysiert werden. Aufgrund des Studienaufbaus glich die Auswertung hier eher der einer Onlinebefragung, bestehend aus ausschließlich offenen Fragen. In der Studie für die DATEV eG kamen am Ende 598 offene Rückmeldungen von den insgesamt 26 Teilnehmern zusammen.

5. Gesamtfazit 5.1. Zum Fokusgruppen-Methodenvergleich

wurde konsequenterweise als neue Standard-Methode in das User Centered Design-Methodenset der DATEV eG aufgenommen.

Auch wenn es sich nur um eine einzige Vergleichsstudie handelt und die Verallgemeinerung der Erkenntnisse daher schwierig ist, zeigte der Methodenvergleich, dass es zwischen der klassischen Fokusgruppe, der synchronen sowie asynchronen OnlineFokusgruppe erkennbare Unterschiede gibt. Dies betrifft zum einen die organisatorische Durchführung und zum anderen die erhobenen Resultate – was aus unserer Sicht viel bedeutsamer ist. Die Ergebnisse sind zwar vergleichbar, es gibt jedoch Unterschiede im Detail.

Bei den nächsten asynchronen OnlineFokusgruppen werden vom DATEV User Experience Design-Team folgende Punkte beachtet werden: –– Bessere Konzeption der Fragestellungen im Hinblick auf die Trennung von eher „analytischen“ und „emotionalen“ Aspekten. –– In diesem Zusammenhang auch eine bessere Vorab-Klärung darüber, wo und wie ggf. Diskussionen zwischen den Teilnehmern erwünscht sind und wie diese aktiviert werden können. Zum Beispiel kann eine stärkere Einbindung von Kreativtechniken den Austausch der Teilnehmer untereinander fördern. –– Es wird eine bessere Berücksichtigung der erhöhten Zeitaufwände bei der Konzeption, der Durchführung und der Auswertung nötig sein. Dies schließt auch einen erhöhten Betreuungsaufwand für die DATEVFachabteilungen – den Auftraggeber solcher Studien – ein. –– Zuletzt ist eine bessere Kontrolle des Zeitaufwands, den die Teilnehmer in die Beantwortung der Fragestellungen investieren, unerlässlich um eine „Überlastung“ der Teilnehmer zu vermeiden.

Vor allem die asynchrone Online-Fokusgruppen kann, wenn die Rahmenbedingungen nicht strikt kontrolliert werden, nur bedingt als Ersatz für eine klassische Fokusgruppe verwendet werden. Sie ist unserer Einschätzung nach fast als ein eigenständiges Analyse-Instrument zu betrachten und stellt eine hervorragende Ergänzung zur Methode der klassischen Fokusgruppe und der synchronen Online-Fokusgruppe dar. Sie kann bei Bedarf sehr gut rationale Begründungen und fundierte Überlegungsprozesse zur Verwendung von Software erheben. Insgesamt sind beide Online-Verfahren eine wertvolle Methodenbereicherung im Bereich der User Research. 5.2. Zum Praxiseinsatz der asynchronen Online-Fokusgruppe Die abschließende Beurteilung der asynchronen Online-Methode war erfreulich positiv. Die Kosteneinsparung steht zwar einem erhöhten Aufwand bei der Konzeption gegenüber, die Ergebnisse sind aber sehr reichhaltig. Die Methode ist flexibel und mit unterschiedlichen Medien (Screenshots, Videos, Skizzen) einsetzbar. Aufgrund der leichteren Verfügbarkeit von Teilnehmern ist bei Bedarf auch eine Segmentierung von Untersuchungsgruppen möglich. Die Durchführung von asynchronen Online-Fokusgruppen

101


User Experience Wissen recyclen Visual Feedback Consolidation mit Interaction Maps

Stephanie Föhrenbach Zühlke Engineering AG Wiesenstrasse 10a 8952 Schlieren Schweiz sfo@zuehlke.com

Markus Flückiger Zühlke Engineering AG Wiesenstrasse 10a 8952 Schlieren Schweiz mdf@zuehlke.com

Abstract Bei der Entwicklung interaktiver Systeme herrscht eine große Meinungsvielfalt bezüglich guter Usability. UX Experten müssen mit Argumenten wie: „Der Markt will X“, „meine Tante macht dies so“, „das funktioniert nicht, wir haben das schon probiert“ und „ich kann das doch auch bedienen“, konfrontiert. Dies ist besonders dann der Fall, wenn die eigentlichen Benutzer extern sind und die Rückmeldungen aus dem Markt lose verstreut in die Köpfe gelangen, so unter anderem bei Consumer Produkten. Dieser Beitrag stellt ein Kommunikationsmittel (Interaction Map) mit einer entsprechenden Methodik (Visual Feedback Consolidation) vor, mit welchen ein UX Experte die verstreut eintreffenden Feedbacks zusammentragen und konsolidieren kann. Der UX Experte bekommt ein Mittel an die Hand, mit dem eine langfristige strategische Planung von Usability Aktivitäten ermöglicht wird. Die Methodik holt dabei die internen Stakeholder und deren Wissen ab und hilft den Entscheidungsträgern, ihr Bild zu komplettieren und abzustimmen. Dies gibt den Entscheidungsträgern einen Rahmen, um gezielt Verbesserungsmaßnahmen in Auftrag zu geben. Die Organisation erhält so ein gemeinsames Wissen der erreichten Benutzungsqualität und ermöglicht es informiert zu entscheiden.

1. Divergierende Ansichten über die User Experience Als Usability Professionals werden wir im Projektalltag oft mit der Situation konfrontiert, dass ein Produktportfolio weiterentwickelt werden soll, unter den Stakeholdern jedoch Uneinigkeit über Richtung und Fokus herrscht. Dabei hätten Firmen eigentlich reichlich Wissen über die Produkte und wie gut Benutzer damit umgehen können. Das Feedback von Benutzern fliesst jedoch über vielfältige Kanäle (Helpdesk, Usability Tests, persönliche Bekannte, Foren, eigene Erfahrungen und mehr) in die Entwicklung. Dadurch ist dieses Wissen über die ganze Organisation zersplittert und es entstehen divergierende Sichten auf die Benutzung der Produkte. Die Folge sind unterschiedliche Gewichtungen der bestehenden Probleme und abweichende Lösungsansätze. [Abb. 1]

102

In dieser Situation besteht nun für einen Usability Professional das Hindernis, dass die Resultate aus Usability Maßnahmen den unterschiedlichen Meinungen der Stakeholder nicht entsprechen und so nicht von allen relevanten Stakeholdern aufgenommen werden können. So kann beispielsweise eine Erfassung der Benutzung mit einer Contextual Design Studie (Beyer, Holzblatt, 1998) einen Feedbackkanal schaffen und wichtige Erkenntnisse zusammentragen.

Keywords: /// Feedback Consolidation /// Mappingtechnik /// Usability Engineering /// Requirements Engineering

Der so erschlossene Feedbackkanal konkurriert jedoch mit den bestehenden Kanälen und führt so weniger zu einer Einigung, sondern schafft mehr zerteiltes Wissen. Die Erkenntnisse aus Usability Maßnahmen fließen dann nur bedingt in die Produktentwicklung ein. Die Usability Maßnahmen laufen Gefahr, als nicht nutzbringend wahrgenommen zu werden und die Bereitschaft zu investieren sinkt. Storyboards und Mock-ups sind Mittel, um in einem frühen Stadium mit

Abb. 1. Vielfältige Feedbackkanäle für Informationen vom Endbenutzer in die Entwicklung


Usability Professionals 2012 Nutzerwissen wissen und nutzen

verschiedenen Stakeholdern zu sprechen und eine Einigung zu erzielen (Richter, Flückiger, 2010). Sie zeigen eine mögliche Lösung auf und fordern Widerspruch und Zuspruch heraus. Beiden Techniken ist gemein, dass sie auf eine künftige Lösung fokussieren. Herrscht jedoch zu große Uneinigkeit über die wesentlichen Probleme der aktuellen Lösungen, wird diese Uneinigkeit in der Diskussion der neuen Lösung ausgefochten. Die Techniken helfen durch ihren Lösungsfokus nur bedingt, abweichende Ansichten über bestehende Probleme zu bereinigen.

Bekannte Techniken hierzu sind Mapping Techniken, wie z. B. eine Experience Map (Torio 2011) oder eine Requirements Map (Adlin, Jameson, Krebs 2001). In der Arbeit mit interaktiven Geräten, hat sich die nachfolgend beschriebene Interaction Map als gutes Hilfsmittel herausgestellt. Eine Produktgalerie wie beispielsweise eine CoWall (Löwgren 2005) mit früheren und aktuellen Produkten, Konkurrenzprodukten und alternativen Lösungen ergänzt die Interaction Map und lässt Probleme und bekannte Lösungsansätze erfahrbar werden.

2. Wissen konsolidieren, um UX Maßnahmen zu planen

Diese Hilfsmittel erzielen die gewünschte Wirkung aber erst, wenn sie mit einem Konsolidierungsprozess kombiniert werden, der die Stakeholder aktiv bei der Erstellung der Hilfsmittel involviert und damit der nötige Wissensabgleich angestossen wird.

In einer Firma, die viel, jedoch zersplittertes Wissen über die User Experience besitzt, ist unser Ansatz, zuerst das bestehende Wissen der Firma zu konsolidieren, um dann mit Usability Engineering Methoden gezielt Wissenslücken zu schließen und bestehende Annahmen zu überprüfen. Durch das dabei entstehende, gemeinsame Verständnis der Stakeholder können Usability Maßnahmen breiter abgestützt in Auftrag gegeben werden und die Resultate in das Gesamtbild integriert werden. Eine passende Methode erzielt dabei insbesondere die folgende Wirkung: –– Die Methode soll bekanntes Wissen zusammentragen und in ein Gesamtbild fügen, so dass ein Stakeholder seine Punkte mit genügend Gewicht wiederfindet. –– Die Methode soll umgekehrt das Wissen der Stakeholder abgleichen und erweitern. –– Die Methode soll eine konsolidierte Gewichtung der Probleme und Lösungen ermöglichen. –– Die Methode soll die Stakeholder dazu bringen, die Probleme aus Sicht der User Experience zu betrachten. Damit dies gelingen kann, sind Hilfsmittel notwendig, mit welchen die Stakeholder Probleme und Lösungsansätze einfach überblicken, erfahren, diskutieren, und in einen Zusammenhang bringen können.

3. Visual Feedback Consolidation Für die Konsolidierung verwenden wir einen Prozess, der zu den bereits erwähnten Mapping Techniken und der Produktgalerie auch Methoden wie Stakeholder Interview, Bewertungstechniken aus dem Requirements Engineering (siehe z. B. Pohl 2008), mit Techniken aus dem Usability Engineering kombiniert. Ebenfalls fließen auch Elemente aus dem Konfliktmanagement (Vigenschow, Schneider, Meyrose 2011) ein. 3.1. Ablauf einer Visual Feedback Consolidation Der Konsolidierungsprozess verläuft in den folgenden Schritten: Startpunkt setzen Der Usability Professional identifiziert zusammen mit einem oder zwei Stakeholdern die Berührungspunkte des Benutzers mit dem Produkt. Gleichzeitig nehmen sie für das Produkt relevante Eigenschaften der Benutzer auf. Die Informationen werden in einer ersten Version der Interaction Map visualisiert. So entstehen eine Grundstruktur und ein

Kommunikationsmittel für die weiteren Interviews (siehe z. B. [Abb. 3]). 1. Zusammenführen von Informationen und Konsolidieren In Einzelinterviews wird das Wissen der Stakeholder über Probleme in der Benutzung und ihnen bekannte Lösungsmöglichkeiten abgefragt. Die Interaction Map dient als Leitfaden für das Interview und wird durch die gewonnenen Informationen erweitert und verfeinert. Während des Interviews sollten idealerweise das besprochene Produkt und auch verwandte Produkte zum Ausprobieren dabei sein. So können Sachverhalte anschaulich demonstriert werden. Die Interaction Map ist das Arbeitsmittel und das Protokoll eines solchen Interviews und wird im Nachgang eines Interviews für das nächste Interview aufbereitet. 2. Bewerten der Probleme und Lösungsansätze Hat der Usability Professional die relevanten Stakeholder befragt und deren Wissen auf die Interaction Map transferiert, erfolgt eine Bewertung der gefundenen Probleme und Lösungsansätze. Für die Bewertung können verschiedene Methoden angewendet werden. Eine einfache Gewichtung in drei bis fünf Stufen kann schon ausreichen. Um Diskussionen zu minimieren empfiehlt es sich den Durchschnitt aus mehreren individual Bewertungen zu bilden. 3. Handlungsfelder beschliessen Durch das obige Vorgehen ist mit der Interaction Map eine konsolidierte Sicht auf das im Unternehmen vorhandene Wissen entstanden, in dem sich jeder Stakeholder wiederfindet. Anhand dieser Darstellung können dann Handlungsfelder gezielt beschlossen werden (z. B. anhand der durchgeführten Bewertung). 3.2. Rollen und Aufgaben Der geschilderte Ablauf geht von den folgenden Rollen aus: Stakeholder: Personen, die diese Rolle wahrnehmen, liefern die Informationen,

103


Vorgehen und arbeitet die Erkenntnisse in die Interaction Map ein. Eine solche Person kann die Diskussion auf die User Experience fokussieren und hat einen entsprechenden Erfahrungshintergrund. Sie kann ebenfalls mit verschiedenen Persönlichkeiten umgehen, Workshops moderieren, Konflikte früh erkennen und in gewissen Grenzen auch vermitteln. Für diese Rolle benötigt es erfahrene Usability Professionals.

Abb. 2. Schematische Abbildung einer Interaction Map

um die Interaction Map aufzubauen und sind zugleich auch Empfänger für die bereits konsolidierte Information. Das Ziel ist deren Wissen zu konsolidieren. Stakeholder bewerten im zweiten Schritt die konsolidierten Probleme und Lösungsansätze. Als Stakeholder sind die für die User Experience relevanten Wissensträger und Entscheidungsträger in einer Organisation zu identifizieren. Moderator: Der Moderator wird typischerweise von einer Person wahrgenommen, die weder Stakeholder noch Auftraggeber ist. Diese Person definiert und treibt das

Auftraggeber: Nebst dem Erteilen des Auftrags, also dem konkreten Ziel, welches erreicht werden soll, kann ein Auftraggeber Zugang zu den Stakeholdern verschaffen und dient als Eskalationsstufe, wenn die Zielerreichung gefährdet ist. Die Rolle Auftraggeber wird entsprechend von Personen mit Leitungsfunktionen, z. B. ein Projektleiter, Programmleiter, Produktmanager, Bereichsleiter und mehr, wahrgenommen werden.

Nimmt eine Person mehrere Rollen war, dann besteht möglicherweise auch ein Konflikt, der das Ziel gefährden kann. Ist beispielsweise der Auftraggeber auch ein Stakeholder, dann besteht ein Interessenkonflikt in dieser Person mit der Gefahr, dass das Wissen des Auftraggebers dominiert und die Konsolidierung zwar auf dem Papier, aber nicht in den Köpfen der anderen Stakeholder stattfindet. Ein ähnlicher Interessenskonflikt kann bestehen, wenn die Person, welche den Prozess moderiert, auch Stakeholder ist.

4. Interaction Map Als Hilfsmittel für den Konsolidierungsprozess ist eine Interaction Map geeignet: [Abb. 2] (siehe [Abb.2] für eine schematische Abbildung). Das Gerüst der Interaction Map sind die Berührungspunkte zwischen Benutzer und Produkt. Sie werden entlang des Benutzungsablaufs dargestellt. An diesem Gerüst lassen sich die weiteren zusammengetragenen Informationen konsolidieren. Eine Interaction Map enthält folgendes: Die Inhalte einer Interaction Map sind in [Tab. 1] aufgeführt. Die Interaction Map entsteht im Konsolidierungsprozess. Die folgenden Abbildungen [Abb. 3], [Abb. 4] und [Abb. 5] zeigen den Entstehungsprozess einer Interaction Map exemplarisch. Als Beispiel dient ein Projekt zur Verbesserung eines Teppichmessers. [Abb. 3] Abbildung 3 zeigt das Gerüst der Interaction Map. Dieses Gerüst entsteht bei der Vorbereitung der Interviews [Abb. 3]. Abbildung 4 zeigt nun den Berührungspunkt Klinge wechseln nach dem ersten Interview. [Abb. 4] Mit der Menge der konsolidierten Information verändert sich auch das Gerüst, welches nach Bedarf durch den Usability Professional ergänzt wird. Dies ist im

Information

Darstellung

Berührungspunkte zwischen dem Produkt und dem Benutzer entlang dem Benutzungsablauf

z. B. als Kreisprozess, linearer Prozess

Relevante Eigenschaften der Benutzer

z. B. ein Foto einer Person mit einem sehr charakteristischen Zitat im Zentrum der Interaction Map platziert

Beobachtungen über Problemen an einem Berührungspunkt

z. B. als Notizzettel zu einem Berührungspunkt

Die Produktteile, welche an den Problemen beteiligt sind, in verschiedenen Varianten

z. B. als Fotos, Skizzen, Screenshots, wichtige Punkte werden markiert

Bewertung der Probleme

z. B. durch eine Markierung mittels Punkten oder mittels Farbcodierung der Notizzettel

Lösungsansätze zu einem Problem

z. B. als Notizzettel zu einem Berührungspunkt oder zu einem Problem

Bewertung der Lösungsideen

Analog zur Bewertung der Problemen

104

Tab.1. Auf der Interaction Map dargestellte Informationen


Usability Professionals 2012 Nutzerwissen wissen und nutzen

Abb. 3. Das Initiale Gerüst als Startpunkt für die ersten Interviews

Ausschnitt in Abbildung 5: nach weiteren Interviews. gut zu sehen: der Berührungspunkt Klinge wechseln wurde hier in drei Schritte aufgebrochen. [Abb. 5] Beim Erstellen einer Interaction Map lassen sich die herkömmlichen Mittel verwenden: Zu Beginn sind dies in erster Linie Papier und Bleistift, in den Interviews kommen grossflächiges Papier und Haftnotizzettel zum Einsatz, später ausgedruckte Poster. Dadurch kann der Usability Professional zusammen mit dem Stakeholder die Interaction Map einfach umzeichnen und ergänzen. In diesem Prozess soll die Interaction Map immer zum Verändern, Durchstreichen und Ergänzen einladen. Es macht aus diesem Grunde Sinn, die Interaction Map, wie beim Paper-Prototyping auch, skizzenhaft aussehen zu lassen. 5. Wie geht’s weiter Mit der Visual Feedback Consolidation wurde das im Unternehmen bekannte Wissen über die Benutzer und die Benutzung des Produktes zusammengetragen, konsolidiert und mit der Interaction Map visualisiert. Neben dem Recycling des vorhandenen User Experience Wissen wurden mit dem Prozess auch die relevanten Stakeholder abgeholt und in den Benutzerzentrierten Prozess eingebunden. Die Stakeholder erhielten so einen Blick auf die Gesamtsituation und die vordringlichsten Punkte.

Abb. 4. Nach dem ersten Interview

Der Fokus für die kommenden Usability Maßnahmen ist sichtbar und die Akzeptanz für deren Erkenntnisse gestärkt. Die Interaction Map enthält Inhalte aus verschiedensten Quellen, und die Informationen sind nicht notwendigerweise durch User Research oder andere UX Methoden belegt. Für die Erstellung der Interaction Map ist die Validität der Daten nicht entscheidend. Umso wichtiger ist es dann, in nachfolgenden Schritten die identifizierten Handlungsfelder genau zu untersuchen, um die User Experience des Produkts im Fokus zu optimieren. Unternehmen können die Interaction Map als Startpunkt nutzen, um die User Experience über einen längeren Zeitraum strategisch zu verbessern. Die Interaction Map zeigt den Handlungsbedarf für Usability Maßnahmen auf. Daraus kann eine Roadmap abgeleitet werden, die aufzeigt in welcher Reihenfolge die identifizierten Handlungsfelder genauer untersucht werden. Bei der Erstellung der Roadmap lassen sich neben der Schwere der Probleme auch andere Aspekte wie z. B. strategische Überlegungen oder Releasezyklen berücksichtigen. Ein Usability Professional kann abhängig von der Problemstellung des Handlungsfeldes Usability Maßnahmen definieren und gemäß der Roadmap aufsetzen. Der Usability Professional kann sich hierbei aus seinem Methoden- und Erfahrungsschatz bedienen. Methoden

aus dem User Research empfehlen sich z. B., um das Wissen über die Benutzer und die bestehenden Probleme detaillierter zu untersuchen. Lo Fi Prototyping hilft bei der Entwicklung und dem Evaluieren von neuen Produkteigenschaften. Jedes Handlungsfeld resultiert somit in einem oder mehreren Usability Projekten, wobei jedes einzelne im Gesamtkontext eingeordnet ist (sowohl inhaltlich als auch zeitlich) und auf vorhandenes Wissen aufsetzt. 6. Tipps und Tricks bei der Anwendung –– Den Beteiligten den Zweck der Visualisierung erklären: Ziel ist es, einen Überblick zu schaffen, um die Orte mit dem größten Handlungsbedarf zu identifizieren. Anschliessend werden die identifizierten Handlungsfelder genauer untersucht. Somit müssen nur die relevanten Details aufgenommen werden und die Interaction Map bleibt übersichtlich. –– Alle Punkte eines Stakeholder abbilden: Damit ist die Grundlage geschaffen, dass alle dem Stakeholder wichtigen Aspekte erfasst werden und sich jeder Stakeholder abgeholt fühlt. Es können bewusst Punkte aufgenommen werden, die dem UX Experten unproblematisch erscheinen. Über die Bedeutung eines berichteten Problems entscheidet die anschliessende Bewertung.

105


Abb. 5. nach weiteren Interviews.

–– Bei der Bewertung der Probleme die ungünstigste Ausgangslage annehmen: Ist z. B. ein Problem direkt davon abhängig, ob der Benutzer über bestimmtes Wissen verfügt oder nicht, sollte bei der Bewertung davon ausgegangen werden, dass dieses Wissen nicht vorhanden ist. Den Stakeholder kann es schwerfallen, eine objektive Bewertung abzugeben. Die Schwere hängt vom Benutzer und Kontext ab. Je nach Wahrnehmung wird das eine Problem verharmlost und das andere übertrieben. Die Bewertung von der ungünstigen Ausgangslage gibt einen gemeinsamen Rahmen für die Bewertung vor und verhindert eine Schönwetterbewertung. –– Bewertungen visuell codieren: Um besonders schwerwiegende Probleme hervorzuheben, können diese z. B. farblich hervorgehoben werden. Eine andere Möglichkeit ist die Anordnung der Probleme in einem zwei-dimensionalen Koordinatensystem. Auf einer Achse sind die Touchpoints als Bereiche abgetragen, die zweite Achse entspricht dem Schweregrad. So kann die Aufmerksamkeit der Stakeholder

106

bewusst auf einen Teilbereich oder die Verteilung der Probleme gelenkt werden. –– Lösungsideen für gewisse Diskussionen weglassen: Dies ist z. B. hilfreich, wenn Designer völlig neue Konzepte basierend auf den bestehenden Schwachstellen entwickeln sollen. Sind die Lösungsideen bereits visualisiert, wird der Blick auf völlig Neues getrübt. 7. Reflexion Das Vorgehen mit der Visual Feedback Consolidation und der Interaction Map erzielt folgende Wirkung: –– Der Prozess kann durch eine Person getrieben werden, welche die Informationen zusammenträgt und konsolidiert. Stakeholder können schon mit ein bis zwei Stunden Aufwand einbezogen werden. Der Bedarf nach mehrstündigen Workshops wird umgangen, was sehr gut in eine typische Organisation passt. –– Alle Quellen können verarbeitet werden: sowohl internes Wissen wie auch Beobachtungen aus Benutzerforschung.

–– Das Sammeln und Konsolidieren von Informationen ist getrennt von der Diskussion über den Wert und die Richtigkeit der Informationen. Dieses aus dem Konfliktmanagement entnommene Prinzip bringt die Fakten neutral auf den Tisch. Erst anschliessend bewerten Stakeholder die Information; nun in Relation zu der konsolidierten Sicht und nicht mehr zur individuellen Sicht. –– Ausgewiesenes Ziel ist es, vorhandenes Wissen zu verwenden. Die Aussage „das ist nicht repräsentativ“ kann, wenn sie denn überhaupt geäußert wird, nun konstruktiv angegangen werden. Ja, die Probleme sind nicht repräsentativ, die Darstellung zeigt aber Handlungsfelder auf die nachfolgend genau untersucht werden können. Diese Untersuchungen können dann diesem Anspruch gerecht werden. –– Mit der Interaction Map wird ein Mediationsmittel geschaffen, indem jeder Stakeholder abgeholt wird und die Konfliktparteien für den Grossteil des Prozesses durch die Einzelinterviews voneinander getrennt sind.


Usability Professionals 2012 Nutzerwissen wissen und nutzen

–– Die Interaction Map spricht eine sehr informelle Sprache und ist deshalb leicht verständlich. –– Die Interaction Map erzeugt eine Ordnung der Probleme und Lösungen entlang der Benutzung und zeigt so die Situation die sich für den Benutzer ergibt. Insbesondere für Personen die stark segmentiert arbeiten und nur einen Teil der Probleme sehen erlaubt dies den Blick auf die Gesamtsituation. –– Die Darstellung als Poster bewirkt, dass die Beteiligten sowohl die wesentlichen Details als auch das Gesamtbild immer vor Augen haben. –– Das Poster als Papier schafft ein gemeinsames Arbeitsmittel, dass von jedem Beteiligten direkt verwendet werden kann. Kommentare und Erweiterungen können direkt auf das Poster skizziert und festgehalten werden. Missverständnisse sind so weniger häufig. –– Bilder und Ansichtsexemplare erlauben Diskussionen über greifbares. Sachverhalte können demonstriert, ausprobiert und direkt am Produkt diskutiert werden. –– Der Usability Professional vernetzt sich mit den relevanten Stakeholdern. –– Es wird ein Bewusstsein für Usability im Unternehmen geschaffen. –– Die Interaction Map zeigt den längerfristigen Bedarf an Usability Engineering Aktivitäten auf.

Literatur 1. Adlin, T.; Jamesen, H., Krebs, T (2001). Fake People and Sticky Notes: Fostering Communication for Human-Centered Software Design. Whitepaper, published under http://www.jamesen.com/publications/ FakePeople-G.pdf 2. Beyer, H. & Holtzblatt, K. (1998). Contextual Design: Defining Customer-Centered Systems. San Francisco: Morgan Kaufmann. 3. Löwgren, J. (2005). Inspirational patterns for embodied interaction. Proceedings of the Nordic Design Research Conference (Nordes), Copenhagen. 4. Pohl, K.(2008): Requirements Engineering – Grundlagen, Prinzipien, Techniken. Dpunkt-Verlag. 5. Richter, M & Flückiger, M. (2010). Usability Engineering Kompakt: benutzbare Software gezielt entwickeln. Heidelberg: Spektrum Akademischer Verlag. 6. Torio, J. (2011). Experience Maps Identify Inefficiencies and Opportunities. UX Mag, http://uxmag.com/, Article 738, October 4, 2011. 7. Vigenschow, U. Schneider B. & Meyrose Ines (2011). Soft Skills für Softwareentwickler. Fragetechniken, Konfliktmanagement, Kommunikationstypen & Modelle. Dpunkt-Verlag.

8. Schlussfolgerung Für den Usability Professional ist Visual Feedback Consolidation und die Interaction Map eine Ergänzung zu dem bestehenden Methodenset, das neben den beschriebenen Wirkungen in einem konkreten Entwicklungsprojekt ebenso für die langfristige strategische Planung von Usability Aktivitäten geeignet ist. Im strategischen Kontext eingesetzt ermöglicht das vorgestellte Vorgehen, Feedback von Benutzern zu konsolidieren und so gezielt zu handeln. Das Vorgehen schliesst damit eine wichtige Lücke zum Usability Roadmapping und ist ein Baustein, um User Experience in einer Organisation zu verankern.

107


Wissensmanagement für Usability Herausforderungen und Perspektiven

Ben Heuwing Universität Hildesheim, Institut für Informationswissenschaft und Sprachtechnologie Marienburger Platz 22, 31141 Hildesheim heuwing@uni-hildesheim.de

Thomas Mandl Universität Hildesheim, Institut für Informationswissenschaft und Sprachtechnologie Marienburger Platz 22, 31141 Hildesheim mandl@uni-hildesheim.de

Abstract Wie können Ergebnisse aus dem nutzerzentrierten Entwicklungsprozess systematisch und produktiv wiederverwendet werden? Wie können Usability Reports so gestaltet werden, dass eine erneute und übergreifende Auswertung der Ergebnisse nach dem Ablauf eines Projektes ermöglicht wird? Inwiefern stehen diese Ergebnisse bereits zur Verfügung, und wie viel Aufwand ist für eine optimierte Dokumentation angemessen? Das Informationsund Wissensmanagement im Bereich Usability und User Experience wird zwar in vielen Unternehmen thematisiert, es existieren aber noch keine umfassenden Lösungsansätze. Trotzdem greifen Usability-Experten in ihrer Arbeitspraxis bereits regelmäßig auf die Ergebnisse aus bereits durchgeführten Projekten zurück. In diesem Beitrag werden existierende Ansätze für die Verwaltung und Verwendung von Usability-Ergebnissen aus Praxis und Forschung diskutiert und erste Ergebnisse zu einer Systematik von Anwendungsfällen vorgestellt. Dabei liegt ein Schwerpunkt auf den Ergebnissen von Evaluierungen, da diese wichtige Design-Entscheidungen nachvollziehbar machen können. Darauf aufbauend soll kurz auf ein aktuelles, relevantes Forschungsvorhaben der Verfasser eingegangen und eine Agenda für weitere Entwicklungen in diesem Bereich vorgeschlagen werden.

1. Formen der Wiederverwendung von Usability-Informationen Usability Professionals erarbeiten im Rahmen ihrer Arbeit wichtige Erkenntnisse und dokumentieren diese für das jeweils aktuelle Projekt. Das Endergebnis der Entwicklung, also das interaktive Produkt, erlaubt jedoch keine Rückschlüsse auf die Abwägungen während der Entwicklung und die Gründe für getroffene Design-Entscheidungen (Haynes u. a. 2005). Die Ergebnisse geraten so leicht in Vergessenheit, obwohl sie meist mit großem Aufwand und oft auf empirischer Grundlage mit Nutzerstudien erarbeitetet worden sind. Diese Ergebnisse werden in der Praxis bereits häufig, jedoch meist noch unsystematisch, in unterschiedlichen Anwendungsfällen eingesetzt (siehe Abschnitt 4). Nur wenige der dabei entstandenen Erkenntnisse werden beispielsweise als Richtlinien, PatternSammlungen oder Styleguides für die weitere Verwendung aufbereitet. Daraus leitet sich ein hoher Bedarf an Vorgehensweisen

108

und Werkzeugen für das Informationsund Wissensmanagement in Bezug auf neu erarbeitete Ergebnisse ab. Die im Folgenden beschriebenen Formen für die Aufbereitung von Forschungsergebnissen und Erkenntnissen aus der Praxis unterscheiden sich hinsichtlich des Aufwandes, der für die Erarbeitung notwendig ist, und der Breite des Bereiches, für den sie anwendbar sind. 1.1. Heuristiken, Standards und Richtlinien Richtlinien beschreiben Details der Umsetzung von Nutzeroberflächen, die bei einer korrekten Umsetzung zu einem gut benutzbaren Produkt führen sollen und auf verschiedene Typen interaktiver Software anwendbar sind. Heuristiken und Standards sind allgemeinere Hinweise, die teilweise auf der Zusammenfassung verschiedener Richtlinien beruhen (Cockton 2012). Richtlinien und Heuristiken können auch für die Evaluierung von Interfaces herangezogen werden.

Steffen Weichert usability.de Plaza de Rosalia 4 30449 Hannover steffen.weichert@usability.de

Keywords: /// Nutzerzentrierte Entwicklung /// Usability-Evaluation /// Wissensmanagement /// Wiederverwendung

1.2. Interaktionspattern User Interface Pattern (UI-Pattern) oder Interaktionspattern beschreiben immer wieder in ähnlicher Form auftretende Probleme und ihre Lösung. Neue Pattern entstehen dabei meist aus der Praxis, sind für einen bestimmten Nutzungskontext definiert und werden mit Beispielen aus der Nutzung belegt (Cooper et al. 2010:167). Die Anwendung von Pattern kann erleichtert werden, indem sie zu Pattern-Katalogen oder einer Pattern-Sprache zusammengefasst werden (Dearden & Finlay 2006:70). Weitergehende Systematisierungen verwenden z. B. semantische Verknüpfungen, um die Anwendung zu erleichtern (Janeiro u. a. 2010). 1.3. Styleguides Ein Styleguide dokumentiert und begründet die wichtigsten für den Entwurf eines Systems getroffenen Design-Entscheidungen


Usability Professionals 2012 Nutzerwissen wissen und nutzen

(Mayhew 1999:313). Dies soll ein möglichst konsistentes Aussehen und Interaktionsverhalten von Interface-Elementen eines Produktes oder einer Produktfamilie sicherstellen (z. B. Standardterminologie, Verwendung von Farben, Position von Interface-Elementen auf dem Bildschirm). Nutzern wird so die Bedienung erleichtert, gleichzeitig werden Zeit und Aufwand für die Entwicklung und den Support eines Produktes reduziert (Cooper u. a. 2010:299). 1.4. Ergebnisse aus dem Entwicklungsprozess Die direkten, nicht aufbereiteten ErgebnisArtefakte (Deliverables) aus verschiedenen Maßnahmen eines nutzerzentrierten Entwicklungsprozesses liegen in unterschiedlichen Formen vor (etwa Personas, Use Cases, Usability-Probleme, Empfehlungen und Prototypen). Die ISO-Norm 25060 systematisiert die verschiedenen Ergebnisartefakte der nutzerzentrierten Entwicklung (ISO 2010). Derartige Ergebnisse liegen meist in unstrukturierter Form vor, beispielsweise als einzelne Dokumente (z. B. Berichte zu Nutzungsstudien oder Evaluierungsmaßnahmen), in Aktenordnern oder Netzwerklaufwerken. [Abb. 1] Teilweise existieren auch speziell dafür angepasste Informationssysteme (etwa Wikis für die Verwaltung von Nutzungsanforderungen, Issue Tracking Tools). Auf die vorhandenen Informationen wird in der Praxis häufig und in neuen Kontexten zugegriffen, jedoch existiert dafür kein systematisches Vorgehen und nur wenig Unterstützung durch entsprechende Werkzeuge. 1.5. Vergleich der Ansätze Die vorgestellten und weit verbreiteten Ansätze zur Formalisierung (Heuristiken, Richtlinien, Pattern, Styleguides) haben einen großen Nutzen für die Verbreitung und Nutzung von etabliertem UsabilityWissen. Heuristiken und Standards sind sehr allgemein formuliert und damit vielfältig anwendbar, bleiben jedoch häufig unspezifisch. Pattern sind konkreter, haben jedoch einen kleineren Anwendungskontext. Styleguides wiederum sind nur für

einzelne Produkte ausgelegt und fördern eher die einheitliche Gestaltung eines Produkts als die Vermeidung von über Aspekte der Konsistenz hinausgehenden Usability-Problemen. Ergebnisse aus dem Entwicklungsprozess sind ohne weiteres nicht direkt auf andere Kontexte übertragbar. Zudem bedeutet die Erarbeitung und Formalisierung einen hohen intellektuellen und zeitlichen Aufwand, der nicht ohne weiteres kontinuierlich innerhalb einer Organisation geleistet werden kann. Weiterhin ist das Vorgehen für die Erarbeitung nicht immer eindeutig. In Bezug auf die vorhandenen Informationen bestehen Schwierigkeiten beim Zugriff. Die meisten Organisationen profitieren daher nicht so sehr von den selbst erarbeiteten, Usability-bezogenen Erkenntnissen, wie es eigentlich möglich wäre.

Abb. 1. Schematische Darstellung der projektübergreifenden Verwendung von Usabilitybezogenen Informationen (eigene Darstellung)

2. Verwendung von UsabilityErgebnissen in der Praxis Im Folgenden werden einige Beispiele für den pragmatischen Einsatz von Werkzeugen für das Wissensmanagement von UsabilityErgebnissen in der Praxis vorgestellt. Dabei werden jeweils spezifische Ziele verfolgt. 2.1. Verwaltung von Testvideos mit UseTube bei Google UseTube ist ein System, welches bei der Firma Google Inc. intern verwendet wird. Es ermöglicht, Videoaufnahmen von Nutzertests allen Interessierten sowohl als Livestream als auch archiviert im Intranet zugänglich zu machen: „[…] a complete and easily accessible archive of all study videos ever recorded at Google“ (LaRosa u. a. 2009:2971). Der Fokus liegt somit auf einer größtmöglichen Verbreitung in der Organisation. Die Aufzeichnungen können online annotiert werden, um die Analyse zu vereinfachen. Einfache Links ermöglichen das Weitergeben von Videos und Video-Ausschnitten. Jede Nutzung der Aufzeichnungen wird aufgezeichnet und auch für die Berechnung des Return on Investments (ROI) für Usability-Maßnahmen herangezogen. [Abb. 2]

Abb. 2. UseTube – Übersicht über vorhandene Testvideos (LaRosa u. a. 2009)

2.2. Dokumentation für medizinische Produkte Im Bereich der medizinischen Produkte ist die Notwendigkeit entstanden, die nutzerzentrierte Entwicklung und Evaluierung dokumentieren und nachweisen zu müssen. Ein Lösungsansatz ist das Usability Engineering File (Walke & Brau 2011). Im Vordergrund steht eine enge Verknüpfung des Usability Engineering mit dem in der Branche wichtigen Risikomanagement. So muss der gesamte nutzerzentrierte Entwicklungsprozess dokumentiert werden, um

109


eine Zulassung für das Produkt zu erreichen. Gleichzeitig ergibt sich aus dieser allgemeinen Verpflichtung die Chance, die Produkte für ihre direkten Nutzer zu verbessern sowie die Sicherheit der Patienten zu erhöhen. 2.3. Pattern-Library für Ergebnisse aus Nutzertests Um die Ergebnisse aus Nutzertests für die Organisation nutzbar zu machen, wurde in der Entwicklungsfirma checkfree.com ein einfaches Wissensmanagementsystem eingesetzt (Hughes 2006). Die Ergebnisse sind dabei jeweils in der Form eines Patterns zusammengefasst, mit Problemstellung, Lösung, unterstützenden Informationen und Verweisen. [Tab. 1] Die Organisation der Ergebnisse orientiert sich am Nutzungskontext: Jedes Finding wird einem produktspezifischen Use Case (z. B. Rechnung bezahlen, [s. Abb. 3]) zugewiesen. Das ermöglicht zu Beginn einer Entwicklungsphase die vertikale Recherche zu einem Anwendungsfall für ein bestimmtes Produkt. Dabei können auch Anforderungen aus Vorversionen ausgewertet werden, für die noch keine Lösungen hinterlegt sind. Gleichzeitig wird jedes Finding auch einem verallgemeinerten, generischen Unterziel zugeordnet (z. B. Datum eingeben). Dies ermöglicht gezielte Anfragen zu Details der Umsetzung bei anderen Produkten, wenn im Laufe der Entwicklung spezifische Gestaltungsfragen aufkommen.

Users wanted to…

Schedule a single bill payment.

User Action

Typed in an invalid date (too early).

System Action

Returned an error message.

Data

ABC Bank Reprot: September 2004

Solution

Automatically populate date field with earliest available pay date when user types in the amount field.

Comment

Many users pay at earliest available date – making earliest pay date a good default.

110

2.4. Aufbau einer Datenbasis für vergleichende Nutzertests Für eine vergleichende Evaluierung der Beschaffung von Musik und Medien auf verschiedenen mobilen Endgeräten wurde in der Agentur usable Products Company eine umfangreiche Datenbasis aufgebaut (Weiss & Whitby 2008). Dafür wurden neben qualitativen Findings auch verschiedene quantitative Kennzahlen erfasst (taskbezogen wie Dauer und Erfolg, testbezogen wie subjektive Wahrnehmung). Die Ergebnisse wurden mittels der Single Usability Metric (Sauro & Kindlund 2005) zu einem Wert zusammengefasst. Grundlage der Auswertung waren verschiedene Nutzungsszenarien (Download von Musik, Download von Videos), die aus einzelnen, Szenario-übergreifend vergleichbaren Schritten zusammengesetzt waren (z. B. Liste mit verfügbaren Medien aufrufen, weitere Medien herunterladen, Mediumabspielen). So konnten Möglichkeiten vor allem für quantitative Vergleiche realisiert werden. 2.5. Automatisierte Sammlung standardisierter UX-Kennzahlen Die Sammlung und die Auswertung von aggregierten quantitativen Ergebnissen werden in einem „User Experience Monitoring“-Tool der Firma m-Pathy ermöglicht (Hartmann 2011).

Tab. 1. Beispiel für ein Usability Finding als Pattern (Hughes 2006)

Die erhobenen Kennzahlen basieren auf der automatischen Auswertung von Onsite-Befragungen und Nutzungsaktivitäten. Einbezogen werden nur eindeutig definierte und automatisch erfassbare Prozessabläufe wie Check-Out oder Registrierung. Die Funktionen dieses Werkzeuges eignen sich primär für die Analyse aktueller Ergebnisse, etwa durch eine Dashboard-Ansicht und Benachrichtigungsfunktionen. Durch die standardisierte Erhebung können auf dieser Datenbasis prinzipiell aber auch längerfristige Entwicklungen ausgewertet und Vergleiche durchgeführt werden. 2.6. Zusammenfassung: Vorgehen in der Praxis Die dargestellten Beispiele unterscheiden sich stark hinsichtlich ihrer Ziele und Herangehensweisen. Zum Teil stehen quantitative, zum Teil auch qualitative Ergebnisse im Vordergrund. Die Zielgruppen für die Informationen sind ebenfalls unterschiedlich, von einer möglichst großen Verbreitung bei UseTube hin zu der sehr spezifischen, externen Zielgruppe des Usability Engineering File. Für die Analyse-Funktionen des User Experience Monitoring Tools sind verschiedene Zielgruppen denkbar, neben UsabilityExperten etwa Produktmanager oder Designer. Hinsichtlich der Systematisierung der Ergebnisse ist in diesen Beispielen eine Orientierung an Use Cases und Tasks aus Nutzersicht vorherrschend.

Abb. 3. Suche nach Findings über Ziele und Unterziele (Hughes 2006)


Usability Professionals 2012 Nutzerwissen wissen und nutzen

3. Forschungsprojekte Im Bereich der Forschung zur MenschMaschine-Interaktion gibt es weitere Vorschläge für den Umgang mit den unterschiedlichen Ergebnissen aus nutzerzentrierten Entwicklungsprozessen. Für die Verwaltung von Ergebnissen aus User Research-Aktivitäten gibt es bisher nur wenige Ansätze, etwa Vorschläge für die elektronische Verwaltung von Affinity Diagramming mit Nutzern als Mittel der Anforderungserhebung (Curtis u. a. 1999). Theorien zur Verwaltung von Anforderungen aus Nutzersicht existieren im Bereich der Domain Theory (Sutcliffe 2002) und des Scenario Based Design (Haynes u. a. 2005). Für die spätere Nutzung von DesignKonzepten und -Entscheidungen liegen eine Reihe von Vorschlägen vor. Stark formalisierte Ansätze aus dem Bereich des Design Rationale (Moran & Carroll 1996; Regli u. a. 2000) leiden aufgrund des damit verbundenen Aufwands unter mangelnder Akzeptanz (Sutcliffe 2003:258). Ein vergleichsweise einfaches, jedoch intuitiv einleuchtendes Beispiel ist d.tour, eine Design-Galerie für Website-Designs, welche mittels einer Volltext-Suche durchsucht und durch Verweise auf ähnliche Entwürfe erkundet werden kann (Ritchie u. a. 2011). Im Folgenden werden einige Projekte im Bereich der Forschung zur MenschMaschine-Interaktion vorgestellt, die sich speziell mit der Verwaltung und Nachnutzung von Evaluierungsergebnissen beschäftigen. 3.1. Modellierung von qualitativen Evaluierungsergebnissen Das User Action Framework (UAF) (Andre u. a. 2001) ist eine Klassifikation zur Beschreibung von Usability-Problemen. Dabei werden die Probleme entsprechend der Phase einer Nutzeraktion eingeteilt, in der sie aufgetreten sind: –– Planung –– Ausführung –– Bewertung

Abb. 4. Screenshot von Vizability (Pyla et al. 2006)

Das UAF umfasst dabei noch vier weitere Unterebenen. Eine mögliche Klassifikation für die Abwesenheit eines eindeutigen „Call to Action“ auf einer Homepage wäre z. B.: Planning > Translation > Existence > Existence of Cognitive Affordance > A clear “Do It Now“ mechanism Ziele der Entwicklung des UAF sind eine erhöhte Reliabilität der Ergebnisse, eine Verbesserung der ReportingQualität und eine übergreifende ToolUnterstützung. Das Tool Vizability (Pyla u. a. 2006) macht die auf Basis des UAF klassifizierten Ergebnisse für eine explorative Suche zugänglich und stellt sie in einem hierarchischen Baum dar. Zusätzlich können die Ergebnisse nach verschiedenen Kriterien gefiltert werden (Cost, Importance, Keywords, Evaluators, [s. Abb. 4]). Weiterhin wurde auch für die Unterstützung der Problemdiagnose und der Erfassung ein Tool entwickelt, welches auf einem Ticketing-System basiert (Wittenberg 2008). UsabML ist ein Ansatz, Usability Findings aus einem Nutzertest in einem XMLFormat (Feiner u. a. 2010) abzulegen.

Dies soll die Integration in Issue TrackingSysteme, die direkte Verknüpfung mit dem Source-Code der Implementierung und die Auswertung von Statistiken zur Umsetzung der Ergebnisse ermöglichen. Ein weiterer Vorschlag, Testing Object Management, ist darauf ausgelegt, eine internationale Sammlung von Testergebnissen aufzubauen, um die studienübergreifende Auswertung unter besonderer Berücksichtigung kultureller Unterschiede zu ermöglichen (Douglas 2007). Eine Systematisierung soll anhand von Nutzerprofilen, Use Cases und Software-Typen erfolgen. In einem weiteren Schritt könnten Richtlinien abgeleitet und mit den Ergebnissen verknüpft werden. 3.2. Auswertung von quantitativen Ergebnissen Zusätzlich zu den qualitativen Ergebnissen der intellektuellen Analyse und Auswertung gibt es quantitative Kennzahlen. Quantitative Evaluationsmaße können auf verschiedenen Evaluationsmethoden basieren: Auf strukturierten Befragungsmethoden, auf der Erfassung von Nutzungsaktivitäten, z. B. von Durchführungszeiten und

111


Produktbezogen

Projektbeginn

Während und am Ende der Entwicklung

In neuen Bereich einarbeiten

Ergebnisse direkt einsetzen

Produktübergreifend

Umsetzung verfolgen

Ergebnisse direkt einsetzen Produkte vergleichen Richtlinien ableiten Andere Informieren

Tab. 1. Anwendungsfälle im Produkt und Projektbezug

Erfolgsmaßen in einem Nutzertest, oder auf der Erfassung der Anzahl gefundener Probleme (eine Übersicht gibt Tullis & Albert 2008). Beim Umgang mit quantitativen Ergebnissen sind vor allem Möglichkeiten zum Zusammenfassen von Maßen zu (etwa Effektivität, Effizienz, Zufriedenheit) oder aus verschiedenen Erhebungsmethoden interessant. Die Single Usability Metric kombiniert beispielsweise mehrere Maße wie Taskerfolg, Fehlerzahlen und Nutzerzufriedenheit zu einer aggregierten Kennzahl (Sauro & Kindlund 2005). 3.3. Gegenüberstellung der Ansätze aus Forschung und Praxis Die Klassifikation von erhobenen UsabilityProblemen mit dem User Action Framework und andere Vorschläge führen interessante Ansätze speziell für den Umgang mit Evaluierungsergebnissen ein und sind theoretisch fundiert. Die Vorschläge sind jedoch wenig nutzungsorientiert gestaltet. In Bezug auf die Systematisierungskriterien unterscheiden sie sich von den vorgestellten Beispielen aus der Praxis: Während hier zumeist der Nutzungskontext für die Systematisierung herangezogen wird (besonders durch die Systematisierung von Tasks) werden im Rahmen der Forschung die Ergebnisse in einem zusätzlichen Schritt in Hinblick auf inhärenten Merkmale klassifiziert. Das Kontext-bezogene Vorgehen verursacht wahrscheinlich einen geringeren Aufwand bei der Erfassung. Ob eine der beiden Herangehensweisen oder eine Mischung aus beiden vorteilhafter für die

112

spätere Anwendung ist, muss dabei jedoch zunächst offen bleiben. Um Erfassung und Zugriff zu optimieren, ist jedoch eine Annäherung aus der Sicht der späteren Nutzer dringend notwendig. 4. Projekt: Informationssystem für Usability-Informationen Der Anwendungskontext für die gesammelten Informationen wird in den vorgestellten Forschungsansätzen häufig noch nicht ausreichend berücksichtigt. Im Folgenden werden die Ziele des Dissertationsprojektes eines der Autoren vorgestellt. Der zugrunde liegende Ansatz ist die Gestaltung eines Informationssystems für Usability-Informationen aus der Sicht der späteren Nutzer, der Usability Experten. Zentrale Bestandteile sind eine effiziente und prozessbezogene Informationsmodellierung und der Entwurf eines Moduls für die Informationssuche. Dabei ist es elementar, den Mehraufwand für die Erschließung der Informationen möglichst gering zu halten. 4.1. Anwendungsfälle für Usability-Informationen Als erste Maßnahme wurden auf der Basis von Interviews Anwendungsfälle erarbeitet. Die Perspektive dieser Anwendungsfälle ergibt sich aus der gewählten Gruppe an Teilnehmern. Diese wurden in Unternehmen rekrutiert, in denen interaktive Produkte entwickelt werden und die

Usability- und User Experience-bezogene Aufgaben innehaben (Inhouse Usability Professionals, n=8). Dabei wurde davon ausgegangen, dass die Wiederverwendung von Arbeitsergebnissen in diesem Kontext häufig vorkommt, da sich die entwickelten Anwendungen und ihre Nutzungskontexte stärker gleichen als dies etwa bei externen Dienstleistern der Fall ist. In den Interviews wurde jeweils erfragt, in welchem Kontext und für welche Aufgaben die in der Organisation vorhandenen Usability-bezogenen Informationen bereits verwendet werden. Dabei konnten die folgenden Anwendungsfälle für die Anwendung von Informationen identifiziert werden: Ergebnisse direkt anwenden: Wenn Ergebnisse aus Studien als anwendbar für einen neuen Projektkontext beurteilt werden, können sie als Vorlage dienen oder direkt angewendet werden. Richtlinien ableiten: Ergebnisse fließen in Usability Guidelines, Design-Styleguides oder Evaluierungs-Richtlinien ein (siehe Abschnitt 1). Durch das Ableiten aus verschiedenen Materialien und Studien können diese Richtlinien nachvollziehbar gemacht und ihre Validität erhöht werden. Produkte vergleichen: Im Rahmen der Usability-Optimierung kann es hilfreich sein, Produkte auf der Basis von qualitativen Ergebnissen und Kennzahlen miteinander und mit Benchmarks von ähnlichen Systemen zu vergleichen. Umsetzung verfolgen: Die Umsetzung von Anforderungen aus Nutzersicht wird über mehrere Produktversionen hinweg verfolgt. Zusätzliche Erkenntnisse widerlegen oder unterstützen mit der Zeit die Notwendigkeit der Umsetzung. Andere informieren: Ergebnisse aus durchgeführten Projekten werden zur Verfügung gestellt, um anderen die Einarbeitung zu ermöglichen, den Einfluss auf die Produktgestaltung zu erhöhen und die eigene Leistung sichtbar zu machen.


Usability Professionals 2012 Nutzerwissen wissen und nutzen

In neuen Bereich einarbeiten: Verschiedene Ergebnisse, aber auch externe Quellen werden konsultiert, um sich möglichst umfassend auf ein neues Projekt vorzubereiten.

Die hier vorgestellten Anwendungsfälle wurden in den Interviews mit absteigender Häufigkeit genannt. Die Systematik der Anwendungsfälle orientiert sich an der jeweiligen Motivation für den Zugriff auf die Informationen. Die Anwendungsfälle lassen sich in auch den von Hughes (2006) vorgeschlagenen Dimensionen „Anwendung im Projekt“ und „Produktbezug“ zuordnen. [Tab. 2] 4.2. Ausblick Anhand der vorgestellten Anwendungsfälle wird ein Informationsmodell erarbeitet, dass einen einfachen und zielgenauen Zugriff auf die Informationen ermöglicht und gleichzeitig den Aufwand für die Erschließung (Verschlagwortung, Social Tagging, Klassifikation) möglichst gering hält. Auch automatische Erschließungsmethoden und Techniken der Informationsextraktion sind denkbar, um den Aufwand zu reduzieren. Aufbauend auf den hier vorgestellten Anwendungsfällen werden mit der Hilfe von Fokusgruppen relevante Informationsobjekte erhoben. Daraus werden Anforderungen an ein integriertes UsabilityInformationssystem abgeleitet. Auf dieser Grundlage wird dann ein konzeptueller Prototyp erarbeitet und mit der Hilfe von Usability Experten aus ihrer Sicht als spätere Nutzer des Systems bewertet. 5. Herausforderungen in der Praxis Auf der Grundlage der vorgestellten Projekte und der ermittelten Anwendungsfälle lassen sich Herausforderungen in der Praxis ableiten und weitere Perspektiven für die Entwicklung in diesem Bereich skizzieren.

5.1. Unternehmensinterne Usability-Experten Wie bereits erläutert bestehen innerhalb von Unternehmen aufgrund des meist homogenen und relativ stabilen Produktportfolios große Potentiale für das Management von Usability-Informationen. Die Herausforderungen liegen dabei in der Integration mit existierenden Informationssystemen und der gemeinsamen Auswertung mit anderen im Unternehmen vorliegenden Informationen. Informationsintegration auf Systemebene: Zunächst müssen die Ergebnisse verschiedener Tools und unterschiedliche Dateiformate auf Systemebene zusammengeführt werden, um die Entstehung von Insellösungen zu vermeiden. Beispielsweise können Schnittstellen zu existierenden Werkzeugen für die Erfassung von Usability-Daten geschaffen werden, z. B. Tools für die Testaufzeichnung, für Online-Befragungen und für Experten-Reviews. Integration mit existierenden Wissensmanagement-Prozessen und -Werkzeugen: Nicht nur in großen Unternehmen existieren bereits Prozesse und Werkzeuge für das Wissensmanagement. Diese angemessen zu nutzen beinhaltet das Potential, die Einführung von Usability-bezogenem Wissensmanagement deutlich zu erleichtern. Weiterhin können vorhandene Informationen aus anderen Bereichen, beispielsweise Kennzahlen zum Produkterfolg, in eine gemeinsame Auswertung mit einbezogen werden. Umgang mit externen Informationen: Führen externe Dienstleister Usability-bezogene Studien durch (s.u.) muss sichergestellt werden können, dass die Ergebnisse vergleichbar sind und im Unternehmen zur Verfügung gestellt werden.

5.2. Externer Usability-Dienstleister Für externe Usability-Dienstleister existiert aufgrund der Vielzahl verschiedener Projekte mit unterschiedlichen Schwerpunkten

großes Potential in einer Optimierung des Managements von Usability-Informationen. Wesentliche Herausforderungen liegen unter anderem in den folgenden Aspekten: Kurzzeitfokus bei Usability-Projekten: Insbesondere bei Evaluationsprojekten besteht das Ziel häufig darin, möglichst schnell verwertbare Ergebnisse zu bekommen. Ein durch den Usability-Dienstleister durchgeführter Usability-Test oder eine Expertenanalyse bedienen diesen Anspruch. Aufgrund des Kurzzeitfokus steht jedoch häufig die gute Aufbereitung für eine schnelle Umsetzung der Ergebnisse im Vordergrund. Vernachlässigt wird dabei hingegen die Frage nach einer späteren Wiederverwendbarkeit und der Wiederauffindbarkeit der Ergebnisse. Auch die Berücksichtigung von möglichst vergleichbaren Faktoren für den Fall, dass es zu Folgestudien kommt, findet noch nicht ausreichend statt. Von der Einführung von Usability-bezogenem Wissensmanagement könnte hier sowohl der UsabilityDienstleister als auch das beauftragende Unternehmen profitieren. Wechselnde Teamzusammensetzungen: Häufig bleibt es nicht bei einer einmaligen Zusammenarbeit zwischen Unternehmen und Usability-Dienstleister. Da zwischen zwei Projekten jedoch unter Umständen Monate oder Jahre liegen, kann sich sowohl auf Unternehmensseite als auch auf Seiten des Dienstleisters das Projektteam in der Zusammensetzung verändert haben. Damit neue Projektbeteiligte sich möglichst reibungslos in die Thematik, vergangene Usability-Studien und Ergebnisse einarbeiten können, bedarf es einer guten Unterstützung durch Usability-bezogenes Wissensmanagement, da nicht immer ein Ansprechpartner aus den vergangenen Projekten für Rückfragen zur Verfügung steht: „Wo finde ich den Ergebnisreport aus dem vergangen Jahr?“, „Warum wurde damals ein Szenario zum Thema x in den Testverlauf integriert?“, „Welche Maßnahmen fanden parallel zum UsabilityTest statt?“ sind beispielhafte Fragen, die unter Umständen nur mit Mühe oder nur begrenzt beantwortet werden können.

113


Doppelte und uneinheitliche Speicherung: Nach einer Zusammenarbeit zwischen Usability-Dienstleister und Unternehmen werden die Ergebnisse aus dem Projekt – z. B. ein Ergebnisreport zu einem UsabilityTest- in der Regel auf beiden Seiten in der jeweiligen Infrastruktur gespeichert und nach Projektende durch weitere Dateien ergänzt. So kann es sein, dass der Usability-Dienstleister im Nachgang noch Verknüpfungen zu relevanten Ergebnissen aus eigenen Studien oder anderen Projekten herstellt. Das Unternehmen auf der anderen Seite entwickelt das Produkt weiter, führt weitere Studien ohne den Dienstleister oder mit anderen Projektpartnern durch und legt auch diese Ergebnisse und Zwischenstände im Projektordner ab. Kommt es dann zu einer erneuten Zusammenarbeit zwischen Unternehmen und ursprünglichem Usability-Dienstleister, gilt es zunächst, den Wissensunterschied durch gegenseitiges Briefing und den Austausch neu entstandener Dokumente und Informationen auszugleichen. Auch hier besteht ein großes Optimierungspotential für ein gutes Management von Usability-Informationen.

Wie die Beispiele gezeigt haben, existieren verschiedene Herausforderungen und Potentiale sowohl aus unternehmensinterner Sicht, als auch auf Seiten externer Usability-Dienstleister. Sinnvollerweise könnte zukünftig sogar das Spektrum eines Dienstleisters über die reine Lieferung von Ergebnissen hinaus um die Beratungsleistung hinsichtlich der Speicherung und Wiederverwendung auf Kundenseite ergänzt werden. 6. Ausblick

übertragen. Eine weitere Vernetzung der Interessierten aus Forschung und Praxis wäre dringend notwendig, um das Thema des Wissensmanagements für Usability zu vertiefen und auszubauen.

114

in the Software Development Lifecycle. Dordrecht: Springer, 269–286 10. Hughes, M. (2006). A Pattern Language Approach to Usability Knowledge Management. In: Journal of Usability Studies

Literatur 1. Andre, T. S., Hartson, H. R., Belz, S.

Bd. 1, Nr. 2, 76–90 11. ISO (2010). Common Industry Format

M.&McCreary, F. A. (2001). The user action

(CIF) for usability – General framework for

framework: a reliable foundation for usability

usability-related information (ISO/IEC TR

engineering support tools. In: International

25060). ISO – International Organization for

Journal of Human Computer Studies Bd. 54, Nr. 1, 107–136

Standardization 12. Janeiro, J., Barbosa, S. D. J., Springer,

2. Cockton, G. (2012). Usability Evaluation.

T.&Schill, A. (2010). Semantically relating user

In: Soegaard, M.&Dam, R. F. (Hrsg.).

interface design patterns. In: Proceedings of

Encyclopedia of Human-Computer

the 1st International Workshop on Pattern-

Interaction. Aarhus, Denmark: The

Driven Engineering of Interactive Computing

Interaction-Design.org Foundation 3. Cooper, A., Reimann, R.&Cronin, D. (2010).

Systems – PEICS’10. Berlin, Germany, 40–43 13. LaRosa, M., Poole, D.&Schusteritsch, R.

About Face: Interface und Interaction

(2009). Designing and deploying usetube,

Design. mitp

google’s global user experience observation

4. Curtis, P., Heiserman, T., Jobusch, D.,

and recording system. In: Proceedings of

Notess, M.&Webb, J. (1999). Customer-

the 27th international conference extended

focused design data in a large, multi-site

abstracts on Human factors in computing

organization. In: Proceedings of the SIGCHI

systems. Boston, MA, USA: ACM, 2971–2986

conference on Human factors in computing

14. Mayhew, D. (1999). The Usability Engineering

systems: the CHI is the limit, CHI’99. New York, NY, USA: ACM, 608–615

Lifecycle: A Practitioner’s Handbook for User Interface Design. Morgan Kaufmann

5. Dearden, A. & Finlay, J. (2006). Pattern

15. Moran, T. P.&Carroll, J. M. (1996). Design

Languages in HCI: A critical review. In:

rationale: concepts, techniques and use.

Human-Computer Interaction Bd. 21, Nr. 1, 49–102 6. Douglas, I. (2007). Testing object

Mahwah, NJ: Lawrence Erlbaum Ass. 16. Pyla, P. S., Howarth, J. R., Catanzaro, C.&North, C. (2006). Vizability: a tool for

management (TOM): a prototype for

usability engineering process improvement

usability knowledge management in global

through the visualization of usability problem

software. In: Aykin, N. (Hrsg.). Usability and

data. In: Proceedings of the 44th annual ACM

Internationalization, Part I, HCII 2007, LNCS.

Southeast regional conference. Melbourne,

Bd. 4559. Heidelberg: Springer, 297–305 7. Feiner, J., Andrews, K.&Krajnc, E. (2010).

Florida: ACM, 620–625 17. Regli, W. C., Hu, X., Atwood, M.&Sun, W.

UsabML: formalising the exchange of

(2000). A survey of design rationale systems:

usability findings. In: Proceedings of the 2nd

Approaches, representation, capture and

ACM SIGCHI symposium on Engineering

retrieval. In: Engineering with computers

interactive computing systems, EICS’10. New York, NY, USA: ACM, 297–302. – ACM ID:

Die im vorhergehenden Abschnitt geschilderten Herausforderungen zeigen vielfältigen Forschungsbedarf für Vertreter verschiedener (Teil-)Disziplinen (MenschMaschine-Interaktion, Informationswissenschaft, CSCW, Software-Engineering, Forschungsdatenmanagement) auf. Weiterhin sind innovative Unternehmen gefragt, welche sich an der Entwicklung beteiligen und dieneuen Ansätze in die Praxis

Software Engineering – Integrating Usability

1822065 8. Hartmann, J. (2011). User Experience

Bd. 16, Nr. 3, 209–235 18. Ritchie, D., Kejriwal, A. A.&Klemmer, S. R. (2011). d.tour: style-based exploration of design example galleries. In: Proceedings

Monitoring: permanente Beobachtung

of the 24th annual ACM symposium on User

geschäftskritischer Online-Prozesse. In: Eibl,

interface software and technology, UIST’11.

M. (Hrsg.). überMEDIEN – ÜBERmorgen, Tagungsband, 361 9. Haynes, S. R., Carroll, J. M.&Rosson, M. B.

New York, NY, USA: ACM, 165–174 19. Sauro, J.&Kindlund, E. (2005). A method to standardize usability metrics into a single score.

(2005). Integrating User-Centered Design

In: Proceedings of the SIGCHI conference on

Knowledge with Scenarios. In: Gulliksen,

Human factors in computing systems. Portland,

J. &Seffah, A. (Hrsg.). Human-Centered

Oregon, USA: ACM, 401–409


Usability Professionals 2012 Nutzerwissen wissen und nutzen

20. Sutcliffe, A. (2002). Domain Theory: Patterns for Knowledge and Software Reuse. Hillsdale, NJ, USA: L. Erlbaum Associates Inc. 21. Sutcliffe, A. (2003). Symbiosis and synergy? Scenarios, task analysis and reuse of HCI knowledge. In: Interacting with Computers Bd. 15, Nr. 2, 245–263 22. Tullis, T.&Albert, B. (2008). Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics.Morgan Kaufmann 23. Walke, T.&Brau, H. (2011). Das Usability Engineering File in der Medizintechnik –Ein Stapel Papier als Business Case. In: Brau, H., Lehmann, A., Petrovic, K.&Schroeder, M. C. (Hrsg.). Stuttgart: German UPA e.V. 24. Weiss, S.&Whitby, C. (2008). Usability Benchmarking: Mobile Music and Video. In: Measuring the User Experience. Morgan Kaufmann, 263–271 25. Wittenberg, C. (2008). Uaftools – Softwareunterstützungformativer UsabilityTests. In: Herczeg, M. &Kindsmüller, M. C. (Hrsg.). Mensch & Computer 2008 – Tagungsband. Oldenbourg Verlag, 405–408

115


116


Zielgruppen im Kontext

117


Wissensmanagement für Usability Herausforderungen und Perspektiven

Dr. Christoph Nedopil YOUSE GmbH Anzinger Straße 4 81671 München christoph.nedopil@youse.de

Cornelia Wendt YOUSE GmbH Anzinger Straße 4 81671 München cornelia.wendt@youse.de

Abstract Angesichts des demografischen Wandels gewinnt die Generation Plus als Zielgruppe verstärkt an Relevanz – auch für digitale soziale Netzwerke. Doch ist die Usability von Facebook & Co. für die Senioren auch ansprechend? Welche Aufgaben und Funktionen soll das digitale Netzwerk überhaupt erfüllen? Eine Einhaltung von Usability-Richtlinien kommt allen Nutzern zu Gute. Aber besondere Anwendungs-Bedürfnisse, wie auch visuelle, motorische und kognitive Einschränkungen der Generation Plus stellen Entwickler immer wieder vor Herausforderungen, wie das aktuelle Angebot an sozialen Netzwerken zeigt. In diesem Beitrag wird zusammengefasst, was Usability Professionals im Hinblick auf die Generation Plus als Nutzergruppe besonders beachten sollten: Welche besonderen Bedürfnisse haben ältere Nutzer im Internet? Wie müssen Webseiten und sozialen Netzwerke gestaltet werden, dass die Generation Plus gut damit zurecht kommt? Und welche besonderen Bedürfnisse sollen Soziale Netzwerke erfüllen, die auf ältere Internetnutzer abzielen?

1. Die Generation Plus als Nutzer von morgen Der demografische Wandel verändert den Altersaufbau der deutschen Bevölkerung dramatisch: Während der Anteil der meist erwerbstätigen 20- bis 65-Jährigen von 61 Prozent im Jahr 2008 auf 54 Prozent im Jahr 2030 zurückgehen wird, wird der Anteil der über 65-Jährigen um ein Drittel auf etwa 29 Prozent der Bevölkerung ansteigen. Abbildung 1 macht deutlich, dass in nicht einmal 20 Jahren die Generation 50plus fast die Hälfte der deutschen Bevölkerung stellen wird. Dies sollte Anlass genug sein, sich als Usability Professional mit den Besonderheiten dieser Nutzergruppe auseinanderzusetzen. [Abb. 1]

Dies ist wenig überraschend, wenn man sich die Vorteile vergegenwärtigt, die das Internet gerade für Personen mit Mobilitätseinschränkungen mit sich bringt: Informationen zu Gesundheitsthemen, Veranstaltungen etc. können bequem von zu Hause recherchiert und Kontakte mit der Familie und Freunden über E-Mails oder Chat-Foren gepflegt werden. Darüber hinaus werden viele Dienstleistungen wie Home Banking oder auch Interaktionen mit Bürgerbüros oder Energielieferanten immer häufiger über das Internet abgewickelt. [Abb. 2]

Der demografische Wandel zeigt sich auch bei der Internet-Nutzung: Waren im Jahr 2001 laut Statistischem Bundesamt nur knapp 16 Prozent der über 50-Jährigen online, sind es im Jahr 2011 bereits 52 Prozent. Mit anderen Worten: Über die Hälfte der Senioren ist täglich online, Tendenz steigend. Abb. 1. Anteile verschiedener Altersgruppen in Deutschland heute und im Jahr 2030 (Statistisches Bundesamt, 2011).

118

Dr.-Ing. Sebastian Glende YOUSE GmbH Winsstraße 62 10405 Berlin sebastian.glende@youse.de

Keywords: /// Generation Plus /// Senioren /// Web-Usability /// Internet, Social Networks /// digitale soziale Netzwerke

Auch wenn manche Firmen aus Imagegründen Berührungsängste mit der Generation Plus haben, macht sie ihr durchschnittlich hohes Einkommen zu attraktiven Kunden. Entsprechend stellen sich Hersteller verschiedener Branchen allmählich auf die wachsende Bedeutung dieser Bevölkerungsgruppe ein: Anstelle von gebrechlichen Testimonials finden sich vermehrt agile, lebensfrohe Senioren in Werbeannoncen, die nicht mehr nur für klassische Seniorenartikel wie Rollatoren oder Gesundheitstees werben, sondern auch für Partnersuche und


Usability Professionals 2012 Zielgruppen im Kontext

gesellschaftliches Engagement – auch in digitalen sozialen Netzwerken. Aus einer Vielzahl von Projekten mit der Generation Plus hat YOUSE zwei zentrale Aspekte festgestellt, die bei älteren Nutzern beachtet werden sollten: zum einen typische altersbedingte Einschränkungen und deren Einfluss auf die Gestaltung von Interfaces, und zum anderen die besonderen Anforderungen dieser konsumerfahrenen Gruppe. Diese beiden Aspekte werden in diesem Artikel auf digitale soziale Netzwerke angewendet. 2. Besonderheiten der Nutzergruppe „Generation Plus“ Für ältere Verbraucher kursieren viele Bezeichnungen wie „Generation Plus“, „Silver Surfers“ „Best Agers“, oder „Empty Nesters“, die sich auf unterschiedliche Altersgruppen, Aktivitäten oder Lebensphasen wie den Auszug der Kinder oder das Renteneintrittsalter beziehen. Die Vielfalt der Ausdrücke spiegelt die Tatsache wider, dass es sich bei der Generation Plus (in diesem Beitrag die über 50-Jährigen) nicht um eine homogene Gruppe handelt, sondern um Menschen in ganz unterschiedlichen Lebensabschnitten, mit unterschiedlichen Konsumpräferenzen, unterschiedlichen finanziellen Mitteln und unterschiedlichem Gesundheitszustand. Verschiedene Typologien wie die Sinus-Milieus® oder die „Typologie der Wünsche“ von Roland Berger zeugen von diesen heterogenen Subgruppen, die bei der Entwicklung und Bewertung von Produkten berücksichtigt werden sollten. Was die Generation Plus eint, ist der fortgeschrittene Alterungsprozess, der bereits mit dem 30. Lebensjahr beginnt und mit irreversiblen Veränderungen des Organismus verbunden ist: Sensorische, motorische und kognitive Fähigkeiten nehmen mit der Zeit kontinuierlich ab (Ding-Greiner/Lang, 2004). Diese natürlichen Abbauerscheinungen sind auch für das Konsumentenverhalten bedeutsam und sollten daher bei der Optimierung der Usability von digitalen Medien, wie soziale Netzwerke, unbedingt beachtet werden.

Abb. 2. Durchschnittliche Nutzung des Internets durch Personen verschiedener Altersgruppen in Deutschland in Prozent (Statistisches Bundesamt, 2011)

2.1. Einbußen im Alter Im Vergleich zur natürlichen Umwelt weisen digitale Medien eine deutliche höhere Informationsdichte auf und stellen somit höhere Anforderungen an die Informationsverarbeitung des Nutzers. Wer das ökonomische Potenzial der Generation Plus nutzen möchte, sollte die Gestaltung digitaler Medien-Produkten an die Bedürfnisse und Einschränkungen dieser Zielgruppe anpassen. Eine Zusammenfassung der Einbußen im Alter findet sich in Tabelle 1. Sensorische Fähigkeiten

Bereits ab dem 35. Lebensjahr ist der Lichtbedarf von Personen signifikant erhöht. Ab dem vierten Lebensjahrzehnt nehmen die Fähigkeit, Tiefe und Helligkeit zu adaptieren, und die Verarbeitungsgeschwindigkeit von Reizen ab. Ab dem 60. Lebensjahr verschlechtern sich visuelle Schärfe und Kontrastsensitivität rapide, und das Blickfeld wird kleiner (Ishihara et al., 2002). Daraus ergeben sich Schwierigkeiten beim Lesen von Webseiten oder Interfaces, aber auch mit Beschriftungen und Anleitungen von Produkten. Auch die korrekte Wahrnehmung und Lokalisierung von Tönen sowie das Sprachverstehen bei Hintergrundgeräuschen nehmen mit zunehmendem Alter ab (Gates/Rees, 2003). Hinzu kommen altersbedingte Einschränkungen der taktilen Reizwahrnehmung, was für die Bedienung

von Tasten ein Problem darstellen kann. Die altersbedingte Austrocknung der Haut hat aufgrund der geringeren Induktion ebenfalls negative Auswirkungen auf die Bedienung von Touchscreens. Motorische Fähigkeiten

Der Mensch verliert bis zum 65. Lebensjahr rund 30-40% seiner Muskelmasse und es kommt zu einer deutlichen Versteifung der Gelenke. Mit etwa 45 Jahren nimmt die Koordinationsfähigkeit, insbesondere unter Zeitdruck, stark ab. Schnell aufeinander folgende Bewegungen bereiten mit zunehmenden Alter Schwierigkeiten. Altersbedingte Einbußen in der Feinmotorik haben direkte Auswirkungen auf die Steuerung von Maus oder Tastatur (Smith et al., 1999): eine präzise Positionierung, schnelle Eingaben oder das Drücken mehrerer Tasten gleichzeitig bereiten im Alter Probleme. Kognitive Fähigkeiten

Aufgrund struktureller Veränderungen im Gehirn verändert sich auch die kognitive Leistungsfähigkeit im Alter. Ab einem Alter von 30 Jahren nehmen Kurz- und Langzeitgedächtnis und Lernfähigkeit sukzessiv ab (Hoyer/Verhaegen, 2006). Damit verbunden ist eine verlangsamte Informationsverarbeitung und Einbußen der geistigen Flexibilität und des Problemlöseverhaltens (kurz: der fluiden Intelligenz). Ferner zeigen sich altersbedingte Defizite bei der selektiven und geteilten Aufmerksamkeit, die vor allem bei komplexen Aufgaben

119


Bereich

Altersbedingte Einbußen

Sehen

–– Verarbeitungseffizienz –– Blickfeld –– Verfolgung schneller Objekte –– Anpassungsfähigkeit an Lichtveränderungen –– Wahrnehmung von Farbunterschieden –– Wahrnehmung hoher Töne –– Verstehen von Sprache, v. a. wenn diese durch Hintergrund- bzw.

Hören

Nebengeräusche gestört ist

Motorik

–– Lokalisierung von Geräuschen –– Beweglichkeit –– Koordination, insbesondere unter Zeitdruck und mit hohen energetischen Anteilen

Kognition

–– Gleichzeitige oder schnell auszuführende sequentielle Bewegungen –– Kurzzeit- und Langzeitgedächtnis –– Verarbeitungsgeschwindigkeit –– Fluide Intelligenz, z. B. Gewöhnung an neue Bedienprinzipien –– Geteilte Aufmerksamkeit, insbesondere bei komplexen Aufgaben und/oder Zeitdruck –– Parallele Verarbeitung

eine wichtige Rolle spielen. Die kristalline Intelligenz hingegen beruht auf im gesamten Lebenslauf gesammelten Wissen, erworbenen Fähigkeiten und Erfahrungen. Als kognitive Kompetenz umfasst sie bspw. Wortschatz, Erfahrungswissen sowie Urteilsfähigkeit. In der Regel bleibt diese Dimension der Intelligenz bis ins hohe Alter erhalten und steigt bei kontinuierlichem Gebrauch kognitiver Funktionen sogar an. [Tab. 1] 2.2. Digitale Seniorentreffs: Die Generation Plus in sozialen Netzwerken Der Lebensabschnitt jenseits der 50 Jahre wird von verschiedenen Lebensthemen bestimmt, wie dem Auszug der eigenen Kinder, dem Eintritt ins Rentenalter oder zunehmenden Gesundheitsbeschwerden bis hin zu verstärkter Abhängigkeit von externer Hilfe. Viele dieser Veränderungen sind mit einem Wegfall sozialer Beziehungen verbunden, und gerade unter den älteren Menschen nimmt die Anzahl der Ein- bis Zwei-Personenhaushalte stark zu. Kommen dann noch Erkrankungen oder Unfälle hinzu, die die Mobilität einschränken, ist die Gefahr der Isolation im Alter groß. Aber auch ohne solch einschneidende Ereignisse führen schleichende

120

Veränderungen dazu, dass die Ausübung von Ehrenämtern, Reisen oder tägliche Besorgungen erschwert werden – und mit ihnen die Möglichkeit der Kontaktaufnahme mit anderen. Digitale soziale Netzwerke für die Generation Plus sind daher ein geeignetes Medium, um einer zunehmenden Isolation gegenzusteuern, Kontakte zu pflegen oder zu initiieren und sich Informationen aus der Außenwelt zu beschaffen. Der Grundgedanke zur Nutzung sozialer Netzwerke entspricht dem jüngerer Surfer: Ähnlichdenkende zu finden und sich mit ihnen auszutauschen. Ziel der älteren Nutzer ist es, über gemeinsame Themen wie Reisen, Kochen oder bestimmte Hobbies neue Bekanntschaften oder Tipps zur Freizeitgestaltung zu finden.

Tab. 1. Sensorische, motorische und kognitive Abbauerscheinungen im Alter (Dollinger, 2009)

Doch sind die großen Online-Netzwerke wie Facebook für die Generation Plus das Richtige? Ältere Nutzer möchten sicher gehen, dass sich die anderen Nutzer für ähnliche Themen interessieren wie sie selbst, was auf altersübergreifenden Portalen nicht unbedingt gegeben ist. Speziell für ältere Nutzer gibt es daher in Deutschland schon eine Vielzahl von sozialen Online-Netzwerken, wie beispielsweise „feierabend.de“ oder „platinnetz. de“. [Tab. 2] Aber auch in der Facebook-Community gibt es zahlreiche registrierte Nutzer zur Generation Plus: bei knapp 24 Millionen Nutzern im Juni 2012 in Deutschland hat die Generation Plus (über 50-Jährige) einen Anteil von ca. sieben Prozent. Dies entspricht ca. 1,7 Millionen registrierten

Netzwerk

Anzahl täglicher Besucher

Platinnetz.de

10.100* – 21.000**

50plus-treff.de

7.300* – 11.000**

Feierabend.de

3.400** – 7.100*

Seniorentreff.de

3.000** – 4.200*

Iquarius.de

780**

Activagers.de

38* – 74**

Seniorenblume.de

Keine Daten verfügbar

Tab. 2. Seitenbesuche sozialer Netzwerke für die Generation Plus (*visualizetraffic.com, **hypestat.com)


Usability Professionals 2012 Zielgruppen im Kontext

Nutzern. Im Zeitraum von März bis Juni 2012 sind ca. 10.000 Nutzer über 65 Jahre und ca. 50.000 Nutzer zwischen 50 und 65 Jahren Facebook beigetreten (www.socialbakers.com). [Abb. 3] Die von der Körber-Stiftung und Stern in Auftrag gegebene Studie „Alter neu Erfinden“ berichtet ähnliche Zahlen (KörberStiftung, 2012): neun Prozent der über 65-Jährigen nutzen soziale Netzwerke im Internet häufig – das entspricht immerhin 1,5 Millionen Nutzern in Deutschland.1 Dagegen benutzen ca. 86 Prozent dieser Altersgruppe soziale Netzwerke im Internet nur selten bis gar nicht (14,5 Millionen Deutsche). Während die Anzahl der Internetnutzer der Generation Plus also insgesamt wächst, liefert Google Trends ein Bild, das bezüglich der „daily unique visitors“ auf digitalen Sozialen Netzwerken eher eine Stagnation zeigt (siehe Abbildung 3). Betrachtet man die Diskrepanz zu der Anzahl der älteren Internetnutzer, zeigt sich ein großes Potenzial für weitere Kunden aus der Generation Plus. Wie lassen sich diese potenziellen Nutzer aktivieren? Welche Anforderungen stellt die ältere Generation an Webseiten bzw. soziale Netzwerke? 3. Social Network Design für die Generation Plus 3.1. Größere Schrift? Einige Wahrheiten über die Generation Plus Die Leitsätze der verschiedenen UsabilityNormen gelten zunächst für alle Altersgruppen gleichermaßen: Erwartungskonforme Dialoge und fehlertolerante Eingabefelder erleichtern allen Nutzern die Interaktion mit einem System. Allerdings ist die Generation Plus von Verletzungen dieser Regeln viel stärker betroffen, was sich quantitativ in schlechteren Usability-Maßen (Erfolgsrate, Gesamtzeit und Fehler) nachweisen lässt (Nielsen, 2002). Der Grund dafür liegt zum einen in den oben angeführten sensorischen, motorischen und kognitiven Einschränkungen sowie in der insgesamt geringeren Erfahrung mit Online-Anwendungen. Dieses Problem wird dadurch

Abb.3. Anzahl der täglichen Besucher (in Tausend) exemplarisch für drei soziale Netzwerke der Generation Plus (Google Trends)

verschärft, dass ältere Nutzer bei UsabilityProblemen die Ursache eher bei sich als bei der Webseite vermuten (im Gegensatz zu jüngeren Nutzern), was die Frustration noch verstärkt (siehe eResult Studie „Senioren nutzen Websites anders“). Betrachtet man beispielsweise die sieben Grundsätze der Dialoggestaltung nach DIN EN ISO 9241-110, so ergeben sich daraus für ältere Nutzer mit ersten Leistungseinbußen ganz spezifische Empfehlungen, die unbedingt beachtet werden sollten (siehe Tabelle 4). Neben ausreichender Schriftgröße und Kontrasten (die übrigens in der Praxis laut eResult selten bemängelt werden) ist besonders die hohe Fehlertoleranz des Systems und eine verständliche, übersichtliche Navigation für ältere Nutzer wichtig. Aufgrund der geringeren Gedächtnisspanne sollten außerdem Links an sinnvollen Stellen redundant verwendet werden. Feinmotorische Einbußen können durch große Link-Icons und den Verzicht auf Dropdown-Menüs nivelliert werden. Webseiten bzw. Interfaces, die diesen Empfehlungen nicht nachkommen, laufen Gefahr, dass gerade ältere Nutzer frustriert und abgeschreckt werden. Dies hat zur Folge, dass weder dem Nutzer der Generation Plus die Vorteile eines digitalen Netzwerks zugute kommen, noch dem Anbieter, der ökonomische Interessen verfolgt. [Tab. 3]

3.2. Bilder-Quiz statt Farmville: Social Networks für die Generation Plus Bezüglich der Usability von digitalen sozialen Netzwerken für die Generation Plus können und müssen die bereits in vielen Studien erforschten Grundsätze (siehe auch Kapitel 3.1) selbstverständlich übertragen werden. Aus zahlreichen Forschungsarbeiten, die YOUSE mit der Generation Plus in unterschiedlichen Bereichen – von Hardware bis Software – unternommen hat (z. B. Nedopil, 2011; Glende, 2012), haben sich die folgenden drei Aspekte als besonders wichtige Erfolgsfaktoren herauskristallisiert: ein hoher persönlicher Nutzen, Kontinuität bzw. Beständigkeit, und eine adäquate Zielgruppenansprache. Mehrwert deutlich machen

Wenn man die Internetseiten betrachtet, welche die Generation Plus am häufigsten besucht, sind Nachrichtenportale (z. B. bild. de, spiegel.de), Unterhaltungsportale (z. B. youtube.com) und Shopping (z. B. amazon.de) sowie Online-Banking besonders beliebt. Das „Surfen“ – also das Stöbern im Netz – wird in der Generation Plus kaum betrieben. Um soziale Netzwerke erfolgreich zu machen, müssen dementsprechend Inhalte angeboten werden, die einen hohen Nutzen für die Generation Plus bringen. Gleichzeitig darf bei allen Angeboten keine

121


Norm

Empfehlungen für Webseiten

Aufgabenangemessenheit

–– Lesbare Schrift: Schriftgröße 12-14 Punkt, Schriftarten wie Arial, Verdana, Garamond, Frutiger; wenig Kursiv; wenig Kapitalisierung von Absätzen, linksbündige Texte, größere Zeilenabstände (optimal: doppelt) –– Kontraste: dunkle Schrift auf hellem Hintergrund (nicht reinweiß) –– blau-grün-Kontraste vermeiden –– Keine Pop-ups, keine animierten Werbebanner –– Printversion anbieten –– Nur textrelevante Bilder verwenden –– Nur unbedingt notwendige persönliche Daten abrufen

Selbstbeschreibungsfähigkeit

–– Links visuell hervorheben (Kontrast und Mouse-Over-Symbol)

–– Flache Link-Hierarchien mit maximal zwei Schritten bis zum Ziel

–– Keine neuen Fenster öffnen (Pop-ups) –– Evtl. farbliche Markierung von bereits besuchten Seiten Erwartungskonformität

–– Konsistente Terminologie für Navigation und Inhalte –– Fixe Position wichtiger Elemente (Suchfeld, Einkaufskorb etc.) –– Verwendete Symbole auf Verständlichkeit prüfen

Lernförderlichkeit

–– Verständliche Fehlermeldungen mit konkreten Handlungsanweisungen

–– Fehlermeldungen mittig auf Seite platzieren, guter Farbkontrast

–– Verständliche Hilfetexte (werden von Senioren gewissenhaft durchgelesen) oder Glossar technischer Begriffe Steuerbarkeit

–– Scroll-Balken nur sparsam verwenden –– Klickbare Elemente groß gestalten –– Keine Fehlermeldung bei Doppelklicks –– Statische Menüs besser als Dropdown-Felder –– Schritt-für-Schritt Anweisungen mit „zurück“-Option

Fehlertoleranz

–– Such- und Eingabefelder tolerant gegenüber Klammern, Anführungszeichen etc. (besonders bei Telefonnummern, Datum, Kreditkartennummer) –– möglichst viele Defaults vorgeben

Individualisierbarkeit

–– Fontgröße einstellbar –– Kontraste einstellbar

Tab. 3. Design-Empfehlungen für Webseiten mit Blick auf die Besonderheiten der Generation Plus (Quelle: Dollinger, 2009; Dzida, 2005; Kurniwa & Zepharis, 2005; YOUSE)

122

Stigmatisierung erfolgen, z. B. durch den Hinweis auf körperliche Einschränkungen oder Einsamkeit im Alter. Stattdessen sollten eher Bedürfnisse der Generation Plus offen und positiv angesprochen werden, z. B. nach Austausch oder Information. Potenziell erfolgreiche Inhalte von sozialen Netzwerken sind beispielsweise: –– Möglichkeiten, zu bestimmten Themen Gruppen zu bilden bzw. diesen beizutreten –– Aktuelle Informationen zu Gesundheit, Recht, Kochen/Handwerken etc. –– Hinweise auf Kulturveranstaltungen (Theater, Konzert, Tanz) –– Reiseberichte und -tipps –– Foren zum Teilen von Erfahrungen, Fotos etc. –– Möglichkeiten zum direkten Kontakt / zur Partnersuche –– Denk- und Knobelspiele Ein zentraler Mehrwert für Senioren an digitalen Netzwerke könnte also darin bestehen, Ansichten auszutauschen und reale „Offline“-Treffen zu organisieren, also z. B. regionale Stammtische zu bestimmten Themen zu veranstalten. Auch die Partnersuche nimmt einen immer größeren Stellenwert ein. Kontinuität und Vertrauen signalisieren

Kontinuität schafft Vertrauen in die Qualität der Webseite. Oft sind gerade die Webseiten erfolgreich, die der Generation Plus auch durch offline-Shops bekannt sind (z. B. Kaufhof). Zusätzliche Printmedien wie Magazine oder Kataloge bieten Senioren etwas „Greifbares“, was ebenfalls die Vertrauenswürdigkeit einer Marke oder eines Produktes erhöht. Umbenennungen oder ein stark verändertes Design stiften dagegen Verwirrung und sollten nur erfolgen, wenn dadurch ein klarer Zusatznutzen für die Zielgruppe entsteht. Darüber hinaus kann sich die Generation Plus bei einem zeitlich stabil gestalteten Web-Auftritt auf die spezielle Nutzerführung besser einlassen. Die Hauptgründe hierfür liegen zum einen in der geringeren Erfahrung mit dem Medium „Internet“,


Usability Professionals 2012 Zielgruppen im Kontext

zum anderen in den bereits genannten altersbedingen Veränderungen, genauer der Abnahme der Lernfähigkeit (liquide Intelligenz). So sollten beispielsweise bestimmte Elemente wie das Suchfeld oder der Warenkorb immer an derselben Stelle auf einer Seite platziert sein, damit sie leicht wiedergefunden werden. Die Hervorhebung von Links und die Benennung von Buttons sollten ebenfalls typischen Standards entsprechen. Neben den Dingen, die eine Webseite können muss, gibt es auch zahlreiche Dinge, die Webseiten vermeiden sollen, da die Generation Plus bestimmte Vorurteile bezüglich des Internets mitbringt. Diese beziehen sich insbesondere auf die Weitergabe persönlicher Daten und die Verbreitung von Viren. Daher sind Sicherheitslabels ein guter Weg, um ein positives Gefühl bei der Benutzung zu vermitteln.

Abb. 4. Beispiel von Persona (YOUSE Innovation Toolbox, 2011)

Die Generation Plus adäquat ansprechen

Die Zielgruppenansprache ist bei allen Altersgruppen ein wichtiger Aspekt. In zwei Punkten unterscheidet sich die Generation Plus jedoch deutlich von jüngeren Webnutzern: (1) die Angst vor Stigmatisierung ist deutlich stärker ausgeprägt (bezüglich negativ besetzter Altersbilder oder der Wahrnehmung als „finanzielles Objekt“) und (2) das Gefühl, dass man entweder daraus „herausgewachsen ist“ oder „das noch nie gebraucht hat“. Wenn man dann noch die unterschiedlichen Werte und Lebenseinstellungen der Generation Plus hinzuzieht – welche sich in verschiedenen Milieus oder Lebensphilosophien äußert (z. B. Limbic Types, Sinus Milieus, Lebensführungstypologien) – zeigt sich, dass die adäquate Ansprache der verschiedenen Zielgruppen der Generation Plus ein „Eiertanz“ ist. Eine günstige Möglichkeit zur ersten Zielgruppenanalyse in der Generation Plus ist die Nutzung von Personas. [Abb. 4] YOUSE konnte in mehreren Studien (z. B. Nedopil, 2012) zeigen, dass die konkrete Ansprache der Generation Plus insbesondere mit Hilfe von Multiplikatoren erfolgen kann – und das trifft in besonderem Maße

auf soziale Netzwerke zu. Dabei haben sich vertraute Personen oder Institutionen (z. B. Verwandte, Freunde, Stiftung Warentest) als zielführend herausgestellt. Ein soziales Netzwerk könnte dementsprechend durch eine vertraute Quelle (z. B. Stiftung Warentest) zertifiziert sein. Um diese Multiplikatoren zu aktivieren, spielt auch für soziale Netzwerke das direkte, persönliche Marketing eine große Rolle. Durch persönliches Marketing (z. B. in Kaufhäusern, Informationsständen) lassen sich Ängste abbauen, da Fragen direkt gestellt und der Nutzen leicht aufgezeigt werden können. 4. Die Zukunft ist offline und online Die Generation Plus ist in sozialen Netzwerken organisiert – offline, und zunehmend online. Digitale soziale Netzwerke bieten jedoch gerade im Rahmen des demografischen Wandels enorme Chancen – sowohl für die Generation Plus (z. B. Verringerung von Vereinsamung), als auch für die Wirtschaft. Um digitale soziale Netzwerke bei der Generation Plus erfolgreich zu machen,

müssen vier Dinge besonders beachtet werden: 1. Das Design muss den altersbedingten Einbußen der Generation Plus angepasst werden. 2. Die Funktionalität der Webseite (kombiniert mit einer guten Benutzbarkeit) muss deutlicher an die Bedürfnisse angepasst werden. Diese sind momentan die Organisation von Offline-Aktivitäten und das Teilen von Informationen ohne Preisgabe zu vieler persönlicher Daten. 3. Die Angebote müssen eine hohe Kontinuität haben, sowohl im Auftritt als auch im Design. Das heißt nicht, dass keine Änderungen notwendig oder möglich sind. Es heißt jedoch, dass diese Änderungen sorgfältig und zum Zwecke eines Zusatznutzens (aus Nutzersicht) erfolgen sollen. 4. Die richtige Kommunikation und Ansprache mit der Generation Plus ist und bleibt eine Herausforderung, da es eine Vielzahl von Zielgruppentypen und Fallen (z. B. Stigmatisierung) gibt. Eine gute Kommunikation sollte persönlich sein und Vertrauen schaffen.

123


Die im Augenblick bestehenden digitalen sozialen Netzwerke für die Generation Plus in Deutschland werden – ähnlich wie auch nicht-alterspezifische Netzwerke – um Marktanteile kämpfen müssen, um nicht in einer kommenden Konsolidierungsphase vom Markt zu verschwinden. Ihr Erfolg wird nicht unwesentlich von der Berücksichtigung der genannten Punkte abhängen.

Handbook of the Psychology of Aging (S. 11. Initiative D21 e.V. und TNS Infratest (2010):

1. Buchegger, O. (2012). Soziale Netze für Senioren. http://www.seniorenfreundlich.de/

(N)Onliner Atlas 2010, Berlin. & Osaki, H. (2002): Measurement and computer-graphics simulation of agerelated decline in color perception. In: R. Pieper, M. Vaarama & J. L. Fozard (Hrsg.): Starting into the Third Millenium (S. 146-157). Aachen: Shaker Verlag,. 13. Kurniawan, S. & Zaphiris, P. (2005). Research-

soziale-netze.html (abgerufen am 27. Juni

derived web design guidelines for older

2012).

people. ASSETS, 9.-12. Oktober 2005,

2. Ding-Greiner, C. & Lang, E. (2004). Alternsprozesse und Krankheitsprozesse

Baltimore, Maryland, USA: 129-135. 14. National Institute on Aging und National

– Grundlagen. In: Kruse, A.; Martin & M.

Library of Medicine (2001). Making Your

(Hrsg.): Enzyklopädie der Gerontologie (S.

Web Site Senior Friendly: A checklist. http://

182-206). Bern: Verlag Hans Huber.

www.nih.gov/icd/od/ocpl/resources/wag/

3. Dollinger, I. V. V. (2009). Silver Gaming – der demografische Wandel als Chance. Eine empirische Analyse der Akzeptanz digitaler Spiele im Altersgruppenvergleich. Dissertationsschrift, Technische Universität München. 4. Dzida W. et al. (2000). Gebrauchstauglichkeit von Software. Schriftenreihe der Bundesanstalt für Arbeitsschutz und Arbeitsmedizin 5. eResult Studie: Senioren nutzen Websites „anders“. 6. http://www.eresult.de/studien_artikel/ forschungsbeitraege/seniorenfreundliche_ website-gestaltung.html (abgerufen am 26.06.2012) 7. Fisk, A. & Rogers, W. A., Charness, N., Czaja, S. J. & Sharit. J. (2004). Designing for Older Adults: Principles and Creative Human Factors Approaches. Boca Raton, FL: CRC Press LLC. 8. Gates, G. A. & Rees, T. S. (2003). Otologic

documents/checklist.pdf (aufgerufen am 27. Juni 2012). 15. Nedopil, C., Steger, U., Amann, W. (2011). Managing Complexity in Organizations; Palgrave Macmillan; Chippenham 16. Nedopil, C., Glende, S., Klaus, H., Balasch, M. (2012). Die Mobile Generation Plus; Berlin: Deutsche Telekom Laboratories und YOUSE. 17. Nielsen, J. (2002). Web Usability for Senior Citizens: 46 Design Guidelines Based on Usability Studies with People Age 65 and Older. Siehe http://www.useit.com/alertbox/ seniors.html (abgerufen am 25.06. 2012). 18. Statistische Ämter des Bundes und der Länder (2011). Demografischer Wandel in Deutschland, Heft 1. 19. Statistisches Bundesamt (2011). Bevölkerungsvorausberechnung: Ergebnisse für Deutschland. 20. Statistisches Bundesamt (2011). Private Nutzung von Informationsund Kommunikationstechnologie.

Changes and Disorders. In: C. K. Cassel et

https://www.destatis.de/DE/

al. (Hrsg.): Geriatric Medicine: An Evidence-

ZahlenFakten/GesellschaftStaat/

based Approach (S. 893-900). 4. Auflage,

EinkommenKonsumLebensbedingungen/

New York: Springer.

ITNutzung/Tabellen/NutzungInternetAlter_

9. Glende S., Nedopil, C. (2012). Sechs

IKT.html (abgerufen am 26. Juni 2012).

Personen in einem Gerät – Anforderungen an

21. Smith, M., W., Czaja, Sara, J. & Sharit,

Assistenzroboter im Haushalt aus Nutzersicht.

J. (1999). Aging, Motor Control, & the

In: BMBF, VDE et al. (Hrsg.): Technik für ein

Performance of Computer Mouse Task.

selbstbestimmtes Leben. Berlin, Offenbach: VDE-Verlag.

Human Factors, 41 (3), 389-397. 22. Turnwald, M, Frerichs, A. & Prilla, M. (2011).

10. Hoyer, W. J. & Verhaegen, P. (2006). Memory

Usability Testing für und mit Senioren. In:

Aging. In: J. E. Birren & W. Schaie (Hrsg.):

H. Brau, A. Lehmann, K. Petrovic & M. C.

124

Professionals 2011 (S.216-220). Stuttgart. 23. YOUSE, TU Berlin (2011): Innovation Toolbox (siehe www.youse.de/toolbox)

12. Ishihara, K., Ishihara, S., Nagamachi, M.

Gerontechnology – Technology and Aging –

Literatur

Schroeder (Hrsg.). Proceedings of Usability

209-232). Amsterdam u. a.: Elsevier.

Die Nutzungsrate von Facebook in der Generation 18-65 in Deutschland liegt im Juni 2012 bei 44%.

1


Usability Professionals 2012 Zielgruppen im Kontext

125


Inclusive Gaming – Spieleentwicklung neu denken! Eine Untersuchung zur Nutzung und Benutzbarkeit digitaler Spiele durch blinde und sehbehinderte Kinder und Jugendliche Janine Liebal Technische Universität Ilmenau FG Kommunikationswissenschaft Ehrenbergstraße 29 98693 Ilmenau janine.liebal@tu-ilmenau.de

Abstract Digitale Spiele gehören zur Jugendkultur, von der Kinder und Jugendliche mit Behinderungen aufgrund mangelnder Barrierefreiheit und Benutzerfreundlichkeit häufig ausgeschlossen werden. Neben typischen Vorurteilen gegenüber vermeintlich kleinen und dadurch offenkundig unrentablen Nutzergruppen, für die sich eine kostspielige Spieleentwicklung kaum lohnt, fehlt es Entwicklern sowohl an Wissen um die Nutzergruppen selbst – deren Fähigkeiten und Anforderungen, Wünsche und Ziele – als auch an Empfehlungen zur Gestaltung der Benutzeroberfläche und des Interaktionsdesigns. Einige erste Studien gehen bereits auf die Mediennutzung blinder und sehbehinderter Menschen ein, wobei sowohl Kinder und Jugendliche als auch digitale Spiele keine nähere Beachtung finden. In einer Studie mit 48 Kindern und Jugendlichen im Alter von 7 bis 18 Jahren wurde daher mittels teilstrukturierter Gruppenbefragung erhoben, ob sie spielen, was und wie sie spielen, welche grundsätzlichen Probleme mit der Bedienung beim Spielen auftreten und welche Wünsche sie an die Spieleentwickler haben.

1. Einleitung Digitale Spiele haben sich trotz mannigfaltigster Diskussionen als Kulturgut etabliert und bilden heute einen wichtigen Teil der Jugendkultur (vgl. Buaud et al., 2002, S. 173). Kindern und Jugendlichen mit Behinderung, egal ob körperlicher, geistiger oder sensorischer Art, bleibt diese Form der Freizeitbeschäftigung jedoch oft verwehrt. Gleichwohl können insbesondere blinde und sehbehinderte Kinder durch die Nutzung digitaler Spiele profitieren, da diese ihre psychomotorische und kognitive Entwicklung nachweisbar fördern (vgl. Archambault et al., 2007, S. 44). Es gibt verschiedene Gründe, warum digitale Spiele für blinde und sehbehinderte Kinder nicht erreichbar sind. Dazu zählen zunächst Vorurteile oder Unwissenheit der Entwickler. Die Vorstellung, blinde Kinder würden Videospiele spielen erscheint möglicherweise absurd und die Zielgruppe selbst viel zu klein, um Gewinne aus der Produktion zu erzielen. Selbst wenn

126

Interesse an diesen bestehen würde, so fehlte es noch immer an Wissen über die Fähigkeiten und Anforderungen, Wünsche und Ziele der kindlichen Nutzer aber auch an expliziten, praxistauglichen Empfehlungen zur Gestaltung der Benutzeroberfläche und des Interaktionsdesigns in digitalen Spielen. Digitale Spiele, die bereits von Haus aus ein hohes Maß an Benutzerfreundlichkeit besitzen und durchaus auch von blinden und sehbehinderten Kindern spielbar wären, bleiben diesen sehr wahrscheinlich verborgen. Aktuell gibt es beispielsweise noch keine gängigen Symbole, die auf die Eignung für besondere Nutzergruppen hinweisen, obgleich die Ansätze hierfür gegeben sind. [Abb. 1]

Abb. 1. Potentielle Symbole zur Darstellung verschiedener Barrieren (Special Effect, 2011)

Keywords: /// Barrierefreiheit /// digitale Spiele /// Blindheit /// Sehbehinderung /// Kinder

2. Hintergrund In Deutschland gibt es keine zuverlässigen Statistiken über die aktuelle Anzahl blinder und sehbehinderter Menschen (vgl. DBSV, 2011). Im statistischen Jahrbuch 2011 wird die Zahl Blinder und Sehbehinderter auf 352.943 geschätzt, wobei ausschließlich Bürger einbezogen werden, die einen Schwerbehindertenausweis besitzen und Sozialleistungen beziehen (vgl. statistisches Jahrbuch, 2011, S. 235). Darunter sind etwa 3.500 blinde Kinder und Jugendliche im Alter von 0 bis 15 Jahren. Aus Hochrechnungen lässt sich zudem schließen, dass zusätzlich etwa 15.000 Kinder und Jugendliche eine Sehbehinderung besitzen (vgl. Beyer, 2009). In Deutschland hat sich der Begriff der Sehschädigung als Oberbegriff etabliert. Darunter werden Sehbehinderung, hochgradige Sehbehinderung und Blindheit zusammengefasst (vgl. Walthes, 2005, S. 51). Ähnlich vage sind die Aussagen zur Mediennutzung durch blinde und


Usability Professionals 2012 Zielgruppen im Kontext

Abb. 2. Geschlechterverteilung

sehbehinderte Menschen. So setzt sich eine Studie „Ohne Bilder im Bilde“ (vgl. Huber, 2004) zwar mit der Mediennutzung und Medienbewertung von Blinden auseinander, diese bezieht sich aber lediglich auf Massenmedien wie Fernsehen, Bücher oder Zeitschriften. Eine weitere Studie „das Internet hören und fühlen“ (vgl. Slawinski, 2005) setzt sich zudem mit der Problematik des barrierefreien Internets auseinander. Hierbei wird explizit die Sichtweise geburtsblinder und früherblindeter Schüler betrachtet. Die Nutzung digitaler Spiele durch Blinde und Sehbehinderte wurde bislang jedoch gar nicht untersucht. 3. Empirische Studie mit blinden und sehbehinderten Kindern und Jugendlichen Um möglichst viele verbale Informationen von den Kindern zu erhalten und erste Eindrücke ihrer Spielenutzung zu gewinnen, wurde eine Befragung angestrebt. Die Durchführung von Interviews mit einem einzelnen Kind geben diesem häufig das Gefühl einer Prüfungssituation, wodurch es gehemmt ist, frei zu sprechen und die eigene Meinung offen mitzuteilen. Durch den so aufgebauten Druck können sich Kinder häufig nicht einmal mehr an Lieblingsspiele erinnern. Es empfiehlt sich daher entweder eine längere Eingewöhnungszeit zu veranschlagen, in der sich Interviewer und befragtes Kind beschnuppern können oder aber von vornherein Gruppeninterviews bzw. Gruppendiskussionen durchzuführen. Diese bestehen im Gegensatz zu

Abb. 3. Altersverteilung

Einzelinterviews aus der Interaktion unter mehreren Teilnehmern und einem Moderator (vgl. Liebal/Exner, 2011, S. 109). Für die Durchführung der Studie fiel die Wahl auf eine teilstrukturierte Gruppendiskussion. Der Moderator hat hierbei die Option, anhand eines vorbereiteten, aber flexibel einsetzbaren Fragenkataloges zielführend in das Gespräch einzugreifen. Gleichzeitig können sich die Kinder offen zur Thematik äußern und austauschen (vgl. Bortz/Döring, 2005, S. 314ff.). 3.1. Vorbereitung Für die Gruppendiskussion mit blinden und sehbehinderten Kindern und Jugendlichen wurde ein staatliches, überregionales Förderzentrum mit dem Förderschwerpunkt „Sehen“ ausgewählt. Als anerkannte Medienschule stellt diese sicher, dass jeder Gruppenteilnehmer zumindest erste Erfahrungen mit digitalen Medien gemacht hat. Um die Kinder nicht zu verunsichern, wurde die Durchführung der Gruppendiskussion innerhalb der bekannten Räumlichkeiten angestrebt. Insbesondere die blinden Kinder orientieren sich stark an dem bekannten Aufbau der Räume. Bereits ein anderer Sitzplatz als der Gewohnte oder ein veränderter Standort der Tische kann sie vor große Probleme stellen, möglicherweise zu Orientierungslosigkeit führen. Teilnehmer

Für die Gruppendiskussionen wurden die Kinder und Jugendlichen in ihren

Realgruppen belassen. Die Zusammensetzung richtete sich dabei nach der jeweils besuchten Klasse, welche aus sechs bis zehn Schülerinnen und Schülern bestand. Diese Einteilung sollte zum einen Ängste oder Hemmungen gegenüber fremden Kindern einer anderen Schulklasse verhindern. Zum anderen schafft ein vertrautes Milieu Sicherheit und lässt die Scheu schneller schwinden, was sich wiederum positiv auf die Interaktion und Kommunikation innerhalb der Gruppe auswirken sollte. Da an der Schule auch Lernförderkinder und Kinder mit einer geistigen Behinderung betreut werden, sind die Schulklassen hinsichtlich des Alters teilweise sehr bunt gemischt. Trotz Larges (2001, S. 86) empfohlenem Altersunterschied von maximal ein bis zwei Jahren wurden vereinzelt auch Gruppendiskussionen mit Kindern bei einem Altersunterschied von bis zu sechs Jahren durchgeführt. Da sich alle Kinder innerhalb einer Klasse auf einem ähnlichen Entwicklungsstand befinden, sollte sich dieser jedoch nicht zum Nachteil entwickeln. An insgesamt sechs Gruppendiskussionen beteiligten sich 48 Kinder und Jugendliche im Alter von sieben bis achtzehn Jahren, die sich wie folgt aufteilen. [Abb. 2], [Abb. 3] Neben dem Alter wurde in Anlehnung an Rath (1987) auch der Grad der Sehschädigung aller Teilnehmer erfasst und in vier Kategorien eingeteilt: –– Mäßige Sehbehinderung: Wer selbst mit Kontaktlinsen oder Brille bzw. bestmöglicher Korrektur auf dem

127


Warm-Up

Die Warm-Up Phase nimmt in Gruppendiskussionen mit Kindern eine elementare Rolle ein. Zum einen dient sie dazu, die Kinder in Ruhe kennenzulernen und generell etwas über ihre Person (Name, Klasse, Alter) und die Art ihrer Sehschädigung zu erfahren. Zum anderen sollen die Kinder erfahren, worum es in der Diskussion geht und dass sie, im Gegensatz zum Schulunterricht, frei und unbefangen ihre Meinung kund tun können.

Abb. 4. Beteiligung nach Grad der Sehschädigung

schlechter sehenden Auge weniger als 30 Prozent Sehkraft besitzt. –– Wesentliche Sehbehinderung: Wer selbst mit Kontaktlinsen oder Brille bzw. bestmöglicher Korrektur auf dem besser sehenden Auge weniger als 30 Prozent Sehkraft besitzt. –– Hochgradige Sehbehinderung: Wer selbst mit Kontaktlinsen oder Brille bzw. bestmöglicher Korrektur auf dem besser sehenden Auge weniger als 5 Prozent Sehkraft besitzt. –– Blind: Wer selbst mit Kontaktlinsen oder Brille bzw. bestmöglicher Korrektur auf dem besser sehenden Auge weniger als 2 Prozent Sehkraft besitzt. 3.2. Durchführung Insbesondere blinde Kinder und Jugendliche legen bei der Begrüßung viel Wert auf Körperkontakt, sie besitzen ein überdurchschnittliches musikalisches Gehör und reagieren meist auch sehr freudig auf Musik. Der Moderator muss seine Wortwahl und Sprechweise nicht verändern. Das Wort „sehen“ stellt beispielsweise überhaupt kein Problem dar.

128

Um das Warm-Up möglichst fröhlich und ungezwungen zu gestalten, wurde mit einer Lockerungsübung begonnen, an der auch die beiwohnenden Lehrkräfte und Moderatoren teilnahmen: es wurde gemeinsam getanzt, gesungen und ungezwungen geplaudert. Medienausstattung und Medienbenutzung / Barrieren und Probleme

In der anschließenden Diskussion wurden die Kinder und Jugendlichen zu ihren Erfahrungen und ihrem aktuellen Nutzungsverhalten bezüglich digitaler Spiele befragt. Es sollte sich ein Eindruck darüber verschafft werden, welche digitalen Spiele die Kinder spielen, wie häufig und warum. Darüber hinaus war es interessant, etwas über die jeweilige Nutzungssituation zu erfahren und Informationen über persönliche Favoriten innerhalb des Spieleangebotes zu erhalten. Neben dem Nutzungsverhalten sollten auch Barrieren und Probleme ermittelt werden, welche – bedingt durch die sensorische Behinderung – beim Spielen digitaler Spiele auftreten können. Mit der Aufforderung: „Versucht mal zu beschreiben, wie das abläuft, wenn ihr digitale Spiele spielt.“ konnte generell etwas über die Spieldurchführung in Erfahrung gebracht werden, so z. B. ob die Kinder schon beim Anschalten der Geräte oder Starten des Spiels auf Barrieren stoßen und Hilfe benötigen. Die Fragen hierzu waren zunächst bewusst sehr allgemein gewählt: „Wie geht ihr vor? Wie macht ihr das? Was braucht ihr denn dafür?“. Auf

diese Weise konnte sichergestellt werden, dass sich die Kinder nicht auf einzelne Barrieren beschränkten und zum freien Erzählen motiviert waren. Erst danach schlossen sich speziellere Fragen an, welche die Kinder konkret auf bestimmte Sachverhalte aufmerksam machten: „Habt ihr das Gefühl, ihr wisst immer was im Spiel zu tun ist? Könnt ihr die Spiele denn so einstellen, dass ihr das besser erkennen könnt?“ Anforderungen und Wünsche

Im dritten Teil der Studie durften sich die Kinder und Jugendlichen im Zuge eines kleinen Rollenspiels in die Position eines Spieleentwicklers versetzen. Die Anwendung dieser Kreativitätstechnik sollte helfen, die Anforderungen an digitale Spiele aus Perspektive der blinden und sehbehinderten Kinder zu identifizieren sowie verborgene und neue Ideen hervorzubringen, ganz unabhängig davon, ob diese umsetzbar sind oder nicht. Um den Perspektivwechsel so anschaulich wie möglich zu gestalten, wurde fantasievoll klingende Musik eingespielt und die jüngeren Kinder bekamen einen Zauberring. Dieser sollte ihnen die Fähigkeit verleihen, ein digitales Spiel ganz nach ihren persönlichen Wünschen und Erwartungen zu entwickeln. Nach circa fünf bis zehn Minuten konnte jedes Kind der Reihe nach sein Traumspiel vorstellen. Für die jugendlichen Teilnehmer wurde das Rollenspiel entsprechend ihrem Alter etwas adaptiert. Anstatt der Ringübergabe gab es die Gruppe der „Träumer“, die eigene Ideen entwickeln konnten und die Gruppe der „Kritiker“, die deren Ideen entsprechend kritisch einschätzen sollten. Im Anschluss an die Bewertung wurden die Rollen getauscht, so dass eine zweite Sichtweise hervorgebracht und neue Impulse für einen offenen Ideenaustausch geschaffen werden konnten. Für die Durchführung war es wichtig, von den Kindern akzeptiert und zu einem Teil der Gruppe zu werden. Legere Kleidung, eine lockere Umgangssprache und Interesse an kindlichen Meinungen und Gefühlen halfen den Kindern sich zu entspannen


Usability Professionals 2012 Zielgruppen im Kontext

und ihre Gedanken mitzuteilen. Diese Begegnung auf Augenhöhe sollte ihnen deutlich machen, dass sie keinen Experten gegenübersitzen sondern eher sie über den Wissensvorsprung verfügen. So bekamen sie immer das Gefühl vermittelt, alles was sie zu diesem Thema wissen, ganz unvoreingenommen erzählen zu dürfen. 3.3. Auswertung und Ergebnisse Medienausstattung und Mediennutzung

Neben dem Treffen mit Freunden, Musik hören und Hobbys wie Reiten, Tanzen und Schwimmen, gehört das Spielen digitaler Spiele zu den beliebtesten Freizeitbeschäftigungen. Fast alle befragten Kinder und Jugendlichen verfügen über einen eigenen Computer. Lediglich 10 Prozent verneinen diese Frage, was eventuell mit der Sehschädigung und den sozialen Verhältnissen begründet werden könnte. Ebenso verfügt die Mehrzahl über ein Nintendo DS, eine Wii, eine Playstation und ein Handy. Nur wenige besitzen eine PSP, einen GameCube, ein Nintendo 3DS oder eine Xbox. Auf dem Computer wird vor allem das Genre der Rennspiele präferiert, welches mit Need for Speed und Mario Kart in erster Linie von den Jungen als Lieblingsgenre angegeben wird. Auch Lernspiele wie Schlaumäuse und Simulationen wie Die Sims sind sehr gefragt. Ähnlich verhält es sich auch mit den Konsolen und Handhelds. Auf der Playstation werden neben Rennspielen Sportspiele und Abenteuer bevorzugt. Auf dem Nintendo DS reicht die Spanne von Rennspielen über Jump’n’Run bis hin zu Simulationen z. B. Nintendogs. Für die Wii ist vor allem Wii Sports sehr beliebt. An dieser Stelle ist hervorzuheben, dass diese Ergebnisse nicht für die befragten blinden Kinder und Jugendlichen gilt, da sie keines der benannten Spiele spielen sondern ausschließlich auf reine Audiogames zugreifen, bevorzugt textbasierte Rollenspiele (MUDs). Zeitvertreib, Spaß und Langeweile sind die häufigsten Nutzungsmotive. Vereinzelt

äußern die Kinder aber auch Wettbewerbsund Herausforderungsaspekte. Ferner wird das Motiv der sozialen Interaktion genannt, etwa um mit der Familie oder Freunden zusammen zu sein. Ein Mädchen geht darauf ein, ihre Emotionen durchs Spielen zu regulieren: „…und auch manchmal, wenn ich spiele und ich voll wütend war, dann beruhige ich mich.“ Barrieren und Probleme

Nur die wenigsten der befragten Kinder und Jugendlichen weisen sofort auf Barrieren hin, die auf ihrer Sehschädigung beruhen. Auf die Frage, welche Probleme während des Spielens auftreten, werden Antworten gegeben, die auch bei Kindern ohne Sehschädigung zu erwarten wären, wie beispielsweise: „Mich stört, wenn das Spiel hängt“. Während der Gruppendiskussionen wurde deutlich, dass die Sehbehinderung von den Kindern nicht als nachteilig wahrgenommen wird. Die Aussage eines hochgradig sehbehinderten Jungen verdeutlicht diesen Aspekt: „Also, mein linkes Auge lasse ich dann immer links liegen. Weil mit dem rechten Auge sehe ich meistens das, was ich auch mit allen beiden Augen sehen würde, weil da sehe ich fast alles.“ Erst auf konkretes Nachfragen geben sie Probleme, insbesondere die Benutzeroberfläche betreffend an: –– Schrift wird oft zu klein oder mit zu wenig Kontrast zum Hintergrund dargestellt. Nur selten gibt es eine Möglichkeit zum individuellen Vergrößern. Insbesondere die Darstellung von Untertiteln wird kritisiert. Neben der Schriftgröße gibt es Probleme mit der Anzeigegeschwindigkeit. Untertitel können weder vergrößert noch gestoppt werden, was sich als sehr frustrierendes Problem herausstellt. –– Auch Bilder und Grafiken werden oft zu klein dargestellt. Wird eine Vergrößerung z. B. in Form einer Lupe angeboten, so geht diese gleichzeitig mit einer Verschlechterung der Auflösung einher. Bilder werden

unscharf oder pixelig, Bildteile einfach abgeschnitten. Eine stufenlose Vergrößerung bei gleichbleibender Qualität wäre das gewünschte Optimum. –– Anstelle der Darstellung von Text und Schrift bevorzugen Kinder die Sprachausgabe und damit die Möglichkeit, vorhandenen Text vorgelesen zu bekommen. Allerdings sollte dieser angehalten oder wiederholt werden können sowie hinsichtlich der Lautstärke innerhalb des Spiels regulierbar sein. –– Als größere Barriere wird die 3D-Darstellung in Spielen angesehen. Einige Kinder bekommen Angstzustände, andere betonen, dass ihnen bereits nach kurzer Zeit die Augen schmerzen. Mitunter kann 3D nicht einmal wahrgenommen werden. –– Ein Spiel sollte stets über eine Anleitung oder im besten Falle über ein Tutorial verfügen. Anleitungen müssen kurz und gut verständlich sein und sollten sowohl als gesprochener als auch geschriebener Text vorliegen. Hinsichtlich der Zugänglichkeit sind sich alle Teilnehmer einig: Alle Geräte sind mühelos für sie zugänglich. Auch für die blinden Kinder und Jugendlichen, die hierbei ausschließlich den Computer nutzen, erfolgt der Zugang problemlos und selbstverständlich. Anforderungen und Wünsche

In Bezug auf das favorisierte Genre der digitalen Spiele sind die Ideen und Vorstellungen der Teilnehmer breit gefächert. Die Mehrzahl der Kinder tendiert zu zivilen Simulationen, die sich mit Tieren und Landwirtschaft beschäftigen und eine Verbindung zum alltäglichen Leben aufweisen. Am zweithäufigsten wünschen sich die Teilnehmer Rennspiele mit den unterschiedlichsten Fahrzeugen (z. B. Eisenbahn, Taxi) und andere favorisieren eher ein Rollenspiel. In den Spielen ist den Kindern die Möglichkeit zur individuellen Gestaltung, vor allem die Charaktererstellung sehr wichtig.

129


Die Bedienung der Spiele muss so einfach wie möglich gehalten sein und sollte nicht zu viele Tasten zur Steuerung beinhalten: Pfeiltasten, Leertaste und Entertaste reichen aus. Taktile Eingabemöglichkeiten stoßen bei einigen Kindern auf Verwunderung. Nachdem sie auf diese Variante hingewiesen werden, antworten sie einvernehmlich: „Das geht nicht.“ Andere schließen allerdings nicht aus, dass es grundsätzlich möglich ist, durch Fühlen ein Spiel zu steuern. Sowohl die sehbehinderten als auch einige der blinden Teilnehmer glauben an die Möglichkeit, dass digitale Spiele auch für Blinde zugänglich gemacht werden könnten. In diesem Zusammenhang gehen sie speziell auf die Möglichkeit der Sprachsteuerung bzw. Sprachausgabe ein. Eine Möglichkeit, die vor allem in Rennspiele integriert werden könnte, indem ein abschaltbarer Co-Pilot den Streckenverlauf ankündigt. Für die Sprachausgabe wünschen sich die jüngeren Kinder eine weibliche Stimme. In Hinblick auf Konsolen und Handhelds fordern die meisten Teilnehmer eine Vergrößerungsfunktion. An die Darstellung der Grafiken haben sie eher geringe Anforderungen, da diese vermutlich nicht mit allen Details und in vollem Umfang wahrgenommen werden können. Neben einer möglichen Helligkeitsanpassung sollten auch die Kontraste im Spiel stärker eingestellt werden können. Die Jugendlichen würden die Farben zur besseren Kontrastierung zudem gerne selbst auswählen.

Diese Aussagen sind jedoch kritisch zu betrachten. Bis auf wenige Ausnahmen haben die Kinder ihre Sehbehinderung von Geburt an, sind mit dieser aufgewachsen und haben ihre ganz eigene Wahrnehmung der Umwelt. Auftretende Probleme, die für Menschen ohne Sehbehinderung gravierende Nachteile darstellen würden, werden als selbstverständlich angesehen. Es kann außerdem festgehalten werden, dass sehbehinderte Kinder und Jugendliche durchaus dieselben Spiele spielen, wie Kinder und Jugendliche ohne Sehbehinderung. Theoretisch bedarf es nur einzelner Zusatzfunktionen wie der Möglichkeit zum Vergrößern. Um die tatsächlichen Barrieren und Probleme besser beurteilen zu können, muss nun im zweiten Schritt ein umfassender Test durchgeführt werden, bei dem die Kinder in ihrer Interaktion beobachtet werden können.

130

of ICCHP International 2002 Conference on Computers Helping People with Special Needs. Linz, Austria. S. 173-180. 5. DBSV (2011): Zahlen und Fakten. Online verfügbar unter: http://www.dbsv.org/ infothek/zahlen-und-fakten, zuletzt geprüft am 06.06.2012. qualitative Studie zur Mediennutzung und Medienbewertung von blinden Menschen in Deutschland. Münster: Lit (4). 7. Large, A. (2001): Focus Groups with Children: Do they Work? In: The Canadian journal of information and library science. Band 26, S. 2-3. 8. Liebal, J. & Exner, M. (2011): Usability für Kids. Ein Handbuch zur ergonomischen Gestaltung von Software und Websites für Kinder. Wiesbaden: Vieweg+Teubner Verlag / Springer Fachmedien. 9. Rath, W. (1987): Sehbehindertenpädagogik.

Für blinde Kinder und Jugendliche bedarf es dagegen grundlegender Basisuntersuchungen, um ermitteln zu können, wie digitale Spiele konzipiert werden müssten, um auch sie als Nutzer mit einzubeziehen.

Stuttgart. 10. Schäffer, B. (2005): Gruppendiskussion. In: Mikos, L.; Wegener, C. (Hrsg.): Qualitative Medienforschung. Ein Handbuch. Konstanz. S. 304-314. 11. Special Effect (2011): Wish List for Accessible

So dienen die gewonnenen Ergebnisse maßgeblich einer ersten Anforderungsanalyse auf dem Weg zum inklusiven Game Design.

Game Design. Online verfügbar unter: http:// www.gamebase.info/magazine/read/wish-listfor-accessible-game-design_531.html, zuletzt geprüft am 04.06.2012. 12. Statistisches Bundesamt (2011): Statistisches

Literatur

Jahrbuch. Online verfügbar unter: https://

1. Archambault, D., Ossmann, R., Gaudy,

www.destatis.de/DE/Publikationen/

T. & Miesenberger, K. (2007): Computer

StatistischesJahrbuch/Sozialleistungen.

Games and Visually Impaired People. In:

pdf?__blob=publicationFile, zuletzt geprüft

The European Journal for the Informatics 2. Beyer, F. (2009): Statistische Angaben zu Blindheit, Sehbehinderung und Punktschriftnutzung. Online verfügbar unter:

Die Mehrzahl der beteiligten Kinder und Jugendlichen fühlt sich grundsätzlich nicht benachteiligt, gibt sogar an, alles auf dem Bildschirm erkennen zu können und keinerlei Probleme beim Spielen zu haben. Die vermuteten Barrieren nehmen die sehbehinderten Kinder kaum als solche wahr. Sie akzeptieren ihre Sehbehinderung und empfinden sie nur selten als Nachteil.

K., Klaus, J. & Zagler, W. (Hrsg.): Proceedings

6. Huber, N. (2004): Ohne Bilder im Bilde. Eine

Professional, 8 (2), S. 43-63.

4. Fazit und Ausblick

visually impaired children. In: Miesenberger,

http://www.blindenmuseum-berlin.de/ uploads/media/statistik-erlaeuterungen.pdf, zuletzt geprüft am 11.06.2012. 3. Bortz, J., Döring, N. (2006): Forschungsmethoden und Evaluation für Human- und Sozialwissenschaftler. 4. Auflage. Heidelberg. 4. Buaud, A., Svensson, H., Archambault, D. & Burger, D. (2002): Multimedia games for

am 10.06.2012. 13. Walthes, R. (2005): Einführung in die Blindenund Sehbehindertenpädagogik. München.


Usability Professionals 2012 Zielgruppen im Kontext

131


Milieubeschreibungen als Meta-Personas Eine neue Ebene der User Experience Evaluation?

Malte Krökel User Interface Design GmbH Claudius-Keller-Straße 3c 81669 München malte.kroekel@uid.com

Tobias Limbach User Interface Design GmbH Claudius-Keller-Straße 3c 81669 München tobias.limbach@uid.com

Abstract Sinus-Milieus gruppieren die Menschen innerhalb einer Gesellschaft anhand ihrer sozialen Lage und ihrer grundsätzlichen Lebensauffassung. Sie entstammen der Marktforschung, sind dort weithin anerkannt und werden laufend validiert. Im Februar 2012 wurden den Milieus erstmals typische Verhaltensmuster und Präferenzen bei der Internetnutzung zugeordnet. Für die UX-Evaluation ist dies eine interessante Erweiterung, da Grundbedürfnisse und Anforderungen von unterscheidbaren Nutzergruppen in den Kontext ihres sozialen und psychografischen Milieus gesetzt werden. Die Sinus-Milieus fungieren so als eine Form validierter „Meta-Persona“. Diese erlaubt eine summative UX-Evaluation über die Grenzen von Produktkategorien hinaus, wenn sie mit Motivatoren (Be-Goals) der User Experience verbunden wird. Nutzen entsteht auch für eine milieugenaue Anforderungserhebung sowie für die Rekrutierung von geeigneten Nutzern zur UX-Evaluation – hauptsächlich für den Consumer-Sektor.

1. Einleitung Personas sind eine etablierte Methodik, um spezifische Vertreter von Nutzergruppen prototypisch zu beschreiben (z. B. Beck, 2004). Diese prototypischen Beschreibungen vermitteln unter anderem demografische und biografische Informationen, Bedürfnisse, Präferenzen, Anforderungen sowie Beschreibungen, wie diese Person das Zielsystem nutzen würde. Solche Beschreibungen haben grundsätzlich auch für die vergleichende Evaluation der User Experience (UX) von Produkten ihre Reize: Wie würde eine reale Person mit den Eigenschaften dieser Persona die UX von zwei Restaurant-Websites im Vergleich bewerten? Wie würde dieselbe Person ein komplett anderes Produkt erleben, z. B. einen Online-Shop? Wenn wir wüssten, dass Personas so hinreichend präzise und umfassend beschrieben wären, dass sie ganze Nutzergruppen unterscheidbar und zutreffend wiedergeben, könnte man dann nicht auch präzise Rekrutierungsprofile für neue Studien ableiten?1

132

Da die Beschreibungen von Personas meist von der Beobachtung und Befragung kleiner Stichproben ausgehen, ist dies aber nicht möglich. Sie entstehen fast immer vor dem Hintergrund der Nutzung eines bestimmten Produkts oder einer Produktgruppe, ohne dass sie den Anspruch auf eine Übertragbarkeit erheben. Ist ein Produkt ausgerollt, lassen sich die erarbeiteten Personas daher meist nicht mehr (direkt) auf andere Produkte oder gar ganz andere Produktkategorien anwenden. Im Webconsumer-Segment ist darüber hinaus davon auszugehen, dass sich die Bedürfnisse und Anforderungen der Zielgruppen über die Zeit verändern. Somit müssten die Personas den Veränderungen angepasst werden, falls sie über die Zeit für vergleichende UX-Evaluationen „konserviert“ werden sollen. Eine solche Normierung ist aber nicht möglich, wenn die Personas nicht aufwändig aufgrund einer soliden Datenbasis aus großen Stichproben erstellt wurden. Auch müssen Personas häufig dem Kunden gegenüber „vermarktbar“ sein, dass heißt sie geben nicht selten eher die Wünsche

Henning Brau User Interface Design GmbH Claudius-Keller-Straße 3c 81669 München henning.brau@uid.com

Keywords: /// Sinus-Milieus /// Persona /// Be-Goals /// UX-Evaluation

des Herstellers als die Realität wieder. So sind Berufe wie Journalist, Lehrer und Webdesigner auffallend häufig in Personas zu finden, sehr selten aber sogenannte „HartzIV-Familien“ aus sozialen Brennpunkten mit geringer Qualifikation – obwohl diese eine relevante und große Konsumentengruppe für viele Online-Shops darstellen. Auch subjektive Projektionen und somit Übertragungsphänomene der UX Professionals, welche die Personas erstellen, sind nicht auszuschließen. Für die von uns oben genannten Zwecke bräuchte es aber eine objektive Datenbasis. Zusammengefasst fehlt es dafür an einer validen, objektiven und reliablen Datenbasis mit direktem Bezug zur UX, die in fixen Intervallen normiert wird, um „Meta-Personas“ zu erstellen, die a) Basis einer zielgruppengerechten Rekrutierung sein können, b) einen Vergleich von UX-Studienergebnissen mit vergangenen Studien zu ähnlichen Produkten ermöglichen beziehungsweise c) Aussagen über Präferenzen bezüglich der UX unterschiedlicher Produktkategorien erlauben.


Usability Professionals 2012 Zielgruppen im Kontext

Abb. 1. Die Sinus-Milieus in Deutschland 2012 (Sinus, 2012b)

Abb. 2. Internet-Milieus (DIVSI, 2012)

Eine Datenbasis, die diese Anforderungen möglicherweise erfüllt, wären die 2012 veröffentlichten Sinus-Milieus zur Internetnutzung, wenn diese mit Prädiktoren von UX verbunden werden könnten.

national ab und eignen sich damit auch zur interkulturellen Bewertung von Produkten. Sie werden laufend mit großen repräsentativen Stichproben erhoben, validiert und veröffentlicht (Sinus, 2012a).

2. Sinus-Milieus

3. Sinus-Milieus und Internetnutzung

Die wissenschaftliche Hintergrundidee der Sinus-Milieus (Sinus, 2012a) sind die „Sozialen Milieus“ des französischen Soziologen Émile Durkheim (z. B. Durkheim, 1992). Soziale Milieus beschreiben soziale Bedingungen wie Werte, Normen, Gesetze aber auch wirtschaftliche und politische Faktoren, die den Einzelnen umgeben und ihn prägen. „Sie fassen (…) soziale Gruppen, also Menschen zusammen, deren Wertorientierungen, Lebensauffassungen und Lebensweisen ähnlich sind.“ (Ueltzhöfer, 1999, S. 629ff.). Dieses Modell hat sich unter der Bezeichnung „Sinus-Milieus“ in der Markt-, Media-, Kommunikations- und Sozialforschung etabliert. Bei der Beschreibung der Sinus-Milieus geht die grundlegende Wertorientierung ebenso in die Analyse ein, wie Alltagseinstellungen zur Arbeit, Familie, Freizeit, zu Geld und Konsum. Abbildung 1 gibt die Sinus-Milieus aus dem Jahr 2012 für Deutschland wieder. [Abb. 1]

Um dem wachsenden Einfluss des Internets auf die Gesellschaft und somit den Konsumenten gerecht zu werden, veröffentlichte das Sinus-Institut im Auftrag des Deutschen Instituts für Vertrauen und Sicherheit im Internet (DIVSI, 2012) im Frühjahr 2012 eine neue Ausrichtung von Sinus-Milieus. Während sich die bisherige Milieu-Studie mit der Auffassung der Lebensverhältnisse auseinandersetzte, stand jetzt die Internetnutzung im Fokus. Die Studie zeigt die verschiedenen Verhaltensmuster und Internet-Präferenzen der Milieus auf und unterscheidet dabei drei Hauptgruppen: Digital Natives, Digital Immigrants und Digital Outsiders (vgl. Punkt 3.2). [Abb. 2]

Zwischen den unterschiedlichen Milieus gibt es Berührungspunkte und Übergänge. Die Sinus-Milieus werden heute häufig verwendet, um Produkte zielgerichtet auf dem Markt zu platzieren. Sie weichen

3.1. Be-Goals als Motivatoren der User Experience Um die Sinus-Milieus im Internet für unsere oben genannten Ziele nutzbar zu machen, müssen sie mit Prädiktoren für die UX verbunden werden. Im UX-Modell von Hassenzahl (Hassenzahl, 2008, 2010) wird zwischen Be-Goals, Do-Goals und

Motor-Goals unterschieden. Be-Goals stellen die Grundlage der Valenzmethode zur Messung von UX dar (z. B. Burmester et al., 2010). Sie beziehen sich auf das Selbst einer Person und haben existenzielle Bedeutung für diese. Aus den Be-Goals werden Do-Goals (das Handeln einer Person zum Erreichen des Bedürfnisses) abgeleitet, die wiederum zu Motor-Goals führen. Letztere sind das zielgerichtete motorische Handeln einer Person und die Umsetzung zum Erreichen des Bedürfnisses. Be-Goals werden aus grundlegenden menschlichen Bedürfnissen abgeleitet. Sheldon et al. (2001) nennen 10 Grundmotive. Diese sind: 1. Selbstwert, 2. Autonomie, 3. Kompetenz, 4. Verbundenheit, 5. Freude und Stimulation, 6. Gesundheit und Fitness, 7. Selbstverwirklichung und bedeutsam sein, 8. Sicherheit, 9. Popularität und Einfluss sowie 10. Bedürfnis nach Geld und Luxus. Aus diesen Grundmotiven heraus werden wie ausgeführt Be-Goals gebildet. Diese definieren, was oder wie eine Person eigentlich sein möchte: „Hat eine Person keinen Zugang zu ihr wichtigen Menschen beispielsweise durch räumliche Trennung, dann stellt sich durch Frustration des Bedürfnisses Verbundenheit ein Gefühl der

133


Einsamkeit ein. Daraus entsteht das Ziel einer wichtigen Person nahe zu sein.“ (Burmester et al., 2010, S. 207). Die Be-Goals stellen – vereinfacht gesagt – also basale Wünsche, Vorstellungen und Sehnsüchte des Menschen dar – auch bei der Internetnutzung. Eine hinreichende bis hohe Erfüllung der Be-Goals eines Menschen während der Nutzungssituation verschafft ihm positives Empfinden und Nutzungserleben. Frustration von Grundbedürfnissen während der Nutzungssituation führt hingegen zu negativen Gefühlen. Das Nutzungserleben ist mithin ein evaluatives Gefühl, das sich bei Erfüllung, beziehungsweise Frustration von Grundbedürfnissen einstellt (Hassenzahl, 2008). Zwar haben Situation und Zeitpunkt einen starken Einfluss auf die jeweils aktiven Grundmotive einer Person, doch es lassen sich interpersonelle Muster erkennen. Für den Einen ist Popularität grundsätzlich maßgeblicher als Selbstverwirklichung. Andere streben stärker nach Autonomie als nach Verbundenheit. Die Dominanz verschiedener Grundmotive sind auch auf die soziale Umgebung zurückzuführen (Sheldon et al., 2001). Menschen, die aus denselben Sinus- Milieus stammen, vereinen grundlegende soziale Hintergründe, Werthaltungen, Lebensweisen und Einstellungen. Mithin ist anzunehmen, dass Mitglieder eines Sinus-Milieus tendenziell auch die gleichen dominanten Be-Goals aufweisen. Neben diesen der Literatur entstammenden Überlegungen konnte in explorativen Betrachtungen von UX Evaluationsstudien mit kleinen Stichproben bei UID Hinweise darauf gesammelt werden, dass unterschiedliche Sinus-Milieus die angenommenen Unterschiede in der Dominanz von Be-Goals aufweisen. 3.2. Sinus-Milieus als Meta-Personas Unabhängig von der Erstellung fallbezogener Persona, die keine produktübergreifende Beständigkeit haben, für ein spezifisches Produkt aber relevant sind, lassen sich die auf die Internetnutzung bezogenen Ausprägungen der Sinus-Milieus auf verschiedenste Webprodukte anwenden. Damit entsteht eine Vergleichbarkeit,

134

die auch eine summative UX-Evaluation erlaubt – es entstehen quasi übergeordnete „Meta-Personas“. Nachfolgend werden die Sinus-Milieus (vgl. Abbildung 2) inhaltlich dargestellt und mit Be-Goals verknüpft, die nach den explorativen Betrachtungen bei UID wahrscheinlich für Vertreter dieser Milieus als maßgebliche Motivatoren erscheinen. 3.2.1. Digital Natives Die Digital Natives sind bereits früh mit dem Internet in Berührung gekommen. Sie sind selbstbewusste Internetnutzer, die sich in drei Gruppen unterteilen lassen (DIVSI, 2012). Die erste Gruppe, die Digital Souveränen („Souveräne“), verstehen sich als digitale Avantgarde des Internets mit individualistischer Grundhaltung und Selbstanspruch, das Internet auf der Suche nach Autonomie in Denken und Handeln in seinen unbeschränkten Möglichkeiten weiterzuentwickeln und zu verändern. IT-Wissen erlernt dieses Milieu intuitiv im kreativ spielerischen Umgang. Sie haben dabei keine Berührungsängste und viel Selbstvertrauen. Sie distanzieren sich vom bürgerlichen Mainstream, der ihrer Meinung nach zu eingeschränkten Routinen führt. Für sie stellt die digitale Welt einen neuen wesentlichen Teil des Lebens dar. Sie sind „always on“ und ein Leben ohne Internet können sie sich nicht vorstellen. Allerdings vernachlässigen sie dabei ihre realen Kontakte nicht, da zu den Bedürfnissen der Souveränen auch die Nähe und das Zusammensein mit anderen gehört und sie es schätzen, voneinander zu profitieren und mit Spaß und Spannung gemeinsam Neues zu entdecken. Sie sind dabei offen für die Chance des Lebens und entwickeln großen Enthusiasmus. Ebenso wie die Souveränen verfügen die Effizienzorientierten Performer („Performer“) über ein hoch entwickeltes IT- und Internetwissen und Equipment auf dem neusten Stand. Die Technik nutzen sie dabei als Erleichterung und Beschleunigung, sowohl zur Kommunikation als auch zur Unterhaltung, aber in erster Linie für berufliche Zwecke. Dabei sind in

ihrem Alltag alle Arbeitsprozesse mit dem Internet verknüpf und man besitzt den Anspruch jeder Zeit von Überall auf das Internet zugreifen zu können. Multitasking ist Selbstverständlichkeit geworden, da man konzentriert arbeitet und während Meetings nebenbei die E-Mails bearbeitet. So verfolgen sie neuste Trends, um frühzeitig davon zu profitieren und sich auf einem hohen Mobilitätsniveau zu bewegen. „Man verbindet Zielstrebigkeit und Leistung mit dem Genussvollen Erleben von Neuem in einem möglichst selbstbestimmten Leben, in dem technische Modernität und Fortschrittsoptimismus selbstverständlich ist“ (DIVSI, 2012, S.81). Die dritte Gruppe der Digital Natives, die Unbekümmerten Hedonisten („Hedonisten“), verfügen über mittlere InternetKompetenz und Erfahrung. Trotzdem haben sie keine Berührungsängste mit dem Medium. Sie sind im Internet auf der Suche nach Ablenkung, Unterhaltung und Bestätigung als Gegensatz zu dem als tendenziell unspektakulär empfundenen Alltag. Das Internet gilt dabei als unkomplizierter Weg, schnell an Unterhaltungsangebote aller Art zu gelangen. Zudem ermöglicht es den Nutzern grenzenlosen Freiraum und Kommunikation mit Gleichgesinnten. Dieses Milieu gehört bei technologischen Neuheiten nicht zu den Entdeckern, sondern richtet sich nach den beiden Multiplikator-Milieus Performer und Souveräne. Dabei sind sie trotzdem neugierig und experimentierfreudig. Sie probieren neue Angebote überdurchschnittlich oft aus und sind dabei über Aktivitäten der Freunde in Social Network bestens informiert. Sie präsentieren proaktiv die Höhepunkte ihres Lebens, um zum Beispiel zu provozieren und Beachtung zu finden. Beim Surfen folgen sie anscheinend spontanen Impulsen und lassen sich oft stundenlang treiben. Dabei zeigt sich auch ein überwiegend spontanes Einkaufsverhalten. Alle drei Gruppen der Digital Natives weisen einen starken Drang nach Freiheit auf. Unabhängig von der Kompetenz wollen sie schnell und unkompliziert ans Ziel. Durch die geringe Berührungsangst mit dem Medium wird viel ausprobiert und Neues erlernt.


Usability Professionals 2012 Zielgruppen im Kontext

Be-Goals wie Selbstwert, Stimulation, Popularität und Verbundenheit stehen für die Hedonisten im Vordergrund. Die Souveränen streben mehr nach Autonomie, Kompetenz und Selbstverwirklichung. Dies gilt auch für die Performer, die aber darüber hinaus auch nach Geld und Luxus streben. 3.3.2. Digital Immigrants Die Digital Immigrants sind eher zurückhaltend im Netz. Für sie ist das Internet nur ein Mittel zum Zweck. Social Network ist für sie kein Fremdwort, aber im Familienleben unerwünscht. Auch hier gibt es Unterkategorien: So sind die Postmateriellen Skeptiker („Skeptiker“) eher zielorientierte Internetnutzer mit distanzierter, kulturkritischer Einstellung gegenüber Konsum und TechnikFaszination. Sie haben eine ambivalente Beziehung zum Internet. Einerseits schätzen sie die Kommunikations- und Informationsvorteile, andererseits möchten sie sich nicht von der Technik vereinnahmen lassen und selbst die Kontrolle bewahren. Zudem nutzen sie das Medium nur sehr selektiv zum Wissens-, Ideen- und interkulturellenAustausch. Dennoch zeigt sich insgesamt eine leicht überdurchschnittliche Nutzung des Internets gegenüber anderen Milieus. Aufgrund ihres Misstrauenszeigen sie ein auffälliges Interesse an nichtkommerziellen Institutionen und Quellen, die Transparenz verkörpern. Diese konventionelle Haltung bestätigt sich auch dadurch, dass sie haptische Artefakte wie das „gute alte Buch“ schätzen. Das zweite Milieu innerhalb der Digital Immigrants sind die Verantwortungsbedachten Etablierten („Etablierte“). Auch sie sind eher selektive Internetnutzer. Sie zeichnen sich durch eine verantwortungsorientierte Grundhaltung gegenüber dem digitalen Fortschritt aus. Technik besitzt für sie keine Faszination. Im Internet zeigen sie ein sehr aktives Verhalten, schützen ihre Daten und sind dabei äußerst restriktiv. Das Internet wird als Arbeits- und Kommunikationsmedium genutzt und weniger zur Unterhaltung. Sie legen Wert auf gepflegte Sprache und

höfliche Umgangsformen, die ihnen im Internet schwindend erscheinen. Allerdings ist ihnen Offenheit und Toleranz und „lebenslanges Lernen“ wichtig. Daher wollen sie sich neuen Technologien nicht verschließen, sondern intellektuell mithalten oder sogar Meinungsführer sein. Für dieses Milieu ist ein leichter Einstieg und durchschaubare Komplexität sowie Transparenz von Bedeutung. Hier sind in der Regel die finanziellen Mittel und die Lernfähigkeit vorhanden, neue Technik zu beschaffen und zu verwenden. In dem Milieu der Skeptiker ist der Wunsch nach Sicherheit, Kompetenz und Freude und Stimulation stark vorhanden. Für die Etablierten hingegen sind Autonomie, das Bedürfnis, Bedeutsam zu sein, sowie das Bedürfnis nach Geld und Luxus von Bedeutung. Weniger stark vertreten sind die Be-Goals Einfluss, Selbstwert sowie Popularität und Einfluss. 3.3.3. Digital Outsiders Die Digital Outsiders streben nach Harmonie in der Familie und fühlen sich hilflos in der unüberschaubaren digitalen Welt. Für sie ist es oft unverständlich, was die Enkel im Internet treiben und wie die „Post“ in Sekunden um die Welt gehen kann. Sie sind meist überfordert mit den neuen Technologien, der Komplexität und Informationsfülle. Besonders die Internetfernen Verunsicherten („Internetferne“) sind nur Gelegenheitsnutzer oder auch erklärte Offliner. Dieses Milieu versucht dem neuen Medium aus dem Weg zu gehen und ist bei der Nutzung auf die Hilfe Fremder angewiesen. Sie sind nicht selten bereits im Ruhestand und schätzen den direkten Kontakt zur Familie und den Freunden. Veränderungen verunsichern und erscheinen demnach unangenehm. Zusätzlich fehlt allgemein die Neugier, sich Neues zu erschließen. Sie sind eher auf der Suche nach Schutz, Harmonie und Geborgenheit, als nach Erfolg und dem Unbekannten. Sie haben (gefühlt) alles Notwendige erreicht und entwickeln sich nicht mehr explorativ. Im Internet sind sie zudem sehr ängstlich und misstrauisch unterwegs.

Ebenso die letzte Gruppe der Ordnungsfordernden Internet-Laien („InternetLaien“). Sie besitzen die gleichen Bedürfnisse und Ängste wie die Internetfernen. Auch bei ihnen spielt das Internet keine große Rolle. Sie nutzen das Internet allerdings in der Regel mehrmals wöchentlich. Sie wollen (noch) mithalten können, haben dabei aber immer wieder Schwierigkeiten, denen die Internet-Laien mit geringer Internetkompetenz nicht gewachsen sind. Die Internetnutzung dient nur noch dem Praktischen und erfreut kaum. Zielloses Herumsurfen wird vermieden, aus Angst Fehler zu verursachen und dafür strafrechtlich Verantwortung übernehmen zu müssen. Wenn dann zufällig etwas Neues, für Digital Natives Gewöhnliches, entdeckt wird, zeigen die Ordnungsfordernden Stolz und durchaus auch den Mut, sich weiter mit dem Medium auseinander setzen zu wollen. Dem Milieu der Internetfernen sind besonders die Be-Goals Schutz und Sicherheit, Gesundheit und Fitness sowie Verbundenheit bedeutsam. Nicht nur den Internetfernen, sondern auch den Internet-Laien ist die Bestätigung ihres Handelns und eine lenkende Führung durch das World Wide Web wichtig. Für sie sind auch die BeGoals Schutz und Sicherheit, Gesundheit und Fitness sowie Verbundenheit wesentlich. Darüber hinaus allerdings auch das Bedürfnis nach Geld und Luxus. Um die Zusammenhänge und Unterschiede zu verdeutlichen, gibt Abbildung 3 die sieben Milieus wieder. Sie enthält auch die maßgeblichen Be-Goals, die sich aus der Literatur sowie aus den explorativen Betrachtungen bei UID für die einzelnen Milieus ergeben. [Abb. 3] Nachfolgend erläutern wir exemplarisch, wie sich die unterschiedliche Verteilung der maßgeblichen Be-Goals auf das Nutzungserleben auswirken kann. Es sei noch einmal hervorgehoben, dass sich die Ausführung bislang auf explorativ gewonnene Daten bezieht. Dem Milieu der Hedonisten beispielsweise sind die Be-Goals „Stimulation“ und „Selbstwert“ als maßgeblich zuzuordnen. Dies schlägt sich in einem ausgeprägtem

135


Kommunikationsverhalten in Social Networks als fester Bestandteil ihres Alltags nieder. Dabei geben sie in der Regel verhältnismäßig unkritisch persönliche Daten preis und sind eher affin für Werbeeinflüsse. Entsprechend sind Produkte, die für diese Gruppe eine positive UX erzeugen, eher persönlichkeitsnah und überbordend. Das Gefühl, immer Neues entdecken zu können, sowie die Möglichkeit, sich im Internet mitzuteilen, sind besonders für diese Gruppe von Bedeutung. Die Be-Goals „Sicherheit“ sowie „Gesundheit“ und „Bedürfnis nach Geld/Luxus“ sind im Milieu der Internet-Laien prägend. So ist anzunehmen, dass diese Gruppe ein schrittweises Vorgehen in einer klaren MenüFührung mit Transparenz und relativ vielen Bestätigungen präferiert, um Sicherheit und das Gefühl der Gefahrenabwendung für Leib und Besitz zu erleben. Dabei sollte jeder Schritt nachvollziehbar und erkennbar sein. Zudem sollte ein eher reduziertes, übersichtliches und geschlossenes Design eine positive UX begünstigen. Wenige Farben sollten bewusst eingesetzt werden, um auf das wesentliche zu lenken. Werbungen sollten nur dezent angebracht werden und eher zufällig und nicht auf die Person fokussiert wirken. Videos oder automatisch bewegte Interaktion werden eher abgelehnt als in anderen Milieus. 4. Fazit Es wurden die Sinus-Milieus der Internetnutzer vorgestellt und Möglichkeiten erörtert, diese mit Be-Goals zu verknüpfen. Auf diese Weise könnten Meta-Personas mit Bezug zur UX geschaffen werden. Diese

Meta-Personas beziehen sich auf eine Datenbasis, die anhand großer Stichproben unabhängig quantitativ abgesichert und fortlaufend normiert wird. Auf diese Weise sollen Benefits in der komparativen UX-Evaluation erzeugt werden. Mithilfe der milieugenauen Rekrutierung über Befragung zum Nutzungsverhalten im Internet soll beispielsweise ein zielgruppengerechtes User Experience Testing ermöglicht werden. Aktuelle Studienergebnisse könnten für einzelne Milieus mit den Ergebnissen von vergleichbaren Studien abgeglichen und somit ein valides Benchmarking durchgeführt werden. Auch Aussagen über grundsätzliche Nutzungsweisen bezüglich neuer Produkte oder Produktgruppen ließen sich nach Milieus getrennt ableiten.

beziehungsweise clusteranalytischen Auswertungen. Diese sind gegebenenfalls über große Stichproben in Online-Panels realisierbar.

Bislang sind diese Überlegungen noch nicht empirisch untermauert. Da die zugrundeliegenden Konstrukte „Sinus Milieu“ sowie „Be-Goals“ aber wissenschaftlich fundiert und validiert sind, ist davon auszugehen, dass ihre Verknüpfung zumindest grundsätzlich zulässig ist. Explorative Betrachtungen kleiner Stichproben im Rahmen von UX-Evaluationen bei UID weisen zusätzlich darauf hin. Sie können aber noch nicht als Beleg für die Anwendbarkeit dienen.

4. Durkheim, E. (1992): Über soziale

Literatur 1. Beck, A. (2002): Personas in der Softwareentwicklung, in: M. Hassenzahl & M. Peissner (Hrsg.). Usability Professionals 2004. 2. Burmester, M., Jäger, K., Mast, M., Peissner, M. & Sproll, S. (2010): Design verstehen – Formative Evaluation der User Experience, in: Brau, H., Diefenbach S., Göring K., Peissner M., Petrovic K. (Hrsg.). Usability Professionals 2010. 3. DIVSI (2012) : DIVSI Milieu-Studie zu Vertrauen und Sicherheit im Internet . Deutsches Institut für Vertrauen und Sicherheit im Internet (DIVSI). Arbeitsteilung. Luchterhand Literaturverlag, Frankfurt/M. 5. Hassenzahl, M. (2008): User Experience (UX): Towards an experiential perspective on product quality, in: Proceedings of IHM’08, 2-5 Sept. 2008, Metz, France, 11-15. 6. Hassenzahl, M. (2010): Experience Design – Technology for all the right reasons. Morgan & Claypool Publ. 7. Reiss, S. (2000): Who am I? Berkley Books. 8. Sheldon, K.M., Elliot, A.J., Kim, Y & Kasser, T. (2001): What is satisfying about satisfying

Daher wird es Studien zur quantitativen Untermauerung geben müssen, um die tatsächlichen Zusammenhänge zwischen Sinus-Milieus und Be-Goals zu untermauern und damit verlässlich anwendbar zu machen. Bei UID werden diesbezüglich Ansätze erarbeitet, wie dies realisiert werden könnte. Aus heutiger Sicht spricht viel für eine quantitative Hypothesenprüfung auf Basis von multifaktoriellen

events? Testing 10 candidate psychological needs, in: Journal of Personality and Social Psychology 80[2], 325-339. 9. Sinus (2012a): [https://www.sinus-intitut.de] 10. Sinus (2012b): Die Sinus-Milieus in Deutschland. [http://www.sinus-akademie. de/typo3temp/pics/Postkarte_SinusMilieusneu_75e6dc253d.jpg] 11. Ueltzhöffer, J. (1999): Europa auf dem Weg in die Postmoderne. Transnationale soziale Milieus und gesellschaftliche Spannungslinien in der Europäischen Union, in: W. Merkel/A. Busch (Hrsg.), Demokratie in Ost und West, Frankfurt/M. 12. Ueltzhöffer, J. & Flaig, B. (1980): Lebensweltanalyse: Explorationen zum Alltagsbewußtsein und Alltagshandeln, masch. Heidelberg, München, Sinus.

Wohlgemerkt, dies sind keine Ziele der

1

Persona-Methodik. Dies ist also keine Kritik an der Methode, sondern ein weiterführendes Abb. 3. Die Sinus-Milieus ihren jeweiligen maßgeblichen Be-Goals zugeordnet.

136

Gedankenspiel.


Arbeitskreise German UPA

137


User-eXperience (UX) meets Return-on-Investment (RoI) Papier zur UP12 aus dem GUPA Arbeitskreis RoI-UX: Status, Vision & Outlook Dr. Boris Oliver Kneisel Karlsruher Institut für Technologie (KIT) – Institut für Entrepreneurship, Technologie- Management und Innovation (EnTechnon) Campus Süd, Geb. 01.85 Fritz-Erler-Str. 1-3 76131 Karlsruhe Boris.Kneisel@kit.edu

Katharina Göring Blumenstrasse 22 04105 Leipzig Katharina-goering@web.de Oliver Siegmund Agentur Siegmund GmbH Leuschnerstr. 3 70174 Stuttgart Tel.: 0711-70 70 91-0 Zeit auf den Markt gekommen sind, o.siegmund@agentur-siegmund.de

Christine Krämer Abstract Fürstenbergerstr. 145 Viele der Interaktionsgeräte, die in jüngster 60322 Frankfurt/Main Christine.Kraemer@hh.de gesten- und touchbasiert. Diese auf neuen Technologien

sind basierenden Interaktionsformen werden häufig auch als natürliche Interaktion bezeichnet. Maus und Tastatur haben als Eingabegeräte Konkurrenz bekommen. Als prominente Vorreiter sind hier die Abstract aktuellen Smartphones sowie Microsoft Surface zu nennen. Damit hat sich auch der GeDie UX-Branche befindet sich aktuell in einem Reifeprozess. User eXperience (UX) Services staltungsraum für Interaktionsdesigner erweitert. Die Konzeption von Steuerungsgesten verändern sich hin zu einer industrialisierbaren Standarddienstleistung. Dies hat Auswirkommt als neue Dimension hinzu. Den damit verbundenen Herausforderungen widmet kungen auf das Berufsbild des UX-Professionals, da sich die Branchenteilnehmer zunehsich unser Tutorial. Wir zeigen die Bandbreite neuer Interaktionsmöglichkeiten auf und mendem Kommoditisierungsdruck ausgesetzt sehen. Um dem herrschenden Wandel zu probieren gemeinsam mit den Teilnehmern eine Methode zur Gestaltung von gestenbegegnen hat die GUPA 2011 den Arbeitskreis „Business Case Usability / RoI-UX“ gegrünund touchbasierter Interaktion aus. det. Der Arbeitskreis stellt sich und den aktuellen Arbeitsstand auf der UP12 vor.

1. Historie des GUPA Arbeitskreises RoI-UX Anlässlich der UP11 diskutierten UX Professionals 2011 in Chemnitz intensiv über Professionalisierungsaspekte der Usability-Branche. Themenfokus war u. a. Etablierung einer unabhängigen Zertifizierung basierend auf Skillprofilen einschlägiger Branchen-fachbeiträge (Bogner et al., 2010). Die UP11-Diskussion spiegelt einen UX-Professionalisierungstrend wider, der mit aktuellen Branchenreports (Diefenbach & Ullrich, 2011) in Einklang steht und sich z. B. in folgenden Beobachtungen niederschlägt: –– „UX Professional“ ist aktuell keine geschützte Berufsbezeichnung – Service-Portfolios einzelner Anbieter differieren z.T. erheblich (bzgl. Scope „was“ angeboten wird, als auch Ausführungsqualität „wie“ es geliefert wird). SchnittstellenRollen und Integrations-Wissen sind stark nachgefragt; Stundensätze für Standard-Services stagnieren bzw. sind rückläufig.

138

–– Verbreitung von High-end Telekommunikations- / UnterhaltungsTechnologien (z. B. Smart-Phones) und wachsende, gesellschaftliche Durchdringung mit mobilen Internet Zugängen resultieren in de-facto Verfügbarkeit von UsabilityBenchmarks für Jedermann (z. B. Apple iOS / Android) – Marktreife und Kunden-Anspruch nehmen stark zu. –– UX Projekte geraten unter Rechtfertigungsdruck bzgl. Kosten:Nutzen-Relation – Parallelen zu Vorgänger-Trends, die IT- / TIMESMärkte und andere Branchensegmente bereits früher durchlaufen haben sind erkennbar (Bsp: Professionalisierungsund Qualitäts-Initiativen wie TQM, ISO 9001, Einführung von Projektmanagement, Umstellung auf Agile Methoden etc.) Genannte Punkte führten im Nachgang der UP11 durch drei der Autoren des vorliegenden Beitrags in Q4-2011 zur Gründung des GUPA Arbeitskreises „Business Case Usability / RoI-UX“. Der AK nahm in Q1-2012 seine Tätigkeit auf, besteht aktuell aus 6 Mitgliedern + 2 Interessenten und

Andreas Hinderks Häfkerstr. 11 28844 Weyhe andreas@hinderks.org Elena Gocheva Tresckosstrasse 27 28203 Bremen elenagocheva@yahoo.de

Keywords: /// Return-on-Investment (RoI) /// UX-Professionalisierung /// Projektstandards /// UX-Service-Qualität

befindet sich nach Initial-Scoping (Aufstellen AK Vision) in der Context-Analyse, um seinen Mehrwert für die UX Community abzuleiten. 2. Positionierung & Mission AK RoI-UX 2.1. Mission des AK RoI-UX Der GUPA AK RoI-UX nimmt im Rahmen des aktuellen UX-Branchenwandels eine Aufklärungs- und Sensibilisierungsmission wahr. Die Haupt-Adressaten sind folgende Zielgruppen: –– Die Aufklärungsmission adressiert „Entscheider mit Budgetverantwortung“ und „Mitentscheider“ bzw. „EntscheidBeeinflusser“. Diese Projekt-(Co)Sponsoren sind zumeist nicht UX-versiert – Ziel ist es daher, ihnen ihre Mitwirkungs- und Gestaltungsoptionen (z. B. im Rahmen der Anforderungsdefinition) aufzuzeigen und UX-Professionals (speziell GUPA/UPAi-Mitglieder) als verlässliche Geschäftspartner für UX-Rollen zu positionieren.


Usability Professionals 2012 Arbeitskreise German UPA

Die Aufklärungsmission adressiert darüberhinaus indirekt Mitarbeiter interner Schnittstellen, die als Verkäufer oder Berater im Prozess involviert sind. Besonders prägnant ist diese Zielgruppe bei großen Webagenturen mit vielen beteiligten Mitarbeitern. –– Die Sensibilisierungsmission adressiert die „UX Professionals“ selbst – UP11-Erkenntnis war u. a., dass Mitglieder der UX-Branche z.T. Ausbildungsbedarfe im Bereich der Schnittstellen-Funktion UX-BWL und UX-Technologie/Ingenieurwissensschaften aufweisen. Viele heutige Know-how Träger haben sich Wissen auto-didaktisch oder in langjähriger Berufs-Praxis angeeignet – der UX-Branchenwandel verkürzt die Zeitbudgets für diese Einarbeitung. Der Markt erwartet von UX-Professionals Stellungnahmen zu Projektaussichten inkl. UX-Performance-Measures vor Projektentscheid.

und GUPA-Mitgliedern zur Verfügung stellen, als betriebswirtschaftliche Argumentationshilfe für ihren Mehrwertbeitrag. 3. Umfeldanalyse & Problemstellung Das vorliegende Statuspapier des Arbeitskreises „Return-on-Investment in User eXperience“ (AK „RoI-in-UX“) beschäftigt sich mit dem Verhältnis aus erwartetem Mehrwert durch UX-Verbesserung von Produkten und Systemen und den damit verbundenen Kosten. Die Relevanz der Problemstellung ergibt sich aus dem Arbeitsalltag und dem wahren Leben:

2.2. AK-Workshop zur UP2012

Die unternehmensinterne SoftwareAnwendung eines DAX 30 Konzerns zur Abrechnung von Dienstreise-Spesen scheint keine Funktion zur Abbildung von Hotel-Stornierungskosten zu besitzen. Die Erfassung von Hotel-Stornokosten verursacht erhöhten Suchaufwand, Rückfrage bei Kollegen („Power-usern“) und endet schliesslich in Erfassung mittels BarkaufBeleg und dem Risiko falscher Verbuchung, d. h. Problemen im Wirtschaftsprüfungsaudit. Eine Mitarbeiterbefragung ergibt ausserdem, dass zur Abrechnung einer Dienstreise durchschnittlich 20 min Zeit aufgewendet werden. Eine Ursachen-Analyse weist als Kernproblem die Verteilung zu pflegender Felder auf nicht weniger als zwei Dutzend unterschiedlicher Masken aus, von denen in den häufigsten Fällen zumindest ein Dutzend angesprungen werden muss – ein erhebliches Einsparpotential wird erkennbar, wenn es gelänge die Reisekosten-Abrechnung in 50% des Zeitbedarfs zu erledigen.

Im diesjährigen Workshop möchten wir auf dem hier beschriebenen Wissenstand aufbauend die Praxiserfahrungen von UX Professionals miteinbeziehen. In einem Open Space Set Up möchten wir Maßnahmen zur Messung des RoI-in-UX näher beleuchten und Beispiele finden wie das Thema Entscheidern und Beeinflussern besser vermittelt werden kann. Im Nachgang werden wir weiter charakteristische Beispiele sammeln, dokumentieren, in standardisierte Templates konvertieren

Die Mitarbeiter haben keine andere Wahl zur Abrechnung ihrer Dienstreise-Spesen, die mangelnde Usability (Gebrauchstauglichkeit) führt zu Frust statt zu Lust: Schnelle und einfache Bedienung und/ oder hoher Komfort sollten Nutzung bequem machen. Freude während der Benutzung jedweder Produkte / Services / Systeme wirkt motivierend. In dem beschriebenen Fall lässt sich die Anwendung nur eingeschränkt effektiv, effizient und zufriedenstellend nutzen.

Diese Haupt-Adressaten-Gruppen sind im Rahmen des UX-Branchenwandels erheblichen Veränderungen im beruflichen Kontext ausgesetzt – Betroffene in aktive Beteiligte zu konvertieren und für neue Ideen zu gewinnen, indem etablierten Spielern neue Perspektiven aufgezeigt und Konzepte zur Rollen-Transformation angeboten werden kann als Schlüssel für erfolgreichen Wandel der UX-Branche sowie beeinflusster Produkte und Systeme verstanden werden.

Der oben beschriebene Fall einer Anwendung im Geschäftskontext (Business-Software) lässt sich auch im privaten Umfeld (Consumer-Products) nachvollziehen. Mangelnde Usability von Navigations-Geräten, Menüführungen an Haushaltsgeräten (Backöfen, Waschmaschinen, Fernsehern) oder der Voicemail-NetBox des Mobilfunkanbieters sind allgegenwärtig. 4. Allgemeine Einführung Return-on-Invest (RoI) Während in unreifen, technologie-getriebenen Anbietermärkten häufig TrendVerfolgung maßgebliche Argumente für Produktneuentwicklungen oder Produkterweiterungen liefert, wird in reifen, kundenorientierten Käufermärkten eher anhand quantifizierter Kosten:Nutzen-Relationen über Investitionen entschieden. Hierbei dienen vorab kalkulierte Kennzahlen zur Bewertung geplanter Projektvorhaben. Um Entscheider von Investitionsvorteilen zu überzeugen, werden Berechnungsmethoden auf Basis unterschiedlicher Modellkomplexität herangezogen: –– Amortisationszeit, –– Kosten- oder Gewinn-Vergleichsrechnungen, –– Rentabilitäts-Funktionen, –– Geld-Zeit-Wert-Relationen. Als Berechnungsergebnis fungieren Kennzahlen, die bei Vergleich verschiedener Alternativen wirtschaftliche Vor- und Nachteile aufzeigen. Der Return-on-Invest (RoI) stellt in der Reihe verschiedener Kennzahlen einen sehr prominenten Vertreter dar. RoI repräsentiert das Verhältnis zwischen erwartetem Gewinn und investiertem Kapital. Eine Investition mit höherem RoI ist demzufolge rentabler als vergleichbare Investitionen mit niedrigerem RoI. Die verschiedenen Berechnungsarten und Beziehungen, die RoI mit verschiedenen anderen Kennzahlen verbindet, sind der gängigen Fachliteratur entnehmbar (Koller et al., 2005). Bei Investition in UX-Prozesse oder der Anwendung von UX-Methoden erfolgt die Identifizierung von Geschäftsvorteilen, die sich grob in zwei Kategorien unterteilen lassen:

139


deren Denkmuster einzulassen. Hieraus entsteht für zukünftig erfolgreiche UXProfessionals die Herausforderung die BWL-Sicht auf UX-Projekte einzunehmen und das RoI-Denkmuster zumindest soweit zu durchdringen, wie es zur erfolgreichen Beauftragung und Projekt-Durchführung notwendig ist. Zum Nachvollziehen der gängigen RoI-inUX-Literatursicht wird auf Standardwerke verwiesen (Bias & Mayhew, 2005). Gängige RoI-in-UX-Messwerte sind u. a. die Erhöhung der Anzahl regelmäßiger Besuche auf einer Webseite oder Applikationsnutzung. Oft werden Korrelationen gebildet z. B. von steigender Nutzerverweildauer und Umsatz. Häufig verwendet werden auch Anzahl Benutzerfehler, Kundensupportkosten, Implementierungskosten, Kundenbeschwerden.

Abb. 1. Innovations-Kategorien, Design Thinking

–– Kostensenkung durch Prozessoptimierung – Produkte auf richtige Art entwickeln Rationalisierung erhöht Produktivität – bereits mit Beginn der Produktentwicklung können mit einem gezielten, benutzerzentrierten Entwicklungsprozess Kosten eingespart werden. Frühzeitiges Erkennen von Fehlentwicklungen ermöglicht Gegenmaßnahmen und senkt Kosten. –– Umsatzsteigerung und Markenstärkung – die passenden Produkte entwickeln. Hochwertige Produkte erzielen Wettbewerbsvorteile durch Differenzieren vom Marktquerschnitt. Dabei können pragmatische Qualitätsmerkmale (Effektivität, Effizienz, Durchschaubarkeit und Steuerbarkeit) von hedonischen Qualitätsmerkmalen (Stimulation und Originalität) unterschieden werden. Diese Eigenschaften definieren die Produktattraktivität und wirken als Umsatztreiber. Neben monetären Aspekten erfolgt eine Markenstärkung. Problematisch ist die Vergangenheitsorientierung der RoI-Denkweise, da RoI aus

140

buchhalterischen Daten ermittelt wird. In Entwicklungsprojekten möchte man aber frühzeitig Aussagen über mögliche Gewinnerzielung des Produkts ableiten. Für den Einsatz von UX-Prozessen möchte man die Auswirkungen frühzeitig erkennen und benennen können, was ein buchhalterischer Ansatz nicht liefern kann. Frühester Zeitpunkt zur Ermittlung RoI-relevanter Daten sind Usability Tests. Dieser Zeitpunkt stellt häufig den ersten Kontakt mit potentiellen Käufern dar. Im agilen UX Prototyping wird dieser Zeitpunkt bereits sehr früh im Entwicklungsprozess erreicht. 5. Verbindung der Denkwelten von RoI & UX Die Wissensdomänen auftraggeberseitiger Entscheider mit „RoI“-Denkmustern und auftragnehmerseitiger UX-Fachexperten treffen z. B. zur Projekt-Verhandlungsphase aufeinander, um Budgetierungen bzgl. UX-Maßnahmenumfang festzulegen. Da in UX-Projekten der UX-Professional auf der zuliefernden Seite steht, erscheint es angemessen zunächst vom UX-Dienstleister (intern wie extern) ausgehend die Auftraggeberseite abzuholen und sich auf

In dem oben erwähnten Beispiel der Spesenabrechnung kann bei einer kalkulierten Zeitersparnis von 20% pro Mitarbeiter pro Reise errechnet werden, wieviel bei einer Investition in User eXperience Aktivitäten und damit in die verkürzte Ausführung der Aufgabe gespart werden kann. Die Schwierigkeit bei RoI–UX-Messwerten ist, dass sie nur bei entsprechender Vorhabens-Ähnlichkeit zu bisherigen ProjektDaten zu exakt kalkulierten Vergleichszwecken herangezogen werden können. Alles andere sind angenommene Kalkulationen aufgrund von Erfahrung. Idealerweise ist die Menge vorhandener UX-Erfahrungsdatensätze im analogen Kontext so groß und deren Granularität so fein, dass sich Daten-Populationen statistisch sauber erfassen und beschreiben lassen (Aussagen-Signifikanz). Erst hierdurch werden Erfahrungswerte als quantitative Daten zur Entscheidungsunterstützung nutzbar. Um Zukunfts-Aspekten als Bemessungsgrundlage von UX-Investments gerecht zu werden, wird an Design Teams oft der Wunsch herangetragen, neben finanzbuchhalterischen RoI-Betrachtungen und Kundensicht (CRM) auch die Prozess-Sicht mitabzubilden. Dies kann z. B. mittels Innovations-KPIs geschehen – KPIs für


Usability Professionals 2011 Arbeitskreise German UPA

Innovations-Kategorien sind der folgenden Abbildung entnehmbar. [Abb. 1] eXperience-Innovation wird nach der verbreiteten „Design Thinking“-Methode (Brown, 2008) als 3fach-Überlappungsbereich („Sweet-Spot“) aus 3 Dimensionen beschrieben: Der Nutzer-Perspektive, die Bedürfnissen Rechnung trägt, der Technologie-Perspektive, die die Durchführbarkeit von Vorhaben gewährleistet und der Geschäfts-Perspektive, die sicherstellt, dass nur solche Ideen zur Ausführung kommen, die sich nach angemessenem Anschub auch nachhaltig selbst finanzieren können. Ideen, die aus den jeweiligen 2fach-Überlappungs-Bereichen stammen (functional / process / emotional innovation), werden als solche auch wertgeschätzt, weisen jedoch gegenüber einer Sweet-Spot Innovation im eXperienceBereich ein geringeres Potential auf. Aus den vorangestellten Ausführungen ist ableitbar, dass sich RoI-Fragestellungen und solche mit RoI-Verwandtschaft grundsätzlich aus finanz-buchhalterischer Sicht in 3 Klassen einteilen lassen. Da sich der GUPA-Arbeitskreis zum Ziel setzt, den RoI auf UX und nicht nur auf Usability zu beziehen, erscheint die Vermutung naheliegend, dass hieraus zunächst kein mathematisches Modell i.S. eines KPI-Wertetreiber Baums resultiert, sondern vermutlich bestehende KPIs in Relation miteinander gesetzt werden, um qualitativ ihre gegenseitige Beeinflussung zu beschreiben. 6. RoI-Verbreitung im UX-Umfeld 6.1. Aktueller Stand der RoI-Verwendung in UX-Teams Eigene Erfahrungen und Recherchen zum Überblick über UX Leistungen von Agenturen und Inhouse UX Teams weisen aus, dass von einem «RoI-in-UX» selten die Rede ist. Oft ist breite, qualitative Zustimmung darüber erzielbar, dass nutzerzentriertes Vorgehen Produkte, Services und Webseiten verbessert was wiederrum die Nutzerzufriedenheit steigert. Momentan

werden aber selten quantitative Messgrößen herangezogen, um UX-Investments zu rechtfertigen. Kombinationen aus Megatrends wie Consumerization (sozio-kulturell) und Mobiles Internet (sozio-kulturell und technisch) bewirkten z. B. einen App Hype, angeführt von Apple über Android bis zu Apps auf Fernsehern mit der Folge, dass Wettbewerber im Konsumgüter-Markt steigendem Druck ausgesetzt werden, das Nutzungserlebnis zu erhöhen, um gestiegenen Nutzererwartungen gerecht zu werden (Löwenberg, 2008). Die vormals scharfen Grenzen zu Investitionsgüter-Märkten (z. B. Business Software) verschwimmen aktuell zunehmend. Der Wettbewerbsvorteil durch Design wird von Apple vorgelebt. Aber noch ist nicht klar, ob UX-Investment mehr Erfolg verspricht als nur durch größere Oberflächen-Attraktivität zu glänzen. Das liegt auch daran, dass die Messgrößen von UX noch nicht hinlänglich bekannt sind. Viele UX Teams messen noch immer nicht den RoI ihrer Arbeit. Auch 2012 werden sowohl in Kundenprojekten als auch bei inhouse UX Arbeit charakteristische Messgrößen (Rückgang Support-Anrufe, niedrigere Trainingsnotwendigkeit=kleinere Trainingsbudgets, kürzere Entwicklungszeiten, häufigere Produktnutzung oder schnellerer Transaktionsdurchlauf) nicht gemessen. Damit fehlen belastbare Aussagen für wirtschaftliche Argumente bzgl. der Rentabilität von UX Leistungen, obwohl mit den oben genannten Parametern messbare und belegbare Größen/Kennzahlen existieren. 6.2. RoI Verbreitung bei In-house UX Teams Zwei Aspekte halten inhouse UX Professionals immer noch davon ab, beweisen zu können, dass UX Leistungen sich auszahlen. Über RoI-in-UX wird gerade in Firmen mit einem geringen UX Reifegrad (UX Maturity) wenig geredet. Maßnahmen, um RoI zu messen, fehlen in der Regel vollständig. Ein Aspekt, der zu Problemen

bzgl. messbarer UX führt, ist eine technologie-getriebene Firmenkultur. UX Professionals beklagen oft die fehlende Wichtigkeit und das Investment Ihrer Firmen in Design. Immer noch werden viele Softwareprodukte um den Produkt Engineering Prozess herum geplant. Die Vermutung, dass Designer sich „am Ende der Nahrungskette“ befinden, vermittelt das Gefühl, dass Design nicht wertgeschätzt wird. Zum Glück haben Software Entwicklung und das Web inzwischen ein Stadium erreicht, in denen sehr viel der grundlegenden Technologien bereits vorhanden sind und viele große Firmen sich nun gezwungen sehen, gutes Design zu bieten, um weiterhin am Markt erfolgreich zu bestehen und sichere Unterscheidungsmerkmale zu Mitbewerbern zu erhalten. Nutzer haben durch die Entwicklung auf dem Konsumentenmarkt immer höhere Erwartungen. Ein anderer Aspekt ist, dass es in den meisten Firmen immer noch keine UX Repräsentanz im Executive Management gibt (Rohn, 2007). Eine ableitbare und zu überprüfende Hypothese ist: „Wenn UX als Domäne nicht in der Geschäftsführung gleichberechtigt (z. B. neben Finanzen, Marketing, Technik) vertreten ist, dann resultiert daraus eine Unterpriorisierung von UX in der Unternehmensstrategie.“

Sollte sich diese Hypothese bewahrheiten, dann stehen Nutzer- und somit bisweilen Kunden-Interessen mitunter in Konflikt mit den Interessen interner Gruppen. Voraussetzung für gute User eXperience ist, dass ein multi-disziplinäres Produktteam (UX, F&E, Marketing, Vertrieb, Qualität etc.) für das Thema User eXperience verantwortlich zeichnet (Rosenberg, 2007). Nur dann können Potenziale wie Reduzierung der Entwicklungszeiten und SupportkostenSenkung durch User eXperience realisiert werden. Erst wenn es das Ziel des Produktmanagers ist, nutzerzentriert Anforderungen zu erheben, kann UX seine Funktion richtig ausüben. Idealerweise arbeitet das multidisziplinäre Team von Anfang an zusammen an der Produktdefinition. Softwareentwicklungsansätze wie Scrum leisten hier entscheidende Beiträge, wenn

141


auf Basis von User Stories entwickelt wird und diese auf Grundlage von Nutzeranforderungen geschrieben worden sind. Auch Methoden wie Design Thinking, wie es z. B. von Firmen wie SAP und der Telekom eingeführt wird, steigern das Verständnis um Designprozesse enorm. 6.3. RoI-in-UX Service-Agenturen Der Reifegrad im Design-Prozess von Agenturen gilt als sehr hoch. Auch die Kunden sprechen oft von guter Usability und state of the art User Interfaces. Oft werden als Vergleich de-facto standards wie Apple-Produkte und Google-Funktionen bzgl. UI-Gestaltung und InteraktionsDesign bemüht. Das Verständnis, was aus UX Sicht dazu gehört um eine solche Nutzererfahrung zu kreieren, ist leider nicht sehr ausgeprägt. Der Begriff User eXperience ist in Deutschland noch nicht hinlänglich verbreitet – knappe Budgets und die Reduktion auf visuelles Design jedoch gängig. Einen Unterschied aber kann man verzeichnen zwischen Webanwendungen und Geschäftsanwendungen. Im Web werden häufiger die sogenannten Conversion Rates und damit auch ein Teil der UX der Anwendungen gemessen. Damit diese Rate besser ausfällt sind oft Maßnahmen aus dem Bereich UX unerlässlich. Usability Tests oder Expert Reviews als geeignete Maßnahmen zur Messung der UX von Geschäftsanwendungen spielen aber gerade bei mittelständischen Unternehmen noch keine große Rolle. Vereinzelt sieht man jedoch, dass Kunden Wireframes kreieren um die Vorstellung, was die Applikation leisten soll, in einem frühen Stadium zu definieren. Momentatn ist der wirtschaftliche Aspekt von User eXperience noch weitestgehend darauf beschränkt, dass sich gutes visuelles Design auf eine höhere Nutzerzufriedenstellung auswirkt. Andere Aspekte der Wirtschaftlichkeit werden kaum betrachtet. Es fehlt an Messungen und Studien zum Thema. Selten werden die Vorteile im Detail von UX Professionals erwähnt und bewiesen.

142

Kunden fragen nach schönen Designs aber selten wird angenommen, dass es sich auch in anderer Hinsicht bezahlt macht, ein umfangreiches UX Leistungspaket zu beauftragen und damit bereits die Produktdefinition nutzerzentriert auszurichten. 7. Zusammenfassung & Ausblick Dieser Beitrag zeigt die Wichtigkeit des Themengebietes User eXperience auf und verdeutlicht die Wirtschaftlichkeit, den Nutzen und die Rentabilität innerhalb des Entwicklungsprozesses von Produkten oder Dienstleistungen. Hierzu wurden einige mögliche Parameter und Kennzahlen beschrieben, die aktuell nicht in die Betrachtung des RoI-in-UX einfließen. Weiterhin wird klar, dass User eXperience nicht erst in zukünftigen Entwicklungsprozessen berücksichtigt werden kann, sondern dass bereits heute in allen laufenden Prozessen die Bedürfnisse und Erwartungen der Nutzer nicht außen vor gelassen werden dürfen.

sondern innerhalb des Unternehmens muss ein User-eXperience-Management eingeführt und gelebt werden, um einen echten Return-on-Invest zu erlangen. Zusammen mit UX Professionals werden im Workshop auf der UP2012 diese Aspekte beleuchtet und geeignete Beispiele für den Geschäftsalltag erarbeitet. UX Professionals sollen damit befähigt werden Entscheidern und Beeinflussern den konkreten Mehrwert und den RoI-in-UX aufzuzeigen. Literatur 1. BIAS, R.G. & MAYHEW, D. J. (2005). Costjustifying Usability – An Update for the Internet Age. Morgan Kaufmann (Elsevier), Burlington, MA, U.S. 2. BOGNER, C. et al. (2010). The Usability / UX Profession – Berufsfeld Usability. GUPA Fachschriften Bd 1, German UPA, Stuttgart. www.germanupa.de/german-upa/berufsfeldusability-ux/germanupa_the-usability-uxprofession.pdf 3. BROWN, T. 2008. Design Thinking. Harvard Business Review (Jun) 84-92. 4. DIEFENBACH, S. & ULLRICH, D. (2011).

Ist User eXperience nun berechenbar? Der RoI-in-UX soll und kann berechnet werden – beispielsweise durch Ressourcenschonung innerhalb der Entwicklung, Verkürzung der Entwicklungszyklen, weniger Korrekturschleifen/ChangeRequests oder durch weniger Rückläufer/ Garantieansprüche.

Branchenreport Usability 2011 – Ergebnisse einer Befragung unter Usability Professionals in Deutschland. German UPA, Stuttgart. www.germanupa.de/german-upa/ branchenreport/Diefenbach-Ullrich_2011_ BranchenreportUsability2011.pdf 5. KOLLER, T. et al. 2005. Valuation – Measuring and Managing the Value of Companies. Hoboken, NJ, U.S., John Wiley & Sons,

Doch die entscheidende Frage ist nicht die nach einer „Formel“ für den RoI, sondern die Frage nach dem echten Mehrwert. Wieviel sind „Innovation“, „Stärkung der Marke“, „positive Kundenrezessionen“, „verstärkte Social-Media-Aktivität“ oder einfach „zufriedene Kunden“ wert?

Fourth Edition 6. LÖWENBERG, B. 2008. Web 2.0: Prinzip, Technologien und Einsatzszenarien – ein Überblick, http://fiz1.fh-potsdam.de/volltext/ oberhof/08272.pdf 7. ROHN, J. 2007. How to organizationally embed UX in your company. Interactions, 25-28

Mit dieser Frage beschäftigen sich viele Experten und ganze Abteilungen in Unternehmen. Top-Ingenieure, Kreative und Kaufleute arbeiten an hochwertigen Produkten. Doch oft verlieren Sie den Blick von außen, die Sicht des Kunden und den Fokus auf den echten Mehrwert ihrer Entwicklung. Nicht nur das Marketing oder das Produktmanagement sind zuständig,

8. ROSENBERG, D. 2007. Introducing the 360° view of UX management. Interactions, 22-24 9. TULLIS, T. & ALBERT, B. (2008). Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics. Morgan Kaufmann (Elsevier), Burlington, MA, U.S.


Usability Professionals 2011 Arbeitskreise German UPA

143


Wie gut ist mein Unternehmen im Usability Engineering und wie kann es (noch) besser werden? Dr. Natalie Woletz T-Systems International Landgrabenweg 151 53227 Bonn natalie.woletz@telekom.de Desdemona Strauß AVM GmbH Alt-Moabit 95 Abstract 10559 Berlin Viele der Interaktionsgeräte, d.strauss@avm.de

Marius Wolf Bayer CropScience AG Alfred-Nobel-Str.50 40789 Monheim am Rhein marius.wolf@bayer.com Nicole Charlier akquinet AG Bülowstr. 66 10783 Berlin Zeit auf den Markt gekommen nicole.charlier@akquinet.de

die in jüngster sind, sind gesten- und touchbasiert. Diese auf neuen Technologien basierenden Interaktionsformen werden häufig auch als natürliche Interaktion bezeichnet. Maus und Tastatur haben als Eingabegeräte Konkurrenz bekommen. Als prominente Vorreiter sind hier die Abstract aktuellen Smartphones sowie Microsoft Surface zu nennen. Damit hat sich auch der GeDer Arbeitskreis “In-house Usability Professionals” der German UPA hat ein Instrument staltungsraum für Interaktionsdesigner erweitert. Die Konzeption von Steuerungsgesten entwickelt, mit dem es möglich ist, die Stärken und Schwächen des Usabillity Engineering kommt als neue Dimension hinzu. Den damit verbundenen Herausforderungen widmet (UE) Prozesses im eigenen Unternehmen zu messen. sich unser Tutorial. Wir zeigen die Bandbreite neuer Interaktionsmöglichkeiten auf und Als Grundlage für das Bewertungsinstrument dienten der German UPA Qualitätsstandard probieren gemeinsam mit den Teilnehmern eine Methode zur Gestaltung von gestenfür die Gestaltung von Usability-Engineering-Prozessen und das Bewertungsschema der und touchbasierter Interaktion aus. ISO/IEC 15504. Anhand dieser beiden Modelle wurde ein Interviewleitfaden erstellt. Er umfasst sieben verschiedene Tätigkeitsbereiche des UE-Prozesses, die jeweils mehrere Aktivitäten beinhalten. Diese Aktivitäten können gemeinsam mit einem oder mehreren Interviewpartnern bewertet werden. Das Ergebnis der Bewertung lässt sich anschließend als Stärken-Schwächen-Profil darstellen, das zur Verbesserung des UE-Prozesses innerhalb des Unternehmens verwendet werden kann. Der Arbeitskreis hat in mehreren Interviews dieses Bewertungsinstrument selbst erprobt und weiterentwickelt. In einem Tutorial auf der UP-Konferenz 2012 stellt der Arbeitskreis dieses Instrument und die bisher gemachten Erfahrungen vor. Außerdem sollen die Teilnehmer die Gelegenheit bekommen, selbst erste Erfahrungen mit dem Bewertungsinstrument zu sammeln.

1. Einleitung In vielen Unternehmen leisten Usability Professionals Pionierarbeit. Sie stehen vor der Aufgabe, Usability Engineering (UE) in ihrem Unternehmen zu etablieren. Der Wunsch und die Anforderung, gebrauchstaugliche Produkte und Dienstleistungen zu entwickeln sind vorhanden, aber es fehlt vielerorts das Wissen darüber, wie das genau vonstatten gehen soll. Welche Aktivitäten und Methoden des Usability Engineerings bzw. des User Centered Designs sind erforderlich? Welche Voraussetzungen müssen erfüllt sein? Welche Personen und welche Abteilungen müssen in die Usability Engineering-Aktivitäten einbezogen werden und zu welchem Zeitpunkt? Im UPA-Arbeitskreis “In-house Usability Professionals” sind wir zu der

144

Überzeugung gelangt, dass es sinnvoll ist, vor der Beantwortung all dieser Fragen zunächst zu bewerten, wie gut (oder schlecht) das eigene Unternehmen bereits in Sachen Usability Engineering unterwegs ist. Fragen in diesem Zusammenhang sind zum Beispiel: Werden Usability Engineering-Aktivitäten regelmäßig durchgeführt oder sporadisch immer nur dann, wenn im Projekt noch Zeit und Geld dafür da sind? Gibt es Regeln, wie und wann bestimmte Methoden im Unternehmen einzusetzen sind? Wer ist für die Durchführung von UEAktivitäten zuständig? Sind UE-Aktivitäten im Budget- und Ressourcenplan verankert? Diese Fragen zielen also darauf ab, wie “reif” der Usability-Engineering-Prozess im eigenen Unternehmen ist. Insbesondere in kleinen und mittelständischen

Charlene Beavers STRATO AG Pascalstraße 10 10587 Berlin beavers@strato.de Berit Leiking NEMETSCHEK Allplan GmbH Konrad-Zuse-Platz 1 81829 München bleiking@nemetschek.com

Keywords: /// Usability Engineering /// User Centered Design /// Usability Reife /// Prozessbewertung /// Prozessqualität

Unternehmen stehen jedoch im Allgemeinen weder ausreichend Zeit noch genügend Geld zur Verfügung, um eine Reifegradstudie durchzuführen. Hier wollen wir ansetzen und In-house Usability Professionals ein Instrument an die Hand geben, mit dem sie schnell und einfach ein Stärken-Schwächen-Profil ihres Unternehmens erstellen und Handlungsempfehlungen ableiten können. Auf der diesjährigen UP-Konferenz wollen wir dieses Instrument in einem Tutorial vorstellen und über unsere bisherigen Erfahrungen damit berichten. 2. Tutorial auf der UP-Konferenz 2012 Das von uns eingesetzte Instrument besteht aus einem Interviewleitfaden, der auf dem German UPA Qualitätsstandard


Usability Professionals 2012 Arbeitskreise German UPA

für Usability Engineering (2012) basiert. Im Tutorial wollen wir den Teilnehmer/ innen den Interviewleitfaden vorstellen und anhand einer praktischen Übung die Gelegenheit geben, erste eigene Erfahrungen damit zu sammeln. Weiterhin möchten wir unsere eigenen Erfahrungen, die wir bisher mit dem Interviewleitfaden gemacht haben, gemeinsam mit den Teilnehmer/ innen diskutieren. Zielgruppe: In-house Usability Professionals mit Kenntnissen im Bereich Usability-Engineering-Prozesse (insbes. ISO 9241-210, ISO/TS 18152) und Interesse an Fragestellungen zur Prozesseinführung und -bewertung. 3. Auswahl eines Prozessmodells Eine Möglichkeit, zu bewerten, wie gut ein Unternehmen den Usabillity Engineering (UE) Prozess durchführt, besteht im Vergleich zwischen einem optimalen UE-Prozess und dem im Unternehmen gelebten UE-Prozess. Wie ein optimaler UE-Prozess aussieht, beschreiben mittlerweile eine Reihe von Leitfäden, Qualitätsstandards, Prozess- und Reifegradmodellen speziell zum Thema Usability Engineering. Wir wollten wissen, ob und inwiefern sich diese für die praktische Arbeit eignen und wie damit die Stärken und Schwächen des eigenen Unternehmens beurteilt werden können. Im Detail wollten wir herausfinden, wie eine Beurteilung des Reifegrades auch für verschiedene Unternehmensgrößen funktionieren kann. Alle von uns untersuchten Prozessmodelle gehen von einem sehr strukturierten, klar definierten Vorgehen aus. Allerdings laufen gerade in kleinen und mittelständischen Unternehmen die Prozesse häufig weniger formalisiert ab. Unser Hauptanliegen war es, ein möglichst einfach anzuwendendes Verfahren zu wählen. Es soll geeignet sein, auch ohne Vorkenntnisse im Bereich Prozess-Assessment angewendet zu werden. Die Auswertung sollte möglichst einfach und schnell gehen. Das Vorgehen muss nicht mit wissenschaflicher Genauigkeit durchgeführt werden.

Es soll nicht um statistische Verfahren oder quantitative Datenerhebung gehen. Im Vordergrund soll stehen, einen Überblick zu bekommen, wo das eigene Unternehmen steht hinsichtlich der Frage, “Wie gut machen wir Usability Engineering und wo können wir besser werden?”. Die sehr einfachen Screening-Verfahren, wie Stages of Acceptance of User-Centered Design von Ehrlich und Rohn (1994) oder Usability Management Maturity Grid von Flanagan (1996) bzw. Flanagan und Rauch (1995), waren uns zu grob. Zudem ist deren Anwendung in der Literatur nur unzureichend beschrieben. Weitere Bewertungsverfahren, die wir uns angesehen haben, waren unter anderem die ISO/ TS 18152 Ergonomics of human-system interaction und das DAkkS-Prüfverfahren für den Usability-Engineering-Prozess auf der Grundlage von DIN EN ISO 13407. Diese beiden Verfahren sind sehr fundiert und auch sehr umfangreich. Eine schnelle Einarbeitung und Anwendung schien uns hier nicht möglich. Wir haben uns entschieden, den German UPA Qualitätsstandard für die Gestaltung von Usability-Engineering-Prozessen als Grundlage für unsere Bewertung einzusetzen. Er basiert auf der ISO 9241-210 und beschreibt praxisnah Aktivitäten, die in den einzelnen Phasen des Usability-Engineering-Prozesses durchgeführt werden sollten, sowie Beispiele für zu erstellende Arbeitsergebnisse. Da der Qualitätsstandard nicht als Bewertungsverfahren gedacht ist, verfügt er auch nicht über ein Bewertungsschema. Für die Bewertung des Erfüllungsgrades haben wir uns daher an dem Bewertungsschema der ISO/IEC 15504 orientiert (siehe Abschnitt „Unser Vorgehen”). 4. Unser Vorgehen Zunächst haben wir basierend auf dem Qualitätsstandard einen Interviewleitfaden entwickelt. Für jede im Qualitätsstandard beschriebene Aktivität haben wir folgende Fragen formuliert:

–– Wird diese Aktivität ausgeführt? Wenn nein, warum nicht? –– In welchem Prozessschritt und durch welche Rolle wird die Aktivität ausgeführt? –– Welche Arbeitsmittel werden benötigt und welche Methoden werden eingesetzt, um diese Aktivität auszuführen? –– Welche Schritte werden unternommen, um die Aktivität durchzuführen? –– Ist definiert, welche Schritte zur Fertigstellung notwendig sind? –– Welche Arbeitsergebnisse werden während dieser Aktivität erzeugt? –– Ist die Struktur der zu generierenden Arbeitsergebnisse definiert? –– Sind alle Arbeitsmittel vorhanden? –– Wie sieht der Zustand nach der Durchführung der Aktivität aus? –– Sind die geplanten Ergebnisse damit erzielt worden? –– In welchem Bereich schätzen Sie die vollständige Ausführung dieser Aktivität ein? Die Beantwortung der letzten Frage erfolgt auf einer vierstufigen Skala: 1 = kaum/nicht erfüllt, 2 = teilweise erfüllt, 3 = größtenteils erfüllt, 4 = vollständig erfüllt. Die Bewertung, wie gut ein Unternehmen in der Durchführung des Usability-EngineeringProzesses ist, erfolgt basierend auf dieser Einschätzung. Für jede Aktivität kann in einem Stärken-Schwächen-Profil angegeben werden, wie vollständig sie ausgeführt wird. Abbildung 1 zeigt beispielhaft ein solches Stärken-Schwächen-Profil. [Abb. 1] Wir haben in fünf verschiedenen Unternehmen insgesamt neun Interviews geführt. Die Interviews wurden mit Usability Engineers, Produktdesignern, Projektmanagern, Produktmanagern und anderen Vertretern des zu bewertenden Unternehmens durchgeführt. Wichtig war uns bei der Auswahl der Interviewpartner, dass diese einen guten Überblick über die relevanten Abläufe haben. Die Befragten wurden gebeten, sich bei ihren Antworten an einem typischen Projekt aus der jüngeren Vergangenheit zu orientieren. Bei der Durchführung der ersten Interviews stellte sich heraus, dass unser

145


ursprünglicher Fragebogen einige praktische Probleme verursachte. Zum einen war der Fragebogen sehr umfangreich und enthielt eine Reihe von Fragen, die sich nicht auf die konkrete Situation anwenden ließen. Zum anderen passten viele Begriffe aus dem Qualitätsstandard nicht zu den Begriffen, die die Interviewpartner verwendeten. Deswegen haben wir den Fragebogen gekürzt und dafür um einige Beispiele und Umschreibungen ergänzt, die die praktische Anwendbarkeit erleichtern sollen. 5. Unsere bisherigen Erfahrungen mit dem Bewertungsinstrument Im Folgenden beschreiben wir einige unserer bisherigen Erfahrungen, die wir bei der Anwendung des Interviewleitfadens gemacht haben. Im Detail möchten wir diese Erfahrungen in unserem Tutorial auf der Konferenz “Usability Professionals 2012” vorstellen und diskutieren. Der aktuelle Fragebogen hält sich sehr nah an den Formulierungen im Qualitätsstandard. Im Sinne einer Bewertung, die sich möglichst eng daran anlehnt, ist dies natürlich sinnvoll. Beim Interviewpartner kann jedoch nicht immer davon ausgegangen werden, dass der vorgestellte UE-Prozess und die verwendeten Terminologien bereits im Detail bekannt sind. Aus diesem Grund haben wir sowohl den Prozess inklusive der Aktivitäten als auch bestimmte Begrifflichkeiten zu Beginn des Interviews kurz vorgestellt. Während des Interviews sind wir immer wieder darauf zurückgekommen

und haben erläutert, an welcher Stelle wir uns gerade im Prozess befinden. Es kann hilfreich sein, wenn der Interviewpartner zum Interview eine Darstellung “seines” Prozesses mitbringt, dann kann dieser mit dem UE-Prozess abgeglichen werden. Welche Tätigkeitsbereiche gibt es in der Theorie (d. h. im Qualitätsstandard) und welche davon sind im Unternehmen abgedeckt? Dies ist die grundlegende Frage, die während des Interviews immer beantwortet werden muss. Werden bestimmte Bereiche von bestimmten Abteilungen oder Gruppen behandelt oder gar extern vergeben? Hier wurden z. B. Customer Insights von der Marktforschungs-Abteilung, Dokumentation von der Redaktionsabteilung, Evaluation von der Testing-Agentur etc. genannt. Dabei ist dann vom Interviewer einzuschätzen und mit dem Interviewten zu diskutieren, ob diese Ergebnisse wirklich zum aktuellen Bereich passen. Falls der Interviewte keine Einsicht in die Abläufe der anderen bzw. externen Abteilung hat, kann der Fragebogen auch modularisiert werden. Dann müssen nicht alle Tätigkeitsbereiche bei einem Verantwortlichen abgefragt werden. Wenn das Unternehmen Consumer Produkte herstellt, kann der Bereich “Das Produkt bei den Benutzern einführen” weggelassen werden. Aber Achtung: Die fünf Hauptbereiche des UE-Prozesses (von der Planung bis zur Evaluation) sind erforderlich, wenn man gebrauchstaugliche Produkte herstellen will. Aber nicht alle Teilschritte daraus sind in jedem Projekt notwendig (z. B. “Erforderliche Navigation entwickeln”).

Den Nutzungskontext verstehen und beschreiben Passende Methoden für eine Nutzungskontextanalyse unter Einhaltung von Kosten-/Nutzen-/Durchführbarkeitsaspekten auswählen Benutzergruppen beschreiben, so dass eine gezielte Auswahl von Benutzern möglich ist Nutzungskontext für jede Benutzergruppe erheben und beschreiben und Erfordernisse kenntlich machen Den Nutzungskontext validieren (von der jeweiligen Benutzergruppe bestätigen lassen) Optimierungsbedarf (Schwachstellen) im Nutzungskontext identifizieren Abb. 1. Ausschnitt aus einem Stärken-Schwächen-Profil

146

nicht/kaum erfüllt

teilweise erfüllt

Die Unterteilung des UE-Prozesses in sieben Tätigkeitsbereiche und deren Unterteilung (wie im Qualitätsstandard aufgeführt) ist in der Praxis häufig so nicht vorzufinden. Insbesondere die Planungsphase ist in der Realität oft nicht geteilt, stattdessen finden Tätigkeiten wie Ressourcen-, Zeit- und Budgetplanung oft gleichzeitig statt, zum Teil auch deswegen, weil diese Dinge voneinander abhängig sind. Beispielsweise muss bei der Einbeziehung einer externen Agentur auch gleichzeitig geplant werden, was deren Aufgabe sein soll und welche Kosten eingeplant werden müssen. In der Praxis gibt es hier viele Überschneidungen der Teilschritte bezüglich Planung und Durchführung. Bei agilen Methoden ist die Planung noch einmal anders gestaltet als bei klassischen Vorgehensweisen der Softwareentwickung. Durch die Notwendigkeit, den Standard allgemeingültig zu halten, sind manche Begriffe etwas schwer zu fassen, ein Beispiel ist hier “aufgabenbezogene Interaktionsobjekte”. Je nach Unternehmen bzw. Projektfall würde man dies zum besseren Verständnis umbenennen, z. B. in “Bedienelemente” oder “Website-Komponenten”. Die Interviews dauerten mindestens 1,5 Stunden, je nachdem, wie viele Bereiche des UE-Prozesses im gewählten Projekt für das Interview abgedeckt wurden. Bei Interviewpartnern ohne genaue Kenntnis des UE-Prozesses und der Fachausdrücke dauert es durch die anfängliche Erklärungsphase mit Beispielen wesentlich länger.

größtenteils erfüllt

vollständig erfüllt


Usability Professionals 2012 Arbeitskreise German UPA

Die Prozessbewertung des Unternehmens innerhalb der sieben definierten Tätigkeitsbereiche (nach einer Skala von 1 bis 4) kann entweder gemeinsam mit dem Interviewpartner gemacht werden, oder der Interviewer wird als Experte im Nachgang allein eine Einschätzung machen. Diese sollte er im Anschluss mit dem Interviewpartner noch einmal besprechen. Manchmal hat der Interviewpartner nur den Überblick über einen Bereich im Unternehmen oder einen Teilabschnitt eines Prozesses oder eines Projekts. Daher sollte sorgfältig abgewogen werden, wie viele Interviews im jeweiligen Unternehmen nötig sind, um einen zuverlässigen Eindruck zu erhalten. Die Objektivität bei der Bewertung muss im Zusammenspiel von Interviewer und Interviewtem behalten werden. Das Herausarbeiten von Stärken und Schwächen und der passenden Empfehlungen ist dann der abschließende Schritt für den Interviewer. Das Unternehmen sollte damit eine Einschätzung bekommen, wo es ansetzen kann, um Fortschritte im Usability Engineering zu erreichen. Für In-house Usability Professionals finden sich hier Argumente, die sie zur Verbesserung der Prozessqualität innerhalb ihres Unternehmens verwenden können. 6. Wie kann es weitergehen Basierend auf den Erfahrungen, die wir bisher gemacht haben, haben wir folgende Punkte identifiziert, an denen eine Weiterentwicklung des Bewertungsinstrumentes erfolgen kann: Handlungsanweisung –– Sowohl für die Durchführung der Interviews als auch für die Auswertung und das Ableiten von Verbesserungsmaßnahmen sollte eine Handlungsanweisung (Gebrauchsanleitung) geschrieben werden. Weiterentwicklung des Glossars –– Erweiterung mit alternativen Begriffen und Beispielen

–– Allgemein formulierte Begriffe (z. B. “Interaktionsobjekte”) könnten zu konkreten Begriffen aus verschiedenen Kontexten zugeordnet werden (z. B. “Navigationselemente auf Webseiten”)

Skills in die Bewertung mit einbezogen werden, woraus sich wiederum wertvolle Hinweise für die Ableitung von Verbesserungsvorschlägen ergeben können.

Ableitung von Verbesserungsvorschlägen / Maßnahmenkatalog –– Für das Entwickeln konkreter Verbesserungsvorschläge sollten zukünftig Hilfestellungen gegeben werden. So könnte beispielsweise beschrieben werden, wie aus dem Stärken-Schwächen-Profil konkrete Ansatzpunkte abgeleitet werden, an denen mit einer Verbesserung angesetzt werden soll. Außerdem könnten verschiedene Maßnahmen entwickelt Beteiligte Rollen im Prozess und deren Skills werden, die in bestimmten Situationen und Kompetenzen empfehlenswert sind. So wäre z. B. –– Bisher werden im Qualitätsstandard für denkbar, dass die Maßnahmen danach jede Aktivität die beteiligten Rollen und unterteilt werden, ob sie auf den Einsatz die Art ihrer Beteiligung (Durchführen, von Usability Engineering-Methoden, Beraten, Entscheiden, …) am Prozess auf organisatorische Aspekte der genannt. Diese werden auch in Aufbau- und Ablauforganisation oder unserem Fragebogen für die jeweiligen auf Verbesserungen im Bereich der Aktivitäten und Bereiche abgefragt. Es Ressourcenzuteilung zielen. zeigte sich in der Befragung, dass die Bezeichnungen der Rollen und deren Literatur Aufgaben in Theorie und Praxis oft 1. DAkkS (2010). Leitfaden Usability, Version 1.3. nicht übereinstimmen. Dazu kommt, DAkkS, Deutsche Akkreditierungsstelle GmbH. dass oft eine Rolle von mehreren 2. Ehrlich, K. & Rohn, J. A. (1994). Cost Personen getragen wird oder eine Justification of Usability Engineering: A Person mehrere Rollen ausfüllt. Darüber Vendor’s Persprective. In R. G. Bias & D. J. hinaus ist über die benötigten Skills Mayhew (Eds.), Cost–Justifying Usability (pp. und Kompetenzen der jeweiligen 73–110). London: Academic Press. Rollen noch zu wenig gesagt, um eine 3. Flanagan, G. A. (1996). Usability Management zuverlässige Zuordnung der Rollen in Maturity, Part 1. Self Assessment – How Do You der Praxis zu den idealtypischen Rollen Stack Up? SIGCHI Bulletin, 28(4). in der Theorie zu machen. –– Bei der Weiterentwicklung des 4. Flanagan, G. A. & Rauch, T. L. (1995). Usability Qualitätsstandards und des Fragebogens Management Maturity. Part 1: Self Assessment ist es daher sinnvoll, die im Prozess – How Do You Stack Up? Special Interest beteiligten Rollen nicht nur über ihre Group. Proceedings of Conference on Human Aufgaben, sondern auch über die Factors in Computing Systems, Denver, CO, erforderlichen Skills und Kompetenzen 336. zu definieren. Die Erweiterung des 5. German UPA e.V. (2012). German UPA Qualitätsstandards um eine solche Qualitätsstandard für Usability Engineering. Definition ist derzeit in Arbeit. Sobald http://germanupa.de/arbeitskreise/ diese vorliegt, sollte auch für den Qualitaetsstandards/N070_Qualitaetsstandard_ Fragebogen der Bereich der Rollen der_German_UPA.pdf, zuletzt geprüft am weiter ausgearbeitet werden. So kann in 31.07.2012. der nächsten Bearbeitungsstufe zusätzlich 6. ISO (2010). ISO/TS 18152 Ergonomics of zu den gelebten Abläufen auch der human–system interaction – Specification for Aufbau der Organisation in Bezug auf the process assessment of human–system die am UE-Prozess Beteiligten und deren issues. Genf: ISO. Auswertungsmöglichkeiten –– Je nach Aktivität zielen die Fragen aktuell entweder auf den Einsatz von Methoden, auf organisatorische Aspekte oder auf Ressourcen. Für die Auswertung der Interviews könnte diese Unterteilung ebenfalls hilfreich sein. Entsprechend könnte ein Auswertungsraster mit diesen Dimensionen entwickelt werden.

147


Barrierefreiheit 101 für Websites Eine Checkliste für Usability Professionals

Brigitte Bornemann BIT Design für Barrierefreie Informationstechnik GmbH Rödingsmarkt 43 20459 Hamburg bb@bit-informationsdesign.de

Nicole Charlier akquinet AG Bülowstr. 66 10783 Berlin nicole.charlier@akquinet.de

Abstract 10 Millionen Menschen in Deutschland leben mit einer amtlich anerkannten Behinderung, eine relevante Benutzergruppe, die jedoch von Angeboten im Internet häufig ausgegrenzt wird. Für Usability Professionals ist eine kurzfristige Einarbeitung in das Thema Barrierefreiheit durch die sehr spezifischen und komplexen Anforderungen und Testverfahren bisher nicht möglich. Sie geraten daher schnell an ihre Grenzen, wenn sie das erste Mal in einem Webprojekt mit dem Thema Barrierefreiheit konfrontiert werden. Wünschenswert wäre es aus Sicht von Barrierefreiheitsexperten, dass Usability Professionals schon in ihren Designs und User Interface Spezifikationen Barrierefreiheit berücksichtigen, und bereits ein Grundwissen darüber haben, wie Barrierefreiheit (z. B. von Webseiten) getestet werden kann. Die gültigen Gestaltungsrichtlinien (Web Content Accessibility Guidelines, WCAG) und auch die veröffentlichten Testverfahren, u. a. der BITV-Test (Barrierefreie Informationstechnik Verordnung) und die Kriterienliste des BIENE-Awards (ein Wettbewerb, der jährlich die besten barrierefreien Angebote im Internet auszeichnet), sind sehr umfangreich und richten sich in erster Linie an Entwickler. Für weniger technisch ausgerichtete Usability Professionals gibt es bisher keine einfache Möglichkeit, sich ein Urteil über den in einem Projekt erreichten Stand an Barrierefreiheit zu bilden. Der Arbeitskreis (AK) Barrierefreiheit der German UPA möchte eine Checkliste „Barrierefreiheit 101 für Websites“ entwickeln, die sich gezielt an Usability Professionals richtet und dieser Berufsgruppe einen leichteren Zugang in die komplexe Thematik vermittelt. Wir werden diese Checkliste vorstellen und die Praktikabilität diskutieren.

1. Zielsetzung Der AK Barrierefreiheit der German UPA wurde schon oft mit der Frage nach einer kurzen Checkliste oder einem unkomplizierten Einstieg in das Thema Barrierefreiheit von Webprojekten konfrontiert. Dahinter steckt der berechtigte Wunsch nach einer Basisqualifikation, die Usability Professionals rasch in die Lage versetzt, in einem Webprojekt im Hinblick auf Barrierefreiheit handlungsfähig zu werden. Ein geeignetes Angebot für dieses Anliegen gibt es bisher nicht. Es fehlt ein Instrument, das sich gezielt an Usability Professionals richtet und deren Fachwissen im Bereich Software-Ergonomie berücksichigt, somit die komplexe Thematik abgestimmt auf

148

diese Berufsgruppe aufbereitet. Diese Lücke will die Checkliste „Barrierefreiheit 101 für Websites“ füllen. Usability Professionals sollen damit ein Arbeitsmittel erhalten, mit dem sie den generellen Stand der Barrierefreiheit in einem Webprojekt beurteilen können. Es soll sie in die Lage versetzen, sich kompetent mit Entwicklern zu beraten und ggf. die Hinzuziehung eines Barrierefreiheitsexperten zu begründen. 2. Bestehende Richtlinien, Testverfahren, Checklisten Die gültigen Richtlinien der WCAG 2.0 sind komplex und sogar für Entwickler eine Herausforderung. Das ausführliche und detaillierte Dokument enthält sehr viele

Petra Kowallik OpenText Software GmbH Werner-von-Siemens Ring 20 85630 Grasbrunn Petra.Kowallik@opentext.com

Keywords: /// Barrierefreiheit /// Accessibility Checkliste /// Accessibility Test /// Website Test

beschreibende Punkte, wodurch die Konzentration auf die 12 Hauptaussagen der Richtlinien schwer fällt. Die Prüfungen müssen zudem mit allen Seiten durchgeführt werden, wodurch der zeitliche Aufwand für die Anwendung der Richtlinien und für das Durchführen eines Barrierefreiheitstests sehr hoch ist. Als Vorbild für unser Vorgehen kann die methodische Herangehensweise des BITV-Tests gelten. Die komplexen Richtlinien der WCAG 2.0 werden hier auf 50 Prüfschritte vereinfacht und die einzelnen Anforderungen, die Prüftechnik sowie Abgrenzungskriterien für Ermessensspielräume werden erläutert. Im Gegensatz hierzu: das BIENE-Testverfahren. Dieses besteht nur aus einer Checkliste von


Usability Professionals 2012 Arbeitskreise German UPA

Anforderungskriterien; die Prüftechnik wird jedoch nicht veröffentlicht. Wer nicht selber Experte ist, kann diese Kriterien kaum praktisch anwenden. Der BITV-Test eignet sich für die Unterstützung der Barrierefreiheit auf verschiedenen Ebenen. In seiner vollen Form ist er ein Prüfverfahren zur Feststellung der BITV-Konformität („es ist für die meisten Besucher gut oder sehr gut zugänglich“), das von dem für die Entwicklung zuständigen BIK-Projekt überwacht und mit einem Prüfsiegel dokumentiert wird. Daneben gibt es eine öffentlich zugängliche Variante des Verfahrens in Form eines Selbsttests. Jeder kann dabei den Selbsttest für die Qualitätssicherung der eigenen Arbeiten nutzen und bei Bedarf eine Überprüfung der Ergebnisse durch das BIK-Projekt beauftragen. Obwohl der BITV-Test bereits mit dem Fokus auf Vermittlung entwickelt worden ist, bleibt er mit seinen 50 Prüfschritten immer noch ein dickes Arbeitspaket, das viele Einsteiger in die Thematik abschreckt. Bereits 2003 (erneuert 2010) hat das AbI-Projekt (Aktionsbündnis für barrierefreie Informationstechnik, ein Zusammenschluss von Behindertenverbänden und Barrierefreiheitsexperten) einen Kurztest herausgegeben, mit dem Barrierefreiheitsexperten in einer frühen Phase der Beratung feststellen konnten, ob sich ein eingehender Test der Website lohnt, oder ob eine Schulung des Entwicklerteams vorteilhafter wäre. Weitere kurze Checklisten wurden auf Fachkonferenzen vorgestellt, um Entwicklern einen Einstieg zu geben oder die wichtigsten Checkpunkte für Blinde und Sehbehinderte vorzustellen (auf der BOA 2008, Best of Accessibility, ein Symposium zum Barrierefreien Webdesign). Grundlage dieser Checklisten ist jeweils der BITV-Test, aus dem eine Auswahl mit verschiedener Priorisierung angeboten wird. In ähnlicher Weise kann eine Priorisierung des BITV-Tests für Usability Professionals vorgenommen werden.

3. Unser bisheriges Vorgehen

4. Was sind die nächsten Schritte?

Im AK Barrierefreiheit der German UPA wurde die für Usability Professionals geeignete Herangehensweise an die Prüfung der Barrierefreiheit von Internetauftritten diskutiert. Dabei tauschten sich erfahrene Accessibility Consultants und Berufsanfänger aus.

Der Ansatzpunkt von „Barrierefreiheit 101“ ist es, Usability Professionals an die Barrierefreiheit heranzuführen. Die Checkliste bietet einen Einstieg in das Gebiet der Barrierefreiheit, vertieftes Wissen sollte mit Hilfe von Schulungen ausgebaut werden.

Als Ergebnis der fachlichen Diskussion wurden insgesamt 5 Prüfschritte erarbeitet, die Kernpunkte der Barrierefreiheit von Webangeboten behandeln und die nach unserer Meinung von Usability Professionals fachkundig beurteilt werden können. Ausgewählt wurden vor allem Prüfschritte mit Bezug zur allgemeinen Software-Ergonomie. Themen sind u. a. die Qualität von Bildbeschreibungen, die Orientierung im Menü und auf der einzelnen Seite und die Tastaturbedienbarkeit einer Website. Die Prüfschritte des BITV-Tests zu diesen Themen werden neu arrangiert und soweit nötig mit weiteren Erläuterungen versehen.

Die Checkliste „Barrierefreiheit 101“ wird zunächst für Websites bzw. Webanwendungen entwickelt. Später sollen die damit gemachten Erfahrungen auf Mobile Apps und Desktop-Anwendungen übertragen werden.

Literatur 1. ABI Aktionsbündnis für barrierefreie Informationstechnik: online http://www. abi-projekt.de/startseite/, zuletzt geprüft am 23.07.2012. 2. BITV-Test (Prüfverfahren für die Prüfung der Barrierefreiheit von informationsorientierten Webangeboten): online http://www.bitvtest. de/, zuletzt geprüft am am 23.07.2012. 3. BIENE (Wettbewerb, der die besten

Unser Ziel ist es, eine Checkliste im Umfang von maximal 2 DIN-A-4-Seiten zu erstellen, die Usability Professionals zur Beurteilung einer Website verwenden können, die aber auch als Arbeitsmittel im Beratungsprozess einsetzbar ist. Die Checkliste wird zusammen mit Erläuterungen auf der Webseite des Arbeitskreises der German UPA veröffentlicht werden. Bestandteil der Checkliste ist darüber hinaus eine Anleitung zum Einsatz der Checkliste im Beratungsprozess.

barrierefreien Angebote im Internet auszeichnet): online http://www.biene-award. de/kriterien/, zuletzt geprüft am 23.07.2012. 4. BOA (Best of Accessibility) 2008: Symposium Barrierefreies Webdesign. Siehe dort Jan Eric Hellbusch, vertreten duch Kerstin Probiesch und Darius Nikolaus Krupinski, online http:// www.best-of-accessibility.de/index.php/ boa2008/programm2008#hellbusch, zuletzt geprüft am 23.07.2012

In unserem Vortrag werden wir die erste Fassung der Checkliste vorstellen und im Forum diskutieren. Praktische Anwendung durch möglichst viele der anwesenden Teilnehmer ist gewünscht, so dass wir vor der endgültigen Veröffentlichung diese Erfahrungsberichte und das Feedback berücksichtigen können. So soll Usability Professionals ein nützliches Werkzeug zum Testen und Beurteilen der Barrierefreiheit einer Website an die Hand gegeben werden.

149


mobile, responsive, accessible Möglichkeiten von Smartphones und Tablets richtig nutzen

Stefan Farnetani mindscreen GmbH Erthalstr. 1 55118 Mainz farnetani@mindscreen.de

Thomas Heilmann mindscreen GmbH Erthalstr. 1 55118 Mainz heilmann@mindscreen.de

Alexander Götze labDigital Franklinstr. 22 01069 Dresden alexander.goetze@activr.eu

Rebecca Rothfuß macio GmbH Am Kiel-Kanal 1 24106 Kiel rebecca.rothfuss@macio.de

Abstract Seit einiger Zeit macht unter Webdesignern Luke Wroblewskis Mantra „Mobile first!“ die Runde. Die Kernidee: Lasst uns die einschränkenden Rahmenbedingungen von mobilen Geräten gleich von Beginn eines Projektes an produktiv nutzen, um uns auf das zu konzentrieren, was für den Nutzer einer Website oder Applikation wirklich wichtig ist – das führe auch zu einer besseren Usability bei der jeweiligen Desktop-Variante. Ein ähnliches Argument greift für die Zugänglichkeit: Ist die Barrierefreiheit von Anfang an Teil des Konzepts, führt das automatisch zu einer besseren Benutzbarkeit für alle. Wir zeigen, wie „Mobile first“ und „Accessibility first“ in Techniken wie dem „Responsive Design“ zusammenfinden, stellen anhand von Beispielen und Prototypen die wichtigsten Regeln für die Zugänglichkeit von mobilen Websites, Shops und Applikationen vor und loten die praktischen Möglichkeiten aktueller Smartphones, Tablets und Embedded Devices aus.

1. Schnittmengen (mobile / accessible) In den letzten Jahren haben sich die Zugriffswege auf das Internet vervielfältigt: Neben dem klassischen Desktop-Rechner und dem Laptop wird mehr und mehr über Tablets und Smartphones auf das Internet zugegriffen. 29% der deutschen Bevölkerung besitzen bereits ein Smartphone (vor einem Jahr waren es nur 18%), 64% davon nutzen das Internet täglich via Smartphone (Google 2012). Nicht zuletzt deshalb werden Konzepte wie „Mobile First“ (Wroblewski 2011) oder das „Responsive Design“ (Marcotte 2011) immer populärer: Als Usability Professionals müssen wir uns zwangsläufig der heterogenen Gerätelandschaft stellen und die veränderten technischen Rahmenbedingungen in unsere Arbeitspraxis einbeziehen. Wir können uns nicht mehr darauf verlassen, dass der User das Menü einer Website mit der Maus bedient, dass ein Bildschirm mit weniger als 1024px Breite die große Ausnahme ist

150

oder dass unsere 10px große Schrift auf einem Smartphone-Display noch lesbar ist (zumal sich vielleicht auch gerade noch die Sonne im Display spiegelt). Insbesondere im Umfeld der Barrierefreiheit beschäftigt man sich schon lange mit alternativer Inhaltsausgabe (z. B. Screenreader), alternativen Steuerungsmöglichkeiten (z. B. Bedienung ausschließlich per Tastatur) und zugänglicher Gestaltung (z. B. ausreichende Schriftgrößen und Kontraste). Aufgrund der rasanten Diversifizierung der Endgeräte haben diese Themen in den letzten Jahren deutlich an Bedeutung gewonnen. Bereits in den späten 90er Jahren formulierte das W3C „Web Content Accessibility Guidelines“. Anfang des Jahrtausends gewann die Barrierefreiheit an Beachtung – insbesondere aufgrund entsprechender Gesetzgebung in den USA (Section 508, 1998) und schließlich auch in Deutschland (Barrierefreie

Stefanie C. Zürn s.c.z. kommunikationsdesign 28209 Bremen zuern@s-c-z.de

Keywords: /// Barrierefreiheit /// Accessibility First /// Responsive Design /// Mobile First /// Touch Interfaces

Informationstechnik-Verordnung, 2002); mobile Endgeräte dagegen blieben mangels Verbreitung noch weitgehend außen vor. Heute scheint zumindest hierzulande die Lage anders zu sein: Das Thema „Mobile“ ist in aller Munde, während die Barrierefreiheit als Nischenthema behandelt wird. Dabei sollte man meinen, dass das geschärfte Bewusstsein für die Heterogenität der Geräte auf der einen und für die teils eingeschränkten Möglichkeiten mobiler Interfaces auf der anderen Seite Verfechtern der Barrierefreiheit in die Hände spielt – schließlich sind hohe Geräteunabhängigkeit und alternative Steuerungsmöglichkeiten zentrale Anforderungen der Barrierefreiheit. Doch bisher scheinen die Ideen hinter der Barrierefreiheit nur sehr partiell ihren Weg in die Praxis von UX-Designern und Entwicklern gefunden zu haben.


Usability Professionals 2012 Arbeitskreise German UPA

2. Wege zur Zugänglichkeit 2.1. Technische Voraussetzungen Immer noch stößt man – auch bei Experten der Interaktiv-Branche – auf die Meinung, Touchscreens könnten von Blinden ohnehin nicht verwendet werden, da sie keine tastbaren Knöpfe haben. Seit dem iPhone 3GS ist das Gegenteil der Fall: Viele Blinde empfinden das Gerät als einfacher und intuitiver zu benutzen als bisherige Mobiltelefone und Smartphones (vergleiche dazu zum Beispiel die eindrücklichen Erfahrungsberichte von Seraphin 2010 und Zehe 2009). Die einfache und bestechende Idee hinter der sogenannten VoiceOver Technologie von Apple: Dem Nutzer wird das Element vorgelesen, das er berührt. Ein sehbehinderter Nutzer kann so nicht nur die Inhalte, sondern (anders als mit einem klassischen Screenreader) sogar die räumliche Anordnung der Inhalte auf dem Bildschirm erfahren. Apple hat damit die gesetzlichen Auflagen in eine Chance verwandelt, ein besseres Produkt konstruiert und sich damit nicht zuletzt weitere Marktanteile gesichert und treue Kunden gewonnen. Andere Gerätehersteller und Entwickler von Betriebssystemen ziehen nach. Auch wenn Einrichtung und Bedienung noch deutlich komplizierter sind als bei den Geräten von Apple, bringt beispielsweise Android 4 den mit VoiceOver vergleichbaren Explore-by-Touch-Modus mit. Viele Geräte ermöglichen auch andere Accessibility-Features wie Schriftvergrößerung und stärkere Kontraste. Und dank des „21st Century Communications and Video Accessibility Act“ sind die Geräte- und Softwarehersteller in den USA inzwischen noch stärker zur Barrierefreiheit verpflichtet. Was bedeutet das aber für die ContentEntwicklung, was muss bei der Erstellung von Websites und Applikation beachtet werden?

2.2. Separation vs. Inklusion

sehenden Nutzer gemeinsam am gleichen Rechner arbeitet.

Um die Probleme, die Menschen bei der Nutzung von Websites mit Mobilgeräten haben, zu lösen, gibt es zwei verschiedene Ansätze. Der erste Ansatz favorisiert die Erstellung separater mobiler Websites parallel zur Desktop-Seite; der zweite Ansatz fordert die Erstellung universeller Websites, die sich an die jeweils eingesetzten Endgeräte anpassen.

Ein Stück weit annähern kann man sich der beobachteten Frustration mit der soziologischen Terminologie von Exklusion, Separation, Integration und Inklusion. Besonders spannend ist die Unterscheidung zwischen Integration und Inklusion: Bei der Integration wird das Individuum in die bestehenden Strukturen eingegliedert, bei der Inklusion dagegen werden die bestehenden Strukturen so geändert, dass die Heterogenität der Individuen zur Normalität wird. Überträgt man diese soziologische Begrifflichkeit in die Welt der Usability Professionals, stößt man auf Begriffe wie das Universal Design. In der Welt des Webdesigns kann das Responsive Design ein Baustein inklusiver Strategien sein, die verschiedene Geräte und Displaygrößen als Normalität voraussetzen (vgl. Tabelle). [Tab. 1]

Ein prominenter Vertreter des ersten Ansatzes ist Usability-Experte Jakob Nielsen: „Two designs, two sites, and cross-linking to make it all work“ (Nielsen 2012). Ein wenig lässt diese Lösung an Zeiten denken, als man häufig Links zu barrierefreien Versionen auf Websites fand, die selbst nur eingeschränkt zugänglich waren – und offenbar würde Nielsen auch heute noch am liebsten für jede Behinderung ein eigenes Interface erstellen, wenn das nicht so teuer wäre (Nielsen 2012b). Aus gutem Grund ist aber die Lösung über eine separate barrierefreie Version heute so gut wie ausgestorben; ähnliche Vorbehalte gelten für die meisten separaten Mobile-Websites. Besonders problematisch ist die Annahme von genuin mobilen Nutzungsszenarien anhand des verwendeten Endgeräts; zum Beispiel ließe die Verwendung eines Smartphones immer darauf schließen, dass der Nutzer unterwegs ist. Ein Großteil der Internetnutzung mit einem Smartphone findet zu Hause mit WLAN-Verbindung statt, die Nutzungsszenarien konvergieren über Gerätegrenzen hinweg. Schränkt man Inhalte vor dem Hintergrund eines vermuteten mobilen Use Case ein, kann das schnell zu Frustration beim Nutzer führen. Ähnliches gilt für eine Nur-Text-Version, die vermeintlich für Blinde besonders geeignet ist: Nutzt der sehbehinderte User die erwähnte VoiceOver-Technologie, ist er nicht mehr gezwungen, sich ausschließlich linear durch den Inhalt zu bewegen, und das Layout bekommt auch für den Blinden eine praktische Relevanz. Zudem kann es sein, dass ein blinder Nutzer mit einem

2.3. Responsive Design / Mobile first Das Grundprinzip des Responsive Design ist nicht neu: Das Layout einer Website soll sich an die jeweilige Displaygröße anpassen. Flexible Grids, die nicht mit Pixelwerten, sondern mit Prozentangaben arbeiten, ermöglichen eine Anpassung von z. B. Spaltenbreiten schon lange. Bei einem dreispaltigen Layout auf einem sehr kleinen Bildschirm würde das aber zu viel zu kleinen Spalten führen. Mit CSS3 Media Queries, die inzwischen von den meisten wichtigen Browsern unterstützt werden, kann man heute das Layout noch spezifischer für verschiedene Bildschirmgrößen anpassen; neben einer Veränderung des Spaltenflusses geht es meist auch um eine Anpassung der Navigation sowie insgesamt um ein ausgewogenes, den jeweiligen Größenverhältnissen angepasstes Layout. Da wir nicht wissen, mit welchen Geräten wir es zu tun haben, wird die Darstellung und das Verhalten einer Seite nicht für spezifische Geräte optimiert und angepasst, sondern für bestimmte Geräteeigenschaften (Geräte-Agnostik). Wir erstellen

151


Soziologie

Mobile Web

Accessible Web

Exklusion

Von Gesellschaft ausgeschlossen

Keine sinnvolle Nutzung möglich

Keine sinnvolle Nutzung möglich

Separation

Eigene Mobile Website mit Individuum kann geselleingeschränkten Inhalten schaftlich aktiv sein, aber nicht als Teil der Gesellschaft und Funktionen

Integration

Individuum ist in Gesellschaft integriert, aber nicht Teil der Normalität

Spezifische Optimierung für bestimmte Geräte / Geräteklassen

Integration von Funktionen zur Barrierefreiheit als Zusatz (z. B. Styleswitcher)

Inklusion

Heterogene Gesellschaft ist Normalität

Flexibles Layout, das sich an verschiedene Größen anpasst (Heterogenität der Geräte ist Normalität)

Barrierefreiheit ist Teil von Webstandards; Universelles User-Interface-Design

Eigene barrierefreie Website (zum Beispiel Nur-Text-Version)

also keine iPhone-spezifischen Stylesheets, sondern Stylesheets für Displaygrößen kleiner oder größer x (vgl. Abb. 1). [Abb. 1]

Einschränkungen, die kleine Displays und andere Navigationsmöglichkeiten mit sich bringen, werden als Chance begriffen, die Usability insgesamt zu steigern.

der Entwicklungsstrategie „Progressive Enhancement“ basiert, kann das Responsive Design seine Potentiale wirklich ausspielen.

Für die meisten Designer ist der Ausgangspunkt bei der Gestaltung die „normale“ Desktop-Website. Diese wird dann nachträglich auf eine Mobilvariante reduziert. Der umgekehrte Ansatz – bekannt unter Luke Wroblewski Schlagwort „Mobile First“ – kann dagegen in mehrerlei Hinsicht gewinnbringender sein. Wird mit dem Design für Mobilgeräte noch vor einer Desktopvariante begonnen, muss man sich zwangsläufig auf das Wesentliche konzentrieren. Von dieser Fokussierung profitieren auch die anderen Varianten einer Applikation oder Website. Anders gesagt: Die

Auf der technischen Seite entspricht das dem Progressive Enhancement: Eine von möglichst vielen Endgeräten problemlos verarbeitbare Version einer Seite wird entsprechend den technischen Möglichkeiten des konkreten Clients Schritt für Schritt erweitert. So werden auf Mobilgeräten keine unnötigen Daten (z. B. große Bilder) geladen – und Geräte, die z. B. keine Media Queries unterstützen, erhalten trotzdem eine navigierbare Version der Seite.

2.4. Mobile Barrierefreiheit/ Accessibility first

152

Erst mit einem Konzept, das auf der Design-Philosophie „Mobile First“ und auf

Nimmt man die vorgestellten Ansätze ernst, entwickelt man eine robuste Applikation, die mit verschiedenen Geräten bedienbar ist, deren Inhalte auf verschiedene Arten dargestellt werden können und in verschiedenen Formen wahrnehmbar und für den Benutzer verständlich sind. Das sind bereits die Grundforderungen der WCAG 2.0 und der Schritt zur Barrierefreiheit ist nicht mehr weit: „Bedienbar“ heißt


Usability Professionals 2012 Arbeitskreise German UPA

Abb. 1. Ausgehend von der weitgehend linearisierten Darstellung auf mobilen Geräten passt sich das Layout den Geräteeigenschaften an

dann auch bedienbar ohne Maus (oder mit einem Touchscreen oder mit aktiviertem VoiceOver oder bei linearisierter Darstellung der Seite), „wahrnehmbar“ auch wahrnehmbar für Menschen mit eingeschränktem Seh- oder Hörvermögen (oder bei schlechten Lichtverhältnissen oder am lauten Flughafen) und „verständlich“ auch verständlich für ältere Menschen (oder wenn man sich in der U-Bahn nur schwer konzentrieren kann). Dennoch wird in der Praxis der entscheidende Schritt zur Barrierefreiheit selten gemacht. Meist ist das Projekt so gut wie abgeschlossen, wenn ein Accessibility Audit durchgeführt wird. Der RefactoringAufwand, um die gefundenen Probleme zu lösen, ist dann schnell zu hoch – genauso wie die Frustration bei den Projektbeteiligten. Der Ansatz von Mobile First und Responsive Design impliziert bereits häufige Iterationen und enge Zusammenarbeit von Konzepter, Designer und Entwickler: Responsive Design muss von Anfang an in Prototypen getestet und weiterentwickelt werden, um wirklich praxistauglich zu werden. Das gleiche gilt für die Barrierefreiheit: Schon in der Konzeptions- und

Designphase muss die Zugänglichkeit eine der zentralen Zielvorgaben sein; frühzeitige Tests von Prototypen (auch durch Betroffene) sind unumgänglich. Gerade im Zusammenspiel mit dem Mobile First Ansatz lassen sich die Schnittmengen nutzen, um bei allen Stakeholdern ein Bewusstsein und einen Willen zur Accessibility aufzubauen („Kann ich dieses Interface auch nutzen, wenn ich im Auto sitze und nur zwei Lenkrad-Tasten zur Bedienung meines Smartphones zur Verfügung habe?“). Maximale Zugänglichkeit schließt nicht nur klassische assistive Technologien wie Screenreader ein, sondern selbstverständlich auch mobile Endgeräte (und deren assistive Technologien). Ähnlich wie man mit dem „Mobile First“-Ansatz die mobilen Einschränkungen aufwertet und produktiv nutzt, sollte man auch die Aspekte der Barrierefreiheit nicht als nachträgliche, separate Anforderung ansehen, sondern als Instrument der Fokussierung und der Steigerung von User Experience und Zugänglichkeit allgemein (nicht ohne Grund findet man in Apples technischen Handbüchern die Accessibility im UX-Kapitel). Diesen Ansatz könnte man „Accessibility First“ (Quesenbery 2010) nennen.

3. Nach dem Spiel ist vor dem Spiel 3.1. Offene Fragen Anders als für Desktop Websites ist gutes Material zur barrierefreien Entwicklung mobiler Seiten und Applikation noch rar. Zwar ist der Standard für barrierefreie Webentwicklung – die WCAG 2.0 – geräteunabhängig formuliert und ist somit auch auf mobile Websites anwendbar; doch die Techniken, die Implementierungshinweise für die jeweiligen Guidelines, sind klar an Desktop-Rechnern ausgerichtet. Hinweise für barrierefreie Gestensteuerung, eines der zentralen Themen von Touchscreen-Interfaces, sucht man beispielsweise vergebens. Die „Mobile Web Best Practices“ des W3C sind in vielen Punkten nicht zeitgemäß, und auch der Versuch, sie mit der WCAG in Relation zu setzen, trägt neuen Techniken nicht Rechnung. Es ist noch offen, auf welcher Ebene Ansätze zur Zugänglichkeit von neuen Eingabemöglichkeiten mittelfristig anzusiedeln sind. Ist es Sache des ContentEntwicklers, sich um Alternativen zu kümmern? Soll es Sache von erweiterten

153


Webstandards und in der Folge Sache des Browsers oder sogar des Betriebssystems sein, Touch-Gesten zu normalisieren und alternative Zugangswege zu schaffen? (Vergleiche dazu die Diskussion auf dem Mobile Accessibility Online Symposium des W3C am 25. Juni 2012, http://www. w3.org/WAI/RD/2012/mobile.) Bis diese Fragen geklärt sind, ist es in Ermangelung anderer Standards Aufgabe des Content-Entwicklers, für spezielle Eingabeformen wie die Gestensteuerung Alternativen im Interface vorzusehen. Die Kriterien der WCAG 2.0 (Tastatursteuerung etc.) bieten trotz aller Mängel auch bei der Entwicklung für mobile Endgeräte einen sicheren Ausgangspunkt. Damit ist das Interface sogar für einen User, der nur ein 1-Bit-Eingabegerät (Taster) zur Verfügung hat, steuerbar. 3.2. Native App vs. Webapp Wir haben uns hauptsächlich auf Websites und Webapplikationen bezogen; das Feld der nativen Applikationen blieb dabei weitgehend außen vor. Für die Entwicklung von nativen Applikationen für Apple-Geräte steht eine umfangreiche Dokumentation für Entwickler zur Verfügung, in der auch erläutert wird, wie barrierefreie Apps für die Geräte erstellt werden können (das schließt die korrekte Auszeichnung von Eingabeelementen genauso ein wie beispielsweise Empfehlungen für die Minimalgröße von Buttons und anderen Interaktionselementen). Auch für Android-Entwickler gibt es Accessibility Guidelines. Selbst wenn man keine native App umsetzt, können die Empfehlungen Anregungen für die Entwicklung von Webapplikationen geben. Die Trennschärfe zwischen Webapplikationen und nativen Applikationen wird in Zukunft ohnehin mehr und mehr abnehmen, so dass Webstandards zur Barrierefreiheit auch für Apps angewendet werden können.

154

3.3. Accessibility Experten in der Pflicht

Touch-Oberflächen mit haptischem Feedback.

Obwohl eine Website mobil nicht oder nur sehr eingeschränkt zugänglich ist, kann man durchaus WCAG 2.0-Konformität für sie behaupten, wenn man als Zielgerät nur Desktop-Browser im Blick hat. Genauso kann man den BIK BITV-Test bestehen, dessen Prüfschritte sich klar an DesktopRechnern orientieren.

Bei Touch-Oberflächen vermissen insbesondere Bediener, die in ihrer Sehfähigkeit eingeschränkt sind, ein direktes Feedback wie den Widerstand einer mechanischen Taste oder eines mechanischen Reglers. Bei Bedienern ohne eine Sehschwäche wird es interessant sein zu beobachten, ob die Generation, die überwiegend mit Touch-Oberflächen aufwächst, das Leerstellengefühl ebenso vermisst wie Personen, die den Tastenhub noch aus der Realität kennen (Dorau 2011).

Als umsetzende Agentur muss man sich aber heute die Frage stellen, ob man eine Website als barrierefrei verkaufen kann, wenn sie mobil nicht zugänglich ist. Bei einer Beschränkung auf Desktop-Umgebungen laufen Accessibility-Experten Gefahr, von ihren eigenen Argumenten widerlegt zu werden: Ein Argument für barrierefreie Seiten war nicht zuletzt schon früh die größere Geräteunabhängigkeit (und damit die bessere Nutzbarkeit auf Mobilgeräten). An der Einlösung dieses Versprechens müssen die Experten angesichts der veränderten technischen Möglichkeiten nun aktiv arbeiten – zum Beispiel durch den Einsatz von Responsive Design und der Berücksichtigung neuer Technologien wie VoiceOver. Gerade über das Thema „Mobile“ kann die Barrierefreiheit so weiter zu einem generischen Ansatz von Zugänglichkeit aufgewertet werden, bei dem es nicht um die lästige und aufwändige Integration von Randgruppen geht, sondern um eine breite Inklusion verschiedener Menschen, Geräte und Zugangswege. 3.4. Beyond mobile: Das Forschungsprojekt TikTak Die Diversifizierung der Geräte hört nicht bei mobilen Geräten auf. Fernseher und Spielekonsolen erhalten Internetzugang, in vielen Bereichen kommen individuelle Embedded Devices zum Einsatz. Dabei gilt es, neue Probleme und Möglichkeiten der Zugänglichkeit auszuloten und ggf. auch für bestehende Geräte und Interfaces zu nutzen. Das Forschungsprojekt TikTak betrachtet vor diesem Hintergrund

Aufgrund der Tatsache, dass immer mehr Embedded Geräte im häuslichen Umfeld Einzug halten, touch-bedienbare Anwendungen aber selten auf die speziellen Bedürfnisse für Anwender mit Einschränkungen zugeschnitten sind, wurde dieses Projekt gestartet. Es sollte eine DemoAnwendung auf einem Embedded Gerät mit haptischem Feedback für Bediener mit einer stark eingeschränkten Sehfähigkeit, die aber nicht blind sind, entwickelt werden, wobei der Ansatz des „Mobile First“ zum Tragen kam. Um die Anwendung auf die speziellen Themen der Barrierefreiheit zu konzentrieren, wurden im gewählten einfachen Szenario einige Annahmen als gegeben vorausgesetzt. Das Kernstück der Anwendung ist eine analoge Uhr, die dem Benutzer durch ihre haptischen Eigenschaften eine Übersicht über die Medikamenteneinnahme vermittelt. Anstatt der üblichen Stunden- und Minutenzeiger verfügt die Uhr über einen einzigen Zeiger, der für den Bediener durch entsprechende Dimensionierung sowie Form- und Farbgebung deutlich sichtbar gestaltet ist. Tastet der Nutzer mit seinem Finger die Uhr ab, so erhält er an den mit Terminen hinterlegten Uhrzeiten ein Feedback, das durch Vibrationen des Displays erzeugt wird. Das heißt, dass zu dieser Uhrzeit Medikamente eingenommen werden müssen. Die zugehörige Uhrzeit wird zur Verdeutlichung an anderer Stelle stark vergrößert dargestellt.


Usability Professionals 2012 Arbeitskreise German UPA

vom Tag- zum Nachtmodus automatisch aufgerufen. Termine können maximal für die nächsten zwei Tage im Voraus erfragt werden; in der Vergangenheit liegende Termine sind nicht mehr erreichbar.

Literatur 1. Dorau, Rainer (2011). Emotionales Interaktionsdesign. Berlin: Springer 2. Google / Ipsos (2012). Unser mobiler Planet: Deutschland. http://services.google.com/ fh/files/blogs/our_mobile_planet_germany_

Abb. 2. Scribble aus der Konzeptphase

Durch einen mit verstärkter Kraft ausgeführten Fingerdruck auf das Display kann der Bediener Informationen zur Medikamenteneinnahme zur ausgewählten Uhrzeit abrufen. Die Informationen öffnen sich in einer neuen Bildschirmansicht und werden durch leicht unterscheidbare Symbole dargestellt. Die Einnahme eines Medikaments kann durch einen verstärkten Fingerdruck auf die zugehörige Medikamenten-Darstellung bestätigt werden. [Abb. 2] Um die Medikations-Übersicht nicht auf die durch eine analoge Uhr dargestellten zwölf Stunden zu begrenzen, wurden weitere Gesten zur vereinfachten Bedienung vorgesehen. Mit einer Long-Touch-Geste auf einer beliebigen Stelle des Displays kann der Anwender über die auf 12 Stunden begrenzte Jetztzeit hinaus zukünftige Informationen ertasten. Damit eine eindeutige Zuordnung der angezeigten 12 Stunden in den Tagesablauf möglich ist, wird zwischen 6 Uhr morgens und 6 Uhr abends der Tagmodus angezeigt, in den übrigen Zeiten der Nachtmodus. Durch kreisen des Fingers auf der Uhr wird der Wechsel

Die Anwendung TikTak wurde für diesen einen Zweck optimiert, dadurch wurde nicht nur die Übersichtlichkeit verstärkt, sondern auch die Bediensicherheit erhöht. Das Grundlayout wurde großzügig fast über das gesamte Display angelegt, so dass es in jedem Fall zu erkennen ist. Die Hauptbedienung erfolgt über eine Geste, die auf dem gesamten Display ausgeführt werden kann. Ausgehend von der Voraussetzung, dass ein visuelles Feedback von drückbaren Schaltflächen nicht identifiziert werden kann, wurde hier das haptische Feedback eingesetzt. Die punktuell eingesetzten Farben dienen nicht der Dekoration, sondern wurden gezielt für die verschiedenen Zustände, auch in Hinsicht auf eine eventuelle Farbfehlsichtigkeit des Anwenders, ausgewählt. Die wenigen Texte wurden in einer großen Schriftgröße mit einer vor dem Hintergrund kontrastreichen Schriftfarbe an eindeutiger Stelle platziert.

de.pdf (30.07.2012) 3. Marcotte, Ethan (2011). Responsive Web Design. New York: A Book Apart 4. Nielsen, Jakob (2012). Mobile Site vs. Full Site. Alertbox. http://www.useit.com/ alertbox/mobile-vs-full-sites.html (30.07.2012) 5. Nielsen, Jakob (2012b). Repurposing vs. Optimized Design. Alertbox. http://www. useit.com/alertbox/repurposing.html (30.07.2012) 6. Quesenbery, Whitney (2010). Accessibility First – for a Better User Experience for All. UXmatters. http://www.uxmatters. com/mt/archives/2010/12/accessibilityfirstfor-a-better-user-experience-for-all.php (30.07.2012) 7. Seraphin, Austin (2010). My First Week with the iPhone. Behind the Curtain. http://behindthecurtain.us/2010/06/12/ my-first-week-with-the-iphone (30.07.2012) 8. Wroblewski, Luke (2011). Mobile First. New York: A Book Apart 9. Zehe, Marco (2009). Das zugängliche iPhone 3G S – ein Erfahrungsbericht. Marco

Als Touch-Komponente kommt ein Projected Capacitive Touch-Sensor zum Einsatz, der unter anderem die wahrgenommene Berührung des Sensors durch den Finger des Bedieners und somit auch die genaue Position an das Betriebssystem leitet. Zur Verarbeitung der Daten kommt ein Embedded System (Intel Atom CPU 1,60 GHz) zum Einsatz.

Zehe EDV-Beratung. http://www.zehe-edv. de/2009/08/04/das-zugangliche-iphone-3g-sein-erfahrungsbericht (30.07.2012)

Richtlinien & Umsetzungshinweise 1. Accessibility Programming Guide for iOS. https://developer.apple.com/library/ ios/#documentation/UserExperience/ Conceptual/iPhoneAccessibility/Introduction/ Introduction.html (30.07.2012)

Zum Redaktionsschluss waren wir noch auf der Zielgeraden der Implementierung. Aber wenden Sie sich jetzt gerne persönlich an uns, um die Ergebnisse zu erfahren!

2. Android Developers Accessibility. http:// developer.android.com/guide/topics/ui/ accessibility/index.html (30.07.2012) 3. BIK BITV Test. http://www.bitvtest.de (30.07.2012) 4. Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG). http://www. w3.org/TR/mwbp-wcag (30.07.2012) 5. Web Content Accessibility Guidelines 1.0. http://www.w3.org/TR/WCAG10 (30.07.2012) 6. Web Content Accessibility Guidelines (WCAG) 2.0. http://www.w3.org/TR/WCAG (30.07.2012)

155


Nachhaltige Barrierefreiheit in Websites Die Bedeutung der Redakteure für die Qualitätssicherung

Harald Weber Institut für Technologie und Arbeit (ITA) Trippstadter Straße 110 D-67663 Kaiserslautern harald.weber@ita-kl.de

Brigitte Bornemann BIT Design für Barrierefreie Informationstechnik GmbH Rödingsmarkt 43 D-20459 Hamburg bb@bit-informationsdesign.de

Abstract Die Barrierefreiheit von Internetpräsenzen ist gesetzliche Pflicht für Bundesbehörden und zahlreiche weitere öffentliche Einrichtungen. Die Einhaltung der Vorgaben erweist sich jedoch in der Praxis als schwierig. Viel beleuchtet wurden bisher die Best Practices eines barrierefreien Webdesigns. Fallstudien zeigen jedoch, dass 2/3 der Fehler in puncto Barrierefreiheit auf der Ebene der Content-Pflege entstehen. In der täglichen Nutzung eines einmal eingerichteten, anfangs noch relativ barrierefreien CMS geht die Barrierefreiheit vielfach wieder verloren. Eine entscheidende Rolle für die nachhaltige Implementierung der Barrierefreiheit in einem Webprojekt spielen Redakteure und Autoren, ihre Ausbildung und ihre Ausstattung mit geeigneten Arbeitsmitteln und Ressourcen. Dieser Vortrag wendet sich an Projektleiter und Consultants aus dem Bereich der Usability Professionals, die für die Umsetzung des Themas „Barrierefreiheit“ in den verschiedenen Phasen eines Webprojekts verantwortlich sind. Er beleuchtet speziell die Rolle der Redakteure und Autoren für die Erreichung und Erhaltung der Barrierefreiheit. Vorgestellt wird eine Sammlung von Arbeitsmaterialien für die Qualifizierung von Redakteuren sowie eine Projekt begleitende Strategie zur Entwicklung einer nachhaltigen Qualitätssicherung bzgl. Barrierefreiheit in der Produktion von Web Content.

1. Einleitung Im Vorfeld des Relaunch-Vorhabens für den Internetauftritt der German UPA wurde ein BITV-Test der aktuellen Website erstellt, um strategische Hinweise für die in Zukunft angestrebte Verbesserung der Barrierefreiheit zu gewinnen. Das Ergebnis war auf den ersten Blick überraschend: Es gab wohl wie erwartet Hinweise auf Grenzen des Content-Management-Systems und unkundiges Webdesign. Der Hauptteil der aufgedeckten Fehler, insgesamt zwei Drittel, lag aber auf Seiten der Contentpflege. Fehlende Allternativtexte, nicht ausgezeichnete Überschriften, unzureichende Untergliederung der Inhalte, nichtssagende Linktexte sind Mängel, die in der täglichen Arbeit der Redakteure entstehen. Ein Teil dieser Mängel könnte durch die Bereitstellung von Hilfen im Content-Management-System vermieden oder wenigstens vermindert werden. Im

156

Wesentlichen ist es aber die Qualifizierung der Redakteure, die die Barrierefreiheit der Website im Endergebnis gewährleistet. Diese Fallstudie unterstützt in unerwarteter Deutlichkeit eine Beobachtung aus der Praxis von Accessibility-Consultants: Der durch einen Relaunch erreichte Grad an Barrierefreiheit einer Webpräsenz verschlechterte sich oftmals schon nach kurzer Zeit wieder, ohne dass an der technischen Implementierung Veränderungen vorgenommen wurden. Redakteure und Autoren, die für die Erstellung der Inhalte verantwortlich waren, wurden dabei als einer der wichtigsten Faktoren für diesen beobachtbaren Effekt identifiziert. Neue Redakteure und Autoren kannten die Implikationen von Barrierefreiheit auf die Gestaltung von Inhalten ggf. nicht, alte Redakteure oder Autoren, die nur zeitweise und ggf. auch für andere Herausgeber Content verfassen, vergaßen das Erlernte mit der Zeit und fielen zurück in

Keywords: /// Barrierefreiheit /// Content-Pflege /// Redakteure /// Qualifizierung /// Qualitätssicherung

alte Arbeitsmuster. Die Herausforderung besteht daher darin, Projektleitern und Consultants aus dem Bereich der Usability Professionals die Relevanz der Rolle von Redakteuren und Autoren zu verdeutlichen und konkrete Vorgehensweisen zu entwickeln, um projektbegleitend Redakteure und Autoren auf eine dauerhafte, nachhaltige Gewährleistung von Barrierefreiheit vorzubereiten. 2. Hauptteil 2.1. Sensibilisierung Redakteuren und Autoren ist häufig nicht bekannt, welche Rolle sie bei der Gewährleistung von Barrierefreiheit spielen. Ein Grund dafür ist vermutlich darin zu sehen, dass das Thema zu lange nur in Kreisen von Programmierern diskutiert und vorangetrieben wurde. Auch schien das Thema mit dem Aufkommen erster Content


Usability Professionals 2012 Arbeitskreise German UPA

Management Systeme (CMS), die in der Lage waren, barrierefreies HMTL zu erzeugen, weitestgehend bearbeitet zu sein. Tatsächlich wurde durch die steigende Verbreitung von technisch barrierefreien Webseiten jedoch deutlich, dass auch die Inhalte, der Web Content, eine entscheidende Rolle dabei spielt, dass Nutzer eine faktische und nicht nur eine technische Barrierefreiheit erfahren können. Zwei grundlegende Standpunkte können dabei helfen, eine veränderte Sichtweise seitens der Redakteure und Autoren zu bewirken. Zum einen ist es ein Betonungswechsel auf die formale Qualität von Inhalten als Redakteurs- und Autorenaufgabe; es geht also nicht darum, Texte zu schreiben, sondern vielmehr darum, Informationen so zu gestalten, dass sie für die Zielgruppe wahrnehmbar und verständlich sind. Ist dieser Wechsel der Betonung akzeptiert, greift das zweite Statement. Caplan (1992) definierte Behinderung als die Unfähigkeit eines Menschen, sich an die Welt anzupassen so wie sie aktuell gestaltet ist. Vanderheiden (1997) hat dies nochmals zugespitzt und Behinderung als Unfähigkeit, sich an schlechtes Design anzupassen, definiert. Beide Aussagen machen deutlich, dass nicht die Behinderung eines Menschen das eigentliche Problem ist, sondern schlechtes Design, das eine gleichwertige Nutzung ver- oder behindert. Der zweite zu vermittelnde Standpunkt betrifft daher die Erweiterung der Palette dessen, was als gutes und was als schlechtes Content-Design bezeichnet werden muss. Nehmen Redakteure und Autoren ihre Aufgabe als Gestaltungsaufgabe wahr, dann bieten Schulungen zum Thema Barrierefreiheit ihnen die Möglichkeit, statt ein „spezifisches Design für behinderte Nutzer“ nun eine „Gutes Design für alle“ zu erlernen, das nicht nur für Menschen mit Behinderungen, sondern auch zahlreichen anderen Stakeholdern Vorteile bringt.

2.2. Schulung Schulungen fokussieren letztendlich auf den Wirkungs- bzw. Gestaltungsbereich von Autoren und Redakteuren. Ausgehend von CMS-seitig vorgegebenen Layouts (mit ihren jeweiligen Möglichkeiten und Einschränkungen) werden Gestaltungshinweise für jede Art strukturierten Contents vorgestellt und diskutiert. Dazu zählen bspw. die Gestaltung von Überschriften, Listen, Hervorhebungen, Sprachwechseln, Tabellen, Abkürzungen etc. Vertiefte Schulungen sind dort erforderlich, wo das CMS nur HTML-Eingaben erlaubt; vorteilhaft sind WYSIWYG-Editoren, die bereits alle zulässigen Strukturierungen in Form von Formatvorlagen anbieten und diese jeder Art von Content leicht zugewiesen werden können. In Bezug auf eine gute Leserführung widmet sich ein zweiter Schulungsteil der Gestaltung von Seitentiteln, Linktexten, Linktiteln, alternativen Texten oder Bildunterschriften. Ziel ist es dabei, prägnante Bezeichner zu entwickeln. Diese helfen allen Nutzern, insbesondere auch blinden Nutzern, sich schnell – visuell, akustisch oder taktil – einen Über“blick“ über eine Inhaltsseite zu verschaffen. Ein weiterer wichtiger Schulungsteil widmet sich schließlich der Sprache selber. Dabei steht die Verständlichkeit im Vordergrund, es geht also um Sprachniveau bzw. Sprachkomplexität. Je nach Zielgruppe muss dieses durch die Autoren angepasst und durch Redakteure überprüft werden. Einfache Sprache zu erstellen ist jedoch durchaus anspruchsvoll und – anfangs auch – zeitaufwändig. Hinweise und Richtlinien zur Gestaltung einfacher Sprache werden daher vorgestellt und eingeübt. 2.3. Aufbau bzw. Erweiterung eines Unternehmens-Styleguides Styleguides dienen Unternehmen dazu, allen an der Unternehmenskommunikation Beteiligten einen Gestaltungsstandard zu vermitteln. Dadurch soll sichergestellt

werden, dass bspw. Webseiten oder Print-Erzeugnisse trotz ggf. zahlreicher Beteiligter im Erscheinungsbild einheitlich wirken und die Marke des Unternehmens wiedererkennbar transportieren. Auch wenn der Begriff ‚Erscheinungsbild‘ die visuelle Komponente betont, beinhalten Styleguides auch darüber hinaus gehende Gestaltungsrichtlinien, bspw. Regeln für die Verwendung von Fremdworten, Sprachkomplexität, Schlüsselbegriffen, Multimedia-Inhalten etc. In Form eines Redakteurshandbuchs, das die vorbereiteten Gestaltungsmuster des ContentManagement-Systems im Detail vorstellt, wird der Styleguide zur praktischen Arbeitshilfe für die tägliche Arbeit der Redakteure. Styleguides dienen aber auch dazu, den Gestaltungsstandard überprüfbar bzw. auditierbar zu machen. Dies ist bspw. dann erforderlich, wenn Gestaltungsaufträge an externe Dienstleister vergeben werden oder die Einhaltung der Standards intern regelmäßig überprüft werden soll. Begleitend zur Schulung bietet es sich nun an, ein bestehendes Styleguide um Aspekte der Barrierefreiheit zu ergänzen (bzw. bei Nichtvorliegen ein neues Styleguide zu erstellen). Sofern ein Styleguide bereits vorliegt, ist dieses auf Kompatibilität zu den Anforderungen an die Barrierefreiheit zu prüfen. Dies betrifft insbesondere klassische ergonomische Aspekte wie bspw. Fonts, Schriftgrößen, Kontraste zwischen Texten und Hintergrund (insb. auch bei Hervorhebungen oder bei aktivem Fokus) usw. Viele, wenn nicht gar alle, dieser Aspekte werden üblicherweise den Redakteuren durch das CMS bereits abgenommen, eine einmalige Überprüfung in Bezug auf Barrierefreiheit ist jedoch angebracht. Auch wenn die Gestaltungsfreiheit der Redakteure durch ein CMS stark reglementiert erscheint, ist es in zahlreichen Feldern noch erforderlich, dass Unternehmen einen eigenen Style in Bezug auf Barrierefreiheit entwickeln, erproben und umsetzen. Dies betrifft bspw. die Sprache (Komplexität, sprachliche Präzision, Verwendung von Abkürzungen, sprachliche Konsistenz usw.),

157


die konkrete Gestaltung textueller Alternativen zu Multimedia-Inhalten, Konventionen zur Betitelung von Links, Tabellen, Abbildungen oder zur Gestaltung und Strukturierung längerer Texte. Weiterentwicklung der Unternehmensstandards

Öffentlichkeitsarbeit, dem CI/CD oder der Unternehmensleitung abzustimmen, bevor sie angegangen werden können. Dieser Schritt wird entweder periodisch ausgeführt oder durch eine der oben genannten Informationsquellen (d. h. Rückmeldungen, Beschwerden, Vorliegen von Benchmarkings oder Auditergebnissen) ausgelöst.

Um eine nachhaltige Barrierefreiheit in Websites zu gewährleisten, empfiehlt sich die Einrichtung eines internen Kontinuierlichen Verbesserungsprozesses (KVP). Ein KVP-Team ‚Barrierefreiheit‘ setzt sich die Konformitätsprüfung und die kontinuierliche Verbesserung des Styleguide hinsichtlich der Gewährleistung der Barrierefreiheit zum Ziel. Teilnehmer können Mitarbeiter der Bereiche Öffentlichkeitsarbeit, Corporate Identity / Corporate Design, ContentRedakteure, falls verfügbar auch Autoren sowie ggf. Qualitätsmanagementbeauftragte sein.

Do

Dieses Team sollte regelmäßig Inhalte (d. h. die ‚Produkte‘ der Autoren) auf Konformität mit den dort vereinbarten Gestaltungsrichtlinien prüfen (interner Audit). Damit können den Autoren individuelle Rückmeldungen gegeben, summarisch über alle Autoren betrachtet aber auch Hinweise auf ggf. erforderliche (Nach-) Schulungen abgeleitet werden. Die Häufigkeit dieser internen Audits hängt von der Anzahl der Autoren und der Häufigkeit von Online-Publikationen der Autoren ab, ein mindestens jährlicher Turnus wird jedoch empfohlen.

Check

In Bezug auf die Weiterentwicklung des Styleguide kann der bewährte PDCA-Zyklus (plan-do-check-act) verwendet werden, der im Folgenden näher beschrieben wird. Plan

Gespeist aus den Rückmeldungen von Autoren, aus Hinweisen oder Beschwerden von Nutzern, aus Benchmarks mit anderen Content-Anbietern oder aus den Ergebnissen der internen Audits entwickelt das KVP-Team einen Vorschlag zur Korrektur oder Weiterentwicklung des Styleguide. Ggf. sind Vorschläge mit Designern, der

158

Das Team setzt den Veränderungsvorschlag testweise um. Neben einem (Um-) Formulierungsvorschlag für das Styleguide kann dies auch bspw. die Dokumentation schlechter und guter Gestaltungsbeispiele in Bezug auf das adressierte Thema (z. B. zur Verwendung in Schulungsunterlagen und Handbüchern) oder die Entwicklung eines geeigneten Prüfinstruments (bspw. zur Unterstützung der Autoren und Redakteure oder des regelmäßigen Audits) beinhalten.

In dieser Phase wird der Veränderungsvorschlag auf seine Gebrauchstauglichkeit und Validität geprüft. Dies kann u. a. die Einbeziehung von Autoren zur Überprüfung bspw. der Verständlichkeit und Eindeutigkeit und die Einbeziehung von Endnutzern, also Lesern, zur Überprüfung der Wirksamkeit der Gestaltungsrichtlinie (d. h. verbesserte Barrierefreiheit) beinhalten. Act

Nach erfolgreicher Testung und Freigabe werden die Änderungen an alle Redakteure, Autoren und Schulungsleiter kommuniziert und in allen relevanten Dokumenten umgesetzt. Laufende und zukünftige Schulungen berücksichtigen ab diesem Zeitpunkt die Änderungen. Falls bspw. aus rechtlichen Gründen älterer Content auf den neuen Gestaltungsstandard angepasst werden muss, so erfolgt dies ebenfalls in diesem Schritt; entsprechende Ressourcen sind zu planen und durch die Unternehmensleitung zur Verfügung zu stellen.

Entwicklung einer positiven Fehlerkultur

Nachdem mit der vorgeschlagenen Vorgehensweise ein grundlegendes System zum Fehlermanagement aufgebaut werden kann, empfiehlt sich auch die Pflege einer dazu passenden positiven Fehlerkultur. Alle Aktivitäten sollten derart ausgestaltet und ‚gelebt‘ werden, dass damit eine eindeutige Nachricht an alle Beteiligten gesendet wird: aus Fehlern wollen wir lernen und (in Bezug auf Barrierefreiheit) besser werden. Damit verbietet es sich, Fehler seitens der Redakteure zu sanktionieren; vielmehr muss es darum gehen, Fehlerursachen zu verstehen und diese dauerhaft zu beseitigen. Dies beinhaltet wie bei allen organisatorischen Veränderungen die Betrachtung verschiedenster Gestaltungsoptionen: die ‚Veränderung‘ des Menschen (d. h. Schulung / Qualifizierung / Anleitung der Redakteure), die Veränderung der Organisation (z. B. in Bezug auf Redaktionsabläufe) oder die Bereitstellung technischer Unterstützung (z. B. Angebot teilautomatischer Konformitätstests für Autoren und Redakteure). Im Sinne einer verbesserten Einarbeitung neuer Autoren und Redakteure kann es auch sinnvoll sein, diese zeitweise in das KVP-Team mit aufzunehmen, so dass sie sich vertieft mit dem Thema auseinandersetzen. 4. Zusammenfassung Schulungen für Redakteure und Autoren sind wichtige Instrumente, um parallel zur Umsetzung eines Projektes zur barrierefreien Gestaltung einer Web-Präsenz dafür Sorge zu tragen, dass auch die Inhalte für Leser wahrnehmbar, nutzbar und verständlich sind. Soll der Content-Anbieter jedoch auch dazu befähigt werden, den einmal erreichten Level an Barrierefreiheit zu halten, dann bedarf es bspw. auch der Einrichtung eines KVP-Teams ‚Barrierefreiheit‘ zur dauerhaften Konformitätsprüfung und zur kontinuierlichen Verbesserung eines Anbieter-spezifischen Styleguide hinsichtlich Barrierefreiheit. Projektleiter und Consultants, die für die Umsetzung des Themas „Barrierefreiheit“ in den verschiedenen Phasen eines


Usability Professionals 2012 Arbeitskreise German UPA

Webprojekts verantwortlich sind, sollten dieses KVP-Team dann bereits parallel zum Umsetzungsprojekt initiieren, so dass es nach Ende des Projektes funktions- und arbeitsfähig ist. Literatur 1. DIAS GmbH (Hrsg): BITV-Test, InternetAuftritt des Projekts BIK â&#x20AC;&#x201C; Barrierefrei informieren und kommunizieren, http://www. bitvtest.de (30.07.2012) 2. Caplan, R. (1992). Disabled By Design. Interior Design, 63, August, 88-91. 3. Inclusion Europe (2009). Information for All. European standards on how to make information easy to read and understand for people with intellectual disabilities. Online: http://inclusion-europe.org/en/policies/ self-advocacy-and-accessibility/easy-to-readproject (27.07.2012) 4. Vanderheiden, G. C. (1997). Design for people with functional limitations resulting from disability, aging or circumstance. In G. Salvendy (Ed.), Handbook of human factors and ergonomics (pp. 2010-2052). New York, NY: John Wiley & Sons.

159


Der Qualitätsstandard für Usability Engineering der German UPA Aktueller Stand der Arbeiten Holger Fischer Universität Paderborn, C-LAB Fürstenallee 11 33102 Paderborn holger.fischer@c-lab.de

Oliver Kluge Versicherungskammer Bayern Maximilianstraße 53 80538 München oliver.kluge@vkb.de

Thomas Geis ProContext Consulting GmbH Von-Werth-Straße 33-35 50670 Köln thomas.geis@procontext.de

Christian Bogner Technische Universität Kaiserslautern Erwin-Schrödinger-Straße 57 67663 Kaiserslautern christian.bogner@sowi.uni-kl.de

Abstract In aktuellen Veröffentlichungen werden Prozesse des Usability Engineering diskutiert. So angemessen diese Unternehmensprozesse definiert sein mögen, so abhängig sind sie jedoch von den Personen, die am Prozess beteiligt sind. Besonders in kleinen und mittelständischen Unternehmen gewinnt die individuelle Kompetenz der Personen an Bedeutung, da diese oftmals mehrere Rollen nebeneinander ausüben und somit essentiell die Qualität des Ergebnisses im Projekt mitbestimmen. Auf Basis des UPA Qualitätsstandards und der Rollendefinition eines Usability Professionals der German UPA wird in diesem Workshop ein „Kompetenzrahmen Usability Engineering“ präsentiert und zur Diskussion gestellt. Dieser orientiert sich an Handlungsfeldern nutzungszentrierter Gestaltungsprozesse und formuliert rollenspezifisches Wissen, Fertigkeiten, sowie personale und soziale Anforderungen an einen Usability Professional. Das Ergebnis soll einerseits als Basis für ein einheitliches Curriculum in der Ausbildung und Qualifizierung zum Usability Professional dienen, andererseits aber auch den Rahmen für eine fundierte Personenzertifizierung festlegen.

1. Einleitung Die Gebrauchstauglichkeit (Usability) von Produkten, insbesondere von Softwareanwendungen, scheint heute sowohl in vielen Unternehmen, als auch bei deren Kunden, als Qualitätsmerkmal erkannt worden zu sein. Jedoch kann in der Praxis aufgezeigt werden, dass noch eine Vielzahl von Herausforderungen für eine angemessene Integration von Usability Engineering (UE) und Software Engineering (SE) bestehen (Seffah et al., 2005). Neben den offensichtlichen Auswirkungen der Gebrauchstauglichkeit hinsichtlich einer gesteigerten Effektivität, Effizienz und Zufriedenstellung bei den Nutzern bezogen auf die Erfüllung ihrer täglichen Aufgaben, handelt es sich ebenfalls um ein entscheidendes Attribut des Entwicklungsprozesses selbst (Fischer et al., 2011). Ein

160

systematischer menschzentrierter Gestaltungsansatz ist daher notwendig, um interaktive Systeme mit einer vorhersagbaren Gebrauchstauglichkeit zu entwickeln. Einige Unternehmen, insbesondere größere und international ausgerichtete, haben dies bereits erkannt und verwenden angemessene Prozesse und Methoden. Wissenschaft und Industrie liefern einen Beitrag auf diesem Gebiet und diskutieren Fragen und Probleme. Die daraus entstehenden Ansätze fokussieren dabei häufig auf die Spezifika der konkreten Unternehmen, so dass sie nicht oder nur mit viel Aufwand auf andere Unternehmen und Prozesse übertragen werden können. Besonders in kleinen und mittelständischen Unternehmen (KMU) der Softwareentwicklung in Deutschland (ausgeschlossen sind Usability Dienstleister) finden solche Ansätze kaum Anwendung (Woywode et al., 2012). Zudem weisen

Knut Polkehn artop GmbH Christburger Straße 4 10405 Berlin polkehn@artop.de

Keywords: /// Qualitätsstandard /// Usability Engineering /// Prozesse /// Zertifizierung /// DIN EN ISO 9241-210

KMU Lücken in Bezug auf das Wissen und die Erfahrung mit UE Methoden und UE Standards auf, was zu einem entscheidenden Wettbewerbsnachteil gegenüber Konkurrenten führt. Obwohl für eine wirklich gebrauchstaugliche Software weitaus mehr als Richtlinien und Standards nötig sind, tragen diese jedoch wesentlich zur Konsistenz, Qualität, einer guten Durchführung bei der Entwicklung und einem gemeinsamen Verständnis bzw. einer gemeinsamen Kommunikationsgrundlage bei (Stewart & Travis, 2003). Eine aktuelle Studie (Woywode et al., 2012) zeigt, dass lediglich 28 Prozent der befragten Unternehmen (bezogen auf eine Stichprobe von 2.000 Unternehmen und einer Rücklaufquote von 10 Prozent) UE Methoden aktiv verwenden. Des Weiteren liegt der Gebrauch von Standards bei gerade einmal 15 Prozent der befragten


Usability Professionals 2012 Arbeitskreise German UPA

Unternehmen, wobei diese größtenteils nur einen der zur Auswahl genannten Standards – neben DIN und ISO Standards waren auch UI Guidelines für MS Windows und Apple iOS aufgelistet – verwenden. Ein Verständnis über einen systematischen Ansatz zur Integration von Usability Engineering ist ebenfalls nicht gegeben. Drei wesentliche Hypothesen können daraus abgeleitet werden: 1. UE Standards sind in der Praxis nicht anwendbar und bedürfen einer Überarbeitung hinsichtlich ihrer Gebrauchstauglichkeit, sozusagen die „Usability of Usability“. 2. Unterschiedliche organisatorische Kulturen (bspw. flache Hierarchiestufen) bei KMU im Gegensatz zur großen Unternehmen führen dazu, dass die Expertise wie auch die Qualität der Ergebnisse verstärkt von einzelnen Personen statt von ganzen Abteilungen abhängt. 3. Es mangelt an einem Konsens über einen etablierten Wortschatz, einem einheitlichen Curriculum sowie vergleichbare und zertifizierbare Qualifikationen bzw. Kompetenzen. Diesen Herausforderungen nimmt sich der Arbeitskreis Qualitätsstandards der German UPA (siehe Abschnitt 2) an und hat dazu im April 2012 die erste Version eines Qualitätsstandards für Usability Engineering veröffentlicht (siehe Abschnitt 4). Dieser soll grundlegend dazu beitragen, existierende Prozessstandards zugänglicher zu machen sowie Anforderungen an die Kompetenzen eines Usability Professionals zu definieren. Diese sollen als Rahmenwerk sowohl für die Qualifizierung als auch die Zertifizierung von Personen, die im Berufsfeld Usability tätig sind, gelten.

als auch aus Praktikern aus der Wirtschaft zusammen, welche in Normierungsgremien existierender Standards mitgewirkt und aber auch bereits einen menschzentrierten Gestaltungsprozess erfolgreich in kommerziellen Projekten etabliert haben. Der Arbeitskreis hat es sich zur Aufgabe gemacht, anhand von praktischen Erfahrungen einen Qualitätsstandard zu formulieren. Dieser soll den Zugang zu internationalen Standards vereinfachen, so dass Produkt- und Prozessverantwortliche unterschiedlicher Herkunft den Entwicklungsprozess verstehen, ihn verankern, aber auch einen konkreten Prozess mit Aktivitäten und daraus resultierenden Artefakten beschreiben können. Zugleich soll der Qualitätsstandard als Grundlage für die von der UXPA international und der German UPA angestrebte Personenzertifizierung dienen. 3. Usability Standards Standards können bei der Entwicklung gebrauchstauglicher interaktiver Systeme eine wesentliche Rolle einnehmen (Geis et al., 2010). Bereits in den späten 1970’ern wurde durch den deutschen Standard DIN 66 234 die Bedeutung ergonomischer Probleme bei Bildschirmarbeitsplätzen und grafischen Terminals adressiert. Dieser Standard sorgte für internationale Aufmerksamkeit, so dass sich die International Organization for Standardization (ISO) diesem DIN-Standard annahm und ihn in den ISO-Standard ISO 9241-10 überführte. Dieser ist heute als ISO 9241-110 beziehungsweise unter dem Begriff der „Dialogprinzipien“ bekannt (Stewart & Travis, 2003).

Bevan (2006) definiert in seiner Arbeit anhand der beabsichtigten Ziele von Standards vier Kategorien von Standards (siehe Abbildung 1). [Abb. 1] In die erste Kategorie lassen sich Standards einordnen, die die „Qualität in der Nutzung“, gemäß der in der Definition der Gebrauchstauglichkeit referenzierten Ziele Effektivität, Effizienz und Zufriedenstellung der Benutzer im Nutzungskontext betreffen. Dazu zählt vor allem der Standard ISO 9241-11, in welchem Leitsätze zur Gebrauchstauglichkeit definiert werden. Die Standardfamilie ISO 9241 beschreibt eine Richtlinie für die Ergonomie der Mensch-System-Interaktion und besteht aktuell aus 34 Teilen. So können die Teile 12, 13, 14, 15, 16 und 143 und der Teil 110 in die zweite Kategorie einsortiert werden, da diese Anforderungen an die Benutzungsschnittstelle von Bildschirmarbeitsplätzen formulieren und somit auf die „Qualität des Produktes“ abzielen. Damit das erstellte Produkt die Ziele der Qualität in der Nutzung und der Produktqualität erreichen kann, bedarf es eines menschzentrierten Gestaltungsprozesses. Ein Rahmenwerk für einen solchen Prozess wird im Standard ISO 9241-210 beschrieben. Die „Prozessqualität“ ist somit Ziel der dritten Kategorie. Ebenso lässt sich der technische Report ISO/TR 18529 in diese Kategorie einordnen, der eine Beschreibung von Prozessen mit Fokus auf menschzentrierte Ansätze beinhaltet und Komponenten, Ergebnisse, sowie die verwendeten und erzeugten Informationen auflistet. Die vierte Kategorie zielt auf organisatorische Fähigkeiten ab. Diese sind Voraussetzung für die Durchführung eines

2. Der Arbeitskreis Gegründet im Jahr 2009 auf der Usability Professionals in Berlin als Konsequenz des Workshops „Qualitätsstandards für Usability Professionals – welche sind das eigentlich?“, besteht der Arbeitskreis „Qualitätsstandards“ der German UPA derzeit aus vierzehn aktiven Mitgliedern. Diese setzen sich sowohl aus Wissenschaftlern, Abb. 2. Kategorien für Standards

161


menschzentrierten Gestaltungsprozesses. Die technische Spezifikation ISO/TS 18152 beinhaltet eine Spezifikation zur Bewertung von Prozessen mit dem Schwerpunkt der Mensch-System Belange und kann in diese Kategorie eingeordnet werden. Während in den genannten ISO-Standards kaum durchzuführende Aktivitäten explizit formuliert sind bzw. nur in einer Form, die selbst für Usability-Experten schwer zu verstehen ist, kann des Weiteren der Leitfaden Usability der Deutschen Akkreditierungsstelle (DAkkS) genannt werden. Dieser beschreibt die Methodik der Nutzungskontextanalyse, sowie die Spezifikation von Nutzungsanforderungen und Nutzungsszenarien. Eine Integration der Aktivitäten in den bestehenden Softwareentwicklungsprozess wird auf Basis der genannten Werke jedoch nicht unmittelbar sichtbar. Der Aufwand, Aspekte der Gebrauchstauglichkeit in vollem Umfang zu berücksichtigen, ist daher beispielsweise für Projektleiter oder Produktmanager hoch, da diese gegebenenfalls nur über ein grundlegendes Hintergrundwissen zu diesem Thema verfügen. Der Arbeitskreis Qualitätsstandards verfolgt daher das Ziel, die zuvor genannten Dokumente in einem „Qualitätsstandard für Usability Engineering“ lesbar und anwendbar zu formulieren. 4. Der Qualitätsstandard Der Qualitätsstandard adressiert unterschiedliche Zielgruppen mit divergenten Ansprüchen an die Durchführung eines menschzentrierten Gestaltungsprozesses (siehe Abbildung 2). Dazu gehören: –– Usability-Professionals, die für die gesamte Gestaltung bzw. das Management eines menschzentrierten Entwicklungsprozesses oder aber auch nur für eine spezifische Aufgabenstellung – wie z. B. „Usability Testing“ – eine konkrete Handlungsanleitung benötigen. –– Auftraggeber für Usability Professionals, die Projektfragestellungen mit Bezug auf Usability durch professionelles Personal bearbeiten lassen möchten und

162

Abb. 2. Zielgruppen und Verwendungszweck

Klarheit darüber benötigen, welche Fähigkeiten von diesen Personen gefordert werden. –– Weiterbildungs-Institute / Ausbilder für Usability-Professionals, deren Qualifizierungsmaßnahmen auf einem von der German UPA anerkannten Qualitätsstandard. –– Personal-Zertifizierungsstellen für Usability-Professionals, die UsabilityProfessionals bescheinigen, dass sie nachweislich über die im „German UPA Qualitätsstandard Usability Engineering“ geforderten Kenntnisse, Fertigkeiten und Kompetenzen verfügen. [Abb. 2] 4.1. Anwendung Um abhängig von den zuvor genannten Zielgruppen einen leichten Zugang zu den Inhalten im Standard zu ermöglichen, werden im Qualitätsstandard Einsatzszenarien aus dem alltäglichen Projektgeschäft definiert. Dabei handelt es sich um typische Ausgangssituationen, die mit den jeweils zu berücksichtigenden Abschnitten im Dokument verknüpft sind. Soll beispielsweise in einem neuen Release

erstmalig die Gebrauchstauglichkeit des Produktes berücksichtigt werden, so werden u. a. Empfehlungen ausgesprochen, die für einen sinnvollen ersten Schritt auf eine Analyse des Nutzungskontextes (einschließlich der Nutzer) und der Nutzungsanforderungen hinweisen, um diese mit dem existierenden Produkt abzugleichen und mögliche Mängel zu identifizieren. 4.2. Struktur Der Qualitätsstandard besteht im Wesentlichen aus der Erläuterung der einzelnen Prozessschritte (Beispiel siehe Abbildung 3). Dabei werden zur Beschreibung der Schritte die im technischen Report ISO/IEC TR 24774 formulierten Elemente eines Prozesses als Strukturierungsbasis verwendet. Die Durchführung eines Schrittes wird dabei durch den „Zweck des Prozesses“ begründet, sowie der Status einer erfolgreichen Durchführung eines Schrittes durch den „Zustand nach Durchführung“ definiert. Die Art der angemessenen und kommunizierbaren Dokumentation von Ergebnissen wird über das Element „Arbeitsprodukte“ angegeben. Über die „Empfohlenen Aktivitäten zur Durchführung“ werden


Usability Professionals 2012 Arbeitskreise German UPA

konkrete Aufgaben an die durchzuführende Person formuliert, damit die angestrebte Qualität des Ergebnisses erreicht wird. Des Weiteren werden die „beteiligten Prozessrollen“ den Prozessschritten zugeordnet, damit die jeweils notwenigen Personen hinzugezogen, informiert oder entsprechende Freigaben eingeholt werden. Dazu zählen zum einen die verschiedenen Rollen des Usability Engineerings (vgl. Bogner et al., 2011) als auch Rollen, die im gesamten Entwicklungsprozess aktiv sind (bspw. Projektleiter). [Abb. 3]

Damit die Rollen des Usability Engineering ihre Aufgaben angemessen bearbeiten und eine größtmögliche Gebrauchstauglichkeit des Produktes erzielen, bedarf es eines etablierten Qualifizierungsniveaus. Als Vorstufe bzw. Basis für eine mögliche Personenzertifizierung wird daher aktuell an einem Kapitel zum Kompetenzrahmen für Usability Engineering gearbeitet, welches nachfolgend kurz vorgestellt wird. 5. Kompetenzrahmen UE Derzeit mangelt es an einem einheitlichen Curriculum von Usability Professionals in Bezug auf Studiengänge und Ausbildungsabschlüsse (Woywode et al., 2012). Softwareunternehmen fällt es deshalb schwer, geeignetes Personal einzustellen bzw. auszuwählen, um das Themengebiet in den Entwicklungsprozessen berücksichtigen zu können. Basierend auf dem Rollenmodell des „Berufsfeld Usability“ der German UPA (Bogner et al., 2011) und den im Qualitätsstandard formalisierten Aktivitäten eines menschzentrierten Gestaltungsprozesses wird derzeit ein entsprechender Kompetenzrahmen für Usability Engineering formuliert, der in den Qualitätsstandard integriert werden soll.

Ein Usability Professional sollte daher in der Lage sein, definierte Handlungen durchzuführen sowie adäquate Methoden auszuwählen und anzuwenden, um qualitative Ergebnisse für seine Aufgabe zu erzielen. Da die Auswahl der Methode abhängig vom jeweiligen Kontext eines Projektes ist, sollten im Rahmen der Qualifizierung oder Zertifizierung von Personen keine bestimmten Methoden zwingend vorgeschrieben werden. Mit dem Kompetenzrahmen soll vielmehr eine verlässliche Basis geschaffen werden, anhand derer Usability Professionals geeignete Auswahlkriterien erlernen können, um im jeweiligen Handlungsfeld autonom die richtigen Entscheidungen treffen zu können. Zur Definition des Kompetenzrahmens werden zu jedem Handlungsfeld eines Usability Professionals in Anlehnung an den europäischen Qualifikationsrahmen (EQR, 2012) drei Komponenten von Kompetenz betrachtet. 5.1. Handlungsfelder Die Beschreibung von Handlungsfeldern von Usability Professionals bezieht sich auf

den Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme gemäß ISO 9241-210 (siehe Abbildung 4). Demnach ergeben sich die folgenden acht Handlungsfelder: –– Planung der menschzentrierten Gestaltung –– Den Nutzungskontext verstehen und beschreiben –– Die Nutzungsanforderungen spezifizieren –– Gestaltungslösungen entwerfen, die die Nutzungsanforderungen erfüllen –– Gestaltungslösungen aus der Benutzerperspektive evaluieren und verwerten –– Das Produkt bei den Benutzern einführen –– Langzeitbeobachtungen –– Den Usability Engineering Prozess organisieren (überwachen und steuern) [Abb. 4] Auf Basis des im AK „Berufsfeld Usability“ der German UPA (Bogner et al., 2011) definierten Rollenmodells werden die sechs Prozessrollen (Usability Engineer, User Requirements Engineer, Interaktionsdesigner, Informationsarchitekt, User Interface Designer, Usability Tester) den jeweiligen

Kompetenz wird dabei als ein nicht direkt beobachtbares Konstrukt verstanden, das durch die drei Dimensionen Struktur, Niveau und Erfassung beschrieben werden kann und durch definierte Handlungen, also nicht durch spezialisierte Methoden oder Techniken, konstituiert wird (PAS 1093, 2009). Abb. 3. Beispiel des Prozessschrittes „Den gegebenen Nutzungskontext für jede Benutzergruppe erheben und beschreiben“

163


beherrschen (Fertigkeiten) sowie die Fähigkeit zur empathischen Kommunikation besitzen (personale und soziale Kompetenz). 6. Aktueller Stand der Arbeiten Derzeit befindet sich die weitere Ausarbeitung des Kompetenzrahmens in Arbeit und soll voraussichtlich Ende 2012 in einer ersten Version fertiggestellt werden. [Abb. 6] Abb. 4. Menschzentrierte Gestaltungsaktivitäten (ISO 9241-210)

Handlungsfeldern „durchführend“ (D) bzw. „beratend“ (B) zugeordnet (siehe Abbildung 5). [Abb. 5] Für jede Rolle können jetzt entsprechende Anforderungen an die Kompetenzen dieser Rolle in einem spezifischen Handlungsfeld hinsichtlich der drei wesentlichen Komponenten der Kompetenz beschrieben werden. 5.2. Wissen, Fertigkeiten und Kompetenzen Die Komponenten der individuellen Kompetenz werden im europäischen Qualifikationsrahmen grundlegend beschrieben (EQR, 2012). Neben Kenntnissen über Theorie und/oder Faktenwissen sowie kognitiven

7. Ziel und Struktur des Workshops

und praktischen Fertigkeiten, wird auch die Kompetenz im Sinne der Übernahme von Verantwortung und Selbstständigkeit berücksichtigt. Der deutsche als national angepasster Qualifikationsrahmen unterscheidet zusätzlich zwischen personalen und sozialen Kompetenzen. Die Teilbereiche „Wissen“, „Fertigkeiten“ und „Kompetenzen“ (personale und soziale) bilden eine untrennbare Einheit und bestimmen in ihrer Gesamtheit die individuelle Kompetenz einer bestimmten Person. Beispielsweise sollte ein Usability-Engineer, um im Handlungsfeld „Nutzungskontext verstehen und beschreiben“ (siehe Abbildung 6) wirksam zu sein, als Mindest-Kompetenzen unter anderem die Dimensionen des Nutzungskontextes nach ISO 9241-11 kennen (Kenntnisse), „aktives Zuhören“

Für die Teilnahme am Workshop des Arbeitskreises im Rahmen der Usability Professionals 2012 werden sowohl Usability-Experten als auch UsabilityEinsteiger als Zielgruppe gesehen. Nach einer kurzen Einführung in das Thema wird den Teilnehmern der aktuelle, inhaltliche Stand der Arbeiten am Qualitätsstandard durch den Arbeitskreis präsentiert, sowie die methodisch-konzeptionelle Herausforderung bei der Erstellung eines solchen Standards verdeutlicht. Ziel ist es, neben einer Verdeutlichung und Sensibilisierung der Problematik sowie einer Evaluation des aktuellen Standes, auch den gewählten Ansatz zur Beschreibung des Kompetenzrahmens für Usability Professionals zu diskutieren, welcher als Basis der Qualifizierung sowie Zertifizierung von Personen, die im Berufsfeld Usability tätig sind, fungieren kann.

Abb. 5. Matrix der Zuordnungen von Prozessrollen zu Handlungsfeldern

164


Usability Professionals 2012 Arbeitskreise German UPA

Abb. 4. Exemplarischer Arbeitsstand für das Handlungsfeld „Nutzungskontext verstehen und beschreiben“

Literatur 1. Bevan, N. (2006). International Standards for

6. Fischer, H., Nebe, K. & Klompmaker, F. (2011). A Holistic Model for Integrating Usability

Weiterbildung – Kompetenzmodellierung in der Personalentwicklung.

HCI. In: Encyclopedia of Human Computer

Engineering and Software Engineering

12. Seffah, A., Desmarais, M. C. & Metzker,

Interaction. Hershey, Pennsylvania: IGI

Enriched with Marketing Activities. In:

E. (2005). HCI, Usability and Software

Global.

Proceedings of the HCI International 2011.

Engineering Integration: Present and Future.

Volume 16, LNCS 6776. Heidelberg: Springer

In: Seffah, A., Gulliksen, J., Desmarais,

Verlag.

M. C. (Hrsg.): Human-Centered Software

2. Bogner, C., Brau, H., Geis, T., Huber, P., Lutsch, C., Petrovic, K. & Polkehn, K. (2011). Beschreibung des Berufsfelds

7. Geis, T., Hofmann, B., Bogner, C. &

Engineering – Integrating Usability in the

Usability / User Experience – Rollen und

Polkehn, K. (2010). (Qualitäts-)Standards für

Aufgaben von Usability Professionals im

Usability Professionals – welche sind das

benutzerorientierten Entwicklungsprozess.

eigentlich?. i-com Zeitschrift für interaktive

13. Stewart, T. & Travis, D. (2003). Guidelines,

German UPA e.V., Arbeitskreis Berufsfeld.

und kooperative Medien, Ausgabe 1-2010.

Standards, and Style Guides. In: Jacko, J.

http://germanupa.de/german-upa/

München: Oldenbourg Wissenschaftsverlag.

A., Sears, A. (Hrsg.): The Human-Computer

berufsfeld-usability-ux 3. Deutsche Akkreditierungsstelle GmbH (DAkkS)

8. ISO/IEC TR 24774 (2010). Systems

Software Development Lifecycle (S. 37-58). Heidelberg: Springer Verlag.

Interaction Handbook – Fundamentals,

and software engineering – Life cycle

Evolving Technologies and Emerging

(2010). Leitfaden Usability, Version 1.3. http://

management – Guidelines for process

Applications (S. 991–1005). Mahwah, New

www.dakks.de/sites/default/files/71-SD-2-007_

description.

Leitfaden%20Usability%201.3.pdf 4. DIN EN ISO 9241-210 (2010). Ergonomie der Mensch-System-Interaktion – Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme. 5. EQR Europäischer Qualifikationsrahmen für lebenslanges Lernen (2012). http:// ec.europa.eu/education/pub/pdf/general/ eqf/leaflet_de.pdf

9. ISO/TS 18152 (2010). Ergonomics of human-

Jersey, USA: Lawrence Erlbaum Associates Inc. 14. Woywode, M., Mädche, A., Wallach, D.

system interaction – Specification fort he

& Plach, M. (2012). Abschlussbericht des

process assessment of human-system issues.

Forschungsprojektes „Gebrauchstauglichkeit

10. ISO/TR 18529 (2000). Ergonomics –

von Anwendungssoftware als

Ergonomics of human-system interaction

Wettbewerbsfaktor für kleine und mittlere

– Human-centred lifecycle process

Unternehmen“ im Auftrag des BMWi.

descriptions. 11. PAS 1093 (2009). Personalentwicklung unter besonderer Berücksichtigung von Aus- und

165


Usability Professionals Nachwuchs fördern mit Sozialen Medien Astrid Beck Hochschule Esslingen 73732 Esslingen Astrid.Beck@HS-Esslingen.de

Anja Wipfler User Experience Design OnDemand Solutions, SAP AG anja.wipfler@sap.com

Abstract Studierende sind vertraut mit sozialen Medien vor allem mit StudiVZ und Facebook. Allerdings werden diese vor allem für den privaten Austausch mit Gleichgesinnten verwendet, weniger für die Planung des Studiums, des Praktikums sowie des weiteren beruflichen Fortkommens. Hier möchte der AK Nachwuchs der UPA unterstützend wirken. Einige Angebote gibt es bereits, wie die Gruppe für den Usability Nachwuchs in Xing oder der Bereich des AK Nachwuchs auf der UPA Webseite. Des weiteren sollen weitere neue Angebote vorgeschlagen und diskutiert werden.

1. AK Nachwuchsförderung der UPA

die Benutzer in den Mittelpunkt ihres Arbeiten und Entwickelns stellt.

Junge, engagierte Menschen zu unterstützen und zu fördern ist eines der vorrangigen Ziele der German UPA. Im April 2011 hat die German UPA den Arbeitskreis Nachwuchsförderung gegründet. Hier haben sich Interessierte aus Industrie, Wissenschaft und Forschung zusammengeschlossen.

Themen der Usability Summer School, die an zwei Tage dauert, sind Usability Grundlagen, Prototyping, Paper Mock-ups, Prototyping Tools und Usability Testing. Nach einführenden Vorträgen arbeiten die Teilnehmer in Gruppen an einer Gestaltungsaufgabe mit Methoden des User-CenteredDesign, bei der das mitgebrachte und neu gelernte Wissen praktisch angewandt wird. Die Teams werden von Senior Experten aus Industrie und Lehre betreut.

Ziele des Arbeitskreises sind die Ausbildung, Vernetzung mit Gleichgesinnten und erfahrenen Usability Experten sowie Angebote speziell für Studierende und Auszubildende, einschliesslich der Unterstützung bei der Suche nach Praktika und Abschlussarbeiten. Der AK Nachwuchsförderung bietet zudem Studierenden die Usability Summer School, die im August 2011 erstmalig stattfand. Teilnehmerinnen und Teilnehmer haben die Möglichkeit anhand von Vorträgen, praktischen Übungen und einem gemeinsamen Projekt in zwei Tagen Praktiker und Kommilitonen aus ganz Deutschland zu treffen und voneinander zu lernen. Es soll das Interesse und die Leidenschaft für eine Profession geweckt werden, die in einem technisch geprägten Umfeld explizit

166

Die German UPA übernimmt Seminar- und Übernachtungskosten für die Studierenden, während sich die Referenten und Arbeitksreismitglieder wie bei der German UPA üblich ehrenamtlich engagieren. Die zweite Summerschool fand nun im August 2012 statt. 2. Planung der beruflichen Karriere Aus Rückmeldungen der Studierenden wissen wir, dass es einen großen Bedarf gibt, mehr über das zukünftige Arbeitsumfeld von Usability Praktikern zu erfahren. Die Thematik Usability ist zwar von immenser Wichtigkeit für Produkte und Services, wie

Kostanija Petrovic Nokia gate5 GmbH kostanija.petrovic@nokia.com

Keywords: /// Social Media /// Web 2.0 /// AK Nachwuchs /// Jobs /// Karriere

auch die zunehmenden Arbeitsangebote in der Wirtschaft zeigen. Die Erkenntnis ist sich aber oft noch nicht an den Hochschulen angekommen. Studierende erfahren dort oft keine oder falsche Beratung, was das Berufsfeld angeht. Gleichzeitig sind Studierende oft auch etwas hilflos mit bestehenden Angeboten umzugehen. Einen guten Überblick liefert die Broschüre „Berufsfeld Usability“ der German UPA (Bogner et al. 2010). Häufiger erreichen uns Anfragen, wie „wo kann ich meine Abschlussarbeit schreiben“ oder „ich möchte ein Praktikum bei Unternehmen XY durchführen“. Nahezu alle großen Firmen bieten heute Jobportale, die auch das Angebot für Studierende beinhalten. Wir haben versucht, auf der UPA Webseite einen Job-Angebotsbereich für Studierende bereitzustellen, doch eigentlich reicht schon Anwendung von Google und „Web 1.0“ im diese Angebote zu finden. Doch das scheint manchen gar nicht so leicht zu fallen. Die klassischen Wege sich zu bewerben via Anzeige oder großes Webportal kann bedeuten, dass man entweder mit Hunderten Bewerbern konkurriert oder den Wunschjob gar nicht erst findet. Ein Großteil von Jobs im Usabilitybereich wird aber über soziale Plattformen, über


Usability Professionals 2012 Arbeitskreise German UPA

Mundpropaganda (viral) oder über einschlägige Veranstaltungen vermittelt. Hier bietet sich ein Anknüpfungspunkt den Nachwuchs zukünftig zu unterstützen, in dem man Hilfe und Überblick gibt, wie man zu Web 2.0 (einen schöne Darstellung geben die HRK-Handreichungen: Herausforderungen Web 2.0) und passenden Angeboten online Zugang findet. Eine Art Metahilfe zu Informationen sowie Praktikums- und Jobbörsen für Studierende im Usabilitybereich ist hier notwendig. Die Bewerbungen für die Summer School der letzten beiden Jahre haben uns auch gezeigt, dass es nicht immer selbstverständlich ist, eine gute, ansprechende und überzeugende Bewerbung zu schreiben. Auch hier möchte der AK Nachwuchs zukünftig Unterstützung anbieten mit Hinweisen zu Bewerbungsverfahren beispielsweise und Muster für Bewerbungsschreiben etc. In den USA durchaus üblich, hier aber noch wenig genutzt, ist z. B. die eigene Webseite als Teil der Bewerbung. Dieses Medium ist gerade aber für angehende Usability Professionals eine gute Form um auf sich aufmerksam zu machen, weil sich im Web sehr gut Portfolios und durchgeführte Projekte darstellen lassen. [Abb. 1] Die meisten Jobs findet man in Deutschland online. Das geht aus einer BITKOM-Studie hervor, die bereits 2010 herausfand, dass der 95 Prozent der Unternehmen ihre Jobangebote ins Internet stellen. Immerhin zwölf Prozent gingen in Sozialen Netzwerken auf Mitarbeitersuche. Es ist zu vermuten, dass diese Zahl in den letzten zwei Jahren eher noch gestiegen sein wird. Laut einer aktuellen BITKOM –Untersuchung (Mai 2012) ist derweil fast ein Drittel (32 Prozent) aller Unternehmen bereits mit eigenen Seiten auf Facebook aktiv (BITKOM-Umfrage unter 723 Unternehmen). Die Plattform der German UPA wird von den Unternehmen der Branche für Jobangebote gut genutzt, sollte also erste Anlaufstelle für den Nachwuchs sein.

Abb. 1. BITKOM (2010): Firmen suchen Mitarbeiter im Internet

Das Praktikum oder der neue Job ist manchmal nur einen Klick entfernt, d. h. wer sowieso jeden Tag in Facebook mit Freunden und Familie kommuniziert, sollte sich einmal die Mühe machen auch Seiten der Unternehmen zu suchen. Hier Beispiele von Unternehmen mit Darstellung des Arbeitsumfelds und Jobangeboten in Facebook: 1. Bayer Business Consulting https://www.facebook.com/ inhouseconsulting 2. Bosch Karriere https://www.facebook.com/ BoschKarriere 3. Daimler Career https://www.facebook.com/ daimlercareer 4. Deutsche Telekom AG https://www.facebook.com/ deutschetelekom 5. Jobs & Karriere bei Porsche https://www.facebook.com/ porschekarriere 6. SAP Careers-EMEA https://www.facebook.com/ SAPCareersEMEA Einen guten Überblick über das Berufsfeld und Verdienstmöglichkeiten des Usability

Professionals bietet der jährlich erscheinende Branchenreport (zuletzt 2011). Er „liefert Informationen zu Ausbildungswegen und Weiterbildungsmöglichkeiten, spezifischen Merkmalen der Arbeitssituation sowie Herausforderungen und Verdienstmöglichkeiten unter angestellten und selbstständig tätigen Usability Professionals“. Eine internationale Studie ist der UX Professionals’ Salary Survey (2012). Online Communities, also Plattformen zum Austausch bieten manche Unternehmen speziell für den Nachwuchs an, z. B.: das SAP Community Network University Alliances http://scn.sap.com/community/uac Hilfreiches zum Thema Job und Bewerbung: 1. http://karrierebibel.de/ 2. http://www.alma-mater.de/c3view.php 3. Reputationsmanagement und Selbstmarketing Die Jobsuche ist als passive, anonyme Aktivität zu bewerten, während die Teilhabe an Web 2.0-Angeboten als aktiv und initiativ betrachtet werden kann und letzteres mehr Chancen bietet.

167


Bereits angesprochen wurde die eigene Webseite als Möglichkeit, sich online bekannt zu machen und seinen Lebenslauf online darzustellen. Wem das zu aufwendig scheint, der hat die einfache und kostenlose Möglichkeit sich in Xing mit einem Profil oder in Facebook mit einer Fanpage der Öffentlichkeit zu präsentieren. Leider machen dies noch sehr wenige Studierende, obwohl die meisten von ihnen StudiVZ oder (heute eher) Facebook täglich nutzen. Quasi alle sozialen Plattformen bieten die Möglichkeit, sich sowohl passiv als auch aktiv zu engagieren. In Xing beispielsweise kann ein Studierender sich mit einem Profil präsentieren und seine Suche kundtun, gleichzeitig besteht die Möglichkeit sich in einer Vielzahl von Foren über Jobangebote zu informieren. Der dritte Weg besteht darin, sich als interessierten, engagierten Xing-User darzustellen. Dieser Weg dauert am längsten bis er Früchte trägt, bedeutet aber irgendwann im Laufe der Karriere, dass man eigentlich gar nichts mehr machen muss, weil die Jobangebote mit der Post (genauer per Mail) von ganz allein kommen. Wie wird man aktiver Xing-User? Dazu gehören Aktivitäten in Foren, Beiträge schreiben, Events organisieren, Informationen und interessante Statusmeldungen posten, provozierende Fragen stellen, Menschen miteinander bekannt machen etc. Auch die Zahl der qualitativ guten, interessanten Kontakte ist wichtig. Selbstverständlich ist ein ausführlicher Lebenslauf. Ein Anmeldedatum was deutlich länger zurückliegt und ein „100%“-AktivBalken deuten darauf hin, dass das Profil zu einem aktiven Netzwerker gehört und nicht zu jemanden, der es jetzt gerade „nötig“ hat. Man beachte: Kontakte machen bevor man sie braucht!

allem für den deutschsprachigen Raum), LinkedIn für USA und das englischsprachige Ausland sollte man sich auch diese Angebote einmal ansehen: 1. Facebook – wo arbeiten meine Freunde: https://www.facebook.com/Branchout 2. Facebook – Jobboard der TopArbeitgeber in Deutschland https:// www.facebook.com/jobstairs 3. Youtube, z. B. eine Idee: The QR Code Job Application http://youtu.be/ acnLepjWe8E 4. Twitter – Jobsuche: http://www. twitjobsearch.com/, http://jobtweet.de/

168

Ullrich_2011_BranchenreportUsability2011. pdf/view 3. BITKOM (2010): Stellenanzeigen im Internet sind bei Firmen erste Wahl, http://www. bitkom.org/de/presse/66442_62229.aspx 4. BITKOM (2012): Daten und Fakten zu sozialen Netzwerken, http://www.bitkom.org/de/ presse/8477_72245.aspx 5. HRK-Handreichungen: Herausforderungen Web 2.0 (Beiträge zur Hochschulpolitik 11/2010), Bonn 2010, htttp://www.hrk.de/de/ home/5784.php 6. Internet führt bei Stellenanzeigen, http://www.techbanger.de/2010/01/27/

4. Web 2.0 und offline sozial Aktiv sein

internet-fuhrt-bei-stellenanzeigen/ 7. UX Professionals’ Salary Survey (Aug 2012) http://research.clicktale.com/rs/clicktale/

Kein Projekt lässt sich nur online abwickeln, ebenso wenig ist es möglich, nur online seine Karriere anzubahnen. Entscheidend ist immer auch im wahren Leben aktiv auf Personen und Institutionen zuzugehen, die man entweder online kennt, um den Kontakt zu vertiefen oder die man kennenlernt und dann im Nachgang mit dieser Person sich online verbindet. Die Frage „Sind sie bei Xing?“ erübrigt heute oftmals das Tauschen von Visitenkarten (die ein Nachwuchskandidat meist eh nicht hat). Wie lernt man als junger Mensch interessante und „wichtige“ Leute kennen? Man besuche einen oder mehrere der folgenden Events, berichte von dort per Twitter oder in einem Blog, arbeite als Student Volunteer mit, halte dort einen Vortrag und spreche Leute an: –– World Usability Day –– Konferenzen und Barcamps –– Social Media Club http:// socialmediaclub.org/ (auch in Facebook und in Xing) –– Usability Summer School Literatur

Es ist also wichtig, Social Media Kanäle in beide Richtung zu nutzen, wie in allen Netzwerken auch kommt es auf das Geben und Nehmen an. In dem man selbst Teil des Geschehens ist, ist es ganz selbstverständlich mit anderen Netzwerkern zu kommunizieren, wenn es um Jobsuche, Gehaltsvorstellungen und potenzielle Arbeitsgeber geht. Neben Xing (vor

german-upa/branchenreport/Diefenbach-

1. C. Bogner, H. Brau, T. Geis, P. Huber, C. Lutsch, K. Petrovic & K. Polkehn: Berufsfeld Usability Broschüre (2010), http://germanupa. de/german-upa/berufsfeld-usability-ux/ germanupa_the-usability-ux-profession.pdf/ view 2. Branchenreport Usability 2011. Ergebnisse einer Befragung unter Usability Professionals in Deutschland, http://germanupa.de/

images/ClickTale%2520UX%2520Salary%2520 Survey%25202012%2520Results.pdf


Von Anforderungen zum Produkt

169


Die Brücke zwischen Anforderungen und Design schlagen Mit Hilfe von Image Schemata Gestaltungsentscheidungen systematisch treffen Diana Löffler Technische Universität Berlin FR 2-7/1 Franklinstrasse 28-29 10587 Berlin dlo@mms.tu-berlin.de

Jörn Hurtienne Universität Würzburg Oswald-Külpe-Weg 82 97074 Würzburg joern.hurtienne@uni-wuerzburg.de

Abstract Der Übergang von der Anforderungsanalyse zum Design stellt im Produkt-Entwicklungsprozess eine besondere Herausforderung dar. In dieser Phase stellt sich die Frage, wie Anforderungen „richtig“ ins Design übersetzt werden können, um zu einem intuitiv benutzbaren Produkt zu führen. Bisher hängt es stark von der Erfahrung und den Fähigkeiten der Gestalter ab, wie gut das Ergebnis dieser Phase ausfällt und ob die entstehenden interaktiven Produkte den mentalen Modellen, die die zukünftigen Benutzer von ihrer Arbeitsaufgabe haben, entsprechen. In der Praxis kann aber eine profunde DesignExpertise für die Herausforderungen dieser Phase nicht immer vorausgesetzt werden. Zur Unterstützung wurde daher die neuartige Image-Schema-Methode entwickelt. Diese Methode erleichtert das Ableiten des Designs aus den Anforderungen und die Überprüfung des Designs auf die korrekte und vollständige Umsetzung der Anforderungen. Durch ihre universelle Ausrichtung kann sie in vielen verschiedenen Bereichen, wie der Gestaltung technischer Geräte, Software und Apps eingesetzt werden.

1. Einführung 1.1. Motivation Das Ziel bei der Entwicklung gebrauchstauglicher interaktiver Systeme ist es, diese den Nutzeranforderungen entsprechend zu gestalten. Um die Anforderungen in die Benutzungsschnittstelle (User Interface) zu übersetzen, muss eine Vielzahl von Gestaltungsentscheidungen getroffen werden. Die benutzerzentrierte Produktentwicklung sieht vor, den Nutzer und den Nutzungskontext bei Gestaltungsentscheidungen zu berücksichtigen (DIN EN ISO 9241 Teil 210), damit ein gebrauchstaugliches User Interface (UI) entsteht, das den mentalen Modellen, die die zukünftigen Benutzer von ihren Arbeitsaufgaben haben, entspricht. Mentale Modelle sind dabei die inneren Repräsentationen einer Person von Ihrer Arbeit aber auch von dem Aufbau und der Funktionsweise eines interaktiven Systems. Mentale Modelle bilden die Grundlage für eine innere Simulation der

170

Benutzung (bewusst oder unbewusst) und beeinflussen damit die reale Benutzung des Systems. Es gibt bereits zahlreiche Methoden, um zu testen, ob das Design-Konzept den Nutzeranforderungen entspricht und um dessen Gebrauchstauglichkeit zu evaluieren, nachdem das UI gestaltet wurde. Ein systematischer Ansatz zur direkten Überführung von Nutzeranforderungen in ein Design, das direkten Bezug zu diesen Anforderungen hat, fehlt allerdings. Dieses Problem wird in der Literatur unter dem Begriff „Gestaltungslücke“ (engl. „Design Gap“, vgl. Wood, 1998) diskutiert. Es obliegt derzeit der Erfahrung und den Fähigkeiten des Designers, wie gut und nutzbar das Ergebnis ist und wie nachvollziehbar die Anforderungen in das Design übersetzt wurden. In der Praxis kann allerdings – gerade in kleinen Unternehmen – nicht immer auf profunde Design-Expertise zurückgegriffen werden. Die Ergebnisse werden durch diesen Missstand entsprechend negativ beeinflusst, weshalb eine

Andreas Maier Fraunhofer Institut für Experimentelles Software Engineering IESE Fraunhofer-Platz 1 67663 Kaiserslautern andreas.maier@iese.fraunhofer.de

Keywords: /// User Interface Design /// Design Methode /// Usability Engineering /// Intuitive Use

Unterstützung zur Schließung der „Gestaltungslücke“ dringend notwendig ist. 1.2. Lösungsansatz In diesem Beitrag wird die Image-SchemaMethode vorgestellt, die einen systematischen Übergang von Anforderungen in Gestaltungsentscheidungen erlaubt und dabei hilft, die Gestaltungslücke zu überbrücken. Die vorgestellte Methode hebt vor allem die intuitive Nutzbarkeit hervor, die als Bestandteil der Gebrauchstauglichkeit einen wichtigen Faktor positiver User Experience darstellt. Die Image-Schema-Methode kann sowohl als konstruktive als auch analytische Methode eingesetzt werden. Image Schemata stellen ein gemeinsames Vokabular zur Beschreibung von mentalen Modellen sowie von UIs dar. Bereits in der Anforderungsphase werden mit Hilfe der Methode die tiefer liegenden Bausteine mentaler Modelle der Benutzer erfasst und als Gestaltungsvorgaben in die Spezifikation der Anforderungen übernommen.


Usability Professionals 2012 Von Anforderungen zum Produkt

Diese Angaben lassen sich dann direkt vom Designer als Vorgaben für die zu erstellende UI-Lösung nutzen, wobei noch genügend Freiraum für die konkrete Ausgestaltung der Interaktionselemente bleibt. 2. Was bedeutet Gestaltung intuitiver Benutzbarkeit? Produkte sind dann intuitiv benutzbar, wenn Benutzer mit unterschiedlichen Vorerfahrungen und Fähigkeiten keine besonderen Anstrengungen aufbringen müssen, um ihr Ziel zu erreichen. Wie intuitiv die Benutzbarkeit eines Produktes ist, wird nach der IUUI Gruppe (Intuitive Use of User Interfaces) bestimmt durch „das Ausmaß in dem die Benutzung eines Produktes auf der unbewussten Anwendung von Vorwissen beruht und dadurch zu einer effektiven und zufriedenstellenden Interaktion bei minimalem Verbrauch kognitiver Ressourcen führt“ (Mohs et al., 2006). Intuitive Benutzbarkeit stellt somit ein Teilkonzept der Gebrauchstauglichkeit dar, denn im Unterschied zur Gebrauchstauglichkeit mit den Kenngrößen Effektivität, Effizienz und Zufriedenheit steht bei der intuitiven Benutzbarkeit besonders die geringe mentale Beanspruchung im Vordergrund. Wenn bei der Entwicklung eines Produkts die intuitive Benutzbarkeit im Vordergrund steht, kann dies unter Umständen dazu führen, dass andere Usability-Kriterien verletzt werden, um das primäre Ziel zu erreichen. Kann zum Beispiel der mentale Aufwand des Nutzers durch eine Umgestaltung die mehr Klicks

notwendig macht verringert werden, so wird in diesem Fall die Verletzung des Usability-Faktors motorische Effizienz zugunsten der mentalen Effizienz in Kauf genommen. Das Konzept der intuitiven Benutzbarkeit ist besonders interessant für Novizen, Gelegenheitsnutzer oder für Nutzer, die nicht bereit sind, sich umfassend in die Benutzung eines Produktes einzuarbeiten. Auch bei der Gestaltung für verschiedene Benutzergruppen, die alle gut mit dem Produkt umgehen können sollen, ist intuitive Benutzbarkeit wichtig (Hurtienne & Blessing, 2008). Derzeit gibt es keinen Konsens darüber, wie genau interaktive Produkte entwickelt werden sollen, damit sie intuitiv benutzbar sind. Prinzipiell muss bei der Gestaltung intuitiver Benutzkonzepte eine möglichst hohe Übereinstimmung zwischen dem mentalen Modell des Nutzers von seinen Arbeitsaufgaben mit dem Modell, dass auf der Ebene des UIs instanziiert wird, erreicht werden. Eine Möglichkeit, diese Übereinstimmung zu erzielen, besteht darin, die unbewussten Bausteine der mentalen Modelle der Benutzer zu erheben und diese als Vorgaben für die Gestaltung zu nutzen. Dahinter steht die Theorie der Image Schemata, welche ein gemeinsames Vokabular zur Beschreibung der mentalen Modelle der Benutzer und des UIs darstellen. Was sich hinter dem Begriff der Image Schemata verbirgt wird im folgenden Abschnitt erläutert.

3. Theoretischer Ansatz: Image Schemata und image-schematische Metaphern Nach Johnson (1987) sind Image Schemata wiederkehrende fundamentale Erfahrungen, die Menschen im Laufe ihres Lebens machen. Erfahrungen wie das Baden in der Badewanne, das Trinken aus einem Glas oder das Einstecken von Gegenständen in die Tasche verdichten sich zu einer abstrakten, analogen Repräsentation, die CONTAINER genannt werden kann. Dieses Schema des CONTAINERS umfasst ein Innen, ein Außen und eine Grenze dazwischen und vereinigt diese verschiedenen Erfahrungen. Diese im ersten Augenblick einfach erscheinende Beschreibung bringt jedoch weitere Implikationen mit sich. Beispielsweise kann der CONTAINER geschlossen oder mit Inhalt gefüllt werden. Dieser Inhalt kann nicht ohne weiteres wieder heraus aus dem CONTAINER, er folgt der Bewegung des CONTAINERs usw. Zu den Image Schemata gehören weitere simple Konzepte, wie FULL-EMPTY, räumliche Dimensionen, wie NEAR-FAR oder UP-DOWN, und basale Kraftrelationen wie BLOCKAGE, COUNTERFORCE und MOMENTUM. Tabelle 1 stellt einen Überblick über die wichtigsten Image Schemata dar (vgl. Hurtienne, 2011). [Tab. 1] Image Schemata werden definiert als grundlegende Bausteine wiederkehrender basaler Erfahrungen, die vom Gehirn unbewusst verarbeitet werden. Wie anhand des Beispiels CONTAINER beschrieben werden aus der Interaktion

Gruppe

Image Schemata

Basic Schemas

OBJECT, SUBSTANCE

Space

CENTER-PERIPHERY, CONTACT, FRONT-BACK, LEFT-RIGHT, LOCATION, NEAR-FAR, PATH, ROTATION, SCALE, SURFACE, UP-DOWN

Containment

CONTAINER, CONTENT, FULL-EMPTY, IN-OUT

Force

ATTRACTION, BALANCE, BLOCKAGE, COMPULSION, COUNTERFORCE, DIVERSION, ENABLEMENT, MOMENTUM, RESISTANCE, RESTRAINT REMOVAL, SELF-MOTION

Multiplicity

COLLECTION, COUNT-MASS, LINKAGE, MATCHING, MERGING, PART-WHOLE, SPLITTING

Process

CYCLE, ITERATION

Attribute

BIG-SMALL, DARK-BRIGHT, HEAVY-LIGHT, STRAIGHT, SMOOTH-ROUGH, STRONGWEAK, WARM-COLD

Tab. 1. Übersicht über die wichtigsten Image Schemata

171


4. Anwendung der Image Schema Methode im benutzerzentrierten Entwicklungsprozess

Abb. 1. Erwerb und Realisierung von image-schematischen Metaphern, mit Beispielen (nach Hurtienne et al., 2010)

mit der Umwelt ähnliche, wiederkehrende sensumotorische Muster abstrahiert. Diese werden dann im Gehirn analog zur (multi-) sensorisch wahrgenommenen Erfahrung, die visuell, akustisch, haptisch oder kinästhetisch sein kann, multimodal repräsentiert (Johnson, 1987). Diese Image Schemata bilden auch die Grundlage zum Verständnis abstrakter Konzepte. So wird zum Beispiel das abstrakte Konzept der „Zeit“ auf einem räumlichen Kontinuum von vorn (Zukunft) nach hinten (Vergangenheit) wahrgenommen. Das Konzept „Wichtigkeit“ wird auf einem räumlichen Kontinuum von Zentrum (wichtig) zu Peripherie (unwichtig) oder das Konzept „Quantität“ auf einem Kontinuum von unten (wenig) nach oben (viel) wahrgenommen (Johnson, 1987; Lakoff & Johnson, 1999). Diese Abbildung abstrakter Konzepte mit (physischen) Image Schemata wird als imageschematische Metapher bezeichnet. Sie sind auch in der Sprache instanziiert, etwa in „Wir müssen nach vorn blicken“, „Was ist denn das zentrale Problem?“ oder „Er

Prozessphase UCD

Analyse des Nutzungskontextes

Anwendung von Extraktion der ImageImage Schemata Schemata aus der Sprache der Benutzer und Erstellung image-schematischer Metaphern.

ist hoch verschuldet“. Die Verfügbarkeit der image-schematischen Metaphern in der Sprache erlaubt nun den Zugang zu den unbewussten image-schematischen Repräsentationen abstrakter Aufgabenbereiche der Benutzer. Abbildung 1 veranschaulicht noch einmal den Erwerb der image-schematischen Metapher MORE IS UP – LESS IS DOWN durch die wiederholte gemeinsame Erfahrung des Image Schemas UP-DOWN mit dem abstrakten Konzept Quantität und die Instanziierung der Metapher in UIs, z. B. einem vertikalen Schieberegler für die Lautstärkesteuerung, einem Wasserhahn oder einer Spin Box (Drehfeld). Ähnlich verläuft der Erwerb der oben erwähnten Metaphern IMPORTANT IS CENTRAL – UNIMPORTANT IS PERIPHERAL und THE FUTURE IS IN FRONT – THE PAST IS IN THE BACK unter Beteiligung der Image Schemata CENTER-PERIPHERY und FRONT-BACK. [Abb. 1]

Spezifikation der Nutzeranforderungen

Die Theorie der Image Schemata wurde ursprünglich in der kognitiven Linguistik entwickelt (Hampe, 2005; Johnson, 1987; Lakoff & Johnson, 1999) und lässt sich gut auf den Anwendungsbereich der Gestaltung von UIs technischer Systeme sowie deren Evaluation übertragen (Bakker et al., 2009; Hurtienne & Israel, 2007; Hurtienne, Israel & Weber, 2008; Hurtienne, Weber & Blessing, 2008; Lund, 2003). Die hier vorgestellte Methode geht von der Annahme der kognitiven Linguisten aus, dass sich image-schematische Metaphern, die unbewusst repräsentiert sind, in der Sprache der Benutzer instanziieren und dadurch der Analyse zugänglich werden. Wenn nun die Gestaltung eines UIs die unbewussten image-schematischen Metaphern berücksichtigt, führt dies zu einer intuitiven und damit effektiven und mental effizienten Interaktion. Empirische Studien konnten Belege für diese Annahme finden. Benutzer sind schneller, machen weniger Fehler und bevorzugen UIs, die image-schematische Metaphern instanziieren gegenüber UIs, die diesen Metaphern widersprechen (Hurtienne & Blessing, 2007; Hurtienne, 2011). Beispielsweise wurde die Gestaltung eines UIs mit vertikal angeordneten Tasten anhand des UP-DOWN Schemas überprüft. Bei einer Interaktion mit zum Schema kompatiblen Beschriftungen (z. B. „gut“ ist oben, „schlecht“ ist unten) sind die Benutzer schneller als mit inkompatiblen Beschriftungen (z. B. „gut“ ist unten, „schlecht“ ist oben). Die kompatiblen Beschriftungen werden von den Nutzern auch als für die Dateneingabe besser geeignet bewertet.

Entwicklung von Gestaltungslösungen

Evaluation der Gestaltungslösung

Aufnahme der identifizierten Gestalten von UI-Elementen Überprüfung der Wirkung IS und Metaphern in konkrete entsprechend der imageder IS entsprechend der Anforderungs­spezifikationen schematischen Metaphern Anforderungen

Tab. 2. Übersicht über den Einsatz von Image Schemata (IS) im benutzerzentrierten Entwicklungsprozess (UCD)

172


Usability Professionals 2012 Von Anforderungen zum Produkt

Im Folgenden wird dargestellt wie Image Schemata in alle Phasen eines nutzerzentrierten Entwicklungsprozesses nach ISO 9241-210 eingebunden werden können (für einen Überblick siehe Tabelle 2). Dies wird an dem Beispiel eines Re-Designs einer Heizungssteuerung erläutert. [Tab. 2] 4.1. Analyse des Nutzungskontextes Nach ISO 9241-210 besteht diese Phase aus der Analyse der Benutzer, ihrer Tätigkeiten, der bestehenden Technologie sowie des soziotechnischen Nutzungskontextes. Für die Beschreibung des Kontextes werden Image Schemata aus dem mentalen Modell der Benutzer (erreicht durch Transkription und Analyse der Sprache der Benutzer über ihre Aufgabe) extrahiert. In unserem Beispiel wurden Benutzer von Heizungssystemen zu Hause aufgesucht und sie erzählten im Allgemeinen und anhand von Demonstrationen ihrer Heizungssysteme darüber, wie sie im Winter nicht auskühlen (d. h. sie konnten auch über die Benutzung von Wärmflaschen, die Abdichtung von Türen usw. reden). Die Suche nach Image-Schemata in den transkribierten Äußerungen der Benutzern ergab: über Temperatur wurde häufig in UP-DOWN Relationen gesprochen: „Wenn die Außentemperatur unter 20° fällt, schiebe ich den Regler hoch auf 22°“ (auch wenn es ein Drehregler war). Zeitabschnitte wurden z. B. mit dem Konzept des CONTAINERS assoziiert: „Ich brauche etwas Wärme in den Morgenstunden und in den Abendstunden“, wobei einzelne Zeitpunkte auf einem PATH lagen: „Die Heizung soll von 6 bis 8 arbeiten.“ 4.2. Spezifikation der Nutzungsanforderungen Die Anforderungen an das Softwaresystem können direkt aus der Analyse des Nutzungskontexts generiert werden. Als Basis für die Formulierung der Anforderungen können die Arbeitsschritte dienen, die unverzichtbar für die Erfüllung des Arbeitszieles sind, sowie die mit ihnen assoziierten Image Schemata. Auch Image

Schemata, die ausschließlich im mentalen Modell der Benutzer auftreten, sollten bei der Anforderungsspezifikation berücksichtigt werden. So waren die Kernaufgaben der Heizungssteuerung festgelegt auf die vier Bereiche: (1) die gesamte Heizung an und ausschalten, (2) Zeiten programmieren, zu denen die Heizung automatisch an und aus geht, (3) Temperaturen einstellen, (4) separate Einstellungen für Heizung und Warmwasser ermöglichen. Jeder dieser Kernanforderungen wurden die entsprechenden Metaphern zugeordnet: z. B. WARM IS UP – COLD IS DOWN zu (3), TIME PERIODS ARE CONTAINERS, TIME IS ON A PATH zu (2) usw.

Abb. 2. Das mit der Image-Schema-Methode entwickelte Touch-Screen Design für eine Heizungssteuerung

4.3. Entwicklung von Gestaltungslösungen Die Generierung von Gestaltungslösungen ist eng mit der Phase der Evaluation verbunden und umfasst sowohl die Skizzierung der Tätigkeitssequenzen als auch Feinheiten in der Gestaltung einzelner Interaktionselemente des UIs. Image Schemata (bzw. ihre Metaphern) werden genutzt, um die Anforderungen in konkrete Gestaltungslösungen zu transformieren. Dabei zeigen sie abstrakte Gestaltungsmöglichkeiten auf, ohne die Kreativität der Designer durch die konkrete Festlegung der Gestaltungslösungen zu beeinträchtigen. Auf Basis der linguistischen Analyse konnte eine neue Gestaltungslösung für eine digitale Heizungssteuerung entwickelt werden, die sich die genannten Prinzipien zu Nutze macht: Die verschiedenen Zeiteinheiten wurden als größenveränderliche CONTAINER auf einer Zeitachse dargestellt, zur Temperaturregelung konnte ein Element in dem Behälter nach oben oder nach unten verschoben werden (siehe Abbildung 2). Die gleichen image-schematischen Metaphern können auch zu einer ganz anderen Instanziierung im UI führen. Während das UI in Abbildung 2 als Touchscreen-Anwendung konzipiert ist, zeigt Abbildung 3 eine Instanziierung der gleichen gefundenen Metaphern in einem UI mit LCD-Display, Knöpfen und Schiebereglern. [Abb. 2], [Abb. 3], [Abb. 4],

Abb. 3. Das mit den gleichen image-schematischen Metaphern entwickelte Design für eine Heizungssteuerung mit LCD-Display, Knöpfen und Schiebereglern

Abb. 4. Das „herkömmliche“ UI einer digitalen Heizungssteuerung

173


4.4. Evaluation der Gestaltungslösung aus Benutzersicht Die Evaluation der Gestaltungslösung zeigt wie gut ein System den Anforderungen entspricht. Bereits während der Entwicklung von Gestaltungslösungen werden die jeweils instanziierten Image Schemata und Metaphern des UIs mit den Image Schemata und Metaphern, welche aus den Nutzeräußerungen und Anforderungen generiert wurden, verglichen. Diese Evaluation kann eine mögliche unangemessene Nutzung von Image Schemata aufdecken und so Verbesserungspotential aufzeigen. Später fließt Feedback von Benutzern aus einem Usability Test in die Evaluation ein. Die Aspekte intuitiver Interaktion – mentale Effizienz, Effektivität und Zufriedenheit – werden untersucht. Produkte und UIs, die nach der Image-Schema-Methode gestaltet werden, sollten mit weniger Fehlern und mit geringerem mentalen Aufwand zufriedenstellend benutzt werden können, als Produkte, die nicht nach dieser Methode gestaltet werden. Die Evaluation der beiden nach der ImageSchema-Methode entwickelten Prototypen der Heizungssteuerung erfolgte als Vergleich mit einer heute am Markt weit verbreiteten digitalen Steuerung (Abbildung 4). Beide Versionen der Heizungssteuerung, die nach der Image-Schema-Methode entwickelt wurden, waren in sämtlichen Erfolgsmaßen (Zeiten, Fehler, mentale Anstrengung, Präferenz) der herkömmlichen digitalen Steuerung überlegen und zeigten untereinander (trotz unterschiedlicher Interaktionsparadigmen) kaum Unterschiede (Hurtienne & Langdon, 2010).

wie er in der ISO 9241-210 skizziert ist, steckt in der ersten Phase (Analyse des Nutzungskontextes). Der meiste Nutzen ergibt sich dagegen in der dritten Phase (Entwicklung von Gestaltungslösungen). Die Analyse des Nutzungskontextes und die Anforderungsspezifikation mit hilfe von Image Schemata bringen wenig Mehrwert, wenn die Ergebnisse nicht auch bei der Entwicklung und Evaluation von Gestaltungslösungen genutzt werden. Umgekehrt ist es nur möglich, die ImageSchema-Methode in der Design- und Evaluationsphase anzuwenden, wenn die image-schematischen Anforderungen auch bekannt sind. Die Integration der Image Schemata in den benutzerzentrierten Entwicklungsprozess kann also Mehraufwand bedeuten, jedoch wird auch eine Qualitätssteigerung erzielt, die bereits in einigen prototypischen Umsetzungen nachgewiesen werden konnte. So führt die Anwendung der Image-Schema-Methode im Software-Engineering-Prozess auch zu besser bewerteten Gestaltungslösungen für betriebswirtschaftliche Software als ohne die Methode entwickelte Lösungen (Hurtienne, Israel & Weber, 2008; Hurtienne, Weber, & Blessing, 2008). So wurden die mit Image Schemata entwickelten UIs von den Nutzern hinsichtlich ihrer pragmatischen und hedonischen Qualität (erhoben mit dem AttrakDiff, Hassenzahl, 2003) höher eingeschätzt.

5. Diskussion und Ausblick

In den vergangenen Studien erwies sich die Image-Schema-Methode im DesignProzess als eine einfach anwendbare Methode für die ein Designer kaum Wissen und Training benötigt. Im Gestaltungsprozess spart sie Zeit und Aufwand, weil durch die Formulierung von Anforderungen im Vokabular der Image Schemata bereits Hinweise auf Gestaltungslösungen gegeben werden.

Die Image-Schema-Methode wurde so konzipiert, dass sie sich in das klassische Vorgehen bei der benutzerzentrierten Gestaltung interaktiver Systeme integrieren lässt. Der höchste Zusatzaufwand bei der Anwendung der Image-SchemaMethode gegenüber dem UCD-Prozess

Weitere Anwendungen der ImageSchema-Methode gibt es unter anderem für die Gestaltung von gestenbasierter Interaktion mit mobilen Geräten, für die Gestaltung und Evaluation von Musiksoftware, für Heizungssteuerungen und für Webbrowser-Software eingesetzt

174

(Bakker et al., 2009; Hurtienne & Langdon, 2010; Hurtienne et al., 2010; Lund, 2003; Wilkie & Holland, 2009). Andere Arbeiten untersuchen die Vorhersage, dass nach Image Schemata gestaltete UIs vom domänenspezifischen Vorwissen und der kognitiven Leistungsfähigkeit der Benutzer im Allgemeinen unabhängig sind (Hurtienne, Langdon, & Clarkson, 2009). Neben der Verwendung in konstruktiven Methoden zur benutzerfreundlichen und kreativen Gestaltung von UIs können Image Schemata auch in evaluativen Methoden, als Kriterien zur Bewertung der Benutzerfreundlichkeit einer bestehenden Schnittstelle, eingebunden werden. Das vom Bundesministerium für Bildung und Forschung (BMBF) unter dem Förderkennzeichen 01IS11017 geförderte Projekt „IBIS – Gestaltung intuitiver Nutzung mit Image Schemata“ integriert die Methode derzeit in Software-Entwicklungsprozesse zweier Kleinunternehmen. Dort wird die Methode in realen Kontexten angewandt und dadurch validiert und evaluiert. Mehr Informationen stehen unter http://www. ibis-projekt.de bereit. Die Grenzen und Implikationen der Methode der Image Schemata müssen den Designern bei der Anwendung bewusst sein. Besonders wichtig ist, dass Image Schemata konsistent und im kompletten Software-Entwicklungs-Prozess angewendet werden. Um eine hohe Vergleichbarkeit und die Reliabilität des Verfahrens sicherzustellen, müssen Designer darin übereinstimmen, welche Image Schemata mit bestimmten Benutzeräußerungen und UI-Elementen zu assoziieren sind. Erste Hinweise auf Übereinstimmung der Verteilung verschiedener image-schematischer Kategorisierungen durch zwei unabhängige Beobachter fallen mit etwa 75% zufriedenstellend aus (besonders im Vergleich zu einer durchschnittlichen Übereinstimmung bei Usability-Problemen in Expertenevaluationen von 22%; Hurtienne, 2011). Im laufenden Forschungsprojekt „IBIS“ wird zusammen mit Software-Herstellern das Kosten-Nutzen-Verhältnis der Anwendung der Image-Schema-Methode in einem Software-Engineering-Prozess ermittelt. So werden Aufwände und Nutzen bezifferbar


Usability Professionals 2012 Von Anforderungen zum Produkt

und Optimierungspotential kann abgeleitet werden, um die Anwendung in der Praxis weiter zu vereinfachen. So besteht weiterer Bedarf, den Aufwand für die Extraktion der Image Schemata und Metaphern aus den Benutzeräußerungen zu vereinfachen. Da viele Metaphern in verschiedenen Kontexten wiederholt auftauchen, sollen diese in der Zukunft gesammelt und in einem Katalog image-schematischer Gestaltungslösungen aufbereitet werden, so dass der Übergang von den Anforderungen zum Design noch schneller und einfacher vonstatten gehen kann.

Interaction, 239-246. New York: ACM. 7. Hurtienne, J., & Langdon, P. (2010). Keeping warm in winter: Image-schematic metaphors

Everyday Things. New York: Doubleday/ Currency. 18. Wilkie, K., Holland, S., & Mulholland, P.

and their role in the design of central heating

(2009). Analysis of conceptual metaphors to

controls. In Fourth International Conference

improve music software: The role of prior

of the German Cognitive Linguistics

experience in inclusive music interaction

Association (pp. 53-54). Bremen: University

design. In HCI 2009 Electronic Proceedings:

of Bremen.

WS4 – Prior Experience. Cambridge: British

8. Hurtienne, J., Weber, K., & Blessing, L. (2008). Prior Experience and Intuitive Use: Image

Computer Society. 19. Wood, L.E. (1998). User interface design:

Schemas in User Centred Design, 107-116.

Bridging the gap from user requirements to

In P. Langdon, P. J. Clarkson, & P. Robinson

design. Boca Raton: CRC Press.

(Eds.), Designing Inclusive Futures. London: Springer. 9. Hurtienne, J., Langdon, P., & Clarkson, P. J.

Literatur

(2009). Towards an Account of Sensorimotor

1. Bakker, S., Antle, A. N., & van der Hoven,

Knowledge in Inclusive Product Design. In C.

E. (2009). Identifying embodied metaphors

Stephanidis (Ed.), Universal Access in Human-

in children’s sound-action mappings. In P.

Computer Interaction: Addressing Diversity,

Paolini & F. Garzotto (Eds.), Proceedings

Lecture Notes in Computer Science (Vol.

of the 8th International Conference on Interaction Design and Children, 140-149.

5614, 251–260). Berlin: Springer. 10. Hurtienne, J., Stößel, C., Sturm, C., Maus,

2. Hampe, B. (2005). From perception to

A., Rötting, M., Langdon, P., & Clarkson,

meaning: Image schemas in cognitive

P. J. (2010). Physical gestures for abstract

linguistics. Berlin: Mouton de Gruyter.

concepts. Inclusive design with primary

3. Hassenzahl, M., Burmester M. & Koller, F. (2003). AttrakDiff: Ein Fragebogen zur

metaphors. Interacting with Computers. 11. Hurtienne, J. (2011). Image schemas and

Messung wahrgenommener hedonischer und

design for intuitive use. Exploring new

pragmatischer Qualität. In J. Ziegler & G.

guidance for user interface design (Doctoral

Szwillus (Hrsg.), Mensch & Computer 2003:

dissertation, Technische Universität Berlin).

Interaktion in Bewegung (187-196). Stuttgart,

Abgerufen von http://opus.kobv.de/tuberlin/

Leipzig: B.G. Teubner. 4. Hurtienne, J., & Blessing, L. (2007). Design

volltexte/2011/2970/pdf/hurtienne_joern.pdf 12. International Standards Organization (2010).

for Intuitive Use – Testing image schema

ISO 9241: Ergonomie der Mensch-System-

theory for user interface design. In ICED

Interaktion, Teil 210: Prozess zur Gestaltung

07 Paris, 16th International Conference on

gebrauchstauglicher interaktiver Systeme

Engineering Design, Proceedings of the conference (P_386, pp. 1-12). [CD-ROM]. Paris: Ecole Centrale. 5. Hurtienne, J. & Israel, J. H. (2007). Image schemas and their metaphorical extensions – Intuitive patterns for tangible interaction. In B. Ullmer, A. Schmidt, E. Hornecker, C. Hummels, R.J.K. Jacob, & E. van den Hoven

(ISO 9241-210:2010). 13. Johnson, M. (1987). The body in the mind: The bodily basis of meaning, imagination, and reason. Chicago, IL: University of Chicago Press. 14. Lakoff, G. & Johnson, M. (1999). Philosophy in the flesh. New York: Basic Books. 15. Lund, A. (2003). Massification of the

(Eds), TEI’07. First International Conference

intangible: An investigation into embodied

on Tangible and Embedded Interaction, 127-

meaning and information visualization

134. New York: ACM. 6. Hurtienne, J., Israel, J. H., & Weber, K. (2008).

(Doktorarbeit). Umea: Umea universitet. 16. Mohs, C., Hurtienne, J. , Kindsmüller, M.

Cooking up real world business applications

C. , Israel, J. H. , Meyer, H. A. & die IUUI

combining physicality, digitality, and image

Research Group (2006). IUUI – Intuitive Use

schemas. In A. Schmidt , H. Gellersen, E.

of User Interfaces: Auf dem Weg zu einer

van den Hoven, A. Mazalek, P. Holleis, & N.

wissenschaftlichen Basis für das Schlagwort

Villar (Eds.), TEI’08. Second International

“Intuitivität”. MMI-Interaktiv, 11, 75-84.

Conference on Tangible and Embedded

17. Norman, Donald (1988). The Design of

175


Bridging the Gap Between Analysis and Design Ein toolbasiertes Vorgehensmodell zur Entwicklung Mobiler Systeme Dr. Dennis Krannich Universität Bremen Bibliothekstraße 1 28359 Bremen krannich@tzi.de

Abstract Usability-Engineering beschäftigt sich seit über 30 Jahren mit der Analyse und Gestaltung von Computer-Systemen. Während Usability-Testing für stationäre Systeme meist standardisiert ist, stellen Mobile Systeme durch ihre Heterogenität neue Herausforderungen dar. In diesem Beitrag stellen wir ein toolbasiertes Vorgehensmodell vor, um die traditionelle Trennung von Analyse und Design aufzubrechen. Es besteht aus einem Phasenmodell und einem Rapid-Prototyping- und Usability-Testing-Instrument und ermöglicht (a) so früh wie möglich mit der Umsetzung prototypischer Entwürfe zu beginnen und diese hinsichtlich ihrer Usability zu untersuchen, (b) im originären Benutzungskontext und auf den späteren realen Endgeräten zu testen und (c) aussagekräftige Daten für die Evaluation zu sammeln. Nach der Beschreibung der Kernelemente präsentieren wir die Ergebnisse unserer Evaluation. Die empirischen Studien bestätigten das Konzept und zeigten vielversprechende Möglichkeiten für einen Paradigmenwechsel innerhalb dieses Forschungsfeldes.

1. Einleitung In den frühen 1980er Jahren – als die ersten Computerprogramme erschienen – waren nur Art und Umfang der Funktionalität von entscheidender Bedeutung, ob eine Anwendung verwendet wird oder nicht. In den letzten drei Jahrzehnten haben sich jedoch Gegenstandsbereiche, Methoden und Instrumente ständig erweitert und analog zum Wandel der Computersysteme weiter entwickelt. Im Allgemeinen gibt es vier Aspekte, die das Usability-Engineering beeinflusst haben: (1) die Vision des Computers als Medium; (2) die Entwicklung von Desktop- und Internet-Anwendungen mit komplexen grafischen Benutzungsoberflächen (GUI); (3) der Einsatz von Mobilen Systemen, nicht nur für die Sprachkommunikation, sondern als universelles und multifunktionales Gerät; und (4) die Verlagerung von performance- und aufgabenorientierten Systemen zu Erfahrungen mit und durch digitale Produkte. Um Mobile Systeme mit

176

einem angenehmen Benutzungserlebnis und einer guten Gebrauchstauglichkeit zu entwickeln, müssen sich Entwickler und Designer daher mit den Herausforderungen und Beschränkungen, die durch die Mobile Welt verursacht werden, beschäftigen. Mit der Einführung von Smartphones, dem iPhone und dem iPad hat sich der Bereich der Mobilen Systeme erneut verändert, nicht nur in Bezug auf Formfaktor, sondern insbesondere in Bezug auf die Nutzungsszenarien (z. B. beiläufige Benutzung und weniger komplexe Aufgaben), Anwendungstypen (z. B. Casual Games, Augmented Reality und immersive Anwendungen) und Interaktionsmodalitäten (z. B. Multitouch, Gesten- und Sprachsteuerung). So überrascht es nicht, dass Forscher und Praktiker zunächst versucht haben, die traditionellen Methoden des UsabilityEngineering eins zu eins für diese neuen Systeme anzuwenden, um die Interaktion zu bewerten und die Zufriedenheit der Gebraucher zu messen. Leider mit wenig Erfolg: Verschiedene Autoren bemängeln

Keywords: /// Mobile Usability /// Rapid-Prototyping /// Usability Testing /// ripcord

die schlechte Usability Mobiler Systeme (z. B. Weiss 2002; Bernhaupt 2008) und sehen dies unter anderem in der fehlenden Berücksichtigung des Benutzungskontextes begründet (z. B. Bernhaupt 2008). Auch wenn das vorliegende Thema etwas antiquiert erscheint, so sind die bisher erreichten Ergebnisse wenig zufriedenstellend. Dies lässt sich anhand von zwei Punkten verdeutlichen: (1) Die hauptsächliche Begrenzung der klassischen Methoden besteht in ihrer Laborfixierung und damit in der Ausblendung des Benutzungskontextes. Der Laboransatz geht von dem „Irrglauben“ aus, die Gebrauchstauglichkeit eines Systems sei nur von den Eigenschaften des Systems abhängig. Diese Annahme ist gänzlich obsolet, wenn sich Systeme nicht mehr an einem Ort (Arbeitsplatz) befinden, sondern von ihren Gebrauchern durch die Welt bewegt werden, denn die Interaktion differiert, da sie (a) oft unterbrochen wird, (b) sehr stark vom Benutzungskontext


Usability Professionals 2012 Von Anforderungen zum Produkt

abhängt und (c) häufig an Orten stattfindet, die für eine Interaktion gänzlich ungeeignet erscheinen. (2) Seit dem Beginn der Software-Ergonomie existiert eine klassische Trennung zwischen Analyse und Design. So gibt es die Zuständigkeit der (Arbeits-)Psychologie für die Analyse und Kritik der UsabilityProbleme und die Zuständigkeit der Informatik für die Entwicklung und Einführung derartiger Systeme. Die Übersetzung der Analyseergebnisse in konstruktive Anforderungen stellt eine kaum bewältigte Herausforderung dar, eine möglicherweise grundsätzliche methodische Lücke, die aus dem unterschiedlichen Methodenverständnis von Sozial- und Technikwissenschaften resultiert. Um diese Herausforderungen endgültig zu meistern, sind daher neue Methoden, Werkzeuge und Vorgehensmodelle erforderlich, die gemeinsame Aspekte der mobilen Geräte reflektieren und ihre Unterschiede respektieren. Gemeinsame Aspekte sind nicht nur durch physikalisch-stoffliche Eigenschaften (z. B. Bildschirmgrößen, Eingabemodalitäten, Formfaktoren und Haptik) und SoftwareEinschränkungen (wie z. B. Speicher-und Computing-Ressourcen) begrenzt, sie umfassen auch den (meist heterogenen) Benutzungskontext. Das allgemeine Ziel sollte daher sein, abstrakte Modelle und praktische Instrumente zu einer Synthese zu bringen und diese in den gesamten Entwicklungsprozess so zu integrieren, dass Usability-Testing nicht mehr als Basis für eine ex-post-Kritik an Usability-Problemen des Endprodukts zu verstehen ist – die meist folgenlos bleibt, weil Änderungen praktisch nicht mehr möglich sind – sondern als Brücke zwischen Analyse und Design. Dabei geht es weniger darum, existierende Methoden in Frage zu stellen, sondern ein neues Bewusstsein zu schaffen, Analyse und Design als einen geschlossenen Prozess der Systementwicklung zu verstehen, und möglichst früh im Entwicklungsprozess mit der Entwicklung, Exploration und Evaluation von Prototypen unter realen Bedingungen zu beginnen.

Darüber hinaus sollten wir uns für zukünftige technologische Entwicklungen rüsten: Durch die Etablierung generativer Fertigungstechniken (z. B. in Form von Fab Labs) sind wir aufgrund kostengünstiger Technologien (z. B. RepRap oder MakerBot Replicator) in der Lage stoffliche Artefakte selbst zu kreieren, die wir mit Elektronik und einer grafischen Benutzungsoberfläche zum Leben erwecken können. Gerade diese technologischen Entwicklungen ermöglichen uns eine holistische Betrachtung eines Systems bestehend aus Hard- und Software, anstatt diese als zwei getrennte Bereiche zu verstehen. Somit könnten wir das Konzept des Rapid-Prototypings auf beide Bereiche gleichermaßen anwenden und deren Zusammenhänge und Abhängigkeiten erforschen. 2. Methodische Ansätze des Mobile Usability-Testings Die Unterschiede von mobilen Geräten und deren Anwendungen stellen eine große Herausforderung an das UsabilityEngineering und die Software-Entwicklung im Allgemeinen: Eingabemethoden, Formfaktoren, Betriebssystemen, zusätzliche Features wie Netzwerkfähigkeit und ihre Anwendungsgebiete unterscheiden sich signifikant. Für die Durchführung von Usability-Tests (Benutzertests) ist es daher erforderlich (a) aussagekräftige Daten für die spätere Analyse zu sammeln, (b) die Tests im Nutzungskontext und auf realen Endgeräten durchzuführen und (c) die Test so früh wie möglich anzusetzen, um kostenintensive Ausbesserungen oder Neuentwicklungen des Produkts zu verhindern. Es existieren diverse Ansätze zur Aufzeichnung der Interaktionen, in denen beispielsweise Kameras verwendet werden (z. B. Holtz-Betiol u. de Abreu-Cybis 2005; Kiljander 2004 oder Roto et al. 2004). Alle Methoden haben jedoch eines gemeinsam: Sie beeinflussen die Haptik des Geräts und verändern dessen Formfaktor erheblich, indem sie das Endgerät in eine verkabelte und unhandliche Maschine verwandeln und die erfassten Daten durch Lichteinflüsse und starkes Ruckeln beeinträchtigen.

Zudem sind derartige Ansätze mit einem hohen Vorbereitungsaufwand (z. B. durch Verkabelung) verbunden und stellen – bedingt durch die Behinderung in der Benutzung und dem erhöhten Aufmerksamkeitsfaktor in der Öffentlichkeit – einen psychologischen Hemmfaktor für die Testperson dar. Letztendlich geht der ursprüngliche Charakter eines kleinen und mobilen Endgerätes verloren. Verschiedene Studien (u. a. Kjeldskov & Stage 2004; Rantanen et al. 2002), haben bewiesen, dass der originäre Benutzungskontext in Labortests nicht hinreichend simuliert werden kann. Bernhaupt et al. (2008) merken an, dass nicht einmal so genannte Portable Usability-Labore, bei denen das Test-Equipment zum Kunden beziehungsweise in den Benutzungskontext gebracht wird, diese Beeinträchtigungen bewältigen können. Der starke Nutzen von Emulatoren und Simulatoren auf einem Desktop-Computer wurde zwar in verschiedenen Untersuchungen gezeigt, dennoch werden bestimmte Aspekte, wie die Haptik, der Benutzungskontext und die technische Beschränkungen und Eigenschaften stark vernachlässigt (vgl. u. a. Dahl et al. 2009; Ballard 2008). Das frühzeitige Durchführen von UsabilityTests ist weitgehend verbreitet (Weiss 2002; Bernhaupt et al. 2008). Ansätze wie das Participatory Design oder das User-Centered Design sollen Akzeptanz und eine Steigerung der Qualität forcieren. Dabei sind herkömmliche Prototyping-Verfahren als proof-of-concept hilfreich und äußerst zeit- und kostensparend. Ein derartiges Vorgehen findet jedoch selten im vollen Umfang – durchgehend von der Konzeption bis zum fertigen Produkt – statt. Es lässt sich daher konstatieren, dass, obwohl verschiedene Werkzeuge zum Erstellen von Prototypen und ein breites Spektrum methodischer Ansätze zum Mobile Usability-Testing existieren, effektive Tools mit denen man schnell und iterativ grafische Benutzungsoberflächen erstellen und diese direkt auf dem Zielgerät im originären Benutzungskontext testen kann, fehlen.

177


Aufzeichnungsfunktionalität und Bereitstellung der Prototypen. Der Mobile Client (MC) sendet die getätigten Eingaben/ Interaktionen an den Mobile Server (MS). Dieser kann – je nach den Gegebenheiten des mobilen Endgeräts – entweder auf einem separatem Gerät oder auf dem Testgerät selbst installiert sein. Der MS interpretiert die Eingaben und sendet ein Ergebnis an den MC zurück. Dies ist entweder ein Screenshot (J2ME-basierte Endgeräte) oder eine HTML-Seite (iOSbasierte Endgeräte). Der MS zeichnet parallel Audiosignale auf und fügt diese mit den Bildschirmabgriffen, dem Gesicht des Benutzers (iOS-basierte Endgeräte mit einer Frontkamera) und Kontextinformationen (z. B. Touch-Position, Gesten, Tastatureingabe, GPS-Koordinaten und Zeitstempel) zu einer Videodatei zusammen. Durch die Verbindung mehrerer MC (1 Master, n Viewer) soll das Testen in Gruppen (basierend auf der Co-Discovery Methode) ermöglicht werden. Als Verbindung zwischen MS und MC können je nach Unterstützung des Endgeräts Bluetooth oder Wi-Fi verwendet werden. Eine Supervision Station zur entfernten Beobachtung und Steuerung kann via UMTS oder Wi-Fi angebunden werden. Abb. 1.

3. Ein Toolbasiertes Vorgehensmodell Basierend auf dem Mangel an geeigneten Werkzeugen und Methoden für die Entwicklung Mobiler Systeme, haben wir ein toolbasiertes Vorgehensmodell, bestehend aus drei Komponenten, entwickelt: (1) ein Instrument (ripcord2.0) zum Rapid-Prototyping und Usability-Testing; (2) ein Phasenmodell zum Einbinden von Rapid-Prototyping und Usability-Tests in den Software-Entwicklungsprozess; und (3) ein Metamodell zum Postulieren von Forschungsfragen, zur Bestimmung von Arbeitsaufgaben und Prüfkriterien, und zur Auswahl des geeigneten Testansatzes (nicht in diesem Beitrag behandelt, eine

178

detaillierte Beschreibung ist in (Krannich 2010) zu finden). 3.1. ripcord2.0 = Rapid-Prototyping + Usability-Testing Tool Im Folgenden beschreiben wir die allgemeine Funktionalität des ripcord2.0 Systems, wie in der [Abb. 1] dargestellt. Eine detaillierte Beschreibung kann in (Krannich2010) gefunden werden. Genereller Ansatz: Das generelle Konzept sieht zwei wesentliche Bestandteile vor: (1) die einfache, schnelle und iterative Erstellung und Modifikation von GUI-Prototypen in Form von HTML5 + CSS3 + JS und (2) die Trennung von

Entfernte Beobachtung und Steuerung: Mit der Supervison Station (SuS) kann der Testleiter auf den MS über das Internet zugreifen, um sich Bildschirminhalte und Interaktionen anzuschauen. Er kann auch Änderungen an der Anwendung vornehmen, wie zum Beispiel das Aufrufen einer alternativen Version. Darüber hinaus kann der Testleiter Teile oder sogar den kompletten Prototypen ersetzen, auch während des Tests. Auf diese Weise können Fehler, die zum Abbruch geführt hätten, beseitigt werden oder alternative Benutzungsoberflächen oder Interaktionskonzepte „on-the-fly“ umgesetzt und ausgewertet werden (die Testbedingungen sollten hierdurch jedoch nicht geändert werden). Wir nennen diesen Ansatz „Remote Rapid-Prototyping“. Aufnahme des Benutzungskontextes: Context Recording (CR) wird verwendet, um mögliche Einflüsse der Testperson sowie das


Usability Professionals 2012 Von Anforderungen zum Produkt

Abb. 2.

Umfeld, in dem sich die Testperson befindet, aufzuzeichnen. Dies kann durch eine weitere Person, Kameras oder Sensoren erfolgen (GPS-Koordinaten, Zeit, Temperatur, Lichtverhältnisse, Lautstärke, etc.). Schnelles und iteratives Erstellung von Prototypen (Rapid-Prototyping): Der Prototyp wird mit HTML5, CSS3 und JavaScript erstellt. Die Auswahl dieses Ansatzes ermöglicht nicht nur Programmierern, sondern auch Designern – die mit einer komplexen Programmiersprache (wie Objective-C oder Java) nicht vertraut sind – Prototypen zu erstellen. Spezielle HTML-kompatible Attribute können für Ereignisse (wie z. B. Vibration oder Ton) verwendet werden. Neben der reinen Verwendung von HTML können Entwickler CSS für die Gestaltung und JavaScript für komplexe Interaktionen nutzen, sowie Bibliotheken wie jQuery einbinden. So können die erstellen Prototypen leicht in andere Web-basierte Frameworks wie Apache Cordova (PhoneGap) oder Appcelerator Titanium überführt werden.

3.2. Phasenmodell Das Phasenmodell besteht aus fünf Phasen (siehe [Abb. 2]). Der Ablauf der einzelnen Phasen ist nicht als streng lineares Schema zu verstehen. Bei Bedarf werden Schleifen und Rückkoppelungen zwischen den einzelnen Phasen durchgeführt, das

heißt, es können zum Beispiel Bestandteile auf dem Programmierungsprozess (Schritt 4) wieder in den Prototyping-Prozess (Schritt 1 und 2) übergeben werden. Schritt 3 stellt die Schnittstelle zwischen Prototy- ping und der eigentlichen Produktentwick- lung dar. Das toolbasierte Vorgehensmodell ermöglicht die Erprobung neuer Funktionen, Gestaltungselemente und Interaktionskonzepte, wobei diese (a) ganz bewusst aus dem Konzept heraus prototypisch umgesetzt werden, (b) im Laufe des Entwicklungsprozesses hinzukommen, (c) als Proof-of-Concept oder Machbarkeitsstudie umgesetzt werden, oder (d) iterativ verändert werden. Wesentliches Augenmerk liegt in der Skalierbarkeit in den einzelnen Phasen und der Flexibilität zwischen den einzelnen Phasen. So können beispielsweise unterschiedliche Prototyping-Ansätze (z. B. low- und high-fidelity oder horizontal und vertikal) verwendet werden oder beliebig viele Bestandteile der Prototypen in die Implementierung übernommen werden. 3.3. Technische Implementierung Das Rapid-Prototyping- und UsabilityTesting-Instrument wurde exemplarisch für den Mobile Server (MS) in Objective-C für Mac OS X und für den Mobile Client (MC) in J2ME (MIDP2.0/CLDC1.1 midlet) für ein

Mobiltelefon umgesetzt. Darüber hinaus existieren eine Portierung des Ansatzes für iOS-basierte Endgeräte, sowie eine Weiterentwicklung (in Bearbeitung), die den Mobile Client und den Mobile Server in einer Anwendung kombiniert und ausschließlich für iOS-basierte Endgeräte ausgerichtet ist. Zur Verbindung zwischen MS und MC können entweder Bluetooth (J2ME-Geräte) oder WiFi (via Bonjour Service) verwendet werden. Die Kommunikation zwischen MS und MC erfolgt über den Austausch spezieller „ripcord Nachrichten“ (RN), die über einen bidirektionalen Kanal gesendet werden, wobei die Reihenfolge dieser Nachrichten sehr genau festgelegt ist. Jede der Nachrichten besteht aus einem Kopfbereich (Header) und einem für die Nachricht spezifischen Inhaltsbereich (Body). Alle Integer werden als Big Endian abgespeichert. Es werden die folgenden sieben Message Type Identifier (MTI) unterschieden: RN1 Hello Server, RN2 Image, RN3 Event, RN4 JFIF head, RN5 JFIF tail, RN6 Vibrate, RN7 Goodbye, RN8 Mouse Event und RN9 URL Change Event. Bildschirminhalte können entweder an den MC gesendet werden (J2ME-Geräte) oder an den MS gesendet werden (iOS-Geräte). Der idealtypische Anwendungsfluss für ein iOS-Gerät sieht wie folgt aus: Nach Tippen auf einen Link wird die Fingerposition an den MS gesendet. Anschließend wird auf

179


dem MC ein Bildschirmfoto erstellt, an den MS gesendet und dort zusammen mit der Fingerposition als ein neues Keyframe gerendert und im Videostream gespeichert. Als nächstes wird ein HTTP Request an den MS gesendet und die korrespondierende Website empfangen (HTTP Response) und auf dem MC angezeigt. Der neue Bildschirminhalt wird abgegriffen und als Bild an den MS gesendet, wo es als neues Keyframe im Videostream gespeichert wird. Parallel dazu werden Audio und die Frontkamera des mobilen Geräts sowie die GPS-Position aufgezeichnet. Bei J2ME-basiertem Endgeräten werden die Tastatureingaben an den MS gesendet, dort interpretiert (z. B. Ausführen eines Links) und die geänderten Bildschirmsegmente als komprimiertes JPEG-Bild an den MC gesendet. Der Bildschirminhalt wird ebenso als neues Keyframe im Videostream gespeichert. 4. Ergebnisse der Evaluation und deren Analyse Zum Testen und Bewerten des toolbasierten Vorgehensmodells wurde eine Methodentriangulation bestehend aus Beobachtung, Befragung und Experteninterviews verwendet. Es wurden fünf Workshops (mit einer Grundgesamtheit von 72 Teilnehmern) und vier Experteninterviews durchgeführt. Die Erkenntnisse aus den Workshops führten zu einer vorläufige Theoriebildung, die durch Experteninterviews überprüft wurde. Der Fokus der Evaluation lag nicht auf der Analyse einer bestimmten mobilen Anwendung, sondern auf der Bewertung des toolbasierten Vorgehensmodells im Allgemeinen. Eine detaillierte Beschreibung des Evaluationsdesigns ist in (Krannich 2010) zu finden. Zusammenfassend kann ein erfolgreicher Verlauf und eine positive Einstellung der Befragten festgehalten werden. Betrachtet man die Ergebnisse der Workshops und Experteninterviews, so lässt sich feststellen, dass die Experten die gewonnenen Erkenntnisse aus den Workshops mit ihren Erfahrungen größtenteils bestätigen konnten. Nachteile wurden insbesondere in der

180

Anwendbarkeit des Ansatzes in späteren Entwicklungsphasen gesehen. Funktionalität und Performance: Sowohl die Workshop-Teilnehmer, als auch Experten bevorzugten das aktuelle System in Bezug auf Funktionalität und Aufwand für die Inbetriebnahme. Im Vergleich zu anderen Ansätzen ist ripcord2.0 einfach zu bedienen und hat keinen Einfluss auf die Testperson durch zusätzliche Geräte oder Kabel. Fast alle Befragten aus den Workshops kritisierten jedoch den fehlenden Anwendungsfluss (insbesondere das automatische Weiterleiten oder Aufblinken von Statusmeldungen). Die Hälfte der Testpersonen bemängelte die Übertragungsverzögerung, die durch die langsame Bluetooth-Verbindung verursacht wird. Im Gegensatz dazu haben die Experten die Übertragungsverzögerung und fehlende automatisierte Sequenzen als nicht gravierend bewertet. Aus ihrer Sicht hat dies keinen Einfluss auf das generelle Anwendungs- und Interaktionskonzept und ist ausreichend genug zum Explorieren und Evaluieren der Prototypen. Darüber hinaus wurden mehrere Nachteile entdeckt: (a) fehlende Animationen und flüssiger Spielablauf, (b) keine Berücksichtigung von Multiuser-Apps, und (c) keine Videowiedergabe möglich. Einflüsse des mobilen Kontextes: Die Experimente zeigten, dass die Probanden bei Tests mit einem Simulator am Desktop-PC zwar konzentrierter waren, als im originären Benutzungskontext, dennoch konnten einige Usability-Probleme – insbesondere in Bezug auf das Interaktionskonzept – nur durch den mobilen Kontext aufgedeckt werden. Auch die Dauer der Tests unterschied sich stark. So ist zu schlussfolgern, dass einige Usability-Probleme nur durch Dual-Task-Situationen aufgedeckt und Aussagen über Interaktionsdauer und -fluss nur im originären Benutzungskontext getätigt werden können. Potentiale der Supervision Station: Alle Befragten (Experten und WorkshopTeilnehmer) konnten die Testpersonen im Kontext beobachten und die Benutzungsoberfläche (Prototypen) aus der Ferne

wechseln und verändern. Die Fähigkeit, Teile des Prototyps zu verändern, zu ersetzen oder hinzufügen, ermöglicht nicht nur sofort neue Variationen zu testen, sondern gibt Entwicklern auch die Möglichkeit, Fehler schnell zu beheben, die den Test abbrechen würden, und verhindert so ein aufwändiges Koordinieren neuer Tests. Potentiale des Rapid-Prototyping: In Bezug auf Lesbarkeit und visuelle Repräsentation von Informationen, empfanden die Probanden die Simulatoren aufgrund ihres nicht-nativen Skalierungsfaktors angenehmer. Andererseits führte dieses Phänomen auch zu schweren UsabilityProblemen: Vor allem in den PrototypingWorkshops konnten wir feststellen, dass die Probanden die Proportionen und Dimensionen des Bildschirms falsch eingeschätzt haben, so dass einige Elemente auf dem realen Endgerät (aufgrund der Bildschirmgröße und Auflösung) nicht mehr lesbar waren. Anwendbarkeit von bestehenden Usability-Methoden: Wir haben festgestellt, dass die Co-Discovery Methode besonders gut für das toolbasierte Vorgehensmodell geeignet ist, da es eine natürliche Kommunikationssituation erzeugt. Dennoch müssen Alternativen untersucht werden, um psychologische Einflüsse zu verhindern, wenn Methoden wie zum Beispiel Thinking-Aloud Protocol verwendet werden sollen. Zudem ergab die Evaluation, dass weder ein Methodenmix erforderlich ist, noch die Anwendbarkeit vorhandener Methoden beeinträchtigt wird. Ein Kompensieren etwaiger Schwachpunkte, wie es in anderen Ansätzen der Fall ist, ist daher nicht erforderlich. Korrelation zwischen Usability-Testing und Rapid-Prototyping: Ein wichtiger Diskussionspunkt der Experteninterviews war der Zusammenhang zwischen Prototyping und Usability-Testing. Auch wenn in kleinen und mittelständischen Unternehmen das Prototyping und Usability-Testing aufgrund des geringen Budgets und des enormen Zeitdrucks kaum angewendet wird, wurde dieser Aspekt von allen Experten stark betont. Die Experteninterviews haben gezeigt, dass


Usability Professionals 2012 Von Anforderungen zum Produkt

es von Vorteil sein kann, frühzeitig mit dem Prototyping anzufangen und gewisse Funktionen, Interaktionskonzepte und Gestaltungen zu testen, bevor eine kostenintensive Implementierung stattfindet. Durch Ansätze wie PhoneGap könnte das Prototyping noch effektiver gestaltet werden, da einzelne oder komplette Teile der Prototypen in die Anwendung fließen könnten.

Literatur 1. Bernhaupt, R., Mihalic, K., und Obrist, M. Usability Evaluation Methods for Mobile Applications. In: Lumsden, J. (Hrsg.) Handbook of Research on User Interface Design and Evaluation for Mobile Technology, IGI Global, S. 745-758. 2008. 2. Ballard, B. Designing the Mobile User Experience. Wiley, 2007. 3. Dahl, Y., Alsos, O. A. und Svanas D.

5. Fazit und Ausblick

Evaluating Mobile Usability: The Role of Fidelity in Full-Scale Laboratory Simulations with Mobile ICT for Hospitals. In: Jacko, J. A.

Durch den Ansatz des toolbasierten Vorgehensmodells wurde die Realisierung eines Instruments bewiesen, dass auf der einen Seite Rapid-Prototyping und Usability-Testing kombiniert und zum anderen, dass es technisch möglich ist, ein Instrument zu entwickeln, dass nicht nur die Haptik des Mobilen System unangetastet lässt, sondern auch das Testen im originären Benutzungskontext ermöglicht. Durch die Kombination mit dem Phasenmodell wurde der Weg für das frühzeitige Testen bereitet, so dass Ideen und Kreativität nicht der „Schere im Kopf“ zum Opfer fallen müssen. Gerade diese Tatsache wird in Zukunft eine entscheidende Rolle spielen, da es durch die hohen Anforderungen der Gebraucher und dem enormen Zeit- und Kostendruck auf innovative Hilfsmittel ankommt.

(Hrsg.) Human-Computer Interaction, Part 1, HCII 2009, LNCS 5610, S. 232-241, Springer Verlag Berlin Heidelberg. 2009. 4. Holtz-Betiol, A. und de-Abreu-Cybis, W. Usability-Testing of Mobile Devices: A Comparison of Three Approaches. In: Proceedings of INTERACT 2005, LNCS 3585. Springer Berlin/Heidelberg, S. 470-481. 2005. 5. Kiljander, H. Evolution and Usability of Mobile Phone Interaction Styles. Helsinki University of Technology. Publications in Telecommunications Software and Multimedia. Otamedia Oy, 2004. 6. Kjeldskov, J. und Stage, J. New Techniques for Usability Evaluation of Mobile Systems. In: International Journal of Human-Computer Studies (IJHCS), Vol. 60, S. 599-620. 2004. 7. Krannich, D. “Mobile Usability-Testing: Ein toolbaisertes Vorgehensmodell zum Rapid-Prototyping und Usability-Testing von Mobilen Systemen im orgininären

Die Verbindung von Prototyping- und Usability-Testing und deren Integration in einen übergangslosen Entwicklungsprozess kann nur den Anfang darstellen. Dieser Ansatz stellt einen entscheidenden Beitrag für das Mobile Usability-Testing und die zukünftige Entwicklung Mobiler Systeme im Allgemeinen dar und zeigt vielversprechende Möglichkeiten für einen Paradigmenwechsel innerhalb dieses Forschungsfeldes.

Benutzungskontext”. Dissertation, E-LIB Universität Bremen, 2010. 8. Rantanen J., Impio J., Karinsalo T., Reho A., Tasanen M. und Vanhala J. Smart Clothing Prototype for the Artic Environment. In: Personal and Ubiquitous Computing, 6, S. 3-16. 2002. 9. Roto, V., Oulasvirta, A., Haikarainene, T., Kuorelahti, J., Lehmuskallio, H. und Nyyssönen, T. Examining Mobile Phone Use in the Wild with Quasi-Experimentation, Helsinki Institute for Information Technology,

In unserer zukünftigen Forschung werden wir uns auf die Entwicklung des ripcord Systems für andere Betriebssysteme (wie z. B. iOS und Android) konzentrieren. Wir werden das toolbasierte Vorgehensmodell in realen Projekten einsetzen, weiter evaluieren und optimieren.

August 2004. 2004. 10. Weiss, S. Handheld Usability. Wiley & Sons, 2002.

181


Design mit Nicht-Designern

Lennart Hennigs Deutsche Telekom AG

Abstract Der Beitrag, den User-Experience- (UX) Professionals in Entwicklungsprojekten leisten können, wird häufig missverstanden. Ein Grund dafür ist, dass UX-Professionals den Nutzen ihrer Arbeit immer noch nicht gut genug kommunizieren. Ein weiterer Grund ist, dass man einem fertigen Produkt die Vielzahl der ihm zugrunde liegenden Design-Entscheidungen nicht ansieht. Die Komplexität der Produktgestaltung ist für Außenstehende nicht immer ersichtlich. Um ein besseres Verständnis für unsere Arbeit zu schaffen, müssen sie Nicht-UX-Professionals besser in unsere Arbeit einbinden.

1. Einleitung Gute Produkte zu gestalten – das ist das Ziel von UX-Professionals. Unter guten Produkten verstehen sie gebrauchstaugliche (usable) Produkte, die Nutzer bei der Erledigung ihrer Aufgaben optimal unterstützen. Das Produkterlebnis des Nutzers (die User Experience) soll ein positives sein. Dieses grundlegende Ziel hat sich seit dem Bestehen dieser Disziplin nicht verändert – geändert haben sich jedoch die Rahmenbedingungen, in denen UXProfessionals arbeiten. 2. Rückblick Anfangs bestand die größte Herausforderung von UX-Professionals darin, während der Produktentwicklung berücksichtigt zu werden. Der Nutzen von User-CenteredDesign- und Usability-Aktivitäten für die Produktentwicklung war größtenteils unbekannt. Wenn überhaupt, wurden sie meist erst am Ende der Produktentwicklung eingebunden, um die Gebrauchstauglichkeit von fertigen (oder fast fertig gestellten) Produkten in Usability-Tests zu überprüfen. Wurden Verbesserungspotentiale gefunden,

182

Keywords: /// Design /// Konzeption /// interdisziplinäre Zusammenarbeit

waren diese in der Regel nicht mehr umzusetzen – Zeit, Budget und Ressourcen waren dafür nicht eingeplant worden.

berücksichtigt werden. Kommt einer dieser Faktoren „zu kurz“, wird das Produkt nicht erfolgreich sein.

Um früher und mehr Berücksichtigung zu finden, entwickelten sie User-CenteredDesign-Prozessmodelle (siehe z. B. Mayhew 1999, Constantine & Lockwood 1999, ISO 2010), in denen Rollen, Aktivitäten und Dokumente beschrieben sind, mit deren Hilfe gebrauchstaugliche Produkte erstellt werden können. Diese Modelle konnten dann, wie die der anderen Projektbeteiligten (wie z. B. von Entwicklern, Qualitätsmanagement, Anforderungsmanagement, Testing, ...) bei der Planung neuer Projekte genutzt werden. UX-Professionals versuchten, den Nutzen und den „Return on Investment“ ihrer Disziplin mit Hilfe von Zahlen zu belegen (Bias 2005).

Heutzutage sind Usability und User Experience in der Produktentwicklung keine Fremdworte mehr. Es kann ein gewisses Verständnis vorausgesetzt werden, und der Nutzen von UX-Aktivitäten muss nicht in jedem Projekt von neuem vermittelt werden. Dafür sehen sich UX-Professionals vor neue Herausforderungen gestellt.

Außerdem änderte sich das Selbstverständnis von UX-Professionals. Sie erkannten, dass es zu eng gedacht ist, sich ausschließlich auf die Gebrauchstauglichkeit zu fokussieren. Don Norman (1999) nutzt die Metapher eines dreibeinigen Schemels, um die drei Faktoren (= Beine), die ein erfolgreiches (Software-) Produkt benötigt, zu beschreiben: Technik-, Business- und Nutzeranforderungen. Diese müssen zu gleichen Teilen bei der Software-Entwicklung

3. Die Situation heute In der Software-Produktentwicklung werden heute vermehrt agile Methoden, siehe Beck (2001), Schwaber und Sutherland (2011) und Poppendieck (2004), eingesetzt. Der Einsatz phasenorientierter Ansätze, wie zum Beispiel das Wasserfall-Model, geht zurück. Das Ziel agiler Entwicklung ist es, durch kürzere Entwicklungs-Zyklen ein planbareres und qualitativ hochwertiges Ergebnis zu erhalten. Produkte werden in kurzen Iterationen, die in der Regel zwischen ein bis vier Wochen dauern, entwickelt. Am Ende


Usability Professionals 2012 Von Anforderungen zum Produkt

eines solchen Zeitraumes soll mindestens eine Funktion vollständig umgesetzt und getestet sein („potentially hipable functionality“). Im Gegensatz zu den bisherigen Phasenmodellen werden Produkte bei der agiler Entwicklung interdisziplinär entwickelt, dass heißt alle beteiligten Personen bzw. Rollen arbeiten gleichzeitig an der Umsetzung mit. In der Regel sind diese Teams autark – sie organisieren und priorisieren ihre Arbeit selbstständig. Eine übergreifende Priorisierung wird anhand von Business-Zielen vorgenommen und umzusetzende Funktionalitäten werden regelmäßig durch Kunden-Feedback validiert. Da es bei der agilen Entwicklung keine festen Entwicklungsschritte gibt, bleibt UX-Professionals weniger Zeit für Analyse und Konzeption. Sie sind in der Regel Teil eines agil arbeitenden Teams und müssen alle Aktivitäten, die sie durchführen wollen, im Team durchsetzen, planen und verwirklichen. 4. Herausforderungen von UX-Professionals Aus diesem Grund ist die Arbeit in interdisziplinären Teams die größte Herausforderung für UX-Professionals heutzutage. Sie müssen sich fragen, wie sie ein positives Produkterlebnis gewährleisten wollen. Sie sind in interdisziplinären Teams, die in SoftwareProjekten hauptsächlich aus Entwicklern bestehen, in der Regel unterrepräsentiert. Außerdem müssen sich UX-Professionals fragen, welchen zusätzlichen positiven Beitrag sie mit ihrer Ausbildung und Sicht auf das Produkt im Team leisten können. Eine Stärke von UX-Professionals erwächst daraus, dass sie das angestrebte Produkterlebnis planen und gestalten. Dies geht über die alleinige Betrachtung der Gebrauchstauglichkeit hinaus. Neben der typischen Nutzung des Produkts betrachten sie (hoffentlich) auch Themen wie den Verkaufsprozess, die Installation und Erstnutzung, die Bearbeitung von Servicefällen, usw. Aus diesem Blickwinkel betrachtet gehört zu dem Produkt, neben

der Software selbst, die Verpackung, Handbücher, Werbung, das Branding, etc. Und genau das sollte auch das Hauptanliegen der Arbeit von UX Professionals sein: Ein gemeinsames Verständnis des Produkterlebnisses vermitteln, kommunizieren und sicherstellen – und auf diese Weise gewährleisten, dass ein Entwicklungsprojekt „auf Kurs bleibt“. 5. Produktentwicklung und „bösartige“ Probleme Eine Herausforderung dabei ist, dass Produktentwicklungs- und Design-Projekte per Definition „bösartige“ Probleme sind (siehe Poppendieck 2002 und Dorst 2003). Als bösartig bezeichnet man schwer lösbare Probleme, die gewisse Eigenschaften gemein haben (siehe Rittel 1973): Eine Vielzahl unterschiedlicher Stakeholder sind an der Erarbeitung der Lösung beteiligt. Natürlich haben diese unterschiedliche Vorstellungen und Prioritäten. Die Anforderungen an die Lösung sind komplex und miteinander verwoben. Das Problem ist schwer einzukreisen und verändert sich während der Lösungsfindung. Das Problem ist daher „einmalig“ – zur Lösung des Problems kann man nicht nach „Schema F“ vorgehen. Außerdem gibt es im Voraus keinen Hinweis, was eine optimale Lösung sein kann. Verschiedene Lösungswege sind denkbar und möglich. Roberts (2000) unterscheidet drei Ansätze, mit denen man sich bösartigen Problemen näher kann: autoritäre, wettbewerbsorientierte und kollaborative. Bei einem autoritären Ansatz gibt es eine Entscheidungsinstanz, welche die „Marschrichtung” vorgibt. Bei einem wettbewerbsorientierten Ansatz lässt man Teams gegeneinander antreten. Bei einem kollaborativen Ansatz versucht man, gemeinschaftlich eine Lösung zu erarbeiten. Da bei agilen Projekten das Team im Vordergrund steht, empfiehlt es sich, dort ein kollaboratives Vorgehen zu wählen.

John C. Camillus (2008) schlägt zur Lösung bösartiger Probleme folgendes vierschrittiges kollaboratives Vorgehen vor: 1. Definiere eine gemeinsame Vision. 2. Dokumentiere Ideen und kommuniziere sie. 3. Beteilige Stakeholder. 4. Mache kleine Schritte, überprüfe dein Ergebnis und iteriere. Gut ist, dass sich eine Reihe von UX- und Design-Aktivitäten in diese vier Kategorien einsortieren lassen. UX-Professionals besitzen also grundsätzlich die Werkzeuge, um bösartige Probleme anzugehen. Welche Methoden sich dazu eignen, wird im Folgenden vorgestellt. 6. Eine gemeinsame Produktvision erstellen Projektbeteiligte haben in der Regel unterschiedliche Erwartungen und Anforderungen an ein Projekt. Daher müssen sie sich anfangs auf ein gemeinsames Ziel und auf eine gemeinsame “Marschrichtung“ einigen. Sie müssen den Projektumfang definieren, sich auf Erfolgskriterien einigen und klären, was der Beitrag der Projektbeteiligten sein soll. Dies sollte im Rahmen eines Kick-off-Meetings geschehen und die Ergebnisse sollten in einem Product Vision Statement zusammengefasst werden. 6.1. Produkt Vision Statement Eine gute Produktvision beantwortet drei Fragen (siehe Shore 2010): Was ist das Ziel des Projekts bzw. welches Problem soll das Produkt lösen? Was macht das Produkt (aus Kundensicht) nützlich? Und wie (und wann) messe ich den Erfolg des Projekts? Moore (2002) beschreibt in seiner ElevatorPitch-Methode die Inhalte einer guten Produktvision noch genauer. In ihr setzt man die Zielgruppe des Produkts, deren Bedürfnisse, die Produktkategorie, die Hauptfunktionalität, Wettbewerber und Unterscheidungsfaktoren einfach in folgende Sätze ein: “For ___ who are dissatisfied with___. Our product is a ___ that provides

183


___ unlike___, we have assembled___.” So erhält man eine Zusammenfassung des Projektziels und der Produktidee, die sich in wenigen Minuten vermitteln lässt. Eine weitere Methode zur Erarbeitung der Produktvision nennt sich “Design the Box” (siehe Highsmith 2001 und Gray et al. 2010), bei der das Projektteam die Vorder- und Rückseite einer (imaginären) Produktverpackung beschriftet. Typische Inhalte sind ein treffender Produktname, ein Slogan, der den Nutzen des Produkts zusammenfasst, eine Abbildung, drei bis vier Verkaufsargumente, eine Beschreibung der Features auf der Rückseite und die technischen Anforderungen des Produkts. Ein gutes Beispiel für eine Produktvision ist das Vision Statement von Metro (siehe Shum 2010), der Design-Sprache von Windows 7 und 8. [Abb. 1] Für mehr Details zu Produktvisionen siehe Haine (2009). 6.2. Design-Prinzipien Haben sich die Projektbeteiligten auf eine gemeinsame Produktvision geeinigt, sollte anschließend ein Set von Design-Prinzipien (im Englischen auch manchmal „Design Tenets“ genannt) aus der Vision abgeleitet werden. Die Aufgabe von Design-Prinzipien ist es, die Inhalte der Produktvision knapp und prägnant zu beschreiben. Mit ihrer Hilfe kann das Projektteam im Verlauf des Projekts aus verschiedenen Design-Alternativen die Beste auswählen. Sie sind sozusagen die Leuchtfeuer, die das Projekt „auf Kurs halten“: “Design principles are short, insightful phrases that act as guiding lights and support the development of great product experiences. Design principles enable you to be true to your users and true to your strategy over the long term.” (Buley 2009) Gute Design-Prinzipien sind projektbezogen, konkret, eindeutig, selektiv, prägnant und fundiert.

184

Abb. 1. Product Vision Statement von Windows Metro, Copyright by Microsoft

Beziehen sich Design-Prinzipien nicht auf ein konkretes Projekt oder sind sie zu unspezifisch, werden sie schnell zu Allgemeinplätzen – wie z. B. „Unser Produkt soll einfach sein.“ Besser ist es, genau zu beschreiben, was „einfach“ für das jeweilige Projekt bedeutet. Man sollte zudem sicherstellen, dass sich Design-Prinzipien sich nicht widersprechen. Außerdem sollte man ihre Anzahl überschaubar halten – fünf bis acht Design-Prinzipien reichen in der Regel. Und zu guter Letzt basieren gute Design-Prinzipien auf Erkenntnissen des User Research – sie sind nutzerorientiert. [Abb. 2] Beispiele für Design-Prinzipien finden sich bei Saffer (2007 und 2010) und Keith (2012). Für mehr Informationen zu DesignPrinzipien siehe Hennigs (2012), Anderson (2011), Saffer (2009) und Spool (2001).

7. Ideen beschreiben und kommunizieren Der zweite elementare Schritt zur Lösung bösartiger Probleme ist die Dokumentation und Kommunikation von Ideen. Bill Buxton schreibt in „Sketching the User Experience“ (2007): “Successful execution of a design depends on communication, and capturing the design rationale is an important component in this.” Aber warum sind Dokumentation und Kommunikation für erfolgreiches Gestalten so wichtig? Ein Grund dafür ist, dass das Design aus einer Vielzahl einzelner Design-Entscheidungen besteht. Um ein konsistentes Produkterlebnis zu gestalten, muss sichergestellt werden, dass bei gleichartigen Problemen auch vergleichbare Lösungen gewählt werden.


Usability Professionals 2012 Von Anforderungen zum Produkt

Dies ist im Team schwieriger umzusetzen als für eine Einzelperson. “The solo designer or artist produces works with this integrity subconsciously; he tends to make each micro decision the same way every time he encounters it.” (Brooks 2010) Daher ist die Dokumentation und die Kommunikation der dem Design zugrundeliegenden Ideen eine wichtige Aktivität für Teams. Aber wie kommuniziert man nun das Design eines Produkts und die dazu gehörigen Design-Entscheidungen? In der Regel mit den typischen Artefakten und Tätigkeiten von UX-Professionals: Durch Skizzen, Diagramme, Wireframes, User-Szenarien, Styleguides, UI-Spezifikationen und durch Prototyping. Eine oft unterschätzte Tätigkeit ist das Skizzieren (sketching) von Design-Ideen und Lösungen, auf die im Folgenden detaillierter eingegangen wird. 7.1. Skizzieren Skizzieren ist visuelle Kommunikation zwischen uns, dem Problem und den anderen Projektbeteiligten. Skizzen werden während des Gestaltens für verschiedenste Zwecke eingesetzt. Indem wir verschiedene Ideen skizzieren, verstehen und definieren wir erst das Problem und dessen Lösung. Skizzen beschreiben den Problemraum, das heißt unser aktuelles Verständnis des Problems. Aber gleichzeitig beschreiben sie auch den Lösungsraum, also wie wir uns die aktuelle Lösung vorstellen. Während des Zeichnens kommen neue Ideen – Skizzieren ist „generative“(siehe Evans 2010).

browsing through information, reading and make sense of information; organizing and structuring and reminding of ideas; […] and activities that involve showing and demonstrating ideas and actions to others.” Außerdem sind Papierskizzen schnell und einfach zu erstellen, sie sind „günstig“ und man scheut man sich weniger, sie zu verwerfen. Da Skizzen per Definition ungenau sind, regen sie die Phantasie und die Diskussion an. „Learning from sketches is based largely on the ambiguous nature of their representation. That is, they do not specify everything and lend themselves to, and encourage, various interpretations that were not consciously integrated into them by their creator.” (Buxton 2007). Man kann Skizzen nutzen, um andere Projektbeteiligte früh in die Gestaltung mit einzubinden. Man kann mit ihrer Hilfe frühe Designkonzepte vorstellen und auf diese Weise schnell Feedback einholen. Für mehr Informationen zum Thema Skizzieren und Best-Practices siehe Brown (2011) und Buley (2010).

8. Stakeholder einbeziehen In interdisziplinären Projekt-Teams kommen unterschiedliche Interessen und Sichtweisen zusammen. Berücksichtigen UX-Professionals diese während der Gestaltung und binden sie ihre Projektpartner aktiv in den Gestaltungsprozess ein, wird die Akzeptanz von Design-Entscheidungen steigen. Werden Projektbeteiligte eingebunden, bekommen sie die Chance, den Nutzen und die (positiven) Auswirkungen von UX-Aktivitäten mitzuerleben. Sie können sehen, welche Konsequenzen Entscheidungen „ihres“ Bereichs auf die gesamte Produkterfahrung haben. Zusätzlich können sie erleben, wie viele kleine Entscheidungen ein Design-Konzept ausmachen. Ein weiterer pragmatischer Grund für die Einbeziehung von Projektbeteiligten ist, dass UX-Professionals in der Regel in Projekten unterrepräsentiert sind. Lassen sich Projektpartner einbinden und können

Obwohl es eine Vielzahl digitaler Möglichkeiten des Skizzierens gibt, ist es sinnvoll, vor allem anfangs auf Papier zurückgreifen. Denn Papier bietet eine Reihe von Vorteilen. Ein Vorteil ist, dass der Mensch wissensorientierte Tätigkeiten am besten auf Papier erledigen kann, wie Sellen und Harper (2003) darlegen: “[Paper] will continue to predominate in activities that involve knowledge work, including

Abb. 2. Design-Prinzip von Windows Metro, Copyright by Microsoft

185


diese bei UX-Aufgaben unterstützen, können im Projekt mehr UX-Aktivitäten umgesetzt werden. Eine einfache Möglichkeit, Projektpartner in die Gestaltung einzubeziehen, ist die so genannte Design Studio-Methode. 8.1. Design Studio Diese Methode stammt ursprünglich aus der Architektur und dem Industriedesign. Sie bezeichnet ein strukturiertes, iteratives Vorgehen, mit dessen Hilfe sich Design-Probleme im Team lösen lassen (siehe Ungar 2008, Evans 2011 und Lindstrom 2011). Zudem eignet sich die Methode besonders für agile Projekte: „The design studio is a collaborative workshop that fits well within the timeframes Agile software development practices while incorporating the benefits of UCD research.” (Ungar 2008). In einer Design-Studio-Session skizzieren die Teilnehmer verschiedene Design-Optionen, präsentieren und diskutieren sie und kombinieren ihre Ergebnisse anschließend in einer gemeinsamen Lösung. Warum ist die Methode so gut geeignet? Sie bindet Nicht-Designern aktiv in den Design-Prozess ein und zeigt ihnen wie Design funktioniert. Auf diese Weise erzeugt eine Design Studio-Session Akzeptanz und stärkt das Projekt-Team (team building). In einer Session werden bereits in kurzer Zeit viele neue Ideen generiert, und außerdem wird durch ein Design Studio gemeinsames Wissen aufgebaut. 9. Kleinschrittig vorgehen und validieren Diese Empfehlung (zur Lösung bösartiger Probleme) setzen die meisten UX-Professionals bereits in ihrer täglichen Arbeit um – sie verfeinern ihr Design-Konzept schrittweise und nähern sich auf diese Weise iterativ einer Lösung.

186

Am Anfang eines Projektes skizzieren sie ihre Ideen alleine oder erarbeiten sie gemeinsam im Team. Erste Ergebnisse können Key Screens, Wireframes oder Diagramme auf Papier sein. Anschließend portieren sie ihre Konzepte auf dem Computer und erstellen erste Prototypen. Anfangs werden Prototypen dazu genutzt einzelne Konzept-Ideen zu überprüfen, anstatt die angestrebte Produkterfahrung realitätsgetreu abzubilden. Aber im Laufe des Projektes ändert sich die Aufgabe von Prototypen (siehe Myers et al. 2008). “Sketches and prototypes are both instantiations of the design concept however they serve different purposes, and therefore are concentrated at different stages of the design process. Sketches are dominant the early ideation stages, whereas prototypes are more concentrated at the later stages where things are converging within the design funnel.” (Buxton 2007) Für mehr Informationen zur Rolle von Prototypen und zum Thema Prototyping im Allgemeinen, siehe Houde und Hill (1997) und Warfel (2009). 10. Fazit

das Prototyping: Wir können unsere Ideen an Hand von Prototypen zeigen, überprüfen und Feedback einholen. Die Methoden sind nicht aufwendig. Sie lassen sich in relativ kurzer Zeit durchführen. Daher fällt es uns auch leichter, ihre Ergebnisse bei Bedarf zu verwerfen oder zu überarbeiten. Und sie sind kooperativ. Auch Nicht-UX-Professionals können an der Lösung mitarbeiten und einen konstruktiven Beitrag leisten. Sie erlauben, dass alle Projektbeteiligten an der Gestaltung des Produkterlebnisses mitwirken. Außerdem sind UX-Artefakte wie DesignPrinzipien, Personas oder Nutzer-Szenarien kompakt und prägnant, da sie Information unterschiedlicher Quellen aggregieren und auf den Punkt bringen. Sie enthalten wichtige Informationen, sind aber für Nicht-UX-Professionals einfach zu verstehen. Sie beschreiben den Problem- und den Lösungsraum und ermöglichen ein gemeinsames Verständnis. Und abschließend haben sie das, was Chip und Dan Heath (2007) als „stickiness factor“ bezeichnen: Sie sind eingängig. Literatur 1. Anderson, S. 2011. “Principles to Build By,” IA Summit 2010, from http://www.slideshare.

Im Rahmen dieser Veröffentlichung wurde eine Reihe von Methoden vorgestellt, mit deren Hilfe UX-Professionals in einem schwierigen Projektumfeld einen positiven Beitrag leisten können. Eine interessante, abschließende Frage ist, warum diese Methoden funktionieren.

net/stephenpa/design-principles-to-build-by, accessed 29/07/2012. 2. Beck, K. et al., 2001. “Manifesto for Agile Software Development,“ from http:// agilemanifesto.org/, accessed 29/07/2012. 3. Bias, R. G. and Mayhew, D. 2005. “CostJustifying Usability: An Update for an Internet Age,” San Francisco, CA: Morgan

Ein wichtiger Grund ist sicherlich, dass die vorgestellten Methoden „menschenfreundlich“ im eigentlichen Sinne des Wortes sind. Sie ermöglichen einen einfachen Zugang zu komplexen Sachverhalten. Skizzieren zum Beispiel erlaubt uns Informationen visuell darzustellen. Wir können Dinge zueinander in Beziehung setzen, Probleme identifizieren und neue Lösungen erarbeiten. Wir sehen (neue) Zusammenhänge und gelangen auf diese Weise zu neuen Ideen. Das Gleiche gilt für

Kaufmann. 4. Brooks, F. P. 2010. “The Design of Design,” Boston, MA: Pearson Education. 5. Brown, D. M. 2011. “Communicating Design: Developing Web Site Documentation for Design and Planning. Second Edition,” Berkeley, CA: New Riders. 6. Buley, L. 2009. “Design Principles in a Nutshell,” from http://www.adaptivepath. com/ideas/d120209, accessed 29/07/2012. 7. Buley, L. 2010. “Good Design Faster,” from http://www.slideshare.net/webwallflower/


Usability Professionals 2012 Von Anforderungen zum Produkt

good-design-faster-slides-failcon-2010, accessed 29/07/2012. 8. Buxton, B. 2007. “Sketching User Experiences,” San Francisco, CA: Morgan Kaufmann. 9. Camillus, J. C. 2008. “Strategy as a Wicked

21. Keith, J. “Design Prinicples“, from http:// principles.adactio.com/, accessed 29/07/2012. 22. Lindstrom, J. 2011. “Design Studio: The Good, the Bad and the Science,” from http:// www.uxbooth.com/blog/design-studios-the-

accessed 29/07/2012. 36. Shum, A. 2010. “Designing Windows Phone 7 Series,” MIX 10, Las Vegas, from http:// channel9.msdn.com/events/MIX/MIX10/ CL14, accessed 29/07/2012. 37. Spool, J. 2001. “Creating Great Design

Problem,” Harvard Business Review, May

good-the-bad-and-the-science/, accessed

Principles: 6 Counter-intuitive Tests,” from

2008.

29/07/2012.

http://www.uie.com/articles/creating-design-

10. Constantine, L. L., Lockwood, L. 1999. “Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design,“ Reading, MA: Addison-Wesley. 11. Dorst, K. 2003. “The Problem of Design Problems,” in N. Cross & E. Edmonds (Eds.), Expertise in design (pp. 135–147). Sydney: Creativity and Cognition Studio Press. 12. Evans, W. 2010. “Shades of Grey: Wireframes as Thinking Device,“ from http://uxmag. com/articles/shades-of-grey-wireframes-asthinking-device accessed 29/07/2012. 13. Evans W. 2011. “Introduction to Design Studio Methodology,” from http://uxmag. com/articles/introduction-to-design-studiomethodology, accessed 29/01/2011. 14. Gray et al. 2010. “Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers,“ O‘Reilly Media, Inc. 15. Haine, P. 2009. “The Components of Product

23. Mayhew, D. 1999. “The Usability Engineering Lifecycle,” San Francisco, CA: Morgan Kaufmann. 24. Moore, G. A. 2002. “Crossing the Chasm. Revised Edition,” New York, NY: Harper Business. 25. Myers et al. 2008. “How Designers Design

17. Hennigs, L. 2011. “Design-Prinzipien,“ 1st

why good products can fail, the personal computer is so complex, and information appliances are the solution,” Cambridge, MA: MIT Press. 27. Poppendieck, M. 2002. “Wicked Projects,” in Software Development Magazine from http://drdobbs.com/184414851, accessed 29/07/2012. 28. Poppendieck, M. 2004. “An introduction to

to-lean-software.html, accessed 29/07/2012. 29. Rittel, H., Webber, M. 1973. “Dilemmas in a General Theory of Planning,” in: Policy Sciences 4(2) June; S. 155-169. 30. Roberts, N.C. 2000. “Wicked Problems and

German UPA Summer School, from http://

Network Approaches to Resolution.,” The

www.slideshare.net/problemloeser/ber-

International Public Management Review.,

designprinzipien, accessed 29/07/2012. 18. Highsmith, J. 2001, “Product Vision“ in the

Vol. 1, 1. 31. Saffer, D. 2007. “Charmr: Creating

23 August 2001 issue of Cutter Consortium‘s

Concepts,” from http://www.adaptivepath.

Agile Project Management E-Mail Advisor,

com/ideas/charmr-creating-concepts,

from http://www.joelonsoftware.com/articles/ JimHighsmithonProductVisi.html, accessed 29/07/2012. 19. Houde, S. and Hill, C. 1997. “What do Prototypes Prototype?,“ in Handbook of Human-Computer Interaction (2nd Ed.), M. Helander, T. Landauer, and P. Prabhu (eds.): Elsevier Science B. V: Amsterdam, 1997. 20. ISO 2010. “ISO 9241-210:2010: Ergonomics of human-system interaction – Part 210: Human-

Rosenfeld Media.

Human-Centric Computing.

www.leanessays.com/2004/06/introduction-

New York, NY: Random House.

Practitioner’s Guide,” Brooklyn, New York:

26. Norman, D. A. 1999. “The invisible computer:

Lean Software Development,” from http://

Why Some Ideas Survive and Others Die,“

Conference. 39. Warfel, T. Z. 2009. “Prototyping: A

IEEE Symposium on Visual Languages and

components-of-product-vision/, accessed 16. Heath, C. and Heath D. 2007. “Made to Stick.

Design for Agile Teams, “ Agile 2008

and Program Interactive Behaviors“, 2008

Vision,“ from http://productvision.org/blog/ 29/07/2012.

principles, accessed 29/01/20112. 38. Ungar, J. 2008. “The Design Studio: Interface

accessed 29/07/2012. 32. Saffer, D. 2009. “Design for Interaction – 2nd Edition,” Berkeley, CA: New Riders. 33. Schwaber, K. and Sutherland, J. 2011. “The Scrum Guide,” from http://www.scrum.org/ scrumguides/, accessed 29/07/2012. 34. Sellen, A. J. and Harper, R. 2003. “The Myth of the Paperless Office,” Cambridge, MA: MIT Press. 35. Shore, H. 2010. “The Art of Agile

centred design for interactive systems,”

Development: Vision,“ from http://

Switzerland.

jamesshore.com/Agile-Book/vision.html,

187


188


User Experience

189


„Das ist ein gewachsenes Produkt“ – User Interface Balkonitis Wie man Usability-Probleme von betrieblich genutzten Anwendungen nachhaltig verbessern kann Guido Tesch DEVK Versicherungen Riehler Straße 190 50735 Köln guido.tesch@devk.de

Abstract In der Realität von betrieblich eingesetzter Software ist der Ausspruch „Das ist ein gewachsenes Produkt“ nur allzu bekannt. Da werden oftmals Anwendungen produktiv genutzt, die eine deutlich verminderte Usability aufweisen. Und dennoch erscheinen die Kräfte, die eine Verbesserung in diesem Bereich verhindern, unüberwindbar, auch wenn es betriebswirtschaftlich sinnvoll wäre. Dieser Erfahrungsbericht bietet einen neuen Blickwinkel auf dieses Phänomen, hilft, die Zusammenhänge zu verstehen und UsabilityVerbesserungen in betrieblich eingesetzter Software nachhaltig zu erreichen. Der Autor definiert den Begriff „User Interface Balkonitis“, zeigt die häufigsten Ursachen hierfür auf und gibt Hinweise aus der Praxis, was man sinnvoll dagegen tun kann.

1. Einführung Wer als User Interface Designer, Interaction Designer, Usability-Experte oder SystemErgonomie-Architekt an der Gestaltung betrieblich genutzter Anwendungen arbeitet, begegnet dort manchmal User Interfaces, die eine überraschend geringe Gebrauchstauglichkeit (Usability) aufweisen. Dennoch werden die Anwendungen eingesetzt, zum Teil sogar in Kernprozessen des Unternehmens, ohne dass etwas an der Usability geändert wird. Die Ursachen hierfür sind schwer zu erkennen und vielfältig, eine Spielart davon wird in diesem Beitrag beschrieben und als „User Interface Balkonitis“ charakterisiert. Die User Interface Balkonitis ist nicht spezifisch für ein bestimmtes Unternehmen. Überall, wo die Komplexität des betrieblich genutzten IT-Systems eine gewisse Komplexität erreicht, kann User Interface Balkonitis auftreten. Es handelt sich bei dem Beitrag um einen Erfahrungsbericht, eine wissenschaftliche Analyse der Ursachen und Nachweise der Wirksamkeit von Maßnahmen bleiben einer zukünftigen Arbeit vorbehalten.

190

Es ist wichtig festzuhalten, dass es in diesem Beitrag um die Entwicklung betrieblich genutzter Anwendungen geht. Eine fundamentale Eigenschaft hiervon ist, dass diejenigen, die diese Anwendungen nutzen dies tun, weil die Geschäftsprozesse des Unternehmens es so vorsehen und nicht, weil sie die Anwendungen für ihre Tätigkeiten selbst gewählt haben. Die Benutzer der betrieblichen Anwendungen haben in der Regel nur einen geringen Einfluss auf die Auswahl sowie die Gestaltung der Anwendungen, die sie tagtäglich gebrauchen. In dieser Hinsicht unterscheidet sich die Betrachtung betrieblich genutzter Anwendungen erheblich von der Betrachtung von Produkten für Endkunden oder für Software-gestützte Consumer-Services. 2. Der Begriff „User Interface Balkonitis“ Der Begriff „User Interface Balkonitis“ (kurz UI Balkonitis) lehnt sich an Begrifflichkeiten in der Medizin an, wobei als „System“ nicht ein Organismus, sondern ein Unternehmen mit einem Informationssystem betrachtet wird. Den Organen entsprechen sowohl IT-Systemkomponenten als auch

Keywords: /// User Interface Balkonitis /// Betrieblich genutzte Software /// Nachhaltige Usability Verbesserungen /// Anwendungsarchitektur /// Integrationsarchitektur /// Featuritis

organisatorische Einheiten mit ihren Entscheidungsträgern sowie Mitarbeitern. Die Endung „-itis“ bezeichnet meist eine entzündliche Krankheit. Am Anfang des Begriffs wird das betroffene Organ/die betroffene Komponente des Unternehmens genannt. Eine Entzündung ist eine charakteristische Antwort von Gewebe / Komponenten auf einen potenziell schädigenden Reiz mit dem Ziel, den Reiz zu beseitigen. Als „Balkon“ einer Software-Anwendung wird ein funktionaler Teil bezeichnet, der oft (aber nicht nur) durch „historisches Wachstum“ der Anwendung entsteht. Der Begriff wird in Anlehnung an die Architektur von Gebäuden verwendet, wobei dies nur ein Beispiel (wenn auch ein typisches) ist, wo der zu beschreibende Sachverhalt auftritt. Andere Beispiele wären, wenn ein Raum eines Gebäudes mit Funktionen überfrachtet und dadurch unübersichtlich wird oder wenn die Anordnung von Räumen zu langen oder umständlichen Laufwegen für typische Nutzungsszenarien führt. „User Interface Balkonitis“ ist die Reaktion des Unternehmens (als Analogon zu dem


Usability Professionals 2012 User Experience

Begriff Organismus betrachtet) auf einen schädigenden Reiz. An den „Balkonen“ der IT-Systeme treten Usability-Probleme in der Mensch-Maschine-Kommunikation / im User Interface auf (der schädigende Reiz). Alternativ können auch durch das Zusammenspiel mehrerer Anwendungen Usability-Probleme auftreten, wo eine Anwendung als „Balkon“ einer anderen Anwendung betrachtet wird oder innerhalb einer funktional überfrachteten Anwendung. Die charakterisierende Antwort des Unternehmens besteht in der Erwartung, dass die Belastung gering sei und von den Benutzern – den Mitarbeitern – getragen werden könne. Dadurch spürt das Unternehmen als Ganzes den Reiz oft nicht mehr, obwohl er fortbesteht. In dem Sinne ist UI Balkonitis in der Regel chronisch, die Komponente „Mitarbeiter“ wird dauerhaft belastet, was unter anderem einen erhöhten Aufwand für die Bearbeitung von Geschäftsprozessen bedeutet. Wie hoch der Aufwand tatsächlich ist, mit dem die Reizbewältigung im Unternehmen betrieben wird, bleibt meist unbekannt. Pro Benutzung eines „Balkons“ ist der Aufwand eher niedrig, kann in der Summe aber substantiell sein. Weil die Benutzer der Anwendungen die Belastung tragen und sie dies als ihre Aufgabe ansehen, ist die Belastung für das Unternehmen als Ganzes vielfach nicht mehr spürbar, was das Erkennen der kausalen Zusammenhänge erschwert. Die Ungewissheit darüber, wie hoch der Aufwand wäre, um den Reiz zu beseitigen, ist das Hauptproblem, das die Auflösung der UI Balkonitis verhindert. Darauf wird bei der Diskussion möglicher Maßnahmen eingegangen. 3. Klarstellungen und Abgrenzungen Der Fokus vieler Unternehmen bei der Weiterentwicklung ihres IT-Systems liegt auf zentralen funktionalen Aspekten der Anwendungen, auf der Gestaltung von Geschäftsprozessen und der Verwendung der Anwendungen in diesen Geschäftsprozessen. Dies ist grundsätzlich sinnvoll, da hier in der Regel mit einem höheren Gewinn in der Effektivität und Effizienz

der Geschäftsprozesse gerechnet werden kann, wodurch wiederum eine Rechtfertigung von entstehenden Kosten für die Weiterentwicklung leichter fällt. Bei der UI Balkonitis geht es um die Fälle, in denen Usability-Probleme in Bezug auf nichtfunktionale Aspekte auftreten und in der Regel nicht die Effektivität betreffen, sondern die Effizienz und die Nutzerzufriedenheit. Wegen des Problems der Ungewissheit über die Höhe der Kosten bleiben diese Verbesserungspotenziale oft ungenutzt. „Balkone“ in Software-Anwendungen sind nicht grundsätzlich schlecht. Es kann sinnvoll sein, Funktionen anzubieten, indem man „am Rand des Gebäudes“ etwas ergänzt oder bestehende Räume erweitert. Die Alternative wäre, das Gebäude im Inneren umzustrukturieren oder Außenmauern zu versetzen, damit im Inneren mehr Platz entsteht –sprich: Die zusätzliche Funktionalität in die bestehenden Bildschirmabläufe der Anwendung sauber zu integrieren. Ein Balkon kann durchaus Sinn machen, wenn die zusätzliche Funktionalität nur gebraucht wird im Sinne eines „kurz hin, erledigen und zurück“. Allerdings wird typischerweise der „Aufwand im Kleinen“ bei der Benutzung unsinniger „Balkone“ wesentlich geringer eingeschätzt als der Aufwand, den „Balkon“ gar nicht erst entstehen zu lassen und die anzubietende Funktionalität besser zu integrieren. Erfahrungsgemäß liegen die Ursachen einer UI Balkonitis nicht in Problemen der Geschäftsprozesse, also an ineffizientem Arbeiten wegen der Festlegung der abzuarbeitenden Arbeitsschritte. Hier sind Prozess- und Organisationsmanagement sowie die Facharchitektur gefragt, die Basis zu schaffen, damit die eingesetzten Anwendungen grundsätzlich zu den abzuarbeitenden Arbeitsschritten passen. Die UI Balkonitis bezieht sich auf die Usability der Interaktionsprozesse in den einzelnen Anwendungen sowie auf deren Zusammenspiel. Der Begriff „Featuritis“ ist verwandt zur UI Balkonitis, sollte aber nicht damit verwechselt werden. Während bei Featuritis das Vorhandensein von zu vielen Funktionen

fokussiert wird, steht bei der UI Balkonitis die Qualität des UI einer einzelnen Funktion sowie deren Integration in das Gesamtsystem im Vordergrund. 4. Typische Ursachen für UI Balkonitis 4.1. Inkorrekte oder extrem unvollständige Anforderungen Wenn die Anforderungen, die von der Anwendung erfüllt werden sollen, extrem unvollständig bekannt oder inkorrekt erfasst sind, hat dies erfahrungsgemäß folgende Konsequenzen: –– Es gibt keine klare oder eine falsche Zielsetzung für die Entwicklung der Anwendung, besonders bei der Gestaltung der Interaktion für neue Funktionen. –– Wegen der Vielzahl an Gestaltungsmöglichkeiten wird mit gewisser Wahrscheinlichkeit in eine Richtung investiert, bei der die Integration der neuen Funktion zu Usability-Problemen führt. –– Die Investitionen führen zu einer „Richtungsträgheit“: Um eine andere Richtung einzuschlagen, muss ein (oft sehr großer) Widerstand überwunden werden – Stichwort „Investitionsschutz“. Doch dieser kann nur sinnvoll sein, wenn die Investition in die richtige Richtung führt. Ähnliche Konsequenzen hat es, wenn das Vorgehen beim Entwicklungsprozess bzw. Vorgehensmodell so gewählt wird, dass eine Orientierung hin zu einer hohen Qualität der Anwendung erschwert wird. Dies kann zum Beispiel dadurch entstehen, dass die Anforderungsanalyse nicht genügend Raum und Zeit erhält oder die Erfüllung der Anforderungen nicht konsequent überprüft wird. 4.2. Die „UI-Macht“ liegt in den falschen Händen Das vorherige Kapitel hat falsche oder extrem unvollständige Anforderungen behandelt. Grundsätzlich kann man in der Praxis

191


beobachten, dass bei der Gestaltung eines User Interface die dazugehörigen Anforderungen niemals vollständig erfasst sind. Auch wenn die wichtigsten Anforderungen bekannt sind, gibt es bei der Realisierung des UI immer Gestaltungsfreiheiten, über die dann jemand entscheiden muss. Und ebenfalls aus der Praxis ist bekannt, dass eine gute Usability korrekte Entscheidungen im Großen genau so wie im Kleinen erfordert: Die beste Anforderungsanalyse führt nicht zum Ziel, wenn in der Detailgestaltung des UI zu viele Fehler gemacht werden. Diese Entscheidungen bezüglich der UI-Details werden allerdings erfahrungsgemäß oft von Personen verantwortet, deren Fokus nicht eine gute Qualität des UI ist: –– Manager/Projektleiter – Ihr Fokus ist die Verwaltung von Ressourcen und die Einhaltung von Verfahrensregeln und Meilensteinen. In der Regel sind sie nicht geschult in der Gestaltung von User Interfaces, und die Qualität des UI ist meist nicht Bestandteil ihrer Projektziele, an denen ihr Erfolg gemessen wird. –– UI Entwickler – Ihr Fokus liegt auf der technischen Umsetzung des UI. Wichtig ist ihnen eine schnelle Entwicklung mit Berücksichtigung der bekannten funktionalen Anforderungen und anderer Aspekte wie zum Beispiel Wartbarkeit. Eine Kompetenz in der UI Gestaltung hinsichtlich der Usability ist durchaus manchmal vorhanden, wird aber wegen der genannten Prioritäten oft nicht ausreichend beachtet. –– Fachverantwortliche – Ihr Fokus ist oft auf die funktionalen Anforderungen gerichtet. Die Qualität der Ausgestaltung im Ganzen interessiert sie wenig. Oft gehörtes Zitat: „Wie das im Detail gestaltet ist, ist mir eigentlich egal. Hauptsache, die Funktion XY ist da.“ Auch sie haben oft wenig Gestaltungskompetenz bezüglich des User Interface.

4.3. Der Wert von Qualität des UI wird unterschätzt Selbst wenn alle wichtigen Anforderungen bekannt sind und die Qualität der UI-Details explizit im Fokus liegt (die „UI Macht“ also in den richtigen Händen liegt), muss es außerdem noch genügend Ressourcen (v. a. Zeit und Geld) geben, um das UI hinsichtlich nichtfunktionaler Anforderungen qualitativ hochwertig gestalten und umsetzen zu können. Die Praxis zeigt aber, dass im Rahmen des Projektmanagements dieser Aspekt oft wenig beachtet wird. Der Grund hierfür liegt nach Meinung des Autors darin, dass der Wert der Qualität des UI von den Ressourcenverantwortlichen unterschätzt wird. Das Projektziel ist erreicht, wenn die funktionalen Anforderungen erfüllt werden, die Qualität im UI zu erhöhen gilt als „teures Optimieren der letzten zehn Prozent“. Damit wird der Wert, den ein qualitativ hochwertiges UI für das gesamte Unternehmen hat, eventuell unterschätzt und entsprechend zu wenig Zeit und Geld für die Umsetzung zur Verfügung gestellt. Ein zweiter Aspekt, der zur Unterschätzung des Wertes von qualitativ hochwertigem UI führt, ist dass die Konsequenzen von schlechten UIs unbekannt bleiben. Es ist oftmals schwer, quantitativ und objektiv nachzuweisen, welche Kosten durch schlechte UIs entstehen. Oft basieren explizite Entscheidungen gegen eine Veränderung des UI auf Annahmen zur Kosten-Nutzen-Relation, die nicht objektiv belegt werden. Die Folge: Es muss an anderen Stellen investiert werden, um eine gewünschte Qualität der Prozessergebnisse zu erzielen – meist im operativen Alltag durch die Mitarbeiter bei der Benutzung der Anwendungen. Die Belastung durch UI Balkonitis wird von den Anwendern ausgehalten oder unterschätzt In der Praxis größerer Unternehmen erlebt man, dass Mitarbeiter sehr belastbar sind

192

und die Belastung durch UI Balkonitis nicht melden, ja manchmal auch stolz darauf sind, dass sie das komplexe UI trotzdem erfolgreich benutzen können. Hierfür gibt es verschiedene Erklärungsansätze: –– Die zu benutzenden Anwendungen werden im Rahmen des Prozessmanagement festgelegt, und die Mitarbeiter sind oftmals an der Gestaltung der Anwendungen nicht beteiligt. Dementsprechend betrachten die Mitarbeiter die Anwendungen als „gegeben“ und gehen davon aus, dass von ihnen erwartet wird, die Belastung durch die UI Balkonitis auszuhalten. Erst wenn diese Belastung über einen gewissen Schwellenwert hinausgeht, melden sich die Mitarbeiter zu Wort, dann allerdings erfahrungsgemäß eher unspezifisch, sodass eine direkte Ableitung von Handlungsanweisungen zur Neugestaltung der UIs schwierig ist. –– Die Mitarbeiter unterschätzen die Belastung durch UI Balkonitis und beachten sie deshalb nicht oder kommunizieren sie nicht. In der Konsequenz ist es für das Management – die Entscheider über Ressourcen und Projektpläne – schwierig, die Belastung der Mitarbeiter durch eine schlechte Qualität der UIs in ihre Entscheidungen einzubeziehen. 4.4. Die Qualität von „StandardProdukten“ wird überschätzt Manche Unternehmen verfolgen das Prinzip, Standardsoftware der Eigenentwicklung von Anwendungen vorzuziehen. Bezüglich der zu erfüllenden Anforderungen wird auf funktionale Anforderungen hingewiesen. Sonstige Anforderungen inklusive Usability / Qualität der umzusetzenden Funktionen stehen nicht im Fokus. Dahinter steht oft die Annahme, dass die Standard-Software, die bereits bei Wettbewerbern erfolgreich eingesetzt wird, eine ausreichende bis gute Usability haben muss. Solange die Software in die ITLandschaft des Unternehmens hineinpasst


Usability Professionals 2012 User Experience

und technisch gut integrierbar ist, wird sie akzeptiert. Aus langjähriger Erfahrung als User Experience Architect bei SAP weiß der Autor, dass bei Herstellern betrieblicher Standardsoftware Usability nur ein untergeordneter Aspekt neben vielen anderen Faktoren ist. Die Qualität von Standardsoftware hinsichtlich des UI darf daher nicht überschätzt werden. Auch wenn die Gesamtkosten für hausinterne SoftwareEntwicklung geringer werden und die Integrationsfähigkeit der Standardsoftware explizit gefordert wird, so kauft man im Endeffekt „die Katze im Sack“, wenn das Thema Usability bzw. UI Balkonitis nicht explizit beachtet wird. Viele kleine Usability-Probleme können sich derart summieren, dass die besten funktionalen Eigenschaften doch nur zur Hälfte hinführen zu der bestmöglichen Lösung. 5. Maßnahmen, die nachhaltig gegen UI Balkonitis helfen Es gibt verschiedene Ansätze, mit UI Balkonitis umzugehen: –– Die Belastung durch UI Balkonitis hinnehmen, ohne genau zu wissen, wie hoch sie eigentlich ist. Diese Praxis verfolgen viele Unternehmen. Verbesserungspotenzial suchen sie oft bei funktionalen Aspekten der Anwendungen, weil sie davon ausgehen, dass die nichtfunktionalen Usability-Probleme keine große Belastung darstellen oder eine Verbesserung an dieser Stelle mit unverhältnismäßigen Kosten verbunden wäre. –– Punktuell die Belastung durch UI Balkonitis verringern, wenn sie einen fiktiven Grenzwert überschreitet. Hilft an der spezifischen Stelle, löst aber das Grundproblem nicht, da zu erwarten ist, dass in vielen Fällen der fiktive Grenzwert nicht überschritten wird und damit dauerhafte Einschränkungen vorliegen, die in der Summe substanziell sein können. –– Überall dort die Belastung durch UI Balkonitis verringern, wo der

erwartete Nutzen größer ist als der entstehende Aufwand für die Belastungsverringerung. Voraussetzung für diesen Ansatz ist allerdings, dass die Kosten durch UI Balkonitis bekannt sind. In der Regel ist die Ermittlung des KostenNutzen-Verhältnisses schwierig (siehe Kapitel 2). –– Strukturell und prozessual vorsorgen, sodass UI Balkonitis gar nicht erst entsteht. Hier ist vor allem die Gestaltung von Organisationsstrukturen und Vorgehensmodellen etwa beim Entwicklungsprozess und im Projektmanagement gemeint sowie die explizite Schaffung einer Integrationsarchitektur. Auch hier besteht das Problem, dass es in der Regel schwierig ist, die Kosten der Vorgehensmodelle und architekturellen Veränderungen korrekt ins Verhältnis zu setzen zu dem Nutzen, den sie im Hinblick auf UI Balkonitis bringen.

Es ist wichtig zu bemerken, dass alle beschriebenen Umgangsmöglichkeiten legitim sind. Es ist eine Frage der Unternehmenskultur sowie eine Frage des Umgangs mit Unsicherheiten in der Kosten-Nutzen-Abschätzung und welchen Ansatz man verfolgt, um die Anwendungslandschaft zu formen. Die Betrachtung der UI Balkonitis ist ein Ansatz neben anderen möglichen Ansätzen, um die Gesamtqualität des Systems zu verbessern. Es geht nicht darum, Balkone zu verhindern oder dogmatisch die Perfektionierung des IT-Systems zu verfolgen. Das Ziel sollte sein, die Entscheidung zur Bildung und Gestaltung von Balkonen im Detail zu informieren, sodass das Gesamtsystem – Unternehmen und Mitarbeiter mit verwendeter Anwendungslandschaft – die gesteckten Ziele erreicht. Mit welchem Stellenwert die Gebrauchstauglichkeit in einem Unternehmen betrachtet wird, ist – wie gesagt – eine Frage der Unternehmenskultur. Und ein Grundproblem beim Umgang mit UI Balkonitis ist, dass das Kosten-Nutzen-Verhältnis bei den zu ergreifenden Maßnahmen meist schwer einzuschätzen ist.

Dementsprechend erscheinen dem Autor seiner Erfahrung nach die folgenden Maßnahmen geeignet, bei Entwicklung und Einsatz betrieblich genutzter Software nachhaltig die Usability der Anwendungslandschaft eines Unternehmens zu verbessern und damit die UI Balkonitis zu verringern. 5.1. Die Belastung objektiv und quantitativ nachweisen Der beste Weg zur nachhaltigen Verbesserung der Situation ist ein objektiver und quantitativer Nachweis der Belastungen durch UI Balkonitis. Solange dies nicht geschieht, werden Verbesserungsversuche bezüglich der nicht-funktionalen Usability an dem Widerstand der Ressourcenverantwortlichen scheitern. Methoden zur Messung von Aufwänden durch Usability-Probleme sind zum Beispiel GOMS-Analysen oder KPI-Messungen im Rahmen von Usability-Tests. Die Herausforderungen sind hierbei: –– Welche Messgrößen sinnvoll sind, hängt maßgeblich von dem zu untersuchenden System ab. Sie müssen sorgfältig gewählt werden, denn sie entscheiden darüber, ob die Ergebnisse einer „Usability-Messung“ für die Ressourcenverantwortlichen nachvollziehbar die Belastungen darstellen. –– Die Messung der Belastung durch UI Balkonitis muss so effizient wie möglich durchgeführt werden, um das KostenNutzen-Verhältnis nicht von vornherein zu sehr zu belasten. –– Es ist oftmals fraglich, mit welchem „Optimum“ die bestehende Lösung verglichen werden soll. Nimmt man als „Maß der Dinge“ eine ReferenzSoftware (zum Beispiel SAP) oder den Gestaltungsvorschlag eines Usability-Experten? An diesen Aspekten entscheidet sich, ob die Belastung durch UI Balkonitis von den Entscheidern und Managern korrekt eingeschätzt wird.

193


Wegen der methodischen Herausforderungen wird diese Maßnahme oftmals vermieden, die Erfahrung des Autors ist aber, dass ohne einen objektiven und quantitativen Nachweis der Belastung im Kontext der UI Balkonitis keine nachhaltigen Verbesserungen zu erzielen sind. Insbesondere führt das oft genutzte Instrument des qualitativen Usability-Testing nicht zum Ziel, da keine Hilfestellung für die KostenNutzen-Abschätzung gegeben wird. 5.2. Einen direkt erkennbaren Mehrwert beisteuern Es ist wichtig, dass der Usability-Experte einen direkt erkennbaren Mehrwert zu einem Projekt beisteuert, damit sein Beitrag akzeptiert wird. Dies kann auf verschiedene Art erfolgen, zum Beispiel: –– wertvolle Gestaltungsvarianten für die zu betrachtende Anwendung liefern. –– Diskussionen zu Gestaltungsvarianten abkürzen, weil der Usability-Experte mit stichhaltigen Argumenten – vor allem mit objektiven, quantitativen Messungen – eine nachvollziehbare Gewichtung beisteuert. –– Substanziell bei der Umsetzung im Projekt mithelfen. Erfolgt diese Maßnahme nicht, wird der Usability-Experte in erster Linie als „Störenfried“ wahrgenommen, der den anderen Mitarbeitern im Projekt Mehrarbeit beschert statt bei der Lösung zu helfen. Ohne die Unterstützung derjenigen, die die Umsetzungen im Projekt leisten, ist es für einen Usability-Experten schwer, gegen UI Balkonitis anzukommen. 5.3. Das Thema verkaufen: Kommunikation, Marketing, Erklären, Demonstrieren, Sponsoring Es ist meist schwierig, die Kosten einer Usability-Messung zu rechtfertigen, da das Kosten-Nutzen-Verhältnis schwer zu ermitteln ist. Dementsprechend müssen solche Maßnahmen verkauft werden, damit Entscheider den Mut finden, sie zuzulassen.

194

–– Die Kommunikation zu dem Thema aktiv betreiben, Leute ansprechen, Ergebnisse präsentieren, „sich unvergesslich machen“. –– Nicht davon ausgehen, dass die Probleme doch offensichtlich sind, sondern erklären, demonstrieren, überzeugen, werben. –– Beispiele aus dem IT-System des Unternehmens selbst heranziehen: Positive Beispiele sind hilfreich; negative Beispiele auch, wenn keiner dabei „sein Gesicht verliert“. –– Fürsprecher / Sponsoren für das Thema gewinnen und diese dafür werben lassen (z. B. Mitbestimmungsgremien). –– Die Bewertung der Belastungen durch UI Balkonitis ist immer diskussionswürdig, also sollte man solche Diskussionen aktiv einfordern. –– Die Sozialverantwortung gegenüber den Benutzern bewusst machen. 5.4. Verbesserungen von hochqualifizierten Experten entwickeln lassen Um nachhaltig gegen UI Balkonitis ankommen zu können, braucht es überzeugende und wirkungsvolle Umgestaltungen der problematischen „Balkone“. Deshalb ist es notwendig, solche Umgestaltungen von jemandem entwickeln zu lassen, der eine große Kompetenz in Sachen UI Design, Usability sowie Software-Architektur besitzt. Außerdem muss er über eine hohe Sozialkompetenz sowie starke Kommunikationsfähigkeiten, Kompromissbereitschaft und Empathie verfügen. Dies ist keine Aufgabe für einen Praktikanten oder einen Entwickler, der sich nebenbei ein paar Grundkonzepte der Usability-Arbeit angelesen hat. Sind die genannten Fähigkeiten nicht bei dem Usability-Experten vorhanden, dann muss man damit rechnen, dass seine Vorschläge nicht gut genug sind, um gegen schlechtere Alternativen oder die bereits bestehende Lösung anzukommen, oder sie werden nicht gehört, nicht ernst genommen oder nicht richtig bewertet.

5.5. Auf lange Sicht: Strategische Einbettung des Themas Usability in Management und Prozesse In der Theorie ist klar, dass UI Balkonitis nachhaltig vermieden werden kann, wenn die Entwicklungsprozesse, Vorgehensmodelle und Kompetenzzuweisungen entsprechend gestaltet sind. Hier kann die Entstehung schlechter UIs verhindert werden. Wenn das Unternehmen ein Produkt mit Mensch-Maschine-Kommunikation (User Interface) entwickelt und verkauft, dann zeigt sich auch in der Praxis, dass dieser Ansatz nachhaltig zielführend ist. In der Praxis der Entwicklung betrieblich genutzter Software innerhalb des nutzenden Unternehmens (also nicht beim Software-Hersteller) zeigt sich, dass diese strategische Betrachtung nur hilfreich ist, wenn eine weitreichende Akzeptanz und Wertschätzung durch alle beteiligten Entscheidungsträger und Mitarbeiter vorliegt. Es müssen erst alle zuvor genannten Maßnahmen etabliert werden und greifen, bevor eine strategische Einbettung sinnvoll erscheint. 6. Fazit UI Balkonitis ist eine Spielart (neben manch anderen), wie schlechte Usability entsteht und wo die Usability nicht so leicht zu verbessern ist. Sie ist typisch für betrieblich genutzte Anwendungen und hat Eigenschaften, die eine nachhaltige Verbesserung der Usability erschweren. Eine der Kernaussagen des Beitrags lautet: Bei UI Balkonitis ist es für eine nachhaltige Verbesserung unverzichtbar, sich mit dem schwierigen Thema des objektiven und quantitativen Nachweises der Belastung auseinanderzusetzen. Wie man dies im Detail umsetzt und wie weitreichend man es umsetzen sollte, hängt von den zu betrachtenden Anwendungen und von der Unternehmenskultur ab. Insofern ist es schwierig, hier allgemeingültige Empfehlungen auszusprechen.


Usability Professionals 2012 User Experience

Eine weitere These ist, dass viele Maßnahmen, die sonst geeignet sind, um Usability zu verbessern, im Kontext von betrieblichen Anwendungen und UI Balkonitis nicht wirken. Dementsprechend entsteht bei vielen Usability-Experten bezüglich der Betrachtung betrieblicher Anwendungen eine Resignation angesichts der Widerstände, die der Verbesserung von Usability entgegenstehen. Wer um die Zusammenhänge rund um die UI Balkonitis weiß, hat es leichter, mit der Situation umzugehen und letztendlich geeignete Maßnahmen zu ergreifen, um die Nutzungsqualität nachhaltig zu verbessern.

Sparda-Banken. Nach der Anzahl der Verträge ist die DEVK Deutschlands viertgrößter Hausrat-, fünftgrößter Pkw- und sechstgrößter Haftpflichtversicherer.

Bei den DEVK Versicherungen ist das Thema UI Balkonitis bekannt. Zurzeit wird dort eine effiziente Methode entwickelt, um die Belastung durch UI Balkonitis objektiv und quantitativ nachzuweisen. Außerdem arbeitet der Autor als User Interface Designer und Usability-Experte für die DEVK in verschiedenen Projekten mit, um das Thema Usability in die Anwendungsentwicklung einzubringen. Um vorzusorgen, dass UI Balkonitis möglichst gar nicht erst entsteht, wird von Seiten der IT-Architektur eine Integrationsplattform (Enterprise Service Bus) eingeführt, um die funktionale Verknüpfung zwischen Anwendungen zu erleichtern. Letztendlich wird in jedem Einzelfall geprüft, welcher Ansatz zur Verbesserung der Gesamtqualität der Anwendungslandschaft unter Beachtung der Kosten-Nutzen-Relation am sinnvollsten erscheint, wobei das Thema Usability einer der betrachteten Faktoren ist. 7. Über die DEVK Versicherungen Den DEVK Versicherungen vertrauen bundesweit rund 4 Millionen Kunden mit 13,4 Millionen Risiken in allen Versicherungssparten. Dass sie besonders treue Kunden sind, hängt nicht zuletzt von der persönlichen Nähe ab: rund 1.250 Geschäftsstellen, gut 2.250 hauptberufliche Vertriebspartner und rund 3.400 nebenberufliche Vermittler sprechen für sich. Langjähriger Kooperationsund Vertriebspartner sind zudem die

195


Usability (Re-) Engineering von Legacy Systemen Hausgemachte Unternehmenssoftware auf dem Usability-Prüfstand Tim Schneidermeier small worlds GbR Bruderwöhrdstr. 15b 93055 Regensburg tim.schneidermeier@small-worlds.de

Markus Heckner Universität Regensburg, Lehrstuhl für Medieninformatik 93040 Regensburg markus.heckner@ur.de

Isabella Hastreiter Universität Regensburg 93040 Regensburg, isabella.hastreiter@stud.uni-regensburg.de

Abstract Unternehmenssoftware als Eigenentwicklung entwickelt sich oft über einen langen Zeitraum evolutionär weiter: Dabei ändern sich die Anforderungen an die Software laufend, der Funktionsumfang wächst kontinuierlich. Das User Interface muss entsprechend an die neuen Gegebenheiten angepasst werden und neue Eingabe- und Interaktionsmöglichkeiten für die Mitarbeiter liefern. In den wenigsten Fällen wird hierbei konsequentes Usability Engineering betrieben, das die Anforderungen der Fachebene in einem benutzbaren Navigationskonzept umsetzt. Die Folge ist häufig eine Software, die hohe Einstiegshürden für neue Benutzer bietet und auch für erfahrene Anwender deutlich effizienter sein könnte. In diesem Beitrag wird ein Projekt vorgestellt, in dem eine über zehn Jahre gewachsene Software einem Usability Reengineering unterworfen wird. Die bestehenden Prozesse wurden analysiert, ein neues Interaktionskonzept erarbeitet und durch Nutzertests evaluiert. Die dafür entwickelte Methodik und die daraus entstandenen Lessons Learned sind für vergleichbare Problemstellungen auch in anderen Projekte einsetzbar.

1. Problemstellung Unternehmen benötigen häufig eine auf Ihre Anforderungen maßgeschneiderte enterprise resource planning-Software (ERP-Software). Auf dem Markt erhältliche Softwarepakete sind oftmals gerade für mittelständische Unternehmen zu teuer in Anschaffung und Wartung, bieten eine Vielzahl von Features, von denen ein Großteil für die Nutzung im Unternehmen irrelevant ist und entsprechen folglich eben gerade nicht den hauseigenen Anforderungen. Der Kauf einer DrittanbieterSoftware von der Stange entfällt damit oft als Option. Alternativ dazu können Lösungen im eigenen Haus entwickelt werden. Diese Software-Pakete passen sich nahtlos dem täglichen Arbeitsspektrum im Unternehmen an und sollen so die Mitarbeiter bestmöglich in ihren Aufgaben unterstützen. Gerade bei mittelständischen Unternehmen werden diese Anwendungen häufig von einer kleinen IT-Abteilung entwickelt und betreut (oftmals nur 1-2 Mitarbeiter). Aus Zeitmangel und mitunter

196

fehlender formeller Ausbildung in Usability Engineering konzentriert man sich auf die Implementierung der notwendigen Funktionen und vernachlässigt Usability-Aspekte. Durch kontinuierliche Weiterentwicklung und Ergänzung der Softwarefunktionalität wird die Gebrauchstauglichkeit zudem eingeschränkt. Die Benutzung solcher Software bietet folglich für die Nutzer nicht selten kein sehr positives Nutzungserlebnis: Die Navigation ist umständlich und häufig über viele Ebenen verschachtelt. Die Nutzer landen bei Ihrer Arbeit in Sackgassen, aus denen Sie mühsam zurückkehren müssen. Häufig bleibt als letzter Ausweg der Helpdesk oder der Supportmitarbeiter (vgl. Twentyman 2009). Die Ursachen für die nicht optimale Usability von Unternehmenssoftware sind vielfältig und oft nicht eindeutig bestimmbar: Software, die über einen längeren Zeitraum verwendet und weiterentwickelt wird, muss an die Anforderungen des Unternehmens angepasst werden. Die Anzahl neuer

Christian Wolff Universität Regensburg , Lehrstuhl für Medieninformatik 93040 Regensburg, christian.wolff@ur.de

Keywords: /// Usability Engineering /// Legacy Systeme /// Reengineering /// Unternehmenssoftware

Features steigt so mit der Zeit stetig an, ohne dass nicht mehr benötigte Funktionen aus der Software entfernt werden. Häufig sind Funktionen nicht mehr den ursprünglichen Anforderungen zuzuordnen und die Bedeutung bestimmter Schaltflächen und Labels erschließt sich aktuellen Benutzern nicht mehr. Im Gegensatz zu Software für Endkunden sind Mitarbeiter im Unternehmen treue Nutzer: Da sie keine Alternativen haben, müssen auch wenig benutzerfreundliche Anwendungen akzeptiert und verwendet werden. Nur in wenigen Fällen wird Usability Engineering wirklich konsequent betrieben. Die Folgen sind für Mitarbeiter und Unternehmen spürbar: Die Einarbeitung in die neue Software dauert lange, Unsicherheit vor Fehleingaben entsteht und Effizienzeinbußen stellen sich ein. Einen Ausweg aus dieser Situation bietet zum einen die Anschaffung einer DrittanbieterSoftware, was in vielen Fällen an den sehr spezifischen Anforderungen scheitert. Zum anderen besteht die Möglichkeit, die bestehende Softwarelösung durch


Usability Professionals 2012 User Experience

konsequentes Usability Reengineering an die veränderten Anforderungen des Unternehmens und der Benutzer anzupassen. Im folgenden Beitrag wird ein konkretes Projekt zur Verbesserung der Usability von einer über die Jahre gewachsenen Unternehmenssoftware vorgestellt. Neben dem Vorgehensmodell werden vor allem die konkreten Herausforderungen an das Usability (Re-) Engineering und die Lessons Learned betont. 2. Herausforderungen und Ziele Die in Regensburg ansässige Firma R-KOM1 bietet Privat- und Geschäftskunden Telekommunikationsprodukte an. Zum Produktportfolio gehören unter anderem Telefon-, DSL- und Glasfaseranschlüsse. Mit der auf Delphi basierten Unternehmenssoftware Zentrale Fachanwendung (ZFA) steuert die R-KOM eine Reihe von innerbetrieblichen Vorgängen: Kunden und Aufträge können in der Software erfasst, bearbeitet, umgezogen und gekündigt werden. Ebenso werden Tickets von Kundenberatern aufgenommen und von Mitarbeitern aus technischen Abteilungen bearbeitet. Die Software wurde vor ca. 10 Jahren erstmals entwickelt und seitdem laufend an die veränderlichen Anforderungen angepasst. R-KOM hat sich an small worlds mit den folgenden Anforderungen gewandt: Bestehende Funktionen sollen für die Benutzer vereinfacht und nicht (mehr) benötigte Funktionen identifiziert werden. Zudem soll ein Styleguide erarbeitet werden, mit dessen Hilfe R-KOM in Zukunft Funktionserweiterungen möglichst eigenständig und benutzerfreundlich entwerfen kann. Aus Sicht des mittelständischen Unternehmens sollten die folgenden Ziele mit diesen Maßnahmen erreicht werden: Entlastung der Mitarbeiter in Ihrer täglichen Arbeit, Effizienzsteigerung der Arbeitsabläufe und Reduktion der Aufwände für Einarbeitung und Support. Zusätzlich soll die Software als Produkt für weitere Unternehmen aus derselben Branche (mittelständische Anbieter von

Telekommunikationsdienstleistungen) angeboten und die Attraktivität der Anwendung dementsprechend für potenziell zukünftige Kunden gesteigert werden. 3. Usability Reengineering: Vorgehensmodell Der Begriff des Reengineering hat seine Wurzeln in der Geschäftswelt und beschreibt „... the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical modern measures of performance, such as cost, quality, service, and speed.“ (Hammer & Champy 1993) Diese Idee aufgreifend dient als Basis für das dem Projekt zugrunde liegende Vorgehensmodell ein iteratives Usability Engineering Framework nach DIN EN ISO 9241-210 (2010). Abbildung 1 zeigt das hier angewandte Modell. [Abb. 1] Das Projekt lässt sich in vier nicht scharf voneinander zu trennenden Phasen einteilen. In der Planungsphase wurde zunächst der Scope für den Projektumfang definiert. Nutzerbeobachtungen und ein Workshop ergaben die Anforderungen für das Usability Reengineering. Sketching (vgl. Warfel 2009) führte zu schnellen Ergebnissen für das Redesign der in den Anforderungen

erhobenen zentralen Aufgaben sowie des kompletten Look and Feel des User Interfaces. Informelle Benutzertests (vgl. Krug 2009; Nielsen 1994) wurden für unmittelbares Feedback verwendet, deren Resultate in einer neuen Iteration eingearbeitet und wieder getestet. Im nächsten Schritt wurden die Ergebnisse in einen klickbaren, interaktiven Prototypen umgesetzt und erneut getestet. Im Folgenden wird ausführlich auf die einzelnen Phasen eingegangen. 3.1. Planung Im Kick-Off wurden Umfang und Scope des Projekts abgesteckt. Aufgrund des sehr großen Funktionsumfangs der Software wurden im ersten Schritt die wichtigsten Geschäftsprozesse für ein Re-design ausgewählt. Diese konnten vom Auftraggeber durch statistische Auswertung der laufenden Geschäftsprozesse eindeutig identifiziert werden. Die Nutzer können so in einem Großteil ihrer täglich anfallenden Arbeitsschritte unterstützt werden. Bei den so ermittelten Hauptfunktionen handelt es sich um Erfassung, Eingabe, Verwaltung und Verändern von großen Datenmengen (Personen, Verträge etc.). Um dem Projektteam einen ersten Eindruck von der Software und der Domäne zu geben, wurde unmittelbar an den Kick-Off ein Demo-Workshop abgehalten. In diesem Workshop wurden Inhalte, Funktionsumfang und bestehendes Interaktions- und

Abb. 1. Das Usability EngineeringVorgehensmodell des Projekts.

197


Navigationskonzept live am Objekt demonstriert, sowie bereits von Seiten des Unternehmens erkannte Usability-Probleme benannt.

–– Identifizierte Usability-Problembereiche präsentieren, ansprechen, diskutieren, Bewusstsein für die Relevanz von Gebrauchstauglichkeit schaffen

3.2. Analyse

Zudem wurden im Workshop die durch die bisherige Analyse gefundenen UsabilityProbleme aufgezeigt und mögliche Lösungen dargelegt. In einer Diskussion wurden Prioritäten aus Geschäfts- und Benutzersicht in Relation gesetzt und die Projektziele nochmals konkretisiert.

Im nächsten Schritt erfolgte die Einarbeitung in die Anwendung und die Domäne. Ein eigener Arbeitspatz der Projektmitarbeiter beim Auftraggeber ermöglichte eine explorative Analyse der ZFA (Funktionsumfang und Informationsarchitektur). Die Methode des Cognitve Walkthrough wurde genutzt, um sich in die Arbeitsvorgänge der Mitarbeiter einzufinden und ein Gefühl für die Abläufe in der Software zu bekommen. Aufbauend darauf wurden die im Kick-Off Meeting festgelegten Hauptprozesse mit Hilfe einer heuristischen Evaluation untersucht und Usability Probleme identifiziert. Dazu dienten Szenarien, die gemeinsam mit den Mitarbeitern entworfen wurden. Konkrete Nutzeranforderungen konnten anhand von Nutzerbeobachtungen, Contextual Inquires und (qualitativen) Interviews erhoben werden. Um unterschiedliche Nutzergruppen und ihre potenziell leicht abweichenden Anforderungen berücksichtigen zu können, wurden repräsentative Mitarbeiter mit unterschiedlichen Erfahrungsniveaus (1 Woche, 2 Jahre, 8 Jahre) ausgewählt. An drei Vormittagen wurden die Mitarbeiter von jeweils zwei Usability Experten bei ihrer Arbeit beobachtet und in kritischen Situationen Nachfragen gestellt.

3.3. Design Die Ergebnisse der Anforderungsanalyse wurden in einem ersten Schritt mit Hilfe von kollaborativem Sketching (vgl. Warfel 2009) zu ersten Entwürfen für die Wizards, das Dashboard sowie das komplette Look and Feel des User Interfaces umgesetzt (siehe unten Kap. 4). Das kollaborative Sketching ermöglicht ein schnelles Generieren von Ideen, die unmittelbar von den Mitgliedern des Projektteams evaluiert, und deren Ergebnisse in einer weiteren Iteration eingearbeitet werden. Gemeinsam entscheidet man sich für eine Lösung.

Die erhobenen Anforderungen wurden dokumentiert, priorisiert und anschließend in einem gemeinsamen Workshop mit dem Entwickler, einem Vertreter der Mitarbeiter und dem Geschäftsführer vorgestellt, abgeglichen und die nächsten Schritte bestimmt. Ziele des Workshops waren: –– Unser Verständnis der bestehenden Abläufe bestätigen / abgleichen –– Konstruktive Diskussion der aktuellen ZFA-Software –– Basis schaffen für den zukünftigen Neuentwurf der Benutzeroberfläche Abb. 2. Screenshot der Zentralen Fachanwendung (ZFA).

198

Das resultierende Konzept für Informationsarchitektur und den jeweiligen Screens wurde in einem nächsten Schritt unter Einsatz eines Tools (Axure) zunächst als statischer Prototyp (WYSIWYG) umgesetzt, das Konzept mittels informeller Nutzertests evaluiert und mit dem Entwickler auf technische Machbarkeit (Delphi als Programmierumgebung für die (Weiter-) Entwicklung) überprüft. Die gewonnen Erkenntnisse wurden wiederum in den Prototypen eingepflegt und in einem auf Nutzungsszenarien2 basierenden klickbaren, interaktiven Prototypen realisiert. 3.4. Evaluation Abschließende Benutzertests mit Hilfe des interaktiven Prototypen lieferten zusätzliche Erkenntnisse, die in den finalen Prototypen eingearbeitet wurden. Als Deliverables für den Abschluss des Projekts wurde zum einen der dokumentierte interaktive Prototyp als Spezifikation für die Benutzeroberfläche geliefert und zum anderen ein Styleguide, der die im Projekt gewonnen (Usability-) Erkenntnisse


Usability Professionals 2012 User Experience

Abb. 3. unterschiedliche Suchfunktionen

Abb. 4. Öffnen des Kontextmenüs durch Rechtsklick.

aufgreift und als Anleitung und Richtlinie für Konzipierung und Integration künftiger Systemerweiterungen dient. 4. Ergebnisse der Analyse In der Analyse konnten folgende Probleme identifiziert werden, die aus unserer Sicht typisch für gewachsene Unternehmenssoftware sind: –– Fehlermeldungen gestalten sich in ihrer Formulierung häufig sehr technisch und unterstützen den Nutzern wenig bei der Problemlösung. Dies hat zur Folge, dass Hilfe bei einem Mitarbeiter aus der IT-Abteilung gesucht werden muss, die Arbeitsprozesse somit verzögert werden und der Frustrationsgrad beim Mitarbeiter steigt. –– Manche Arbeitsschritte sind aus technischen Gründen irreversibel und lassen dem Mitarbeiter keine andere Möglichkeit, als den technischen Support um den nötigen Lösch- bzw. Undo-Vorgang zu bitten. Dies führt zu Angst vor irreversiblen Aktionen bei der Benutzung.

–– Die Auftragsdaten auf den ausgedruckten Formularen, die in die Software übertragen werden müssen, stimmen nicht mit der Bearbeitungsreihenfolge der Software überein. Der Mitarbeiter muss deshalb viel Zeit dafür aufwenden, die benötigten Daten im Papierformular zu suchen. Dokument- und Formulardesign im Printmedium bzw. in der Benutzerschnittstelle sind nicht aufeinander abgestimmt. –– Die formularlastigen Screens zeigen gerade neuen und unerfahrenen Nutzern keine Reihenfolge der Bearbeitung auf, in der Daten eingegeben werden sollen/müssen. Nutzer stehen vor einem Wald aus Formularfeldern, von denen nur eine Bruchteil für den aktuellen Arbeitsschritt relevant ist. Die Einarbeitungszeit erhöht sich durch die hohe kognitive Belastung, die der neue Mitarbeiter beim Erlernen der Software (cognitive load) erfährt deutlich (Abbildung 2). –– Durch das stetige Anwachsen der Funktionsvielfalt und sich weiter ändernde Anforderungen hat sich eine große Anzahl an Feldern entwickelt,

die nicht (mehr) relevant sind. Oft ist nicht klar, ob ein bestimmtes Feld / Funktion überhaupt noch benötigt wird. Die Übersichtlichkeit der Software leidet darunter stark. Die dadurch entstandene schwer zu durchschauende Informationsstruktur lässt die Zusammenhänge von Informationen oft nicht klar erkennen (Abbildung 2). –– Begriffe werden oft nicht konsistent verwendet, z. B. wird der Begriff Stammdaten für unterschiedliche Informationen mehrmals verwendet. Zudem werden die Begrifflichkeiten oft aus Entwicklersicht vergeben (z. B. Ansichten: Eine Funktionsleiste, in der der Nutzer häufig benötigte Werkzeuge ablegen kann) und unterstützen den Mitarbeiter nicht aktiv darin, zu verstehen, welche Funktionen sich dahinter verbergen. Auch hier ergeben sich gerade für einen neuen Mitarbeiter viele Unklarheiten. [Abb. 2] –– Die Umsetzung der Suche erfolgt aus Systemsicht (Abbildung 3), da in unterschiedlichen Datenbanken gesucht wird, werden dem Nutzer auch mehrere Einstiegspunkte angeboten (Kunde, Tickets, Telefonleitungen). [Abb. 3] –– Die Schlüsselfunktionen sind oft versteckt und nur über Klick mit der rechten Maustaste über ein Kontextmenü aufrufbar (Abbildung 4). Auch sonst gestaltet sich die Navigation sehr klicklastig, da für neue Funktionen neue Reiter geschaffen wurden (z. B. Rabatte), was zu einem hin und herspringen zwischen den einzelnen Formularen führt. Zusätzlich wird durch eine horizontale Trennung der Formulare das Auffinden von wichtigen Informationen erschwert. [Abb. 4] –– Die Verschachtelung der Informationen und Funktionen, sowie eine nicht ersichtliche Abfolge von Arbeitsschritten stellt auch erfahrene Mitarbeiter immer wieder vor Herausforderungen. Die Reihenfolge, in der die Schritte abgearbeitet werden müssen, sind zwar nach langer Erfahrung in die Routine der

199


Abb. 5. Viele Reiter verursachen ein Hin- und Herspringen in der Nutzung.

–– Zentrale Anzeige der offenen Arbeitsschritte als Strukturierungshilfe für den Arbeitsalltag –– Vereinheitlichte Suchfunktion aus Nutzersicht: Ein Suchformular durchsucht alle Datenbanken und stellt Ergebnisse gruppiert dar –– Angleich an Papierformulare zur schnelleren Datenerfassung (match between system and the real world) –– Ausblenden nicht benötigter Funktionen –– Schlüsselfunktionen über einen Klick erreichbar machen. [Abb. 8] –– Abbildung 8: Schlüsselfunktionen (z. B. Neuauftrag, Suchfunktion) sind stets mit einem Klick erreichbar. –– Konsistentes Layout für alle Formulare –– Kontextsensitive Hilfe zur Erläuterung von Feldnamen und Funktionen –– Umsetzung der Suche aus Nutzersicht: Ein Eingabefeld für den Suchstring liefert strukturierte Ergebnisse zurück. 6. Lessons Learned

Abb. 6. Prozessorientierter Wizard zur schnellen Dateneingabe.

Mitarbeiter eingegangen, erfordern aber gerade bei nicht so häufig auftretenden Use Cases immer wieder hohe kognitive Belastung. [Abb. 5] 5. Redesign: Wesentliche Designentscheidungen Aus dem oben beschriebenen Prototyping und Testzyklus ergeben sich die folgenden Designentscheidungen für den Neuentwurf:

Abb. 7. Kunden und eindeutig zugeordnete Informationen.

200

–– Umsetzung eines prozessorientierten Wizards für häufige Dateneingabesequenzen. [Abb. 6] –– Eine auf den Unternehmenskontext angepasste Informationsarchitektur für Kunden, Produkte und deren zugehörigen Daten. [Abb. 7] –– Anpassen und Abgleichen der Terminologie auf Arbeitsprozesse; Reduktion der Doppelbelegungen

Abb. 8. Kunden und eindeutig zugeordnete Informationen.

Das Projekt konnte erfolgreich abgeschlossen werden und das überarbeitetet Bedienkonzept wird vom Kunden gerade umgesetzt. Wir gehen grundsätzlich davon aus, dass die in diesem Projekt vorgefundene Mischung aus fehlendem Usability-Know-how und gewachsenen Softwarestrukturen mit hohem Funktionsumfang gerade bei kleinen und mittleren Unternehmen weit verbreitet ist. Neben der Einführung von Usability EngineeringMethoden stellt sich das konkrete Usability Re-Engineering solcher Anwendungen als relevantes Tätigkeitsfeld für Usability Consultants heraus. Folgende Punkte sind unseres Erachtens besonders relevant: 1. Do it fast | Durch hohe Arbeitsbelastung aufgrund parallel zu bearbeitender Projekte konnte dieses Projekt nicht so effizient bearbeitet werden, wie es prinzipiell möglich gewesen wäre. Komplexe Problemstellungen


Usability Professionals 2012 User Experience

ziehen immer wieder erneuten Einarbeitungsaufwand für die Usability-Consultants nach sich und verursachen somit eine ineffizientere Projektabwicklung durch Mehraufwände. 2. Record your results | Gerade bei komplexen und umfangreichen Programmen ist es für eine UsabilityAnalyse essentiell, dass Nutzertests, Contextual Inquiries etc. mit Video und Ton aufgezeichnet werden. Nur so lässt sich auch zu einem späteren Zeitpunkt das erfasste Problem erneut verstehen (vgl. Punkt 1). Für unsere Analyse und das Redesign war es immer wieder nötig, das Videomaterial zu sichten und erneut aus einem anderen Blickwinkel zu betrachten. Aufgrund der Komplexität ergaben sich häufig neue Perspektiven auf Probleme wie Lösungen. Die Nutzung von Morae und Annotationen mit so genannten Markern erleichtert die Analyse der Videos deutlich. 3. Fragen, fragen, fragen |  Nicht nur bei der Anforderungsanalyse ist es essentiell, stets nachzufragen. Wenn man denkt, man habe es verstanden – nochmals nachfragen. Aus unserer Sicht können nur so Missverständnisse minimiert werden. Falsche Höflichkeit oder Angst, der Auftraggeber können den Consultant aufgrund der vielen Nachfragen für nicht fähig halten, sind völlig fehl am Platz: Für nicht fähig wird man nur eingestuft, wenn man auch nach mehrwöchiger Projektlaufzeit Dinge nicht versteht, die man zu Anfang hätte durch Nachfragen klären können. 4. Erfolgsfaktor | Veränderungswille beim Unternehmen ist essentiell für den Erfolg eines Usability-Projekts eines Dritten. Mit Unterstützung des Managements ist ein wichtiger Schritt für den Erfolg des Projekts getan. 5. Geeignete Testumgebung | Durch die räumliche Struktur des Arbeitsumfelds beim Auftraggeber blieben die Türen zum Gang hin auch während der Contextual Inquiry und den Nutzertests geöffnet. Dies legt den Verdacht nahe, dass eventuell einige kritische Äußerungen weniger deutlich geäußert wurden.

6. Hauseigene Software | Das sehr gute Klima im Unternehmen führte evtl. auch dazu, dass auch von Entwicklerseite her bekannte Usability-Probleme weniger deutlich formuliert und sofort relativiert wurden. 7. Klares Abstecken von Zielen des Reengineering | Am Anfang ließ sich der funktionale Umfang der Software auf Grund ihrer Komplexität nur schwer erkennen. Sich hier schnell einen Überblick zu verschaffen und dann mit dem Kunden die Rahmenbedingungen abklären, was im Zeitrahmen möglich ist, ist essentiell für ein gelungenes Projekt.

6. Twentyman, J. (2009). Usability: „Lovely Software, but I can’t work it“. Financial Times. (http://www.ft.com/cms/s/0/ c627386a-5a0d-11de-b687-00144feabdc0. html#axzz1pVBLkXQZ [Zugriff 3 / 2012]). 7. Warfel, T. Z. (2009). Prototyping: A Practitioner’s Guide (1st ed.). Rosenfeld Media. 1

http://www.r-kom.de

2

Typische Nutzungsszenarien wurden in der Analyse erhoben.

7. Fazit Unternehmenssoftware zeichnet sich aufgrund des umfangreichen Funktionsumfangs häufig durch hohe Komplexität aus. Für ein zielgerichtetes und erfolgreiches Redesign ist ein Verständnis der bestehenden Prozesse deshalb essentiell. Zudem spielen die Rahmenbedingungen eine wichtige Rolle: Der Veränderungswille beim Kunden und die Unterstützung der Mitarbeiter stellten wichtige Faktoren für den Erfolg des Projekts dar. Literatur 1. DIN EN ISO 9241-210 (2010). Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme. Beuth Verlag GmbH. 2. Hammer, M., & Champy, J. (1993). Reengineering the Corporation: A Manifesto for Business Revolution. Harper Business. 3. Johnson, J. (2010). Designing with the mind in mind: simple guide to understanding user interface design rules. Children. Morgan Kaufmann Publishers Inc. 4. Krug, S. (2009). Rocket surgery made easy: The do-it-yourself guide to finding and fixing usability problems. New Riders. 5. Nielsen, J. (1994). “Guerrilla HCI: using discount usability engineering to penetrate the intimidation barrier.” In Bias, R. G., Mayhew, D. J. (Eds.). Cost-justifying usability. Orlando, FL: Academic Press, 245-272 (http://portal.acm.org/citation. cfm?id=186524.186639).

201


Interaktive Kommunikation für Ausstellungen gestalten Wie spielerisch soll mediale Wissensvermittlung sein? Thomas Willis studio klv GmbH & Co. KG Crellestraße 29 – 30 10827 Berlin tw@thomaswillis.de willis@studioklv.de

Abstract In dem Beitrag wird erörtert, wie sowohl das technische als auch das inhaltliche Innovationspotential von neuen Medien in Ausstellungen zielführend genutzt werden kann. Der Autor vertritt dabei die These, dass eine intuitive und „freudvolle“ Interaktion mit dem Medium einen entscheidenden Faktor für die erfolgreiche Wissensvermittlung darstellt. Sobald den Ausstellungsbesuchern der Umgang mit dem jeweiligen technischen System leicht fällt und Freude bereitet, lassen sie sich auf die zu vermittelnden Inhalten ein und erinnern sich nachhaltig daran.

1. Wissensvermittlung in Ausstellungen Die Paradigmen des Lernens und des Lehrens haben sich in den letzten Jahren stark gewandelt. Wenn noch vor einigen Jahren der Frontalunterricht die gängige Lehrmethode in den deutschen Schulen war, gestaltet sich der Unterricht heute bedeutend vielfältiger. Es wird in Gruppen gearbeitet, Workshops veranstaltet, Exkursionen unternommen, usw. Der heute lernende Schüler wird also im Vermittlungsprozess viel mehr als aktiver Teilnehmer, denn als passiver Zuhörer verstanden. Was für die Schulbildung gilt, kann auch auf andere Formen des Lernens übertragen werden. Egal ob Ausbildung, Weiterbildung, Erwachsenenbildung, LiveLong-Learning, usw. Der Lernende nimmt nicht nur das zu Vermittelnde geduldig hin, er erwirbt es sich selbständig und aktiv. Ausstellungen können, ganz allgemein formuliert, als Einrichtungen der Wissensvermittlung verstanden werden. Je nach Kontext, in dem eine Ausstellung stattfindet, unterscheidet sich die Art des „Wissens“, das dargeboten wird. Sei es kulturhistorisches Wissen im historischen Museum, naturwissenschaftliches Wissen im Science Center oder auch „MarkenWissen“ im Firmenmuseum. Und auch bei

202

Ausstellungen ist derselbe didaktische Trend wie in der Schulbildung zu erkennen: Der Ausstellungsbesucher will nicht mehr bloß mit Fakten konfrontiert werden, er will sich das Wissen selbst erwerben und dabei Freude empfinden.

Keywords: /// Interaction Design /// Funology /// Ausstellung /// Wissensvermittlung /// Lernen

Das Konzept des selbstmotivierten, spielerischen Lernens durch Ausprobieren und Experimentieren wird schon seit den 70er Jahren in Science Centern praktiziert. Science Center oder zu Deutsch „Mitmach-Museen“ sind Ausstellungsorte

Abb. 1. Exponat „Rodeo-Kreisel“ im Dynamikum Science Center Pirmasens, Entwicklung: Technorama, Foto: Axl Klein


Usability Professionals 2012 User Experience

mit naturwissenschaftlichem Schwerpunkt. Es wird ein Vermittlungskonzept verfolgt, das den Ausstellungsbesucher auffordert, physikalische oder andere naturwissenschaftliche Phänomene mit möglichst vielen seiner Sinnen im wahrsten Sinne des Wortes zu begreifen – z. B. indem er sich selbst auf einen Rodeo-Kreisel setzt und die Gesetzmäßigkeiten der Drehimpulse als körperliches Erlebnis erfährt. Als erstes Science Center wurde 1969 das Exploratorium San Francisco eröffnet, das Frank Oppenheimer initiierte. Seither erfolgt eine rasche Ausbreitung dieses Ausstellungsformats, zuerst in den USA und seit den 80er Jahren auch in Europa und Deutschland. [Abb. 1] 1.1. Darf Lernen Spaß machen? Dem Konzept des Edutainment – ein Kunstwort aus Entertainment und Education – wird oft mangelnde Ernsthaftigkeit und inhaltliche Flachheit vorgeworfen. Das Kritikwürdige an dem Konzept ist aber nicht die Bemühung, unterhaltsame Momente (Entertainment) mit solchen der Bildung und des Lernens (Education) zu verbinden. Fatal ist eher, diese beiden Begriffe als Gegensätze zu verstehen: Bittere Lernhappen werden erst durch Spaßhäppchen erträglich. Von einem gelungenen „Edutainment“ kann dann gesprochen werden, wenn Spaß und Lernen nicht auseinanderfallen, sondern sich ergänzen. Wenn dieses Ineineinandergreifen gegeben ist, bereitet die lernende Beschäftigung selbst Freude. Und eine emotional positive Grundeinstellung, begleitet von persönlichem Interesse wird in der Lernpsychologie als Motivation bezeichnet und gilt als eine der wichtigsten Voraussetzungen für den erfolgreichen Lernprozess (vgl. Reinmann 2005). In diesem Verständnis spricht man heute eher von Playful Learning als von Edutainment. Mark Blythe und Marc Hassenzahl (Blythe & Hassenzahl 2003) versuchen die Terminologie von „Spaß“ als positives Gefühl genauer zu differenzieren. Sie definieren Spaß (fun) als ein Gefühl, das hauptsächlich auf Ablenkung beruht, während

Freude (pleasure) ein auf Absorption beruhendes Gefühl sei. Nach dieser Definition sollte im Kontext des Lernens eher von Freude als von Spaß die Rede sein. So dürfte die anfangs gestellte Frage nicht lauten „Darf Lernen Spaß machen?“ sondern „Darf Lernen Freude bereiten?“. Und diese Frage muss nach dem Verständnis des Autors mit einem eindeutigen „Ja!“ beantwortet werden. Die Frage die sich nun für Macher von medialen Lernumgebungen stellt, ist folgende: Wie kann mediale Wissensvermittlung so gestaltet werden, dass sie Freude bereitet? Obwohl computergestützte Medien sich besonders anbieten, ihre Benutzer als aktive Protagonisten zu verstehen, sind sie nicht per se gute Tools der Wissensvermittlung. Im Gegenteil, schlecht eingesetztes „Bildschirm-Flimmern“ kann auch zu Ablehnung und Frustration führen. Es kommt – wie bei allen Medien – auf die Qualität der Umsetzung an. Das betrifft einerseits die technische Gestaltung, wobei dabei die Gestaltung der Benutzungsschnittstelle eine besondere Rolle spielt. Andererseits ist die Aufbereitung der Inhalte entscheidend. Sowohl hinsichtlich des Vermittlungskontextes und der Zielgruppe, als auch hinsichtlich des Mediums, mit dem es präsentiert wird. 2. Informationen mit neuen Medien vermitteln Die Kernaufgabe jeglicher Wissensvermittlung liegt darin, Informationen und Wissensinhalte so aufzubereiten, dass sich die Lernenden damit Wissen spielerisch aneignen können. Das Adjektiv „spielerisch“ soll in diesem Zusammenhang die Eigenschaften des Lernens hervorheben, die Johan Huizinga in seiner Definition von Spiel beschreibt: „Spiel ist eine freiwillige Handlung oder Beschäftigung, die innerhalb gewisser festgesetzter Grenzen von Zeit und Raum nach freiwillig angenommenen, aber unbedingt bindenden Regeln verrichtet wird, ihr Ziel in sich selbst hat und begleitet wird von einem Gefühl der Spannung und Freude und einem Bewusstsein

des ‘Andersseins’ als das ‘gewöhnliche Leben’.“ (Huizinga 2004) Spielerisches Lernen impliziert somit als Grundvoraussetzung, dass sich der Lernende freiwillig mit dem Lernstoff beschäftigt. Darüber hinaus bereitet ihm die lernende Beschäftigung solche Freude, dass er ganz in die Welt der Lerninhalte eintaucht und das „gewöhnliche Leben“ dabei quasi vergisst. Das sind hohe Ansprüche an Wissensvermittlung, die bestimmt nicht in allen Fällen zu hundert Prozent erreicht werden können. Dennoch können sie als Ziel und Messlatte für eine gelungene Wissensvermittlung stehen. Welche Faktoren zur Freude beitragen ist schwer zu identifizieren und variiert mit den individuellen Vorlieben. PierreAlexandre Garneau (Garneau 2001) zum Beispiel zählt 14 Formen von Freude auf, die er im Zusammenhang mit Computerspielen für relevant hält. Das sind: Schönheit, Immersion, Problemlösen, Wettkampf, Soziale Interaktion, Komödie, Nervenkitzel, Physische Aktivität, Liebe, Schöpfung, Macht, Entdeckung, Fertigkeiten anwenden. Die meisten der aufgezählten Quellen für Freude können auch auf die vermittelnde, interaktive Kommunikation angewandt werden. Für besonders relevant hält der Autor folgende: –– Entdeckung –– Soziale Interaktion –– Physische Aktivität –– Immersion –– Schöpfung Diese Aufzählung soll um drei Begriffe erweitert werden: –– Bezug zu sich selbst –– Spiel (beinhaltet u. a. auch Wettkampf und Fertigkeiten anwenden) –– Narration 3. Beispiele aus der Praxis Im Folgenden sollen die aufgestellten Thesen anhand von Beispielen aus der Praxis belegt werden. Dafür werden interaktive

203


Abb. 2. Foyer des Dynamikum Science Center Pirmasens, Foto: Axl Klein

Medienexponate aus zwei Einrichtungen herangezogen, die von studio klv gestaltet wurden. Das ist zum einen das 2008 eröffnete Dynamikum Science Center Pirmasens. Ein Mitmach-Museum mit rund 150 Hands-On Exponaten zu naturwissenschaftlichen Phänomenen. Zum anderen das Vitarium, ein außerschulischer Lernort und Besucherzentrum der luxemburgischen Molkereigenossenschaft „Luxlait“, welches 2011 eröffnet wurde. [Abb. 2], [Abb. 3] 3.1. Interesse wecken Im Vitarium Luxemburg werden die Themen Kuh und Milch, Ernährung, Gesundheit, Fitness und Konsum behandelt. Das Spektrum reicht von sehr einfachen Inhalten, wie dem Gewicht einer Kuh bis hin zu hochkomplexen Zusammenhängen, wie dem Verdauungsprozess bei Wiederkäuern. Sowohl die Vermittlung von niederkomplexen, als auch von hochkomplexen Inhalten birgt die Gefahr, langweilig oder frustrierend zu erscheinen. Wenn beim Lernenden von Anfang an eine negative Einstellung herrscht, wird dieser nicht gewillt sein, sich freiwillig mit der Materie zu beschäftigen. Aus diesem Grund besteht die erste (vielleicht sogar primäre) Aufgabe der Ausstellungskommunikation darin, bei den Ausstellungsbesuchern

204

Interesse zu wecken. Im Falle der interaktiven Kommunikation kann das bedeuten, dass die Interaktion an sich so interessant und freudvoll ist, dass die Inhalte quasi „nebenbei“ aufgenommen werden. Die beiden Vitarium Exponate „Magenmikroskop“ und „Die Kuh und du!“ stellen diesen Zusammenhang dar. 3.1.1. Exponat „Magenmikroskop“ Ein wichtiger Faktor der medialen Interaktion ist ihre intuitive Verständlichkeit. Hierbei ist es hilfreich, wenn der Benutzer auf bereits gelernte Interaktionsschemata zurückgreifen kann, die er in so genannten mentalen Modellen (vergleiche Norman 2002) gespeichert hat. Die Bedienung des Exponats „Magenmikroskop“ erfolgt beispielsweise wie ein analoges Mikroskop. Der Benutzer wählt zunächst vier Magen-Scheiben (entspricht den Mikroskop-Präparaten) aus und legt diese unter das mediale Mikroskop. Statt in ein Okular schaut der Benutzer dann auf ein kleines Display, worauf er den jeweiligen Magen entsprechend vergrößert dargestellt sieht. Indem er die Magen-Scheiben unter dem Mikroskop bewegt, wird die Magengrafik auf dem Display analog mit bewegt. Als Ergebnis kann er jeden einzelnen Magen spielerisch erforschen. Über sogenannte interaktive Hotspots ist es ihm möglich,

Abb. 3. Ausstellungsraum des Vitarium Luxemburg, Foto: Dan Zoubek

vertiefende Wissensinhalte in Form von Text, Grafik und Animation abzurufen. Auf diese Weise erhält der Besucher einen selbstbestimmten Zugang zum Wissen über die Funktionsweise der vier Mägen einer Kuh. Die komplexen Zusammenhänge des Verdauungsprozesses werden dem Lernenden Schritt für Schritt präsentiert. Er erarbeitet sich die Zusammenhänge selbst, indem er die Mägen wie ein Forscher untersucht. Im Prozess des Untersuchens und Entdeckens liegt der Reiz, der den Lernenden motivieren kann, sich intensiver mit einem Thema zu befassen, als das bei einer „klassischen“ Vermittlung der Fall wäre. [Abb. 4], [Abb. 5] 3.1.2. Exponat „Die Kuh und du!“ Bei der Benutzung des Exponats „Die Kuh und du!“ wird auf bereits vorhandene mentale Modelle zurückgegriffen. Dabei handelt es sich um eine digitale Personenwaage – allerdings mit einer speziellen Gewichtsanzeige. Anstatt das eigene Gewicht als Zahlenwert angezeigt zu bekommen, werden stattdessen Kuhorgane mit korrelierendem Gewicht angezeigt. Dies erfolgt auf eine Weise, die den anatomischen Zusammenhang im Körper der Kuh verständlich macht.


Usability Professionals 2012 User Experience

Abb. 4. Exponat „Magenmikroskop“ im Vitarium Luxemburg

Wie viele Kilogramm die Euter oder der Pansen einer Kuh wiegen, ist für die meisten Menschen relativ belanglos und daher langweilig. Wenn man hingegen erfährt, dass der Pansen einer Kuh so viel wiegt, wie man selbst, finden das die meisten Menschen viel interessanter. Das liegt ganz einfach daran, dass aus einer abstrakten Zahl (76 Kilogramm) eine vorstellbare Größe („mein Gewicht“) und vor allem ein Bezug zu sich selbst und damit zur eigenen Lebenswirklichkeit hergestellt wurde. Die Tätigkeit des sich Wiegens und dabei Informationen über die Kuh-Anatomie zu erfahren, wird viel explorativer, kommunikativer und dadurch freudvoller, wenn man das nicht nur alleine, sondern mit anderen Leuten zusammen machen kann. Das erweitert den Spielraum auch insofern, als nicht nur das eigene Gewicht, mit dem von Kuhorganen verglichen werden kann. Sondern nun auch andere Organe aus einer Kombination von mehreren Besuchern dargestellt werden können. So werden die Besucher angehalten, miteinander zu kommunizieren, andere Besucher zu motivieren, mitzumachen und gemeinsam zu experimentieren. Diese Art der Vermittlung, die auf den Bezug des Besuchers zu sich selbst und auf soziale Interaktion setzt, hilft, „langweiliges“ Faktenwissen über die Anatomie

einer Kuh mit einem freudvollen Erlebnis zu verbinden. [Abb. 6], [Abb. 7] 3.2. Den Benutzer ins Zentrum rücken Das übergeordnete Thema im Dynamikum Science Center Pirmasens lautet „Bewegung“. Neben einer großen Anzahl von analogen, vornehmlich physikalischen Experimenten gibt es auch mediale Experimentierstationen zur Thematik. Gemäß der Science Center Philosophie des selbst ausprobieren, experimentieren und körperlich aktiv sein, werden die Besucher auch bei den medialen Experimenten ins Zentrum der Vermittlung gerückt. Der Bezug zu sich selbst spielt als Vermittlungsprinzip sowohl im „Wettlauftunnel“ als auch im „Planetenraum“ die wichtigste Rolle. 3.2.1. Exponat „Wettlauftunnel“ Die Fortbewegungsgeschwindigkeiten von verschiedenen Lebewesen – etwa eines Elefanten, eines Dackels, eines Krokodils, einer Schildkröte und eines Spermiums – sind statistische Werte und werden nicht unmittelbar mit einem emotionalen Erlebnis in Verbindung gebracht. Das würde sich schlagartig ändern, wenn man gegen diese Tiere um die Wette rennen könnte. Genau das können die

Abb. 5. Screendesign „Magenmikroskop“

Ausstellungsbesucher im Wettlauftunnel machen. Mit Hilfe von Medientechnik zum einen und Animationen auf Grundlage von filmischen Bewegungsanalysen der genannten Tiere zum anderen. Wenn man den Wettlauf gegen einen Elefanten haushoch verliert, wird man sich nachhaltig erinnern, dass ein Elefant viel schneller läuft, als ein Mensch. Und zwar deshalb, weil ein emotionales Erlebnis mit diesem Wissen verknüpft wurde. Um die Illusion des Wettrennens in der Mixed Reality Anwendung für den Benutzer aufrecht zu erhalten, müssen einige Faktoren berücksichtigt werden. Das Szenario muss so aufgebaut sein, dass ein für den Benutzer „korrekter“ räumlicher Eindruck entsteht. Dafür wird das laufende Tier als animierte Silhouette genau seitlich, ohne perspektivische Verzerrung dargestellt und auf die 12 Meter lange Wand des Wettlauftunnels projiziert. Wenn nun der Benutzer beim Rennen zur Seite schaut, hat er das Gefühl, das Tier würde tatsächlich neben ihm laufen. [Abb. 8] 3.2.2. Exponat „Planetenraum“ Während es sich beim Wettlauftunnel um eine Mixed Reality Anwendung handelt, spielt der Planetenraum komplett in der virtuellen Realität. Wenn der Besucher

205


Abb. 6. Exponat „Die Kuh und du!“ im Vitarium Luxemburg

den abgedunkelten Raum betritt, dessen Fussboden komplett medial bespielt wird, taucht er völlig in die Welt der Inszenierung ein. Bei diesem Exponat wird das Konzept des Benutzer-ins-Zentrumder-Vermittlung-rücken noch intensiver angewandt und auf die Spitze getrieben. Denn jeder Benutzer, der den Raum betritt bekommt eine von oben projizierte Sonne als seinen Avatar zugewiesen, die ihn auf Schritt und Tritt folgt. Der Lernende wird quasi selbst zu einer Sonne, wodurch er selbst und der Raum um ihn herum in einen makroskopischen Maßstab skaliert wird. Aus dieser Perspektive beobachtet er nun, wie Planeten durch den Raum fliegen und welche Kräfte er als Sonne auf die Himmelskörper ausübt: Wenn er einen Planeten „eingefangen“ hat, beginnt dieser getreu den Keplerschen Gesetzen als animierte Simulation in einer elliptischen Bahn um den Lernenden zu kreisen. Da sich mehrere Benutzer gleichzeitig im Planetenraum aufhalten können, sind die Lernenden angehalten, gemeinsam „planetarische Experimente“ zu vollziehen und in spielerischer Interaktion zu beobachten, wie sich die Gravitationskräfte mehrerer Sonnen auf die Bewegungsbahnen der simulierten Himmelskörper ausüben. Auch hier wird ein immersives, emotionales Erlebnis geschaffen, dass der Lernenden im Gedächtnis behalten wird.

206

4. Fazit Der Vorgang des „Lernens“ bedeutet in erster Linie, sich mit etwas zu beschäftigen – dabei werden etwaige neue Erkenntnisse mit vorhandenen verknüpft, alte Erkenntnisse neu bewertet, umstrukturiert, usw. Je intensiver diese Beschäftigung ist, desto größer ist die Chance, einen Lerneffekt zu erzielen. Der Grad der Intensität steht dabei in engem Zusammenhang mit dem Grad der Freude an der Beschäftigung. Aus dem Grund hilft spielerische interaktive Kommunikation dabei, Lernen in Ausstellungen als freudvolles Erlebnis zu gestalten – wenn sie gut gemacht ist.

Abb. 7. Screendesign „Die Kuh und du!“

Literatur 1. Blythe, M. & Hassenzahl, M. (2004). The semantics of fun: Differentiating enjoyable experiences. In Blythe, M., Overbeeke, C. , Monk, A.F. & Wright, P.C. (Hrsg.). Funology: From Usability to Enjoyment (S. 91-100). Dordrecht: Kluwer Academic Publishers. 2. Garneau, P.-A. (2001). Forteen forms of fun. http://accad.osu.edu/~pgarrett/730/ gamasutra/Gamasutra-Fourteen-Forms-ofFun.html 3. Hassenzahl, M. (2003). Spielend arbeiten? Computerspiele und ‘ernsthafte’ Software. http://www.playability.de/1/hassenzahl.html 4. Huizinga, J. (2004). Homo Ludens: Vom Ursprung der Kultur im Spiel. Reinbek bei Hamburg: Rowohlt Taschenbuch Verlag. 5. Norman, D. (2002). The Design of Everyday Things. New York: Basic Books 6. Reeps, I. (2004). Joy-of-Use – eine neue Qualität für interaktive Produkte. Masterarbeit, Universität Konstanz. 7. Reinmann, G. (2005). Blended Learning in der Lehrerbildung: Grundlagen für die Konzeption innovativer Lernumgebungen. Lengerich: Pabst Science Publishers 8. Wilke-Müller, G. (2006).Prinzipien von Funology in ihrer Relevanz für E-Learning Systeme unter besonderer Berücksichtigung kommunikativer Funktionen. Masterarbeit, Universität Konstanz.


Usability Professionals 2012 User Experience

Abb. 8. Exponat „Wettlauftunnel“ im Dynamikum Science Center Pirmasens, Foto: Axl Klein

Abb. 9. Exponat „Planetenraum“ im Dynamikum Science Center Pirmasens, Foto: Axl Klein

207


Die papierlose Haltestelle Anforderungsanalyse für interaktive digitale Fahrgastinformationssysteme als Ersatz für Papieraushänge im ÖPNV Paul Müller Agentur Siegmund GmbH Leuschnerstraße 3 70714 Stuttgart p.mueller@agentur-siegmund.de

Benjamin Laukenmann Agentur Siegmund GmbH Leuschnerstraße 3 70714 Stuttgart b.laukenmann@agentur-siegmund.de

Abstract An Haltestellen des öffentlichen Personennahverkehrs werden Informationen schon seit Jahren gezielt auf digitalem Weg bereitgestellt. Größer Pluspunkt ist dabei die Möglichkeit der Aktualisierung von Daten in Echtzeit. Allerdings bieten viele Haltestellen immer noch zahlreiche Informationen über herkömmliche Papieraushänge an. Dies bedeutet bisher bei Änderungen einen hohen Aufwand für die Verkehrsbetriebe. Mit dem verstärkten Einsatz von Digital Signage, also dem Einsatz von digitalen Medieninhalten, und der steigenden Benutzung von Smartphones auch in Deutschland, stellt sich daher die Frage, ob und wie man Fahrgästen die benötigten Informationen digital anbieten kann. Dabei entstand die Vision der papierlosen Haltestelle. Für eine Realisierung dieser Vision wird nun ein Anforderungskatalog erstellt, der den Grundstein für ein benutzerfreundliches Konzept einer interaktiven digitalen Informationsvitrine legen soll.

1. Einleitung Der Einsatz von digitalen Medieninhalten im öffentlichen Raum, auch Digital Signage genannt, erfreut sich zunehmender Beliebtheit. Während das Bereitstellen digitaler Informationen auf diesem Weg vor einigen Jahren noch weitestgehend auf den angelsächsischen Raum beschränkt war, sind die zahlreichen Bildschirme mit Werbung oder sonstigen Informationen mittlerweile auch in Deutschland nicht mehr zu übersehen. Dem Einsatz sind dabei kaum Grenzen gesetzt: In Hotels, Geschäften, Unternehmen, Bibliotheken oder Restaurants können somit rund um die Uhr Informationen digital verbreitet werden. In Bahnhöfen oder auch Flughäfen haben sich digitale Informationsanzeiger bereits seit längerem durchgesetzt. So ist beispielsweise im öffentlichen Personennahverkehr die dynamische Fahrgastinformation (kurz DFI) nicht mehr wegzudenken und bietet Reisenden minutengenaue Informationen zu den Abfahrtszeiten von Bus und Bahn an. Trotzdem werden an vielen Haltestellen Informationen, wie beispielsweise Abfahrtspläne oder

208

Oliver Siegmund Agentur Siegmund GmbH Leuschnerstraße 3 70714 Stuttgart o.siegmund@agentur-siegmund.de

Keywords: /// eVitrine /// Digital Signage /// ÖPNV /// Anforderungen /// Informationen

Tarifinformationen, größtenteils noch über herkömmliche Papieraushänge angeboten. Mit den bestehenden digitalen Möglichkeiten stellt sich allerdings die Frage nach dem Sinn dieser Papieraushänge. Wäre es nicht sinnvoller, den Fahrgästen sämtliche Informationen an einer Haltestelle über ein einziges digitales Medium zur Verfügung zu stellen?

benötigten Informationen gebündelt über ein einziges Medium verfügbar zu machen, müssten Fahrgäste diese je nach Bedarf individuell abrufen können. Realisiert werden könnte dies über ein einzelnes interaktives digitales System.

Die Grundidee, Fahrpläne statt auf Papier in digitaler Form anzubieten, ist an sich nicht neu und momentan ein von vielen Seiten mit großem Interesse verfolgtes Thema, welches aber speziell in Deutschland erst im Aufkommen ist. Digitale Abfahrtspläne an Bushaltestellen finden sich beispielsweise bereits in Dresden oder der Region Salzburger Seenlandschaft. Dabei handelt es sich allerdings meist um ein passives Aufnehmen von Informationen, welche mehr oder weniger von den Papieraushängen übernommen und digitalisiert werden. Dies wäre aber beispielsweise bei der Vielzahl von Aushanginformationen einer komplexen U-BahnHaltestelle mit mehreren Linien nicht möglich, da diese sich nicht auf einem einzigen Display darstellen lassen. Um alle

Seit September 2010 betreibt die Stuttgarter Straßenbahnen AG (SSB) in Stuttgart drei elektronische Informationsvitrinen, dort kurz eVitrinen genannt, im Testbetrieb. Im Gegensatz zu den dynamischen Fahrgastinformationen, über welche Informationen nur passiv aufgenommen werden, sind die eVitrinen mit einem Touch-Display ausgestattet. Fahrgäste können sich somit per direkter Interaktion mit der eVitrine individuell ihre benötigten Informationen beschaffen. Dabei gehen die angebotenen Informationen weit über die Abfahrtszeiten der nächsten Stadtbahnen hinaus. So können beispielsweise die Abfahrtspläne aller an den Haltestellen abfahrenden Linien von S-Bahnen, Stadtbahnen oder Bussen abgefragt werden. Außerdem werden Liniennetzpläne,

2. Stand der Dinge


Usability Professionals 2012 User Experience

Tarifinformationen, Sonderlinien zu Events und aktuelle Betriebsänderungen angeboten. Im Juni 2011, also nach einem knappen Jahr Testbetrieb, wurde die Nutzung der eVitrinen statistisch ausgewertet. Ergänzend dazu wurden Mitarbeiter des Fahrgastservice sowohl zu ihrer persönlichen Meinung über die eVitrine als auch ihre Beobachtungen hinsichtlich der Nutzung der eVitrine durch Fahrgäste befragt. Die Erkenntnisse dieser Befragung hatten unter anderem Änderungen in der Menüstruktur und einen Umstieg von der Akustik-Touch-Technik hin zu kapazitiven Touch-Displays zur Folge. In Köln werden schon seit 2008 mehrere eVitrinen vom gleichen Hersteller wie in Stuttgart eingesetzt, allerdings mit einer anderen Oberfläche. Wie auch in Stuttgart können die eVitrinen bisher parallel zu den herkömmlichen Papieraushängen genutzt werden. In Köln wurden ebenfalls Untersuchungen zur Nutzung der eVitrine durch Fahrgäste durchgeführt. Die wichtigsten Erkenntnisse decken sich dabei zu großen Teilen mit denen aus Stuttgart, allem voran die Akustik-Touch-Technik als InteraktionsHürde und der häufige Wunsch einer direkten Fahrplanauskunft von A nach B. 3. Vorteile Der Einsatz von eVitrinen bietet sowohl für die Fahrgäste als auch für die Verkehrsbetriebe viele Vorteile. Aus der Sicht der Fahrgäste sind dies beispielsweise Informationen in Echtzeit, sowohl was die Abfahrtszeiten von Bussen und Bahnen angeht als auch Störungen und Hinweise auf aktuelle Veranstaltungen. Außerdem können über eine eVitrine wesentlich mehr Informationen, auch individuell für einzelne Haltestellen, angeboten und komfortabler dargestellt werden. Als Beispiel seien an dieser Stelle Netz- oder Umgebungspläne genannt, welche über entsprechende Touch-Gesten vergrößert oder gedreht werden könnten. Auch touristische Ziele könnten anschaulicher dargestellt und detaillierter beschrieben werden. Durch den guten Kontrast der hellen Displays, die Sprachauswahl und die Möglichkeit,

Elemente zu vergrößern, bieten eVitrinen außerdem eine höhere Barrierefreiheit als herkömmliche Papieraushänge. Ein weiterer Mehrwert kann auch die Vernetzung von Informationen zwischen eVitrine und mobilen Geräten, beispielsweise über sogenannte Quick Response Codes (QRCodes), darstellen. So könnten beispielsweise Netzpläne oder die individuelle Verbindungen direkt auf das Smartphone übernommen werden. Auch für die Verkehrsbetriebe ergibt sich durch den Einsatz von eVitrinen eine Vielzahl von Vorteilen. Ein sehr wichtiger stellt dabei sicherlich die Einsparung von Material und Zeit und somit von Kosten bei Aktualisierungen der Informationen dar. Anstatt die Informationen wie bisher vor Ort an jeder Haltestelle einzeln auszutauschen, können diese nun einmal zentral geändert werden und sind dann sofort auf allen eVitrinen aktuell und zugänglich. Abgesehen davon verspricht der Einsatz von eVitrinen auch eine Imageverbesserung für die Verkehrsbetriebe: Kommen Fahrgäste komfortabel und einfach an die von ihnen benötigten Informationen und wird ihnen darüber hinaus noch ein Mehrwert geboten, fühlen sie sich wertgeschätzt und sind dementsprechend zufriedener. In der Folge bleibt ein positives Bild des jeweiligen Verkehrsbetriebs und der Stadt im Kopf der Fahrgäste zurück. Dieses hat wiederum das Potential, beispielsweise durch Erzählungen im Bekanntenkreis, weiter verbreitet zu werden. 4. Herausforderungen Auch wenn der Einsatz der eVitrine etliche neue Möglichkeiten eröffnet und durch die moderne Technologie auf viele Menschen faszinierend wirkt, darf nicht außer Acht gelassen werden, dass es auch Gruppen gibt, für die dies möglicherweise nicht zutrifft. So muss das nötige Verständnis aller Fahrgäste für die Touch-Technologie bedacht werden, da dies letztendlich über den Zugang zu den benötigten Informationen entscheidet. Dies gilt insbesondere für ältere Menschen und solche, die nur wenig technikaffin sind. Eine Studie von Google

aus dem Jahr 2011 zeigt, dass die Nutzung von Geräten mit Touch-Displays wie Smartphones oder Tablets in Deutschland zwar stetig zunimmt, die Zahlen hängen im Vergleich zu anderen Ländern wie der USA, Großbritannien oder Frankreich aber noch deutlich hinterher. Der Fakt, dass die Nutzergruppe des öffentlichen Personennahverkehrs sehr breit und heterogen ist, macht eine derartige Untersuchung zu einer echten Herausforderung. Ein Punkt, der gerade im öffentlichen Personennahverkehr (ÖPNV) keinesfalls vernachlässigt werden darf, ist das Thema Barrierefreiheit. Auch wenn diese, wie bereits erwähnt, durch den guten Kontrast, Mehrsprachigkeit und die Möglichkeit des Vergrößerns von Elementen zunächst deutlich erhöht wird, sind auch Faktoren wie beispielsweise die Möglichkeit der Benutzung durch Rollstuhlfahrer oder Kinder zu beachten. Ein sehr wichtiger Punkt ist auch der Fakt, dass die eVitrine immer nur von einer Person zur selben Zeit genutzt werden kann. Sollten mehrere Personen gleichzeitig und unter großem Zeitdruck Informationen benötigen, könnte dies ein Problem darstellen. Durch den konsequenten Einsatz von dynamischen Fahrgastinformationen, welche jeweils die nächsten abfahrenden Busse oder Bahnen anzeigen und meist so angebracht sind, dass sie von allen Seiten auch aus größerer Entfernung gut

209


eingesehen werden können, lassen sich größere Ansammlungen von Menschen vor einer eVitrine jedoch voraussichtlich vermeiden. Allgemein darf gerade bei dem Einsatz im öffentlichen Raum der reale Nutzungskontext nicht vernachlässigt werden. So entspricht die Benutzung einer eVitrine nicht der eines Computers zu Hause. Hier müssen Informationen schnell und eventuell unter hohem Zeitdruck gefunden und verstanden werden. Außerdem haben Faktoren wie Umgebungslärm oder andere Fahrgäste möglicherweise einen Einfluss auf die Nutzung. 5. Ziel und geplantes Vorgehen Für eine Ausschreibung hinsichtlich der Erstellung von Konzept und Design einer neuen Oberfläche der eVitrine sollen nun Anforderungen gesammelt werden, welche schließlich den Grundstein für ein benutzerfreundliches Konzept legen. Für dieses Projekt hat sich eine Allianz von mehreren Verkehrsbetrieben aus verschiedenen Städten zusammengetan. Im Einzelnen sind dies: Stuttgart, Köln, Bonn, Hannover, Bochum/Gelsenkirchen, Nürnberg und Mannheim. Ziel ist es dabei

210

letztendlich, die eVitrine so zu konzipieren, dass sie für Fahrgäste nützlich ist, eine hohe Gebrauchstauglichkeit aufweist und im Optimalfall einen echten Mehrwert bietet. Es müssen benötigte Informationen verständlich dargestellt und das Interface auf einfache Art und Weise nutzbar sein. Die Punkte dienen dabei als Basis für eine positive User Experience. Von Interesse ist dabei vorrangig, welche Informationen an welchen Haltestellen primär benötigt werden. Desweiteren sollen auch, basierend auf Erkenntnissen bereits bestehender Systeme, Hinweise zur Gestaltung mit einfließen. In den Anforderungskatalog aufgenommen werden außerdem auch die Akzeptanz und die Erwartungshaltung von Nutzern sowie neue Ideen hinsichtlich Trends und der Vernetzung mit mobilen Geräten.

Teil 1 – Befragung an herkömmlichen Haltestellen

Das Projekt befindet sich noch in der Planungsphase und wird im August 2012 anlaufen. Es ist zum gegenwärtigen Zeitpunkt in zwei Phasen unterteilt, welche sich wiederum in mehrere Teile untergliedern lassen. So werden in Phase 1 Beobachtungen und Befragungen im Feld durchgeführt, während in Phase 2 ein aktueller Prototyp der eVitrine im Labor evaluiert wird.

Teil 2 – Befragung an bestehenden eVitrinen

Phase 1

In der ersten Phase geht es primär darum herauszufinden, welche der Informationen am häufigsten benötigt werden sowie um Akzeptanz, Erwartung und neue Ideen hinsichtlich des Einsatzes einer eVitrine anstelle von Papieraushängen. Ziel ist dabei unter anderem die Ableitung von typischen Nutzungsszenarien.

Im ersten Teil der ersten Phase werden in verschiedenen Städten und an verschiedenen Haltestellen-Typen kurze Befragungen von Fahrgästen an Informationsvitrinen im Feld durchgeführt. Um diese nicht zu beeinflussen, werden die Fahrgäste erst befragt, nachdem sie die gesuchten Informationen vermeintlich gefunden haben und sich wieder von der Informationsvitrine entfernen. Die Befragung soll dabei bewusst kurz gehalten werden, um die Geduld nicht unnötig zu strapazieren und so schnell viele Personen für die Datenerfassung zu gewinnen. Ziel ist hierbei vor allem herauszufinden, welche Informationen an welchen Haltestellen-Typen benötigt werden.

Im zweiten Teil der ersten Phase werden Fahrgäste an Haltestellen mit einer bestehenden eVitrine beobachtet und anschließend darüber befragt, für welche Art von Informationen sie diese genutzt haben und wie sie das System bewerten. Auch hier sind Kurz-Interviews geplant, welche aber tiefergehende Erkenntnisse als im ersten Teil liefern sollen. Die Befragung wird dabei voraussichtlich teilstandardisiert durchgeführt und durch einen kurzen Fragebogen unterstützt. So soll neben der Art der Informationen zusätzlich auch eine Bewertung der eVitrine hinsichtlich von Interaktion, Gestaltung und dem Umfang der angebotenen Informationen vorgenommen werden. Von Interesse sind


Usability Professionals 2012 User Experience

Teil 1 – Nutzertest

dabei sowohl positive als auch negative Eigenschaften. Ziel ist es, die Akzeptanz der Nutzer und eventuelle Verbesserungsvorschläge zu erfassen. Teil 3 – Focus Groups

Im dritten Teil der ersten Phase werden schließlich mehrere Fokusgruppen zum Thema eVitrine durchgeführt. Geplant ist dabei unter anderem eine Gruppe mit älteren und wenig technikaffinen Menschen, um einen Eindruck der Akzeptanz hinsichtlich des Systems als Ersatz für herkömmliche Papieraushänge zu erhalten. Hierzu wird den Teilnehmern vorab ein Video über die Nutzung der eVitrine gezeigt und anschließend über den Einsatz des Mediums diskutiert. Dabei werden auch die Anforderungen an das System festgehalten und dokumentiert. Außerdem können in diesem Schritt durch Diskussionen mit technikaffinen Teilnehmern auch neue Ideen generiert sowie aktuelle Trends mit aufgenommen werden.

Im ersten Teil der zweiten Phase werden mehrere Nutzertests an dem System einer eVitrine durchgeführt. An diesem sollen die Nutzer typische Aufgaben lösen und werden im Anschluss über Erwartungshaltung, Akzeptanz und einer abschließenden Beurteilung der eVitrine befragt. Um einen zusätzlichen Mehrwert hinsichtlich der Aufmerksamkeitsverteilung zu generieren, wird dabei mit den SMI Glasses auch ein mobiles Eye Tracking System zum Einsatz kommen. Die Nutzertests werden zunächst unter Laborbedingungen stattfinden, da gezielt auf die Interaktionen und das Verständnis von Icons und Menüpunkten geachtet wird und Störvariablen ausgeschlossen werden sollen. Ein Test unter realistischen Nutzungsbedingungen unter Berücksichtigung von Faktoren wie Zeitdruck oder der Einfluss von Menschen oder anderen Ablenkungen in unmittelbarer Umgebung muss im Feld durchgeführt werden, was zu einem späteren Zeitpunkt geplant ist.

Papieraushänge abgeklebt und Fahrgäste beobachtet werden, welche die benötigten Informationen dann ausschließlich über die eVitrine erhalten können. Sind die Reaktionen der Fahrgäste in einer realen Nutzungsumgebung und unter realen Nutzungsbedingungen schlussendlich positiv, kann die Vision der papierlosen Haltestelle in die nächste Phase gehen.

Literatur 1. BBR Verkehrstechnik. (o.A.). Innovation zum Anfassen – Tagesaktuelle Information im ÖPNV. Zugriff am 16.06.2012 unter http://www.bbr-vt.de/fileadmin/pdf/ mofis_iPoint_dt.pdf 2. BBR Verkehrstechnik. (o.A.). Aktuelle Information in höchster Qualität. Zugriff am 16.06.2012 unter http://www.bbr-vt.de/de/ news/artikel/artikel/aktuelle-information-inhoechster-qualitaet.html 3. flexPaper. (2012). Fahrgastinformation mit elektronischem Fahrplanaushang. Zugriff am 18.06.2012 unter http://www.flexpaper.de/ new/index.html 4. mix-L. (2011). Salzburger Seenland –

Teil 2 – Experten-Review

städte- und gemeindeübergreifendes digitales Informationssystem. Zugriff am

Im zweiten Teil der zweiten Phase schließlich wird ein Experten-Review mit dem gleichen System des vorherigen Nutzertests durchgeführt. Dabei wird die implementierte Oberfläche auf die Einhaltung gängiger Usability-Standards wie Selbstbeschreibungsfähigkeit, Konsistenz, Erwartungskonformität und Steuerbarkeit untersucht. Außerdem werden gängige Szenarien aus Nutzersicht durchgespielt und das System hinsichtlich der Gebrauchstauglichkeit und des Nutzungserlebnisses bewertet.

13.06.2012 unter http://www.mix-l.com/ salzburger-seenland 5. Business Partner PBS. (2009). Das Schaufenster als Hingucker. Zugriff am 18.06.2012 unter http://www.pbs-business. de/inhalt/5184-CityUp_-_Das_Schaufenster_ als_Hingucker 6. Wikipedia. (2012). Digital Signage. Zugriff am 20.06.2012 unter http://de.wikipedia.org/ wiki/Digital_Signage 7. Winzer, T. (2010). Verkehrsbetriebe schaffen gedruckten Fahrplan ab. Zugriff am 15.06.2012 unter http://www.sz-online.de/ nachrichten/artikel.asp?id=2567276

Phase 2

6. Ausblick

In Phase zwei wird schließlich ein aktuell bestehendes System evaluiert und auf positive sowie negative Faktoren hin untersucht. Abgedeckt werden soll dies sowohl durch einen Nutzertest als auch durch ein Experten-Review. An dieser Stelle werden Erkenntnisse zur Gestaltung und der Interaktion gesammelt.

Im Anschluss an die Erstellung des Anforderungskatalogs soll schließlich ein auf diesen Anforderungen basierendes Konzept und Design entwickelt und umgesetzt werden. Nachdem dies erfolgt ist, soll als nächster Schritt das neue System an einer Haltestelle im Feld getestet werden. Dabei sollen die momentan noch vorhandenen

211


Cross Plattform Mobile Application Design

Björn Oltmanns ERGOSIGN GmbH Saarbrücken Europa-Allee 12 66113 Saarbrücken oltmanns@ergosign.de

Abstract Der Smartphone und Tablet Boom der vergangenen Jahre hält weiter an. Mittlerweise dominieren Apple und Google mit ihren Geräten und mobilen Betriebssystemen den Markt. In Zukunft ist jedoch von einer weiteren Diversifizierung, beispielsweise durch Microsoft Windows 8 oder neue Geräteformate, auszugehen. Konkurrierende Frameworks und Kulturen stellen Designer und Entwickler von mobilen Applikationen vor enorme Herausforderungen. Der Beitrag erläutert die konzeptionellen Unterschiede von nativen und cross-platform Applikationen und stellt Anhand einer Case-Study einige der Probleme beim Entwurf für mehrere Plattformen vor. Daneben wird auf jene technischen Einschränkungen und Fallstricke beim Entwurf von cross-platform Applikationen eingegangen, die sich direkt auf die User Experience auswirken.

1. Einleitung Durch den Smartphone Boom der letzten Jahre haben mobile Plattformen einen enormen Aufwind erhalten. Derzeit dominieren zwei mobile Betriebssysteme ganz klar den Markt: Zum einen Googles Android mit 61% Marktanteil, sowie Apples iOS mit 20,5% Marktanteil. Microsoft liegt mit seinem Windows Phone Betriebssystem derzeit abgeschlagen noch hinter Blackberry mit 5,2% Marktanteil. [1] Der Marktforscher IDC sieht teilweise jedoch ein starkes Wachstum der von Microsoft entwickelten Windows Phone Plattform und des für Tablets optimierten Betriebssystems Windows 8. Bis 2016 könnte sich im Smartphone Markt das Kräfteverhältnis auf 52,9% für Android, 19,0% für iOS und 19,2% für Windows Phone verschieben. [1] Insgesamt ist jedoch von einer weiteren Diversifizierung des Marktes auszugehen. So plant z. B. Facebook ein eigenes Smartphone samt Betriebssystem auf den Markt zu bringen. Intel arbeitet nach dem erfolglosen MeeGo nun an dessen Nachfolger Tizen.

212

Auf dem Tablett Markt dominiert weiterhin Apples iPad mit einem Marktanteil von 65%, dahinter liegen Samsung und andere Hersteller von Android getriebenen Geräten. Die native Entwicklung von Applikationen für alle Plattformen stellt aufgrund der wachsenden Diversifizierung eine enorme Herausforderung dar, denn jede der Plattformen basiert auf unterschiedlichen Technologien und Frameworks. Dieses Problem wird vermehrt durch crossplatform Lösungen angegangen, welche die Entwicklung von Anwendungen für unterschiedlichste Plattformen auf einer gemeinsamen Technologiebasis erlauben. Vor allem HTML5-basierte Lösungen treten hier in den Vordergrund. Die Entwickler werfen dabei gerne Versprechen wie „Code-Once, Deploy-Everywhere“ in den Raum. 2. Nativ oder nicht? Der Begriff der Nativität einer Anwendung hat unterschiedliche Dimensionen. Zum einen kann dies bedeuten, dass eine

Keywords: /// Mobile /// Cross-Plattform /// Design /// User Experience

Anwendung die vom Hersteller vorgesehenen Programmiersprachen und Frameworks einer Plattform nutzt. Dies stellt in den meisten Fällen auch die Grundlage für die Verwendung von nativen UI-Komponenten dar. Entscheidend für eine positive User Experience einer App ist jedoch die Konformität zur Kultur der Plattform und weniger deren technische Grundlage. Neben nativen UI Controls gehören hierzu auch das Layout, das Informations- und Interaktionsdesign, im Speziellen auch der Einsatz von Gesten. 3. Problematik der Fragmentierung 3.1. Konzeptuelle Fragmentierung und Plattformkultur

Jede der heute am Markt anzutreffenden Plattformen verwendet eine eigene Design-Sprache und etabliert eine eigene Kultur, was Aussehen, Interaktion und Verhalten von nativen Anwendungen angeht. iOS revolutionierte im Jahr 2007 den Markt und stellte etablierte Bedienkonzepte nicht


Usability Professionals 2012 User Experience

Grundsätzlich stellt die Einhaltung der Android Design Guidelines jedoch keine Voraussetzung für eine erfolgreiche Aufnahme in den Play Store von Google dar. [Abb. 1] 3.2. Technische Fragmentierung Neben den konzeptuellen Unterschieden der Plattformen, wirken sich auch technische Aspekte auf das plattformübergreifende Design aus. Diese bedürfen ebenfalls einer individuellen Berücksichtigung, um ein optimales Benutzererlebnis zu ermöglichen. 3.2.1. Hardware Buttons Jede Plattform verwendet Tasten oder Softkeys zur direkten Interaktion mit ihren Anwendungen. Anzahl und Verwendung unterscheiden sich jedoch stark. Das Spektrum reicht von einer einzelnen Taste bei iOS Geräten bis hin zu vier Tasten bei Android Geräten älterer Generation.

Abb. 1. Visuelle und konzeptuelle Unterschiede von iOS 5 und Android 4.0 am Beispiel der Email Apps

nur in Frage, sondern löste einen wahren „Touch Boom“ aus. Während die Entwicklung von iOS von ihren Anfängen bis heute eine kontinuierliche Evolution darstellt, folgten bei Android mit einigen Versionssprüngen teils massive Änderungen am UI. Google hat im Zuge von Android 4.0 das gesamte Interface von Android überarbeitet und eine visuell reduzierte DesignSprache etabliert. Größtes Problem aus Designersicht war zuvor neben fehlenden Design Guidelines auch die Fragmentierung der Android Plattform durch Herstellererweiterungen und deren Custom-UIs. Apple setzt hingegen auf ein geschlossenes Ökosystem und stellte sehr früh umfangreiche Richtlinien in Form der „iOS Human Interface Guidelines“ zur Verfügung. In diesen Dokumenten wird detailliert die Kultur der Plattform beschrieben, auf deren Konzepte und Paradigmen eingegangen und die korrekte Verwendung

von UI Controls erläutert. Die Einhaltung dieser Richtlinien stellt zumindest im Groben auch eine Voraussetzung für die Zulassung der eigenen Produkte in Apple‘s App Store dar. [2] Für die ersten Android Versionen konnte man sich beim Design lediglich an Anwendungen von Google oder jenen von Drittparteien orientieren. Problematisch ist, dass HTC oder Samsung wie andere Hersteller auf eigene Oberflächenerweiterungen und Look&Feels setzen, welche die Erscheinung von Standardkomponenten beeinflussen. Erst mit Version 4.0 stellt Google selbst ein umfangreiches DesignDokument zur Verfügung. Zudem schreibt Google die Auslieferung des Standard Look&Feels als Fallback vor. So kann eine Anwendung entscheiden, ob sie Google konform aussehen möchte oder sich dem Herstellerdiktat unterwirft, mit teils undurchschaubaren Folgen. [3]

Bei iOS ist die Taste lediglich dem Betriebssystem zugeordnet, eine Nutzung innerhalb einer App ist nur zum Verlassen dieser vorgesehen. Bei Android 2.3 Geräten wird eine Taste zum Verlassen der App und zur Rückkehr zum Home Screen verwendet, eine weitere für die Suche, eine dritte für das Aufrufen des in-App Menüs und eine vierte zur Rückkehr zum vorherigen Screen. Bei Samsung Geräten ist jedoch oft keine Suche Taste vorhanden. Android 4.0 führt das Konzept von virtuellen Tasten auf der „Navigation Bar“ am unteren Ende des Screens ein. Diese haben die Funktionen „Zurück zum letzten Screen“, „Applikation verlassen und zum Homescreen“ und „App Switcher öffnen“ für das Multitasking. Der Menü Button wird durch das neue Konzept der „ActionBar“ ersetzt. Legacy Anwendungen die innerhalb von 4.0 ausgeführt werden, erhalten einen zusätzlichen Menü Button in der

213


Abb. 2. Android 2.3 Hardkeys (HTC Sensation XL), Android 4.0 Virtual Keys (Samsung Galaxy Nexus), Android 4.0 Hardkeys (HTC One X), iOS Hardkeys (Apple iPhone 4S), Windows Phone 7 Hardkeys (Nokia Lumia 800)

„Navigation Bar“, der das aus Android 2.x vertraute Menü öffnet. [Abb. 2]

3.2.2. Formfaktoren und Auflösungen Neben unterschiedlichen Betriebssysteme und Versionen, müssen Applikationen auch verschiedene Formfaktoren und Auflösungen beherrschen.

erstrecken sich von 7,0 bis 10,1 Zoll und Auflösungen von 800x480 über 1024x600 bis 1280x800 Pixel. Das native Android Framework führt deshalb eine Matrix aus DPI (Auflösung im Verhältnis zur physikalischen Größe) und Displaygröße ein. Eine native Anwendung kann so bestimmen, welche Auflösungen von UI Grafiken verwendet werden müssen und wie das Layout auf dem Gerät aufgebaut werden muss. Der Designer muss zumindest die gängigen Kombinationen explizit vorsehen und andere durch ein flexibles Layout unterstützen. Ein pixelgenaues Design ist somit kaum möglich. Insgesamt müssen für eine optimale Darstellung Grafiken von Controls und Icons für alle DPI Bereiche vorliegen. Im Idealfall heißt dies vier Auflösungsvarianten pro Element. Eine Verdopplung gegenüber iOS. 4. Case Study: Portierung einer bestehenden Anwendung auf vier Plattformen Die in den ersten Kapiteln erläuterten Probleme gehörten zu den Vorüberlegungen eines konkreten Kundenprojektes von ERGOSIGN.

Das iOS Ökosystem stellt hierbei noch die geringste Herausforderung dar. Eine Anwendung muss zwei Formfaktoren, iPhone und iPad, unterstützten sowie deren korrespondierende Auflösungen, 480x320 und 1024x768 auf 3,5 und 9,7 Zoll Bildschirmdiagonale, sowie im Idealfall deren Rotationsformate. „Retina“ Auflösungen stellen lediglich eine Vervielfachung der Pixelanzahl dar, jedoch keine Änderung in den physikalischen Größen. Der Designer kann hier pixelgenaue Entwürfe erstellen. Für die Verwendung im Control-Styling und für Icons müssen dann jedoch sowohl Standard als auch Retina Auflösung zur Verfügung gestellt werden. Das Android Ökosystem hingegen ist stark fragmentiert. Smartphones rangieren von 3 Zoll Screens mit Auflösungen von 320x240 bis hin zu 4,7 Zoll Screens mit bis zu 1280x720 Pixeln. Android Tablets

214

Abb. 3. Papierprototyp der mobilen Applikation

4.1. Ausgangspunkt Ausgangspunkt für unsere Entwicklung war sowohl ein Desktop Client auf Microsoft Silverlight Basis, als auch eine mobile Applikation auf Microsoft Windows Mobile 6.5 Basis. Neu hinzukommen sollten Versionen für Android Smartphones und Tablets und iOS Geräte, die durch uns zu entwerfen waren. Idee des Kunden war es, konzeptuell auf jeder Zielplattform so nativ wie möglich aufzutreten. Hierzu zählte auch der Einsatz von Standard Controls, wenn immer möglich. Im Hintergrund sollte eine plattformübergreifende Engine abstrakte Konzepte in jeweils native UI Komponenten übersetzen. Wo nötig sollten für einzelne Plattformen Speziallösungen gefunden werden. Da die neuen Applikationen von Funktionsumfang mindestens der derzeitigen Mobilanwendung entsprechen sollten, erfolgte zunächst eine sorgfältige Analyse derselben. Hierzu wurde anhand eines Papierprototypen der Interaktionsfluss der mobilen Anwendung nachgestellt. [Abb. 3]


Usability Professionals 2012 User Experience

4.2. Abstrakter Tablet Master Um den Umfang der Applikation für die mobilen Plattformen im Gesamten festzulegen, wurden generische Tablet Wireframes angefertigt. Diese legten das plattformübergreifende, grundlegende Layout und den Funktionsumfang fest. Die Entwürfe sollen dabei die Szenarien und Prozesse der bestehenden Anwendung benutzergerecht in einem mobilen Tablet Kontext abbilden. Jedes Modul der Anwendung bildet in der Regel jeweils einen Prozess ab, der aus mehreren Schritten und Unterschritten bestehen kann. Die Reihenfolge muss jedoch nicht streng eingehalten werden, so dass man nicht von einem Wizard sprechen kann. Innerhalb eines Prozesses gliedert sich das Layout dann in drei Ebenen: Zum einen die Anzeige und Auswahl der Prozessschritte, eine Liste mit Elementen oder Optionen zum aktuellen Prozessschritt (Master) und eine Liste mit Optionen zum im Master ausgewählten Element (Detail). Teilweise können in einem Detail noch einmal Unteroptionen auftreten, welche dann in einem Overlay oder Flyout zur Verfügung gestellt werden. Das Design ist hauptsächlich durch Listen getrieben, die je nach Kontext zum Betrachten von Informationen oder zum Bearbeiten von Werten verwendet werden, um den zugrundeliegenden Prozess erfolgreich durchzuführen. [Abb. 4] 4.3. Überführung in konkrete Plattform Entwürfe Der abstrakte Master bildet den gesamten Funktionsumfang und die grundlegende Informationsstruktur der Anwendung ab. Die beschriebenen Probleme der ersten Kapitel bedurften einer individuellen Betrachtung jeder Plattform. Im Folgenden musste deshalb der abstrakte Entwurf in individuelle Entwürfe für

Abb. 4. Abstraktes Tablet Wireframe mit Prozessnavigation, Prozessschnitt-Master und Prozessschritt-Detail.

alle anvisierten Plattformen übersetzt werden. Für Android wurden sowohl Entwürfe für Version 2.3 als auch 4.0 angestrebt. Zunächst sollten dabei alle plattformspezifischen Designmuster und Best-Practices so berücksichtigt werden, als erfolge die Entwicklung nur für eine einzelne Plattform. Danach sollten die Entwürfe konsolidiert werden, indem Gemeinsamkeiten identifiziert und zu plattformübergreifenden Konzepten überführt werden. Unvereinbare Unterschiede sollten in Individuallösungen festgehalten werden. Für den Kunden war es wichtig, eigene Designrichtlinien zu definieren, die es ihm erlauben, bestehende Datenstrukturen jeweils in die für die Plattformen geeigneten Controls zu überführen, so dass diese wiederum den Design Richtlinien der Plattformen und deren Kriterien der Benutzbarkeit unterliegen. Im technischen Sinne würden die Richtlinien als Input für die plattformübergreifende Engine des Kunden herangezogen.

4.3.1. Zerlegung für Formfaktoren Sowohl für iPhone als auch Android mussten die komplexen Layouts des Tablet Masters zunächst in einzelne Views zerlegt werden. Während der Tablet Master bis zu drei Ebenen gleichzeitig anzeigt (Prozess, Master, Detail), kann der Smartphone Formfaktor zu jeder Zeit nur eine Ebene anzeigen oder zumindest nur modal zur Verfügung stellen. Für Android 2.3 und iPhone führten die Entwürfe zu ähnlichen Ergebnissen. Das Fehlen von Design Guidelines für Android 2.3 verlangte nach eigenen Lösungen, die sich an bestehenden Anwendungen orientierten. Die Hierarchien der Informationsarchitektur werden in den meisten Fällen durch Listen mit drill-down umgesetzt. Generell wird nur eine Ebene gleichzeitig angezeigt. Die anderen Ebenen sind über Navigationselemente in den Titelleisten, Tab oder Toolbars erreichbar.

215


Abb. 5. Zerlegung des Tablet-Wireframes in „Process“, „Master“ und „Detail“ für Smartphones am Beispiel von Android 2.3.

Vom Master aus ist die Navigation über Navigationselemente im Header erreichbar. Ein Custom Control erlaubt sowohl den direkten Wechsel zum vorherigen oder nächsten Prozessschritt, als auch den Sprung zur Prozessübersicht. Die Darstellung von Details zu einem einzelnen Element des Masters erfolgt im Drill-Down auf einen eigenen Screen. [Abb. 5] Für die Rückkehr zum Master muss auf dem iPhone ein „Zurück“ Button vorgesehen werden, während auf Android auf die entsprechende Hardwaretaste zurückgegriffen werden kann. In vielerlei Hinsicht stellt die mit Android 4.0 eingeführte „Action Bar“ einen Fortschritt für eine vereinheitliche Navigation innerhalb von Applikationen dar. Sie beinhaltet ein „Nach oben“ in der Informationsarchitektur, ein Dropdown um schnell zwischen Bereichen der Applikation zu wechseln, Kontext Aktionen über Icons und einen Menü Button als Ersatz für das Applikationsmenü vor Android 4.0. Das Konzept konnte von uns sehr sinnvoll

216

Abb. 6. Action Bar zur Prozessnavigation in Android 4.0.

zur Optimierung der Android Entwürfe eingesetzt werden. Die Prozessnavigation wurde in das Dropdown gelegt und bedarf nun keines eigenen Screens mehr. Zusätzlich wurden Icons in der Bar zum direkten Wechsel auf den vorherigen oder nächsten Prozessschritt gelegt. Das Applikationsmenü wird vollständig im Menü Control der Action Bar verankert. Konzeptuell haben sich damit iPhone und Android Applikation voneinander entfernt, jedoch profitiert der Android Benutzer sehr stark vom eigenständigen Konzept. [Abb. 6] Wenig problematisch stelle sich die Überführung der abstrakten Entwürfe in konkrete Designs für das iPad und Android Tablets dar. Unterschiede ergaben sich hier vor allem in der Verwendung von Toolbars auf dem iPad und der Action Bar auf den Android Tablets. Die grundsätzliche Struktur und das dreispaltige Layout sind auf beiden Plattformen gut umsetzbar.

4.3.2. Konzeptuelle Eigenheiten anhand von Listen und Gesten Das Anzeigen und Ausführen von Aktionen auf Listenelementen in Android 2.3 erfolgt standardmäßig über eine „TapAnd-Hold“ Geste, z. B. für „Löschen“ oder „Abbrechen“. Die Menü Hardwaretaste wird eingesetzt, um elementübergreifende Aktionen durchzuführen, wie z. B. „Hinzufügen“. Sie ruft das Applikationsmenü am unteren Bildschirmrand auf. Um Aktionen auf mehreren Elementen durchzuführen, muss in einen Bearbeiten oder Mehrfachselektionsmodus gewechselt werden. Der Wechsel erfolgt bei uns explizit über das Applikationsmenü. Elemente können dann mittels Checkboxen ausgewählt werden und die Aktion wird über das Menü für alle selektierten Elemente ausgeführt. „Tab-And-Hold“ ist eine auf iOS selten anzutreffende Interaktionsform. Für Elementoptionen werden z. B. Toolbars, Bearbeiten-Modi oder Disclosure verwendet. Da auf den Elementen weiterhin ein DrillDown möglich sein soll, haben wir uns für einen Disclosure Button entschieden. Ein


Usability Professionals 2012 User Experience

„Options“ Button wird für elementübergreifende Aktionen vorgesehen. Für die Mehrfachselektion ist das Verhalten analog zu Android umgesetzt. Der Moduswechsel erfolgt über das Optionsmenü. Die Aktion wird über eine Toolbar ausgewählt. Für iOS müssen also wieder mangels Hardwaretasten einige zusätzliche Interface Elemente eingesetzt werden, die dann auch sinnvoll in Navigation- und Titelleisten untergebracht werden müssen, oder eigene Leisten benötigen. Während die zuvor beschriebenen Optionen zwar jeweils anders ausgelöst und im UI anders dargestellt werden, sind sie konzeptuell ähnlich und es lassen sich für beide Regeln definieren, um sie aus einer gemeinsamen Datenbasis herzuleiten. Android 4.0 führt jedoch ein eigenes Konzept für Selektion und Kontextoptionen ein. Die „Tab-And-Hold“ Geste wird nicht mehr im Android 2.3 Sinne verwendet, sondern um in einen Selektions-Modus zu wechseln, welcher dann für alle selektierten Elemente eine eigene Toolbar zur Verfügung stellt. Möchte man sofort zugängliche Elementoptionen anbieten, so muss bei Drill-Down auslösenden Elementen auch bei Android 4.0 ein Disclosure Button vorgesehen werden. Ein solches Listenelement erhält dann einen Dropdown Marker in Form eines Rechteckes am rechten Rand. Elementübergreifende Aktionen werden über Icons in der „Action Bar“ und deren Menü ausgelöst. [Abb. 7]

implementiert. RhoMobile sieht hierzu standardmäßig den Einsatz des jQuery Mobile Frameworks vor. [4] Um eine möglichst native User Experience zu generieren, sollen die im Entwurf identifizierten konzeptionellen Unterschiede weiterhin Berücksichtigung finden. 5.1. Cross-Plattform Ansätze Während native Ansätze der individuellen Entwicklung mit den Sprachen der Plattformen bedürfen, verfolgen die meisten Cross-Plattform Ansätze eine Entwicklung mit Web-Technologien. Das Spektrum reicht von Cross-Compiling aus JavaScript in native Sprachen, über Back-End Systeme mit Python oder Ruby bis zu reinen Web-Apps, bei denen das Layout über HTML erfolgt, das Styling über CSS und die Logik mit JavaScript definiert wird. Weiterhin sind hybride Apps inzwischen verbreitet, die native Komponenten mit WebViews mischen, um dokumentennahe Teilbereiche der Applikation durch HTML zu generieren. Ein bekannter Vertreter ist hier die Facebook App.

Cross-Compiling Lösungen wie Titanium erlauben es zudem, die nativen Programmiersprachen und Frameworks durch plattformfremde Technologien zu ersetzen, jedoch ein natives UI zu generieren und damit im Fortgang auch die Kultur der Plattform zu ehren. Die Entwicklung macht sich hier jedoch abhängig von der Qualität und den Fähigkeiten der Drittanbieterlösung. Insbesondere ist es für Designer ohne Kenntnisse des Frameworks nicht transparent, wie anpassbar die generierten Controls sind und welche UI Komponenten sich tatsächlich nativ umsetzen lassen. [5] Sencha Touch und jQuery Mobile sind rein browserbasierte Ansätze, bei denen sowohl GUI als auch Logik in einer WebView laufen. Lösungen wie Phonegap schließen die Brücke der WebView zur eigentlichen Device-Logik, um über HTML5 und JavaScript auf Gerätehardware und native Schnittstellen zurückzugreifen. RhoMobile verwendet als Brücke zur nativen Welt eine eigene Serverkomponente, die auf dem Gerät läuft und Daten an eine WebView ausliefert. Das Front-End kann mit HTML und JavaScript oder gar mit jQuery Mobile oder Sencha Touch gestaltet werden.

5. Cross-Plattform Das in der Case-Study beschriebene Konzept einer nativen Anwendung für jede Plattform, mit einer übergreifenden LogikSchicht sollte im Folgenden mit einer auf HTML5 basierenden Cross-Plattform Lösung verglichen werden. Der Kunde erwog hierzu die Umsetzung mittels RhoMobile. Die übergreifende Logik würde damit in einem Ruby Backend umgesetzt. Das Frontend würde ausschließlich mit Web-Technologien auf HTML5 und JavaScript Basis

Abb. 7. „Tab-and-Hold“ (Links) öffnet ein Vollbild-Overlay (Mitte) auf Android 2.3 mit Kontext-Aktionen. Das Kontext-Menü wird über ein Disclosure Element in Android 4.0 geöffnet (Rechts).

217


HTML5 basierte Lösungen haben nur begrenzte Möglichkeiten Formfaktoren, Displaygrößen, Auflösungen und Pixeldichten zu berücksichtigen. JavaScript und auslösungsabhängige Stylesheets können analog zum Response Webdesign herangezogen werden, um die Anwendung anzupassen. Einzig der Android Browser bietet zusätzliche Möglichkeiten zur Evaluation der Bildschirmdichte. Auf keiner der beschriebenen Plattformen können die Hardware Tasten in einer reinen Web-App verwendet werden. Im Android Browser ist lediglich die Navigation in der URL Historie mittels „Zurück“ Taste möglich. Bei einer AJAX-getriebene Anwendung ist ein Einsatz in diesem Sinne nicht unmöglich. Erst die Kapselung als Native App durch beispielsweise PhoneGap oder RhoMobile erlaubt den Zugriff. Um beim Benutzer keine Verwirrung zu stiften, müssen die Tasten in jedem Fall plattform- und betriebssystemabhängig korrekt unterstützt werden. Hingegen müssen „Menü“ und „Zurück“ bei Fehlen der korrespondierenden Taste über Controls im UI zugänglich sein. Im Sinne einer nativen Anwendung hat iOS zumindest für das „Zurück“ das feste Konzept des „Back Buttons“ im Header. [7]

lauffähig. Jedoch werden die Anmutung, die Anordnung von Tabbars oder die Anwesenheit eines „Back“ Buttons bei Android Benutzern eine FremdkörperWahrnehmung hervorrufen. Kein Problem stellt dies sicherlich bei immersiven Applikationen, wie z. B. Spielen dar, da solche eigene Welten erschaffen in die der Benutzer eintaucht. Standard Controls oder Plattform Paradigmen werden hier nur in den seltensten fällen eingesetzt. So besteht von Benutzerseite auch keine Erwartungshaltung diesbezüglich. 6.1. jQuery Mobile Das unter anderem von RhoMobile nahe gelegte JQuery Mobile Framework verfolgt aus Entwicklersicht einen klassischen Ansatz des Webs. Ein beliebiges Back-End generiert HTML Code, der die Inhalte der Applikation definiert. Das JavaScript Framework generiert aus dem HTML Gerüst eine touch-freundliche Oberfläche. Das Styling der Oberfläche erfolgt mit CSS.

Der ausschließliche Einsatz von nativen Frameworks und Design-Richtlinien kann zumindest eine grundlegend Benutzbarkeit und das schnelle Zurechtfinden des Benutzers begünstigen.

Die Umsetzung von Prototypen oder gar Anwendungen ist für viele Designer mit wenigen HTML und JavaScript Kenntnissen nach kurzem Studium der Dokumentation möglich. Zusätzlich existieren am Markt bereits visuelle UI Builder wie z. B. Codiqa (http://www.codiqa.com/), mit welchen sich jQuery Mobile UIs innerhalb kürzester Zeit definieren lassen. [Abb. 8] 6.2. Sencha Touch Sencha Touch geht im Vergleich zu jQuery Mobile einen anderen Weg: die Definition des UIs erfolgt über deklaratives JavaScript. Das Framework generiert dann zur Laufzeit passend dazu ein HTML Gerüst. Das Styling erfolgt jedoch auch hier mit CSS. Sencha Touch bringt dabei teils eigene und teils nachgeahmte Controls mit (Abb. 9). Diese sind stark an die nativen Komponenten von iOS angelehnt. Die Interaktionskonzepte sind ebenfalls denen von iOS ähnlich. Am augenscheinlichsten sind hier Navigationsbars, Tabbars, Toolbars, Action Sheets und Picker. Die Controls haben standardmäßig jedoch „mattes“ Styling. Dadurch entsteht der Eindruck eines eigenen Look&Feels für native iOS Standardcontrols. Insgesamt wirkt Sencha Touch auf iOS vertraut, auf Android damit jedoch fremd. Es kann der falsche Eindruck einer unangepassten Portierung von iOS entstehen. Vor allem Navigationbars mit „Back“ Button und die Anmutung und Anordnung von Tabbars stehen im Widerspruch zu Android Designprinzipien, falls die Controls unangepasst verwendet werden.

Hingegen erlaubt PhoneGap es beispielsweise nur, Webtechnologien in einen nativen Container zu verpacken, ohne Zugriff zu nativen UI Komponenten zu erhalten. Das User Interface muss hier mit HTML, CSS und JavaScript implementiert werden und kann höchsten die Kultur der Plattform nachahmen, jedoch niemals vollständig abbilden. Der cross-platform Ansatz erlaubt im Prinzip das Ausrollen einer einheitlichen Applikation auf allen Plattformen. So ist eine auf Basis der iOS Richtlinien entwickelte WebApp ohne weiteres auf Android Geräten Abb. 8. Einige jQuery Mobile Controls

218

jQuery Mobile orientiert sich dabei kaum an nativen UIs. Es bietet eigene Controls mit eigenem Stil (Abb. 8). Weder iOS noch Android Elemente werden nachgeahmt. Hieraus ergibt sich ein eigenes Kulturverständnis für „native“ jQuery Mobile Anwendungen. Solche Applikationen werden zwangsläufig als plattformfremd wahrgenommen. Positiv daran ist, dass keine falsche Erwartungshaltung beim Benutzer hervorgerufen wird.


Usability Professionals 2012 User Experience

wird, welche Elemente welches Feedback liefern, wie das UI animiert ist, wie das Scroll-Verhalten definiert ist, wie Daten manipuliert werden, welche Gesten zur Verfügung stehen und so weiter. Insgesamt können diese Erwartungshaltungen höchstens Ansatzweise erfüllt werden. Alleine visuelle Ungenauigkeiten, die beim Nachbilden der nativen Controls unvermeidbar sind, werden zwangsläufig den Qualitätseindruck der Anwendung verschlechtern.

Abb. 9. Sencha Touch Controls erinnern stark an die nativen Controls von iOS

Die Entwicklung eines interaktiven und animierten Prototypen für die Case-Study mit Hilfe von Sencha Touch hat sich als sehr produktiv herausgestellt. Die Arbeit mit JavaScript und HTML sollte für die meisten Web-Designer keine fremde Welt darstellen. Das Styling mit CSS3 führt zu schnellen Ergebnissen. Inzwischen bietet Sencha Touch mit Sencha Architect ebenfalls einen eigenen GUI Builder. [Abb. 9] 6.3.1. Performance Am Beispiel von Sencha Touch zeigt sich jedoch auch, dass vor allem auf Android Devices noch massiver Nachholbedarf seitens der Browserperformance für HTML5 Anwendungen besteht. Komplexe Anwendungen können hier derzeit unmöglich eine native Performance und Responsivität erreichen. In unseren eigenen Tests, vor allem mit Geräten der Mittelklasse, ergaben sich selbst beim Einsatz von lediglich lokalen Daten bereits spürbare Verzögerungen des UIs. Auf iOS Geräten neuerer Generation (iPhone 4, iPad 2) konnten wir eine subjektiv akzeptable Responsivität feststellen. Beim Scrollen von langen Listen mit vielen Einträgen ergeben sich leider dennoch kleinere Verzögerungen.

Selbst cross-platform Framworks, die ein teilweise natives UI generieren, sind nicht vor Performance Problemen gefeit. So hat die bekannte und mit Titanium entwickelte „Wunderlist“ App ihre Android Version Ende 2011 von Grund auf neu als native Android App entwickelt. Gründe hierfür waren unter anderen eine ungenügende Performanz und Responsivität. [8] [9] 6.3.2. Konzeptuelle Fallstricke Da in reinen HTML5 Lösungen die Verwendung von nativen UI Komponenten ausgeschlossen ist, besteht die Möglichkeit diese zumindest visuell nachzuahmen. Eine HTML basierte Toolbar oder ein Button sieht so z. B. auch wie die entsprechenden nativen Komponenten des iOS AppKit Frameworks von Apple aus. Eingebettet in Listen und Tabellen, die alle jeweils einen nativen Anstrich erhalten haben, wird dem Benutzer praktisch ein natives iOS UI vorgeschwindelt. Eine solche Erscheinung erweckt automatisch eine auf den Erfahrungen mit nativen Applikationen beruhende Erwartungshaltung: Wie responsiv die App sein

Martin Fowler beschreibt dies als das aus der Robotik und Animation bekannte Phänomen des „Uncanny Valley“. Eine Applikation, die nahezu so aussieht wie eine native und sich ähnlich verhält, jedoch ein letzter Zweifel übrig bleibt, ruft beim Betrachter oder Benutzer eine überproportionale negative Reaktion hervor. [10] [Abb. 10] Als Design-Prozess zur Entwicklung hybrider Applikationen wäre ein Weg des kleinsten gemeinsamen Nenners denkbar. Dabei werden das UI und die Benutzererfahrung auf Controls und Konzepte beschränkt, die auf allen angestrebten Plattformen vertreten sind. Eventuell reduziert man sogar auf zwei Apps, jeweils für eine Smartphones und für Tablets. Die jeweiligen Entwürfe werden dann konsolidiert. Das Konzept einer portablen Applikationen ist heute faktisch die Grundlage jeder reinen Web-App. Im mobilen Kontext wird letztendlich damit jedoch die User Experience auf allen Plattformen eingeschränkt. Im Prinzip wird eine Applikation entwickelt, die es versucht, es allen recht zu machen aber niemanden vollends befriedigt. Es stellt sich die Frage, ob überhaupt ein angemessener Mittelweg zu finden ist. Vorstellbar ist es, ein eigenes Design für jede Plattform zu entwickeln, welches die plattformspezifischen Gegebenheiten und Design Muster berücksichtig, ohne als „Copycat“ aufzutreten. Hierzu gehören die Informationsarchitektur der App, das Interaktionsdesign und die grundsätzliche Verwendung von Controls sowie der

219


Abb. 10. Wie das „uncanny valley“ im Bereich cross-platform App Design aussehen könnte.

generelle visuelle Stil der Applikation und der Einsatz von Hardware Tasten zum Aufruf von App Funktionen. Optimiert man eine Applikation stark auf den Use-Case und fügt den nativen Mustern dafür eine ganze Reihe eigener Konzepte hinzu, entstehen zwangsläufig plattformübergreifende Konzepte. Gepaart mit einem eigenen, jeweils plattformspezifischen visuellen Design, das die entsprechende Designsprache nicht ignoriert, sondern weiter entwickelt, kann durchaus eine robuste User Experience entstehen. Die Frage ist, ob eine solche Lösung kostengünstiger als eine rein native multi-platform Entwicklung zu implementieren ist. Und wenn nicht, wie dann der cross-platform Ansatz noch zu begründen wäre.

220

7. Fazit Sowohl die aufgeführte Case-Study aus Design Sicht als auch die beschriebenen technischen Rahmenbedingungen und Limitierungen machen klar, dass CrossPlattform Design und Entwicklung heute eine enorme Herausforderung darstellen.

Browser und technologischen Brücken zwischen HTML5, Javascript und nativen Schnittstellen. Jedoch befreit dies nicht von einer sorgfältigen Analyse der einzelnen Plattformkulturen, Paradigmen und Muster.

Die Diversifizierung der mobilen Landschaft hat viele miteinander konkurrierende native Technologien, Design Richtlinien und Plattformkulturen hervorgebracht. Das Ziel einer bestmöglichen User Experience kann nur erreicht werden, indem jede gewünschte Zielplattform im Einzelnen berücksichtigt wird.

Trotz aller Abstraktionsmöglichkeiten in der Informationsarchitektur und im Interaktionsdesign müssen für jede Plattform die passenden Layouts, Controls und Gesten verwendet werden. Alleine die Unterschiede zwischen iOS und Android verbieten die Vorstellung einer einfachen Anpassung mittels Stylesheets oder ähnlichem, denn es ist nicht nur die oberflächliche Erscheinung, die dem Benutzer das Gefühl gibt zuhause zu sein.

Cross-Plattform „Lösungen“ gibt es nicht. „Code-Once, Deploy-Everywhere“ ist heute technisch kein Problem mehr, dank der umfangreichen Fähigkeiten modernen

Im Idealfall steht hinter jeder Version einer Applikation ein eigenes sorgfältig durchdachtes Design und plattformspezifischer Code.


Usability Professionals 2012 User Experience

Literatur 1. [1] IDC. (2012, Juni) Android Expected to Reach Its Peak This Year as Mobile Phone Shipments Slow. [Online]. http://www.idc. com/getdoc.jsp?containerId=prUS23523812 2. [2] Apple Inc. (2012, M채rz) iOS Human Interface Guidelines. [Online]. http://developer.apple.com/library/ ios/#documentation/userexperience/ conceptual/mobilehig/Introduction/ Introduction.html 3. [3] Google Inc. Android Design Guidelines. [Online]. http://developer.android.com/ design/index.html 4. [4] Motorola Inc. (2012) RhoMobile Suite. [Online]. http://www.rhomobile.com 5. [5] Appcelerator Inc. (2012) Titanium SDK. [Online]. http://www.appcelerator.com/ platform/titanium-sdk 6. [6] Sencha Inc. (2012) Sencha Touch. [Online]. http://www.sencha.com/products/touch 7. [7] jQuery Foundation. (2012) jQuery Mobile. [Online]. http://jquerymobile.com/ 8. [8] 6 Wunderkinder. (2011, September) Wunderlist for Android? Rebuild, relaunched and really awesome! [Online]. http:// www.6wunderkinder.com/blog/2011/09/05/ wunderlist-for-android-rebuilt-relaunchedand-really-awesome/ 9. [9] Manuel Gomes. (2011, September) Wunderlis for Android going native, drops Appcelerator Titanium Mobile. [Online]. http://www.tryexcept.com/ articles/2011/09/12/wunderlist-for-androidis-going-native-drops-appcelerator-titaniummobile.html 10. [10] Martin Fowler. (2012, Juni) Developing Software for Multiple Mobile Devices. [Online]. http://martinfowler.com/articles/ multiMobile/

221


Multiscreen Experience Design Prinzipien, Muster und relevante Faktoren für die Konzeption und Strategieentwicklung von Multiscreen Projekten Wolfram Nagel digiparden GmbH Oberbettringer Straße 15 73525 Schwäbisch Gmünd wn@digiparden.de

Abstract Die Gerätelandschaft wird immer dynamischer, fragmentierter und vernetzter. Deshalb müssen Informationen und Services zukünftig auf möglichst allen (relevanten) Screens und Ausgabekanälen verfügbar sein und geräteübergreifend funktionieren. Kurz- und mittelfristig stehen dabei vier Gerätekategorien im Fokus: Desktop-PCs, Tablets, Smartphones und Smart TVs. Der Beitrag zeigt worauf es ankommt und gibt Empfehlungen, die man bei der Konzeption von Multiscreen Projekten und der Entwicklung einer passenden Content Strategy berücksichtigen sollte. Es wird aufgezeigt wie sich die verschiedenen Screens sinnvoll miteinander kombinieren lassen, wie man die unterschiedlichen Nutzer berücksichtigt und wie wichtig und unterschiedlich der jeweilige Nutzungskontext ist.

1. Status Quo „Multi-screen is not a value-add any more; consumers expect products and service to work seamlessly across all their devices.“ (Gabriel White, Small Surfaces) 1.1. Herausforderungen im Informationszeitalter Die Gerätelandschaft wird immer dynamischer, fragmentierter und vernetzter. Deshalb müssen Informationen und Services zukünftig auf möglichst allen (relevanten) Screens und Ausgabekanälen verfügbar sein und geräteübergreifend funktionieren. Zusammen mit dem Designer Valentin Fischer habe ich im Rahmen des „Multiscreen Experience“ Projekts verschiedene Muster, Prinzipien, Methoden und Ansätze zusammengetragen und weiterentwickelt, die man bei der Konzeption von

Keywords: /// Multiscreen /// User Experience /// Service Design /// Content Strategy /// Informationsarchitektur

Multiscreen Projekten berücksichtigen sollte. In diesem Beitrag stelle ich auszugsweise einige davon vor. Die drei relevanten Faktoren sind die (vier) Screens bzw. Geräte (und deren Kombinationsmöglichkeiten), die Nutzer und der jeweilige Nutzungskontext.

2. Vier Screens Im Fokus stehen Smartphone, Tablet-PC, Laptop bzw. Desktop-PC und SmartTVs.

1.2. Definition Multiscreen

Die vier Screens bzw. Geräteklassen lassen sich einteilen und definieren über den Nutzungskontext, die Art und Weise wie mit dem Gerät interagiert bzw. navigiert wird, über die Haupt-Eingabemethode (z. B. Fernbedienung, Gesten, Maus, Tastatur, (Multi-)Touch, Sensoren, Ziffernblock, Minitastatur), die durchschnittliche Displaygröße des Screens und die typische Entfernung zwischen User (Augen) und Screen. Zwei Beispiele: Ein typischer Nutzungskontext des TV-Geräts ist das Wohnzimmer. Die Entfernung vom User zum relativ großen Bildschirm des TV-Geräts ist wesentlich größer als zum kleinen Smartphone-Bildschirm.

Für den Begriff Multiscreen gibt es keine offizielle Definition (http://bit.ly/msxdefblog). Allgemein bedeutet Multiscreen, dass der Anwender mindestens zwei verschiedene Screens bzw. Endgeräte für eine oder während einer Tätigkeit nutzt. Eine Multiscreen Anwendung ist mit verschiedenen Endgeräten nutzbar und somit Cross Device-fähig. In einem Multiscreen Szenario werden mehrere Endgeräte oder Bildschirme (und damit auch Informationsangebote) gleichzeitig genutzt. [siehe Abb. 1]

2.1. Geräteklassen

Abb. 1. Digitale Gesellschaft (2012): Zunehmende Gerätefragmentierung und Parallelnutzung. Informationen muss man zukünftig für verschiedene Screens anbieten. Vier Geräteklassen stehen im Fokus: Smartphone, Tablet-PC, Laptop bzw. Desktop-PC und internetfähiges TV-Gerät (Smart TV). „iPad“, „iPhone“, „Laptop“ by thenounproject.com; „Fernseher“ by Ally Noormohamed from thenounproject.com

222


Usability Professionals 2012 User Experience

Abb. 3. Es gibt verschiedene Möglichkeiten mehrere Endgeräte bzw. Screens miteinander zu kombinieren. *Die Muster basieren auf den Multiscreen Patterns von Precious Design Studio aus Hamburg.

Abb. 2. Typische durchschnittliche Entfernung zwischen User (Augen) und Bildschirm

2.2. Entfernungen zwischen User und Screen Bei jeder der vier Geräteklassen hat der User eine typische durchschnittliche Entfernung. [siehe Abb. 2] 2.3. Screens kombinieren Es gibt verschiedene Möglichkeiten mehrere Endgeräte bzw. Screens miteinander zu kombinieren (http://bit.ly/msxthmm). Die Screens können parallel benutzt oder Informationen müssen zwischen den Geräten synchronisiert werden (z. B. mit Hilfe von Dropbox). Die Screens können sich auch gegenseitig steuern (zum Beispiel wenn das Smartphone als TV-Fernbedienung genutzt wird) oder Informationen austauschen, indem Informationen zwischen zwei oder mehreren Screens hin und her geschoben werden (mit AppleTV und AirPlay lassen sich beispielsweise Videos vom kleinen Screen des iPhones oder iPads auf den großen TV-Bildschirm schieben). [siehe Abb. 3]

3. Nutzer(typen) “People use any platform to do anything.“ (Giles Colborne) 3.1. Nutzer verstehen Damit Informationen und Applikationen den (Multiscreen-) Tagesablauf begleiten anstatt ihn zu dominieren, sollte man bereits im Entwurfsprozess die Bedürfnisse und Verhaltensmuster von Benutzern berücksichtigen. Multiscreen Experience Design ist Service Design für Nutzer mehrerer und verschiedener Endgeräte. Es ist wichtig die Tagesabläufe der Zielgruppe und die Device Touchpoints zu kennen, d. h. zu wissen mit welchen Geräten die Anwender wann, warum, wie und in welchem Umfang in Kontakt kommen. Für optimale Ergebnisse sollte man bereits im Entwurfsprozess die Umfelder, Bedürfnisse, Motive und Verhaltensmuster von Benutzern berücksichtigen. Um den (initialen) Prozess der Zielgruppendefinition zu vereinfachen, haben wir im Rahmen unseres Projekts ein Multiscreen Experience Toolkit (www.multiscreen-experience.

com) entwickelt, in dem unter anderem acht prototypische Personas der Digitalen Gesellschaft beschrieben werden – repräsentativ für die gesamte Bevölkerung in Deutschland (vom total vernetzten Multiscreener bis hin zum digitalen Außenseiter). Die Personas basieren auf den Nutzertypen der Studie „D21 – Die Digitale Gesellschaft“ (http://bit.ly/id21pub) und fokussieren unter anderem die Bereiche Medienaffinität, Gerätenutzung, Nutzungskontext und Nutzerbedürfnisse. Diese Personas (http://bit.ly/msxpersonas) können als Einstieg in ein Projekt dienen und sollten im Optimalfall an die jeweiligen Projektanforderungen angepasst werden. Auf Basis von Research Ergebnissen und im Abgleich mit evtl. bestehenden Persona-Prototypen sollte man die relevanten Personas identifizieren um die Devicepriorität abschätzen und letztlich (primär) für die (relevanten) Geräte konzipieren, gestalten und entwickeln zu können. [siehe Abb. 4], [siehe Abb. 5] 4. Nutzungskontext Der Nutzungskontext wird neben dem Anwender und dem verwendeten

223


Endgerät durch drei weitere Parameter beeinflusst. [siehe Abb. 6] 4.1. Kontextrelevanz Ein Informationsangebot sollte stets zur Situation, dem Umfeld, dem Anwender und dem Gerät und somit zum Nutzungskontext passen – also die richtige Information zur richtigen Zeit liefern (Kontextrelevanz). Die Inhalte einer Website, die mit einem Laptop aufgerufen werden, müssen auf einem Smartphone ganz anders aussehen, weil sich der Anwender in einem komplett anderen Nutzungskontext befindet und völlig andere Anforderungen an die Informationen hat.

Abb. 4. Der Fokus bei den Persona-Prototypen liegt auf Medienaffinität, Gerätenutzung, Nutzungskontext und Nutzerbedürfnissen

4.2. Die Parameter im Nutzungskontext Der Nutzungskontext wird neben dem Anwender und dem verwendeten Endgerät durch die Parameter Nutzungsmodus (Lean Back oder Lean Forward), Situation (stationär oder mobil) und Umfeld (Privat, Arbeitsplatz, öffentlicher Raum, unterwegs) bestimmt. Im Lean Back Modus beispielsweise ist der Anwender vorwiegend entspannt und passiv. Er lässt sich berieseln. Öffentlicher Raum ist grundsätzlich für jedermann zugänglich. Die Situation ist nicht privat. Aus dieser Erkenntnis kann man je nach Projekt den Schluss ziehen, dass Anwender in diesem Umfeld beispielsweise keinen Audio-Output wünschen oder Sprache ungern als Input-Methode benutzen wollen, weil es ihnen unangenehm oder grundsätzlich verboten sein kann.

Abb. 5. Chris Kulig, Trendnutzer (35 Jahre, ledig, Eventmanager, Mittlere Reife und Ausbildung)

4.3. Sonderfall: Mobiler Nutzungskontext Nutzungskontexte sind sehr vielfältig und unterschiedlich. Ein Sonderfall ist der mobile Nutzungskontext – nicht zu verwechseln mit einer mobilen Situation. Der mobile Nutzungskontext (d. h. die Situation und das Umfeld, in denen ein mobiles Endgerät genutzt wird) ist keinesfalls nur unterwegs (was für eine mobile Situation Abb. 6. Der Nutzungskontext wird neben dem Anwender und dem verwendeten Endgerät durch die Parameter Nutzungsmodus, Situation und Umfeld beeinflusst.

224


Usability Professionals 2012 User Experience

zutrifft). Er ist quasi unvorhersehbar und kann überall auftreten: Das iPad wird als Kochbuchersatz in der Küche genutzt, das Smartphone ist auf der Couch während dem Fernsehen quasi ständig parat und die Handynutzung während dem Radfahren ist auch nicht ganz ungewöhnlich (Beispiel für eine typische „Mobile Situation“). Außerdem kann ein mobiles Endgerät als Schnittstelle zum Auto-Interface genutzt werden. Oft, und vor allem weil Anwender teilweise ausschließlich mit dem mobilen Endgerät auf Informationen zugreifen, ist es notwendig, dass auch auf den kleinen mobilen Geräten der komplette Funktionsumfang zur Verfügung steht und nicht nur eine extrem abgespeckte Variante angeboten wird. „Don’t cut content or features just because people happen to be on a small screen.“ (Cennydd Bowles, http://bit.ly/twjc120417) 4.4. Verhaltensmuster Im mobilen Nutzungskontext gibt es fünf typische Interaktions- und Verhaltensmuster. Man kann kleinere Aufgaben erledigen (Micro-tasking mit Evernote, E-Mails checken, SMS, Skype), eine wiederholende Tätigkeit ausführen (Statusupdate einholen, z. B. von einem Sport-Liveticker, Börsenkurse, Wetter) oder aus Langeweile, in einer Warteschlange oder in der Freizeit Ablenkung suchen (Zeit tot schlagen, im Internet surfen, Social Networking, Spiele). Häufig sind in einer typischen mobilen Situation ortsbezogene Informationen wichtig (ÖNV-Fahrplan, Routenplaner). In manchen Fällen braucht man dringend eine Information oder muss eilig etwas erledigen (Notiz machen, die man sonst vergessen würde). (oreil.ly/clarktapworthy und bit.ly/googlemobileux) 5. Konzeption und Strategie Es gibt verschiedene Ansätze für die Konzeption und Strategieentwicklung von Multiscreen Projekten.

5.1. Mobile First

quasi „gemeinsam fernsehen“ und Sendungen bewerten können.

Studien zufolge wird zukünftig hauptsächlich mit mobilen Endgeräten auf internetbasierte Services zugegriffen (http:// bit.ly/mobvsdesk1005 und http://bit.ly/ Hi5DmO). Daher macht es Sinn nach dem Prinzip Mobile First (http://bit.ly/mobfirst) vorzugehen und deshalb Konzept und Layout zuerst für das wichtigste Gerät zu entwickeln bzw. primär auf den kleinen Screen auszurichten. Ein positiver Nebeneffekt ist, dass man auf kleinen Screens (typische Eigenschaft mobiler Endgeräte) wesentlich weniger Platz hat um Inhalte anzuordnen. Deshalb sind mobile Informationsangebote meistens fokussierter und besser an die Nutzerbedürfnisse angepasst.

5.3. Device Shifting

5.2. Simultannutzung Unterschiedliche Endgeräte oder Informationsangebote werden heutzutage häufig gleichzeitig genutzt. In Deutschland surft mittlerweile jeder zweite Fernsehzuschauer parallel zum Fernsehen im Internet (Stichwort „Second Screen“ oder „Social TV“). (http://bit.ly/tvonlineparallel2011) Die Informationen auf den beiden Screens können sich gegenseitig ergänzen. Auf dem Second Screen lassen sich Zusatzinformationen anzeigen. Weitere nützliche Optionen für parallel genutzte Geräte sind Microblogging, ein Chat oder Ticker als ergänzender und paralleler Info-Stream. Beispiel Social TV: User können während des Fernsehens miteinander kommunizieren und sich über eine Sendung unterhalten. Durch Nutzerprofile werden den Usern entsprechende Vorschläge für potentiell interessante Sendungen unterbreitet. Unter anderem werden Sehgewohnheiten, persönliche Vorlieben, das Nutzerverhalten von Netzwerkfreunden und die verwendeten Geräte ausgewertet. Eigentlich war Fernsehen aber schon immer sozial. In Social TV-Konzepten wird die frühere Familiensituation eigentlich nur emuliert. Couchfunk oder TunedIn sind typische Second Screen Apps, mit denen die User

Die Anzeige von Inhalten oder Informationen lässt sich von einem auf ein anderes Gerät verschieben. Dabei wird die Darstellung zwischen den beteiligten Screens umgeschaltet. Der Vorteil für die Anwender ist, dass sie die Informationen auf dem bevorzugten Device darstellen können (stets passend zum Nutzungskontext) und sie dadurch sehr flexibel in der Informationsaufnahme bleiben. Device Shifting ist auch im Zusammenhang mit zeitversetzter Information relevant. Wenn man beispielsweise während der Arbeit oder unterwegs einen interessanten Artikel oder ein Video findet, kann man ihn/es sich für später bookmarken (Watch / Read Later) und zu einem geeigneten Zeitpunkt weiter lesen oder zu Ende schauen. 5.4. Synchronisation Adobe Plattform Evangelist Serge Jespers wünscht sich wie viele Fans von Casual Games eine bessere Synchronisation populärer Multiscreen Applikation: „Ich habe Angry Birds auf meinem Smartphone und auf meinem Tablet installiert. Aber die beiden sind nicht miteinander verbunden. Wäre es nicht großartig, wenn man einfach die App auf seinem Tablet öffnet und auf demselben Level weiterspielt, den man zuvor auf seinem Smartphone erreicht hat? Um dann vielleicht wiederum auf dem Desktop im selben Level weiter zu spielen? Oder am Fernseher?“ lamentierte er vor einiger Zeit in seinem Artikel „Think multiscreen“ (http://bit.ly/jespersthkms). Wie Jespers erwarten Anwender, dass die identischen Informationen oder Daten jederzeit und überall, mit unterschiedlichen Endgeräten abgerufen und bearbeitet werden können. Sinnvolle Multiscreenund Cross Platform-Services sind ohne Cloud Computing und Data Sharing nicht denkbar. Je besser verschiedene Services, Software und Datenformate miteinander

225


kombiniert und je einfacher und effizienter Informationen zwischen verschiedenen Systemen ausgetauscht werden können, je besser (Interoperabilität). Wenn Daten regelmäßig synchronisiert bzw. deren Status abgeglichen werden, sind die Nutzer unabhängig(er) von Gerätetyp, Zeitpunkt oder Ort. Ein perfektes SynchronisationsSzenario ist bislang allerdings nur schwer realisierbar, weil die technischen Anforderungen anspruchsvoll sind. Selbst wenn die Anwendung alle erforderlichen Funktionalitäten mitbringt, kann die Synchronisation immer noch an mangelnder Netzabdeckung scheitern. In Zusammenhang mit Synchronisation und Cloud-Computing muss man natürlich auf das Thema Datenschutz hinweisen, das von vielen Anbietern bislang (noch) nicht zufriedenstellend gelöst bzw. kommuniziert wird. 5.5. Kohärenz Die Anwender erwarten (unbewusst), dass ein Informationsangebot auf jedem Endgerät ähnlich funktioniert. Damit sie ein Interface auf allen Geräten verstehen, sollten sie es möglichst intuitiv bedienen können. Es muss nicht identisch, aber ähnlich sein. Daher ist es wichtig, dass Inhalte auf den teilweise sehr unterschiedlichen Geräten und Bildschirmen möglichst verständlich, schlüssig und visuell stimmig dargestellt und gleichzeitig kontext- und nutzungsrelevant angeboten werden. Netflix, Evernote oder mittlerweile auch Facebook haben diese Herausforderung ordentlich gelöst. 5.6. Fluid Experience Anwendungen müssen nicht auf allen Plattformen und Screens exakt gleich aussehen, sollten sich aber auf allen Endgeräten stimmig anfühlen. Ein Informationsangebot sollte sich zudem logisch in die native Experience einer Plattform eingliedern. Eine iPhone-App muss sich auf jeden Fall wie eine iPhone-App und nicht wie eine Website oder Android-App anfühlen; das heißt Buttonanordnung, Größe, Interaktion und Screenflow sollten iOS-konform

226

angelegt sein. Gleichzeitig muss das Angebot auch noch die visuellen Vorgaben (Corporate Styleguide, etc.) der jeweiligen Marke bzw. des Anbieters erfüllen. 5.7. Adaptability Um geräteübergreifendes Informationsmanagement zu vereinfachen, müssen sich Layouts und Inhalte dynamisch und flexibel an die jeweiligen Geräteeigenschaften anpassen. Responsive Design ist ein guter Ansatz, allerdings werden damit die Inhalte nicht an die unterschiedlichen Nutzungskontexte angepasst, sondern lediglich anders auf dem Screen angeordnet. Neben dem Layout sollte ein Informationsangebot zudem flexibel auf Interaktion, Bandbreiten, Inhalte (Responsive oder Adaptive Content), Leistungsstärke der Endgeräte und andere Parameter reagieren und eingehen. Außerdem lassen sich die Möglichkeiten der verschiedenen Endgeräte sinnvoll einsetzen, wie zum Beispiel Ortung, Audio Input, Kamera oder Neigungssensor bei Smartphones. Konzepter und Gestalter müssen generell berücksichtigen, dass man ein sinnvolles Layout erst gestalten kann, wenn die Inhalte (zumindest grob) fest stehen („Content First“). Es ist ein entscheidender Unterschied, ob man lange oder kurze Texte, Bilder, Galerien oder Videos darstellen muss und in welcher Qualität und Quantität diese Inhalte vorliegen. Es gibt nicht mobile und andere Angebote, sondern im Grunde nur einmal das gleiche Angebot, das in unterschiedlichen Nutzungskontexten (unterschiedlich) abgerufen und dargestellt wird. „There is no Mobile Web. There is only The Web, which we view in different ways. There is also no Desktop Web. Or Tablet Web. Thank you.“ (Stephen Hay, http://bit. ly/nomobweb)

5.8. Smart Content Je eleganter und granularer (die zu publizierenden) Inhalte, Daten und Informationen sind, desto flexibler lassen sie sich geräteübergreifend einsetzen, aufbereiten und darstellen. Unformatierte Texte lassen beispielsweise wesentlich einfacher in andere Informationen (App, Software, News) integrieren und auf vielen verschiedenen Geräten, Screens und Anwendungen darstellen. Inhalte sollten an einer zentralen Stelle hinterlegt und gepflegt werden, beispielsweise mit einem Content Management System oder nach dem COPE-Prinzip von npr: Create Once, Publish Everywhere (http://bit.ly/nprCOPE). Um multiscreen-fähige Informationen und Daten zu erstellen und zu pflegen werden Backend-Systeme mit entsprechenden flexiblen Content Management Workflows benötigt. Da Informationen nicht nur auf einer bestimmten Plattform konsumiert, sondern auch in anderen Anwendungen zu neuen Informationspaketen aggregiert werden, ist es entscheidend den Fokus auf die Gestaltung der Informationen anstatt auf die Gestaltung deren Darstellung zu legen. Es wird immer wichtiger Menschen einen möglichst einfachen Zugang zu digitalen Diensten und Informationen zu ermöglichen. In Anlehnung an einen Artikel von Scott Jenson im UX Magazine (http://bit. ly/uxdata) über die „User Experience von Daten“ beschreibt der Begriff „Information Experience“ das Nutzungserlebnis von Informationen. Sie müssen in jeder Situation kontextrelevant und für das jeweilige Gerät optimiert zur Verfügung stehen. Die erfolgreichsten Informationssysteme der Gegenwart bieten die Möglichkeiten zur Vernetzung von Informationen untereinander. Um derartige Szenarios zu ermöglichen, müssen diese Informationen klar strukturiert sein, unter anderem in Form von Metadaten. Metadaten oder Metainformationen sind Daten, die Informationen über andere Daten enthalten (z. B. Dateiname, Dateigröße, Dateityp, Datum,


Usability Professionals 2012 User Experience

Beschreibungen, Schlagwörter, etc.). Nur auf strukturierte Information kann sinnvoll mittels einer Schnittstelle zugegriffen werden. Strukturierte Information wiederum ist die Basis für eine medienneutrale Content Strategy. Wenn sich Inhalte flexibel in ein Layout und den Nutzungskontext anpassen, ist Content smart. Josh Clark benutzt dazu die Metapher „Content like water“ (http:// bit.ly/twjc111107). Mit Hilfe möglichst flexibler und offener Inhalte (Open Content), Schnittstellen und Metadaten können neue Geschäftsmodelle entstehen. 5.9. Mashability Plattformunabhängige und flexible Inhalte, Daten und Informationen lassen sich durch Nutzung entsprechender Schnittstellen zu neuen mehrwertigen Services kombinieren. Mashup-Dienste nutzen Schnittstellen anderer Services, um Informationen zu einem neuen Informationsangebot zu aggregieren. Dienste mit entsprechenden Schnittstellen wie YouTube lassen sich überall einbinden. Die Videoplattform ist mittlerweile auch in vielen SmartTV-Plattformen integriert. Das verschafft YouTube eine enorm gute Marktposition. Im Gegenzug sind SmartTV-Anbieter, die populäre Services wie YouTube in ihr Angebot integrieren, natürlich attraktiver für potentielle Käufer. Viele mobile Apps verwenden Dropbox als Cloud-Schnittstelle um Daten oder Informationen zu speichern und geräteübergreifend und -unabhängig zu synchronisieren. Qwiki ist ein Mashup aus Suchmaschine, Lexikon und Videoportal, das über entsprechende Schnittstellen Informationen aus unterschiedlichen Quellen zu einem neuen Informationspaket aggregiert (qwiki. com). SmartTV-Plattformen aggregieren verschiedenste Informationen und Services über Apps (z. B. tagesschau.de, YouTube, Facebook), Social TV und Web Browser.

5.10. Communification und soziale Vernetzung Eine soziale Vernetzung oder die Schaffung einer Community können ein Informationsangebot in vielen Fällen attraktiver machen. Social Involvement, User Generated Content, Kommentare, persönliche Empfehlungen und User-Einschätzung verleihen Informationen (Nachrichten, Daten, Produkte) eine höhere, persönliche und teilweise subjektive Qualität. Es entsteht eine Win-Win-Situation für Anbieter und Nutzer. Durch die Community entsteht ein zusätzlicher Kommunikationskanal für den direkten Dialog zwischen Anbieter und Nutzer, aber auch zwischen den einzelnen Nutzern selbst. Die Community muss auf allen relevanten Endgeräten erreich- und verfügbar sein. Die „Nike+“-App zeigt, wie man dieses Konzept stimmig umsetzt. Auch der Trend „Social TV“ lebt von der Kombination von Entertainment und Community. Mit der Nike+ iPhone App lassen sich Laufstrecken via GPS aufzeichnen, mit dem Online-Portal Nikeplus.com synchronisieren und mit anderen Läufern in der Community teilen. Alle Laufstrecken werden in der Online-Plattform gelistet und können kommentiert, bewertet, mit anderen Netzwerken geteilt und an andere Läufer weiterempfohlen werden. Es ist auch möglich, sich mit anderen Joggern in einem Wettkampf zu vergleichen oder persönliche Rekorde zu brechen (Gamification). 5.11. Emotionality (User Experience) Services sind emotional ansprechender, wenn sie Spaß machen und einen gerätefragmentierten Tagesablauf unterstützen. Erkenntnisse aus der Psychologie können helfen gezielt und sinnvoll die Bedürfnisse und Motive der Nutzergruppe anzusprechen und Informationen zielgruppengerecht zu emotionalisieren. Es gibt interessante Ansätze aus dem Bereich des Neuromarketing, die man auch bei der Konzeption von digitalen Services sinnvoll einsetzen kann (z. B. das System

„Limbic“ von Hans-Georg Häusel, Gruppe Nymphenburg, http://www.nymphenburg. de/limbic.html). Wenn ein Informationsangebot Mehrwert über verschiedene Endgeräte und Touchpoints (das sind alle Kontaktpunkte an denen man mit einem Service in Berührung kommt) bietet und Informationen immer und überall verfügbar sind, dann steigt die Wahrscheinlichkeit, dass Anwender sich mit dem Angebot identifizieren und es gerne und dauerhaft (be)nutzen. Spielelemente und soziale Komponenten (vgl. Communification) können die Bindung zwischen User und Service ebenfalls steigern. 5.12. Technische Herausforderungen Die Theorie praktisch umzusetzen und anzuwenden ist eine große Herausforderung. Man wird stets mit der Frage konfrontiert, ob eine reine Desktopvariante ausreichend ist oder ob man zusätzlich eine Web-App oder gar native App benötigt. Ob eine native, eine Web App oder eine Responsive Website die bessere Lösung ist, muss man von Fall zu Fall entscheiden. Dann stellen sich diverse Fragen nach relevanten Plattformen, Maintenance und so weiter. Werden die Devices und Geräteklassen richtig erkannt und lassen sich Layout und Inhalte entsprechend angepasst ausgeben? Sind die Inhalte für die Ausgabe auf den verschiedenen Geräten, Screens und Anwendungen optimiert? Für eine optimale Layout-Anpassung muss man die verschiedenen Media-Queries richtig (ein)setzen. In manchen Fällen muss man Event-Anpassungen für die verschiedenen Ausgabegeräte vornehmen und unterschiedliche und gerätespezifische Interaktionsmuster berücksichtigen. Werden aktuelle Webtechnologien geräteund plattformübergreifend konsistent unterstützt? Welche Bugs bei einzelnen Betriebssystemen und den unterschiedlichen Versionen liegen vor? Jede Plattform hat gewisse Eigenheiten. Der Aufbau einer effizienten und breitgefächerten Testumgebung kann Risiken, Test- und Entwicklungsaufwände minimieren, Probleme aber nie komplett verhindern. Letztlich geht es

227


darum die Unbekannten so weit wie möglich zu minimieren und mit jedem neuen Projekt dazuzulernen. Vor allem in technischer Hinsicht ändern sich die Anforderungen, Einschränkungen und Möglichkeiten teilweise sehr schnell. 6. Fazit

Wiederverwendbare Muster oder das Multiscreen Experience Toolkit (http:// www.multiscreen-experience.com) können helfen die anstehenden Herausforderungen zu meistern. Wer außerdem wie ein Multiscreener lebt und Spaß bei der Arbeit hat, wird es einfacher haben adäquate Services und zukunftsfähige Konzepte zu entwerfen!

Literatur [alle anderen Quellen werden direkt im Text erwähnt]

Wir arbeiten momentan an einer Publikation zum Thema Multiscreen Experience Design. Erscheinungstermin ist voraussichtlich Herbst/Winter 2012. Näheres erfahren Sie unter www.multiscreen-experience-design.com.

2. Nagel, W., Fischer V. (2011). Multiscreen

1. Nagel, W., Fischer V. (2011). Multiscreen Experience – Medien und plattformübergreifendes Informationsmanagement für die Digitalen Gesellschaft. Unveröffentlichte Master-Thesis, Hochschule für Gestaltung Schwäbisch Gmünd.

„Multiscreen ist kein „netter Zusatz“ mehr, sondern Pflicht!

6.1. Zusammenfassung

Experience: Multiscreen Muster. http://www. multiscreen-experience.com/?page_id=47 (13.03.2012) http://bit.ly/msxthmm 3. Nagel, Wolfram (2012). brainsight (Blog): Multiscreen Definition (Wikipedia Entwurf). http://wnagel.posterous.com/multiscreen-

Mittlerweile ist jedes Projekt eines für mehrere Screens. Deshalb dürfen wir zukünftig nicht nur Insellösungen für einen Screen entwerfen, sondern müssen ganzheitliche Konzepte entwickeln, um dem Ziel eine fließende Multiscreen Experience anzubieten möglichst nahe zu kommen. Kunden oder Projektbeteiligte können mit guten Beispielen überzeugt bzw. aufgeklärt werden. Gerätefragmentierung und die verschiedenen Screens werden eine der zentralen Herausforderungen für aktuelle und zukünftige (digitale) Projekte sein. Man muss die relevanten Endgeräte oder Screens und deren Kombinationsmöglichkeiten identifizieren, die User (Zielgruppe) und deren Bedürfnisse, den fragmentierten Tagesablauf und das geänderte Nutzungsverhalten kennen, berücksichtigen und unterstützen. Flexible und dynamische Layouts und (!) Inhalte und allgemein multiscreen-fähige Daten und passende Content Management Workflows sind Grundvoraussetzung. Datensicherheit und Connectivity sind weitere zentrale Aufgaben. Generell ist es aber wichtig, dass man nicht nur für die Endgeräte und Screens gestaltet, sondern stets die Menschen, die diese Geräte und entsprechende Informationsangebote benutzen, in den Mittelpunkt stellt und den potentiellen Nutzungskontext berücksichtigt oder zumindest versucht zu antizipieren.

228

6.2. Ausblick

definition-wikipedia-entwurf (16.08.2012) 4. Stoll, Christophe und Schardt, Johannes (2010). Precious Design Studio: Patterns

Wir werden zukünftig natürlich nicht nur die momentan vier wichtigsten Screens berücksichtigen müssen, sondern viele Interfaces und andere internetfähige Geräte, die die Multisceen-Welt noch fragmentierter aber auch noch spannender werden lassen.

for Multiscreen Strategies. http://preciousforever.com/multiscreen-patterns (07.06.2011) 5. Colborne, Giles (2012). cxpartners: Mobile app or mobile web? http://www.cxpartners. co.uk/cxblog/mobile-app-or-mobile-web/ (16.06.2012) 6. Initiative D21 (2011). Digitale Gesellschaft 2011. Die digitale Gesellschaft in

„A part of Multi-device strategy is simply embracing the uncertainty.“ (Josh Clark)

Deutschland – Sechs Nutzertypen im Vergleich. http://www.initiatived21.de/ wp-content/uploads/2011/11/Digitale-

Egal ob Laptops, MP3-Player, Mobiltelefone, Smart TVs, HiFi-Systeme, Kühlschränke oder die voll elektronisch gesteuerte Heizung. Bald besteht jedes kleine Gerät aus einem Chip. Und der Nutzer wird mächtiger. Er entscheidet sich bewusst für eine Anwendung (App) oder einen Service – und (erst) dann entscheidet er welches Endgerät er sich kaufen oder benutzen möchte. Das Endgerät macht für ihn nur Sinn, wenn es die Informationen, die ihm wichtig sind, auch verarbeiten und darstellen kann. Es geht nicht (mehr) darum welche Features ein Produkt hat, sondern ob und wie der Zugang zu Informationen optimal funktioniert (Zugang ist wichtiger als Besitz). Entscheidend sind die Informationen selbst und die Objekte mit denen der Anwender interagieren möchte.

Gesellschaft_2011.pdf (16.02.2012) 7. Nagel, W., Fischer V. (2011). Multiscreen Experience: Personas. http://www. multiscreen-experience.com/?page_id=53 (13.03.2012) 8. Clark, Josh (2012). „Don‘t punish users for their contexts“— @cennydd. Don‘t cut content or features just because people happen to be on a small screen. #bdconf. https://twitter.com/globalmoxie/ status/192268677305999361 (17.04.2012) 9. Clark, Josh (2010). Tapworthy. Designing Great iPhone Apps. O‘Reilly Media. Sebastopol, California. 10. Clark, Josh (2011). MobX Conference 2011: Mobile Context is a Myth (18.11.2011) 11. McGrane, Karen (2011). MobX Conference 2011: Adapting ourselves to adaptive content. http://slidesha.re/mobx11mcgrane (09.01.2012)


Usability Professionals 2012 User Experience

12. Wellmann, Stephen (2007). InformationWeek

1. Nagel, W., Fischer V. (2011).

Mobility: Google Lays Out Its Mobile

Multiscreen Experience – Medien

User Experience Strategy. http://www.

und plattformübergreifendes

informationweek.com/mobility/business/

Informationsmanagement für die Digitalen

google-lays-out-its-mobile-user-

Gesellschaft. Unveröffentlichte Master-Thesis,

experien/229216268 (14.04.2012)

Hochschule für Gestaltung Schwäbisch

13. Oschatz, Alexander (2010). Mobile Metrics:

Gmünd.

Mobile Web überholt Desktop Web in 5 Jahren. http://mobilemetrics.de/2010/05/19/

http://bit.ly/msxdefblog

mobile-web-uberholt-desktop-webin-5-jahren (zitiert nach Meeker, 2010).

Multiscreen Patterns Precious Design Studio

(23.06.2011) 14. Meeker, Mary (2010). Internet Trends.

http://bit.ly/msxthmm

Präsentation am 12. April 2010). http:// www.morganstanley.com/institutional/

“People use any platform to do anything.“ (Giles

techresearch/pdfs/Internet_Trends_041210.

Colborne)

pdf (23.06.2011) 15. Verband Privater Rundfunk und Telemedien

www.multiscreen-experience.com

e.V. (2011). Parallele Nutzung von TV und Online. IP Deutschland, TNS Emnid, W&V:

http://bit.ly/id21pub

DigitalBarometer Herbst 2011. via http:// www.vprt.de/thema/marktentwicklung/

http://bit.ly/msxpersonas

marktdaten/mediennutzung/tv-nutzung/ content/parallele-nutzung-von-tv-und-

Cennydd Bowles, http://bit.ly/twjc120417

onli?c=2 (14.04.2012) 16. Jespers, Serge: Think multi-screen.2010.

oreil.ly/clarktapworthy

http://www.webkitchen.be/2010/12/15/thinkmulti-screen (28.01.2011)

bit.ly/googlemobileux

17. Hay, Stephen (2011). There is no Mobile Web. http://www.the-haystack.com/2011/01/07/

http://bit.ly/mobvsdesk1005

there-is-no-mobile-web (26.07.2012) 18. Jacobson, Daniel (2009). programmableweb:

http://bit.ly/Hi5DmO

COPE: Create Once, Publish Everywhere. http://blog.programmableweb.

http://bit.ly/tvonlineparallel2011

com/2009/10/13/cope-create-once-publisheverywhere/ (16.03.2012)

http://bit.ly/jespersthkms

19. Jenson, Scott (2011). UX Magazine: The UX of Data. http://uxmag.com/articles/the-ux-of-

http://bit.ly/nomobweb

data (02.05.2011) 20. Clark, Josh (2011). Content like water:

http://bit.ly/nprCOPE

design flexible content to flow anywhere. „Put water into a cup, it becomes the

http://bit.ly/uxdata

cup“—Content strategist Bruce Lee #fowd. https://twitter.com/globalmoxie/

http://bit.ly/twjc111107

status/133587842654937088 (01.02.2012) 21. Häusel, Dr. Hans-Georg (2011). Gruppe

http://www.nymphenburg.de/limbic.html

Nymphenburg Consult AG. Limbic®: Das innovative und einzigartige NeuromarketingInstrumentarium. http://www.nymphenburg. de/limbic.html (17.10.2011)

229


Best Practice „Automobilbranche“: Service- und Informationsportal Die effiziente Planung komplexer Informationsarchitektur für 50.000 Mitarbeiter. Sebastian Ammermüller chilli mind GmbH Königstor 23, 34117 Kassel www.open-ideation.com ammermueller@chilli-mind.com

Oliver Gerstheimer chilli mind GmbH Königstor 23, 34117 Kassel www.chilli-mind.com gerstheimer@chilli-mind.com

Abstract Industrie-Interfaces müssen effizient und effektiv sein im internationalen Wettbewerbsumfeld. Die Informationsarchitektur und die User Interface-Bedienlogik werden bewertet nach der Geschwindigkeit und Eindeutigkeit bei der Informationsbeschaffung und Interaktion mit Funktionen, Service und Kommunikation. Vorgestellt wird eine Intranetund Extranet-Projektierung – die Neugestaltung des zentralen Informationsportals für die Volkswagen Partner (Autohäuser) in Deutschland – zirka 50.000 Anwender in den Bereichen Verkauf, Service, Werkstatt, Teiledienst, Marketing und Management. Der Beitrag stellt die Herausforderungen bei der Entwicklung und Bearbeitung von Industrie-Interfaces – insbesondere im komplexen Konzernumfeld – Business-to-Employee (B2E) und Business-to-Business (B2B) dar. Als Beispielprojekt wird die Zusammenlegung und Neukonzeption von zwei bestehenden Informationssystemen zu einem neuen, gesamtheitlichen Informationsportal in der Automobil-Branche genutzt. Im Fokus stehen die praxisorientierte Integration der relevanten Nutzergruppen/Anwender über qualitative Fokusgruppen und Kontext-Interviews sowie die Vermittlung und Kompromissentwicklung zwischen den Anforderungen beteiligter Stakeholder. Es wird aufgezeigt wie das User Interface Design im Spannungsfeld zwischen Effizienz, Skalierbarkeit, Flexibilität und Corporate Design-Konformität entwickelt wird – bei gleichzeitiger Integration und Vermittlung zwischen konzerninternen Fachbereichen, Corporate Design, IT und externer Programmierung.

1. Ausgangssituation und Zielsetzung Volkswagen PartnerNet und ServiceNet sind heute die zentralen Informationssysteme (> 70.000 Dokumente/Artikel) für die Volkswagen Partner in Deutschland. Die Zielgruppe umfasst zirka 50.000 Nutzer verteilt auf zirka 2.400 Autohäuser. Die Anwender kommen aus allen Bereichen im Autohaus vom Verkauf über Disposition und Marketing bis zu Service, Werkstatt und Teiledienst. Die Informationsbedürfnisse sind stark unterschiedlich ausgeprägt und reichen von allgemeiner Informationsbeschaffung bis zum speziellen kontextspezifischen Informationsabruf. Die detaillierten Nutzeranforderungen waren zu Beginn des Projekts weitestgehend unbekannt.

230

Die bestehenden Systeme sind über die Jahre sukzessiv weiter entwickelt und immer wieder den aktuellen Informationsanforderungen angepasst worden. Die gewachsenen Strukturen, mit starkem Fokus aus der internen Sichtweise bilden heute in vielen Fällen nicht mehr die täglichen Nutzeranforderungen im Berufsalltag ab. Zudem entspricht die starke Trennung der Bereiche Verkauf (=PartnerNet) und Service (=ServiceNet) nicht der gelebten/ realen Organisationsstruktur im Autohaus. Die Zusammenlegung der Systeme, Neustrukturierung der Inhalte und die Entwicklung alternativer Zugangsstrukturen sind notwendige Maßnahmen. Aufgrund der Unwissenheit bzw. Unsicherheit über die aktuellen Nutzungskontexte und Informationsanforderungen der Nutzergruppen im Autohaus war ein

Gesa Nolte chilli mind GmbH Königstor 23, 34117 Kassel www.chilli-mind.com/42 nolte@chilli-mind.com

Keywords: /// Industrie-Interfaces /// Informationsarchitektur /// User-Experience Management /// praxisorientierte Nutzerinteraktion /// User Stories /// Rapid Prototyping

nutzerzentrierter Entwicklungsansatz für das neue Informationsportal erforderlich. 1.1. Herausforderung Die Rolle des User Experience Teams, Informationsarchitekten, User Interface Designer etc. hatte im Entwicklungsprozess unterschiedliche Facetten. Wichtige Meilensteine und Herausforderungen im Projekt waren die folgenden Punkte: –– Evaluation der Nutzerbedürfnisse im Berufsalltag durch aktive Integration der Nutzer; –– Entwurf einer nutzergerechten Informationsarchitektur für zirka 70.000 Einzeldokumente und 15 Nutzergruppen im Autohaus (Datenaufkommen vs. Nutzeranforderungen);


Usability Professionals 2012 User Experience

–– Konzeption eines übergeordneten Personalisierungskonzept mit Rollenberechtigung; –– Management und Kommunikation des Entwicklungsprozesses zwischen den beteiligten Fachbereichen, Konzern-IT und externen Programmierdienstleistern; –– Planung des Systemwechsels und Rollout mit Einführungs- und Kommunikationskampagne. 2. Entwicklungsansatz – UX Management Framework Der Startpunkt für den Entwurfsprozess war die Aufgabe aus zwei gewachsenen Systemen mit den bestehenden Vor- und Nachteilen ein neues System mit einer nutzerzentrierten durchgängigen und logischen Informationsarchitektur zu entwickeln. Der integrierte User Experience (UX) Entwicklungsansatz für das Informationsportals ist in drei Hauptachsen unterteilt. Die klare Abgrenzung sowie das permanente Zusammenspiel dieser Prozessachsen waren die Grundlage für einen flexiblen und zielgerichteten Entwurfsprozess zwischen den beteiligten Bereichen.

Folgende Entwicklungsachsen werden unterschieden: A) Entwurf und Design – mit unterschiedlich detaillierten Stufen der Konkretisierung/Visualisierung des Entwurfs vom Scribble/Skizze über WireframeStrukturscreens bis hin zu definierten Designscreens. B) Experten- und Nutzerinteraktion – mit Usability Check-Up Methoden, Expert (P) replanning, qualitativen Fokusgruppen und Kontext-Interviews, Use Case-Testings am Prototypen. C) Konzept, Definition und Optimierung – der zusammenführende Prozess zwischen Entwurf und Design (A) und Expert-/Nutzerinteraktion (B) mit ständiger Optimierung auf die Nutzeranforderungen. D) Projektmanagement – Koordination und Kommunikation – „Vermittlung“ des Entwicklungsstands für alle beteiligten Stakeholder inklusive Definition,

Abb. 1. UX-Management Entwicklungsframework

Dokumentation und Transfer der Entwurfsergebnisse. Der Bereich (A) Entwurf und Design arbeitet in einem ständigen Zusammenspiel (PingPong-Effekt) mit dem Bereich (B) Experten- und Nutzerinteraktion. Ziel ist es auf jeder Entwicklungsstufe die adäquate Methode/Output auf der Entwurfs-/Designachse für die Evaluation und Optimierung bei den Nutzerinteraktionen (B) zu erreichen. Das flexible und gleichzeitig abgestimmte Projektmanagement zwischen diesen beiden Bereichen, ermöglicht das schnelle Umschalten und Wechseln der Visualisierungsmethoden und damit eine optimale praxisorientierte Nutzerintegration. Gleichzeitig werden im mittleren Prozessstrang „Konzept und Definition“ die Ergebnisse aus den flankierenden Achsen zusammengeführt, verdichtet und in entwurfsrelevante Definitionen überführt. [Abb. 1]

Der aufgezeigte Entwicklungsansatz schafft als Kommunikationsgrundlage Transparenz für die Beteiligten im Entwicklungsprozess und bietet das Basisframework für ein planvolles Voranschreiten im Entwurfsprozess über Analyse, Konzept, Design und Definition des neuen Portals. Zudem kann eine praxisrelevante Nutzerintegration bei gleichzeitig adäquatem Ressourceneinsatz durch das „PingPong“ zwischen Entwurfund Visualisierungsmethoden (A) und Nutzerinteraktionsmethoden (B) sichergestellt werden. Eine klare Ausrichtung und Konzentration der Methoden auf das Ergebnis für den Konzept- und Definitionsprozess ist das ausgemachte Ziel. 2.1. A: Entwurf und Design – Visualisierungsportfolio Nachfolgend werden ausgewählte Visualisierungsmethoden aufgezeigt, die zu

231


verschiedenen Zeitpunkten im Projekt zum Einsatz kamen. Der Output aus den einzelnen Stufen bildete die gemeinsame Kommunikations- und Interaktionsbasis sowohl für die Zielabstimmung auf Entwicklerseite (Fachbereiche, IT, User Interface Design) als auch für die Anforderungsanalyse und Evaluation auf Nutzerseite (Personal im Autohaus). 2.1.1. A1: Persona Design und User Stories – „pragmatisch & verständlich“ Die Grundlage für den nutzerzentrierten Designansatz wurde durch das klassische Persona Design gelegt. Im Falle der verschiedenen Nutzertypen im Autohaus war dabei die praktikable Reduktion auf die entwurfsrelevanten Archetypen aus den Bereichen Verkauf, Service, Werkstatt, Teiledienst, Marketing und Management. Die entwickelten Personas stellten dabei keine real existierenden Personen dar, sondern übernahmen eine Art „Stellvertreterfunktion“ für eine Gruppe ähnlicher Nutzertypen (Querschnittsfunktion). Anhand der Archetypen wurde die Überprüfung der täglichen Nutzungsfälle im Arbeitsalltag durch User Stories abgebildet. Der Fokus lag dabei auf der Sammlung, Strukturierung und Priorisierung der Nutzeranforderungen und Use Cases nach Relevanz (besonders wichtig) und Frequenz (besonders häufig). Darüber konnten im Fall des geplanten Informationsportals für die Volkswagen Partner 80% der Struktur- und Funktionsanforderungen an das Gesamtsystem abgedeckt werden. 2.1.2. A2: Scribble und First Sketching – „einfach & vorstellbar“ Das schnelle und dennoch durchdachte (Hand-)Scribble des geplanten Entwurfs stellte einen guten Einstiegspunkt in den Designprozess dar – insbesondere für die frühe Integration der verschiedenen beteiligten Fachabteilungen. Ideen und Ansätze für Layout, Funktionen und Zugangsstrukturen bekamen eine erste sichtbare und bewertbare Vorstellung. Der Vorteil bei dieser Art der Konkretisierung ist der weite

232

Interpretationsraum, den die skizzenhaften Screens und Clickflows offen lassen. Das „Unfertige“ nimmt die Angst der beteiligten Parteien, es mit vollendeten Tatsachen zu tun zu haben, die unwiderruflich und nicht zu ändern sind. Im Falle des InfoNetProjekts konnte über diese Visualisierungsstufe eine grundlegende Projektierung und Sichtbarkeit des Projekts in den internen Abteilungen bis hin zum Management erreicht werden. 2.1.3. A3: Wireframe & Clickflow – „Informationsarchitektur & Interaktion“ Der nächste Detaillierungsschritt war das Wireframe-Design. Die Digitalisierung der Entwürfe schaffte dabei eine flexible und einfach skalierbare Entwurfsgrundlage für die effiziente Vervielfältigung verschiedener Screenansichten. Fokus dabei ist die detaillierte Überprüfung und Optimierung sowie Verfeinerung des Layouts, Strukturen und Einzelelemente. Gleichzeitig konnte verbindlich und ohne „Geschmacksfragen/-diskussionen“ die Informationsarchitektur fokussiert und weiter entwickelt werden. Mit dem abgestimmten „Grundriss“ / „Technische Zeichnung“ des Portals wurden weitere Detailfragen (Design, Interaktionsstrukturen, etc.) effektiv bearbeitet. 2.1.4. A4: User Interface Design & Skinning – „flexibel und adaptierbar“ Die Überführung der Wireframes in User Interface Screens fokussiert das Skinning bzw. das Oberflächendesign. Die Festlegung von Farben, Formen, Schriften sollte dabei systematisch klaren Standards folgen, um bei der Vielzahl der Einzelelemente des Portals ein einheitliches und wiedererkennbares Gesamtbild zu erreichen. Gleichzeitig sollte die Verwendung weniger definierter Styles die Programmierung von Portlets für das Portal vereinfachen und eine hohe Effizienz bei der Umsetzung und Erweiterung des Portals erreichen. Die Herausforderung des UI-Designs bewegte sich im Spannungsfeld zwischen der Standardisierung von

Layout, Elementen und Formaten sowie der Flexibilität in der Umsetzung neuer Einzelansichten. Über diese Vorgehensweise konnten punktuell wichtige Adaptionen zu den Corporate Design Vorgaben von Volkswagen realisiert werden. Die Ergebnisse bildeten die Grundlage für die Design Spezifikation (C) – „Design & Interaction Guide“. 2.1.5. A5: Prototyping & Simulation – „effizient & erfahrbar“ Rapid Prototyping, Klickdummies und Simulationen des Realsystems zielen auf die erfahrbare Überprüfung von Design, Informationsarchitektur und Interaktionsstrukturen. Der Ansatz der Simulationsmethoden war es, mit einem adäquaten Kostenaufwand/Einsatz soviel „Realsystem“ zu erzeugen, wie notwendig war für die Erfahrbarkeit auf Nutzerseite. Dabei reichte die Spanne von linear hintereinander geschalteten Einzelscreens im PPT-Format über erläuternde Animationssequenzen bis hin zum sequentiell klickbaren Funktionsmodell. Je nach Zielsetzung bei der Nutzerinteraktion wurde zwischen den Methoden/Outputs variiert. 2.2. B: User Interaktion – Methodenportfolio Ziel der Nutzerinteraktion war es in der Anfangsphase die Bedürfnisse und Anforderungsstrukturen an das zukünftige Volkswagen InfoNet aus Sicht der Anwender in den verschiedenen Autohausbereichen Geschäftsführung, Verkauf, Service, Marketing, Teiledienst zu definieren. Im weiteren Projektverlauf verlagerte sich der Fokus auf die Überprüfung und Optimierung des Entwurfs aus Anwendersicht. Die frühe und aktive Integration der Nutzer als „Betroffene“ in den Entwicklungsprozess liefert nicht nur entwurfsrelevante Ergebnisse sondern stellt auch ein politisches Signal dar. Gleichzeitig wird eine positive Grundakzeptanz für das neue System aufgeladen.


Usability Professionals 2012 User Experience

2.2.1. B1: Expert UX-Check – „Analyse & First Impression“ Vor der ersten Nutzerinteraktion wurde das zu gestaltende System bzw. die Vorgängersysteme einem internen Expert UX-Check unterzogen. Diese Methode konzentriert sich auf die IST-Analyse durch Usability-Experten aus dem UX-Team. Fokus war die Aufnahme, das „Einfrieren“ des ersten Eindrucks – das Look and Feel – als unvoreingenommener „Erstlings“Nutzer. Dieser Check ist vergleichbar mit einem neuen Mitarbeiter im Autohaus, der das erste Mal mit dem System konfrontiert wird. In der Folge wurden relevante Use Cases aus Sicht typischer Anwender durchlaufen und auf UsabilityKriterien wie Aufgabenangemessenheit, Erwartungskonformität etc. hin überprüft. Die Prüfung der bestehenden ClickflowStrukturen basierte dabei auf den relevanten oder häufig frequentierten Use Cases der Nutzerarchetypen als Ergebnis aus (A1) Persona-Design und User Stories. Entwurfsrelevante Ergebnisse waren eine generelle Stärken- und Schwächenanalyse der bestehenden Anwendungen sowie die konkrete Identifikation von Optimierungspotenzialen mit Ableitung übergreifender Strategieziele für die Gesamtprojektierung. 2.2.2. B2: Expert (P)replanning Die Integration der internen Experten und fachlich Verantwortlichen auf System-/Betreiberseite durch integrative Entwurfsworkshops zielte auf die frühe

Identifikation der Hauptmerkmale und Anforderungen an das Informationsportal aus Innensicht des Konzerns (= Portalbetreiber). Hier wurden die Hauptziele und die Gesamtstrategie festgelegt. Daraus abgeleitet wurden die sogenannten „Must have“ Anforderungen und Funktionen. Der Abgleich der Auftraggeberanforderungen (B2) mit den Anwenderbedürfnissen (B1) ergab das strategische Grundframework für die Entwurfsphase. 2.2.3. B3: Qualitative Fokusgruppen – „aufgabenbezogen & flächendeckend“ Die Anwendergruppen im Autohaus besitzen differenzierte Anforderungen. Grundsätzlich konnten zwei Hauptanforderungen unterschieden werden: die allgemeine Informationssuche (NewsUpdate) und die gezielte situationsspezifische bzw. aufgabenbezogene Suche nach Detailinformationen. Um die Vielfalt der Nutzungs-/Aufgabenkontexte in den verschiedenen Nutzergruppen zu identifizieren, wurden qualitative Fokusgruppen mit den Hauptzielgruppen im Autohaus durchgeführt – von der Geschäftsführung, Finanzen und Buchhaltung über Verkaufsleiter und -berater bis hin zum Serviceleiter, -berater und Werkstattmitarbeiter. Die Fokusgruppen wurden als offene Gruppendiskussion mit Anreiz-Präsentation und Flipchart-Interaktion durchgeführt. Über die Präsentation wurden die Nutzer mit ersten Strukturüberlegungen, neuen Zugangssystemen und Designscreens aus dem Entwurfsprozess (A) konfrontiert. Folgende Themenbereiche wurden dabei systematisch strukturiert:

–– Analyse der Portalbedürfnisse entlang des typischen Tagesverlaufs; –– Sammlung der wichtigsten Aufgaben und Prozesse im Arbeitsalltag; –– Gemeinsames Ranking der Tätigkeiten, Funktionen und Inhalte nach Wichtigkeit, Häufigkeit und allgemeiner Nutzungsrelevanz. Die aufgabenbezogen zusammengesetzten Fokusgruppen bestanden aus 8-10 Teilnehmern – jeweils aus einem Funktionsbereich bzw. Nutzersegment im Autohaus. Sie waren integriert in volkswageninterne Veranstaltungen (z. B. Schulungen, Weiterbildungen, ExpertenKonferenzen) und dauerten zwischen 2-3 Stunden. Über diesen Aufbau konnten effektiv verdichtete Bedürfnisstrukturen aus über 140 Nutzerinteraktionen für den Entwurfsprozess gewonnen werden. [Abb. 2] 2.2.4. B4: Kontext-Interviews – „authentisch & polarisierend“ Als Ergänzung und Detailanalyse der Nutzeranforderungen an das Portal wurde die Methode des Kontext-Interviews eingesetzt. Dabei wurden die Nutzer im Original-Arbeitskontext in Einzelinterviews (Dauer 1 – 1,5 Stunden) intensiv befragt hinsichtlich typischer Prozesse, Aufgaben, Systeme und Anwendungen in ihrem Arbeitsalltag. Über die zusätzliche beobachtende Analyse und die Think aloud Methode in diesen Kontexten konnten relevante Entwurfsindizien aufgedeckt werden, die den Nutzern so nicht offensichtlich waren, da sie sich in vielen

Abb. 2. Need-Maps – Bedürfnisstrukturen im Arbeitsalltag verschiedener Nutzertypen

233


Arbeitsabläufen mit den bestehenden Systemen und Formaten arrangiert haben. 2.2.5. B5: Testing-Interaktion – „interaktiv & optimierend“ Zur Überprüfung und Optimierung der entwickelten Informationsarchitektur, Navigations- und Interaktionsstrukturen, wurden vereinzelt Nutzertests durchgeführt. Dabei wurden den Nutzern unterschiedliche Aufgaben gestellt, die sie an einem simulierten Testsystem „Clickdummy“ bearbeiten sollten. Über die Methode des lauten Denkens, über spontane Reaktionen und Eindrücke auf das Gesehene wurden wertvolle Optimierungspotenziale und zudem wichtige Kommunikationsziele für die spätere Systemeinführung im Handel gewonnen. Ergebnisse waren neben den einzelnen Detailoptimierungen von Interaktionsstrukturen und -elementen, erste Real-Eindrücke auf das neue System sowie allgemeine Verständnis- und Akzeptanzeinschätzungen. 2.3. C: Konzept, Design und Definition Die Prozessachse (C) Konzept, Design und Definition ist das zusammenführende Element in dem nutzerzentrierten Entwurfsprozess. Die Ergebnisse aus den Experten-/Nutzerinteraktionen (B) und aus den einzelnen Entwurfsschritten (A) wurden in der Konzept- und Definitionsphase vereint. Parallel dazu wurde ein ständiger Anpassungs- und Optimierungsprozess der Informationsarchitektur und des User Interface entlang der Nutzeranforderungen aus den Nutzerinteraktionen angestoßen und durchlaufen. Die Ergebnisse des User Interface wurden im letzten Schritt im Design & Interaction Guide definiert. In der Definitionsphase wurden die User Interface-Elemente standardisiert. Die erforderlichen Designund Interaktionsspezifikationen wurden detailliert für die Programmierungsumsetzung festgelegt. Ziel waren standardisierte UI-Elemente mit hoher Flexibilität und Skalierbarkeit für die Umsetzung sowie für die

234

spätere Weiterentwicklung des Systems. Parallel dazu wurden im Pflichtenheft die Funktionen des Systems sowie Abhängigkeiten, Strukturen und Schnittstellen zu anderen Systemen beschrieben. 3. Entwurf Volkswagen InfoNet Nachfolgend werden grundlegende Entwurfsansätze des entwickelten Systems aufgezeigt. Die Informationsarchitektur des entwickelten Portals folgt dem Grundsatz: Analog ist Digital. Die Hauptbereiche der Navigationsstruktur orientieren sich an der typischen Organisationsstruktur im Autohaus. Somit entspricht die Navigation den gewohnten Denkstrukturen und -mustern der Anwender im Autohaus. Eine einfache und intuitive Orientierung wird dadurch unterstützt. Ein weiterer Fokus ist die effiziente und gezielte Informationsdarstellung für die Anwender durch die Integration personalisierter, funktionsbezogener Bereiche – insbesondere auf der InfoNet Startseite. Speziell ausgewiesen Bereiche wie z. B. Top News, Banner oder Top Teaser sind inhaltlich auf die 15 Hauptzielgruppen/Funktionen im Autohaus zugeschnitten. Für ein schnelles Informationsupdate ist damit der Aufruf der Startseite ausreichend. Ein weiterer Ansatz ist die konsequente Alternativverortung von Inhalten. Einzelne Inhalte und Informationen können nur selten eindeutig einem Thema zugeordnet werden. Die Nutzer denken in unterschiedlichen Strukturen und Mustern. Aus diesem Grund sieht die Zuordnung im InfoNet eine Hauptnavigation und „beliebig“ viele Alternativverortungen vor. Darüber soll die Auffindbarkeit der gesuchten Information für die verschiedenen Denktypen gewährleistet werden. Neben dem klassischen Zugang über die Navigationsstruktur bietet das Volkswagen InfoNet zwei zusätzliche alternative Zugänge für kontext- und aufgabenspezifische Nutzeranforderungen. Die

Zugangssysteme über Modelle und Baugruppen sind permanent auf der Systemoberfläche sichtbar. Mit wenigen Klicks können hierüber zielgerichtet alle Informationen zu einem bestimmten Modell oder einer bestimmten Baugruppe angezeigt werden. Als letzte Neuerung beinhaltet das System in der rechten Spalte eine sogenannte Toolbar mit individuellen Schnellzugängen und Tools. Neben dem Zugang zur Mediathek existieren hier persönliche Bereiche zur Selbstorganisation wie z. B. Favoriten, Kalender oder das NewsletterAbonnement. Die Reihenfolge und Darstellung der einzelnen Funktionsbereiche kann individuell durch den Nutzer definiert werden. [Abb. 3] 4. Fazit – Die Rolle des UX-Teams Informationsarchitekten und User Interface Designer können eine zentrale Rolle bei der Umsetzung von UI-Großprojekten auf Konzernebene einnehmen und den interdisziplinären Entwicklungsprozess zwischen den beteiligten Stakeholdern positiv voran bringen. Die eigentlich „vermittelnde“ Position bzw. Funktion basiert dabei auf der Visualisierung und Simulation des Entwurfs, der Oberflächen und Interaktionsstrukturen. Aufgrund der Komplexität der Aufgabe sind einfach verständliche Bilder als Kommunikationsgrundlage eines gemeinsamen Verständnis auf technischer und fachlicher Seite erforderlich. Hier liegt wie aufgezeigt die neue Herausforderung und Chance für die User Experience Teams vom Informationsarchitekten über den User Interface bis zum Interaction Designer.


Usability Professionals 2012 User Experience

Abb. 3. Exemplarische Startseite des Volkswagen InfoNet

235


Anforderungen an HMI in industriellen Kontexten Potentiale und Herausforderungen bei der Gestaltung maschinennaher Bedienoberflächen Natalie Oster ERGOSIGN GmbH Europa-Allee 12 66113 Saarbrücken oster@ergosign.de

Jan Groenefeld ERGOSIGN GmbH Europa-Allee 12 66113 Saarbrücken groenefeld@ergosign.de

Abstract Gebrauchstaugliche Bedienoberflächen gewinnen im industriellen Kontext zunehmend an Bedeutung. Ein ergonomisch optimiertes und visuell-ästhetisch ansprechendes Human Machine Interface (HMI) ist heute ein herausragendes Erfolgskriterium für die Entwicklung einer Maschine. Hierbei stellt insbesondere die Gewährleistung hoher Bediensicherheit bei gleichzeitiger Unterstützung effizienter Bediener-System-Interaktionen eine besondere Herausforderung dar. Die bislang oftmals technikgetriebene Entwicklung maschinennaher User Interfaces resultierte nicht selten in einem unnötig komplexen HMI, das Anforderungen von Benutzern, kontextuellen Gegebenheiten und Spezifika der auszuführenden Arbeitsaufgaben lediglich unzureichend Rechnung trägt. Aufbauend auf Erfahrungen zahlreicher Industrieprojekte wird im vorliegenden Beitrag ein Querschnitt wiederholt beobachteter Probleme in der Interfacegestaltung identifiziert, in ihren Implikationen für Bedien- und Überwachungssituationen analysiert sowie angemessene Lösungsansätze diskutiert. Folgende Themen werden innerhalb des Beitrags betrachtet: Maschinennahe HMI oder Monitoring Systeme, Komplexität, Benutzerrollen, Eingabemethoden, Maschinenvisualisierung und Fehlerverfolgung.

1. Motivation Obwohl in zahlreichen Projekten beobachtet werden kann, dass Maschinenhüllen bereits seit Längerem von Industriedesignern zweckoptimiert und ansprechend gestaltet werden, wurden deren Bedienoberflächen im maschinennahen Kontext zunächst vernachlässigt und in ihrer Bedeutung oft als nachrangig angesehen. Das Fehlen dezidierter Budgets zur Entwicklung gebrauchstauglicher HMI wies nicht selten Software-Ingenieuren die Aufgabe der Interfacegestaltung zu. Dies führte – bedingt durch eine technisch geprägte Sicht auf Daten und Systeminteraktionen – zu Bedienkonzepten, die die spezifischen Anforderungen von Benutzern, Arbeitsaufgaben und -kontexten nicht angemessen berücksichtigten. Angeregt durch herausragende Beispiele ausgewählter maschinennaher Interfaces – und nicht zuletzt auch durch die

236

Verbreitung mobiler Consumergeräte wie dem Apple iPhone – steht die benutzerzentrierte Gestaltung von User Interfaces nun auch bei der Entwicklung industrieller Anwendungen zunehmend im Fokus. 2. Anforderungen und Herausforderungen an das UI-Design Im maschinennahen und überwachungsgetriebenen Bedienkontext liegen häufig besondere Rahmenbedingungen vor, die einen starken Einfluss auf die Bedienung ausüben und hierbei Gestaltungsmöglichkeiten eröffnen oder diese einschränken. So ist die Arbeitsumgebung von Benutzern nicht selten durch Lärm- und Schmutzbelastung geprägt oder es muss eine Arbeitskleidung getragen werden, die die Motorik von Benutzern bei der Ausführung von Bedienhandlungen behindert. Die folgenden Abschnitte diskutieren eine Auswahl wiederholt beobachteter

Markus Kühner ERGOSIGN GmbH Europa-Allee 12 66113 Saarbrücken kuehner@ergosign.de

Keywords: /// HMI /// Industrie /// Maschinenbedienung /// Anforderungen /// Usability

Anforderungen an HMI und ihrer Lösungsansätze. Tabelle 1 fasst die wichtigsten Punkte nochmals stichpunktartig zusammen. 2.1. Maschinennahes HMI oder Monitoring System? Allgemein lassen sich zwei Typen von Benutzeroberflächen in der Industrie unterscheiden: maschinennahe Bedienoberflächen und Überwachungssysteme. Maschinennahe Bedienoberflächen werden in erster Linie zur Manipulation von Maschinenwerten und Kenngrößen des Prozessablaufs verwendet. Hierbei stellt die effiziente Anpassung von Rezeptparametern zumeist eine zentrale Anforderung dar. Jedoch lässt sich oftmals beobachten, dass häufig benötigte Parameter und Funktionen erst nach aufwändigen Systeminteraktionen in intransparenten


Usability Professionals 2012 User Experience

Strukturhierarchien zugreifbar sind, deren Organisation Benutzern zudem oft nicht bekannt ist. Ein naheliegendes Designprinzip kann daher in der Sicherung einer effizienten Erreichbarkeit prozessrelevanter Funktionen und der angemessenen Präsentation zentraler Informationen liegen. Treten während des Betriebs Störungen auf, so stellt sich die Frage nach der angebotenen Systemunterstützung bei deren Behebung: Je länger die Störungsbehebung dauert, desto höher ist ein Produktionsausfall und die entstehenden Kosten. Die frühzeitige Fehlererkennung steht vor allem bei Überwachungssystemen, den sogenannten Monitoring Systemen, im Mittelpunkt. Sie sollen Benutzer in der Überwachung des Systems unterstützen und die wichtigsten Systemparameter übersichtlich und leicht erfassbar darstellen. Dies stellt insbesondere in Abhängigkeit von der Menge und Komplexität darzustellender Informationen eine Herausforderung dar (vgl. Abschnitt 2.2 dieses Beitrags). Eine zunehmend bedeutsame Fragestellung, mit der sich HMI-Designer bei Überwachungssystemen häufig befassen müssen, ist die Anzahl der verwendeten

Monitore. Es ist keine Seltenheit, dass Benutzer drei bis sechs oder sogar mehr Monitore im Auge behalten müssen (vgl. Abbildung 1). Neben der Datenvisualisierung steht damit der gesamte Arbeitsplatz des Benutzers gemäß der Arbeitsplatzrichtlinien der ISO 11064-4 First edition 2004-07-01, Ergonomic design of control centres – Part 4: Layout and dimensions of workstations [2] im Zentrum der Optimierungsbemühungen, um ein menschengerechtes Arbeiten zu ermöglichen. Eine der Richtlinien fordert beispielsweise die leicht kreisförmige Anordnung von Monitoren, um den gleichen Abstand zwischen jedem Monitor und den Augen des Betrachters sicherzustellen. Eine weitere Optimierungsmöglichkeit betrifft die korrekte Anbringung von Monitoren. Die natürliche Sichtlinie eines Menschen beim entspannten Blick ist um ca. 15° nach unten geneigt (vgl. Abbildung 2). Häufig kann jedoch eine Anbringung von Monitoren in Kontrollstationen beobachtet werden, die zu hoch an der Wand und somit außerhalb der Sichthöhe des Betrachters platziert sind. Eine nützliche Gestaltungsheuristik liegt in der Reduktion anzuzeigender, für einen Prozess nicht fortlaufend relevanter Daten und der möglichen Verringerung der Monitoranzahl.

Abb. 1. Beispiel eines Leitstandes

Kombiniert man die Neugestaltung eines Arbeitsplatzes mit innovativen Eingabemethoden wie beispielsweise einem zentralen (Multi-)Touch-Panel zur Steuerung einzelner Bildschirminhalte, so bieten sich vielfältige Möglichkeiten zur Optimierung von Interaktion, Navigation und Informationsdarstellung (vgl. Abbildung 3). [Abb. 1], [Abb. 2], [Abb. 3] 2.2. Komplexität Vor allem bei Monitoring Systemen müssen eine Vielzahl an Parametern und Indikatoren gleichzeitig dargestellt werden. Aus dem Bemühen, wichtige Daten nicht zu vernachlässigen, leidet häufig die Übersichtlichkeit von Bildschirmlayouts. Bildschirmoberflächen werden oft auch mit für den Bediener weniger relevanten Kennzahlen und Statusmeldungen überfrachtet. Die Anwendung des Designprinzips „Progressive Disclosure“ kann diesem Problem hilfreich entgegenwirken. Dabei werden Informationen in unterschiedliche Informationsebenen und Gruppen strukturiert, so dass zu Beginn lediglich die oberste und aussagekräftigste Ebene sichtbar ist. Erst

Abb. 3. Möglicher Leitstand

Abb. 2. Arbeitsplatz-Layout angelehnt an Angaben aus der ISO 11064-4 “Ergonomic design of control centres – Part4: Layout and dimensions of workstations”

237


Abb. 4. Beispiel für die Anwendung von „Progressive Disclosure“

Abb. 5. Beispiel für die Anwendung des „Dark Cockpit“-Prinzips.

Abb. 6. Beispiele für analoge Informationsvisualisierung

bei Bedarf können weitere detailliertere Informationen durch Benutzer aufgerufen werden (vgl. Abbildung 4). Die strukturierte Präsentation von Informationen in inhaltlich kohärenten und übersichtlich angeordneten Gruppen erleichtert Benutzern die schnelle Erfassung von Werten. Die Reduktion anzuzeigender Werte beugt so einer zu hohen kognitiven Belastung des Benutzers vor [1]. Die kognitive Belastung von Benutzern kann ebenfalls durch den angemessenen Einsatz von Farben und Kontrasten reduziert werden. Ein Beispiel hierfür ist das sogenannte „Dark Cockpit“ in Flugzeugen [4]. Befindet sich das System in einem störungsfreien Zustand, so sind die jeweiligen Signalquellen des Cockpits ausgeschaltet. Erst bei einer notwendigen Reaktion

238

von Piloten wird das Signalelement des jeweiligen Parameters aktiviert. Durch den deutlichen Kontrast zum dunklen Cockpit kann die Aufmerksamkeit von Bedienern unmittelbar auf das Signalelement gelenkt werden. Dieses Prinzip lässt sich entsprechend auf andere Industriebereiche übertragen, indem einerseits positive bzw. unkritische Werte neutral gestaltet und andererseits Fehler und kritische Werte hervorgehoben werden (vgl. Abbildung 5). Eine weitere Möglichkeit, Informationen leichter lesbar zu gestalten und Komplexität zu reduzieren, besteht in der Verwendung unterschiedlicher Informationsformate. Abhängig vom Kontext einer Anwendung können Visualisierungen, die Anwendern aus der Alltagswelt vertraut sind, in Benutzeroberflächen Verwendung finden. So bietet es sich an, beispielsweise Geschwindigkeitswerte als analoge Tachos mit hinterlegten Grenzbereichen zu präsentieren (vgl. Abbildung 6). Dies erleichtert Benutzern die Zuordnung von Werten und liefert gleichzeitig eine Information über den aktuellen Status. Grundsätzlich sollte der Informationsgehalt von Wertedarstellungen in einem gegebenen Verwendungszusammenhang sorgfältig überprüft werden. Unter Umständen ist die Darstellung eines aggregierten Wertes, wie etwa die Differenz zweier Werte, sinnvoller und erleichtert die Erkennung von Fehlerzuständen. Die Komplexität eines HMI richtet sich neben der Informationsvielfalt auch nach der Art der Maschine. Serienmaschinen verfügen in der Regel über einen festen Umfang von Funktionen und Inhalten mit kleineren Varianten, so dass eine Bedienoberfläche auf den bekannten Umfang abgestimmt werden kann. Individualmaschinen hingegen setzen typischerweise eine gewisse Skalierbarkeit des HMI voraus. Mögliche Erweiterungen der Maschine oder unterschiedliche Anordnungen von Maschinenelementen können einen erheblichen Einfluss auf die Qualität des HMI ausüben. Auch im Falle solcher Änderungen muss eine einfache und konsistente Bedienung gewährleistet werden.

Grundsätzlich ist es empfehlenswert, die einzelnen Bereiche einer Anwendung so generisch wie nötig aufzubauen, da jeder Bereich der Anwendung von einer Erweiterung betroffen sein kann. Durch eine Maschinenerweiterung können neue Navigationspunkte, Funktionen, Kennwerte, Statusanzeigen oder Visualisierungselemente hinzukommen, die sich ohne Probleme in das Konzept integrieren lassen müssen. Aus diesem Grund sollte bereits bei der Entwicklung eines HMIKonzepts immer die minimale und maximale Ausprägung darzustellender Inhalte berücksichtigt werden, um auf Änderungsanforderungen reagieren zu können. [Abb. 4], [Abb. 5], [Abb. 6] 2.3. Benutzerrollen Wie bei Desktopanwendungen, so existieren auch im industriellen Kontext unterschiedliche Benutzerrollen für ein System. Hierbei können sowohl der Stand der fachlichen Ausbildung sowie die vorhandenen IT-Kenntnisse von Benutzern stark variieren. Zusätzlich ist in vielen Unternehmen ein häufiger Wechsel von Mitarbeitern und ihren Aufgaben gegeben, so dass eine der Hauptanforderungen darin bestehen kann, eine leichte Einarbeitung von Benutzern zu fördern und sie in ihrer Tätigkeit umfassend zu unterstützen. Aus diesem Grund ist es sinnvoll, ein HMI durch unterschiedliche Informationsebenen zu gliedern. Die oberste Ebene stellt alle Informationen und Funktionen bereit, die der Hauptanwender für eine effiziente Bearbeitung benötigt. Auf diesem Weg wird die Übersichtlichkeit und ein schneller Zugriff auf Routineelemente während des Betriebs unterstützt. Weitere Ebenen können dann beispielsweise detaillierte Analysen oder administrative Vorgänge umfassen, die in den meisten Fällen außerhalb des Arbeitsumfangs des normalen Benutzers liegen. Diese Arbeitsvorgänge werden vor allem von Schichtleitern, Servicemitarbeitern oder Administratoren durchgeführt, welche mit dem System meist vertraut sind und unter Umständen das alleinige Zugangsrecht zu diesen Bereichen innehaben.


Usability Professionals 2012 User Experience

Abb. 7. Button ohne und mit Aufforderungscharakter

Um systemseitig eine Unterscheidung zwischen einzelnen Benutzerrollen treffen zu können, muss eine Identifizierung von Benutzern stattfinden. Der Einsatz eines Standard-Logins mit Benutzer ID und Passwort stellt eine Möglichkeit dar – jedoch birgt dies verschiedene Risiken und Probleme. Wechselt ein Benutzer beispielsweise regelmäßig zwischen unterschiedlichen Stationen, so ist dieses Verfahren zum einen zeitaufwändig, da der Benutzer sich immer wieder ein- und ausloggen muss, und zum anderen risikobehaftet, da das Ausloggen leicht vergessen wird und so ein Missbrauch von Nutzungsrechten entstehen kann. Eine Erweiterung des Standard-Logins ist der automatische Logout. Ein Benutzer wird nach einer festgelegten inaktiven Zeitspanne automatisch durch das System abgemeldet. Diese Lösung mindert zwar das Risiko eines Logout-Versäumnisses, wirft jedoch neue Fragen auf. Die Bestimmung einer angemessenen Zeitspanne ist problematisch, da ein zu kurz gewähltes Intervall ein erneutes Einloggen erzwingt und somit wiederum Zeit in Anspruch nimmt. Ein zu langes Intervall beugt wiederum dem Missbrauch nicht vor. Alternativen wie RFID oder Chipkarten können diese Probleme lösen. Der Benutzer wird automatisch über die Erkennung des Funksignals oder das Lesen des Chips angemeldet. Ist die Entfernung für das Signal zu weit oder wird der Chip entfernt, so wird der Benutzer systemseitig automatisch abgemeldet. Dadurch spart sich der Benutzer die Eingabe der Informationen und kann direkt mit seiner Arbeit beginnen.

Abb. 8. Analogien zu realen Bedienelementen

Welcher Mechanismus jeweils geeignet ist, hängt vom speziellen Anwendungskontext und den zu beachtenden Sicherheitsstandards ab. 2.4. Eingabemethoden Die zunehmende Verbreitung von touchbasierten Endgeräten verschiedenster Art hat auch einen Einfluss auf die Gestaltung industrieller Bedienoberflächen genommen [5]. Obwohl sich manche Unternehmen auf Grund von spezifischen Konstellationen oder bestehenden Normen und Richtlinien auch weiterhin auf die Nutzung von Eingabemöglichkeiten wie Hard Keys, Tastatur, Maus oder Trackball beschränken, lässt sich in zahlreichen Projekten ein Trend in Richtung Touch-Displays beobachten. Touch-HMIs ermöglichen häufig eine intuitivere Bedienung, da Benutzer auf eine natürlichere Art und Weise mit der Oberfläche interagieren können, weshalb in diesem Zusammenhang oft von Natural User Interfaces (NUI) [3] gesprochen wird. Zusätzlich ist durch solche Interfaces der Bezug zwischen Ein- und Ausgabe deutlicher, da die durch eine Interaktion ausgelöste Änderung im Blickfeld des Benutzers stattfindet. Eine erlebte Direktheit der Bedienung setzt jedoch voraus, dass Schaltflächen groß genug sind [6] und interaktive Elemente einen deutlichen Aufforderungscharakter besitzen (vgl. Abbildung 7: Button ohne und mit Aufforderungscharakter). In Verbindung mit der direkten Fingerbedienung bietet es sich bei Touch-HMIs an, Analogien zu

realen Bedienelementen wie Drehreglern, Schaltern oder ähnlichem aufzugreifen und Benutzern so einen Bezug zu bekannten Elementen und Verhaltensmustern an die Hand zu geben (vgl. Abbildung 8: Analogien zu realen Bedienelementen). Dies fördert die Bediensicherheit von Benutzern, beugt Fehlbedienungen vor und erleichtert den Einstieg. Neben der Darstellung spielt die Anordnung von Elementen bei Touch-HMI eine wichtige Rolle. Häufig genutzte Funktionen sollten beispielsweise am unteren Rand des Bildschirms angeordnet werden, um diesen während der Bedienung nicht mit dem Arm oder der Hand zu verdecken (Screen Coverage) und zum anderen die körperliche Anstrengung so gering wie möglich zu halten. Aus der Sicht eines HMI Designers ist die Wahl des Touchscreen-Typs ein entscheidender Faktor für das Konzept eines HMI, da Eigenschaften wie Auflösung, Format oder Art der Gestenerkennung grundlegend unterschiedliche Voraussetzungen mit sich bringen. Vor allem die Unterschiede zwischen resistiven und kapazitiven Monitoren sowie Single-, Dual- oder Multi-Touch beeinflussen das Konzept und die Bedienung der Oberfläche. Resistive Monitore erfordern im Gegensatz zu kapazitiven eine gewisse Druckstärke um eine Geste bzw. Aktion zu erkennen. Dies kann dazu führen, dass der Kontakt während einer fortlaufenden Geste unterbrochen und die erneuten Versuche als mühselig empfunden werden. Kapazitive

239


Abb. 9. Schematische Maschinenvisualisierung

Abb. 10. 3D Modell einer Turbine

Monitore können bereits durch eine leichte Berührung die Position des Fingers erkennen und sind durch ihre Genauigkeit häufig empfehlenswerter. Durch technische Weiterentwicklungen werden auch Dual- und Multi-Touch Monitore zunehmend industrietauglich. Dies ermöglicht die Verwendung von Gesten mit mehreren Fingern, die beispielsweise für die Navigation genutzt werden können. Gerade die Diskussion von Multi-Touch Systemen führt – durch die implizite Anlehnung an touchbasierte ConsumerProdukte – jedoch gelegentlich zu einer übersteigerten Erwartungshaltung bei Industrieprojekten. Häufig werden Interface Designer mit der Annahme konfrontiert, dass durch die Umstellung auf ein touchbasiertes HMI alle bisherigen Probleme auf einen Schlag gelöst werden und die neue Oberfläche um eine Vielzahl von Zusatzfunktionen ergänzt

240

werden kann. Die sorgfältige Analyse der vorgesehenen Nutzungssituation liefert in diesem Zusammenhang eine bedeutsame Entscheidungsgrundlage zur Auswahl eines Designkonzepts für ein Multi-Touch Systems. [Abb. 7], [Abb. 8] 2.5. Maschinenvisualisierung Maschinenvisualisierungen sind ein wichtiges Designmittel zur Illustration eines Fertigungsprozesses oder des strukturellen Aufbaus einer Maschine. Sie können beispielsweise als Orientierungshilfe, zur Navigation innerhalb des Systems oder der Fehlerverfolgung dienen. Wie detailliert eine Maschine dargestellt wird, hängt dabei von der Funktion der Visualisierung und der Komplexität einer Maschine ab. Die Darstellung kann von schematischen Zeichnungen über ausgearbeitete 2D- bis hin zu realistischen 3D-Modellen reichen.

Schematische Darstellungen (vgl. Abbildung 9) und 2D-Modelle bieten sich beispielsweise für eine Übersicht der Komponenten einer Maschine oder einer Anlage an. Auf diese Art kann sich ein Benutzer einen Überblick über sein Arbeitsfeld verschaffen und sich angemessen orientieren. Einzelne Elemente der Visualisierung können gleichzeitig als Absprünge zu Detailanalysen fungieren und so eine Navigation zwischen Bereichen ermöglichen. 3D-Modelle (vgl. Abbildung 10) sind durch ihre detailreichen Darstellungen häufig recht komplex und können unter Umständen zu Performanzeinbußen führen. Eine der Herausforderungen besteht somit in der Bestimmung des Detaillierungsgrads und der korrekten Einbindung einer Visualisierung. 3D-Modelle können unter anderem für Detailanalysen verwendet werden, da sie meist über mehr Details verfügen und durch die perspektivische Darstellung


Usability Professionals 2012 User Experience

dem Benutzer eine andere Sicht auf die Maschine ermöglichen. Kombiniert mit einer Zoom-Funktion und gegebenenfalls einer Multi-Touch-Bedienung erfährt der Benutzer somit ein neues Bedienerlebnis bei der Analyse von Maschinenzuständen. Ein weiterer Faktor für die Einbindung einer Maschinenvisualisierung ist die verwendete Visualisierungstechnologie. Die Wahl der Technologie ist entscheidend für die Entwicklung eines HMI, da diese für Interface Designer bestimmte Einschränkungen mit sich bringt. Vor allem bei Anbietern von Automatisierungsframeworks, die auf einer bestehenden Technologie aufbauen, müssen häufig Einschränkungen, zum Beispiel bei der grafischen Umsetzung, berücksichtigt werden. So können unter Umständen speziell konzipierte Custom Controls im Nachhinein nicht umgesetzt werden, da lediglich ein festes Set an Elementen angeboten wird, das nicht erweitert oder flexibel kombiniert werden kann. Es sollte daher genau evaluiert werden, welcher Anbieter und welche Technologie die passende ist und welchen Aufwand die Entwicklung mit sich bringt. Auf der einen Seite kann eine bereits bekannte Entwicklungsumgebung Aufwand und somit Kosten einsparen. Andererseits müssen dadurch eventuell Abstriche bei der Umsetzung gemacht werden, falls die Technologie bestimmte Konzepte oder Ansätze nicht unterstützt. Moderne Technologien wie Microsoft WPF oder Nokia Qt bieten hier deutlich mehr Freiheiten und Vorteile als bisherige Ansätze und erlauben insbesondere auch eine effiziente Realisierung von MultiTouch-Anwendungen. [Abb. 9], [Abb. 10]

geprägt. Oft bestehen Fehlermeldungen aus einer ID und einem kryptischen Titel, die kaum Rückschlüsse auf Art, Ort oder Ursache des Fehlers oder geeignete Handlungen zu dessen Beseitigung zulassen. Benutzern sollte vermittelt werden, um welchen Fehler es sich jeweils handelt, welche Systemkomponenten genau betroffen sind, was die potentielle Ursache für einen Fehler ist und vor allem wie genau dieser behoben werden kann. Diese Informationen sollten Benutzern möglichst leicht zugänglich gemacht werden. Aus diesem Grund sollte eine Alarmseite zentraler Bestandteil eines HMI sein und prominent platziert werden. Mit Hilfe einer solchen Übersicht hat ein Benutzer immer die Möglichkeit, sich einen Überblick über den Status der Maschine zu verschaffen. Zusätzliche Anzeigen wie temporäre Flyouts oder permanente Anzeigen in Statusleisten helfen unterstützend, die Benutzer auf Probleme aufmerksam zu machen. Wurde ein Fehler identifiziert, so besteht die wichtigste Aufgabe darin, einen Benutzer bei der Behebung der Störung zu unterstützen. Hierzu sollten klare Handlungsempfehlungen formuliert werden, so dass ein Anwender direkt reagieren kann. Dies können textuelle Beschreibungen,

Bilder oder Aktionen sein, falls ein Fehler mit Hilfe der Software behoben werden kann (vgl. Abbildung 11). [Abb. 11] 3. Fazit HMI müssen eine Vielzahl an kontextspezifischen Anforderungen erfüllen, um im Fertigungsprozess effektiv, effizient und sicher eingesetzt werden zu können. Aus diesem Grund ist die Sensibilisierung von Herstellern, Ingenieuren und Designern für die Bedeutsamkeit der in den vorausgegangenen Abschnitten genannten Spezifika nach wie vor eine wichtige Aufgabe im Kontext maschinennaher HMI. Getrieben durch den Einfluss von Consumer-Produkten und neuen technischen Möglichkeiten im Hinblick auf innovative Eingabe- und Visualisierungsmöglichkeiten werden auch die Anforderungen an HMI stetig wachsen und die Kompetenz von Spezialisten erfordern. Aus diesem Grund ist es unerlässlich, dass Interface Designer und Hersteller grundlegende Richtlinien und Prinzipien der benutzerzentrierten Gestaltung befolgen, um die Qualität von HMI durchgängig und nachhaltig zu gewährleisten.

2.6. Fehlerverfolgung Die Fehlerverfolgung ist eine zentrale Anforderung im maschinennahen Bedienkontext. Fehler im Prozessablauf und an der Maschine müssen schnell erkannt und behoben werden, zeitliche Verzögerungen können zu einem Verzug der Produktion oder sogar zu gefährdenden Situationen führen. Gerade die Fehlerdarstellung ist bei vielen Systemen sehr technisch

Abb. 11. Fehlermeldung

241


Anforderung / Problemstellung Beschreibung Komplexität

Hinweis / Empfehlung

–– Unübersichtlichkeit durch hohe Datendichte –– Erschwerte Wahrnehmung wichtiger Werte

Benutzerrollen

Eingabemethoden (Touch)

–– Gliederung der Inhalte in Informationsebenen

IT-Kenntnissen –– Mangelnder Komfort und Rechtekontrolle bei Nutzer-Login

–– Verwendung von RFID oder Chipkarten.

–– Unter Umständen mangelnde Selbst-

–– Schaltflächen müssen über ausreichende Größe und

–– Häufig unnötig komplexe Darstellung –– Beachtung von technologieabhängigen Visualisierungseigenschaften und Einschränkungen

Fehlerverfolgung

Benutzerrollen

–– „Progressiv Disclosure“ –– „Dark Cockpit“-Prinzip –– Kontextspezifische Informationsvisualisierung

–– Starke Unterschiede in Ausbildung und

beschreibungsfähigkeit interaktiver Bedienelemente –– „Screen Coverage“-Problematik bei Handbedienung –– Einfluss der Touch-Screen-Technologie und Größe auf Bedienkonzepte

Maschinenvisualisierung

–– Reduktion durch Informationszuschnitt auf

–– Erschwerte Erkennbarkeit des aktuellen Maschinenstatus –– Technische Prägung der Fehlerkommunikation und mangelnde Lösungsanleitung

entsprechend der Benutzerrollen

deutlichen Aufforderungscharakter verfügen

–– Analogien zu realen Bedienelementen wie Drehreglern und Schaltern können die Wahrnehmung unterstützen –– Anordnung häufig genutzter Funktionen am unteren Bildschirmrand –– Heutiger Stand: Kapazitive Dual Touch-Monitore, häufig als 16:9

–– Schematische und 2D-Modelle können als Übersicht zur besseren Orientierung oder Navigation dienen.

–– 3D Modelle bieten mehr Details und perspektivische Darstellung. Können jedoch zu Performanzproblemen führen. –– Moderne Technologien wie Microsoft WPF und Nokia QT bieten viele Freiheiten und Vorteile.

–– Alarmseite als zentraler UI-Bestandteil –– Nutzung temporärer, amodaler Anzeigen und Statusleisten

–– Fehlermeldungsinhalte: Typ, Auswirkung und Ursache, Handlungsempfehlung.

Tab. 1. Anforderungen und Problemstellungen an HMI in industriellen Kontexten

Literatur 1. Cooper, A., Reimann, R & Cronin, D. (2007).

5. Wölwer, S. (2012). Die Industrie braucht User-

About Face 3: The Essentials of Interaction

Interface-Design!. Weave, 01.12, 22 – 28.

Design. Indianapolis: Wiley Publishing, Inc.

6. Wroblewski, L. (2010). Touch Target Sizes.

2. ISO, ISO 11064-4 First edition 2004-07-01, Ergonomic design of control centres – Part 4: Layout and dimensions of workstations. 3. Nui Group. http://nuigroup.com/go/lite/ about/ (24. Juni 2012) 4. Sweetman, B. (1981). Automatic airliners – ready for take off?. New Scientist, 1277, 302 – 305.

242

http://www.lukew.com/ff/entry.asp?1085. (24. Juni 2012


Usability Professionals 2012 User Experience

243


Mobile User Experience Engineering – Mit Methodik und der richtigen Technologie zu erfolgreichen Apps Mischa Demarmels Zühlke Engineering AG Wiesenstrasse 10a 8952 Schlieren (Zürich), Schweiz Mischa.Demarmels@zuehlke.com

Katja Neumann Zühlke Engineering AG Wiesenstrasse 10a 8952 Schlieren (Zürich), Schweiz Katja.Neumann@zuehlke.com

Abstract Die rasante Verbreitung von Mobile Apps auf immer besserer Hardware hat auch zu einem steigenden Anspruch der Anwender in Bezug auf die gebotene Funktionalität und die Benutzerfreundlichkeit geführt [Vgl. 1]. Schnelle Datennetze und Cloud Dienstleistungen verstärken die Erwartungen der Benutzer nach visuell ansprechenden und interaktiven Apps, die ortsunabhängig funktionieren und überall den Zugriff auf Daten ermöglichen. In diesem Kontext wird die Bedeutung von User Experience (UX) im Entstehungsprozess einer App immer größer. Das Erreichen einer hohen UX ist dabei eine Herausforderung, die von vielen Faktoren beeinflusst wird. Design und gute Bedienkonzepte sind ebenso wichtig wie die enge Verzahnung mit End-to-End Software Engineering. In diesem Beitrag wird das Engineering von Mobile Apps anhand von abgeschlossenen Praxisprojekten beleuchtet. Die gesammelten Erfahrungen werden im Kontext von UX diskutiert.

1. User Experience und Mobile Technologien Wegen des rasanten Erfolgs von mobilen Endgeräten und der angeschlossenen Ökosysteme haben sehr viele Unternehmen in den letzten Jahren mit Hochdruck eigene Apps veröffentlicht. Wer UX nicht von Anfang an berücksichtigt hat, wurde in vielen Fällen von schlechten Rezensionen oder ausbleibendem Interesse überrascht. Die Benutzer-Feedbacks in den öffentlichen App Stores und die damit verbundenen Risiken für die Reputation eines Unternehmens forcieren die Einbindung von UX Expertise in den Entwicklungsprozess. Kunden und Fachabteilungen rufen inzwischen sogar selbst den Bedarf an UX Design und Methodik aus. Wer hätte das vor wenigen Jahren für möglich gehalten? UX-Experten hatten in der Vergangenheit oft einen eingeschränkten Wirkungskreis und konnten ihre Methoden nicht nachhaltig in die Wertschöpfungskette integrieren. Für unser Fachgebiet sind Apps eine fantastische Entwicklung. Endlich ist das Thema UX bei allen Entscheidungsträgern angekommen. Und auch im Volksmund ist

244

es zum Synonym der ganzheitlichen Erfahrung mit einem Produkt oder einer Applikation geworden. Man könnte von einem Zeitalter der Mobile UX sprechen, die der Thematik einen neuen Schub verliehen hat – zum Vorteil der Anwender und Unternehmen. Letztere haben verstanden, dass nicht nur die Usability einer App Auswirkung auf deren Wahrnehmung und Erfolg beim Benutzer hat. Auch der Einfluss vieler weiterer Faktoren, wie beispielsweise die Qualität der Hardware-Materialien, die vom Hersteller kommunizierten Werte oder das in der App reflektierte Image eines Unternehmens [2] spielen eine wichtige Rolle. Das iPhone war das erste Smartphone, das für viele UX-Aspekte, darunter sein Design, seine Benutzerführung und seine Performance, sehr gelobt wurde. Zudem erzielte das iPhone eine Benutzer- und Markenakzeptanz, die es so zuvor nicht gegeben hat [3; 4]. Andere Plattformen haben aber zwischenzeitlich stark aufgeholt. Die Android-Plattform hat iOS weltweit bereits als meist genutztes Operating System (OS) für Smartphones abgelöst, während Windows Phone noch nicht zu den acht

Dr. Thomas Memmel Zühlke Engineering AG Wiesenstrasse 10a 8952 Schlieren (Zürich), Schweiz Thomas.Memmel@zuehlke.com

Keywords: /// Mobile, User Experience /// Usability /// Software Engineering /// Praxisbericht

meistgenutzten Betriebssystemen der Welt zählt [5; 6]. Die Fragmentierung des Mobile-Marktes ist Fluch und Segen zugleich. Für die Anwender ist der Wettbewerb erfreulich, da UX im Kampf um die Gunst der Kunden einen hohen Stellenwert einnimmt. Unternehmen stehen jedoch vor der Entscheidung, für welche Plattform(en) sie eine App entwickeln sollen. Eine Rolle spielt hier auch, dass das Vorhalten notwendigen Know-hows und die Betriebskosten für mehrere verschiedene Plattformen Budget verschlingt. [Abb. 1] Während anfänglich der Druck mit Apps auf den Markt zu kommen die Investitionsbudgets sprudeln ließ, verändern sich die Mobile-Strategien nach und nach in Richtung Cross-Plattform Entwicklung. Dieser Ansatz stellt die Verwendung des gleichen Codes für verschiedene Plattformen in Aussicht. Bei diesem Szenario gibt es jedoch starke Abhängigkeiten zum UX Design, denn trotz gleichen Codes erwarten die Anwender weiterhin natives Look & Feel und eine hohe Performance. Um eine App auf mehrere Plattformen zu


Usability Professionals 2012 User Experience

Abb. 1. Vier verschiedene Techniken Apps auf mehrere MobilePlattformen zu bringen: Native Apps, WebApps, Hybrid Apps, Cross-Compile Apps

bringen, kann man sich somit verschiedener Techniken bedienen. Zum besseren Verständnis für das Zusammenspiel von App-Ansatz und UX werden nachfolgend die vier wichtigsten Techniken vorgestellt: Die Entwicklung von nativen, Web- und Hybrid-Applikationen sowie Cross-Compile Ansätze (siehe Abb. 1). Wenn man Apps nativ entwickeln möchte, bedeutet dies eine separate Umsetzung für jede Plattform. Vorteil dieses Vorgehens ist, dass die maximale UX erreicht werden kann, da native Apps auf alle System-Features uneingeschränkt zugreifen können und die App ganz auf das Interaktionskonzept und das Look & Feel der Plattform zugeschnitten werden kann. Für eine native App-Strategie bedarf es demnach Spezialisten für jede Plattform. Dass die komplette Applikation für Anzahl x unterstützte Plattformen auch x-mal entwickelt wird, treibt letztendlich auch die Entwicklungskosten in die Höhe. Klassische Web-Applikationen können durch diverse CSS und Javascript Frameworks (z. B. jQuery Mobile [7], Sencha Touch [8]) für Smartphones und Tablets optimiert werden. Mit dieser Technik können alle mobilen Plattformen auf einen Streich angebunden werden, da die App direkt im mobilen Webbrowser über eine URL gestartet wird. Dadurch verliert man aber die Möglichkeit die Applikation über den App-Store – ein sehr wichtiges

Marketinginstrument – zu verbreiten, wodurch diese Apps eine deutlich geringere Sichtbarkeit aufweisen. Das plattformspezifische Interaktionskonzept und das Look & Feel bleiben bei dieser Methode notgedrungen mehr oder weniger auf der Strecke. Darüber hinaus kann mit der WebApp-Technologie nur sehr beschränkt auf System-Features zugegriffen werden (z. B. Smartphone-eigenen Kamera, Kontaktdaten, Smartphone-Sensoren, etc.). Einige Nachteile von Web-Apps werden von Hybrid-Apps dadurch kompensiert, dass ein spezielles Framework (z. B. PhoneGap [9]) für jede Plattform einen nativen Wrapper zur Verfügung stellt. Dieser reicht die Plattform-Features weiter, wodurch diese vom eigentlichen Programmcode der App initiiert werden können, z. B. über Javascript-Methodenaufrufe. Dadurch muss der eigentliche Code der App für alle Plattformen nur einmal mit HTML/ Javascript geschrieben werden. Das hat jedoch auch wieder zur Folge, dass das native Look & Feel kaum für jede Plattform erzielt werden kann. Der Cross-Compile Ansatz (z. B. MonoTouch [10]; Titanium [11]) bietet den Entwicklern von Apps ein eigenes Framework mit einer dedizierten „Mainstream“-Programmiersprache (z. B. Javascript oder C#). Dieser Code wird vom Framework automatisch in den jeweils nativen Code der zu unterstützenden Plattformen übersetzt.

Dieser technisch sehr vielversprechende Ansatz birgt aus UX-Perspektive aber den Nachteil, dass nicht auf die plattformspezifischen Applikations- und Interaktionskonzepte eingegangen werden kann, da die Apps auf allen Plattformen den gleichen Code teilen. Zum Teil wird diesem Problem begegnet, indem neben dem gemeinsamen Code (z. B. Business Layer und Backend-Anbindung) manuell nativer Code für das UI der einzelnen Plattformen in die Codebasis eingepflegt wird. Dies bildet dann einen Kompromiss zwischen nativer und Cross-Compile Entwicklung (siehe [10]). Erfahrungen aus entsprechenden Projekten zeigen, dass mit dieser Herangehensweise und bei geeigneter Softwarearchitektur immerhin 50% Code Reuse erzielt werden kann. 2. Projekt-Steckbriefe In diesem Abschnitt werden Erfahrungen aus verschiedenen Mobile-Projekten aufgezeigt und diskutiert. Für den Einblick in die Projekte haben wir Interviews mit Entwicklern, UX- Experten und Projektleitern geführt. Insgesamt wurden Erkenntnisse aus sieben Projekten gesammelt, wovon an dieser Stelle drei näher beleuchtet werden sollen. 2.1. My Swisscom App (iOS, Android, Web-App) Die Ausgangslage des Projekts war ein nur mäßig erfolgreicher Umsetzungsversuch mit einem Cross-Compile Ansatz, der neben technischen Problemen auch nur eine geringe UX aufwies und entsprechend unbefriedigendes Feedback in den App Stores erzielte. Daraufhin wurde eine völlige Neuentwicklung der My SwisscomApp als Native- (iOS, Android) und WebApp beschlossen. Die My Swisscom App sollte ausgewählte Funktionen zur Verwaltung des persönlichen Portfolios von Swisscom-Privatkunden (z. B. Optionen- und Abo-Verwaltung, Kosten- und Rechnungskontrolle, etc.) zusätzlich zu einem bereits bestehenden Webportal für Desktop Computer als

245


Abb. 2. My Swisscom App für iPhone (links), für Android (Mitte) und als WebApp (rechts). Die dargestellten Daten unterscheiden sich aufgrund leicht unterschiedlicher AppKonzepte etwas voneinander.

mobile App zur Verfügung stellen. Der Vorteil: Kunden haben ihre Kosten jederzeit im Blick und können wichtige Änderungen an ihrem Portfolio von überall vornehmen. Des Weiteren können Anrufe im Callcenter reduziert werden. Damit alle Swisscom Privatkunden gleichermaßen von diesem Angebot profitieren, wurde das App Projekt für die beiden mobile Plattformen iOS [12] und Android [13], die in der Schweiz mit Abstand am weitesten verbreitet sind, gleichzeitig umgesetzt. Zudem wurde für Kunden mit anderen mobilen Betriebssystemen (Windows Phone, BlackBerry, Symbian, etc.) die entsprechende Funktionalität parallel als Web-App [14] entwickelt, auf die beim Besuch der vorhandenen Desktop-Webseite über eine Browsererkennung umgeleitet wird. [Abb. 2] Das Ziel des Projektes war eine signifikante Steigerung der Nutzerzufriedenheit und die End-to-End-Anbindung der App an eine Vielzahl von Backend-Systemen. Dies war notwendig, um den Funktionsumfang der App ausbauen zu können. Die verschiedenen Entwickler arbeiteten zusammen in einem Team, um von erarbeiteten Lösungen gegenseitig profitieren zu können. Diese Zusammenarbeit stellte sich schnell als Vorteil heraus, denn neben der eigentlichen App-Entwicklung musste auch eine serverseitige Komponente implementiert werden, welche die verschiedenen komplex strukturierten Backend-Systeme anbindet, Autorisierungsaufgaben und

246

serverseitiges Caching übernimmt sowie schließlich die Daten über eine RESTSchnittstelle den App-Clients zur Verfügung stellt. Diese Serverkomponente wurde vom ganzen Team gemeinsam definiert, umgesetzt und wird von allen drei Apps gleichermaßen genutzt. Während des Projektes hat das Team, auch aufgrund der vorausgegangenen Erfahrungen und Rezensionen von Version 1 (Cross-Compile Variante), eine größere Erwartungshaltung von iOS-Nutzern an die UX antizipiert. Insgesamt stieg der Aufwand für das UX-Design für alle drei parallelen Vorhaben relativ schnell an. So hatten die Projektbeteiligten zunächst vielfach unterschätzt, dass geeignete Interaktionskonzepte für alle drei Plattformen separat erstellt werden müssen. Die Annahme, ein Konzept auf allen drei Plattformen gleichartig umsetzen zu können, führte immer wieder zu technischen Problemen bei der Umsetzbarkeit des UI und letztendlich auch zu Einschränkungen bei der UX der Apps. Für die Entwicklung der iOS-App bedeuteten einige UI-Designs einen hohen (und oft nicht eingeplanten) Mehraufwand, vor allem wenn diese nicht auf iOSStandard-Komponenten basierten. Dies konnte schnell zu Verzögerungen führen. Die Android-Entwicklung verlief mit bis zu 50% kürzeren Entwicklungszeiten schneller als prognostiziert. Hier war das

UI-Design von Anfang an enger an die Android-Standards angelehnt. Die enge Zusammenarbeit zwischen Grafik-Designern, UX-Experten, Requirements Engineers, Business-Vertretern und den App-Entwicklern war aus Sicht unserer Interviewpartner für das Projekt sehr wichtig und wird für künftige Releases noch weiter verstärkt. Damit Grafik- und UI-Designer nicht an den Möglichkeiten und Realitäten einer Plattform vorbeiarbeiten, sind ein interdisziplinäres Team und eine starke (agile) Kommunikation erfolgsentscheidend. 2.2. Delta Energy System App (Hybrid App) Delta Energy System ist ein weltweit agierender Anbieter von innovativen Stromversorgungslösungen. Zusätzlich zu der bereits vorhandenen umfangreichen LaptopLösung mit Web-Schnittstelle und einem kleinen LCD-Display am Gerät, soll den Wartungsmitarbeitern eine Smartphone Applikation für die effiziente Durchführung von routinemäßigen Wartungsarbeiten und die einfache Verwaltung mehrerer Anlagen zur Verfügung gestellt werden. Das Ziel dieses Forschungsprojektes bestand darin, eine geeignete Technologie für diese Smartphone Anwendung zu evaluieren und anhand eines Prototyps deren Tauglichkeit für den Feldeinsatz zu überprüfen.


Usability Professionals 2012 User Experience

Abb. 3. Delta Engergy App für das iPhone entwickelt mit einem Hybrid-Ansatz

Für den Auftraggeber war eine hohe UX ein entscheidendes Ziel. Gleichzeitig gab es Anforderungen zur Wart-, Adaptier- und Portierbarkeit der App. Auch die Verbreitung der verschiedenen Smartphones im Weltmarkt spielte eine entscheidende Rolle bei der Technologiewahl. Zudem sollte die Applikation schnell auf individuelle Anlagen anpassbar sein. Aus diesen Gründen fiel die Entscheidung auf eine Hybrid-App Lösung mit HTML5, JavaScript, jQuery Mobile und PhoneGap als Umsetzungstechnologien. So konnte eine Codebasis für alle Plattformen verwendet werden und die Entwickler von Delta konnten auf vorhandenem Web Know-how aufbauen. Der Fokus der ersten Version lag auf der Unterstützung für das iPhone. [Abb. 3] Die Entscheidung für den Hybrid-Ansatz war letztendlich ein Kompromiss zwischen effizienter Entwicklung, Erweiterbarkeit und einer guten UX. Trotz grosser Anstrengungen, die App mit CSS3 auf iPhone Look zu trimmen, reagiert die Anwendung im Vergleich zu einer nativen Lösung langsamer. Dies ist mehr auf den Reifegrad und die Implementierung des Frameworks (hier jQuery Mobile) zurückzuführen als auf die Verwendung von HTML5/JavaScript. Bei einer Portierung der App z. B. auf Android-Geräte, müsste entweder das UI der App für diese Plattform angepasst werden oder man müsste mit dem iPhone Look & Feel auch in einer eventuellen

Android-App Vorlieb nehmen, was, wie hier, für Business-to-Employee (B2E) Apps vermutlich akzeptabler ist als für Businessto-Consumer (B2C) Apps. Aus Sicht der Entwickler scheint klar, dass eine hohe mobile UX nur mit nativen Lösungen möglich zu sein scheint, da es mit HTML5 nur CSS3 als Möglichkeit gibt, das Screendesign zu optimieren, womit auch alle Zielplattformen gleichzeitig abgedeckt werden müssen. Die Entwickler dieses Projektes haben Zweifel, dass man mit der HTML5-Cross-Plattform Lösung (bzw. Hybrid-Apps) wirklich „schneller“ entwickelt, da sowohl iOS als auch Android jeweils eine sehr gute Tool-Suite anbieten, um Software für die entsprechende Plattform zu entwickeln, wohingegen die existierenden HTML5-Frameworks zur Zeit des Projektes zum Teil noch etwas unausgereift waren und dementsprechend häufig vorhandene Unzulänglichkeiten mit Workarounds umschifft werden mussten. Ein Beispiel hierfür ist die Implementierung von Tabs und scrollbarem Content zugleich – jedes Interaktionselement für sich kann problemlos mit JQuery Mobile umgesetzt werden, möchte man beide allerdings zusammen einsetzen, d. h. scrollbarer Content in einer Tab-Struktur, dann ist die Implementierung zum Erreichen einer guten UX ohne Ruckeln der Tabs sehr aufwändig. Deshalb könnte man vermutlich auch eine native iPhone-App schneller entwickeln als eine Hybrid-Lösung,

insbesondere mit der neuen iOS Storyboard Technologie, mit der relativ einfach mehrere Screens einer Applikation (inkl. der Übergänge zwischen den Screens) auf einmal mit dem GUI-Designer „entwickelt“ werden können [15, 16]. Für eine weitere native Android-App bräuchte man eventuell auch nicht viel mehr Zeit (abhängig natürlich vom Umfang und Inhalt der jeweiligen App). Letztendlich würden die Entwickler HTML5-Crossplatform Lösungen aktuell nur empfehlen, wenn bewusst gewisse Abstriche beim UI und bei der UX in Kauf genommen werden können, was beispielsweise bei gewissen B2E Applikationen durchaus akzeptabel ist. 2.3. XING App (Windows Phone) Die Entwicklung der XING-App für das Windows Phone geschah in enger Zusammenarbeit von Zühlke, Microsoft und XING. Die Qualität und die Reichweite der Applikation standen dabei im Vordergrund. Bei einer B2C App entscheiden die Benutzer über den Erfolg der Applikation – bei nativen Apps sind dies z. B. die Bewertungen im Store. In diesem Zusammenhang waren eine hohe UX und gute Rezensionen sehr wichtig. Natürlich kommen bei einer XING App auch hohe Performance-Anforderungen und Skalierbarkeit hinzu – vom gelegentlichen

247


XING-Benutzer bis zum Power User mit tausenden Kontakten existiert ein breites Spektrum. Gleichzeitig war das Ziel in Kooperation mit Microsoft eine Top-App für die neue Windows Phone-Plattform zu entwickeln, die einerseits die gleichen inhaltlichen Features wie die anderen XING Apps bietet und andererseits das spezifische Windows Phone Interaktionsdesign gut umsetzt (siehe Abb. 4). Neben der Kundenseite war in diesem Projekt somit auch der Plattformhersteller involviert – eine spannende und außergewöhnliche Konstellation. [Abb. 4] Unter den größten Herausforderungen in diesem Projekt waren die Erreichung einer hohen Performance, die Umsetzung der Metro Design Guidelines – hier insbesondere die Gestaltung des Live Tiles – sowie die Sicherstellung einer guten UX mit Hilfe von zahlreichen Reviews, Tests und der kontinuierlichen Verarbeitung von Benutzer-Feedbacks im Anschluss an die Veröffentlichung der App. Hinsichtlich der Performance war es in diesem Projekt nützlich, nicht nur die tatsächliche Performance zu optimieren, sondern auch die wahrgenommene Performance zu berücksichtigen, da für den Benutzer letztendlich die wahrgenommene Reaktion der Anwendung zählt. Insbesondere bei einer neuen Plattform wie Windows Phone 7 ist es für eine erfolgreiche App unerlässlich, jemanden im Projekt zu haben, der sich mit den Plattformspezifitäten auskennt. Die Live Tile ist eine Kachel, die der Anwender auf dem Startbildschirm von Windows

Phone platzieren kann. Die Kachel bringt idealerweise die interessantesten Informationen aus der App an die Oberfläche und verhindert so das unnötige Starten der App. Für das Design einer Live Tile sollte ausreichend Zeit eingeplant werden, wobei schnelle und zahlreiche Design-Iterationen für ein optimales Ergebnis empfehlenswert sind (in diesem Fall waren es ca. 20 Iterationen) (siehe Abb. 5). Der größte Nachteil dieser Plattform besteht in ihrer momentan noch sehr geringen Reichweite – sowohl in Deutschland als auch in der Schweiz macht Windows Phone weniger als 5% aller mobilen Betriebssysteme aus [6]. [Abb. 5] 3. Erkenntnisse und Empfehlungen Die drei vorgestellten Projekte verdeutlichen, dass sich sowohl die Technologiewahl als auch das App-Konzept auf die UX auswirken – und umgekehrt. Aus den beschriebenen Projekten und den Interviews, die wir mit Entwicklern, UXExperten, Auftraggebern und Projektleitern geführt haben, wollen wir nachfolgend einige Erkenntnisse und Empfehlungen für Mobile Projekte ableiten. 3.1. Technologiewahl und UX Die Entscheidung für die richtige MobileTechnologie muss in jedem Projekt neu getroffen werden, da es verschiedene und je nach Kontext und Ziel unterschiedlich

relevante Parameter zu beachten gibt. Dazu gehören zum Beispiel Entwicklungsbudget, vorhandenes Know-how, Funktionalität, UX-Ziele und Anforderungen an das Look & Feel. Grundsätzlich bieten sich zwei Strategien an: die native Entwicklung getrennt für alle Plattformen oder die Verwendung von Frameworks zur einfacheren Übertragung einer App auf verschiedenen Plattformen. Bei der nativen Entwicklung ist es oft nötig neues Know-how aufzubauen, da es nur wenige UX-Experten und noch weniger Entwickler gibt, die auf allen MobilePlattformen gleichermaßen mit Erfahrung aufwarten können. Gerade für iOS ist es noch schwierig erfahrene Entwickler zu finden. Für neue Plattformen wie dem kommenden Windows 8/Metro UI müssen sich auch UX-Experten mit einer weiteren Mobile-Plattform auseinandersetzen. Der Cross-Compile- und der Hybrid-Ansatz versprechen gleichermaßen eine Senkung der Entwicklungskosten, da wesentliche Teile des Projektes nur einmal entwickelt werden müssen. Aber auch hier gilt: wenn das gewählte Framework neu für die Entwickler ist, brauchen sie auch hier Einarbeitungszeit. Dies wirft die Frage auf, ob in diesem Fall der Cross-Compile Ansatz wirklich in der Lage ist eine native Entwicklung zu übertrumpfen. Ein weiteres Problem besteht darin, dass es momentan viele Frameworks gibt, von denen jedes einzelne Stärken und Schwächen in gewissen Bereichen aufweist. Hier auf das richtige Pferd zu setzen ist nicht einfach

Abb. 5. Die Live Tile der XING App für Windows Phone 7

Abb. 4. Ein Ausschnitt der Panorama-Ansicht der XING App für Windows Phone 7

248


Usability Professionals 2012 User Experience

und erfordert viel Erfahrung und Kenntnisse von allen technischen Lösungen. Unsere Interviewpartner waren sich in einem Punkt einig: Cross-Compile-, Hybrid-App- und Web-App-Ansatz bedeuten klare Abstriche bei der UX im Vergleich zu nativ entwickelten Apps.

weiterentwickeln zu können. Stetige kleine Releases, die eine App verbessern, werden von den Nutzern in der Regel positiv aufgenommen.

Technische Probleme wie Device-Fragmentierung, Versionsunterschiede des Betriebssystems und die Connectivity-Problematik haben im Mobile-Bereich viel stärkeren Einfluss auf die Arbeit des UX-Experten, von dem sehr großes Know-how und Erfahrung erwartet wird. Auch das Testen auf den verschiedenen mobilen Endgeräten spielt eine zentrale Rolle bei der Umsetzung von Multi-Plattform Projekten.

Ein erfahrener UX-Experte mit plattformspezifischen Kenntnissen ist in einem Mobile-Projekt unverzichtbar und sollte dort eine zentrale Rolle einnehmen. Neben der Anwendung von UX- Methoden ist es auch seine Aufgabe zwischen Fachseite und Entwicklung zu vermitteln und schon bei der Spezifikation der Anforderungen darauf zu achten, dass diese benutzergerecht erhoben werden und auf den verschiedenen Plattformen kostenbewusst umsetzbar sind. Da der UX-Experte oft die Person mit dem besten Überblick über die verschiedenen zu unterstützenden Plattformen ist, trägt er in Mobile-Projekten oft mehr Verantwortung als in anderen Projekten. Es ist auch seine Aufgabe, Business, Grafikdesigner und Entwickler auf die Eigenheiten des Mobile-Umfelds aufmerksam zu machen und entsprechend zu coachen.

3.2. Mobile-Strategie Funktionalität alleine reicht bei mobilen Apps nicht aus, wie ein Blick auf die Benutzerkommentare in den verschiedenen App Stores verrät. Die UX einer App spielt eine sehr wichtige Rolle, also z. B. auch, wie eine App und sogar der Anbieter hinter der App von den Benutzern wahrgenommen werden. Apps mit toller UX zu entwickeln ist deshalb weder einfach noch billig. Insbesondere bei der Entwicklung von B2C Apps ist von halbherzig umgesetzten Apps strikt abzuraten, da diese manchmal mehr (Reputations-)Schaden anrichten können als sie Nutzen bringen. Die verschiedenen mobilen Plattformen (iOS, Android, Windows Phone, etc.) spalten ihre Benutzer oft in verschiedene Sympathie-Lager. Und so kann es auch vorkommen, dass der persönliche Geschmack von Entscheidungsträgern in Mobile-Projekten zu einer bestimmten Plattform- bzw. Technologiewahl führt. Hier ist es auch die Aufgabe von UX-Experten solche Entscheidungen zu hinterfragen und womöglich bessere Alternativen aufzuzeigen.

4. Fazit

Cases. Der Stellenwert von B2C und B2E Apps wird weiter zunehmen. Die Entwicklung anspruchsvoller Apps wird auch UX-Experten weiter fordern, aber auch den Stellenwert ihrer Rolle fördern, insbesondere in einem technologisch immer stärker fragmentierten Markt und einer immer UX-bewussteren Benutzerklientel. Quellen 1. Berkman E. & Hoober, S. (2012). Designing Mobile Interfaces. Sebastopol, CA: O’Reilly. 2. http://www.google.de/imgres?hl= de&sa=X&biw=1440&bih=775&tb m=isch&prmd=imvnslb&tbnid=Z-_ O6xpMsYYDzM:&imgrefurl=http://blog. procontext.com/2010/03/usability-unduser-experience-unterscheiden.html&doci d=vDBaKrUEgu3Q8M&imgurl=http://blog. procontext.com/images/posts2010/userexperience-und-usability.png&w=1372&h=75 8&ei=snr8T9uKDoOO8wSf5ZHqBg&zoom=1 (Zugriff am 29.07.2012) 3. http://www.time.com/time/specials/2007/art icle/0,28804,1677329_1678542_1677891,00. html (Zugriff am 29.07.2012) 4. http://www.nytimes.com/2007/06/27/ technology/circuits/27pogue.html?_ r=1&pagewanted=all (Zugriff am 29.07.2012)

Sehr gutes Know-how aller Zielplattformen, der geltenden Style Guides und der Vorgaben beim Interaktionsdesign ist essenziell bei der erfolgreichen Umsetzung von Mobile- Projekten, in denen eine sehr hohe UX angestrebt wird.

5. http://www.netmarketshare.com/ (Zugriff am 29.07.2012) 6. http://gs.statcounter.com (Zugriff am 29.07.2012) 7. http://jquerymobile.com (Zugriff am 29.07.2012) 8. http://www.sencha.com/products/touch

Viel mehr als in anderen Projekten muss im Mobile-Bereich der Nutzungskontext berücksichtigt werden. Anders als z. B. bei Desktop-Anwendungen, welche den Kontext des Benutzers gewissermaßen vorgeben, spielen bei mobilen Apps externe Faktoren eine entscheidende Rolle, wie zum Beispiel die Qualität der mobilen Internetverbindung, die aufwändigere Eingabe von Text via Touchscreen und die Unterbrechung der App-Nutzung, z. B. durch eingehende Anrufe.

(Zugriff am 29.07.2012) 9. http://phonegap.com (Zugriff am 29.07.2012) 10. http://xamarin.com/monotouch (Zugriff am 29.07.2012) 11. http://www.appcelerator.com/platform/ titanium-sdk (Zugriff am 29.07.2012) 12. http://itunes.apple.com/ch/app/ my-swisscom/id444087594 (Zugriff am 29.07.2012) 13. https://play.google.com/store/apps/ details?id=com.swisscom.myswisscom (Zugriff am 29.07.2012) 14. http://www.swisscom.ch/myswisscom (Zugriff

UX lässt sich nicht vollends vorhersehen, darum ist es wichtig, bei der Strategie von Mobile-Projekten Zeit und Geld einzuplanen, um nach dem ersten Release auf das Feedback von Benutzern reagieren und die App immer wieder verbessern und

Die Entwicklung von Apps für Smartphones und Tablets steht immer noch am Anfang. Die Geräte werden immer leistungsfähiger und viele End-to-End-Anwendungen verschieben sich von klassischen Desktop-Anwendungen zu mobilen Use

am 29.07.2012) 15. https://developer.apple.com/technologies/ ios5/ (Zugriff am 30.07.2012) 16. http://www.raywenderlich.com/5138/ beginning-storyboards-in-ios-5-part-1 (Zugriff am 30.07.2012)

249


Alle schreiben SMS – aber wer füllt gerne Formulare aus? Fallstudie zur Usability-Optimierung von Formularen für iPhone & Co Sandra Schuster Facit Digital GmbH Neuhauser Straße 17 80331 München s.schuster@facit-digital.com

Abstract Formulare sind zentraler Bestandteil von Anmelde-, Registrierungs- und Kaufprozessen. Ohne die Eingabe der relevanten Daten funktioniert kein M-Commerce. Doch Lust und Frust der Nutzer liegen hier ebenso nahe beieinander wie Conversion-Erfolg und Eingabe-Abbruch. Der Beitrag stellt exemplarische Ergebnisse einer Fallstudie vor, die sich mit der optimalen Gestaltung von Formularen für die Nutzung auf mobilen Devices (speziell: Smartphones) beschäftigt. Dabei werden insbesondere folgende Fragestellungen thematisiert: Wie lässt sich die User Experience bei der Formular-Nutzung verbessern? Welche Nutzungsbarrieren und Eingabehürden gibt es? Wie kann die Dateneingabe optimal unterstützt werden, um Usability-bedingte Abbrüche zu vermeiden?

Schon auf dem Papier entscheiden Anordnung, Beschreibung und Gestaltung von Freitextfeldern oder Listen darüber, ob wir uns in einem Formular alleine zurechtfinden oder nicht. Und während wir kein Problem damit haben, seitenlange What’s App-Messages zu schreiben, schrecken Formulareingaben auf dem Smartphone eher noch mehr ab als am PC. Dabei sind Formulare zentraler Bestandteil von Anmelde-, Registrierungs- und Kaufprozessen. Ohne die Eingabe der relevanten Daten funktioniert kein M-Commerce. 1. Grundlegende Prinzipen für Online-Formulare Für die Gestaltung von Formularen im Web gibt es inzwischen zahlreiche Guidelines. Allein die POUR-Prinzipien der WCAG 2.0 gelten für Formulare quasi in Reinform: Formulare müssen Perceivable (wahrnehmbar), Operable (bedienbar), Understandable (verständlich) und Robust sein. Spezieller formuliert Jessica Enders als grundlegende Prinzipien und Anforderungen die 4 Cs der Formulargestaltung: Clear, Concise, Clever und Cooperative. Dabei bedeutet Clear (Klar), dass der Nutzer mit minimalem Aufwand herausfinden

250

kann, was von ihm verlangt wird. Concise (Knapp) heißt, dass die benötigten Informationen auf eine möglichst effiziente Art gesammelt werden sollen. Clever (Klug) sind Formulare dann, wenn sie die kognitive Belastung für den Nutzer reduzieren und Cooperative (Kooperativ) verhalten sie sich, wenn sie mit dem Nutzer arbeiten und nicht gegen ihn; letztendlich also dem mentalen Modell der Nutzer entsprechen. Zum Teil ergänzt werden diese Kriterien durch ein fünftes C bzw. K für Consistence (Konsistenz) in dem Sinne, dass einmal gesetzte Regeln in Formularen konsequent durchgesetzt und damit für den Nutzer vorhersehbar werden. Aus technischer Sicht sollten Web-Formulare selbstverständlich Bug-frei bedienbar sein und dem Nutzer die Möglichkeit geben, auf einfache Weise Korrekturen vor der endgültigen Datenübergabe vorzunehmen. Dass diese grundlegenden Anforderungen an Web-Formulare auch auf die Nutzung am mobilen Device übertragbar sind, muss an dieser Stelle nicht diskutiert werden. Die Frage ist viel eher: Welche zusätzlichen Ansprüche stellen Größe, Format und spezielle Nutzungssituation von iPhone &

Keywords: /// Mobile UX /// Formulare /// Smartphone /// M-Commerce

Co. an die bedienungsfreundliche Dateneingabe – und damit letztendlich auch an eine Conversion-optimierte Formulargestaltung? Von besonderem Interesse ist in diesem Zusammenhang auch, inwiefern Device-spezifische Eingabehilfen (wie z. B. Picker, Kontext-sensitive Tastaturen, Picker, Kalenderfunktionen) die Dateneingabe tatsächlich erleichtern bzw. welche Umsetzungs-Varianten von den Nutzern präferiert werden. 2. Qualitativer UX-Test am Beispiel Flugbuchung Antworten auf diese und weitere Fragen liefert eine qualitative Fallstudie, die von facit digital in Form von Szenario-basierten UX-Tests in 15 Einzelinterviews mit Vertretern der Zielgruppe durchgeführt wurde. Als relevantes Untersuchungsfeld wurde dafür der Flugbuchungsprozess verschiedener Airlines (Lufthansa, Airberlin, Condor und Germanwings) gewählt. Die Auswahl dieser Airlines erfolgte nach speziellen inhaltlichen Kriterien, die vor allem auf eine möglichst breite Varianz in der Formulargestaltung und dem Einsatz Device-spezifischer Eingabehilfen abzielten. Gegenstand der Tests waren die Buchungsstrecken auf


Usability Professionals 2012 User Experience

Abb. 1.

den jeweiligen mobil optimierten Websites dieser Airlines. [Abb. 1] In einem monadischen Ansatz war jeder Studienteilnehmer angehalten, denselben Flug auf allen drei mobilen Sites zu buchen. Dazu wurde ihm das folgende Szenario vorgegeben: „Stellen Sie sich vor, Sie sind in München unterwegs und haben gerade erfahren, dass Sie am XX.YY.ZZZZ einen Geschäftstermin in Berlin haben werden. Sie wollen nun mit Ihrem Smartphone einen Flug von München nach Berlin buchen: Economy und nur mit Handgepäck. Bitte buchen Sie diesen Flug nun bei [Airline XY].“ Sämtliche Probanden waren erfahrene iPhone-Nutzer (besitzen seit mindestens drei Monaten ein iPhone, nutzen damit regelmäßig Apps und Internet, haben zum Teil bereits Formulare am mobilen Device ausgefüllt; zum Beispiel Hotelbuchung, Registrierungsprozesse). Die Bearbeitung der Aufgaben erfolge am iPhone 4S. [Abb. 2]

Nicht nur nach Jacob Nielsens Erfahrung werden in diesem Zusammenhang 85% der Usability-Probleme bereits in den ersten fünf Interviews deutlich. Auf der anderen Seite sollten Lösungen und Umsetzungsvarianten identifiziert werden, welche dem Nutzer das „müßige“ Formulare-Ausfüllen so einfach und mühelos wie möglich gestalten – und damit aktiv zur Conversion-Optimierung beitragen.

Möglichkeit zur Verfügung, seine eingegebenen Daten noch einmal zu modifizieren; Condor und Germanwings fragen Angaben teilweise doppelt ab oder zwingen den User gar zur Angabe von Daten, die auf ihn gegebenenfalls überhaupt nicht zutreffen: Beispielsweise sind bei Condor sowohl Handy- als auch Festnetznummer als Pflichtangaben deklariert.

3. Ausgewählte Ergebnisse

3.1. Spitzere Anforderungen an „mobile“ Formulare

Als erste interessante Erkenntnis der Fallstudie lässt sich festhalten, dass von den betrachteten Airlines bei weitem nicht alle Hausaufgaben in Form der für OnlineFormulare artikulierten grundlegenden Prinzipien und Anforderungen gemacht wurden: So verzichtet Airberlin zum Beispiel auf die Markierung von Pflichtfeldern; Lufthansa stellt dem Nutzer keine (in Form eines „Ändern“-Buttons sofort erkennbare)

Daneben wurde in den Tests deutlich, dass sich zahlreiche Anforderungen an Web-Formulare im mobilen Umfeld noch einmal zuspitzen. Dies betrifft insbesondere den Formularumfang: Zum einen als die generelle Anzahl der Formularfelder; zum anderen als die Menge der obligatorisch einzugebenden Daten. Aber auch die Reihenfolge der Formularfelder und der abgefragten Daten spielt bei mobiler

Selbstverständlich lassen sich auf Basis einer verhältnismäßig geringen Fallzahl von 15 Probanden keine allgemein gültigen Aussagen (z. B. zu Anteilen oder Präferenzen) treffen. Dies war jedoch auch nicht Ziel der Studie. Vielmehr ging es darum, kritische Barrieren in der konkreten Site- bzw. Formular-Nutzung aufzudecken, welche direkt einhergehen mit einem erhöhten Risiko, den Buchungsprozess vorzeitig, sprich: vor erfolgreichem Abschluss der Buchung, abzubrechen. Abb. 2.

251


Nutzung eine nochmals bedeutendere Rolle, da sich der Nutzer am kleinen Smartphone-Display keine umfassende Übersicht verschaffen kann. Angaben wirken schnell aus dem Kontext gerissen, da ein „Aus-dem-Augenwinkel-Erkennen“, welche weiteren Angaben zu machen sind, nicht bzw. nur eingeschränkt möglich ist. Verstärkte Relevanz im mobilen Nutzungskontext erhält auch die Frage nach der optimalen Platzierung von Ausfüllanweisungen. Während Empfehlungen für das stationäre Web hier Großteils in Richtung einer horizontalen Anordnung von Ausfüllanweisung und Eingabefeld gehen, ist auf Basis der Studienergebnisse von dieser Lösung für mobile Formulare eher abzuraten. Gerade für den Fall, dass ein Zoom In in das Formular nötig ist (z. B. aufgrund einer zu geringen Größe des Eingabefeldes), verlieren die Nutzer eine neben dem Feld platzierte Ausfüllanweisung schnell „aus dem Blick“; ein erneuter Zoom Out wird als umständlich empfunden. Demzufolge empfiehlt sich eher eine Platzierung der Ausfüllanweisung oberhalb des Eingabefeldes. Denkbar ist auch eine Kombination von Ausfüllanweisung und Platzhalter. Platzhalter als Stand-Alone-Lösung werden von den Nutzern aus Angst vor Informationsverlust eher abgelehnt. Im Zusammenhang mit geringer Displaygröße und beschränktem Blickfeld zeigten sich auch Implikationen zur optimalen Ausgestaltung von Fehlermeldungen bzw. zur nutzerfreundlichen Kennzeichnung „falsch“ ausgefüllter Felder. Während die betrachteten Airline-Angebote sich zumeist für eine der beiden Alternativen (entweder Fehlermeldung am Seitenanfang oder Markierung des entsprechenden Formularfelds) entschieden, lag der eindeutige Wunsch der Nutzer in einer Kombination beider Varianten; sprich in einer Auflistung inklusive Erklärung zu Art und Weise der Fehleingaben bei gleichzeitiger Markierung des jeweiligen Feldes. Diese Lösung erschien den Studienteilnehmern der einfachste und schnellste Weg zu Fehlererkennung und -behebung.

252

Auch für eine „altbekannte“ Fragestellung im Kontext der optimalen WebFormulargestaltung – und zwar der, ob umfassende Formulare lieber auf mehreren Seiten bzw. in mehrere Schritte unterteilt werden sollten oder nicht – konnten für die mobile Nutzung Antworten gefunden werden. Nicht zuletzt aufgrund einer im Nutzerverhalten deutlich spürbaren „TippFaulheit“ scheint hier zu gelten: „Scrollen statt Tippen“. Damit kann prinzipiell für die Darstellung des Gesamt-Formulars auf einer Seite plädiert werden. 3.2. Im Visier: Spezielle Eingabehilfen in mobilen Formularen Dass Scrollen allerdings nicht immer vor Tippen kommt, zeigen die Ergebnisse zu unterschiedlichen Verwendungsszenarien des Pickers (Trommel mit Listenauswahl). Grundsätzlich hießen die befragten Nutzer zwar die Picker-Funktionalität als sinnvolle Option willkommen, die Dateneingabe bzw. -auswahl am mobilen Device zu erleichtern und zu beschleunigen. Allerdings sollte ihr Einsatz stets im Kontakt der abgefragten Daten gesehen werden und damit unter Berücksichtigung der hierarchischen Beziehung „Inhalt vor Funktion“. So wirkte die Bestimmung von Start- und Zielflughafen über Picker bzw. Listenauswahl (in dieser Art angeboten von Germanwings) auf die befragten Nutzer mühsam und (unnötig) zeitaufwendig. Einige Benutzer drohten sogar mit Abbruch des Buchungsprozesses während sie ungeduldig die lange Liste der Flughäfen bis zum Buchstaben „M“ für München durchblätterten. Erschwerend hinzu kam bei Germanwings außerdem eine für die Probanden nicht nachvollziehbare Segmentierung der Liste in nationale und internationale Flughäfen. Die Freitexteingabe des gewünschten Flughafens (so umgesetzt bei Lufthansa, Airberlin und Condor) führte dagegen in den seltensten Fällen zu Problemen und wurde von den meisten Studienteilnehmern der Trommel-Auswahl vorgezogen. Insbesondere dann, wenn sie bei der Dateneingabe zusätzlich unterstützt

wurden: zum einen durch die gleichzeitig mögliche Eingabe von Städtenamen als auch IATA-Flughafen-Code, zum anderen durch eine effiziente AutoSuggest-Funktion (speziell Lufthansa, aber auch Condor). Während Airberlin und Lufthansa zur Datumsangabe entweder auf eine Auswahl per Picker (Airberlin) oder per Kalenderfunktion (Lufthansa) setzen, bieten Condor und Germanwings beide Möglichkeiten parallel an. Diese Variante wird von den meisten Nutzern tatsächlich bevorzugt; nicht zuletzt, da sich in der Benutzung keine Präferenz für die eine oder andere Option finden ließ. Die Auswahl von Hinund Rückflugdatum konnte sowohl über Picker als auch über Kalender von den Probanden meist problemlos vorgenommen werden. Dennoch lassen sich Empfehlungen für eine optimale(re) Umsetzung der beiden Varianten zur Datumsangabe formulieren. Speziell für die Auswahl per Picker wird von den Nutzern eine „Durch-ScrollMöglichkeit“ über den letzten Tag (bzw. Monat) eines Monats (bzw. Jahres) hinweg erwartet. Speziell für die Datumsangabe per Kalenderfunktion sollte darauf geachtet werden, dass die Darstellung zum einen ausreichend groß ist, um eine leichte Bedienbarkeit (in diesem Sinne: Tippbarkeit der Felder) zu gewährleisten; andererseits aber klein genug, um eine Gesamt-Übersicht über (zumindest einen) Kalendermonat beibehalten zu können. Häufig wird von den Nutzern auch eine automatische Blockierung von Daten gewünscht, die in der Vergangenheit liegen (und somit für eine Flugbuchung nicht mehr in Frage kommen). Eine DefaultEinstellung des tagesaktuellen Datums kann außerdem für eine zusätzliche Vereinfachung der Datumsangabe sorgen – unabhängig von der gewählten Variante Picker/Trommel oder Kalender. Für den betrachteten Spezialfall der Flugbuchung wünschen sich die befragten Nutzer außerdem eine automatische Anpassung des (überhaupt möglichen) Rückflugtermins an das zuvor ausgewählte Hinflug-Datum (z. B. bei Eingabe 04.05.2012 als Hinflug, Rückflug nicht vor 04.05.2012 möglich).


Usability Professionals 2012 User Experience

4. And the winner is: Lufthansa und kontext-sensitive Keyboards? Sicherlich behandelt die vorliegende Fallstudie lediglich fokussierte Bereiche für eine optimale Gestaltung „mobiler“ Formulare. Dennoch konnten einige interessante Ansatzpunkte identifiziert werden, auf welche Art und Weise den Nutzern das Ausfüllen von Formularen am mobilen Device (hier speziell: iPhone bzw. Smartphone) einfacher und damit vielleicht auch „angenehmer“ gemacht werden kann. Die Ergebnisse implizieren zum einen eine notwendige Anpassung bzw. Konkretisierung bestehender Anforderungen für WebFormulare. Zum anderen verweisen sie auf die Tatsache, dass in der Konzeptionsphase auch Device-spezifische Eingabehilfen verstärkt auf ihre Sinnhaftigkeit für das konkrete Einsatzziel hin zu überprüfen sind. Auch wenn es nicht im primären Fokus der Studie stand, am Ende einen „Sieger“ unter den Airlines zu küren, kann an dieser abschließenden Stelle doch festgehalten werden, dass das mobile Angebot von Lufthansa der Nutzervorstellung von einem reibungslosen und proaktiven Buchungsprozess unter den betrachteten Angeboten mit Abstand am nächsten kommt – sowohl inhaltlich hinsichtlich Formularumfang und Reihenfolge der Formularfelder als auch technisch hinsichtlich der angebotenen Funktionen und Eingabehilfen. Als größte Stärke des Lufthansa-Formulars gilt dabei eine Eingabehilfe, die bis dato im Text noch nicht angesprochen wurde, da sie zum Testzeitpunkt von keiner anderen Airline eingesetzt wurde: Kontext-sensitive Keyboards. Die Verwendung alternierender Keyboards in Abhängigkeit von Art und Kontext der abgefragten Daten (Text, Zahl, Email, etc.) traf bei allen Studienteilnehmern spontan auf großen Zuspruch. Wem ist es zu verdenken? Ersparen kontext-sensitive Keyboards dem „tippfaulen“ iPhone-Nutzer doch ein manuelles Switchen zwischen den Tastaturen und damit einen zusätzlichen Zwischen-„Tap“ im Buchungsablauf.

253


Nur weil es viele Retweets kriegt, ist es noch lange nicht richtig Eine kritische Betrachtung von „UX-Trends“ Dr. Markus Weber Centigrade GmbH Science Park 2 66123 Saarbrücken markus.weber@centigrade.de

Abstract User Experience Design ist ein hoch dynamisches Feld, in dem es für den Einzelnen kaum noch möglich ist, bezüglich aller Trends und Entwicklungen umfassend auf dem Laufenden zu bleiben. Leider bleibt zuweilen aufgrund der hohen Dynamik des Feldes die kritische Auseinandersetzung mit Informationen auf der Strecke bzw. es werden bestimmte Themen nur oberflächlich und stark simplifiziert behandelt. Auf diese Weise finden mit wenig kritischer Betrachtung aber umso mehr Enthusiasmus Positionen und Methoden in den „UX-Kanon“ Eingang, die bei genauerer Betrachtung nicht haltbar sind oder doch zumindest sehr viel differenzierter gesehen werden müssen. Der Beitrag soll einige dieser Aspekte kritisch beleuchten.

1. Einleitung User Experience (UX) Design ist ein hoch dynamisches Feld, in dem Akteure verschiedenster Disziplinen bei der Gestaltung von User Experiences zusammenarbeiten. Im Folgenden wird für die Beteiligten der allgemeine Begriff „UX Designer“ verwendet. Aufgrund der Schnelllebigkeit sowie der unterschiedlichen fachlichen Hintergründe und Erfahrungen der Beteiligten ist es schwer, alle Informationen und Standpunkte, die sich beispielsweise in Blog-Artikeln, TwitterNachrichten und ähnlichem niederschlagen, zu verfolgen, kritisch zu bewerten und einzuordnen. Dies führt dazu, dass zum Teil Dinge quasi „viral“ in die UX Community Eingang finden und nachhaltig verbreitet werden, die einer genaueren kritischen Betrachtung nicht standhalten. Auch werden bestimmte Themen wieder und wieder diskutiert, weil aufgrund impliziter Kommunikationsprobleme divergierende konzeptuelle Auffassungen nicht hinreichend deutlich werden. Schließlich kann eine unzureichend kritische Betrachtung von Informationen auch dazu führen, dass im UX Design Methoden zum Einsatz kommen, die nur scheinbar hinsichtlich

254

ihrer Anwendbarkeit und Einschränkungen durchdrungen wurden – vor allem, wenn diese Methoden einen „Marketingeffekt“ haben. Im Folgenden sollen diese Aspekte näher betrachtet werden. 2. Wovon reden wir eigentlich? – Kurz und prägnant ist nicht immer hilfreich UX Design lebt von Kommunikation. Nicht nur die Kommunikation von UX Designern mit ihren Auftraggebern ist relevant, sondern auch die Kommunikation innerhalb der UX Community. Eine wesentliche Rolle spielt hierbei der Austausch, der online stattfindet, beispielsweise in Blogs und auf Twitter. Dieser Austausch zeichnet sich durch eine hohe Dynamik aus. Hinzu kommt, dass Mitteilungen häufig kurz formuliert werden (z. B. in 140 Zeichen auf Twitter) und/oder dass Autoren ihre Informationen pointiert formulieren. Dies geschieht nicht zuletzt auch aus Gründen der Selbstvermarktung, um in der enormen Menge an Informationen, die online verfügbar ist und die ständig weiter anwächst, nicht unterzugehen. Dies begünstigt jedoch Missverständnisse, wenn der scheinbar „entbehrliche“ Teil einer Argumentation entfällt, weil der

Keywords: /// User Experience Design /// User Experience Community /// Kommunikation /// Professionalisierung /// Qualitätskontrolle

Absender davon ausgeht, dass sein Publikum mit dem betreffenden Teil vertraut ist und diesbezüglich die gleiche Sichtweise wie er selbst einnimmt, beispielsweise was die Definition von Begriffen angeht. Trifft dies jedoch nicht zu, entstehen Kommunikationsfehler, die im ungünstigsten Falle schlicht unbemerkt bleiben. Ein inzwischen schon „klassisches“ Thema, das immer wieder auf Twitter und in der Blogosphäre auftaucht, betrifft die Frage, ob UX Designer auch fähig sein sollten, Code zu schreiben. Es finden sich dann immer Tweets und Posts, die dies befürworten, wie auch solche, die dagegen argumentieren. Betrachtet man die Beiträge genauer, so wird deutlich, dass manche Diskutanten, wenn sie von „UX Design“ reden, schlicht „Web Design“ meinen, und dass der Begriff „Coding“ sich dementsprechend vor allem auf HTML, CSS und JavaScript bezieht. Im Kontext von Web Design hat „Coding“ ein deutlich anderes Gewicht als dies bei nativen Applikationen der Fall ist, wo die erwähnten Technologien von höchstens untergeordneter Bedeutung sind und die Programmierung stattdessen beispielsweise in C# stattfindet. Als weiterer Unterschied kommt hinzu, dass


Usability Professionals 2012 User Experience

UX Design-Projekte im Web-Bereich im Vergleich zu Projekten, die zum Beispiel im Bereich der Steuerung industrieller Maschinen stattfinden, häufig von überschaubarer Größe sind. Nicht selten werden UX Design-Projekte im Bereich Web von einem UX Designer alleine durchgeführt. In einem solchen Kontext ist es natürlich naheliegend, dass der UX Designer auch zum „Coding“ in der Lage sein sollte. In größeren UX Design-Projekten im industriellen Kontext kommt es praktisch nicht vor, dass diese von einem einzigen UX Designer bestritten werden, da dies schon aufgrund der reinen Arbeitsmenge nicht möglich ist, ganz abgesehen von den teilweise hoch-spezialisierten Anforderungen im Bereich Coding, die erforderlich sind. Angesichts dieser Tatsachen ist es nun kaum verwunderlich, dass man hinsichtlich der Anforderung an UX Designer, auch coden zu können, zu unterschiedlichen Schlussfolgerungen kommt, abhängig vom jeweiligen Verständnis des Begriffs „UX Design“. Es ist also sinnvoll, bei aller Dynamik des Feldes, die sich im schnellen Veröffentlichen und Austausch von Informationen widerspiegelt, hin und wieder zu hinterfragen beziehungsweise explizit zu machen, wie bestimmte Begriffe für eine Diskussion definiert sind. Auch wenn das Definieren von Begriffen angesichts des lebhaften Austauschs in der UX Community wie langweilige Arbeit anmuten mag, sollte dennoch ein Bewusstsein dafür bestehen, dass der hoch-dynamische Austausch von Informationen nicht zwangsläufig dazu führt, dass grundsätzliche Themen schnell geklärt werden. Ganz im Gegenteil kann eine Konsequenz der Dynamik auch sein, dass Themen wieder und wieder behandelt werden, ohne dass – zumindest für den Kontext der jeweiligen Diskussion – eine Einigung auf eine Sichtweise erzielt wird. 3. Pseudo-Psychologie – Dafür muss man mehrere Jahre studieren? Das Erleben und Verhalten von Menschen ist der Dreh- und Angelpunkt im Bereich

UX Design. Insofern ist es nicht verwunderlich, dass in der UX Community ein großes Interesse an Erkenntnissen aus der Psychologie besteht. Dies ist grundsätzlich begrüßenswert, da die psychologische Forschung in der Tat viele Erkenntnisse liefert, die im UX Design nutzbringend zur Anwendung kommen können. Problematisch wird es dann, wenn psychologische Erkenntnisse über Gebühr vereinfacht und nicht hinterfragt werden, so dass am Ende eine „Pseudo-Psychologie“ übrig bleibt, die mit der realen Disziplin kaum noch etwas gemein hat, weil Aussagen in einer simplifizierten und gleichzeitig verallgemeinernden Art und Weise getroffen werden, die schlicht nicht haltbar ist. Ein Beispiel in diesem Kontext ist der Artikel des Psychologen Miller (1956) zur „Magischen Zahl 7“, der angeblich besagt, dass der Mensch maximal 7 (± 2) Elemente gleichzeitig verarbeiten kann, ohne dass seine kognitiven Kapazitäten überschritten werden. Verweise auf diesen Artikel dürften den meisten UX Designern schon begegnet sein. Problematisch hierbei ist, dass es sich bei dem Artikel nicht um die Beschreibung von Forschungsergebnissen handelt, sondern um allgemeine Überlegungen von Miller zur Begrenzung der kognitiven Kapazität. Die Zahl 7 war hierbei lediglich ein rhetorisches Mittel, was Miller sogar explizit betont (siehe hierzu auch Liesefeld, 2012a). Doch selbst wenn man von Begrenzungen der kognitiven Kapazität des Arbeitsgedächtnisses ausgeht, wofür es gute Gründe gibt, werden zuweilen aus dieser Tatsache die falschen Schlussfolgerungen gezogen, beispielsweise dann, wenn UX Designer die Empfehlung geben, die Anzahl von Einträgen in einem Menü an diese Grenze anzupassen. Nur wird hier vergessen, dass für den Anwender in der Regel keine Notwendigkeit besteht, alle Menüeinträge auf einmal im Arbeitsgedächtnis zu halten, da er diese ja am Bildschirm alle vor Augen hat. Es gibt zwar auch hier Einflüsse des Arbeitsgedächtnisses (Liesefeld, 2012b), jedoch sind diese differenzierter zu betrachten als es in der Praxis des UX Design mit der Tendenz zu prägnanten Formulierungen einfacher Guidelines häufig getan wird.

Aus der Perspektive des ausgebildeten Psychologen ist es über diese Problematik hinaus auch unbefriedigend, wenn der Eindruck entsteht, Psychologie sei eine „Wissenschaft des Offensichtlichen“, die nichts weiter als mehr oder weniger triviale Wahrheiten zu bieten hat. Dies wird dem Gegenstand des Fachgebiets und dem menschlichen Erleben und Verhalten jedoch bei weitem nicht gerecht. Dass die Betrachtungen in der Psychologie in der Regel weiter gehen als die Simplifizierungen im UX Design es vermuten lassen, ist beispielsweise in Bezug auf die Guideline „Prefer recognition over recall“ zu sehen. Die Richtlinie basiert auf der Annahme, dass Elemente leichter wiedererkannt als erinnert werden können und daher dem Anwender beim Wiedererkennen die Arbeit erleichtert wird. Auch wenn dies in vielen Fällen zutrifft, so handelt es sich nicht um eine allgemeine psychologische Wahrheit. Das Phänomen der „Recognition Failure“ (z. B. Tulving & Wiseman, 1975) zeigt, dass es durchaus auch möglich ist, dass Elemente eher erinnert als wiedererkannt werden. Die Funktionsweise des kognitiven Systems ist also offensichtlich komplexer als die einfachen „psychologischen“ Guidelines es vermuten lassen. Es ist auch für UX Designer wünschenswert, sich der Differenziertheit psychologischer Erkenntnisse bewusst zu sein. Dies bedeutet nun nicht, dass differenzierte Betrachtungen und einzelne Effekte in jedem Fall für das UX Design relevant sind (auch aus falschen beziehungsweise vereinfachten Prämissen kann ein „richtiges“ UX Design folgen). Jedoch geht mit der steigenden Professionalisierung des Bereichs UX Design eine Differenzierung einher, beispielsweise was die Betrachtung unterschiedlicher Zielgruppen mit speziellen (kognitiven) Eigenschaften angeht. Es wird also auch hier zunehmend erforderlich, nicht mehr alles und jeden über einen Kamm zu scheren, sondern sich verstärkt mit spezifischen Details von Nutzungskontexten, Aufgaben und Nutzern zu beschäftigen. Und dann ist derjenige UX Designer besser gewappnet, der über die einfachen „Daumenregeln“ hinaus mit den differenzierteren Betrachtungen des menschlichen

255


Erlebens und Verhaltens vertraut ist, wie sie in der Psychologie angestellt werden. 4. Warum eine Methode durchdringen, wenn man stattdessen auch eine neue verwenden kann? – Neue Methoden statt neuer Erkenntnisse Der UX Designer gestaltet interaktive Systeme für Nutzer. In den wenigsten Fällen sind jedoch diese Nutzer auch die Auftraggeber des UX Designers. Stattdessen arbeitet dieser für Kunden, die intern oder extern sein können, abhängig davon, wo der UX Designer beschäftigt ist. Nicht selten müssen diese Kunden akquiriert werden in dem Sinne, dass sie von den Leistungen des UX Designers überzeugt werden müssen. Idealerweise sollte diese Überzeugungsarbeit durch Qualität und Nutzen der geleisteten Arbeit erfolgen. Bei bestimmten Projekten kann es jedoch eine Weile dauern, bis Arbeitsresultate entstehen, die „Eindruck machen“. Die meisten UX Designer werden wissen, dass Wireframes zwar ein wichtiges Werkzeug zur Kommunikation in einem Projektteam sein können, dass sie jedoch bei Vorstandspräsentationen beziehungsweise allgemein bei Präsentationen gegenüber Personen, die nicht eng im Projekt mitarbeiten, nur wenig Eindruck erzugen. Hier kann die Versuchung entstehen, schnell „Punkte zu sammeln“ durch den Einsatz von Methoden, die „brandneu“ sind oder die „sexy“ Ergebnisse liefern – mit denen also schnell ein „Marketingeffekt“ erzielt werden kann. Im ungünstigsten Falle ist es dann zweitrangig, ob der Einsatz der Methode vom UX Designer hinreichend reflektiert oder die Methode selbst überhaupt verstanden wurde. In diesem Kontext ist zum Beispiel die Methode Eye Tracking zu nennen. Ohne Zweifel sind die Video-Overlays oder Heatmaps, die mit dieser Methode erstellt werden können, eindrucksvoll. Eines der Probleme der Methode liegt jedoch in ihrer Scheinplausibilität: es ist leicht, der Illusion anheim zu fallen, dass man versteht, was z. B. eine Heatmap aussagt: die intensivere Färbung bedeutet mehr

256

Aufmerksamkeit für die betreffende Stelle und mehr Aufmerksamkeit bedeutet, dass die entsprechende Stelle von größerem Gewicht für die kognitive Verarbeitung des Anwenders ist. Nur sind die Gegebenheiten der visuellen Aufmerksamkeit nicht so einfach – selbst dann nicht, wenn man einmal davon absieht, dass Informationen auch im peripheren Bereich des Sehens (und damit außerhalb von fixierten Bereichen) wahrgenommen werden können. Der Zusammenhang zwischen Fixation und Aufmerksamkeit ist bereits ein interpretativer Schritt, der in seiner Schlichtheit nicht immer gerechtfertigt ist. Hinzu kommt, dass das Messen von Fixationen keine standardisierte Prozedur ist. Es kann vorkommen, dass zwei Eye Tracker mit unterschiedlichen Algorithmen zur Fixationsbestimmung arbeiten und auf Grundlage identischer Rohdaten (d. h. Blickbewegungen) unterschiedliche Fixationswerte und Fixationsmuster zurückliefern. Die Messung von Blickbewegungen ist also bei weitem nicht mit etwa der Messung einer Temperatur zu vergleichen, bei der es in der Regel unabhängig vom Messgerät möglich ist, den wahren Wert zu ermitteln. All dies wird üblicherweise bei der Durchführung beziehungsweise beim Reporting von Eye Tracking-Studien im UX Design nicht reflektiert, was zu dem Eindruck beiträgt, dass diese methodisch relevanten Aspekte entweder nicht verstanden werden oder aber dass der Durchführende eher auf den Marketingwert der Methode setzt und hierbei die (begrenzte) Aussagekraft der Befunde bewusst nicht reflektiert, um die Wirkung auf die Rezipienten nicht zu schmälern. Es ist wünschenswert, dass Methoden, die im UX Design zur Anwendung kommen, hinsichtlich ihrer Anwendbarkeit und Aussagekraft reflektiert eingesetzt werden. Eine Methode sollte nie als reine Marketingmaßnahme eingesetzt werden. Können die gewünschten Ergebnisse mit einer etablierten und erprobten Methode erzielt werden, so sollte dieser in der Regel der Vorzug gegenüber neuartigen Methoden gegeben werden. Neue

Methoden sollten zunächst auf den Prüfstand gestellt werden. Dies kann zum Beispiel geschehen, indem man sie in Kombination mit anderen etablierten Ansätzen einsetzt, um die jeweiligen Ergebnisse zu vergleichen und auf diese Weise Aufschluss zum Beispiel über Objektivität, Reliabilität und Validität zu erhalten. Nicht zuletzt können auch etablierte Methoden von einem solchen Vorgehen profitieren, indem sie weiter verfeinert werden. 5. Fazit UX Design ist ein hochdynamischer und heterogener Bereich. Dies führt zu einen dazu, dass der UX Designer sich mit einer rasch anwachsenden Informationsmenge konfrontiert sieht, die kaum noch in ihrer Gesamtheit überschaut werden kann. Zum anderen besteht der Wunsch nach Informationen, die kurz und prägnant formuliert sind, damit sie schnell konsumiert und angewendet werden können. Beide Faktoren führen dazu, dass Informationen in die UX Community Eingang finden, die von fragwürdiger Qualität sind, jedoch aufgrund der hohen Dynamik nur unzureichend hinterfragt werden. Je prägnanter diese Informationen verpackt sind und je pointierter oder eindrucksvoller sie dargestellt werden, desto größer das Risiko, dass sie nachhaltig in den Köpfen hängen bleiben und unzureichend hinterfragt werden. UX Designer sollten kritische Rezipienten von Informationen sein. Nur auf diese Weise kann die Professionalisierung der Domäne UX Design weiter voranschreiten. Es ist wünschenswert, auch – oder gerade – Informationen, die innerhalb kürzester Zeit weite Kreise ziehen, beispielsweise auf Twitter, kritisch unter die Lupe zu nehmen. Dadurch kann vermieden werden, dass allein die Menge der Personen, die den „Retweet“-Button betätigen, als Gütesiegel missverstanden wird.


Usability Professionals 2012 User Experience

Literatur 1. Liesefeld, R. (2012a). Die Zahl Sieben ist nicht magisch, aber kognitive Kapazit채tsgrenzen sind echt und relevant (Teil 1). Online im Internet: URL: http://www.centigrade.de/ de/blog/article/die-zahl-sieben-ist-nichtmagisch-teil-1/ (Stand 25.07.2012) 2. Liesefeld, R. (2012b). Die Zahl Sieben ist nicht magisch, aber kognitive Kapazit채tsgrenzen sind echt und relevant (Teil 2). http://www. centigrade.de/de/blog/article/die-zahlsieben-ist-nicht-magisch-teil-2/ (Stand 25.07.2012) 3. Miller, G.A. (1956). The magical number seven, plus or minus two: Some limits on our capacity for processing information. Psychological Review, 63(2), 81-97. 4. Tulving, E. & Wiseman, S. (1975). Relation between recognition and recognition failure of recallable words. Bulletin of the Psychonomic Society, 92, 257-276.

257


Privacy UX – Was ist datenschutzbezogene User Experience? Michael Hatscher Google Switzerland Brandschenkestrasse 110 8002 Zürich mitchhatscher@google.com

Sebastian Schnorf Google Switzerland Brandschenkestrasse 110 8002 Zürich sebschnorf@google.com

Martin Ortlieb Google Switzerland Brandschenkestrasse 110 8002 Zürich mortlieb@google.com

Abstract Angeregte Diskussionen in Presse und Politik sowie aktuelle Gesetzgebungsprozesse, wie die im Mai in Kraft getretene E-Privacy- Direktive oder die im Reviewprozess befindliche Datenschutz-Rahmenrichtlinie, weisen auf die hohe und weiter steigende Bedeutung von Datenschutz auch im Internet hin. Damit wird Privacy UX ein Thema, dem sich Usability Professionals in allen Unternehmen stellen müssen, die Nutzerdaten verarbeiten. Am Beispiel von Googles Privacy UX-Team zeigen wir auf, was a) unsere Arbeit von derjenigen anderer Usability Professionals unterscheidet, b) in welchem Kontext wir uns bewegen und c) wie wir die Qualität unserer Arbeit zu messen versuchen. Wir berichten über ein ehrgeiziges User Research-Projekt und wie sich die so gewonnenen Erkenntnisse in den Produkten niederschlagen konnten. Abschließend führen wir Faktoren für erfolgreiche Privacy UX-Arbeit auf und zeigen einige Lessons Learned auf.

1. Einleitung: Warum datenschutzbezogene UX? User Experience für Datenschutzprodukte und -services (Privacy UX) ist ein neues Tätigkeitsfeld für User Experience Professionals, das rapide an Bedeutung gewinnt. Neben den Bedürfnissen der Nutzer kommen starke Impulse auch von zwei neuen rechtlichen Rahmenwerken, die für viel Diskussionsstoff sorgen: die gerade neu in Kraft getretene EU E-Privacy-Direktive und die sich noch im Reviewprozess befindende EUDatenschutz-Rahmenrichtlinie, die in eine Verordnung übergehen soll. Privacy UX unterscheidet sich von „herkömmlicher“ produktbezogener UX-Arbeit in mehrerer Hinsicht: –– Privacy UX erstreckt sich meist über einzelne Produkte hinweg bzw. liegt quer zu ggf. bestehenden Produktgruppen oder -silos –– Privacy UX richtet sich nach innen (interne Datenverarbeitungsprozesse) und nach außen (Datenschutzprodukte für Nutzer)

258

–– Privacy UX bearbeitet ein Feld, in dem Metriken für Erfolg fast vollständig fehlen. So ist nicht leicht zu erheben, wie und wann Privacy UX gute Arbeit geleistet hat. Privacy UX findet in einem Umfeld mit unterschiedlichen Herausforderungen statt. Neue Produkt-Features, gerade bei „sozialen“ Produkten, laden Nutzer oft dazu ein, möglichst viel über sich preiszugeben. Um neue Produkte zu realisieren, wäre es wünschenswert, wenn Daten möglichst frei bewegt werden können innerhalb eines Unternehmens oder des Ökosystems, in das ein Unternehmen eingebettet ist. Auch bestehen in verschiedenen Ländern unterschiedliche Rechtsauffassungen, Gesetze und Traditionen zum Thema Datenschutz und Privatsphäre, die bestimmen, wie mit privaten Daten umgegangen werden soll und darf. Da Daten aber nicht an einen Ort oder an Staatsgrenzen gebunden und viele Unternehmen international tätig sind, benötigt man rechtliche Rahmenwerke, damit Unternehmen nicht versehentlich geltendes Recht verletzen. Die zwischen

Kalle Kormann-Philipson Google Germany Dienerstraße 12 80331 München kalle@google.com

Keywords: /// Datenschutz /// Privacy Policy /// Privacy UX /// UX-Aufgabenfelder /// Privacy UX-Messkriterien

der EU und den USA geltenden „International Safe Harbor Privacy Principles“ definieren, wie US-Unternehmen mit Daten von EU-Bürgern umgehen müssen, um mit den EU-Datenschutzgesetzen in Einklang zu sein. Darüber hinaus behandeln die Medien Datenschutzthemen gern und nicht immer nur sachlich. Letztlich weisen auch Nutzerreaktionen und -verhalten eine große Varianz auf, die von Unbekümmertheit über Ratlosigkeit bis hin zu irrationalen Handlungen, „abergläubischem Verhalten“ und Panik reicht. Vielfach konnte auch festgestellt werden, dass beim Thema „Datenschutz” zwischen Nutzereinstellung und eigentlichem Nutzerverhalten eine große Inkongruenz vorherrscht (z. B. Joinson, Reips, Buchanan & Paine Schofield, 2010; generell dazu: Fishbein & Aijzen, 1975) Im folgenden Beitrag werden wir Privacy UX näher beschreiben und dabei beispielhaft auf das Google Privacy UX-Team verweisen. Es geht darum, welche Aufgaben Privacy UX umfasst, in welchem Maße umfangreiche User Research uns hilft, das Feld besser zu begreifen, und wie wir


Usability Professionals 2012 User Experience

Erfolgskriterien unserer Arbeit definieren. Abschließend listen wir eine Reihe von Faktoren auf, die wir als hilfreich für erfolgreiche Privacy UX-Arbeit identifiziert haben. 2. Datenschutzbezogene UX-Arbeit Für die Tätigkeit im Umfeld der datenschutzbezogenen UX-Arbeit kann vor allem die geplante EU Datenschutzverordnung neue Anforderungen bringen, denn zusätzlich zu den bereits seit langem existierenden Rechten, wie z. B. dem Recht der Menschen zu erfahren, welche Daten über sie gespeichert sind, sollen noch weitere Prinzipien eingeführt werden: –– „Right to be forgotten“: Daten von Nutzern sollten über ein Ablaufdatum verfügen. –– „Data portability“: Der Umzug von Daten zwischen Anwendungen sollte gewährleistet werden. –– „Privacy by default“: Einstellungen sollten standardmäßig nicht öffentlich sein. –– „Breach notification“: Über die (unbeabsichtigte) Veröffentlichung von Daten sollte informiert werden. –– „Explicit consent“: Nutzer sollten zur Verwendung ihrer Daten ihre Einwilligung geben. Neben rechtlichen und infrastrukturbezogenen Implikationen bleibt offen, welche Auswirkungen diese Prinzipien konkret auf die Nutzer und ihr Nutzungserleben haben werden. Zum Beispiel: Wann, wo und mit welchen Features sollen Nutzer ihr Einverständnis (Consent) zur Verwendung personenbezogener Daten geben? Bei Google gibt es bereits seit einigen Jahren eine Abteilung, die sich ausschließlich mit dem Thema Privacy beschäftigt. Das Privacy UX-Team innerhalb dieser Abteilung besteht aus einer Gruppe von User Experience Designern und User Experience Researchern, die zurzeit in Zürich, Mountain View und München ansässig sind. Wir arbeiten sehr stark mit Googles Privacy

Engineering-Teams an diesen und weiteren Orten zusammen, halten aber auch engen Kontakt zu weiteren Abteilungen wie dem Legal-Department, der PolicyAbteilung und PR. Wir beschäftigen uns typischerweise mit den folgenden Fragestellungen: –– Wie kann für die Nutzer Transparenz erzeugt werden? –– Wie kann den Nutzern Kontrolle über ihre Daten gegeben werden? –– Wie kann man den Nutzern sinnvolle Wahlmöglichkeiten einräumen? Diese Fragestellungen behandeln wir jeweils in Bezug auf a) Nutzerdaten, die bereits vorliegen, b) auf die zukünftige Nutzung von Daten, die erhoben werden sollen und c) auf den Umgang mit den Daten. Beispiele für konkrete Arbeitsgebiete und aktuelle Produkte sind: –– Google Dashboard: Nutzern Übersicht und Kontrolle über ihre Daten geben –– Google Anzeigenvorgaben-Manager: Nutzern Wahlmöglichkeiten bei der Personalisierung von Anzeigen verschaffen –– Google+ Circles: Nutzern verbesserte Möglichkeiten zum Teilen von Inhalten anbieten Eine spannende Herausforderung besteht darin, dass es zum Thema Privacy sehr wenig verlässliche User ResearchErgebnisse gibt. Der Datenschutz-Diskurs wird vielfach innerhalb der DatenschutzSzene durch Aktivisten, Technologen und Politiker betrieben. Die Medien greifen das Thema gern auf, weil es „gut funktioniert”, Aufmerksamkeit und damit Klicks bzw. Schlagzeilen bringt – aber was genau ist es, was die Menschen zum Thema Datenschutz denken und fühlen? Um das zu verstehen, legten wir 2010 ein ehrgeiziges Datenschutz-Forschungsprojekt auf: User Perceptions of Privacy (UPOP).

3. Die Datenschutzbedenken unserer Nutzer verstehen: „User Perceptions of Privacy“ (UPOP) 3.1. Das Forschungsprojekt Das Forschungsprojekt „User Perceptions of Privacy“, kurz UPOP, verfolgte zwei Zielsetzungen: –– Erforschen, was Nutzer unter „Datenschutz“ verstehen. Wir wollten das Thema herauslösen aus einerseits der erhitzten Debatte unter Ingenieuren (Zugriffskontrolle, Verschlüsselung) und andererseits dem Diskurs unter den Juristen (Recht auf Privatsphäre, Konzept von Datenschutz als Abwenden von Unheil) –– Eine nutzerzentrierte Perspektive von „Datenschutz” gewinnen Das Forschungsprojekt war wie folgt aufgebaut: –– Phase 1: Zuordnung von Terminologie und Kontext von Konversationen über Privatheit (durch 3 x 3 Fokusgruppen in verschiedenen Ländern bzw. Orten: London, Denver, München) –– Phase 2: Zusammentragen und Sammeln realer Nutzererfahrungen und Nutzerberichte zu speziellen privatheitsbezogenen Themen (~100 Tagebuchstudien in Großbritannien, Deutschland, US-West- und US-Ostküste) –– Phase 3: Eingehende Untersuchung über Strategien, wie Benutzer versuchen, sensible Daten zu schützen (34 In-Home Interviews in Großbritannien, Deutschland, US-Westküste, US-Ostküste) 3.2. Erkenntnisse aus der Forschung zu UPOP Eines der zentralen Ergebnisse aus diesem Forschungsprojekt besteht darin, dass bestätigt werden konnte, dass Nutzer unter „Datenschutz“ (oder Englisch „Privacy“) vor allem die Einsicht in und die Kontrolle über ihre sensiblen Daten

259


verstehen. Einige der Erkenntnisse aus der UPOP-Forschung stellten auch für uns Überraschungen dar. So lassen sich beispielsweise praktisch keine prinzipiellen Unterschiede in den DatenschutzBedenken der Nutzer zwischen den USA, Großbritannien und Deutschland feststellen. Weitere interessante Erkenntnisse sind unter anderem: –– Nutzer haben in erster Linie Sorge davor, dass andere, meist ihnen bekannte Menschen Zugriff auf ihre Daten bekommen; weniger Sorgen machen sie sich über Zugriffe durch Hacker. Noch deutlich weniger fürchten sie einen unberechtigten Zugriff durch Unternehmen oder staatliche Institutionen –– Nutzer haben nicht per se ein Problem damit, dass Daten über sie online verfügbar sind. Allerdings sind sie unglücklich über den fehlenden Überblick über diese oft scheinbar periphären Daten. Nutzer möchten wissen können, wer in welchem Maße auf was für Daten über sie Zugriff hat –– Weiterhin befürchten Nutzer, aufgrund von öffentlich zugänglichen Daten unfair bewertet zu werden (z. B. indem jemand von ihrem Musikgeschmack Rückschlüsse auf ihren Charakter zieht) –– Nicht nur im Rahmen von UPOP, sondern auch bei anderen User Research-Aktivitäten hören wir immer wieder, dass Nutzer sich von Google (und anderen großen Unternehmen der Branche) Hinweise, Hilfe und Strategien zum Umgang mit und zum Schutz privater Daten wünschen Viele dieser Erkenntnisse haben auch direkt Einfluss auf Design- und Produktentscheidungen gefunden. Beispielsweise hatten sich Nutzer vor allem besorgt gezeigt über unberechtigten Zugriff auf ihre Daten durch andere, ihnen bekannte Menschen. Für Google Dashboard zogen wir daher einen zweiten Authentifizierungsschritt ein, um sicherzugehen, dass die Person am Computer auch berechtigt ist, diese

260

vertraulichen Daten zu sehen. Nutzer werden also beim Zugriff aufs Dashboard ein weiteres Mal nach ihrem Passwort gefragt, selbst wenn sie bereits mit ihrem Google Account angemeldet sind. Auch reagierten wir auf den Nutzerwunsch nach Hilfe und Unterstützung: Googles „Gut zu Wissen“-Kampagne bietet viel Information und Tipps dazu, wie man sich sicher im Internet bewegt, was ein starkes Passwort ausmacht, was Cookies sind und wie sie funktionieren, wie man anhand der Internetadresse (IP) den Ort bestimmt, was Google genau an Daten speichert, wie man das Webprotokoll löschen kann und vieles mehr. Nicht immer aber ist der Schritt von den Erkenntnissen zur Maßnahme so geradlinig wie in diesen Beispielen. Viel häufiger müssen wir uns in unserer Arbeit die Frage stellen, was eigentlich „gute Privacy UX“ ausmacht, d. h. wie man diesen Aspekt der Nutzungserfahrung messen und bewerten kann. 4. Die Forschungsergebnisse ins Design übersetzen: Privacy UX Design 4.1. Die Qualität der datenschutzbezogenen Nutzungserfahrung messbar machen Typische Qualitätskriterien für Interaktionsdesign fokussieren (natürlich) primär auf Usability (z. B. ISO-Kriterien) und manchmal zusätzlich auf hedonische Aspekte der Nutzung (Hassenzahl et al., 2000). Gängige Instrumente basieren auf der ISO 9241-10 (z. B. Gediga, Hamborg & Düntsch, 1999). Der AttrakDiff (Hassenzahl et al., 2003) erstellt aus pragmatischen und hedonischen Qualitäten eine Gesamtqualität. Heuristiken wie die von Nielsen (1993) oder Tognazzini (2003) geben Leitschnüre für „gutes“, gebrauchstaugliches Design. Darüber hinaus werden Metriken verwendet wie Task Completion Rate oder Task Completion Time.

Für den Anteil „datenschutzbezogene Nutzungserfahrung“ von Privacy UX bestehen keine derartigen Instrumente oder Heuristiken. Das hat mehrere Gründe: –– „Datenschutz“ oder „Privacy“ ist schwer zu definieren und noch schwerer zu messen. Gemessen (oder erforscht) werden können meist Datenschutzbedenken, die dann aber durch stark davon abweichendes beobachtbares Verhalten wieder relativiert werden (z. B. Buchanan et al., 2007). Es gibt also eine Diskrepanz zwischen Einstellung und Verhalten. –– Es bestehen große interkulturelle Unterschiede darin, was Regulatoren und Juristen unter „Privacy“ verstehen und was durch „Privacy“ geschützt werden soll. Beispielsweise gibt es in den USA die Auffassung von Privacy als „Right to be left alone“, die auf die US-Verfassung zurückgeführt wird (Warren & Brandeis, 1890). In Deutschland leitete das Bundesverfassungsgericht 1983 im „Volkszählungsurteil“ das Recht auf informationelle Selbstbestimmung vom Allgemeinen Persönlichkeitsrecht (Art. 2 GG) ab. Wir mussten also unsere eigenen Kriterien ableiten. 4.2. Kriterien für eine gute Nutzungserfahrung aus Sicht von Privacy UX definieren Um zu empirisch abgeleiteten und nützlichen Kriterien nach einem FragenkatalogPrinzip zu gelangen, gingen wir wie folgt vor: Zunächst generierten wir bei einem erneuten Durchgang aller UPOP-Erkenntnisse pro Erkenntnis Bündel von Fragen, die auf diese spezifische Erkenntnis abzielten. Beispielsweise ergab unsere UPOP-Erkenntnis „Kein verlässliches Feedback“ die Frage: „Werden Lösungen mit Feedback und zusätzlicher Information angeboten (insbesondere für den Fall, dass im Bereich des Datenschutzes


Usability Professionals 2012 User Experience

etwas schief läuft)?“ Dies ergab ca. 70 Fragen. Anschließend filterten wir die 70 Fragen auf Redundanzen und gruppierten sie letztlich in sieben einigermaßen trennscharfe Cluster (z. B.: „Contextual guidance & problem-solving“). Abschließend erbrachte ein erneuter (intuitiver) Kondensations- und Filterdurchgang zwölf (z.T. umformulierte) Fragen in drei Clustern: „User Control & Feedback“, „Privacy User Education“ sowie „Privacy Guidelines & Beyond“. 4.3. Privacy UX-Qualitätskriterien Die oben beschriebene Vorgehensweise ermöglichte es uns, aus den UPOPErgebnissen die folgenden Kriterien abzuleiten: Steuerbarkeit durch den Nutzer und Feedback (User Control and Feedback): –– Können die Nutzer die Kontrolle über ihre Daten ergreifen und ausüben? –– Wie werden Prozesse den Nutzern gegenüber kommuniziert und erklärt, insbesondere solche, die den Umgang mit ihren Daten betreffen? –– Werden Lösungen mit Feedback und zusätzlicher Information angeboten (insbesondere für den Fall, dass im Bereich des Datenschutzes etwas schief läuft)? –– Wie geht das Produkt mit mehreren Nutzern und / oder mehreren Geräten um? Datenschutzbezogene Nutzerinstruktion (Privacy User Education): –– Wie wird den Nutzern erklärt, wie das Produkt mit ihren Daten umgeht / was es mit ihren Daten tut? –– Wie wird auf die unterschiedlichen Lernstile und Kenntnisstände über private / vertrauliche Daten eingegangen? –– Werden Nutzern Strategien für ein „sicheres“ Online-Leben angeboten? Datenschutzregelwerke und darüber hinaus (Privacy Guidelines and Beyond): –– Wie wird über die DatensicherheitsStandards hinaus dafür gesorgt, dass

Nutzer ihre Daten dem Produkt und Google anvertrauen? –– Wie sehen die Vorkehrungen für den Fall aus, dass es zu einem Datenschutz-Leck kommt (von Google oder den Nutzern verursacht)? –– Wie werden interne und externe Regelwerke und „Best Practices“ im Interesse der Nutzer verwendet? –– Wie wird festgestellt, dass das Standardverhalten des Produkts auch „gutes“ Standardverhalten für die Nutzer darstellt? Diese neuen Kriterien und ein kleines Set von UI-Patterns werden zurzeit einem Praxistest unterzogen: Wir werden sie als Richtschnur in UI- und Konzept-Reviews für eigene und fremde Projekte anzuwenden versuchen und dabei beobachten, wie gut sie uns helfen, die Nutzer-Perspektive auf Datenschutz noch besser zu vertreten. Auch arbeiten wir daran, alle Mitglieder des Teams auf vergleichbare Privacy UX-Maßstäbe hin zu kalibrieren, um verlässlichere Ergebnisse aus Privacy UI-Reviews zu bekommen. Mittelfristig erhoffen wir uns, die Fragen noch stärker standardisieren und in ein Regelwerk überführen zu können, so dass andere Produktteams den Datenschutz noch stärker im Design berücksichtigen können. 5. Lessons learned: Wie wir Privacy UX bei Google etablieren konnten Wie ist es uns gelungen, Privacy UX innerhalb der Firma erfolgreich zu etablieren? Die folgenden Faktoren waren aus unserer Sicht hilfreich: –– Privacy muss ganz tief in der Unternehmenskultur verankert sein oder werden. Das ist erstaunlicherweise möglich, selbst wenn die Firma schon mehr als zehn Jahre besteht. Eine mit entsprechenden Befugnissen und Ressourcen ausgestattete Stelle zu schaffen, erwies sich dabei als zentral. Bei Google wurde dazu die Position eines Director of Privacy, Product & Engineering geschaffen.

–– Unterstützung „von ganz oben“ ist notwendig: Privacy in der Produktentwicklung konkret zu berücksichtigen, ist ein Quartals- und Jahresziel für jedes Entwicklungsteam. Die Teams müssen ihre Produktneuerungen einem Privacy Review-Prozess unterziehen. Im Rahmen dieses Prozesses beurteilt eine Gruppe von interdisziplinären Privacy-Experten das Produktkonzept und teilweise auch die Ausführung und gibt Rückmeldung, die für das Produkt sehr weitreichend sein können. –– Privacy ist nicht primär ein Security-, sondern ein Nutzerthema: Es geht hier um Vertrauen, das besonders im Web-Umfeld so wichtig ist, weil „der Wettbewerb nur einen Mausklick entfernt“ ist. Mit dem Thema Privacy kann man Wettbewerbsvorteile gewinnen: Nutzer vertrauen den Produkten und der Marke mehr, wenn wir ihnen Transparenz, Kontrolle und sinnvolle Wahlmöglichkeiten geben. –– Ein verlässliches Netzwerk mit anderen (senioren) UX-Leuten innerhalb der Firma ist hilfreich: Gerade Privacy UX-Arbeit geht stärker über Produktgrenzen hinweg als irgendein anderer Aspekt von UX. –– Wie für alle UX-Positionen, gilt auch für Privacy UX: Man sollte vermeiden, sich in die Rolle der Design-Polizei zu begeben. Stattdessen muss man darauf hinarbeiten, als hilfreich für andere Teams wahrgenommen zu werden. Literatur 1. Buchanan, T., Paine, C., Joinson, A. N. & Reips, U.-D. (2007). Development of measures of online privacy concerns and protection for use on the Internet. Journal of the American Society for Information Science and Technology, 58(2), S. 157-165. 2. Fishbein, M. & Aijzen, I. (1975). Belief, Attitude, Intention, and Behavior: An Introduction to Theory and Research. Reading, MA: Addison-Wesley. 3. Gediga, G., Hamborg, K.-C. & Düntsch, I. (1999). The IsoMetrics usability inventory:

261


An operationalisation of ISO 9241-10. Behaviour and Information Technology,

– letzter Zugriff am 26.6.2012 13. E-Privacy-Direktive: circumstances,

18, S. 1