Mensch und Computer 2015 – Usability Professionals: Workshop 9783110443882, 9783110443325

Citation preview

Holger Fischer, Anja Endmann, Malte Krökel (Hrsg.) Mensch und Computer 2015 - Usability Professionals

Weitere empfehlenswerte Titel Mensch-Maschine-Interaktion Andreas Butz, Antonio Krüger, 2014 ISBN 978-3-486-71621-4, e-ISBN 978-3-486-71967-3

Prozessführungssysteme Michael Herczeg, 2014 IISBN 978-3-486-58445-5, e-ISBN 978-3-486-72005-1, Set-ISBN 978-3-486-79087-0

Data Mining Jürgen Cleve, Uwe Lämmel, 2014 ISBN 978-3-486-71391-6, e-ISBN (PDF) 978-3-486-72034-1, e-ISBN (EPUB) 978-3-486-99071-3

IT-Sicherheit, 9. Auflage Claudia Eckert, 2014 ISBN 978-3-486-77848-9, e-ISBN 978-3-486-85916-4

Vernetzte Organisation Alexander Richter (Hrsg.), 2014 ISBN 978-3-486-74728-7, e-ISBN 978-3-486-74731-7, Set-ISBN 978-3-486-98957-1

Informatik und Gesellschaft Andrea Kienle, Gabriele Kunau, 2014 ISBN 978-3-486-73597-0, e-ISBN 978-3-486-78145-8

Mensch und Computer 2015 – Usability Professionals Herausgegeben von Holger Fischer, Anja Endmann, Malte Krökel

Herausgeber Holger Fischer s-lab – Software Quality Lab UniversitätPaderborn Zukunftsmeile 1 33102 Paderborn [email protected]

Anja Endmann itCampus Software- und Systemhaus GmbH Nonnenstraße 27 04229 Leipzig [email protected]

Malte Krökel BSH Hausgeräte GmbH Carl-Wery-Straße 34 81739 München [email protected]

ISBN 978-3-11-044332-5 e-ISBN (PDF) 978-3-11-044388-2 e-ISBN (EPUB) 978-3-11-043556-6 Set-ISBN 978-3-11-044389-9 Library of Congress Cataloging-in-Publication Data A CIP catalog record for this book has been applied for at the Library of Congress. Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.dnb.de abrufbar. © 2015 Walter de Gruyter GmbH, Berlin/Boston Druck und Bindung: CPI books GmbH, Leck ♾ Gedruckt auf säurefreiem Papier Printed in Germany www.degruyter.com

Inhaltsverzeichnis Inhaltsverzeichnis

Vorwort Keynote Creativity at Work! Janaki Kumar

XI   3  

Branchenreport Branchenreport UX/Usability 2015 Sarah Diefenbach, Stefan Tretter, Daniel Ullrich, Nina Kolb

7  

Full Paper Wie schnell ist „schnell“ bei Business- Software? Wolfgang Bonhag, Doreen Feindt, Siegfried Olschner, Ulf Schubert Faktoren der User Experience Dominique Winter, Martin Schrepp, Jörg Thomaschewski Data Canvas und Data-Need Fit Katrin Mathis, Felix Köbler Prototyping hoch Drei – interaktiv, dynamisch und konsequent (in der Zusammenarbeit) Moritz Fröhner, Sebastian Ammermüller, Julian Mengel, Michael Kühnel Antizipative Nutzererfahrungen Agnieszka Maria Walorska Content Design und UI Architektur für Multiscreen-Projekte Wolfram Nagel User Experience in Kanban Jan Uhlenbrok, Eva-Maria Schön, Dominique Winter, Jörg Thomaschewski Doppelt hält besser Hartmut Schmitt, Dominik Pascal Magin, Steffen Hess, Dominik Rost

22  

33  

42   51   61  

72   84   95  

VI

Inhaltsverzeichnis

Usability-Testing in agilen Entwicklungsprojekten Alexander Rösler, Michaela Thölke 3, 2, 1, meins! Nina Kolb, Sarah Diefenbach, Susanne Niklas Bodystorming als Best Practice Methode für die Entwicklung von AAL-Lösungen Tobias Limbach, Kathrin Kim, Jan Köppen, Peter Klein Anforderungsanalyse bei IT-Experten mit der Experience-Sample-Methode Andreas Thom, Sebastian Meier, Frank Heidmann Ein Bild von einem Roboter: Der Care-O-bot 4 als Gentleman Johannes Schäfer, Sven Feustel, Ralf Kittmann Usability und Smart Home: Aktuelle Herausforderungen und Implikationen Sandra Schering, Jasmin Kuhn, Michael Jendryschik sunnyplaces.com – Lean UX-Design Oliver Gerstheimer, Oliver Endemann, Andreas Strusch Der Usability Engineering Prozess für Medizinprodukte nach IEC 62366:2007 Thore Reitz, Torsten Gruchmann Ein Accessibility (a11y)-Konzept für Google Calendar Mitch Hatscher, Astrid Weber Personalisierung & Dynamic Content Joachim Stalph Agrarwirtschaft meets Mobile UX Steffen Hess, Felix Kiefer, Karl-J. Wack, Dominik Magin

106   113  

123  

133   144   152  

162   172  

184   192  

203  

Hard- und Software Schnittstelle für den Sipos Seven PROFITRON Stellantrieb 213   Holger Schlemper, Hans-Georg Hopf, Katrin Proschek, Ulrich Raithel, Peter Müller, Michael Molle Erfolgreich AppS für die Industrie entwickeln Franz Koller, Claus Oetter DATEV Design-DNA – Entwicklung einer produktübergreifenden Designsprache Ulf Schubert, Claude Toussaint, Kristina Helmreich

224  

232  

Die Entwicklung des Interaktionsdesigns für ein KFZ-Assistenzsystem von übermorgen 241   Olde Lorenzen-Schmidt, Christine Ullmann

Inhaltsverzeichnis

VII

Reminder Objects Henrik Rieß, Peter Klein, Martin Ecker, Stefan Hintz

252  

Immersive Simulation eines Magneten durch die Kombination einer VR-Brille mit Force Feedback Ronja Scherz, Thomas Immich Zeit ist Geld – App Evaluation in nur 5 Minuten Claudia Nass, Dominik Pascal Magin Usability Testing als Kunst des Möglichen Markus Weber

261   271   284  

Late-Breaking Results UX Trends Benjamin Uebel Übertragung mobiler Navigations-formen auf Desktop-Websites Saskia Niemann Der Nutzer im Rad der Zeit Patricia Paule, Sabrin Kenaan, Tim Schneidermeier „Da haste den Salat“ Jan Schröter, Steffi Hußlein, Constanze Langer Nutzerorientierte Gestaltung einer Entwicklungsumgebung von MR-Sequenzen auf Magnetresonanztomographen Saulius Archipovas Analyse des aktuellen Stands der Berücksichtigung von Usability bei der Softwareentwicklung in deutschen kleinen und mittleren Unternehmen Tatjana Rößler, Michaela Kauer Einführung von Human-Centered Design in industriellen Projekten Edna Kropp Die Macht von Limitierungen Andreas Burghart, Markus Weber Six-Second-Scenarios Tobias Limbach Die Sushi-Strategie: In 15 Minuten soviel wissen wie in einer Stunde Oliver Gerstheimer, Sarah Henß, Cord Krüger

293  

297   302   307  

311   316   321   326  

330   334  

VIII

Inhaltsverzeichnis

Smart Watch: Nur Schmuck oder doch noch mehr (-Wert)? Christián Acevedo, Sven Feustel, Fabian Pfaff „Be my Mate!“ Rahel Flechtner, Johannes Schäfer, Bernhard Schmid-Wohlleber Danke: Einfach Starten. – Mehr als 2 Millionen mal. Oliver Gerstheimer, Steffen Wüst, Sarah Schuster Mobile User Experience Sandra Schuster

341   346  

350   355  

Workshops Als Usability/UX-Professional wirksam handeln Knut Polkehn, Malte Sönksen Qualitätsdimensionen für interaktive Systeme Holger Fischer, Knut Polkehn, Thomas Geis, Oliver Kluge, Kay Behrenbruch, Catharina Riedemann Traumberuf UX Professional nach dem Studium? Reinier Kortekass, Ludwig Fichte, Jan Preßler, Martin Schrepp, Astrid Beck, Konstanija Petrovic

361   371   379  

Tutorials Usability Engineering für Medizinprodukte Michael Engler Wie effizient ist mein User Interface? Martin Schrepp, Theo Held Survival-Analyse für UX-Praktiker Bernard Rummel User Journey Mapping Anja Endmann, Daniela Kessner Lebendige UX Dominique Winter Reverse Design Analyse Malte Sönksen, Florian Kaase, Sabine Rougk

383  

393  

401   408   415  

420  

Inhaltsverzeichnis

IX

Demos Wie kann Anforderungserhebung mit mobilen Geräten unterstützt werden? Marius Brade

431  

Usability-Glossar mit Usability-Quiz Herbert A. Meyer, Felix Hemke, Knut Hühne, Maximilian Schneider, Volker Wohlgemuth

437  

Casolysis 2.0 Adrian Hülsmann, Yevgen Mexin, Gerd Szwillus, Anastasia Wawilow

445  

Programmkomitee Autoren

457  

459  

Vorwort Vor kurzem noch als Vision betrachtet, so werden wir mittlerweile mit zukunftsträchtigen Themen nahezu überhäuft und die Digitalisierung hält Einzug in sämtliche Branchen und Haushalte. Mit unseren intelligenten Fitnessbändern und Uhren sammeln wir rund um die Uhr zahlreiche Daten über uns selbst und bekommen umfangreiche Analyseergebnisse zu unserer Gesundheit und unserem Wohlbefinden. Bei unserem Museumsbesuch leiten uns digitale Helfer entlang unserer persönlichen Interessen zu den spannendsten Exponaten oder präsentieren uns zusätzliche audiovisuelle und textuelle Informationen direkt in der Gemischten Realität. Auch unser Zuhause wird zunehmend intelligent. Mit dem Smart Home finden aktuell Entwicklungen statt, die es uns nicht nur ermöglichen, den Raum bereits von unterwegs vorzuwärmen, sondern umfangreiche Strategien in Bezug auf Energie- und Ressourceneffizienz sowie zur Nachhaltigkeit liefern. Aber nicht nur im eigenen Haus, sondern auch in der Industrie hält die Digitalisierung Einzug. Teilprodukte kennen ihren eigenen Zustand und lassen sich zur entsprechenden Maschine zur Weiterverarbeitung bringen. Auch nach mehreren Jahren kann die Situation zum Zeitpunkt der Fertigung abgerufen werden, so dass ein Produkt die Tore der Fabrik nie ganz verlässt. Neue Wertschöpfungsketten und Geschäftsideen entstehen, aber auch die Art der Aufgaben für den Menschen von morgen verändern sich. In all diesen Themenbereichen und noch vielen mehr stellen Usability und User Experience ausschlaggebende Qualitätskriterien dar. Einen entsprechenden Ort zum Erfahrungsaustausch zwischen Wissenschaftlern und Praktikern, zur Diskussion von Forschungsergebnissen, zum Kennenlernen von neuen Produkten und Methoden als auch zum Networking mit Kolleginnen und Kollegen, bietet die Usability Professionals 2015 (UP15). In diesem Jahr findet im Rahmen der Mensch und Computer Konferenz in Stuttgart vom 6.9. September bereits die 12. UP statt. Damit schließt sich dieses Jahr ein kleiner Kreis, denn bereits 2003 wurde die allererste UP seitens der German UPA e.V. auf der Mensch und Computer in Stuttgart in Kooperation mit dem Fachbereich Mensch-Computer Interaktion der Gesellschaft für Informatik (GI) initiiert. Insgesamt wurden dieses Jahr 106 Beiträge einreicht, die durch das 14-köpfige ehrenamtliche Programmkomitee begutachtet wurden. Dabei konnten 63% aller Einreichungen für die Tagung akzeptiert werden. Diese verteilen sich auf 29 Full Paper, 14 Late-Breaking Results, 11 Workshops/Paneldiskussionen, acht Tutorien sowie vier Demos. Die Demos stellen seit diesem Jahr ein neues Format dar, in denen Herstellern von UX/Usability-Tools die Möglichkeit geboten wird, ihr Tool zu präsentieren sowie den Mehrwert und professionellen Umgang zu vermitteln. Die angenommenen Beiträge berichten u.a. über die Themenfelder Management, Methoden, Evaluation, Design

XII

Vorwort

Perspektiven, Information Monitoring, Future UX, Industrial UX und Agile UX. Darüber hinaus finden sich Einreichungen der Arbeitskreise der German UPA. Als Organisatoren seitens der German UPA bedanken wir uns bei allen Autoren, Referenten, Session Chairs, Programmmitgliedern sowie den lokalen Organisatoren für das Engagement. Wir wünschen Ihnen und euch eine spannende Lektüre der Beiträge sowie zahlreiche Anstöße und Erkenntnisse für die eigene betriebliche Praxis. Stuttgart, im September 2015 Anja Endmann Fachvorstand

Holger Fischer Vize-Präsident

Vorwort

German UPA e.V. Leitzstraße 45 D-70469 Stuttgart Fon: 0711 490 66 – 117 Fax: 0711 490 66 - 118 E-Mail: [email protected] Web: http://www.germanupa.de

Sponsoren Ein herzliches Dankeschön gilt allen Sponsoren der Mensch und Computer 2015!

Platin

Förderschwerpunkt Mittelstand-

Tobii Pro

Sponsoren

Digital, Bundesministerium für Wirtschaft und Energie (BMWi)

Gold

Agentur Siegmund GmbH

artop GmbH

Ergosign Ergonomie und Design GmbH

Noldus Information Technology GmbH

User Interface Design GmbH

Robert Bosch GmbH

SensoMotoric Instruments GmbH (SMI)

XIV

Sponsoren

Silber

1&1 Internet SE

chilli mind GmbH

Intuity Media Lab GmbH

Mangold International GmbH

Phoenix Design GmbH

Usability.de

+ Co. KG

UserZoom GmbH

UXQB – International Usability and User Experience Qualification Board e.V.

Walter de Gruyter GmbH

Keynote

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, 2015, S. 3.

Creativity at Work! Humanizing the Enterprise through Design Janaki Kumar

Janaki Kumar

Head of Strategic Design Services, America Design and Co-Innovation Center SAP Labs Palo Alto Twitter: @JanakiKumar | @SAP_designs

Abstract To deliver best in class user experiences to business users, design practitioners need to consider not just the user interface of applications, but the end-to-end customer experience. The enterprise software industry is undergoing a transformation as users expect simple, easy-to-use experiences from their business software. However, to deliver on this expectation, enterprise software vendors face three primary hurdles:

The complexity of their customer’s information technology landscapes, Complexity of business processes in their customer’s organizations, and Lack of design skills in customer’s IT organizations. In this talk, Janaki Kumar will describe these changing expectations and unique challenges in enterprise software user experience design. She is outline the user experience strategy that SAP has developed to enable this shift from features to experience. Janaki will introduce Design Thinking, a structured process for creativity and innovation, along with three case studies from the Design and Co-Innovation Center (DCC), an in-house design agency within SAP. Twitter:

@JanakiKumar

TEDx Talk:

https://www.youtube.com/watch?v=6wk4dkY-rV0

Book:

http://www.amazon.com/Gamification-Work-Designing-EngagingBusiness/dp/8792964079

Branchenreport

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, 2015, S. 7- 20.

Branchenreport UX/Usability 2015 Ergebnisse einer Befragung unter UX/Usability Professionals in Deutschland Sarah Diefenbach, Stefan Tretter, Daniel Ullrich, Nina Kolb

Sarah Diefenbach

Stefan Tretter

Daniel Ullrich

Nina Kolb

LMU München Department Psychologie Leopoldstr. 13, 80802 München [email protected] LMU München Institut für Informatik Amalienstr. 17, 80333 München [email protected]

LMU München Department Psychologie Leopoldstr. 13, 80802 München [email protected] TU Darmstadt Institut für Psychologie Alexanderstr. 10, 64283 Darmstadt [email protected]

Abstract Seit über zehn Jahren bietet die German UPA (Berufsverband der deutschen Usability und User Experience Professionals, www.germanupa.de) mit dem Branchenreport einen regelmäßigen Überblick der Situation von Usability und User Experience (UX) Professionals in Deutschland. 2015 haben sich 226 Personen an der Befragung beteiligt und liefern damit eine umfangreiche Informationsbasis zu Aus- und Weiterbildung, Arbeitsfeldern und Aufgabenbereichen, Verdienstmöglichkeiten, Trends sowie den wichtigsten Arbeitgebern der Branche. Neben Zahlen und Fakten liefern subjektive Einschätzungen zu Arbeitszufriedenheit, Unternehmenskultur und wahrgenommenen Herausforderungen eine umfassende Beschreibung der Situation von Angestellten und Selbstständigen in der UX/Usability-Branche.

Keywords Usability, User Experience, Branche, Arbeitssituation, Gehaltsspiegel, Ausbildung, Unternehmen

Einleitung Mit dem jährlichen Branchenreport informiert die German UPA (Berufsverband der deutschen Usability und User Experience Professionals, www.germanupa.de) über die aktuelle Situation und Entwicklungen im Arbeitsfeld Usability und User Experience. Hierbei werden zum einen Daten bezüglich Aus- und Weiterbildungsmöglichkeiten,

8

Sarah Diefenbach, Stefan Tretter, Daniel Ullrich, Nina Kolb

Projektschwerpunkten und Kennzahlen zum aktuellen Arbeitgeber oder der eigenen Unternehmung erhoben, zum anderen auch subjektive Bewertungen zu Zufriedenheit, Unternehmenskultur und wahrgenommenen Herausforderungen erfragt. Zusätzlich bietet der Branchenreport einen Überblick über die Einschätzung aktueller Trends und potenzieller Entwicklungsfelder. Der Branchenreport bietet für verschiedene Personengruppen eine wertvolle Informationsbasis. Interessierte, die eine Tätigkeit im Usability- bzw. User ExperienceBereich in Erwägung ziehen, erhalten einen aufschlussreichen Einblick in die aktuelle Situation der Branche, potentielle Karrierewege und Ausbildungsmöglichkeiten. Bereits in der Branche Tätige erhalten Vergleichswerte zur Orientierung, um ihre aktuelle Situation im Verhältnis zu der ihrer Kollegen einschätzen zu können. Darüber hinaus bieten die im Branchenreport gebündelten Informationen auch Anknüpfungspunkte für Diskussionen zur Weiterentwicklung und Professionalisierung des Berufsbilds und bilden damit eine wichtige Grundlage für die Arbeit des Berufsverbands. Die Datenerhebung erfolgte wie auch in den Vorjahren mittels Online-Befragung im Zeitraum von März bis Mai. Die Teilnehmer wurden über den German UPA Newsletter sowie durch Einladungen in Usability & User Experience-Gruppen in sozialen Netzwerken wie Xing oder Facebook gewonnen. 226 Teilnehmer machten Angaben zu einem Großteil der Fragen und bilden die Basis für die im Folgenden vorgestellten Analysen. Die Gruppe der Teilnehmer bestand zu nahezu gleichen Teilen aus erstmaligen BranchenreportTeilnehmern (51%) und Teilnehmern, die bereits im Vorjahr teilgenommen hatten (49%). Unterschiede werden als signifikant bezeichnet, wenn eine Irrtumswahrscheinlichkeit von < 5% vorliegt (p < .05). Bei Fragen mit vorgegebenen Antwortkategorien basiert die Auswahl der Kategorien in der Regel auf den häufigsten Nennungen der Vorjahre.

Demografie 61% der befragten UX/Usability Professionals sind männlich, 39% weiblich. Das Durchschnittsalter der Befragten liegt bei 34 Jahren (sd=6,1; min=23; max=53). 20% der Teilnehmer arbeiten in Nordrhein-Westfalen, 19% in Bayern, 15% in Berlin/Brandenburg, 14% in Baden-Württemberg, 7% im Saarland und jeweils 6% in Hessen und SchleswigHolstein/Hamburg. Der Anteil der Befragten in anderen Bundesländern sowie außerhalb Deutschlands belief sich jeweils auf unter 6%. Die Teilnehmer sind seit durchschnittlich 6 Jahren (sd=4,5; min=0; max=25) in der UX/Usability Branche tätig.

Branchenreport UX/Usability 2015

9

Abbildung 1: Geschlechterverhältnis in der UX/Usability-Branche

Aus- und Weiterbildung Unter den 215 Teilnehmern mit akademischem Abschluss ist der meist genannte höchste akademische Grad mit 40% noch das klassische Diplom. Für 26% ist es ein MasterAbschluss, bei 21% ist es ein Bachelor-Abschluss, 5% verfügen über einen MagisterAbschluss, 4% haben promoviert (siehe Abbildung 2).

Abbildung 2: (Studien-)Abschlüsse in der UX/Usability-Branche

Die Abfrage des Ausbildungshintergrunds basierte auf den häufigsten Nennungen der Vorjahre, Tabelle 1 zeigt die meist vertretenen Studienfächer und Ausbildungsberufe (Mehrfachnennungen möglich). Wer eine UX/Usability-spezifische Zusatzausbildung absolvierte, schloss diese meist mit dem Titel "Certified Professional for Usability and User Experience" (29 Personen), "Usability Consultant" (23 Personen) oder "Usability Engineer" (19 Personen) ab. Die populärsten Ausbildungsanbieter sind wie in den Vorjahren auch das artop Institut Berlin (26 Personen) sowie die Fraunhofer Institute (12 Personen).

10

Sarah Diefenbach, Stefan Tretter, Daniel Ullrich, Nina Kolb

Studienfach/Ausbildungsberuf Informatik Medieninformatik Psychologie Digitale Medien Kommunikationsdesign Mediengestalter/in (Ausbildungsberuf) Betriebswirtschaftslehre Industriedesign Medienwissenschaft Mediengestaltung Industriedesign Informationsdesign Interaktionsdesign Informationswissenschaft Kommunikationswissenschaft Fachinformatiker/in (Ausbildungsberuf

% der Befragten 14% 12% 12% 9% 9% 7% 6% 5% 5% 5% 4% 4% 4% 4% 4% 4%

Tabelle 1: Studienfächer

Die Befragten wurden außerdem um die Angabe der drei für sie persönlich wichtigsten Aktivitäten zum Wissenserwerb im Bereich UX/Usability gebeten. Abbildung 3 zeigt die Relevanz der verschiedenen Aktivitäten. Auf die offene Frage nach weiteren besonderen Empfehlungen für UX/Usability-Wissen wurden beispielsweise außerdem genannt: LinkedIn-Gruppe IxDA, usabilitymatters.org, UI19 conference video tutorials, UIE Newsletter (Jared M. Spool), uxmag.com, uxhh.de, das UX Camp Europe und schließlich auch die Usability Professionals/Mensch und Computer Konferenz.

Branchenreport UX/Usability 2015

11

Abbildung 3: Wichtigste Aktivitäten zum UX/Usability-Wissenserwerb

Arbeitsaufgaben und Projekte Der größte Anteil der UX/Usability-Projekte ist den Branchen Industrie & Logistik mit 41% und e-Commerce mit 33% zuzuordnen, gefolgt von Medizin & Pflege und dem Automobilsektor, wie Tabelle 2 zu entnehmen ist. Neben den hier vorgegebenen Branchen (basierend auf den häufigsten Antworten der Vorjahre), wurden auch die Sektoren Finanzdienstleistung, Business Software und Touristik häufiger genannt.

Branche Industrie & Logistik e-Commerce Medizin, Pflege Automobil Elektronik Unterhaltung, Spiele Hochschule, Lehre Food, fast moving consumer goods Bekleidung Bauen & Wohnen

% der Befragten 41% 33% 19% 18% 14% 10% 7% 6% 3% 2%

Tabelle 2: Schwerpunkte von UX/Usability-Projekten

12

Sarah Diefenbach, Stefan Tretter, Daniel Ullrich, Nina Kolb

Innerhalb der Branche fallen 68% aller Projekte zumindest teilweise in den Bereich B2B, gleichzeitig können auch 66% dem Bereich B2C zugeordnet werden. "Interne Kunden" und "eigene Mitarbeiter" wurden beispielsweise als andere Zielgruppen genannt. Auf die Frage nach den Endgeräten, auf die ihre Projekte abzielten, nannten 80% der Befragten unter anderem den "Desktop". Dahinter liegen relativ gleichauf "Mobile Geräte" mit 68%, sowie "Tablets" und "Eignung für verschiedene Endgeräte (Responsive Design)" mit jeweils 62%. Zudem befassten sich auch 29% der Projekte mit anderen Endgeräten wie "Terminals", "Automobilen" und "medizinischen Geräten".

Abbildung 4: Häufigste Endgeräte in UX/Usability-Projekten

Zusätzlich wurde den Teilnehmern die Frage gestellt: Wo liegen Ihrer Meinung nach typischerweise die größten Probleme/Herausforderungen in UX/Usability Projekten? Auf einer Skala von 1 (=eher unproblematisch) bis 5 (=größte Herausforderung) ergaben sich durchschnittlich die höchsten Werte für "Analyse/User Research" (m=3,5; sd=1,2), "Transfer von Konzept zu Entwicklung" (m=3,5; sd=1,1), sowie "Transfer von Konzept zu Kunde" (m=3,4; sd=1,1) und "UAT/Qualitätssicherung" (m=3,4; sd=1,1). Im Gegensatz dazu lagen die Werte für "Transfer von Konzept zu Design" (m=2,8; sd=1,1), "Persona Entwicklung" (m=2,8; sd=1,2) und "Übersetzung von Grob- zu Feinkonzepten" (m=2,7; sd=1,2) im Schnitt deutlich niedriger. Unabhängig des Anwendungsbereichs wurden die Teilnehmer auch nach der Verteilung ihres Arbeitspensums auf unterschiedliche Aufgabenbereiche befragt. Tabelle 3 zeigt die

Branchenreport UX/Usability 2015

13

durchschnittlichen Bewertungen der in die jeweilige Tätigkeit investierten Zeit auf einer Skala von 1 (=nie) bis 5 (=sehr häufig) und die zugehörigen Standardabweichungen.

Aufgabenbereich UX Design Beratung, Stakeholder Management Prototypenentwicklung Information Architecture Usability Engineering Evaluation Requirements Engineering User Research Usability Testing

M 3,6 3,5 3,4 3,4 3,2 3,2 3,0 2,9 2,9

SD 1,2 1,3 1,2 1,2 1,2 1,1 1,3 1,2 1,2

Tabelle 3: Mittleres Arbeitspensum in verschiedenen Aufgabenbereichen (1=nie, 5=sehr häufig)

Momentane Position Zur differenzierteren Erhebung der momentanen Arbeitssituation wurden die Teilnehmer im Laufe der Befragung in Arbeitnehmer und Arbeitgeber/Freiberufler geteilt. 88% der befragten UX/Usability Professionals arbeiten in einem Angestelltenverhältnis, 12% sind selbstständig tätig als Freelancer oder Unternehmensinhaber. Im Folgenden sind Kennwerte und Analysen zur Situationen beider Personengruppen getrennt aufgeführt.

Abbildung 5: Verhältnis von Angestellten und Selbstständigen in der UX/Usability-Branche

14

Sarah Diefenbach, Stefan Tretter, Daniel Ullrich, Nina Kolb

Situation der Angestellten Die Angaben der Angestellten zur Größe ihres Unternehmens variieren von 4 bis zu 360.000 Beschäftigten (m=3,1; sd=11,5; med=100). Wie Tabelle 4 zu entnehmen ist, bilden Unternehmen mit 16 - 50 Mitarbeitern in der Stichprobe die größte Gruppe. 32% der befragten Arbeitnehmer arbeiten in Unternehmen dieser Größe, die mit durchschnittlich 38% auch den größten Anteil an Beschäftigten im Bereich UX/Usability stellen. Insgesamt beschäftigt sich im Schnitt ein Anteil von 19% (sd = 28,3) der Mitarbeiter mit dem Bereich UX/Usability.

Unternehmensgröße 1-15 16-50 51-100 101-1000 1001-1000 >10000

% der Befragten 6% 32% 12% 30% 12% 8%

% UX/Usability Beschäftigte 14% 38% 17% 11% 1% 3%

Tabelle 4: Teilnehmerverteilung und UX/Usability-Beschäftigte nach Unternehmensgröße

Auf die Frage "Beschäftigen Sie sich hauptsächlich mit der Verbesserung "eigener" Produkte (unternehmensintern) oder der Produkte von Auftraggebern?" gaben 46% der Befragten an, sich vorwiegend mit eigenen Produkten zu beschäftigen, während bei 54% der Fokus eher auf der Verbesserung fremder Produkte liegt. Wie im Vorjahr war die häufigste genannte Berufsbezeichnung die des "Usability Engineer" mit 10,6%, diesmal gleichauf mit "User Experience Consultant" und gefolgt vom "User Interface Designer" mit 6,6%. Bemerkenswert ist an dieser Stelle die Diversität in den Berufsbezeichnungen (siehe Abbildung 6). Obwohl die vorgegebenen Antwortmöglichkeiten auf den meistgenannten Berufsbezeichnungen des letzten Jahres basieren, nutzten 110 der 226 Teilnehmer die Möglichkeit, einen alternativen Jobtitel anzugeben. Die hierbei meistgenannten Berufsbezeichnungen sind "User Experience Designer", "User Experience Architect", "User Experience Researcher" und "Interaction Designer".

Branchenreport UX/Usability 2015

15

Abbildung 6: Vielfalt der Jobtitel in der UX/Usability-Branche

Bei ihrem aktuellen Arbeitgeber sind die Befragten im Schnitt seit 3,9 Jahren (sd=3,9; min=0; max=27; med=3) angestellt. Mit 23% hat rund ein Viertel der Angestellten Personalverantwortung, wobei die Übertragung von Personalverantwortung mit andauernder Unternehmenszugehörigkeit wahrscheinlicher wird (r=.18*) und mit höherem Bruttogehalt einhergeht (r=.20*). Die große Mehrheit der Angestellten (97%) besitzt derzeit eine Vollzeitstelle. Gleichzeitig geben 18% der Teilnehmer an, dass sie ihre Stelle gerne reduzieren würden. Hierbei liegt der gewünschte Stellenumfang bei durchschnittlich 79% (sd=8,9, min=50, max=95) der jetzigen Arbeitszeit. Die Diskrepanz zwischen dem mit 3% niedrigen Anteil an Teilzeitstellen und dem Wunsch nach Reduktion kann teilweise darauf zurückgeführt werden, dass die entsprechenden Angestellten nicht die Möglichkeit einer Umstellung auf Teilzeit sehen. Diejenigen Teilnehmer, die sich eine Reduktion wünschen, nehmen signifikant weniger Unterstützung für Teilzeitmodelle durch ihren Arbeitgeber wahr (m=3,2; sd=1,2; t(177)=2,95**) als diejenigen, die mit dem Umfang ihrer Stelle zufrieden sind. Hier wäre eventuell ein offenerer Umgang mit diesem Konzept von Seiten des Arbeitgebers empfehlenswert, um diese für beide Seiten auf lange Sicht ungünstige Konstellation aufzulösen.

Situation der Selbstständigen In diesem Jahr haben sich 26 Unternehmensinhaber an der Befragung zum Branchenreport beteiligt. Die Unternehmensbezeichnungen wurden über vorgegebene Kategorien abgefragt,

16

Sarah Diefenbach, Stefan Tretter, Daniel Ullrich, Nina Kolb

die sich jeweils aus den meistgenannten Bezeichnungen der entsprechenden offenen Frage der letzten Jahre ergaben. Unter den 26 Unternehmensinhabern bezeichnen sich 8 Personen als "Freelancer", während weitere 8 Personen ihr Unternehmen als "Beratung" beschreiben. Weitere 4 Personen betreiben eine "Agentur", 2 Personen bezeichnen ihr Unternehmen als "Consulting" und eine Person betreibt ein "Designstudio/-büro". Beispiele für weitere Nennungen sind "Startup", "Design- und Softwareentwicklung" sowie "Softwarehersteller". Die Unternehmensgründung liegt im Schnitt 6 Jahre zurück, allerdings sind auch Inhaber ganz frisch gegründeter Unternehmen vertreten (sd=5,5; min=0; max=20). 33% der Selbstständigen arbeiten allein, der Großteil beschäftigt Angestellte. In vielen Fällen (38%) beläuft sich diese Zahl allerdings auf nur einen Angestellten. Der Anteil von Selbstständigen mit zwei bis sechs Mitarbeitern liegt dieses Jahr bei 17%, Selbständige mit 30 Angestellten und mehr bilden in diesem Jahr 13% der Stichprobe. Das größte Unternehmen hat 60 Mitarbeiter. Im Durchschnitt brauchen die Unternehmensinhaber 3,3 Monate (sd=2,3; min=0, max=6) bis sie eine offene Stelle besetzen können. Als häufigste Schwierigkeit bei der Suche nach einem passenden Bewerber wird hierbei fehlendes Fachwissen im Bereich UX/Usability, beispielsweise zu Usability-Methoden, angeführt (35%), gefolgt von mangelnder Berufserfahrung (31%), überhöhten Gehaltsvorstellungen (27%) sowie der Tatsache, dass es insgesamt zu wenige Bewerber für eine Stelle gibt (19%). Weniger häufig auftretende Schwierigkeiten bei der Bewerbersuche sind fehlende Expertise in Bezug auf spezifische Programme oder Tools wie z.B. Prototyping-Tools (15%) und mangelnde Soft Skills (12%). Die nach wie vor größte Herausforderung bei der Unternehmensgründung besteht für Unternehmer darin, potentiellen Auftraggebern die Relevanz von Usability zu vermitteln, 62% der Selbstständigen stimmen hier zu. Eine weitere Herausforderung stellt die Kontaktaufnahme zu potentiellen Auftraggebern (54%) dar, sowie die Vermittlung der eigenen Professionalität bzw. die Abgrenzung von "unseriösen" Konkurrenten (42%). 31% berichten von Schwierigkeiten, bei Entwicklern Anerkennung zu finden. Weitere genannte Herausforderungen sind beispielsweise "bei Designern Anerkennung finden" oder die Tatsache, dass "zu wenige Projekte für Dienstleister" verfügbar seien und "folglich ein großer Preisruck" entstehe. Dies wird darauf zurückgeführt, dass "große Unternehmen eigene Fachabteilungen etabliert haben und keine Dienstleister mehr benötigen. Auch UsabilityConsulting ist nicht mehr gefragt." Die relative Wichtigkeit der Herausforderungen hat sich somit im Vergleich zum Vorjahr nicht geändert. Die Auftragslage des vergangenen Jahres beurteilten die selbstständigen Teilnehmer auf einer Skala von 1 (=nicht zufriedenstellend) bis 5 (=sehr zufriedenstellend) mit durchschnittlich 4,0 (sd=0,9), also als eher zufriedenstellend. Damit unterscheidet sich die Bewertung des vergangenen Jahres nicht von den Erwartungen in Bezug auf die Auftragslage des aktuellen Jahres mit m=4,0 (sd=0,9).

Branchenreport UX/Usability 2015

17

Arbeitszufriedenheit und Unternehmenskultur Auf die Frage "Wie beurteilen Sie Ihre Tätigkeit im UX/Usability-Bereich im Vergleich zu typischen Tätigkeitsfeldern Ihrer (ehemaligen) Studienkollegen?" gaben die Befragten auf einer Skala von 1 (=gering) bis 5 (=hoch) für alle abgefragten Aspekte positive Einschätzungen, welche den Skalenmittelpunkt von 3 signifikant übersteigen. Die höchsten Mittelwerte ergaben sich hier für die Aspekte "Vielfalt, Abwechslung" (m=4,6; sd=0,9), "Spaß an der Arbeit" (m=4,0; sd=0,8) und "Gestaltungsspielraum/Eigenständigkeit" (m=4,0; sd=0,9), etwas niedriger lagen die Mittelwerte hinsichtlich "Stress/Zeitdruck" (m=3,6; sd=1,0), "Weiterbildungsmöglichkeiten" (m=3,5; sd=1,0) und "Gehalt" (m=3,3; sd=1,0). Alles in allem scheinen die Befragten also mit dem eingeschlagenen Weg in Richtung UX/Usability zufrieden und haben das Gefühl in der richtigen Branche gelandet zu sein. Der Arbeitszeitanteil der tatsächlich für Tätigkeiten im Bereich UX/Usability genutzt wird liegt bei durchschnittlich 54%, der Median bei 75%, d.h. die Hälfte der Befragten können sich zu 75%-100% ihrer Arbeitszeit reinen UX/Usability-Tätigkeiten widmen. Zur Frage nach dem Anteil der Vorschläge zur Verbesserung von UX/Usability der tatsächlich realisiert wird, reichen die Einschätzungen der Befragten von 0% bis 95%, der Mittlerwert liegt hier bei 54% und der Median bei 60%. Mit zunehmender Berufserfahrung werden die Einschätzungen positiver (r=.16*), bedeutsam ist außerdem die Art der Aufgabenschwerpunkte: Besonders positive Einschätzungen kommen von Teilnehmern mit Aufgabenschwerpunkten im Bereich UX Design (r=.23*) und User Research (r=.19**) sowie allgemein von Teilnehmern die einen hohen Anteil ihrer Zeit für Aufgaben im Bereich UX/Usability aufwenden können (r=.39**). Eine Analyse von Zusammenhängen zwischen geschätzter Realisationsrate und Angaben zu den häufigsten Problemen in UX/UsabilityProjekten zeigt, dass die Nicht-Umsetzung von Vorschlägen oftmals im Zusammenhang mit Transferverlusten im Entwicklungsprozess steht – dies betrifft sowohl den Transfer von Konzept zu Design (r=-.16*), von Konzept zu Entwicklung (r=-.13*) als auch von Konzept zu Kunde (r=-.14*). Unter den UX/Usability Professionals die in einem Angestelltenverhältnis arbeiten, wurden außerdem die Arbeitszufriedenheit und wahrgenommene Unternehmenskultur beim momentanen Arbeitgeber erfragt. 63% der Angestellten sind bei ihrem momentanen Arbeitgeber eher/sehr zufrieden, 15% sind eher/sehr unzufrieden, 22% beantworteten die Frage neutral. Spezifische Aspekte positiver Unternehmenskultur wurden in Anlehnung an das Great Place to Work Modell (greatplacetowork.de) erfasst, welches die Dimensionen "Glaubwürdigkeit", "Respekt", "Fairness", "Stolz" und "Teamgeist" unterscheidet. Die Dimensionen wurden auf einer Skala von 1 (=sehr unzufrieden) bis 5 (=sehr zufrieden) mit jeweils drei Items erfasst, die Werte der internen Skalenkonsistenz waren zufriedenstellend (Cronbachs Alpha .77-.87). Mit Ausnahme der Dimension "Glaubwürdigkeit" liegen die Mittelwerte für alle Dimensionen signifikant über dem Skalenmittelpunkt (=3). Am positivsten wird von den Angestellten der "Teamgeist" beurteilt (z.B. Vertrautheit im Team, man selbst sein können, sich aufeinander verlassen können; m=3,9; sd=0,9). Für die Dimension "Glaubwürdigkeit" (z.B. Integrität des

18

Sarah Diefenbach, Stefan Tretter, Daniel Ullrich, Nina Kolb

Managements, klare Visionen, Einhaltung von Versprechungen) liegt der Mittelwert mit 3,1 (sd=1,1) nur im neutralen Bereich – gleichzeitig findet sich für die "Glaubwürdigkeit" die stärkste Korrelation zur Gesamtzufriedenheit (r=.72**). Es scheint also besonders wichtig, den Aspekt der Glaubwürdigkeit gezielt zu stärken. Ansatzpunkte sind hier beispielsweise die Schaffung verbesserter Möglichkeiten des wechselseitigen Dialogs zwischen Management und Mitarbeitern, eine klare Kommunikation von Erwartungen und konsistente Äußerungen seitens der Führungskräfte, sowie eine gute Mitarbeiterkoordination mit sinnvollen Aufgabenzuweisungen. Erfasst wurde außerdem die wahrgenommene organisationale Unterstützung von Innovation, zum Einsatz kam hier die "Support for Innovation Scale" (Scott & Bruce, 1994; 13 Items auf einer 5er Skala; Cronbachs Alpha .91). Mit einem Mittelwert von 3,6 (sd=0,7) liegt die Innovationsunterstützung im oberen Skalenbereich. Die Korrelation zur Gesamtzufriedenheit liegt bei .63**. Das bedeutet, dass Unterschiede in der Zufriedenheit der Angestellten zu 40% durch die organisationale Unterstützung von Innovation erklärt werden können, was angesichts vieler weiterer Faktoren für Zufriedenheit ein bemerkenswerter Anteil ist. Es besteht außerdem eine positive Korrelation zur Einschätzungen bezüglich des Anteils tatsächlich umgesetzter eigener Vorschläge zur Verbesserung von UX/Usability (r=.34**).

Verdienst Das durchschnittliche Bruttojahresgehalt liegt in diesem Jahr bei 52.409€ (sd=17.090; min=12.000; max=130.000; Berücksichtigung der Inhaber von Vollzeitstellen), und entspricht damit in etwa dem Wert vom Vorjahr (2014: 52.872€). Erfragt wurden außerdem etwaige Gehaltserhöhungen zum Vorjahr auf individueller Ebene, hier reichen die Angaben von 0 € bis 20.000 €. Im Mittel konnten die Befragten eine Steigerung des Bruttojahresgehalts um 3.614€ (sd=3.929) gegenüber dem Vorjahr verzeichnen, der Median liegt bei 3.000€. Wichtigster Gehaltsprädiktor ist die Berufserfahrung im Bereich UX/Usability (r=.64**). Tendenziell höhere Gehälter finden sich außerdem in größeren Unternehmen (r=.17*) sowie unter UX/Usability Professionals mit Aufgabenschwerpunkten in den Requirements Engineering (r=.32**), Usability Engineering (r=.31**) und Beratung/Stakeholder Management (r=.27**). Die angegebenen Korrelationen sind partielle Korrelationen, welche Zusammenhänge von Aufgabenschwerpunkten und Berufserfahrung berücksichtigen.

Branchenreport UX/Usability 2015

19

Abbildung 7: Gehälter unter angestellten UX/Usability Professionals

Der mittlere Stundensatz unter selbstständig tätigen UX/Usability Professionals liegt bei 63€ (min=11; max=80; sd=19), der mittlere Tagessatz bei 697€ (min=500; max=1.000; sd=189) mit einer durchschnittlichen Auslastung von 154 Tagen pro Jahr (min=70; max=365; sd=64).

Abbildung 8: Stundensätze unter selbstständig tätigen UX/Usability Professionals

Aktuelle Trends und Herausforderungen im UX/Usability-Bereich Zur Frage nach besonders begeisternden Entwicklungen und Trends im Bereich interaktive Produkte und Interaktionstechniken sind die meistgenannten Schlagwörter Virtual Reality (insb. Oculus Rift), Responsive Design, Smart Home, Mobile Design, MedienstreamingDienste (insbesondere Netflix), Lean UX, Internet of Things, Wearables, Apple Watch, Google Glass, Flat Design und die Erweiterung durch Google Material Design, sowie Fitness & Health Gadgets. Einige dieser Nennungen finden sich gleichzeitig auch unter den von den Teilnehmern als überschätzt bzw. nervig empfundenen Trends: Das mit Abstand meist genannte Schlagwort ist hier (schlechtes) Flat Design, gefolgt von Smart Watches (insb. Apple Watch) und Fitness & Health Gadgets, Google Glass, Facebook, Smart Home, Kachel Design, Parallax Scrolling. Beispiele weiterer Nennungen sind das "Sharing von Tracking-Daten", "die sogenannte Apple-Experience", "zu große Handy-Displays" oder "Grafiken, die den

20

Sarah Diefenbach, Stefan Tretter, Daniel Ullrich, Nina Kolb

Gegenstand und die Teildomänen des Themas User Experience beschreiben, kann ich echt nicht mehr sehen." Zu wenig beachtetes bzw. ungenutztes Potential sehen die Teilnehmer hingegen im B2BBereich. Zahlreiche Teilnehmer beklagen, dass UX/Usability sich zu lange auf den Consumer Bereich fokussiert hat, insbesondere auch der klinischen Bereich wird häufig als zukunftsträchtiges Feld für UX/Usability Professionals genannt. Beispiele weiterer Nennungen sind "Besseres Verständnis von und Zusammenarbeit mit anderen Berufszweigen", "Nutzen von UCD in der Wirtschaft bekannt machen" sowie "Bereitschaft des Managements die Entwickler zum Kunden zu schicken" oder auch "Geräte, die das Bastlerherz höher schlagen lassen (z.B. Raspberry Pi)".

Unternehmen der Branche Auf die Frage "Welche Unternehmen im deutschsprachigen Raum fallen Ihnen spontan ein, wenn Sie an Usability/UX denken?" waren die meistgenannten Unternehmen UID (85), Ergosign (32), Artop (30), eResult (28), Centigrade (26), GfK SirValUse (26), Conze (14), Bosch (11), Fraunhofer (10), usability.de (10) und USEEDS (10). Weitere Unternehmen wurden jeweils von weniger als 10 Befragten genannt. Danksagung Herzlichen Dank an alle Branchenreport-Teilnehmer, ohne deren Bereitschaft der vorliegende Report nicht möglich gewesen wäre. Außerdem ein großes Dankeschön an Tim Keißelt für die kreative Unterstützung bei der Erstellung der Abbildungen! Literatur Scott, S. G., & Bruce, R. A. (1994). Determinants of innovative behavior: A path model of individual innovation in the workplace. Academy of Management Journal, 37(3), 580-607. Great Place to Work (2015). Das Great Place to Work Modell. Retrieved from http://www.greatplacetowork.de/storage/documents/GPTW_Modell.pdf

Full Paper

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 22- 32.

Wie schnell ist „schnell“ bei BusinessSoftware? Analyse zur Performance bei der Nutzung von Business-Software Wolfgang Bonhag, Doreen Feindt, Siegfried Olschner, Ulf Schubert

Wolfgang Bonhag

Doreen Feindt

Dr. Siegfried Olschner

Ulf Schubert

DATEV eG Fürther Straße 111 90329 Nürnberg [email protected]

GfK SE Burchardstraße 19 20095 Hamburg [email protected]

DATEV eG Fürther Straße 111 90329 Nürnberg [email protected]

DATEV eG Fürther Straße 111 90329 Nürnberg [email protected]

Abstract Die Performance einer Software ist ein wichtiger Einflussfaktor für die User Experience. Dabei hängt die Zufriedenheit mit der Performance eines Systems nicht nur von der tatsächlichen Geschwindigkeit, sondern auch von der Erwartungshaltung der Anwender ab. Wir stellen in diesem Beitrag die Ergebnisse einer Studie vor, in der wir der Frage nachgegangen sind, welche Geschwindigkeit bei spezifischen Interaktionskategorien vom Anwender akzeptiert wird. Dabei wurden 733 Teilnehmern simulierte System-Bearbeitungszeiten innerhalb einer simulierten Business-Software vorgegeben. Es wurden insgesamt 7 Aufgaben/Benutzerinteraktionen abgebildet (aus drei unterschiedlichen Interaktionskategorien), für welche jeweils 4 unterschiedliche System-Bearbeitungszeiten simuliert wurden. Aufgrund der erhobenen Daten konnte für zwei der drei Interaktionskategorien eine klare Empfehlung für die Performance von Business-Software abgeleitet werden.

Keywords Performance-Messung, Bearbeitungszeiten

Interaktionskategorien,

Bearbeitungszeiten,

Ladezeiten,

System-

Wie schnell ist „schnell“ bei Business- Software?

23

Einleitung Die Geschwindigkeit von Software (Performance) wird von ihren Anwendern in der Regel nicht objektiv, sondern subjektiv eingeschätzt. Die Einschätzung basiert dabei nicht allein auf der tatsächlichen Reaktionszeit, sondern auch auf den mit vergleichbaren Systemen gemachten Erfahrungen und den Erwartungen an die Performance. Um die einzelnen Aspekte zu berücksichtigen, welche die subjektiv wahrgenommene Performance ausmachen, verwendet DATEV das nachfolgende Modell (Schubert 2013).

Abbildung 1: Elemente subjektiver Performance (Schubert 2013) – In diesem Artikel wird anstelle des Begriffs Bearbeitungszeit die Benennung System-Bearbeitungszeit verwendet.

Nach diesem Modell besteht die subjektiv wahrgenommene Performance aus der Reaktionszeit, der System-Bearbeitungszeit und der Zeit, die Anwender benötigen, um die nächsten Schritte zu planen. Die Reaktionszeit ist die Zeitdauer, die eine Anwendung benötigt, um auf die Eingabe des Anwenders zu reagieren. Die Reaktion kann entweder das direkte Ausführen der gewünschten Aktion oder ein Systemfeedback über die zu erwartende System-Bearbeitungszeit sein. Die Reaktionszeit ist etwas, worauf bei der Entwicklung häufig am meisten geachtet wird, denn diese kann man gut messen. Sie macht aber oft nur einen kleinen Teil der subjektiv erlebten Performance aus. Für das subjektive Erlebnis spielt die System-Bearbeitungszeit eine große Rolle. Diese beschreibt die Dauer, die Anwender und Anwendung benötigen, um eine Arbeitsaufgabe zu bearbeiten und abzuschließen. Betrachtet man die Performance umfassend, muss bei der Bewertung derselben auch die Zeit betrachtet werden, die ein Anwender zur Planung der weiteren Interaktionsschritte benötigt. Für die Reaktionszeit ist es nicht notwendig, Zeitvorgaben zu ermitteln. Auf die Eingabe des Anwenders muss ein System generell innerhalb von wenigen Millisekunden reagieren minimal mit einer Anzeige, dass eine Wartezeit erfolgt, maximal mit einer Meldung über die geschätzte Dauer der System-Bearbeitungszeit (Systemfeedback). In der vorliegenden Studie haben wir uns auf die System-Bearbeitungszeit konzentriert. Die Hauptfragestellung war, wie lange die System-Bearbeitungszeit eines Systems bei

24

Wolfgang Bonhag, Doreen Feindt, Siegfried Olschner, Ulf Schubert

unterschiedlichen Interaktionen dauern darf, ohne die Zufriedenheit der Anwender mit dem System negativ zu beeinflussen. Dabei war es insbesondere interessant herauszufinden, welche Erwartungen Anwender an unterschiedliche Interaktionen haben. Weiterhin ging es uns um die Ableitung von Empfehlungen von System-Bearbeitungszeiten für bestimmte Interaktionsformen, die als Leitlinie für die Entwicklung bzw. als nicht-funktionale Anforderungen verwendet werden können.

Untersuchungsmethode Allgemeines Vorgehen Zur Vorgabe der System-Bearbeitungszeiten an eine große Teilnehmeranzahl und zur Abfrage einer Bewertung derselben wurde im Jahr 2012 von GfK und DATEV ein OnlineFragebogen konzipiert, der neben klassischen Frageformen auch einen Klickdummy enthielt. Dieser Klickdummy war in Form einer fiktiven Business-Software mit klassischem Bildschirmaufbau gestaltet und stellt nacheinander mehrere Screenshots mit einer simulierten System-Bearbeitungszeit dar. Die dargestellten fiktiven Oberflächen enthielten vor allem Listen und Tabellen. Ein optischer Bezug zu einer bestimmten im Markt befindlichen Business-Software wurde vermieden. Die Genauigkeit, in der die System-Bearbeitungszeiten simuliert werden konnten, wurde leicht durch den verwendeten Browser und die Internet-Verbindungsgeschwindigkeit beeinflusst. Um die Messfehler zu mitteln, war eine hohe Anzahl an Messungen notwendig.

Stichprobe Insgesamt beteiligten sich 733 Personen an der Studie. Das Durchschnittsalter betrug 42,4 Jahre (zwischen 18 und 80). 45,6 % der Teilnehmer waren weiblich, 54,4 % der Teilnehmer waren männlich. Alle Teilnehmer verwendeten bei ihrer beruflichen Arbeit Business-Software und nutzten diese mindestens „mehrmals pro Woche“. Weiterhin war die Nutzung einer DSLInternetverbindung Voraussetzung, und es konnten nur Nutzer von Desktop-PCs oder Notebooks teilnehmen. Die Rekrutierung der Teilnehmer erfolgte aus einem Online-Panel mit Mitgliedern aus unterschiedlichen Unternehmen. Zur Überprüfung, ob bezüglich Performance eine einheitliche Erwartungshaltung besteht, wurde mit Hilfe einer allgemeinen Kontrollfrage nach der subjektiv erlebten Performance von Microsoft Word gefragt. 86 % der Teilnehmer bewerten die Performance von Word als "angemessen" (Ladezeit zwischen einem Klick und dem Erscheinen des Ergebnisses). Deswegen betrachten wir die Stichprobe als ausreichend homogen.

Wie schnell ist „schnell“ bei Business- Software?

25

Maskierung des Untersuchungsziels Um eine zu starke Fokussierung der Teilnehmer auf die Warte- bzw. SystemBearbeitungszeit zu vermeiden, wurde das Hauptziel der Studie nicht explizit genannt. Die Befragung wurde allgemein als „Untersuchung der Qualität einer Business-Software“ angekündigt. Neben den Fragen zur Einschätzung der System-Bearbeitungszeit wurden zwei zusätzliche Fragen zur Gestaltung der Software und zur Auffindbarkeit von Bedienelementen gestellt. Diese wurden nicht ausgewertet. Die Fragen lauteten: Wie beurteilen Sie die Ladezeit zwischen Ihrem Klick und dem Erscheinen der Ergebnisse? (Antwortmöglichkeiten: „Zu schnell“, „Angemessen“ und „Zu langsam“). Maskierungsfrage: Wie schwierig war es für Sie, das richtige Bedienelement zum Start der Aktion zu finden? (Antwortmöglichkeiten: „Überhaupt nicht schwierig“, „Etwas schwierig“ und „Sehr schwierig“). Maskierungsfrage: Wie hat Ihnen die Gestaltung der Oberfläche gefallen? (Antwortmöglichkeiten: „Sehr gut“, „Gut“, „Teils-teils“, „Schlecht“ und „Sehr schlecht“). Bei der Frage zur System-Bearbeitungszeit/Ladezeit wurde bewusst eine 3-stufige Skala gewählt („Zu schnell“, „Angemessen“ und „Zu langsam“). Eine stärkere Unterteilung wie z.B. in "etwas zu langsam" und "viel zu langsam" hätte für die spätere Festlegung eines Bewertungssystems keinen Mehrwert geliefert, da sowieso eine dichotome Kategorisierung angestrebt wurde (Ladezeit in Ordnung vs. nicht in Ordnung). Die Antwortkategorie "zu schnell" entspricht in diesem Zusammenhang eher einer Kontrolloption.

Versuchsbeschreibung Interaktionskategorien Im Rahmen dieser Grundlagen wurden unterschiedliche Interaktionsformen zu Interaktionskategorien gruppiert. Alle Interaktionsformen beziehen sich auf die Interaktion mittels Maus und Tastatur (Shneiderman 1984; Seow 2008). Eine Interaktionskategorie (IK) beschreibt eine Gruppe von Interaktionsformen, für die eine ähnliche Erwartungshaltung hinsichtlich Performance besteht. Das Konzept der Interaktionskategorien wurde von DATEV auf die eigenen Bedürfnisse angepasst. Insgesamt wurden fünf Interaktionskategorien definiert. Die System-Bearbeitungszeiten bei diesen fünf Interaktionskategorien reichen von wenigen Millisekunden in der Interaktionskategorie 1 (IK1) bis hin zu mehreren Minuten oder gar Stunden in der Interaktionskategorie 5 (IK5). Die konzipierten Interaktionskategorien werden wie folgt definiert:

26

Wolfgang Bonhag, Doreen Feindt, Siegfried Olschner, Ulf Schubert

IK1: Alle Interaktionen, die in Zusammenhang mit der Hand-Auge-Koordination stehen und bei denen der Anwender vom System ein direktes Feedback erwartet und benötigt. (z. B. Tastatureingabe, Anzeigen eines Mouseovers, Anzeigen eines Textcursors nach Klick in einem Eingabecontrol). IK2: Alle Interaktionen, die mit der direkten Manipulation bzw. Änderung der Oberfläche zusammenhängen und bei denen der Anwender eine zeitnahe Umsetzung der angeforderten Aktion erwartet (z. B. Ein-/Ausblenden eines Bereichs der Bedienoberfläche, Sortieren einer Liste, Wechsel einer Registerkarte). IK3: Alle Interaktionen, die in Arbeitsprozesse integriert sind. "Integriert" bedeutet, dass vor und nach dieser Interaktion weitere Interaktionen vom Anwender zu tätigen sind (z. B. Öffnen eines Dialogfensters mit umfangreichen Daten, Start einer Unteranwendung aus einer bereits geöffneten Anwendung heraus, Refresh der gesamten Oberfläche). IK4: Alle Interaktionen zur Vorbereitung oder am Ende eines Arbeitsprozesses oder Tätigkeit, wie z. B. Neustart einer Anwendung, umfangreiche Berechnungen oder Erstellen von Reports. Beim Beenden eines Arbeitsprozesses wird davon ausgegangen, dass der Anwender danach seine Interaktion mit dem System in einem anderen Arbeitsprozess fortsetzt. IK5: Alle Interaktionen zur Vorbereitung oder am Ende eines Arbeitsprozesses, bei denen der Anwender von vornherein eine längere System-Bearbeitungszeit erwartet, wie z. B. Installation, Systemwartung, Update. Üblicherweise dauern diese Interaktionen länger. ¥ Die vorliegende Studie konzentriert sich auf die Interaktionskategorien 2 bis 4, da für die Interaktionskategorien 1 und 5 Zeitangaben entweder offensichtlich oder nicht sinnvoll sind.

System-Bearbeitungszeit und Systemfeedback Für die verwendeten drei Interaktionskategorien wurde jeweils ein eigenes Set von vier System-Bearbeitungszeiten vorgegeben, z. B. 0, 1, 2 oder 3 Sekunden bei IK2 [Tabelle 1], wobei 0 Sekunden einen idealen Wert darstellen. Ebenso wurde für jede Interaktionskategorie ein übliches spezifisches Systemfeedback angezeigt, z. B. eine Sanduhr bei IK2 und ein Fortschrittsbalken bei IK4.

Aufgabenstellungen Insgesamt wurden jedem Teilnehmer vier Aufgaben vorgelegt. Pro Interaktionskategorie gab es zwei bis drei verschiedene Interaktionen, die mit jeweils vier verschiedenen SystemBearbeitungszeiten getestet wurden, woraus sich 28 Aufgaben-BearbeitungszeitKombinationen ergeben. Die Auswahl der vier Aufgaben pro Teilnehmer aus dem Set von 28 möglichen Kombinationen erfolgte zufällig. Allerdings wurde ausgeschlossen, dass ein Teilnehmer die gleiche Interaktion zweimal beurteilt, nur jeweils mit unterschiedlichen Zeiten. Jede der 28 Kombinationen wurde von mindestens 100 Teilnehmern bearbeitet. Die

Wie schnell ist „schnell“ bei Business- Software?

27

Ergebnisdaten der Kombinationen zeichnen sich somit durch eine hohe Teilnehmeranzahl aus.

Nr.

IK

Beispiel für Aufgabenstellung

1

2

2

eine

SystemBearbeitungszeiten in Sek.

Feedback während der System-Bearbeitungszeit

Wechsel einer Liste von einer Listenansicht in eine Detailansicht

0, 1, 2, 3

Sanduhr (ab 1 sec System-Bearbeitungszeit)

2

Sortieren einer Liste nach einer anderen Spalte

0, 1, 2, 3

3

3

Öffnen eines Arbeitsblattes aus der Übersicht links

3, 5, 7, 9

4

3

Wechsel des angezeigten Dokuments über einen Navigator

3, 5, 7, 9

5

3

Datenbearbeitung aus laufenden Anwendung

3, 5, 7, 9

6

4

Start einer Anwendung vom Desktop

9, 13, 17, 21

7

4

Erstellen eines umfangreichen Reports, incl. Grafiken

9, 13, 17, 21

der

Animierte Grafik (drehende Uhr mit Erläuterungstext)

Fortschrittsbalken mit festem Erläuterungstext

Tabelle 1: Sieben Aufgaben in jeweils vier System-Bearbeitungszeiten ergeben 28 Aufgaben -BearbeitungszeitKombinationen.

Ziel einer jeden Aufgabe ist es, eine einzige Frage zu beantworten: War die gerade erlebte System-Bearbeitungszeit bezogen auf die Interaktion „zu schnell“, „angemessen“ oder „zu langsam“? Um die Erwartungshaltung zu setzen, enthielt jede Aufgabenbeschreibung eine Information über die zu erwartende Reaktion des Systems. ¥ Der Ablauf bei jeder der 28 Einzelaufgaben war stets gleich gestaltet. Die unterschiedlichen Aufgaben und System-Bearbeitungszeiten wurden den Teilnehmern zufällig rotiert vorgegeben: Der Anwender erhält eine aufgabenspezifische Anleitung:

28

Wolfgang Bonhag, Doreen Feindt, Siegfried Olschner, Ulf Schubert

Beispiel IK3: Bitte öffnen Sie den Kontenplan, indem Sie auf den entsprechenden Eintrag im Dropdown-Menü klicken. Sie öffnen damit ein neues Fenster, in dem die gewählte Anwendung gestartet wird. Nach dem Klick auf das angesprochene Bedienelement startet die System-Bearbeitungszeit, und entsprechend der Interaktionskategorie wird das Systemfeedback eingeblendet. Nach Ablauf der System-Bearbeitungszeit wird das Ergebnis der Interaktion angezeigt, z. B. öffnet sich der Kontenplan (Abbildung 2). Danach wurden die drei Bewertungsfragen vorgelegt.

Abbildung 2: Beispiel für die Simulation des Öffnens eines Reports.

Ergebnisse Interaktionskategorie 2 Die Ergebnisse der Aufgaben aus IK2 sind nicht aussagekräftig. Bei den Bewertungen ist kein Trend erkennbar; es werden sehr lange System-Bearbeitungszeiten toleriert. Vermutlich ist die Fragebogensituation nicht mit einer „echten“ Arbeitssituation vergleichbar. Abbildung 3 zeigt kaum Veränderungen bei den Prozentverteilungen der Antwortkategorien.

Antworten in % (N = 100 bis 103 pro Wartezeit)

Wie schnell ist „schnell“ bei Business- Software?

29

100% 80% 60% 40% 20% 0%

0

1

2

3

0

Aufg. 1 - Wartezeit in Sek. Zu schnell

1

2

3

Aufg. 2 - Wartezeit in Sek.

Angemessen

Zu langsam

Abbildung 3: Bewertung der System-Bearbeitungszeit bei Wechsel von einer Listenansicht in eine Detailansicht (Aufgabe 1) und Sortieren einer Liste nach einer anderen Spalte (Aufgabe 2).

Interaktionskategorie 3

Antworten in % (N = 100 bis 103 pro Wartezeit)

Bei IK3 ist bei zwei Aufgaben ein klarer Trend erkennbar. Alle drei Aufgaben zeigen eine interpretierbare Verlaufslinie für die Bewertung „zu langsam“ (Abbildung 4).

100% 80% 60% 40% 20% 0%

3

5

7

9

3

5

7

9

3

5

7

9

Aufg. 3 - Wartezeit Aufg. 4 - Wartezeit Aufg. 5 in Sek. in Sek. Wartezeit in Sek. Zu schnell

Angemessen

Zu langsam

Abbildung 4: Öffnen eines Arbeitsblattes aus der Übersicht links (Aufgabe 3) und Wechsel des angezeigten Dokuments über einen Navigator (Aufgabe 4) und Datenbearbeitung aus der laufenden Anwendung (Aufgabe 5).

30

Wolfgang Bonhag, Doreen Feindt, Siegfried Olschner, Ulf Schubert

Interaktionskategorie 4

Antworten in % (N = 100 bis 103 pro Wartezeit)

IK4 zeigt ebenfalls interpretierbare Messergebnisse. In einer Aufgabe kommt es zu einer Überschneidung der Linien „Angemessen“ und „Zu langsam“ [Abbildung 5].

100% 80% 60% 40% 20% 0%

9

13

17

21

Aufg. 6 - Wartezeit in Sek. Zu schnell

Angemessen

9

13

17

21

Aufg. 7 - Wartezeit in Sek. Zu langsam

Abbildung 5: Start einer Anwendung vom Desktop (Aufgabe 6) und Erstellen eines umfangreichen Reports, incl. Grafiken (Aufgabe 7).

Interpretation der Bewertungen Die in der Studie erhobenen Bewertungen sind nur aussagefähig in Verbindung mit einem Norm-System. Dieses wurde von uns individuell festgelegt und könnte je nach Anwendungskontext auch anders justiert werden. Bei der Interpretation der Daten wird der Anteil der Studien-Teilnehmer, die mit einer erlebten System-Bearbeitungszeit unzufrieden sind, herangezogen. Diese bestimmen durch ihre Anzahl die Qualität der gezeigten Performance. Je höher der Anteil der unzufriedenen Teilnehmer bei einer System-Bearbeitungszeit ist, desto schlechter ist die Bewertung der System-Bearbeitungszeit. Tabelle 2 zeigt unseren Vorschlag für eine strenge Auslegung der Bewertungen (Norm-System).

Wie schnell ist „schnell“ bei Business- Software? „Schnell genug“

„Sollte sein“

schneller

Bearbeitungszeiten, mit denen weniger als 10 % der Teilnehmer der Studie unzufrieden sind

Bearbeitungszeiten, mit denen 10 bis 20 % der Teilnehmer der Studie unzufrieden sind

31

„Zu langsam“

„Viel zu langsam“

Bearbeitungszeiten, mit denen 20 bis 30 % der Teilnehmer der Studie unzufrieden sind

Bearbeitungszeiten, mit denen mehr als 30 % der Teilnehmer der Studie unzufrieden sind

Tabelle 2: Beispiel für eine strenge Auslegung der Bewertung (Norm-System).

Übertragung der Werte in Anforderungstabellen Anhand der Verteilungen der Bewertungen können auf Basis der in Tabelle 2 festgelegten Prozentwerte Anforderungen an die System-Bearbeitungszeiten in IK3 und IK4 formuliert werden. Tabelle 3 zeigt die Umsetzung in Sekundenwerte. System-Bearbeitungszeiten, die im Bereich "sind schnell genug" liegen, bedürfen keiner Optimierung. Liegen die System-Bearbeitungszeiten allerdings in den Bereichen "sollten schneller sein", "sind zu langsam" oder "sind viel zu langsam", besteht Handlungsbedarf. Die Bearbeitungszeiten …

Interaktionskategorie 3

Interaktionskategorie 4

… sind schnell genug

Bis 3,5 Sekunden

Bis 7 Sekunden

… sollten schneller sein

3,5 bis 5,5 Sekunden

7 bis 10,5 Sekunden

… sind zu langsam

5,5 bis 7 Sekunden

10,5 bis 14,5 Sekunden

… sind viel zu langsam

Ab 7 Sekunden

Ab 14,5 Sekunden

Tabelle 3: Empfehlungen für System-Bearbeitungszeiten der Interaktionskategorie 3 und 4

Diskussion Die große Anzahl der Teilnehmer ermöglicht es, mit dieser Studie valide Messwerte zu präsentieren. Die Übertragbarkeit der Ergebnisse auf reale Business-Software muss jedoch mit Vorsicht erfolgen, da die Messungen nicht in einer realen Arbeitssituation erfolgten. Bei der Übertragung der Ergebnisse ist es notwendig, die Erwartungshaltungen der Anwender an die Software zu berücksichtigen. Es ist davon auszugehen, dass sich die Erwartungshaltungen zwischen unterschiedlichen Anwendergruppen und Nutzungskontexten unterscheiden. Außerdem verändert die Erfahrung der Anwender im Umgang mit digitalen Produkten und Dienstleistungen die Erwartungshaltung im Zeitverlauf. Es ist davon

32

Wolfgang Bonhag, Doreen Feindt, Siegfried Olschner, Ulf Schubert

auszugehen, dass die Erwartungen hinsichtlich der Dauer von System-Bearbeitungszeiten steigen. Die Empfehlungen für die System-Bearbeitungszeiten in IK3 und IK4 können aktuell als Orientierung für die Einschätzung der System-Bearbeitungszeiten in Business-Software herangezogen werden. Weiterhin können sie als nicht-funktionale Anforderungen in die Entwicklung von Business-Software übernommen werden. Literatur Butler, T. W. (1983). Computer Response Time and Use Performance. In Proceedings of ACM SIGCHI ’83 Conference on Human Factors in Computer Systems (1983), 58-62. New York: ACM. Miller, R. B. (1968). Response time in man-computer conversational transactions. In Proc. AFIPS Fall Joint Computer Conference Vol. 33, 267-277. Montvale, NJ: AFIPS Press. Seow, S. C. (2008). Designing and Engineering Time: The Psychology of Time Perception in Software. Boston MA: Addison Wesley Professional Schubert, U. (2013) Performance ist nicht objektiv messbar. http://www.user-experienceblog.de/2013/08/performance_ist_nicht_objektiv. Letzter Aufruf: Juni 2015. Shneiderman, B. (1984). Response Time and Display Rate in Human Performance with Computers. In ACM Computing Surveys, Vol. 16, No. 3. New York: ACM

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 33- 41.

Faktoren der User Experience Systematische Übersicht über produktrelevante UX-Qualitätsaspekte Dominique Winter, Martin Schrepp, Jörg Thomaschewski

Dominique Winter

Buhl Data Service GmbH Am Siebertsweiher 3/5 57290 Neunkirchen [email protected]

Martin Schrepp

SAP SE Dietmar-Hopp-Allee 16 69190, Walldorf [email protected]

Jörg Thomaschewski

Hochschule Emden/Leer Constantiaplatz 4 26723 Emden [email protected]

Abstract User Experience ist eine Aggregation vieler unterschiedlicher Faktoren bzw. Qualitätsaspekte. Je nach Produkt sind andere Faktoren wichtig, um ein positives Nutzungserlebnis zu erzeugen. Für den Praktiker ist ein klares Bild der vorhandenen Faktoren wichtig, um für den Designprozess schon frühzeitig Schwerpunkte zu setzen (welche Faktoren sind für dieses Produkt wichtig). Auch helfen die Faktoren nach Fertigstellung des Produkts, die richtigen Fragebögen zur Evaluation der erreichten User Experience auszuwählen. Die für die Wahrnehmung der User Experience wichtigsten Qualitätsaspekte wurden durch Literaturanalyse, Expertenbefragungen und -diskussionen gesammelt und kritisch betrachtet. Dazu wurde eine erste Studie durchgeführt, um zu erfahren, welche Faktoren für welche Produkttypen besonders relevant sind. Es wird weiterhin für die verbreitetsten UX-Fragebögen eine Übersicht gegeben, welche der vorgestellten Faktoren durch den Fragebogen jeweils erfasst werden.

Keywords User Experience, Fragebögen, UX-Qualitätsaspekte, UX-Faktoren, UX-Evaluation

Einleitung Vergleicht man gängige Fragebögen zur User Experience, so stellt man fest, dass diese oft sehr unterschiedliche Faktoren bzw. Qualitätsaspekte der User Experience messen. Faktoren sind Einflussgrößen die das Gesamtkonstrukt User Experience entweder repräsentieren oder

34

Dominique Winter, Martin Schrepp, Jörg Thomaschewski

signifikant beeinflussen. In relevanten wissenschaftlichen Artikeln werden sehr unterschiedliche Faktoren untersucht, von denen man annimmt, dass sie die User Experience beeinflussen oder bestimmen. Allein die ISO 9241-210 nennt über 20 solcher Einflussfaktoren. Einige dieser Faktoren liegen im Nutzer (z.B. aktuelle Gemütslage), aber viele andere lassen sich erst durch die Interaktion mit dem Produkt fassen (z.B. Steuerbarkeit). Eine weitere Schwierigkeit liegt darin, dass manche Faktoren nur für bestimmte Produkte relevant sind bzw. die Wichtigkeit dieser Faktoren für die Wahrnehmung der User Experience zwischen verschiedenen Produktkategorien stark variiert. Für eine Anwendung zur Erfassung der Steuererklärung spielt das wahrgenommene Vertrauen in Datensicherheit und Vertraulichkeit eine andere Rolle als bei einem Web-Radio. Für einen Self-Service im Internet, z.B. das Rückmelden von Zählerständen an einen Versorger, ist intuitive Bedienung von zentraler Bedeutung. Für eine von Experten häufig genutzte betriebswirtschaftliche Anwendung spielt dieser Faktor eher eine untergeordnete Rolle. Hier sind andere Faktoren (z.B. Leichtigkeit) deutlich wichtiger. Wir geben in diesem Beitrag einen Überblick der wichtigsten, für die User Experience relevanten Faktoren, die durch Literaturanalyse, Expertenbefragungen und -diskussionen gesammelt und kritisch betrachtet wurden. Zusätzlich werden wir anhand der Daten einer ersten Studie diskutieren, welche Qualitätsaspekte für welche Produkttypen besonders relevant sind. Die Faktoren wurden in einer Umfrage zur Beurteilung von weitverbreiteten Produkten wie MS Word oder WhatsApp getestet. Dazu mussten die Teilnehmer beantworten, wie sehr der jeweilige Faktor ihrer Meinung nach auf dieses Produkt zutrifft und wie wichtig dieser Faktor bei solchen Produkten ist. Für den Praktiker ist ein klares Bild der vorhandenen UX-relevanten Faktoren einerseits wichtig, um für den Designprozess schon frühzeitig Schwerpunkte zu setzen (welche Qualitätsaspekte sind für dieses Produkt wichtig). Andererseits helfen sie auch nach Fertigstellung des Produkts die richtigen Fragebögen und Fragestellungen zur Evaluation der User Experience auszuwählen.

Faktoren der User Experience Wir geben im Folgenden eine Übersicht der aus unserer Sicht wichtigsten UX-Faktoren, die durch Literaturanalyse, Expertenbefragungen und -diskussionen zusammengetragen wurden. Einige Faktoren werden in der Literatur unter einer alternativen Bezeichnung genannt. In diesem Fall stehen die alternativen Bezeichnungen in Klammern hinter dem in diesem Beitrag verwendeten Namen bzw. wir geben diesen bei den Quellen explizit mit an. Fast alle Faktoren tauchen in einer Vielzahl von Quellen und Publikationen auf. Das Auflisten aller Quellen zu den verschiedenen Faktoren würde den Rahmen dieses Beitrags sprengen, deshalb wurden nur die unserer Ansicht nach relevantesten Quellen angegeben. Ist keine Quelle angegeben, stammt der Faktor aus Expertenbefragungen und -diskussionen, an der neben den drei Autoren zwei weitere Personen mit umfangreichen Erfahrungen in der

Faktoren der User Experience

35

Produktentwicklung teilgenommen haben. Bei diesen Expertenbefragungen und diskussionen wurden zuerst mögliche Faktoren gesammelt und anschließend anhand verschiedener Produktszenarien potentielle Faktoren ermittelt. Hierbei wurden einige neue Faktoren erhalten, die sich noch nicht in vorhandenen Fragebögen finden. Falls es einen Fragebogen gibt, der eine entsprechende Skala enthält, wird dieser angegeben. Skalen bestehen aus mehreren inhaltlich zusammenhängenden Fragen, die gemeinsam ausgewertet werden, um ein Messergebnis zu ermitteln. Auch hier konnten natürlich nicht alle vorhandenen Fragebögen berücksichtigt werden. Wir haben uns auf die folgenden relativ häufig verwendeten Fragebögen beschränkt: IsoMetrics (Gediga & Hamborg 1999), ISONORM (Prümper 1997), SUMI (Kirakowski 1996), UEQ (Laugwitz et al. 2008), AttrakDiff (Hassenzahl et al. 2003), meCUE (Minge & Riedel 2013), VISAVIS (Thielsch & Moshagen 2011) und SUPRQ (Sauro, 2015). Fragebögen, die nur eine globale UX-Dimension messen, d.h. keine klar abgegrenzten Faktoren aufweisen, z.B. der SUS (Brooke 1986) wurden nicht berücksichtigt. Aktualität (Inhaltsqualität, Content-Qualität): Die Informationen, die das Produkt dem Nutzer liefert, sind stets auf dem aktuellen Stand und von guter Qualität. Bei Webseiten ist die Aktualität gegeben, wenn die Informationen in der Seite dem aktuellen Wissens- bzw. Datenstand entsprechen. In einer betriebswirtschaftlichen Finanzanwendung, wenn diese die aktuellen gesetzlichen Regelungen implementiert. Quelle: Bargas-Avila et al. (2009), Laugwitz et al. (2009). Der Intranet Satisfaction Questionnaire (Bargas-Avila et al 2009) enthält eine Skale zum Messung der Qualität der Information auf Intranet-Seiten. Eine zusätzliche Skala zum UEQ Fragebogen bei dessen Anwendung innerhalb der DATEV AG erfragt, ob eine betriebswirtschaftliche Anwendung die aktuellen gesetzlichen Regelungen implementiert. Im SUPRQ ist eine Skala Credibility enthalten, die Aspekte von Aktualität und Vertrauen in einer Skala vereinigt. Anpassbarkeit (Individualisierbarkeit, Personalisierbarkeit): Der Nutzer kann das Produkt an seine persönlichen Bedürfnisse und Anforderungen bzw. seinen Arbeitsstil anpassen. In einem professionell genutzten Produkt kann dies zum Beispiel durch das Ausblenden nicht genutzter Felder oder Funktionen erfolgen. In einem sozialen Netzwerk durch die Möglichkeit Einstellungen dafür vorzunehmen, für wen welche Informationen sichtbar gemacht werden. Quelle: ISO 9241 (Teil 110 – Individualisierbarkeit). Skala im ISONORM und IsoMetrics Fragebogen. Bequemlichkeit: Das Produkt erleichtert das Leben. Dies wird als ein von der Nützlichkeit abgegrenzter Faktor angesehen, da ein zusätzlicher Nutzen auch Möglichkeiten bietet, die sonst nicht vorhanden sind, d.h. nicht unbedingt in einer Erleichterung des Lebens münden muss. Durchschaubarkeit (Erlernbarkeit, Lernförderlichkeit): Ist es einfach, die Bedienung des Produkts zu verstehen und zu erlernen? Quelle: ISO 9241 (Teil 110 – dort als Lernförderlichkeit bezeichnet). Als Skala im UEQ, SUMI, SUS, ISONORM und IsoMetrics vorhanden.

36

Dominique Winter, Martin Schrepp, Jörg Thomaschewski

Effizienz: Der Nutzer kann seine Ziele mit minimalem zeitlichem und physischem Aufwand erreichen. Das Produkt reagiert schnell auf Nutzereingaben. Das Design der Nutzerschnittstelle macht keine unnötigen Arbeitsschritte erforderlich. Quelle: ISO 9241 (Teil 11) bzw. (Teil 110 – Aufgabenangemessenheit). Zur Messung existieren eigene Skalen im UEQ und SUMI. In den Fragebögen ISONORM und IsoMetrics deckt die Skala Aufgabenangemessenheit diesen Faktor mit ab. Identität: Ich kann mich mit dem Produkt identifizieren und nehme Eigenschaften des Produkts in mich auf. Quelle: Hassenzahl et al. (2003), Faktor Identität des AttrakDiff Fragebogens, Skala Status im meCUE. Immersion: Wenn der Nutzer sich mit dem Produkt beschäftigt, vergisst dieser die Zeit. Der Nutzer kann völlig in der Beschäftigung mit dem Produkt versinken. Dieses Qualitätskriterium ist insbesondere bei Spielen und anderen zur Unterhaltung dienenden Produkten relevant. Intuitive Bedienung: Kann der Nutzer die Benutzerschnittstelle mit seinen vorhandenen Fähigkeiten unmittelbar und ohne jegliche Einarbeitung oder Anleitung durch andere bedienen? Quelle: Mohs et al. (2006). Leichtigkeit: Es ist für den Nutzer einfach seine Aufgaben mit dem Produkt zu erledigen. Die Interaktion mit dem Produkt ist weder körperlich noch mental anstrengend. Quelle: Hart & Staveland (1988) NASA-TLX (Task Load Index). Neuartigkeit: Das Produkt ist neu und innovativ. So etwas gab es bisher nicht. Nützlichkeit: Die Benutzung des Produkts bringt Vorteile. Dies ist zum Beispiel der Fall, wenn das Produkt die Produktivität oder Effizienz bei betriebswirtschaftlichen Prozessen erhöht. Aber auch, wenn ein Self-Service im Web, dem Nutzer einen lästigen Behördengang erspart. Quelle: Davies (1989), Technology Acceptance Model, dort werden auch sechs Fragen zu Messung dieses Faktors angegeben. Auch der meCUE enthält eine Skala Nützlichkeit, die diesen Aspekt mit drei Fragen erfasst. Originalität: Das Produkt ist interessant und ungewöhnlich gestaltet. Es erregt durch seine originelle Gestaltung das Interesse des Nutzers. Quelle: Laugwitz et al. (2008). Als Skala im UEQ vorhanden. Schönheit (Ästhetik): Das Produkt ist schön und ansprechend gestaltet. Das Produkt macht auf den Nutzer einen ästhetischen Eindruck. Quellen: Moshagen & Thielsch (2010) VisAWI Fragebogen, dieser liefert vier Unterfaktoren (Einfachheit, Vielseitigkeit, Farbigkeit, Kunstfertigkeit) zu diesem Konstrukt; Fragebogen von Lavie & Tractinsky (2004), der die zwei Unterfaktoren klassische und expressive Ästhetik nennt. Auch der meCUE und der SUPRQ (Skala Appearance) enthalten entsprechende Skalen. Soziales: Die Beschäftigung mit dem Produkt hilft mir Kontakte zu knüpfen und mich selbst positiv darzustellen. Spaß: Die Interaktion mit dem Produkt macht dem Nutzer Freude. Trotz der Nähe zur Stimulation ist Spaß ein eigener Faktor, da bei der Stimulation die Motivation des Nutzers im

Faktoren der User Experience

37

Vordergrund steht, dass Produkt immer wieder zu nutzen, was aber nicht zwingend daraus entstehen muss, dass die Nutzung des Produkts Spaß macht. Die Motivation kann auch aus durchaus anderen Faktoren resultieren, z.B. Möglichkeiten zur persönlichen Entwicklung oder andere Anreize. Quelle: Hatscher (2001). Steuerbarkeit (Kontrollierbarkeit, Fehlertoleranz, Robustheit): Das Produkt reagiert immer vorhersehbar und konsistent auf Nutzerinteraktionen. Der Nutzer hat stets die volle Kontrolle über das Produkt. Das Produkt ist fehlertolerant. Quelle: ISO 9241 (Teil 110), dort wird dieser Aspekt in die beiden Teilaspekte Steuerbarkeit und Fehlertoleranz aufgespalten, die als unabhängige Teilaspekte behandelt werden. Als Skala im SUMI, UEQ, ISONORM und IsoMetrics vorhanden. Stimulation: Die Arbeit mit dem Produkt motiviert den Nutzer immer wieder mit ihm zu arbeiten. Es ist anregend und spannend mit dem Produkt zu arbeiten. Quelle: Laugwitz et al. (2008). Skala des AttrakDiff und UEQ-Fragebogens. Übersichtlichkeit (visuelle Komplexität): Die Benutzerschnittstelle wirkt aufgeräumt und übersichtlich und hat eine geringe visuelle Komplexität. Der Nutzer findet sich schnell darin zurecht. Quelle: Müller & Schrepp (2013), dort wird auch eine einzelne Frage zur Messung beschrieben. Verbundenheit (Loyalität, Bindung): Auch wenn es andere, bessere Produkte für die gleichen Aufgaben gibt, wird der Nutzer nicht wechseln. Nutzer fühlen sich durch die bisherigen positiven Erfahrungen mit dem Produkt, der Marke oder dem Anbieter verbunden. Kann durch die Skala Produktloyalität des meCUE Fragebogens erfasst werden (es gibt dort auch eine Skala Bindung mit ähnlichem Inhalt). Der SUPRQ enthält eine eigene Skala Loyalty mit zwei Fragen zur Messung dieses Aspekts. Vertrauen: Die Daten und Informationen, die der Nutzer bei der Interaktion mit dem Produkt eingibt, sind in sicheren Händen. Dies spielt natürlich vor allem bei Produkten eine Rolle, bei denen der Nutzer kritische Daten preisgibt, z.B. beim Einkaufen in Web-Shops oder Online-Banking. Quelle: Corritore et al. (2001). Vollständigkeit: Das Produkt bietet dem Nutzer alles, was er oder sie erwartet. Es fühlt sich vollständig an, auch wenn es nicht tatsächlich alles im konkreten Nutzungskontext Notwendige bieten sollte. Der Faktor Vollständigkeit bezieht sich somit mehr auf die wahrgenommene Vollständigkeit und weniger auf die Summe der aufgabenangemessenen Nutzungskontexte. Wertigkeit (Professionelle Gestaltung, Kunstfertigkeit): Das Produkt macht einen hochwertigen und soliden Eindruck. Die Gestaltung des Produkts wirkt professionell. Quellen: Moshagen & Thielsch (2010) - VisAWI Fragebogen, dieser liefert mit dem Unterfaktor Kunstfertigkeit einen Teilaspekt zur Wertigkeit.

38

Dominique Winter, Martin Schrepp, Jörg Thomaschewski

Faktorenrelevanz für unterschiedliche Produkte Nicht jeder der genannten Qualitätsaspekte ist in allen Situationen relevant. Es hängt einerseits vom befragten Nutzer ab, wie wichtig ihm ein solcher Aspekt ist. Andererseits wird dies auch zwischen Produkten stark variieren, d.h. derselbe Nutzer wird einen dieser Aspekte bei einem Produkt wichtig finden und bei einem anderen nicht. Für einige der Qualitätsaspekte ist naheliegend, dass sie nur bei bestimmten Produkten überhaupt sinnvoll sind. Bei Identität geht es z.B. darum, dass der Nutzer über den Besitz (z.B. ein Smartphone eines bestimmten Typs) oder die Benutzung eines Produkts etwas über sich kommuniziert und dadurch Kontakte knüpft oder sein Ansehen mehrt. Dies setzt in gewisser Weise voraus, dass der Nutzer über die Nutzung bzw. Nicht-Nutzung dieses Produkts selbst entscheidet oder entscheidend beitragen kann. Bei einer Business Software, die beruflich genutzt und von der Firma beschafft wird (d.h. der Nutzer hat hier in der Regel keine Entscheidung zu treffen), spielt dieser Aspekt eine untergeordnete Rolle. In einer exemplarischen Studie wurden 56 Probanden in einer Onlineumfrage nach ihren Einschätzungen zu den vorgenannten, einzelnen Faktoren für Produkte aus den drei Produktkategorien Textverarbeitung, Kommunikation und Webbrowser befragt. Ziel der Umfrage war es zu erkennen, welche dieser Faktoren für die drei beispielhaften Produktkategorien von den Nutzern als wichtig eingestuft wurden und welche nicht. Die Faktoren wurden in einer 7-stufigen Zustimmungsskala abgefragt, wobei für jeden Faktor die Aussage, dass dieser Faktor wichtig sei zu bewerten war (z.B. „Steuerbarkeit ist mir bei Produkten wie Firefox wichtig.“). Erkenntnisse aus einer solchen Umfrage könnten genutzt werden um die Faktorenrelevanz für eine Produktkategorie zu bestimmen. Wie auszugsweise in Abbildung 1 zu erkennen, können Aussagen aus einer solchen Befragung hergeleitet werden: ¥ Intuitive Bedienung, Nützlichkeit und Leichtigkeit sind über alle drei Produktkategorien von sehr hoher Wichtigkeit. ¥ Soziales ist für Textverarbeitungen Kommunikationsanwendungen.

nicht

so

wichtig

wie

für

¥ Aktualität und Anpassbarkeit ist bei Browsern wichtiger als bei Textverarbeitungen und Kommunikationsprogrammen. Auf Grundlage solcher Umfrageergebnisse könnte nun eine Auswahl von Fragebögen erfolgen, die vor allem die wichtigen Faktoren abfragt und unwichtige ausspart. Dadurch ist es möglich die Belastung der Probanden durch Vermeiden unnötiger Fragen gering zu halten und deren Beteiligung bzw. Bereitschaft zur Unterstützung zu erhöhen.

Faktoren der User Experience

39

Abbildung 1: Faktorengewichtung durch Nutzerbewertung

Zusammenfassung und Ausblick Wir haben eine Übersicht über relevante UX-Qualitätsaspekte gegeben, die auf das Gesamtkonstrukt UX einzahlen. Die Liste der angeführten Aspekte ist natürlich nicht vollständig. Einerseits gibt es immer neue Nutzungsszenarien, bei denen dann auch neue Aspekte zur Beurteilung der UX zum Tragen kommen können. Vor Einführung von WebShops oder Online-Banking musste man sich zum Beispiel über ein Kriterium wie Vertrauen weniger Gedanken machen. Dieses Kriterium tauchte erst mit der Verbreitung dieser neuen Möglichkeiten sehr prominent in der UX-Literatur auf. Andererseits gibt es sehr unterschiedlicher Produkte. Daher können für spezielle Anwendungen weitere Kriterien relevant sein, die in dieser Liste nicht genannt worden sind, aber stark auf die UX einwirken. Die in diesem Artikel dargestellte Liste aller relevanten UX-Faktoren wird sich entsprechend den zukünftigen Anwendungen und Nutzerbedürfnissen weiterentwickeln. Der Vergleich der Qualitätsaspekte mit den wichtigsten UX-Fragebögen zeigt, dass keiner dieser Fragebögen in der Lage ist alle Aspekte abzudecken. Das ist wegen der Abhängigkeit der Art des Produkts und der damit verbundenen Zielgruppen natürlich auch nicht sinnvoll. Allerdings bedeutet dies auch, dass man ggfs. mehrere Fragebögen verwenden muss, um alle Aspekte abzudecken, die man für ein zu evaluierendes Produkt für wichtig erachtet. Da die verschiedenen Fragebögen in Bezug auf Messung und Darstellung der Resultate nicht einheitlich sind, ist das für die Datenerhebung nicht förderlich, da die befragten Nutzer innerhalb einer Befragung mit sehr verschiedenen Frageformaten konfrontiert werden.

40

Dominique Winter, Martin Schrepp, Jörg Thomaschewski

Naheliegend wäre es, auf Basis dieser Faktoren einen flexiblen und erweiterbaren Fragenkatalog zu entwickeln. Der UX-Professional könnte dann für jede Evaluation eines Produkts zuerst entscheiden, welche Qualitätsaspekte relevant sind und diese dann durch eine direkt in einen passgenauen Fragebogen überführen. Damit würden nur genau die als relevant angesehenen Aspekte erfragt. Wegen der inhärenten Unvollständigkeit solcher Kataloge, sollte das Fragenformat so gewählt sein, dass weitere Qualitätsaspekte leicht ergänzt werden können. Man verliert bei einer solchen flexiblen Vorgehensweise jedoch Vorteile standardisierter Messinstrumente. Etablierte Fragebögen bieten oft einen Benchmark an, mit dem man sein Evaluationsergebnis mit dem einer großen Menge von bereits evaluierten Produkten vergleichen kann. Das Erstellen eines solchen Benchmarks wird bei passgenau zugeschnittenen Fragebögen schwieriger, da pro Skala eine geringere Menge an Evaluationen anfällt, aus denen man einen sinnvollen Benchmark berechnen kann. Literatur Bargas-Avila, J. A., Lötscher, J., Orsini, S. & Opwis, K. (2009). Intranet satisfaction questionnaire: Development and validation of a questionnaire to measure user satisfaction with the intranet. Computers in Human Behavior, 25, 1241 1250. Brooke, J. (1986). SUS: a quick and dirty usability scale. In Jordan, P.W., Thomas, B., Weerdmeester, B.A. & McClelland, A.L. (Hrsg.): Usability Evaluation in Industry. London: Taylor and Francis. Corritore, C.L., Wiedenbeck, S. & Kracher, B. (2001). The elements of online trust. In CHI '01 Extended Abstracts on Human Factors in Computing Systems (CHI EA '01). ACM, New York, NY, USA, 504-505. DOI=10.1145/634067.634355 http://doi.acm.org/10.1145/634067.634355 Davis, D. (1989). Perceived usefulness, perceived ease of use, and user acceptance of information technology. MIS Quarterly, 13(3), 319 339. Deng, L. & Poole, M. S. (2012). Aesthetic design of e-commerce web pages – Webpage Complexity, Order and preference. Electronic Commerce Research and Applications, 11(4), 420-440. DIN EN ISO 9241-110 (2006). Ergonomics of human-system interaction – Part 110: Dialogue principles. Beuth, Berlin. Gediga, G. & Hamborg, K.C. (1999). IsoMetrics: Ein Verfahren zur Evaluation von Software nach ISO 9241/10. In Holling, H. & Gediga, G. (Hrsg.): Evaluationsforschung, S. 195-234. Göttingen: Hogrefe. Hart, S. & Staveland, L. (1988). Development of NASA-TLX (Task Load Index): Results of empirical and theoretical research. In Hancock, P. & Meshkati, N. (Hrsg.): Human mental workload (pp. 139-183). Amsterdam: North Holland. Hassenzahl, M., Burmester, M. & Koller, F. (2003). AttrakDiff: Ein Fragebogen zur Messung wahrgenommener hedonischer und pragmatischer Qualität. In Ziegler, J. & Szwillus, G. (Hrsg.): Mensch & Computer 2003. Interaktion in Bewegung. Stuttgart: Teubner. S. 187-196. Hatscher, M. (2001). Joy of use - Determinanten der Freude bei der Software-Nutzung. In: Oberquelle, H., Oppermann, R. & Krause, J. (Hrsg.), Mensch & Computer 2001: 1. Fachübergreifende Konferenz. Stuttgart: B. G. Teubner. S. 445-446.

Faktoren der User Experience

41

Kirakowski, J. (1996). The Software Usability Measurement Inventory: Background and usage. In Jordan, P., Thomas B. & Weerdmeester B. (Hrsg.), Usability Evaluation in Industry (S. 169- 178). London, UK: Taylor & Francis. Lavie, T. & Tractinsky, N. (2004). Assessing dimensions of perceived visual aesthetics of web sites. International Journal of Human-Computer-Studies, 60, S. 269-298. Laugwitz, B., Held, T. & Schrepp, M. (2008). Construction and Evaluation of a User Experience Questionnaire. In Holzinger, A. (Hrsg.): HCI and Usability for Education and Work, LNCS 5298, Berlin, Heidelberg: Springer, S. 63–76. Laugwitz, B., Schubert, U., Ilmberger, W., Tamm, N., Held, T. & Schrepp, M. (2009). Subjektive Benutzerzufriedenheit quantitativ erfassen: Erfahrungen mit dem User Experience Questionnaire UEQ. In: Brau, H., Diefenbach, S., Hassenzahl, M., Kohler, F., Peissner, M., Petrovic, K., Thielsch, M., Ulrich, D. & Zimmermann, D. (Hrsg.); Usability Professionals 2009, S. 220 – 225, Fraunhofer Verlag. Minge, M. & Riedel, L. (2013). meCUE – Ein modularer Fragebogen zur Erfassung des Nutzungserlebens. In Boll S., Maaß, S. & Malaka, R. (Hrsg.): Mensch und Computer 2013: Interaktive Vielfalt (S. 89-98). München: Oldenbourg Verlag. Mohs, C., Hurtienne, J., Israel, J. H., Naumann, A., Kindsmüller, M. C., Meyer, H.A. & Pohlmeyer, A. (2006). IUUI – Intuitive Use of User Interfaces. In Bosenick, T., Hassenzahl, M., Müller-Prove, M. & Peissner, M. (Hrsg.), Usability Professionals 06 (S. 130-133). Stuttgart: German Chapter der Usability Professionals' Association. Moshagen, M. & Thielsch, M. T. (2010). Facets of visual aesthetics. International Journal of HumanComputer Studies, 68, S. 689-709. Müller, K. & Schrepp, M. (2013). Visuelle Komplexität, Ästhetik und Usability von Benutzerschnittstellen. In Boll, S.; Maaß, S. & Malaka, R. (Hrsg.), Mensch & Computer 2013 – Interaktive Vielfalt, S 211 – 220, München: Oldenbourg Verlag 2013. Prümper, J. (1997). Der Benutzungsfragebogen ISONORM 9241/10: Ergebnisse zur Reliabilität und Validität. In Liskowski, R., Velichkovsky B.M. & Wünschmann, W. (Hrsg.), Software-Ergonomie ‘97 - Usability Engineering: Integration von Mensch-Computer-Interaktion und SoftwareEntwicklung (pp. 253-262). Stuttgart: Teubner. Sauro, J. (2015). SUPR-Q: A Comprehensive Measure of the Quality of the Website User Experience. In: Journal of Usability Studies 10 (2), S. 68–86. Thielsch, M. T. & Moshagen, M. (2011). Erfassung visueller Ästhetik mit dem VisAWI. In Brau, H., Lehmann, A., Petrovic, K. & Schroeder, M.C. (Hrsg.), Usability Professionals 2011, S. 260-265. Stuttgart: German UPA e.V.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 42- 50.

Data Canvas und Data-Need Fit Daten für neue Geschäftsmodelle nutzen Katrin Mathis, Felix Köbler

Katrin Mathis

Digitale Konzepte mit mehr Wert. Gerberau 2 79098 Freiburg [email protected]

Dr. Felix Köbler

FELD M GmbH Sandstrasse 33 80335 München [email protected]

Abstract Daten gelten als das Öl des 21. Jahrhunderts. Doch nur 4% der Unternehmen nutzten laut BITKOM 2012 Analysen großer Datenmengen als Grundlage neuer Geschäftsmodelle. Um ausgehend von Daten Geschäftsmodelle zu entwickeln, ist zunächst ein Verständnis über die verfügbaren Daten nötig. Zu diesem Zweck wurde zum einen der Business Model Canvas als Vorgehensmodell zur Entwicklung von Geschäftsmodellen durch den Data-Need Fit konzeptionell erweitert und zum anderen ein Werkzeug entwickelt (Data Canvas), um Daten systematisch für die Entwicklung von Geschäftsmodellen heranzuziehen. Der Data Canvas ermöglicht eine zielgerichtete Nutzerforschung insbesondere im Hinblick auf die Nutzererfahrung (User Experience) eines Produkts oder einer Dienstleistung. Die Nutzerforschung dient als Grundlage für den Data-Need Fit, also der Identifikation von relevanten Aufgaben der Nutzer, die sich mit den für ein Unternehmen verfügbaren Daten unterstützen lassen.

Keywords Big Data, Business Model Canvas, Business Model Engineering, Data Canvas, Data-Need Fit, Geschäftsmodellentwicklung in der digitalen Ökonomie

Einleitung Unter dem Schlagwort Big Data werden Entwicklungen zusammengefasst, dass Daten schneller wachsen als Technologien, um diese zu verarbeiten. Doch trotz der wachsenden Menge an vorhandenen Daten nutzt bisher nur ein Bruchteil der Unternehmen diese für die Entwicklung neuer, innovativer und nachhaltiger Geschäftsmodelle (BITKOM 2012). Zur Dokumentation und Entwicklung von Geschäftsmodellen wurden in den letzten Jahren verschiedene Vorgehensmodelle erarbeitet. Insbesondere konnte sich der Business Model

Data Canvas und Data-Need Fit

43

Canvas von Osterwalder und Pigneur (2010) in der Praxis etablieren. Der Business Model Canvas dient als Vorgehensmodell und Rahmenwerk, um Geschäftsmodelle systematisch zu entwickeln und visualisiert zu dokumentieren. In der Praxis und Literatur finden sich jedoch kaum Vorgehensmodelle, die zur systematischen Konzeption und Entwicklung von Geschäftsmodellen ausgehend von Daten herangezogen werden können. Zudem zielen bestehende Vorgehensmodelle darauf ab, eine initiale Vision eines Geschäftsmodells am Markt zu validieren und umzusetzen. Jedoch stellt sich für Unternehmen die Frage, wie zunächst Visionen für innovative und nachhaltige Geschäftsmodelle systematisch konzipiert werden können. Methoden, die hierzu, bspw. aus dem Service Design, herangezogen werden können, sind stark nutzerzentriert. Diese gehen folglich von Bedürfnissen der Nutzer aus. Doch solange weder Zielgruppe noch Wertversprechen (Value Proposition) definiert sind, stehen Unternehmen vor dem Dilemma, wie eine zielgerichtete Nutzerforschung hinsichtlich des Produktoder Dienstleistungsangebots initiiert und durchgeführt werden kann.

Abbildung 1: Verankerung von Data-Need Fit und Data Canvas innerhalb des etablierten Vorgehensmodells nach Osterwalder et al. (2014)

Der Beitrag beschreibt zum einen den Data-Need Fit als konzeptionelle Voraussetzung für das etablierte Vorgehensmodell nach Osterwalder et al. (2014), und zum anderen den Data Canvas als neues Werkzeug, um Daten systematisch für die Entwicklung von Geschäftsmodellen heranzuziehen. Der Data Canvas kann zusammen mit dem Business Model Canvas und dem Value Proposition Canvas verwendet werden und ergänzt damit bestehende Werkzeuge aus dem User Experience und Service Design, die für die Entwicklung von Geschäftsmodellen durch das Vorgehensmodell nach Osterwalder et al. (2014) orchestriert werden (Abbildung 1). Nach dem Ansatz der Effectuation als Entscheidungslogik werden zunächst verfügbare Mittel betrachtet (Sarasvathy 2001; Bettencourt, Lusch & Vargo 2014). Insbesondere sind dies Partnerschaften und Daten, auf die ein Unternehmen zurückgreifen kann. Zur

44

Katrin Mathis, Felix Köbler

systematischen Erarbeitung und Dokumentation von Partnern und deren Relationen können etablierte Werkzeuge, wie bspw. die Stakeholder Map, herangezogen werden. Mit dem Data Canvas wird ein neues Werkzeug vorgestellt, um verfügbare Daten systematisch zu erfassen und strukturiert zu dokumentieren und somit ein Verständnis über das Potential verfügbarer Daten für alle Akteure eines Wertschöpfungs- und Erbringungsnetzwerks zu schaffen. Eine ausgearbeitete Stakeholder Map und der Data Canvas können herangezogen werden, um eine zielgerichtete Nutzerforschung durchzuführen. Ziel dieser primär qualitativen Nutzerforschung ist es, relevante Aufgaben von Nutzern zu identifizieren, die mit verfügbaren Daten unterstützt werden können. Ein Data-Need Fit tritt ein, wenn eine oder mehrere verfügbare Datenquellen identifiziert wurden, die relevante Aufgaben von Kunden unterstützen, Probleme lösen oder Nutzen schaffen können. Ein Data-Need Fit ist eine wichtige Voraussetzung, um das Wertversprechen (Value Proposition) zu entwickeln, welches den Kern eines Geschäftsmodells bildet und zudem bestimmt, wie Daten den Nutzern in Form eines Produkts oder einer Dienstleistung bereitgestellt werden.

Übersicht aller Beteiligten in einer Stakeholder Map Um ein Verständnis über die Akteure und deren Relationen in einem Wertschöpfungs- oder Erbringungsnetzwerk zu gewinnen, kann bspw. auf die aus dem Service Design stammende Stakeholder Map als methodisches Werkzeug zurückgegriffen werden. Methodische Alternativen, die in diesem Schritt angewendet werden können, finden sich zudem in der e3value-Methode (Gordijn & Akkermans 2001) sowie Entity-Relationship-Modellen (Chen 1976). In einer Stakeholder Map werden einzelne Akteure anhand ihrer Relevanz für die Bereitstellung eines Produkts oder Erbringung einer Dienstleistung innerhalb konzentrischer Kreise positioniert. Die Relevanz eines Akteurs nimmt dabei mit der Entfernung zum Mittelpunkt ab. Im inneren Kreis werden somit Partner verzeichnet, deren Existenz eine notwendige Bedingung bspw. für die Anbahnung und Erbringung einer Dienstleistung darstellt. Weiterführend kann innerhalb der Stakeholder Map vermerkt werden, welche Relationen zwischen den verschiedenen Akteuren bestehen und welche Arten von Strömen (in diesem Fall insbesondere Daten) existieren (Stickdorn & Schneider 2010). Eine Stakeholder Map ermöglicht allen Partnern und Akteuren, die kontextuellen Anhängigkeiten innerhalb eines Wertschöpfungs- und Erbringungsnetzwerkes über die eigene Organisation hinaus zu verstehen.

Übersicht verfügbarer Daten in einem Data Canvas Für das Verständnis von Daten hingegen findet sich in der Literatur und Praxis kein etabliertes Werkzeug. Meist stecken Unternehmen und Konzerne in einem Dilemma: Die Mitarbeiter und Abteilungen eines Unternehmens, die einen Überblick über verfügbare Daten haben, sind meist nicht in die Entwicklung neuer Geschäftsmodelle involviert.

Data Canvas und Data-Need Fit Umgekehrt haben diejenigen, die mit der Konzeption und Entwicklung Geschäftsmodellen betraut sind, nur selten ein Verständnis über verfügbare Daten.

45 von

Im Rahmen des Forschungsprojekts ExCELL wurde mit dem Data Canvas ein Werkzeug entwickelt, welches strukturiert ein Verständnis über das Potential verfügbarer Daten für alle Akteure eines Wertschöpfungs- und Erbringungsnetzwerks schafft. Durch den Data Canvas (Abbildung 2) werden Daten nach zwei Dimensionen strukturiert: (i) der Herkunft sowie (ii) der Aktualisierungsfrequenz der Daten. Interne Daten sind Eigentum des Unternehmens oder der Geschäftsfelder eines Konzerns. Externe Daten werden hingegen von Partnern oder externen Bezugsquellen bereitgestellt. Turnusmäßige Daten sind je nach Kontext Daten, die in bestimmten zeitlichen Abständen – beispielsweise jährlich – aktualisiert werden. Kontinuierliche Daten stehen hingegen mindestens täglich oder in Echtzeit zur Verfügung, da diese bspw. bei der Nutzung eines Produkts oder einer Dienstleistung generiert werden.    

Abbildung 2: Dimensionen des Data Canvas

Zunächst entscheidend für die Entwicklung innovativer und nachhaltiger Geschäftsmodelle sind der dauerhafte Zugriff auf die Daten und deren Potential zur regelmäßigen Monetarisierung. Grundsätzlich kann internen kontinuierlichen Daten das größte Potential für die Entwicklung von Geschäftsmodellen zugesprochen werden, da Unternehmen volle Kontrolle über diese Daten haben und diese eine regelmäßige Monetarisierung ermöglichen. Bei externen Daten ist es hingegen möglich, dass diese nicht mehr bereitgestellt werden oder verfügbar sind (bspw. durch veränderte Nutzungsbedingungen von technischen Schnittstellen). Zudem haben Wettbewerber meist Zugriff auf die gleichen externen Daten und könnten folglich ein bestehendes Geschäftsmodell leicht kopieren oder optimieren. Das geringste Potential haben externe turnusmäßige Daten. Für sich alleine sind diese Daten aus den genannten Gründen mit Risiken behaftet.

46

Katrin Mathis, Felix Köbler

Um die Benutzung des Data Canvas für alle Beteiligten möglichst einfach zu gestalten, empfiehlt es sich, mit Haftnotizen zu arbeiten. Sofern Haftnotizen in unterschiedlichen Formen und Farben vorhanden sind, können diese weitere Attribute visualisieren. So können bspw. eckige Haftnotizen für strukturierte Datenquellen verwendet werden und runde Haftnotizen für unstrukturierte Datenquellen. Grüne Haftnotizen können für vertrauenswürdige Datenquellen stehen, wie bspw. Verwaltungsdaten. Haftnotizen in gelber oder roter Farbe können für weniger vertrauenswürdige Datenquellen verwendet werden, wie bspw. Daten aus sozialen Medien. Jede Haftnotiz steht für eine Datenquelle, die eindeutig benannt und deren thematischer und kontextueller Bezug notiert wird. Weitere relevante Charakteristika und Attribute der Datenquelle können je nach Kontext vermerkt werden, bspw. dass die Verwendung der zugrundeliegenden Datenquelle mit Kosten verbunden ist.

Abbildung 3: Beispielhafter Data Canvas

Anhand eines ausgefüllten Data Canvas (Abbildung 3) können Potentiale und Risiken der verfügbaren Daten bestimmt werden. Thematische und kontextuelle Schwerpunkte sowie Einschränkungen bei Verwendung und Nutzung der Daten sind hieraus ablesbar. Der Data Canvas ist keine statische Dokumentation, sondern sollte kontinuierlich an mögliche Veränderungen angepasst werden. Er kann Anhaltspunkte für weitere noch nicht identifizierte Datenquellen liefern, die entweder Lücken bestehender Daten ergänzen oder zusätzliche Potentiale realisieren. Auch verschiedene Variationen mit unterschiedlichen Attributen sind denkbar. Für Mitarbeiter, die für die Nutzererfahrung (User Experience) eines Produkt- oder Dienstleistungsangebots verantwortlich sind, steckt der Data Canvas den Rahmen für die sich anschließende Nutzerforschung ab.

Data Canvas und Data-Need Fit

47

Zielgerichtete Nutzerforschung Eine ausgearbeitete Stakeholder Map und definierter Data Canvas können herangezogen werden, um Zielgruppen einzugrenzen, die am wahrscheinlichsten von den verfügbaren Daten profitieren können. Nach dem Jobs-to-be-done Framework sind zu erledigende Aufgaben der Grund für Kunden, Produkte zu nutzen oder Dienstleistungen in Anspruch zu nehmen (Christensen, Anthony, Berstell & Nitterhouse 2007). Nur wenn Kunden ihre Aktivitäten zur Zielerreichung optimal ausführen können, demzufolge ihre Aufgaben erledigen können, entsteht für sie Wert. Nach diesem Verständnis sind Kunden Teil des Wertschöpfungs- und Erbringungsnetzwerkes von Unternehmen. Damit kann es entscheidend sein, Zielgruppen nach ihrer Fähigkeit und Bereitschaft zur Mitwirkung auszuwählen (bspw. Nutzungsdaten zur Verfügung zu stellen). Im Vergleich zu Zielgruppensegmentierungen auf Basis von bspw. Produktkategorien oder demografischen Faktoren ist eine Segmentierung auf Basis von Aufgaben über die Zeit stabiler, da Bedürfnisse und Wünsche sich mit der Zeit ändern, Aufgaben hingegen langfristig konstant bleiben. Vor allem Themen, zu denen besonders hochwertige Daten oder multiple Datenquellen vorhanden sind, sind ein guter Ausgangspunkt, um zielgerichtete Forschungsfragen zu formulieren. Ziel der Nutzerforschung ist es somit, relevante Aufgaben zu identifizieren, die mit verfügbaren Daten unterstützt werden können.

Data-Need Fit Im Rahmen der Geschäftsmodellinnovation werden drei Arten von sogenannten „Fits“ (Osterwalder et al. 2014) unterschieden: (i) (ii) (iii)

Ein Problem-Solution Fit tritt ein, wenn ein Wertversprechen zumindest in der Theorie relevante Aufgaben, Probleme und Nutzen von Kunden adressiert. Ein Product-Market Fit ist erreicht, wenn gezeigt werden konnte, dass Kunden tatsächlich kaufbereit sind. Ein Business Model Fit erfolgt schließlich, wenn das Wertversprechen in ein profitables und skalierbares Geschäftsmodell eingebettet ist.

Bei der Entwicklung von Geschäftsmodellen auf Basis von Daten sollte zusätzlich ein DataNeed Fit erfüllt sein. Dieser tritt ein, wenn eine oder mehrere verfügbare Datenquellen identifiziert wurden, die relevante Aufgaben von Kunden unterstützen, Probleme lösen oder Nutzen schaffen können.

48

Katrin Mathis, Felix Köbler

Abbildung 4: Beispielhafter Value Proposition Canvas

Der Value Proposition Canvas kann bspw. als Werkzeug herangezogen werden, um aus einem ausgearbeiteten Data Canvas und den Ergebnissen der durchgeführten Nutzerforschung einen Data-Need Fit zu identifizieren (Abbildung 4). Die Ergebnisse der Nutzerforschung werden dabei im rechten Teil des Value Proposition Canvas, dem sogenannten Kundenprofil, in Form von Aufgaben, Problemen und Nutzen dokumentiert. Anschließend wird der linke Teil des Value Proposition Canvas, die so genannte Value Map, erarbeitet. An der Stelle von Produkten oder Dienstleistungen nutzt man in diesem Schritt, die im Data Canvas identifizierten Datenquellen. Auf dieser Seite wird somit vermerkt, wie die Datenquellen einen Nutzen bieten oder zur Problemlösung beitragen können. Ein DataNeed Fit ist gefunden, wenn dieser Nutzen und die Lösung der Probleme von Nutzern als wertvoll eingestuft werden.

Von einem Data-Need Fit zu einem Geschäftsmodell Ein Data-Need Fit ist eine wichtige Voraussetzung, um ein Wertversprechen (Value Proposition) zu entwickeln. Das Wertversprechen bildet den Kern eines Geschäftsmodells und legt fest, wie Daten den Nutzern in Form eines Produkts oder einer Dienstleistung bereitgestellt werden. Die Erarbeitung einer zweiten Value Map des Value Proposition Canvas kann dazu verwendet werden, das zu entwickelnde Produkt- oder Dienstleistungsangebot zu beschreiben. Wenn dieses auf Basis der Erkenntnisse aus der Nutzerforschung relevante Probleme der Nutzer löst und Nutzen schafft, ist ein ProblemSolution Fit gefunden. Weitere Elemente des Business Model Canvas resultieren teils aus dem Produkt- oder Dienstleistungsangebot selbst oder können variabel gehalten werden. Da der Business Model Canvas zunächst nur auf Annahmen basiert, sollten diese möglichst frühzeitig mit Kunden und Nutzern überprüft werden, um das Risiko eines späten Scheiterns zu minimieren. Etablierte Vorgehensmodelle, wie der Lean Startup Ansatz bieten ein systematisches Vorgehen, um bspw. mittels eines sogenannten Minimum Viable Product (MVP) die kritischsten Annahmen zu überprüfen (Ries 2011).

Data Canvas und Data-Need Fit

49

Ergebnis Mit dem Data Canvas wurde ein Werkzeug entwickelt, welches einen strukturierten und sogleich flexiblen Ansatz darstellt, um relevante Datenquellen zu identifizieren und das Verständnis über verfügbare Daten zu verbessern. Dies ermöglicht, deren Potentiale und Risiken für die Entwicklung von innovativen und nachhaltigen Geschäftsmodellen besser einschätzen zu können. Der Data Canvas fördert eine zielgerichtete Nutzerforschung insbesondere im Hinblick auf die Nutzererfahrung (User Experience) eines Produkts oder einer Dienstleistung. Die Nutzerforschung dient als Grundlage für den Data-Need Fit, also der Identifikation von relevanten Aufgaben der Nutzer, die sich mit den für ein Unternehmen verfügbaren Daten unterstützen lassen. Der Data-Need Fit wurde als eine konzeptionelle Voraussetzung für das etablierte Vorgehensmodell nach Osterwalder et al. (2014) vorgestellt, um Daten systematisch für die Entwicklung von für die Nutzer relevanten Produkt- und Dienstleistungsangeboten mit nachhaltigen Geschäftsmodellen heranzuziehen. Danksagung Der Beitrag ist im Rahmen des Forschungsprojekts “ExCELL – Echtzeitanalyse und Crowdsourcing für eine selbstorganisierte City-Logistik” entstanden. ExCELL ist ein Forschungsprojekt bestehend aus Praxispartner (FELD M GmbH, MingLabs GmbH und Entiretec AG) sowie universitären Institutionen (Technische Universität München, Technische Universität Dresden und Beuth Hochschule Berlin). Wir danken dem Bundesministerium für Wirtschaft und Energie (BMWi) für die Finanzierung des Projekts im Rahmen des Technologieprogramms "Smart Data – Innovationen aus Daten" (Förderkennzeichen: 01MD15001A). Weiterführende Informationen erhalten Sie unter: http://excell-mobility.de Literatur Bettencourt, L., Lusch, R. & Vargo, S. (2014). A Service Lens on Value Creation: Marketing’s Role in Achieving Strategic Advantage. California Management Review, Vol. 57 (1), 44-66. BITKOM (2012). Big Data im Praxiseinsatz – Szenarien, Beispiele, Effekte. Leitfaden. http://www.bitkom.org/files/documents/BITKOM_LF_big_data_2012_online%281%29.pdf [30.10.2014]. Chen, P. (1976). The Entity-Relationship Model – Toward a Unified View of Data. ACM Transactions on Database Systems, Vol. 1 (1), 9-36. Christensen, C., Anthony, S., Berstell, G. & Nitterhouse, D. (2007). Finding the Right Job for Your Product. MIT Sloan Management Review, Vol. 48 (3), 38-47. Gordijn, J. & Akkermans, H. (2001). Designing and Evaluating E-business Models, IEEE Intelligent Systems, Vol. 16 (4) , 11-17. Osterwalder, A. & Pigneur, Y. (2010). Business Model Generation. A Handbook for Visionaries, Game Changers, and Challengers. Hoboken, United States: John Wiley & Sons.

50

Katrin Mathis, Felix Köbler

Osterwalder, A., Pigneur, Y., Bernarda, G. & Smith, A. (2014). Value Proposition Design: How to Create Products and Services Customers Want. Hoboken, United States: John Wiley & Sons. Ries, E. (2011). The Lean Startup. How Constant Innovation Creates Radically Successful Businesses. London, United Kingdom: Portfolio Penguin. Sarasvathy, S. (2001). Causation and Effectuation: Toward a Theoretical Shift from Economic Inevitability to Entrepreneurial Contingency. The Academy of Management Review, Vol. 26 (2), 243-264. Stickdorn, M. & Schneider, J. (2010). This is Service Design Thinking. Amsterdam, Netherlands: BIS Publishers. 2nd Edition.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 51- 60.

Prototyping hoch Drei – interaktiv, dynamisch und konsequent (in der Zusammenarbeit) Komplexe Industrie-Interfaces mit Prototypen nachhaltig entwickeln, optimieren und umsetzen Moritz Fröhner, Sebastian Ammermüller, Julian Mengel, Michael Kühnel

Moritz Fröhner

Sebastian Ammermüller

Julian Mengel

Michael Kühnel

Micromata GmbH Marie-Calm Str. 1-5 D-34131 Kassel [email protected] Micromata GmbH Marie-Calm Str. 1-5 D-34131 Kassel [email protected]

Micromata GmbH Marie-Calm Str. 1-5 D-34131 Kassel [email protected] Micromata GmbH Marie-Calm Str. 1-5 D-34131 Kassel [email protected]

Abstract Softwareentwicklungsprojekte im Bereich Industrie-Interfaces haben nicht selten Laufzeiten über mehrere Jahre – von der Konzeption der Informationsarchitektur über die Ausgestaltung des User Interface bis hin zur Realisierung. Parallel werden die Bedienoberflächen von Softwareprodukten immer komplexer und dynamischer in den Interaktionsstrukturen und Bedienmechanismen. Das klassische Entwurfsvorgehen und die damit verbundenen Methoden im User Experience Design stehen vor neuen Herausforderungen. Das Entwerfen über Skizzen und Wireframe-Screens ist je nach Ausrichtung des geplanten User Interface oftmals zu statisch und zu langsam, um die dynamischen Interaktionsstrukturen sichtbar und für den Nutzer oder Kunden (Auftraggeber) erfahrbar und bewertbar zu machen. Neue Ansätze und Technologien im Bereich des Prototyping bieten indes gute Möglichkeiten den Entwurfsprozess für alle Beteiligten zu optimieren und zu beschleunigen.

Keywords Industrie-Interfaces, Prototyping, Framework, UX-Designprozess, Interdisziplinär, Frontend.

52

Moritz Fröhner, Sebastian Ammermüller, Julian Mengel, Michael Kühnel

Ausgangssituation und Herausforderung Das Web hat sich in den letzten zehn Jahren stark verändert. Die Tools, mit denen Webseiten und Applikationen gestaltet werden, haben diesen Wandel sehr viel langsamer vollzogen. Für die Entwicklung von Webapplikationen hat sich HTML5 als Bindeglied zwischen UIDesignern und Frontend-Entwicklung etabliert und bietet z. B. durch die native Unterstützung von Animationen neue Möglichkeiten in der Gestaltung von BenutzerInterfaces. Dabei wird nicht mehr in einem statischen Grid und einer festen Breite gearbeitet, sondern mit flexiblen Designs auf einer Vielzahl von Endgeräten mit unterschiedlichen Auflösungen, wodurch die Möglichkeiten und damit die Komplexität von Webapplikationen stetig gestiegen sind. Diese Entwicklungen haben einen direkten Einfluss auf die Arbeit von Usability Professionals und stellen den klassischen Entwurfsprozess vor geänderte und neue Herausforderungen. Das herkömmliche Entwurfsvorgehen über statische Wireframes stößt in komplexen Industrieprojekten oft an seine Grenzen. Dynamische Navigationsstrukturen und die Funktionen von Off-Canvas-Menüs sowie gesten- oder touchbasierte Interaktionen können dem Kunden und zukünftigem Anwender über statische Wireframe-Screens nur bedingt verdeutlicht werden. Durch den Paradigmenwechsel zum Responsive Design wird das Entwerfen und Gestalten von Web-Applikationen mit herkömmlichen Entwurfs- und Designwerkzeugen zunehmend ineffizienter. Das Verhalten einer responsiven Bedienoberfläche auf unterschiedlichen Endgeräten in verschiedenen Anwendungskontexten kann dabei oft nur umständlich und mit großem Zeitaufwand veranschaulicht werden. Seit dem Aufkommen des Material-Design-Ansatzes werden Interfaces nicht nur responsiv, sondern die Übergänge zwischen den einzelnen Kontexten einer Applikation verschwimmen immer häufiger. Animationen verbinden diese Kontexte in weichen Übergängen. Sie werden hier nicht zum Selbstzweck eingesetzt, sondern helfen dem Benutzer sich auf den jeweils veränderten Anwendungskontext zu fokussieren. Die Animation wird damit fester Bestandteil der Benutzerführung und User Experience. ¥ Interaktive Prototypen auf Basis von HTML5 können hierbei mehrfach Abhilfe schaffen – zum einen bei der Gestaltung der Interaktionsstrukturen und Mikrointeraktionen auf den unterschiedlichen Endgeräten, zum andern bei der frühen Bewertbarkeit und verständlichen Kommunikation der Applikationen mit Nutzern, Kunden und Entwicklern.

UI-Design: Standardvorgehen und Methoden Heute existieren vielfältige Entwurfsansätze, Vorgehensmodelle und Methoden für das klassisches User Interface Design und den nutzerzentrierten Designprozess. Im Bereich der Visualisierung von UI-Entwürfen haben sich einige Standardmethoden etabliert, über die im Folgenden ein kurzer Überblick inklusive deren Vor- und Nachteile aufgezeigt wird.

Prototyping hoch Drei – interaktiv, dynamisch und konsequent (in der Zusammenarbeit)

53

Abbildung 1: Übersicht und Zusammenspiel der Visualisierungsmethoden im klassischen Entwurfsprozess

Sketching – „schnelle Skizzen“ Erste schnelle Pen&Paper-Skizzen dienen der Ideenfindung und Exploration ohne Anspruch auf Konsistenz. Sketching erlaubt es in der frühen Entwurfsphase schnell und einfach Ideen auszutauschen und zu diskutieren. UX-Designer, Projektmanager und Entwickler können so Ideen gezielt erkunden und überprüfen ohne zu viel Zeit und Aufwand zu investieren. Wireframing – „Flächenbelegung und Klickflows“ Beim Wireframing steht die Benutzerführung und Flächenbelegung im Fokus. In diesem Designschritt werden die grundlegende Informationsarchitektur, das Navigationskonzept, die Funktionen und Verortung der Interaktionselemente sowie die visuelle Struktur der geplanten Anwendung entwickelt und festgelegt. Wireframes bilden die relevanten Anwendungsfälle exemplarisch ab, um Kunden und Stakeholdern eine Rückversicherung zu geben, dass sämtliche Anforderungen abgebildet werden können bzw. berücksichtigt worden sind. Diese Phase dient auch dem Kunden, seine Anforderung auf Vollständigkeit zu überprüfen und hilft die oft komplexen Anforderungsdokumente besser zu verstehen. Mockups – „Visuelles Prototyping“ Unter Mockups werden im UI-Designprozess visuelle Prototypen bzw. nicht funktionale Designsimulationen verstanden. Mockups oder Design-Mockups verlieren im zielführenden und effektiven Entwurfsprozess zunehmend an Bedeutung. Eingesetzt werden sie vor allem in exemplarischen Designscreens, um sicherzustellen, dass die Corporate-Design-Vorgaben des Kunden (Auftraggeber) korrekt umgesetzt wurden. Prototypen – „funktional & interaktiv“ Unter Prototypen verstehen wir funktionale, interaktive Prototypen (Low- und High-Fidelity) ohne Backend-Anbindung. Für die zunehmende Interaktivität und die Verwendung von

54

Moritz Fröhner, Sebastian Ammermüller, Julian Mengel, Michael Kühnel

Animationen als Gestaltungsmittel bietet der Einsatz interaktiver Prototypen eine gute Möglichkeit, Kunden und Nutzern die Funktionalitäten besser verständlich zu machen.

Prototyping mit HTML-Frameworks Ansatz und Idee Für viele Kunden und Anwender ist die Bedienoberfläche einer Software die eigentliche Applikation. Durch die Entwicklung mit Prototypen sind beide in der Lage die Applikation mit ihrer Bedienlogik frühzeitig vor der Fertigstellung zu bewerten, zu testen und zu optimieren. In der Softwareentwicklung versteht man unter dem Begriff Framework eine Sammlung von Konventionen und Vorgaben, eine sogenannte Rahmenstruktur für die Programmierung. Unter dem hier verwendeten Begriff des (CSS-)Frameworks verstehen wir eine auf HTML5 (HTML, JavaScript und CSS3) basierende Sammlung von Gestaltungsvorlagen für Formulare, Buttons, Tabellen, Typografie, Grid-Systeme, Navigations- und weitere Oberflächengestaltungselemente. Die Einbindung eines solchen Frameworks in den Designprozess bietet die Möglichkeit, in relativ kurzer Zeit mit vertretbarem Aufwand interaktive Prototypen zu erstellen, die den erweiterten UI-Anforderungen in den Punkten Komplexität und Dynamik gerecht werden. Die vorgefertigten Komponenten wie Buttons, Navigationskomponenten oder Formularelemente ermöglichen das schnelle Erreichen von Ergebnissen. Dabei entsteht ein komplexes Tool-Set an UI-Komponenten, die relativ einfach, schnell und mit wenigen HTML-Kenntnissen zusammengebaut werden können. Auf diesem Weg können sinnvolle Werkzeuge entstehen, die Usability Professionals in die Lage versetzen, erste Designideen und Lösungen schnell und kostengünstig in Prototypen zu überführen und so die Klickpfade einzelner oder aller User Stories für die Projektbeteiligten einfach nutzbar und erfahrbar zu machen. HTML-Frameworks bieten gegenüber Standard Prototyping Tools u.a. folgende Vorteile. ¥ ¥ ¥

HTML-/CSS-Frameworks sind für interdisziplinäre Teams der kleinste gemeinsame Nenner, um gemeinsam eine konsistente Umsetzung der Oberfläche zu erreichen. Das entstandene Markup kann im gesamten Prozess wieder- bzw. weiterverwendet werden. Es entstehen keine „Abfallprodukte“ bis zur finalen Implementierung. Die zusätzliche Entwicklung eines Design-Style-Guides entfällt, da die visuellen Designdefinitionen direkt in HTML/CSS-basierten Designbibliotheken vorliegen.

Prototyping hoch Drei – interaktiv, dynamisch und konsequent (in der Zusammenarbeit)

55

Arbeiten mit HTML-Frameworks im UX-Design Prozess Die Detailarbeit beim Erstellen eines HTML-Prototyps unterscheidet sich abhängig vom gewählten Framework marginal. Die grundsätzliche Vorgehensweise lässt sich jedoch unabhängig vom gewählten Framework in fünf Schritte unterteilen.

Abbildung 2: Prototyping in HTML-Frameworks – Schritt für Schritt zum funktionalen Prototyp

Schritt 1 – Styling The Basic Elements Zu Beginn der Arbeit mit einem Framework (wie z. B. Bootstrap) wird im ersten Schritt das grundlegende Aussehen der Applikation bestimmt. Dabei unterstützt Bootstrap das von Luke Wroblewski ausgerufene Paradigma des „Mobile-First“-Ansatzes voll umfänglich. Neben den grundlegenden HTML-Elementen, wie z. B. Typographie, Buttons, Tabellen und Formularen wird auch ein Gestaltungsraster definiert. Ergebnisse nach diesem Arbeitsschritt sind ein robustes und für mobile Endgeräte optimiertes Gestaltungsraster. Alle Elemente, wie z. B. Typographie, Formulare, Tabellen etc. sind nach den Designvorgaben angepasst ebenso wie sämtliche Basiskomponenten des Frameworks. Schritt 2 – Basic Layouts Definition Zur Erstellung eines Prototyps wird mindestens eine Masterseite benötigt, in der die grundlegende Flächennutzung definiert ist. In diesem Template wird der Aufbau der Applikation festgelegt, wie Kopf- und Fußzeile, Navigationsbereich/-strukturen und der eigentliche Inhalts-/Arbeitsbereich. Das Spaltenlayout kann zusätzlich individuell eingerichtet werden. Je nach Detaillierungsgrad der Corporate-Design-Vorgaben und dem Anspruch eines High-Fidelity-Prototypen ist der Umsetzungsaufwand in diesem Bereich unterschiedlich hoch. Die Masterseiten bilden die Vorlage für den späteren Prototyps.

56

Moritz Fröhner, Sebastian Ammermüller, Julian Mengel, Michael Kühnel

Mit Abschluss dieses Arbeitsschritts ist das Applikationslayout festgelegt. Die Masterseiten für die verschiedenen Applikationsbereiche sind definiert und dienen als „Blaupause“ für die Erstellung des Prototyps. Schritt 3 – Components under Construction Wiederkehrende Elemente werden analysiert und daraus HTML-Komponenten erstellt. Typische Beispiele für Komponenten sind z. B. Navigationsleiste, Buttonbars, modale Dialoge, Tabellen, Feedback- und Login-Panel. Je nach verwendetem Framework werden die Basiskomponenten bereits mitgeliefert und sind individuell modifizierbar. Zusätzlich können eigene Komponenten entwickelt werden. Dafür sind erweiterte HTML-Kenntnisse hilfreich. Nach Schritt 3 stehen die wiederkehrenden Elemente als HTML-Komponenten (Baukasten) zur Verfügung und können für die Erstellung weiterer Seiten kopiert und eingefügt werden. Zudem wurden die Corporate-Design-Vorgaben der Komponenten in das CSS überführt. Durch die Trennung von Code und Layout können Designer und Entwickler parallel am Prototyp weiterarbeiten. Schritt 4 – Build & run the Prototype Mit den HTML-Elementen und den Komponenten wird entsprechend den Skizzen und Wireframes das UI nachgebaut. Für jeden Schritt eines Click Flows wird eine eigene HTMLSeite gebaut. Durch die logische Verlinkung der einzelnen Seiten werden die Use Cases durch interaktive Click Flows für den Benutzer erfahrbar gemacht. Die Inhalte sind zu diesem Zeitpunkt noch statisch im HTML-Code integriert und bestehen aus fiktiven Daten. Mit Fertigstellung dieses Arbeitsschrittes liegen alle Seiten und Dialoge der Applikation als HTML-Seiten vor. Gleichzeitig sind sämtliche Schritte eines Use Cases als einzelne HTMLSeiten vorhanden. Die Bedienlogik der Applikation kann von allen Beteiligten anhand der Click Flows nachvollzogen und bewertet werden. Schritt 5 – Mock Your Applikation Die vorhandenen Seiten sind bis auf die Verlinkung einzelner Arbeitsschritte noch ohne dynamische Interaktion. Um das Benutzererlebnis noch stärker an die Realität zu koppeln können die statischen Inhalte durch dynamische Daten ersetzt werden. Dazu werden reale Daten aus zukünftigen Schnittstellen so integriert, als ob diese Schnittstellen bereits bestehen würden. Somit sind weitere Benutzerinteraktionen, wie z.B. die Facettierung eines Suchergebnisses möglich. Dadurch entsteht eine realistisches Look & Feel der zukünftigen Applikation. Nach dem letzten Arbeitsschritt ist der Prototyp scheinbar voll funktionsfähig und kann von Nutzern getestet und optimiert werden. Die Mikrointeraktionen, die den „Joy of Use“ der Applikation steigern, sind integriert. Alle Projektbeteiligten bekommen ein vollständiges Bild der Funktionsweise der zukünftigen Applikation.

Prototyping hoch Drei – interaktiv, dynamisch und konsequent (in der Zusammenarbeit)

57

Ausblick – Prototype goes Production Der final abgestimmte Prototyp kann nun in die Implementierung gegeben werden. Abhängig davon, wie viel Detailarbeit in die Entwicklung des Prototyps investiert wurde, können bis zu 100% des Codes wiederverwendet werden. Neben der Zeitersparnis in der Entwicklung ist der Prototyp ein wichtiges Kommunikationsmittel zwischen UX Professionals und Entwicklern. Die Entwickler können das Verhalten auf unterschiedlichen Endgeräten, die Interaktionsmöglichkeiten und Animationen jederzeit anschauen und ihre eigene Implementierung überprüfen.

Best Practice – Praxisbeispiele für Prototyping Die folgenden Beispiele geben einen kleinen Überblick über Einsatzmöglichkeiten von HTML-Prototypen im UI-Designprozess. Nicht immer, müssen ganze Applikationen in Prototypen überführt werden, manchmal sind es nur einzelne Details, sogenannte „Microinteractions" – die durch einen Prototyp verdeutlicht werden können. Volkswagen Werbebriefprogramm Das Volkswagen Werbebriefprogramm ist eine Web-Applikation, auf der Volkswagen Partnerbetriebe Aktionsbriefe individualisieren und über einen Lettershop an ihre Kunden verschicken können. Die Anwendung wird kontinuierlich weiterentwickelt - mit steigender Komplexität im User Interface. Die Herausforderung bestand in der Konsolidierung der Informationsarchitektur und Harmonisierung des UI-Designs unter Berücksichtigung der Anforderungen aus Usability Tests und unter Einbeziehung der wichtigsten Stakeholder.

Abbildung 3: Volkswagen Werbebriefprogramm – Prototyping zur kontinuierlichen Weiterentwicklung

Der Prototyp diente dabei als Kommunikationsmittel zur gemeinsamen Abstimmung mit den beteiligten Fachbereichen und weiteren externen Dienstleistern. Die Moderation und Kommunikation im Entwurfsprozess konnte so effektiv und effizient gestaltet werden. Zudem wurde der Prototyp zur Durchführung von User Acceptance Test bereits in der Konzeptionsphase als fester Bestandteil integriert werden.

58

Moritz Fröhner, Sebastian Ammermüller, Julian Mengel, Michael Kühnel

Bei der Detailierung der Applikation konnte durch den Prototyp die optimale Flächenbelegung einzelner Elemente, wie die Spaltenbezeichnung von Tabellen, auf die eingeschränkte maximale Breite der Anwendung unter realen Bedingungen geprüft und abgestimmt werden. Zum Ende der Spezifikation entstand so ein High-Fidelity-Prototyp, der alle Funktionen der zukünftigen Anwendung detailliert dokumentiert und als Style Guide fungierte. Dadurch konnte eine hohe Qualität der Corporate Usability der Anwendung zwischen allen beteiligten Dienstleistern erreicht werden. POLYAS Login Polyas ist der führende Anbieter für Online-Wahlen in Deutschland. Die gleichnamige SAAS-Software ermöglicht es Unternehmen, Institutionen aber auch Einzelpersonen sichere Online-Wahlen individuell zu konfigurieren und an die eigene Bedürfnisse anzupassen.

Abbildung 4: Polyas Login – Prototyping zur Gestaltung von Microinteractions

Um den Login- und Registrierungsprozess möglichst einfach und attraktiv zu gestalten, entstand die Idee, beide Formulare nahtlos über eine Animation zu verknüpfen. Die Herausforderung dieses Entwurfs war die exakte Dokumentation der Animationsvorgaben und des genauen Timings der Mikrointeraktionen für die Entwicklung. Die Entscheidung einen Prototyp zu entwickeln, brachte den Vorteil, dass die Animationsvorgaben der UIDesigner nicht aufwändig dokumentiert werden mussten, sondern 1:1 von den Entwicklern in die Applikation übernommen werden konnten. Kirchlicher Arbeitsplatz ECKD GmbH Die von der ECKD GmbH entwickelte Software KirA („Kirchlicher Arbeitsplatz“) wird von zirka 3.000 Benutzern in den Kirchengemeinden mehrerer Landeskirchen eingesetzt. Die ECKD GmbH zählt seit mehr als 25 Jahren zu den führenden IT-Dienstleistungsunternehmen für Informationsverarbeitung im kirchlichen Umfeld. Die Herausforderung im Projekt bestand zunächst in der Überführung einer Windows-Applikation in eine mobilefriendly Webapplikation. Zudem sollte eine applikationsübergreifende, konsistente

Prototyping hoch Drei – interaktiv, dynamisch und konsequent (in der Zusammenarbeit)

59

Benutzerführung und Usability gestaltet und sichergestellt werden unter Berücksichtigung der Nutzergruppe 50+ und deren besonderen Bedürfnisse an die Software-Ergonomie. Im Rahmen der Umstellung der Anwendung wurde im ersten Schritt eine ExpertenEvaluation der Bestandsapplikation durchgeführt. Für die Neuentwicklung standen zusätzlich zwei zentrale Anforderungen im Mittelpunkt: Zum einen sollte die bestehende RibbonNavigation, bekannt aus Windows Office-Anwendungen, beibehalten werden, zum anderen sollte die Applikation vollumfänglich auch auf einem Tablet nutzbar sein. Zur Überprüfung des Navigationskonzepts und der Interaktionsmodule wurde ein Prototyp entwickelt, der es den Projektbeteiligten ermöglichte, ein Gefühl für die zukünftige Tablet-Version von KirA zu bekommen und das Look & Feel zu bewerten.

Abbildung 5: KirA – Prototyping zur Anwendungsoptimierung auf Desktop und Tablet und Erstellung „Living Style Guide“

Aus dem Prototyp wurde im Verlauf des Projekts einen „Living Style Guide“ entwickelt. Dieser ist vergleichbar mit einem HTML/CSS-Baukasten, in den UI-Designer und Entwickler wiederverwertbare Elemente einstellen und entnehmen können. Durch das „Baukastenprinzip“ konnte die Konsistenz der Applikation gesteigert und gleichzeitig der Entwicklungsaufwand für das Frontend reduziert werden.

Fazit Dynamisches Prototyping bietet eine Reihe von Vorteilen bei der Konzeption, Ausgestaltung, Definition und Implementierung von Softwareprodukten insbesondere im Rahmen der Zusammenarbeit mehrerer Disziplinen im Entwurfs- und Entwicklungsprozess. Die folgenden Aspekte können dabei herausgestellt werden. HTML ist leicht für Nicht-Entwickler zu lernen und ist der kleinste gemeinsame Nenner. Bereits nach wenigen Tagen sind auch Usability Professionals ohne ausgeprägten Entwicklungshintergrund in der Lage, ihre ersten Prototypen umsetzen.

60

Moritz Fröhner, Sebastian Ammermüller, Julian Mengel, Michael Kühnel

Das dynamische Verhalten von Menüs, Dialogen und Interaktionselementen kann durch Prototypen schneller und besser für Kunden und Nutzer erfassbar und bewertbar gemacht werden. Eine frühe Optimierung der Bedienstrukturen ist das Ergebnis. Informationsarchitektur, Interaktionsdesign und visuelles Design können parallel und unabhängig voneinander entwickelt werden, das Styling erfolgt unabhängig von der HTMLStruktur durch CSS-Anweisungen. Kollaboration von Design und Entwicklung werden durch die vorgegeben Strukturen erleichtert und fokussiert. Die Zusammenarbeit von Kunden, UX-Professionals, UI-Designern, Requirement Engineers, Frontend- und Backend-Entwicklern wird durch den Einsatz von Prototypen- Frameworks verbessert, gleichzeitig können spätere Korrekturen oder Anpassungen am User Interface auf ein Minimum reduziert werden. Der gesamte Entwicklungsprozess von der Idee über die Konzeption und Ausgestaltung des User Interface bis hin zur Umsetzung und Implementierung kann je nach Komplexität und Dynamik der Anwendung deutlich beschleunigt werden – insbesondere bei Industrieprojekten mit vielen Stakeholdern.

Lessons Learned „Lessons learned“ aus dem frühen Einsatz interaktiver Prototypen im Entwurfsprozess: [Effektive Planung und Optimierungsmanagement] Die Korrekturen des User Interfaces werden bei interaktiven Prototypen im Projektverlauf nach vorne verlagert und können so schneller und „kostengünstiger“ umgesetzt werden. [Vermeidung von redundanten Korrekturen] Änderungen an Navigationspunkten oder am „Wording“ führen bei klassischen Prototypen oft zu zeitaufwendigen Änderungen an zahlreichen Screens. In webbasierten Prototypen können diese leicht und automatisiert geändert bzw. im Vorfeld vermieden werden, indem wiederkehrende Elemente nur einmal erstellt aber mehrfach referenziert werden. [Stärkere Kundenintegration und Partizipation] Für viele Kunden ist das Frontend die eigentliche Anwendung. Kunden und auch Nutzer können durch interaktive Prototypen zu einem frühen Zeitpunkt das finale Produkt erfahren und bewerten. [Bessere Problemlösung] Viele kleine, oft unscheinbare Usability-Probleme lassen sich an interaktiven Prototypen besser erkennen und darüber hinaus auch besser lösen. Die User Experience der zu entwickelnden Anwendung kann dabei spürbar gesteigert werden. [Detaillierte und vollumfängliche Spezifikation] Steigerung der Anforderungsdokumentation durch die Parallelisierung von Konzeption und UI-Design durch Usability Professionals und Spezifizierung der Software durch Requirements Engineers.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 61- 71.

Antizipative Nutzererfahrungen Wie aus Daten Erfahrungen entstehen Agnieszka Maria Walorska

Agnieszka Maria Walorska

Creative Construction Heroes Brunnenstraße 192 10119 Berlin [email protected]

Abstract In der Ära der connected Devices haben wir es mit einer ständig wachsenden Menge an Daten zu tun. Dem Nutzer erscheinen diese Daten allerdings häufig eher ziemlich dumm. Die meisten Anwendungen, die wir heute verwenden, reagieren zwar korrekt auf Interaktionen, die in der Gegenwart stattfinden, nutzen aber die verfügbaren Daten nicht um die zukünftigen Bedürfnisse des Nutzers vorherzusagen und zu adressieren. Einige Unternehmen, wie Google (Nest, Google Now) oder Amazon (anticipatory shipping) haben den Wert der Antizipation früh erkannt, andere ziehen nach. Pro-aktive Anwendungen können zwar zu einer deutlich besseren Nutzererfahrung beitragen, sie können aber auf der anderen Seite auch zu einer Verwunderung und Unbehagen führen.

Keywords Anticipatory Interfaces, Anticipatory Design, Big Data, User Experience

Einleitung Nahezu alle digitalen Produkte bzw. Produkte mit digitalen Komponenten generieren oder verarbeiten eine enorme Menge von Daten. Auch wenn das Schlagwort „Big Data“ sich aktuell auf dem Zenit seiner Popularität befindet, ist die Bezeichnung „Dumb Data“in den meisten Fällen präziser. 1 Der Grund dafür ist, dass diese Daten bisher selten einen Mehrwert 1

Boland, G.W., Thrall, J.H. & Duszak, R. (2015). in Business Intelligence, Data Mining, and Future Trends. Reston, Virginia. S 9-11

62

Agnieszka Maria Walorska

für den Nutzer generieren. Der Großteil der Systeme und Benutzeroberflächen, die wir benutzen und entwickeln sind lediglich „responsiv“. Nicht in der Bedeutung von Responsive Web Design, sondern im semantischem Sinne: sie reagieren ausschließlich auf Aktionen und Veränderungen in der Gegenwart.

Neue Nutzungskontexte und Technologien Mobile Endgeräte gelten als eine der treibenden Kräfte hinter dem Übergang von einer responsiven zu einer antizipativen Nutzererfahrung. Das Zeitalter der allgemeinen Verbreitung von Mobiltelefonen beginnt in den späten neunziger Jahren.2 Von diesem Zeitpunkt an, bis zu den Jahren 2007 bzw. 2008 gab es nur geringfügige Veränderungen innerhalb des Konzepts von mobilem Nutzungsverhalten.3 Handys wurden in erster Linie zur Tätigung von Anrufen oder zum Versenden von SMS verwendet.4 Als die signifikanteste Innovation innerhalb dieser Zeit kann die Markteinführung und Verbreitung von PDAs verstanden werden. PDAs erlaubten dem Nutzer, E-Mails zu versenden und zu empfangen und waren sogar in der Lage, zumindest rudimentär, Webseiten aufzurufen. Dieser Iteration des mobilen Nutzungskontextes folgte bald der Einstieg einer neuen Art von mobilen Endgeräten auf den Handy-Markt. Das Smartphone, anfangs hauptsächlich verkörpert in Apples iPhone, fand immer größere Popularität und Verbreitung. Auch wenn die ersten Smartphone-Versionen noch einige Wünsche auf Soft- und Hardwareebene zu Wünschen übrig ließen, läuteten sie einen Wendepunkt in der Geschichte von mobiler Nutzungshistorie ein. Eine der wenigen Technologien, mit denen die frühen Smartphone-Versionen bereits versehen waren, sind Sensoren. Sensoren stellen, neben dem Faktor der Mobilität, einen der primären Antriebsfaktoren für die Entwicklung hin zu antizipativen Systemen dar. Als weitere Faktoren dieser Entwicklung sind standort-bezogene Dienste, die sozialen Medien und Big Data zu nennen. 5

2

Ling, R. (2008). The mobile connection: the cell phone’s impact on society. New York, NY.

3

Hjorth, L. (2012) Studying mobile media: cultural technologies, mobile communication, and the iPhone. New York, NY.

4

Hjorth, L. & Goggin, G. in Goggin (Hrsg.) (2009). Mobile technologies: from telecommunications to media. New York, NY. S 3-9

5

Scoble, R. & Israel, S. (2013) Age of Context: Mobile, Sensors, Data and the Future of Privacy. New York, NY

Antizipative Nutzererfahrungen

63

Von der Responsivität zur Antizipation Zur genaueren Dechiffrierung der verwendeten Begrifflichkeiten in dieser Ausarbeitung, soll die Bezeichnung „responsiv“ genauer examiniert werden. Responsive Web Design erreichte seinen Zenit im Jahr 2013 und ist seitdem als Standard in der Entwicklung von zeitgemäßen Webseiten etabliert.6 Eine Analyse des Begriffs auf semantischer Ebene zeigt auf, in welchen Ebenen responsives Webdesign angewendet wird. Responsiv handelt ein Subjekt, wenn es auf eine Aktion antwortet, es agiert rezeptiv. Es ist also passiv und reaktiv anstatt proaktiv. Die Mehrheit der Systeme und Benutzeroberflächen, die aktuell verwendet und entwickelt werden, besitzen eher beschränkte antizipative Fähigkeiten. Sie reagieren auf Aktionen und Veränderungen bei der Nutzung in der Gegenwart, sind also responsiv. Das Verhalten antizipativer Interfaces hingegen wird durch unterschiedliche Aspekte der Vergangenheit und Gegenwart und durch die Erwartung zukünftiger Aktionen beeinflusst. Mit Hilfe dieser zeitlich dreidimensionalen Einschätzung von Nutzerverhalten, können antizipative Technologien Interaktionsebenen bedienen, die dem Nutzer nicht nur individualisierte Lösungen anbieten, sondern zusätzlich in der Lage sind, das Verhalten des Nutzers zu prognostizieren und unter der Berücksichtigung aktueller und absehbarer Umweltzustände, einen optimalen Lösungsweg zu erstellen und diesem dem Nutzer zu empfehlen.

Hypothetisches Szenario Die Möglichkeiten der proaktiven Erfahrungen den Alltag des Nutzers zu verändern sind vielfältig. Eine Darstellung einiger dieser Möglichkeiten anhand eines hypothetischen futuristischen Szenarios an dieser Stelle dient dazu, ein besseres Gefühl für die Idee hinter den vorausschauenden Technologien und Erfahrungen und für die zukünftige NutzerTechnologie Interaktionen zu vermitteln. In der nahen Zukunft könnte der Alltag eines Nutzers wie folgt aussehen: Der Morgen beginnt mit einem sanften erwachen mit dem Geruch frisch gebrühten Kaffees, einfallendem Morgenlicht und mit einer Rückenmassage. Sensoren in der Matratze analysieren den Schlaf und steuern die Kaffeemaschine, Rollos und Massage-Elemente im Bett automatisch. Und zwar so, dass der Nutzer in dem günstigsten Moment geweckt wird – ohne dass seine Tiefschlaf-Phase unterbrochen wird. Klimaanlage, Musik, Beleuchtung – die gesamte Wohnung ist vernetzt, lässt sich nicht nur mit einfachen Handbewegungen oder Spracheingaben steuern, sondern merkt sich auch die Präferenzen des Nutzers. Der Kleiderschrank stellt automatisch die auf den Terminkalender abgestimmte Kleidung bereit. Sensoren in der Toilette analysieren die Werte - basierend darauf werden Ernährungsempfehlungen an die intelligente Küche übergeben. Das Frühstück

6

Cashmore, P. Why 2013 is the Year of Responsive Web Design. http://mashable.com/2012/12/11/responsiveweb-design, abgefragt am 17.06.2015.

64

Agnieszka Maria Walorska

wird unter Berücksichtigung dieser Empfehlungen und in Abhängigkeit von den bekannten Präferenzen des Nutzers zusammengestellt. Der Kühlschrank schlägt die benötigten Lebensmittel vor, zusammen mit der Empfehlung des günstigsten Anbieters. Der Einkauf kann mit einem klick freigegeben werden. Das selbstfahrende Auto hat den gegenwärtigen Straßenverkehr mit dem Terminkalender abgeglichen und informiert den Nutzer über die verbleibende Zeit und empfiehlt welche Erledigungen in dieser Zeit getätigt werden können.

Antizipation ermöglichen Futuristen wie auch die Science-Fiction Literatur und Filme haben diese und viel weiter gehende Möglichkeiten schon vor einiger Zeit vorhergesagt, doch der Einzug der tatsächlichen Anwendung solcher (bzw. ähnlicher) Technologien in den ConsumerMainstream ist erst seit dem Jahr 2014 wirklich bemerkbar.7 Durch künstliche Intelligenz werden Computer immer intelligenter und nützlicher, durch die steigende Speicher- und Prozessorkapazität sind sie in der Lage, immer schneller immer mehr Daten zu verarbeiten. Der Vormarsch antizipativer Lösungen ist jedoch nicht nur mit den immer schlauer und schneller werdenden Maschinen verbunden, sondern auch mit dem veränderten Stellenwert von Technologie im Leben der Nutzer. Technologie hat den Schritt von einem reinen Produktivitätswerkzeug hin zu einem mobilen sozialen und funktionalen Begleiter im Alltag der Nutzer vollzogen.8 Diese Entwicklung verdeutlicht sich auch bei der Betrachtung der Anwendung von Mobiltelefonen. So ist das Tätigen von Anrufen nur noch die sechsthäufigst genutzte Funktion beim Benutzen eines Smartphones und bis zu 40 % der Smartphone Nutzer sagen, sie könnten auf die Anruf-Funktion komplett verzichten.9 Hinzu kommt, dass die Bezeichnung „mobiler Endgeräte“ nicht mehr nur Telefone beschreibt. Sie umfasst mittlerweile eine Reihe diverser Wearables wie Smart Watches, Smart Glasses und FitnessTracker und wird ständig um neue Technologien erweitert. Diese Innovationen sind eng mit der Entwicklung der Sensorik von Smartphones und Wearables verbunden. Sie ist ein essentieller Teil für die Mess- und Erfassungsfähigkeiten dieser Geräte. Beginnend mit Beschleunigungsmessern und Gyroskopen über Magnetometer und Näherungssensoren zur Orientierung, der Lichtsensorik, dem Thermometer und dem Feuchtigkeitssensor hin zum Schrittzähler, Pulsmesser und Fingerabdruck-Sensor streckt sich die Auflistung der unterschiedlichen Sensoren.

7

Frith, J. (2015). Smartphones as Locative Media. New York, NY: DMS – Digital Media and Society

8

Negroponte, N. (1995). Being Digital. New York, NY

9

Hailo App Umfrage (2014): Mobile Usage Survey

Antizipative Nutzererfahrungen

65

Anwendung findet eine Vielzahl dieser sensorischen Technologie jedoch häufig nur durch das Hinzuziehen von standortbasierten Daten. Standortbezogene Dienste erscheinen in zeitgemäßer Analyse von mobiler Technologie als rudimentärere Funktion, sind aber essentieller Bestandteil vom Großteil der Anwendungsmöglichkeiten mobiler Endgeräte. Alleine die Vorstellung des Aufschlagens einer analogen Karte zur Orientierungshilfe ist schon lange nicht mehr Teil des kollektiven Nutzergedächtnisses. Sensorik und Standortbezogene Dienste sind tief in den Funktionen sozialer Netzwerke verwurzelt und verstärken die Erstellung der hochgradig individualisierten Inhalte durch den Nutzer auf den verschiedenen Plattformen. Diese Inhalte ermöglichen antizipativer Technologie, die Identität und Vorlieben des Nutzers nachzuvollziehen und zu kontextualisieren, um damit zukünftige Handlungen des Nutzers zu prognostizieren. Die Daten, die innerhalb der genannten Prozesse produziert werden, kann als ein weiterer treibender Faktor zur Entwicklung antizipativer Lösungen verstanden werden. Laut dem Softwareunternehmen IBM, wurden 90% aller Daten auf der Welt in den letzten zwei Jahren generiert.10 Laut Jeniffer Erwitt (Smolan & Erwitt 2012) werden am ersten Tag im Leben eines Neugeborenen, weltweit das Siebzigfache an Daten der Library of Congress erstellt.11 Diese enorme Datenmenge wird umgangssprachlich häufig als „Big Data“ bezeichnet. Jedoch sind es vor allem die kleinen, stark personalisierten Daten, die der Kontextualisierung und Erstellung antizipativer Lösungen dienen.12 Ganz so weit wie in den dargestellten Beispielen sind wir allerdings noch nicht. Angefangen damit, dass es für solche Technologien noch nicht mal ein einheitlicher Terminus existiert. Wir sprechen von „anticipatory computing“, „anticipatory Interfaces“, „proactive experiences“, „predictive technology“ usw. Mir gefällt „anticipatory experiences“13 am besten - unter anderem weil man das so schön ins deutsche mit „antizipative bzw. Voraussehende Erlebnisse“ übersetzen kann. „Antizipative Schnittstellen“ dagegen klingt einfach sehr technisch und transportiert nicht die gesamte Aussage. Diese „antizipative Erlebnisse“ sind eine Art von User Experience Design, in dem die Geräte oder Software, mit denen der Nutzer interagiert, aktiv „mitdenken“. Sie wissen, was der Nutzer in dem gegebenen Moment tut, und „überlegen“, was er als nächstes tun wird, ohne dass er das explizit sagen muss.

10

IBM (2013). What ist Big Data? http://www-01.ibm.com/software/data/bigdata/what-is-big-data.html, abgefragtam 21.06.15

11

Smolan, R. & Erwitt, J. (2012) The human face of big data. Sausalito, CA

12

Ferrer-Roca, O., Tous R. & Milito, R. (2014). in International Conference on Identification, Information and Knowledge in the Internet of Things. Peking. S 260-261

13

Lopez, M. (2013) Right-Time Experiences. Hoboken, NJ.

66

Agnieszka Maria Walorska

Eine ideale User Experience im Anticipatory Design soll für den Nutzer wie die Interaktion mit dem besten Freund oder dem Partner sein, der nicht nur seine Sätze vervollständigen kann, sondern auch seine Wünsche und Aktionen antizipieren kann. Oder wie mit einem äußerst aufmerksamen Assistenten, der ihn und seine Routinen und Präferenzen so gut kennt, dass sie das meiste ohne explizite Aufforderung erledigen.

Beispiele für die antizipativen Erlebnisse Eine sehr einfache Anwendung, die eine rudimentäre Antizipation bietet ist die Kalenderfunktion von iOS. Wird auf dem iPhone eine E-Mail empfang, die den Text „Wir sehen uns morgen“ enthält, nimmt das System an, man wolle möglicherweise einen Kalendereintrag erstellen und wandelt das Wort „morgen“ in einen Hyperlink um, der direkt zum Kalender führt. Leider hat dieses System noch einige Lücken – wie in dieser Mail.

Abbildung 1

Die Phrase „thursday morning“ wurde zwar verstanden, allerdings nicht im Kontext: „thursday morning is no longer free“. Ein funktionierendes antizipatives System müsste dem Nutzer eher empfehlen, den Termin zu löschen, anstatt einen hinzuzufügen. Ein gutes Beispiel für eine antizipative Anwendung ist das kürzlich von Google aufgekaufte Unternehmen “Nest”. Nest produziert intelligente Thermostate, die individuell angepasste

Antizipative Nutzererfahrungen

67

Energiepläne erstellen. Bei der Planerstellung werden das Verhalten der Bewohner, das Wetter und die Energiepreise dynamisch berücksichtigt. Nests Geräte sind so in der Lage zu antizipieren, unter welchen Umständen welche Temperierungseinstellungen gemäß der Präferenzen des Nutzers zu treffen sind.14 LGs intelligenter Kühlschrank weiß, womit er gefüllt ist, und kann somit Einkaufslisten erstellen. Zusätzlich kann man ihm beispielsweise eine SMS schicken und fragen, wie viel Bier noch da ist. Er weiß auch zu warnen, dass es Zeit ist wieder Milch einzukaufen.15 Als erfolgsversprechender Ansatz gilt auch eine weitere Applikation aus dem Hause Google: Google Now. Diese App versorgt den Nutzer automatisch mit Informationen, die für sein persönliches Handeln relevant sind. Dazu lernt Google Now zum einen die Routinen und das Verhalten seines Benutzers und stimmt diese dann mit den äußeren Umweltbedingungen ab.16 Abhängig vom üblichen Tagesablauf und derzeitigen Aufenthaltsort des Nutzers kann Google Now so erkennen, ob sich der Benutzer zu Hause oder auf der Arbeit befindet, welches seine wahrscheinlichste nächste Destination ist, ob es auf dem gewohnten Reiseweg zu diesem Ziel derzeit Staus gibt, und es kann dem Nutzer somit – ohne die Erfordernis einer Eingabe – Alternativen vorschlagen. Schon diese wenigen Beispiele zeigen, dass der aktuelle Entwicklungsstand eigentlich gar nicht so weit von dem eben vorgestellten Zukunftsszenario entfernt ist.

Die Schattenseite der Antizipation Hier noch ein anderes Beispiel – Amazon. Im Kontext von Amazons “Anticipatory Shipping”17 haben viele zum ersten Mal von antizipativen Erfahrungen gehört und es nicht unbedingt mit Begeisterung zur Kenntnis genommen. Dieses antizipative LogistikManagement-Tool von Amazon soll in der Lage sein, durch die Analyse der Kauf- und Suchmuster des Kunden genau die Produkte herauszufiltern, die er wohlmöglich bei der nächsten Bestellung erwerben möchte. Auf Basis dieser Berechnungen werden dann die kundennahen Logistikzentren vorausschauend mit den entsprechenden Produkten versorgt, um dann im Falle einer Bestellung die Lieferzeiten zu minimieren.

14

Google Nest (2015). https://nest.com/ abgefragt am 21.06.2015

15

Luna Sleep (2015). https://lunasleep.com/ abgefragt am 21.06.2015

16

Gordon, W. (2014). Lifehacker – Top 10 Awesome Features of Google Now. http://lifehacker.com/top-10-awesomefeatures-of-google-now-1577427243 abgefragt am 21.06.2015

17

Bensinger, G (2014). Amazon Wants to Ship Your Package Before You Buy It. http://blogs.wsj.com/digits/2014/01/17/amazon-wants-to-ship-your-package-before-you-buy-it abgefragt am 21.06 2015

68

Agnieszka Maria Walorska

Spätestens bei diesem Beispiel kommen Fragen hoch. Während kaum ein Nutzer Bedenken bezüglich der personalisierten Temperatureinstellung oder der proaktiven Informationen zur Verkehrslage äußern würde, fänden viele die Vorstellung merkwürdig, dass ein Produkt, welches nach Einschätzung Amazons wahrscheinlich unter ihre nächste Bestellung fällt, vorsorglich in ein Lieferzentrum ihrer Nähe verfrachtet wird und dort auf den tatsächlichen Bestellimpuls wartet. 2012 hat eine ähnliche Geschichte Schlagzeilen gemacht. Ein wütender Mann kam in eine Target-Filiale in der Nähe von Minneapolis und wollte den Filialleiter sprechen. Er zeigte ihm ein Heft mit Rabattgutscheinen für Schwangerschaftsmode und Babyartikel und beschwerte sich. Seine Tochter, ein Teenager, hätte sie in ihrer Post gefunden. Der Filialleiter entschuldigte sich für das Missverständnis. Nach einigen Tagen stellte sich allerdings heraus, dass es sich hier um gar kein Missverständnis gehandelt hat – die Tochter des Mannes war tatsächlich schwanger. Und Target hat das früher erfahren als der Vater. Allerdings war es nicht so, dass das Mädchen irgendwo bei Target eine Angabe zu ihrer Schwangerschaft gemacht hätte. Das Gutscheinheft wurde ihr basierend auf der Analyse ihrer Käufe zugeschickt. Dabei hat sie nicht mal etwas explizit Schwangerschaft-relevantes gekauft. Alleine durch die Veränderung ihres Kaufverhaltens – verglichen mit der Daten-Analyse tausender anderer Kunden – konnte ihre Schwangerschaft antizipiert werden. 18

Uncanny valley of anticipation Dieses Phänomen könnte als „uncanny valley of anticipation“ bezeichnet werden. Der Begriff „Uncanny Valley“ bezieht sich ursprünglich auf die Robotik19. Er definiert das Phänomen, dass die Akzeptanz von Robotern oder Avataren vom Realitätsgehalt dieser abhängt, jedoch nicht linear mit der Menschenähnlichkeit der Figur steigt, sondern innerhalb einer bestimmten Spanne einen starken Einbruch verzeichnet. Die Grafik verdeutlicht dies. Das gleiche Prinzip kann auch auf die antizipative Software angewendet werden.

18

Forbes (2012). How Target Figured Out A Teen Girl Was Pregnant Before Her Father Did. http://www.forbes.com/sites/kashmirhill/2012/02/16/how-target-figured-out-a-teen-girl-was-pregnant-beforeher-father-did/ abgefragt am 21.06.2015

19

Liu, H. L. (2010). The Freudian robot : digital media and the future of the unconscious. Chicago, IL

Antizipative Nutzererfahrungen

69

Abbildung 2

Die Ansätze von Amazon oder Target befinden sich genau in diesem „unheimlichen Tal“, da sie dem Nutzer das Gefühl geben, etwas über ihn zu wissen, dass er gar nicht vorhatte, Preis zu geben. Es ist zudem durchaus denkbar, dass diese Kurve am Ende noch einmal nach unten geht. Wäre ein Szenario wie im „Minority Report“ nicht vorstellbar (die Polizei in Bayern versucht jetzt schon mithilfe einer entsprechenden Software zukünftige Einbrüche vorher zu sehen und zu verhindern. Nur nicht mit Hilfe der Personen, „precogs“ sondern der Software „precob“)? 20 Wo genau ist die Grenze zwischen Hilfestellung und Bevormundung? Wird der Alltag, der auf der Analyse meinen Präferenzen und Gewohnheiten basiert, nur einfacher oder wird er langweilig, da die Zufallskomponente komplett rausgenommen wird? Kann es tatsächlich passieren, dass sich die antizipative Software so weit entwickelt, dass sie sich tatsächlich verselbständigt (wie das Betriebssystem Samantha in „Her“) und durch den Menschen unkontrollierbar wird?

20

AFP (2014). Berlin police mull crime-predicting software. http://phys.org/news/2014-12-berlin-police-mullcrime-predicting-software.html abgefragt am 21.06.2015

70

Agnieszka Maria Walorska

Es wird in jedem Fall noch einige Jahrzehnte dauern, bis sich diese Fragen in ihrer ganzen Dimension tatsächlich stellen werden. Trotzdem können und sollten wir damit anfangen, antizipative Erfahrungen zu gestalten. Dabei sollten wir folgendes beachten: Relevant sein, aber nicht unheimlich – klar werten wir die Nutzerdaten aus, um Relevanz zu schaffen, aber wir nutzen sie nur so weit, dass der Nutzer nicht das Gefühl hat, er hätte einen Stalker. Unterstützen statt bevormunden – die angebotenen Anwendungen sollen sich eher wie ein aufmerksamer Butler anfühlen, der sich zurückhält, wenn er nicht gebraucht wird, der diskret ist und der unaufdringlich seine Hilfe anbietet. Nicht aber wie eine überfürsogliche Mutter, die immer besser weiß, was für ihre Kinder am besten ist, und sich somit berechtigt fühlt, die Entscheidungen für sie zu treffen. Frustrationen beim Nutzer verhindern - eine zu 85% genaue Antizipation klingt zunächst nach einem Erfolg. Das wird jedoch schnell relativiert, wenn man den Vertrauensverlust bedenkt, der sich bei den restlichen 15% ergibt, bei denen eine falsche Empfehlung abgegeben wurde. Diese Analogie lässt sich auch auf Spracherkennung anwenden, wie die Frustration über SIRI zeigt, wenn die User-Eingaben nicht erkannt werden. Ein ähnliches Problem wird sich bei allen Arten von proaktiven Apps ergeben. Daher müssen wir überlegen, wie wir es überwinden können.

Antizipative Interfaces befinden sich zwar noch in den Kinderschuhen, die großen Plattformen werden aber ihre proaktiven Kapazitäten nach und nach weiter ausbauen. Apple, Google, Amazon und weitere Unternehmen besitzen jetzt schon viele der für antizipative Lösungen notwendigen Bausteine. Auch die Vorhersagen der Technologie-Trends für 2015, z.B. von Gartner21, deuten stark darauf hin, dass proaktive Erfahrungen immer stärker im Alltag ankommen werden. Daher sollten wir uns als UX und Usability-Profis darauf einstellen relevante, unterstützende und möglichst wenig frustrierende antizipative Erfahrungen zu gestalten. Literatur AFP (2014). Berlin police mull crime-predicting software. http://phys.org/news/2014-12-berlin-policemull-crime-predicting-software.html abgefragt am 21.06.2015 Bensinger, G (2014). Amazon Wants to Ship Your Package Before You Buy It. http://blogs.wsj.com/digits/2014/01/17/amazon-wants-to-ship-your-package-before-you-buyabgefragt am 21.06 2015 21

Gartner (2015). Gartner’s Top 10 Strategic Technology Trends for 2015. http://www.gartner.com/smarterwithgartner/gartners-top-10-strategic-technology-trends-for-2015/ abgefragt am 21.06.2015

Antizipative Nutzererfahrungen

71

Boland, G.W., Thrall, J.H. & Duszak, R. (2015) in Business Intelligence, Data Mining and Future Trends. Reston, Virginia. S. 9-11 Cashmore, P. Why 2013 is the Year of Responsive Web Design. http://mashable.com/2012/12/11/responsive-web-design, abgefragt am 17.06.2015. Ferrer-Roca, O., Tous R. & Milito, R. (2014). in International Conference on Identification, Information and Knowledge in the Internet of Things. Peking. S 260-261 Forbes (2012). How Target Figured Out A Teen Girl Was Pregnant Before Her Father Did. http://www.forbes.com/sites/kashmirhill/2012/02/16/how-target-figured-out-a-teen-girl-waspregnant-before-her-father-did/ abgefragt am 21.06.2015 Frith, J. (2015). Smartphones as Locative Media. New York, NY: DMS – Digital Media and Society Gartner (2015). Gartner’s Top 10 Strategic Technology Trends for 2015. http://www.gartner.com/smarterwithgartner/gartners-top-10-strategic-technology-trends-for-2015/ abgefragt am 21.06.2015 Gordon, W. (2014). Lifehacker – Top 10 Awesome Features of Google Now. http://lifehacker.com/top10-awesomefeatures-of-google-now-1577427243 abgefragt am 21.06.2015 Hailo-App Umfrage (2014): Mobile Usage Survey Hjorth, L. (2012). Studying mobile media: cultural technologies, mobile communication, and the iPhone. New York, NY Hjorth, L. & Goggin, G. in Goggin (Hrsg.) (2009). Mobile technologies: from telecommunications to media. New York, NY. S 3-9 IBM (2013). What ist Big Data? http://www-01.ibm.com/software/data/bigdata/what-is-big-data.html, abgefragt am 21.06.15 Ling, R. (2008) The mobile connection: the cell phone’s impact on society, New York, NY Liu, H. L. (2010). The Freudian robot : digital media and the future of the unconscious. Chicago, IL Lopez, M. (2013) Right-Time Experiences. Hoboken, NJ. Negroponte, N. (1995). Being Digital. New York, NY Scoble, R. & Israel, S. (2013) Age of Context: Mobile, Sensors, Data and the Future of Privacy. New York, NY Smolan, R. & Erwitt, J. (2012) The human face of big data. Sausalito, CA

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 72- 83.

Content Design und UI Architektur für Multiscreen-Projekte Methoden und Regelwerke für die Konzeption, Gestaltung und Umsetzung von Layout, Inhalt und Workflows im Baukasten-Prinzip Wolfram Nagel

Wolfram Nagel

SETU GmbH Oberbettringer Straße 15 73525 Schwäbisch Gmünd [email protected]

Abstract Digitale Inhalte können heute überall erscheinen. Wir nutzen täglich digitale Services auf verschiedensten Geräten und Medien. Informationen fließen in alle Kanäle. Multiscreen ist inzwischen digitale Realität geworden. Um ein einheitliches Nutzungserlebnis zu erschaffen, benötigt es einen durchgängigen Informationsfluss. Voraussetzung dafür sind ein zentraler Knotenpunkt für Inhalte, ein System zur Definition von UI Elementen und Regeln wann welche Inhalte in welcher Kombination wo und wie angezeigt werden. Damit dies technisch gelöst werden kann, ist es erforderlich Inhalte, User Interfaces und Workflows nach einem jeweils ähnlichen Muster modular und strukturiert zu planen und aufzubauen – vergleichbar mit den Bausteinen in einem Baukastensystem. Anmerkung: In diesem Beitrag werden die Begriffe Content und Inhalt gleichbedeutend verwendet. Die deutsche Bezeichnung wird immer dann verwendet, wenn es sprachlich sinnvoll erscheint.

Keywords Content Design, UI Architektur, User Interface Design, Design Prozess, Konzeption, Multiscreen

Einleitung Viele Content-Angebote (z.B. einzelne Artikel der New York Times oder des Spiegel) werden heute häufiger in anderen Kanälen (z.B. auf Twitter oder in Flipboard) als der originären Website wahrgenommen. Eine Inhalts-Schnittstelle (Content API) gibt alle Infos

Content Design und UI Architektur für Multiscreen-Projekte

73

ab und der Empfänger oder darstellende Kanal entscheidet, welche Inhaltselemente er verwendet. Die visuelle Ausgestaltung ist dann durch die Styling-Definitionen der Ziel- und Fremdplattformen vorgegeben. Um für eine automatisierte Verwendung die richtigen Inhaltsbausteine bereitstellen zu können, muss der Inhalt entsprechend strukturiert – im besten Fall sogar „intelligent“ – sein. “You can create good experiences without knowing the content. What you can't do is create good experiences without knowing your content structure. What is your content MADE from, not what your content IS.” — Mark Boulton

Next Generation Information Experience in einer Multiscreen-Welt Die Art und Weise, wie Informationen entstehen, verändert sich. Auf der Seite der Entstehung von Inhalt steht der Autor oder Inhaltskurator. Auf der anderen Seite steht der Rezipient, also der Nutzer der Informationen. Am besten wäre es, wenn Autoren ihr gewohntes Erstellungs-System benutzen können und die erfassten Inhalte über entsprechende Schnittstellen und eine Art Inhalts-StrukturMapping im Content Hub gemäß des Inhaltsmodells konsolidiert, zusammengeführt und auf die definierte Struktur gebracht werden. Dadurch wäre es möglich Inhalte mit Informationen des Inhaltsmodels zum Beispiel per E-Mail, Evernote, Tweet, Facebook-Post oder einem anderen System zu erfassen, im Content Hub aufzubereiten und flexibel an einen beliebigen Kanal abzugeben. Es wäre somit möglich über eine „simple“ E-Mail die Inhaltselemente Autor/Verfasser, Erstellungsdatum, Kurzbeschreibung, textlicher Hauptinhalt, Bilder oder Media-Elemente (als Anhänge) und andere Metainformationen z.B. mit Hilfe von Hashtags oder anderen definierten Zeichen im E-Mail-Text zu erfassen. Die erfassten Inhalte können dann von den Editoren im zentralen Knotenpunkt bearbeitet, optimiert und ergänzt werden. Inhaltsanbieter stehen vor dem Problem, dass sie Inhalte in vielen Kanälen konsistent publizieren können sollten. Informationen sollten sich überall darstellen lassen. Voraussetzung dafür sind ein zentraler und möglichst benutzerfreundlicher Knotenpunkt für Inhalte (z.B. CMS), ein zentrales System zur Definition von UI Elementen (z.B. Styleguide) und entsprechende Regeln (Workflows) wann welche Inhalte in welcher Kombination auf welchem Gerät wie angezeigt werden. In einem vorgelagerten oder zumindest am Anfang des Projekts initiierten (CMXD-) Prozess lassen sich die dafür wichtigsten Parameter definieren (Nagel, 2014b). CMXD steht hier für „Content Manager Experience Design“, angelehnt an einen Artikel von Rasmus Skjoldan (2013). Dazu gehört es die Modi der Inhaltserfassung zu erkennen, die 3-5 wichtigsten Zielkanäle zu definieren und das Eingabeinterface und die Systeme entsprechend anzupassen oder zu synchronisieren.

74

Wolfram Nagel

Abbildung 1: Next Generation Information Experience (Nagel, 2014a). Zentraler Content Hub. Drei Phasen im Informationsfluss: Erfassen, Verwalten und Nutzen von Inhalten (dann ggf. kommentieren, ändern, ergänzen = erneutes Erfassen)

Eine unabhängige Methode für eine ungewisse Zukunft Mein nachfolgender Ansatz ist nicht grundsätzlich neu. Es geht mir unter anderem um das Grundprinzip und eine einheitliche allgemein verständliche Sprache und um disziplinübergreifende Begriffe, die von allen Stakeholdern verstanden werden (Projektmanager, Kunden, Entwickler, Konzepter, Gestalter). Der Grundgedanke ist es, alles (ähnlich) atomar bzw. nach dem Baukastenprinzip zu zerlegen bzw. zusammenzusetzen und generisch zu denken. Vor allem vor dem Hintergrund, dass wir gar nicht ahnen können, für welche zukünftigen Kanäle wir zum aktuellen Zeitpunkt Inhalte und User Interfaces entwerfen (Frost, 2015). „I have no idea what the hell I am doing. And neither do you. And that’s ok.“ – Brad Frost Ich denke, dass wenn man Inhalte, User Interfaces und Prozesse nach atomaren, modularen Baukasten-Patterns erstellt, ist man von zukünftigen Entwicklungen weitgehend unabhängig. Semantisch gleiche Inhalte sollten in unterschiedlichen Medien, Kanälen und Geräten variabel einsetzbar sein – das gilt für Smartphone, Tablet, Desktop, TV und Smartwatch genauso wie für Inhalte auf der eigenen Website, im Google-Suchergebnis, im RSS-Feed, auf Instagram oder Facebook oder jede andere Inhalts-Darstellung.

Content Design und UI Architektur für Multiscreen-Projekte

75

Vier Kernbereiche Um Inhalte, Interfaces und Prozesse flexibel, strukturiert und modular zu planen und umzusetzen, sind im Projektverlauf grundsätzlich vier Kernbereiche zu betrachten: Inhalte, UI, Workflows und Schnittstellen. Der Inhalt und seine Nutzer (das sind sowohl die Autoren und Editoren als auch die Empfänger der Information) sollten im Zentrum der Betrachtung stehen. „Design from the Content out“ – Stephen Hay (via Frost, 2012) Informationen (Daten/Content). Entsprechend der thematischen Tendenz (Taxonomie, "Unit", Domäne) gibt es Inhaltselemente für verschiedene Inhaltstypen. Dazu die entsprechenden Formular-Elemente für das "Backend-Frontend", um die Eingabemaske für die Inhaltsobjekte zu bauen (vorausgesetzt die Inhalte werden in einem eigenen Content Management System erfasst). Ein Inhaltstyp besteht aus verschiedenen Inhaltselementen. Die semantische Bedeutung beeinflusst die Struktur des Inhaltstyps, dessen Klassifikation und entsprechende Kategorien. Interface/UI Zum User Interface gehören in dem Fall auch Visual Design, Interaction Design. Die UIElemente werden nach dem Atomic Design Prinzip aufgebaut. Sie sind relevant für die Frontend-Ausgabe, für die Formular-Elemente im Backend und für die (Preview-) Darstellung der Inhalte im Backend. Visual Design und individuelles Styling wird über einen „Living Styleguide“ beschrieben, der stets aktuell gehalten wird. Das UI und die UIElemente für das Backend werden generisch vorbereitet. Die UI-Elemente und Bibliotheken können sukzessive ergänzt werden. Prozesse und Workflows (Regeln). Sie definieren – nach dem „If This Then That“-Prinzip – wie Inhalte zusammenhängen oder sich ändern können, wenn ein Ereignis eintritt oder eine Veränderung stattfindet. Es handelt sich dabei um die Definition einer regelbasierten Interaktion zweier Objekte untereinander. Schnittstellen Das Konzept der originären App mit eigenständigem Inhalt wird abgelöst vom Konzept der App als ein Content-Lieferant. Dieser stellt (in kleine Einheiten zerlegte) Inhalte über eine Schnittstelle anderen Diensten zur Verfügung (Schätzle, 2015a) – innerhalb der InhaltsBausteine im Content Hub und von und zu anderen Applikation, um die Inhalte/Daten auszutauschen bzw. zu synchronisieren.

76

Wolfram Nagel

Baukastenprinzip Modularer Ansatz: Atomic Design und Content Modeling Struktur und Modularität Apps und Websites sind zukünftig weniger autarke Einheiten, sondern eher aus unterschiedlichsten Modulen bestehende Systeme. Dieser Aspekt wird vor allem wichtiger, wenn sich Smart Watches im Windschatten der Apple Watch stärker verbreiten. Eine Information setzt sich strukturell aus einzelnen Elementen zusammen. Je nach Plattform, Zielkanal und Kontext werden die entsprechenden Elemente angezeigt. Diese Zusammensetzung beschreibt Brad Frost im User Interface Design Kontext mit Atomic Design (Frost, 2013a). Auf dem gleichen Prinzip basierend lässt sich auch Inhalt atomar aufbauen, man könnte von „Atomic Content“ sprechen.22 Mit Atomic Design werden ähnlich wie in der Chemie (daher die Atom-Metapher) WebProjekte in kleinstmögliche Bausteine zerlegt. Diese Bausteine werden anschließend zu größeren Einheiten (vgl. Moleküle oder Organismen) bis hin zu kompletten Seiten kombiniert. Beim Content Modeling (Gibbon, 2015 und Lovinger, 2012) werden – basierend auf dem Inhaltskonzept – Inhaltsmodelle erstellt, die strukturierten Inhalt (Structred Content) in Form von Inhaltstypen (Content Types), einzelnen Attributen und Datentypen und deren Beziehung untereinander beschreiben. Um Inhalt zu strukturieren, muss man die Inhaltstypen kennen und natürlich auch den Themenbereich, um den es sich handelt, weil dieser die Struktur und die Semantik entscheidend beeinflusst. Gut strukturierter modularer Inhalt lässt sich auch als Rich Snippets für die Suchmaschinenoptimierung einsetzen. Diese Elemente werden in den Suchergebnissen angezeigt. Das sind beispielsweise Qualitätsbewertungen wie sie bei Focus-Online-Artikeln angezeigt werden oder bei Rezepten Bilder, Kalorienangaben, Kochzeiten und Zutaten. Atomic Design und Content Modeling sind vergleichbar mit dem Lego-System oder ähnlichen Prinzipien. Ihnen gemein ist Modularität und strukturierter Aufbau der einzelnen „Bauteile“. Vorbild: Atomic Design und LEGO Das Ziel der von mir vorgestellten Baukasten-Überlegungen ist es alle Elemente ähnlich zu strukturieren und dafür ein gemeinsames verständliches und allgemeingültiges Wording für

22

Andere gängige Begriffe sind Structured Content, Future Friendly Content, Intelligent Content, Adaptive Content oder Smart Content.

Content Design und UI Architektur für Multiscreen-Projekte

77

alle Projektbeteiligten zu finden, weil die Metapher „Atom“ unter Umständen schwer vermittelbar oder irritierend sein könnte. Beim Atomic Design und Content Modeling werden einzelne Elemente (oder Bausteine) LEGO-ähnlich nach dem Baukastenprinzip zusammengesetzt. Da sich auch Workflows und andere Bereiche nach diesem Prinzip konzipieren und realisieren lassen, setze ich ein einheitliches Wording angelehnt an das Content Modeling ein.

UI und Content Inventory (und Audit) Um zu wissen mit welchen visuellen und inhaltlichen Bausteinen es man in einem Projekt zu tun hat, empfiehlt es sich in einer frühen Projektphase eine Analyse der bestehenden und zukünftig zu verwendenden Elemente durchzuführen. Mit einem Content Inventory (oder Audit) wird untersucht, welche Arten von Inhalt aus welchem Themenbereich verwendet werden und wie diese Inhalte und Inhaltsmodelle strukturiert sind (Baldwin, 2010). Welche Inhaltselemente sind erforderlich, um mit dem zu publizierenden Inhalt alle aktuell bekannten und ggf. zukünftig relevanten Kanäle mit adäquatem Inhalt zu versorgen. Entsprechend ähnlich untersucht und definiert man mit einem UI Inventory welche UI Elemente in einem Projekt verwendet werden (sollen) (Frost, 2013b). Nach der Inventur folgt das Modellieren der Bestandteile.

Modellieren nach dem Baukastenprinzip Wenn die Inhalte und deren potentielle strukturelle und visuelle Ausprägung bekannt sind, kann man sich an das Modellieren von Inhaltstypen und UI Typen machen. Diese Typen werden stufenweise aufgebaut, beginnend mit dem kleinstmöglichen Bauteil.

78

Wolfram Nagel

Abbildung 2 (Matrix): Inhalte und User Interface lassen sich modular strukturiert aufbauen – vergleichbar mit den Bausteinen des LEGO-Baukastensystems. Die fünfte Stufe (konkrete Ausprägung) kommt beim Rezipienten an.

Generisches 5-Stufiges Baukasten-Model (Matrix) Die einzelnen (atomaren) Elemente bzw. Bausteine bauen aufeinander auf und lassen sich flexibel zu einem Model zusammensetzen. Jedes Model lässt sich 5-stufig aufbauen. Vom kleinstmöglichen Element über das generische Template bis zum realen, einmaligen Objekt (individuelles Unikat). Die Begriffe aus der Chemie-Metapher lassen sich durch allgemeingültige generische Begriffe ersetzen: Atom = Element / Molekül = Komponente oder Modul / Organismus = Segment / Template oder Typ (generisch) / Instanz oder Objekt (konkret). Modulare Baukastenprinzipien gibt es auch in anderen Bereichen. Ob ich nun ein LEGO Produkt zusammensetze, mit Hilfe eines Konfigurators meinen nächsten Neuwagenkauf plane oder die im Kühlschrank vorhandenen Zutaten zu einem schmackhaften Gericht kombinieren möchte – alles lässt sich aufteilen, konfigurieren und kombinieren.

Korrelation zwischen Inhalt und UI Es besteht eine Korrelation der Elemente in Atomic Design und Content Modeling, das bedeutet zwischen den einzelnen Inhaltselementen und deren Darstellung im Zielkanal oder verwendeten Medium des Rezipienten. Wenn ich Inhalt modelliere, definiere ich damit quasi indirekt auch gleich das zugehörige UI-Element in generischer Form (Wireframe-artig / ohne Visual Design). Wenn man den Inhaltstyp definiert, legt man außerdem indirekt automatisch auch die entsprechenden Formular-Feld-Typen für das Eingabe-Interface fest. Mit dem

Content Design und UI Architektur für Multiscreen-Projekte

79

Eingabe-Interface werden die Inhalte erfasst. Im besten Fall (für den Erfasser) können das sehr beliebige bzw. die von ihm bevorzugten Systeme sein. Die erfassten Inhalts-Elemente müssen bei unterschiedlichen Systemen zur Struktur des Inhaltstyps passen, damit sie auf diesen gemappt werden können. Es ist bekannt, dass Inhalt und UI – also die Formatierung des Inhalts beim Rezipienten – strikt voneinander getrennt werden sollen. Dennoch stehen die Elemente in direktem Zusammenhang zueinander. UI Typen und Inhaltstypen korrelieren. Beim Rezipienten bzw. im jeweiligen Medium werden UI und Inhalt wieder zusammengefügt.

Universalität und Verständlichkeit Ich möchte den Bezug zwischen den verschiedenen strategischen und konzeptionellen Disziplinen im Bereich Inhalt und UI herstellen. Alles baut auf dem Baukastenprinzip auf und ist miteinander verknüpft. Spätestens beim Rezipieren der Informationen stehen UI und Inhalt in direktem Zusammenhang. Der Nutzer konsumiert Inhalt und UI nämlich in kombinierter Form. Die Korrelation besteht außerdem auch zwischen UI, Inhalt und Workflows. Schnittstellen bilden die Brücke beispielsweise um Inhalte zu synchronisieren oder zwischen Systemen auszutauschen. Das Prinzip soll stets verwendet werden können (egal ob es sich um Atome, UI, Layout, Inhalt oder irgendetwas anderes handelt). Mit der vorgestellten Korrelationsmatrix möchte ich diese generischen und allgemeinverständlichen Muster erklären und auf alle Bereiche anwendbar halten. Die 5-Stufigkeit und der Atomic Design Ansatz sind kein Dogma. In einem Kundenprojekt haben wir einen Living Styleguide nach dem Atomic Design Prinzip aufgebaut und davor noch eine zusätzliche Ebene zur Definition von Basiselementen wie Grid, Farben, Typografie und Interactive States eingeführt. Kleinstmögliche, nicht weiter unterteilbare Elemente sollten in der untersten Ebene definiert werden.

Prozesse und Tools Wenn man den atomaren Ansatz wählt und nach und nach mit den aufeinander aufbauenden kleinsten Elementen – den Atomen – beginnt, erhält man erst spät im Projektverlauf vorzeigbare Seiten. Voraussetzung dafür ist, dass Moodboards, Scribbles oder PhotoshopScreens, die die Visual Design Richtung andeuten und aus meiner Sicht immer noch eine Berechtigung haben, zur Abstimmung anfangs ausreichen. Je weiter das Projekt fortgeschritten ist, desto mehr amortisieren sich die anfangs höheren Aufwände zum Projektstart (Schätzle, 2015b).

Methodisches Vorgehen Die Disziplinen UI und Content Modeling, Visual Design und Multiscreen Konzeption werden sich zukünftig noch stärker überschneiden. Projekte werden komplexer, alle

80

Wolfram Nagel

Disziplinen und Themenbereiche müssen zur richtigen Zeit berücksichtigt und bearbeitet werden. Im Projektverlauf müssen (kompakt formuliert) nacheinander und iterierend das Thema erkannt, priorisierte Ausgabekanäle und die Inhaltsmodelle definiert werden. Ausgehend vom Inhalt lassen sich weitere Details festlegen und bearbeiten (Struktur, Content Wireframes, Inhaltserfassung, Schnittstellen). Wenn diese Parameter bekannt sind, können unter Berücksichtigung des Baukastenprinzips Workflows modelliert und Ausgabe Interfaces bestimmt und gestaltet werden. Da sich alles um den Inhalt dreht, könnte ein zentraler Content (Management) Hub den erwähnten Gedanken Rechnung tragen.

Zentraler Content (Management) Hub Das Konzept basiert auf der bereits erwähnten Vierteilung der Projektbestandteile Inhalt, UI, Workflows und Schnittstellen. Der Content Editor (also der Nutzer der Software) steht dabei im Vordergrund. Die Datenstruktur für das Backend wird entsprechend der Inhaltsmodelle definiert. Das Editor Interface besteht aus einem auf der Datenstruktur basierenden Formular. Im zentralen Content Hub können die Inhalte konsolidiert abgelegt und verwaltet werden. Das Inhaltsmodell definiert das UI Modell. Wenn am Anfang ein Content Audit durchgeführt und anschließend die Inhaltsmodelle erstellt werden, lassen sich daraus die passenden UI Formular-Elemente für das Backend (und die UI Elemente für das Frontend) ableiten. Durch die Korrelation von Inhalt und UI definiert das Inhaltsmodell im Grunde auch schon das Backend und die Frontendausgabe. Themenrelevanz Das (Projekt) Thema ist relevant bzgl. Begrifflichkeit für das Inhaltselement und das Labeling im Backend bzw. dem Interface für die Erfassung und Verwaltung der Inhalte (Unit, Domäne, Taxonomie). Es ist ein Unterschied, ob es sich um Kochrezepte, technische Produkte, Restaurants, geschäftliche Adressdaten oder einen Urlaubsantrag handelt. Auf Basis der jeweiligen Unit- oder Themen-spezifischen Inhaltsmodelle ergibt sich eine Art spezialisierter Content Manager passend zum definierten Anwendungsfall. Zu jedem definierten Inhaltstyp erhält der Anwender die korrelierenden UI-Formular-Elemente. Ein Inhaltsmodell für ein Kochbuch (Rezept) sieht deutlich anders aus als die Inhaltsmodelle für einen Produktkatalog mit E-Shop-Funktionalität, eine Kalenderapplikation oder eine klassische Nachrichtenpublikation. Mit einem Formulargenerator lassen sich die Formularelemente generisch nach dem Baukastenprinzip zum Eingabe-Interface kombinieren. Durch das Inhaltsmodell steht die vordefinierte Struktur des Formulars fest (atomare Korrelation von Inhalt, Backend-UI und Frontend-UI), könnte jedoch bei Bedarf um eigene Module und Templates erweitert werden.

Content Design und UI Architektur für Multiscreen-Projekte

81

Unabhängiges Eingabe-Interface Die Datenübernahme in den Hub kann grundsätzlich unabhängig vom Eingabe-Interface geschehen. Die Inhaltsobjekte müssen lediglich entsprechend konvertiert und den einzelnen Inhalts-Elementen zugeordnet werden (Content Mapping). Das grundsätzliche UI für das Eingabe-Interface ist durch die Strukturdefinition der Inhaltstypen festgelegt, nicht jedoch das exakte Styling (das ist flexibel). Zudem können eigene UI Elemente jederzeit ergänzt werden. Die Ausgabe ist davon ebenfalls unabhängig und kann in einem eigenen oder fremden Kanal erfolgen. Das Styling der Inhaltselemente im Frontend ist unabhängig vom Backend. Lediglich die Struktur (Chunks der Inhaltsobjekte, nicht deren Reihenfolge) ist vorgegeben. Der Ansichtsmodus im Backend ist „nur“ eine „Content Structure Preview“. Die Reihenfolge, Anordnung und Darstellung der InhaltsElemente geschieht im Client bzw. Ausgabemedium. Durch die klare Strukturierung und Gliederung der Inhaltstypen (konkrete gefüllte Inhaltstypen sind Inhaltsobjekte) sind die Daten grundsätzlich plattform- und touchpointunabhängig und können in beliebigen Ausgabemedien und Kanälen dargestellt werden. Die Ausgabe wird im Backend konfiguriert (über Regeln bzgl. der jeweiligen Nutzungskontexte, die wiederum Vorgaben bzgl. Kanal, Layout und Medium und auch Interaktion beinhalten). Dreistufiger Content Hub ¥ Der Content Hub ist dreistufig aufgebaut [vgl. drei Phasen in Abb. 1]. Man kann Inhalte erstellen, erfassen und ausgeben, wo und womit man möchte. Für die Ausgabe ist eine entsprechende Schnittstelle erforderlich (also z.B. Inhaltserfassung im Formular des Content Hubs und Ausgabe in Wordpress, Flipboard oder jedem anderen Kanal). Es ist auch denkbar Inhalte in einem beliebigen System zu erfassen (Step 1) und diese nach dem Mapping des Inhalts im Content Hub (Step 2) wiederum flexibel auszugeben (Step 3).

Eine Modeling-Software passend zum Baukastenprinzip. SETU als Tool für zukunftsfähigen Inhalt Basierend auf den vorgestellten Ideen haben wir bei der SETU GmbH ein Konzept für einen solchen „Content Management Hub“ entwickelt, das wir momentan in unser ab Ende des Jahres verfügbares SETU 3.0 Release einfließen lassen. Damit lassen sich Content Management Apps für verschiedene Themenschwerpunkte (Units) realisieren. Der Content Architekt hat weitgehend freie Hand bei der Strukturierung von Datenkörpern. Die Software bietet eine große Bibliothek an vordefinierten (und erweiterbaren) Formularund Ausgabeelementen und unterstützt innerhalb eines Datenmodells iterierende Elemente (auch komplexere Strukturen wie Text mit Bild) sowie Beziehungen und Beziehungsarten zu anderen Elementen. Es bietet Funktionen für die Erstellung und Verwaltung von Sprach- und Marktspezifischen Inhalten wie Vererbung und Workflow Unterstützung.

82

Wolfram Nagel

Außerdem lassen sich regelbasierte und verknüpfte/verwandte und individuell personalisierte kontextbasierte Inhalte bereitstellen. Die abgegebenen strukturierten Informationen lassen sich in beliebige Plattformen und Kanälen integrieren.

Quo vadis Inhalt und Interface? Für die Zukunft empfiehlt es sich Informationen in jeglicher Ausprägung baukastenartig zu planen und zu erfassen, um mit den richtigen Tools möglichst ohne große Zusatzaufwände Informationen auf allen erdenklichen Kanälen publizieren zu können. Die passenden Prinzipien, Methoden und Prozesse sollten verständlich beschrieben, etabliert und angewandt werden. Aus dieser Überzeugung heraus zerlege ich sämtliche Projektbestandteile in generische Einzelteile, die sich später leicht zusammensetzen lassen. Ganz ähnlich wie man das von LEGO kennt. Literatur Baldwin, S. (2010). Doing a content audit or inventory. http://nform.com/blog/2010/01/doing-acontent-audit-or-inventory/ (14.04.2015) Frost, Brad (2012). BDConf: Stephen Hay presents Responsive Design Workflow. http://bradfrost.com/blog/mobile/bdconf-stephen-hay-presents-responsive-design-workflow/ (03.02.2015) Frost, Brad (2013a). Atomic Design. http://bradfrost.com/blog/post/atomic-web-design/ (14.05.2015) Frost, Brad (2013b). Interface Inventory. http://bradfrost.com/blog/post/interface-inventory/ (07.01.2015) Frost, Brad (2015). I Have No Idea What The Hell I Am Doing. http://bradfrost.com/blog/post/i-haveno-idea-what-the-hell-i-am-doing/ (03.06.2015) Gibbon, C. (2015). Cleve Gibbon Website: Content Modeling. http://www.clevegibbon.com/contentmodeling/ (04.02.2015) Lovinger, R. (2012). A List Apart. Content Modelling: A Master Skill. http://alistapart.com/article/content-modelling-a-master-skill (11.02.2015) Nagel, W. (2014a). Next Generation Information Experience: Trends und Herausforderungen von morgen. https://wolframnagel.wordpress.com/2014/12/09/next-generation-information-experiencetrends-und-herausforderungen-von-morgen/ Nagel, W. (2014b). Next Generation Information Experience: Trends und Herausforderungen von morgen. EXD Prozess. https://wolframnagel.wordpress.com/2014/12/09/next-generationinformation-experience-trends-und-herausforderungen-von-morgen/#EXD_Prozess (13.04.2015) Nagel, W., Fischer V. (2013). Multiscreen Experience Design. Prinzipien und Muster für die Strategieenwticklung und Konzeption digitaler Services für verschiedene Endgeräte. Schwäbisch Gmünd. digiparden GmbH. Schätzle, A. (2015a). Modulare Systeme. In: PAGE Ausgabe 02.15. S. 24f

Content Design und UI Architektur für Multiscreen-Projekte Schätzle, A. (2015b). Im Teilchenbeschleuniger. In: PAGE Ausgabe 06.15. S. 82ff Skjoldan, R. (2013). Editor Experience Design. http://rasmusskjoldan.com/post/64666373967/editorexperience-design (05.11.2013)

83

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 84- 94.

User Experience in Kanban Case Study: Erfahrungen aus dem Relaunch eines Internetportals Jan Uhlenbrok, Eva-Maria Schön, Dominique Winter, Jörg Thomaschewski

Jan Uhlenbrok

Eva-Maria Schön

Dominique Winter

Jörg Thomaschewski

basecom GmbH & Co. KG Hannoversche Straße 6–8 49084 Osnabrück [email protected] Buhl Data Service GmbH Am Siebertsweiher 3/5 57290 Neunkirchen [email protected]

CGI Deutschland Ltd. & Co. KG Am Sandtorkai 72 20457 Hamburg [email protected] Hochschule Emden/Leer Constantiaplatz 4 26723 Emden [email protected]

Abstract Kanban ist eine agile Projektmanagementmethode, die auf geringe Durchlaufzeiten während des Entwicklungsprozesses abzielt. Bereits im Jahre 2013 haben wir uns mit der Herausforderung beschäftigt, wie eine Integration von Human-Centered Design in Kanban gestaltet werden kann. Ein wesentlicher Punkt dabei ist es, einen Gesamtüberblick über die zu bearbeitenden Aufgaben zu erhalten. Hierzu haben wir verschiedene Methoden vorgestellt, welche den Kanban-Prozess um Human-Centered Design Aktivitäten erweitern. In einer Case Study zum Relaunch eines Internetportals wurden die Methoden im interdisziplinären Team produktiv eingesetzt, um ein Produkt mit positiver User Experience zu entwickeln. Nach Abschluss des Projektes wurden Interviews mit den Projektbeteiligten durchgeführt, Ergebnisse zusammengefasst sowie Vor- und Nachteile herausgearbeitet.

Keywords Human-Centered Design, User Experience, Kanban, Agile Development, Case Study

User Experience in Kanban

85

Einleitung In der heutigen Zeit setzen zunehmend mehr Unternehmen Kanban für die Entwicklung digitaler Produkte ein. „Kanban und Design Thinking haben in den letzten zweieinhalb Jahren eine deutlich höhere Wachstumsrate an Nutzern erfahren als agile Methoden insgesamt“ (Komus et al. 2014). Im direkten Vergleich der Studienergebnisse Status Quo Agile 2012 (Komus 2012) und 2014 (Komus et al. 2014) wird deutlich, dass Kanban zunehmend an Bedeutung gewinnt. Während 2012 noch 24,04% der Teilnehmer angaben, dass Kanban keine Bedeutung für sie habe, reduzierte sich diese Zahl innerhalb von nur zwei Jahren auf unter 16,52%. Gleichzeitig stieg der Anteil der Teilnehmer, für die Kanban eine zentrale Bedeutung hat, um 3,57%. Die Methode Kanban hat ihren Ursprung in der Automobilbranche bei Toyota. Damit beste Qualität mit niedrigen Kosten und einer möglichst kurzen Durchlaufzeit erzielt werden kann, wird von einer monotonen Arbeitsteilung abgesehen und der Fokus auf den Fluss des Produktes durch den gesamten Produktionsprozess gelegt (Leopold & Kaltenecker 2012). Die Methode ist von Anderson (Anderson 2011) mit einigen Anpassungen für die IT übernommen worden. IT-Organisationen setzen Kanban für das Projektmanagement im Rahmen der agilen Softwareentwicklung ein. Bei Kanban für die IT liegt der Fokus auf der aktuell zu erledigenden Aufgabe. Dabei wird die Wertschöpfungskette des zu entwickelnden Produktes mit Hilfe eines Kanban-Boards (vgl. Abbildung 1) visualisiert.

Abbildung 1: Beispiel Kanban-Board

Kanban zeichnet sich durch drei wichtige Bestandteile aus, hierzu zählen: Visualisierung des Workflows, Limit für Work in Progress (WIP) und Lead Time bzw. Cycle Time (Kniberg & Skarin 2010). Die Visualisierung des Workflows erfolgt in Kanban über ein Kanban-Board. Die einzelnen Spalten zeigen dabei die Aktivitäten der Wertschöpfungskette, welche eine Aufgabe durchlaufen muss, bevor sie erledigt ist. WIP beschreibt die Anzahl an Aufgaben, die zeitgleich mit den vorhandenen Mitarbeitern bearbeitet werden können. Jede Spalte hat

86

Jan Uhlenbrok, Eva-Maria Schön, Dominique Winter, Jörg Thomaschewski

ihr eigenes WIP-Limit (siehe in Abbildung 1, die beispielhaften Zahlen in der obersten Zeile). Wenn das WIP-Limit überschritten wird, entsteht ein Engpass, der den Aufgabenfluss unterbricht. Die Cycle Time konkretisiert die Zeit, die eine Aufgabe benötigt, bis sie fertig gestellt ist (Kniberg & Skarin 2010). Hierzu muss die Aufgabe alle Schritte der Wertschöpfungskette durchlaufen haben. Die im Kanban-Prozess entstehende Fokussierung auf kleinteilige Aufgaben hat den Nachteil, dass die Gesamtbetrachtung des Produktes eingeschränkt wird. Diese Gesamtbetrachtung ist jedoch notwendig für die Entwicklung eines Produktes mit einer positiven User Experience (UX), da beispielsweise nur hierdurch eine sinnvolle Informationsarchitektur erstellt werden kann. Aus diesem Grund stehen Unternehmen vor der Herausforderung Human-Centered Design (HCD) (Deutsches Institut für Normung 2011) in den Entwicklungsprozess mit Kanban zu integrieren. Eine mögliche Lösung hierfür stellt die von Winter et al. (Winter et al. 2013) vorgestellte Kombination verschiedener Methoden zur Erweiterung des Kanban-Prozesses um HCD-Aktivitäten dar.

Integration von UX in Kanban Damit der HCD-Prozess in Kanban abgebildet werden kann, erfolgt eine entsprechende Gestaltung der Wertschöpfungskette. Hierzu ist es sinnvoll, konzeptionelle Aufgaben wie beispielsweise Analyse des Nutzungskontexts, Festlegen von Nutzungsanforderungen und Erarbeitung von Gestaltungslösungen zu berücksichtigen. Zudem sollte die Evaluation fest im Prozess verankert werden. Winter et al. (Winter et al. 2013) nehmen für die Umsetzung zum einen Änderungen am Prozess sowie eine Anpassung des Kanban-Boards vor, zum anderen führen sie UX-Artefakte (Persona Stories, Prototypen) ein.

Prozesserweiterung mit Konzeptionsboard Ein Kanban-Board bildet in vielen Fällen die Wertschöpfungskette des Software Engineerings ab (vgl. Abbildung 1). Dabei werden konzeptionelle Aufgaben oftmals vernachlässigt, die für eine erfolgreiche Umsetzung der nutzerzentrierten Gestaltung jedoch maßgeblich sind. Damit die konzeptionellen Aufgaben im Kanban-Prozess aufgenommen werden, wird der Prozess nach vorne um ein Konzeptionsboard (vgl. Abbildung 2) erweitert. Das bestehende Kanban-Board der Umsetzung bleibt dabei unberührt. Somit können die konzeptionellen Aufgaben in gleicher Weise wie die Programmieraufgaben organisiert werden.

User Experience in Kanban

87

Abbildung 2: Verwendetes Konzeptionsboard

Interdisziplinäre Zusammenarbeit Agile Entwicklungsprozesse leben von der Zusammenarbeit verschiedener Disziplinen (Beck et al. 2001). Wenn Experten einer Fachrichtung eng zusammenarbeiten und ein geringer Austausch mit anderen Fachrichtungen stattfindet, können sich funktionale Silos bilden. Diese Bildung kann durch eine interdisziplinäre Zusammenarbeit vermieden werden. Beispielsweise können Konzeptions- und Entwicklungsteams ein gemeinsames Daily Standup ausführen. Hierfür kann das Konzeptionsboard in sichtbarer Nähe zum Entwicklungsboard angebracht werden. Durch den Austausch werden zum einen Engpässe abteilungsübergreifend sichtbar und zum anderen können unterschiedliche Sichtweisen auf ein Problem in den Entwicklungsprozess einfließen.

Release Evaluation Ziel einer Release Evaluation ist es, die nutzerbezogenen Produkteigenschaften in regelmäßigen Abständen hinsichtlich ihrer User Experience zu testen. Die resultierenden Optimierungen können als neue Aufgaben in den Kanban-Prozess eingeplant werden. Damit die Release Evaluation in regelmäßigen Abständen stattfindet, wird auch für die letzte Spalte („Done“) des Kanban-Boards ein WIP-Limit eingeführt. Wenn das WIP-Limit erreicht ist, werden entsprechende UX-Tests durchgeführt.

Verwendung von UX-Artefakten Damit die am Prozess beteiligten Menschen eine einheitliche Sprache verwenden und eine gemeinsame Vision vom Produkt teilen, ist es wichtig mit den gleichen Artefakten zu

88

Jan Uhlenbrok, Eva-Maria Schön, Dominique Winter, Jörg Thomaschewski

arbeiten. In agilen Produktentwicklungsprozessen haben sich hierzu Personas, Persona Stories und Prototypen bewährt (Winter et al. 2013). ¥ Personas repräsentieren den Nutzer während des Entwicklungsprozesses und unterstützen dabei, dass alle Stakeholder ein gemeinsames Verständnis vom Nutzer und seinen Bedürfnissen erhalten (Cooper 1999; Holt et al. 2011; Nielsen 2013;). ¥ Zur Abgrenzung des Produktumfangs werden in agilen Entwicklungsprozessen häufig User Stories eingesetzt (Cohn 2004; Wirdemann 2011). Persona Stories (Hudson 2013) (auch: Persona-driven User Stories Reichelt 2010; Winter et al. 2012; Holt et al. 2012) sind eine spezielle Form von User Stories, bei denen Personas anstatt von Rollen verwendet werden. Dies hat den Vorteil, dass eine Integration der Personas im gesamten Entwicklungsprozess erfolgt. ¥ Prototypen visualisieren komplexe Zusammenhänge einzelner Anforderungen (Rudd et al. 1996). Sie ermöglichen es zu lernen, zu entdecken, Ideen zu generieren und zu verfeinern (Lim et al. 2008). Mit ihrer Hilfe kann überprüft werden, ob das konzeptuelle Modell des Produktes mit den Annahmen über das mentale Modell der Nutzer übereinstimmt.

Case Study In den Jahren 2013/2014 wurde die zuvor beschriebene Integration von UX in Kanban im Rahmen eines Projektes eingesetzt. Basierend auf (Winter et al. 2013) sind für die Durchführung der Case Study vier Forschungsfragen formuliert worden. RQ1: Welche Vorteile bringt der Einsatz eines Konzeptionsboards in Kanban? RQ2: Wie hat sich die interdisziplinäre Zusammenarbeit gestaltet? RQ3: Wie wurde die Release Evaluation durchgeführt? RQ4: Wie sind die UX-Artefakte integriert worden?

Projektbeschreibung Das Projekt wurde mit einem zwölfköpfigen Team (Teamleiter, Projektmanager, zwei Grafikern, zwei UX-Experten und sechs Entwickler) als Teilprojekt im Rahmen eines Relaunch eines Internetportals innerhalb von sechs Monaten in 2013/2014 durchgeführt. Im Rahmen des Projektes wurde in einer IT-Organisation, die bereits mit Kanban arbeitete, ein Konzeptionsboard eingeführt. Dieses wurde dem bestehenden Entwicklungsboard vorgelagert, so wie bei Winter et al. (Winter et al. 2013) beschrieben. Aufgrund der Größe des Projektteams wurden damit die nötigen Strukturen für den teamübergreifenden Austausch geschaffen, um die Bildung von funktionalen Silos zu verhindern.

User Experience in Kanban

89

Für die letzte Spalte des Konzeptionsboards wurde ein WIP-Limit eingeführt. Sobald dieses erreicht wurde, ist eine Release Evaluation durchgeführt worden. Bereits nach einigen Wochen hatte sich die letzte Spalte des Entwicklungsboards gefüllt, so dass eine erste Release Evaluation durchgeführt wurde. Die Schwere der dabei erkannten UX-Probleme wurde von einem UX-Experten bewertet. Schnell umsetzbare Anpassungen (< 30 Minuten) wurden gemeinsam mit dem Entwickler sofort vorgenommen. Andere Aufgaben wurden dafür unterbrochen. Dieses Vorgehen wurde eingesetzt um Release-Zusagen einzuhalten. War das UX-Problem schwerwiegend, wurde im Konzeptionsboard eine neue Aufgabe erstellt, um das Problem vollumfänglich zu lösen. Auf die Verwendung von Persona Stories wurde verzichtet, da sich die Nutzung von Personas zum Projektzeitpunkt noch nicht etabliert hatte. Es wurden stattdessen einfache User-Stories eingesetzt. Für komplexere Anforderungen wurden entsprechende Prototypen erstellt, die in der Spalte „Testing“ des Konzeptionsboards (vgl. Abbildung 2) ihre Anwendung fanden.

Datenerhebung und Analyse Für die Erhebung aussagekräftiger Daten wurden mit sechs Projektteilnehmern qualitative Telefon-Interviews durch einen neutralen Interviewer (unternehmensextern) durchgeführt. Diese dauerten zwischen 20 und 25 Minuten. In den Interviews wurden die Befragten gebeten, ihre eigene Sicht auf den Prozess zu äußern und eine Einschätzung bezüglich Vorund Nachteilen dieses Vorgehens zu nennen. Abschließend sollten die Befragten ihre Einschätzung der Usability und User Experience des Projektergebnisses äußern und beantworten in welcher Form sich dieses mit durch das sonst übliche Vorgehen erzeugten Projektergebnissen unterschied. Die Telefoninterviews wurden 12 Monate nach Projektabschluss durchgeführt. Das aus dem Projekt entstandene Internetportal hatte sich somit vor der Durchführung der Interviews etabliert.

Ergebnisse Die Erkenntnisse aus der Case Study liefern wichtige Hinweise zum Einsatz in der Praxis. Im Folgenden werden die Ergebnisse im Hinblick auf die Forschungsfragen diskutiert. Die Aussagen aus den einzelnen Interviews werden hierzu anonymisiert dargestellt (I1-I6).

Welche Vorteile bringt der Einsatz eines Konzeptionsboards in Kanban? ¥ Vorteile vorgelagerte Konzeption: erste Anlaufstelle für Anforderungen, gleiche Anforderungen können gleiche Lösung verwenden (I1) ¥ Zuvor sind Anforderungen eher unstrukturiert in das Produkt eingeflossen (I1)

90

Jan Uhlenbrok, Eva-Maria Schön, Dominique Winter, Jörg Thomaschewski

¥ Zuvor viele Konzepter, die gleichzeitig Anforderungen gestellt haben, jetzt bündeln Konzepter Anforderungen und es erfolgt eine bessere Kommunikation (I5) ¥ Produktverantwortliche und Konzepter haben Entwicklern viel Chaos erspart (I6) ¥ Konzeptionsboard für Entwickler nicht sichtbar (I2) ¥ Konzeptionsarbeit war während des Projektes nicht sichtbar, erst das Ergebnis (I5)

Wie hat sich die interdisziplinäre Zusammenarbeit gestaltet? ¥ Hohe Umsetzungsgeschwindigkeit: enge Zusammenarbeit zwischen Entwickler und Konzepter war notwendig, sonst hätte das Projekt 4-5 Monate länger gedauert (I3) ¥ Zuvor fehlende Verzahnung (räumliche Trennung) führte zu mehr Rückfragen (I3) ¥ Konzeptionsarbeit war während des Projektes nicht sichtbar, erst das Ergebnis (I5) ¥ Entwickler bekommen ein besseres Gefühl für die Anforderungen (I2) ¥ Herausforderung beim Daily Standup: Waage zwischen oberflächliche Betrachtung und detaillierte Diskussion halten (I3)

Gemeinsame Daily Standup positiv

Gemeinsame Daily Standup negativ:

Transparenz bzgl. der Arbeit anderer (I1), (I2), (I5) Eigene Arbeit konnte daraufhin besser abgestimmt werden (I1) Guter Gesamtüberblick: Jeder bekommt Gefühl, wo Projekt gerade steht (I1) Fördert Kommunikation und Übersicht (I4) Zum Teil die Arbeit von Konzeptern mitbekommen (I4) Persönliches Stresslevel war geringer, da die Kommunikation verbessert wurde (I4) Kurze Wege zu Konzeptern (I4) Nachfrage in Gruppe während kritischer Phasen oder Neuerungen (I5) Vorerfahrungen anderer bzgl. komplexer Aufgaben konnte im Team geteilt werden (I2) Für Entwickler interessant zu sehen, wo die Reise hingeht (aus Usability-Sicht) (I2)

Uhrzeit und Regelmäßigkeit waren eine Umstellung (I1) Durch Größe des Teams oftmals 15 min. überzogen (I1), (I6) Es ist blöd, wenn man aus der eigenen Arbeit gerissen wird (I4)

Tabelle 1: Wahrnehmung vom Daily Standup

User Experience in Kanban

91

Wie wurde die Release Evaluation durchgeführt? ¥ Einschätzung der Usability aus Sicht der Projektteilnehmer gut, jeder ist mit Ergebnis zufrieden (I1-I6) ¥ Zuwachs bzgl. Unique User und Nutzungszahlen (I6) ¥ Für Zeit und Aufwand ist Ergebnis der Usability sehr gut (I4)

Wie sind die UX-Artefakte integriert worden? ¥ Hohe Anzahl an Konzepten ist sehr gut im Ergebnis (I3) ¥ User Stories kamen aus der Konzeption (I5)

Weitere Erkenntnisse ¥ Hohe Effizienz (I1) ¥ Fokus auf die eigene Arbeit (I1) ¥ gut zu wissen, dass ein Prozess dahinter steckt, mit Vor- und Nachfolger zur eigenen Position (I1) ¥ Kanban sehr positiv, da klares Ablaufschema vorhanden (I4) ¥ Kanban im Vergleich zu Scrum performanter (weniger Organisatorisches) (I3) ¥ Sehr organisiert im Vergleich zu anderen Projekten ohne agiles Vorgehen (I2) ¥ Usability: Bisher nicht mit so hoher Genauigkeit und Geschwindigkeit umgesetzt (I3) ¥ Struktur und Disziplin werden benötigt (I4) ¥ Im Anschluss an das Projekt können Informationen verloren gehen (I5) ¥ Mit üblichen Prozess hätte Projekt länger gedauert, Fülle an Funktionen wäre nicht lieferbar (I5) ¥ Wohl gefühlt, da Anzahl an Aufgaben gut strukturiert (I5) ¥ Hohe Wertschätzung der eigenen Person (I6) ¥ Planning Poker hat Spaß gemacht und das Ergebnis des Mittelwertes war gut (I2) Aus einer Retrospektive mit dem UX-Verantwortlichen gehen weitere Erkenntnisse hervor. Insgesamt konnte bei den Stakeholdern durch die Integration von UX-Experten in den Entwicklungsprozess ein besseres Verständnis für den HCD-Prozess herbeigeführt werden. Zudem wurde das Bewusstsein für die Wichtigkeit eines eigenen, kleinen UX-Teams gestärkt. Weiterhin konnte durch die direkte Zusammenarbeit die Entstehung von funktionalen Silos vermieden werden. Darüber hinaus schärfte die interdisziplinäre

92

Jan Uhlenbrok, Eva-Maria Schön, Dominique Winter, Jörg Thomaschewski

Zusammenarbeit das Bewusstsein für die Usability bei allen Beteiligten nachhaltig. In aktuellen Projekten äußert sich dies, indem eine gute Bedienbarkeit viel häufiger Gesprächsthema bei den Entwicklern ist. Die Entwickler gehen mit Detailfragen aktiv auf die UX-Experten und Grafiker zu, um eine gemeinsame Lösung zu finden. Ein weiteres Ergebnis stellt ein bestehender Werkzeugkasten an UI-Elementen dar. Die einzelnen UI-Elemente wurden bezüglich ihrer Eignung im Projekt vom UX-Experten überprüft. Durch diesen Werkzeugkasten an UI-Elementen konnte das Konzeptionsteam nachhaltig entlastet und die Konsistenz der Interaktionselemente vereinheitlicht werden. Die UI-Elemente des Werkzeugkastens werden im aktuell laufenden Betrieb bei kleineren Änderungen vom Entwickler-Team teilweise selbstständig genutzt. Hieraus ergeben sich drei Vorteile: (a) durch die selbständige Verwendung erhalten die Entwickler die Sicherheit auch unter Zeitstress noch immer möglichst passende UI-Elemente zu verwenden, (b) das Konzeptionsteam wird entlastet und (c) die Entwickler haben aufgrund des besseren Verständnisses für den HCD-Prozess und kennen den UX-Experten, so wie der UX-Experte das Projekt kennt. Bis zum jetzigen Zeitpunkt weist das Internetportal eine vergleichsweise hohe UX und Usability auf, was durch Aussagen von Nutzern und Redakteuren des Internetportals bestätigt wird. Die Anzahl von Nutzerfragen (z.B. „Finde ich ...?“ oder „Wie funktioniert ...?“) ist zurückgegangen, was eine Entlastung des Supports zur Folge hat.

Zusammenfassung und Ausblick In der durchgeführten Case Study zum Relaunch eines Internetportals wurden die Methoden zur Integration von HCD in Kanban eingesetzt. Zusammenfassend kann festgehalten werden, dass die Anforderungen durch das vorgelagerte Konzeptionsboard strukturierter in den Entwicklungsprozess eingeflossen sind. Zudem können die konzeptionellen Aufgaben in gleicher Weise wie die Programmieraufgaben organisiert werden. Das gemeinsame Daily Standup sorgt für eine bessere Transparenz bzgl. des Fortschritts und verkürzt die Abstimmungsprozesse zwischen Konzeptern und Entwicklern. Insgesamt bestätigten alle interviewten Projektteilnehmer, dass das Internetportal ein sehr gutes Ergebnis hinsichtlich der wahrgenommenen Usability aufweist. Die Anzahl der erwarteten UX-Probleme hat sich nach subjektiven Empfinden der Stakeholder verringert. Dies lässt sich auf den Einsatz der Prototypen und deren regelmäßiger Verbesserung zurückzuführen. Der entstandene UIWerkzeugkasten wird bis zum jetzigen Zeitpunkt eingesetzt. Auf Basis der Erkenntnisse lassen sich Empfehlungen für die Optimierung des Vorgehens formulieren. Das Konzeptionsboard war für einige Entwickler nicht sichtbar, da es aufgrund organisatorischer Rahmenbedingungen nicht direkt neben dem Entwicklungsboard platziert werden konnte. Zukünftig kann die Transparenz hinsichtlich der konzeptionellen Aufgaben gesteigert werden, indem das Konzeptionsboard direkt neben dem Entwicklungsboard platziert wird. Aufgrund der großen Teilnehmerzahl während des Daily Standups war die Einhaltung der gesetzten Timebox (15 min.) oftmals nicht möglich. Damit die Timebox

User Experience in Kanban

93

zukünftig eingehalten werden kann, ist es sinnvoll einen Verantwortlichen zu benennen (vgl. Scrum Master in Scrum, Sutherland & Schwaber 2013). Aus den Interviews geht zudem der Wunsch hervor, dass die Frequenz der Daily Standups und die Größe des Teilnehmerkreises verringert werden sollte, um die Effizienz zu steigern (vgl. I6). Literatur Anderson, D. J. (2011). Kanban. Evolutionäres Change Management für IT-Organisationen (1st. ed.). Heidelberg, Neckar: dpunkt. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for Agile Software Development (2001). Cohn, M. (2004). User stories applied. For agile software development. Boston, Mass: AddisonWesley. Cooper, A. (1999). The inmates are running the asylum. Indianapolis, Ind: Sams. DIN EN ISO 9241-210 (2011). Ergonomie der Mensch-System-Interaktion - Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme. Beuth, Berlin. Holt, E.-M., Winter, D. & Thomaschewski, J. (2011). Personas als Werkzeug in modernen Softwareprojekten. Die Humanisierung des Anwenders. In Usability Professionals 2011, Stuttgart, 40–44. Holt, E.-M., Winter, D. & Thomaschewski, J. (2012). Von der Idee zum Prototypen. Werkzeuge für die agile Welt. In Usability Professionals 2012. German UPA e.V., Stuttgart. Hudson, W. (201)3. User stories don't help users. Interactions 20, 6 (2013), 50–53. Kniberg, H. & Skarin, M. (2010). Kanban and Scrum. Making the most of both. C4Media, Inc. Komus, A. (2012). Studie: Status Quo Agile. Verbreitung und Nutzen agiler Methoden from www.status-quo-agile.de/ Komus, A., Kuberg, M., Atinc, C., Franner, L., Friedrich, F., Lang, T., Makarova, A., Reimer, D. & Pabst, J. (2014). Status Quo Agile 2014. Zweite Studie zu Verbreitung und Nutzen agiler Methoden. Leopold, K. & Kaltenecker, S. (2012). Kanban in der IT. Eine Kultur der kontinuierlichen Verbesserung schaffen. München: Hanser. Lim, Y.-K., Stolterman, E. & Tenenberg, J. (2008). The anatomy of prototypes. Prototypes as Filters, Prototypes as Manifestations of Design Ideas. ACM Trans. Comput.-Hum. Interact. 15, 2 (2008), 1–27. Nielsen, L. (2013). Personas from www.interaction-design.org/encyclopedia/personas.html Reichelt, L. (2010). Persona driven user stories for Agile UX. from www.disambiguity.com/personadriven-user-stories-for-agile-ux/ Rudd, J., Stern, K. & Isensee, S. (1996). Low vs. high-fidelity prototyping debate. Interactions 3, 1 (1996), 76–85. Sutherland, J. & Schwaber, K. (2013). The Scrum Guide. The Definitive Guide to Scrum : The Rules of the Game from www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf

94

Jan Uhlenbrok, Eva-Maria Schön, Dominique Winter, Jörg Thomaschewski

Winter, D., Holt, E.-M. & Thomaschewski, J. (2012). Persona driven agile development. Build up a vision with personas, sketches and persona driven user stories. Proceedings of the 7th Conference on Information Systems and Technologies (CISTI) (2012). Winter, D., Schön, E.-M., Uhlenbrok, J. & Thomaschewski, J. (2013). User Experience in Kanban. Die UX-Karte ausspielen. In Usability Professionals 2013. German UPA e.V., Stuttgart, 220–224. Wirdemann, R. (2011). Scrum mit User Stories (2nd. ed.). München: Hanser, Carl.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 95- 105.

Doppelt hält besser Mit UUX-Best-Practices agile Projekte zum Erfolg führen Hartmut Schmitt, Dominik Pascal Magin, Steffen Hess, Dominik Rost

Hartmut Schmitt

Dominik Pascal Magin

Steffen Hess

Dominik Rost

HK Business Solutions GmbH Mellinweg 20 66280 Sulzbach [email protected] Fraunhofer IESE Fraunhofer-Platz 1 67663 Kaiserslautern [email protected]

Fraunhofer IESE Fraunhofer-Platz 1 67663 Kaiserslautern [email protected] Fraunhofer IESE Fraunhofer-Platz 1 67663 Kaiserslautern [email protected]

Abstract Gerade wegen ihrer Kundennähe, Prozesseffizienz und des flexiblen Reagierens auf Anforderungen erfreuen sich agile Entwicklungsvorgehen einer großen Beliebtheit. Agile Entwicklungsmethoden fokussieren meist auf funktionale Korrektheit. Daher bedarf es zur Erreichung nichtfunktionaler Produktqualitäten wie Gebrauchstauglichkeit oder Nutzungsqualität in agilen Projekten entweder sehr viel Erfahrung oder einer zusätzlichen Hilfestellung. Das Forschungsprojekt PQ4Agile erarbeitet eine effiziente und systematische Unterstützung agiler Teams bei der Durchführung von Usability- und User-Experience(UUX)-Aktivitäten (sog. Best Practices). Hierfür werden klassische UUX-Methoden an agile Entwicklungsvorgehen angepasst, aber auch neue, erfolgversprechende Ansätze entwickelt. Zwei neu erarbeitete UUX-Best-Practices stellen wir in diesem Beitrag im Detail vor.

Keywords Best Practices, Agile Entwicklung, Scrum, Software-Engineering-Methoden

Motivation Agile Softwareentwicklung ist zum führenden Entwicklungsansatz in vielen Domänen und Unternehmen geworden (Komus 2012). Angesichts der unbestreitbaren Vorteile agiler Vorgehen ist dies nicht verwunderlich: schnelles und stetiges Ausliefern nutzbarer (Teil)Funktionalitäten durch kurze Entwicklungszyklen, Kundenzufriedenheit durch enge

96

Hartmut Schmitt, Dominik Pascal Magin, Steffen Hess, Dominik Rost

Interaktion und kontinuierliche Anpassung der Anforderungen und Zufriedenheit der Entwickler durch eigenverantwortliches und selbstbestimmtes Handeln sind Ziele, die zahlreiche Unternehmen erreichen wollen. In der Vergangenheit gab es viele Diskussionen darüber, ob konzeptionelle Tätigkeiten wie Usability- und User-Experience(UUX)-Engineering Platz in agilen Entwicklungsprozessen haben und ob es hier nicht eine grundsätzliche Inkompatibilität gibt. Diese Diskussionen sind mittlerweile mehrheitlich vorüber: Ein Framework wie Scrum (Schwaber & Sutherland 2013) bietet mit Aktivitäten wie Sprint Planning, Daily Scrum und Sprint Review systematische Unterstützung beim Projektmanagement, agile Techniken wie Pair Programming, Test Driven Development und Refactoring tragen zu einer effektiven Implementierungsarbeit bei. Eine Unterstützung zur systematischen Erreichung von Produktqualitäten wie Gebrauchstauglichkeit oder Nutzungsqualität fehlt jedoch gänzlich. In Projektsituationen mit in der Domäne und Technologie erfahrenen Entwicklern und einem System von übersichtlicher Größe und Lebenszyklus wird dieser Mangel durch die Erfahrung des Teams kompensiert. In allen anderen Situationen sind jedoch häufig frühe Qualitätsmängel die Folge, die durch aufwendige Nacharbeiten behoben werden müssen. Folglich hat sich die Auffassung durchgesetzt, dass nicht-triviale Projektsituationen zusätzliche, dedizierte Engineering-Aktivitäten erfordern und dass es sich dabei keineswegs um einen Widerspruch handelt. Wie jedoch die Integration von UUX-Engineering in agiler Entwicklung zu gestalten ist, ist noch immer eine offene Frage.

Lösungsidee Viele UUX-Techniken – z. B. die Durchführung von kontextuellen Benutzerinterviews, die Verwendung von Usability-Patterns oder Usability-Inspektionen – bieten genau diese erwünschte, zusätzliche Unterstützung zur systematischen Erreichung von Usability und User Experience. Solche Techniken wurden vielfach in der Praxis eingesetzt, sind empirisch validiert und werden kontinuierlich weiterentwickelt. Um diese gewinnbringend in agilen Entwicklungsprojekten einsetzen zu können, müssen sie jedoch auf die Spezifika von agilen Prozessen wie kurze Iterationszyklen oder enge Interaktion mit Stakeholdern angepasst werden. Unsere Kernidee ist es, etablierte und zusammenhängende Methoden des UUX-Engineering in einzelne Bausteine zu zerlegen, die von Entwicklern in agilen Entwicklungsprojekten selbstbestimmt ausgewählt und effizient eingesetzt werden können – ohne die Notwendigkeit, den Entwicklungsprozess gänzlich umgestalten zu müssen. Um dies zu erreichen, entwickeln wir Best Practices, mit denen agile Entwicklungsprozesse angereichert werden können. Das Forschungsprojekt PQ4Agile bietet uns dafür den entsprechenden Rahmen. Dabei haben wir nicht nur Aktivitäten aus dem UUX-Bereich sondern auch aus dem Requirements Engineering und der Softwarearchitektur im Blick (Schmitt & Rost 2015). Abbildung 1 visualisiert diese Idee.

Doppelt hält besser

97

Abbildung 1: Kernidee – Erweiterung von agilen Entwicklungsprozessen mit Best Practices

Das Ergebnis des Projektes ist ein Kompendium mit Software-Engineering-Best-Practices aus den Bereichen UUX, Requirements Engineering und Softwarearchitektur. Aus diesem Kompendium können sich Entwickler nach Bedarf die vielversprechendsten Best Practices für ihr agiles Entwicklungsprojekt auswählen. Wir haben sieben Prinzipien definiert, denen die Best Practices folgen sollen, damit sie kompatibel zu agiler Entwicklung sind: Minimalismus/Simplizität: Eine Software-Engineering-Aktivität soll nur so umfangreich ausgeführt und deren Ergebnisse nur so umfangreich dokumentiert werden, wie durch die gegebene Projektsituation notwendig ist, damit eine effiziente Weiterbearbeitung und Wartung möglich wird. Personennähe: Die Verfügbarkeit und enge Zusammenarbeit mit Stakeholdern des Kunden und von Teammitgliedern untereinander soll durch Software-Engineering-Aktivitäten genutzt werden können. Artefaktnähe: Software-Engineering-Artefakte sollen so produziert und verfügbar gemacht werden, dass sie möglichst effizient von Nachfolgetätigkeiten verwendet werden können und möglichst nahe am Zielprodukt sind. Timing: Software-Engineering-Aktivitäten sollen immer genau bzw. spätestens dann ausgeführt werden, wenn es für den Projektfortschritt am nützlichsten und effizientesten ist. Skalierbarkeit: Bei einer Zunahme von Projektfaktoren wie Stakeholdern, Systemkomplexität oder Teamgröße müssen Software-Engineering-Aktivitäten weiterhin so ausführbar sein, dass sie nicht den Grundprinzipien von agilen Vorgehen widersprechen und dennoch genügend Unterstützung zur Erreichung von Qualitätsattributen bieten. Änderungsaffinität: Häufige Änderungen werden von agilen Vorgehen als essentieller Teil der Projektdurchführung gesehen. Software-Engineering-Aktivitäten sollen Änderungen ebenso begreifen und Änderungen, die die Bereiche User Experience Engineering, Requirements Engineering und Softwarearchitektur betreffen, effizient ermöglichen und Stakeholder dabei unterstützen. Integrierbarkeit: Die Software-Engineering-Aktivitäten müssen so beschaffen sein, dass sie eine möglichst nahtlose Integration in bestehende agile Entwicklungsprozesse erlauben.

98

Hartmut Schmitt, Dominik Pascal Magin, Steffen Hess, Dominik Rost

PQ4Agile – Produktqualität für Agile Softwareentwicklung Seit November 2013 widmet sich das Forschungsprojekt „PQ4Agile – Produktqualität für Agile Softwareentwicklung“ der Aufgabe, die in der Lösungsidee beschrieben ist. Wichtigstes Ziel des Projekts ist die Erstellung von Software-Engineering-Best-Practices, die agile Entwickler bei der Erreichung nichtfunktionaler Qualitätsmerkmale unterstützen sollen – möglichst effektiv, mit wenig Aufwand und idealerweise ohne dass für die Anwendung der Best Practices Expertenkenntnisse notwendig sind. Als Basis für die Arbeiten in PQ4Agile haben wir zunächst ein Qualitätsmodell entwickelt, das ein gemeinsames Qualitätsverständnis für agile Ansätze und empirisches Software Engineering schafft. Dieses Qualitätsmodell deckt alle für PQ4Agile relevanten Qualitätskriterien ab: die funktionalen und nichtfunktionalen Anforderungen an das Softwareprodukt (Bereich Softwarequalität), die Aktivitäten des Entwicklungsprozesses (Bereich Prozessqualität) sowie strukturelle Aspekte im Unternehmen (Bereich Strukturqualität). Für jeden dieser drei Bereiche diente ein bestehendes Qualitätsmodell als Grundlage: das Modell der ISO 25010 (ISO/IEC 25010:2011-3) für den Bereich Softwarequalität, das Modell „Gokyo Ri“ (Kneuper 2014) für den Bereich Prozessqualität und das Modell der ISO 9001 (DIN EN ISO 9001:2008) für den Bereich Strukturqualität. Im nächsten Schritt haben wir untersucht, welche Anknüpfungspunkte geeignet sind, um die Best Practices in beliebige agile Entwicklungsprozesse zu integrieren. Da Prozessanpassungen vermieden werden sollen, mussten möglichst allgemeingültige und generalisierbare Anknüpfungspunkte identifiziert werden. Hierzu wurden das ScrumFramework, das CMMI-DEV-Modell (CMMI Product Team 2011), verschiedene Prozesse aus der Software-Engineering-Literatur sowie die Entwicklungsprozesse der an PQ4Agile beteiligten Softwareunternehmen analysiert. Ergebnis ist ein agiler Referenzprozess, dessen 22 Aktivitäten (z. B. „Lösungskonzept entwickeln“, „Oberflächenentwurf erstellen“, „Prototypen erstellen“ und „Reviews durchführen“) als Anknüpfungspunkte für die Best Practices geeignet sind. Dieser Referenzprozess ist in sechs Bereiche unterteilt: „Anforderungen“, „Planung und Design“, „Evaluation“, „Realisierung“, „Kontrolle“ sowie „Projektplanung und -steuerung“. Die Bereiche und die in ihnen enthaltenen Aktivitäten werden während des Entwicklungsprozesses in der Regel iterativ ausgeführt.

Entwicklung und Dokumentation der Best Practices Ziel des Projekts PQ4Agile ist es, ein Kompendium von Best Practices zu schaffen, das für agile Entwickler möglichst effizient nutzbar ist und eine umfassende Unterstützung in allen relevanten Qualitätsbereichen bietet. Zudem sollen die Entwickler möglichst bei allen relevanten Aktivitäten, die im Referenzprozess beschrieben sind, eine Hilfestellung in Form von Best Practices erhalten. Um die erarbeiteten Best Practices in geeigneter Form dokumentieren zu können, wurde ein generisches Beschreibungstemplate entwickelt, das ein

Doppelt hält besser

99

Mapping der Best Practices mit den Qualitätsaspekten des Qualitätsmodell und den Aktivitäten des Referenzprozesses erlaubt. Alle Best Practices wurden so ausgestaltet und dokumentiert, dass für die Anwendung keine aufwändigen Prozessanpassungen notwendig sind; hierdurch soll die Hürde zur Anwendung der Best Practices bewusst niedrig gehalten werden. Aus dem UUX-Bereich haben wir mehr als 130 etablierte Methoden und Praktiken untersucht. Nach der Bereinigung von Dubletten und einer ersten Vorauswahl verblieben circa 25 erfolgversprechende Kandidaten für die weitere Ausarbeitung (z. B. „Kontextuelles Benutzerinterview durchführen“, „Personas erstellen“, „Informationsarchitektur erstellen“, „Usability-Review durchführen“ und „Usability-Test durchführen“). Diese Praktiken haben wir bei Bedarf angepasst, so dass sie relativ leicht in agile Prozesse integriert werden können und auch von Usability-Novizen angewendet werden können. Berücksichtigt wurden aber auch erfolgversprechende neue Ansätze der Projektpartner, die zu einer Steigerung der Produktqualität in agilen Prozessen beitragen sollen. Außerdem fanden aktuelle Vorschläge aus der Usability-Community Eingang. Beispielsweise haben wir im Rahmen der Konferenz Usability Professionals 2014 den Workshop „UX4Agile – Integration von Best Practices des Usability- und User-ExperienceEngineering in agile Entwicklungsprozesse“ (Hess et al. 2014) durchgeführt. Hier haben wir gemeinsam mit den Teilnehmern untersucht, welche Best Practices des UsabilityEngineerings heute bereits erfolgreich in agilen Projekten eingesetzt werden. Zudem haben wir in dem Workshop erarbeitet, welche Defizite und Herausforderungen in Bezug auf UUXAktivitäten in agilen Entwicklungsprozessen momentan bestehen und wie wir durch pragmatischere Vorgehensweisen und eine stärkere Einbindung der Entwickler Verbesserungen herbeiführen können (vgl. Abbildung 2). Auf diese Weise wurde wertvolles Feedback gewonnen, das sowohl bei der Anpassung etablierter UUX-Aktivitäten als auch der Beschreibung neuartiger Best Practices (z. B. „Usability-Patterns verwenden“) zum Tragen kam.

Abbildung 2: UX4Agile – Workshopergebnisse

100

Hartmut Schmitt, Dominik Pascal Magin, Steffen Hess, Dominik Rost

Best-Practice-Beispiele Wie oben dargestellt haben wir im Zuge von PQ4Agile existierende Best Practices angepasst und basierend auf den Erfahrungen der Projektpartner neue Best Practices entwickelt. Im Folgenden werden zwei neue UUX-Best-Practices vorgestellt.

„Templatebasierte UI-Gestaltung“ Das Aussehen der Benutzungsoberfläche (engl.: user interface, kurz: UI) einer Softwareanwendung unterliegt während der Entwicklung häufigen Änderungen, die prototypisch skizziert und als ausführbarer Code implementiert werden. Diese Änderungen haben nicht nur Einfluss auf einzelne Teile des UIs, sondern können Auswirkungen auf das komplette UI-Konzept haben. Konsistente Änderungen sind in der Regel sehr zeitintensiv und fehleranfällig, da diese Änderungen in allen betroffenen Artefakten nachgezogen werden müssen. Es muss nicht nur eine potenziell große Anzahl an Prototypen angepasst werden, sondern es müssen auch viele Änderungen am bereits implementierten Code vorgenommen werden. Eine Verfolgbarkeit von prototypisch skizzierten UI-Elementen zu deren Umsetzung im Code und die Verfolgung von Änderungen innerhalb von Prototypen über die Zeit hinweg sind dabei üblicherweise nicht möglich oder werden vernachlässigt. Eine schnelle und konsistente Umsetzung von Änderungswünschen bezüglich des UI-Designs ist dadurch nur schwer möglich. Die Best Practice „Template-basierte UI-Gestaltung“ dient der Erstellung und Verwendung von Vorlagen, die bei der Gestaltung der Benutzeroberfläche zum Einsatz kommen. Diese Vorlagen definieren das Grundgerüst einer Anwendung durch instanziierbare UI-Elemente, die innerhalb der Anwendung verwendet werden, z. B. Schaltflächen, Tabellen, Header und Navigationsmenüs. Hierbei wird eine hierarchische Struktur dieser Elemente festgelegt, zum einen um die Zuordnung einzelner Elemente zu übergeordneten Elementen zu kennen, zum anderen um die Einflüsse von Änderungen bestimmter Elemente auf untergeordnete, von ihnen abhängige Elemente von vornherein festzulegen und zu kennen. Weiterhin werden sämtliche Attribute (vgl. Abbildung 3: Content Area) jedes einzelnen Elements spezifiziert, damit bei dessen Implementierung keine unterspezifizierten oder nichtspezifizierten Aspekte auftreten. Abbildung 3 zeigt ein Template vom Aufbau einer Webanwendung.

Doppelt hält besser

101

Abbildung 3: Template einer Webanwendung

Sämtliche Dialoge der entwickelten Anwendung werden unter ausschließlicher Verwendung dieser Vorlagen gestaltet. Ähnlich einem Styleguide können somit die Elemente für ein einzelnes Projekt, für eine bestimmte Produktlinie oder für das gesamte Unternehmen spezifiziert werden. Dadurch wird nicht nur die Erstellung konsistenter Prototypen erleichtert, sondern es wird zugleich die Nachverfolgbarkeit von prototypisch instanziierten UI-Elementen zu ausführbarem Code ermöglicht. Abbildung 4 zeigt eine konkrete Instanz des in Abbildung 3 dargestellten Templates. Da die Erstellung einer Hierarchie der UIElemente zunächst zeitaufwändig ist, eignet sich diese Best Practice vor allem für größere Entwicklungsprojekte mit mehr als zwanzig verschiedenen Templates. Auch wenn die Vorteile der Best Practice bereits in kleinen Entwicklungsprojekten greifen, könnte der Aufwand für die Erstellung der UI-Element-Hierarchie hier in einem ungünstigen Verhältnis zu dem dadurch erzeugten Nutzen stehen, da ein beträchtlicher Teil des Gesamtbudgets in die Erstellung der Hierarchie fließen könnte. Das Nachziehen von Änderungen und die damit verbundene konsistente Gestaltung von Prototypen sind in kleinen Entwicklungsprojekten noch relativ einfach manuell durchzuführen. In großen Entwicklungsprojekten hingegen ist der Einsatz der Best Practice sehr viel gewinnbringender, da hier nicht nur mit einer wesentlich höheren Anzahl verwendeter UI-Elemente zu rechnen ist, sondern durch die

102

Hartmut Schmitt, Dominik Pascal Magin, Steffen Hess, Dominik Rost

größere Anzahl erstellter Prototypen und die größere Menge implementierten Codes eine Nachverfolgung von Änderungen sowie eine konsistente Erstellung von Prototypen schwerer möglich ist.

Abbildung 4: konkrete Instanz eines Templates

„Produktphilosophie erstellen“ Die Best Practice „Produktphilosophie erstellen“ unterstützt die Definition und Bewertung der User Experience einer Softwareanwendung. Sie wird im Rahmen agiler Projekte hauptsächlich zur Entscheidungsunterstützung bzw. Priorisierung durch das Team bzw. den Product Owner verwendet. Dabei wird insbesondere der Trade-off zwischen funktionalen Features und User-Experience-Features aufgelöst. Abbildung 5 zeigt das Mobile Template der Produktphilosophie, bei dem es vordefinierte Attribute gibt, auf die man sich in den ersten Sprints einigt. Dahinter steckt jeweils eine Erklärung der Bewertung bzw. die Unterstützung durch Beispiele. Die Wertepaare und die Bewertung geben hierbei an, welchen Eindruck die Software vermittelt bzw. vermitteln soll. Beispielsweise besagt die Produktphilosophie in Abbildung 5, dass das zu entwickelnde Produkt einem individuellen Look & Feel folgen soll. Dies bedeutet, dass es bei Entscheidungen hinsichtlich des

Doppelt hält besser

103

Interaktionskonzepts und der Benutzeroberfläche eher ein individuelles Look & Feel (z.B. Company CI/Guidelines) zu verfolgen gilt. Der Entwickler erhält so eine Idee, wie die genannten Aspekte zu berücksichtigen sind. Die Best Practice „Produktphilosophie erstellen“ verbessert die Kommunikation zwischen UI-Verantwortlichen, Vertrieb und Entwicklern. Insbesondere unterstützt sie Entwicklerteams dabei, systematisch eine spezifische User Experience in das fertige Produkt zu „injizieren“. Um dies zu erreichen, können z. B. einzelne User Stories auf die Attribute gemappt werden. Einen besonderen Nutzen erzielen Unternehmen, wenn sie die vorhandenen Templates vor der Verwendung auf ihre konkreten Bedürfnisse anpassen. Im Rahmen von PQ4Agile sollen verschiedene weitere Templates erstellt werden, die den unterschiedlichen Anwendungsarten (z. B. Mobile, Security, Software Renovation) gerecht werden.

Abbildung 5: Produktphilosophie Mobile Template

Ausblick Aktuell werden die entwickelten Best Practices in Pilotprojekten der PQ4Agile-Partner angewendet. Im weiteren Verlauf des Vorhabens wird empirisch überprüft, ob sich durch die Verwendung der Best Practices messbare Effekte, also Verbesserungen im Entwicklungsprozess und bei den resultierenden Softwareprodukten, einstellen. Im Zuge dieser Evaluation haben wir einen Fragebogen entwickelt, um die Qualität des Produkts und des Entwicklungsprozesses zu ermitteln. Es handelt sich bei den Evaluationsfragen um Items

104

Hartmut Schmitt, Dominik Pascal Magin, Steffen Hess, Dominik Rost

auf Basis von Standards (z. B. ISO 25010) und etablierten Theorien (z. B. Hassenzahl et al. 2003), die nach den drei Qualitätsbereichen (Softwarequalität, Prozessqualität, Strukturqualität) klassifiziert sind. Die Bewertung durch den Fragebogen erfolgt zu drei Zeitpunkten: vor Einführung der Best Practices, nach Einführung und Anwendung eines ersten Sets von Best Practices und zu Projektende, nach Einführung eines zweiten Sets von Best Practices. Somit können Einflüsse durch Anwendung der Best Practices auf die Produkt- und Prozessqualität festgestellt und der Wert der Best Practices bestimmt werden. Um die dokumentierten Best Practices einem möglichst großen Entwicklerkreis zugänglich zu machen, werden diese kostenlos und diskriminierungsfrei im Projektportal zur Verfügung gestellt. Unterstützend wird ein Wiki aufgebaut, in dem Softwareentwickler verschiedene Einstiegspunkte finden, um nach geeigneten Best Practices zu suchen (z. B. die Aktivitäten und Rollen des agilen Referenzprozesses oder die Qualitätsmerkmale und -teilmerkmale des Qualitätsmodells). Die Entwickler werden damit in die Lage versetzt, verschiedene Best Practices für ihre eigenen Entwicklungsprojekte auszuwählen und ohne großen Aufwand auszuprobieren. Das Wiki soll zudem die Möglichkeit zum Erfahrungsaustausch und zur Diskussion der Best Practices bieten, so dass Erfahrungen, die Entwickler mit der Anwendung der Best Practices gemacht haben, in die Best Practices zurückgespiegelt werden können. Danksagung Das Projekt „PQ4Agile – Produktqualität für Agile Softwareentwicklung“ wird vom Bundesministerium für Bildung und Forschung im Rahmen der Maßnahme KMU-innovativ: IKT – Softwaresysteme und Wissenstechnologien gefördert. Mehr Informationen: www.pq4agile.de Literatur CMMI Product Team (2011): CMMI für Entwicklung, Version 1.3. Carnegie Mellon University, Pittsburgh DIN EN ISO 9001:2008 Qualitätsmanagementsysteme – Anforderungen. Beuth, Berlin. Hassenzahl, M., Burmester, M. & Koller, F. (2003): AttrakDiff: Ein Fragebogen zur Messung wahrgenommener hedonischer und pragmatischer Qualität. In J. Ziegler & G. Szwillus (Hrsg.): Mensch & Computer 2003: Interaktion in Bewegung, S. 187-196. Teubner, Stuttgart Hess, S., Rost, D. & Schmitt, H. (2014). UX4Agile – Integration von Best Practices des Usability- und User-Experience-Engineering in agile Entwicklungsprozesse. In: German UPA (Hrsg.): Tagungsband Usability Professionals 2014 ISO/IEC 25010:2011-3 Software-Engineering - Qualitätskriterien und Bewertung von Softwareprodukten (SQuaRE) – Qualitätsmodell und Leitlinien. Beuth, Berlin. Kneuper, R. (2014). Gokyo Ri: Messung und Bewertung von Prozessqualität. Verfügbar unter: http://www.kneuper.de/GokyoRi/ Komus, A. (2012). Studie: Status Quo Agile Verbreitung und Nutzen agiler Methoden. Ergebnisbericht (Langfassung). Hochschule Koblenz, Koblenz

Doppelt hält besser

105

Schmitt, H. & Rost, D. (2015). Qualitätssteigerung durch Best Practices. In: Software und Support Media GmbH (Hrsg.): Entwickler Magazin Ausgabe 2015 (2), S. 82-86. Software & Support, Frankfurt am Main Schwaber, K. & Sutherland, J. (2013). Scrum Guide - Der gültige Leitfaden für Scrum: Die Spielregeln. Verfügbar unter: http://www.scrumguides.org/download.html

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 106- 112.

Usability-Testing in agilen Entwicklungsprojekten Alexander Rösler, Michaela Thölke

Alexander Rösler

usability.de Plaza de Rosalia 4 30449 Hannover [email protected]

Michaela Thölke

usability.de Plaza de Rosalia 4 30449 Hannover [email protected]

Abstract Agile Softwareentwicklung ist heute in vielen Unternehmen angekommen. Statt lange zu planen und zu spezifizieren, sollen Anforderungen innerhalb kürzester Zeit in funktionierender Software aufgehen. Dies stellt Usability Dienstleister vor neue Herausforderungen. Die Durchführung eines klassischen Usability-Tests mit Erstellung eines Prototyps, Vorbereitung, Durchführung und schriftlicher Dokumentation dauert zu lang und wird den Anforderungen agiler Softwareentwicklung nicht gerecht. In einem Erfahrungsbericht aus zwei Projekten für den Energiekonzern RWE und das Expat Netzwerk InterNations berichten wir, wie wir durch ein neues schlankes Testing-Verfahren auch in agilen Projekten schnelles und gleichzeitig wertvolles Usability-Feedback liefern können.

Keywords Usability-Test, Agile Entwicklung

Einleitung Agile Softwareentwicklung ist heute in vielen Unternehmen angekommen. Statt lange zu planen und zu spezifizieren, sollen Anforderungen innerhalb kürzester Zeit in funktionierender Software aufgehen. Dies stellt Usability Dienstleister und In-House Usability Experten vor neue Herausforderungen. Der Projektplan sieht im Regelfall keine zweiwöchige Entwicklungspause für die Durchführung eines klassischen Usability-Tests mit Erstellung eines Prototyps, Vorbereitung, Durchführung und schriftlicher Dokumentation vor. Nach dem Motto fail fast, learn fast soll im Optimalfall innerhalb von 1-2 Tagen Usability-Feedback zum aktuellen Entwicklungsstand eingeholt werden, um direkt Optimierungen vornehmen zu können.

Usability-Testing in agilen Entwicklungsprojekten

107

Um auf diese neuen Anforderungen zu reagieren, haben wir bei usability.de ein neues schlankes Testing-Verfahren entwickelt. Im Kern setzt dieses Modell auf eine enge Zusammenarbeit mit den Stakeholdern auf Kundenseite. Statt als Dienstleister fertige Ergebnisse in Form eines ausführlichen Reports und eines Highlightvideos zu liefern, wird der Kunde direkt bei der Vorbereitung, Beobachtung und Auswertung mit einbezogen.

Best Practices Dies klingt im Prinzip erstmal ganz einfach und logisch. In der Praxis haben wir jedoch gelernt, dass es bei der Arbeitsteilung und Herangehensweise einige Dinge zu beachten gilt. In einem praktischen Erfahrungsbericht möchten wir unsere Learnings deshalb gerne teilen.

Wer übernimmt die Vorbereitung? In nicht agilen Testing Projekten achten wir darauf, dass die Vorbereitung und das Entwickeln von Szenarien immer auf unserer Seite liegen. Mit dem Kunden besprechen wir, welche Fragestellungen durch den Test beantwortet werden sollen und welche Hauptanwendungsfälle die Nutzer normalerweise mit der Anwendung verfolgen. Das eigentliche Ausformulieren nicht suggestiver, gut verständlicher Szenarien erfolgt dann aber durch uns als Usability-Experten. In agilen Testing Projekten funktioniert dies leider so nicht immer. Teilweise ist bis kurz vor dem Test noch unklar, welche Anwendungsbestandteile überhaupt funktionsfähig sein werden. Manchmal ändert sich sogar der Scope des Tests noch kurzfristig, weil sich neue Feature Wünsche ergeben. Um Kommunikationsaufwände gering zu halten und sicherzugehen, dass die Aufgaben später funktionieren, erarbeiten deshalb unsere Kunden Vorschläge für die Aufgabenszenarien. Achtung Falle! Als Usability-Experten wissen wir, wie schwierig es sein kann gute Szenarien zu entwickeln. Die Szenarien sollen leicht verständlich formuliert sein, den Nutzer zur Interaktion mit der Anwendung auffordern und trotzdem möglichst wenig von der Aufgabenlösung verraten. Ohne Coaching und Kontrolle geht es deshalb nicht. Wir briefen unsere Kunden deshalb detailliert, was es beim Schreiben von Szenarien zu beachten gilt. Grundsätzlich planen wir außerdem mindestens eine Feedbackschleife schon vor dem PreTest ein, um sicherzugehen, dass die Qualität der Szenarien stimmt. Die finale Qualitätskontrolle und Abnahme der Testszenarien liegt dann natürlich bei uns!

108

Alexander Rösler, Michaela Thölke

Wie geht man damit um, dass der Testgegenstand erst kurz vor dem Test fertiggestellt wird? Agile Softwareentwicklung ist im Optimalfall schnell. Statt monatelang an einem Konzept zu schreiben, um dann in das Design und die Entwicklung einzusteigen, entwickeln unsere Kunden innerhalb weniger Wochen Teile komplexer Anwendungen. Dies hat zur Folge, dass wir als Agentur oft erst wenige Tage bis Stunden vor der Testdurchführung den finalen Testgegenstand zur Verfügung gestellt bekommen. Achtung Falle! In der Vergangenheit führte das späte Liefern des Testgegenstands immer wieder zu Problemen. In einem Fall konnten wir die wesentliche Fragestellung des Kunden nicht beantworten, weil der Testgegenstand nicht ausreichend interaktiv war. So war es unter anderem ein Ziel, die Seitennavigation der Website zu testen, der Nutzer konnte jedoch nicht zwischen den verschiedenen Seitenteilen navigieren. In einem Fall wurde das Testergebnis durch den gelieferten Testgegenstand verzerrt. Ein Kalender Widget sollte getestet werden – das im Kalender zu findende Element wurde jedoch direkt beim Öffnen des Kalenders angezeigt (so dass natürlich jeder Teilnehmer „erfolgreich“ war). Um diese Probleme zu umgehen, empfehlen wir, die Szenarien für den Test bereits vor der Finalisierung des Testgegenstands (und häufig schon vor der Entwicklung) festzulegen. Durch die vorgegebenen Szenarien wird sehr klar was genau an Interaktivität für den Test vorhanden sein muss. Außerdem ist es uns wichtig, bereits früh in der Entwicklung mit einbezogen werden, so dass wir auf solche Probleme frühzeitig hinweisen können.

Wen genau lädt man zur Testdurchführung ein? Ganz einfach: Alle Personen, die an der Entwicklung beteiligt sind. Ziel ist es, das am nächsten Tag sofort mit den an der Software notwendigen Anpassungen begonnen werden kann. Dies ist nur möglich, wenn alle, die Anpassungen vornehmen sollen, informiert sind. Die Information erfolgt über die Teilnahme an den Tests (alle haben das Gleiche gesehen). Das Reporting beschränkt sich auf das Nötigste und dient dabei als Erinnerungsstütze. Das ist das Ziel. Die Realität sieht meist so aus, dass ein bis zwei feste Mitarbeiter aus dem Kundenprojektteam dabei sind und weitere Mitarbeiter nur einzelne Testsessions sehen (remote oder live). Bei der abschließenden Besprechung sollten dann aber möglichst alle dabei sein. Achtung Falle! Der Kunde denkt, es sei nicht notwendig an ALLEN Tests teilzunehmen. Besonders mit den wenigen Teilnehmern (wir beschränken uns oft auf einen Testtag) je Test in einem agilen Setting ist es jedoch wichtig, alle Tests zu sehen, um ein klares Gesamtbild zu erhalten. Sonst bleibt nur die Auswahl der gesehenen Tests im Gedächtnis, was zu einer

Usability-Testing in agilen Entwicklungsprojekten

109

verzerrten Wahrnehmung führen kann. Daher sollten ein bis zwei Mitarbeiter des Kunden fest dabei sein, damit ein klares Gesamtbild in das Unternehmen weitergetragen wird. Achtung Falle! Der Kunde denkt, die umzusetzende Agentur müsse nicht an den Test teilnehmen. Das kann klappen, kann aber dazu führen, dass die Agentur wichtige Findings nicht versteht oder nicht ernst genug nimmt. Da das Reporting sehr knapp ist, ist mehr Kommunikationsaufwand vom Kunden zu Agentur notwendig.

Wie genau bereitet man Kunden auf die Beobachtung der Testsessions vor? Generell empfehlen wir all unseren Kunden, bei Usability-Tests zuzuschauen. Der Kunde erlebt so einerseits aus erster Hand, welche Schwierigkeiten Nutzer bei der Lösung der Testaufgaben haben, andererseits ermöglicht uns die Anwesenheit des Kunden, mehr über den bisherigen Verlauf des Projekts und bisher getroffene Entscheidungen zu erfahren. Bei normalen Usability-Tests weisen wir unsere Kunden darauf hin, mehr auf das Verhalten zu achten als auf das gesprochene Wort und nicht nach der ersten Testperson bereits alle Schlüsse zu ziehen. Bei iterativen, agilen Tests genügt es nicht, wie bei normalen Tests, den Kunden auf die Beobachtung während der Tests hinzuweisen, sondern hier soll der Kunde aktiv mitarbeiten. Was heißt das? Da wir gemeinsam die beobachteten Probleme sammeln und beurteilen wollen, bitten wir jeden Projektbeteiligten während der Tests alle beobachteten Probleme schriftlich festzuhalten. Achtung Falle! Viele Beobachter neigen dazu, wirklich jede einzelne Bemerkung der Teilnehmer aufzuschreiben. Das führte zu Beginn oft zu langwierigen Nachbesprechungen der einzelnen Tests. Kunden fällt es oft schwer zwischen echten Usability-Problemen, generellem Feedback oder Wünschen für derzeit nicht vorhandene Features zu unterscheiden. Wesentliche Beobachtungen gehen dadurch vielleicht unter. Hier sollte man für die ersten Tests deutlich mehr als eine halbe Stunde für die Besprechung einplanen. Des Weiteren erklären wir schon vor der Durchführung des ersten Tests wie genau ein UsabilityProblem definiert ist. Achtung Falle! Anfangs haben wir die Kunden gebeten auf Post Its ihre Beobachtungen zu notieren (ein Problem je Post It). Inzwischen sind wir davon abgerückt, da die Masse an Post Its besprochen werden will. Zudem kann man ein Post It nicht einfach aussortieren (oder es erfordert einiges an Fingerspitzengefühl). Dazu später mehr!

110

Alexander Rösler, Michaela Thölke

Wie nimmt man Kunden bei der Auswertung der Testsessions vernünftig mit? Nach jedem Test haben wir eine Pause von mindestens 30 Minuten. Diese Pause dient normalerweise bei uns dazu, das Testsetting wiederherzustellen (z.B. Browser Cache leeren, andere Vorbereitungen zu absolvieren), einen Puffer zu haben (falls ein Teilnehmer zu spät oder zu früh kommt) und sich mit dem Kunden auszutauschen. Bei iterativen, agilen Tests besprechen wir in der Pause zusätzlich die Erkenntnisse aus dem letzten Test. Dazu versammelt sich das gesamte Projektteam im Beobachtungsraum, in den die Test Sessions per Livestream übertragen werden, zur Nachbesprechung. Mit Hilfe des Testleitfadens leitet der Moderator die Auswertung an. Chronologisch wird der Test von Anfang bis Ende besprochen und alle Teilnehmer dürfen ihre Beobachtungen teilen. Wenn ein Problem beobachtet wurde und sich die Runde einig ist, wird dieses auf einem Post-it festgehalten und an unsere Auswertungswand gehängt. Hilfreich ist es dabei, Probleme gleich nach Seitenbereichen zu clustern. Achtung! Falle Wie bereits im Abschnitt „Wie genau bereitet man die Kunden auf die Beobachtung der Testsettings vor“ beschrieben, erklären wir unseren Kunden anhand von Beispielen bereits vor den Tests, was Probleme, Wünsche, Beobachtungen und Lösungen sind. Wir hatten anfangs sehr mit der Fülle an beobachteten „Problemen“ zu kämpfen. Die Gruppe spielt sich aber sehr schnell ein. Um dies zu unterstützen, ist es sinnvoll aufeinanderfolgende Projekte mit den gleichen Consultants zu besetzen. Jedes Problem wird bei uns außerdem mit einem Schweregrad bewertet. Wie schwerwiegend war das Problem für den Nutzer? Hierfür haben wir Definitionen entwickelt, die vor der Auswertung erklärt werden. Diese Definitionen beschreiben eindeutig, wann genau ein Problem als kritisch und wann nur als geringfügig einzustufen ist. Achtung Falle: Analog zur Sammlung der Probleme haben wir zu Beginn auch die Schweregradbewertung gemeinsam mit dem Kunden vorgenommen („Was denkt ihr, wie bewertet ihr das Problem?“). Dies hat den Vorteil, dass der Kunde selbst darüber nachdenkt und auch mit der Bewertung konform geht. Andererseits hängen an der Beurteilung häufig auch andere projektrelevante Entscheidungen, wie z.B. ob ein Bereich ein erneutes Mal überarbeitet wird oder nicht. Insbesondere wenn die umsetzende Agentur ebenfalls anwesend ist, kann dies zu hitzigen Diskussionen führen. Eine objektive Beurteilung von Problemen fällt dann schwer. Deshalb sind wir inzwischen dazu übergegangen, dass wir als Experten die finale Entscheidung treffen, aber die Meinungen und Einschätzungen gern hören. Den Goldstandard bilden dabei unsere Schweregraddefinitionen.

Usability-Testing in agilen Entwicklungsprojekten

111

Wie genau werden die Testergebnisse und Lösungsvorschläge dokumentiert, um später schnell verwertbar zu sein? Bei normalen Tests erhält der Kunde bei uns ein ausführliches Reporting mit Problembeschreibung, Empfehlung zur Lösung der Probleme (Best Practice oder Wireframes), Screenshots, Highlightvideo usw. Das Erstellen dieses Ergebnisberichts dauert im Normalfall mehrere Tage. Ziel der agilen Tests ist es, dass der Kunde sofort weiter entwickeln kann. Alles Wissen dafür hat er durch die Beobachtung und Beteiligung an der Auswertung, trotzdem ist eine kleine Form der Dokumentation hilfreich, um sicherzustellen, dass auch alle Punkte beachtet und bearbeitet werden können. Wir führen dazu immer ein Debriefing durch: Nach dem letzten Test reservieren wir ein bis drei Stunden, um noch einmal die Probleme zusammenzufassen und dann auch das erste Mal über Lösungen zu sprechen. Dabei wird außerdem kurz mitprotokolliert: Problembeschreibung, Schweregrad, diskutierte Lösungen, evtl. eine Priorität. Außerdem fertigen wir Fotos der Post Its an. Achtung Falle! Oben ist natürlich der Idealfall beschrieben. In einem Konzern möchten natürlich auch andere Stakeholder wissen, wie der Test lief und dafür eignet sich o.g. Kurzdokumentation nur bedingt. Hier muss man in Absprache mit dem Kunden ggf. doch wieder auf das übliche Reporting zurückgreifen. Trotzdem sehen wir hier den Vorteil, dass die weitere Entwicklung dadurch nicht behindert wird (und der Report zur Formsache wird). Ähnliches gilt übrigens für das Highlightvideo: Wenn doch nicht alle Mitarbeiter zuschauen können, dann kann es hilfreich sein, wenigstens Eindrücke über die wichtigsten Erkenntnisse zu vermitteln. Statt eines langen Reports haben wir sehr gute Erfahrungen mit der Erstellung eines kurzen Highlightvideos gemacht. So kann man weitere Stakeholder auf Kundenseite schnell ins Thema holen.

Verlieren die Ergebnisse durch die Schnelligkeit des Verfahrens an Qualität? Uns ist es in jedem Projekt wichtig, den Kunden belastbare, nachvollziehbare und qualitativ hochwertige Ergebnisse zu liefern und wir haben uns natürlich auch gefragt, ob wir durch die Schnelligkeit des Verfahrens nicht an Qualität verlieren. Immerhin erhält der Kunde innerhalb von 1-2 Tagen die Ergebnisse seines Usability-Tests und nicht wie sonst üblich nach ca. einer Woche. Woran sparen wir und wie stellen wir sicher, dass dies keinen negativen Einfluss auf die Qualität hat?

112

Alexander Rösler, Michaela Thölke

Vorbereitungszeit: Der Kunde übernimmt einen Teil der Vorbereitung, aber wir führen eine Qualitätskontrolle durch und beraten bei der Erstellung der Szenarien. Das letzte Wort bei der Formulierung der Szenarien haben wir. Teilnehmerzahl: Statt den üblichen 8 Teilnehmern testen wir mit 5 Teilnehmern und können so auf einen Durchführungstag reduzieren. Durch iteratives Testen stellen wir sicher, dass wichtige Bereiche immer wieder überprüft werden (z.B. Startseite). Auswertungszeit: Statt die Auswertung nach den Tests durchzuführen, besprechen wir die Ergebnisse mit den Kunden gemeinsam zwischen den Tests. Durch die Beteiligung von zwei erfahrenen Usability Consultants stellen wir sicher, dass Ergebnisse korrekt interpretiert werden. Dokumentation: Die Hauptersparnis resultiert aus der reduzierten Dokumentation. Statt ausführlichem Reporting kommt hier lediglich ein kurzes Word-Dokument zum Einsatz. Da der Kunde jedoch alle Tests und Besprechungen erlebt hat und die Ergebnisse sofort in eine Umsetzung fließen, wird lediglich eine Erinnerungsstütze benötigt und keine Dokumentation, die auch für Unbeteiligte nachvollziehbar ist.

Fazit “Working software over comprehensive documentation.“ (Manifesto for Agile Software Development) Das Testsetting muss an die agile Herangehensweise angepasst werden. Vor allem die Beteiligung des Kunden am Prozess erfordert einige Vorbereitungen. Wenn die o.g. Fallen jedoch beachtet werden, stehen agile Testingprojekte in nichts den normal üblichen Usability-Tests nach. Agiles Testing eignet sich hervorragend in agilen Entwicklungsprojekten, wo nicht lange auf ausführliche Reports gewartet werden kann. Das Ziel ist in kürzester Zeit verwertbares Nutzerfeedback zu erhalten. Aus unserer Einschätzung heraus, ist die Qualität der Testergebnisse mit normalen Tests absolut vergleichbar. Sie hat sogar den Vorteil, dass der Kunde die Testergebnisse viel besser versteht, da er direkt bei der Ermittlung der Ergebnisse beteiligt war. Wichtig ist, den Kunden deutlich zu machen, wo die Zeiteinsparung herkommt: Wir sparen Dokumentationszeit, die der Kunde durch Anwesenheitszeiten und Mitarbeit kompensieren muss. Sprich: Wir verteilen die Aufwände nur anders. Unterm Strich bleibt der Aufwand der gleiche oder ist sogar höher (weil mehr Personen involviert sind).

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 113- 122.

3, 2, 1, meins! Analyse der Nutzerziele beim Onlineshopping mittels der "Mental Models"-Methode Nina Kolb, Sarah Diefenbach, Susanne Niklas

Nina Kolb

TU Darmstadt Forschungsgruppe Arbeits- und Ingenieurpsychologie (Projekt CASED) Alexanderstr. 10 64283 Darmstadt [email protected]

Sarah Diefenbach

LMU München Leopoldstr. 13 80802 München [email protected]

Susanne Niklas

eResult GmbH Uhlandstraße 58 60314 Frankfurt [email protected]

Abstract Welche Ziele verfolgen Konsumenten beim Onlineshopping: Schnell ein konkretes Produkt zu finden, zu stöbern oder vor allen Dingen sicher zu bezahlen? Und welche Bedürfnisse stehen dabei im Vordergrund – Unterhaltung, Selbstbestimmung oder soziale Interaktion? Eine Möglichkeit für die Untersuchung von User Experience und Nutzerverhalten mittels Feldforschung bietet die Methode „Mental Models“ von Indie Young (2008). Der Beitrag gibt eine allgemeine Einführung in die Methode und präsentiert Ergebnisse einer Analyse der Nutzerziele beim Onlineshopping. Neben Einsichten für die konsumentenorientierte Gestaltung von Onlineshops ergeben sich hieraus auch Ansätze für die Entwicklung neuer, innovativer Konzepte für das Onlineshopping. Spezifische Stärken und Potentiale sowie Limitationen der Methode „Mental Models“ werden diskutiert.

Keywords Onlineshopping, Mental Models, Konsumentenziele, Bedürfnisse, Interviews

Einleitung Mit zweistelligen jährlichen Wachstumsraten ist der Internethandel weiterhin auf dem Vormarsch: In Deutschland betrug der Umsatz aus online getätigten B2C-Verkäufen im Jahr

114

Nina Kolb, Sarah Diefenbach, Susanne Niklas

2013 z.B. 33 Milliarden Euro, über ein Drittel der deutschen Internetnutzer (37%) kaufte sogar mehrmals im Monat per Internet ein (Statista GmbH 2015). Im Jahr 2014 lag der Umsatz schon bei 39 Milliarden Euro (HDE 2015) und wird sich laut aktueller Prognosen in den folgenden Jahren weiterhin steigern (Heinick 2014). Angesichts dieser erfolgreichen Entwicklung überrascht es umso mehr, dass nach wie vor ein Großteil aller Onlinekäufe (rund 68%) von den Konsumenten abgebrochen wird (Appleseed & Holst 2013). In den meisten Fällen scheint das Problem darauf zurückzuführen sein, dass die Bedürfnisse der Konsumenten während des Einkaufsprozesses nicht oder nur unzureichend erfüllt werden (Nielsen 2000; Hausman & Siekpe 2009). Der Begriff Bedürfnis beschreibt hierbei einerseits den Wunsch nach dem Erreichen eines bestimmten Handlungszieles, wie beispielsweise die schnelle und mühelose Auswahl eines passenden Produkts, die Identifikation des günstigsten Onlineshops oder die Verwendung einer als sicher empfundenen Zahlungsmethode. Andererseits umfasst der Bedürfnisbegriff jedoch auch psychologische Bedürfnisse, deren Erfüllung während des Einkaufsprozesses von einigen Konsumenten abseits des Produkterwerbs verfolgt wird, wie z.B. das Verlangen nach Unterhaltung, Belohnung oder sozialer Interaktion (Arnold & Reynolds 2003). Der besseren Verständlichkeit halber wird im Folgenden für den zuerst beschriebenen Fall der Ausdruck Ziele verwendet, während Bedürfnisse im klassischen Sinn die zuletzt genannten „tieferliegenden“ Begehrlichkeiten beschreibt. Hierbei können durch Erreichen der Ziele auch die dahinterliegenden Bedürfnisse erfüllt werden. Während die Ziele und Bedürfnisse von Konsumenten bei Käufen im Laden bereits ausgiebig untersucht wurden (ein Überblick findet sich z.B. bei Ganesh et al. 2007), mangelt es bisher an Untersuchungen für den Kontext „Onlineshopping“. Die folgende Studie stellt daher eine Methode vor, die es ermöglicht zu identifizieren, welche Ziele Konsumenten während des Onlineshoppingprozesses verfolgen und welche Bedürfnisse dabei jeweils im Vordergrund stehen. Hierzu wurden auf Basis der Methode Mental Models von Indi Young (2008) ethnografische Interviews durchgeführt, deren Inhalte anschließend in einem Diagramm angeordnet wurden, das sämtliche Aktivitäten, Einstellungen, Wahrnehmungen und Gefühle umfasst, die für Konsumenten während des Onlineshoppings von Relevanz sind.

Die Methode Mental Models Die Methode Mental Models basiert auf der Erhebung und Auswertung ethnografischer Daten, d.h. Daten, welche mittels Feldforschung erhoben werden und Einblicke in das Verhalten spezifischer Nutzergruppen und somit auch das Verständnis dieses Verhaltens geben sollen. Der ethnografische Forschungsansatz ist daher gut dazu geeignet, eine umfassende Analyse des Nutzerverhaltens vorzunehmen und ermöglicht so die Berücksichtigung von Nutzeranforderungen bereits im Entwicklungsprozess. Gerade letzteres stellt einen maßgelblichen Erfolgsfaktor dar, denn die Einbindung des Nutzers und die Berücksichtigung von Nutzerbedürfnissen sind ein elementarer Bestandteil, um nicht am Nutzer (respektive Konsumenten) vorbei zu entwickeln. Die von vielen Produktentwicklern

3, 2, 1, meins!

115

klassischerweise durchgeführten Usability Tests stellen hingegen vor allem ein Werkzeug dar, um die technologische Umsetzung, deren Bedienbarkeit und das diesbezügliche Nutzungserleben, nicht jedoch um den Fokus der Anwendung selbst zu überprüfen. Eine hohe Usability nutzt jedoch nichts, wenn die entsprechende Webseite oder Anwendung die Ziele und Bedürfnisse der Nutzer nicht erfüllt, also überhaupt nicht gebraucht und somit nicht genutzt wird. Die Methode Mental Models von Indie Young (2008) bietet eine Möglichkeit, um die durch ethnografische Forschung gewonnenen Erkenntnisse bezüglich der Ziele, Bedürfnisse und Nutzungsgewohnheiten der Zielgruppe in konkrete Produktanforderungen zu übersetzen. Konkret werden die häufig im Rahmen eines Interviews berichteten Verhaltensweisen bzw. Ziele sowie die zugehörigen Emotionen, aber auch Philosophien für eine bestimmte Aktivität wie z.B. Onlineshopping in einem Affinitätsdiagramm angeordnet (siehe Abbildung 1). Young verwendet dabei zwei Ebenen zur Strukturierung der Daten: Die einzelnen Ziele, Verhaltensweisen, Emotionen und Philosophien sind in sogenannten Towern zusammengefasst, während aus den Towern wiederum die Mental Spaces, also die kognitiven Oberkategorien, gebildet werden. In der unteren Hälfte des Diagrammes sind alle Produktfunktionen abgetragen, die den Nutzer darin unterstützen, die im korrespondierenden Tower aufgeführten Ziele zu erreichen – dabei kann es sich sowohl um die implementierten Funktionen eines bereits existierenden Produktes handeln als auch um eine Ideensammlung für ein zu entwickelndes Produkt. Diese Ansicht ermöglicht die Durchführung einer Gap Analyse, bei der geprüft wird, welche Nutzerziele bereits optimal durch das untersuchte Produkt unterstützt werden, welche Ziele und Bedürfnisse aktuell nicht durch das Produkt befriedigt werden können bzw. welche Produktfunktionen überflüssig sind, da sie nicht zur Erfüllung relevanter Nutzerziele benötigt werden.

116

Nina Kolb, Sarah Diefenbach, Susanne Niklas

TOWER

MENTAL  SPACE

MENTAL  SPACE

GAP  ANALYSE Abbildung 1: Beispielhafter Ausschnitt aus dem im Rahmen dieser Studie erstellten Affinitätsdiagramms.

Interview-Methode und Shopping-Dimensionen Um bei Anwendung der Methode Mental Models sicherzustellen, dass alle relevanten Verhaltensweisen der verschiedenen Konsumenten erfasst werden, werden vorab verschiedene Konsumenten- bzw. Nutzergruppen definiert, die sich in dem jeweils

3, 2, 1, meins!

117

interessierenden Verhalten (in diesem Fall das Shoppingverhalten) unterscheiden. Im Rahmen dieser Studie wurden hierfür alle im Rahmen einer Literaturanalyse zu besagtem Thema identifizierten Verhaltensweisen bzw. Käufertypen zunächst zu Clustern zusammengefasst. Anhand dieser Cluster wurden insgesamt neun Dimensionen identifiziert, anhand derer sich das Verhalten der Konsumenten im Kontext Onlineshopping beschreiben lässt: ¥ Der Fokus bzw. die Motivation beim Shopping – liegt der Fokus eher auf dem Vergnügen, einhergehend mit einer hohen Motivation oder liegt er eher auf der Zielerreichung, einhergehend mit einer niedrigen Motivation? ¥ Der primär zum Shoppen genutzte Kanal – wird primär online geshoppt oder bevorzugt im Laden (offline) und erst in zweiter Instanz online? ¥ Die Wichtigkeit des Komforts – ist es für den Käufer sehr wichtig, den Shoppingprozess so angenehm und bequem wie möglich zu gestalten oder ist dieser Aspekt für ihn eher unwichtig? ¥ Die Loyalität – sucht der Käufer bevorzugt seine Lieblingsshops auf, kauft immer die gleichen Marken bzw. Produkte oder tätigt er seine Einkäufe unabhängig von bisherigen Erfahrungen? ¥ Die Bewertung von Neuheiten – ist der Käufer immer auf der Suche nach neuen Erfahrungen und kauft mit Vorliebe in Geschäften bzw. Shops, die ihm bisher unbekannt sind und hat Freude daran, neue Produkte zu testen oder lehnt er Neuheiten eher ab? ¥ Die Tendenz, Preise zu vergleichen – vergleicht der Käufer bevorzugt Preise und verfolgt dabei das Ziel, Produkte möglichst günstig zu erwerben oder ist der Preis für ihn eher unwichtig? ¥ Die Wichtigkeit von Boni & Sonderangeboten – orientiert sich der Käufer bei seinen Kaufentscheidungen stark an Boni und Sonderangeboten oder findet er diesen Aspekt eher unwichtig? ¥ Die Bewertung des sozialen Kontaktes – legt der Käufer beim Shopping hohen Wert auf soziale Interaktion oder möchte er diese lieber auf ein Minimum reduzieren? ¥ Das Modebewusstsein – richtet sich der Käufer nach aktuellen Trends und Modeerscheinungen oder legt er eher wenig Wert darauf, der aktuellen Mode zu entsprechen? Zum Zweck der Teilnehmerrekrutierung für die eigentliche Datenerhebung wurden 24 Items zur Erfassung der oben dargestellten Dimensionen entwickelt (Kolb 2015). Die Rekrutierung erfolgte über das Onlinepanel Bonopolis der eResult GmbH. Insgesamt wurden einstündige ethnografische Telefoninterviews mit zwanzig Personen durchgeführt (6 Frauen, 14 Männer). Das Durchschnittsalter lag bei 36,6 Jahren (min=20, max=52). Die Teilnehmer stammten aus dem gesamten Bundesgebiet. Alle Teilnehmer gaben an, mindestens einmal im Monat Onlinekäufe zu tätigen.

118

Nina Kolb, Sarah Diefenbach, Susanne Niklas

Art der Interviews Aufgrund des deskriptiven Charakters der Methode Mental Models erfolgt die Interviewdurchführung in ethnografischer, d.h. qualitativer, unstandardisierter Form (Young, 2008; Atorough, 2013). In der ethnografischen Forschung wird grundsätzlich eine informelle, eher unstrukturierte Interviewgestaltung empfohlen, da der Interviewer zu Beginn des Forschungsprozesses meist nicht über ausreichende Informationen verfügt, um allein mit vorab definierten Fragen den Kern des untersuchten Prozesses/Phänomens zu treffen. Aus diesem Grund sollte der Interviewer anstelle von ausformulierten Fragen eher mit grob definierten Themenbereichen arbeiten (Blomberg et al. 1993). Somit lässt sich das ethnografische Interview auf dem Kontinuum irgendwo zwischen unstrukturiert und semistrukturiert einordnen (Crabtree & Miller, 1999), jeweils abhängig von der Dominanz des Interviewers in Bezug auf die Gesprächsführung. Ein sehr guter Überblick über die verschiedenen Formen qualitativer Interviews findet sich bei Mey & Mruck (2011). Sie unterscheiden zwischen den narrativen und den diskursiv-dialogischen Interviews, wobei sich erstere auf den „Zugzwang“ des Erzählens verlassen – d.h. der Interviewte hebt automatisch subjektiv bedeutsame Aspekte hervor und erzählt sowohl detailliert als auch vollständig, um seine Erzählung verständlich zu gestalten – und dem Interviewer die Rolle des Zuhörers überlassen, während die zweitgenannten Interviewarten dem Interviewer eine deutlich aktivere, die Kommunikation mitgestaltende Rolle zuweisen. Bei der Methode Mental Models sollten Elemente aus der narrativen mit solchen aus der diskursivdialektischen Interviewführung kombiniert werden, indem den Interviewten freier Raum für ihre Erzählungen gegeben sowie Unterbrechungen des Erzählflusses strikt vermieden werden, gleichzeitig aber bei Bedarf eine Steuerung durch den Interviewer mittels Erzählaufforderungen, Sach- oder Verständnisnachfragen sowie Rückspiegelungen des soeben Gesagten erfolgen kann. Im Fall der vorliegenden Studie erfolgte der inhaltliche Einstieg über die Fragen „Welche Produkte kaufen Sie in der Regel im Internet?“ und „Was war das letzte Produkt, das Sie im Internet gekauft haben? Wie sind Sie dabei vorgegangen?“. Dieser Einstieg ergab sich aus dem Ziel, das Interview mit einer leicht zu beantwortenden, allgemeinen Frage zu starten, die einen klar erkennbaren Bezug zum Untersuchungsthema aufweist. Dies dient unter anderem zur Entwicklung von Rapport zwischen Interviewer und Interviewtem (DiCicco-Bloom & Crabtree, 2006), d.h. einer vertrauensvollen, auf Empathie und Aufmerksamkeit basierenden Beziehung. Da die Gesprächsführung beim Interviewten liegt, ergibt sich in der Regel für jedes Gespräch ein individueller Aufbau. Der Interviewer hat hierbei ggf. durch nachfragen oder Aufforderungen zum Erzählen dafür zu sorgen, dass alle vorab definierten interessierenden Themenbereiche besprochen werden, wobei die Reihenfolge meist flexibel ist. Auswertung Um das Affinitätsdiagramm zu erstellen, wurden aus den Interviewtranskripten sämtliche shoppingbezogenen Ziele, Bedürfnisse, Verhaltensweisen, Emotionen und Philosophien, die von den Teilnehmern beschrieben wurden, identifiziert und präzise benannt. Anschließend wurden die Inhalte in Mental Spaces kategorisiert und innerhalb der Kategorien zu Towern geclustert. Eine Darstellung des finalen Diagrammes findet sich bei Kolb (2015). Um zu

3, 2, 1, meins!

119

verdeutlichen, welche inhaltlichen Erkenntnisse mithilfe der Methode Mental Models gewonnen werden können, werden im Folgenden exemplarisch ausgewählte Ergebnisse der Studie dargestellt.

Beschreibung der Konsumentenziele anhand der ShoppingDimensionen Die wichtigsten Ziele, die Konsumenten während des Shoppingprozesses verfolgen, lassen sich problemlos anhand der bereits vorgestellten Shopping-Dimensionen beschreiben. Am häufigsten findet sich die Dimension Fokus (spaß- vs. zielorientiert) in den Aussagen der Konsumenten wieder. So empfinden einige Konsumenten Spaß am Einkaufsprozess per se, während andere shoppen quasi als lästige „Pflicht“ ansehen und sich vor allem darüber freuen, den Kaufprozess so schnell wie möglich abschließen zu können: „Viele Frauen gehen ja gerne shoppen, nur um zu gucken, was es so gibt, und da gehöre ich eben nicht dazu. Wenn ich was brauche, möchte ich das dann auch sofort haben und mich nicht tagelang damit beschäftigen müssen. Das ist dann Zeitverschwendung.“ Bei dem primären Kanal (Online vs. Offline) weisen die Konsumenten sehr unterschiedliche Vorstellungen auf und schreiben jeweils einem der beiden Kanäle die gleichen Vorteile zu, z.B. die Möglichkeit, eine bessere Auswahl zu treffen oder Aufwand bzw. Zeit zu sparen. Einige Konsumenten sind bei der Wahl des Kanals auch eher ambivalent und schätzen die Vorzüge beider Varianten: „Das ist schon ein anderes Gefühl online. Zuhause ist es bequemer, man muss nicht irgendwo hinfahren, hinter vielen Menschen anstehen. Man hat die Ruhe, online ist auch oft vieles günstiger, klar ist es ein Unterschied. Aber im Laden kann man die Artikel anfassen, richtig sehen.“ Während bei einigen Konsumenten der Komfort keine große Rolle zu spielen scheint, besteht für andere Konsumenten ein zentrales Motiv in nahezu allen Phasen darin, möglichst wenig Zeit und Energie aufzuwenden. Auch in Bezug auf die Loyalität gegenüber Shops oder Herstellern unterschieden sich die befragten Konsumenten. Einige berichteten explizit davon, bestimmte Marken oder Shops zu bevorzugen, mit denen sie bereits positive Erfahrungen gemacht hatten, während andere sich bei jedem Einkauf aufgrund der Gegebenheiten neu entscheiden und beispielsweise jeweils den Shop wählen, der das gewünschte Produkt am günstigsten anbietet: „Wenn ich spontan etwas bestelle brauche ich vorher Vergleichsmöglichkeiten. Ich brauche Zeit, um mir zwei, drei Angebote oder zwei, drei verschiedene Anbieter anzugucken, um auch ein Gefühl dafür zu bekommen, dass ich nicht beim teuersten gekauft habe, nur weil es der erste war.“ Die Vorliebe, jeweils bei den gleichen Shops zu bestellen, spiegelt sich auch in der Bewertung (bzw. in diesem Fall der Ablehnung) von Neuheiten wieder. Der umgekehrte Fall zeigt sich beispielsweise in der Tendenz, bei regelmäßigen Käufen jeweils ein leicht abweichendes Produkt zu wählen, Produkte über Suchmaschinen zu suchen, um auch neuen Shops „eine Chance zu geben“ oder auch mal „verrückte“ Produkte zu kaufen: „Ich war ein paar Mal in Portugal und habe mich erinnert, dass die da ein paar sehr gute Weine haben. Ich wollte einfach mal wieder was Neues ausprobieren, aber ein bisschen was bekanntes,

120

Nina Kolb, Sarah Diefenbach, Susanne Niklas

was hier schwer zu bekommen ist. […] Sowas kann man ja immer mal wieder machen, man kann auch mal verrückte Ideen umsetzen.“ Die Neigung, Preise zu vergleichen mit dem Anspruch, das günstigste oder zumindest nicht das teuerste Produkt bzw. Angebot zu wählen, wurde von vielen Konsumenten berichtet. Manche Konsumenten betrachten diesen Aspekt jedoch als nebensächlich und erwerben unabhängig vom Preis spontan die Produkte, die ihnen am besten gefallen. Boni und vor allen Dingen Sonderangebote wurden nicht von allen Konsumenten erwähnt, bilden jedoch für andere die Voraussetzung, bestimmte Produkt überhaupt zu kaufen, weil sie sich diese sonst nicht leisten könnten: „Wenn ich mal im Katalog etwas gefunden habe, es für gut befunden, aber nicht auf die Idee komme, mir das jetzt zu kaufen. Wenn ich das Kleid dann aber nicht vergessen kann, weil ich es unbedingt haben will. Das ist dann bei mir gespeichert und wenn dann das Versandhaus zufällig einen Newsletter schickt, wo dann Rabatt angeboten wird oder ein Schlussverkauf, dann gucke ich nochmal nach, ob ich‘s mir vielleicht doch kaufen kann.“ Die soziale Interaktion wurde hauptsächlich in Bezug auf den Ladenkauf thematisiert, den manche Konsumenten gerade deswegen bevorzugen, weil sie dort die Möglichkeit haben, gemeinsam mit anderen Personen nach Produkten zu gucken oder eine persönliche Beratung zu erhalten. Beim Onlinekauf gaben einige Konsumenten an, bewusst keine anderen Personen in ihre Entscheidungen einzubeziehen, eine Konsumentin hingegen berichtete, vor dem Kauf regelmäßig Screenshots an ihre Mutter oder andere wichtige Bezugspersonen zu schicken und diese um Rat zu bitten. Das Modebewusstsein wurde von keinem der Konsumenten explizit erwähnt, was angesichts der Tatsache, dass einige der befragten Konsumenten in der vorgeschalteten Befragung angaben, ein recht hoch ausgeprägtes Modebewusstsein zu besitzen, entweder darauf zurückgeführt werden kann, dass der Fokus der Interviews nicht speziell auf dem Produkt „Kleidung“ lag oder dass diese Dimension bei der Gestaltung des Kaufprozesses eine insgesamt eher untergeordnete Rolle spielt.

Fazit Die Websites vieler Onlineshops bleiben momentan noch hinter ihren Möglichkeiten zurück und unterstützen die Konsumenten nicht optimal darin, ihre Ziele zu erreichen bzw. Bedürfnisse zu erfüllen (Hausman & Siekpe 2009). Zur Verbesserung des Shoppingerlebnisses ist daher eine bessere Anpassung der Websites an die Anforderungen der Konsumenten nötig. Die im Rahmen dieser Studie verwendete Methode Mental Models stellt die für diesen Schritt benötigten Informationen über die Ziele und Bedürfnisse der Konsumenten zur Verfügung und gibt ebenso Auskunft darüber, wie diese üblicherweise vorgehen, um die besagten Ziele zu erreichen bzw. die Bedürfnisse zu erfüllen. Aufgrund seiner Gestaltung ist das Affinitätsdiagramm bestens geeignet zur Durchführung einer Gap Analyse, bei der die einzelnen Funktionen einer Shopwebsite gegen die Inhalte der „Tower“ abgetragen werden, wodurch genau bestimmt werden kann, welche der angebotenen

3, 2, 1, meins!

121

Funktionen den Konsumenten darin unterstützen, für ihn wichtige Ziele zu erreichen, welche überflüssig sind und im Sinne der Übersichtlichkeit von der Website entfernt werden sollten und nicht zuletzt, welche Konsumentenziele durch die Website aktuell nicht hinreichend unterstützt werden. Eine genauere Beschreibung zur Durchführung einer solchen Gap Analyse findet sich bei Young (2008). Allerdings kann das Affinitätsdiagramm nicht nur zur Verbesserung einer bereits bestehenden Website genutzt werden, es bietet ebenso Potenzial zur Entwicklung neuer, innovativer Konzepte und Geschäftsmodelle, die sich grundlegend an den Anforderungen der Konsumenten orientieren und damit große Chancen haben, eine bestehende Marktlücke zu füllen. Sowohl an der Entwicklung neuer Konzepte, als auch an der Verbesserung und Neugestaltung bereits existierender Modelle sind in der Regel Experten aus unterschiedlichen Fachgebieten beteiligt. Das Affinitätsdiagramm erleichtert diesen interdisziplinären Teams zum einen die Kommunikation, indem die verschiedenen Ausdrücke für die Aktivitäten der Konsumenten durch das Diagramm nicht nur vorgegeben werden, sondern auch auf einer einheitlichen Definition basieren. Zum anderen macht es unfruchtbare Diskussionen darüber, was von den Konsumenten gewünscht wird, hinfällig, da diese Erkenntnisse direkt aus den auf Angaben der Konsumenten basierenden Inhalten des Affinitätsdiagrammes gezogen werden können. Aufgrund seines extrem breiten Formates ist die Darstellung des Affinitätsdiagrammes jedoch nicht ganz unproblematisch und es fällt schwer, direkt eine gute Übersicht über den Inhalt zu bekommen. Die qualitative, unstandardisierte Art der Datenerhebung verhindert zudem eine Priorisierung der Ergebnisse. Zu diesem Zweck bietet sich eine ergänzende quantitativ angelegte Studie an, auf Grundlage deren Ergebnisse eine fundierte Entscheidung darüber erfolgen kann, welche der im Rahmen einer Gap Analyse identifizierten Funktionen der Shopwebsite implementiert oder entfernt werden sollten. Literatur Atorough, P. (2013). Consumer behaviour in online shopping – understanding the role of regulatory focus. PhD Thesis, Robert Gordon University. Abgerufen von http://core.ac.uk/download/pdf/19182282.pdf Appleseed, J. & Holst, C. (2013). E-Commerce Checkout Usability. Abgerufen von http://baymard.com/checkout-usability Arnold, M. J. & Reynolds, K. E. (2003). Hedonic shopping motivations. Journal of Retailing, 79(2), 77-95. Blomberg, J., Giacomi, J., Mosher, A. & Swenton-Wall, P. (1993). Ethnographic Field Methods and Their Relation to Design. In Schuler, D. (Hrsg.): Participatory Design: Principles and Practices. Hillsdale, N.J.: L. Erlbaum Associates, S. 123-155. Ganesh, J., Reynolds, K. E. & Luckett, M. G. (2007). Retail patronage behavior and shopper typologies: a replication and extension using a multi-format, multi-method approach. Journal of the Academy of Marketing Science, 35, 369-381. Hausman, A. V. & Siekpe, J. S. (2009). The effect of web interface features on consumer online purchase intentions. Journal of Business Research, 62(1), 5-13.

122

Nina Kolb, Sarah Diefenbach, Susanne Niklas

HDE. (n.d.). B2C-E-Commerce-Umsatz in Deutschland 1999 bis 2014 und Prognose für 2015 (in Milliarden Euro). In Statista - Das Statistik-Portal. Zugriff am 17. Juni 2015, von http://de.statista.com/statistik/daten/studie/3979/umfrage/e-commerce-umsatz-in-deutschland-seit1999/. Heinick, H. (2014). Branchenreport Online-Handel 2014. Abgerufen von http://shop.ifhkoeln.de/de/Themen/Handel-Allgemein/Branchenreport-Online-Handel-2014 Kolb, N. (2015). 3, 2, 1, meins! Analyse der Nutzerziele beim Onlineshopping mittels der "Mental Model Diagramm"-Methode. Master-Thesis, Technische Universität Darmstadt. Maslow, A. H. (1943). A Theory of Human Motivation. Psychological Review, 50, 370-396. Maslow, A. H. (1971). Farther Reaches of Human Nature. New York, NY: Viking Press. Nielsen, J. (2000). Designing web usability: the practice of simplicity. Indianapolis, IN: New Riders Publishing. Statista GmbH. Marktdaten zu E-Commerce & Versandhandel (B2C). In Statista - Das Statistik-Portal. Zugriff am 17. Juni 2015, von http://de.statista.com/statistik/kategorien/kategorie/10/themen/80/branche/b2c-e-commerce/. Tauber, E. M. (1972). Why do people shop? Journal of Marketing, 36, 46-9. Young, I. (2008). Mental Models. Aligning Design Strategy with Human Behavior. New York, NY: Rosenfeld Media.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 123- 132.

Bodystorming als Best Practice Methode für die Entwicklung von AALLösungen Tobias Limbach, Kathrin Kim, Jan Köppen, Peter Klein

Tobias Limbach

Kathrin Kim

Jan Köppen

Dr. Peter Klein

User Interface Design GmbH Claudius-Keller-Straße 3c 81669 München [email protected] User Interface Design GmbH Claudius-Keller-Straße 3c 81669 München [email protected]

User Interface Design GmbH Claudius-Keller-Straße 3c 81669 München [email protected] User Interface Design GmbH Claudius-Keller-Straße 3c 81669 München [email protected]

Abstract Bodystorming ist eine kreative Methode, die den menschlichen Körper und die räumliche Umgebung für den Gestaltungsprozess nutzt. Die Vorteile des Bodystormings können in ganz unterschiedlichen Entwicklungsphasen genutzt werden. So kann bereits der Ideenfindungsprozess qualitativ und quantitativ enorm bereichert werden. Bodystorming bietet hier – ganz im Sinne des Design Thinking – einen idealen Raum für Kreativität. Im Designprozess kann die Methode dabei helfen, bisher übersehene oder unbekannte Aspekte in der Konstellation Mensch-Technik-Umwelt zu entdecken und daraus ableitend (kritische) Situationen nachzuvollziehen. Am Beispiel der Konzeptentwicklung für das Projekt „InPres – Interaktives Sicherheits- und Assistenzsystem“ werden exemplarisch die designrelevanten Vorteile der Bodystorming Methode aufgezeigt.

Keywords Body Storming, Produktentwicklung, Produktdesign, Design Thinking, AAL, Ambient Assisted Living, Design Thinking, Ideation

Was ist Bodystorming? Bodystorming lehnt sich begrifflich an das Brainstorming an. Doch neben der kreativen Ideenfindung hat die Methode vor allem das unmittelbare Ausprobieren zum Ziel. Es geht

124

Tobias Limbach, Kathrin Kim, Jan Köppen, Peter Klein

darum, eine Handlung spielend zu „erfahren“ und auf diese Weise nachzuvollziehen und zu verstehen. Dadurch wird die analytische Betrachtung durch die praktische und durchweg empathische Erfahrung bereichert. Eine Gruppe von Menschen (beispielsweise das Designteam) begibt sich spielend in eine Szene, für welche ein Artefakt oder eine technische Lösung entwickelt werden soll. Auf diese Weise sollen die notwendigen Eigenschaften der zukünftigen Lösung besser verstanden werden. Um die Kreativität zu steigern, wechseln die Designer im Bodystorming die räumliche, zeitliche, kognitive, motivationale und emotionale Perspektive (vgl. Funke 2013). Sie versetzen sich in eine andere Person, einen anderen Raum und eine andere Zeit. Auf diese Weise vollziehen sie die jeweiligen Motive der gespielten Personen nach. Wie fühlt man sich, wenn man gestürzt ist und hilflos auf dem Boden liegt? Die beste Möglichkeit das nachzuempfinden, ist, sich in eben diese Situation zu begeben.

Aspekte des Bodystormings Das Ausprobieren in einer Art „so tun als ob“ konkretisiert Vorstellungen und legt Schwachpunkte bisheriger Lösungen offen. Im Kontext des Ambient Assisted Living (AAL) ist es gleichsam ein Vorgreifen auf ein reales Nutzungserlebnis. Systeme und Konzepte können erfahrbar gemacht werden – sei es im Stadium einer ersten Idee, in der Entwicklung begriffen oder bereits prototypisch umgesetzt. Was genau passiert beispielsweise in der Wohnumgebung? In welcher Reihenfolge und Geschwindigkeit wird etwas von den Personen „erlebt“? Diese und noch viele weitere Aspekte treten im Bodystorming zutage – zum frühestmöglichen Zeitpunkt in der Produktentwicklung. Wer die Methode des Bodystormings im Innovationsprozess konsequent einsetzt, schützt sich mitunter vor teuren Anpassungen im späteren Entwicklungsverlauf.

Der Mensch im Mittelpunkt Die theoretische Betrachtung eines Problems vom Schreibtisch aus ist auf schnelle, technische Lösungen hin orientiert. Bodystorming hingegen stellt den Menschen physisch und empathisch in den Mittelpunkt. Man könnte auch sagen, dass die Methode nicht per se problemorientiert ist, sondern menschenorientiert. Das Werkzeug der Personas (= idealtypische Vertreter einer Nutzergruppe) ist vom Ansatz her ähnlich gelagert wie die Bodystorming-Methode. Beide möchten das empathische Verständnis von Zielen und Bedürfnissen der Nutzer ermöglichen. Jedoch sind PersonaBeschreibungen nicht nur auf dem Papier, sondern auch in der kreativen Diskussion immer ein zweidimensionales Instrument. Es bleibt immer bei der Trennung von Betrachter und Persona. Beim Bodystorming wird die Perspektive noch erweitert: Man denkt sich nicht nur in die jeweilige Befindlichkeit und Erfahrungswelt der Persona ein, sondern wird selbst zum unmittelbaren Nutzer und „Erleber“. Im Idealfall spürt und versteht man die Bedürfnisse

Bodystorming als Best Practice Methode für die Entwicklung von AAL-Lösungen

125

selbst. Bodystorming findet nicht nur im dreidimensionalen Raum statt, sondern ist eine Methode, die alle Dimensionen des Erlebens nutzt. Das enge Zusammenspiel im AAL-Bereich von Mensch und Technik innerhalb eines viel weiteren Interaktionsraumes als bei herkömmlichen Produkten (z. B. PC, TV, Mobiltelefon) birgt besondere Herausforderungen. Die Technik soll sich „natürlich“ in die Tagesabläufe der Bewohner einer Wohnung oder eines Hauses einbetten und kein unnatürliches Verhalten aufzwingen. Diese Abläufe über Zeit und Raum können im Bodystorming besser nachgestellt und nachempfunden werden als mittels Diskussion und Storyboards. Darüber hinaus ist Bodystorming ein ideales Instrument, um den Horizont von einer eindimensionalen „Usability-Untersuchung“ hin zur Erforschung der „User Experience“ zu erweitern. Darin liegt ein weiterer Vorteil der kreativen Methode: Sie öffnet die Perspektive auch für eben solche Kleinigkeiten, die bisher nicht im Fokus standen, die aber mitunter aus Nutzersicht der zentrale Erfolgsfaktor einer AAL-Lösung sein können. So fließen alle Aspekte der Erfahrungen eines Nutzers bei der Interaktion mit ein. Die reine Funktionalität tritt in den Hintergrund – wird gleichsam zur banalen Grundvoraussetzung degradiert. Auf diese Weise wird die Qualität des gesamten Service einer AAL-Lösung sichtbar. Im Forschungsprojekt InPreS-Projekt zeigte sich, dass das Bodystorming eine ideale Methode ist, um erste Ideen konkret werden zu lassen und auch Grenzen des Machbaren auszuloten. Das Projekt InPreS (Interaktives Sicherheits- und Assistenzsystem zur Steigerung der Sicherheit und Teilhabe von dementiell erkrankten Personen), zielt darauf ab, die familiären ebenso wie die professionellen Pflegeleistungen bei der ambulanten Betreuung von Demenzkranken zu unterstützen. Im Projekt werden hierzu neuartige Ansätze kognitivtechnischer Systeme entwickelt. Gerade diese Neuartigkeit machte es notwendig, die ausgetretenen Entwicklungspfade zu verlassen und neue Methoden auszuprobieren. Insbesondere um die technischen Potentiale in eine erste Form zu gießen und eine gemeinsame Vorstellung vom „wie“ und „warum“ der AAL-Lösungen zu erhalten, war das Bodystorming der ideale Weg.

126

Tobias Limbach, Kathrin Kim, Jan Köppen, Peter Klein

Abbildung 1: Ausschnitt aus dem Bodystorming für das InPreS-Projekt

Es wurde beispielsweise die Idee entwickelt, Personen auf Gegenstände hinzuweisen, die sich im Geh-Bereich befinden. Ziel war die Sturzprävention. Erst im Bodystorming merkte das Team jedoch, dass dies in der Realität schwer umsetzbar ist. Denn wie könnte ein solcher Hinweis aussehen? Stimmen aus dem Off können unheimlich wirken – gerade für demente Personen, die moderne Technik nicht kennen oder den Umgang mit ihr vergessen haben. Auch die Idee Lichtspots auf Gegenstände zu projizieren, um darauf aufmerksam zu machen, wurde verworfen. Die Experten waren sich einig, dass Licht für Demenzkranke anziehend wirkt und daher einen gegenteiligen Effekt haben könnte. Eventuell könnten durch beleuchtete Gegenstände im Geh-Bereich gefährliche Situationen überhaupt erst entstehen.

Implizites explizieren Ideen entstehen im Kopf und sind im ersten Moment skizzenhaft. Die Umsetzung im Bodystorming zwingt das Entwicklungsteam, konkret zu werden. Lücken und offene Fragen tauchen auf. Zum großen Teil können sie noch im Bodystorming-Prozess selbst beantwortet werden. Auch unterschiedliche Wahrnehmungen im Team treten zutage. Durch das Bodystorming wird die Ideenwelt jedes Einzelnen für das Team expliziert. Hierbei wird auch deutlich, wenn im Team ein unterschiedliches Verständnis eines Ablaufs vorliegt. So kann

Bodystorming als Best Practice Methode für die Entwicklung von AAL-Lösungen

127

das Bodystorming durch das notwendige Explizieren von Vorstellungen dazu beitragen, die Sichtweisen im Team abzugleichen und zu fokussieren.

Wissenstransfer Das Bodystorming kann sein Potential vor allem dann entfalten, wenn die Teilnehmer eine gewisse Heterogenität mitbringen. Auf diese Weise kann der Erfahrungshorizont verschiedener Menschen einfließen. Im InPres Projekt arbeiten Designer, Sozialwissenschaftler, Menschen mit Hintergrundwissen im Health-Care-Bereich und Ingenieure zusammen. Im Bodystorming konnten alle Beteiligten vom jeweiligen Wissensschatz des Anderen profitieren. Insbesondere die Technik-Partner konnten ihre Sichtweise erweitern, indem sie sich in konkrete Situationen einfühlen mussten und von den Sozialwissenschaftlern direkt erläutert bekamen, wie eine demente Person diese wahrscheinlich wahrnehmen würde. Immer wieder wurden Lösungsvorschläge diskutiert und Fachwissen eingebracht: Welche Farbschemata können bei einer Demenzerkrankung sinnvoll eingesetzt werden? Inwiefern können Symbole verstanden werden? Bodystorming hat sich somit als ein ausgezeichnetes Instrument für den Wissenstransfer bewährt: Es kann einen interdisziplinären, fruchtbaren Dialog anstoßen.

Designentscheidungen treffen und dokumentieren Während des Bodystormings werden grundlegende Designentscheidungen getroffen, das heißt Design-Prinzipien entwickelt. Warum sollten bestimmte Aspekte des Systems genau so und nicht anders funktionieren? Warum ist gerade diese Lösung besser als alternative Möglichkeiten? Welche Probleme der Nutzer werden damit adressiert? Bodystorming hilft dem Entwicklerteam einerseits diese Fragen zu beantworten. Andererseits werden die getroffenen Entscheidungen im Bodystorming dokumentiert. Das unmittelbare und sehr visuelle Festhalten der Arbeitsergebnisse ist ein zentraler Erfolgsfaktor des Bodystormings. Hierfür bieten sich verschiedenste Formen an: Notizen, Fotografien oder Videodokumentation. Die festgehaltenen Design-Prinzipien bilden die weitere Arbeits- und Argumentationsgrundlage. Die Entscheidungen können Außenstehenden transparent gemacht werden und sind jederzeit nachvollziehbar. Damit wird vermieden, dass kritische Punkte in verschiedenen Gremien ständig aufs Neue diskutiert werden müssen.

Praxis statt graue Theorie Ein explizites Ziel des Bodystormings ist es, die analytische Betrachtung vom Konferenztisch zu durchbrechen. Beim Bodystorming sollen Dinge ausprobiert werden, um zu sehen und zu spüren, ob sie funktionieren. Verbleibt die Betrachtung eines Problems auf einer theoretischen Ebene, so werden komplexe Sachverhalte gerne vereinfacht dargestellt. Im Bodystorming hingegen werden unbedachte, durchaus in der Situation komplexe Aspekte offenkundig und gelöst.

128

Tobias Limbach, Kathrin Kim, Jan Köppen, Peter Klein

Das heißt die eindimensionale theoretische Betrachtung muss sich in der Praxis beweisen. Und häufig stellen sich die Dinge hier völlig anders dar. Es hilft auch, festgefahrene Diskussionen weiter zu bringen – allein schon, indem die Teilnehmer ihren Schreibtisch verlassen müssen. Hinzu kommt ein nicht unerheblicher Aspekt für das Team: Spaß. Es macht ganz einfach Freude, sich auf die neue Technik und damit das ungewohnte Terrain einzulassen. Auf diese Weise kann das Bodystorming auch zur Quelle großer Kreativität werden.

Kreativität Bodystorming kann den Kreativprozess bereichern. Insbesondere ist jedoch dabei darauf zu achten, keine zu engen Grenzen im Hinblick auf die technische Machbarkeit zu setzen. Das würde den Ideenfindungsprozess zu früh beengen und viele (eventuell sehr gute) Einfälle ausschließen. Konsequent angewandt fügt sich das Bodystorming ideal in die grundlegenden Prinzipien des Design-Thinking ein: ¥ Arbeite visuell ¥ Nur einer spricht ¥ Fördere verrückte Ideen ¥ Stelle Kritik zurück ¥ Quantität ist wichtig ¥ Bleib beim Thema ¥ Baue auf den Ideen Anderer auf Die Dynamik des Bodystormings und die notwendigen Iterationen sind gleichsam essentielle Bestandteile des Kreativprozesses. Die Teilnehmer bewegen sich fließend zwischen Bedürfnisidentifikation, Ideenfindung, erstem Prototyping und Testen. Auf diese Weise werden Ideen innerhalb kürzester Zeit generiert, weiterentwickelt, umgesetzt und auf ihre Praxistauglichkeit hin erprobt.

Raum und Körper Die Methode des Bodystormings profitiert enorm von der Dreidimensionalität der Kulisse. Handlungsabläufe bleiben nicht nur eine reine Beschreibung auf Papier, sondern finden tatsächlich statt. Dabei treten sowohl besonders gelungene Ansätze als auch Widrigkeiten deutlich zutage. Seien es zeitliche Abläufe, die es zu synchronisieren gilt, oder technische Anforderungen, die noch nicht bedacht wurden. Erst im Raum, beim Nachspielen und Nacherleben wird deutlich, welche Aspekte bei Design und Entwicklung im Detail zu beachten sind. Das gilt auch für scheinbar banale Erkenntnisse.

Bodystorming als Best Practice Methode für die Entwicklung von AAL-Lösungen

129

Beispielsweise wurde beim Bodystorming für das InPreS-Projekt deutlich, dass sich Haustüren (im Gegensatz zu den meisten Bürotüren) generell nach innen öffnen. Eine Anzeige, die auf der Tür selbst positioniert ist, ist bei geöffneter Tür somit nicht mehr lesbar.

Abbildung 2: Ausschnitt aus einem Storyboard, das auf Basis des Bodystormings entstanden ist

Auch physische Aspekte der Nutzer fließen unweigerlich in die Erkenntnisse mit ein. Welche Höhe ist hier ideal für eine bequeme Eingabe? Ist der Bewegungsablauf natürlich? Steht Ergonomie beim Bodystorming zwar nicht explizit im Mittelpunkt, so ergeben sich doch zumindest erste Anhaltspunkte, welchen ergonomischen Aspekten weitere Aufmerksamkeit geschenkt werden sollte.

Das Handlungsnetzwerk Beim Bodystorming stehen nicht einzelne technische Funktionen im Vordergrund, sondern die gesamte Interaktionskette. An dieser sind sowohl menschliche, als auch technische Akteure beteiligt und bilden gemeinsam ein Netzwerk (vgl. Latour 2002). Ziel ist die Stabilität des Aktanten-Netzwerks. Das heißt die Akteure müssen sich erwartungskonform verhalten, so dass ihr Verhalten für alle am Netzwerk Beteiligten vorhersehbar ist und die Handlungsfolgen aufeinander aufbauen können. Im Bodystorming kann die Konvergenz des Handlungsnetzwerks eingeübt werden. Wie können sich die Akteure in ihrem Verhalten abstimmen? Was passiert, wenn ein Akteur anders handelt als erwartet? Für eine gelungene AAL-Lösung ist es zentral, dass die technischen Akteure den menschlichen Akteuren keine unnatürliche Handlung aufzwingen und immer eine alternative, sinnvolle Reaktion zulassen. Ist das nicht der Fall, mündet die Handlungskette zwangsläufig in einer Sackgasse, was das Scheitern erfolgreicher Interaktion bedeutet. Es bedarf folglich einer anpassungsfähigen und intelligenten technischen Umgebung, die entsprechend adaptiv auf die unberechenbaren menschlichen Akteure reagiert. Ein sinnvolles AAL-Konzept lässt dem menschlichen Akteur immer das letzte Wort. Das bedeutet, dass die

130

Tobias Limbach, Kathrin Kim, Jan Köppen, Peter Klein

Entscheidungen des Menschen immer mächtiger sein müssen und ggf. eine technische Befehlskette überschreiben. Auch solche Situationen können im Bodystorming ideal konzipiert werden.

Abbildung 3 und 4: Beim Forschungsprojekt InPreS entwickelt UID mit Partnern unter anderem ein digitales Schlüsselboard. Die Bilder zeigen den spontanen Entwurf während des Bodystormings und den finalen Designentwurf.

Bodystorming als Best Practice Methode für die Entwicklung von AAL-Lösungen

131

Dienstleistungskette Die oben genannte Verschiebung von der Betrachtung einer einzelnen technischen Funktion hin zu einem ganzheitlichen Blick auf den angebotenen Service zeigt ein weiteres Potential der Methode Bodystorming auf. Sie kann auch dazu beitragen, AAL-Lösungen in Form einer Dienstleistungskette zu gestalten. Gerade im schauspielerischen Nachstellen treten Anforderungen und Ideen zutage, die essentiell für einen gelungenen Gesamtservice sind. Sind es doch gerade die Handlungsketten und Prozesse, die im Bodystorming im Vordergrund stehen. Auch trägt das Nachspielen einer Handlungssequenz dazu bei, die Bedürfnisse der Nutzergruppe auf empathische Weise zu verstehen (siehe 1.2). So wurde im InPreS-Projekt deutlich, dass die Einrichtung einer Sturzerkennungssoftware nur einen kleinen Teil des Gesamtservice darstellt. Weiterhin muss eine Personenkette festgelegt werden, die im Notfall über den Sturz eines Angehörigen benachrichtigt wird. Auch ein automatisierter Anruf bei der Notrufzentrale muss in der Dienstleistung enthalten sein, um im Notfall sinnvoll Hilfe zu bieten. Doch wie kann dem Gesprächspartner in der Rettungsleitstelle versichert werden, dass die automatisierte Stimme verlässliche Daten zu einem tatsächlichen Unglück liefert? Für ein gelungenes Gesamtkonzept ist die Klärung solcher Punkte unbedingt notwendig. Bodystorming kann dabei helfen, genau diese offenen Fragen zu identifizieren und sinnvoll zu beantworten.

Anleitung für das Bodystorming Ein Bodystorming Team sollte etwa 4-8 Personen umfassen, die sich der Thematik aus verschiedenen Blickwinkeln nähern (siehe Abschnitt Wissenstransfer). Um das Bodystorming erfolgreich anzuwenden, ist es weiterhin zwingend notwendig, dass fundiertes Wissen über die aktuellen Problembereiche der Zielgruppe vorliegt. Demnach muss dem Bodystorming eine Beobachtungs- und Recherchephase vorangehen, an der idealerweise alle Teammitglieder teilnehmen sollten. Nur so können Handlungen und Abläufe realitätsnah gespielt und erlebt werden. Um von allen Vorteilen des Bodystormings zu profitieren, muss ein nicht zu geringer Dokumentations- und Diskussionsaufwand eingeplant werden. Das heißt, Bodystorming braucht Zeit. Vor allem der Aufwand für Nachbereitungen ist nicht zu unterschätzen, da die gewonnenen Einsichten festgehalten werden müssen, um im weiteren Projektverlauf wirksam zu werden. Es ist weiterhin wichtig, geeignete Räumlichkeiten für das Bodystorming zu organisieren. Je näher diese dem echten Schauplatz kommen, desto besser. Aber es kann ebenso improvisiert werden. Mit Hilfe von Markierungsstreifen am Boden oder durch das Verrücken von Möbeln können Räume erfunden und umgestaltet werden. Je nach Szenario, das das Team spielt, kann es auch hilfreich sein, sich Requisiten zu organisieren. Das können alltägliche Gegenstände, aber auch Mobiliar oder spontan gebastelte Papier-Prototypen sein. Auf alle Fälle sollte Schreib- und Bastelmaterial vorrätig sein, um ad hoc kreativ werden zu können.

132

Tobias Limbach, Kathrin Kim, Jan Köppen, Peter Klein

Sind alle Vorbereitungen getroffen, geht es ans Ausprobieren. Dabei werden zunächst die offensichtlich notwendigen Rollen verteilt. Jeder Akteur, so auch technische Funktionen, Systeme oder Geräte sollten sich in den Rollen wiederfinden. Über die Reflektion des gerade Gemachten in der Diskussion kann so das eigene Verständnis und das Verständnis des Entwicklungs-Teams von der Rolle erweitert und festgezurrt werden. Idealerweise macht ein Teilnehmer Notizen und Fotos der Szenen. Alternativ kann auch eine Videoaufzeichnung gemacht werden. Wichtig ist eine gegenseitige wohlwollende Grundhaltung: Das bedeutet, dass die Handlungen der verschiedenen Rollen aufeinander Bezug nehmen und aufbauen müssen. Die Rollen kommunizieren miteinander. Andernfalls gerät der Spielfluss ins Stocken. Wer keine offizielle Rolle bekommen hat, beobachtet die Szenen, gibt Input und hilft bei der Reflektion der Handlungen. Dies ist mitunter der wichtigste Schritt: das Diskutieren und Reflektieren des Erlebten. Typische Fragen, die hier auftauchen, sind: Wie hast du das erlebt? Warum hast du das gerade auf diese Weise gemacht? Könnte das auch anders ablaufen? Sich auf diese Diskussion einzulassen, ist der schwierige, aber auch spannendste und fruchtbarste Teil des Bodystormings. Literatur Adler, Stella: Die Schule der Schauspielkunst. Leipzig: Henschel 2005. Design Thinking. http://www.gruenderszene.de/lexikon/begriffe/design-thinking (abgerufen am 16.10.2014, 9:21 Uhr). Funke, Joachim: Neues durch Wechsel der Perspektive. In H. R. Fischer (Ed.), Wie kommt Neues in die Welt? Phantasie, Intuition und der Ursprung von Kreativität (pp. 187-196). Frankfurt: Velbrück 2013. Online unter: http://www.psychologie.uniheidelberg.de/ae/allg/mitarb/jf/Funke%202013%20Perspektivwechsel.pdf (abgerufen am 06.03.2015, 09:34 Uhr) Gray, Dave; Brown, Sunni; Macanufo, James: Game storming: Ein Praxishandbuch für Querdenker, Moderatoren und Innovatoren. Köln: O’Reilly, 2011, 64-65 Latour, Bruno: Wir sind nie modern gewesen – Versuch einer symmetrischen Anthropologie. Frankfurt am Main: Fischer 2002. Wilson, Chauncey: UXD Method 11 of 100: Bodystorming. http://dux.typepad.com/dux/2011/04/uxdmethod-11-of-100-bodystorming.html (abgerufen am 16.10.2014, 9:04 Uhr).

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 133- 143.

Anforderungsanalyse bei IT-Experten mit der Experience-Sample-Methode Wie ein Diagramm den Arbeitsverlauf visualisiert Andreas Thom, Sebastian Meier, Frank Heidmann

Andreas Thom

Fachbereich Design, Fachhochschule Potsdam Kiepenheuerallee 5 14469 Potsdam [email protected]

Sebastian Meier

Fachbereich Design, Fachhochschule Potsdam Kiepenheuerallee 5 14469 Potsdam [email protected]

Frank Heidmann

Fachbereich Design, Fachhochschule Potsdam Kiepenheuerallee 5 14469 Potsdam [email protected]

Abstract Dieser Beitrag beschäftigt sich mit den Herausforderungen eine Anforderungsanalyse im hoch technologischen Umfeld der IT-Security durchzuführen, bei dem keine der üblichen ethnografischen Methoden wie teilnehmende Beobachtung u.a. möglich waren. Im Umfeld von IT-Sicherheitsexperten besteht grundsätzlich Skepsis bzgl. möglicher Datenerfassungen, die Sicherheitsbelange des eigenen IT-Sicherheits-Betriebes (ITS) betreffen. Diese muss vor allem in der Anforderungsanalyse beachtet werden. Welche Methode könnte hierbei also zum Einsatz kommen? Im Rahmen des Beitrages möchten wir unser Vorgehen und die gewonnen Erkenntnisse im Rahmen eines ZIM-Koop-Projektes des BMWi vorstellen und anhand eines Frameworks inkl. der Sample-Visualisierung der gewonnenen Daten zur Experience-Sample-Methode erläutern.

Keywords Partizipatives Design, User Requirements, Design Research, User Experience, User Centered Design

Einleitung Durch die rapide Weiterentwicklung heutiger Produkte werden Entwicklungszyklen immer agiler. Besonders im Umfeld fortschreitendender IT-Entwicklungen im KMU-Bereich werden Mitarbeiter häufig mit sich schnell verändernden Herausforderungen und

134

Andreas Thom, Sebastian Meier, Frank Heidmann

Anforderungen konfrontiert. Vor allem im vielfältigen Arbeitsbereich der ITDienstleistungen sind die zeitlichen Einschränkungen enorm. Ein großer Umfang der Arbeiten erfordert es, dass einzelne Tätigkeiten ausgelagert werden. Die absolute Zahl der Aufgaben pro IT-Mitarbeiter hat abgenommen, während im gleichen Zeitraum die Zahl der relativen Aufgaben angestiegen ist. Im gleichen Zusammenhang wurde durch die zunehmende Komplexität der IT-Infrastrukturen auch die zeitliche Belastbarkeit eine Herausforderung im Umgang mit Entwicklungsprojekten. Zum Zeitpunkt des Forschungsprojektes existierten vor diesem Hintergrund bereits verschiedene Ansätze zur natürlichen Beobachtung von Administratoren, die auf Video aufgezeichnet und zusammen mit Interviews, Fragebögen und speziellen Artefakten wie Tagebüchern, Instruktionen kombiniert werden. (Haber & Bailey, 07) Hierbei werden primär die Dimensionen von administrativer Arbeit aufgezeigt und entsprechend des Aufgabengebietes beschrieben. Dieses gesamte Vorgehen ist sehr zeit- und labor-intensiv, die Resultate beruhen hierbei eher auf kleinen Stichproben und sind vor allem temporäre Beispiele der Probanden (Haber & Bailey, 07). Für die Auswertung dieser qualitativen Stichproben wird viel Zeit benötigt, die dann zumeist in ihren Darstellungen Excel-Tabellen ähneln. Nichtdestotrotz sind die bisherigen Methoden für die InSitu-Beobachtung gut einsetzbar. Barett et al. nutzen diese Methoden z.B. um Administratoren im konkreten Aufgabenkontext zu beobachten: „to find opportunities for supporting work through appropriate design and technology.“ (Barett et al., S. 394) Im Hinblick auf die Abfolge und auftretende Tätigkeitsherausforderungen war es aber im Bereich der IT-Security (Informations- und Datensicherheit) innerhalb des Projektes nicht zielführend, herkömmliche Beobachtungsmethoden einzusetzen.

Hintergrund Im Rahmen des Forschungsprojektes „Entwicklung einer modularen, erweiterbaren und herstellerneutralen Middleware als Abstraktionsschicht zwischen security-relevanter Hardware / Software und einem IT-Security-Management-Cockpit speziell für ITSMUmgebungen im Mittelstand“ war das erklärte Ziel die Entwicklung eines Dashboards. Dieses Dashboard soll hierbei relevante Metriken (Kennzahlen der IT-Security) entsprechend den Anforderungen der Anwender (IT-Experten) darstellen. Um hierfür die Anforderungen erheben zu können, war es erforderlich, dass die Tätigkeiten der Projekt-Praxispartner (Krankenhäuser und Forschungsinstitute) identifiziert und beschrieben wurden.

Methodik Für das Erreichen der zuvor beschriebenen Ziele innerhalb des Forschungsprojektes wurde das Experience Sampling – auch als Ecological Momentary Assessment (EMA) (Stone &

Anforderungsanalyse bei IT-Experten mit der Experience-Sample-Methode

135

Shiffman, 1994) bekannt – eingesetzt. Die folgenden zwei Hauptvarianten werden hierbei unterschieden: Die ESM-Methode (Csikszentmihalyi & Larson, 1987) wird als fragenbogenbasierter Ansatz eingesetzt, bei dem die Probanden durch einen Trigger aus jeweils vorgefertigten Antworten auswählen oder auf offene Fragen reagieren können. Bei der Descriptive-Experience-Sample-Methode (DES) (Hurlbert & Akhter, 2015) notiert der Proband seine innere Erfahrung nachdem er einen Trigger erhalten hat. In einem qualitativen Interview, das bspw. 24 h nach der Aufnahme mit einem Interviewer (oder Forscher) durchgeführt wird, schildert der Proband entsprechend der Notizen seine genauen, ursprünglichen Erfahrungen.

Materialumfang Die Studie wurde in die zwei Phasen Datensammlung und Datenanalyse aufgeteilt.

Phase 1 – Datensammlung Die Teilnehmer konnten zu Anfang zwischen einer Print-Version und einer digitalen Version wählen. Print-Version Zur Situationserläuterung beinhalteten die gedruckten Sets jeweils ein Tagebuch, zwei analoge Einwegkameras (je 27 Aufnahmen) und einen frankierten Maxibrief. Alle Unterlagen sollten nach Ende der Studie wieder an die Fachhochschule Potsdam zurückgeschickt werden. Digitale Version Die digitale Version bestand aus einem Link zu einem digitalen Fragebogen, in dem die Fragen inkl. einer Fotofunktion aufgelistet waren. Die Protokollierung konnte sowohl mit einem Computer, Tablet oder Smartphone durchgeführt werden. Auf Grundlage der Ergebnisse aus den Projekten MyExperience (Froehlich, Chen, Consolvo, Harrison, & Landay, 2007) und CAES (Massachusetts Institut of Technology, 2008) wurde die digitale Ausführung vor allem zur Aufzeichnung der Inhouse-Aktivitäten ohne Integration einer Kontext-bedingten Datensammlung verwendet. Um eine Vergleichbarkeit zwischen der Print- und Digitalen Version zu erhalten, wurden situative Informationen (Umgebungsfragen, Stimmungseinschätzungen) in Form von offenen Fragen integriert und nach der Beantwortung über die hinterlegte Email-Adresse an die uns verschickt (siehe Abbildung 1). Aufgaben Um eine höchstmögliche Dichte an Informationen zu erhalten, sollten die Teilnehmer ihren individuellen Tagesarbeitsverlauf inkl. der Arbeitsaufgaben protokollieren. Dazu erhielten sie in der Arbeitszeit zwischen 09:00-18:00 Uhr in zufälligen Intervallen (30-90 min) einen Auslöser (Zeitanker) in Form einer SMS bzw. Email gesendet. Wichtig war, dass die

136

Andreas Thom, Sebastian Meier, Frank Heidmann

Einträge innerhalb der Situation oder kurze Zeit (max. 15min) später durchgeführt wurden. Zur Erläuterung der Einträge konnten optional Fotos, Screenshots o.ä. gemacht werden, um uns einen Einblick in den Arbeitsvorgang bzw. die Kontextsituation zu ermöglichen. Folgende Fragen sollten die Probanden während der Protokollierung beantworten: ¥ Kreuzen Sie bitte an, was im Moment auf Sie zutrifft. (Allein, Mit Jemanden, Arbeit, Freizeit) ¥ Wo sind Sie gerade? (Beschreiben Sie bitte Ihren Aufenthaltsort / Ihre Umgebung? ¥ Was tun Sie gerade? (Beschreiben Sie bitte, was Sie jetzt gerade tun, z.B. Ihren Arbeitsablauf.) ¥ Was nutzen Sie dafür? (Beschreiben Sie bitte, welche (Software-)Werkzeuge und welches Wissen Sie dafür benötigen. ¥ Wie fühlen Sie sich gerade? (Beschreiben Sie Ihre derzeitige Gefühlsphase.) ¥ Was würde Ihre Arbeit jetzt erleichtern? (Beschreiben Sie bitte Ihre Idee einer Arbeitserleichterung.) ¥ Haben Sie ein Foto aufgenommen?

Ausführung und Framework Die Studie wurde im September 2014 durchgeführt und umfasste max. 5 aufeinanderfolgende Werktage jeweils von Montag bis Freitag. Wichtig war vor allem, dass die Teilnehmer/innen min. an drei aufeinanderfolgenden Tagen ihren Arbeitsverlauf dokumentierten. Framework Das Framework wurde als eine web-basierte Applikation entwickelt, welche die Skriptsprache PHP für die serverseitige Verarbeitung nutzte und dies in eine HTML5Anwendung einbettete. Mit Hilfe dieses Ansatzes konnten die Teilnehmer ihre präferierten Geräte (Bring your own Device) verwenden. Die gesammelten Daten wurden in einer relationalen MySQL-Datenbank gespeichert, die auf einem Apache Web-Server lief. Im Vergleich, z.B. zu nativen Anwendungen, die auf dem Gerät des Anwenders installiert werden müssen, erlaubte uns dieses Vorgehen wenn erforderlich, die Änderung der Elemente zur Laufzeit und die sofortige Analyse der Daten. Zum Senden der Auslöser SMS oder Email nutzten wir die Developer Garden Global SMS API. (Telekom AG, 2015) Diese API konnte schnell und effizient integriert werden, war gut dokumentiert und unterstützt den Industrie-Standard GSMA OneAPI v3. Zur weiteren Verarbeitung der Daten exportierten wir diese aus der SQL-Datenbank und nutzen R und Excels statistischen Auswertungsfunktionalitäten sowie D3 und Illustrator zur Visualisierung der Ergebnisse.

Anforderungsanalyse bei IT-Experten mit der Experience-Sample-Methode

137

Dokumentation und Datenanalyse Das Basismaterial für die Analyse bestand aus beantworteten, digitalen Fragebögen, einigen Fotos (insgesamt nur drei) und den Nachbefragungsbögen. Nach der Datenerhebung wurden die gesamten Notizen in ein einheitliches Excel-Format gebracht. Hierbei wurde entschieden, dass das Material zur IT-Sicherheit näher dokumentiert und analysiert werden sollte. Im Anschluss an die Dokumentation erfolgte eine explorativ-interpretative Erschließung der Daten entlang einer systematischen Reduzierung auf Allgemeinheitsniveau und eine Abstraktionsbildung. Dies geschah durch die Bündelung Konstruktion und Integration von Bedeutungseinheiten innerhalb der Daten. Aus diesen Ergebnissen entwickelten wir unser Kategoriesystem (siehe Tabelle 1).

Hauptkategorien (Alle)

Subkategorien

Subkategorien

(IT-Leiter)

(IT-Admin)

Administration

Fehleranalyse, Tests + Log-FileAnalyse, Konfiguration, Support

Fehleranalyse, Tests + LogUpdates, File-Analyse, Konfig-uration, Support, Recherche

Organisation

Tagesplanung/Email, Mitarbeiter-führung

Tagesplanung/Email

Strategie

Beschaffung/Akquisition, Prozessmanagement, Projektbesprechung/-planung

IT-Security-Verfahren, Projektbesprechung/planung. Reiseplanung/Abrechnung

Kommunikation

Dokumentation, Informationstransfer/Meldungen

Dokumentation, Informationstransfer/Meldun gn

Zusatz

ÖPNV, Freizeit

ÖPNV, Freizeit

Tabelle 1: Gebildete Aufgabenkategorien nach Teilnehmergruppen

Nach diesem Vorgehen wurde u.a. ersichtlich, das es zwischen den IT-Administratoren und den IT-Leitern eine größere Varianz in den Aufgabendokumentationen gab. Dies verdeutlichte, dass es zwischen diesen beiden Gruppen unterschiedlich stark wechselnde Tätigkeiten gibt, die sich entsprechend der Rollen innerhalb des Arbeitsalltags einer Organisationsstruktur ergeben. Nichtdestotrotz gab es auch Chimären, die sowohl Administrations- als auch Leitungsaufgaben wahrnahmen.

138

Andreas Thom, Sebastian Meier, Frank Heidmann

Ergebnisse und Visualisierung Es wurden insgesamt 209 Einträge aufgenommen, was einer durchschnittlichen Quote von ca. 42 Einträgen pro Proband über fünf Tage entsprach, siehe [Tab 2]. Zwischen den ITAdministratoren und den IT-Leitern gab es teilweise eine Diskrepanz von ca. 20 Einträgen innerhalb der Studienzeitspanne. Dies bestätigte die Annahme, das Administratoren vor allem tagesaktuelle, intervenierende Tätigkeiten ausführten, während die Leiter eher organisatorisch-strukturelle Tätigkeiten wahrnahmen. Experience Samples

Digital (D)

Analog (D)

Ausgeteilt

8

0

Rücklauf

5

0

ausgewertet

5

0

Durchschnittl. Teilnahmezeit (in Tage)

5

0

Durchschnittl. Einträge

42

0

Durchschnittl. Fotoanzahl

2

0

Nachbefragung (Anz. Teilnehmer)

3

0

Tabelle 2: Zusammenfassung der durchgeführten ESM-Methode

Vor dem Hintergrund der zeitlichen und effizienten Auswertung der Daten wurde im Studienverlauf von uns ein eigener Ansatz in Form einer diagrammbasierten Aufgabenvisualisierung entwickelt. Mit diesem Ansatz wollten wir von den gesammelten Aufzeichnungen der Teilnehmer ein alternatives Bild zu gängigen funktionalen, listenbasierten Darstellungen geben. Hierbei sollten die Aussagen (Tätigkeiten und Aktivitäten) in einer zeitlichen Verlaufsvisualisierung aggregiert und miteinander vergleichbar dargestellt werden. Entwicklung der Visualisierung Auf Basis der gesammelten und kodierten Daten (Kategorien) entwickelten wir zuerst eine Matrix, in welcher wir die einfachen Statements Teilnehmer für Teilnehmer aufgelistet hatten. Zur visuellen Kodierung wurden entsprechend der Wahrnehmung folgende stufenweise Parameter zur Selektion der Informationen verwendet: 1. Stufe: Farben für Aufgabenkategorien 2. Stufe: Geometrische Formen für Einzel bzw. Mehrfachaufgaben Zur Übertragung dieser Parameter wurde eine Diagramm-Matrix erstellt, die eine eindeutige Beziehung zwischen Vorder- und Hintergrundelementen ermöglicht. Diese Diagramm-

Anforderungsanalyse bei IT-Experten mit der Experience-Sample-Methode

139

Matrix repräsentiert hierbei die Dauer einer gesamten Studie (Montag-Freitag) eines Teilnehmers (siehe Abbildung 1).

Abbildung 1: Grundmatrix inkl. Beschriftung X-Achse (Tageszeit) und Y-Achse (Tag)

Jede Zeile stellt einen Studientag eines Teilnehmers dar und beinhaltet 54 Zellen. Jede Zelle repräsentiert wiederum 10 Min. eines Arbeitstages. Die gesamte Zeile eines Tages ist in Zeiteinheiten von je 20 Einheiten unterteilt. Durch den Ablauf der Studie wurde der ganze Tag in die Zeitintervalle vor der Arbeit, während der Arbeit und nach der Arbeit eingeteilt. Die visuelle Kodierung einer individuellen Zelle wird bestimmt durch eine Farbskala und den abgeleiteten Arbeitsaufgaben. Die abgeleiteten fünf Hauptkategorien: Administration, Organisation, Strategie, Kommunikation und Zusatz wurden dem Farbverlauf von Kalt zu Warm (hier in Graustufen) zugeordnet. Jede Hauptkategorie wird entsprechend der identifizierten Sub-Kategorien nochmals visuell unterteilt (siehe Abbildung 2).

Abbildung 2: Legende der Hauptkategorien mit Sub-Kategorien (IT-Administrator)

Die kodierten Daten wurden dann ihrer inhaltlichen Kategorisierung folgend den spezifischen Farben zugeordnet und auf die Matrix übertragen. Wenn die Teilnehmer während der Studie nach einem Trigger in zwei aufeinanderfolgenden Zeitintervallen die gleiche Tätigkeit angaben, wie z.B. „Besprechung zum bevorstehenden Generator-Testlauf“ (Proband 3) um 10:05 Uhr und 10:55 Uhr, dann wurde die offene Zeitspanne der Tätigkeiten zwischen den Einträgen interpoliert. Während der Aufzeichnung der Daten war es auch möglich, dass die Teilnehmer verschiedene Arbeitsaufgaben in kurzer Zeitabfolge oder zur gleichen Zeit durchführten, wie z.B. Emails lesen und den Tagesplan ändern. In diesen Fällen wurden die quadratischen 10 Min.-Blöcke in zwei rechtwinklige Dreiecke aufgeteilt und in zwei Kategorienfarben dargestellt (siehe Abbildung 3). Durch diese Darstellung war es möglich, zwei Aktivitäten in einer Zelle darzustellen. Die Abstände zwischen den Zellen in einer Reihe symbolisierten die Zeitabstände zwischen den dokumentierten Aufgaben. Zur visuellen Unterstützung und Lesbarkeit der Reihen werden Richtungspfeile in den Freiräumen angezeigt.

140

Andreas Thom, Sebastian Meier, Frank Heidmann

Abbildung 3: Detail von Einzel- und Simultanaktivitäten (IT-Administrator)

Ergebnisse und Schlussfolgerungen Der Einsatz der Experience Sample Methode ermöglichte uns einen erweiterten Einblick in die Arbeitsabläufe von IT-Experten jenseits von Interviews und teilnehmender Beobachtung. Der webbasierte Ansatz unseres Studiendesigns erlaubte zudem eine schnelle Anpassung an unterschiedlichste mobile Erhebungskontexte. Aufgrund der webbasierten Speicherung der Daten konnten wir zur Laufzeit einen schnellen Eindruck zur aktuellen Datenlage, zum Verlauf der Studie, zu Unterschieden und Gemeinsamkeiten in der individuellen Arbeitsstruktur erkennen, sowie einen Einblick in die Teilnehmermotivation erhalten. Auf Grundlage der individuellen Diagramme und identifizierten Tätigkeiten, die häufig, weniger häufig oder selten innerhalb der Studienzeit durchgeführt wurden, konnten wir übergreifende Elemente identifizieren. Innerhalb der Tätigkeiten der IT-Administratoren zeigte sich v.a., dass administrative Aufgabenfelder (Konfiguration, Fehleranalysen und deren Beseitigung, Support/Hotline-Aufgaben, Einspielen von Updates) gegenüber bspw. strategischen Erwägungen (IT-Security-Verfahren, Projektbesprechungen/ -planungen, Reiseplanungen) ein Großteil der Arbeitszeit in Anspruch nahmen. Im Gegensatz dazu waren die IT-Leiter stärker auf die strategischen Aspekte (Projektbesprechung/-planung, Mitarbeiterführung, Beschaffung/Akquisition) und kommunikative Aufgaben (Informationsaustausch, Kongressbesuche) konzentriert. Dieser Eindruck variierte vor dem Hintergrund der Einrichtungsgröße und der individuellen, persönlichen Auffassung des Aufgabegebietes eines IT-Leiters. Auf Grundlage dieser stichprobenartigen Erhebung konnten wir mehrere Rollenwechsel innerhalb des Arbeitstages in Zusammenhang mit Aufgaben identifizieren, die sich auf die Gestaltung des Dashboards und seiner Funktionskombinationen auswirkten.

Konzeption vs. Durchführung Da unser Framework auf Grundlage der Cultural-Probes-Methode (Gaver, Dunne, & Pacenti, 1999; Gaver, Boucher, Pennington, & Walker, 2004) für die Erhebung interkultureller Nutzeranforderungen (Thom, Meier, & Heidmann, 2014) entwickelt wurde, achteten wir

Anforderungsanalyse bei IT-Experten mit der Experience-Sample-Methode

141

darauf, dass wir eine einfache Erweiterbarkeit hinsichtlich qualitativer Methoden sicherstellten. Dies ermöglichte uns eine schnelle und einfache Konzeption und Integration des Studiendesigns in unser webbasiertes UX-Observation Framework. Die Verwendung der Trigger (SMS bzw. Email) wurden von den Teilnehmern als positiv und hilfreich bezeichnet. Die zufälligen Versandintervalle waren teilweise für die Teilnehmer nicht adäquat, da es hier vereinzelt zu Irritationen kam. So kam es bei einem Teilnehmer bspw. vor, dass drei SMS innerhalb zu kurzer Zeitintervalle oder nicht zu den individuellen Kernarbeitszeiten empfangen wurden. Ggf. können hier bereits 4 SMS pro Tag ausreichend sein. Um generelle Information zum Studiendesign zu erhalten, wurde den Teilnehmern im Anschluss an die Studie (5-7 Tage) eine Email mit drei Anschlussfragen zugesendet, mit der wir die Qualität des Studiendesigns und der Selbstwahrnehmung der Teilnehmer spiegeln wollten. Bei den Antworten zeigte sich, dass die Teilnehmer vor allem Optimierungsempfehlungen hinsichtlich des Studiendesigns (Arbeitszeit für Durchführung der Studie) und der verwendeten Skalendimensionen abgaben. Zusätzlich wurde ersichtlich, dass es in einigen Fällen zu Herausforderungen in der Koordination der eigentlichen Arbeit und den zu tätigen Dokumentationsaufgaben kam. So konnte bspw. ein Teilnehmer nicht innerhalb der Zeitspanne von + 15 Min. ab Eingang des Triggers seine Tätigkeit dokumentieren. Dies führte zu einer Eintragshäufung, da hier plötzlich mehrere Aufgaben parallel bzw. in kurzer Reihenfolge aufgezeichnet wurden. Die Einträge wurden so teilweise erst 1h später in Ausnahmefällen sogar erst einen Tag später eingegeben.

Zusammenfassung und Ausblick Das eingesetzte Framework konnte, obwohl noch in der Entwicklung, erfolgreich in zwei Studien eingesetzt werden. Die Verwendung der Experience-Sample-Methode schafft vor allem im direkten Anwenderkontext eine wirkliche Alternative zu klassischen Fragebögen und verringert Störfaktoren wie z.B. die situationale soziale Erwünschtheit. Die Erlebnisqualitäten oder Tätigkeiten von Anwendern sind meist nicht umfänglich zu ermitteln, wie im Experten-Interview beschrieben: „Eine der Herausforderungen in der Human-Computer Interaction ist die Verwendung geeigneter Methoden.“ (Obrist, 2009). Sobald Fragen in Umgebungen oder Kontexten beantwortet werden müssen, in der Anwender schlecht zu beobachten sind und sehr unterschiedliche Nutzungssituationen auftreten, dann ist diese Methode unsere erste Wahl. Die meiste Arbeit sollte aus unserer Sicht in den konzeptionellen Aufbau (Planung. Vorbereitung, Durchführung) einer Studie investiert werden, da u.a. darauf zu achten ist, welche Fragen erstellt werden, wie häufig diese Fragesamples ausgespielt werden und ob die Samples variieren. Während der Planung sollte zudem darauf geachtet werden, welche Trigger mit welchem Fragensample verschickt werden. Die Visualisierung in Form unser Diagrammmatrix bildet derzeitig eine Alternative zu herkömmlichen Darstellungen, wie sie in MS Excel in Form von Tabellen oder in

142

Andreas Thom, Sebastian Meier, Frank Heidmann

MAXQDA (MAXQDA, 2015) z.B. als Codeliner oder Textportrait angeboten werden. (Kuckertz, 2007) Literatur Barett, R., Kandogan, E., Maglio, P. P., Haber, E. M., Takayama, & L. A., Prabaker, M. (2004). Field Studies of Computer System Administrators: Analysis of System Management Tools and Practices. In Proceedings of the 2004 ACM conference on Computer supported cooperative work, (S.388395), New York: ACM. Consolvo, S., & Walker, M. (2003). Using the experience sampling method to evaluate ubicomp applications. IEEE Pervasive Computing , 2 (2), 24-31. Csikszentmihalyi, M., & Larson, R. (1987). Validity and Reliability of the Experience-Sample-Method. Journal of Nervous and Mental Disease 175 , 526-536. Froehlich, J., Chen, M. Y., Consolvo, S., Harrison, B., & Landay, J. A. (2007). MyExperience: a system for in situ tracing and capturing of user feedback on mobile phones. In Proceedings of the 5th international Conference on Mobile Systems, Applications and Services (San Juan, Puerto Rico, June 11 - 13, 2007). (S. 57-70). New York: ACM. Gaver, W. W., Boucher, A., Pennington, S., & Walker, B. (2004). Cultural probes and the value of uncertainty. Interactions, 5. Gaver, B., Dunne, T., & Pacenti, E. (1999). Cultural Probes. Interactions , Volume 6 (1), 21-29. Glanznig, M. (27. 04 2015). BeepMe. Abgerufen am 27. 04 2015 von BeepMe: http://beepme.yourexp.at. Hurlbert, R., & Akhter, S. A. (29. 04 2015). Exploring Inner Experience: The Descriptive Experience Sampling Method. Stuttgart, Baden-Würtemberg, Deutschland. Haber, E. M., & Bailey, J. (07). Design Guidelines for System Administration Tools Developed through Ethnographic Field Studies. In Proceedings of the 2007 symposium on Computer human interaction for the management of information technology, 2007, New York: ACM. Kuckertz, U. (24-25. 05 2007). Uni Marburg. Abgerufen am 10. 04 2015 von Uni Marburg: https://www.uni-marburg.de/fb21/ep/downloads/visualisierung. Kahnemann, D., Krueger, A. B., Schkade, D. A., Schwarz, N., & Stone, A. A. (18. 02 2007). http://www.uvm.edu. Abgerufen am 29. 04 2015 von http://www.uvm.edu: http://www.uvm.edu/~pdodds/files/papers/others/2004/kahneman2004a.pdf. Khan, V. J., & Markopoulous, P. (29. 06 2009). EXPERIENCE SAMPLING: A workbook about the method and the tools that support it . Eindhoven, Niederlande. MAXQDA. (05. 05 2015). MAXQDA – The Art of Data Analysis. Abgerufen am 05. 05 2015 von MAXQDA: http://www.maxqda.de. Massachusetts Institut of Technology. (2008). Home: CAES: Context-Aware-Experience Sampling. Abgerufen am 28. 08 2014 von CAES: Context-Aware-Experience Sampling: http://web.mit.edu/caesproject/index.htm. Obrist, M. (7. 10 2009). Experience Sampling – eine Alternative zum klassischen Fragebogen. (I. Ottinger, Interviewer).

Anforderungsanalyse bei IT-Experten mit der Experience-Sample-Methode

143

Roibas, C. A., & Johnson, S. (2008). Use of Experimental Ethno-Methods to Evaluate the User Experience with Mobile Interactive Multimedia Systems. In J. Lumsden, Handbook of Research on User Interface Design and Evaluation for Mobile Technology (S. 16-34). London: Information Science Reference (ICI Global). Stone, A., & Shiffman, S. (1994). Ecological Momentary Assessment (EMA) in Behavioral Medicine. Annals of Behavioral Medicine , 16 (3), S. 199-202. Telekom AG. (05 2015). Global SMS API. Abgerufen am 15. 05 2015 von https://www.developergarden.com/de/apis/apis-sdks/global-sms-api/. Thom, A., Meier, S., & Heidmann, F. (2014). Interkulturelle Nutzeranforderungen erheben – Cultural Probes zwischen Praxis und Forschung. Abgerufen am 15. 01 2015 von http://dl.mensch-undcomputer.de/handle/123456789/3925?discover=true. Wheeler, L., & Reis, H. (1991). Self-Recording of Everyday Life Events: Origins, Types, and Uses.Journal of Personality , 339-354.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 144- 151.

Ein Bild von einem Roboter: Der Care-O-bot 4 als Gentleman Einblicke in den Entwicklungsprozess Johannes Schäfer, Sven Feustel, Ralf Kittmann

Johannes Schäfer

Phoenix Design GmbH + Co. KG Kölner Str. 16 70376 Stuttgart [email protected]

Sven Feustel

Phoenix Design GmbH + Co. KG Kölner Str. 16 70376 Stuttgart [email protected]

Ralf Kittmann

Phoenix Design GmbH + Co. KG Kölner Str. 16 70376 Stuttgart [email protected]

Abstract Gestatten: Care-O-bot 4. Darf ich Ihnen einen Blick hinter die Kulissen geben, wie man einen „Best of the Best“ Roboter gestaltet? – Wir geben Einblicke in den Entwicklungsprozess des „Gentleman“ Roboters, den Phoenix Design zusammen mit dem Fraunhofer IPA und Partnern aus der Industrie entwickelt hat. Mit Bildern zeigen wir den Weg von den ersten Ideen über Funktionsanalyse, MoodCharts, Skizzen und Konzepten über die Materialauswahl, „Emotional Design“ und dem Einbetten in Szenarien bis hin zum Red Dot Award „Best oft he Best“. Der Care-O-bot 4 ist nun bereit, in vielen Anwendungsszenarien und der Forschung eine emotionale User Experience zu ermöglichen.

Keywords Human-Robot Interaction, Emotional Design, UCD-Prozess, UX Design, User Experience

Einleitung Die Entwicklung des Care-O-bot war anfangs geprägt von der technischen Machbarkeit, in Version 3 kam eine bewusste Gestaltung der äußeren Erscheinung hinzu (IPA 2015a, Reiser et al. 2013). Für den Care-O-bot 4 arbeiteten in einem multi-disziplinären Team Designer, Psychologen und Ingenieure zusammen, um einen einzigartigen Roboter zu schaffen.

Ein Bild von einem Roboter: Der Care-O-bot 4 als Gentleman

145

Wir stellen mit vielen Momentaufnahmen aus dem Entwicklungsprozess vor, wie der CareO-bot 4 entstanden ist. Dabei gehen wir auf Funktionsanalyse, Szenarien, Formfindung und Emotional Design ein. Der Beitrag gibt einen Blick hinter die Kulissen, wie ein „Best of the Best“ Roboter entsteht, der für viele Anwendungsszenarien geeignet ist. Der Care-O-bot 4 ist ausgezeichnet gestaltet und bestens ausgestattet, so dass für jede Anwendung eine ideale User Experience entstehen kann. Wie sein Vorgänger der Care-Obot 3 soll er auch der Forschung im Bereich der Mensch-Roboter-Interaktion dienen und bedarf immer der Anpassung an den jeweiligen Einsatzzweck.

Abbildung 1: Übersicht zum Care-O-bot 4 mit Skizzen aus verschiedenen Phasen des Entstehungsprozesses

Funktionsanalyse Zu Beginn des Projekts wurden die Anforderungen an den Care-O-bot 4 gesammelt und bewertet: Es wurden Funktionen aus den Bereichen Reisen, Hospitalität und Wohnen betrachtet, um das Leistungsspektrum abzudecken. Diese wurden den folgenden Bereichen zugeordnet: Transport, Greifen, Interaktion/Kommunikation und Präsenz (siehe Abbildung 2).

Abbildung 2: Funktionsbereiche für den Care-O-bot 4 (Farbkodierung, siehe Abbildung 6)

146

Johannes Schäfer, Sven Feustel, Ralf Kittmann

So findet sich bspw. für „Transport“ auf „Reisen“ die Funktion als Gepäckträger, bei „Hospitalität“ etwa die Begleitung beim Gang zur Toilette und in der Wohnung der Wäschetransport. Für viele Aktivitäten ist das „Greifen“ notwendig, etwa beim Gepäck, dem Tisch decken oder dem Servieren von Getränken. Die „Interaktion“ tritt beim Spielen oder als persönlicher Trainingspartner in den Vordergrund. Der „Präsenz“ des Roboters wurde besondere Bedeutung beigemessen, da er sich zwar im Hintergrund halten soll, aber dennoch spürbar zur Verfügung stehen soll. Über die Präsenz definiert sich zum einen der erste Eindruck, den der Care-O-bot 4 hinterlässt: Dieser soll die Nutzer anziehen und zur Interaktion einladen. Zum anderen vermittelt sie zwischen dem reinen „Anwesend-Sein“ und der Interaktion mit dem Nutzer. Insgesamt bildet sie auch eine emotionale Schnittstelle auf der viszeralen Ebene (Norman, 2004, siehe auch Abschnitt „Emotional Design“). Die Funktionalität wurde im Team diskutiert und priorisiert und leitete damit das Erstellen der Szenarien, die Formfindung und diente immer wieder der Bewertung des Designs.

Szenarien Als Grundbild für den Care-O-bot 4 diente der Archetyp des „Gentleman“ (Abbildung 3), der stets zuvorkommend präsent ist, wenn man ihn wünscht, aber nie aufdringlich wird oder zum reinen Befehlsempfänger verkommt.

Abbildung 3: Entwicklung des Archetyps für den Care-O-bot 4

Früh im Prozess wurden basierend auf der Funktionsanalyse verschiedene Szenarien festgelegt und per Handskizzen veranschaulicht (Abbildung 4). Anhand dieser Szenarien wurden die Vor- und Nachteile sowohl aus technischer als auch aus Nutzersicht diskutiert und durchgespielt. Hierbei wurden auch potenzielle Nutzer außerhalb des Projektteams hinzugezogen, die halfen, die Szenarien zu bewerten und zu verfeinern. Es entstanden erste „Weißmodelle“ (aus Styropor), mit denen die Größenverhältnisse und die Erreichbarkeit von Display bzw. anderer Bedienelemente durch Nutzer getestet wurden.

Ein Bild von einem Roboter: Der Care-O-bot 4 als Gentleman

147

Abbildung 4: Frühe Skizzen für verschiedene Anwendungsszenarien (Servieren, Unterhaltung, Training, Transport)

Durch diese frühen Skizzen wurden die funktionalen Anforderungen besser erfahrbar und dienten so als Grundlage für die weiteren Iterationen im Projekt (Formfindung, Materialwahl und das UX Design); sie wurden im Laufe des Projekts weiter entwickelt, detaillierter ausgearbeitet und dargestellt (Abbildung 10, bis hin zum Film, z.B. IPA 2015b).

Formfindung Ausgehend von unterschiedlichen funktionalen Schwerpunkten wurden vier Konzepte für die Gestaltung entwickelt und anhand der Szenarien visualisiert (Abbildung 5). Dabei spielten Interaktionsdesigner die einzelnen Situationen und Abläufe im Detail durch, z.B. Wie zeigt der Roboter im „Ruhezustand“ seine Bereitschaft an: Pulsierendes Licht? Größenänderung? Wie laufen Bewegungen bei einzelnen Aktionen ab: Entgegenkommen und Nicken? „Natürliche“ Gesten? Was ist die Hauptinteraktion: Tablet, integriertes Display, Projektion?

Abbildung 5: Vier Konzepte im Vergleich eines Interaktionsszenarios (Kaffee servieren)

Anhand dieser Analyse und Visualisierung nahm das Team eine explizite Bewertung der vier Konzepte anhand der vorab definierten Kriterien vor (Abbildung 6). Bei der Formfindung entwarfen die Designer deutlich verschiedene Konzepte, um Vor- und Nachteile der unterschiedlichen Ansätze einschätzen zu können. Wie man deutlich sieht, zeigen die Konzepte verschiedene Schwerpunkte.

148

Johannes Schäfer, Sven Feustel, Ralf Kittmann

Abbildung 6: Bewertung der Konzepte im Funktionsvergleich (Schwerpunkte in Farben, siehe Abbildung 2), von links nach rechts; tailliert, segmentiert, kompakt und skulptural

Über die funktionale Analyse hinaus betrachteten die Ingenieure die technischen Details: Wie ist die Kinematik der Bewegungsabläufe? Welche Greifräume ergeben sich? Welche Gelenke können zum Einsatz kommen? Wo kann die erforderliche Technik untergebracht werden? Dazu kommen Fragen, die sich zwischen Anmutung und Technik bewegen: Lässt sich mit den gewählten technischen Mitteln das Gesamtbild eines „Gentleman“ erreichen? Wirken Bewegungen flüssig und natürlich? Sind die Proportionen stimmig und erscheinen vertraut? In der multi-disziplinären Zusammenarbeit entstand so ein Gesamtbild aus funktionalen und nicht-funktionalen Anforderungen, technischer Machbarkeit und emotionaler Wirkung. Das Konzept „tailliert“ zeichnet sich durch Stärken beim Transport und den großen Greifraum aus. Hinzu kommt ein großer Bildschirm als Interaktionsfläche. Das Konzept „skulptural“ vermittelt eine große Präsenz durch das schlanke Erscheinungsbild und die durch die Segmentierung gegebenen eleganten Bewegungen. In die Stele können unauffällig vielfältige Interaktionsmöglichkeiten integriert werden, z.B. Sensoren, die Bewegungen oder Gesten erkennen, Mikrofone für die Spracherkennung. Am Ende entschieden wir uns für eine Weiterentwicklung basierend auf diesen beiden Konzepten (Abbildung 7). Hier ist das Display in den „Kopf“ integriert, mit dem sich einfach interagieren lässt; zusammen mit dem „Hals“ bietet er Raum für die vielfältigen Interaktionsmechanismen, die der Care-O-bot 4 bietet. Die Form ist symmetrischer geworden, die Arme an die Seiten gewandert; die Beweglichkeit wird durch zwei Kugelgelenke an zwischen Kopf und Körper und zwischen Körper und Basis ermöglicht.

Ein Bild von einem Roboter: Der Care-O-bot 4 als Gentleman

149

Abbildung 7: Zwischenschritt in der Formfindung (Skizzen)

Diese Gelenke sind eine Besonderheit: Sie stellen eine technische Innovation dar (inzwischen patentiert), die durch das Zusammenspiel von Design und Technik auf der Suche nach „anmutigen“ Bewegungen und einer eleganten Form zustande kam.

Emotional Design Wichtig für die emotionale Wirkung des Care-O-bot 4 sind neben der Form auch Material, Farbgebung, ein nicht zu technisches und gleichzeitig nicht zu menschliches Erscheinungsbild (z.B. Mori, MacDorman & Kageki, 2012). Dazu kommen die Posen, die er einnehmen und die Gesten, die er ausführen kann sowie die „Mimik“, mit der er den Nutzern entgegentritt. Um die allgemeine Ausstrahlung des Roboters als Gentleman zu erreichen, sollte die Materialwahl hochwertig, vielseitig und elegant wirken; Formen und Übergänge fließend und gleichzeitig organisch. Hier haben wir viel mit Mood-Bildern gearbeitet (Abbildung 8), die ähnlich wie die funktionalen Kriterien und die Szenarien immer wieder im Entwicklungsteam und darüber hinaus zur Bewertung und Verfeinerung der Entwürfe herangezogen wurden.

Abbildung 8: Auswahl der verwendeten Mood-Bilder im Design-Prozess

Viel Sorgfalt floss in die Gestaltung der Gesten und Posen, die der Care-O-bot 4 einnehmen kann (Abbildung 9). Diese sollten einladen, auf den Roboter zuzugehen und mit ihm zu interagieren. Hierzu wurden z.B. die Arme durch die Farbgebung mit einer Innen- und Außenseite versehen, um möglichst elegante Bewegungen zu erzeugen, bei denen dem Nutzer möglichst immer die Außenseite zugewandt ist.

150

Johannes Schäfer, Sven Feustel, Ralf Kittmann

Abbildung 9: Skizzen und (finales) Rendering für verschiedene Posen des Car-O-bot 4; „natürliche“ Bewegungen und Posen sind ein essenzielles Mittel der User Experience des Care-O-bot 4.

Greifraum und Bewegungsmuster sollten vertraut wirken, ohne „humanoid“ zu werden. Ganz charakteristisch für den Care-O-bot 4 ist die leichte Verbeugung (in der Abbildung rechts außen). Hier kommt die Haltung, die Bewegungsmöglichkeiten an „Hüfte“ und „Hals“ sowie das Display am Kopf sehr gut zur Geltung. Für die Mimik griffen wir auf eine sehr reduzierte Darstellung mittels der Augen zurück, wie sie z.B. im Charakter der „EVE“ oder der Holzfigur Bløk zu finden sind (Walt Disney 2015; Berendsohn, 2015). Hiermit lassen sich im Ruhezustand vielfältige Emotionen zeigen, ohne aufdringlich zu werden. Die Mimik macht Platz für ein großes Touch-Display, sobald dies erforderlich ist (Übergang zum „behavioral level“ nach Norman, 2004).

Fazit Die Gestaltung des Care-O-bot 4 lief in iterativen Zyklen, in denen ein multi-disziplinäres Team ausgehend von den funktionalen Anforderungen über Szenarien und vielfältige Visualisierung das Design immer weiter verfeinert hat. Dabei war es äußerst fruchtbar, von Anfang an sowohl Ingenieure als auch Designer in einem Team zusammen zu haben. Die Schritte Funktionsanalyse, Szenarien, Formfindung und Emotional Design wurden keineswegs linear durchlaufen, sondern in jeder Phase neu betrachtet, da sie sich gegenseitig bedingen und beeinflussen. Durch konsequentes Erfahrbar-Machen der einzelnen Schritte, sei es durch Skizzen, Modelle oder Funktionsstudien, entstand eine neue Generation des Care-O-bot, der sich durch ein nahbares emotionales Erscheinungsbild auszeichnet und die technischen Möglichkeiten für vielfältige Interaktionen bietet. Der Care-O-bot 4 ist wie seine Vorgänger ein „general-purpose“ Roboter, der auf das jeweilige Anwendungsszenario angepasst werden muss (Abbildung 10). Mit seinem Auftreten und den vielfältigen Interaktionsmöglichkeiten, die er bietet, hängt es nun nur noch an der Kreativität der Designer, Ingenieure und Entwickler, eine faszinierende User Experience für die jeweilige Anwendung zu schaffen.

Ein Bild von einem Roboter: Der Care-O-bot 4 als Gentleman

151

Abbildung 10: Zwei mögliche Anwendungsszenarien für den Care-O-bot 4

Literatur Berendsohn AG (2015). Blue Line Kollektion – Bløk, zeigen Sie Ihre Gefühle. http://www.berendsohn.de/blue-line/alfredo-haeberli (letzter Zugriff 29. Mail 2015). IPA 2015a: Fraunhofer Institute for Manufacturing Engineering and Automation). Care-O-bot History. http://www.care-o-bot.de/en/care-o-bot-3/history.html (letzter Zugriff 29. Mai 2015). IPA 2015b: Fraunhofer (Institute for Manufacturing Engineering and Automation). Videos Handtasche: https://www.youtube.com/watch?v=zDSw_bxDLO0), Rose: https://www.youtube.com/watch?v=3n42WbbYGZI (letzter Zugriff 29. Mai 2015). Mori, M., MacDorman, K.F., Kageki, N. (2012). The Uncanny Valley. IEEE Robotics & Automation Magazine, 19(2), 98-100. Norman, D. (2004). Emotional design: Why we love (or hate) everyday things. New York: Basic Books. Reiser, U., Jacobs, T., Arbeiter, G. Parlitz, C. & Dautenhahn, K. (2013). Care-O-bot 3 – Vision of a Robot Butler. In R. Trappl, (Ed.): Your Virtual Butler (p. 97-116). Heidelberg: Springer. The Walt Disney Company (2015). WALL-E – der Letzte räumt die Erde auf: Charaktere. http://filme.disney.de/wall-e/charaktere; http://pixar.wikia.com/EVE (letzter Zugriff 29. Mai 2015).

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 152- 161.

Usability und Smart Home: Aktuelle Herausforderungen und Implikationen Sandra Schering, Jasmin Kuhn, Michael Jendryschik

Sandra Schering

itemis AG Am Brambusch 15 44536 Lünen [email protected]

Jasmin Kuhn

itemis AG Am Brambusch 15 44536 Lünen [email protected]

Michael Jendryschik

itemis AG Am Brambusch 15 44536 Lünen [email protected]

Abstract Smart Home wird immer mehr zu einem Mainstream-Thema. Während sich früher vor allem technikaffine Personen mit dem Thema auseinandergesetzt haben, wird heute auch in „normalen“ Haushalten für den Einsatz entsprechender Hard- und Softwarelösungen geworben. Dies impliziert als nur eine von vielen Herausforderungen, dass die Lösungen einer breiten Nutzergruppe mit verschiedenen Eigenschaften zugänglich sein müssen. Im Rahmen des Usability-Engineering-Prozesses einer SmartHome-Anwendung haben wir durch verschiedene Evaluationen solche Herausforderungen und Fragestellungen identifiziert und diskutieren in diesem Paper mögliche Lösungsansätze.

Keywords Usability, Smart Home, Internet of Things

Einleitung Smart-Home-Lösungen durchdringen immer mehr den Massenmarkt. Während laut statista (2015) im Jahr 2014 3,3 Millionen Smart-Home- und Hausautomatisierungslösungen in Europa installiert wurden, werden für 2017 17,4 Millionen und für 2019 bereits 29,7 Millionen Installationen erwartet. Auch im Alltag wird durch Plakat- und Fernsehwerbung immer mehr für das Thema, dessen Möglichkeiten und Vorteile geworben. Blickt man zurück auf die Geschichte von Smart-Home-Lösungen bzw. klassischer Heimautomatisierung, handelte es sich dabei vor allem um Lösungen für technik-affine

Usability und Smart Home: Aktuelle Herausforderungen und Implikationen

153

Menschen. Zudem war die Automatisierung des eigenen Heims mit enormen Kosten für benötigte Technik und Umbauten verbunden (vgl. Bachfeld & Hansen, 2013). Mittlerweile werben Anbieter von Smart-Home-Lösungen jedoch mit einer einfachen Installation und Bedienung der Geräte und bieten Lösungen in einem bezahlbaren Preissegment an. Durch die damit einhergehende Verbreitung gehen jedoch auch diverse Herausforderungen einher, um die Nutzbarkeit der Systeme durch nicht-technik-affine Menschen sicherzustellen. In diesem Paper sollen eben jene Herausforderungen zusammengefasst werden (s. Kapitel 2). Daran anknüpfend wird in Kapitel 3 das Eclipse Smart Home Framework als Open-SourceLösung vorgestellt, auf dessen Basis eine Oberfläche entwickelt wird, die vor allem dem Aspekt einer einfachen Einbindung von Geräten durch weniger technik-affine Personen gerecht werden soll. Die Oberflächen-Entwicklung erfolgt im Rahmen eines nutzerzentrierten Designprozesses, dessen Methoden und Ergebnisse in Kapitel 4 beschrieben sind. Basierend auf den dabei gesammelten Erfahrungen erfolgt in Kapitel 5 die Ergebnisdiskussion.

Herausforderungen im Smart Home Umfeld Die Hard- und Softwarelösungen für Smart-Home-Geräte und -Anwendungen sind heutzutage vielfältig. Dies geht einerseits damit einher, dass die bereitgestellten Anwendungen von verschiedenen Herstellern auch unterschiedliche Interaktionskonzepte besitzen. Weiterhin ergibt sich ein Netzwerk, in dem manche Geräte stark, andere wiederum nur schwach zusammenhängend sind (UX Magazine, 2013). Stark zusammenhängend werden die Geräte vor allem durch gemeinsame Nutzungsszenarien. Dies ist beispielsweise der Fall, wenn der Nutzer möchte, dass automatisch das Licht angeht, wenn die Rollläden herunterfahren. Schwach zusammenhängende Geräte werden hingegen unabhängig voneinander genutzt, beispielsweise Heizungen und Waschmaschinen. Die Vielfältigkeit von sowie auch Abhängigkeit zwischen den verschiedenen Geräten führen zu einer weiteren Herausforderung: Sowohl das physische Gerät, als auch die Anwendung zur Steuerung müssen von den jeweiligen Nutzern bedient werden können. Einheitliche Normen oder Standards an die Benutzerführung existieren diesbezüglich noch nicht, weshalb sich der Benutzer für jedes Gerät neu mit der Steuerung und den zur Verfügung stehenden Interaktionselementen vertraut machen muss (UX Magazine, 2013). Die weite Verbreitung auf dem Massenmarkt führt zudem dazu, dass die Geräte und Anwendungen für eine äußerst breite Nutzergruppe zugänglich sein müssen: zu den „neuen“ Nutzern zählen nun auch Kleinkinder oder Senioren, entweder als direkte Nutzer oder als indirekte, wenn andere Haushaltsmitglieder entsprechende Geräte installiert haben. Diese unterschiedlichen Nutzergruppen müssen in Bezug auf ihre (technischen) Erfahrungen sowie ihre körperlichen und geistigen Fähigkeiten betrachtet werden (Engelbrecht et al., 2014). Eine mit dem bereits beschriebenen Zusammenwirken verschiedener Geräte zusammenspielende Herausforderung bildet der Bereich um Nutzungsszenarien und Regeln. Dabei erstellt und steuert der Nutzer automatisierte Abläufe. Ein beispielhaft skizzierter

154

Sandra Schering, Jasmin Kuhn, Michael Jendryschik

Ablauf für einen Morgen könnte wie folgt aussehen: Um 7:00 Uhr dimmt das Licht langsam höher, sodass um 7:15 Uhr die volle Lichtintensität erreicht ist. Gleichzeitig wird um 7:00 Uhr die Heizung im Badezimmer vorgewärmt und um 7:20 Uhr fahren die Rollläden im Schlafzimmer hoch. Bei der Erstellung solcher Systeme muss berücksichtigt werden, dass der Nutzer in einen Nutzungszwang geraten kann, der sein Verhalten beeinflusst. Steht beispielsweise jeden Morgen ein Kaffee bereit, so wird der Nutzer diesen wahrscheinlich auch trinken – weil er da ist, nicht aber, weil der Nutzer Lust auf Kaffee hat. Solche fest eingestellten Abläufe müssen sich zudem flexibel anpassen lassen, falls sich der Nutzungskontext ändert: Ist der Nutzer im Urlaub oder krank, wird er wahrscheinlich nicht wollen, dass alle eingestellten Abläufe weiterhin ausgeführt werden. Den oben aufgeführten Herausforderungen zu begegnen, ist Ziel der Entwicklung einer auf dem Eclipse Smart Home Framework aufbauenden Benutzeroberfläche, die Nutzern einheitliche Wege für die Installation und Steuerung von Smart-Home-Geräten bietet. Das Projekt wird nachfolgend beschrieben.

Das Projekt Das Eclipse Smart Home Projekt ist ein Open-Source Framework für die Hausautomatisierung, dessen Entwicklung von der Telekom getrieben wird. Das Projekt existiert seit Anfang 2014. Die itemis AG ist als Mitglied der „Eclipse Internet of Things Industry Working Group“ aktiv an der Entwicklung des Frameworks beteiligt. Der Grundgedanke des Projekts besteht darin, die Entwicklung von Smart-Home-Lösungen in einem heterogenen Umfeld zu vereinfachen, wenn verschiedene Protokolle und Standards unterschiedlicher Smart-Home-Geräte kombiniert werden sollen. Dazu wird für jedes Gerät, mit dem kommuniziert werden soll, ein sogenanntes „Binding“ implementiert, das das Gerät mit dem Framework bekannt macht, sodass es sich über eine einheitliche Oberfläche steuern und mit anderen Komponenten vernetzen lässt. Die Entwicklung einer solchen Oberfläche ist Ziel eines internen Entwicklungsprojektes der itemis AG. Ausgangspunkt für dieses Projekt war die Feststellung eines Mitentwicklers des Eclipse Smart Home Frameworks, dass es keine geeignete Oberfläche für dieses gibt, die weniger technisch affinen Nutzern eine einfache Einbindung von Geräten ermöglicht. Eine erste Version der Oberfläche wurde zunächst vom entsprechenden Entwickler ohne Einbezug von Usability-Methoden umgesetzt und erst zu einem späteren Zeitpunkt dem UsabilityTeam der itemis AG zur näheren Analyse und Verbesserung vorgelegt. Grund für die Zusammenarbeit war die Feststellung des Entwicklers, dass ihm nicht genau bekannt war, was die Nutzer tatsächlich benötigen und wie er diesen die einzelnen Funktionen benutzergerecht zur Verfügung stellen und anzeigen kann. Die Benutzeroberfläche und die dahinter stehende Anwendung adressieren verschiedene Use Cases. Der Fokus liegt primär auf einer einfachen Anbindung verschiedener Smart-HomeGeräte. Ziel ist es, geräteunabhängige, verständliche und einheitliche Wege anzubieten, die Geräte mit der Anwendung zu verbinden. Darüber hinaus kann über die Benutzeroberfläche

Usability und Smart Home: Aktuelle Herausforderungen und Implikationen

155

auf alle konfigurierten Geräte zugegriffen und diese gesteuert werden. In der Oberfläche stehen dem Nutzer darüber hinaus verschiedene Konfigurationsmöglichkeiten zur Verfügung. Dabei geht es insbesondere um Möglichkeiten der Darstellung der angebundenen Geräte, z. B. durch die Organisation dieser in verschiedenen Gruppen. Auch soll die Anwendung zukünftig die Möglichkeit bieten, Regeln bezüglich des Zusammenspiels verschiedener integrierter Smart-Home-Geräte zu erstellen und zu visualisieren. Durch den laufenden Entwicklungsprozess konnten bereits erste Erkenntnisse hinsichtlich dieser Use Cases gewonnen werden. Diese sind im nächsten Kapitel beschrieben.

Evaluation der Smart Home Anwendung Um die Gebrauchstauglichkeit der Eclipse-Smart-Oberfläche sicherzustellen, werden gemäß DIN EN ISO 9241-11 drei grundsätzliche Ziele verfolgt: Erstes Ziel ist, dem Nutzer die Funktionen zur Verfügung zu stellen, die er benötigt, sodass er die von ihm gewünschten Aktionen ausführen kann (Effektivität). Dazu zählen primär das Anschließen und Steuern von Geräten, die er in seinem Smart Home im Einsatz hat oder einsetzen möchte. Darüber hinaus soll er dies in einer angemessenen Zeit schaffen können (Effizienz), weshalb ein möglichst einheitliches, geräteübergreifendes Konzept für Setup und Steuerung angeboten werden sollte. Drittens liegt der Fokus auf der Sicherstellung der Verständlichkeit der Anwendung sowie der Zufriedenheit des Nutzers während des Gebrauchs. Verschiedene Usability-Methoden sollten dabei helfen, diese Ziele zu erreichen (s. Abb. 1). Da vor dem Start der Einbindung von Usability-Maßnahmen in den Entwicklungsprozess der Benutzeroberfläche bereits eine erste Version vorlag, diente eine Heuristische Evaluation als Einstiegspunkt. Für entsprechende Evaluationen eignen sich die zehn Kriterien zur Bewertung der Usability in Smart-Home-Umgebungen aus Engelbrecht et al. (2014, S. 11). Grundsätzlich konnte durch die heuristische Evaluation festgestellt werden, dass die Oberfläche zwar die Möglichkeit bietet, alle Smart-Home-Geräte, für die ein Binding existiert, mit der Anwendung zu verbinden und diese zu steuern; allerdings auf eine umständliche und für den Nutzer nicht nachvollziehbare Art. Das bis zu diesem Zeitpunkt umgesetzte Interaktionskonzept verlangte vom Nutzer viele unnötigen Interaktionsschritte, bis ein Gerät tatsächlich verbunden und der Nutzer somit in der Lage war, dieses zu steuern. Bereits basierend auf den Ergebnissen der heuristischen Evaluation wurde die Benutzeroberfläche grundlegend überarbeitet. Die aktualisierte Version wurde anschließend in einem Usability-Test mit typischen Endanwendern evaluiert. Da das Feedback der Evaluation aufzeigte, dass insbesondere die Anbindung von Smart-Home-Geräten an die Anwendung für die meisten Probleme sorgt, wurde das Interaktionskonzept für den SetupProzess vollständig überarbeitet und in einem weiteren Usability-Test basierend auf Papierprototypen getestet. Nachfolgend werden die durchgeführten Usability-Tests mit ihren Ergebnissen sowie das resultierte Interaktionskonzept im Detail beschrieben.

156

Sandra Schering, Jasmin Kuhn, Michael Jendryschik

Abbildung 1: Bisherige Aktivitäten im Rahmen des Usability-Engineering-Prozesses

Usability-Test der Gesamtanwendung Die Integration echter Nutzer in den Entwicklungsprozess ist zwingend erforderlich – am besten bereits vor Beginn der Entwicklung, um die Nutzer und deren Aufgaben innerhalb des Nutzungskontexts zu verstehen und basierend auf diesen Erkenntnissen die Benutzerschnittstelle zu entwerfen. Wie in der Praxis leider häufig anzutreffen ist, startete die Entwicklung auch hier ohne jeglichen Einbezug von Nutzern allein basierend auf den Erfahrungen, Kenntnissen und – auch gestalterischen – Fähigkeiten der Entwickler. Bereits die heuristische Evaluation hat gezeigt, dass diese Vorgehensweise massive Nutzungsprobleme mit sich gebracht hat. Ein Usability-Test sollte daher untersuchen, wie die Nutzer grundsätzlich mit der Oberfläche zurechtkommen, aber auch, um dem Entwickler aufzuzeigen, wo große Schwachstellen existieren. Dabei wurde Wert darauf gelegt, Nutzer mit verschiedenem Kenntnisstand zu rekrutieren, um mögliche Einflüsse in die Analyse einbeziehen zu können. Zwei der rekrutierten Probanden wiesen noch keine praktische Erfahrung mit Smart-Home-Anwendungen auf, interessierten sich jedoch stark für das Thema. Die anderen drei Probanden haben bereits Smart-Home-Geräte genutzt, wobei zwei dieser Probanden eigene Geräte in ihrem Haushalt installiert haben. Im Rahmen des Usability-Tests sollten die Probanden zwei Aufgaben erfüllen: (1) das Entpacken und physische sowie virtuelle Anschließen einer Philipps Hue, einem System bestehend aus einer Bridge und einer Lampe, sowie (2) die Steuerung der Hue Lampe (Lampe einschalten und blau leuchten lassen). Keiner der Probanden hatte zuvor die Philipps Hue verwendet, sodass der Kenntnisstand der Probanden diesbezüglich gleich war. Die Ergebnisse des Usability-Tests zeigten, dass kein Proband ohne Hilfe in der Lage war, die Philipps Hue anzuschließen und die Lampe zu steuern. Wesentliche Probleme wurden vor allem durch technische Bezeichnungen in der Oberfläche verursacht. So wurde hier eine Unterscheidung in „Things“, „Items“ und „Bindings“ vorgenommen, die für die Nutzer nicht verständlich war. Diese Begriffe betiteln Bereiche in der Oberfläche, in denen Konfigurationen vorgenommen werden müssen, um die Hue anzuschließen. So muss im Bereich der „Bindings“ das Protokoll für die Hue ausgewählt werden. Im Bereich „Items“ musste die Bridge konfiguriert sowie eine Gruppe angelegt werden, der die Lampe später

Usability und Smart Home: Aktuelle Herausforderungen und Implikationen

157

zugefügt werden sollte. Erst im Bereich „Things“ konnte dann die konkrete Lampe hinzugefügt werden. Das bis zu diesem Zeitpunkt vorhandene Konzept wurde von keinem Nutzer verstanden. Dies zeigte vor allem, dass sich die mentalen Modelle vom Entwickler sowie von den Nutzern unterscheiden. Weiterhin wurde deutlich, wie wesentlich eine klare Benutzerführung ist, die dem Nutzer genau verdeutlicht, wie er das Smart-Home-Gerät anschließen muss. Insbesondere bei der Hue wurde dies deutlich, da – anders als bei direkt WLAN-fähigen Geräten – zunächst die Bridge als Empfangsstation (vergleichbar mit einem Router) angeschlossen werden muss und erst dann die tatsächliche Lampe in der Oberfläche erkannt werden kann. Diese Trennung der Geräte führte bei allen Probanden zu Verwirrung. Weiterhin zeigte sich deutlich, dass es beim Thema Smart Home nicht nur um die Usability der Benutzeroberfläche geht, sondern auch um die des verwendeten Smart-Home-Geräts. So hatte es ein Proband zwar mit Hilfestellung geschafft, die Hue in die Benutzeroberfläche zu integrieren, konnte diese aber nicht steuern – der physikalische Schalter der Lampe stand auf „Aus“. Die eigentliche Steuerung der Lampen führte zu keinen Problemen bei den Probanden. Dies erfolgt in einem separaten Control-Bereich (s. Abb. 2) mittels Schiebereglern und An-/Aus-Schaltern. Angemerkt wurden diesbezüglich vor allem Aspekte der Benennung: so wurden zum Teil gleiche Benennungen für inhaltlich unterschiedliche Aktionen verwendet.

Abbildung 2: Control-Bereich zur Steuerung angeschlossener Geräte

Interaktionskonzept Setup-Prozess Da der Setup-Prozess die Nutzer vor die größte Hürde gestellt hat, wurde der Fokus im weiteren Vorgehen auf die Optimierung des Gerätesetups gesetzt. Basierend auf den Erkenntnissen aus dem ersten Usability-Test wurde innerhalb des Usability Engineering

158

Sandra Schering, Jasmin Kuhn, Michael Jendryschik

Teams ein neues Interaktionskonzept für diesen Prozess entwickelt. Neben den Erfahrungen der Teammitglieder wurden darüber hinaus Interaktionskonzepte vergleichbarer Systeme zur Steuerung von Smart-Home-Objekten bei der Gestaltung berücksichtigt. Da in Kapitel 2 als eine wesentliche Herausforderung herausgestellt wurde, dass Interaktionskonzepte zwischen den verschiedenen existierenden Systemen variieren, wurde als wichtig erachtet, in der Benutzeroberfläche ein einheitliches Vorgehen für alle Geräte anzubieten. Dazu wurde zuerst ein Grobkonzept entworfen, das den kürzesten Weg zum Ziel – also die Mindestanzahl an nötigen Schritten – wiederspiegelt, die ein Nutzer durchführen muss, um ein Gerät mit der Anwendung zu verbinden und in den Kontrollbereich zu gelangen. Auf Basis dieses Konzepts wurden weitere Handlungsabläufe aufgenommen, um auch vom Idealfall abweichende Situationen darstellen zu können. Dies sind z. B. Situationen, in denen ein Gerät nicht direkt WLAN-fähig ist und eine zusätzliche Empfangsstation benötigt wird, oder ein Gerät nicht automatisch von der Anwendung erkannt wird und somit manuell hinzugefügt werden muss.

Abbildung 3: Schritt 1 im Wizard zum Gerätesetup

Der neue Setup-Prozess ist als Wizard aufgebaut, der dem Nutzer klar beschreibt, was dieser als nächsten Schritt ausführen muss. Essentiell für die Unterstützung von weniger technikaffinen Nutzern ist, dass die Anwendung Smart-Home-Geräte automatisch erkennt, wenn der Nutzer diese dem Netzwerk hinzufügt, und anschließend im Bereich „Add new thing“ (s. Abb. 3) anzeigt. Darüber hinaus wurde in dem neuen Interaktionskonzept viel visuell gearbeitet. Zum Beispiel werden die einzelnen Smart-Home-Objekte durch Fotos dieser repräsentiert. Diese Abbildungen sollen dem Nutzer dabei helfen, die Geräte zu erkennen und zu verstehen, welches Gerät er in welcher Reihenfolge mit der Oberfläche verbinden muss. So wird ihm z. B. zunächst nur die Hue Bridge angezeigt und erst nach deren Anschließen die einzelnen Lampen. Durch Selektion eines der angezeigten Geräte leitet die Anwendung den Nutzer weiter durch den Prozess. Im nachfolgenden Schritt hat er die Möglichkeit, dem Gerät einen eigenen Namen zu geben. Handelt es sich um Geräte ähnlich einer Empfangsstation wie die Hue Bridge, werden dem Nutzer anschließend alle zur Verfügung stehenden Geräte, welche von der Station erkannt wurden, angezeigt, damit auch

Usability und Smart Home: Aktuelle Herausforderungen und Implikationen

159

diese der Anwendung hinzugefügt werden können. Hier kann er auswählen, welches Gerät er anschließen möchte und auch diesem einen eigenen Namen geben. Handelte es sich beim ersten Schritt um ein Gerät, welches direkt bedient werden kann (direkt WLAN-fähig), entfällt dieser Schritt. Zuletzt hat der Nutzer die Möglichkeit, die zugefügten Geräte einer bestehenden Gruppe (z. B. Wohnzimmer) zuzufügen oder zunächst eine neue Gruppe anzulegen. Diese Gruppen sind zentral für den Control-Bereich, da die Geräte dort basierend auf den Gruppen geordnet sind (s. Abb. 2). Abschließend erhält der Nutzer eine Bestätigung, dass das Gerät hinzugefügt wurde und wird zum Control-Bereich geleitet, in dem er dann mit dem Gerät interagieren kann. Falls die Anwendung ein Smart-Home-Gerät nicht automatisch erkennt, kann der Nutzer dieses manuell hinzufügen. Dazu kann er aus allen in der Oberfläche verfügbaren Bindings das auswählen, für das er ein Gerät anschließen möchte. Auch hier wird wieder Gebrauch von Abbildungen gemacht, um den Nutzer visuell bei der Auswahl zu unterstützen und nicht durch technische Begriffe zu verwirren. Nachfolgend wählt er wiederum entweder ein konkretes Gerät aus, wenn dieses direkt WLAN-fähig ist, oder zunächst eine Empfangsstation. Der einzige Unterschied zur automatischen Erkennung ist hier, dass der Nutzer je nach Binding manuelle Eingaben machen muss, etwa die Eingabe einer IP-Adresse oder Geräte-ID.

Usability-Test des Setup-Prozesses Im Rahmen einer zweiten Usability-Evaluation wurde das neue Interaktionskonzept für den Setup-Prozess überprüft. Das Konzept selbst wurde zunächst in Form eines Papierprototypen umgesetzt, um frühes Nutzerfeedback noch vor der Implementierung zu erhalten. Für diesen Usability-Test wurden weitere fünf Endnutzer rekrutiert, die hinsichtlich der Vorerfahrung mit Smart Home der Nutzergruppe aus dem ersten Test gleichen. Die Probanden sollten einerseits eine Hue (Bridge und Lampe) und andererseits eine LIFX (Lampe ohne Bridge) anschließen. Grundsätzlich erkennt die Anwendung beide Lampen automatisch, für den Test wurde allerdings simuliert, dass die LIFX nicht erkannt und somit manuell durch die Eingabe der Device-ID angeschlossen werden muss. Die System Usability Scale (Brooke, 1996) sollte anschließend einen Eindruck über die subjektive Einschätzung der Usability und Learnability der Oberfläche durch die Probanden liefern. Grundsätzlich konnte durch den Usability-Test gezeigt werden, dass der neue Setup-Prozess den Nutzer deutlich besser anleitet, als dies zuvor der Fall war. Die Hue konnte von allen Probanden schnell und problemlos angeschlossen werden. Dabei unterstützten laut der Nutzer vor allem die Abbildungen der Bridge und der Lampen sowie die klare Benutzerführung, was in welcher Reihenfolge angeschlossen werden muss. Diese Benutzerführung half den Nutzern auch bei der manuellen Installation der LIFX. Interessant war hier, dass der Begriff des „Bindings“ keine Probleme verursachte, da sich die Probanden an den Abbildungen der Geräte orientierten und für sie dadurch klar war, was sie auswählen sollten. Problematisch war vielmehr, die Device-ID einzugeben, da die Probanden hier nicht wussten, an welcher Stelle diese auf der Verpackung des Geräts zu finden ist. Grundsätzlich konnte durch den neuen Setup-Prozess ein SUS-Score von 76,5 (SD = 9.1) erreicht werden, wobei die Usability mit 72,5 und die Learnability mit 92,5 bewertet wurde.

160

Sandra Schering, Jasmin Kuhn, Michael Jendryschik

Diskussion und Implikationen Die neu entwickelte Benutzeroberfläche soll verschiedenen Herausforderungen, die mit Smart Home einhergehen (s. Kapitel 2), entgegen wirken. Aktuell steht der Entwicklungsprozess noch relativ am Anfang. So wurde nach einer Gesamtevaluation der Anwendung zunächst ein Fokus auf einen geräteübergreifenden, einheitlichen Setup-Prozess gelegt, da das Gerätesetup die Probanden vor die größte Hürde stellte. Während viele Hersteller für ihre Geräte eigene Apps zur Verfügung stellen, erlaubt es die Anwendung dagegen, die einzelnen Geräte über eine einzige Oberfläche anzusprechen, was als wesentlicher Vorteil zu sehen ist. Als zentral hat sich für die Gestaltung der Anwendung auch gezeigt, dass Abbildungen einzelner Geräte in der Anwendung für ein Verständnis des Prozesses durch Nutzer, die bisher noch nicht mit Smart Home in Kontakt gekommen sind, unterstützend wirken. Dies ist insbesondere hilfreich, wenn vor der Verbindung des eigentlich zu steuernden Geräts Empfangsstationen eingerichtet werden müssen. Eine klare Benutzerführung ist hier essentiell. Grundsätzlich ist geplant, die Anwendung kontinuierlich weiterzuentwickeln und dabei eine enge Zusammenarbeit zwischen den Entwicklern und dem Usability Engineering Team zu fördern. Wir haben diesbezüglich die Erfahrung gemacht, dass der Mehrwert unserer Usability-Aktivitäten für die Entwickler vor allem durch die Durchführung der UsabilityTests ersichtlich wurde. Zwar erhielten wir schon nach der heuristischen Evaluation das Feedback, dass wir wichtige Aspekte identifiziert hätten, die vorher aus Entwicklersicht nicht aufgefallen seien; die Sichtung realer Nutzerproblemen in den Usability Tests verstärke jedoch die Motivation der Entwickler, weiterhin einen nutzerzentrierten Designprozess zu verfolgen. Deshalb ist im nächsten Schritt eine Nutzungskontextanalyse angestrebt. Wie bereits erwähnt, wurde diese aufgrund des späten Einbezugs des Usability Teams in den Prozess bisher noch nicht durchgeführt. Dies ist nach DIN EN ISO 9241 jedoch zwingend notwendig, um den Nutzer in seinem Kontext sowie seine mentalen Modelle verstehen und darauf basierend Anforderungen ableiten zu können. Neben einer übergreifenden Betrachtung wird hier ein Fokus auf der Regelerstellung und -bearbeitung in der Anwendung liegen, um Ideen zur Begegnung der entsprechend in Kapitel 2 aufgeführten Herausforderungen generieren zu können. Insgesamt hat sich bereits durch die ersten Evaluationen gezeigt, dass die nutzergerechte Gestaltung von Smart-Home-Anwendungen ein komplexes Feld ist, da verschiedene Faktoren und Herausforderungen berücksichtigt werden müssen. Das Nutzerfeedback zur entwickelten Benutzeroberfläche zeigte jedoch, dass wir bezüglich unserer Arbeit auf dem richtigen Weg sind, eine Anwendung zu gestalten, die vielen der Herausforderungen begegnet.

Usability und Smart Home: Aktuelle Herausforderungen und Implikationen

161

Literatur Bachfeld, D. & Hansen, S. (2013). Home, smart Home! Bequeme Steck- und Funktionslösungen im Einsatz. heise online, 9. http://www.heise.de/ct/artikel/Home-smart-Home-1834136.html (Stand: 29.05.2015). Brooke, J. (1996). SUS: a ‘quick and dirty’ usability scale. In: Jordan, P., Thomas, B., Weerdmeester, B., McClelland, I. (Hrsg.), Usability Evaluation in Industry. Taylor & Francis London, S. 189-194. Engelbrecht, K.-P., Ehrenbrink, P., Hillmann, S. & Möller, S. (2014). Messung und Bewertung der Usability in Smart Home-Umgebungen, In VDE Kongress 2014. Smart Cities - Intelligente Lösungen für das Leben in der Zukunft. Frankfurt am Main. Statista (2015). Installed base of home automation/smart home systems in Europe from 2012 to 2019 (in millions). http://www.statista.com/statistics/286815/smart-home-systems-installed-in-europe/ (Stand: 29.05.2015) UX Magazine (2013). Home Automation: The next frontier for UX? UX Magazine, 966, http://uxmag.com/articles/home-automation-the-next-frontier-for-ux (Stand: 29.05.2015).

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 162- 171.

sunnyplaces.com – Lean UX-Design B2C-Portal-Entwicklung für private Solaranlagenbesitzer von der Biz-Idee bis zum Market Rollout Oliver Gerstheimer, Oliver Endemann, Andreas Strusch

Dipl.-Des. Oliver Gerstheimer chilli mind GmbH Königstor 23 34117 Kassel [email protected]

Dipl.-Des. Oliver Endemann chilli mind GmbH Königstor 23 34117 Kassel [email protected]

Andreas H. H. Strusch SMA Solar Technology AG Sonnenallee 1 34266 Niestetal [email protected]

Abstract Die Nutzung von Design-Thinking-Methoden in der Geschäftsmodellentwicklung und der strategischen Marktpositionierung ist genauso wichtig wie das agile User-Experience- und Design-Handwerk in der Ausgestaltung, um erfolgreich kundenzentrierte, digitale Neuprodukte zu launchen. Im zukunftsrelevanten Segment der erneuerbaren Energien wurde die Überwachung von Photovoltaik(PV)-Anlagen in der Vergangenheit überwiegend für Techniker konzipiert. Energie- und Ertragsdaten blieben ohne Mehrwert und Erlebnis für den privaten Anlagenbesitzer, Solaranlagen waren „gesichtlos“. Ein Portal zum effektiven und effizienten Überwachen von PV-Anlagen mit einem „Joy of Use“ für den Nutzer und der Möglichkeit zum Erfahrungsaustausch in einer Solar-Community fehlte bisher. Gemeinsam mit dem Weltmarktführer für Solarwechselrichter, der SMA Solar Technology AG, wurde dazu ein „Lean Start Up“-Projekt in nur acht Monaten realisiert: von der Idee über Konzeption, Entwurf und Programmierung bis zum erfolgreichen Marktlaunch des ersten B2C-PV-CommunityPortals.

Keywords Lean-UX, User Centered Development, Service Design, Design Thinking

sunnyplaces.com – Lean UX-Design

163

Prolog: Was ist eigentlich ein Lean-UX-Prozess? "Lean UX also lets us change the way we talk about design. Instead of talking about features and documents, we can talk about what works." [1] Lean UX, Jeff Gothelf

Ein internationales Portal-Projekt innerhalb von 8 Monaten zu planen, umzusetzen und erfolgreich zum Zieltermin zu launchen, erfordert ein agiles und diszipliniertes Vorgehen. Viele Entwicklungsschritte müssen parallel statt nacheinander erfolgen, Konzepte müssen in schneller Abfolge erzeugt werden, Lösungen in Teillösungen zerlegt und iterativ evaluiert und optimiert werden. Über der ganzen Entwicklung steht der Fokus, die Anforderungen möglichst „schmal“ (lean) zu halten, ohne dass die User Experience geschmälert wird, die notwendig ist, um das Projekt von Anfang an erfolgreich zu machen. Es gilt also nicht, all die hervorragenden Ideen umzusetzen, die man in der Anfangsphase so hat, sondern sich die wichtigsten davon herauszusuchen und diese konsequent sowie bestmöglich umzusetzen. Dies mit dem Ziel, in einem Sprintprojekt diejenigen Funktionen und Features auszusortieren bzw. zurückzustellen, die mit gegebener Zeit und monetärem Budget nicht sicher realisierbar sind. Die priorisierten Funktionen werden im Sinne der Lean-UX-Methode (Think – Make – Check) entwickelt. Das bedeutet etwas verkürzt, es werden Lösungsansätze für gestellte Probleme erzeugt (Think), welche in Simulationen oder Prototypen (Make) mit Experten und Endanwendern überprüft werden können (Check). Die teilweise experimentell gewonnenen Erkenntnisse fließen in die jeweils folgende Iteration bzw. die finale Lösung ein. Eine wichtige Randbedingung für einen „Lean-UX-Prozess“ mit hohem agilen Anteil ist eine drastische Reduktion von Dokumentationen und Spezifikationen, einhergehend mit kurzen Kommunikationswegen und schnellen Freigabeprozessen.

Ansatzpunkt und Zielsetzung „Sunny Places: Smart. Simple. Sharable.“ http://www.sunnyplaces.com

„Green Energy“, also das Wissen um regenerative Energiequellen, deren Nutzung und Entwicklung, sowie der bewusste Umgang damit sind absolut essenziell für die Zukunft. Der Rückgang von Subventionen für erneuerbare Energien – in Deutschland die Einspeisevergütungen im Rahmen des Erneuerbare-Energien-Gesetzes (EEG) – haben zu einem erheblichen Rückgang im Photovoltaik-Markt und bei Investitionen in Neuanlagen

164

Oliver Gerstheimer, Oliver Endemann, Andreas Strusch

geführt. Anlagenanbieter und Installateure sind somit gezwungen, aus der langjährigen Komfortzone der etablierten B2B2C-Vermarktung herauszutreten und neue Wertschöpfungsnetze zu entwickeln. Der direkte Weg zum Endkunden (B2C) erfordert eine treffgenaue Planung sowie innovative Produkte und Services. Neues Denken im Bereich der Geschäftsmodelle und Markt-Positionierungen sind dafür ebenso notwendig wie das Handwerk der User-Experience-Spezialisten, um am Markt weiterhin und zunehmend erfolgreich zu sein. Ergebnis dieser Überlegungen ist die Umsetzung des ersten weltweiten Community-Portals für private Solaranlagenbesitzer. Im Rahmen eines agilen UX-Design-Prozesses und mit Unterstützung von Design-ThinkingAnsätzen wurden Endkundenbedürfnisse identifiziert und konsequent umgesetzt. Daraus abgeleitet steht stellvertretend die unterschwellige Projekt-Mission: „Einer Solaranlage in zweifacher Hinsicht ein Gesicht geben.“ Denn nicht die Solaranlage steht primär im Fokus der Aufmerksamkeit, sondern auch der Anlagenbetreiber/Anlagenbesitzer als Person. Unterstützt wird der Nutzer dabei durch einfache, selbsterklärende Funktionen und eine Plattform zum Austausch mit anderen Nutzern und Experten. Dies ist umso wichtiger, da sich bisherige Solar-Portale primär an technisch versierte Nutzer und professionelle Betriebsführer richteten. Weiterhin bietet die Umsetzung des Portals in einem responsiven Framework und als Web-App eine hohe Usability auf stationären und mobilen Endgeräten. So verbindet das zur Messe „Intersolar 2014“ gelaunchte Portal „Sunny Places“ an einem Ort auf seinem „Portalinterface“ ein einfaches Anlagen-Monitoring mit einem hohen „Joy of Use“ und den Vorteilen einer Online-Solar-Community.

Abbildung 1: Beispiel User Interface – Dashboard mit Community

sunnyplaces.com – Lean UX-Design

165

Umsetzung des Projekts Strategische Markt- und Bedürfnisanalyse Eine Besonderheit bei der Entwicklung des Community-Portals war die enge Kopplung an ein bestehendes Solar-Portal (SMA Sunny Portal) und die damit einhergehende Herausforderung, die fachspezifischen und geübten Visualisierungen mit Respekt zu behandeln und trotzdem der spezifischen Community-Zielgruppe ein neues Portal und damit auch ein neues Benutzererlebnis zu bieten, welches sich positiv weitererzählen lässt. Ein Bestand von über 180.000 PV-Anlagen im bestehenden Portal eröffnete eine geschätzte Teilmenge von ca. 30.000 kleineren bis mittleren PV-Anlagen, die potenziell durch den Anlagenbesitzer oder dessen Installateur mit einem Klick in das neue Portal übernommen werden können. Weiterhin bestand ein zentrale Aufgabe in der Konzeption einer realistischen Darstellung von „simulierten PV-Anlagen“, die eine WIN-WIN-WIN-Situation für PV-Interessierte, Solar-Installateure und dem Portalanbieter bzw. Produzenten von WechselrichterTechnologie herstellt. Der Interessent erlebt durch diese Simulation einen Einstieg in die PVWelt und kann abschätzen, was an seinem Standort mit welcher Anlage an Ertrag zu erzielen ist und inwieweit eine Unabhängigkeit von Energieversorgern und Strompreiserhöhungen erreicht werden kann. Der regionale Installateur kann über diese Simulationen neue Kunden gewinnen und der Wechselrichterhersteller kann sowohl seinen Abverkauf steigern wie auch durch die Datenauswertung und das Nutzerverhalten seine Produktstrategie anpassen bzw. optimieren.

Die Produkt-/Service-Ideation und Business-ModelPositionierung Vor dem Hintergrund der oben beschriebenen Veränderungen im nationalen, europäischen und globalen Subventionsmarkt für Solaranlagen und erneuerbare Energien wurde folgerichtig vom Auftraggeber die Notwendigkeit erkannt, neue Services und Produkte zu entwickeln, um den Endanwender direkter anzusprechen und zu binden. Initialer Ausgangspunkt des Projekts war somit eine Business Model Ideation zur strategischen Ideenfindung. Im Vorfeld wurde hierzu neben einem ausführlichen Benchmark von Portalen aus den Bereichen Solartechnologie, regenerative Energien, Social Media und Community-Portalen, inkl. Bewertung und Priorisierung von Funktionen und Lösungen, auch eine Analyse der „Best Practices“ von internationalen Portalen durchgeführt. Zur Anforderungsanalyse aus Benutzersicht wurden Zielgruppen identifiziert und eine umfangreiche Umfeldanalyse mit kontextuellen Fokusinterviews zu den Bereichen

166

Oliver Gerstheimer, Oliver Endemann, Andreas Strusch

Anlagenmonitoring, Ertrags- und Eigenverbrauchsoptimierung Community-Funktionalitäten durchgeführt.

in

Verbindung

mit

In einem dritten Schritt wurden die Ergebnisse dieses „Vorprojekts“ gemeinsam mit Experten aus der Portal-Entwicklung, Produktmanagement sowie Marketing & Sales in insgesamt 10 Fokusgruppen und weiteren 25 Leitfadeninterviews evaluiert, fusioniert und in Form einer strategischen Positionierung des Portals sowie eines kontextuellen Anforderungsmangements dokumentiert.

Abbildung 2: User Interface – Beispiel Energie-/Anlagenvergleich

UX-Methoden im agilen Lean-Start-Up-Prozess bei der UIDesign- und Portalumsetzung Das Vorgehen in einem agilen Entwicklungsprozess unterscheidet sich an mehreren Stellen grundlegend von den klassischen Vorgehensweisen, z. B. im Rahmen eines starren Produktentwicklungsplans. Das Vorgehen setzt verstärkt auf Flexibilität und Anpassung, anstatt zu Beginn eines Projekts umfangreiche und ausführliche Planungen umzusetzen. Kerneigenschaften eines agilen Vorgehens sind eine adaptive, also flexible Planung sowie kurzfristige Abstimmungen innerhalb des Projektteams.

sunnyplaces.com – Lean UX-Design

167

So wurden in der Planungsphase zu Beginn des Projekts lediglich zweiwöchige SprintPhasen verabredet, in denen jeweils die aktuellen Aktivitäten und Verantwortlichkeiten, Projektmeilensteine mit Status, geplante Aktivitäten für den nächsten Sprint und die Einschätzung aktueller Projektrisiken dokumentiert wurden. Konzept- und Designphase Die Konzeptphase des Projekts war geprägt von einem iterativen Vorgehen sowie der Einbeziehung von Experten und potenziellen Nutzern in den Entwurfsprozess. So wurden z. B. auf Basis des oben beschriebenen Anforderungsmanagements prototypische Personas definiert, auf deren qualitativen und quantitativen Nutzer- und Nutzungsanforderungen Use Cases definiert und entwickelt wurden. Diese Personas waren z. B.: Solaranlagenbesitzer mit einer bis mehreren PV-Anlagen Solarteure (PV-Installateure) & Betriebsführer Investoren Interessenten (geplante Neuinstallation oder allgemein thematisch interessiert) Im Rahmen von Expertenworkshops wurden diese Personas ebenso iteriert und verfeinert, wie auch in einem „Cognitive Walktrough“ die Konzeption der Portalanwendung, die Klärungen von Abhängigkeiten und die Optimierung von Prozessen hinsichtlich Effektivität und Effizenz ausgearbeitet wurden. Anschließend konnte gemeinsam mit den Stakeholdern im Unternehmen eine Priorisierung und Migrationsplanung für drei Release-Stufen als Grundlage der Anforderungsspezifikation und der Ableitung von User Stories durchgeführt werden.

Abbildung 3: User Interface Skizze aus low-fidelity Prototype für frühe Benutzerbefragung

168

Oliver Gerstheimer, Oliver Endemann, Andreas Strusch

Zur Entwicklung der Navigationsstruktur wurde das „Card Sorting“ verwendet, um die Findung, Strukturierung und Ableitung von Funktionseinheiten zu erleichtern. Hierbei werden einer ausreichenden Anzahl von Testern Karten mit möglichen Menüpunkten vorgelegt, welche von diesen dann in eine ihrer Meinung nach sinnvolle Struktur gebracht werden. Eng verbunden mit der Navigationsstruktur ist die iterative Entwicklung von Struktur- und Systembäumen der Gesamtanwendung und einzelner komplexer Komponenten, wie z. B. der PV-Anlagenzuweisung oder -verwaltung.

Abbildung 4: Iterativ entwickelter Strukturbaum mit Use Cases, Abhängigkeiten, Fragestellungen

Parallel wurden die Informationsarchitektur in Form von Wireframes und das eigentliche User Interface Design mit Variantenbildung entlang definierter Nutzungsszenarien (Use Cases) iterativ entwickelt und zur Überprüfung der Anforderungen und der User Experience in User Testings herangezogen. Die hier erzielten Ergebnisse unterstützten die anschließende Erstellung von „Click Flows“ im Anwendungskontext, also der Darstellung definierter Uses Cases „Schritt für Schritt“. Die Umsetzung dieser „Click Flows“ als interaktiv nutzbarer „Click Dummy“ in Form einer HTML-Programmierung war dann die Grundlage der folgenden User Experience- und Prototypen-Tests. Iterationsphase Die konsequente und frühe Integration von zukünftigen Benutzern in den Entwicklungs- und Entwurfsprozess ist ein entscheidender Erfolgsfaktor, sowohl für eine hohe Treffgenauigkeit bei Usability und User Experience als auch für eine hohe Akzeptanz des umgesetzten Designentwurfs in den Zielgruppen. Die Einbeziehung von Benutzern in User Experience

sunnyplaces.com – Lean UX-Design

169

Tests erfolgte hier in Form von Leitfadeninterviews, und zwar sowohl in der Entwurfsphase wie auch in der Evaluation anhand der oben beschriebenen Prototypen („Click Dummy“). In der Entwurfsphase wurden mehrere moderierte User Tests mit Endanwendern („Häuslebauer“) und Experten (PV-Installateure) unter Verwendung von Low-FidelityPrototypen durchgeführt. Hierbei wurden ausgedruckte Wireframe-Entwürfe verwendet, die Schritt für Schritt die jeweils personaspezifischen Use Cases abbildeten. Der Fokus lag hier auf der grundsätzlichen Überprüfung der Herangehensweise und der abgebildeten Prozesse. In der Evaluationsphase wurde der bereits erwähnte High-Fidelity-Prototyp auf HTML5Basis verwendet, der sowohl auf PC/Laptop wie auch auf Tablet-PC und Smartphone nutzbar war. Diese aufwendige Umsetzung ermöglicht es, auch komplexere Funktionseinheiten wie z. B. das Responsive-Design-Verhalten einzelner Seiten mit Hilfe von „Adobe Edge Reflow“ oder von Kartenfunktionen über die „Google Maps API“ umzusetzen und zu überprüfen. Der User Experience Test in der Evaluationsphase wurde in Form eines Feldtests mit Experten und Benutzern durchgeführt. Als ergänzender Baustein der Usability-Überprüfung wurde nach dem Produktlaunch eine Langzeitbeobachtung implementiert, in der das User-Feedback über Kommentare und Anregungen im portaleigenen Feed und der angebotenen Feedback-Option überwacht und ausgewertet wurde (Customer Engagement). Ergänzend wurde nach ein paar Monaten Portalbetrieb eine kurze Benutzerbefragung durchgeführt, die per Mail angeboten und auf einer dafür eingerichteten Webseite durchgeführt wurde.

Das Rollout Marketing vom Brand Name bis zum Feature Video Gemäß dem Motto „Nach dem Launch ist vor dem Launch“ wurden entsprechend dem mehrstufigen Umsetzungskonzept mit dreiteiliger Release-Planung in kürzeren Abständen kleinere Feature-Updates umgesetzt und in größeren Abständen komplett neue Funktionen und Bereiche des Portals aktiviert. Einerseits war diese Form der Umsetzung vor dem Hintergrund der begrenzten Zeit- und Kostenbudgets nur in dieser Form umsetzbar, andererseits ermöglicht dieses Vorgehen „mit dem Benutzer in Kontakt zu bleiben“ und Feature-Updates als akzeptierten Kommunikationskanal zu nutzen und so einen ersten Teil der Rollout-Marketing-Kampagne umzusetzen. Weiterhin wurde der Kunde in den folgenden Marketingmaßnahmen unterstützt: Namensfindung für das Portal unter Corporate Identity- und Corporate Marketing-Aspekten inkl. Überprüfung der entsprechenden Domains; Erstellung eines Communication Pools mit grundlegenden Marketingtexten wie z. B. Slogans, Sub-Slogans, Textelemente (kurz, mittel, lang), Benefit- und USPArgumentationsketten, E-Mail-Anschreiben etc. sowie Visuals, Grafiken und Fotobriefings;

170

Oliver Gerstheimer, Oliver Endemann, Andreas Strusch

Konzept und Erstellung eines Video-Trailers in drei Sprachversionen (Deutsch, Englisch, australisches Englisch) zur Nutzung im Portal, der Corporate Website, dem YouTube Channel des Unternehmens sowie im Rahmen der internen und externen Produkt- und Projektkommunikation sowie bei Messeauftritten.

Abbildung 5: Einführungsfilm Sunny Places auf YouTube (1:18 Minuten)

Ergebnisse Die wichtigsten Projektergebnisse in Zahlen zusammengefasst: Planung & Prozess: Punktgenaue Umsetzung von der Business-Idee bis zum Messe-Rollout und Vermarktungsfähigkeit in 8 Monaten; Lean Product Management: Ganzheitliches UX-Management und User Interface Design aus „einer Hand“ mit einem schlanken Projektteam von 8-10 Personen seitens chilli mind (1 Projektmanager, 1 UX Manager, 2 UI Designer, 4-6 Programmierer) und 3-5 Personen seitens des Auftraggebers (1 Projektleiter 1 Produktmanager, 1 Portal-API Entwickler, 2 IT Mitarbeiter); Akzeptanz im Markt: 6 Monate nach dem Launch im Juli 2014 hatten sich mehr als 5.000 Benutzer im neuen Portal registriert – geplante Zielzahl war im ursprünglichen Geschäftsmodell die Registrierung von 3.500 Solaranlagen in einem Zeitraum von 12 Monaten. Laut aktuellem Stand (Juni 2015) sind mittlerweile >12.000 Anwendern mit mehr als 7.500 Solaranlagen registriert, wovon ca. 6000 mit Ertragsdaten durch die Besitzer veröffentlicht wurden.

sunnyplaces.com – Lean UX-Design

171

Lessons Learned Die Lean-Startup-Methode bezeichnet den Dreiklang „Build – Measure – Learn“. Das bezieht sich hauptsächlich auf das Produkt selbst, aber ist auch auf das Projektvorgehen übertragbar.

Lean-UX Ansatz ist nicht easy Viele Projektschritte erfolgen aufgrund des hohen Zeitdrucks parallel und erfordern vom Entwicklerteam eine sehr klare Struktur sowie ein diszipliniertes Vorgehen. Hierbei zeigt sich, wie „lean“ ein Projekt wirklich gehandhabt werden kann, denn die schiere Summe der dezentralisierten Projektbeteiligten verlangt nach Dokumentation und Spezifikation, um Information transparent und verfügbar zu halten. Und es sind ja nicht nur die direkten Beteiligten zu informieren. Bei einem Großkonzern will auch die ganze EntscheiderHierarchie bis hoch zum Vorstand informiert sein, und jeder dabei mit einem spezifischem Fokus.

Perfektionismus ist der Feind vor dem Launch Alle planerisch beteiligten Personen wie Produktmanager, UI- & Interaction-Designer oder Informationsarchitekten planen und entwerfen „tolle“ Dinge, die dann aufgrund von Zeitdruck oder technischen Restriktionen nicht oder nicht in dieser Form umgesetzt werden. Mehr als in anderen Projekten haben wir hier gelernt, das Produkt zum Lauch als MVP (Minimum Viable Product) zu begreifen und alle Leidenschaft in kontinuierliche Updates zu investieren.

Datenpräzision als Grundlage von User Experience Die Zielgruppe der ambitionierten „Solar-Community“ wünscht sich die angezeigten Daten am liebsten live und auf das Komma genau. Die Grundlage hierfür muss in einem gepflegten Datenmodell, einer fehlerminimierten Datenerfassung und einer optimierten Bereitstellung der Daten gelegt sein. Im Entwicklungsprozess zeigte sich, dass hier immer Optimierungspotenzial besteht und eine Implementierung z. B. von Anlagenvergleichen (Leistung und Ertrag) über beliebige Zeiträume und -zonen nicht nur Hürden in Konzeption und Programmierung birgt, sondern vor allem die Benutzer dazu bringt, ihre Ansprüche an die Datenpräzision und -verfügbarkeit vehement einzufordern. Literatur Gothelf, Jeff & Seiden, Josh (2013). Lean UX - Applying Lean Principles to Improve User Experience. 1005 Gravenstein Highway North, Sebastopol, CA 95472: O’Reilly Media, Inc..

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 172- 183.

Der Usability Engineering Prozess für Medizinprodukte nach IEC 62366:2007 Ein Praxisbeispiel der benutzerorientierten Gestaltung eines neuronalen Monitoring Systems Thore Reitz, Torsten Gruchmann

Thore Reitz

Use-Lab GmbH Am Campus 2 48565 Steinfurt [email protected]

Torsten Gruchmann

Use-Lab GmbH Am Campus 2 48565 Steinfurt [email protected]

Abstract Innerhalb eines von der Eureka Initiative geförderten Projektes wurde unter dem Namen „Optobrain“ ein Monitoring System zur Messung der zerebralen Vitalparameter, wie die Sauerstoffsättigung im Hirngewebe, das zerebrale Blutvolumen und der Blutfluss entwickelt. Die Entwicklung folgte hierbei dem in der internationalen Norm IEC62366:2007 definierten gebrauchstauglichkeitsorientierten Entwicklungsprozess. Die Einhaltung ist für Hersteller von Medizinprodukten vorgeschrieben. Bei der Anwendung dieses Prozesses wurde in dem Projekt in einer ersten Phase eine Anforderungsanalyse auf diversen neurologischen Intensivstationen durchgeführt. Nachdem die Anforderungen in Spezifikationen überführt wurden, wurden auf deren Basis diverse User-Interface Konzepte generiert und in mehreren formativen Usability Evaluierungen in einem iterativen Prozess verfeinert und an die Anforderungen der Anwender angepasst. Die in diesen Prozess entwickelte Benutzerschnittstelle erfüllt nicht nur die regulativen Anforderungen an die Medizinproduktehersteller, sondern auch die Anforderungen der Anwender.

Keywords Medizinprodukte, IEC62366:2007, Gebrauchstauglichkeit Monitoring, Benutzerzentrierte Gestaltung

von

Medizinprodukten,

Neuronales

Der Usability Engineering Prozess für Medizinprodukte nach IEC 62366:2007

173

Einleitung Dieser Artikel beschreibt an Hand eines konkreten Entwicklungsprojektes, wie der in der internationalen Norm IEC62366:2007 beschriebene gebrauchstauglichkeitsorientierte Entwicklungsprozess für Medizinprodukte in der Praxis umgesetzt werden kann. Als Beispiel dient hierfür eine Software, welche in Kombination von verschiedenen Sonden zerebrale Messwerte darstellt. Diese Software wurde in Zusammenarbeit mit der Firma NeMo Devices aus der Schweiz entwickelt. Anhand verschiedener Schritte aus dem konkreten Entwicklungsprojekt wird der gesamte Prozess nach IEC62366 beschrieben und erläutert.

Usability in der Medizintechnik Seit 2007 existiert ein Standard, der sich auf die Gebrauchstauglichkeit von Medizinprodukten bezieht. Dieser definiert, wie Medizingerätehersteller gewährleisten sollen, dass Ihre Produkte anforderungskonform und vor allem sicher für den Patienten und den Anwender selbst eingesetzt werden können. Das Ergebnis ist der gebrauchstauglichkeitsorientierte Entwicklungsprozess, der in Synergie mit dem Risikomanagement und Qualitätsmanagementprozess im Unternehmen stehen soll bzw. kann. Die IEC 62366 „Medizinprodukte - Anwendung der Gebrauchstauglichkeit auf Medizinprodukte“ in der gültigen Fassung von 2007 ist ein Standard, der sich auf alle Medizinprodukte bezieht, d.h. auf die aktiven aber auch die nicht-aktiven Produkte. Sie gilt als Ablösung für die IEC 60601-1-6 „Medizinische elektrische Geräte - Teil 1- 6: Allgemeine Festlegungen für die Sicherheit einschließlich der Wesentlichen Leistungsmerkmale Ergänzungsnorm: Gebrauchstauglichkeit“, ebenfalls ein Gebrauchstauglichkeitsstandard, welcher sich nur auf die aktiven, d.h. elektrischen Medizinprodukte bezieht. Dies ist der Tatsache geschuldet, dass sie Teil der Normenreihe der IEC 60601-1 ist. Die IEC 60601-1 „Medizinische elektrische Geräte – Teil 1: Allgemeine Festlegungen für die Basissicherheit und die wesentlichen Leistungsmerkmale“ ist der Basisstandard für die Sicherheit von elektrischen Medizinprodukten. Der 2004 erstmals veröffentlichte Kollateralstandard IEC 60601-1-6 wurde in 2006 von der 2. Ausgabe abgelöst und 2010 erschien dann die 3. Ausgabe, in der erstmalig ein direkter Verweis auf die IEC 62366 erfolgte. Dies war ein deutliches Zeichen, dass Hersteller von elektrischen Medizinprodukten in Zukunft den normativen Anforderungen Genüge tun, wenn sie sich bei der Erstellung der Gebrauchstauglichkeitsakte ausschließlich an die IEC 62366 halten und im Rahmen der Dokumentation der IEC 60601-1 auf die IEC 62366 referenzieren. Aufwind hat der Gebrauchstauglichkeitsstandard dann im Jahre 2010 noch einmal durch das Inkrafttreten der Änderungsrichtlinie 2007/47/EG zur Medical Device Directive (MDD 93/42/EWG), der europäischen Medizinprodukterichtlinie, erhalten. Durch das Inkrafttreten der Änderungsrichtlinie von 2007 ist das Thema Ergonomie und Gebrauchstauglichkeit,

174

Thore Reitz, Torsten Gruchmann

zumeist alternativ verwendete Begrifflichkeiten, seit 2010 in der konsolidierten Fassung der 93/42/EWG in den Grundlegenden Anforderungen in Anhang I gelistet. Dies bedeutet gleichzeitig, dass Gebrauchstauglichkeit damit im Rahmen der nationalen Gesetze eingefordert werden muss. Seit diesem Datum ist somit für alle Hersteller von aktiven aber auch nicht aktiven Medizinprodukten europaweit vorgeschrieben, dass während der Entwicklung eines Medizinproduktes ein besonderes Augenmerk auf die Gebrauchstauglichkeit bzw. Usability des Produktes gelegt werden muss. Innerhalb der Norm IEC62366:2007 (Abbildung 1) wird ein gesamter Prozess beschrieben, welcher mit der Anforderungsanalyse beginnt und mit einem abschließenden Usability Test mit repräsentativen Anwendern des Medizinproduktes, der Usability Validierung, abschließt. Neben diesen zwei Eckpfeilern der guten, benutzerzentrierten Entwicklung besteht der Entwicklungsprozess noch aus Schritten des Risikomanagements und weiteren Evaluierungen, welche während der Entwicklung stattfinden sollten, der Usability Verifikation.

!

Abbildung 1: Der Usability Engineering Prozess nach IEC62366:2007

Zerebrales Monitoring Die Behandlung von Hirnschäden ist extrem kostenintensiv. Ein Hirnschaden kann durch Gewalteinwirkung, einem sogenannten Schädel-Hirn-Trauma, z.B. im Rahmen eines Verkehrsunfalls, entstehen. In solchen Fällen wird von einem primären Hirnschaden gesprochen. Hirnschäden können aber auch indirekt, durch Schlaganfall, Herzinfarkt, große Operationen in Verbindung mit zum Beispiel einer Herz-Lungen-Maschine oder schweren Krankheitsbildern wie der Sepsis, einer schwere Blutvergiftung, hervorgerufen werden. In diesen Fällen wird von einer sekundären zerebralen Ischämie oder Hypoxie gesprochen. Es handelt sich in diesen Fällen immer um eine nicht ausreichende Versorgung des Gehirns mit Blut und Sauerstoff. Folglich wird immer versucht, eine solche nicht ausreichende Versorgung des Gehirns mit Blut und Sauerstoff zu vermeiden und möglichst früh zu

Der Usability Engineering Prozess für Medizinprodukte nach IEC 62366:2007

175

erkennen. Um solch eine drohende Unterversorgung des Gehirns zu vermeiden lassen sich unterschiedliche Werte kontinuierlich überwachen. Zu den wichtigsten Parametern, die einen frühzeitigen Hinweis auf eine drohende oder stattfindende Unterversorgung des Gehirns mit Blut und Sauerstoff geben können, gehören der Blutfluss und das Blutvolumen im Gehirn, aber auch die Tatsache, wie viel Sauerstoff sich aktuell tatsächlich im Hirngewebe befindet. Diese Werte spielen sowohl im Rahmen der Früherkennung und Vermeidung, als auch in der Therapie von Hirnschäden, eine entscheidende Rolle. Messen lassen sich diese, aber auch eine Vielzahl weiterer Werte, über spezielle Sensoren, welche auf verschiedene Arten an dem Patienten angebracht werden. Zum einen gibt es spezielle pflasterähnliche Sensoren, welche direkt auf die Kopfhaut aufgeklebt werden. In diesem Fall spricht man von einer nicht-invasiven Messung. In anderen Fällen kann es sich als nicht ausreichend erweisen, dass ein solches nichtinvasives System Messwerte alleinig durch die Messung durch die Haut und Schädelknochen bestimmt. In diesen Fällen werden Sonden durch die Kopfhaut und den Schädelknochen direkt in das Gehirn eingebracht. So werden Werte direkt am Ort des Geschehens, dem Gehirn, gemessen. In diesem Fall spricht man von einer invasiven Messung.

Der Entwicklungsprozess nach IEC62366:2007 Die nachfolgenden Unterkapitel beschreiben den gebrauchstauglichkeitsorientierten Entwicklungsprozess, wie er von der Use-Lab GmbH gemeinsam mit dem Medizinproduktehersteller NeMo Devices angewendet wurde. Das Projekt "OptoBrain" wurde von dem Schweizer Start-up Unternehmen NeMo Devices initiiert und durch die Eureka Initiative gefördert. Ziel des Vorhabens war die Entwicklung eines Systems zur Messung der zerebralen Vitalparameter, wie die Sauerstoffsättigung im Hirngewebe, das zerebrale Blutvolumen und den Blutfluss. Diese Parameter spielen eine entscheidende Rolle bei der Untersuchung und Behandlung von Patienten mit Schädel-HirnTrauma. Das OptoBrain-System setzt sich aus mehreren Hardware-Komponenten sowie Sensoren zusammen, die für die Messung und die Aufbereitung der gemessenen Daten notwendig sind. Die Auswertung und Darstellung der Werte erfolgt durch eine spezielle Software, welche auf einem für medizinische Anwendungen geeigneten PC installiert werden kann. Um ein hohes Maß an Anwendersicherheit und Zufriedenheit zu garantieren wurde von der Use-Lab GmbH der an die IEC62366:2007 angelehnte „usable design process“ angewendet, welcher sich durch eine enge Verzahnung der normativ geforderten Inhalte und eines klassischen Designprozesses auszeichnet (Abbildung 2).

176

Thore Reitz, Torsten Gruchmann

!

Abbildung 2: Schematische Darstellung des „Usable Design Process“ der Use-Lab GmbH

Spezifikation der Anwendung Zu Beginn des Usability Engineering Prozesses steht laut der Norm die sogenannte Spezifikation der Anwendung. Dieser in Kapitel 5.1. der Norm beschriebene Schritt beinhaltet das Erlangen von Informationen über die spätere Anwendung des Produktes. Neben verschiedenen klinischen Informationen wie der vorgesehenen medizinischen Indikation, der vorgesehenen Patientengruppe, oder der physikalischen Funktionsweise des Systems werden hier ebenfalls erste Usability typische Informationen dargestellt, wie z.B. das vorhergesehene Benutzerprofil oder auch die Gebrauchsbedingungen des späteren Produktes. In Zusammenarbeit mit NeMo Devices wurden neben den normativ geforderten Anforderungen und Definitionen ebenfalls eine Anforderungsliste an das Produkt und die spätere Bedienung definiert. Eine Herausforderung stellte die am Anfang des Projekts formulierte Anforderung hinsichtlich einer möglichst flexiblen Auflösung dar. Die Software sollte gemäß Spezifikation sowohl für ein Echtzeit-Monitoring als auch für die retrospektive Auswertung geeignet sein. Die Benutzeroberfläche muss sich verschiedenen Bildschirmen anpassen und sowohl mit der Maus am Laptop als auch per Touch mit dem Finger am Patientenmonitor zu bedienen sein. Als Ausgangspunkt diente eine in den früheren Stadien des Projekts entwickelte Software, die bereits einen Teil der vorgesehenen Funktionen abdeckte, jedoch nur für die reine Maussteuerung konzipiert wurde. Nach einer internen Analyse wurde entschieden, das UserInterface von Grund auf zu überarbeiten und neu zu entwerfen. Bevor die erste Designphase starten konnte, musste vorab eine ausgiebige Analyse des Einsatzfeldes und der Austausch mit potenziellen Benutzern durchgeführt werden. Das Entwicklerteam besuchte dafür eine Intensivstation in der Schweiz und nutzte die Gelegenheit, um in persönlichen Gesprächen mit dem Fachpersonal erste Hinweise für die späteren Entwürfe zu sammeln (siehe Abbildung 3). Das Ziel der Gespräche bestand darin, möglichst viele Informationen über das Umfeld und den Arbeitsablauf in der Behandlung von Patienten mit Schädel-Hirn-Trauma zu erhalten sowie die Stärken und Schwächen der aktuell verwendeten Systeme herauszufinden. Aufgrund dieser Feldanalyse entstanden die ersten Ideen, Notizen und Skizzen, die dann in den späteren Entwurf einflossen.

Der Usability Engineering Prozess für Medizinprodukte nach IEC 62366:2007

177

!

Abbildung 3: Erklärung während der Prozessanalyse

Häufig benutzte Funktionen Der nächste, von der Norm geforderte Schritt ist die Definition von häufig benutzten Funktionen des späteren Medizinproduktes. Dieser laut Norm in Kapitel 5.2 erforderte Schritt wurde bereits teilweise während der Anforderungsanalyse, welche als Teil der Spezifikation der Anwendung durchgeführt wurde, erarbeitet. Hierzu wurde basierend auf der Beobachtung von Anwendern in der typischen Anwendungsumgebung von bereits bestehenden oder vergleichbaren Systemen evaluiert, welche Funktionen typischerweise häufig benutzt werden. Der Hintergrund dieser frühen Klassifizierung von häufig benutzen Funktionen liegt darin, dass in einem folgenden Schritt, der vorläufigen Risikobewertung, bereits eine Aussage über die potentielle Gefahr bzw. Gefährdung des Medizinproduktes getroffen werden kann. Der Ansatz hierbei liegt laut der international gültigen Risikomanagementnorm IEC 14971 darin, dass die häufige Benutzung der selben Funktion dazu führen kann, dass durch Routine oder Aufmerksamkeitsfehler Gefahren für und durch den Anwender bestehen könnten. Für das System wurden verschiedene, häufig benutzte Funktionen wie das Umschalten zwischen verschiedenen gemessenen Parametern, das Erkennen und Reagieren auf Meldungen durch das System aber auch das korrekte Anlegen der unterschiedlichen Messsonden definiert. Da während des hier beschriebenen Projektes lediglich die Software Komponente des Systems gestaltet wurde, wurden innerhalb des Projektes nur Software relatierte Anforderungen detailliert betrachtet.

178

Thore Reitz, Torsten Gruchmann

Risikomanagement Wenn man die Norm IEC62366 genau betrachtet, handelt es sich hierbei rein formal gesehen um einen Standard für die Sicherheit von Medizinprodukten, genaugenommen für die sichere Anwendung von Medizinprodukten. Einer der dahinterliegenden Grundsätze besteht in der Annahme, dass von jedem Medizinprodukt, welches an einem Menschen angewendet wird, ein (potentiell tödliches) Risiko ausgeht. Je nach Art des Medizinproduktes gehen unterschiedliche und verschieden hohe Risiken von einem Produkt aus. Mit Hilfe des internationalen Standards IEC14971 sollen diese Risiken überschaubar und, nach Möglichkeit, beherrschbar gemacht werden. Das dies auch für den Bereich der Anwendung notwendig ist zeigt eine Studie des National Research Councils aus dem Jahr 1999 (National Research Council 2000). Aus dieser Studie, welche über mehrere Jahre Zwischenfälle mit Medizinprodukten in den USA betrachtet, geht hervor, dass ca. 2/3 aller Zwischenfälle, welche zu einer Behandlungsverzögerung, Schädigung oder Tod eines Patienten geführt haben, als Benutzungsfehler klassifiziert werden können (Abbildung 4).

!

Abbildung 4: Zwischenfälle mit Medizinprodukten (aus „to err is human“)

Dies ist einer der Gründe, weswegen die Norm IEC62366 ins Leben gerufen wurde, um potentiell tödliche Fehler bei der Anwendung von Medizinprodukten zu minimieren. Dies wird innerhalb der Norm in Kapitel 5.3 adressiert. In diesem Schritt des Prozesses erfolgt eine vorläufige Bewertung der Risiken, welche von dem zu entwickelnden Produkt ausgehen. Als Eingangsgrößen dienen hierzu die Spezifikation der Anwendung, aber auch die bereits definierten häufig benutzten Funktionen. Dieser Schritt wird sehr iterativ während des gesamten Entwicklungsprozesses durchgeführt und geht über diesen hinaus. Wichtig ist aus normativer Sicht eine eindeutige Kenntlichmachung von benutzungsrelatierten Risiken und möglichen Gegenmaßnahmen. Innerhalb des NeMo Entwicklungsprozesses wurden verschiedene potentielle Risiken beschrieben. Beispiele sind: Auf der Intensivstation kann es zu stressigen Situationen für den Anwender kommen, welche auf den Entscheidungsprozess des Anwenders Einfluss nehmen können. Durch die Fehlinterpretation bestimmter vom System dargestellten Informationen kann der Anwender falsche Entscheidungen für den Therapieverlauf treffen.

Der Usability Engineering Prozess für Medizinprodukte nach IEC 62366:2007

179

Durch die sich ändernden Beleuchtungssituationen innerhalb einer Intensivstation (Tag bzw. Nachtdienst) kann es zu erschwerten Ablesebedingungen der Anzeige kommen. Durch die Darstellung auf unterschiedlichen, vorab nicht immer definierbaren Anzeigen kann es zu ungünstigen Informationsdarstellungen kommen. Aus diesen und vielen weiteren Risiken wurden weitere Anforderungen an die Gestaltung aber auch Gebrauchstauglichkeit des späteren Produktes abgeleitet.

Hauptbedienfunktionen Nach der vorläufigen Risikoanalyse ergeben sich weitere Funktionen, welche nicht zwingend als häufig benutzt erachtet werden (Kapitel 5.2 der Norm), aber dennoch ein gewisses Risiko in sich bergen. Ebenfalls kann es durch diese vorläufige Analyse dazu kommen, dass häufig benutzte Funktionen ebenfalls ein weiteres oder größeres Risiko mit sich bringen. Diese neu definierte Liste an Funktionen, welche sich aus den häufig benutzten aber auch sicherheitsrelevanten Funktionen zusammen setzen, wird in der IEC62366:2007 in Kapitel 5.4 adressiert. Innerhalb des Projektes wurde die bereits definierte Liste an Funktionen um weitere Punkte ergänzt, wie die Installation der Software sowie die Darstellung bestimmter, sekundärer Parameter innerhalb der Software.

Spezifikation der Gebrauchstauglichkeit Nach der Definition von Risiken und Bedienfunktionen wurden auf den Bedienfunktionen basierende Use Szenarien erstellt. Diese sollten dem gesamten Entwicklerteam die spätere Benutzung möglichst erlebbar und nachvollziehbar machen, erfüllten aber auch die von der Norm in Kapitel 5.5 geforderten Inhalte. Neben den Benutzungsszenarien, welche auf den Hauptbedienfunktionen basieren und sowohl die Benutzungsumgebung als auch die potentielle Anwendergruppe beschreiben, wurden erste Usability Spezifikationen erstellt. Hierbei handelt es sich um von der Norm geforderte überprüfbare Forderungen für die spätere Evaluierung des Systems durch Endanwender.

Validierungsplan für Gebrauchstauglichkeit Dieses von der Norm geforderte Kapitel beschreibt die formalen Inhalte, welche innerhalb des Evaluierungsplans für das betreffende Produkt genannt werden sollen. Dieses Kapitel zeigt ebenfalls den größten Interpretationsspielraum zwischen verschiedenen Medizintechnikherstellern. Für die einen sollte dieser Plan die Gesamtevaluierung des gesamten Projektes, inklusive der Methodik für jedwede Usability Evaluierung, beinhalten. Andere definieren in diesem Kapitel lediglich die Anforderungen für die von der Norm ebenfalls geforderte Usability Validierung. Beide Interpretationen werden derzeit von den benannten Stellen als korrekt angesehen.

180

Thore Reitz, Torsten Gruchmann

Innerhalb des NeMo Projektes wurde der häufiger anzutreffende Ansatz gewählt und es wurden alle Details für die finale Evaluierung der Endanwender definiert. Dies beinhaltet alle Informationen für die Anwenderbefragungen wie Methodik, Testumgebung, Testablauf etc.

Gestaltung und technische Umsetzung der BenutzerProdukte Schnittstelle Dieser von der Norm erst in Kapitel 5.7 geforderte Punkt beschreibt den eigentlichen iterativen Design und Gestaltungsprozess. Die Tatsache, dass das Projekt auf einer Vorversion der Software aufbaute, erleichterte es, einen Überblick über die benötigten Funktionen zu erhalten. Auf der anderen Seite stellte es die Herausforderung dar, sich von bekannten Strukturen lösen zu müssen, um einen Neuanfang zu ermöglichen. Da in diesem Fall die Neuentwicklung im Vordergrund stand, entschied sich das Entwicklerteam dazu, das Layout komplett neu aufzubauen. Solch ein Neuanfang bietet für ein Unternehmen die Möglichkeit, völlig ungebunden an die Gestaltung des Produkts heranzugehen, wohingegen die Weiterentwicklung eines bestehenden Systems oft Schwierigkeiten mit sich bringt, weil alle späteren Releases und Updates der Benutzeroberfläche auch den Anspruch der Kundenpflege tragen. Eine Rückwärtskompatibilität spielt neben dem Umgang mit den Speicherformaten eine große Rolle, um die Erwartungshaltung der Gruppe der Bestandskunden zu erfüllen. Jede gravierende Veränderung im Layout oder der Bedienlogik birgt das Risiko, bei dem bereits etablierten Benutzerkreis auf Inakzeptanz zu stoßen. Im Zuge der Neuentwicklung wurden unterschiedliche Layouts erarbeitet und auf ihre Anforderungskonformität und Benutzerfreundlichkeit in den grundlegenden Szenarien hin untersucht. Während der gesamten, iterativen Gestaltung wurde ein besonderes Augenmerk auf die möglichen multiplen und unterschiedlichen Bedienmodalitäten gelegt. Dies beinhaltet sowohl die klassische Bedienung via Maus und Tastatur, aber auch Touchscreen basierte Systeme. Ebenfalls wurde die Skalierbarkeit der Anzeige auf verschiedene Monitore und Auflösungen als wichtige Anforderung mit in Betracht gezogen, da die Software in einer bereits bestehenden IT Infrastruktur genutzt werden soll. Bevor es zu der detaillierten Ausarbeitung eines konkreten Layoutentwurfs kommen konnte, wurden die Ergebnisse der Anwenderbefragungen (siehe Kapitel „Verifikation der Gebrauchstauglichkeit“) ausgewertet und im internen Entwicklerkreis diskutiert. Viele parallel konzipierte Varianten wurden daraufhin zugunsten einer zielgerichteten Weiterentwicklung verworfen. Aus Sicht jedes Designers gleicht diese Phase einem "Massensterben der Ideen", aber aus Sicht des Projektmanagements ist es ein zielführender Prozess und somit ein enormer Schritt nach vorne. Skizzen und Interaktionsabläufe wurden überarbeitet und den neu gewonnenen Erkenntnissen angepasst. Im Laufe des nächsten Designschritts bekamen die Entwürfe nach und nach ihre wirkliche Gestalt. Obwohl professionelle Grafikprogramme bereits vom ersten Entwurf an mit im Spiel waren, gab es die Darstellungen bis dahin ausschließlich als Handskizze.

Der Usability Engineering Prozess für Medizinprodukte nach IEC 62366:2007

181

Am Anfang des Detailentwurfs geht es vor allem darum festzulegen, welches Erscheinungsbild man dem Endprodukt geben möchte. Dafür wurden am Beispiel eines Screenlayouts mehrere Gestaltungsrichtungen durchgespielt und verglichen. Persönlicher Geschmack und aktuelle Designtrends spielen bei dieser wichtigen Entscheidung eine bedeutende Rolle, denn das Ästhetikempfinden unterliegt im Regelfall relativ stark äußeren Einflüssen. Dennoch spielen auch funktionale Aspekte eine Rolle, und im Fall des OptoBrain Projektes entstand glücklicherweise eine gewisse Überschneidung zwischen Trend- und Funktionsaspekten. Das aktuell populäre "Flat Design" mit einem grafisch eher minimalistischen Gestaltungsstil war technisch gesehen prädestiniert für ein weitestgehend auflösungsunabhängiges Interface.

!

Abbildung 5: Beispiel des Iterativen Designs

Verifizierung der Gebrauchstauglichkeit Dieses Kapitel der Norm beschreibt die während der Entwicklung stattfindenden Usability Evaluierungen. Häufig werden diese durch formative Usability Tests durchgeführt. Hier stehen dem Entwicklerteam alle Methoden des klassischen Usability Engineerings frei zur Verfügung. Innerhalb des NeMo Projektes wurden neben diversen Expertreviews ebenfalls

182

Thore Reitz, Torsten Gruchmann

zwei Fokusgruppen Diskussionen zu verschiedenen Zeitpunkten durchgeführt, um die wichtige und notwendige Rückmeldung von potentiellen Endanwendern zu erhalten. Die erste formative Evaluierung der Usability wurde zusammen mit Vertretern der späteren Benutzergruppe durchgeführt. Insgesamt wurden 6 potentielle Anwender aus verschiedenen medizinischen Fachgebieten eingeladen, gemeinsam an einer Diskussion teilzunehmen. Nachdem den Teilnehmern die ersten skizzenhaften Entwürfe zum Layout vorgestellt und erläutert wurden, ging es unter anderem darum, durch offene Fragestellungen den ersten Eindruck zu ermitteln. Neben der Abfrage des ersten Eindrucks zu den unterschiedlichen Designkonzepten diente die Fokusgruppe zudem dazu, die favorisierte Layoutidee zu identifizieren, was durch zusätzliche Fragestellungen erreicht wurde. Konkrete Fragestellungen hierzu waren zum Beispiel die Darstellung der Messwerte, verschiedene Screenlayouts aber auch das Thema der Ablesbarkeit unter verschiedenen Bedingungen. Diese erste Anwenderbefragung brachte einige aufschlussreiche Erkenntnisse hinsichtlich der Erwartungshaltung. Eine Erkenntnis war beispielsweise, dass sich die Medizintechnik langfristig nicht dem Einfluss der Konsumgüterindustrie entziehen können wird. Geprägt durch die Bedienlogik von Smartphones und Tablets suchen heutige Benutzer meist nach dem "Home"- und "Zurück"-Icon und setzen bei einem Touchscreen die Gestensteuerung voraus. Dies ist nur ein Beispiel einer gewonnenen Erkenntnis, die später in die Entwicklung eingeflossen ist.

Validierung der Gebrauchstauglichkeit Innerhalb des von der Eureka geförderten und hier beschriebenen Projektes wurde die abschließende Validierung, auch als summative Usability Evaluierung bekannt, nicht mehr durchgeführt.

Fazit Die konsequente Anwendung des gebrauchstauglichkeitsorientierten Entwicklungsprojektes sorgte dafür, dass ein Produkt entstehen konnte, welches für den Anwender einfach und sicher anzuwenden ist und ebenfalls aktuelle Entwicklungen und Gestaltungsparadigmen innerhalb der Medizintechnikwelt beinhaltet. Ebenfalls wurde durch die konsequente Dokumentation aller Schritte innerhalb des Usability Engineering Files ein kleiner, aber zulassungsrelevanter Teil der Gesamtdokumentation ohne großen Mehraufwand abgehandelt. Neben den von der Norm geforderten Punkten wurde innerhalb des Projektes ebenfalls Wert auf Anwenderzufriedenheit, ein klassisches Maß der Usability, gelegt, so dass neben der Pflichterfüllung ebenfalls ein Mehrwert für den Anwendender geschaffen werden konnte.

Der Usability Engineering Prozess für Medizinprodukte nach IEC 62366:2007 Literatur DIN EN 62366:2007 (2007). Medizinprodukte – Anwendung der Gebrauchstauglichkeit auf Medizinprodukte. Beuth, Berlin. DIN EN ISO 14971:2007 (2007). Medizinprodukte - Anwendung des Risikomanagements auf Medizinprodukte. Beuth, Berlin. National Research Council (2000). To Err Is Human: Building a Safer Health System. Washington, DC: The National Academies Press.

183

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 184- 191.

Ein Accessibility (a11y)-Konzept für Google Calendar Schritt für Schritt zum Inclusive Design Mitch Hatscher, Astrid Weber

Michael „Mitch“ Hatscher Google Switzerland GmbH Brandschenkestr. 110 8002 Zürich / Schweiz [email protected]

Astrid Weber

Google Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 / USA [email protected]

Abstract Wie entwickelt man ein Inclusive Design-Konzept für ein Produkt mit so hoher Informationsdichte, starker Visualität und diverser NutzerInnenpopulation wie Google Calendar? Neben der Beschreibung der Vorgehensweise erklären die Autoren, welche besonderen Herausforderungen sie meistern mussten und welche Erkenntnisse sie hierdurch gewannen. Der Artikel schließt mit Best PracticeEmpfehlungen und Design-Implikationen, die über Google-Produkte hinaus relevant und interessant sein dürften.

Keywords Accessibility, Barrierefreiheit, Mobile, Android, iPhone, Screen Reader

Ausgangssituation UX-Produkt-Team: Google Calendar Im Herbst 2013 erhöhte sich innerhalb von Google die Aufmerksamkeit in Sachen Accessibility; damit wurden Engineering- und Produktmanagement-Kapazitäten für diese wichtige und herausfordernde Aufgabe frei. Zu diesem Zeitpunkt bestand im gesamten User Experience-Team für Google Calendar kaum Vorwissen über Accessibility, abgesehen von einigen basalen Grundlagen, geschweige denn von Implikationen für die Implementierung.

Ein Accessibility (a11y)-Konzept für Google Calendar

185

Zentrales Accessibility-Engineering-Team Das zentrale Accessibility-Engineering-Team unterstützt Produktteams darin, ihre Accessibility-Strategie auszuarbeiten. Zentrale Fragen lauten beispielsweise: Was ist für einen blinden Menschen ein tatsächlich nützlicher Kalender? Welche Farb- und Form-Prinzipien ermöglichen es einem farbenblinden Nutzer, Googles Produkte mühelos zu nutzen? Mit Hilfe von User Research strebt die Accessibility Community innerhalb von Google an, in all ihren Design-Entscheidungen und -Definitionen einer Philosophie des Inclusive Design zu folgen.

Vorgehen Wir hatten den Auftrag, innerhalb sehr kurzer Zeit Barrierefreiheit als zentralen Designaspekt in die App zu integrieren. Aus einem früheren Projekt bestand bereits ein enger und vertrauensvoller Kontakt zwischen dem Calendar UX-Team und Astrid, die als User Researcherin im zentralen Accessiblity-Team arbeitet. Über mehrere Wochen intensiver Zusammenarbeit am Standort Zürich erstellten wir gemeinsam ein Grundkonzept der Accessibility für Google Calendar. Wir begannen mit einer praktischen und eindrücklichen Einführung ins Thema Accessibility: Wir luden mehrere blinde NutzerInnen von außerhalb zu uns ins Büro ein, um uns zeigen zu lassen, wie Menschen mit visuellen Einschränkungen digitale Produkte nutzen. Anschließend durchliefen wir die folgenden Schritte: ¥ Auswahl und Priorisierung zentraler Use Cases, die wir barrierefrei gestalten wollten, beispielsweise: Einen Überblick über die anstehenden Ereignisse vermitteln; einen neuen Kalendereintrag erstellen; einen Zahnarzttermin finden, der für die nächsten Wochen vereinbart wurde; zu einem Datum navigieren ¥ Brainstorming über die ideale Accessible User Experience – z.B.: wie viel Sprachausgabe ist angemessen? Wie kann man Navigationsvorgänge beschleunigen, beispielsweise mit Hilfe von Sprungmarken? ¥ Definition von Storylines und User Journeys, die es uns ermöglichten, die Nutzungserfahrung besser nachzuvollziehen und zu optimieren ¥ Entwicklung eines Ansatzes für Low-Fidelity Prototyping für Accessibility, um erste Konzepte ohne Engineering-Vorarbeit testen zu können: Nachdem wir für alle zentralen Use Cases eine Vorstellung von einer geeigneten barrierefreien UX entwickelt hatten, definierten wir diese Flows in Form von Geschichten. Mit verteilten Rollen lasen wir dann vor, was der Nutzer tut und was die Assistive Technology (AT, meist: der Screen Reader) daraufhin ausgibt. So konnten wir ein AT-gestütztes Konzept simulieren, ohne dass Code geschrieben werden musste, und lernten in kurzer Zeit sehr viel, v.a. was die Menge des ausgegebenen Materials und die System- und Ausgabe-Steuerbarkeit angeht. Das Konzept funktioniert sogar für Remote User Testing via Telefon und Videokonferenz

186

Mitch Hatscher, Astrid Weber

¥ Iterative Definition des Basic Accessibility-Konzepts mithilfe des beschriebenen Prototyping-Ansatzes in zahlreichen Interviews mit blinden KollegInnen ¥ Erstellen einer Functional Spec für die barrierefreie UX für iPhone und intensive Diskussion mit dem zentralen Accessibility Team. Diese Functional Spec ergänzte die vorhandene Produktdefinition für die allgemeine Nutzungserfahrung ¥ (Teilweise) Implementierung des optimierten Accessibility-Konzept im nächsten iPhonePrototypen und iteratives Testen mit externen NutzerInnen mit Einschränkungen ¥ Aktualisieren der Spec für iPhone, Erstellen der Spec für Android auf Grundlage der Spec für iPhone und Übergabe ans Engineering In späteren Phasen des Projektes fand die Weiterentwicklung der barrierefreien UX für Google Calendar in Buganizer, unserem Bug-Tracking-Tool, in einzelnen Bugreports und Lösungen statt. Dies geschah in Form von spezifischen Designlösungen für konkrete Probleme und Accessibility Bugs, die unser Quality Assurance (QA)-Team aufspürte.

Herausforderungen und Erkenntnisse Design-Prozess und -Deliverables Der Gestaltungsprozess der barrierefreien Nutzungserfahrung für Calendar funktionierte grundsätzlich sehr ähnlich wie der Gestaltungsprozess für die allgemeine UX: Ausgehend von Nutzer-Personas und -szenarien definierten wir Design-Skizzen in Form kurzer DialogAbschnitte, erstellten Prototypen in Form ausgearbeiteter Skripte, testeten die Prototypen mit echten NutzerInnen und entwickelten die Design-Ansätze über mehrere Iterationen mit zunehmend höherer Fidelity weiter, bis wir abschließend die Design-Lösung in einer Spezifikation dokumentierten, die Ingenieure bei der Implementierung unterstützten und auf Design-Bugs der Qualitätssicherung bzw. des Testing Teams reagierten oder unsererseits Bugs öffneten. Allerdings waren die Problemlösungen i.d.R. eben keine vorrangig visuellen Lösungen, und als Deliverables kamen nicht Wireframes oder annotierte Mock-ups zum Einsatz. Stattdessen lagen die Lösungen in Kombinationen von visuellen, auditiven, haptischen Reizen und zusätzlichen Definitionen des Systemverhaltens (z.B. wenn das System, wie bei iOS, für die NutzerInnen den Fokus setzt). Die Lösungen mussten in ausführlichen Spezifikationsdokumenten niedergelegt werden und wiesen oft eine Kleinteiligkeit auf, wie wir sie im UX-Design vorher nicht angetroffen hatten. Auch war der Übergang zwischen Spezifikations- und Build-Phase sehr fließend: Wohl auch, weil die Functional Specs anfangs nicht detailliert genug waren, fand letztlich ein guter Teil der Design-Arbeit im Zusammenspiel mit dem Engineering und der QA auf den fast fertigen Builds statt. Eine weitere Herausforderung bestand darin, dass niemand im Product Management- oder auch im restlichen Calendar UX-Team Erfahrung mit Accessibility hatte und somit UX

Ein Accessibility (a11y)-Konzept für Google Calendar

187

Reviews, wie wir sie für alle anderen Teile des Produkts durchführten, schwer zu realisieren waren. Hier waren wir oft auf Rat und Empfehlungen der Google Accessibility Community angewiesen.

Dokumentation und Best Practice Es liegt eine Fülle an technischer Dokumentation vor, wie sich Barrierefreiheit aus Engineering-Sicht realisieren lässt; aber es gibt sehr wenig best practices oder Beispiele für wirklich gelungenes barrierefreies Design. Auch Google stand bei diesem Thema am Anfang. Von Nutzern mit Einschränkungen hörten wir mehrfach Aussagen wie diese: „[Wir] sind für alles dankbar, was die Tools überhaupt nutzbar macht“ (siehe auch Fast Company, 2015). Sowohl für Android als auch für iOS hatten wir Mühe, Beschreibungen der eigentlichen barrierefreien User Experience oder des angestrebten Verhaltens zu finden. Es liegt sehr viel technische Dokumentation zur Implementierung vor (Apple, 2015; Google, 2015a). Daher mussten wir sehr viel reverse engineering durchführen: Stundenlang testeten wir mit geschlossenen Augen und Kopfhörer eine Vielzahl von Apps auf ihr Accessibility-Verhalten hin und versuchten, Verhaltensmuster und -standards zu identifizieren, die auch für Google Calendar sinnvoll sein könnten.

Spezifikation In unseren Functional Specs definierten wir die Grundzüge der barrierefreien Nutzungserfahrung. Viele Detailprobleme erkannten wir allerdings erst später, als die Apps bereits gebaut wurden oder waren und wir Bugs vom QA-Team oder auch von NutzerInnen gemeldet bekamen. Viele der Lösungen zu diesen Problemen sind aktuell in Buganizer in einzelnen Bugreports beschrieben. Ebenso haben jegliche Feature- und Design-Änderungen und -Neuentwicklungen Implikationen für die Accessible User Experience. Es ist wichtig, diese im Blick zu behalten und jede Design-Änderung ebenfalls in der Definition der barrierefreien Nutzungserfahrung nachzuziehen.

Organisation Starke Unterstützung und ein klares Mandat vom Top-Management zu bekommen, war sehr hilfreich, um Engineering- und Produktmanagement-Ressourcen zu erhalten und Accessibility gegenüber anderen Anforderungen zu priorisieren. Allerdings erlebten wir auch als Herausforderung, die gerade für Barrierefreiheit dringend erforderliche Konsistenz über Produkte hinweg zu erreichen, wenn viele Produktteams gleichzeitig auf ein ehrgeiziges Ziel losstürmen. Kontinuierliches Testen ist unerlässlich. Von großem Vorteil für das Calendar Team war es, dass einige Mitglieder des QA-Teams sich für einige Monate komplett auf das Testen von Accessibility konzentrieren konnten. Ein internes Google Accessibility Rating (GAR) half bei der Priorisierung der gefundenen Probleme für das Produktmanagement. Jetzt, wo ein

188

Mitch Hatscher, Astrid Weber

gewisser (hoher) Standard erreicht worden ist, stellt sich allerdings die Frage, wie Accessibility Bugs gegenüber den anderen Bugs oder gar der Entwicklung von neuen Features zu gewichten sind. Es stellte sich ebenfalls als sehr hilfreich heraus, ein Team von Accessibility-Experten innerhalb der Organisation zu haben und auf einen Pool von internen und externen trusted testers mit Einschränkungen zurückgreifen zu können, um zeitnah Ideen und Konzepte diskutieren und testen zu können.

Spezifische vs. generische Lösung und Implementation Unsere internen Accessibility-Experten rieten uns davon ab, Accessibility-spezifisches Design zu implementieren. Der Code werde oft später nicht gewartet und könne „spröde“ werden, so dass die ursprünglich optimierte Erfahrung dann häufig nicht mehr funktioniere. Für Calendar sind wir allerdings an mehreren Stellen von dieser Empfehlung abgewichen und haben für einzelne Elemente eine besondere Experience für Barrierefreiheit implementiert. Beispielsweise bewegen wir den „Floating Action Button“ auf dem iPhone von der rechten unteren Bildschirmecke in die obere horizontale Action Bar, wenn VoiceOver eingeschaltet ist – der eingebaute Screen Reader in iOS, der auch zusätzliche Gesten zur Steuerung freischaltet. Durch Designentscheidungen wie diese versuchen wir, jeder Gruppe von NutzerInnen die bestmögliche Produktinteraktion zu ermöglichen und alle unsere NutzerInnen dabei zu unterstützen, zu jedem Zeitpunkt den Überblick über ihre täglichen Termine und Aufgaben zu haben. Idealerweise bringen UI-Komponenten in der Plattform ihre Accessibility-Eigenschaften bereits mit, so dass ein hohes Maß an Konsistenz über das gesamte Design-System hergestellt werden kann und Änderungen über das System hinweg ausgerollt werden können. In der Entwicklung von Google Calendar war dies nur eingeschränkt möglich: Plattformübergreifend befanden sich die UI-Komponenten von Material Design, Googles neuer Design-Sprache im damals gerade angekündigten Android Lollipop-Release, zu diesem Zeitpunkt noch in der Konzeptionsphase (Google, 2015b).

Ein Accessibility (a11y)-Konzept für Google Calendar

Abbildung 1: Google Calendar iPhone App ohne VoiceOver: der „Floating Action Button“ sitzt in der rechten unteren Bildschirmecke

189

Abbildung 2: Die iPhone App mit VoiceOver – der „+“Button wird in die Action Bar verschoben (rechte obere Ecke)

Unterschiedliche Plattformen weisen unterschiedliche Accessibility-Standards auf. Diese Unterschiede wirken sich auf die Lösungen aus und erfordern die Erstellung spezifischer Spezifikationen für Plattform (Android vs. iOS vs. Web) und Gerätetyp (Handy vs. Tablet vs. Desktop) (Apple, 2015; Google, 2015a; O Connor, 2012). Einige Beispiele für diese Unterschiede: ¥ Rotor (iOS) vs. Local / Global Context Menu (Android): iOS-NutzerInnen können mittels einer Zwei-Finger-Drehbewegung ein Menü aufrufen, in dem sie beispielsweise die Granularität der VoiceOver-Ausgabe (Buchstabe vs. Wort vs. Absatz) oder FokusSprungweiten definieren. In Android erlauben Local und Global Context Menu ähnliche, aber nicht identische Aktionen ¥ Fokus-Behandlung: iOS setzt den Fokus automatisch auf das erste Element einer jeden Bildschirmseite, so dass immer ein Element den Fokus hat. Android kennt kein automatisches Setzen des Fokus

190

Mitch Hatscher, Astrid Weber

¥ Gesten: iOS verwendet drei-Finger-Wischbewegungen, Android zwei-Finger-Wischbewegungen für weite Sprünge ¥ Tastaturkürzel: Dies betrifft v.a. die unterschiedlichen Screen Reader-Systeme für den Desktop, die jeweils unterschiedliche Tastaturkürzel verwenden; aber auch Tastaturunterstützung für Tablets Barrierefreiheit für native Apps ist einfacher zu handhaben als fürs Web, weil die Accessibility-Technologien ins jeweilige mobile OS integriert sind und eine Anwendung daher weiß, ob die NutzerInnen eine unterstützende Technologie verwenden. TouchInteraktion stellt allerdings eine besondere Herausforderung dar. Dagegen “weiß” die WebAnwendung nicht, dass sie z.B. mit einem Screen Reader genutzt wird. In diesem Fall können wir keine spezifischen Accessibility Experiences definieren, sondern müssen die barrierefreie Nutzungserfahrung grundsätzlich in das System hineingestalten (O Connor, 2012; Pickering, 2014; Rucker et al., 2006). Diejenigen Nutzer, von denen wir wissen, dass sie eine spezifische unterstützende Technologie verwenden, können leichter bedient werden, da wir ihre Bedürfnisse kennen und so das Design anpassen können (z.B. mit speziellen Modi, High Contrast etc.). Herausfordernder ist es, für Nutzer zu gestalten, die eine Einschränkung mitbringen, aber keine unterstützende Technologie verwenden: z.B. Farbfehlsichtigkeit oder eine mildere Form einer Sehbehinderung. Hierzu zählen NutzerInnen mit nicht korrigierbaren Hornhautveränderungen und ältere NutzerInnen. Die unterschiedlichen Ansprüche und Präferenzen in Bezug auf Kontrast und Farbkonzept unterschiedlicher Gruppen von NutzerInnen stellen eine kontinuierliche Herausforderung ans visuelle Design dar, da sich die Frage stellt: Was ist ein universell funktionierendes, attraktives Design, das die Usabilityund Accessibility-Bedürfnisse aller Nutzer berücksichtigt?

Fazit Die folgenden zentralen Erkenntnisse ergaben sich für uns aus diesem Projekt: ¥ Accessibility muss – wie Usability – von Beginn an Teil der Produktdefinition sein, weil Accessibility einige spezifische Anforderungen beinhaltet und bei der Schätzung des Entwicklungsaufwandes berücksichtigt werden muss ¥ Accessibility und Usability schließen sich nicht aus, sie ergänzen sich – gute Usability ist eine wichtige Grundlage für Accessibility. Als Designer muss man allerdings jeweils entscheiden, ob man einen Accessibility Layer auf eine bestehende Nutzungserfahrung aufsetzt oder eine neue, alternative barrierefreie Erfahrung zusätzlich zur allgemeinen UX definiert. ¥ Es gibt interessante Spannungsfelder zwischen Accessibility-Anforderungen und visuellem Design, z.B. bei Kontrastverhältnissen zwischen Schrift- und Hintergrundfarbe

Ein Accessibility (a11y)-Konzept für Google Calendar

191

¥ So, wie man die allgemeine Nutzungserfahrung in Testverfahren einschätzen kann, kann man auch die barrierefreie Nutzungserfahrung simulieren, bereits früh Nutzerfeedback sammeln und über das Design iterieren ¥ Die Gestaltung der barrierefreien Nutzungserfahrung erwies sich als extrem kleinteilig und erforderte ein hohes Maß an Abstraktionsvermögen. Während der Gestaltungsprozess ähnlich ablief wie bei herkömmlicher UX-Arbeit, waren die Problemlösungen i.d.R. eben keine vorrangig visuellen Lösungen, sondern eine Kombination aus visuellen, auditiven, haptischen Reizen und zusätzlichen Definitionen des Systemverhaltens (z.B. wenn das System, wie bei iOS, für die NutzerInnen den Fokus setzt) Abschließend möchten wir noch festhalten: Inclusive Design bedeutet nicht nur: Design für Menschen mit Einschränkungen in der visuellen Wahrnehmung. Mehrfachbehinderungen (wie z.B. blind / gehörlos) stellen besondere Herausforderungen dar; starke motorische oder gar kognitive Einschränkungen noch deutlich mehr. Hier stehen wir noch ganz am Anfang. Literatur Apple Inc. (2015). Accessibility for Developers: iOS. https://developer.apple.com/accessibility/ios/ Letzter Zugriff: 22.6.2015 Cunningham, K. (2012). Accessibility Handbook. Sebastopol, CA: O’Reilly Media. FastCompany (2015): Google's Guide To Designing With Empathy. http://www.fastcodesign.com/ 3047545/googles-guide-to-designing-with-empathy Letzter Zugriff: 22.6.2015 Google Inc. (2015a). Android Developers: Accessibility. https://developer.android.com/guide/topics/ ui/accessibility/index.html Letzter Zugriff: 22.6.2015 Google Inc. (2015b). Material Design: Accessibility. https://www.google.com/design/spec/usability/ accessibility.html# Letzter Zugriff: 22.6.2015 Horton, S. & Quesenbery, W. (2014). A Web for Everyone: Designing Accessible User Experiences. Brooklyn, NY: Rosenfeld Media. O Connor, J. (2012). Pro HTML5 Accessibility. New York, NY: Apress Media. Parker, T., Jehl, S., Wachs, M.C., & Toland, P. (2010). Designing with Progressive Enhancement: Building the Web that Works for Everyone. San Francisco, CA: New Riders. Pickering, H. (2014). Apps For All: Coding Accessible Web Applications. Freiburg: Smashing Magazine GmbH. Rutter, R., Lauke, P.H., Waddell, C., et al. (2006). Web Accessibility: Web Standards and Regulatory Compliance. New York, NY: Apress Media.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 192- 202.

Personalisierung & Dynamic Content Konzeption und Vorgehen zur Einführung personalisierter Inhalte und Angebote Joachim Stalph

Joachim Stalph

elaboratum GmbH Kaflerstrasse 2 81241 München [email protected]

Abstract Auf den meisten Webseiten bekommt jeder Besucher einheitlich die gleichen Inhalte angezeigt, unabhängig davon, ob er bereits einmal die jeweilige Webseite besucht hat und sich daraus z.B. ein Produktinteresse ableiten lässt oder ob er zum ersten Mal das Portal betritt. Durch diese einheitliche Behandlung der Besucher besteht das Risiko, dass in höherem Maße Abschluss- und Kontaktpotenziale verloren gehen, da der Kunde nicht schnell genug die Themen und Produkte findet, die für ihn relevant sind. Dieser Praxis-Bericht, der auf eigenen Projekterfahrungen beruht, gibt Einblicke in die nutzer-zentrierte Herangehensweise, Konzeption und Umsetzung eines Personalisierungs-Projektes, das das Ziel verfolgt sowohl Erstbesuchern als auch Wiederkehrern individuell-relevante Inhalte und Produkte anzuzeigen.

Keywords Personalisierung, Dynamic Content, Smart Data, Conversion Optimierung, Konzeption,

Einleitung Im Prozess der Conversion Optimierung versuchen Konzepter die Ziele und Motive der Internetnutzer zu verstehen um dementsprechend Anforderungen an die Webseite abzuleiten. Ziel ist es potenzielle Kunden bestmöglich sowohl kommunikativ abzuholen als auch hinsichtlich der Customer Journey zielgerichtet führen zu können. Hierbei kommt man an verschiedenen Fragestellungen nicht herum: ¥ Wer sind die Nutzer überhaupt? ¥ Mit welcher Intention kommen sie auf unsere Webseite?

Personalisierung & Dynamic Content

193

¥ Kommen sie zum ersten Mal oder sind es Wiederkehrer? ¥ Müssen diese Nutzer anders behandeln und führen als den Erstbesucher? Für all diese Fragen sucht man in verschiedenen Projekten nach Antworten, um dann Anforderungen an die Webseite abzuleiten und ein Konzept zu entwickeln, dass ideal zu der identifizierten Zielgruppe passt. Die Zielgruppe an sich ist aber in vielen Fällen wiederum ein Kompromiss, der sich auf den kleinsten gemeinsamen Nenner der vielen verschiedenen Anforderungen der einzelnen Nutzer reduziert. Darüber hinaus fokussiert man sich viel zu häufig darauf die Customer Journey offsite zu optimieren, in dem man möglichst genau plant wie, welcher Traffic auf welche Landingpage geführt wird. Auf der Seite selbst geht man davon aus, dass durch ein intelligentes Navigationskonzept und eine optimierte Onsite-Suche bereits alles getan ist, und sich der Nutzer ab hier alleine zurechtfindet. Sollten sich Konzepter an dieser Stelle tatsächlich schon zurücklehnen? Ist diese Annahme ausreichend? Kann man da nicht noch weiterdenken? Was wäre eigentlich wenn man jeden einzelnen Nutzer erkennen würden und Daten-basiert seine ideale Customer Journey individuell vorhersagen könnte um eine 1:1 Personalisierung der Webseite damit zu ermöglichen? Welche Auswirkung hätte dies auf die Conversion Rate? Und ist dies überhaupt so möglich? Ja, ist es, und andere Branchen denken nicht nur intensiv darüber nach, sondern experimentieren bereits mit ersten Lösungen, sogenannten predictive experiences. Predictive Experiences Die folgenden beiden Ansätze haben gemein, dass sie auf eigens erhobenen Daten aufsetzen, diese intelligent analysieren und auswerten um Muster zu erkennen. Auf Basis dieses Ansatzes versuchen unterschiedliche Branchen bereits heute die User Experience mit Hilfe von Vorhersagen zu verbessern. Vor allem die Automobilbranche arbeitet fleißig an Konzepten und Anwendungsfällen für die sogenannte „Predictive User Experience“ (Mercedes. 2014), wie es Mercedes Benz in Ihrem konzeptionellen Ansatz Intelligent Drive nennt. Zugrunde liegende Idee hierbei ist, dass man als Fahrer mit dem Einsteigen ins Fahrzeug ständig Entscheidungen treffen muss, die mit der eigentlichen Aufgabe, das Autofahren, nicht unbedingt viel zu tun haben: Welche Route soll ich nehmen? Welche Temperatur soll ich einstellen? Welche Musik soll ich hören? Hier kann das „Predictive Interface“ (Mercedes. 2014), also das intelligente, vorhersagende Fahrzeug, dem Fahrer viele lästige Routinen abnehmen, so dass er sich voll und ganz auf das Fahren konzentrieren kann. Wie das funktioniert? Das Fahrzeug lernt das Verhalten des Fahrers, erkennt wiederkehrende Muster und kann Umwelteinflüsse wie beispielsweise die Außentemperatur und deren Auswirkungen auf den Fahrer erkennen.

194

Joachim Stalph

Abbildung 1: Mercedes Benz Intelligent Drive (Mercedes. 2014)

Mercedes Benz geht somit einen großen Schritt um das künftige Autofahren einerseits komfortabler und andererseits sicherer zu machen. Mercedes Benz nutzt hierbei die Daten des Autos um auf diese Weise das Fahrverhalten zu messen, zu analysieren und Muster zu erkennen. Diese Muster sollen dann in Form von Vorhersagen dem Fahrer das Fahren erleichtern, indem ihm zum Beispiel Entscheidungen abgenommen werden oder Einstellungen automatisch für vorgenommen werden. Einen anderen Anwendungsfall bedient ein neues Patent von Amazon in den USA, das „anticipatory shipping“ (Amazon Patent US8615473) genannt wird. Hinter diesem Patent steckt die Analyse der Kauf- und Suchmustern des Kunden um genau die Produkte herauszufiltern, die er wohlmöglich bei der nächsten Bestellung erwerben möchte. Auf Basis dieser Berechnungen werden dann die kundennahen Logistikzentren vorausschauend mit den entsprechenden Produkten versorgt, um dann im Falle einer Bestellung die Lieferzeiten zu minimieren. Vorhersagen und Personalisierung im E-Commerce Im E-Commerce sind Ansätze und Konzepte wie im Abschnitt zuvor beschrieben kaum verbreitet. Vielmehr findet man klassische Warenkorb- und Produktanalysen „andere Kunden kauften auch….“, die auf view-view und view-buy Analysen beruhen. Diese kennen wir schon seit Jahren, sind aber mittlerweile konzeptionell ausgereizt. Hinzu kommt, wie bereits beschrieben, dass eine Customer Journey Betrachtung des Kunden heute vor allem über die Vermarktungskanäle betrieben. Es wird also Zeit für neue Konzepte. Konzepte, die das Thema der Onsite-Optimierung in den Mittelpunkt stellen und Ansätze wie die von Mercedes Benz und Amazon als Vorbild nehmen. Diese Ansätze beruhen auf Vorhersagen, die durch die Analyse von Nutzerdaten

Personalisierung & Dynamic Content

195

berechnet werden, und auf Basis der Berechnung das Frontend dynamisch verändern, individuell auf den Nutzer zugeschnitten. Ziel dieses Beitrags ist es einen Konzeptansatz für kundenindividuelle Optimierung des Angebotes auf Basis von Verhaltensvorhersage und Kundeninformationen zu beschreiben.

Vorgehen zur Erhebung und Analyse von Daten mit dem Ziel Personalisierungen dynamisch anzuzeigen Für die Dynamisierung kundenindividueller Inhalte müssen Daten und Informationen in unterschiedlichen Phasen der Customer Journey erfasst und analysiert werden. Das Vorgehen zur Sammlung von Daten, Analyse der Daten und Ausspielung dynamischer Inhalte wird nachstehend in 5 Phasen Schritt für Schritt beschrieben.

Abbildung 2: Übersicht der unterschiedlichen Phasen

Phase 1: Der digital footprint Grundlage für Vorhersagen und entsprechende dynamische Inhalte im Frontend ist die Erhebung von Daten. Dies fängt bereits beim ersten Aufruf der Webseite an, denn dieser verrät viel über den Besucher. Durch den sogenannten digital footprint weiß man schon viel über den Nutzer, obwohl er sich auf der eigentlichen Webseite noch nicht bewegt hat. Durch Informationen wie Geolocation, Sprache, Device, Betriebssystem, Referrer etc. bekommt man bereits ein erstes Bild des Nutzers, das es gilt weiter anzureichern. Phase 2: Onsite Daten sammeln Entlang der Customer Journey auf der Webseite werden diverse weitere Daten erfasst, die den bereits erhobenen digital footprint anreichern und ein immer klarer werdendes Bild des Nutzers zeichnen.

196

Joachim Stalph

Abbildung 3: Daten sammeln pro Seitentyp und Element

Die Beschreibung einer typischen Customer Journey eines Nutzers in einem TennisWebshop veranschaulicht welche Daten gesammelt werden können: 1.

Max Mustermann öffnet in seinem Mailaccount den Newsletter von seinem Lieblings Tennis Webshop ¥ Newsletter geöffnet ¥ Verweildauer ¥ Auf welches Element im Newsletter wurde geklickt ¥ Newsletter-Abonnent seit wann ¥ Durchschnittliche Öffnungsrate

2.

Max Mustermann klickt einen Link im Newsletter und gelangt auf die Startseite des Webshops ¥ Page View Startseite ¥ Verweildauer Startseite ¥ Auf welches Element wurde geklickt ¥ Wiederkehrer oder Erstbesucher ¥ Wievielter Besuch ¥ In welchem Zeitraum

3.

Max sucht auf der Startseite nach „Nike Tennisschuh“ ¥ Suche nach „Nike Tennisschuhe“ ¥ Page View Suchergebnisseite ¥ Produktinteresse „Nike Tennisschuh“ ¥ Wie weit wird gescrollt? ¥ Werden die weiteren Suchergebnisseiten (2ff.) angesehen? ¥ Werden Suchfilter genutzt, welche? (Geschlecht, Größe, Preisspanne etc.) ¥ Heavynutzer der Suche?

4.

Max sucht sich auf der Suchergebnisseite einen Schuh aus und wird auf die Artikeldetailseite geführt ¥ Page View Detailseite ¥ Verweildauer Detailseite? ¥ Welche Elemente angesehen? Z.B. Rezensionen ¥ Renzensionen geschrieben und/oder gelesen? ¥ Klick auf CTA „in den Warenkorb“?

Personalisierung & Dynamic Content

5.

197

Max legt den Schuh in den Warenkorb und schließt den Checkout ab ¥ Checkout gestartet ¥ Checkout abgeschlossen? ¥ Abgebrochen? An welcher Stelle? ¥ Verweildauer im Checkout? ¥ Welche Zahlart? ¥ Welche Versandart? ¥ Gutschein eingelöst? ¥ Welche Produkte wurden in der Vergangenheit gekauft?

Die gesammelten Bewegungs- und Sessiondaten Personalisierungs-Datenbank gespeichert:

werden

strukturiert

in

einer

Abbildung 4: schematische Skizze der Personalisierungs-Datenbank

Pro Nutzer gibt es eine eindeutige ID, der die einzelnen Sessions des Nutzers mit dieser ID zugeordnet werden. Pro Session werden zusätzlich alle Bewegungsdaten (page views, Verweildauer etc.) des Kunden festgehalten. Für die Spalten in der Tabelle sollte man bei der Konzeption Annahmen treffen, welche Werte für die Berechnung von Vorhersagen für das Ausspielen von Dynamischem Content wichtig sein könnten. Phase 3: Daten analysieren Die gesammelten Bewegungsdaten werden auf Basis eines Regelwerks für jede Nutzer ID analysiert um sogenannte Muster bilden zu können, nach denen die Nutzer eingeordnet und bewertet werden können. Ein einfaches Muster ist z.B. das „Produktinteresse“. Die dahinterliegende Regel betrachtet über einen bestimmten Zeitraum (hier kann man die durchschnittliche Dauer von Erstkontakt

198

Joachim Stalph

bis zum Kauf als Grundlage nehmen) die Anzahl der Webseitenbesuche des Shops und die Häufigkeit der page-views bestimmter Produkte. So kann man für den jeweiligen Nutzer ein spezifisches Produktinteresse herausfinden. Ähnliches gilt auch für das Muster „Cross Channel“ in dem der bevorzugte Kanal des jeweiligen Nutzers analysiert wird. Ein komplexeres Muster ist z.B. „Frequenz und Umsatz“. Hier kann mit Hilfe einer mathematischen Formal aus Anzahl der Besuche in einem bestimmten Zeitraum, Intervall der Besuche und erzielter Umsatz ein Score-Wert berechnet werden, der wiederum als Grundlage für die Einstufung des jeweiligen Nutzers verwendet werden kann.

Abbildung 5: Beschreibung des Regelwerks für die Muster „Frequenz und Umsatz“ und „Cross Channel“

Ein Beispiel: Für den Nutzer mit der ID #123456789 (siehe Abbildung 4 und 5) stehen folgende Muster in der Datenbank: ¥ Ein „Frequenz und Umsatz“ Score von 45 ¥ Als „Produktinteresse“ die Kategorie Tennisschläger, und ¥ und als bevorzugten Kanal wurde TV ausgemacht (messbar z.B. über eine Bestellhotline, die nur für TV Werbung verwendet wird). Ergebnis dieser Analyse ist ein individuelles Bild des Verhaltens eines Nutzers samt Vorlieben (favorisierter Kanal) und Produktinteressen. Dies ist ein erster wertvoller Schritt, jedoch müssen diese Informationen aggregiert und die Nutzer eindeutigen Segmenten zugeordnet werden, die bei der Anzeige des dynamischen Contents im Frontend als Selector dienen. Die Segmente werden auch Dynamisierungsfaktoren genannt, da auf Basis dieser Information entschieden wird, was sich konkret auf der Webseite ändert. Anders ausgedrückt kann anhand dieser Segmente konkret gesteuert werden, welches Analyseergebnis (z.B. der Kundenstatus: A oder B) wichtig ist und in Form des personalisierten Contents belohnt wird. Für das Frontend bedeutet dies, dass für jedes der Segmente der Inhalt der Webseite auf den identifizierten Kunden optimiert werden kann. Wenn man nun auf Basis der in Abbildung 9 gezeigten Muster ein zweites Set an Regeln anwendet, ordnet man so den Nutzer bestimmten Segmenten zu (siehe Abbildung 10).

Personalisierung & Dynamic Content

199

Segmente sind in diesem Kontext die „Trigger“, die eine konkrete dynamische Veränderung auf der Webseite auslösen. Beispiel für diese „Trigger“ ist zum Beispiel der Kundenstatus: ¥ Kundenstatus A = guter Kunde à qualifiziert sich für spezielle Preis-relevante Aktionen wie Gutscheine, Versandkostenfrei Aktionen etc. ¥ Kundenstatus B = weniger guter Kunde à noch nicht qualifiziert für Aktionen, es kann aber ein Hinweis angezeigt werden, dass der Kunde eine überdurchschnittlich hohe Retourenquote hat, und er, wenn er diese senkt, künftig versandkostenfrei bestellen kann. Eine konkrete Regel für die Einsortierung von Nutzern in die Segemente kann z.B. sein: wenn „Frequenz und Umsatz“-Index > 40, dann Kundenstatus A (siehe Abbildung 6). Diese Regeln können beliebig komplex ausgestaltet werden und bedingen gründlicher konzeptioneller Vorarbeit und Abstimmung wann ein Kunde zum Beispiel den Status A oder B erhält. Die Information, dass ein Kunde den Status A hat, kann z.B. im täglichen Betrieb für den Callcenter-Agenten bedeuten, dass er diesem Kunden beim nächsten Anruf einen Discount von 20% einräumen darf, um diesen vom Kauf zu überzeugen. Genauso funktioniert dies natürlich auch auf der Webseite. Wenn dort ein Nutzer als A-Kunde identifiziert wird, so wird diesem auch hier ein Gutschein als personalisierter Verkaufsverstärker angezeigt, den er im Warenkorb einlösen kann.

Abbildung 6: Anwendung der Regel

Insgesamt bietet dieser Ansatz vor allem Vorteile hinsichtlich der Flexibilität und Agilität wenn man sich mit den Themen Vorhersagen und Personalisierung erstmalig auseinandersetzt. Einerseits können diese Regeln sowohl in Echtzeit als auch offline angewandt werden. Gerade in den Anfängen der Personalisierung ist die notwendige Systemlandschaft häufig noch nicht darauf ausgelegt Berechnung in Echtzeit durchzuführen. So besteht die Möglichkeit Berechnungen über Nacht durchzuführen und die Ergebnisse für die nächste Session des Nutzers zu verwenden. Und andererseits ist weitere Flexibilität gegeben dadurch dass aufgrund der gewonnenen Erkenntnisse die Regeln jederzeit angepasst

200

Joachim Stalph

und verändert und auf den bestehenden Datenbestand der Kunden angewendet werden können. Dies ist wiederum zu Beginn notwendig, wenn man mit den einzelnen Werten und Regeln experimentiert bis man ein performantes Set gefunden hat. Eine unterschiedliche Gewichtung der Segmente kann außerdem auch unterschiedliche Usecases bedienen. Ein klares Bewusstsein der wichtigsten Usecases auf der Webseite ist daher unabdingbar. Der Ansatz kann dann über die Zeit flexibel ausgeweitet werden, in dem weitere Muster und Segmente ergänzt werden. Phase 4: Anzeige im Frontend Die dynamische Personalisierung des Contents kann auf Basis der Analyseergebnisse nun auf unterschiedliche Arten erfolgen. Die verschiedenen Möglichkeiten der Anpassung lassen sich in vier Gruppen bilden: 1.

2.

3. 4.

Anordnung und Priorisierung In dieser Kategorie kann man z.B. damit experimentieren die Primärnavigation anzupassen in dem je nach Nutzer ggf. Kategorien umsortiert oder sogar ausgeblendet werden. Insgesamt können Elemente der Webseite, wie aus dem responsive Webdesign bereits bekannt, umsortiert oder ausgeblendet werden. Unterschiedliche Inhalte Auf der Hand liegt das bereits erwähnte Beispiel eines Gutscheins, der dynamisch je nach Kundenstatus angezeigt werden kann. Weitere Ansätze sind konkrete ProduktTeaser, die direkt in die als bevorzugt identifizierte Produktkategorie linken. Produkt-Passung Auf Basis der Information, dass ein Nutzer Marken-affin ist können No-Name Produkte auf einer Seite entsprechend gegen Marken-Artikel getauscht werden. Preise/Preispunkte Dynamic Pricing ist in diesem Zusammenhang ein großes Thema, um unter bestimmten Voraussetzungen wie Tageszeit, Wettervorhersage o.ä. Preise dynamisch anzupassen. Zusätzlich kann man hier auch wieder den Kundenstatus als mögliche Bedingung zugrunde legen.

Zu beachten ist jedoch, dass mit jeder zusätzlichen Dynamisierung der redaktionelle Aufwand steigt. Mit Blick auf die Pflege in einem Content Management System zeigt folgende Formel die Komplexität auf: X = Segmente * Muster * Positionen *Varianten Aus diesem Grund halten wir eine intelligente CMS Integration des Themas für einen effizienten Workflow im Betrieb für absolut notwendig. Phase 5: Testing Wie grundsätzlich bei der Conversion Optimierung bekannt, so gilt auch hier „Optimierung ohne Testing ist Esoterik!“ Die in Phase 4 beschriebenen Vorschläge zur Anpassung der Inhalte sollten alle auf jeden Fall getestet und nicht als gesetzt angesehen werden. Dies sind keine allgemein gültigen Best

Personalisierung & Dynamic Content

201

Practices, da Erfolg und Misserfolg des personalisierten Contents stark von Branche, Geschäftsmodell und identifizierten Zielen abhängig ist. Erste Projekte auf Basis dieses Vorgehens zeigen, dass folgendes Vorgehen zielführend ist, um zu Beginn strukturelle Fehler zu vermeiden, aber gleichzeitig belastbare Ergebnisse zu erzielen, die das Management überzeugen können und somit mittelfristig den Weg in Richtung mehr Personalisierung auf der eigenen Webseite ebnen. Das Vorgehen ist bewusst an den klassischen Test- und Optimierungsprozess angelehnt, um das Thema Personalisierung so einfach wie möglich in bereits vorhandene Prozesse und Arbeitsabläufe zu integrieren. 1.

2. 3.

4. 5. 6. 7.

Der erste Tipp ist klein anzufangen. Es macht wenig Sinn sich eine umfassende Infrastruktur aufzubauen oder einzukaufen ohne erste Ziele definiert zu haben, und diese mit einfachen Usecases und idealerweise Bordmitteln verifizieren zu können. Einen Ansatz bieten zum Beispiel bestehende A/B Testing Lösungen, die häufig Personalisierungs-Module beinhalten. Auf Basis dessen lassen sich erste Usecases testen und Potenziale der Personalisierung herausfinden. Für den nächsten Schritt und bei allen Erweiterungen in der Personalisierungslogik ist es wichtig klare Ziele zu definieren, die klar zu prüfen sind. Ein erstes Ziel könnte zum Beispiel „mehr views auf Produktdetailseiten“ sein. Wenn dieses Ziel erreicht ist, bedeutet dies, dass es bereits möglich ist Produktinteressen vorherzusagen und die Kunden entsprechend auf die Detailseiten zu führen. Der nächste logische Schritt wäre dann, zu messen ob auch mehr Nutzer in den Checkout einsteigen. So kann man sich an der Customer Journey entlang hangeln und die Ziele stetig erweitern und anpassen. Dies wäre Schritt 3, das Verhalten der Nutzer ständig zu messen und mit den gesteckten Zielen abzugleichen. Schritte 4-7 sind vor allem im Fehlerfall wichtig und man sich fragt, warum die Ziele nicht erreicht werden. Wie im klassischen A/B Testing sollten hierfür Hypothesen aufgestellt werden. Auf Basis der Hypothesen werden verschiedene Varianten erstellt, von denen man glaubt, dass diese das analysierte Problem lösen könnten. Diese Varianten werden mit Hilfe eines multivariates Testing auf die Webseite gebracht und die Performance einer jeden Variante gemessen. Im letzten Schritt wird dann die Gewinner-Variante ermittelt, die verrät was man hinsichtlich der Personalisierung verbessern sollte.

Schlussteil Dieser Beitrag beschreibt ein umfassendes konzeptionelles Vorgehen, mit dem in Anlehnung an die Ansätze von Mercedes-Benz und Amazon Vorhersagen auf Basis der Nutzerdaten berechnet werden können, um auf diese Weise Webseiten-Inhalte dynamisch anzupassen.

202

Joachim Stalph

In wenigen Stichpunkten zusammengefasst ist in diesem Ansatz folgendes zu tun und zu bedenken: ¥ Zielgruppe und wichtigste Usecases, die es zu optimieren gilt, sollten bekannt sein ¥ Bewegungsdaten, die sie eh in Ihrem Analytics System sammeln, strukturiert in eine Personalisierungs-Datenbank schreiben ¥ Konzeption und Anwendung eines ersten Regelwerkes um Muster wie z.B. das „Produktinteresse“ zu erkennen ¥ Konzeption und Anwendung eines zweiten Regelwerkes um Nutzer verschiedenen Segmenten wie „Kundenstatus A oder B“ zuzuordnen, die im Frontend steuern ob und welcher Inhalt dynamisch angepasst wird ¥ Ausspielung der Personalisierung im Frontend ¥ Erfolgsmessung und ggf. Anpassung der Regelwerke um die verschiedenen Use Cases ideal zu unterstützen

Die konkreten Vorteile dieses Vorgehens 1. 2. 3. 4.

Man hat einen Konzeptansatz zur Hand mit dem schnell erste Personalisierungen auf die Webseite gebracht werden können. Der Ansatz lässt sich beliebig ausbauen und erweitern. Das Vorgehen lässt sich leicht in bestehende Test- und Optimierungs-Prozesse und Arbeitsabläufe integrieren. Die wichtigsten Use Cases auf einer Webseite können dynamisch unterstützt werden, Nutzer können individuell angesprochen werden, und auf diese Weise die Conversion Rate erhöht werden.

Literatur Amazon (2013). Method and system for anticipatory package shipping. US Patent. US 8615473 B2 Mercedes Benz. (2013). Interactive Prototype: Predictive User Experience. http://ces.mercedespressevents.com/content_predictive.php

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 203- 212.

Agrarwirtschaft meets Mobile UX Wie Apps zukünftig die Landwirtschaft unterstützen Steffen Hess, Felix Kiefer, Karl-J. Wack, Dominik Magin

Steffen Hess

Felix Kiefer

Karl-J. Wack

Dominik Magin

Fraunhofer IESE Fraunhofer-Platz 1 67633 Kaiserslautern [email protected] let's dev GmbH & Co. KG Alter Schlachthof 23c 76131 Karlsruhe [email protected]

John Deere ETIC Straßburger Allee 3 67657 Kaiserslautern [email protected] Fraunhofer IESE Fraunhofer-Platz 1 67633 Kaiserslautern [email protected]

Abstract Die Verbreitung von mobilen Endgeräten nimmt ununterbrochen zu. Im Consumer Bereich sind mobile Applikationen bereits weit verbreitet und erfreuen sich einer häufigen Nutzung. Während man im Consumer Bereich bereits diverse Verhaltensänderungen, wie beispielsweise „Second Screen Behavior“ beobachten kann, nehmen mobile Applikationen in der Industrie nur langsam Einzug und erschließen neue Anwendungsfelder – so auch in der Agrarwirtschaft. Das vorliegende Paper zeigt unser nutzerzentriertes Vorgehen bei der Entwicklung eines Mobile Ecosystem für die Agrarwirtschaft und hebt dabei insbesondere die Herausforderungen der Branche und unsere genutzten Best Practices hervor.

Keywords UX, Mobile, UCD, Ecosystem, Apps, Agrarwirtschaft

Einleitung Die Weltbevölkerung steigt von Jahr zu Jahr. Es wird erwartet, dass bis zum Jahr 2050 die gesamte Weltbevölkerung sich um zwei Milliarden Menschen vergrößert – bei gleichbleibender Anbaufläche für Nahrungsmittel. Daraus resultieren neue Herausforderungen an die Agrarwirtschaft und die damit verbundenen Unternehmen,

204

Steffen Hess, Felix Kiefer, Karl-J. Wack, Dominik Magin

insbesondere im Bereich der Landmaschinen. Zu diesen zählen beispielsweise Traktoren, Erntemaschinen, Bodenbearbeitungs- und Sägeräte. Durch den Einsatz sowie die ständige Weiterentwicklung der Landmaschinen und der damit verbundenen Technologien konnte die Nahrungsmittelproduktion in den letzten 50 Jahren verdoppelt werden. Um das Ziel der sog. Präzisionslandwirtschaft – Ertragsoptimierung und erhöhte Ressourceneffizienz – weiterhin zu verfolgen, werden daher zukünftige Trends und Technologien im Bereich mobiler Maschinen entwickelt. Hierzu zählen beispielsweise Produkte und Dienstleistungen unter Verwendung von satellitengesteuerten Lenksystemen, Dokumentationssystemen, Telemetrieanwendungen als auch eine Vielzahl von mobilen Lösungen. Konzeption sowie Realisierung von solchen mobilen Lösungen waren Ziele der Kooperation. Dabei war eine Evolution von einzelnen App hin zu einem „Mobile Ecosystem“ (Hess et al. 2015) zu beobachten (Abbildung 1). Mit dieser Entwicklung gingen ständig wechselnde Anforderungen an die Arbeitsweise einher, welche insbesondere in der Mobile UX mündeten.

Abbildung 1: Evolutionsstadien des Mobile Ecosystems

Zu Anfang der Kooperation stand die initiale Entwicklung einer einzelnen App mit lokaler Datenhaltung. Dabei beschränkten sich die Herausforderungen auf die Optimierung der Mobile UX für diesen speziellen Anwendungsfall unter Anwendung des unternehmensspezifischen Look & Feels. In der darauf folgenden Phase war zu beobachten, dass eine Vielzahl von einzelnen Apps existierte. Damit verbunden waren vor allem Herausforderungen bzgl. Konsistenz über verschiedenen Geräteklassen und Plattformen. Entscheidend dabei war, wie durch hauptsächlich organisatorische Maßnahmen, Konsistenz und damit einhergehend auch eine gute UX herbeigeführt werden konnten. Phase 3, die verbundene App Community und insbesondere der Übergang zu Phase 4 ließen erstmals ein eigentliches Ecosystem entstehen. Dabei wurde organisatorisch ein eigenes Team aufgebaut und eine globale Mobile UX Strategie erarbeitet. Einen maßgeblichen Einfluss auf die UX in den Applikationen hatte die Vernetzung der Backendsysteme und ging daher Hand in Hand mit der Spezifikation des Gesamtsystems. Innerhalb der Gesamtarchitektur sind sowohl marktreife Applikationen als auch Forschungsprototypen enthalten.

Einführung in die Domäne Agrarwirtschaft Entgegen der weitläufigen Meinung ist die Domäne der Agrarwirtschaft eine hochinnovative Branche, die sehr von technischer Unterstützung profitiert. GPS gesteuerte Lenksysteme,

Agrarwirtschaft meets Mobile UX

205

automatisierte Dokumentationserstellung oder der Einsatz von Telemetriesystemen sind Teil der täglichen Arbeit moderner agrarwirtschaftlicher Betriebe geworden. Die Branche befindet sich in einem ständigen Wandel um durch den gezielten Einsatz moderner Verfahren und Technologien Erträge, Prozesse und Ressourceneffizienz zu steigern. Dieser anhaltende Fortschritt führt dazu, dass innerhalb der Domäne Agrarwirtschaft ein sehr starkes Aufeinandertreffen von Generationen und Nutzergruppen stattfindet. So gibt es auf der einen Seite konservativ agierende Unternehmen, die über Jahre hinweg eigene Systeme entwickelt haben um den Betrieb zu führen. Oft basieren diese Systeme nur teilweise oder gar nicht auf Software. Dem gegenüber stehen progressive Landwirte, häufig auch mit Universitätsabschluss, die versuchen durch den Einsatz von softwaregestützten Systemen ihre betrieblichen Prozesse zu optimieren. Aus diesem breiten Spektrum unterschiedlicher potentieller Anwender ergeben sich große Herausforderungen für die Gestaltung mobiler Lösungen. Des Weiteren zeichnen sich die Benutzer durch eine hohe Individualität aus. Auf Grund unterschiedlicher Kombination aus Böden, Anbaugebieten, Mitarbeitern und persönlicher, jahrelanger Erfahrung werden die eigenen Lösungen als optimal empfunden, um den Betrieb effektiv und effizient zu führen. Dies erschwert die Einführung neuer Systeme. Die Diversität der Nutzer äußert sich auf vielen Ebenen, so variiert z.B. die Anzahl der Felder, die ein landwirtschaftlicher Betrieb bewirtschaftet von ca. 40 bis hin zu mehreren Hundert – klassische Ackerbauern haben darüber hinaus andere Anforderungen als beispielsweise Viehmastbetriebe oder im Maisanbau. Hinzu kommt eine große regionale Diversität. So gelten innerhalb von Deutschland je nach Bundesland unterschiedliche Bedingungen und Anforderungen an die Betriebe. International betrachtet sind diese Unterschiede noch prägnanter: So unterscheiden sich zum Beispiel Feldgrößen und Feldfrüchte, Bestimmungen und Landmaschinen in Nordamerika im Vergleich zu Europa sehr. Trotz der hohen Diversität können aber auch Gemeinsamkeiten innerhalb der angestrebten Nutzergruppe gefunden werden. Als Hauptzielgruppen für das Mobile Ecosystem wurden Lohnunternehmer und Landwirte gewählt. Trotz individueller Unterschiede lassen sich viele Gemeinsamkeiten im Hinblick auf Ziele und Tätigkeiten innerhalb der beiden Gruppen erkennen. Landwirte bewirtschaften ihren eigenen Hof und stellen in der Regel mehrere Produkte her. Lohnunternehmer hingegen besitzen vorrangig diverse Landmaschinen und bieten häufig ein breites Spektrum an Servicedienstleistungen, wie bspw. das Ausbringen von Gülle oder Erntetätigkeiten, an. Operative Unterschiede zeigen sich in der betrieblichen Planung. Landwirte fokussieren auf Ablaufplanung auf Basis der Felder und Anbaufrüchte, Lohnunternehmer fokussieren auf Kapazitätsplanung auf Basis von Kundenaufträgen. Für die Entwicklung eines Mobile Ecosystems sind neben Charakteristika der Nutzergruppe auch die aktuell verwendeten Softwarelösungen von besonderem Interesse. So ist zu beobachten, dass sehr häufig individuelle Lösungen wie angepasste Excel Tabellen verwendet werden. Farm Management Systeme sind aktuell eher im Hinblick auf Fakturierung und Dokumentation im Einsatz, selten jedoch zur tatsächlichen Planung und Durchführung der täglichen Arbeit. Auf Grund der großen Verbreitung mobiler Endgeräte sind diese überall dort im Einsatz, wo die Struktur der Mitarbeiter es zulässt. Häufig werden Chatlösungen zur Kommunikation eingesetzt. Zudem findet man aber auch fest montierte Tablets als zusätzliche Displays zum Haupt-HMI in der Fahrerkabine. Diese werden

206

Steffen Hess, Felix Kiefer, Karl-J. Wack, Dominik Magin

typischerweise zur Navigation oder auch zur Absprache in Flotten eingesetzt. Die Tatsache, dass fast jeder Mitarbeiter mit einem Mobilgerät ausgestattet ist und sich der komplette Tagesablauf völlig mobil gestaltet macht deutlich, wie hoch hier das Potential für ein Ecosystem mobiler Apps ist. Hauptproblem der Zielgruppe bzgl. Software ist das Fehlen einer integrierten Lösung. Die einzelnen mobilen Endgeräte – Smartphone, Tablets und Displays der Landmaschinen sind nicht vernetzt. Eine Hauptursache hierfür liegt in den sog. gemischten Flotten – Flotten bestehend aus Maschinen unterschiedlicher Hersteller – die häufig in Europa vorzufinden sind. Mobile bietet auch hier die Chance eine integrierte Lösung zu schaffen.

Vorgehensweise zur nutzerzentrierten Gestaltung eines Mobile Ecosystems Bei der Entwicklung des Mobile Ecosystems wurde sich grundlegend an den klassischen Human Centered Design (HCD) Prozess (vgl. ISO 9241-210) (siehe Abbildung 2) angelehnt. Dieser wurde jedoch erweitert, um die gegebenen Projekt- und Domänenanforderungen erfüllen zu können. Darüber hinaus war es ein zentrales Projektergebnis den HCD Prozess so zu erweitern, dass dieser für die Gestaltung von Mobile Ecosystems anwendbar ist. Hierfür wurde ein HCD Prozess für Mobile Ecosystems (HCDME) entwickelt, der in Abbildung 3 dargestellt ist.

Abbildung 2: Klassischer Human Centered Design Prozess

In diesem Kapitel wird der HCDME erläutert und konkret dargestellt, welche Aktivitäten in den einzelnen Phasen durchgeführt wurden. Im Fokus hierbei steht die Beschreibung des skizzierten Mobile Ecosystems im Anwendungsbereich Farm-Management. Sonstige mobile Lösungen, wie beispielsweise Apps aus dem Marketing Umfeld oder anderen Geschäftsbereichen sind nicht Teil der Betrachtung. Der HCDME Prozess beginnt mit einer Strategiephase (Doerr et al. 2014) in der grundsätzliche Entscheidungen getroffen werden, die sich mit der Unternehmensstrategie bzgl. des Einsatzes von mobilen Apps aber auch mit der Strategie für die Partizipation am

Agrarwirtschaft meets Mobile UX

207

Ecosystem befassen. So wurde im Projekt zunächst die grundsätzliche Herangehensweise an die Realisierung von mobilen Applikationen geklärt – u.a. auch die technische Fragestellung, welche mobilen Applikationen nativ und welche unter dem Einsatz von Webtechnologien entwickelt werden. Die Definition und Entwicklung dieser Strategie ist eine kontinuierliche Aktivität, die von vielen Entscheidungspunkten beeinflusst wird. Grundsätzlich ist anzumerken, dass zum jetzigen Zeitpunkt die Basisanwendung (ein umfassendes FarmManagement-System) als Webanwendung existiert und native Apps diese Webanwendung um Funktionalitäten erweitern, die im mobilen Anwendungskontext zur Verfügung stehen müssen.

Abbildung 3: Gelebter Human Centered Design Prozess für Mobile Ecosystems

Apps werden aktuell in folgende Kategorien eingeteilt: Apps, die Maschinen erweitern, sogenannte On-Board Apps; Apps, die Funktionalitäten zum Farm-Management bereitstellen (z.B. Einsatz- und Ablaufplanung); unterstützende Apps, die spezifische individuelle Funktionalitäten bereitstellen (z.B. Spritzempfehlungen für Landwirte).

¥ ¥ ¥

Aktivitäten Strategie ¥ ¥ ¥ ¥ ¥ ¥

Strategiedefinition bzw. Anpassung (auch Native vs. Web) Positionierung als Player im Ecosystem Anpassung existierender Services und Anwendungen Durchführung von Marktanalysen Möglichkeiten der Kooperation mit anderen Playern ausloten Schaffung von Business Cases Tabelle 1: Aktivitäten der Strategiephase

Vor allem vor dem Hintergrund einer tiefgehenden Verzahnung der mobilen Applikationen mit der Gerätehardware, der Verwendung von Sensoren, umfassende Offline-

208

Steffen Hess, Felix Kiefer, Karl-J. Wack, Dominik Magin

Funktionalitäten und spezielle Lösungen zur Integration von Maschinen, ist die Entscheidung auf eine rein native Entwicklung getroffen worden. Aufgrund der Marktsituation der mobilen Betriebssysteme wurde der Fokus hierbei auf Android und iOS gelegt. Eine besondere Erkenntnis aus der Projektphase ist, dass im Einzelfall die Verwendung einer Lead-Plattform pro App sinnvoll erscheint. In der Kontext- bzw. Analysephase wurde klassisch vorgegangen. So wurden sehr viele Kundeninterviews vor Ort bei potentiellen Nutzern durchgeführt. Dabei ergab sich die Möglichkeit einen guten Eindruck davon zu bekommen, welche Systeme von den Kunden aktuell genutzt werden. Dabei ist hervorzuheben, dass in der Branche besonders viele individuelle Insellösungen existieren. So arbeiten viele Nutzer mit Excellösungen – aber auch Mobilgeräte sind bereits flächendeckend im Einsatz. Hier sind die existierenden Lösungen jedoch nicht in einer Weise verfügbar, dass die Nutzer zufrieden sind. Um ein einfaches Beispiel zu nennen, häufig werden Messenger zur Kommunikation von Flotten eingesetzt. Limitierungen sind hier z.B., dass keine Dokumentation des Chatvorgangs in Zusammenhang mit der Arbeitsaufgabe gebracht werden kann, da u.a. für die Fakturierung eine solche verlangt wird. Im Hinblick auf die Entwicklung eines Mobile Ecosystem war in dieser Phase die Herausforderung zu bewältigen, die Anforderungen der Märkte in Europa und Nordamerika zu vereinen. Kontextanalysen wurden in verschiedenen Teams durchgeführt und verfolgten das Ziel, Anwendungsfälle zu finden, die im Testmarkt Europa identifiziert und evaluiert werden können, gleichzeitig aber auch für den Markt in Nordamerika relevant sind. So wurde schnell klar, dass bei dem Aufbau eines Ecosystems sehr viel Aufwand in dieser Phase investiert werden muss. Aktivitäten Kontext / Analyse ¥ ¥ ¥ ¥

Kundeninterviews Vor Ort Begehungen Begleitung durch Domänenexperten Fokusgruppen Tabelle 2: Aktivitäten der Kontext / Analysephase

Eines der zentralen strategischen Ziele beim Aufbau des Ecosystems war die Integration von innovativen Lösungen. Hierzu haben wurde explizit eine Phase der Innovationsfindung in den Prozess eingebunden. Durch die wiederholte Durchführung von Kreativitätsworkshops sollten insbesondere Ideen aus verschiedenen Bereichen generiert werden. Ziel dabei war es den nutzerzentrierten Prozess durch Innovationen aus allen Bereichen anzureichern. Positive Erfahrungen wurden damit gemacht, technische Innovationen, wie beispielsweise die Nutzung von Optimierungsalgorithmen vorzubereiten und in das Ecosystem zu integrieren. Zusätzlich wurden verschiedenste Lösungen unter der Nutzung von Smart Devices (iBeacons, Smart Watches, Glasses) integriert. Hierdurch können die „klassischen“ Apps im Ecosystem in der Nutzung durch intelligente Funktionen erweitert werden. Im Prozess hat

Agrarwirtschaft meets Mobile UX

209

sich gezeigt, dass die kontinuierliche Einbindung von Sessions mit dem Ziel der Innovationsfindung das Mobile Ecosystem als Ganzes profitieren lässt. Aktivitäten Innovationsfindung ¥ ¥ ¥ ¥ ¥

Kreativitätsworkshops Aufgreifen von Ideen aus dem Unternehmen Ideation Workshops mit Lead Usern Technische Innovationsfindung Smart Device Exploration Tabelle 3: Aktivitäten der Innovationsfindung

Ein zentraler Punkt der Anforderungsdefinition bildete das App Scoping, bei dem entschieden werden muss, wie die Services bzw. die Apps geschnitten werden, um einen optimalen Mehrwert für den Nutzer zu bieten, gleichzeitig aber auch ins Ecosystem Gesamtkonzept zu passen. Im Rahmen der Definition von Anforderungen ist es im Ecosystem notwendig besondere Mechanismen zur Schaffung von Konsistenz der User Experience einzuführen. Hierzu wurde eine ganzheitliche Produktphilosophie (Hess et al. 2015) definiert, die hauptsächlich als Kommunikationsmedium diente. Hierbei wurde das Ziel verfolgt, eine konsistente User Experience über die verschiedenen Touchpoints zu schaffen. Dies ist besonders herausfordernd, da ein Touchpoint mit Maschine (z.B. Traktor) und mobile App existiert. Bei der eigentlichen App Entwicklung ist ein klassisches Vorgehen wie die Definition von Anforderungen in Form von User Stories sinnvoll. Speziell ist für das Ecosystem, dass zwischen variablen und statischen Anforderungen unterschieden wird: variable Anforderungen sind für einzelne Apps zu beachten, wohingegen statische Anforderungen für das ganze Ecosystem gleich sind. Aktivitäten Anforderungsdefinition ¥ ¥ ¥ ¥ ¥ ¥

Definition von User Stories und Epics Variable vs. Statische Nutzeranforderungen „Best Guessing“ Anforderungen Produktphilosophie App Scoping Datenanforderungen Tabelle 4: Aktivitäten Anforderungsdefinition

Zur Ausgestaltung der Anforderungen in der Konzeption und Design Phase wurden zunächst Personas für Lohnunternehmer und Landwirte erstellt. Diese wurden dann schrittweise erweitert, um auf die Gegebenheiten in der Domäne einzugehen. Zur App Konzeption wurden in frühen Iterationen klassische Papierprototypen und später auch voll ausgearbeitete Visual Designs erarbeitet. Welche Artefakte hier im Einzelfall erstellt wurden war auch stark von den involvierten Entwicklern abhängig. Als besonders positiv hat sich

210

Steffen Hess, Felix Kiefer, Karl-J. Wack, Dominik Magin

das Einbinden von UI-affinen Entwicklern in die Designphase herausgestellt. Diese wurden vor die Aufgabe gestellt, ein bereits ausgearbeitetes Design durch den Einsatz von technischen Feinheiten besser und attraktiver zu machen. Daraus etablierte sich eine vielversprechende Zusammenarbeit, welche nachhaltig für eine hohe Akzeptanz auf beiden Seiten gesorgt hat und gleichzeitig die Qualität der Apps erhöhte. Die endgültige Entscheidung, für welche Geräte eine App entwickelt wird bzw. welche Funktionalitäten auf welchem Gerät umgesetzt werden, wurde nach der Designphase getroffen. Auf Basis des Designs wurde auch entschieden, ob Funktionalitäten auf dem Backend bzw. Frontend umgesetzt werden. Die Klärung der Frage, über Verfügbarkeit und Qualität von Daten aus Sicht der Benutzer erfolgte parallel zur eigentlichen Konzeption. Diese Informationen haben schlussendlich das Design der App maßgeblich beeinflusst. Aktivitäten Konzeption und Design ¥ ¥ ¥ ¥

Personas Papierprototypen Entwicklerinput Datendesign und Visual Design Tabelle 5: Aktivitäten Konzeption und Design

Die Evaluation von Apps in der Agrarwirtschaft ist eine Herausforderung, da Aktivitäten stets mit zeitlichen, nicht immer wiederkehrenden Ereignissen verbunden sind. Die Ernte als geschäftskritische Phase steht zudem unter extremem Druck, so dass viele Unternehmen in einem zwei- bis dreischichtbetrieb Arbeiten müssen. Dies macht den Zugang zu Nutzern für Endnutzerevaluationen unter realen Bedingungen schwierig. Gute Erfahrungen wurden mit langfristigen Feldtests gemacht, so dass Informationen über die App Nutzung automatisiert erhoben werden konnten. In Phasen, bei denen der Arbeitsdruck des Kunden geringer war, konnte umfassendes Feedback eingeholt und Konzeptvalidierungen durchgeführt werden. Aktivitäten Evaluation ¥ ¥ ¥

Feldtests Lead User Validierung Konzeptvalidierung Tabelle 6: Aktivitäten Evaluation

In einem solchen Setting wurde gewinnbringend der Lead User Ansatz (von Hippel 1986) eingesetzt, d.h. zum einen haben Domänenexperten, die nicht mehr hauptberuflich als Lohnunternehmer oder Landwirt tätig sind, kontinuierlich die Entwicklung begleitet, zum anderen haben sich Endnutzer zur Verfügung gestellt, die Apps auch in den geschäftskritischen Phasen zu benutzen und damit Evaluationen durchzuführen. Als abschließende Phase jeder Iteration steht beim vorgeschlagenen Ansatz die Prüfung auf Wiederverwendung und Konsistenz. Diese beinhaltet die kontinuierliche Erweiterung von

Agrarwirtschaft meets Mobile UX

211

UX Guidelines, Design Elementen und Icon-Bibliotheken. Zusätzlich muss kontinuierlich geprüft werden, welche existierenden Apps aktualisiert werden müssen, um eine möglichst hohe Konsistenz zu erhalten. Hierbei hat sich gezeigt, dass eine Verfolgbarkeit von Artefakten bzw. Widgets auf Design Ebene bis hin zu Source Code die Arbeit wesentlich erleichtert. Aktivitäten Wiederverwendung und Konsistenz ¥ ¥ ¥

UX Guidelines und Aufbau von Icon-Bibliotheken Iteration von Design Artefakten Erstellung von Widgets zur Wiederverwendung von Design Elementen in Verbindung mit Source Code Tabelle 7: Aktivitäten Widerverwendung und Konsistenz

Best Practices UX für den Aufbau eines Mobile Ecosystems in der Agrarwirtschaft Im Rahmen dieser Kooperation haben sich über die Zeit Best Practices etabliert, die über die Grenzen der Anwendungsdomäne hinaus von Relevanz und Praktikabilität sind. Diese können insbesondere helfen wenn man im Begriff ist, ein Mobile Ecosystem aufzubauen. Die folgende Auflistung zeigt die eingesetzten Best Practices. Template-Basierte App Konzeption: Die Verwendung von Templates für User Interface Elemente sichert die Schaffung von Konsistenz über verschiedene Apps und Plattformen hinweg. Darüber hinaus wird die Erstellung von Konzepten für neue Apps immer effizienter. Benutzung der Produktphilosophie als Kommunikationstool: Die Produktphilosophie dient in erster Linie als Leitfaden zur Kommunikation zwischen User Experience Professional, Management und Entwicklung. Enge Verbindung von technischen Enablern und UX in der Konzeption: Die Integration von technischen Enablern durch Einbeziehung von erfahrenen Mobile Entwicklern in die Konzeption und Designphase lieferte einen besonderen Mehrwert sowie eine Steigerung der gegenseitigen Wertschätzung von Entwicklung und Design. Wartung und Integration von UX Assets im Prozess: Die zu Beginn aufwändigere Arbeit der Erstellung widerverwendbarer UX Assets trägt langfristig zu einer Steigerung der Effektivität bei. Konzepte von neuen Apps können auf Grundlage von existierenden Templates erstellt werden. Sinnhafte Integration von Smart Devices: Smart Devices, wie beispielsweise Smart Watches bieten dem gesamten Umfeld einen großen Mehrwert, da Nutzer einfache Use Cases ohne Interaktion mit dem Smartphone ausführen können. Die Verwendung von iBeacons ermöglicht auch eine Integration von älteren Maschinen.

212

Steffen Hess, Felix Kiefer, Karl-J. Wack, Dominik Magin

User Experience meets Data: In den Ecosystems der Zukunft spielen gerade auch in Zusammenhang mit Big Data, Daten eine immer größere Rolle. Als Best Practice empfiehlt es sich, diese Daten in den User Experience Gestaltungsprozess einzubinden und frühzeitig herauszufinden, wo Daten für den Endnutzer einen Mehrwert bringen. Dies kann z.B. die Aggregation von mehreren Quellen für Wetterprognosen sein (Naab et al. 2015). Es gibt keine One-Size Fits All Lösung für Datensynchronisation: Die Synchronisation von Daten ist im Mobile Ecosystem ein sehr sensibles Thema, das maßgeblich die User Experience beeinflusst. Datenbedarfe genau zu analysieren ist von großer Wichtigkeit, um das Verfahren der Datensynchronisation auf die User Experience Bedarfe auszurichten.

Zusammenfassung & Ausblick Die Agrarwirtschaft befindet sich derzeit im Wandel und durchläuft eine spannende und hoch innovative Phase - gerade in der Produktentwicklung. Der vorgestellte Beitrag repräsentiert einen Praxisbericht mit den im Rahmen des Gesamtprojektes gesammelten Erfahrungen. Die Erkenntnisse liefern insbesondere interessante Aspekte bei der Vorgehensweise im Rahmen der UX. Ein besonderer Fokus ist ebenfalls auf die daraus resultierenden einzelnen Phasen zu legen. Diese verdeutlichen die Evolution einer mobilen Einzellösung hin zu einem Mobile Ecosystem. Die Entwicklung eines Mobile Ecosystems für die Agrarwirtschaft stellt einige besondere Herausforderungen an User Experience Professionals dar, welche aufgrund der bisherigen Erfahrungen durchaus auch auf andere Domänen übertragbar sind. Zur Verdeutlichung des Vorgehens wurde der HCDME Prozess erstellt und die Erfahrungen der Anwendung von UX Praktiken in der Agrarwirtschaft erläutert. Literatur DIN EN ISO 9241-110 (2006). Ergonomics of human-system interaction – Part 110: Dialogue principles. Beuth, Berlin. Doerr, J., Trapp, M., Hess, S. (2014). Mobile Prozesse: eine Chance für die Wirtschaft. Computerwoche. http://www.computerwoche.de/a/mobile-prozesse-eine-chance-fier-diewirtschaft,2555126. Hess, S., Braun, S., Feldhaus, S., Hack, M., Kiefer, F., Magin, D., Naab, M., Richter, D., Lenhart, T. & Trapp, M. (2015). Building Mobile Software Ecosystems – A Practical Approach. In: Proceedings of HCII 2015. Naab, M., Braun, S., Lenhart, T., Hess, S., Eitel, A., Magin, D., Carbon, R. & Kiefer, F. (2015). Why Data needs more Attention in Architecture Design – Experiences from prototyping a large-scale mobile app ecosystem. WICSA 2015. Von Hippel, E. (1986). Lead Users: A Source of Novel Product Concepts, Management Science 32 (7): 791–806.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 213- 223.

Hard- und Software Schnittstelle für den Sipos Seven PROFITRON Stellantrieb Integration von Usability Engineering Methoden in der klassischen Maschinenbauentwicklung Holger Schlemper, Hans-Georg Hopf, Katrin Proschek, Ulrich Raithel, Peter Müller, Michael Molle

Holger Schlemper

Prof. Dr. Hans-Georg Hopf

Katrin Proschek

Ulrich Raithel

Peter Müller

Michael Molle

Technische Hochschule Nürnberg Keßlerplatz 12 90489 Nürnberg [email protected] Technische Hochschule Nürnberg Keßlerplatz 12 90489 Nürnberg [email protected] Sipos Aktorik GmbH Im Erlet 2 90518 Altdorf [email protected]

Technische Hochschule Nürnberg Keßlerplatz 12 90489 Nürnberg [email protected] Sipos Aktorik GmbH Im Erlet 2 90518 Altdorf [email protected] Sipos Aktorik GmbH Im Erlet 2 90518 Altdorf [email protected]

Abstract Die Bedienschnittstelle des neuen Stellantriebs Sipos Seven PROFITRON ist eine durchgreifende Neuentwicklung. Durch die Integration von Usability Engineering Methoden in die klassischen Entwicklungsprozesse der Maschinenbau-Industrie konnte diese Entwicklung mitgestaltet und zu einer deutlichen Verbesserung der Usability beigetragen werden. Beim Sipos Seven PROFITRON wurden Hardware- und Softwareschnittstelle gleichzeitig entwickelt um zu einer guten Integration für die Gerätebedienung zu kommen. Das Gerät unterliegt im Außeneinsatz extremen Umweltbedingungen und muss auch mit schwerer Schutzkleidung (Handschuhen) bedient werden können. Dabei war eine große Herausforderung, die aus der tiefen Kenntnis des Vorproduktes resultierenden mentalen Modelle der Domainexperten zu diskutieren um neue Lösungen zu ermöglichen. Dieser Beitrag soll einen Überblick über den Projektverlauf und die eingesetzten Methoden im Prozess geben.

214

H. Schlemper, H.-G. Hopf, K. Proschek, U. Raithel, P. Müller, M. Molle

Keywords Usage Centered Design, Embedded Systems, Interface- und Interaktions-Design

Einleitung Für die Neuentwicklung den Sipos Seven PROFITRON wurde sowohl die Hardware als auch die Software-Schnittstelle komplett benutzergerecht neuentwickelt. Ziel war es, eine deutlich verbesserte Schnittstelle zu gestalten, welche bestenfalls auch ohne die Zuhilfenahme einer Gebrauchsanleitung verständlich und bedienbar ist. Der neue Sipos Seven PROFITRON sollte eine Bedienung über nur noch einen Dreh-Drück-Knopf, den sogenannten Drive Controller, ein Farbdisplay sowie die Dioden-Anzeige des Betriebszustandes aufweisen und damit die eher schwer verständliche Benutzerführung des Vorgängermodells ablösen.

Die Aufgabenstellung Stellantriebe steuern oder regeln Mediendurchflüsse in großen Anlagen. Geräte aus dieser Gruppe können ferngesteuert werden, besitzen aber auch eine Vor-Ort-Steuerung, mit deren Hilfe wichtige Aufgaben am Gerät ausgeführt werden müssen, welche nicht von der Leittechnik erledigt werden können.

Ausgangslage Das Vorprodukt Sipos 5 PROFITRON stellt für diese Vor-Ort-Steuerung eine menügeführte 2-zeilige-LCD-Anzeige plus Leuchtdioden zur Zustandsanzeige zur Verfügung. Bedient wird über eine Vier-Druckknopf-Bedienung mit kontextabhängig wechselnder Funktionalität.

Abbildung 1: Vorprodukt Sipos 5 PROFITRON – Vor-Ort-Bedienschnittstelle

Hard- und Software Schnittstelle für den Sipos Seven PROFITRON Stellantrieb

215

Randbedingungen Die Bedienung Vor-Ort unterliegt zum Teil extremen Bedingungen; die Geräte sind oft außen installiert. Hohe oder niedrige Temperaturen, Sonneneinstrahlung auf die Displays und ähnliche Randbedingungen müssen berücksichtigt werden. Die Bedienung muss also auch mit dicken Schutzhandschuhen möglich sein.

Methodenauswahl Schon im Vorfeld war klar, dass bei der Entwicklung von Software, welche mit komplett neuer Hardware kombiniert wird, auch die Bedienkonzepte von Software und Hardware zusammen erdacht werden müssen. Die Wahl fiel auf den Usage Centered Design Ansatz (Constantine & Lockwood, 2006). Die Methode ist insbesondere gut geeignet, um mit Software-Entwicklern auf Grundlage ihrer eigenen Modelle und Artefakte Usability Engineering Prozesse zu initiieren. Durch die Modellierung wird eine Neubetrachtung des oft stark funktional geprägten Mind Setups im Hinblick auf die eigentlichen Motivationen der Benutzer ermöglicht. Es werden festgefahrene Denkstrukturen aufgebrochen und ein gemeinsames Verständnis erzeugt (Beyer & Holtzblatt, 1998, 270ff). Durch die abstrahierte und implementierungsfreie Formulierung der „Essential Use Cases“ werden sie in dieser neuen Form den Scenarios ähnlich. Die Integration von Modellen aus dem klassischen Software Engineering baut eine Brücke (Chlebek, 2011, 163ff) zwischen verschiedenen Disziplinen und war insofern für das hier beschriebene Projekt ideal geeignet. Alan Cooper äußert sich kritisch gegenüber der Verwendung von Use Cases im Usability Engineering im Vergleich zu personabasierten Scenarios. Er bescheinigt ihnen nur eine geringe Aussagekraft darüber, wie Aufgaben dem Benutzer präsentiert und wie sie priorisiert werden sollen (Cooper et al., 2007, 113ff.). Demgegenüber greift der Usage Centered Design Ansatz eben diese Use Cases auf (Constantine & Lockwood, 2006) und abstrahiert sie von „konventionellen“ zu „essenziellen“, also aus Benutzersicht formulierten, Use Cases. Von der ursprünglichen Struktur der Darstellung von User Actions und System Response verändert sich der Blickwinkel im Usage Centered Ansatz, ganz im Sinne von Scenarios, zu einer Darstellung von User Intentions, also der impliziten Benutzungs-Motivation, und System Responsibilities, also den Elementen, deren Bereitstellung in der Systemverantwortung liegen, da sie der Benutzer zur Aufgabenbewältigung braucht. Diesen „Essential Use Cases“ können im weiteren Verlauf Tools und Materials zugeordnet werden (Constantine & Lockwood, 2006), also Interaktionsmöglichkeiten (in abstrakter Form) und Datenobjekte, mit denen umzugehen ist. Durch eine Weiterverarbeitung zu einem abstrakten Prototypen und einem Navigation- oder Interaction-Space wird ein stabiles Modell erstellt, auf dem die visuelle Gestaltung aufsetzen kann.

216

H. Schlemper, H.-G. Hopf, K. Proschek, U. Raithel, P. Müller, M. Molle

Benutzerbeteiligung Oft stellt es eine nicht zu unterschätzende Schwierigkeit dar, während der Entwicklung eines Produktes häufiger auf Benutzer und deren Feedback zugreifen zu können. Häufig trifft man gerade in der Maschinenbau-Branche auch auf Vorbehalte, Benutzern in frühen Entwicklungsphasen in die Prozesse einzubinden. Die Angst basiert auf der Vorstellung, dass Kunden von unfertigen Produkten abgeschreckt werden könnten. Möglich war allerdings eine Befragung der Benutzer über Fragebögen. In der ersten Phase der Entwicklung wurden die Benutzer des eigentlichen Systems mit Hilfe von Vorerfahrungen aus BenutzerFeedbacks seitens der fachlichen Beteiligung von Service-Mitarbeitern und durch das Referenzieren von Personas zunächst substituiert. Im weiteren Verlauf konnte mit reiferen Interaktionsprototypen Usability-Tests mit Benutzern durchgeführt werden.

Abbildung 2: Sipos Seven PROFITRON mit Bedienschnittstelle

Vorgehen Von der Sipos Aktorik zur Verfügung gestellte Dokumentation des Vorproduktes, bestehend aus technischen Mindmaps und Bedienungsanleitungen, wurden sorgfältig analysiert und in Anforderungen für die Neuentwicklung überführt. Im weiteren wurden die klassischen Phasen des benutzerzentrierten Entwicklungsprozesses durchlaufen.

Hard- und Software Schnittstelle für den Sipos Seven PROFITRON Stellantrieb

217

Abbildung 3: Ursprüngliches Mindmap zur funktionalen Beschreibung des Sipos Seven (Ausschnitt)

Analyse des bestehenden Systems Der Fokus der Mindmap-Beschreibung lag auf einer detaillierten Abbildung des Funktionsflusses bei gleichzeitiger Darstellung sämtlicher technischer Zustände. Auf dieser Basis wurde die Übertragbarkeit der bisherigen funktionellen Auflösung des Workflows generell diskutiert. Die eigentlichen Benutzungsaufgaben konnten daraus jedoch nicht abgeleitet werden. Nur durch ein klares Verständnis des funktionalen Aufbaus des Antriebes und – was noch wichtiger ist – der damit verbundenen Benutzungsaufgaben, kann die Gestaltung und Konzeptionierung von Interface und Interaktionselementen zielgerichtet betrieben werden. Auf dieser Basis wurde die Übertragbarkeit der bisherigen funktionellen Auflösung des Workflows generell diskutiert.

Workshop zur Rollen und Aufgabenanalyse Daher wurde als erster Schritt ein Workshop zur Identifikation von User Roles und Use Cases auf Basis des Usage Centered Design Konzepts durchgeführt; Teilnehmer waren Ingenieure der R&D Abteilung, Hardware Spezialisten und Softwareentwickler, Vertriebsspezialisten, Spezialisten aus dem technischen Service, Experten aus der technischen Dokumentation und zwei Usability Engineering Experten aus dem Usability Engineering Center der Technischen Hochschule Nürnberg. Rollen-Modellierung Durch die Definition von Benutzungsrollen im Usage Centered Design Prozess, im Gegensatz zur klassischen Sicht der organisatorischen Rolle, welche nur Stellung, Berufsbezeichnung oder Ähnliches referenziert, lassen sich sehr differenzierte Aussagen über die mit den jeweiligen Rollen verbundenen Use Cases und deren Wichtigkeit im späteren Interface treffen. Solche Benutzungsrollen beziehen sich in der Regel auf ein bestimmtes Verhalten in der Software. Verschiedene Teilaufgaben oder Use Cases können dementsprechend einer oder mehreren Rollen zugeordnet werden.

218

H. Schlemper, H.-G. Hopf, K. Proschek, U. Raithel, P. Müller, M. Molle

Task-Modellierung Auf Basis der bereits beschriebenen Usage Centered Design Methode wurden neben der Möglichkeit zur Parametrierung drei wesentliche Navigationskontexte identifiziert. Zum einen der Homescreen, welcher generell über den aktuellen Betriebszustand informiert, die Vor-Ort-Bedienung, welche die Steuerung des Antriebes vor dem Gerät ermöglicht und die Einstellungen, welche es dem Benutzer möglich machen, die Endlageneinstellung vorzunehmen und den Antrieb in einen gültigen Betriebszustand zu versetzen. Dan Saffer beschreibt konzeptionelle Modelle als Möglichkeit, relevante Daten zu identifizieren und in einem neuen Lichte zu betrachten (Saffer, 2010, 103ff). In diesem Sinne erlaubte die Aufgaben-Modellierung als Best Practice einen neuen Zugang und ein Neudenken von Interaktion mit dem geplanten System (Anderson et al. 2010, 110ff)

Abbildung 4: Abstract Prototype, Ausschnitt

Nach dem Workshop wurde sofort eine Vorvisualisierung eines möglichen finalen Interfacedesigns von Home- und Informationsscreen angefertigt. Dies war notwendig, um das UEC als Partner gegen einen Konkurrenzanbieter zu etablieren, das zukünftige Produkt für Messen zu visualisieren und die Sipos Marketing-Abteilung von der Notwendigkeit eines Visual Displays zu überzeugen.

Projektverlauf Der aus der modellbasierten Aufgabenanalyse hervorgegangene Abstract Prototype ermöglichte es dem Entwicklungsteam, viele herkömmliche und funktionsgetriebene Umsetzungsansätze zu hinterfragen und zur Diskussion zu stellen. Hilfreich hierbei war die Zusammensetzung des Teams selbst, da durch die unterschiedlichsten Domainexperten aus der technischen Dokumentation, dem Kundenservice, Usability und Design und entwicklungsbeteiligten Ingenieuren eine echte multidisziplinäre Zusammenarbeit ermöglicht wurde. Ein Großteil der Anforderungsanalyse im Projektverlauf bestand in einem interdisziplinären Wissenstransfer bei regelmäßigen Fokusgruppen und Review-Sitzungen.

Hard- und Software Schnittstelle für den Sipos Seven PROFITRON Stellantrieb

219

So wurden wichtige Themen wie etwa zwingend nötige Handlungsabläufe oder hardwareabhängige Handhabungen schnell geklärt und Information effizient an alle weitergegeben. Neben der Neuentwicklung der Software wurden auch diverse Hardware-Komponenten von Grund auf neu entwickelt. Während die technische Entwicklung des Drive Controllers in der Verantwortung der Ingenieure von Sipos lag, wurde Neugestaltung der Gehäuseabdeckung um die Bedienschnittstelle an das UEC beauftragt. Das parallel erfolgte Produktdesign der Geräteabdeckung durch das UEC berücksichtigte neben ergonomischen Gesichtspunkten wie einen maximierten Einblickswinkel auf den Anzeige-Screen oder gute Erreichbarkeit des Drive Controllers auch sicherheitsrelevante Randbedingungen wie etwa den Kollisionsschutz mit dem Drive Controller und eine analoge Sperrung des Antriebes.

Abbildung 5: Links: Entwurf mit Abdeckung, rechts: Der neue Gehäusedeckel des Sipos Seven

Grundlage für das Gelingen des Projektes war, dass die Beteiligten aus allen Fachgebieten von der Sinnhaftigkeit der Usability Engineering Methoden überzeugt waren. Dies betraf insbesondere die Einbindung der unterschiedlichen Abteilungen in der Anforderungsphase, sowie die Notwendigkeit zu wiederholten Reviews.

Prototyping Aus dem Abstract Prototype und den umstrukturierten Mindmaps wurde ein Interaktionskonzept abgeleitet und mit Wireframes und interaktiven Mockups zur Interaktionsplanung umgesetzt. Der Ablauf der Aufgabenerledigung ist extrem wichtig, um zu einer gültigen Einstellung des Antriebes zu kommen. Um aus der abstrakten und aus Sicht des Benutzers formulierten Form hin zu ersten prototypischen Entwürfen und damit zu einer Auflösung der Abstraktion in funktionelle Interaktions-Elemente zu kommen, wurden erste Scribbles und Wireframes erstellt und diskutiert. In regelmäßigen Experten-Reviews, meist in Form von Cognitive Walkthroughs der einzelnen Gestaltungs-Iterationen konnten so drei Hauptbedienungs-Strukturen prototypisch umgesetzt, verfeinert und als TeilImplementierung auf dem eigentlichen Antrieb getestet werden. Die Interfaces für die drei Schlüsselbereiche, Homescreen, Vor-Ort-Bedienung und Einstellungen, wurden in High

220

H. Schlemper, H.-G. Hopf, K. Proschek, U. Raithel, P. Müller, M. Molle

Fidelity Prototypes umgesetzt, Domainexperten abzufragen.

um

möglichst

störungsarmes

Feedback

von

den

Abbildung 6: Verschiedene Stadien der Prototypen-Entwicklung

Interaktionskonzeption Ein wichtiger Bestandteil des Interaktionskonzeptes war eine geführte Unterstützung im Bereich Inbetriebsetzung. Diese stellt sicher, dass bestimmte Einstellungen gemacht wurden, um den korrekten Einstellungsvorgang erfolgreich abzuschließen. Auch die Kombination aus Softwarehandhabung und Interaktion mit den Hardware-Komponenten des Antriebs wurde konzeptionell berücksichtigt. Die Herausforderung war es, einen einzelnen Bedienknopf mit Dreh- und Drückfunktionalität als übergreifendes Bedienprinzip zu etablieren und das Interaktionsprinzip irritationsfrei auf das Gesamtsystem nach dem Konzept der direkten Manipulation (Shneiderman, 2009), umzubrechen. Parallel wurden Teilbereiche der Software implementiert und die aus der Umsetzung resultierenden technischen Anforderungen in das Design übernommen. Es wurden regelmäßige, iterative Reviews mit den Domainexperten durchgeführt. Herausforderung war dabei, dass nicht alle Experten zu jedem Review Meeting verfügbar waren, was Entscheidungsprozesse verzögert hat. Die Erfahrung ist, dass gerade signifikante Änderungen zum Vorgängersystem mehrfach diskutiert werden mussten, um Akzeptanz bei den Experten zu finden. Es ist ein großer Verdienst der Sipos-Ingenieure, dass sie sich an diesem Prozess beteiligten und einem externen Usability Partner mit einem ganz anderen Produktentwicklungsansatz Vertrauen schenkten. Sobald die drei Schlüsselbereiche implementiert waren, wurde ein Usability Test mit 16 Probanden (Kunden) auf dem Originalgerät durchgeführt. Auf Grundlage der Testergebnisse wurden sowohl Softwareoberfläche und Interaktionskonzepte verfeinert als auch Änderungen am Drive Controller vorgenommen.

Usability Test Der Benutzungstest wurde auf dem Endgerät unter Zuhilfenahme eines mobilen Eye Tracking Systems (Tobii Glasses) durchgeführt. Ein großer Vorteil des Usability Tests war, dass durch die exemplarische Implementierung sowohl Software als auch Hardwareprobleme identifiziert werden konnten. Die neue Bedienschnittstelle Drive Controller wurde von allen

Hard- und Software Schnittstelle für den Sipos Seven PROFITRON Stellantrieb

221

Probanden verstanden und konnte sofort bedient werden. Die anfängliche Schwergängigkeit des prototypischen Controllers konnte im weiteren Entwicklungsverlauf gelöst werden. Außerdem wurde eine „Rasterung“ der Drehzustände vorgenommen um unbeabsichtigte Weiterschaltung beim Drücken zu vermeiden, welche beim Test gelegentlich aufgefallen war.

Abbildung 7: Versuchsaufbau des Gerätes für den Usability Test mit Markern für das Tobii Glasses Eye Tracking System

Ein weiteres technisches Finding war die Feststellung, dass der verbaute Anzeige-Screen bei einer Betrachtung von oben eine Art Farbumschlag aufwies und dadurch manche Interface Elemente kontrastärmer erschienen. Diesem Problem sowie einigen anderen Findings zur Icon-Verständlichkeit und Menüführung konnte mit einer weiteren, kleinen Iteration des Designs begegnet werden.

Abbildung 8: Eines der gravierenderen Findings des Tests war die schwer verständliche Darstellung der Motor-Sperre

222

H. Schlemper, H.-G. Hopf, K. Proschek, U. Raithel, P. Müller, M. Molle

Abbildung 9: Motorsperre – Aktuelle Lösung, links: Vor-Ort-Verfahren, rechts: Motor gesperrt

Die Testergebnisse wurden ausgewertet und Änderungsbedarf als Verbesserungsvorschläge prototypisch umgesetzt. Nach weiteren, begleitenden Tests wurden sie in die Software integriert. Diese Design Reviews wurden für alle Module bis zur Produktreife fortgeführt.

Benefit der Methode Usage Centered Design Auf Grundlage des erstellten Aufgabenmodells konnte in direkter Folge das Interface für ein weiteres Produkt von Sipos Aktorik, den Sipos Seven ECOTRON, umgesetzt werden. Hier konnte auf sämtliche Vorprodukte aus diesem Projekt und das entstandene Wissen zurückgegriffen werden. Obwohl die technische Umsetzung beim „kleineren Bruder“ des Stellantriebes sich auf ein Segmentdisplay zur Anzeige sämtlicher Betriebszustände beschränken sollte und der funktionale Umfang bei der Vor-Ort-Bedienung deutlich reduziert war, erwies sich die Strukturierung der Aufgaben auch in diesem Fall als gültig und das Modell als durchgehend stabil.

Ergebnis Ergebnis der Entwicklung ist eine komplett neu strukturierte Mensch-Maschine-Schnittstelle für ein marktreifes Produkt. Ein fundamentales Verständnis der technischen Abläufe des zu erstellenden Produktes und deren Auflösung in Aufgaben des Benutzers, erwies sich als unerlässlich um adäquate Gestaltungslösungen zu konzipieren. Ein multidisziplinärer Prozess funktioniert nur über die Bereitschaft der beteiligten Personen. Das Team ist die wichtigste Komponente im Erstellungsprozess, die Kommunikation muss funktionieren. Ein Schlüsselfaktor war, dass der leitende Softwareentwickler die Usability Engineering Prozesse voll unterstützt hat. Das Projekt ist abgeschlossen und die Markteinführung des Produkts ist für Sommer 2015 geplant.

Hard- und Software Schnittstelle für den Sipos Seven PROFITRON Stellantrieb Literatur Anderson, J.(2010). Effective UI. Sebastopol: O’ Reilly. Benyon, D.(2010). Designing Interactive Systems, 2.Auflage. Harlow: Pearson Education Limited. Beyer,H. & Holtzblatt,K. (1998). Contextual Design. San Francisco: Morgan Kaufmann Chlebek, P. (2011). Praxis der User Interfaceentwicklung. Wiesbaden: Vieweg + Teubner Verlag. Constantine, L. L. & Lockwood, L. A. D.(2006). Software for Use. 7. Auflage. New York: Addison Wesley. Cooper, A.(2007). About Face 3. Indianapolis: Wiley Publishing, Inc. Herczeg, M. (2005). Softwareergonomie, 2.Auflage. München: Oldenbourg Wissenschaftsverlag GmbH. Khazaeli, C. D. (2005). Systemisches Design. Reinbek bei Hamburg: Rowohlt Verlag GmbH. Saffer, D. (2010). Designing for Interaction, 2. Auflage. Berkeley: New Riders. Sarodnik, F. & Brau, H. (2011). Methoden der Usability Evaluation, 2.Auflage. Bern: Verlag Hans Huber. Shneiderman, B. & Plaisant, C. (2009). Designing the User Interface. Boston: Addison Wesley. Unger, R. & Chandler, C. (2009). A Projekt Guide to UX Design. Berkeley: New Riders.

223

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 224- 231.

Erfolgreich Apps für die Industrie entwickeln Mit User Experience fit für die Industrie 4.0 Franz Koller, Claus Oetter

Franz Koller

User Interface Design GmbH Wilhelm-Bleyle-Straße 10–12 71636 Ludwigsburg [email protected]

Prof. Claus Oetter

Fachverband Software, VDMA Lyoner Straße 18 60528 Frankfurt a. M. [email protected]

Abstract Der Trend der zunehmenden Technologisierung und Vernetzung hat im Consumer-Bereich begonnen und hält durch die Entwicklungen rund um Industrie 4.0 schnellen Einzug in das industrielle Umfeld. Vor allem Apps setzen starke Impulse und hohe Erwartungen. Doch wie können diese Erwartungen speziell im industriellen Umfeld erfüllt werden? Bei welchen Einsatzszenarien in der Industrie und Industrie 4.0 spielen die Smart Devices ihre Stärken am besten aus? Welche besonderen Gestaltungskriterien gilt es zu beachten? Der Beitrag zeigt, wie Smart Devices und Apps und damit auch Consumer-Trends ihren Weg in die Industrie finden und wie sich im industriellen Kontext gezielt eine positive User Experience gestalten lässt.

Keywords Industrie 4.0, Apps, Smart Devices, Touch, Mobile, User Experience

Smart Devices durchdringen mehr und mehr unser Leben und unseren Arbeitsalltag. Gerade in der industriellen Praxis bieten sie Herstellern viele Potentiale. Mit Smart Devices und Apps können Hersteller ihr Portfolio erweitern und für ihre Kunden wichtige Mehrwerte und Alleinstellungsmerkmale schaffen. Zudem können Prozesse und Abläufe besser unterstützt sowie die Produktivität, Flexibilität und somit der Erfolg des Produkts gesteigert werden. Folgende Vorteile bieten Smart Devices: ¥ Industry 4.0: Apps erlauben die ortsunabhängige Bedienung und Überwachung von Maschinen. Nutzer können mehrere Produktionseinheiten gleichzeitig überwachen. Zudem entstehen neue Anwendungsgebiete und damit auch Geschäftsmodelle.

Erfolgreich Apps für die Industrie entwickeln

225

¥ Zusatzfunktionen: Apps ermöglichen die Kommunikation über unterschiedliche Kanäle – egal ob Telefon, SMS, Video oder E-Mail – und bieten Zusatzfunktionen wie Kamera Lage- oder Beschleunigungssensorik. ¥ Emotion und Image: Apps verleihen Unternehmen ein innovatives Image. ¥ Kürze Produktionszyklen: Apps haben einen überschaubaren Funktionsumfang. Daher können sie einfacher gemanagt und in kürzeren Entwicklungszyklen erweitert und optimiert werden. ¥ Distribution: Apps können einfach aktualisiert werden. ¥ Entwicklung: Die Entwicklung von Apps unterscheidet sich nicht von der Entwicklung von anderen Software-Produkten. Allerdings sind Entwickler mit geeigneten Qualifikationen einfacher zu finden.

Besonderheiten des industriellen Umfelds Im Zuge der Diskussion von „Industrie 4.0“ und dem damit verbundenen Paradigmenwechsel zu einem kooperierenden Netzwerk, in der Werkstücke, Werkzeuge oder Werkstückträger über eine eigene „eingebettete Intelligenz“ verfügen, verändert sich die bisherige Automatisierungstechnik. Werden bislang Aufträge geplant und überwacht, können zukünftig dynamische und selbstorganisierende Wertschöpfungsnetzwerke einen Auftrag automatisch einplanen und bearbeiten. Die Rolle des Nutzers und des Maschinenbedieners verändert sich und in Teilen werden die Nutzer von den eigentlichen Fertigungsprozessen stärker entkoppelt. Trotzdem oder gerade deshalb muss es für die Nutzer möglich sein, sich jederzeit einen Überblick zu verschaffen. Hier bieten sich typischerweise mobile Geräte an, die sich nahtlos in die Kommunikationsstrukturen integrieren und mit ihrer Sensorik kontextbezogen Informationen zu Werkstücken, Werkzeugen und aktuellen Kennzahlen darstellen können. Die Entwicklungen Richtung Industrie 4.0 laufen im industriellen Umfeld eher evolutionär und auch in aktuellen Systemen werden schrittweise Teilaspekte für Industrie 4.0 eingeführt. So werden beispielsweise auf Bedienpanels QR Codes angezeigt, die die bisherige Maschinenbedienung so erweitern, dass Nutzer in einem ersten Schritt Informationen auf diese Art auf ihren mobilen Geräten aufnehmen können, die sie beispielsweise an einer entfernten Stelle einer Anlage benötigen. Ein wesentliches Merkmal im industriellen Umfeld sind die sehr langen Entwicklungs- und Produktlebenszyklen. Das bedeutet, dass Produkte zehn Jahre und länger im produktiven Einsatz sind. Eine Herausforderung ist es die Wertigkeit solch langlebiger, typischerweise hochpreisiger Systeme über die Bedienqualität zu unterstützen. Hier können mobile Systeme einen zusätzlichen Mehrwert erzeugen und bestehende Systeme und Anlagen um zusätzliche Funktionalitäten erweitern. Auf diese Art können Systeme gezielt weiter entwickelt werden, ohne das eigentliche Maschinen-Interface signifikant zu verändern.

226

Franz Koller, Claus Oetter

Die Anforderungen an Informationssicherheit (Security) und Funktionale Sicherheit (Safety) in der Industrie sind sehr hoch. Priorität in der Automatisierung hat dabei die Aufrechterhaltung der Kontrolle über Produktion und Prozess und nur authentifizierte Benutzer dürfen die Bedienungen im Rahmen ihrer Berechtigungen durchführen. Funktionale Sicherheit ist eine Anforderung im europäischen Maschinenbau, die über die Maschinenrichtlinie vorgegeben und in Safety-Normen beschrieben wird. Besonderes Augenmerk gilt dabei Verfügbarkeit, Fehlerrobustheit und Reaktionszeit. Bei Apps ist deshalb auch die Verteilung und Aktualisierung von Apps ein wichtiger und kritischer Punkt: Ein sicherheitsrelevantes Update muss unverzüglich durchgeführt werden und darf beispielsweise nicht durch Zulassungsverfahren in App-Stores verzögert werden. Um den Anforderungen aus dem industriellen Kontext gerecht zu werden, ist es deshalb unumgänglich zunächst eine entsprechende Strategie für mobile Anwendungen zu entwickeln. Bei der Gestaltung von mobilen Anwendungen für den industriellen Kontext ist die Bediensicherheit das wesentliche Kriterium. Ergänzend kommen bereits bekannte und etablierte Gestaltungsprinzipien zum Einsatz die sich im Consumer-Umfeld bewährt haben.

Die richtige Strategie Der Erfolg einer App steht und fällt mit einer entsprechenden App-Strategie. Dabei sollten Hersteller die Unternehmensziele, das bestehende Portfolio, die Marketing- und Produktstrategie ebenso berücksichtigen wie die Nutzer mit Ihren Erwartungen und Zielen [Abb. 1]. Nur dann ist sichergestellt, dass sich die Apps in bestehende Strategien, Produkte und Prozesse nahtlos integrieren. Die wichtigste Herausforderung ist es, die richtigen Nutzungsszenarien zu definieren: Bei welchen Aufgaben und Zielen spielen Smart Devices und Apps ihre Stärken am besten aus? Welche Interessengruppen profitieren am meisten durch den Einsatz von Apps? Der größte Vorteil von Smart Devices ist deren Mobilität. Dadurch können Informationen an jedem beliebigen Ort angezeigt werden. Das spart Wege und ermöglicht die Interaktion mit der Maschine oder Anlage an Stellen, an denen es bisher nicht möglich war. Es gibt aber auch Aufgaben, bei denen Kommunikations- oder Zusatzfunktionen wie Kamera, Mikrofon, Gyro- oder Lage-Sensoren eine wesentliche Rolle spielen. Die Mobilität stellt dabei keinen Selbstzweck dar, sondern unterstützt beim Optimieren von Unternehmensprozessen: Kann das Produktportfolio ausgebaut werden? Können Bearbeitungszeiten beispielsweise bei der Wartung verkürzt werden? Erhöht sich die Qualität der Aufgabenbearbeitung dadurch, dass Entscheidungen direkt getroffen werden? Können bisher nur händisch durchführbare Aufgaben digitalisiert werden? Etc.

Erfolgreich Apps für die Industrie entwickeln

227

Abbildung 1: Faktoren bei der Festlegung einer App-Strategie

Sind die Ziele und Strategien für die App-Entwicklung definiert, können daraus konkrete Einsatzszenarien abgeleitet werden. Im Folgenden finden Sie eine Auswahl, in welchen Bereichen industrielle Apps typischerweise erfolgreich genutzt werden können: ¥ Vertrieb: Informationen zum Anbieter oder Zugriff auf Produkt- oder Technikkataloge, Unterstützung bei technischer Auslegung und Konfiguration ¥ Betriebsleittechnik: Betriebsdatenerfassung, Anforderung von Betriebsmittel und Auftragsüberwachung ¥ Service und Wartung: Meldung von Fehlern und Alarmen, Unterstützung der Diagnose sowie der Inbetriebnahme von Komponenten, Kommunikation mit entfernten Experten z.B. als Wartungs- und Serviceunterstützung ¥ Produktionsumfeld: Steuerung nachfolgender Aufträge

von

Maschinen

oder

Anlagen,

Vorbereitung

228

Franz Koller, Claus Oetter

Abbildung 2: Beispielhafte Visualisierung unterschiedlicher Nutzungskontexte

Dabei sollte auch geklärt werden, welche Szenarien sich eher mit etablierter Software abbilden lassen. Eine App sollte möglichst nur für einen kleinen Funktionsumfang konzipiert und umfangreiche Funktionen auf mehrere Apps verteilt sein.

Erst wenn die Ziele und Anwendungsszenarien definiert sind, wendet man sich technischen Fragen zu wie die Zielplattform, zur Verfügung stehende Ressourcen und vorhandenes Know-how.

Hohe Erwartungen an die Gestaltung Eine intuitive und attraktive Gestaltung kennen Nutzer aus der Consumer-Welt – und erwarten diese auch im Arbeitsumfeld. Damit setzen Erfahrungen mit Tablets und Smart Devices aus dem privaten Umfeld den Benchmark für User Interfaces, die im Arbeitskontext genutzt werden. Die User Interfaces müssen durch eine hohe Gebrauchstauglichkeit (Usability) Nutzer optimal in der Arbeit unterstützen. Doch das allein reicht nicht mehr aus: Ein positives Nutzungserleben (User Experience) entscheidet über den Erfolg von Technologien und Produkten. Daher müssen Hersteller nicht nur funktionale und pragmatische, sondern auch emotionale Aspekte bei der HMI-Gestaltung industrieller Produkte und insbesondere bei der Gestaltung von Anwendungen auf Smart Devices berücksichtigen.

Interaktion und Gestaltungsprinzipien Mobile ist nicht Desktop oder Bedienpanel Interaktion und Design von Desktop-Anwendungen lässt sich nicht einfach auf mobile Anwendungen übertragen. Denn Nutzer interagieren mit Smart Devices anders als mit einer

Erfolgreich Apps für die Industrie entwickeln

229

Desktop-Applikation. Das hängt zum einen mit dem Kontext der Nutzung zusammen, aber natürlich auch mit den unterschiedlichen Funktionen des Endgeräts. Dennoch ist es wichtig, dass mobile Apps und stationäre Anwendungen konsistent gestaltet sind und ihnen ein einheitliches Interaktions- und Designkonzept zugrunde liegt.

Mobile Gestaltungsprinzipien Im Folgenden stellen wir die wichtigsten mobilen Gestaltungskriterien vor. Keep it short and simple Aufgrund der geringen Bildschirmgröße gilt das Credo „Weniger ist mehr“. Ziel ist es, die Komplexität für den Nutzer zu reduzieren und so seine Arbeit zu vereinfachen. ¥ Fokussierung auf die wesentlichen Anwendungsfälle, Informationen und Funktionen ¥ Inhalte kategorisieren, priorisieren und in eine flache Informationsarchitektur mit wenigen Navigationsoptionen gliedern ¥ Erweiterte Einstellungen in zweiter Menüebene verbergen ¥ Auslagern komplexer Inhalte und Funktionen auf andere Ausgabegeräte ¥

„Keep it brief“: Inhalte sollen schnell erfassbar sein (kurze Sätze und einfache Worte)

¥ „Pictures are faster than words“: Bilder und Grafiken beschreiben Sachverhalte besser als Text ¥ „Only show what I need when I need it“: Nur Informationen und Funktionen anzeigen, die aktuell benötigt werden ¥ „Never loose my stuff“: Einstellungen speichern, um Mehrfacheingaben zu vermeiden ¥ „If it looks the same, it should act the same“: Konsistente Position und Funktion der Elemente innerhalb der Anwendung Gestalte Inhalte „Content before chrome“ – bei der Gestaltungen sollten die Inhalte im Vordergrund stehen und nicht die Interaktionselemente. Gestalte für Touch Um Nutzern ein intuitives Nutzungserlebnis zu bieten, sollten Hersteller natürliche Interaktionen nachahmen. Sie orientieren sich an der realen Welt und den dort herrschenden physikalischen Gegebenheiten (z. B. beim Verschieben von Objekten, Blättern von Seiten, Anstoßen von Listen). Durch Gesten kommen erfahrenen Nutzer schneller ans Ziel. Wichtig ist es, Standard-Gesten zu verwenden, die aus anderen Anwendungen bereits bekannt und erlernt sind.

230

Franz Koller, Claus Oetter

Eine Herausforderung bei der Gestaltung für Touch ist die Wahl der richtigen Größe für Schrift und Schaltflächen. Je nach Hersteller variieren die Angaben zu Mindest-TouchGrößen von Bedienelementen. Generell gelten für den Consumer-Bereich geringere Größenempfehlungen als für die Industrie und Medizintechnik. Der Grund: Bedienfehler im Arbeitsumfeld oder Gesundheitsbereich können schwerwiegende Konsequenzen haben. Daher muss die Bedienung von Produkten in diesen Branchen eine höhere Bediensicherheit gewährleisten. Biete angemessenes Feedback Durch visuelles und auditives Feedback sollten Apps ihre Nutzer über aktuelle Vorgänge informieren: Wo hat er den Bildschirm berührt und für wie lange? Welche Prozesse laufen und was ist deren Ergebnis? Wo befindet sich der Nutzer und wie ist er dahin gekommen? Welche Aktionen können als nächstes gestartet werden? Die Meldungen und Hinweise sollten klar und verständlich sein. Dabei können Transitions und Animationen visuell unterstützen. Mach die Nutzung zum Erlebnis Bedürfnis Zielerreichung Produkte mit einer guten User Experience befriedigen menschliche Grundbedürfnisse: ¥ Sie erzeugen Verbundenheit, beispielsweise in dem sie ein gemeinsames Arbeiten und Erleben fördern. ¥ Sie wecken die Neugier und stimulieren, indem sie Herausforderung bieten. ¥ Sie begeistern durch neuartige Interaktionsformen. ¥ Sie ermöglichen ein autonomes – zeit- und ortsungebundenes – Arbeiten. ¥ Sie unterstützen das eigene Kompetenzerleben, indem sie entsprechende Hilfe zur Analyse und Behebung von Störungen/Fehlern bieten. User Experience wirkt sich positiv auf das Produkt und das Markenimage aus. Nutzer identifizieren sich mit der Anwendung, sind effizienter und motivierter.

Fazit Apps im industriellen Umfeld haben das Potenzial, Wegbegleiter von Industrie 4.0 zu werden und damit unseren Arbeitsalltag zu verändern. Usability und User Experience sind dabei wesentliche Erfolgsfaktoren, die die Wahrnehmung und Bedienung der App maßgeblich beeinflussen. Für ein optimales Bedienerlebnis gilt es, Anwendungsziele klar zu fokussieren, Bedürfnisse der Zielgruppe und deren Nutzungskontexte zu kennen und zu berücksichtigen, mobile Gestaltungsprinzipien umzusetzen und – soweit möglich – optimale Bedienbarkeit mit Spaß zu verbinden.

Erfolgreich Apps für die Industrie entwickeln

231

Literatur VDMA (2014). App-Entwicklung in der Industrie. Grundlagen und Entscheidungshilfen. Frankfurt a. M.: VDMA Verlag.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 232- 240.

DATEV Design-DNA – Entwicklung einer produktübergreifenden Designsprache Ulf Schubert, Claude Toussaint, Kristina Helmreich

Ulf Schubert

DATEV eG Fürther Straße 111 90329 Nürnberg [email protected]

Claude Toussaint

designaffairs Balanstraße 73 | Haus 32 81541 München [email protected]

Kristina Helmreich

DATEV eG Fürther Straße 111 90329 Nürnberg [email protected]

Abstract Die DATEV ist sich des Nutzens einer starken Marke bewusst. Sie entwickelt daher ihren Markenauftritt stringent und kontinuierlich weiter. Eine wesentliche Herausforderung dabei ist es, die Markenwerte an den zahlreichen Kontaktpunkten der Genossenschaft konsistent zu kommunizieren. Um dies zu gewährleisten, wurde in den letzten Jahren zusammen mit designaffairs eine Design-DNA konzipiert und eingeführt, welche die Klammer über alle Kontaktpunkte bilden soll. Wir beschreiben in diesem Beitrag, wie die Design-DNA konzipiert wurde, geben Einblicke in die Grundideen und erläutern die Herausforderungen bei der Einführung einer durchgängigen Designsprache in großen Unternehmen.

Keywords Designstrategie, Designmanagement, Markenführung, Corporate Branding, Designsprache

DATEV Design-DNA – Entwicklung einer produktübergreifenden Designsprache

233

Einleitung Die DATEV ist das Softwarehaus und der IT-Dienstleister für Steuerberater, Wirtschaftsprüfer und Rechtsanwälte sowie deren Mandanten. Als Genossenschaft besteht das wichtigste Ziel der DATEV in der wirtschaftlichen Förderung ihrer Mitglieder. DATEV unterstützt ihre Mitglieder bei deren beruflicher Tätigkeit durch Softwareprodukte und andere Dienstleistungen. (DATEV 2011) Das Streben nach höchster Qualität ist bei DATEV daher wichtiger als das Streben nach finanziellem Erfolg. Dies spiegelt sich auch im Markenauftritt der DATEV wider. Sie steht für Sicherheit (Datenschutz, Datensicherheit, Zukunftssicherheit), Erfolg (nachhaltige Förderung der Mitglieder, Leistung zum fairen Preis, bedarfsgerechte Software), Nähe (sowohl geografisch als auch im partnerschaftlichen Umgang) und Aktualität (aktuelle Software und Wegbereiter) (DATEV 2015).

Ausgangssituation Ihren hohen Anspruch bzw. ihr Versprechen kommuniziert DATEV über einen stringent geführten Markenauftritt. Die DATEV zeichnet sich seit Jahren durch eine sehr fortschrittliche Markenführung aus. Spürbar und erlebbar wird dies an den zahlreichen Kommunikations-Kontaktpunkten von digitalen Medien über Druckerzeugnisse bis zu Veranstaltungen. In den letzten Jahren wurde die Markenführung immer weiter auch in den Bereich der Produktgestaltung ausgedehnt. Hier besteht die Herausforderung darin, die Markenwerte bzw. das Markenversprechen auch über die mehr als 200 Produkte der DATEV, die seit der Gründung der DATEV im Jahr 1966 entstanden sind und ständig weiterentwickelt wurden, zu kommunizieren. Zum einen kommunizieren DATEV-Produkte die Markenwerte natürlich über ihre fachlichen und technischen aber auch über ihre gestalterischen Qualitäten und Eigenschaften. Der rasante technologische Fortschritt stellt die DATEV dabei vor große Herausforderungen. Wie kann es bei der Vielzahl der technischen Plattformen, Geräte und Ökosysteme in der digitalen Welt gelingen eine Designsprache zu entwickeln, die produktübergreifend eingesetzt werden kann und welche die Markenwerte an allen Punkten, an denen ein Anwender mit einem Produkt oder Anwendung in Kontakt kommt, konsistent kommuniziert? Wie kann es gelingen, mit einer Designsprache zwar eine konsistente Gestaltung über die mehr als 200 Produkte der DATEV zu erreichen, aber noch genügend Freiraum für die fachlichen, technischen bzw. zielgruppenspezifischen Anforderungen zu lassen? Wie kann es bei einem über 1.800 Mitarbeiter starken Entwicklungsteam gelingen, diese Designsprache zu etablieren?

Ganzheitlicher Blick auf UX Design Bei der Betrachtung der Herausforderungen wurde schnell klar, dass es nicht genügt, einfach ein paar gestalterische Vorgaben zu machen und diese in einem Styleguide zu dokumentieren. Um diesen Herausforderungen begegnen zu können, war eine ganzheitliche

234

Ulf Schubert, Claude Toussaint, Kristina Helmreich

und strategische Betrachtungsweise notwendig. Daher stand vor der Entwicklung der DATEV Design-DNA die Entwicklung einer Designstrategie. Mit dem Begriff „DATEV Design-DNA“ bezeichnen wir den Kern unserer Designsprache. Die DATEV Design-DNA umfasst alle wesentlichen Merkmale, die zur Kommunikation der Markenbotschaft und zur Gestaltung einer positiven User Experience eingesetzt werden. Grundgedanke einer Designstrategie ist, dass die Produktgestaltung einen wesentlichen Beitrag zur Erreichung der Geschäftsziele eines Unternehmens liefern muss. Es ist eine Abkehr von dem in der Softwareentwicklung historisch weitverbreiteten Verständnis, dass die Produktgestaltung dazu dient, die Produkte durch einen modernen „Anstrich“ dem Kunden „schmackhafter“ zu machen. Eine Designstrategie beschreibt viel mehr, mit welchen gestalterischen Mitteln und Methoden die Erreichung bestimmter Unternehmensziele am besten unterstützt werden kann. Gestalterische Mittel können z.B. eine Designsprache oder Designprinzipien sein. Gestalterische Methoden sind beispielsweise Methoden der anwenderorientierten Gestaltung (Human Centered Design). Eine Designstrategie basiert immer auf den Geschäfts- und Produktstrategien eines Unternehmens und steckt den gestalterischen Rahmen für die mittel- bis langfristige Weiterentwicklung der Produkte ab. Da sich eine Designstrategie immer auch an den Bedürfnissen des Marktes sowie der Kunden orientieren muss und sich im Wesentlichen damit beschäftigt, wie die Lösungen für die Kunden- und Marktanforderungen aussehen sollen, bildet sie eine gute Grundlage für den Innovationsprozess. Ein weiteres Ziel einer Designstrategie ist es, einen positiven Beitrag zur Erzeugung einer klaren und vorteilhaften Corporate Identity zu leisten. Dazu muss sie in Einklang mit dem Kommunikationsdesign, dem Environment-Design und der Unternehmenskultur gebracht werden. (Sommerlatte, 2009)

Abbildung 1: Zusammenspiel der Designdisziplinen nach Sommerlatte

DATEV Design-DNA – Entwicklung einer produktübergreifenden Designsprache

235

Mit Kommunikationsdesign ist die Gestaltung aller Kommunikationsinhalte eines Unternehmens gemeint. Dazu gehören neben der Marke auch die Kommunikationsmittel im Bereich des Marketings. Unter Environment-Design wird die Gestaltung der physischen Umgebung eines Unternehmens verstanden. Dazu gehört beispielsweise die Gestaltung der Arbeitsumgebung und der Gebäude eines Unternehmens. Nur ein Unternehmen, welches in allen vier Bereichen – Produktgestaltung, Kommunikationsdesign, Environment-Design und Unternehmenskultur – die gleichen Inhalte und Aussagen kommuniziert, kann die Vorteile einer ganzheitlichen Corporate Identity nutzen, wie z.B. Kundenbindung und Absatzförderung. Im Vorfeld der Entwicklung der Designsprache wurde daher eine umfangreiche Analyse der Produktgestaltung, der Designorganisation und der gestaltungsrelevanten Trends aus Gesellschaft und Technik vorgenommen. Aus dieser Analyse wurden Handlungsfelder und Rahmenbedingungen für die DATEV Designstrategie abgeleitet. Es wurde bereits zu diesem frühen Zeitpunkt definiert, welche Themen bearbeitet, welche Voraussetzungen geschaffen und welche Veränderungen in der Organisation herbeigeführt werden müssen, um eine Designsprache erfolgreich einführen zu können.

1.800 Entwickler, 200 Produkte, 1 Designsprache Definition der grundlegenden Designrichtung Der erste Schritt bei der Entwicklung der DATEV Design-DNA war die Identifikation der Markenwerte, die am Kontaktpunkt „Produkt“ kommuniziert werden sollen. Kernfragen der durch designaffairs durchgeführten Markenanalyse waren daher: Was sind die primären Markenwerte? Wie können diese Werte visuell auf die Designsprache übertragen werden?

designaffairs analysierte mithilfe des neurosemantisches Analyse-Tools SimuPro® die DATEV Markenwerte. SimuPro® macht sichtbar, ob die gestalterischen Grundkonzepte zur Zielgruppe, Marke oder den Unternehmenswerten passen. Dazu werden die Markenwerte über semantische Differenziale auf allgemeingültige psychologische Werte übertragen. Das Ergebnis wird grafisch in dem SimuPro®-Profil dargestellt.

236

Ulf Schubert, Claude Toussaint, Kristina Helmreich

Abbildung 2: Neurosemantisches Tool „SimuPro®“ zur Markenanalyse

designaffairs beobachtet seit vielen Jahren Designstile, beschreibt diese und bewertet diese mit Hilfe des SimuPro®. Im Laufe der letzten 10 Jahre wurde mit über 3.000 Probanden die Wirkung der relevantesten Designstile gemessen und eine große Datenbasis für Vergleiche geschaffen. Hierdurch war es möglich, auf Basis der identifizierten Markenwerte zuverlässig zu ermitteln, welcher grundlegende Designstil am besten für die Kommunikation der Markenwerte der DATEV geeignet ist. Der identifizierte Designstil beschreibt grob, über welche grundlegenden gestalterischen Merkmale die Produktgestaltung definiert werden soll. Kulturelle Übersetzung Ein abstrakter Designstil ist jedoch nicht genug, um als Leitlinie für die Gestaltung von zahlreichen Produkten durch eine große Entwicklungsorganisation zu dienen. Er ist zu generisch, reflektiert die Marke zu wenig und lässt zu viel Raum für Interpretation. Außerdem ist es sehr unwahrscheinlich, dass ein generischer Designstil – auch wenn er mit einem zuverlässigen Verfahren ermittelt wurde – von einer großen Entwicklungsorganisation als neue Designsprache einfach so akzeptiert und umgesetzt wird. Grundidee des weiteren Vorgehens war daher, dass die neue Designsprache auf einer gemeinsam getragenen UX-Vision basieren sollte. Die UX-Vision sollte zur Definition der Ausrichtung und des Entscheidungsspielraums für die Produktgestaltung dienen. Sie soll dabei aber nicht nur regulierend, sondern auch inspirierend sein und als Messlatte für Designentscheidungen dienen. (Schubert, 2015) Damit eine UX-Vision ihre Wirkung entfalten kann, muss sie so entstehen, dass sie von Anfang an von allen wichtigen Beteiligten getragen und von diesen im Unternehmen vertreten wird. Eine UX-Vision funktioniert dann gut, wenn sie von vielen Personen im Unternehmen verinnerlicht wird. Dazu muss sie nicht

DATEV Design-DNA – Entwicklung einer produktübergreifenden Designsprache

237

nur sehr einfach sein, sondern auch von vielen mit Überzeugung wiederholt kommuniziert werden. Sie muss entsprechend fokussiert und einprägsam sein. Daher wurde der Designstil mit Vertretern des mittleren Managements im Rahmen eines UX-Vision Workshops in UX-Prinzipien übersetzt. Es wurden bewusst Vertreter des mittleren Managements gewählt, da diese sowohl nah genug an der konkreten Umsetzung der Produkte beteiligt sind als auch über die notwendigen Entscheidungsfreiräume verfügen. Im UX-Vision Workshop wurden über die Bewertung und Gruppierung von Fotos erst Adjektive und dann Slogans abgeleitet. Die Fotos wurden dafür so ausgewählt, dass sie Gegenstände aus unterschiedlichen Bereichen zeigten, die dem identifizierten Designstil entsprachen. Die Slogans wurden danach durch die Erstellung von fiktiven Produktverpackungen priorisiert. Die Slogans, die am höchsten priorisiert wurden, wurden im Anschluss in UX Prinzipien überführt. Weitere Details zum Workshop sind im UX-Blog beschrieben. (Schubert, 2015) Gestalterische Übersetzung Im nächsten Schritt übersetzte designaffairs die UX-Prinzipien auf Basis von realistischen fachlichen sowie technischen Szenarien in Gestaltungsentwürfe. Auf diese Weise konnte ermittelt werden, wie sich die UX-Prinzipien mit visuellen und interaktiven Gestaltungsmitteln wirksam übersetzen lassen. In einem iterativen Verfahren wurden durch ein gemeinsames Designteam von designaffairs und DATEV die Entwürfe so lange überarbeitet, bis sie in Form eines Design-Leuchtturms für die Ableitung der konkreten Gestaltungsmerkmale sowie für die interne Kommunikation verwendet werden konnten.

Abbildung 3: Konzeptionsphase der DATEV Design-DNA

Unter einem Design-Leuchtturm verstehen wir einen gestalterischen Prototypen, der visualisiert, wie sich ein Produkt mit einer bestimmten Designsprache anfühlt. Wie eine Art Concept Car aus der Automobilindustrie dient er als Basis für Richtungsentscheidungen bzgl. der Produktgestaltung sowie zur internen und externen Kommunikation.

238

Ulf Schubert, Claude Toussaint, Kristina Helmreich

Ableitung der Gestaltungsmerkmale Während des iterativen Erstellungsprozesses des Leuchtturms wurden Gestaltungsmerkmale als tragende Schlüsselelemente herausgearbeitet. Sie haben die Aufgabe, einen starken Eigencharakter und damit die Klammer zu bilden, die die Wiedererkennung über das Produktportfolio hinweg garantiert. Die Gestaltungsmerkmale wurden am Ende der Erstellung des Design-Leuchtturms dokumentiert. Für die DATEV Design-DNA wurden folgende Gestaltungsmerkmale definiert: ¥ Typographie: Eine typographische Kombination einer Serifen-Schrift und einer serifenlosen Grotesk-Schrift. Damit dieses Gestaltungsmerkmal seine Wirkung auch entfalten kann, wenn die definierten Schriften nicht verfügbar sind, wurden die Schriften so gewählt, dass für beide Schriften ähnliche Schriften auf allen technischen Plattformen vorhanden sind. ¥ Farbe: Ein markanter Farbdreiklang aus den Corporate Colors der Marke DATEV ¥ Icons: Ein Iconsystem, welches farblich und semantisch die Markenwerte transportiert. (Kirstein et.al., 2012) ¥ Form: Eine einfache und einprägsame Form. ¥ Animation: Eine Definition, wie Animationen umgesetzt werden sollen. Im weiteren Verlauf der Etablierung der Designsprache wurden diese Gestaltungsmerkmale weiter verfeinert. Beispielsweise wurde das initial definierte Farbsystem durch die Umsetzung in diversen Entwicklungsprojekten erweitert und im Detail definiert. Wie eingangs beschrieben, müssen die visuellen und interaktiven Gestaltungsmerkmale der DATEV Design-DNA auf der Vielzahl von technischen Plattformen und technischen Ökosystemen funktionieren. Um dies zu erreichen, wurden die Gestaltungsmerkmale nach der Prämisse konzipiert: die Gestaltungsmerkmale werden nur dann eingesetzt, wenn dies mit einem wirtschaftlich vertretbaren technischen Aufwand möglich ist und sie nicht im Widerspruch zu den Grundprinzipien der eingesetzten User Interface-Technologie stehen. Sie wurden daher so konzipiert, dass sie auch ihre Wirkung entfalten, wenn ein Gestaltungsmerkmal in einem Produkt nicht umgesetzt werden kann. Eine weitere eingangs beschriebene Herausforderung war das Spannungsfeld zwischen einer einheitlichen Umsetzung der Designsprache in allen Produkten und dem Freiraum für fachliche, technische oder zielgruppenspezifische Anforderungen. Dieser Herausforderung begegnet die DATEV Design-DNA mit einer einfachen Antwort: der Reduktion auf die wesentlichen Gestaltungsmerkmale. Die DATEV Design-DNA umfasst nur die Gestaltungsmerkmale, die notwendig sind, um die Markenwerte zu kommunizieren. Sie ist bewusst einfach und reduziert, damit sie sich leicht einprägen und in der Organisation kommunizieren lässt. Sie bietet viel Freiraum für Kreativität und Innovation. Damit dieser Freiraum nachhaltig und im Sinne der Marke DATEV genutzt werden kann, wurde begleitend zur Einführung der DATEV Design-DNA eine Community of Practice (Wikipedia, 2015) für UX-Design etabliert. Die UX-Designer der Community arbeiten entweder im zentralen UX-Design-Team oder in einer produktentwickelnden Fachabteilung

DATEV Design-DNA – Entwicklung einer produktübergreifenden Designsprache

239

der DATEV. Auf diese Weise kann die Umsetzung der Designsprache in den Entwicklungsprojekten gesteuert werden. Es fließen aber auch Impulse aus den Entwicklungsprojekten für die Weiterentwicklung der Designsprache zurück.

DATEV Design-DNA Zusammenfassend kann man sagen, dass die DATEV Design-DNA aus UX-Prinzipien und Gestaltungsmerkmalen besteht, welche die Grundlage für die zielgerichtete Kommunikation der Markenbotschaften über die Produktgestaltung bilden. Diese tragen dazu bei, dem Markenversprechen der DATEV gestalterisch in den Produkten gerecht zu werden.

Abbildung 4: Umsetzung der DATEV Design-DNA in Beispielen

Durch die Herleitung über die Marke stellt die DATEV Design-DNA keinen isolierten Gestaltungsstil für Produkte dar. Sie bildet vielmehr eine Klammer über die verschiedenen Kontaktpunkte der Marke – vom Kommunikationsdesign über das Environment-Design bis hin zum Produktdesign. Literatur DATEV (2011). Satzung der Genossenschaft. Nürnberg: DATEV DATEV (2015). Zwölf Gründe, sich für DATEV zu entscheiden. http://www.datev.de/portal/ShowPage.do?pid=dpi&nid=120825 Kirstein, E., Schoenherr, N., Schubert, U. (2012). Icon Design im großen Stil - Erfahrungen zu Gestaltung und Einsatz von umfangreichen Icon Bibliotheken. In Brau, H. / et. al. (Hrsg.): „Usability Professionals 2012“, Berichtband der Usability Professionals / Mensch und Computer 2012, Konstanz, S. 60

240

Ulf Schubert, Claude Toussaint, Kristina Helmreich

Schubert, U. (2015). Workshop-Format für die Entwicklung und Einführung einer UX-Vision. http://www.user-experience-blog.de/2015/02/ux-vision-gemeinsam-entwickeln/ Sommerlatte, T. (Hrsg.) (2009). Praxis des Designmanagements. Düsseldorf: Symposion Publishing Wikipedia (2015). Community of Practice. http://de.wikipedia.org/wiki/Community_of_Practice

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 241- 251.

Die Entwicklung des Interaktionsdesigns für ein KFZAssistenzsystem von übermorgen Projektive und assoziative Methoden in der KfzVorentwicklung Olde Lorenzen-Schmidt, Christine Ullmann

Olde Lorenzen-Schmidt

mind-centric Garstedter Weg 71 22453 Hamburg [email protected]

Christine Ullmann

Zotai Pty Ltd PO Box 328 Somerville, VIC, 3912, Australia [email protected]

Abstract Wie kann man ein nutzerzentriertes Interaktionsdesign (IxD) entwickeln, obwohl es noch gar kein konkretes Produkt gibt? Die Interaktion zwischen Nutzer und Produkt soll eine spezifische Charakteristik aufweisen, um von den Nutzern angenommen und aktiv genutzt zu werden. Wenn sich die Produktentwicklung noch in einer sehr frühen Phase befindet und sich die zukünftige Interaktion als sehr neuartig darstellen wird, ist es sehr sinnvoll die zukünftigen Nutzer möglichst frühzeitig mit einzubeziehen. Besonders wenn es sich um so komplexe Produkte wie Assistenzsysteme im Automobil handelt. Denn die Gestalter der Interaktion müssen möglichst früh wissen, wie sie das Produktdesign auslegen sollen, um a) die „richtige“ IxD - Charakteristik und b) die Marken-Assoziationen genau zu treffen. Der folgende Beitrag beschreibt ein Studiendesign, bei dem Nutzer in einer sehr frühen Phase in diesen Findungsprozess einbezogen werden. Der Vorteil liegt u.a. darin, dass entscheidende Erkenntnisse vollkommen ohne Prototypen gewonnen werden können.

Keywords KFZ-Vorentwicklung, Interaktionsdesign (IxD), Assistenzsysteme, Methoden, Projektiv-Methoden

Grundlagenstudie, Assoziativ-

242

Olde Lorenzen-Schmidt, Christine Ullmann

Einleitung Wie findet man heraus, wie sich die Interaktion mit einem KFZ-Assistenzsystem für die Nutzer „anfühlen“ soll, wenn es das System in absehbarer Zeit nicht in einer präsentierbaren, physischen Form geben wird, gleichzeitig aber bereits viele Überlegungen der fachlichen Experten bezüglich der Konzepte und möglicher Umsetzungsszenarien angestellt werden? Die Entwicklung war also in vollem Gange, aber viele Richtungsentscheidungen standen noch aus. Insbesondere die, wie sich das System verhalten sollte, damit es von den Nutzern als Bereicherung, als unterstützend und einfach in den Fahrkontext integrierbar erlebt wird. Damit diese konzeptionelle Arbeit fokussierter und vor allem fundierter erfolgen kann, wurde nach Ansätzen gesucht, die eine verlässliche Grundlage für Richtungs- und Gestaltungsentscheidungen bieten können. Die Suche nach geeigneteren Ansätzen wurde auch deshalb erforderlich, weil der Einsatz klassischer Research-Methoden bislang nicht den erhofften Input liefern konnte. Immerhin sollen die gestalterischen Grundlagen für eine Vielzahl von Experten geschaffen werden. Mit diesen Herausforderungen sahen wir uns konfrontiert und legen im Folgenden unser methodisches Vorgehen sowie unsere Erfahrungen dar. Aus Gründen der Vertraulichkeit werden bei diesem Beitrag ausschließlich die methodischen Ansätze beschrieben, jedoch keine konkreten Ergebnisse oder Details zum Produkt.

Hintergrund & Aufgabenstellung Wie kann man also die Anforderungen vom Nutzer an die Interaktion mit einem zukünftigen Produkt bzw. System erheben, wenn es zum Zeitpunkt der Fragestellung noch keinen erlebbaren Prototypen gibt? Wie kann man Fragen adressieren, die sich auf Themen wie den Gesamtcharakter eines Systems beziehen, der in allen Interaktionen für den Nutzer spürbar sein soll, obwohl die einzelnen Produktdetails noch nicht klar festgelegt sind. Vor der Entwicklung von Interfaces oder Informationsarchitektur sollten Anforderungen an den Umgang zwischen Nutzer und System beleuchtet werden, um die weitere Entwicklung im Voraus in eine konkrete und angemessene Richtung leiten zu können. Der Projektrahmen für diese Studie gab daher vor, dass mit potentiellen Nutzern die Charakteristika der Interaktion mit einem sehr komplexen Assistenzsystem im Fahrzeug erhoben werden sollten. Da sich das Projekt in einer sehr frühen Phase der Produktentwicklung befand, war eine zentrale Voraussetzung, dass Nutzerstudien ohne Prototypen oder konkrete Stimuli auskommen mussten. Dabei sollten neben den Anforderungen für die Interaktion auch die Passung zwischen dem neuen Produkt und der etablierten Marke untersucht werden. Die Frage im Vordergrund war dabei, wie stark sich aus Nutzersicht das Marken-Image im Interaktionsdesign wiederspiegeln sollte. Ohne diese grundlegenden Nutzerinputs würde die Produktentwick-

Die Entwicklung des Interaktionsdesigns für ein KFZ-Assistenzsystem von übermorgen 243 lung Gefahr laufen, dass lange an sehr aufwändigen, jedoch rein hypothesengeleiteten Interaktionskonzepten gearbeitet wird, deren Nutzen und Akzeptanz erst sehr spät im Rahmen einer Umsetzung überprüft werden kann. Im Zweifel müsste dann zu einem späteren Zeitpunkt eine grundlegende Änderung des Interaktionsdesigns erfolgen, weil die Annahmen nicht korrekt wären und die Nutzerakzeptanz sich als äußerst fraglich herausstellen würde. In Hinblick auf die hohen internen Anforderungen, wie Kosten der Produktentwicklung, Time to Market, Markenimage etc., kann ein Projekterfolg, ohne dieses frühzeitige Nutzerfeedback, kaum gewährleistet werden.

Der methodische Ansatz In dem vorliegenden Beispiel ging es insbesondere darum, Input zu den „weichen“ Faktoren der Anmutung im Rahmen der Mensch-Maschine-Interaktion zu erhalten, also wie sich die Interaktion grundsätzlich für den Nutzer anfühlen soll, bzw. welche Beziehung der Nutzer zwischen sich und dem Produkt herstellen kann und wie sich diese in der Interaktion ausdrücken soll. Es ging explizit nicht um „harte“ Faktoren, z.B. wie die Gestaltung der Informationsarchitektur oder konkreten Produkt-Features, die weder als Input für die Erhebung zur Verfügung standen noch ermittelt werden sollten.

Das Studien-Design Aufgrund des Fehlens von Vorerfahrungen mit Vorgängerprodukten oder festen Vorgaben von Auftraggeberseite zur Interaktionsgestaltung, war ein qualitativer Ansatz – quasi als Grundlagenstudie – naheliegend und es wurde entsprechend deskriptiv-assoziativer Ansatz für diese Nutzerstudie gewählt. In den Fokus der Befragung haben wir folglich die Assoziationen der Probanden über ihren Umgang mit einem solchen System gestellt und dies mittels assoziativer und projektiver Ansätze tiefer beleuchtet. Die Ansätze waren in zweistündige Tiefeninterviews eingebettet, was genug Raum bot, um die gesamte assoziative Breite des Themas vertiefend zu beleuchten und nachvollziehen zu können. Die 22 Teilnehmer der Studie wurden frei rekrutiert und zwar vorwiegend nach dem Nutzungsumfang verschiedener Fahrzeugklassen in Kombination mit der Nutzung gängiger Assistenzsysteme oder New Media Devices im Fahrzeug bzw. in Kombination mit dem Fahren. Zudem wurde vorab bei der Rekrutierung evaluiert, ob die potentiellen Probanden eine gewisse Offenheit gegenüber assoziativen Methoden mitbringen und sich darauf einlassen können. Da keine Prototypen oder Ähnliches für eine Untersuchung zur Verfügung standen und das Augenmerk auf der Gesamtinteraktion und nicht auf einzelnen Produktumfängen liegen sollte, haben wir uns für eine sehr generische Beschreibung des Gesamtsystems als grundlegenden Stimulus für die Probanden entschieden. Der für die Studie entwickelte Leitfaden wird im Folgenden detaillierter vorgestellt.

244

Olde Lorenzen-Schmidt, Christine Ullmann

Ablauf der Tiefeninterviews Nach einem Warming-up mit Fragen zum Nutzungsverhalten, typischen Nutzungsszenarien und einer Themen-Überleitung in Form einer Assoziativ-Übung, war das Tiefeninterview grob in vier Abschnitte eingeteilt: ¥ Assoziativ-Methode zur Hersteller-Marke und Verortung der Hersteller-Marke anhand der `Sozialen Kreise´ (s.u.) und anhand von Attributen, die auf einem Modell für `Implizite Motive´ (s.u.) basieren. ¥ Assoziationen zu Assistenzsystemen im Fahrzeug allgemein mit Überleitung zur Konzeptbeschreibung der Produkt-Prinzipien in groben Zügen. Dabei wurde bewusst auf explizite Funktionsbeschreibungen verzichtet, sondern lediglich eine Idee davon vermittelt, wie das Produkt im Nutzungsalltag grundsätzlich funktionieren könnte und welche Serviceleistungen damit verbunden sein könnten. Wichtig war dabei, dass die Probanden ein möglichst ganzheitliches „inneres“ Bild von dem Assistenzsystem als Service entwickeln konnten. ¥ Im Hauptteil sollten die Probanden nun ihre Vorstellungen und Erwartungen in Bezug auf eine Interaktion mit dem beschriebenen System ausdrücken. Die geschah zunächst frei, danach stärker strukturiert unter erneuter Verwendung der `Sozialen Kreise´ und der Liste mit Attributen für die `Impliziten Motive´, diesmal jedoch mit Fokus auf das vorgestellte Assistenzsystem. Als weitere Methode zur Generierung eines greifbareren Gesamtbildes kam nun eine `Morphologische Analyse´ (`Morphologischen Kastens´ s.u.) zum Einsatz, um spezifische Aspekte der Interaktion genauer zu betrachten. Dabei wurden die Probanden systematisch darin unterstützt ihre impliziten Vorstellungen von der Interaktion mit diesem System stetig weiter zu entwickeln und entlang von Leitfragen zu konkretisieren. Das beinhaltete z.B. Leitfragen nach der Tonalität, dem Aktivitätsgrad und dem situativen Verhalten des Systems. Entsprechend konnten die zunächst unspezifischen Vorstellungen der Probanden nach und nach in Form expliziter Eigenschaften ausgedrückt werden. Zum Ende hin erfolgte noch eine Evaluation in Form einer Gegenüberstellung der Assoziationen in Bezug auf die Systemeigenschaften und das Interaktionsverhalten einerseits und die Assoziationen in Bezug auf die Marke andererseits, die sich sowohl aus den Verortungen in den `Sozialen Kreisen´ und den ausgewählten Attributen für die `Impliziten Motive´ ergeben haben. Nach Beendigung aller Tiefeninterviews wurde für jedes Interview ein Transkript auf Grundlage der Audio-Aufzeichnungen erstellt. Diese Transkripte bildeten die Grundlage für eine qualitative orientierte, systematische Inhaltsanalyse nach Philipp Mayring (Mayring 2007), um über die Einzelinterviews hinweg aus der jeweiligen Kommunikation Muster in Bezug auf die Interaktionsgestaltung aufzudecken. Erst dieser Analyse-Schritt in Kombination mit den Verortungen, Motiv-Attributen und den Eigenschaftsausprägungen ermöglichte eine solide Beschreibung von erwartungskonformen Interaktionspattern für das KFZ-Assistenzsystem.

Die Entwicklung des Interaktionsdesigns für ein KFZ-Assistenzsystem von übermorgen 245

Die tragenden Assoziativ- und Projektiv-Methoden Im Folgenden wird auf die drei zentralen Assoziativ- und Projektiv-Methoden dieses Studienansatzes eingegangen. Diese Methodenkombination diente dazu, über die gesamte Interviewdauer ein zunehmend abgerundetes Bild der zukünftigen Interaktion zu erhalten. Zudem ermöglichte der gewählte Ansatz einen wichtigen und zentralen Abgleich zwischen den Assoziationen zu Marke und zum zukünftigen Interaktionsdesign. Ein nicht unerheblicher Aspekt, wenn Systemeigenschaften im Kern auch ein bestimmtes Markenerleben gewährleisten sollen. Die `Sozialen Kreise´ Die `Sozialen Kreise´ sind eine projektive Methode, die auf dem Grundgedanken der `Organisationsaufstellung´ beruht und eine Weiterentwicklung der `Systemischen Aufstellung´ aus der psychotherapeutischen Arbeit darstellt. Sie dient dazu, innere Beziehungsbilder von Menschen in Bezug zu Systemen räumlich zu veranschaulichen. Eine weitere Grundlage für die `Sozialen Kreise´ bildet das `Soziale Panorama´, einem Ansatz, der von dem niederländischen Sozialpsychologen und NLP-Forscher Lucas Derks (vgl. Derks 2005) entwickelt wurde. Beide methodischen Ansätze verbindet der Gedanke „… dass die Welt der menschlichen Imagination räumlich organisiert ist.“ (Fauconnier & Turner 2002). Die Methode der `Sozialen Kreise´ (Social Proximity Methode) wurde von Olde LorenzenSchmidt für die Einzelarbeit im Rahmen von Tiefeninterviews entwickelt, um tieferliegende und meist unreflektierte Beziehungen zwischen Probanden und abstrakten oder konkreten Entitäten für Außenstehende und für die Probanden selber sichtbar und nachvollziehbar zu machen.

246

Olde Lorenzen-Schmidt, Christine Ullmann

Abbildung 1: Beispiel Markenverortung in den `Sozialen Kreisen´

Im Rahmen dieser Tiefeninterviews dienten die `Sozialen Kreise´ zur ergänzenden Ableitung von Anforderungen für das Interaktionsdesign des Assistenzsystems. Die `Sozialen Kreise´ wurden konkret eingesetzt, um a) die wahrgenommene Beziehung des Probanden zum Assistenzsystem im KFZ und b) um die Beziehung des Probanden zur Herstellermarke zu betrachten. Den Probanden wurden in unterschiedlichen Phasen des Interviews drei Ausfertigungen der `Sozialen Kreise´ vorgelegt, um 1) das Assistenzsystem, 2) die Herstellermarke und 3) eine beliebige Marke ihrer Wahl zu verorten. Nach einer Instruktion und der Verortung wurden die Probanden gebeten, einerseits die Verortung und andererseits in Abgrenzung zu den Feldern, auf denen keine Verortung stattfand zu erläutern. Daraus ließ sich im ersten Schritt ein konkretes Bild formen, wie die Probanden eine wahrgenommene soziale Nähe oder Distanz auf die Beziehung zum Assistenzsystem und zu den Marken projizieren. Im zweiten Schritt erlaubte diese Darstellungsweise eine Gegenüberstellung der wahrgenommenen sozialen Beziehung zum Assistenzsystem und zur Marke, die durchaus nicht immer deckungsgleich sein müssen. Diese Erkenntnis war wiederum sehr wichtig in Hinblick auf die Gestaltung des Interaktionsdesigns bzw. der Beziehung zwischen System und Anwender.

Die Entwicklung des Interaktionsdesigns für ein KFZ-Assistenzsystem von übermorgen 247 Die `Impliziten Motive´ Die `Impliziten Motive´ zielen auf die psychologischen Faktoren des menschlichen Handelns und der Entscheidungsfindung ab, die sehr häufig unreflektiert, also implizit von statten gehen. Entscheiden und Handeln werden sehr stark durch die menschlichen Motive bestimmt, da diese auch ohne Beteiligung unseres reflektierten Ichs darauf Einfluss nehmen, worauf wir unsere Aufmerksamkeit richten, wie wir Dinge – auch über ihren tatsächlichen Wert hinaus – bewerten und worauf wir unsere Ziele ausrichten. Trotz all der vielen Menschen weltweit ist das Motivsystem universell im Menschen angelegt und wirkt recht einheitlich gleichsam als Triebfeder für Handlungen und Entscheidungen. Dank dieser wissenschaftlich gesicherten Erkenntnis (Schwartz 2006) stellt die Untersuchung der impliziten Motive heutzutage einen sehr stabilen Ansatz in Bezug auf Produkteigenschaften dar. Die Erhebung menschlicher Motive dient dazu zu verstehen, was Menschen, die ein sich einem bestimmten Produkt zu- oder abwenden, als belohnend empfinden (Abb. 3). Dabei wirkt belohnend, was den Motiven, oder anders ausgedrückt der motivationalen Zielerreichung, dient. So können alle Produkteigenschaften belohnend oder eben nicht-belohnend wirken und damit auf Nutzerseite Wohlgefühl oder Ablehnung erzeugen. Belohnungen haben im menschlichen Gehirn eine physiologische Entsprechung und die Wahrnehmung von Belohnungen basiert dabei auf physiologischen, organischen Prozessen im menschlichen Gehirn selbst. Denn das Belohnungssystem ist Bestandteil des limbischen Systems im Gehirn, also dem Teil, der für die emotionale Einfärbung von Umweltreizen verantwortlich ist. Es ist dafür verantwortlich, ob wir etwas aufgrund unserer Wahrnehmung als angenehm empfinden, weil es unsere Motive befriedigt (Spitzer 2009) oder nicht. Ist das der Fall, werden Neurotransmitter im Gehirn ausgeschüttet und u.a. an höhere Hirnregionen, wie den präfrontalen Cortex, das Stirnhirn – Sitz der Bewertung von Sinneseindrücken und der Motivation - weitergeleitet. Im umgekehrten Fall, wenn also Reize nicht unserer motivationalen Zielerreichung entsprechen, kommt es zur Aktivierung des Schmerzzentrums, was zur Meidung eben dieses Reizes führt. All das passiert in Bruchteilen von Sekunden, vielfach und in Folge von kleinen und kleinsten Umweltreizen. Und es entzieht sich im Alltag fast ausschließlich der bewussten Reflektion. Der deutsche Neurowissenschaftler Prof. Manfred Spitzer (2006) beschreibt das so: „Die Wahrnehmung aktiviert Gedanken und Gefühle, die sich dann wiederum unmittelbar auf unser Verhalten auswirken. Völlig unbemerkt.“ In der Motiv-Forschung haben sich Dreifelder-Modelle zur Beschreibung des Motiv-Raumes sehr bewährt. Die hier genutzte Motiv-Landkarte referenziert auf den von Scheier & Held (2008) entwickelten `Belohnungsraum´. Die drei Felder beschreiben die klassischen drei Hauptcluster bei Motiv-Analysen `Stabilität´, `Anregung´ und `Autonomie´. Jedem der drei Felder sind in diesem Fall wiederum drei Dimensionen zugeordnet, die durch eine unterschiedliche Anzahl von Attributen genauer beschrieben werden. Diese Attribute bilden entsprechend die Grundlage für die Operationalisierung der Motiv-Analysen.

248

Olde Lorenzen-Schmidt, Christine Ullmann

Abbildung 2: Motiv-Landkarte

In unserem Fall sollten der Ansatz Aufklärung darüber geben, welche Motive in Bezug auf das KFZ-Assistenzsystem und welche Motive in Bezug auf die Hersteller-Marke zum Tragen kommen. Besonders interessant war auch hier, ob die Motive in Bezug auf das System und in Bezug auf die Marke voneinander abweichen und worin die Gründe dafür liegen könnten.

Abbildung 3: Welche Motive werden von dem System/ der Marke angesprochen?

Die Entwicklung des Interaktionsdesigns für ein KFZ-Assistenzsystem von übermorgen 249 Das hier gewählte Vorgehen zur Erhebung der `Impliziten Motive´ stellt entsprechend eine Operationalisierung des menschlichen Motiv- bzw. Belohnungssystems in Form von Attributzuweisungen im Rahmen eines qualitativen Forschungsansatzes dar. Wie bei quantitativen Messungen der impliziten Motive, wird bei diesem Ansatz zunächst eine Rationalisierung durch die Begrenzung der Bearbeitungszeit für den Probanden unterbunden. Konkret heißt das, dass im ersten Schritt eine Attributierung stattfand. Im zweiten Schritt erfolgte die Verdichtung dieser ausgewählten Attribute auf maximal fünf. Beide Schritte sollten vom Probanden möglichst schnell und intuitiv durchgeführt werden. Auf Grundlage der fünf übrigen Attribute erfolgte eine Tiefenexploration mit dem Probanden, um herauszufinden, warum gerade diese als besonders relevant und tragend für das System, respektive die Marke empfunden wurden. Aus den Informationen, welche Motive bei dem Assistenzsystem im Vordergrund stehen, lassen sich Ableitungen treffen, wie die Interaktion und das grundlegende Design ausgelegt werden sollte, um eine motivkonforme Wirkung zu erzielen. Der `Morphologische Kasten´ Der morphologische Kasten ist eine systematisch heuristische Kreativitätstechnik nach dem Schweizer Astrophysiker Fritz Zwicky (Zwicky 1959). Sie dient dazu, komplexe Problembereiche vollständig zu erfassen und alle möglichen Ansätze vorurteilslos zu betrachten, um anschließend anhand der gesammelten, möglichen Parameter-Ausprägungen geeignete Lösungen zu suchen. Die zwei- oder mehrdimensionale Matrix bildet das Kernstück der morphologischen Analyse. Für eine Fragestellung werden die bestimmenden Merkmale festgelegt und untereinander geschrieben. Hierbei ist darauf zu achten, dass die Merkmale unabhängig voneinander sind und dass sie im Hinblick auf die Aufgabenstellung auch umsetzbar (operationalisierbar) sind. Dann werden alle möglichen Ausprägungen des jeweiligen Merkmals rechts daneben geschrieben. So entsteht über alle Tiefeninterviews und Probanden hinweg eine Matrix, in der jede Kombination von Merkmalsausprägungen einen theoretisch möglichen Gestaltungsansatz bietet. Für dieses Studiendesign wurde dieser Ansatz etwas angepasst. Im Vorfeld wurde eine Merkmalsliste erstellt und mit den Probanden durchgegangen. Jeder Proband hat seine individuelle Ausprägung jedes Merkmals beschrieben, so dass über alle Interviews besagte Matrix von Merkmalsausprägungen entstanden ist. Dabei zeigt sich als erster Hinweis für die Gestaltung, ob bestimmte Muster aufgetreten sind, also bestimmte Aspekte der Interaktion über alle Probanden hinweg tendenziell in ähnlicher Weise ausgeprägt sind. Des Weiteren wurden Merkmalsausprägungen aus vorangegangenen Interviews mit den Probanden hinsichtlich ihrer Passung zu den eigenen Assoziationen diskutiert. Auf diesem Weg lassen sich Ähnlichkeiten im Problemraum identifizieren. Dies ist deswegen interessant, weil hier entgegen der üblichen Anwendung der Methode nicht in Gruppen sondern im Einzelinterview gearbeitet wird und weil ganz klar die gestützten Assoziationen der Probanden im Vordergrund stehen und nicht die Umsetzbarkeit.

250

Olde Lorenzen-Schmidt, Christine Ullmann

Lessons learned Zu allen zentralen Fragestellungen konnten sehr aufschlussreiche Erkenntnisse gewonnen werden. Die Ergebnisse wurden ausführlich aufbereitet und fließen nun gestaltungsleitend in die weitere Entwicklung des Produktes sowie von Prototypen für zukünftige Nutzertests ein. Der Aufwand bei diesem methodischen Vorgehen und der Analyse ist recht hoch. Er rechtfertigt sich jedoch dadurch, dass in einer frühen Phase der Produktentwicklung sehr bedeutsame Ableitungen für das Interaktionsdesign gewonnen werden können. Möglichen Fehlentwicklungen und späteren Designänderungen wird damit sehr gut vorgebeugt. Basierend auf unseren Erfahrungen sehen wir in diesem Vorgehen eine vielversprechende und interessante Ergänzung zu den gängigen Formen der Nutzerbefragung, besonders in Hinblick auf die „weichen“, emotionalen Themen, wenn solche im Vordergrund des Erkenntnisinteresses stehen. Denn bereits lange vor einer Ausgestaltung von realen Konzepten oder Prototypen können diese Ansätze sehr relevante Gestaltungshinweise aufdecken. Dies gilt umso mehr, je aufwändiger und teurer das Erstellen von Prototypen im Individualfall ist. Aus unserer Sicht hat die Tatsache, dass es vorher keinen Prototypen gab, sogar eher positiv dazu beigetragen, dass keine vertiefenden Diskussionen mit den Testpersonen über „harte“ Themen oder Features stattgefunden haben. Jedenfalls erschien es somit deutlich leichter, sich mit den Testpersonen auf ihre Vorstellungen zu den „weichen“ Eigenschaften, zu Anmutung und Design, des KFZ-Assistenzsystems zu fokussieren.

Fazit Gerade weil es kein präsentables Produkt für das anvisierte KFZ-Assistenzsystem gab, konnten mit dem gewählten methodischen Ansatz sehr grundlegende und wertvolle Ableitungen für die Gestaltung des Interaktionsdesigns und der Beziehungsebene gewonnen werden. Sowohl Ingenieure als auch Designer konnten sich gut auf die Studienergebnisse einlassen und haben den Input als deutliche Bereicherung erlebt. Daher wird sowohl über die Ausweitung der methodischen Ansätze auf andere Fragestellungen nachgedacht als auch über die deutliche Weiterentwicklung der Methoden zu einem geschlossenen „Framework“ für Entscheidungsprozesse im Interaktionsdesign. Literatur Derks, L. (2005): Social Panoramas - Changing the Unconscious Landscape with NLP and Psychotherapy. Carmarthen: Crown House Publishing. Fauconnier, G. & Turner, M. (2002). The Way We Think: Conceptual Blending and the Mind's Hidden Complexities. New York: Basic Books.

Die Entwicklung des Interaktionsdesigns für ein KFZ-Assistenzsystem von übermorgen 251 Mayring, Philipp (2007). Qualitative Inhaltsanalyse. Grundlagen und Techniken. 9. Auflage. Erste Auflage 1983. Weinheim: Deutscher Studien Verlag. Scheier, C. & Held, D. (2008). Wie Werbung wirkt. Erkenntnisse des Neuromarketing. München: Rudolf Haufe Verlag. Schwartz, S. H. (2006). Basic Human Values: Theory, measurement, and applications. Revue française de sociologie, 42, 249-288. Spitzer, M. (2006). Das neue Unbewusste. Oder die unerträgliche Automatizität des Seins. Nervenheilkunde, 8, 615-622. Schattauer GmbH. Spitzer, M. (2009). Lernen. Gehirnforschung und die Schule des Lebens. Heidelberg: Spektrum Akademischer Verlag. Zwicky, F. (1959). Morphologische Forschung. Neuauflage Fritz Zwicky-Stiftung (Hrsg.). 2. Auflage (1989). Glarus, Schweiz: Baeschlin Verlag.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 252- 260.

Reminder Objects Greifbare Interaktion im alltäglichen Leben Henrik Rieß, Peter Klein, Martin Ecker, Stefan Hintz

Henrik Rieß

Dr. Peter Klein

Martin Ecker

Stefan Hintz

User Interface Design GmbH Rankestraße 8 10789 Berlin [email protected] User Interface Design GmbH Wilhelm-Bleyle-Str. 10–12 71636 Ludwigsburg [email protected]

User Interface Design GmbH Rankestraße 8 10789 Berlin [email protected] User Interface Design GmbH Rankestraße 8 10789 Berlin [email protected]

Abstract Reminder Objects bezeichnen Alltagsgegenstände, die mit digitalen Informationen vernetzt sind, und durch ihr objekthaftes Verhalten Nutzer bei wichtigen Entscheidungen und Hilfegesuchen unterstützen. Unter Objekthaftigkeit sind in diesem Falle alle physischen Merkmale eines Produktes zu verstehen, die unsere Sinne erfassen können. Der Beitrag erklärt das Konzept der Reminder Objects, zeigt auf, wie man diese entwickelt, und stellt Projektbeispiele vor.

Keywords Internet der Dinge, Internet of Things, Reminder Objects, Interaction Design, User Experience, Tangible Interaction, Physical Computing

Sei es der Blick auf den Wetterbericht („Muss ich mich auf Schmuddelwetter einstellen?“), der Weg zum nächsten Notdienst („Wohin muss ich gehen, um jemanden zu finden, der mir weiterhilft?“) oder die Frage nach dem Kontostand am Monatsende („Kann ich mir diese Sneakers noch leisten?”): Diese Informationen sind im Internet vorhanden, doch gerade in zeitkritischen Situationen und im mobilem Kontext ist das Suchen nach ihnen stressig und unkomfortabel. Unterwegs wird aktuell vor allem über das Display (Smartphones, Laptops, Anzeigen im öffentlichen Raum) auf digitale Informationen zugegriffen. Die Informationsaufnahme läuft vorrangig über den visuellen Sinn. Zweitranging wird dann oft die Akustikebene

Reminder Objects

253

eingebunden (Durchsagen, Töne). Viele der zu betrachtenden Screens sind durch ihre physikalischen Abmessungen zu klein, um die Information mit allen Zusammenhängen detailliert darzustellen. Dazu kommen physische Einschränkungen von Nutzern wie Weitsichtigkeit, fehlende Mobilität oder psychische Faktoren wie die Angst, sensible Daten in der Öffentlichkeit aufzurufen. So fand UID im BMBF-Forschungsprojekt inDAgo in Fokusgruppen und Kontextinterviews heraus, dass Senioren Ausflüge in ihrem Wohnort vermieden. Der Grund: Sie fühlten sich von der Fülle an Fahrplaninformationen sowie Änderungen an Aushängen und in mobilen Applikationen überfordert und hatten Angst, nicht wieder zurück zu finden. Das Gefühl der Ohnmacht, mit dem falschen Ticket in die falsche Bahn einzusteigen, lässt sie dann lieber gar nicht ausgehen. Dabei würde oft schon der Hinweis reichen, auf dem richtigen Weg zu sein. Führt man diesen Gedanken weiter, so genügt anstelle des Scrollens durch Ergebnislisten oft bereits eine weniger präzise, aber eindeutige Information, um eine sichere Entscheidung treffen zu können. Ansatz der Reminder Objects ist es, Gegenstände unserer Umgebung zu identifizieren, die tägliche Handlungsabläufe unterstützen, diese mit hilfreichen Informationen zu verknüpfen und als Entscheidungshilfen und Erinnerungen in der Interaktion zwischen Objekt und Nutzer zugänglich zu machen.

Internet der alltäglichen Dinge In seinem Buch „Die Dinge des Alltags“ (1989: 11f.) spricht Donald Norman von ca. zwanzig- bis dreißigtausend Gegenständen, auf die wir im Alltag stoßen. Angefangen von der morgendlichen Tortur des Wecker, dem Bürostuhl, mit dem wir einige hunderte Male auf dem Linoleum scharren, bis hin zum Schlüssel, der uns Abends wieder die Wohnungstür öffnet. Ein besonders gutes Beispiel für rein analoge Reminder Objects ist das Wetterhäuschen, das viele vielleicht noch aus ihrer Kindheit kennen. Relativ verlässlich zeigt das kleine Haus an, wie sich das Wetter der nächsten Stunden entwickelt. Einmal erlernt, weiß jedes Kind das Häuschen zu interpretieren, ohne die Funktionsweise des dahinter steckenden Hygrometers zu kennen: Die Sonnenfrau bringt gutes Wetter, beim Regenmann dagegen sollte der Schirm für unterwegs nicht fehlen. Beide Figuren sind auf einer Drehscheibe angebracht, die von einer Feder in eine Richtung gezogen wird. Auf der Gegenseite dagegen sitzt ein Stück tierisches Material (bspw. Pferdehaar), welches sich bei Feuchtigkeit ausdehnt oder bei Trockenheit zusammenzieht. Digitale Informationen liegen oftmals in hohem Detailgrad vor und ermöglichen – richtig interpretiert – ein wesentlich weitsichtigeres Reagieren. Für die Visualisierung persönlicher Informationen und Entscheidungsvorlagen fehlt es jedoch jenseits der Smartphone-Screens

254

Henrik Rieß, Peter Klein, Martin Ecker, Stefan Hintz

noch weitestgehend an klaren Anzeigeformaten. Daher sind Wearables der nächste Schritt zu einer vernetzten, reaktionsfähigen Umgebung mit Sensoren und Aktoren. Die daraus resultierende Frage ist also: Wie sehen die „Wetterhäuschen“ aus, die den Surplus des Internets nutzen? Und wie lassen sich die Werte in physisches Objektverhalten transformieren, das sich im Kontext des Auftretens intuitiv erschließt?

I/O: Aufforderung an unsere Sinne Für die nachfolgenden Forschungsbeispiele lag der Ansatz darin, In- und Output von Technologien mit denen menschlicher Wahrnehmung abzugleichen. Ziel war es, mindestens einen Sinn vordergründig oder sogar mehrere Sinne anzusprechen und Informationsveränderungen über eine Veränderung der Objekteigenschaften sensorisch (be)greifbar zu machen. Die klassischen Sinneskanäle dabei sind Sehen (Visuell – Farbe und Helligkeit), Hören (Auditiv – Tonhöhe und Lautstärke), Riechen (Olfaktorisch – Geruch), Schmecken (Gustatorisch – Geschmack) und Fühlen (Taktil – Druck, Berührung, Vibration). Nach aktueller Betrachtung verfügt der Mensch noch weitere, stimulierbare Sinne (vgl. Physiologie des Menschen, Schmidt & Thews, 1997): Gleichgewichtssinn (Körperhaltung und Orientierung im Raum), Temperatursinn (Wärme und Kälte) sowie den vestibulären Sinn (Beschleunigung).

Abbildung 1: Die klassischen Sinneskanäle

Da jeder Mensch sowohl physiologisch als auch psychologisch über seine Sinnesebenen einen individuellen Zugang zu Kommunikation hat, ist es förderlich, wenn die Interaktion mit dem System eine breite Anzahl an Modalitäten unterstützt, so dass ein Austausch von Informationen eindeutig und situativ passend stattfindet. Die Sinneskanäle können einzeln voneinander und dramaturgisch miteinander verknüpft angesprochen werden. In den nachfolgenden Forschungsbeispielen haben wir uns weniger auf die Entscheidung des Nutzers für eine bestimmte Modalität aus mehreren fokussiert, sondern haben für einzelne Szenarios experimentell ermittelt, wie analog-digitale Interfaces über Wahrnehmungsebenen kommunizieren und in entsprechenden Situationen auf sich aufmerksam machen. Situativ eingesetzt, enthält jeder Impuls, der vom Reminder Object ausgeht, eine sensorische Affordanz. Diese zielt auf die entsprechende Modalität des Nutzers (Sehen, Hören, Fühlen…), wird kognitiv zuordnet und in (ggf. rückgekoppelte) Entscheidungen umsetzt.

Reminder Objects

255

Beispiel: Die Erkenntnis, dass meine Jacke an meiner rechten Schulter vibriert, weil sie mich zu einer Richtungsänderung bewegen möchte.

Abbildung 2: Jacke „Spirit Guide“ aus dem Forschungsprojekt inDAgo

Für bestehende Alltagsobjekte bedeutet dies, dass neben dem offensichtlichen Angebotscharakter – im Falle der Jacke das Ankleiden – ein zweiter, verborgener hinzukommt. Somit ist die Jacke nicht nur Kleidungsstück, sondern auch vertrauensvoller Wegweiser. Für Gestalter tun sich damit in Zeiten der Implementierung des Internet of Things riesige Potentiale, aber auch Risiken auf, wenn es darum geht, das Verhalten analog-digital koexistierender uns bislang vertrauter Gegenstände mitzugestalten.

Theorie: Die Triple-6-Methode Dies ist eine Abwandlung der 6-3-5 Methode, welche im Brainwriting angewandt wird, um Ideen zu finden. Bei der klassischen 6-3-5 Methode erhalten sechs Teilnehmer ein Blatt mit sechs Zeilen und drei Spalten. Jeder Teilnehmer schreibt drei Ideen auf. Anschließend wird das Blatt weitergereicht. Der nächste Teilnehmer greift die Ideen des Vorgängers auf und entwickelt sie weiter. Bei der Tripel6-Methode sind die Teilnehmeranzahl und Runden gleich wie bei der 6-3-5 Methode. Lediglich die Anzahl der Ideen ist nicht auf 3 begrenzt – stattdessen, werden den Spalten verwendbare Modalitäten zugeordnet (z. B. Sehen, Hören, Riechen, Fühlen, Beschleunigung und Temperatur spüren). Jeder Teilnehmer formuliert in der ersten Spalte je eine Idee für einen Sinneskanal. Danach werden die Blätter im Urzeigersinn zum Nächsten weitergereicht, der die Idee aufgreift und weiterentwickelt. Nach einem Durchlauf steht somit eine große Anzahl theoretischer Ansätze zur Verfügung, die später im Experiment mit Technologie prototypisch erfahrbar gemacht und ausgeschlossen oder weiterentwickelt werden können.

256

Henrik Rieß, Peter Klein, Martin Ecker, Stefan Hintz

Vorteil: Aus Gewohnheit sind digitale Gestalter oft geneigt, zunächst mit visuellen Reizen zu arbeiten, danach unterstützend mit akustischen und taktilen Signalen, die gerade im mobilen Kontext sehr überzeugen können. Insofern zwingt diese Erweiterung der Methode zu einer sehr differenzierten Betrachtung der Gestaltung einzelner Modalitäten und führt zu disruptiven Ideen. Kritik: Nicht alle Modalitäten lassen sich in jeder Situation gleich bedienen. Andere machen z.T. wenig Sinn und können schon theoretisch ausgeschlossen werden.

Praxis: Das Experiment Bei allen Projektbeispielen, die sich an unsere Sinne wenden, eignen sich Kreativmethoden wie die Triple-6-Methode für den Beginn der Ideenphase hervorragend, um erste Produktideen zu generieren. Gerade zu Beginn des Gestaltungsprozesses braucht es aber noch einen Gegenimpuls, welcher Sehen, Anfassen, Hören... direkt in Form von Technologie erlebbar macht. Hier sollte eine strukturell-experimentelle Entwicklungsphase ganz zu Beginn des klassischen User-Centered-Design-Prozesses einbezogen werden. In dieser provoziert die Konfrontation aus der emotionalen Ansprache der Nutzer und einer medienadäquaten Ausschöpfung technischer Artefakte eine neue Sicht auf Lösungswege und Nutzung bereits vorhandener Ressourcen. Gestalter sollten sich dabei lediglich von der Frage leiten lassen „Wie kann diese Technologie vielleicht unseren Use Case unterstützen?“ Eine Kinect kann beispielsweise neue Ideen für den Einsatz von Gesichtserkennung geben. Ebenso kann ein selbstgebauter Drucksensor über mehrere Punkte auf einer Fläche verteilt einen Präsenzsensor ersetzen.

Abbildung 3: Experiment

Vorteil: Überzeugende Lösungen können schnell identifiziert werden, während faule Kompromisse ebenso schnell für die weitere Gestaltung ausgeschlossen werden können.

Reminder Objects

257

Im Gegensatz zu rein ingenieursbezogenen Designprozessen mit Prototypenbau ist der Technologietransfer im strukturell-experimentellen Prozess weniger Proof of Concept, sondern mehr Möglichkeit, für Gestalter einen kreativen Kontrapunkt zu vermeintlich eindeutigen Produktanforderungen zu entwickeln.

Beispiel 1 – Spirit Guide Spirit Guide wurde im Kontext des BMBF-Forschungsprojektes inDAgo entwickelt, welches sich mit Gestaltungslösungen beschäftigt, die älteren Leuten bei ihren täglichen Problemen im öffentlichen Personennahverkehr der Städte helfen soll.

Abbildung 4: Jacke „Spirit Guide“ und Location Badget

Innerhalb des prototypischen Szenarios „Finden statt Suchen“ wurde eine handelsübliche Jacke mit dem Internet verbunden. Auf einer der Jackentaschen befindet sich eine Klettfläche, auf der „Location Badges“ angebracht werden können. „Location Badges“ sind kleine, flache Abzeichen, die einen NFC-Chip (Near Field Communication) besitzen. Jedes Badge besteht aus einem einzigartigen, gestickten Motiv und repräsentiert eine Person oder einen Ort. Die Badges können Informationen, wie die GPS-Koordinate eines Ortes, speichern. Diese Informationen können reale Orte repräsentierten (wie „Bringe mich nach Hause“) oder einen flexiblen Point-of-Interest (wie „Führe mich zur nächstgelegenen Apotheke“) beschreiben. Die Klarheit und Selbstbeschreibungsfähigkeit machen die „Location Badges“ zu einer einfachen und intuitiven Eingabemethode für Personen jeden Alters. Sobald der Location Badge auf den Klettkontakt gedrückt wird, übermittelt der Badge die enthaltenden Koordinaten via NFC drahtlos an ein konnektives Arduino-basiertes Navigationssystem, welches in die Jackeninnentasche eingenäht ist. Die Interaktion mit dem Träger der Jacke erfolgt über vibrierende Schulterpolster, die dem Nutzer mit haptischem Feedback den Weg weisen und ihn über plötzliche Routenänderungen informieren. Details wie Verspätungen und alternativen Routen lassen sich wiederum rückgekoppelt am Screen von Handy oder Smartwatch einsehen.

258

Henrik Rieß, Peter Klein, Martin Ecker, Stefan Hintz

Beispiel 2 – Rainminder Rainminder ist eine prototypische Installation für den Eingangsbereich von Wohnungen. Für das Szenario „das Haus verlassen“ entstand die Idee einer mit dem Internet verbundenen Fußmatte, die beim Betreten informiert, ob es im Laufe des Tags Regenwetter gibt und den Nutzer beim Rausgehen gegebenenfalls erinnert, einen Schirm mitzunehmen. Unabhängig vom Alter sollte die Installation gleichermaßen für Schulkinder, berufstätige Erwachsene und Senioren funktionieren, indem die Information spielerisch, aber gezielt über sensorische Affordanzen vermittelt wird. Für die sinnlich erfassbare Darstellung des Regens boten sich folgende Modalitäten an: ¥ Sehen – Visuell – Projektion einer Regensilhouette; Visualisierung auftürmender Wolken ¥ Hören – Auditiv – Regentropfen, Pfützen, Donnern ¥ Riechen – Olfaktorisch – Geruch eines Sommerregens ¥ Fühlen – Taktil – Sprühnebel winziger Regentropfen auf der Haut Für den ersten Prototyp der Fußmatte wurde sich auf die auditive Affordanz fokussiert: Bei Regenwetter klingt jeder Schritt auf der Matte wie der Sprung in eine Regenpfütze. Bei sonnigem Wetter dagegen bleibt die Matte still.

Abbildung 5: Rainminder

Der erste Prototyp basiert auf Holzplatten, die an Unterseiten mit Drucksensoren ausgestattet sind. Betritt eine Person die Platte, ändert sich der Widerstand der Sensoren und ein Signal wird an ein verbundenes Arduino Yún Board gesendet. Das Board interpretiert die Werte der Sensoren und stellt fest, dass ein Nutzer die Matte betreten hat. Daraufhin fragt es die aktuelle Wettervorhersage für den aktuellen Ort über die API von openweathermap.org ab. Meldet die Wettervorhersage Niederschlag für den aktuellen Tag, so spielt das Board über angeschlossene Lautsprecher einen randomisierten Sound ab, der an

Reminder Objects

259

den Tritt in eine Wasserpfütze erinnert. So ergibt sich für den Nutzer das Gefühl, als würde er an einem regnerischen Tag durch Wasserpfützen laufen. Aus der akustischen Affordanz heraus kann der Nutzer noch schnell zu Schirm oder Friesennerz greifen. Ein realistischer Effekt ergibt sich, wenn die Sensordaten mehrerer Platten ausgewertet werden, so dass bei jedem Schritt des Nutzers ein Sound hörbar ist. Ebenso beeinflusst die Intensität des Auftritts die Charakteristik des wiedergegebenen Sounds.

Beispiel 3 – BESTÅBOOTH BESTÅBOOTH ist eine Hommage an den klassischen Berliner Fotoautomaten (http://www.photoautomat.de/). Die alten Kabinen aus den 70er Jahren sind ein Tummelort für junge Menschen geworden, die gemeinsam ein Erlebnis teilen und in einem S/W-Abzug festhalten wollen. Für das experimentelle Projekt BESTÅBOOTH wurde das Phänomen der selbsttätig arbeitenden Box analysiert und ein prototypisches Gestaltungskonzept für das Jahr 2015 entwickelt. Der Schlüssel des Erlebnisses „Automat“ ist die Unbedarftheit des Interfaces: Es gibt keine Buttons, keine Touchscreens. Als Input des Nutzers genügt der Einwurf eines 2Euro-Stückes. Dann läuft der Countdown, bis die 4er Aufnahmereihe erfolgt. Eine halbverspiegelte Scheibe gibt den Kabineninsassen ein Gefühl für das spätere Bild, ohne jedoch zu konkret zu werden. Trotz des beengenden Raumes entfalten diese Einschränkungen eine unglaubliche Kreativität der Nutzer. Für die Gestaltung stellte sich die Frage: Ist es wirklich die Münze, die das Foto anstößt? Oder vielleicht ein Blick, ein Wort...? In der Kabine soll der Nutzer der Auslöser sein und den Moment der Aufnahme durch sein Verhalten rückgekoppelt steuern können.

Abbildung 6: BESTABOOTH Explosion

260

Henrik Rieß, Peter Klein, Martin Ecker, Stefan Hintz

Die Nutzererkennung und Fotoaufnahme erfolgt mit einer Microsoft Kinect II. Durch die Vielzahl der inkludierten Sensoren (PrimeSense-Tiefensensor, HD Farbkamera) wird eine großzügige Abdeckung des Aktionsbereiches möglich. Niederkomplexe Icons als Handlungsunterstützung leiten den Nutzer und geben visuell Führung. Zwei Lautsprecher ergänzen den Output der Kabine auf akustischer Ebene. Die Ansteuerung der Kinect erfolgt über ein MS Surface Pro Tablet, die der restlichen Komponenten über ein Arduino Micro Board. Software-seitig steuert eine ProcessingAnwendung die Logik der miteinander verketteten In- und Outputs. Im aktuellen Stadium erkennt die Box einen oder mehrere Nutzer, die sich in ihrer Nähe aufhalten. Das Erkennen des Motives setzt eine Kaskade an Locksignalen mit multimodalen Affordanzen hervor, bis das Bild erstellt und als Print ausgegeben wird. Im Einzelnen sind diese: ¥ Sehen – Visuell – LED Korona, LED Statusanzeige, Bildausgabe ¥ Hören – Auditiv – Lockrufe und Handlungsanweisungen ¥ Fühlen – Taktil – Randbegrenzung der Box spüren, Print aus Slot entnehmen Das Activity Diagram zeigt sowohl die Eigenständigkeit der einzelnen Modalitäten, als auch ihre Verknüpfung untereinander.

Abbildung 7: BESTÅBOOTH Activity Diagram

Literatur Norman, D. (1989). Die Dinge des Alltags. Frankfurt/Main: Campus-Verlag. Schmidt, R., Thews, G. & Lang, F. (Hrsg.) (2000). Physiologie des Menschen. Heidelberg: Springer.

H. Fischer, A. Endmann & M. Krökel (Hrsg.): Mensch und Computer 2015 – Usability Professionals, Berlin: De Gruyter, S. 261- 270.

Immersive Simulation eines Magneten durch die Kombination einer VR-Brille mit Force Feedback Eine Studie zur Evaluation von intuitiv bedienbaren Virtual Reality Anwendungen Ronja Scherz, Thomas Immich

Ronja Scherz

Centigrade GmbH Science Park 2 66123 Saarbrücken [email protected]

Thomas Immich

Centigrade GmbH Science Park 2 66123 Saarbrücken [email protected]

Abstract Das Thema Virtual Reality (VR) hat in den letzten Jahren immer mehr an Bedeutung gewonnen. Neu entwickelte VR-Brillen ermöglichen ihren Trägern den visuellen Zugang zu virtuellen Welten in einer bislang nicht gewohnten Qualität und Zuverlässigkeit. Zwar erlauben VR-Anwendungen häufig die Interaktion mit der dreidimensionalen Umgebung über Gesten- oder Sprachsteuerung, doch meist bricht die Illusion, sobald ein Nutzer einen virtuellen Gegenstand berührt, da die haptische Rückmeldung fehlt. Um eine möglichst natürliche Interaktion mit einer virtuellen Umgebung zu erreichen, wurde ein Prototyp entwickelt, der das visuelle Feedback einer VR-Brille mit Force Feedback verbindet. In einer Studie wurde die Wirkung dieser Kombination auf die Realitätswahrnehmung von 38 Probanden getestet. Im Rahmen der Studie konnte gezeigt werden, dass Testpersonen Schwierigkeiten haben, zwischen simulierten und realen magnetischen Kräften zu unterscheiden, wenn die VR-Anwendung sowohl Seh- als auch Tastsinn anspricht.

Keywords Virtual Reality, Force Feedback, Oculus Rift, Magnetsimulation, haptisches Feedback, 3D Interaktion

Einleitung Schon heute ist Virtual Reality längst nicht mehr nur für die Spieleentwicklung von Interesse, sondern hat auch in vielen anderen Bereichen, wie beispielsweise Medizin und

262

Ronja Scherz, Thomas Immich

Industrie, Einzug gefunden. Realitätsnahe Simulationen ermöglichen es Auszubildenden, aus den unterschiedlichsten Bereichen, Übungen an virtuellen Modellen durchzuführen, ohne dabei realen Schaden zu verursachen (Fang et al. 2013). Im psychologischen Bereich werden VR-Anwendungen bereits häufig eingesetzt, um beispielsweise Phobien mit entsprechenden virtuellen Umgebungen23, oder Schizophrenie mittels virtueller Avatare zu behandeln (DeAngelis 2012). Auch für die Industrie ist, vor allem für die Fernsteuerung und überwachung, mit Fortschritten zu rechnen, da es durch VR möglich wird, sich visuell an einen anderen Ort zu versetzen und die Geschehnisse dort zu steuern (Gravier et al. 2011). Dabei ist nicht nur der visuelle Zugang zur virtuellen Welt eine Herausforderung, sondern auch die Frage, wie Nutzer mit der dreidimensionalen Umgebung interagieren. Die Verwendung von Maus und Tastatur für die Steuerung in einer virtuellen Umgebung ist eher hinderlich als nützlich. Gerade da durch VR-Brillen der Eindruck vermittelt wird, sich unmittelbar innerhalb einer virtuellen Umgebung zu befinden, ist eine indirekte Interaktion mit den dort befindlichen Objekten nicht intuitiv oder benutzerfreundlich. Daher ist es bei vielen VR-Anwendungen bereits möglich, die eigenen Hände in der virtuellen Umgebung zu erkennen und mithilfe von Gesten die vorhandenen Gegenstände zu manipulieren (Xu 2006). Auch Sprachsteuerung wird teilweise zur Steuerung im virtuellen Raum verwendet (Muller et al. 1998). Dennoch fehlt bei der 3D-Interaktion bisher meist die haptische Komponente, die es Nutzern ermöglicht, spürbare Rückmeldungen von virtuellen Objekten zu erhalten. Zwar wird durch die virtuelle Berührung eines Gegenstandes häufig ein visuelles Feedback ausgelöst, dennoch fällt es schwer, die Illusion einer virtuellen Realität aufrecht zu erhalten, wenn der Nutzer bei seiner Berührung keinen Widerstand spürt, sondern ins Leere greift (Huang et al. 2014). Um eine vollständige Immersion, bis hin zur sogenannten „Präsenz“, zu erreichen, ist es notwendig, möglichst viele Sinne des Nutzers anzusprechen und ihm den Eindruck zu vermitteln, er befände sich tatsächlich innerhalb der virtuellen Umgebung (Lombard & Ditton 1997). Dabei ist die Möglichkeit der direkten Interaktion mit den virtuellen Objekten von entscheidender Bedeutung (Witmer & Singer 1998). Als Grundlage für die Studie sollte mittels der Entwicklung eines Prototyps, der visuelles und haptisches Feedback kombiniert, ein Weg gefunden werden, direkt mit einer virtuellen Umgebung zu interagieren. Der Prototyp sollte die Simulation verschiedener magnetischer Kräfte beinhalten, um ein möglichst komplexes haptisches Verhalten abzubilden. Um die Wirkung der Kombination aus visuellem und haptischem Feedback hinsichtlich der Immersion der Nutzer zu erforschen, sollte der Prototyp von Probanden getestet und ihre Wahrnehmung des Realitätsgrades der Simulation evaluiert werden. Unabhängig von der zusätzlichen haptischen Komponente sollte der Prototyp eine natürliche Steuerung ermöglichen, sodass Nutzer die Anwendung intuitiv bedienen können. Im

23

http://www.vrphobia.com/

Immersive Simulation eines Magneten ...

263

Gegensatz zu den üblichen Interaktionsmöglichkeiten, der sogenannten Natural User Interfaces (NUI), wie Touch- oder Gestensteuerung, sollten Nutzer in diesem Prototyp daher direkt mit den virtuellen Gegenständen interagieren. Der visuelle Zugang zum virtuellen Raum wurde über die VR-Brille Oculus Rift, Development Kit 2, realisiert. Für das haptische Feedback wurde ein Novint Falcon24 verwendet. Die Anwendung selbst wurde mit der Engine Unity3D25 entwickelt.

Entwicklung eines Prototyps zur Magnetsimulation Der entwickelte Prototyp sollte Anwender über das Head Mounted Display (HMD) Oculus Rift visuell in eine dreidimensionale Umgebung versetzen, mit der sie über das Force Feedback-Gerät Novint Falcon interagieren können. Dabei sollte der Schwerpunkt des Projekts nicht auf einem möglichst hohen Realitätsgrad der Szene, sondern auf der Kombination von Optik und Haptik liegen. Nutzer sollten nicht in der Lage sein, sich mit ihrem gesamten Körper im virtuellen Raum zu bewegen, sondern lediglich ihre Hand zu steuern und mit ihr haptisches Feedback wahrzunehmen. Im folgenden Abschnitt wird das Szenario beschrieben, das für den Prototyp entwickelt wurde. Zudem wird auf die Umsetzung der Steuerung im dreidimensionalen Raum und auf die Erzeugung des haptischen Feedbacks eingegangen.

Das Szenario Nutzer sollten beim Bedienen des Prototyps in die Rolle eines männlichen Lagerarbeiters schlüpfen. Daher wurde eine Lagerhalle als visuelle Umgebung modelliert. Damit sich Anwender, wenn sie die VR-Brille aufsetzen, mit ihrem virtuellen Ich identifizieren können, wurde das Modell eines Körpers in der Szene positioniert. Die Kamera wurde so auf dem Hals dieses Modells platziert, dass Nutzer die Möglichkeit hatten, an sich hinab zu sehen und ihren virtuellen Körper zu begutachten. Durch die Oculus Rift war es möglich, sich in der Szene durch Kopfbewegungen umzublicken und die virtuelle Umgebung aus Sicht des Arbeiters zu betrachten.

24

www.novint.com

25

www.unity3d.com

264

Ronja Scherz, Thomas Immich

Abbildung 1: Aufbau der Szene

Im virtuellen Raum wurde direkt vor dem Nutzer ein Tisch positioniert, auf dem sich die Gegenstände befanden, mit denen er interagieren konnte. Bevor auf die Umsetzung der Steuerung eingegangen wird, sollen an dieser Stelle kurz die einzelnen Gegenstände und die Interaktionsmöglichkeiten beschrieben werden.

Interaktion mit virtuellen Objekten Auf dem Tisch wurden zwei magnetische Platten platziert, sowie ein ebenfalls magnetischer Würfel. Der Nutzer selbst hält in seiner virtuellen Hand einen Stabmagneten, mit dem er den Würfel aufheben und zu den beiden Platten bewegen kann. Eine der Platten wirkt auf den Würfel eine abstoßende Kraft aus, die andere zieht ihn zu sich heran. Daraus ergibt sich folgender Interaktionsablauf: 1. Beim Start der Anwendung kann der Nutzer sich mit dem Stabmagneten dem Würfel nähern und spürt die dabei wirkende Anziehungskraft. Bei Berührung werden die beiden Gegenstände aneinander geheftet. 2. Hebt der Anwender den Stabmagneten mit dem Würfel hoch, so wird das zusätzliche Gewicht des Würfels simuliert. Er hat nun die Möglichkeit, sich den beiden magnetischen Platten zu nähern und ihre abstoßenden und anziehenden Kräfte zu spüren. 3. Berührt der Würfel die anziehende Platte, so kann er von dort nicht mehr abgehoben werden, da die magnetischen Kräfte der Platte stärker eingestellt wurden, als die des Stabmagneten.

Immersive Simulation eines Magneten ...

265

4. Der Nutzer hat nun noch die Möglichkeit, den Stabmagneten vom Würfel zu lösen. Anschließend ist die Interaktion abgeschlossen.

Abbildung 2: Die magnetischen Gegenstände in den verschiedenen Interaktionsphasen

Interaktion im virtuellen Raum Damit Anwender den Stabmagneten in der Szene steuern konnten, musste zunächst eine Verbindung zwischen den realen Handbewegungen des Nutzers und den Bewegungen der modellierten Figur in der Szene hergestellt werden. Da Nutzer die Kraftwirkungen der virtuellen Magnete direkt haptisch wahrnehmen sollten, wurde zu diesem Zweck der Novint Falcon verwendet. An diesem wurde ein Griff befestigt, sodass alle Anwender das Steuerelement intuitiv auf die gleiche Art mit ihrer Hand umschließen sollten. Auch am 3DModell des Stabmagneten wurde ein Griff angebracht, sodass dieser als verbindendes Element zwischen Realität und virtueller Umgebung diente. Anwender spürten somit während der Interaktion mit dem Prototyp den realen Griff in ihrer Hand, während sie in der virtuellen Umgebung auch eine visuelle Repräsentation des Griffs in ihrer Hand sahen. Die Handbewegungen des Nutzers wurden mit dem Novint Falcon getrackt und auf die virtuelle Figur übertragen. Dadurch waren Anwender in der Lage, den Arm der virtuellen Figur so zu bewegen, als wäre es ihr eigener. Sobald ein Nutzer in den Wirkungsbereich eines Magneten eintrat, wurde die Simulation der magnetischen Kräfte am Force Feedback Gerät ausgelöst.

Testdurchführung Um zu evaluieren, wie realistisch die magnetischen Kräfte durch diesen Prototyp simuliert werden können, wurde ein Test mit zwei Gruppen durchgeführt. Beide Gruppen zählten gleich viele Probanden und bestanden sowohl aus Personen mit großer Erfahrung im Informatik-Bereich als auch aus Teilnehmern mit nur wenig Computerkenntnissen.

266

Ronja Scherz, Thomas Immich

Es nahmen 22 männliche (57,9%) und 16 weibliche (42,1%) Probanden teil. Davon waren 23,7% der Teilnehmer zwischen 18 und 25, 39,4% zwischen 26 und 35, 13,2% zwischen 36 und 50 und 23,7% über 50 Jahre alt. 57,9% der Testpersonen hatten keine oder nur wenig Erfahrung mit Videospielen. Die VR-Brille Oculus Rift hatten 23,7% der Probanden bereits zuvor verwendet. Beide Gruppen sollten während des Tests die Oculus Rift tragen und sich folglich visuell in der gleichen Szene befinden. Auch bekamen beide Gruppen die gleiche Aufgabenstellung: Die Teilnehmer sollten mit den Magneten in der Szene interagieren und anschließend eine Aussage darüber treffen, ob sie die gespürten Kräfte für echt oder für simuliert hielten. Diese Frage wurde sowohl in einem Interview mündlich beantwortet und begründet, als auch in einem Fragebogen festgehalten. Während die erste Gruppe (Gruppe Sim) beim Test mit der Simulation arbeitete, wurden bei der zweiten Gruppe (Gruppe Echt) unterhalb des Novint Falcon echte Magneten aufgebaut. In dieser Kontrollgruppe diente das Gerät somit lediglich zum Tracking der Handposition des Nutzers, simulierte jedoch keine magnetischen Kräfte. Während des Tests wurden den Teilnehmern Anweisungen gegeben, zu welchem Objekt sie sich wann bewegen sollten, um den Testablauf bei jedem Probanden gleich zu gestalten. Jeder Teilnehmer absolvierte den Test zweimal in Folge. Anschließend bekamen die Probanden im Rahmen eines Interviews die Möglichkeit, ihre Empfindungen während der Arbeit mit dem Prototypen zu beschreiben und zu entscheiden, ob sie die magnetischen Kräfte als echt oder simuliert einstuften. Im Anschluss an das Interview füllten die Probanden einen Fragebogen aus. Dieser wurde speziell für dieses Projekt im Hinblick auf die Kernelemente Interaktion und Immersion entwickelt. Er enthielt daher sowohl Fragen bezüglich der Einschätzung des Realitätsgrades der simulierten Kräfte, als auch Fragen zur Steuerung und Identifikation mit der virtuellen Figur. Die einzelnen Frageelemente konnten dabei anhand von Ordinalskalen bewertet werden. Während des Tests wurden die Hand- und Kopfbewegungen der Teilnehmer aufgezeichnet. Außerdem wurde bei den Interviews der Ton mitgeschnitten. Dadurch konnten umfassende Daten zum Testablauf gewonnen und bei der Auswertung der Fragebögen mit einbezogen werden.

Testauswertung In diesem Abschnitt werden die Ergebnisse der Studie dargestellt. Dabei wird zunächst auf individuelle Aussagen und Reaktionen während der Interviews eingegangen. Anschließend wird die Auswertung der Fragebögen abgebildet.

Auswertung der Interviews Im Rahmen der Interviews wurden den Testpersonen folgende Fragen gestellt:

Immersive Simulation eines Magneten ...

267

1. War der getestete Magnet echt oder simuliert? 2. Was hat dich davon überzeugt? 3. Wie hat sich die Abstoßung für dich angefühlt? 4. Wie hat sich die Anziehung angefühlt? 5. Wie hast du den Test erlebt? Kannst du deine Gedanken dazu beschreiben? 6. Hat dich etwas gestört? 7. Wie hast du die Kombination aus Haptik und Visuell erlebt? Nachdem die Probanden eine Entscheidung bezüglich ihrer Einschätzung zur Echtheit des Magneten getroffen hatten, hatten sie so anhand des Leitfadens die Gelegenheit, diese zu begründen. Die weiteren Fragen dienten dazu, die Wahrnehmung der virtuellen Umgebung und der Interaktionsmöglichkeiten durch die Teilnehmer zu erörtern. Die Befragung ergab, dass 29 der 38 Probanden ihr Urteil über die Echtheit des Magneten hauptsächlich von dem Gefühl der Abstoßung abhängig machten. In beiden Testgruppen beschrieben viele dabei das „Wegrutschen“ oder „Vorbeigleiten“ zu den Seiten, das ein Absetzen des Würfels auf der Platte unmöglich machte, als Indiz für einen realen Magneten. Die Anziehung wurde hingegen von 13 Teilnehmern als „zu kurz“ oder „zu schnell“ beschrieben, um anhand dessen eine Aussage über die Echtheit treffen zu können. Nur fünf Probanden trafen ihre Entscheidung bezüglich der Echtheit des Magneten auf Grundlage der Anziehungskräfte. Insgesamt wurden die Kräftewirkungen, unabhängig von der Entscheidung für oder gegen einen echten Magneten, von der Hälfte der Teilnehmer als „sehr realistisch“ oder „natürlich“ beschrieben. Bei der Beantwortung von Frage 5 sprachen 17 Probanden von dem Gefühl, tatsächlich „in“ dem virtuellen Raum zu stehen, das die VR-Brille bei ihnen ausgelöst hatte. Zu Frage 7 sagten 23 Teilnehmer, dass die Identifikation mit der virtuellen Figur und die Möglichkeit, direkt, ohne Interface, mit den virtuellen Objekten zu interagieren, diesen Eindruck verstärkt hätten. Die haptische Komponente gab einigen Probanden ein „Gefühl der Kontrolle“. Allgemein wurde die Steuerung als sehr „natürlich“ und „einfach“ empfunden. Ein Teilnehmer formulierte: „Sobald ich den Griff in der Hand hatte, bin ich eingetaucht in diese virtuelle Welt.“ Auch Testpersonen, die im Alltag sehr wenig mit Computern arbeiten, sagten aus, sie hätten die Bedienung des Systems schnell erlernt und als „erstaunlich leicht“ empfunden. Eine große Anzahl der Testpersonen beschrieb die Kombination aus Fühlen und Sehen im virtuellen Raum als ein „neues Erlebnis“, das die Immersion verstärkte und Orientierung und Steuerung vereinfachte.

Auswertung der Fragebögen Die Aufteilung der Probanden in zwei Testgruppen diente dem Zweck, die Aussagen über die Echtheit des getesteten Magneten gegenüberstellen zu können. Die Auswertung der

268

Ronja Scherz, Thomas Immich

Fragebögen zeigt, dass die Anzahl der Probanden, die den getesteten Magneten für echt hielten, in beiden Testgruppen etwa gleich groß war. Als Antwort auf die Frage nach der Echtheit der getesteten Magneten wählten in Gruppe Sim 10 Personen „simuliert“ und 9 Personen „echt“. In Gruppe Echt wurde die Frage von 10 Probanden mit „echt“ und von 9 mit „simuliert“ beantwortet (siehe Abbildung 3). Probanden

Probanden

10

10

9

9

8

8

7

7

6

6

5

5

4

4

3

3

2

2

1

1 Antwort Gruppe Simuliert

Simuliert Antwort Gruppe Echt

Echt

Abbildung 3: Gegenüberstellung der Aussagen der beiden Testgruppen über die Echtheit des Magneten

Auch wenn das Benutzererlebnis des simulierten Magneten nicht vollständig mit dem eines echten übereinstimmte, so war es dennoch für die Hälfte der Testpersonen überzeugend. Durch die Kontrollgruppe, die mit dem echten Magneten arbeitete, wurde deutlich, dass auch ein realer Magnet nicht mehr zuverlässig als solcher identifiziert werden kann, wenn der Nutzer sich lediglich auf die Haptik konzentriert und die direkte visuelle Verbindung fehlt. Auch in dieser Gruppe antwortete nur die Hälfte der Teilnehmer mit „echt“, während die andere die magnetischen Kräfte für simuliert hielt. Somit kann davon ausgegangen werden, dass der Realitätsgrad des simulierten und des echten Magneten nahezu identisch empfunden wurde. Das Ergebnis dieser Studie spricht daher dafür, dass es durch die Kombination von visuellem und haptischem Feedback möglich ist, einen Gegenstand so realistisch zu simulieren, dass Testpersonen die Simulation nicht mehr zuverlässig als solche erkennen können. Neben der Gegenüberstellung der Aussagen der beiden Testgruppen zur Echtheit des Magneten wurden auch die Angaben zu Immersion und Steuerung betrachtet. So trug die Kombination aus Optik und Haptik bei 92,1% aller Teilnehmer entscheidend dazu bei, dass sie sich auf die virtuelle Umgebung einlassen konnten. Auch der Körper der virtuellen Figur wurde von 79% der Probanden beider Gruppen als hilfreich für die Immersion empfunden. Die Steuerung in der Szene wurde im Mittel mit 4,21 bewertet, wobei Werte zwischen 1 (nicht realistisch) bis 5 (sehr realistisch) vergeben werden konnten. Dies zeigt, dass die Möglichkeit der direkten Interaktion mit einer virtuellen Umgebung ohne Interface eine

Immersive Simulation eines Magneten ...

269

intuitive und natürliche Art der Steuerung darstellt, die von Probanden positiv aufgenommen wird. Bei der inferenzstatistischen Auswertung wurde mit Spearman-Rho ein Zusammenhang zwischen der angegebenen Immersion der Testpersonen mit der Empfindung der Kombination aus visuellem und haptischem Feedback überprüft. Dabei konnte ein stark signifikanter Zusammenhang festgestellt werden(p50% gilt, ist diese Zuordnung für jede Karte eindeutig. Karten, die für keine Kategorie solch eine Mehrheit erreicht haben, werden von SLA nicht zugeordnet. Im Falle einer rot dominierten Heatmap, kann SLA also sehr viele Zuordnungen treffen. Die Anwendung von SLA auf offene Experimente (Definition der Kategorien durch die Testteilnehmer) ist nicht sinnvoll. Eine Zuordnung einer Karte zu einer Kategorie kann ja nur dann erfolgen, wenn wenigstens mehr als 50% der Teilnehmer die gleiche Kategorie definiert und diesen die gleichen Karten zugeordnet haben. Alleine durch verschiedene Schreibweisen, Tippfehler, Groß-/Kleinschreibung oder Synonyme wird dies in der Praxis bei offenen CS-Experimenten so gut wie nie erreicht. DBSCAN DBSCAN ist die Abkürzung von “Density-Based Spatial Clustering of Applications with Noise”. Dieser Algorithmus gehört zur Familie der dichtenbasierten Verfahren der Clusteranalyse. Bei der klassischen Variante von DBSCAN (Alhajj 2007) werden Gruppen basierend auf räumlicher Nähe und der Festlegung eines Radius um einzelne Punkte gebildet. Diese Grundidee wird hier leicht abgewandelt. Wir gehen wiederum von einem geschlossenen CS-Experiment aus, d.h. die Kategorien waren für das CS-Experiment vorgegeben. Auch unser DBSCAN verwendet als Parameter den schon erwähnten Radius r, der in dieser Variante zwischen 0 und n (Anzahl der Versuchsteilnehmer) liegen muss. Eine Karte wird als sogenannte Core Card einer Kategorie zugeordnet, wenn maximal r Versuchspersonen die Karte nicht in diese Kategorie einsortiert haben. Positiv formuliert: Bei kleinem r haben also fast alle Personen, die Karte dieser Kategorie zugeordnet. In einem zweiten Schritt werden einer Kategorie zusätzlich sogenannte Border Cards zugeordnet, wenn diese wiederum von maximal r Versuchspersonen nicht mit einer der Core Cards in die gleiche Kategorie einsortiert wurden. Eine Karte, die zu weit von allen anderen Core Cards entfernt liegt, wird als Noise Card bezeichnet und bleibt unkategorisiert. Durch eine etwas größere Toleranz trifft DBSCAN (außer bei r=0) mehr Zuordnungen als SLA. Hierarchische Clusteranalyse Dies ist das für CS-Experimente in der Literatur (Martin und Kidwell 2001) allgemein empfohlene, klassische Gruppenbildungsverfahren. Es ist für offene und geschlossene CSExperimente geeignet, da es die Kategorien (ob vorgegeben oder benutzerdefiniert) nicht auswertet. Ausgangspunkt der Clusteranalyse ist die Distanzmatrix, eine Dreiecksmatrix, die für jedes Kartenpaar den Distanzwert für die beiden Karten angibt. Dies ist ein normierter Wert zwischen 0 und 1; dabei bedeutet 0, dass die beiden Karten immer zusammen in die gleichen Stapel, 1 bedeutet, dass sie nie zusammen einsortiert wurden; Zwischenwerte entsprechen teilweiser Gleich- und teilweiser Ungleichsortierung. Basierend auf dieser Distanz von Karten, wird das Maß verallgemeinert auf die Distanz von Mengen von Karten. Dabei unterscheidet die Clusteranalyse drei sogenannte Fusionierungsvarianten: Bei Average Linkage ist die Distanz zweier Kartenmengen gleich

Casolysis 2.0

449

der durchschnittlichen Distanz aller Paare von Einzelkarten; bei Single Link ist es die minimale Distanz zweier Einzelkarten und bei Complete Link die maximale Distanz zweier Einzelkarten. Der Algorithmus platziert zunächst jede Karte alleine in eine Gruppe (ein Cluster) und vereinigt anschließend jeweils die beiden Cluster, die die geringste Distanz gemäß der gewählten Fusionierungsvariante - haben. Startet man z.B. mit 30 Karten, also 30 Clustern, dann hat man nach einem Schritt 29 Cluster, dann 28 usw. Nach 24 Schritten z.B. sind alle Karten auf 5 Cluster aufgeteilt. Das Ergebnis des Clusteralgorithmus lässt sich mit einem sogenannten Dendogramm (siehe Abbildung 3) darstellen. Jede Zusammenführung zweier Linien - gelesen von links nach rechts - entspricht einem Fusionsschritt. Je weiter rechts ein solcher Schritt durchgeführt wird, desto größer ist die Distanz der zusammengeführten Cluster und desto fragwürdiger ist die Qualität des Ergebnisses (geringerer semantischer Zusammenhang der Clusterelemente). Je nachdem, welche Fusionierungsmethode angewendet wird, entstehen unterschiedliche Strukturen (Jain und Dubes 1988). So führen Complete und Average Linkage typischerweise zu homogenen Clustern, sind aber anfälliger gegen fälschliche Einbindung von Ausreißern; letzteres ist bei Single Linkage kaum der Fall - diese Methode führt aber oft zu Kettenbildungen. Casolysis 2.0 bietet daher die Möglichkeit Cluster aus den verschiedenen Varianten miteinander zu kombinieren. Multidimensionale Skalierung (MDS) Wie bei der Clusteranalyse ist der Ausgangspunkt bei dieser Methode die Matrix der Distanzen zwischen je zwei Karten. In einem MDS-Diagramm werden die Karten durch Punkte dargestellt, wobei die Abstände der Punkte untereinander möglichst so gewählt werden, dass sie den Distanzen in der vorgegebenen Distanzmatrix entsprechen. Das entstehende Punktmuster (siehe Abbildung 4 und 5) stellt daher eine visuelle Repräsentation der Distanzmatrix dar. Somit können Gruppen von Punkten (Karten), die gemäß der Distanzmatrix geringen Abstand haben, leicht als “Punktwolke” erkannt werden. Die Methode arbeitet nur näherungsweise, da sich die exakten Distanzen im Allgemeinen nicht alle gleichzeitig einstellen lassen. Ein Auffinden von Punktgruppen ist aber meistens gut möglich. Zudem erlaubt die Methode eine einfachere Einschätzung von Karten als “problematisch”, da diese als isoliert liegende Punkte im MDS-Diagramm auftauchen. In Casolysis 2.0 wurde die Algorithmus-Variante nach Kruskal (Holtmann 1974) implementiert; andere Varianten liefern ähnliche Ergebnisse. Manuelle Sortierung Trotz der verschiedenen Algorithmen kommt es vor, dass der Benutzer manuelle Nachbesserungen an den Ergebnissen vornehmen will. Dazu hat er im Werkzeug Casolysis 2.0 jederzeit die Möglichkeit. Im sogenannten “Preview”-Fenster kann der Benutzer neue Kategorien erzeugen, Kategorienamen vergeben oder verändern und auch einzelne Karten per Drag and Drop von einer Kategorie zu einer anderen verschieben.

450

Adrian Hülsmann, Yevgen Mexin, Gerd Szwillus, Anastasia Wawilow

Hold und Unhold Die Kombinierbarkeit von Teilergebnissen wird durch die Hold/Unhold-Funktionalität realisiert. Bei der Anzeige von Gruppierungsergebnissen der einzelnen Algorithmen kann der Benutzer einzelne bereits gebildete Kartengruppen fixieren (Hold-Operation). Sie werden dann ausgegraut dargestellt und im nächsten Bearbeitungsschritt nicht mehr berücksichtigt. Eine einmal getroffene Fixierung kann jederzeit auch wieder aufgehoben werden (UnholdOperation). Dieses Bedienkonzept erlaubt es dem Benutzer nach Wunsch einzelne, gewünschte Gruppen zu erhalten und trotzdem mit den restlichen Karten ungestört weiterzuarbeiten. Damit ist es möglich, den Lösungsraum flexibel zu explorieren, ohne Zwischenergebnisse zu verlieren.

Anwendungsbeispiel In der Folge präsentieren wir ein Anwendungsbeispiel von Casolysis 2.0 mit dem wir die Interaktionsmöglichkeiten exemplarisch darstellen. Es handelt sich um ein geschlossenes CS-Experiment, das mit WeCaSo (Vdovkin 2009) durchgeführt wurde. Analysiert wurde die Homepage einer unserer Partneruniversitäten (University of Reading, England). Auf der obersten Ebene enthält diese Seite sechs Links, die jeweils 3-6 verfeinernde Stichworte auf der nächsten Ebene anbieten. Als Karten haben wir die 24 Stichworte der zweiten Ebene verwendet, als Kategorien die sechs Links auf der obersten Ebene. Dieser Kartensatz wurde von 51 Teilnehmern (Informatik-Masterstudenten) getestet. Wir skizzieren nun einen möglichen Analyseprozess der Ergebnisse. WeCaSo liefert diese als Liste von Datensätzen in einer CSV-Datei. Jeder Datensatz enthält eine Zuordnung einer Karte zu einer Kategorie durch eine Versuchsperson. Für ein geschlossenes CS-Experiment ist es sinnvoll, als ersten Schritt nach Import der Daten die Heatmap (s. Abbildung 1) anzusehen. Es gibt viele „sehr rote“ Felder, d.h. es macht Sinn, um diese klaren Zuordnungen schnell einzufangen, den Algorithmus SLA mit einem hinreichend großen Schwellwert auszuführen; hier wählen wir etwa den Wert 70%. SLA bietet verschiedene Gruppen an, von denen wir zwei mit den Namen “About us” und “Research at Reading” (Abbildung 2 a) auswählen und durch Klick auf den Hold-Button fixieren. Die restlichen Karten verarbeiten wir jetzt zunächst mit dem DBSCAN Algorithmus. Hierbei geben wir Radius r=16 an, was bei 51 Versuchspersonen eine relativ enge Grenze ist. DBSCAN liefert einen weitere Gruppe mit dem Namen “Study at Reading”. Diese halten wir ebenfalls fest. Das bis dahin erzielte Zwischenergebnisse zeigt im Preview (Abbildung 2 b), die zwei mit SLA und eine mit DBSCAN gefundene Gruppe, sowie eine Gruppe von noch nicht zugeordneten Karten unter “Uncategorized”.

Casolysis 2.0

451

Abbildung 2: a) SLA-Ergebnis (links), b) Preview (rechts)

Auf diese “Restmenge” wenden wir nun das Clusteranalyseverfahren mit der Fusionsvariante Single Link an. Die drei Varianten werden in der Buttonleiste von Casolysis 2.0 direkt angeboten, sodass ein Vergleich der Clusterbildung möglich ist. Welches der drei Verfahren zur Anwendung kommen sollte, lässt sich nicht von vorneherein sagen - am besten experimentiert man mit den drei Varianten und vergleicht die Ergebnisse.

Abbildung 3: Dendogramm

452

Adrian Hülsmann, Yevgen Mexin, Gerd Szwillus, Anastasia Wawilow

In diesem Fall ergeben sich bei Verschiebung der Cut-Off-Linie im Dendogramm (siehe Abbildung 3) auf den Wert 0,53 zwei Cluster, die dem Benutzer semantisch sinnvoll erscheinen. Diese werden selektiert und mit dem Hold-Button fixiert. Das nun erzielte Zwischenergebnis zeigt im Preview-Fenster die 5 fixierten Gruppen mitsamt den Verfahren, in denen sie entstanden sind, ebenso unter “Uncategorized” die noch nicht einsortierten Karten. In dieser Ansicht fügen wir nun manuell die “übriggebliebenen” 3 Karten alle der Gruppe „About us“ hinzu, womit wir ein erstes Endergebnis erzielt haben.

Abbildung 4: MDS-Diagramm

Wenden wir nun in diesem Zustand der Analyse das MDS-Verfahren an, dann ist erkennbar, ob wir mit den getroffenen Zuordnungen gute Entscheidungen getroffen haben oder nicht. Die Punktwolke (siehe Abbildung 4) zeigt durch Farbkodierung die bislang definierten Gruppen. Während zum Beispiel vier der sechs orangenen Punkte47 aus der Gruppe “About us” links im Bild relativ eng zusammen liegen, ist die manuell zugeordnete Karten “Request a prospectus” rechts sehr weit davon entfernt. Gleichzeitig können wir erkennen, dass diese Karte besser der Gruppe (“Study at Reading”) zuzuordnen wäre, deren Punkte alle in der Nähe liegen. 47

Zu Abbildung 4: Was natürlich bei nicht-farbiger Darstellung leider nicht sehr deutlich wird.

Casolysis 2.0

453

In dieser ersten Analyse haben wir versucht, konstruktiv eine Lösung aus dem CSExperiment abzuleiten. Alternativ führen wir nun zur reinen Evaluation der existierenden Struktur eine Clusteranalyse durch und prüfen, wie gut die Cluster mit der echten Website übereinstimmen. Da die vorgegebene Struktur sechs Links aufweist, betrachten wir die Clusteranalyse-Ergebnisse an der Stelle im Dendogramm, wo gerade 6 Cluster entstanden sind. Bei Anwendung des Fusionsverfahrens Single Link zeigt sich in diesem Fall die größte Nähe zur vorgegebenen Seitenstruktur: Die Karte “Student Support” wurde beim Card Sorting unter “Study at Reading” einsortiert, während sie auf der realen Webseite unter “Life at Reading” auftrat. Ansonsten wird deutlich, dass alle Karten, die im Original unter “Things to do now” beim Card Sorting durchweg in die zugehörige Sachkategorie eingeordnet wurden - mit dieser Kategorie konnten die Testteilnehmer offenbar nichts anfangen. Erzeugt man ein MDS-Diagramm aus dem gesamten Datensatz (siehe Abbildung 5), erkennt man zusammenhängende Punktwolken, aber auch, dass es Karten gibt, die isoliert positioniert werden. Dies kann daran liegen, dass Karten tatsächlich in verschiedene Kategorien gehören oder aber von den Testteilnehmern nicht verstanden wurden. Das kann ein Werkzeug wie Casolysis natürlich nicht entscheiden, aber es kann Hilfsmittel wie MDS anbieten, um derartige Probleme überhaupt erkennbar zu machen. Wie an diesen Beispielen sichtbar wird, können CS-Experimente wertvolle Hinweise für die Gestaltung oder Verbesserung von Navigationsstrukturen liefern.

Abbildung 5: MDS-Diagramm des gesamten Datensatzes

454

Adrian Hülsmann, Yevgen Mexin, Gerd Szwillus, Anastasia Wawilow

Ausblick Wir können uns eine Reihe von weiteren Funktionen von Casolysis vorstellen. Zum einen könnte neben der bisherigen zweidimensionalen Darstellung von MDS-Diagrammen eine drei- oder ggf. höher-dimensionale Darstellung hinzukommen. Zwar ist die Interpretation dann schwieriger, aber die Diagramme würden eine genauere Positionierung der Punkte (Karten) erlauben. Auch wollen wir mehr Interaktion mit den MDS-Diagrammen anbieten, indem etwa visuell erkennbare Punktwolken vom Benutzer auch selektiert und als Gruppen abgespeichert werden können. Bislang bietet Casolysis 2.0 auch keine Unterstützung bei der Analyse von Kategorienamen, die in offenen CS-Experimenten von den Versuchsteilnehmern angegeben werden. Zwar sind Automatismen hier wenig zielführend, aber eine Anzeige der verwendeten Bezeichnungen würde schon sehr weiterhelfen, um Ideen für die Benennung der erzeugten Cluster zu bekommen. Literatur Alhajj, Reda (Hg.) (2007): Advanced data mining and applications. Third international conference. Berlin, Heidelberg, New York: Springer (Lecture Notes in Computer Science, Vol. 4632 : Lecture notes in artificial intelligence). Emmrich, Sebastian; Szwillus, Gerd (2008): Auswertung von Card-Sorting-Experimenten mit Casolysis. In: Michael Herczeg und M. C. Kindsmüller (Hrsg.): Mensch & Computer 2008. Viel Mehr Interaktion. Mensch und Computer 2008. Lübeck, 7.-10.09.2008. München: Oldenbourg. Enough Pepper (Hrsg.) (2012): xSort. xSort is a free card sorting application for Mac OS X aimed at user experience professionals and social scientists. Enough Pepper Lda. Online verfügbar unter http://www.xsortapp.com/, zuletzt geprüft am 8.4.13. Holtmann, D. (1974): Multidimensionale Skalierung, Methode und ihre Anwendung in den Sozialwissenschaften: Hansen. Jain, Anil K.; Dubes, Richard C. (1988): Algorithms for clustering data. Englewood Cliffs, N.J: Prentice Hall. Martin, Shirley; Kidwell, Donna K. (2001): A Case Study in Cluster Analysis for Intranet Organization. In: Tony Ambler, Ken Graham und Paul Jensen (Hrsg.): 2nd International Workshop on Engineering Management for Applied Technology, EMAT 2001. Austin, TX, USA, 16.-17. 08. 2001. Los Alamitos, Calif: IEEE Computer Society, S. 57–64. Optimal Workshop (Hrsg.) (2010): Optimal Sort. Online Card Sorting Software. Online verfügbar unter http://www.optimalworkshop.com/optimalsort.htm, zuletzt geprüft am 18.6.12. Spencer, Donna (2009): Card Sorting: Rosenfeld Media. Spencer, Donna; Warfel, Todd (2004): Card sorting: a definitive guide. Boxes and Arrows. Online verfügbar unter http://www.boxesandarrows.com/view/card_sorting_a_definitive_guide, zuletzt aktualisiert am 13.06.2012. Toro, Jorge A. (2001): CardZort. Online verfügbar unter http://www.cardzort.com/, zuletzt geprüft am 09.04.2013.

Casolysis 2.0

455

Vdovkin, Andreas (2009): Entwicklung einer webbasierten Card-Sorting-Applikation. Bachelorarbeit. Universität Paderborn, Paderborn. Institut für Informatik. Wood, Jed R.; Wood, Larry E. (2008): Card Sorting: Current Practices and Beyond. In: Journal of Usability Studies 4 (1), S. 1–6.

Programmkomitee Programmkomiteevorsitz Anja Endmann, itCampus Software- und Systemhause GmbH Holger Fischer, s-lab – Software Quality Lab, Universität Paderborn Programmkomiteemitglieder Henning Brau, BSH Hausgeräte GmbH Susanne Hanst, proALPHA Software GmbH Steffen Hess, Fraunhofer IESE Jochen Heyden, Freelance Andreas Hinderks, RMTSoft GmbH & Co. KG Oliver Jacobs, ergonomics Oliver Kluge, Versicherungskammer Bayern Malte Krökel, BSH Hausgeräte GmbH Andreas Lehmann, lemisoft Eva Nesbach, Goodgame Studios Malte Sönksen, artop – Institut an der Humboldt-Universität zu Berlin Markus Weber, Centigrade GmbH

Autoren Acevedo, Cristián Cristián Acevedo studierte Design mit einem Schwerpunkt im Kommunikationsdesign an der Universidad Tecnológica Metropolitana in Santiago, Chile. Er arbeitete als Designer, Illustrator und Art Director und machte schließlich seinen Master im Fach elektronische Medien an der Hochschule der Medien in Stuttgart. Im Anschluss war er im Bereich User-Centered Design als Interaction und User Experience Designer tätig. Seit 2013 arbeitet er als Senior Designer bei Phoenix Design in den Bereichen Automotive, Consumer Electronics, Smart Products, Film und Animation.

Ammermüller, Sebastian Sebastian Ammermüller arbeitet als Informationsarchitekt und UXBerater bei der Micromata GmbH in Kassel. Schwerpunkte sind die strategische Produktentwicklung, konzeptionelle Ausgestaltung und Evaluation digitaler Anwendungen sowie die Kommunikationsberatung in den Bereichen Automotive, Logistik, Healthcare, Statistics und Mobile Application Design.

Archipovas, Saulius Saulius Archipovas studierte Digitale Medien B.Sc sowie Informatik M.Sc. mit Schwerpunkt Interaktion sowie Digitale Medien, wo er breites Wissen unter anderem in Interaktionsdesign, Software und Usability Engineering, erwarb. In seiner Abschlussarbeit setzte er sich mit der visuellen Programmierung von MR-Sequenzen auseinander und verfolgt diese Thematik auch bei seiner Arbeit im Fraunhofer Mevis Institut in Bremen.

460

Autoren

Beck, Astrid Astrid Beck hat in Berlin Informatik und in Los Angeles Computer Science studiert. In Stuttgart war sie beim Fraunhofer-Institut für Arbeitswirtschaft und Organisation tätig, bis sie sich 1994 mit GUI Design selbstständig machte. Seit 2004 hat Astrid Beck zudem eine Professur für Mensch-Maschine-Schnittstellen an der Hochschule Esslingen. Ihre Beratungs- und Lehrschwerpunkte sind die Konzeption von Benutzungsoberflächen, Usability und User Experience. Ihre Kunden sind u.a. Banken (ING-DiBa, LBBW, Dresdner Bank, Deutsche Bank) und große Unternehmen (Bosch, Daimler AG, Carl Zeiss, Deutsche Post AG). Sie ist Expertin im Normenausschuss NAE Ergonomie bei der DIN sowie Mitglied bei SENS. Seit April 2011 leitet Sie gemeinsam mit Anja Wipfler den Arbeitskreis Nachwuchsförderung der German UPA.

Behrenbruch, Kay Kay Behrenbruch studierte Industrieanthropologie an der ChristianAlbrechts-Universität Kiel, arbeitete als wissenschaftlicher Mitarbeiter an der Universität Kassel im Forschungsprojekt VENUS und engagiert sich im Bereich Produktergonomie in Forschung und Lehre, u.a. als Lehrbeauftragter an der Fachhochschule Kiel. Parallel führt er seit 2006 Beratungen für eine ergonomische Produktgestaltung durch und gründete 2011 die Firma Humanergonomics, die er als Geschäftsführer leitet. Er ist aktives Mitglied im Normausschuss Ergonomie des Deutschen Instituts für Normung, im Ausschuss VDI/VDE-GMA FA 5.31 Nutzergerechte Gestaltung von Maschinenbediensystemen (3850) sowie im Arbeitskreis Qualitätsstandards der German UPA.

Bonhag, Wolfgang Seit 25 Jahren ist er in der Software-Entwicklung bei DATEV eG im Bereich Business-Software tätig, Er ist Berater für User Interface Design mit Microsoft-Technologien. Sein Arbeitsschwerpunkt ist das Interaktionsdesign der Programme sowie die Evaluation, Prüfung und Bewertung der Qualität von Bedienoberflächen.

Autoren

461

Brade, Dr. Marius Marius Brade arbeitet und forscht seit 2010 im Schnittgebiet von Interaktionsdesign, Informatik und Kognitionspsychologie. Die „Begreifbare“ Interaktion von Gedanken als Objekte mit welchen in Computersystemen interagiert werden kann, begeistert ihn seit seinem Studium der Medieninformatik an der TU Dresden. Er promovierte im Rahmen einer Industriepromotion an der Technischen Universität Dresden in Kooperation mit SAP Research. In seiner Doktorarbeit erforschte er Visualisierungsmethoden zum Sammeln und Strukturieren von Informationen, die zu neuartigen und innovativen Bedienkonzepten im Bereich der Wissensmodellierung führten. (mehr Infos unter: http://www.visualsensemaking.info).

Burghart, Andreas Andreas Burghart studierte Interaktionsgestaltung an der HfG Schwäbisch Gmünd. Im Rahmen seiner Bachelorarbeit befasste er sich mit Konzepten für den sinnvollen Einsatz von digitalen Medien innerhalb des deutschen Notrufsystems. Andreas arbeitet an der Schnittstelle zwischen Usability Engineering und Visual Design.

Diefenbach, Sarah Sarah Diefenbach ist Professorin für Wirtschaftspsychologie an der Ludwig-Maximilians-Universität München. Schwerpunkte ihrer Forschung sind das Konsumentenerlebens und die Gestaltung interaktiver Produkte unter psychologischen Gesichtspunkten. Vor dem Ruf an die LMU war sie in interdisziplinären Arbeitsgruppen (Gestaltung, Psychologie) an der Folkwang Universität Essen und der Universität Koblenz-Landau tätig.

Ecker, Martin Martin Ecker ist seit 2012 Software Engineer mit dem Schwerpunkt Soft- und Hardware Prototyping bei der User Interface Design GmbH (UID) in Ludwigsburg. Im Rahmen von Kunden- und Forschungsprojekten experimentiert der Informationsdesigner mit Technologie und macht Interaktionskonzepte mit neuartigen Objekten erfahrbar.

462

Autoren

Endemann, Oliver Oliver studierte Produkt-Design mit dem Schwerpunkt IndustrieDesign an der Universität Kassel. Selbstständige Software- und UIEntwicklung ab 2000. Von 1998 -2003 wissenschaftlicher Mitarbeiter an der Universität Kassel (Produkt-Design). Seit 2009 bei chilli mind GmbH in Kassel als Senior UI-Designer und UX-Manager tätig. Der Fokus seiner Arbeit liegt auf der konzeptionellen und nutzerzentrierten Entwicklung, Gestaltung und Evaluation von User-Interfaces digitaler Produkte im Bereich industrieller und technischer Anwendungen wie Gerätesteuerungen, Portallösungen und mobile Applikationen.

Endmann, Anja Anja Endmann, Diplom-Kommunikationspsychologin, arbeitet als Senior UX Researcher bei der itCampus GmbH. Ihr Aufgabenspektrum umfasst die Bereiche User Research, Evaluation von Softwarelösungen, Agile & User Experience, Projektmanagement, Coaching und Trainings. Seit 2012 arbeitet Sie als Dozentin, u.a. an der HTWK Leipzig und der HTW Dresden. In der German UPA engagiert sie sich seit 2012 im Arbeitskreis User Research und wurde 2014 zum Fachvorstand gewählt.

Engler, Michael Michael Engler beschäftigt sich seit elf Jahren mit dem Thema Usability. Er ist Mitglied im Arbeitskreis Qualitätsstandards der German UPA und im Normungsgremium zur IEC 62366 – DKE/UK 811.4 Ergonomie, Gebrauchstauglichkeit, Gebrauchsanweisung sowie im Fachausschuss „Software-Qualität in der Medizintechnik“ und im Richtlinienausschuss „Medical SPICE“ des Verbands Deutscher Ingenieure. Als freier Berater hat er zahlreiche Projekte zum Thema Gebrauchstauglichkeit für Medizinprodukte durchgeführt. Er schult, berät und coacht Unternehmen der Medizintechnikbranche zu den Themen Requirements- und Usability-Engineering.

Autoren

463

Feindt, Doreen Sie ist Diplom Wirtschaftspsychologin (FH) mit dem Schwerpunkt Arbeits- und Ingenieurpsychologie. Seit 2004 arbeitet sie im User Experience Team von GfK in Hamburg. Als Senior Consultant leitet sie dort zahlreiche qualitative User Experience Projekte, die inhaltlich von Konzepttests und Rapid Prototyping über Akzeptanztests bis hin zu multi-nationalen Studien reichen. Ihr besonderes Interesse gilt den digitalen Produkten der Finanzbranche, für die sie als Account Manager im Bereich User Experience bei GfK mitverantwortlich ist.

Feustel, Sven Sven Feustel studierte Industrial Design an der Fachhochschule Design&Medien Hannover. Parallel arbeitete er 3 Jahre bei BOSCH Telekom im Mobile Phone Bereich. Anschließend arbeitete er ein halbes Jahr bei Isao Hosoe Design in Mailand und konzipierte dort überwiegend Nutzungsszenarien für Flugzeuginterieurs. Seit 2001 arbeitet er bei Phoenix Design in Stuttgart und leitet seit mehreren Jahren das Produkt Design Team. Der Schwerpunkt liegt in der Konzeption und der Kreation von markentypischen und nutzerzentrierten Produktstrategien.

Fichte, Ludwig Ludwig Fichte arbeitet als Senior User Experience Researcher bei der SAP SE. Seine Arbeitsschwerpunkte liegen zum einen darin, Entwicklungsteams bei der Erhebung, Auswertung und Umsetzung von Benutzungsanforderungen zu beraten und zu unterstützen. Weiterhin trägt er als interner UX-Trainer dazu bei, Methodenwissen und praktische Erfahrungen in Schulungen an weltweite Teams zu vermitteln. Vor seiner Tätigkeit bei SAP arbeitete er für die Fahrzeugsystemdaten GmbH als Usability Engineer. Hier verfasste er auch seine Diplomarbeit zum Thema nutzungszentrierte Konzeption und Evaluation einer Datenerfassungssoftware für mobile Kontexte. Ludwig studierte Kommunikationspsychologie an der Hochschule Zittau/Görlitz mit Schwerpunkt auf Psychologie der MMI.

464

Autoren

Fischer, Holger Holger Fischer studierte Medieninformatik an der FH Köln und arbeitet seit 2010 als wissenschaftlicher Mitarbeiter an der Universität Paderborn. Dort war er zunächst im C-LAB tätig, bevor er 2013 ins slab – Software Quality Lab wechselte. Als Usability Consultant unterstützt er die Ein- und Durchführung von Human-Centered Design Aktivitäten in Softwareentwicklungsprozesse und thematisiert dies auch als Lehrbeauftragter an der FH Köln. Seine Forschung fokussiert die Integration von Usability Engineering und modellgetriebener Softwareentwicklung. In der German UPA ist er seit 2010 im AK Qualitätsstandards engagiert und wurde 2014 zum Vize-Präsidenten gewählt.

Flechtner, Rahel Rahel Flechtner studierte Industrial Design an der Hochschule Magdeburg-Stendal. Während des Studiums absolvierte sie Praktika bei Phoenix Design in Stuttgart und den Telekom Innovation Laboratories in Berlin und ist jetzt bei Phoenix Design als User Experience Designerin tätig. Sie arbeitet in den Bereichen Smart Home, Consumer Electronics und Unternehmenssoftware.

Fröhner, Moritz Moritz Fröhner schreibt seit 1998 leidenschaftlich HTML und arbeitet bei der Micromata GmbH als Informationsarchitekt und UX-Berater mit Schwerpunkt auf Konzeption digitaler Dienstleistungen und Usability Evaluation in den Bereichen Automotive, Logistik und Transport, Rohstoffgewinnung und Medizintechnik.

Geis, Thomas Thomas Geis ist seit 1993 im Arbeitsgebiet Usability Engineering tätig und seit 2003 Geschäftsführer der ProContext Consulting GmbH, einem Beratungshaus, das auf Requirements Engineering aus Nutzersicht, Produktmanagement und Standardisierung im Usability Engineering spezialisiert ist. Er hat zahlreiche Anforderungsanalysen aus Nutzersicht, Interaktionsdesignprojekte und Usability-Tests sowie Schulungen für Software-Entwicklungsteams durchgeführt. Er verfügt über profundes Wissen im Bereich Usability Engineering und in der konsequenten Umsetzung theoretischer Ansätze in die Praxis. Er leitet den DIN-Ausschuss „Benutzungsschnittstellen“ und den ISOAusschuss „Common Industry Formats for usability-related information“, kurz CIF.

Autoren

465

Gerstheimer, Oliver Oliver ist seit über 15 Jahren passionierter Fährtensucher & Evangelist für die Praxis des „Design Acting“ und bessere „Digitale Produkte & Services von Morgen“. 2001 gründete er die chilli mind GmbH – ein verflixt scharfer Think Tank für digitale Innovation, UX-Design, Business Model Generation und Informationsarchitektur. Er ist regelmäßiger Speaker und Publizist auf internationalen Innovations- & Design-Bühnen und war 14 Semester Fachdozent an deutschen und schweizerischen Designhochschulen. Oliver studierte Produktdesign sowie Technologie- & Innovationsmanagement.

Gruchmann, Torsten

!

Torsten Gruchmann erlangte sein Diplom 1995 im Fachbereich Physikalische Technik an der Fachhochschule Münster. Nach einem Jahr in der Medizintechnik-Abteilung eines Krankenhauses war er für die praktische Ausbildung der Studenten des Studienganges Biomedizinische Technik an der FH Münster zuständig. Darüber hinaus baute er während dieser Zeit das Zentrum für Gebrauchstauglichkeit und Medizintechnik an der FH Münster auf. 2001 gründete er die Use-Lab GmbH als unabhängiges Beratungsunternehmen. Seitdem ist es ein Schwerpunkt seiner Arbeit, die Bedürfnisse von Nutzern zu verstehen und daraus Produktspezifikationen und Produktkonzepte abzuleiten.

Hatscher, Michael „Mitch“ Calendar UX Lead und Senior User Experience Designer, Google. Bei Google seit 2007 mit Tätigkeit auf Calendar, Datenschutz-Produkten, YouTube, Gmail, Maps. 2005-07 Senior User Interface Manager bei AOL Deutschland, 2001-05 User Interface Designer bei der SAP AG und SAP Deutschland. 2000 Psychologie-Diplom über „Joy of use – Determinanten der Freude bei der Softwarenutzung“.

466

Autoren

Heidmann, Prof. Dr. Frank Frank ist seit 2005 Professor für das Themenfeld „Design of Software Interfaces“ im Studiengang Interfacedesign an der Fachhochschule Potsdam. Seine Interessen in Forschung und Lehre umfassen neben der Gestaltung und Evaluation von Benutzungsschnittstellen, die Visualisierung raumbezogener Daten (Geovisualisierung), Smart Cities und Green IT sowie die Frage wie Informations- und Kommunikationstechnologien individuelle Einstellungsund Verhaltensänderungen hinsichtlich nachhaltiger Lebensstile fördern können.

Held, Theo Dr. Theo Held studierte Psychologie an der Universität Regensburg (Schwerpunkt: experimentelle Wahrnehmungspsychologie). Nach der Promotion (Universität Heidelberg) war er in Forschung und Lehre an den Universitäten Heidelberg, Graz und Halle/Saale tätig. Seine hauptsächlichen Forschungsinteressen liegen in den Bereichen Wahrnehmung und Wissensrepräsentation, sowie der Evaluation von Softwareprodukten. Seit 2001 gehört er dem User Experience Team der SAP an. Bis Ende 2010 war er für eine Reihe zentraler Designkonzepte der SAP Customer Relationship Management Lösung verantwortlich. Seit 2011 ist er als User Experience Research Expert für die Entwicklung von Evaluationsmethoden zuständig.

Helmreich, Kristina Kristina Helmreich ist bei DATEV eG als UX-Designerin für die Produktentwicklung tätig. Neben den Themenschwerpunkten Ergonomie und User Centered Design erarbeitet sie im Rahmen der unternehmensweiten Designstrategie die Komponenten für das User Interface Design.

Hemke, Felix Felix Hemke ist Mitarbeiter im Forschungsvorhaben "KOMET – Kompetenzzentrum für die Etablierung von Usability in KMU und Schaffung von nutzerzentrierten Vorgehensmodellen" an der Hochschule für Technik und Wirtschaft Berlin (HTW).

Autoren

467

Henß, Sarah Sarah studierte Produktdesign mit Schwerpunkt Systemdesign an der Universität und Kunsthochschule Kassel. Seit 2012 ist sie bei chilli mind als Senior-Design-Consultant (UXQB zertifiziert) und verantwortet als Cross-Media-Konzepter und Projektleiter die Entwicklung von neuen, benutzerfreundlichen Formaten und UserInterfaces. Sarah ist zudem seit 2013 Autor und aktives Mitglied im UPA-Arbeitskreis Usability in der Medizintechnik.

Hess, Steffen Steffen Hess ist User-Experience-Teamleiter am Fraunhofer IESE; seit 5 Jahren in den Schwerpunkten Anforderungserhebung, UXEvaluation, UX-Konzeption und Projektmanagement mit Schwer-punkt Mobile UX tätig.

Hintz, Stefan Stefan Hintz ist seit 2015 mit dem Schwerpunkt Soft- und HardwarePrototypen bei der User Interface Design GmbH (UID) in Berlin tätig. Er studiert seit 2011 Interface Design (BA) an der Fachhochschule Potsdam.

Hopf, Prof. Dr. Hans-Georg Gründer und wissenschaftlicher Leiter des UEC. Arbeitsgebiet Softwareentwicklung und -qualität seit 1989. Arbeitsschwerpunkte: Human Centered Software Engineering, Usability Engineering, Requirements Engineering und Softwaremetriken.

Hühne, Knut Knut Hühne ist Mitarbeiter im Forschungsvorhaben "KOMET – Kompetenzzentrum für die Etablierung von Usability in KMU und Schaffung von nutzerzentrierten Vorgehensmodellen" an der Hochschule für Technik und Wirtschaft Berlin (HTW).

468

Autoren

Hülsmann, Adrian Adrian Hülsmann ist wissenschaftlicher Mitarbeiter in der Fachgruppe Mensch-Computer-Interaktion der Universität Paderborn. Seine Forschungen konzentrieren sich u.a. auf die Entwicklung kooperativer Systeme mit interaktiven Displays.

Hußlein, Steffi Steffi Hußlein ist Professorin für Interaction Design an der HS Magdeburg-Stendal am Institut Industrial Design. Sie lehrt "Interactive Systems & Products“ im MA Interaction Design und BA Industrial Design. Ihre Schwerpunkte sind Behavior & Physical Interaction Design, Information Visualization und -Architecture, UXD und Usability in Kombination von Soft- and Hardware. Davor war sie Vertretungsprofessorin für Interface Design an der HS Anhalt in Dessau im Bauhaus. Als Research Assistent im Interface Design und Informationswissenschaften hat sie das Forschungslabor IDL/Interaction Design Lab an der FH Potsdam etabliert. Als Designerin war sie u.a. tätig für Meta Design (Corporate Design & Informations- und Leitsysteme), bvm (Game Design), Telekom Labs (Research) und Icon Mobile (Mobile Design). Sie studierte an der Universität der Künste in Berlin Industriedesign mit dem Schwerpunkt Interaktive Systeme in der Klasse ID5. Unter anderem in Barcelona und Hildesheim Industrial Design. In China lehrte sie an der CDK/ Academy of Arts und am Leeds College of Art, UK.

Immich, Thomas Thomas Immich ist Mitbegründer und Geschäftsführer der Centigrade GmbH und leitet dort den Bereich User Experience. Seit vielen Jahren beschäftigt er sich mit nutzer-zentrierten User Interface Design Methoden im Hinblick auf deren technische Umsetzbarkeit und Werkzeugunterstützung. Er betreute zahlreiche Kundenprojekte namhafter Industrieunternehmen wie z.B. TRUMPF Werkzeugmaschinen und berät in seiner Funktion als Projektleiter und Trainer agile Softwareentwicklungsteams bezüglich der ästhetischen und konzeptionellen Optimierung von User Interfaces, vor allem im .NET Umfeld.

Autoren

469

Jendryschik, Michael Michael Jendryschik leitet seit 2008 den Bereich Usability Engineering bei der itemis AG. Er ist Diplom-Informatiker, zertifizierter Usability Engineer (Fraunhofer FIT, CPUX-F) und Spezialist für die Konzeption und Entwicklung von Software und Webseiten mit hoher Usability. Für seine Arbeits- und Interessensschwerpunkte Usability und Webstands engagiert er sich als Autor und Speaker, ist Mitglied der Webkrauts und Leiter der Regionalgruppe Metropole Ruhr der German UPA.

Kaase, Florian Florian Kasse, Konzepter und Usability-Consultant, ist seit 2011 bei artop in Usability/UX-Projekten tätig. Dort ist er mit seinem Hintergrund als Informatiker und Anwendungsentwickler Teil des interdisziplinären Teams. Seine Tätigkeitsschwerpunkte sind die Analyse und Spezifikation von Anforderungen an interaktive Produkte und Services, die Konzeption von Benutzungsschnittstellen und die Entwicklung von Mockups/Prototypen sowie dem Einsatz von Experten-Evaluationsverfahren. Sein Ansatz: Im Projektkontext das beste Vorgehen für eine erfolgreiche Analyse oder Konzeption finden, um mit dem Auftraggeber gemeinsam Produkte und Services mit positiver User Experience und hoher Usability zu entwickeln.

Kauer, Dr. Michaela Michaela Kauer studierte Psychologie an der Technischen Universität Darmstadt. Nach ihrem Abschluss 2008 wechselte sie an das Institut für Arbeitswissenschaft (IAD) der TU Darmstadt, wo sie seit 2010 für den Bereich Usability zuständig ist. Nach dem Abschluss ihrer Promotion zu Technikakzeptanz im September 2012 leitete sie die Forschungsgruppe Produktergonomie am IAD. Inhaltlich liegt ihr Forschungsschwerpunkt auf Fragen der Akzeptanz und Usability von technischen Lösungen. Seit Ende 2012 leitet sie das Unternehmen Custom Interactions mit dem sie Firmen bei der menschzentrierten Gestaltung ihrer Produkte unterstützt.

470

Autoren

Kenaan, Sabrin Sabrin Kenaan ist seit 2015 Studentin des Masterstudiengangs Medieninformatik an der Universität Regensburg und ist nebenbei seit 2014 als Werkstudentin im Bereich des Usability Engineerings bei der Firma car-i-solutions in Regensburg tätig. Während ihres vorangegangenen Bachelorstudiums der Medieninformatik und Medienwissenschaft entwickelte sie ihr Interesse für die Bereiche des Usability Engineerings und des User Experience Designs. Anhand verschiedener universitärer Projektarbeiten, die in Kooperation mit externen Firmen entstanden, konnte sie erste praktische Kenntnisse in den genannten Interessensbereichen erwerben. Diese konnten im Rahmen ihrer abschließenden Bachelorarbeit – mit dem Schwerpunkt Usability Engineering – erweitert und vertieft werden.

Kessner, Daniela Daniela Keßner, Diplom-Psychologin, ist Senior UX Designer bei der itCampus GmbH. Ihr Aufgabenbereich umfasst den User Research, das Interaktionsdesign und die Evaluation von Software und Webanwendungen. Frühere berufliche Stationen waren die Kompetenzinitiative Usability an der TU Berlin, wo sie mittelständische Unternehmen bei der Usability-Optimierung ihrer Produkten unterstützte, sowie die Siemens AG, wo sie als Usability Expertin an der Entwicklung eines Krankenhaus-Informationssystems beteiligt war.

Kiefer, Felix Arbeitet als User–Experience–Engineer für John Deere (ETIC). Seit mehr als 5 Jahren beschäftigt er sich mit dem Thema Mobile UX. Dabei erstrecken sich die Tätigkeiten von der Anforderungserhebung, über Konzeption und Design bis hin zur eigentlichen Entwicklung von mobilen Applikationen.

Kim, Kathrin Kathrin Kim arbeitet als User Experience Consultant bei der User Interface Design GmbH (UID). Zu den Schwerpunkten der DiplomSozialwissenschaftlerin zählen User Research, User Experience Consulting, Interaction Design und UI-Dokumentation.

Autoren

471

Kittmann, Ralf Ralf Kittmann ist Senior Produktdesigner und blickt auf fünf Jahre Berufserfahrung zurück: Mit Projekten aus dem Bereich Sanitär, Licht und Beleuchtung, Möbel und Medizintechnik deckt er ein breites Spektrum an innovativem Design ab, das seine Expertise im Bereich nachhaltiges Design bestens ergänzt.

Klein, Peter Dr. Peter Klein ist als Head of Research für die User Interface Design GmbH (UID) tätig. Er koordiniert sämtliche Forschungsprojekte und setzt Forschungsarbeiten in marktgerechte Dienstleistungen um. Der Diplom-Informatiker lehrte an der Hochschule Reutlingen und der Hochschule der Medien (HdM) in Stuttgart und publizierte zum Thema Ambient Assisted Living (AAL), Service-Robotik in der Pflege sowie zur Visualisierung von großen Datenmengen.

Kluge, Oliver Oliver Kluge hat Elektro- und Informationstechnik an der TU München studiert. Nach dem Studium arbeitete er viele Jahre als SoftwareIngenieur in der Anwendungsentwicklung. Seit 2008 beschäftigt er sich als Usability Engineer mit Fragen zur Gebrauchstauglichkeit von Anwendungen und Produkten bei der Versicherungskammer Bayern (VKB). Er verantwortet alle Usability Engineering Aktivitäten für die Anwendungen, die den Vertriebspartnern der VKB am Point of Sale zur Verfügung gestellt werden.

Köbler, Felix Dr. Nach seiner Promotion an der Fakultät für Informatik der Technischen Universität München (TUM) ist Dr. Felix Köbler in den Bereichen User Experience Design und strategische Beratung sowie im Business Development bei der FELD M GmbH und als selbständiger Berater tätig. Zudem berät er nationale wie internationale Startups. Seine Forschungsinteressen fokussieren sich auf Gamification, Persuasive Technologies sowie Ubiquitous und Mobile Computing mit einem starken Fokus auf Human-Computer Interaction.

472

Autoren

Kolb, Nina Nina Kolb studierte Psychologie an der Technischen Universität Darmstadt. Seit April 2015 ist sie dort am Institut für Psychologie als wissenschaftliche Mitarbeiterin in der Forschungsgruppe für Arbeitsund Ingenieurpsychologie tätig. Ihre Forschungsinteressen liegen im Bereich der Mensch-Maschine-Interaktion, wie der Erfassung von User Experience mithilfe psychophysiologischer Methoden sowie dem Umgang von Nutzern mit sicherheitskritischen Technologien.

Koller, Franz Franz Koller ist Managing Director bei der User Interface Design GmbH. Er ist seit den 80er Jahren im Bereich Usability und User Experience tätig. Er war Mitinitiator und Editor der DIN EN ISO 14915 zu Software-Ergonomie von Multimedia und hat umfangreiche Erfahrungen in UX-Projekten im industriellen Kontext gesammelt.

Köppen, Jan Jan Köppen ist Interaction Designer bei der User Interface Design GmbH (UID). Zu den Schwerpunkten des diplomierten Media System Designer gehören die Konzeption von Produkten, TouchscreenInterfaces und die Gestaltung für ökologisches und gesundheitsbewusstes Verhalten.

Kortekaas, Reinier Dr. Reinier Kortekaas arbeitet bei Siemens Healthcare GmbH in der Entwicklung von Röntgensystemen für die Angiographie, d.h. die Untersuchung und Behandlung von Gefäßen. Sein Schwerpunkt ist dabei die User Experience. Vor seiner Tätigkeit in der Angiographie arbeitete er mehrere Jahren als Produktmanager mit starkem Fokus auf Usability bei Siemens Hörgeräte. Reinier studierte Informatik kombiniert mit Sprachwissenschaften in Amsterdam, hat in der Psychoakustik in Eindhoven promoviert, und war 2 Jahre als PostDoc in den USA tätig. Reinier interessiert sich stark für die Methodik der UX.

Autoren

473

Kropp, Edna Edna Kropp ist Usability Beraterin bei der akquinet AG in Berlin. Ein weiterer Schwerpunkt ihrer Arbeit ist die Integration des HumanCentered Design Ansatzes in den Softwareentwicklungsprozess. Sie ist im Organisationsteam des World Usability Day Berlin und Mitglied der German UPA sowie der Gesellschaft für Informatik.

Krüger, Cord Cord Krüger ist Produktmanager Blended Learning bei der Bibliomed Medizinische Verlagsgesellschaft mbH. Er studierte an der Johannes Gutenberg-Universität Mainz Publizistik, Filmwissenschaft, Politikwissenschaft und an der Hochschule Karlsruhe Technische Dokumentation. Fokus seiner Expertise im Projekt sind das OverallManagement, das Portfoliomanagement, die Dienstleisterauswahl sowie die Gestaltung der LMS-Online-Plattform und die redaktionelle Prozessgestaltung im Bereich Blended Learning der neuen eLearningFormate bei Bibliomed.

Kuhn, Jasmin Jasmin Kuhn hat durch ihr Informatik-Studium mit dem Schwerpunkt auf dem Bereich Mensch-Maschine-Wechselwirkung viele Einblicke in die Gestaltung und Evaluation von Anwendungen sowie einen tiefen Einblick in die Bereiche des User Experience und Usability bekommen. Sie war seit 2012 in verschiedenen Firmen im Bereich Usability aktiv beschäftigt und arbeitet seit 2014 bei der itemis AG als Usability Engineer. Hier hat sie unter anderem in verschiedenen Projekten die Gebrauchstauglichkeit von Anwendungen bewertet und entsprechende Verbesserungsvorschläge erarbeitet.

Kumar, Janaki Janaki Kumar is the Head of Strategic Design Services, America in SAP’s Design and Co-Innovation Center. She leads a team of designers who work directly with customers to transform their user experience. She has over a decade of experience building, coaching, and leading high performance teams to deliver design-led innovation. She is the coauthor of the book ‘Gamification at Work – Designing Engaging Business Software’. She has given a TEDx talk on Gamification at Work. Janaki has a Masters in Information Systems from Boston University. She has authored 20 intellectual property patent applications of innovative user experiences.

474

Autoren

Kühnel, Michael Michael Kühnel ist Frontendentwickler bei der Micromata GmbH. Seit Netscape 4.7.8 (2001) im Geschäft, schreibt er inzwischen fast ausschließlich HTML, CSS und JavaScript mit Erfahrungen in den Bereichen Veranstaltungen, Solartechnik, Automotive, Government, medizinische Fortbildung.

Langer, Constanze Constanze Langer ist seit Oktober 2012 Professorin für Visual Interface Design am Fachbereich Design der Fachhochschule Potsdam. Ihre Forschungsschwerpunkte sind crossmediale und kollaborative Nutzungsprozesse im Kontext von Digitalisierung & Globalisierung. Zuvor war sie drei Jahre als wissenschaftliche Mitarbeiterin im Interaction Design an der Hochschule Magdeburg-Stendal (Institut Industrial Design) und im weiterbildenden Studiengang M.A. Cross Media tätig. Wenn sie nicht arbeitet, fährt sie Rennrad.

Limbach, Tobias Tobias Limbach ist Team Manager User Experience bei der User Interface Design GmbH (UID). Als Leiter nationaler und internationaler Projektteams verfügt er über langjährige Erfahrung bei der Durchführung länderübergreifender User-Research-Studien. Er hat zudem mehrere Forschungsprojekte rund um AAL geleitet.

Lorenzen-Schmidt, Olde Olde Lorenzen-Schmidt ist Inhaber von mind-centric und Berater für Customer- & User- Experience Management, Research und Branding. Nach dem Studium der Psychologie, Soziologie und Erziehungswissenschaft und Stationen als UX Experte bei dem Hamburger Institut GfK SirValUse und als Leiter des international angelegten Tablet-PC User Research für Microsoft Deutschland, war er über fünf Jahre für das UX Management bei der comdirect bank AG verantwortlich. Als Research Director leitete er bei der implicit diagnostics & solutions GmbH Forschungsprojekte zum Kommunikations- und Produktdesign mit neuropsychologischen Schwerpunkten u.a. in den Bereichen TK, Automotive und Banking.

Autoren

475

Magin, Dominik Pascal Dominik Magin ist seit zwei Jahren wissenschaftlicher Mitarbeiter am Fraunhofer IESE. Er arbeitet im Bereich User Experience und Mobile und besitzt mehrjährige Erfahrung in der iOS- und Web-Entwicklung.

Mathis, Katrin Katrin Mathis arbeitet seit Abschluss ihres Bachelors of Science in Online Medien als User Experience Konzepterin für digitale Medien. Als freiberufliche Beraterin hilft sie Unternehmen, ihr Angebot besser auf die Bedürfnisse der Kunden auszurichten. Berufsbegleitend absolviert sie ein MBA-Studium in Service Innovation and Design in Finnland.

Meier, Sebastian Sebastian ist wissenschaftlicher Mitarbeiter und Dozent im Interaction Design Lab im Fachbereich Design der Fachhochschule Potsdam. Seine Forschungsinteressen liegen im Bereich User Experience Design, Interaction Design und Geovisualisierung. Zur Zeit arbeitet Sebastian an seiner Doktorarbeit.

Mengel, Julian Julian Mengel ist User Experience Designer bei der Micromata GmbH. Er arbeitet seit 2001 mit wechselnden Schwerpunkten als UI- und UX Designer. Sein Fokus liegt auf Konzeption und Design von komplexen Webapplikationen und Apps im Bereich Energiemanagement, Automotive und Logistik.

Mexin, Yevgen Yevgen Mexin studiert Informatik an der Universität Paderborn im Masterstudiengang und unterstützt das Zentrum Musik-Edition-Medien seit 2015 als studentische Hilfskraft.

476

Autoren

Meyer, Herbert A. Dr. Herbert A. Meyer war von 1988 bis 2000 als Experimentalpsychologe in der Forschung tätig. Seit 2001 arbeitet er bei artop im Arbeitsbereich Usability/User Experience und ist u.a. Dozent bei der Ausbildung zum Professional für Usability und User Experience. Seit 2010 betreut er als Lehrbeauftragter ein Blickbewegungslabor an der Hochschule für Technik und Wirtschaft Berlin (HTW).

Molle, Michael Leiter R&D bei Sipos Aktorik GmbH

Müller, Peter R&D, Sipos Aktorik GmbH

Nagel, Wolfram Wolfram Nagel arbeitet als Designer und Konzepter bei der SETU GmbH (ehemals digiparden). Als Head of Design ist er für Konzeption und Gestaltung verantwortlich und betreut interne und externe Webund Software-Projekte in den Bereichen Content Design, UI Architektur und Visual Design im engen Austausch mit Frontend- und Backend-Entwicklern. Auf der UP15 stellt er verschiedene Herangehensweisen, Methoden und Prozesse für Multiscreen-Projekte vor und beschreibt wie sich die beteiligten Disziplinen zukünftig entwickeln könnten.

Autoren

477

Nass, Claudia Claudia Nass ist ausgebildete Industrie- und Grafikdesignerin. Seit 2001 beschäftigt sie sich mit Interaktionsdesign und seit 2006 arbeitet Claudia Nass im Bereich User Experience in verschiedenen Forschungs- und Industrieprojekten mit der Entwicklung von GUIs und NUIs. Davor beschäftigte sich Claudia Nass mit der Entwicklung und dem Prototyping von Benutzerschnittstellen für europäische und lateinamerikanische Märkte.

Niemann, Saskia usability.de, Hannover

Niklas, Susanne Dr. Susanne Niklas ist seit Juni 2013 bei der eResult GmbH als Senior User Experience Consultant am Standort Frankfurt tätig. Neben der Konzeption und Umsetzung verschiedener Studien und Testings betreut sie zudem als Produktmanagerin die methodische Weiterentwicklung quantitativer Analyseverfahren. Darüber hinaus gilt ihr Interesse den Entwicklungen, Einsatzszenarien und -möglichkeiten mobiler Lösungen im Consumer und Enterprise Bereich sowie entsprechender Akzeptanzfaktoren.

Oetter, Prof. Claus Prof. Claus Oetter beschäftigt sich seit 14 Jahren als stellvertretender Geschäftsführer des VDMA-Fachverbands Software sowie Leiter des Forums IT@Automation mit Themen wie Usability/User Experience und App-Entwicklung im industriellen Umfeld. Er ist Professor an der University of Applied Sciences Frankfurt, Fachbereich Informatik und Ingenieurwissenschaften mit dem Schwerpunkt Softwareengineering.

478

Autoren

Olschner, Dr. Siegfried Als Mitglied des User Research-Teams der DATEV eG Nürnberg. führt er vor allem User Research-Projekte, Methoden-Beratungen und Methoden-Weiterentwicklungen durch. Er beschäftigt sich u.a. mit Fragen zur Verbesserung und Effizienzsteigerung von Datenerhebungen und mit Prozessfragen, die die Integration der UXErgebnisse in den Entwicklungsprozess betreffen. Ein zentraler Arbeitsschwerpunkt ist momentan der Aufbau von RemoteTestverfahren.

Paule, Patricia Patricia Paule ist seit 2011 Studentin der Medieninformatik und Medienwissenschaft an der Universität Regensburg. Im Rahmen des Studiums kam sie erstmals mit den Bereichen HCI, Usability Engineering und UX(-Design) in Berührung. Studienbegleitende Projekte in Kooperation mit externen Auftraggebern dienten dem Sammeln praktischer Erfahrung und motivierten zur Teilnahme an der MuC 2014 als Student Volunteer. Vom Herbst 2014 bis Frühjahr 2015 absolvierte sie ein Praktikum bei der Audi AG wo sie nun im Kontext Usability und UX ihre Abschlussarbeit verfasst, um anschließend ihr Masterstudium in den genannten Bereichen aufzunehmen.

Petrovic, Kostanija Kostanija Petrovic, Dipl.-Psychologin, arbeitet als Product Owner, HERE.com bei HERE, a Nokia business in Berlin. Zuvor arbeitete Sie als Senior Manager User Insight bei Nokia, wo sie kontinuierliche Produktvalidierung als Teil des Entwicklungsprozesses etabliert hat. Derzeitige Schwerpunkte sind Produktdefinition und Produktentwicklung im Rahmen eines agilen Entwicklungsprozesses. Wenn es die Zeit erlaubt, hält sie Praxisvorträge an Hochschulen über die Integration von User-centered Design in die Softwareentwicklung. Kostanija Petrovic ist seit September 2010 Präsidentin der German UPA e.V., wo sie sich seit 2006 ehrenamtlich engagiert.

Autoren

479

Pfaff, Fabian Fabian Pfaff studiert Informationsdesign im 6. Semester an der Hochschule der Medien in Stuttgart. Seinen persönlichen Schwerpunkt legt er hier auf nutzerzentrierte Gestaltung, Medienpsychologie und anwendungsorientierte Forschung. Nach seiner Ausbildung zum Mediengestalter für Digital- und Printmedien mit Schwerpunkt Webdesign in Mainz (2008) arbeitete er im Rhein-Main-Gebiet als Screendesigner und Junior Art Director. Seit März 2015 unterstützt er als Werkstudent das User Experience Team bei Phoenix Design in den Bereichen Automotive und Consumer Electronics.

Polkehn, Knut Seit mehr als 15 Jahren ist der Psychologe als Partner und Berater bei artop – Institut an der Humboldt-Universität zu Berlin in Analyse, Design und Evaluation interaktiver Systeme sowie in der Weiterbildung von Usability Professionals tätig. Als systemischer Komplementärberater bildet die Begleitung von Veränderungsprozessen durch Training, Mentoring, Moderation sowie verschiedene Formen von Fach- und Prozessberatung einen weiteren Schwerpunkt seiner Tätigkeit. Knut Polkehn bringt seine Expertise in Arbeitskreisen der German UPA, im Vorstand des UXQB e.V. sowie im DIN Normenausschuss „Benutzungsschnittstellen“ ein.

Preßler, Jan Jan Preßler hat Mensch-Computer-Systeme an der Universität Würzburg studiert. 2012 hat er noch im Studium bei der nobiscum GmbH im Bereich Usability angefangen zu arbeiten und wechselte 2013 zur Agentur CaderaDesign in Würzburg. 2013 war er zusätzlich als wissenschaftliche Hilfskraft in Würzburg am Lehrstuhl für Psychologische Ergonomie eingestellt. Er konzipierte mit Prof. Dr. Jörn Hurtienne unter anderem die Lehrveranstaltung „Mobile User Experience Design“. Jan war als Gastautor an dem Buch UX Design für Tablets beteiligt. Bei CaderaDesign ist er inzwischen als Usability Engineer angestellt. Nebenbei arbeitet er aktuell an einer eigenen Gründung eines Projekts bzw. Social Startups, welches sich zum Ziel gesetzt hat das bürgerliche Engagement u.a. mit UX-Methoden und Softwareeinsatz zu vereinfachen und zu fördern. Seit 2012 ist er als Unterstützung bei der Summer School der gUPA dabei.

480

Autoren

Proschek, Katrin Seit 1997 im Bereich Medien an der TH Nürnberg tätig und seit der Gründung 2006 im Usability Engineering Center. Zuständig für die Organisation der Industriekooperationen. Arbeitsschwerpunkt: Usability Evaluation.

Raithel, Ulrich Software Entwickler, Sipos Aktorik GmbH

Reitz, Thore

!

Thore Reitz studierte „Human Technology“ an der Hanze University of Applied Sciences Groningen, Niederlande. Während dieses interdisziplinär angelegten Studienganges mit dem Schwerpunkt der nutzerzentrierten Produktentwicklung konnte er bereits praktische Erfahrung im Bereich Usability und Human Factors Engineering sammeln. Derzeit arbeitet er bei der Use-Lab GmbH im Bereich des Human Factors Engineering und ist in verschiedenen Projekten wie Anforderungsanalysen, Usability Tests aber auch Dokumentation des Usability Engineering Prozesses tätig.

Riedemann, Catharina Catharina Riedemann, Diplom-Geographin, arbeitet seit 1997 im Usability-Umfeld. Seit 10 Jahren ist sie als Usability Specialist bei Olympus Soft Imaging Solutions tätig und unterstützt Projekte von der Anforderungserhebung bis zur Evaluierung, mit Schwerpunkten auf Requirements Engineering, Styleguides und Usability-Tests. Davor war sie wissenschaftliche Mitarbeiterin am Institut für Geoinformatik der Universität Münster, wo sie heute als externe Lehrbeauftragte nutzerzentrierte Entwicklung unterrichtet.

Autoren

481

Rieß, Henrik Henrik Rieß ist Creative Director bei der User Interface Design GmbH (UID) am Standort Berlin. Seit 2012 befasst er sich mit der User Experience vernetzter Produkte aus den Bereichen Heimautomation und Ambient Assisted Living. Neben direkten Kundenprojekten arbeitet der Industrial und Interaction Designer im Bereich UID Research vernetzt mit Forschungseinrichtungen an Innovationsthemen wie dem Internet der Dinge und der emotionalen Erfahrbarkeit digitaler Produkte.

Rösler, Alexander Alexander Rösler ist User Experience Consultant und Eye Tracking Experte bei usability.de. Als Projekt- und Testleiter in verschiedensten Usability-Projekten unterstützt er Unternehmen dabei, ihre Produkte einfach und intuitiv bedienbar zu gestalten. Des Weiteren ist Alexander Lehrbeauftragter für Mensch-Maschine-Interaktion an der Universität Hildesheim.

Rößler, Tatiana Tatiana Rößler studierte Wirtschaftsinformatik an der Wjatkaer staatlichen Universität in Kirov, Russland. Anschließend hat sie ihren Masterabschluss in Informationswirtschaft am Karlsruher Institut für Technologie (KIT) erworben. Seit Februar 2014 ist sie als wissenschaftliche Mitarbeiterin am Institut für Arbeitswissenschaft der TU Darmstadt tätig. Im Rahmen des BMWI-Projektes PUMa (Projekt Usability in Mittelstandsanwendungen) beschäftigt sie sich insbesondere mit der Integration von Usability und User Experience in die Softwareentwicklungsprozesse von KMU.

Rost, Dominik Dominik Rost ist seit sechs Jahren wissenschaftlicher Mitarbeiter am Fraunhofer IESE; angewandte Forschung und Industrieberatung im Bereich Design, Dokumentation und Bewertung von Softwarearchitekturen für Informationssysteme.

482

Autoren

Rougk, Sabine Sabine Rougk ist Psychologin und seit 2012 in Usability/UX-Projekten bei artop tätig. Als Teil des interdisziplinären Teams begleitet sie mit dem systemischen Ansatz als Mindset und ihren analytischen Fähigkeiten Praxis- und Forschungsprojekte. Mit Schwerpunkt auf Industrie- und Dienstleistungsunternehmen liegen ihre Tätigkeiten hauptsächlich in den Bereichen User Research und Analyse, ExpertenEvaluation sowie qualitatives Usability Testing. Sie versteht sich nicht nur als Usability Dienstleister sondern viel mehr als Beraterin, die in Projekten strukturiert auf die Bedürfnisse aller Stakeholder eingeht.

Rummel, Bernard Bernard Rummel arbeitet seit mehr als 20 Jahren im Arbeitsfeld Ergonomie, Gebrauchstauglichkeit und Interaktionsdesign. Seit 2011 beschäftigt er sich bei SAP mit der Quantifizierung von Gebrauchstauglichkeit und UX Benchmarking. Als Diplom-Psychologe hat er zu diversen UX-Themen gearbeitet und publiziert, so zu Weiterbildung, Etablierung von Usability Engineering und Praxis der betrieblichen Standardisierung im Design. Er arbeitet weiterhin im DIN-Normenausschuss Ergonomie – Benutzungsschnittstellen an Designstandards wie z.B. der Normenreihe DIN EN ISO 9241 und seit 2014 als UXQB-Fachprüfer für Usability Testing.

Schäfer, Johannes Johannes Schäfer kennt als Informatiker und Psychologe beide Seiten der Mensch-Maschine-Interaktion von Grund auf. Er arbeitet seit 15 Jahren im Bereich User-Centered Design als Usability Engineer, Interaction und User Experience Designer. Als Projekt- und Teamleiter hat er praktische Erfahrung in vielen Projekten unter anderem in den Branchen Investitionsgüter, Medizintechnik, Unterhaltung und Unternehmenssoftware sowie verschiedenen Forschungsprojekten.

Schering, Sandra Sandra Schering hat sich durch ihr Studium der „Angewandten Kognitions- und Medienwissenschaft“ auf die Themenfelder Usability, User Experience und Mensch-Computer-Interaktion spezialisiert und dieses Wissen in verschiedenen Forschungsprojekten aktiv angewendet. Seit 2014 arbeitet sie bei der itemis AG als Usability Engineer und beschäftigt sich in diversen Projekten mit der Verbesserung der Gebrauchstauglichkeit von Softwarelösungen, unter anderem im Bereich Smart Home.

Autoren

483

Scherz, Ronja Ronja Scherz studiert Medieninformatik an der Hochschule Trier, Standort Umwelt-Campus Birkenfeld. Ihre Studienschwerpunkte liegen dabei im Bereich Human Computer Interaction und 3D-Modellierung. Seit September 2013 arbeitet sie als 3D Design Engineer bei der Centigrade GmbH. Zu ihren Hauptaufgaben zählen die Entwicklung von intuitiv bedienbaren 3D Anwendungen mit Unity3D und die Evaluierung neuer Interaktionsmöglichkeiten im Bereich Virtual Reality.

Schlemper, Holger Holger Schlemper studierte Kommunikations-Design an der Georg Simon Ohm Hochschule Nürnberg. Aktuell ist er an der Technischen Hochschule Nürnberg als wissenschaftlicher Mitarbeiter im Usability Engineering Center beschäftigt. Zu seinen Hauptaufgaben zählen Interaktions- und Interface-Design.

Schmid-Wohlleber, Bernhard Seit 1998 ist Bernhard Schmid-Wohlleber Professor für Grundlagen der Gestaltung an der Hochschule Magdeburg Stendal. Zwischen 1993 und 1997 lehrte er an der Hochschule für Gestaltung, Technik und Wirtschaft in Pforzheim und gründete 1992 gemeinsam mit Anette Wohlleber das Designbüro DESIGN 4 EYES. Zwischen 1989 und 1992 arbeitete er als Design Manager bei frogdesign. Seine Lehre in Magdeburg verknüpft Produkt Design, Modellbau und Interaction Design in einem gesamtheitlichen Gestaltungsprozess.

Schmitt, Hartmut Koordinator Forschungsprojekte bei der HK Business Solutions GmbH und Gesamtprojektleitung PQ4Agile; seit 2006 Verbundvor-haben im Umfeld Mensch-Computer-Interaktion, Usability / User Experience und Software-Engineering.

Schneider, Maximilian Maximilian Schneider ist Mitarbeiter im Forschungsvorhaben "KOMET - Kompetenzzentrum für die Etablierung von Usability in KMU und Schaffung von nutzerzentrierten Vorgehensmodellen" an der Hochschule für Technik und Wirtschaft Berlin (HTW).

484

Autoren

Schneidermeier, Tim Tim Schneidermeier ist seit 2015 Senior User Experience Designer bei der USEEDS GmbH. Zuvor arbeitete er fünf Jahre als Wissenschaftlicher Mitarbeiter am Lehrstuhl für Medieninformatik der Universität Regensburg. Dort vertrat er die Themen Usability Engineering und User Experience Design in Lehre und Forschung. Zudem war er von 2011 bis 2014 teilhabender Geschäftsführer der small worlds GbR, einem Spin-Off der Medieninformatik der Universität Regensburg: Erfahrungen aus Forschung und Praxis werden hier zusammengebracht und bilden die Grundlage für die Arbeit als Usability Consultant.

Schön, Eva-Maria Eva-Maria Schön ist in diversen Projekten an der Schnittstelle zwischen Business und IT tätig. Sie sammelt seit 2010 praktische Erfahrungen im Bereich User Experience. Als PhD Researcher der University of Seville beschäftigt sie sich wissenschaftlich mit Agilen Vorgehensmodellen und Human-Computer Interaction. Ihre Erkenntnisse fließen in ihre Arbeit als Business Consultant ein. Sie arbeitet vorrangig in agilen Projekten, die sich mit der Entwicklung von Individualsoftware beschäftigen.

Schrepp, Martin Dr. Martin Schrepp studierte Mathematik und Psychologie an der Universität Heidelberg. 1990 Abschluss als Diplom-Mathematiker. 1990 – 1993 Promotion in Psychologie. Seit 1994 bei der SAP AG tätig. Bisherige Tätigkeitsfelder waren hier die Konzeption technischer Dokumentation, Software-Entwicklung, User Interface Design und Barrierefreiheit. Hauptinteressen sind die Anwendung kognitionswissenschaftlicher Erkenntnisse auf das Design interaktiver Anwendungen, Barrierefreiheit und die Entwicklung von Methoden zur Evaluation und Datenanalyse.

Schröter, Jan Jan Schröter studierte B.A. Industrial Design und anschließend M.A. Interaction Design an der Hochschule Magdeburg-Stendal. Im Anschluss arbeitete er bei Phoenix Design hauptsächlich im Bereich Visual Interface Design. Aktuell ist er bei der Audi AG als GUIDesigner tätig.

Autoren

485

Schubert, Ulf Ulf Schubert ist Leiter User Experience bei DATEV eG in Nürnberg. Er verantwortet neben der Produktdesign-Strategie der DATEV auch die Themen User Experience Design, User Research, Requirements Engineering und UI Pattern Development. Er berichtet in seinem User Experience Blog über Neuigkeiten der Branche und den Erfahrungen aus seiner täglichen Arbeit (www.ux-blog.de).

Schuster, Sandra Nach Ausbildung zum IT-Professional an der it akademie bayern, studierte Sandra Schuster Soziologie und Marktund Werbepsychologie an der LMU München. Schon während des Studiums etablierte sie den Forschungsschwerpunkt „Usability“ in der Münchner Marktforschungsagentur up2date und leitete diesen bis 2008 als Methoden- und Projektverantwortliche. 2009 übernahm sie die Projektleitung für die Entwicklung standardisierter Qualitätssicherungssysteme im Gesundheitswesen bei der medicaltex GmbH. Seit 2010 ist sie bei der facit digital GmbH in München tätig und betreut dort schwerpunktmäßig Kunden aus dem Bereich Gesundheit und Automobil. Außerdem verantwortet sie inhaltlich und strategisch die Positionierungsfelder „Mobile UX“ und „Lean Back UX“.

Schuster, Sarah Dipl. Kffr. Sarah Schuster ist aktuell Leiterin Performance Management Analysen & Strategie bei der Kabel Deutschland Vertrieb und Service GmbH. Vorher war Sie im Bereich Unternehmens- und Strategie-Beratung als Engagement Manager bei McKinsey tätig. Fokus ihrer Expertise im Projekt war das Overall-Management, das Controlling und die Prozessgestaltung sowie das multinationale SchnittstellenManagement aller Stakeholder im vorgestellten Service-DesignProjekt.

486

Autoren

Sönksen, Malte Malte Sönksen, Psychologe und Industrietechnologe, ist seit 2010 in Usability/UX-Projekten als Berater und Dozent tätig. Seine Arbeitsschwerpunkte liegen im Bereich Analyse und Spezifikation aller Stakeholderanforderungen an interaktive Produkte und Services, Experten-Evaluation und Usability Testing sowie in der Beratung und im Training zu Methoden und Prozessen rund um das HCD. Maßgeschneidert und Hand in Hand mit dem Auftraggeber Herausforderungen zu analysieren, Lösungen zu entwickeln und diese zu evaluieren ist für ihn nicht nur Ansatz der menschzentrierten Gestaltung, sondern spiegelt auch seine Haltung in Beratung und Ausbildung wieder.

Stalph, Joachim Joachim Stalph ist Senior Consultant bei elaboratum – New Commerce Consulting. Seine Spezialgebiete sind Projektmanagement und Konzeption für E-Commerce- und Cross-Channel-Anbieter. Er ist Artop-zertifizierter Usability Consultant und PMI-zertifizierter Projectmanagement Professional (PMP). Er arbeitet seit 10 Jahren im Online- und E-Commerce-Umfeld und war zuletzt als Projektleiter und Konzeptioner in verschiedenen Digitalisierungs- und Relaunch Projekten in unterschiedlichen Branchen (u.a. Telco, Versicherung, Handel) unterwegs.

Strusch, Andreas Andreas ist Senior Product Manager mit Schwerpunkt Online Services bei SMA Solar Technnology AG. Von 1996-2002 als Bankkaufmann für die Commerzbank AG tätig. Ab 2002 selbstständig mit einem Multiplayer-Online-Portal für eSport. Konzeption, Gestaltung und Betrieb diverser Onlineangebote u.a. für Trading Cards und Websitevermarktung. 2004-2007 Produktmanager bei easyCredit in Nürnberg mit Fokus Preismanagement und Analysen. Seit 2008 im Produktmanagement bei SMA verantwortlich für Apps, mobile Seiten und Portale für Commercial & Residential O&M Lösungen sowie Smart Grid Cloud Services.

Autoren

487

Szwillus, Gerd Prof. Szwillus arbeitet seit Jahren im Bereich Mensch-ComputerInteraktion am Institut für Informatik der Fakultät für Elektrotechnik, Informatik und Mathematik der Universität Paderborn. Zu den Schwerpunkten von Prof. Szwillus gehören Konzepte zur Modellierung von User Interfaces und Entwicklung zugehöriger unterstützender Werkzeuge, in jüngster Zeit auch die Entwicklung von Anwendungen gestenbasierter Interaktion.

Thölke, Michaela Michaela Thölke ist Senior User Experience Consultant bei usability.de. Zuvor hat sie über 10 Jahre in verschiedenen Softwareunternehmen im medizinischen Bereich eine Schnittstellenfunktion zwischen Entwicklern und Nutzern wahrgenommen. Ihr Fokus liegt auf dem Bereich User Research und UX Evaluation sowie auf der Durchführung von Workshops und der strategischen Verankerung von Usability in Unternehmen. Als Projektleiterin in komplexen Software-Entwicklungs-Projekten sorgt Sie dafür, dass das Thema Usability ausreichend Berücksichtigung findet.

Thom, Andreas Andreas ist wissenschaftlicher Mitarbeiter im Interaction Design Lab(IDL) im Fachbereich Design der Fachhochschule Potsdam. Er ist seit mehr als 6 Jahren im Bereich Usability / User Experience tätig. Seine Forschungsinteressen liegen überwiegend in den Bereichen Human-Computer-Interaction, User Experience Design und Interaction Design.

Thomaschewski, Jörg Dr. Jörg Thomaschewski ist Professor für Internetanwendungen an der Hochschule Emden/Leer mit den Lehr- und Forschungsschwerpunkten Human Computer Interaction, E-Learning, Softwaretechnik. Er ist Autor verschiedener Online-Module, u.a. „Mensch-ComputerKommunikation“, das im Rahmen der Virtuellen Hochschule (VFH) an sechs Hochschul-Standorten eingesetzt wird. Er verfügt über umfangreiche Erfahrungen in Usability-Schulungen, Analysen und Beratungen.

488

Autoren

Toussaint, Claude Claude Toussaint arbeitet seit 1999 bei der designaffairs GmbH und hat dort den Bereich Interface Design aufgebaut. Seit März 2007 ist er einer der vier Inhaber und Geschäftsführer der designaffairs GmbH. Er ist für das interdisziplinäre Interface-Team verantwortlich und betreute Projekte für Kunden wie Porsche, MAN, Opel, Siemens, Bosch, DATEV oder RWE. Neben seiner Tätigkeit als Geschäftsführer ist er regelmäßig als Gastdozent an der HTA Luzern und als Referent auf internationalen Kongressen tätig. Claude Toussaint veröffentlichte zahlreiche Beiträge zu User Interface Design in Zeitschriften und Buchbeiträgen.

Tretter, Stefan Stefan Tretter ist Masterstudent des Studiengangs Wirtschafts-, Organisations- und Sozialpsychologie der Ludwig-MaximiliansUniversität München. Er arbeitet als wissenschaftliche Hilfskraft am Lehrstuhl für Wirtschafts- und Organisationspsychologie sowie dem LMU Center for Leadership and People Management. Seine Forschungsinteressen liegen im Bereich der Konsumentenpsychologie und des Nutzererlebens.

Uebel, Benjamin Benjamin Uebel ist Gründer und Geschäftsführer von RapidUsertests.com. Er ist seit 2007 als Usability-Berater tätig und gehört zu den Pionieren des Crowd-Testings in Deutschland. Er war als wissenschaftlicher Mitarbeiter der Technischen Universität Berlin tätig und ist Autor in diversen Fachmagazinen. Er hat einen Lehrauftrag in Software-Ergonomie an der HTW-Berlin.

Uhlenbrok, Jan Jan Uhlenbrok ergänzte sein Medieninformatik-Studium 2010 um eine Weiterbildung zum zertifizierten Usability Engineer am Fraunhofer Institut. Nach Projektmanagement und Teamleitung in einem regionalen Medienhaus arbeitet er nun hauptverantwortlich als Produktmanager für digitale Verlagsprodukte. In allen digitalen Bereichen arbeitet er agil mit Kanban.

Autoren

489

Ullmann, Christine Christine Ullmann hat Psychologie an der Universität Hamburg studiert. Nach ihrer Diplomarbeit bei der Daimler AG hat sie als User Experience Consultant für Infotainment-Systeme im AutomotiveBereich gearbeitet. Im Anschluss war sie für die Audi AG tätig, unter anderem als Teamkoordinator für Konzeptsimulationen und als Senior UX Designer in der Vorentwicklung. Aktuell arbeitet sie freiberuflich als UX Consultant in Australien.

Ullrich, Daniel Daniel Ullrich ist Post-Doc an der Ludwig-Maximilians-Universität München im Bereich Mensch-Maschine-Interaktion des Instituts für Informatik. Seine Forschungsschwerpunkte sind intuitive Interaktion mit technischen Produkten sowie Interaktionsgestaltung und wahrnehmung in den Bereichen Automotive und Human-RobotInteraction.

Wack, Karl-J. Gründer und Geschäftsführer des Dienstleistungsunternehmens für mobile App Entwicklung let’s dev GmbH & Co. KG. Seit mehreren Jahren beschäftigt er sich insbesondere mit mobile UX und ist Experte in der Konzeption und Realisierung von mobilen Applikationen.

Walorska, Agnieszka M. Agnieszka M. Walorska ist Gründerin und Geschäftsführerin der digitalen Innovationsagentur Creative Construction Heroes. Seit gut 10 Jahren beschäftigt sie sich beruflich mit den digitalen Themen und hat dabei vor allem die Nutzer im Blick. Als eine der ersten Mitarbeiterinnen von studiVZ war Agnieszka in Führungsposition maßgeblich am erfolgreichen Wachstum des Social Networks beteiligt. Sie ist Autorin von Fachpublikationen und Sprecherin zu den Themen User Experience und digitale Innovation und führte mehrere erfolgreiche UXund Innovationsprojekte u.a. für Energieunternehmen, Banken und Medienhäuser. Sie studierte Sozialund Politikwissenschaften an der Universität Warschau und der Humboldt-Universität Berlin und war Stipendiatin der Hertie-Stiftung und der Studienstiftung des Deutschen Volkes.

490

Autoren

Wawilow, Anastasia Anastasia Wawilow studierte Informatik an der Universität und unterstützt das Zentrum – Musik – Edition – Medien seit 2015 als wissenschaftliche Mitarbeiterin. Ihre Schwerpunkte liegen im Umfeld der Softwareentwicklung mit Fokus auf Mensch-Computer-Interaktion.

Weber, Astrid Astrid Weber arbeitet als UX Researcher im Google Headquarter in Mountain View, Kalifornien. Seit 2013 betreut Astrid den Bereich Accessibility UX Research innerhalb des zentralen Accessibility Engineering Teams, das zum Bereich Research & Machine Learning zählt. Astrids Fokus liegt auf der Erforschung von sprachgesteuerten Interfaces und deren Usability.

Weber, Markus Dr. Markus Weber leitet den Bereich Usability Engineering der Centigrade GmbH. Er studierte Psychologie an der Universität des Saarlandes, wo er auch mit einer Arbeit zum Thema Eye Tracking im eLearning Kontext promovierte. In seiner Rolle als Usability Engineer befasst er sich unter anderem mit agilen Usability Prozessen und der effizienten Kooperation von Usability Engineers, User Interface Designern und Entwicklern. Seine Tätigkeiten beinhalten die strategische Planung und Durchführung von Anforderungsanalysen, Usability Evaluationen und Interaktionsdesigns, die er in einer Vielzahl von Projekten in verschiedensten Branchen durchführte. Außerdem ist er aktiver Blogger und Twitterer und trägt regelmäßig zu Fachkonferenzen im UX Umfeld bei.

Winter, Dominique Dominique Winter arbeitet als Senior Produktmanager bei der Buhl Data Service GmbH. Seine derzeitigen Schwerpunkte sind User Experience Design und Softwarekonzeption im Bereich Vereinsmanagement. Zuvor war er bei der GreenPocket GmbH verantwortlich für die Webportale im Bereich Smart Metering und Smart Home. Davor war er an der Universität zu Köln in verschiedenen DFG- und EU-Projekten verantwortlich für Softwarekonzeption, Barrierefreiheit und Usability-Engineering. Zudem ist er Mitglied einer Forschungsgruppe der HS Emden/Leer und beschäftigt sich hauptsächlich mit der Vereinbarung von User Experience, Innovationsmanagement und Produktmanagement.

Autoren

491

Wohlgemuth, Volker Prof. Dr. Volker Wohlgemuth ist Hochschullehrer an der HTW Berlin für die Gebiete Stoffstrommanagement, Modellbildung und Simulation sowie Anwendung und Entwicklung betrieblicher Umweltinformationssysteme (BUIS). Er hat das KOMET-Projekt initiiert und leitet es.

Wüst, Steffen Steffen ist seit 2006 Senior Consultant und Projektleiter bei der chilli mind GmbH und dort schwerpunktmäßig für die Bereiche Strategie-, Produkt- und Geschäftsmodellentwicklung, Usability und User Experience zuständig. Sein Projektfokus liegt auf den Bereichen Healthcare, erneuerbare Energien, Telekommunikation und elektronische Haustechnik. Nach seiner Ausbildung als Goldschmied und mehreren Jahren Berufserfahrung im In- und Ausland studierte Steffen Produktdesign mit Schwerpunkt Systemdesign an der Universität Kassel.