Issuu on Google+

2013 Usability Professionals German UPA e. V. LeitzstraĂ&#x;e 45 | 70469 Stuttgart www.germanupa.de

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

Usability Professionals 2013


Sponsoren

Konferenzsponsoren

users´

German UPA Förderkreis

2

´


Inhaltsverzeichnis

Workshop 12 Papierlose Fahrgastinformation im ÖPNV: Die Vision einer Haltestelle der Zukunft

Paul Müller, Benjamin Laukenmann

16 Die Anwendung von Spielmechanismen im User Research – Level up oder Epic Fail?

Eva Rügenhagen, Theo Held

22 Erfolgreiche Usability & UX in Unternehmen Thesen und Erfolgsfaktoren zu Usability/UX-Prozessen, -Strategie und Change

Jana Löffler, Knut Polkehn, Jens Hüttner

26 Arbeitskreis ROI: Return-on-User-eXperience in a Nutshell

Boris Kneisel, Katharina Goering

28 Arbeitskreis Qualitätsstandards: „Do you speak usability?“ Aktueller Stand des Glossar und des Curriculums für den „Certified Professional for Usability and User Experience (CPUX-F)“ der German UPA

Holger Fischer, Thomas Geis, Rolf Molich, Oliver Kluge, Rüdiger Heimgärtner, Peter Hunkirchen, Knut Polkehn

36 Arbeitskreis User Research: Workshop zur Mensch & Computer 2013

Carolin Flesch, Anja Endmann

38 Arbeitskreis Medizintechnik Präsentation: Leitfaden Medical Usability

Tobias Walke

44 Arbeitskreis Inhouse: Interviewleitfaden Usability Prozessreife

Natalie Woletz, Berit Leiking, Desdemona Strauß, Jan-Hendrik Spieth, Nicole Charlier

3


Tutorial 50 Qualitätsmanagement nach ISO 9001 im UX Engineering – Ein Ansatz auf Basis des Qualitätsstandards der German UPA

Henning Brau

54 Von der Nutzungsanforderung bis zur formalen Software­spezi­fi­ kation – Modellieren mit dem Werkzeug YAKINDU Requirements

Florian Geyer, Jens Trompeter, Michael Jendryschik

60 Bummler und Schummler – wie effizient ist mein UI wirklich? Bear­ beitungszeiten analysieren und verstehen mit Probability Plots

Bernard Rummel

66 Schätzen der User Experience – Von der Möglichkeit die UX bereits im Produktplanungsprozess zu erheben

Dominique Winter, Jens Pietschmann

72 User Experience mit Fragebögen messen – Durchführung und Auswertung am Beispiel des UEQ

Maria Rauschenberger, Martin Schrepp, Jörg Thomaschewski

78 Durch schnelles Scheitern zum Erfolg: Eine Frage des passenden Prototypen?

Kirstin Kohler, Thorsten Hochreuter, Sarah Diefenbach, Eva Lenz, Marc Hassenzahl

Cross Plattform UX 86 Jenseits mobiler Anwendungen: Telekommunikation trifft Super Natural Interaction – Von SMS bis M2M

Sascha Wolter

92 Mobile User Experience Pattern. Konsistente UX für Android, iOS und Windows Phon

4

Steffen Hess, Felix Kiefer


Usability Professionals 2013 Inhalt

Inhouse & Zulieferer Kooperation 98 UX, UCD, HMI and CAI – customer agency interaction – Pitch-Usabilitytest-Erfahrungen aus Auftraggebersicht

Katja Busch, Vicky Zander

104 Customer-generated Prototypes. Chancen und Herausforderungen von durch Kunden erstellte Prototypen für Usability Consultants

Tim Schneidermeier, Markus Heckner

110 UX „Wir kaufen Usability ein“ – Ein nutzerzentrierter Erfahrungsbericht

Markus Weber, Sandra Köpf

Responsive UX 116 Responsive Design – a whole new world?

Joachim Stalph

122 Responsives User Interface Design – Wirkungsvolles Mittel gegen zunehmende Gerätefragmentierung?

Nicolas Leyking, Jan Grönefeld, Markus Kühner

130 Herausforderungen für UX-Teams in „Responsive Design”-Projekten im agilen Kontext. Ein Beispiel für die Zusammenarbeit im Projektalltag von mobile.de

Michael Fleck, Stephan Köpp

UX Best Practices 138 Best Practice Tele-Medizintechnik Total-User-ExperienceDesign für ein gesamtheitliches Blutzuckermess-System

Oliver Gerstheimer

5


146 Travel Experience – Interaktive Technologien für positive Erlebnisse in der Transportphase des Reisens

Michael Burmester, Ralph Tille

152 Das Geheimnis der Hilfefunktion. Möglichkeiten und Potenzial für sinnvolle Hilfe-Konzepte

Natalie Oster, Markus Kühner, Jan Groenefeld

Industrie UX 162 Interfacekonzept für einen „Role Based Client“ als Anwendung im gesamten Produktlebenszyklus

Ralph Tille, Michael Burmester

170 „Time = Money“: User-Interface-Konzept zur zeiteffizienten Auslegung komplexer Solaranlagen

Oliver Gerstenheimer

180 Human Centered Design für Prozessleitsysteme in der Industrieautomation

Peter Hartmann, Maike Petzold

User Research 188 Feldstudien in der iterativen Anwendungsentwicklung

Dr. Markus Wienen, Dr. Rolf Schulte Strathaus

194 Experience Tagebücher: Potentiale und Einschränkungen der Methode sowie Gesetzmäßigkeiten für den richtigen Einsatz

Angelika Kunz, Ulrike Gruber, Markus Murtinger, Manfred Tscheligi

200 Lean Experiments: Die Rolle von Interaction Design und UX Research im Lean Startup Ansatz

6

Sascha Mahlke, Lars Giere, Silvia Kleine Hörstkamp, Sebastion Hoos, Sirin Cepkenli


Usability Professionals 2013 Inhalt

UX Integration 208 Einführung von Human-Centered Design bei der adidas AG Ein Praxisbericht

Lucie Grudno, Leo Glomann

214 Die Benutzung des Styleguides für Software-Entwickler optimieren

Maria Rauschenberger,Heike Sinning,Jörg Thomaschewski

220 User Experience in Kanban

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

Spezielle Designanforderungen 226 Voice Control um jeden Preis? Theoretische und praktische Grund­lagen für erfolgreiche Sprachsteuerungs-Angebote aus User Experience-Sicht

Sandra Schuster

232 „Ich würde jetzt anrufen.“ – Webshops aus Sicht älterer Nutzer

Cornelia Schauber, Christoph Nedopil, Sebastian Glende, Tina Weisser, Christian Wedl

Enterprise / Government UX 240 „Pimp my GUI – Kosmetik allein genügt nicht“ Herausforderungen bei der Modernisierung der Benutzungsoberfläche von Unternehmenssoftware

Reiner Schlenker, Frank Patz-Brockmann

248 Willkommen auf der Achterbahn

Michael Bechinie, Peter Strassl, Markus Murtinger, Manfred Tscheligi

256 (Über-) Leben mit Anforderungen

Thom Scheiner

7


Branchentrends 264 Branchenreport UX/Usability 2013

Sarah Diefenbach, Nina Kolb, Daniel Ullrich

274 Mit Interface Design ein Markenprofil stärken

Manfred Dorn

Kurzvorträge 282 User Experience für Kinder am Beispiel der „Seite mit der Maus“

Katrin Schlierkamp, Prof. Dr. Michael Burmester

288 Eine Lernwelt für alle? Stand User Experience Design in einem Bildungsverlag

Christiane Schmidt, Maria Mory

294 Einführung eines plattformübergreifenden Bezahlmodells für DIE WELT DIGITAL Gibt es Raum für Usability-Aktivitäten bei einem agilen Vorgehen nach Scrum?

Roland Andrus

300 Usability-Methoden in der Praxis. Ergebnisse einer Umfrage zu Einsatz und Bewertung von Usability-Engineering-Verfahren

Monique Janneck, Anika Röhrich

308 Valenzen in Serious Games – Spielerisch auf neuen Wegen der UX Messung

Insa Wulf, Prof. Dr. Huberta Kritzenberger

314 Storytelling für User Experience Designer. Methoden und Beispiele für den Einsatz von User Stories im UX Design Prozess.

8

Kinga Kujat


Usability Professionals 2013 Inhalt

318 Zur Notwendigkeit anwendungsspezifischer Usability-Verfahren für betriebliche Software

Nina Bär, Susen Döbelt, Thomas Seeling, Frank Dittrich

322 Usability Testberichte gebrauchstauglicher machen

Lisa Daske

Bewusst. Unter-bewusst. Unbewusst. 330 Online Shopping mit Emotionen. Eine Usability Studie über Online-Shops mit EEG Messung

Sabrina Duda

Usability/UX Testing 342 Usability Test Ergebnisse – Eine sehr persönliche Angelegenheit.

Rolf Molich, Lisa Daske

348 User Experience Questionnaire (UEQ) Benchmark. Praxiserfahrungen zur Auswertung und Anwendung von UEQ-Erhebungen im Business-Umfeld

Martin Schrepp, Siegfried Olschner, Ulf Schubert

Referenten 356 Referenten

Impressum 385 Impressum

9


10


Workshops

11


Papierlose Fahrgastinformation im ÖPNV: Die Vision einer Haltestelle der Zukunft Konzeption neuer digitaler und interaktiver Informations­­­systeme für Fahrgäste im ÖPNV Paul Müller Agentur Siegmund GmbH Leuschnerstraße 3 70714 Stuttgart p.mueller@agentursiegmund.de

Benjamin Laukenmann Agentur Siegmund GmbH Leuschnerstraße 3 70714 Stuttgart b.laukenmann@agentursiegmund.de

Abstract Die Vision im modernen ÖPNV: Touch-Displays oder ähnliche Systeme ersetzen zukünftig die klassischen Papieraushänge an den Haltestellen – Fahrgastinformationen wie Fahrpläne und Umgebungspläne sind dann nur noch digital abrufbar. Um die Machbarkeit dieser Vision zu untersuchen, wurde 2012 bereits eine Anforderungsanalyse durchgeführt: Welche Informationen werden von den Fahrgästen wann und wie abgefragt? Was sind die wichtigsten Nutzungsszenarien? Können neue digitale Systeme wie z.B. Touch-Displays alle Szenarien zur Informationsbeschaffung für die Fahrgäste abbilden? Wie gut sind digitale Systeme für die breite Zielgruppe bedienbar? Auf Basis dieser Studie wurde ein Anforderungskatalog erstellt, der als Basis für die Konzeption einer digitalen Informationsvitrine dienen soll. Ziel des Workshops ist es, alternative oder ergänzende Informationsund Interaktionssysteme anzudenken und zu diskutieren. Hierzu werden die wichtigsten Erkenntnisse aus der Anforderungsanalyse als Grundlage in die Diskussion eingebracht.

1. Einleitung Die Idee, Fahrpläne statt auf Papier in digitaler Form anzubieten, ist momentan ein von vielen Seiten mit großem Interesse verfolgtes Thema, welches aber speziell in Deutschland erst noch im ­Aufkommen ist. Digitale Abfahrtspläne an Bushaltestellen finden sich beispielsweise bereits in Dresden oder der Region der Salzburger Seenlandschaft. Dabei handelt es sich allerdings meist um ein passives Aufnehmen von Informationen, welche mehr oder weniger von den Papieraushängen übernommen und digitalisiert wurden. Dies wäre aber beispielsweise bei der Vielzahl von Aushanginformationen einer komplexen U-Bahn-Haltestelle mit mehreren Linien nicht möglich, da sich diese so nicht auf einem einzigen Display darstellen lassen. Um alle benötigten Informationen gebündelt über ein einziges Medium verfügbar zu machen, müssten Fahrgäste diese je nach Bedarf individuell abrufen können. Realisiert werden könnte dies über ein interaktives digitales System wie beispielsweise der in New York an diversen

12

Haltestellen im Testbetrieb laufenden „On the Go! Travel Station“. Das System in New York stellt allerdings nur eine zusätzliche Informationsquelle zu den herkömmlichen Aushängen dar. Die Zukunftsvision sieht dagegen vor, alle Informationen an Haltestellen, welche bisher auf Papier verfügbar waren, nur noch digital und eventuell zusätzlich auch interaktiv anzubieten. 2. Stand der Dinge Bereits auf der Mensch und Computer 2012 in Konstanz wurde ein Zwischenstand der Anforderungsanalyse für die papierlose Haltestelle vorgestellt. Diese war im Vorfeld unter der Anwendung verschiedener Methoden, darunter Fokusgruppen, Feldbefragungen und Nutzertests, durchgeführt worden. Die Anforderungsanalyse, der erste Schritt im User Centered Design Prozess, ist mittlerweile abgeschlossen. Als Ergebnis entstand ein Anforderungskatalog, der nun in Zusammenarbeit mit den Partnern der Studie, neben der SSB AG noch sechs weitere deutsche Verkehrsunternehmen, in eine offizielle Schrift des

Keywords: /// Informationen /// Haltestelle /// ÖPNV /// Zukunft /// Interaktion

Verbands Deutscher Verkehrsunternehmen (VDV) münden wird. Nun steht Phase 2, die Konzeption eines Fahrgastinformations­ systems an, welches die in Schritt 1 gesammelten Anforderungen erfüllen soll. Im Zentrum der durchgeführten Studie standen dabei Fragestellungen wie beispielsweise: –– Wie stehen Fahrgäste grundsätzlich zu der Vision der papierlosen Information an Haltestellen? –– Welchen Mehrwert bieten digitale Infor­­­­­mationssysteme für Fahrgäste und Verkehrsbetriebe? –– Wie sehen die gängigsten Nutzungsszenarien im Umgang mit Pa­pieraushängen an Haltestellen aus und was bedeutet dies für zukünftige digitale Systeme? –– Welche Anforderungen und Erwartungen haben Fahrgäste an digitale Informationssysteme wie z.B. Touch-Displays? –– Wie gut sind bestehende Systeme und Prototypen digitaler Informationssysteme bedienbar?


Usability Professionals 2013 Workshop

Um diese Fragen zu beantworten, wurden in insgesamt sieben Städten mehrere Methoden für die Gewinnung von Wissen eingesetzt. So wurden in Gelsenkirchen und Nürnberg Fokusgruppen durchgeführt, in welchen Fahrgäste in moderierten Gruppendiskussionen an die Vision der papierlosen Haltestelle herangeführt wurden. Auf diesem Weg wurden Erkenntnisse über die grundsätzliche Einstellung gegenüber digitalen und analogen ­Informationsmedien für die Fahrgastinformation gewonnen. In Mannheim, Hannover, Köln und Stuttgart wurden Feldbefragungen von Fahr­ gästen durchgeführt, sowie Nutzungsdaten bestehender Livesysteme analysiert und ausgewertet. Um zu verstehen, welche Informationen durch ein digitales Informationssystem an Haltestellen zur Verfügung gestellt werden müssen, wurde den Fahrgästen bei der Suche nach Informationen an klassischen Papieraushängen über die Schulter geschaut. Durch anschließende Befragungen wurde ermittelt, welche Informationen im Rahmen welcher Nutzungsszenarien gesucht wurden. In Köln und Stuttgart sind seit einigen Jahren bereits sogenannte elektronische Vitrinen mit Touch-Displays im Testbetrieb. Ergänzend zu den Feldbefragungen wurden anhand der Daten dieser Live-Systeme analysiert, welche Informationen an diesen digitalen Systemen wie häufig aufgerufen wurden. Anhand eines Prototyps einer elektronischen Vitrine der Firma BBR wurden Nutzertests mit insgesamt 16 Teilnehmern in Stuttgart und Bonn durchgeführt. Der Usability-Test bestand dabei aus einer Kombination von lautem Denken und dem Einsatz eines mobilen Eye Trackers. Ziel war es primär, das Ausmaß der Ge­­ brauchstauglichkeit der Benutzeroberfläche zu untersuchen und Optimierungsempfehlungen abzuleiten. Ergänzt wurden diese Ergebnisse außerdem durch ein Experten-Review, in welchem der Prototyp der elektronischen Vitrine anhand gängiger Usability-Prinzipien und typischer Handlungsabläufe evaluiert wurde. Die Ergebnisse der Studie lieferten wert­volle Erkenntnisse für die weitere

Entwicklung des Konzepts der papierlosen Information an Haltestellen. Die Optimierungsempfehlungen für die Gestaltung der elektronischen Vitrine werden aktuell in einem neuen Prototypen umgesetzt, der als Basis für zukünftige Nutzertests dienen wird. Beispielsweise könnte das Interface des überarbeiteten Touch-Sys­tems im nächsten Schritt im Rahmen eines P ­ ilottests an einer ausgewählten Haltestelle erstmals alle Fahrgastinforma­tionen in Papierform komplett ersetzen, um wei­tere Erkenntnisse zur Akzeptanz und Nutzungsbereitschaft solcher Systeme zu gewinnen. Die im Verband Deutscher Verkehrsunternehmen (VDV) von den Projektpartnern gemeinsam erarbeitete VDV-Mitteilung zum Thema „Papierlose Aushanginformation an ÖPNV-Haltestellen“ befindet sich momentan in Vorbereitung. Sie wird die ausführliche Dokumentation der Gemeinschaftsstudie und Empfehlungen für die Benutzeroberfläche, die Informationsinhalte und Nutzungsszenarien für die elektronische Aushanginformation an Haltestellen enthalten sowie Empfehlungen für die Anbindung an Hintergrundsysteme und den Betrieb elektronischer Vitrinen bieten. 3. Ablauf des Workshops Ziel des Workshops ist es, zusammen mit den Teilnehmern einen Entwurf für folgende Fragestellungen zu erarbeiten: „Wie sieht die Haltestelle der Zukunft aus, wenn es keine Papieraushänge mehr gibt? Wie könnte ein digitales, interaktives Informationssystem aussehen, welches dort eingesetzt wird?“ Nach dem Input, den Erkenntnissen aus der Studie, sollen anschließend im zweiten Teil anhand verschiedener Möglichkeiten (z.B. Papier Prototyp, Scribbles, Wireframes) die Ideen in Gruppenarbeiten umgesetzt und visualisiert werden. Die Grundidee dieses Workshops besteht darin, den Teilnehmern anhand eines realen und praxisbezogenen Beispiels die Möglichkeit zu bieten, im engen Austausch und in Zusammenarbeit mit anderen Experten eine innovative Schnittstelle zwischen Mensch und Maschine zu konzipieren. Die

Herausforderung hierbei soll unter anderem darin bestehen, dass sich die Teilnehmer auf die Vielfalt der Nutzer im ÖPNV einstellen, intuitive und gebrauchstaugliche Interaktionskonzepte erarbeiten und die verschiedenen Nutzungskontexte sowie die definierten Anforderungen aus der Anforderungsanalyse berücksichtigen. Der Ablauf des Workshops ist dabei in drei Phasen geplant: 1. Input über grundlegende Findings aus der durchgeführten Anforderungsanalyse –– Präsentation ausgewählter Punkte aus dem Anforderungskatalog wie zum Beispiel gängigste Use Cases, Priorisierung der Informationen, Wünsche und Bedenken der Fahrgäste im Bezug auf Technologie oder neue Features –– Impulse zu aktuellen Trends und Beispiele 2. Gruppenarbeiten zu Konzepten, Features und Gestaltung eines digitalen Fahrgastinformationssystems für eine papierlose Haltestelle der Zukunft unter Berücksichtigung von Aspekten wie z.B. Medium, Umgebung, Technologie, Interaktionskonzept, Features und Design 3. Vorstellung der Entwürfe und gemeinsame Diskussion zum Beispiel anhand von Kriterien wie Machbarkeit, Innovationsgrad, Usability, Erfüllung des Anforderungskatalogs, Berücksichtigung der vielfältigen Nutzungskontexte und der generellen User Experience

Da bei dem Thema ÖPNV (öffentlicher Personennahverkehr) so gut wie jeder mitreden und aus Erfahrung berichten kann, stößt dieser Bereich allgemein auf breites Interesse. Über die wichtigsten Findings aus dem Anforderungskatalog wird nur eine grobe Richtung vorgegeben, ansonsten sollen die Teilnehmer bewusst offen in die Ideensammlung und Erstellung von Entwürfen einsteigen – hier wird der spezielle Mix aus den Erfahrungen und dem Wissen von Experten und Nichtexperten verschiedenster Disziplinen voraussichtlich zu interessanten Ergebnissen führen. Die Motivation für die Teilnehmer des Workshops ergibt sich

13


dabei aus der persönlichen Betroffenheit: Da die digitale Haltestelle in absehbarer Zeit von diversen Verkehrsbetrieben realisiert werden wird, haben sowohl Gelegenheitsnutzer als auch Vielnutzer von Bus und Bahn ein berechtigtes Interesse daran, dass diese sowohl eine hohe Gebrauchstauglichkeit als auch ein modernes Design und nützliche Features aufweist. Weiterführende Links 1. http://www.agentursiegmund.de/ pdf/referenzen/die_haltestelle_der_ zukunft_2013.pdf 2. http://www.popsci.com/gadgets/ article/2011-09/hands-mtas-go-mobilestation-47-inch-travellers-touchscreen 3. http://youtu.be/4z99zEbNvOw 4. http://youtu.be/jZkHpNnXLB0

14


Usability Professionals 2013 Workshop

15


Die Anwendung von Spielmechanismen im User Research – Level up oder Epic Fail? Workshop zur Relevanz und Anwendbarkeit von Spiel­­ mechanismen in User Research Methoden Eva Rügenhagen SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf eva.ruegenhagen@sap.com

Dr. Theo Held SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf theo.held@sap.com

Abstract Meist wollen Usability Professionals ihren Kunden nicht nur belastbare Ergebnisse für die Entwicklung besser bedienbarer Software liefern, sondern legen auch auf die Benutzerfreundlichkeit ihrer Arbeitsweise wert. Die Mitglieder des Projektteams als ­Endanwender der Resultate zu sehen legt dementsprechend nahe, auch hier eine bestmögliche User Experience anzustreben. Dies stellt jedoch häufig eine Herausforderung dar, denn ob­ wohl Projektteams die gewonnenen Erkenntnisse als relevant einstufen, wird der Weg dahin von ihnen streckenweise als mühevoll empfunden. Bei der Suche nach einer möglichen Verbesserung dieser Situation kam die Idee auf zu untersuchen, ob eine Anwendung von Spielmechanismen auf User Research Methoden sinnvoll sein kann. Das Resultat ist ein internes Projekt zum Design spielerischer Varianten von praktizierten Methoden. Dabei wird die Methode selbst nicht modifiziert, sondern in einen spielerischen Kontext eingebettet. Im Workshop soll kurz über die Vorüberlegungen berichtet werden, die zu diesem Pro­jekt geführt haben. Als Beispiel für die Anwendung wird ein in diesem Projekt erstelltes Spiel, ein Tippspiel im Rahmen eines Usability Tests, vorgestellt. Dieses Tippspiel wird in ver­ kürzter Form angespielt, woraus sich bereits erste Diskussionsgegenstände ergeben kön­ nen. Im Anschluss werden in Gruppenarbeit Ideen gesammelt, wo unterschiedliche Spiel­ mechanismen sinnvoll eingesetzt werden können und wo Modifikationen u ­ nerwünschte Nebenwirkungen haben könnten. Ergebnis des Workshops ist der Beginn eines Diskurses, der in der Community der ­Usability Professionals an Relevanz gewinnen kann.

1. Vorüberlegungen 1.1 Problembeschreibung Viele Usability Professionals haben – ne­ben dem Abliefern von qualitativ hoch­wertigen Services und belastbaren empirischen Daten – den Anspruch, ihre Leistungen in benutzerfreundlicher Art und Weise anzu­ bieten. Frühes Einbeziehen des Projekt­ teams und eine klare Formulierung von Research-Ziel, Vorgehensweise und Ab­schluss­bericht sind wichtige Bestandteile in der Umsetzung dieses Anspruchs (siehe Tomer, 2012). Diese Vorgehensweise erhöht die von den Mitgliedern des Projektteams

16

wahr­­genommene Transparenz und Qualität, geht jedoch kaum auf hedonische Aspekte ein. Aus unserer Projekterfahrung lassen sich als ein Beispiel ­hierfür formative Usability Tests nennen, bei denen die Mitglieder des Projektteams zur bes­seren Akzeptanz der Ergebnisse stark in die Durchführung mit eingebunden werden. So haben sich Teams sehr positiv über den Erkenntnisgewinn durch diese Art der Usability Testens geäußert. Es wird aber teilweise auch angemerkt, dass die dabei durchzuführenden Aufgaben wie Note Taking und Analyse als ­inhaltlich sinnvoll, darüber hinaus aber auch als sehr anstrengend wahrgenommen wer­den. Hinzu kommt die Ernüchterung über den Umstand, dass das aufgezeigte Ver­besserungspotential der Software im Anschluss zu einem nicht

Keywords: /// User Research /// Gamification /// Formative Usability Tests /// Projektteam Commitment

antizipierten Arbeitsaufwand führt, wenn das ­Feedback der Anwender dann tat­ sächlich umgesetzt werden soll. Dies kann in der Summe dazu führen, dass die hohe Akzeptanz der Ergeb­nisse, die durch die aktive Teilnahme der Projektteams zu Beginn des Tests ent­standen ist, bereits bei der Ergebnispräsen­tation stark gesunken ist. Dies führt gleichermaßen zur Frustration auf Seiten des Usability Professionals und des Projektteams. Mehrere Ansätze sind denkbar, wie diese Situation verbessert werden könnte. Neben Modifikationen an der Methode kann eine Herangehensweise hierfür auch sein, das methodische Vorgehen ­inhaltlich so zu belassen wie es ist, aber die emotionale Bindung des Projektteams an die


Usability Professionals 2013 Workshop

Methode und deren Ergebnisse durch Ver­änderungen in der Umsetzung zu steigern. Bei der Suche nach einer Antwort auf diese Fragestellung kam die Idee auf, zu untersuchen, ob die Anwendung von Spielmechanismen zu einer Steigerung der Zufriedenheit in der Durchführung von User Research, gar einem ‚Spaßfaktor Usability Test‘, führen kann. Im Folgenden werden die Aspekte und Inhalte erläutert, die für die Arbeit an einer Verknüpfung von User Research und Spielmechanismen relevant waren. 1.2 Das Methodenspektrum von Gamifi­ cation Design und Game Design Der Begriff Gamification beschreibt die Anwendung von Spielattributen auf spielfremde Kontexte. Dieses Vorgehen wird nicht mehr nur im Bereich von Kundenbindungsprogrammen genutzt, sondern gewinnt auch in der Softwareentwicklung stetig an Bedeutung. Die stärkere Verbreitung von Gamification und die breitere Fächerung möglicher Use Cases k­ ommen nicht zuletzt durch das wachsende Ange­ bot an Gamification-Plattformen zustande. Denn um Spielmechanismen in die Softwareentwicklung zu integrieren, ist es notwendig, Spielmechanismen zu kennen und sich also der Kenntnisse und Methoden der Disziplin ‚Game Design‘ zu bedienen. Da es sich dabei jedoch um eine Disziplin handelt, die nicht häufig im Qualifikationsportfolio von Projektteams anzutreffen ist, gestaltet sich dies im Projektalltag schwierig (zur begrifflichen Abgrenzung von Game Design und Gamification Design siehe Detering, 2011 und Herger, 2013). Diese Hürde zu überwinden haben sich Gamification-Plattformen wie beispielsweise Badgeville zur Aufgabe gemacht. Sie bieten an, Spielmechanismen in Pro­dukte einzubinden, ohne dass eine zusätzliche Qualifikation ‚Game Design‘ im Projektteam vorhanden sein muss. Den Nutzern wird eine ‚User Experience der nächsten Generation‘ versprochen, die sich nicht nur auf Soziale Medien, sondern auch auf Lösungen für Produktentwicklung und Geschäftsprozesse erstreckt (siehe

Badgeville Inc., 2012). Mit derartigen Versprechen stellen Gamification-Plattformen einen Bezug zum Tätigkeitsfeld des Usability Engineering her, so dass eine Prüfung deren Relevanz entsprechend sinnvoll erscheint.    Beleuchtet man die hier zur Anwendung kommenden Techniken jedoch näher aus der Perspektive des Game Designs wird deutlich, dass der Begriff der Gamification stark geprägt ist von Spielattributen wie Auszeichnungen und Punktesystemen. Zwar werden dem Spieler hier durch die verwendeten Techniken integrale Vortei­le des Game Designs geboten, wie beispielsweise klare Zielsetzung und transparente Feedback-Mechanismen; auch werden so­ziale Aspekte gestärkt wie beispielsweise der Statuszugewinn durch das Erar­ beiten von Abzeichen (siehe Antin und Churchill, 2011). Nichtsdestotrotz führen aber die von Gamification-Plattformen angewendeten Techniken zu einer Ein­ schränkung des Spielerlebens, da sie vor­ wiegend auf den kompetitiven Bereich des Spektrums emotionaler Qualitäten von Spielen abzielen. Folgt man den For­ schungsergebnissen von Lazzaro (2004) zu emotionalen Qualitäten in Spielen, die eingeteilt werden können in „Hard Fun“ (Freude an Wettbewerb und Sieg), „Easy Fun“ (Freude an freien Explorationsmöglichkeiten), „Altered States“(von Spielern angestrebte Zustandsveränderungen wie Entspannung oder Inspiration) und „People Factor“(Spielerleben als Pforte zu sozialer Interaktion), so wird deutlich, dass die emotionalen Dimensionen eines möglichen Spielerlebens nur eingeschränkt befriedigt werden. Entsprechend heftig wird darüber diskutiert, inwieweit sich über­haupt Techniken des Gamification Designs sinnvoll anwenden lassen können (siehe McGonigal, 2011 und Herger, 2013), Im Kontext des eingangs beschriebenen Problems stellte sich also auch in unserem Projekt die Frage, ob die hedonische Qualität von User Research Methoden allein durch die Anwendungen von Techniken des Gamification Designs verbessert werden könnte. Berücksichtigt man Lazzaros Modell des emotionalen

Erlebens in Spielen muss diese Frage mit ‚Nein‘ beantwortet werden. Denn durch die Implementierung von Auszeichnungen und Punktesystemen allein kann ein Prozess wie die Durchführung einer Usability Tests, was wie oben beschrieben ohnehin schon als herausfordernd empfunden wird, zwar eine neue spielerische Komponente, jedoch keine neue emotionale Qualität gewinnen. Daher erscheint es sinnvoll, Mechanismen des Game Designs sowie grundlegende Spielmechanismen näher zu betrachten, um eine Erweiterung der emotionalen Qualitäten zu erreichen. Verlässt man das Angebot des Gamifica­ tion Designs – die Bereitstellung von Soft­ waresystemen zur automatisierten Erzeugung von Spielerleben – und erweitert den Methodenkoffer auf Konzepte des Game Designs, so ist ein kurzer Blick auf die Definitionsdiskussion des Begriffs ‚Spiel‘ unerlässlich. Diese komplexe Diskussion wird von Salen und Zimmermann (2004) sowie McGonigal (2012) ausführlich beleuch­tet; basierend darauf hat sich für unsere Projektarbeit eine Reduktion auf die folgenden Komponenten als hilfreich und gut anwendbar erwiesen. Demnach bezeichnet ein Spiel einen Raum, den der Spieler freiwillig betritt und in dem es gilt den Weg zu einem bestimmten Ziel unter Anwendung der in diesem Raum geltenden Regeln zu erreichen. Das Besondere dabei ist, dass das Ziel nicht auf direktem Weg erreicht werden kann, sondern es ein unnötiges Hindernis gibt, dessen Um­gehung den Spielern kreative Problemlösungsstrategien abfordert. FeedbackMechanismen geben dem Spieler darüber Aufschluss, wie weit er auf seinem Weg der Erreichung des Ziels bisher gekommen ist und welche Auswirkung die Regeln auf sein Fortschreiten haben. Diese Elemente erheben den Anspruch, universell für alle Spiele gültig zu sein, von Golf bis League of Legends. Sie können in dem Moment zu einem positiven Spielerleben führen, wenn die Herausforderung, das Ziel zu erreichen, weder zu leicht noch zu schwierig gestaltet ist.

17


2. Anwendung von Spielmechanismen auf User Research Methoden: 2.1. Möglichkeiten Um eine Annährung von Spiel und User Research Methoden zu ermöglichen haben wir im Zuge unseres Projekts überprüft, ob die Anwendung von User Research Methoden überhaupt dafür geeignet sein könnte, ein Spielerlebnis hervorzurufen. Diese Überlegungen wurden am Beispiel der Methode Usability Test vorgenommen. Dabei wurde offensichtlich, dass Potential vorhanden ist, die Methode in einigen für das Game Design relevanten Bereichen zu überarbeiten und dadurch von einer Steigerung des Spaßfaktors profitieren zu können. So ist beispielweise das abstrakte Ziel, eine Verbesserung der Usability eines User Inter­­face zu erreichen, den Teilnehmern zu Beginn häufig klar und meist Anlass dafür, den Raum ‚Usability Test‘ zu betreten. Dass dieser Weg nur über das Zwischenziel ‚Probleme werden identifiziert‘ und ‚Erarbeiten einer Lösung‘ erreicht werden kann, wird vorab häufig nicht vergegenwärtigt. Dies kann beabsichtigt geschehen, um die Motivation zu Testbeginn nicht zu dämpfen oder aber unbeabsichtigt aus Unkenntnis des Prozesses. Hier unterscheidet sich der Usability Test klar von einem Spiel, letzteres erhebt den Anspruch einer klaren Ziel­ setzung. Eine Steigerung der hedonischen Qualität durch bessere Detaillierung der Zwischenziele und Spielregeln des Usa­bi­ lity Test scheint hier denkbar. Auch gibt es für Usability Tests keinen leicht durchdringbaren Feedback-Mechanismus, der den Teilnehmern deutlich macht, wann sie das Meta-Ziel einer besseren Usability erreicht haben und der Raum des Usability Tests erfolgreich wieder verlassen werden kann. In Spielen wird der Spieler durch Punktzahlen, visuelle Anzeigen oder akustische Signale über seinen Status informiert. In Usability Tests hingegen wird zwar häufig ausgezählt wie viele Usability Probleme gefunden worden sind und welchen Schweregrad diese haben;

18

jedoch gibt es keine Regel dazu, wie viele Probleme behoben sein müssen um das Ziel einer besseren Usability zu erreichen, so dass ein entsprechendes Feedback fehlt. Dazu kommt die Schwierigkeit, dass das Produktteam eine steigende Anzahl gefundener Usability-Probleme eher als Entfernung vom Gesamtziel wahrnehmen kann, als diese als notwendige Schritte in Richtung Gesamtziel zu betrachten. Dies sind nur zwei Beispiele für die viel­fäl­ tigen Ansatzpunkte, wo durch die An­­wen­ dung von Spielkonzepten Inspiration für Ver­besserungen gewonnen werden kann. Dies kann möglicherweise sogar erreicht werden, ohne dass ein spielerischer Ansatz im Projektteam Anwendung findet, da hier bereits ein Diskurs unter Usability Professionals neue Blickrichtungen ermöglichen kann. Wendet man zusätzlich Lazzaros Ergebnisse zu den vier emotionalen Komponenten von Spielen an, erweitert sich die Bandbreite der möglichen Ideen, wie User Research Methoden um neue hedonische Qualitäten ergänzt werden können. So ist beispielsweise eine Stärkung der ‚Altered States‘, der Erfahrung der emotionalen Zustandsveränderung, denkbar, indem den Teilnehmenden der Erkenntnisgewinn durch einen Usability Test spieler­isch transparent gemacht wird. Die Kompo­ nente des ‚People Factor‘ kann gestärkt werden, indem das Projektteam ­stärker gemeinschaftlich auf das Ziel einer bes­ seren Usability hinarbeitet indem es Usability Probleme besiegt – oder aber man fokussiert auf die Komponente ‚Hard Fun‘ und ermöglicht den Teilnehmern einen _Triumph über Kollegen durch eine möglichst genaue Hervorsage des Ergebnis des Usability Tests. 2.2. Risiken Lässt man sich auf die Analogie des Usability Tests als Spiel ein stellt man schnell fest, wie vielfältig die Möglichkeiten der Anwendung von Spielmechanismen auf existierende User Research Methoden

sind. Dies zeigte sich bereits in unserem Projekt, genauso birgt dieser Ansatz je­doch auch Risiken. Nachfolgend wollen wir auf einige Schwierigkeiten eingehen, die es zu berücksichtigen gilt. Ein Risiko bei der Anwendung von Spielmechanismen kann darin bestehen, das komplexe Zusammenspiel von Spielmechanismen, Spieldynamik und emotionalen Qualitäten zu unterschätzen. Welche Auswirkungen die Änderung einer Regel im Spielmechanismus für die emotionale Qualität eines Spiels hat, ist nur schwer abzuschätzen. So fordert Fullerton beispielsweise dazu auf, die Mechanismen einfacher Spiele systematisch zu verändern, um ein Gespür für die Auswirkungen der Modifikationen zu entwickeln (Fullerton, 2008). Hunicke, LeBlanc und Zubek (2004) schlagen einen formalen Ansatz zum Design von Spielen vor, der entgegengesetzt zur Spielererfahrung verlaufen sollte. Demnach gestaltet sich die Spielerfahrung des Spielers derart, dass zunächst die Spielmechanismen beispielsweise in Form einer Spielanleitung wahrgenommen werden, sich durch deren Anwendung eine Spieldynamik entwickelt und diese dann in einem ästhetischen Empfinden resultiert. Der Game Designer solle jedoch genau um­gekehrt vorgehen, um gezielt eine Spiel­erfahrung zu ermöglichen, die auf seine Spielergruppe ausgerichtet ist. Dieser Ansatz erwies sich zunächst als hilf­ reich, da es sich bei der ‚Spielergruppe‘ für User Research Methoden um Projektmit­ glieder handelt, deren Kontexte und spe­ zi­fische Erwartungshaltungen an eine im professionellen Umfeld durchgeführten Test berücksichtigt werden müssen. Darü­ ber hinaus ermöglicht ein Beginn bei der Spielästhetik eine Stärkung wünschenswerter emotionaler Qualitäten oder aber eine Schwächung negativer Emotionen. Nichtsdestotrotz haben wir in unserem Pro­jekt erfahren, dass dieser Ansatz nur bedingt vollständig umgesetzt werden kann. So haben wir die Idee, die emotio­nale Qualität eines Fußballtippspiels nutzen zu wollen, als hilfreich ­empfunden, da ein Fußballtippspiel in vielen ­SAP-­Büros durchgeführt wird


Usability Professionals 2013 Workshop

und somit sicherge­stellt ist, dass dies die Zielgruppe ­ansprechen könnte; auch liefert die ­Analogie viele Inspi­rationen zur Detaillierung der Spielmechanik. Dieser Ansatz trägt jedoch nur begrenzt: er hilft zunächst mit einer gewissen Sicherheit in den Game Design Prozess einzusteigen; ist jedoch der Zeitpunkt erreicht, an dem die Spielmechanismen konkret ausdetailliert werden müssen, wie beispielsweise die Gewichtungen der einzelnen Usability-Tipps festzulegen, war dies nur möglich indem wir das Spiel in verschiedenen Varianten selbst als Spieler und mit Pilotspielern testgespielt haben. Die eigene Spielerfahrung und den Prozess des sogenannten Playtesting hebt wiederum Fullerton stark hervor. Unsere Projekterfahrung hierzu legt den Schluss nahe, dass beide Blickwinkel, also sowohl die Spielerperspektive als auch ein Designprozess ausgehend von der emotionalen Erfahrung jeweils ihre Berechtigung haben, und hier nur ein iterativer Ansatz zu einer mechanisch funktionalen und hedonisch verbesserten Spielerfahrung führen kann. Wird ein iterativer Ansatz und der Prozess des Playtesting vernachlässigt, besteht das Risiko, dass die Gamification dahingehend scheitert, dass zwar eine bessere ästhetische Qualität erzeugt wird, aber statt eines Spiels lediglich ein Puzzle oder Spielzeug entsteht. Laut S. Kim in Fullerton (2008, S. 35–39) unterscheiden sich diese darin, dass ein Puzzle zwar wie ein Spiel ein regelbasiertes System ist, dessen Ziel der Spieler zwar erreichen kann; dies geschieht jedoch immer auf die gleiche Weise und ohne einen Triumph über einen menschlichen Gegner oder den Spielmechanismus, so dass auf Dauer der Wiederspielwert aufgrund der fehlenden Neuigkeit der Herausforderung gering ist. Bei einem Spielzeug fehlt nicht nur die Gewinnkomponente, es gibt auch kein erreichbares Ziel, so dass hier eine weiterer Aspekt, der ein Spiel ausmacht, fehlt. Dieses Risiko zeigte sich zu einem Zeitpunkt unseres Gamificationprojekts, an dem wir mit der Idee der Usability Tests im Kontext einer Schiffsbaumetapher experimentierten. Hier ergab sich zwar eine gute Möglichkeit, Usabilityprobleme ansprechender zu

visualisieren, jedoch konnten wir keinen sinnvollen Spielmechanismus entwickeln, dessen Regelwerk stimmig die Metapher getragen hätte. Wir ließen diesen Ansatz entsprechend wieder fallen, obwohl dies keine einfache Entscheidung war, da die Möglichkeit einer ansprechenderen Visualisierung verlockend ist. Die beschriebene Nutzung eines DesignThemas oder einer Metapher wird von Schell (2008) als potentiell hilfreich beschrieben, da dieses Thema den Ton für die emotionale Qualität des gesamten Spiels angeben und bei dessen weiterer Ausdetaillierung unterstützen kann. Auch hier zeigt unsere Projekterfahrung, dass dieser Ansatz gleichermaßen Möglichkeiten und Risiken birgt. Hilfreich ist ein Thema, um initiale Überlegungen anzustellen und einen Ansatzpunkt für den Start zu finden. Anders als beim Design eines Spiels liefert jedoch die Gamification einer existierenden User Research Methode gewisse Rahmenbedingungen, die zwingend eingehalten werden müssen um die Methode nicht zu stark zu verändern und die Qualität der Testergebnisse nicht zu gefährden. Riskant kann die Nutzung eines Themas dann werden, wenn durch die bereits investierte Zeit eine hohe Bindung an das Thema entstanden ist und es schwer fällt dieses aufzugeben, weil sich die Mechanismen der Metapher nicht an die Methode anpassen lassen. Nach unserer Einschätzung ist dieses Risiko nicht vermeidbar, jedoch mit dem entsprechenden Bewusstsein dafür gut kalkulierbar. Nicht zuletzt zeigte sich hier auch wieder für uns als positive Komponente der große Erkenntnisgewinn, den eine Anwendung von Spielmechanismen auf User Research Methoden möglich macht, da die thematische Betrachtung des Usability Tests als Kriminalgeschichte, Schiffsbauprojekt und sportliches Tippspiels neue Klarheiten über die Regeln und Ziele dieser Methode mit sich gebracht hat. Erste Testläufe mit potentiellen Projektteams bestätigen uns darin, dass eine Verbesserung der hedonischen Qualität möglich ist und wir diesen Ansatz weiter verfolgen wollen.

3. Workshop programm Um einen gemeinsamen Wissensstand sicher zu stellen, werden einleitend kurz die beschriebenen Vorüberlegungen sowie grundlegende Begriffe und Methoden von Gamification Design und Game Design vorgestellt. Um nach dieser Einführung einen besseren Eindruck über Möglichkeiten zur Umsetzung vermitteln zu können, stellen wir die bis dahin vorliegenden Ergebnisse eines Projekts vor, das die SAP Inhouse User Research Abteilung im Juli 2012 begonnen hat. Im Rahmen dieses ­Projekts werden Spiele entworfen, die User Research Me­tho­den um eine Spielkomponente erwei­tern sollen. Pilotprojekt war ein Tippspiel, das im Rahmen eines Usability Tests durchgeführt werden kann. Spielerziel ist es, einen möglichst treffenden Tipp darüber abzugeben, welche Usability-TestTasks von den Usern erfolgreich durchgeführt werden können, ob eine Hilfestellung durch Moderator-Assists nötig ist, und welche Funktionalitäten die größten Stolpersteine darstellen. Verifiziert wird dieser Tipp durch einen klassischen Usability Test mit Endanwendern, die selbst nicht Teil des Spiels bzw. keine Mitspieler sind. In der Ergebnispräsentation des Tests werden neben Usability-Problemen die Resultate des Tippspiels ermittelt. Verschiedene Spielmechanismen wurden dafür verwendet: aus dem Bereich des Game Design kommt ein kompetitiver Aspekt zur Anwendung, da die Entwicklungsteam-Mitglieder ihre Expertise im Bereich Usability in einem möglichst freund­schaftlichen Wettstreit unter Beweis stellen können. Darüber hinaus können aber auch Ziele verfolgt werden, die spielferne Kontexte betreffen: –– der Usability-Professional kann ein besseres Bewusstsein des Projektteams für die Methode schaffen –– Projektteammitglieder, die an einzelnen Sessions teilnehmen, können

19


stärker motiviert sein, diese auch mit auszuwerten –– Projektteammitglieder, denen eine Teilnahme am Test nicht möglich ist, werden durch das Abgeben eines Tipps von Beginn an stärker in das Resultat involviert –– das komplette Team kann von einer Veränderung der Teamdynamik dahingehend profitieren, dass Stimmen von Projektteammitgliedern, die sonst weniger Gehör finden, durch eine gute Einschätzung des Anwenderverhaltens verstärkt als relevant wahrgenommen werden können –– nicht zuletzt kann die Gruppe der Endanwender profitieren, da nicht nur prägnante Zitate stärker verbalisierender Testteilnehmer beim Projektteam im Gedächtnis bleiben, sondern auch die summative Komponente qualitativer Methoden stärker ins Bewusstsein des Projektteams gerückt werden kann.

Literatur 1. Antin, J. & Churchill, E. (2011). Badges in Social Media: A Social Psychological Perspective.: Proceedings of CHI 2011 Vancouver, BC, Canada. ACM Press. 2. Badgeville, Inc.(2012). About Badgeville. [Website]. Abgerufen von http://www. badgeville.com/about. 3. Deterding, S., Khaled, R., Nacke L.E. & Dixon, D. (2011). Gamification: Toward a Definition. Proceedings of CHI 2011 Vancouver, BC, Canada. ACM Press. 4. Fullerton, T. (2008). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. Burlington, MA, USA: Elsevier. 5. Herger, M. (2012). The Framing-Problem of Gamification-Criticism [Blog Eintrag]. Abgerufen von http://enterprisegamification.com/index.php/de/ blog/4-blog/120-the-framing-problem-ofgamification-criticism 6. Hunicke, R., LeBlanc, M. & Zubek, R. (2004). MDA: A Formal Approach to Game Design and Game Research. Game Design and

Dieses Beispiel wird kurz vorgestellt und anschließend in verkürzter Version angespielt. Hieraus können bereits neue Anregungen und Diskussionsgegenstände entstehen.

Tuning Workshop at the Game Developers Conference, San Jose 2001–2004. 7. Lazzaro, N. (2004). Why We Play Games: Four Keys to More Emotion Without Story. [Whitepaper]. Abgerufen von http://xeodesign.com/xeodesign_

Im letzten Teil des Workshops soll erarbeitet werden, in welchen User Research Methoden die Anwendung von Spielmechanismen noch denkbar und sinnvoll sein könnte.

whyweplaygames.pdf 8. McGonigal, J. (2012). Reality is Broken: Why Games Make Us Better and How They Can Change the World. London, UK: Vintage. 9. McGonigal, J. (2011). We don’t need no stinkin’ badges: How to re-invent reality

Das Resultat des Workshops ist eine Ideensammlung, die zu einem weiteren Diskurs in der Community der Usability Professionals führen kann.

without gamification. Presentation at GDC 2011. (http://goo.gl/9a6ka). 10. Tomer, S. (2012). It’s Our Research. Waltham, MA, USA: Morgan Kaufmann. 11. Salen, K. & Zimmerman, E. (2004). Rules of Play: Game Design Fundamentals. Cambridge, MA, USA: Massachusetts Institute of Technology. 12. Schell, J. (2008). The Art of Game Design: A Book of Lenses. Burlington, MA, USA: Elsevier.

20


Usability Professionals 2013 Workshop

21


Erfolgreiche Usability & UX in Unternehmen Thesen und Erfolgsfaktoren zu Usability/UX-Prozessen, Strategie und Change Jana Löffler artop – Institut an der Humboldt-Universität Berlin Christburger Str. 4, 10405 Berlin loeffler@artop.de

Knut Polkehn artop – Institut an der Humboldt-Universität Berlin Christburger Str. 4, 10405 Berlin polkehn@artop.de

Abstract Viele Unternehmen haben lange erkannt, dass eine hohe Usability & UX nicht allein durch die Evaluation ihrer Produkte und Services zu erreichen ist. Sie berücksichtigen inzwischen den Nutzungskontext und klären Anforderungen an die zu entwickelnden Lösungen. Mit einem zunehmenden Reifegrad stehen sie vor neuen Herausforderungen: Es gilt, UX Prozesse zu systematisieren. Agile Entwicklungsprozesse wollen mit UX Aktivitäten in Einklang gebracht werden. Produkte sollen Anforderungen aus dem Business und von Benutzern in einem gewinnbringenden Zusammenspiel beantworten. Organisationale Funktionen und Management Praktiken werden etabliert, um UX Prozesse zu verankern. Usability wird zum Thema für die Unternehmensstrategie. Zusätzlich müssen Unternehmen mit den sich daraus ergebenden Veränderungen – diesem „Change“ – umgehen. Im Workshop auf der UP 13 berichten wir Beobachtungen aus unserer Praxis als Berater und Dienstleister und erarbeiten die Erfahrungen der Teilnehmenden. So soll die Landschaft aktueller Herausforderungen der unternehmensinternen Arbeit an Usability & UX skizziert werden. Gemeinsam erarbeiten wir Thesen, die Ansatzpunkte zum Umgang mit diesen Herausforderungen beschreiben und Anforderungen an erfolgreiche Usability/ UX-Projekte und -Prozesse adressieren.

Für die erfolgreiche Etablierung von UX Prozessen in Unternehmen sind Werkzeuge und Landkarten nötig In Workshops, die wir mit UX-Verantwortlichen bei einem großen e-Commerce Unternehmen durchführten, berichteten diese, sich in einer „Sprinthetzjagd“ zu erleben und im „Hamsterrad des Scrum“ zu stecken. Innerhalb möglichst kurzer Zeitspannen versuchen sie – im Takt der agilen Entwicklung – wertvolle Erkenntnisse zu produzieren und beizusteuern. Sie verfügen über ein enormes Wissen über die Benutzer und arbeiten dennoch zum Teil „für die Tonne“. Sie sehen es als nahezu unerreichbare Herausforderung, ihre Erkenntnisse zu Produktverantwortlichen und in den agilen Entwicklungsprozess zu transferieren. Das Problem der Integration von UX und agiler Entwicklung wird in den letzten Jahren ja immer wieder behandelt (z.B. „Lean UX“ von Gothelf und Seiden,

22

Publikationen der UP in den letzten Jahren, Thema auf der IA Konferenz 2013). Ein Teil des agile-Entwicklung-UX-Problems liegt im Umgang mit der Taktung der Prozesse. Wenn stillschweigend oder per Management-Entscheidung angenommen wird, dass der Taktgeber für UX Prozesse die agile Entwicklung ist, versuchen UXVerantwortliche, ihre Arbeit in den agilen Takt zu bringen und scheitern dabei zum Teil. Denn es ist nur begrenzt möglich. Manche Formate (z.B. ein Testing) lassen sich leichter in diesen Takt bringen als andere (z.B. ausgefeilte Kontext-Research

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

Keywords: /// Strategie /// Change /// Herausforderungen der UX Integration

und Modellbildung. Nicht zuletzt ist es natürlich auch eine Frage von Man-Power). Natürlich ist hier auch die Anpassung von UX Methoden und die Entwicklung pragmatischer Herangehensweisen gefragt. Das ist aus unserer Erfahrung jedoch kein hinreichender Zugang. UX Prozesse haben Eigenzeiten. Die Annahme, die Tätigkeiten eines Feldes komplett in ein anderes eintakten zu können, führt in die Irre. Von ihr getrieben, erleben sich UX Professionals im „Hamsterrad“. UX- und agile Prozesse müssen synchronisiert werden. [Abb. 1]

Abb. 1. Synchronisation der Prozesse


Usability Professionals 2013 Workshop

Im Fallbeispiel ist dies jedoch noch nicht die einzige Schwierigkeit der Integration von UX. Wie in vielen anderen eCommerce Unternehmen auch, wurde mit dem MVP-Ansatz gearbeitet, um beim Experimentieren mit einem „minimum viable product“ für die weitere Produktentwicklung zu lernen. Jedoch wurde in der Produktentwicklung das Knowhow über den Kundennutzen kaum herangezogen. Im Team wurde gewitzelt, die Hauptquelle für die Entwicklung neuer Features seien „Ideen, die dem product owner unter der Dusche kommen“. Wir wollen hiermit auf keinen Fall Kreativitätstechniken abwerten. Am Beispiel sehen wir – neben dem „Schmerz“ der UX-Verantwortlichen und den Belastungen für die Mitarbeiter und Unternehmenskultur – dass ein enormes Potential an Wissen über die Benutzer, und damit Innovationspotential, nicht systematisch angezapft wird. Aus der UXPerspektive hört man dann: „Wir müssen eben pragmatischer werden.“ Oder „Die sollten uns mehr fragen.“ Diese Perspektive greift zu kurz und mit reinen Aufforderungen an Teammitglieder und mehr Anstrengung kommt man nicht weiter. Erfolgreiche UX braucht Flughöhe Das Fallbeispiel soll zeigen, dass die Betrachtung des Problems allein aus der UX-Perspektive zu kurz greift. Die Flughöhe muss sich verändern. Aus Sicht der Organisation bestimmt sich der Erfolg eines Produktes durch die Güte des Einklangs von Erfolgskriterien aus der Sicht des Business, der Benutzer und der Technologie. Für das Business sind

Erfolgskriterien z.B. Umsatzsteigerung, Kostenminimierung, Innovation, gesellschaftliche Verantwortung (business value). Aus der Perspektive der Technologie sind es z.B. Funktionalität, Zuverlässigkeit, Übertragbarkeit. Erfolgskriterien aus der Sicht des Menschen bzw. der Benutzer sind Nützlichkeit, Einfachheit, Ästhetik, Freude bei der Nutzung (customer value) (siehe auchPolkehn & Hüttner, 2012). [Abb. 1] Wenn also das Zusammenspiel der drei Zielgrößen wichtig ist, ist das Modell auch ein möglicher Kompass für die erfolgreiche Integration von UX. So sollte das „Experimentieren mit dem MVP“ ein Experimentieren mit allen drei Perspektiven sein, in welchem z.B. die Fragen beatwortet werden: „Trägt das Business Modell? Passt die Technologie? Ist das Produkt nützlich und kommen Benutzer damit zurande?“ Im Fallbeispiel war die Abstimmung der drei Perspektiven problematisch. Zwar sah der „blueprint“ des agilen Prozesses den Kundennutzen als wichtiges Element an. Jeder Entwicklungsschritt begann mit einer Phase, in der dieser eingeschätzt werden sollte. Jedoch wurden im reellen Prozess kaum Ressourcen für Aktivitäten zur Erarbeitung des Kundennutzens allokalisiert, weder zeitliche noch strukturelle. Es gab (noch) keinen mit dem agilen Vorgehen vereinbarten Ort, an dem der Kundennutzen systematisch hinterfragt und bewertet wurde. Geschweige denn, den Kundennutzen zum Ausgangspunkt der Entwicklung zu machen und übergeordnet von einzelnen kleinen Projekten über diesen nachzudenken. Während der Produktentwicklung entfiel also ein Teil der Perspektive „Mensch“. Chancen wurden vertan. Zudem gab es beim Auftreten von Zielkonflikten aufgrund der Rollenverteilung keine tragfähige Instanz. Die Produktverantwortlichen verstanden sich eher als Erfinder und Innovatoren, denn als Manager

der unterschiedlichen Anforderungen aus den Perspektiven Business, Technologie, Mensch. Aus unseren Erfahrungen müssen die drei Perspektiven idealerweise durch „Anwälte“ – Rollen und Funktionen – repräsentiert und im Laufe der konkreten Produktentwicklung jeweils ausgehandelt werden. Als problematisch erleben wir es, – wenn es in Unternehmen niemanden gibt, der sich systematisch mit Zielen aus der Perspektive des Business, der Benutzer, der Technologie auseinandersetzt und diese in den Entwicklungsprozess einbringt. – wenn einzelne Bereiche mit unterschiedlicher Macht ausgestattet sind und die Produktentwicklung so den Mangel an einer Perspektive erleidet – wenn es keine Container (wie Prozesse, Meetings, …) gibt, an denen sich die verschiedenen Ziele und Perspektiven austauschen und integrieren lassen – wenn die Aushandlung zu sehr unter politischen Kämpfen leidet und Unternehmen damit teilweise „blind“ für einige Perspektiven werden. Fazit: Für eine funktionierende Etablierung von UX in Unternehmen ist eine Integration der drei Perspektiven Business, Technologie & Benutzer in Prozessen und Strukturen (Entscheidungen, Hierarchien) von Unternehmen nötig. Wie wir weiter unten sehen werden, braucht es dafür Funktionen und organisationale Orte. Bezogen auf die oben erwähnte Synchronisation von Prozesse gilt es, die Prozesse zu allen drei Zielgrößen zu orchestrieren und zu managen, mit gemeinsamen und eigenen Takten, und dabei verschiedene Geschwindigkeiten einen gemeinsamen Klang zu erlauben.

Wie Unternehmen versuchen, die Herausforderung der Integration zu bewältigen – Erfahrungen einer externen Beratung Abb. 2. Integration der Perspektiven Business, Technologie und Mensch für erfolgreiche Produkte

Die Herausforderung ist beschrieben. Wie gehen Unternehmen mit ihr um?

23


Unternehmen stellen sich oft gar nicht die Frage: „Wie bekommen wir den HCD Prozess systematisch integriert?“. Deshalb ist es ist aus unserer Erfahrung in Beratungsprojekten oft nicht zielführend, gleich die gesamte Produktentwicklung in Richtung UX „umkrempeln zu wollen“. Wichtiger ist die Frage: „Welche UX-Aktivität ist für diesen Schritt benötigt? Sind Kontextinformationen von Nöten? Sollen Anforderungen beschrieben werden? Usw.“ In einem solchen aktivitätsbasierten Ansatz nähern sich Unternehmen Schritt für Schritt der UX Integration. Sie lernen, dass UX ein Qualitätsmerkmal ist und sie einen Bedarf an solchen Prozesse haben.

Benutzermodelle ab. Der CEO berichtete, über die erstellten Modelle glücklich zu sein: Sie gaben wertvolle Hinweise für Entscheidungen zur Steuerung des Unternehmens. Allerdings zeigten sich Schwierigkeiten, die Ergebnisse in die Produktentwicklung einfließen zu lassen: Produktmanager und Programmierer hatten z.B. noch nie mit Mental Models und anderen Outputs gearbeitet, daneben gab es Vorbehalte über den Einsatz der Informationen. Es gab keinen Prozessschritt und keine Methode, die intern halfen, die Informationen in den Entwicklungsprozess einzuarbeiten.

In Projekten sehen wir, wie Unternehmen, die wir beraten, an der Grenze zu einem nächsten Schritt in der Entwicklung stehen. Manchmal dauert es – wie bei einem Indus­trie­unternehmen – fünf Jahre, bis die Erhebung von Nutzungsanforderungen auf der „Landkarte der Produktentwicklung“ erschien. Manchmal übernehmen wir als „verlängerte Werkbank“ Aufgaben (vom Usability Test bis zur Anforderungsanalyse), bis sie integrierbar sind und inhouse Kompetenzen aufgebaut wurden.

Lernaufgabe für das Unternehmen war hier, die Anschlussfähigkeit der UX Aktivitäten sicherzustellen, damit die teure und qualitativ hochwertige Information nicht ungenutzt bleibt.

Von internen UX Verantwortlichen und uns als externen Beratern erfordert das auch Ab­grenzung und Geduld. Der Wunsch, mög­ lichst zeitnah gute UX auf hohem Niveau zu machen, wird teilweise stark frustriert. Eine gute Auftragsklärung ist hilfreich, um UX-Projekte, erst recht mit wenig R ­ essourcen, zum Erfolg zu führen: Geht es darum, eine Dienstleistung zu erbringen (z.B. User Research)? Geht es darum, auf die nächste Entwicklungsstufe hinzuarbeiten? Oder sogar, einen Veränderungsprozess anzustoßen? Wir wollen beispielhaft drei Phänomene beschreiben, die wir bei Unternehmen im Umgang mit UX-Integration beobachten: UX-U-Boote, UX Guerilla und Top-Down Integration. UX U-Boote In einem e-Commerce Unternehmen führten wir im Auftrag des CEO und mit dem UX Verantwortlichen eine initiale Kontextforschung durch und leiteten

24

Solange UX eine Teilaktivität ist, muss der Blick auf die Schnittstellen, an denen sie eine Rolle spielt, gelenkt werden und auf organisatorische „Orte“, an denen die Outputs verarbeitet werden können. Sonst kann die gute, zusätzliche Nahrung „nicht verdaut werden“. UX Guerilla – UX Resignation Wie beobachten, dass UX Projekte manchmal aus der individuellen Initiative von Personen entstehen, die Feuer für das Thema gefangen haben. Auf eigene Kostenstellen oder privat erzeugen sie mit Zuversicht und Euphorie UX Insights, die mehr oder weniger wirksam sind. Manchmal geschieht das in einer Projektorganisation quer zu den Unternehmensstrukturen und ist dann sogar legitimiert. Oft sind diese Aktivitäten sehr lebendig aber vergeblich. Sie münden in Resignation oder teilweise sogar Kündigung, wenn sich die Hoffnung, im Thema UX arbeiten zu können, nicht erfüllt. Folgen auf Unternehmensseite sind der Verlust von qualifizierten Mitarbeitern, von Inspiration und Engagement. Top-Down-Integration Bei der Top-Down-Integration hat das TopManagement UX als zentrales Handlungs­feld

erkannt und ruft einen Wandel aus. Hier gilt es, die Mitarbeiter zu gewinnen („wake-up“ nach unten) und in einem „Change“ mitzunehmen. Und die eingeübten Prozesse in neue Muster zu überführen. Neue Orte in der Organisation sind nötig Wir sehen, dass UX Aktivitäten als U-Boot oder Guerilla jeweils nicht so in die Unternehmensprozesse integriert sind, dass eine anschlussfähige UX Arbeit erledigt werden kann. Bei der U-Boot Strategie ist es nötig, den Anschluss an die Schnittstellen im jeweiligen Projekt zu gewährleisten und – wie bei der Guerilla Arbeit – auf lange Sicht die nächsten Ebenen zu gewinnen (Entscheider-Eskalation). Im Hinblick auf die Hierarchie gesprochen: Ein „Wake-up“ muss auf derselben Ebene und nach oben adressiert werden. In unseren Projekten heißt es dann: „Wir brauchen ja unsere Chefs im Boot“. Das ist in der Top-DownIntegration schon geschehen. Mit jeder UX Aktivität entsteht bei den Beteiligten mehr Bewusstheit über das Thema. Ob sich diese auch organisational niederschlägt, hängt davon ab, ob UX Maßnahmen in die Sprache der Organisation übersetzt werden (Simon, 2011). Aus der organisationalen Perspektive ist Guerilla UX nur „Rauschen“. Erst mit der Formalisierung kommt UX in der Organisation an. Sonst läuft es wie bei dem Industrieunternehmen, dessen UXSpezialisten klagten: „Wir haben doch alles schon so oft erzählt, es hört eh keiner zu!“ Hier gab es keinen Weg, die Erkenntnisse aus UX Projekten zu verarbeiten. Es ist so, als ob das Wissen nicht vorhanden wäre. In Reifegradmodellen finden wir deshalb Management-Praktiken (z.B. UsabilityRollen, Usability-Budget) die vom Ausmaß der Usability bzw. UX Integration künden (DAKKS Usability Leitfaden; Studie Usability in Germany, 2011). Aus unserer Sicht ist aber eine der wichtigsten Praktiken die Bildung organisationaler „Orte“ (Strukturen, Prozesse, Schnittstellen, z.B. „Ergebnisse der User Research zur Definition des MVP heranziehen“). Diese „Orte“ sind Voraussetzung, um andere Aspekte der Reife zu erreichen (zum Beispiel vorgelagerte Gestaltung).


Usability Professionals 2013 Workshop

Deshalb sollten die Reifegradmodelle das Ausmaß der Abstimmung der UX-Perspektive Mensch mit den anderen Perspektiven Business und Technologie berücksichtigen (solche Management-Praktiken wären z.B. die Schnittstellen zwischen UX, Business und Technologie schon in der Konzeption zu schaffen, oder eine Rolle, die die Integration der drei Perspektiven als ihre Aufgabe sieht). Was wir über unsere Beratung in diesem Feld gelernt haben Als externe Berater kommen wir i.d.R. über drei Anknüpfungspunkte mit Unternehmen in Kontakt: Produkte, Personen und Prozesse. An Produkten selbst setzen wir durch unser Angebot an Dienstleistungen wie Kontext-Analysen, Anforderungsdefinition, Testing an. Personen qualifizieren wir durch Trainings, Workshops und Mentoring. Die Prozesse betrachten und entwickeln wir, wenn wir gemeinsam mit unseren Kunden daran arbeiten, UX Abläufe zu gestalten oder UX in die Gesamtorganisation zu integrieren. Jeder dieser Ansatzpunkte ist für sich genommen wichtig. Im oben erwähnten Workshop, in dem wir als Berater ein UX-Team qualifizierten, bemerkten wir und das UX-Team, dass eine wirksame Veränderung in der besseren Abstimmung zwischen UX und agiler Entwicklung liegen würde, also in einer Veränderung der Prozesse (und nicht nur in einer Veränderung der Personen, die darin bestand, dass das UX-Team noch besser Bescheid wüsste). Im Projekt war unser beraterischer Ausgangspunkt das Thema „Person“, wir entdeckten jedoch, dass auch das Thema „Prozess“ eine Rolle spielt und es sinnvoll wäre, UX besser in den Kanon mit den anderen Triebkräften in Unternehmen in Einklang zu bringen.

der Spitze des Unternehmens angesetzt werden muss – an der Stelle, die das Zusammen­spiel der Bereiche sehen kann und die genügend Macht für organisationale Veränderungen hat.

Literatur 1. Bundesministerium für Wirtschaft und Techno­logie (2011). Abschlussbericht des Forschungsprojekts „Gebrauchstauglichkeit von Anwendungssoftware als Wettbewerbs­ faktor für kleine und mittlere Unternehmen

Wie oben berichtet, besteht die Herausforderung darin, die Perspektive des Kundennutzens als gleichberechtigt zu etablieren. In der strategischen Beratung arbeiten wir mit Unternehmen an Fragen wie –– „Welche Bedeutung hat die Perspek­ tive ‚Mensch/ Benutzer’ für uns?“ –– „Welche Rolle soll sie spielen?“ –– „Wie weit ist sie bei uns integriert?“

(KMU)“. Quelle: http://www.usability-ingermany.de/forschungsergebnisse (Stand: 08.07.2013) 2. DAKKS – Deutsche Akkreditierungsstelle (2010). Leitfaden Usability (Version 1.3). Frankfurt am Main. Quelle: http://www. dakks.de/sites/default/files/71-SD-2–007_ Leitfaden%20Usability%201.3.pdf (Stand 24.07.2013) 3. DIN EN ISO 9241–210 (2010). Ergonomie

Nach den Ergebnissen der Studie „Usability in Germany“ nehmen viele mittelständische Unternehmen (57% der Befragten), eine „hohe Usability seit längerer Zeit als wichtigen Aspekt des Unternehmenserfolges wahr“ (UIG, S. 111), die wenigsten definieren hierfür jedoch Vorgaben oder Kennzahlen.

der Mensch-System-Interaktion – Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme. Beuth Verlag. 4. Doppler, K., & Lauterburg, C. (2008). Change Management. Den Unternehmenswandel gestalten (12. Auflage). Frankfurt: Campus Verlag. 5. Hurtienne, J., & Prümper, J. (2007).

Wir haben gelernt, dass es Unternehmen hilft, neben den Zielen selbst auch deren Implementierung zu betrachten. Dann werden auch die Strukturen und Prozesse und die Personen und Beziehungen adressiert – wichtige Ebenen, auf denen Veränderungen in einem „Change“ stattfinden (Vahs, 2007). Nützlich sind hier Fragen wie: „Was braucht es für eine stärkere Integration?“ und „Woran merken wir, dass UX gut mit den anderen Perspektiven ‚vernäht’ ist?“ Als Antwort auf diese letzte Frage können wir geben: Wir merken es an den Personen, die mit dem Thema UX aufgeladen sind: UX ist kein Fremdwort mehr. Wir merken es an den Produkten: Man sieht – da war jemand dran. Wir merken es an den Prozessen: Die Schnittstellen zwischen UX, Technologie und Business sind klar verschaltet.

Vom Zauberer zum Partner – Usability Beratung im Spiegel organisationaler Reife. In V. Nissen (Hrsg.) Consulting Research. Unternehmensberatung aus wissenschaftlicher Perspektive (S. 309–327). Wiesbaden: Deutscher Universitätsverlag. 6. Gothelf, J., & Seiden, J. (2013). Lean UX: Applying Lean Principles to Improve User Experience. Sebastopol, USA: O‘Reilly Media. 7. Polkehn, K., & Hüttner, J. (2012). Dem UX-Pro­ fessional zugeworfene Themen gekonnt 8. auffangen: HCD-Aktivitäten maßschneidern. In: Usability Professionals 2012 – Tagungsband (S. 28–33). Quelle: http:// issuu.com/germanupa/docs/usabilityprofessionals-2012 (Stand: 30.07.2013) 9. Schaffer, E., & Lahiri, A. (2013). Institutionalization of UX: A Step-By-Step Guide to a User Experience Practice (2. ed.).

UX Integration braucht Macht – Ansatzpunkt Unternehmensstrategie Geht es um bereichsübergreifende Prozesse in Unternehmen, wird es nötig, dass andere Stakeholder über UX nachdenken, nicht nur „ein paar UX-Verantwortliche“. Es geht um eine strategische Entscheidung, über die „die Organisation“ nachdenken muss. Das bedeutet, dass an

Wir haben gelernt, dass wir als Dienstleister und Fachberater nützlich sein können, wenn wir auch im Bereich UX mit den Unter­nehmen über den Tellerrand schauen und an Themen wie Unternehmenszielen, Leitsätzen und Change zu arbeiten. Benutzerorientierung kann so integraler Bestandteil der Unternehmenskultur werden statt Insellösung, Guerilla oder U-Boot zu bleiben.

Boston: Addison Wesley Pub Co. Inc. 10. Simon, F. (2011). Einführung in die systemische Organisationstheorie (3. Auflage). Heidelberg: Carl Auer Verlag. 11. Vahs, D., & Leiser, W. (2007). Change Management in schwierigen Zeiten, Erfolgs­ faktoren und Handlungs­empfehlungen für die Gestaltung von Veränderungsprozessen (mit CD-ROM, 2. Nachdruck). Wiesbaden: Deutscher Universitäts-Verlag.

25


GUPA-AK-ROI UX Papier zur UP13, Bremen 2013-Sept Dr. Boris Oliver Kneisel Karlsruher Institut für Technologie (KIT) – EnTechnon (Inst. f. Entrepreneurship, Technologie-Mgmt und Innovation) Campus Süd, Geb. 01.85, Zähringerhaus 5. OG Fritz-Erler-Strasse 1–3, DE-76131 Karlsruhe Boris.Kneisel@kit.edu

Katharina Göring itCampus Software- und Systemhaus GmbH – a Software AG company Nonnenstrasse 37, DE-042229 Leipzig K.Goering@itcampus.de

Abstract Der GUPA Arbeitskreis „Return on investment on User-eXperience“ (kurz: AK-RoI UX) stellt sich in diesem Papier und dem zugehörigen Konferenz-Track kurz der ­GUPA-­Community vor.

Einführung Was ist ein RoI und was sagt RoI aus? Der Begriff „Return-on-Investment (RoI)“ wurde in den 1920ern durch die U.S. Firma DuPont geprägt und beschreibt die Rendite unternehmerischer Tätigkeit. Bei Investitionen ist es in vielen Industrien und Branchenzweigen gängig RoI-Kalkulationen zu erstellen, um abzusichern, dass nur Vorhaben realisiert werden, die sich „rechnen“. Projekte (u.a. auch UX-Aktivitäten) können analog zu sonstigen Investitionen dieser RoI-Logik unterzogen werden. (UX-) Projekte, die die notwendigen Investitionen (= Projekt-Kosten lt. Vorkalkulation) nicht innerhalb bestimmter Vorgabezeiträume wieder einspielen, unterbleiben.

Warum ist es wichtig UX-Arbeiten auf Basis von Kennzahlen zu monitoren und wieso ist u.a. der RoI auf UX-Projekte eine geeignete Kennzahl? UX-Projekte sind keine zusätzlichen, kleinen Verschönerungsprojekte mit wenigen Resourcen mehr. Sie unterliegen daher analog zu anderen Vorhaben (= alternative Investitions-Optionen) einem Selektionsprozess der ein risikogewichtetes Portfolio generiert, da oft nur begrenzte Ressourcen (Budget, Personal-Kapazität etc.) zur

26

Verfügung stehen … Für UX-Professionals ergibt sich hieraus 1. die Notwendigkeit sich mit RoI auseinanderzusetzen und 2. die Option RoI-Kalkulationen aktiv als Argument in der Projekt-Akquise für eigene Vorhaben zu nutzen. Historie des GUPA-AK-ROI UX (Why / How / What / Who) Der GUPA-AK-RoUX geht auf die M&C / UP11 in Chemnitz zurück. Im Rahmen von Konferenz-Gesprächen sinnierte man darüber, ob und falls ja, wie man die beiden Welten der „UX-Professionals“ und der „Projekt-Sponsoren“ enger miteinander verzahnen könnte. Dabei kam man zu der Einsicht, dass „man die beiden Welten aufeinander zugehen lassen müsste anhand einer gemeinsamen Sprachregelung & Kommunikations-Plattform“. „RoI“ war schnell als eine Schnittstelle identifiziert an der die Welten von „UX-Professionals“ und „Projekt-Sponsoren“ aufeinanderstossen, ohne die jeweils andere Sicht tief zu verstehen. Der Aufbau eines gegenseitigen Verständnisses für die Sicht der jeweils anderen Perspektive schien sich daher u.a. an Themen rund um RoI festmachen zu lassen. Im Nov 2011 gründete sich der GUPAAK-ROI UX (AK-Gründer: Boris Kneisel, Katharina Göring und Andreas Hinderks).

Keywords: /// RoI /// Return on investment /// UX Quantifizierung /// UX measures /// Kosten-Nutzen-Kalkulation

Zielsetzung des GUPA-AK-ROI UX AK-Ziele sind „Erweiterung der Wissensbasis“ und „thematische Vernetzung“ rund um „Rentabilität von UX-Vorhaben“. Nach der Scopingphase hat der AK 2012 begonnen sich in der GUPA mit anderen AKs zu vernetzen. Mitglieder des AK-ROI UX sind in enger Abstimmung z.B. mit AK-Qualitätsstandards und AK-UserResearch – weitere AK-Kooperationen sind in Arbeit. Der AK-ROI UX besteht aktuell aus 5 Mitgliedern. Aktueller Stand bei UX-Projekten Weder ein im Vorfeld kalkulierter PlanRoI, noch ein durch Messung bestimmter, realisierter RoI ist für UX-Projekte Stand 2013 die Regel – RoI wird in wenigen Fällen explizit bestimmt. Häufig scheinen die notwendigen Basisdaten zur RoI-Kalkulation bzw. Messung nicht oder nur unvollständig vorzuliegen. In den wenigen Fällen, in denen zumindest die notwendigen Basis-Daten vorliegen und anschliessend auch eine RoI-Kalkulation durchgeführt wird, werden die Ergebnisse kaum systematisch zur Entscheidungsfindung verwandt. UX-Projekte gelten gemeinhin als „optionale Aufhübscher“, weil der Terminus „UX“ gerade „hip“ ist und es als chic gilt, „sich ein UX-Projekt zu


Usability Professionals 2013 Workshop

leisten“. In Organisationen mit derartigem Mind-set sind UX-Projekte im Rahmen von Budget-Kürzungen oft die Streich-Kandidaten der ersten Runde. Eine mögliche Ursache hierfür ist mangelnde Integration von UX-Prozessen in die Gesamt-Wertschöpfungskette des Unternehmens. UXProfessionals haben bisher oft noch keine sauber abgestimmte Rollen-Definition, Abgrenzung von Verantwortlichkeiten und kein holistisches Gesamt-Arbeitsmodell mit Unternehmensfunktionsbereichen wie Entwicklung / ProduktMgmt / Marketing gefunden.

Generierung entsprechender Surveys und die Organisation bzgl. ROI UX-Erst-Erhebung fokussieren. Literatur 1. BIAS, R.G. & MAYHEW, D. J. (2005). Costjustifying Usability – An Update for the Internet Age. Morgan Kaufmann (Elsevier), Burlington, MA, U.S. 2. KOLLER, T. et al. 2005. Valuation – Measuring and Managing the Value of Companies. Hoboken, NJ, U.S., John Wiley & Sons, Fourth Edition 3. TULLIS, T. & ALBERT, B. (2008). Measuring the User Experience: Collecting, Analyzing,

Lösungsansätze bestehen im Aufbau interdisziplinärer Teams. Diese sollten aus sog. „T-shaped“ Individuen bestehen. „T-shapes“ besitzen stark ausgeprägte Tiefen-Expertise in mindestens einer Domäne (z.B. Marketing, Entwicklung/ Engineering, UX/Usability) und gleichzeitig grosse Offenheit für andere Themen und Neugier. Die Tiefen-Domäne ist der Pflock im „T“, die Offenheit der Querträger des “T“. Klassische Unternehmensabteilungen sind im Arbeitsmodell interdisziplinärer Teams eher lose Klammern einer Linienorganisation mit fallender Bedeutung. Die Aufstellung solcher Teams für R&DAktivitäten ist seit dem Übergang Agiler Entwicklungsmethoden in den Mainstream ein de-facto Standard und schliesst UXAktivitäten mit ein.

and Presenting Usability Metrics. Morgan Kaufmann (Elsevier), Burlington, MA, U.S. 4. BROWN, T. 2008. Design Thinking. Harvard Business Review (Jun) 84–92. 5. THOMKE, S. & REINERTSEN, D. 2012. Six Myths of Product Development. Harvard Business Review (May) 84–94. 6. KOTTER, J. 2012. Accelerate. Harvard Business Review (Nov) 44–58. 7. BLANK, S. 2013. Why the Lean Start-Up Changes Everything. Harvard Business Review (May) 3–9. 8. KIM, D. 2013.The State of Scrum: Benchmarks & Guidelines, ScrumAlliance in ProjectsAtWork (June).

Unser Vorgehen Seit AK-Gründung treffen wir uns regelmässig ca. alle 6–8 Wochen in zentraler Lage im Rhein-Main-Gebiet. Nächste Schritte Der AK-ROI UX stellt basierend auf typischen Projekterfahrungen RoI-Argumentationshilfen zusammen. Weiterhin regt der AK-ROI UX an, in Bremen zur UP13 die Diskussion aufzunehmen, ob die GUPA als Interessenverband der UX-Professionals in Deutschland z.B. den jährlichen Branchenreport um ein Kapitel State-of-ROI UX erweitern sollte. Bei erkennbarem Bedarf sollte sich die Diskussion auf die

27


„Do You Speak Usability?“ Aktueller Stand des Glossars und des Curriculums für den „Certified Professional for Usability and User Experience (CPUX)“ der German UPA Holger Fischer Universität Paderborn, C-LAB Fürstenallee 11 33102 Paderborn holger.fischer@c-lab.de

Oliver Kluge Versicherungskammer Bayern Maximilianstraße 53 80538 München oliver.kluge@vkb.de

Thomas Geis ProContext Consulting GmbH Von-Werth-Straße 33–35 50670 Köln thomas.geis@procontext.de

Rüdiger Heimgärtner Intercultural User Interface Consulting Lindenstraße 9 93152 Undorf ruediger.heimgaertner@iuic.de

Rolf Molich DialogDesign Skovkrogen 3 3660 Stenløse, Dänemark molich@dialogdesign.dk

Peter Hunkirchen Fraunhofer FIT Schloss Birlinghoven 53754 Sankt Augustin peter.hunkirchen@fit.fraunhofer.de

Abstract Sprechen wir Usability/UX Professionals wirklich „eine“ Sprache oder reden wir munter aneinander vorbei? Werden wir von unseren Kunden wirklich verstanden oder hören diese von jedem „Usability Experten“ etwas anderes? Die Gemeinschaft der Professionals ist in Deutschland im Laufe der letzten Jahre stetig gewachsen. Diese Community lässt sich dabei in zwei Gruppen aufteilen: Personen mit einer einschlägigen Ausbildung (bspw. Studium mit entsprechendem Usability/UX-Anteil) und Quereinsteiger im Themengebiet Usability/UX. Die international divergente Begriffswelt hat sich dabei national fortgesetzt. Auf Basis des „Qualitätsstandard für Usability Professionals“ arbeitet der German UPA Arbeitskreis Qualitätsstandards an einer vereinheitlichten Begriffswelt im deutschsprachigen Raum und entwickelt dazu ein entsprechendes Glossar. Zudem wurde ein Curriculum erstellt, anhand dessen Personen gemäß dem Motto „Do you speak usability?“ die Prüfung zum „Certified Professional for Usability and User Experience – Foundation Level (CPUX-F)“ ablegen können. Sowohl Glossar als auch Curriculum dienen als Kommunikationsgrundlage zur informierten Verständigung zwischen Usability-Einsteigern, UsabilityProfessionals, Projektverantwortlichen, Entwicklern etc.

1. Herausforderungen und Ziele Die letzten zwanzig Jahre betrachtend, hat sich das Themengebiet der Usability und später auch das der User Experience wesent­lich weiterentwickelt. Dies lässt sich unter anderem am aktuellen Branchenreport Usability 2012 (Diefenbach et al., 2012) der German UPA ablesen. Insbesondere auch im Bereich von kleineren und mittleren Unternehmen gewinnt der Einsatz gebrauchstauglicher Anwendersoftware an Bedeutung (Woywode et al., 2012), was nicht zuletzt auf die „[…] Erreichung be­triebs­wirtschaftlicher Ziele wie die Stei­gerung von Produktivität,

28

Qualität und Kundenzufriedenheit sowie die Erfüllung industriespezifischer Standards zur Dokumentation und Nachvollziehbarkeit der Unternehmensaktivitäten“ zurückzuführen ist. Jedoch bestehen in der betrieblichen Praxis noch eine Vielzahl an Herausforderungen, um eine angemessene Sicherstellung menschzentrierter Aktivitäten in der Systementwicklung zu gewährleisten (Seffah et al., 2005). Eine systematische Einbeziehung realer Benutzer ist daher notwendig, um interaktive Systeme mit einer vorhersagbaren Gebrauchstauglichkeit zu entwickeln (DIN EN ISO 9241–210).Zwei dieser wesentlichen Herausforderun­gen – bestätigt durch eine Studie im Auf­trag des

Knut Polkehn artop GmbH Christburger Straße 4 10405 Berlin polkehn@artop.de

Keywords: /// Usability /// User Experience /// Curriculum /// Glossar /// Zertifizierung

BMWi (Woywode et al., 2012) – existieren in Form eines „Professionali­sierungs-Gap“ sowie eines „Lehre- und Forschung-Gap“. Diese bestehen darin, dass die Ausbildung zum Thema Gebrauchs­tauglichkeit nur ein Randgebiet in der Nachwuchsausbildung darstellt und die Hochschullandschaft eher noch heterogen ausgerichtet ist. „Der Mangel an spezifischen, interdisziplinären Ausbildungsoptionen wird häufig als zentrales Hemmnis der Verbreitung des Themenfeldes Usability angesehen“ (Woywode et al., 2012). Ebenso lässt sich eine Strukturierung des Arbeitsmarktes erst in Anfängen beobachten. Software-Herstellern fällt es daher schwer, auf Grund einer nicht existierenden


Usability Professionals 2013 Workshop

Verbreitung einheitlicher Berufsbilder bzw. -abschlüsse, qualifiziertes Personal auszuwählen und einzustellen (Woywode et al., 2012). Bestätigt werden diese Lücken durch den Branchenreport Usability 2012 (Diefenbach et al., 2012). In Bezug auf die Frage, welche Herausforderungen, Forderungen und Wünsche die Befragten stellen, antworteten 10% der Befragten, dass sie „[…] eine klare Definition des Berufs­bildes, möglicherweise auch in Form einer Zertifizierung fordern“ (Diefenbach et al., 2012). Im Rahmen des German UPA „Qualitäts­ standards für Usability Engineering“ (Behrenbruch et al., 2012) wurde bereits ein Kompetenzrahmen für Usability Engineering (Fischer et al., 2012) betrachtet. Dabei zeigte sich, dass Kompetenzen im Bereich Usability weitaus mehr als nur theoretisches Wissen umfassen. Insbeson­dere auch praktische Fertigkeiten sowie personale und soziale Aspekte, bspw. empathische Kommunikation oder Perspektivenübernahme, sind von Relevanz. Um einen ersten Schritt in Richtung Zerti­fizierung zu ermöglichen, wurde zunächst ein Curriculum entwickelt, auf dessen Basis grundlegende Konzepte und Begriffe im Bereich Usability und User Experience geprüft werden können. Resultierend daraus wurden inzwischen erste Pilot-Zertifizierungen zum „Certified Professional for Usability/UX – Foundation Level (CPUX-F)“ durchgeführt. Struktur und Hintergrund dieser Zertifizierung werden im weiteren Verlauf dieses Beitrages näher erläutert. Dazu bedarf es zunächst der Betrachtung einiger Grundlagen, die als Basis der Zertifizierung dienen. 2. Grundlagen Wesentliche Dokumente, auf denen das Curriculum als auch das Rahmenkonzept der Zertifizierung zum CPUX-F basieren, sind der German UPA „Qualitätsstandards für Usability Engineering“ (Behrenbruch et al., 2012), die German UPA Fachschrift „Berufsfeld Usability/UX“ (Bogner et al., 2011) sowie existierende Zertifizierungsprogramme im Bereich des Requirements Engineering und Testing (bspw. ISTQB, IREB).

2.1. Qualitätsstandard für Usability Engineering Der Qualitätsstandard für Usability Engi­ neering wurde in seiner ersten Version im April 2012 durch den German UPA Arbeitskreis Qualitätsstandards veröffentlicht. Ziel dabei ist es den Zugang zu internationalen Stan­dards zu vereinfachen, so dass Produkt- und Prozessverantwortliche ­unterschiedlicher Herkunft den Entwicklungsprozess ­ver­stehen, ihn verankern, aber auch einen konkreten Prozess mit Aktivitäten und daraus resultierenden Arbeitsprodukten beschreiben können. Die Zielgruppe des Qualitätsstandards ist divergent und erhebt unterschiedliche Ansprüche an die Durchführung eines menschzentrierten Ge­staltungsprozesses. Neben UsabilityProfessionals, die sich konkrete Handlungsanweisungen wünschen, gehören auch Auftraggeber, Aus- und Weiterbildungsinstitute sowie Personen-Zertifizierungsstellen dazu, die Klarheit über benötigte Kenntnisse, Fertigkeiten und Kompetenzen fordern. Alltägliche Einsatzszenarien aus dem Projektgeschäft bieten einen leichten Einstieg zu den Inhalten des Qualitätsstandards, indem sie mit den zu ­berücksichtigenden Abschnitten im Dokument verknüpft wurden. Kern des Dokumentes stellt eine Detaillierung der einzelnen Prozessschritte dar. Dabei werden sowohl der „Zweck des Prozesses“ begründet, wie auch der „Zustand nach [erfolgreicher] Durchführung“ definiert. Zudem werden „Empfohlene Aktivitäten zur Durchführung“ sowie „Arbeitsprodukte“ angegeben, um eine gewisse Qualität der Ergebnisse zu gewährleisten. Gekoppelt sind die einzelnen Schritte außerdem mit entsprechenden Rollen im gesamten Entwicklungsprozess (bspw. Projektleiter), die entweder Verantwortlichkeiten besitzen, durchführende Positionen einnehmen oder zumindest informiert werden sollten. Dabei wird unter anderem auch auf das Rollenmodell gemäß der German UPA Fachschrift „Berufsfeld Usability“ (Bogner et al., 2011) zurückgegriffen.

2.2. Usability Professionals Gemäß der Fachschrift „Berufsfeld Usability“ (Bogner et al., 2011) ist ein Usability Professional „[…] eine Person, die qualifiziert und methodisch die Anforderungen an die Gebrauchstauglichkeit (Usability) interaktiver Systeme (Hardware und Soft­ware) herleitet, umsetzt oder deren Um­setzung überprüft“. Verglichen mit anderen Berufsbildern ist der Beruf des Usability Professionals eher jung, so dass weder im deutschsprachigen noch im internationalen Raum ein kohärentes Bild der Tätigkeiten und Prozesse in Bezug auf die Themen Usability und User Experience (UX) besteht. In Anlehnung an die Kernaktivitäten einer menschzentrierten Gestaltung (DIN EN ISO 9241–210) entwickelten Bogner et al. (2011) ein Modell bestehend aus sechs Prozessrollen: –– Usability Engineer: Verantwortet als Querschnittsrolle die Planung sowie Durchführung eines menschzentrierten Gestaltungsprozesses und integriert diesen in den Produktentwicklungs­ prozess eines Unternehmens. Dabei definiert er Erfolgskriterien in Bezug auf die Gebrauchstauglichkeit, trainiert die beteiligten Projektteams und legt zu erbringende Arbeitsergebnisse, zu berücksichtigende Richtlinien und durchzuführende Methoden in Absprache mit den anderen Prozess­ rollen fest. –– User Requirements Engineer: Analysiert und beschreibt den Nutzungs­­kontext inkl. der Benutzer, deren Aufgaben sowie der physi­­ kalischen und sozialen Umgebung. Auf Basis des Nutzungskontextes identifiziert er die Erfordernisse der Benutzer, leitet Nutzungsan­­ forderungen ab und priorisiert diese für die Berücksichtigung im Projekt. –– Interaktionsdesigner: Konzipiert die Interaktion zwischen den Benutzern und dem technischen System, wobei er die Nutzungsanforderungen berücksichtigt und die Ziele der Effektivität, Effizienz und Zufrieden­ stellung bei der Aufgabenerledigung sicherstellt.

29


–– Informationsarchitekt: Erarbeitet die Informationsstruktur des Systems in Bezug auf die nutzergruppengerechte Aufbereitung von Inhalten und Navigationsstrukturen und schafft eine konsistente und erwartungskonforme Bezeichnung der Interaktionsobjekte (bspw. Menüs). –– User Interface Designer: Gestaltet die Benutzungsschnittstelle unter Berücksichtigung der Nutzungs­ szenarien und erstellt Prototypen. –– Usability Tester: Validiert zusammen mit im Projekt beteiligten Benutzern die Zwischenergebnisse (Nutzungs­ anforderungen, Szenarien, Konzepte, etc.) im Verlauf der Entwicklung und verantwortet die Durchführung von Usability-Test, Studien und Expertenevaluationen sowie die Kommunikation der Ergebnisse. Das Rollenmodell dient als Grundlage für die Struktur des in Abschnitt 3 beschriebenen Zertifizierungsmodells. 2.3. Zertifizierungsprogramme Neben einer inhaltlichen Ausgestaltung ist ebenfalls das organisatorische Rahmenwerk einer Zertifizierung wesentlich. Daher wurden etablierte Zertifizierungsprogramme aus den Bereichen Requirements Engineering und Testing betrachtet. Das Hauptaugenmerk lag dabei auf den beiden Programmen –– International Software Testing Qualification Board (ISTQB, http:// www.istqb.org) mit dem Certified Tester Foundation Level (CTFL) bzw. Advanced Level (CTAL) sowie –– International Requirements Engineering Board (IREB, http://www. certified-re.de) mit dem Certified Professional for Requirements Engineering (CPRE). Fazit der Begutachtung, ist die grundsätzliche strukturelle Einteilung der Zertifizierungsstufen in eine Grundlagenprüfung („Foundation Level“) sowie mehrere weiter­führende Prüfungen („Advanced Level“ und „Expert Level“)

30

unterschiedlicher Ausprägung. Die Grundlagenprüfung wird mittels eines Fragebogens gemäß des Multiple-Choice-Prinzips durchgeführt. Diese umfasst 40–45 Fragen, die in jeder Prüfung variieren. Exemplarische Fragen mit Lösungen stehen den Teilnehmern zur Verfügung. Für den Erhalt einer Zertifizierung ist eine kritische Marke von 60–65% richtig beantworteter Fragen notwendig. Die Dauer einer Prüfung beträgt zwischen 60–75 Minuten. Bei weiterführenden Prüfungen wird teilweise der Nachweis einer mehrjährigen Tätigkeit im jeweiligen Berufsfeld vorausgesetzt bzw. Fähigkeiten im Rahmen eines mündlichen Gespräches geprüft. Inhalte des „Qualitätsstandards für Usability Engineering“, relevante ISO Standards (Geis et al., 2010) und der Fachschrift „Berufsfeld Usability“ sowie Erkenntnisse aus den etablierten Zertifizierungsprogrammen dienen somit sowohl als inhaltliche als auch als organisatorische Basis für den Certified Professional for Usability/UX, welcher im Folgenden beschrieben wird. 3. Certified Professional for Usability and UX Der Arbeitskreis Qualitätsstandards der German UPA befasst sich bereits seit 2011 mit der Ausgestaltung eines Kompetenzrahmens für das Usability Engineering, welcher unter anderem als Grundlage für eine mögliche Zertifizierung dienen soll. Dieser Kompetenzrahmen basiert dabei im Wesentlichen auf dem Rollenmodell des „Berufsfeld Usability“ (Bogner et al., 2011) und den im „Qualitätsstandard Usability Engineering“ (Behrenbruch et al., 2012) formalisierten Aktivitäten eines humanzentrierten Gestaltungsprozesses. 3.1. Kompetenzrahmen „Usability Engineering“ Kompetenz wird als ein nicht direkt beobachtbares Konstrukt verstanden, das durch die drei Dimensionen Struktur, Niveau und Erfassung beschrieben werden kann und durch definierte Handlungen, also nicht

durch spezialisierte Methoden oder Techniken, konstituiert wird (PAS 1093, 2009). Ein Usability Professional sollte daher in der Lage sein, definierte Handlungen durchzuführen sowie adäquate Methoden auszuwählen und anzuwenden, um qualitative Ergebnisse für seine Aufgabe zu erzielen. Da die Auswahl der Methode abhängig vom jeweiligen Kontext eines Projektes ist, sollten im Rahmen der Qualifizierung oder Zertifizierung von Personen keine bestimmten Methoden zwingend vorgeschrieben werden. Mit dem Kompetenzrahmen soll vielmehr eine verlässliche Basis geschaffen werden, anhand derer Usability Professionals geeignete Auswahlkriterien erlernen können, um im jeweiligen Handlungsfeld autonom die richtigen Entscheidungen zu treffen. Basierend auf der Norm DIN EN ISO 9241– 210 (2010) konnten acht Handlungsfelder identifiziert werden, die von den sechs entsprechenden Rollen des Berufsfeldes Usability (siehe Abschnitt Fehler! Verweisquelle konnte nicht gefunden werden.) ausgeübt werden: 1. Planung der menschzentrierten Gestaltung 2. Den Nutzungskontext verstehen und beschreiben 3. Die Nutzungsanforderungen spezifizieren 4. Gestaltungslösungen entwerfen, die die Nutzungsanforderungen erfüllen 5. Gestaltungslösungen aus der Benutzerperspektive evaluieren und verwerten 6. Das Produkt bei den Benutzern einführen 7. Langzeitbeobachtungen 8. Den Usability Engineering Prozess organisieren (überwachen und steuern) Zur Definition des Kompetenzrahmens werden zu jedem Handlungsfeld eines Usability Professionals in Anlehnung an den europäischen Qualifikationsrahmen (EQR, 2012) drei Komponenten von Kompetenz betrachtet. Neben Kenntnissen über Theorie und/oder Faktenwissen sowie kognitiven und praktischen Fertigkeiten, wird auch die Kompetenz im Sinne der Übernahme von Verantwortung und Selbstständigkeit


Usability Professionals 2013 Workshop

berücksichtigt. Der deutsche als national angepasster Qualifikationsrahmen unterscheidet zusätzlich zwischen personalen und sozialen Kompetenzen. Die Teilbereiche „Wissen“, „Fertigkeiten“ und „Kompetenzen“ (personale und soziale) bilden eine untrennbare Einheit und bestimmen in ihrer Gesamtheit die individuelle Kompetenz einer bestimmten Person. Beispielsweise sollte ein Usability-Engineer, um im Handlungsfeld „Nutzungskontext verstehen und beschreiben“ (siehe Abbildung 1) wirksam zu sein, als MindestKompetenzen unter anderem die Dimensionen des Nutzungskontextes nach ISO

9241–11 kennen (Kenntnisse), „aktives Zuhören“ beherrschen (Fertigkeiten) sowie die Fähigkeit zur empathischen Kommunikation besitzen (personale und soziale Kompetenz). [Tab. 1] Auf Grund von zunehmenden Wünschen einer Zertifizierung im Bereich Usability und User Experience wurde der Fokus zunächst vom Kompetenzrahmen Usability Engineering auf einen „Usability Führerschein“, also einer Grundlagenzertifizierung über das Verständnis wesentlicher Begriffe und Konzepte, gelegt. Dieser wird demnächst für die Ausgestaltung weiterführender Zertifizierungen weiter ausgearbeitet, die

über ein gemeinsames Grundverständnis hinausgehen. Basierend auf denen im Qualitätsstandard formalisierten Aktivitäten wurde ein Curriclum für eine Grundlagenzertifizierung inklusive eines entsprechenden Glossars, einer Beschreibung zum Zertifizierungsprozess und einem Satz öffentlicher Prüfungsfragen erstellt. Das Ergebnis liegt in Form einer Zertifizierung zum „Certified Professional for Usability and User Experience – Foundation Level (CPUX-F)“ vor. Entsprechende Dokumente sind über die Internetseite zum Zertifizierungsprogramm der German UPA verfügbar (German UPA, 2013).

Usabiliy-Engineer

Spezialist (User Requirements Engineer)

Mindest-Kompetenzen, um als Usability-Engineer im Handlungsumfeld „Nutzungskontext verstehen und beschreiben“ wirksam zu sein

Zusätzlich notwendige Kompetenzen, um als Spezialist Engineer im Handlungsfeld „Nutzungskontext verstehen und beschreiben“ wirksam zu sein

Theorie (Wissen) Definition im Nominalstil

–– Dimensionen des Nutzungskontexte nach ISO 9241-11 –– Arbeitswissenschaftliche Anforderungen über vollständige Tätigkeiten (vgl. ISO 9241-2) –– Relevante Ansätze, um Nutzungskontexte zu erheben, zu beschreiben und zu kommunizieren –– Grundlegende Methoden zur Erhebung, Beschreibung Kommunikation des Nutzungskontextes –– Kriterien zur Auswahl geeigneter Methoden –– Grundlagen der Kommunikation –– Verhaltensregeln, Gesprächsregeln, Checklisten

–– Vertieftes Wissen über Ziele, Aufbau und Wirkungsweisen der eingesetzten Methoden –– Kriterien zur Anpassung und Weiterentwicklung grundlegender Ansätze und Methoden für spezifische Fragestellungen –– Kriterien zur Auswahl geeigneter Benutzergruppen –– Verfahren zur Akquise geeigneter Benutzergruppen

Praxis (Fertigkeiten) Definition im Verbalstil

–– Geeignete grundlegende Methoden zur Erhebung, Beschreibung und Kommunikation der Kontextanalyse auswählen –– Validierung der Beschreibung des Nutzungskontextes durchführen –– „Aktives Zuhören“

–– Entscheiden, ob grundlegende Methoden zur Erhebung, Beschreibung und Kommunikation der Kontextanalyse an spezifische Fragestellungen angepasst bzw. weiterentwickelt werden müssen –– ggf. Identifikation alternativer Methoden –– Anpassung oder Weiterentwicklung grundlegender Methoden zur Erhebung, Beschreibung und Kommunikation der Kontextanalyse –– Erhebung eines Nutzungskontextes eigenverantwortlich durchführen –– Nutzungskontexte kommunizierbar beschreiben –– Optimierungsbedarf im Nutzungskontext identifizieren

Personale und Soziale Aspekte

–– Fähigkeit zur Perspektivenübernahme ohne Nutzungskontext offensiv zu beeinflussen (Interviewpartner nicht unterbrechen, nicht kritisieren, Lösungsvorschläge machen etc.) –– Selbstwirksamkeit bezogen auf soziales Verhalten (auf Menschen zugehen, Kontakte herstellen, Menschen ansprechen) –– Fähigkeit zur emphatischen Kommunikation

–– Kreativität, Gestaltungsfähigkeit, Offenheit, neue Lösungen entwickeln, bei Bedarf von typischen Lösungen abweichen, neue Wege beschreiten –– Bei Bedarf offensives Verhalten, für eigenes Anliegen kämpfen, Durchsetzungsfähigkeit –– Hohe Selbstwirksamkeit bezogen auf projektbezogene eigene Ziele, Handlungen und Beiträge J

Tab. 1. Handlungsfeld „Nutzungskontext verstehen und ­beschreiben“

31


3.2. Curriculum CPUX-F Das Curriculum (Lehrplan) umfasst alle The­men und Konzepte, auf welche die Prüfungs­fragen Bezug nehmen. Es ist in Unterrichtseinheiten strukturiert, die je­doch für Anbieter entsprechender Trainings nicht verpflichtend sind, d.h. die Reihenfolge der Themen und die Ausgestaltung von Übungen bleibt dem Anbieter überlassen. Folgende acht Unterrichtseinheiten sind Inhalt des Curriculums: 1.1. Grundlegende Begriffe und Konzepte 1.2. Verstehen und Spezifizieren des Nutzungskontextes 1.3. Spezifizieren der Nutzungsanforderungen 1.4. Entwickeln von Designlösungen 1 – Usability Prinzipien und Richtlinien 1.5. Entwickeln von Designlösungen 2 – Spezifizieren der Interaktion 1.6. Evaluierung des Designs 1 – Usability-Test 1.7. Evaluierung des Designs 2 – Andere Evaluierungsmethoden 1.8. Prozessmanagement und Verwendung von Methoden So werden neben den „klassischen“ vier Kernaktivitäten rund um 1) den Nutzungskontext, 2) den Nutzungsanforderungen, 3) Entwickeln von Designlösungen sowie 4) Evaluationen auch grundlegende Begriffe und Konzepte (bspw. interaktives System, Benutzungsschnittstelle, Effektivität, Effizienz, Zufriedenstellung) sowie das Thema Prozessmanagement (u.a. Verantwortlichkeiten, Angemessenheit von Methoden) berücksichtigt. 3.3. Glossar CPUX-F Die Usability Begriffswelt ist sowohl im internationalen als auch im nationalen Raum innerhalb der Community divergent, so dass ein Glossar von essentieller Bedeutung ist, um eine gemeinsame Kommunikationsebene für ein Curriculum zu schaffen. Ursachen hierfür sind beispielsweise in unterschiedlichen fachlichen Ausrichtungen (Design, Informatik, Psychologie, etc.) oder in länderspezifischen Kulturen zu finden.

32

Betrachten wir exemplarisch den Begriff des „Szenario“, so lässt sich feststellen, dass der Begriff in unterschiedlichen Ausprägungen verwendet wird. Somit existieren sowohl deskriptive Szenarien, welche auf empirischen Daten aus der Nutzungskontextanalyse beruhen, als auch präskriptive Szenarien, welche auf konstruierten Daten basieren und die die zukünftige Aufgabenerledigung oder Interaktion am System beschreiben. In die erste Kategorie lassen sich bspw. Kontextszenarien (DAkkS, 2010), Problemszenarien (Rosson & Carroll, 2002) oder im weiteren Sinne auch Persona (Pruitt & Adlin, 2006) einordnen. Zur zweiten Kategorie gehören demnach bspw. Aktivitätsszenarien und Interaktionsszenarien (Rosson & Carroll, 2002) sowie User Stories (Cockburn, 2000). Daher wurde ein Glossar erstellt, welches die im Curriculum und in den Zertifizierungsfragen verwendeten Begriffe und deren Definitionen auflistet. Dabei wurden einerseits normierte Begriffe verwendet, bspw. die Gebrauchstauglichkeit aus der DIN EN ISO 9241–210, als auch bisher nicht normierte Begriffe definiert und mit Beispielen und Kommentaren angereichert, bspw.: –– Handlungsleitung (engl. Affordance): Aspekte eines Objektes, die klar machen, wie das Objekt benutzt werden kann. –– Intuitiv: Die Benutzung des interaktiven Systems ist unmittelbar zu verstehen – unabhängig von der Erfahrung, des Wissens, der Sprachkenntnisse oder des momentanen Konzentrationsgrades des Benutzers. –– Nutzungsanforderung – Qualitativ: Eine Beschreibung, was Benutzer während der Durchführung einer Aufgabe mit dem interaktiven System erkennen, auswählen oder eingeben müssen. –– Nutzungsanforderung – Quantitativ: Geforderte Leistung, die die Basis für Design und die Evaluierung eines interaktiven Systems darstellt, mit dem Ziel, identifizierte Erfordernisse zu befriedigen.

Zusammen mit dem Curriculum bildet das Glossar die inhaltliche Ausgestaltung der Zertifizierung zum CPUX-F. 3.4. Anforderungen CPUX-F Das aktuelle Zertifizierungsprogramm spiegelt allgemein akzeptierte gemeinsame Praktiken von Usability Experten wieder und basiert über den Qualitätsstandard auf anerkannten internationalen Standards, insbesondere der ISO 9241 Serie, der ISO/ IEC TR 25060 (2010) sowie dem UXPA Body of Knowledge (http://www.usabilitybok. org). Somit soll eine weltweite Anwendbarkeit sichergestellt werden. Eine Person mit einem „CPUX Foundation Level“-Zertifikat kennt die grundlegenden Fachbegriffe im Bereich Usability und User Experience. Zudem versteht sie die grundlegenden Techniken und Methoden des Usability Engineerings und deren Anwendung. Organisatorisch dauert eine entsprechende Zertifizierungsprüfungen 75 Minuten und besteht aus 40 Multiple-Choice-Fragen. Ab einer erreichten Gesamtpunktzahl über 28 von 40 erreichbaren Punkten (70%) wird ein Zertifikat ausgestellt. Eine exemplarische Prüfungsfrage sieht wie folgt aus: „Sie werden gebeten, einen Usabilitytest für die Autovermietungswebseite von Sixt. com mit durchschnittlichen Benutzern zu machen. Welche der folgenden Aufgaben ist eine angemessene Testaufgabe für den Usabilitytest? 1. Wie lautet der Name des Geschäftsführers von Sixt? 2. Teilen Sie mir bitte mit, was Sie über die Homepage von Sixt denken. 3. Nehmen wir an, Sie sind ein Firmenkunde. Wie kann Sixt Ihnen helfen zu sparen? 4. Mieten Sie einen Kleinwagen am Frankfurter Flughafen ab 15. Februar 9 Uhr. Sie planen den Wagen am gleichen Ort am 19. Februar um 11 Uhr zurückzugeben. 5. Worüber berichtete die letzte Pressemitteilung von Sixt?


Usability Professionals 2013 Workshop

6. Nehmen wir an, Sie sind Donald Duck und Sie haben ein Auto am Flughafen von Duckburg reserviert. Bitte stornieren Sie die Reservierung. Ihr Benutzername ist Goofy und Ihr Passwort ist Daisy.“ Richtig dabei wäre Antwort 4. Die Antworten 1, 3 und 5 sind von zu geringem Interesse für durchschnittliche Benutzer und sind zu unspezifisch formuliert. Antwort 2 ist ebenfalls falsch, da hier eine Meinung und nicht die Durchführung einer Testaufgabe gefordert wird. Antwort 6 ist lediglich lustig. 3.5. Evaluation Das Zertifizierungskonzept wurde in mehrfachen Iterationen evaluiert bei denen auch die Prüfungsfragen mittels zweier Prototyp-Sessions in Deutschland und den USA von mehr als 100 Usability Professionals getestet wurden. Nachdem das Curriculum und das Glossar zunächst im Rahmen des Arbeitskreises in Form von Workshops umfangreich diskutiert und überarbeitet wurde, konnten auf internationaler Ebene am Rande des Konsortialtreffens eines ISO Gremiums weitere Begutachtungen in Form von Expertenreviews

eingeholt werden. Nachdem ein abschließendes Expertenreview durch den Vorstand der German UPA durchgeführt war, konnten im Juni 2013 im Rahmen eines zweitägigen Pilot-Workshops erstmals die Inhalte des Curriculums und Glossars vermittelt sowie zertifiziert werden. Dabei wurden insgesamt 23 Personen, in Bezug auf Usability und UX, durch zwei Prüfer entsprechend vorbereitet und anschließend geprüft. Fünfzehn Personen nahmen dabei am Vorbereitungsseminar teil, während weitere Personen sich im Selbststudium vorbereiteten. Die Gruppengrößen sind ungeplant abweichend, da eine Vielzahl von kurzfristigen Absagen in der Selbststudiumsgruppe vorlag. Zum Bestehen der Prüfung waren wie oben ausgeführt 70% korrekte Antworten gefordert. Diese Hürde wurde von 22 der 23 Teilnehmer überschritten, in einem Fall jedoch denkbar knapp (Brau, 2013). Dieses insgesamt sehr gute Abschneiden war erwartungskonform, da die Mehrheit der Teilnehmer bereits mehrjährige praktische Erfahrungen als Usability/UX Professional hatten und somit den fachlichen Reifegrad des Foundation Levels überschritten. Hiermit lässt sich wahrscheinlich auch erklären, dass zwischen der Seminarund der Selbststudiumsgruppe keine

signifikanten Unterschiede hinsichtlich des Prüfungserfolgs nachgewiesen werden konnte, obschon das Seminar durch die Teilnehmer in der Evaluation als sehr positiv bewertet wurde. Abbildung 2 gibt die Ergebnisse in den jeweiligen Gruppen schematisch wieder. [Abb. 1] 20 Teilnehmer füllten nach der Prüfung einen Bewertungsbogen zu Prüfungsevaluation aus. Die Ergebnisse legen nahe, dass die Prüfungsdurchführung insgesamt positiv wahrgenommen wurde (Likert-Skala; MW=4.4; SD=0.94; MAX=5; MIN=2). Die zur Verfügung stehende Zeit (19x angemessen; 1x zu lang) und der allgemeine Schweregrad (14x angemessen, 3x zu schwer, 3x keine Angabe) wurden insgesamt als angemessen wahrgenommen. In Punkto Verständlichkeit (Likert-Skala; MW=3.35; SD=1.04; MAX=5; MIN=1) und Eindeutigkeit (Likert-Skala; MW=2.9; SD=1.12; MAX=4; MIN=1) der Prüffragen besteht aus Sicht der Teilnehmer Verbesserungspotenzial. Dieses Potenzial wird durch die Ergebnisse der anschließenden statistischen Bewertung der Items reflektiert: Hinsichtlich des Kriteriums Itemschwierigkeit zeigte sich,

Abb. 1. Schematische Wiedergabe der Prüfungs­ ergebnisse der Pilotzertifizierung CPUX-F (Brau, 2013)

33


dass vier Items hinsichtlich Schwierigkeits­ index und Trennschärfekoeffizienten un­­ günstige Werte aufweisen. Dass nicht wenige Items sehr hohe Schwierigkeitsindizes aufwiesen kann (und damit als zu leicht gelten müssten) ist zum Teil sicherlich auch auf den hohen fachlichen Reifegrad der Gruppe zurückführbar. Hier werden sich weitere Itembewertungen nach durchgeführten Prüfungen anschließen.

Für die Zukunft sind aktuell noch fortgeschrittene Programme für –– CPUX – Information Architect (CPUX-IA) und –– CPUX – Usability Engineer (CPUX-UE)

4. Ausblick Zusammengefasst ist die Realisierung einer Zertifizierung zum Thema Usability und UX mit dem Zweck einer Professionalisierung des Berufsbildes erfolgt. Durch den Arbeitskreis der German UPA wurde hierzu ein Curriculum sowie ein Glossar erstellt, auf dessen Basis das gemeinsame Verständnis von Begriffen und Konzepten aus dem Usability Engineering auf einer ersten Zertifizierungsstufe (Foundation Level) bescheinigt werden soll. Nach diversen Evaluationsaktivitäten und einer ersten Pilot-Zertifizierung im Juni 2013 findet nun im Rahmen der Konferenz Mensch & Computer 2013 sowie Usability Professionals 2013 im September die erste offizielle Zertifizierungsrunde statt, bei der sich 100 Usability und User Experience interessierte Personen zertifizieren lassen können. Weitere Möglichkeiten werden später folgen. Zudem rücken die Arbeiten am Kompetenzrahmen Usability Engineering (vgl. Abschnitt 3.1) nach Erstellung des Curriculums und der Zertifizierungsfragen wieder in den Vordergrund. Auf dessen Grundlage sollen dann weitere Zertifizierungen auf einem fortgeschrittenen Level (Advanced Level) erarbeitet werden. Angedacht für eine nächste Stufe sind demnach Zertifizierungsprogramme für –– CPUX – Usability Tester (CPUX-UT) sowie –– CPUX – User Requirements Engineer (CPUX-URE).

34

für lebenslanges Lernen (2012). http:// ec.europa.eu/education/pub/pdf/general/ eqf/leaflet_de.pdf 10. Fischer, H., Geis., T., Kluge, O., Bogner, C. & Polkehn, K. (2012). Der Qualitätsstandard

geplant.

für Usability Engineering der German UPA – Aktueller Stand der Arbeiten. In: Brau,

Literatur

H. et al. (Hrsg.) Tagungsband Usability

1. Behrenbruch, K., Bogner, C., Fischer, H.,

Professionals 2012, German UPA, S.

Geis, T., Geitner, C., Heimgärtner, R.,

Die im Rahmen der Pilot-Zertifizierung gewonnen Erkenntnisse werden entsprechend in das Curriculum, die Prüfungsfragen sowie das Glossar eingearbeitet.

9. EQR Europäischer Qualifikationsrahmen

Hofmann, B., Hunkirchen, P., Kluge, O.,

160–165. 11. Geis, T., Hofmann, B., Bogner, C. &

Litzenberg, B., Polkehn, K., Pysarenko, Y.

Polkehn, K. (2010). (Qualitäts-)Standards für

& Zimmermann, D. (2012). German UPA

Usability Professionals – welche sind das

Qualitätsstandard für Usability Engineering,

eigentlich?. i-com Zeitschrift für interaktive

Version 1.0. German UPA e.V., Arbeitskreis

und kooperative Medien, Ausgabe 1–2010.

Qualitätsstandards. 2. Bogner, C., Brau, H., Geis, T., Huber, P.,

München: Oldenbourg Wissenschaftsverlag. 12. German UPA (2013). Dokumente zur

Lutsch, C., Petrovic, K. & Polkehn, K.

Zertifizierung CPUX-F. http://www.

(2011). Beschreibung des Berufsfelds

germanupa.de/aktivitaeten/zertifizierung/

Usability / User Experience – Rollen und Aufgaben von Usability Professionals im benutzerorientierten Entwicklungsprozess. German UPA e.V., Arbeitskreis Berufsfeld. http://germanupa.de/german-upa/ berufsfeld-usability-ux 3. Brau, H. (2013). Evaluation der Pilotzertifizierungsprüfungen zum CPUX-F. Unveröffentlichter Projektbericht der German UPA. 4. Cockburn, A. (2000). Writing Effective Use Cases. München: Addison-Wesley Professional. 5. Deutsche Akkreditierungsstelle GmbH

dokumente-zur-zertifizierung/ [14.07.2013]. 13. ISO/IEC TR 25060 (2010). Common Industry Format: General Framework for Usability Related Information (CIF). 14. PAS 1093 (2009). Personalentwicklung unter besonderer Berücksichtigung von Aus- und Weiterbildung – Kompetenzmodellierung in der Personalentwicklung. 15. Pruitt, J. & Adlin, T. (2006). The Persona Lifecycle: Keeping People in Mind Throughout Product Design. San Francisco, CA, USA: Morgan Kaufmann. 16. Rosson, M. B. & Carroll, J. M. (2002). Usability Engineering – Scenario-based

(DAkkS) (2010). Leitfaden Usability,

Development for Human-Computer

Version 1.3. http://www.dakks.de/sites/

Interaction. San Francisco, CA, USA: Morgan

default/files/71-SD-2–007_Leitfaden%20 Usability%201.3.pdf 6. Diefenbach, S., Ullrich, D. & Kolb, N. (2012).

Kaufmann. 17. Seffah, A., Desmarais, M. C. & Metzker, E. (2005). HCI, Usability and Software

Branchenreport Usability 2012 – Ergebnisse

Engineering Integration: Present and Future.

einer Befragung unter Usability Professionals

In: Seffah, A., Gulliksen, J., Desmarais,

in Deutschland. In: Brau, H. et al. (Hrsg.)

M. C. (Hrsg.): Human-Centered Software

Tagungsband Usability Professionals 2012,

Engineering – Integrating Usability in the

German UPA, S. 288–294.

Software Development Lifecycle (S. 37–58).

7. DIN EN ISO 9241–11 (1999). Ergonomische Anforderungen für Bürotätigkeiten mit

Heidelberg: Springer Verlag. 18. Woywode, M., Mädche, A., Wallach, D.

Bildschirmgeräten – Teil 11: Anforderungen

& Plach, M. (2012). Abschlussbericht des

an die Gebrauchstauglichkeit – Leitsätze.

Forschungsprojektes „Gebrauchstauglichkeit

8. DIN EN ISO 9241–210 (2010). Ergonomie

von Anwendungssoftware als

der Mensch-System-Interaktion – Teil 210:

Wettbewerbsfaktor für kleine und mittlere

Prozess zur Gestaltung gebrauchstauglicher

Unternehmen“ im Auftrag des BMWi.

interaktiver Systeme.


Usability Professionals 2013 Workshop

35


Arbeitskreis User Research: Workshop zur Mensch & Computer 2013

Anja Endmann itCampus GmbH Nonnenstraße 37 04229 Leipzig a.endmann@itcampus.de

Carolin Flesch SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf carolin.flesch@sap.com

Abstract Der Arbeitskreis (AK) User Research wurde von Anja Endmann und Carolin Flesch im Herbst 2012 gegründet, und wird dieses Jahr zum ersten Mal auf der Konferenz vorgestellt. Der Workshop des AK richtet sich an alle Usability Professionals die sich für User Research interessieren oder selbst als User Researcher tätig sind. Der Workshop soll die Möglichkeit geben, über Erwartungen und Zielsetzungen des AK zu diskutieren. Usability Professionals, die sich für User Research interessieren oder selbst als User Researcher tätig sind, sind herzlich zur Mitarbeit eingeladen.

1. Einleitung User Research ist ein zentraler Bestandteil der benutzerzentrierten Produktentwicklung, durch den Benutzeranforderungen identifiziert und dokumentiert, und daraus abgeleitete Prototypen evaluiert (validiert) werden können. Obwohl der User Research ein fundamentaler Bestandteil der nutzerzentrierten Produktentwicklung ist, wird diese Disziplin bei Tagungen und Workshops noch zu wenig thematisiert. Gemeinsam mit neuen AK-InteressentInnen möchten wir dieses wichtige Thema sowohl inhaltlich als auch organisatorisch diskutieren und die Visibilität dieses Be­reiches stärken. Sie sind dazu herzlich eingeladen!

2. Ziele des Arbeitskreises Der Fokus des Arbeitskreises liegt auf dem Austausch über angewandte Research-Methoden – vom klassischen ­Contextual Interview, über Focus Groups bis hin zum Massenfeedback – sowie neue Methodenansätze.

36

Der Workshop soll zur Gründung neuer Netz­ werke im User Research Bereich an­regen. Folgende Fragestellungen werden diskutiert: –– Vor welchen Herausforderungen stehen User Researcher derzeit? –– Wie können Methoden an besondere Umstände angepasst werden? –– In welchen Zusammenhängen stehen die unterschiedlichen Methoden und was kann mit ihnen erreicht werden? Des Weiteren soll eine höhere Sichtbarkeit des User Research innerhalb des Fachbereiches User Experience geschaffen werden. User Experience ist mehr als Interaktionsund Visuelles Design; ein gutes Design beruht stets auf einer fundierten Anforderungsanalyse sowie einer Evaluation des Designs mit repräsentativen Nutzern. Des Weiteren ist eine umfassende Literaturliste zum Thema User-Research-Methoden und deren Anwendung geplant; sowie langfristig eine Sammlung der angewandten Methoden mit Hinweisen, Tipps und Tricks. 3. Ziel des Workshops In diesem ersten Workshop steht das Kennenlernen der Interessenten und der AKLeitung im Vordergrund. Es soll Raum für

Keywords: /// User Research /// Methodenaustausch /// Best Practices

Diskussionen über Erwartungen und Ziele jedes Interessenten geschaffen werden. Zudem hinaus möchten wir gemeinsam mit Ihnen als aktives Mitglied eine Roadmap für das kommende Jahr entwickeln. 4. Geplante Zusammenarbeit Zur Überbrückung der Zeiträume zwischen den Konferenzen finden regelmäßig monatliche Telefonkonferenzen statt. Dazu kann jedes AK-Mitglied Themen einbringen. Die Telefonkonferenzen werden abwechselnd vorbereitet. In ca. 45 Minuten kann ein Projekt, eine Methode, Fachliteratur, oder ein Konferenzbericht vorgestellt werden; im Anschluss daran ist Zeit für Fragen und Diskussionen. Wir freuen uns auf Ihre Mitarbeit!


Usability Professionals 2013 Workshop

Literatur 1. Albert, W.; Tullis, T. (2010) Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics. Morgan Kaufman, Elsevier Science, San Francisco. 2. Kaushik, A. (2009). Web Analytics 2.0: The Art of Online Accountability and Science of Customer Centricity. John Wiley & Sons, Indianapolis. 3. Kuniavsky, M. (2003). Observing the user experience. A practitioner’s guide to user research. Morgan Kaufman, Elsevier Science, San Francisco. 4. Mose, C. (2012). User Experience Design – Mit erlebniszentrierter Softwareentwicklung zu Produkten, die begeistern. Springer Verlag, Berlin Heidelberg 5. Reichheld, F. & Markey, R. (2012). The Ultimate Question 2.0: How Net Promoter Companies Thrive in a Customer-Driven World. Harvard Business Review Press, Boston. 6. Schumacher, R. (2006). Handbook of Global User Research. Morgan Kaufman, Elsevier Science, San Francisco. 7. Sharon, T. (2012). It’s Our Research – Getting Stakeholder Buy-in for User Experience Research Projects. Morgan Kaufman, Elsevier Science, San Francisco.

37


Workshop des Arbeitskreises „Usability in der Medizintechnik“ Tobias Walke User Interface Design GmbH tobias.walke@uid.com

Abstract Bei der Entwicklung von Medizinprodukten ist die Anwendung eines Usability Engineering Prozesses per Normen vorgeschrieben. Dadurch sollen Gefährdungen, hervorgerufen durch Benutzungsfehler von Patienten, Anwendern und Dritten minimiert werden. Der Arbeitskreis „Usability in der Medizintechnik“ versteht sich als Austauschplattform für Medizinprodukte-Hersteller und Usability Dienstleister und möchte somit praktische Tipps für die Umsetzung der Normen liefern. Als Medium entsteht hierbei gerade ein Leitfaden, der die Erfahrungen der Arbeitskreis-Mitglieder in einer kompakten Broschüre bündelt und einem breiten Publikum zur Verfügung stellt.

Ein Leitfaden für Usability in der Medizintechnik Durch reines Studieren der relevanten ­Normen wie DIN EN 60601–1-6 oder DIN EN 62366 lässt sich noch kein wirksames Usability Engineering durchführen. Hier bedarf es die Erfahrung von Spezialisten auf diesem Gebiet wie zum Beispiel die der Mitglieder der GermanUPA. Aus diesem Grund haben sich Usability Experten von Medizingeräte-Herstellern, Dienstleistern und Free Lancern im Arbeitskreis „Usability in der Medizintechnik“ zusammen gefunden. In regelmäßigen Abständen treffen sie sich, um über Themen wie die Zusammenarbeit verschiedener Disziplinen in einem Entwicklungsprozess oder das Zusammenspiel zwischen Risikomanagement und Usability Engineering zu diskutieren. Die Essenz dieser Treffen findet ihren Platz in einem Leitfaden.

einen schnellen Einblick zu geben, welche Dinge bereits bei der Planung beachtet werden müssen. An wen richtet sich der Leitfaden? Der Leitfaden richtet sich an unterschiedliche Management-Ebenen wie zum Beispiel Geschäftsführer, Projekt- und Produktmanager, die die Entwicklung neuer Medizinprodukte steuern und wesentlich an der Planung beteiligt sind. Sie müssen neuerdings auch Usability von vornherein miteinplanen und wissen, dass es Normen gibt, die Usability einfordern. Der Leitfaden soll sie dabei unterstützen, die richtigen Weichen stellen zu können.

Basierend auf dem bekannten Format der GermanUPA Broschüren soll mit dem Leit­ faden ein kompaktes Hilfsmittel entsteh­en, das über 30–40 Seiten darüber informiert wie sich Usability Engineering in bestehen­de Entwicklungsprozesse integrieren lässt.

Weiterhin soll er Mitarbeiter aus dem Qualitätsmanagement oder Regulatory Affairs Umfeld, die auf die Usability Normen gestossen sind. Sie müssen andere Mitarbeiter im Unternehmen auf diese Normen aufmerksam machen und darauf achten, dass sie Berücksichtigung finden. Ebenso sind sie dafür verantwortlich, dass alle Schritte des Usability Engineerings während der Entwicklung ein einem Usability Engineering File dokumentiert werden.

Es ist dabei nicht das Ziel, die bestehenden Normen zu wiederholen, sondern

Ebenso gibt es den Risikomanager, der einen Riskomanagement Prozess nach DIN

38

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

EN 14971 durchführt und dokumentiert. Er kann mit Hilfe von Usability Engineering nutzergerechte Maßnahmen zur Risikokontrolle definieren. Wie er dazu auf die Unterstützung von Usability Experten zurückgreifen kann, zeigt ihm der Leitfaden auf. Nicht zuletzt zeigt der Leitfaden aber auch Personen aus dem Usability und UX Um­­ feld auf, welche Besonderheiten sie bei Ent­wicklung von Medizintechnik beachten müssen. Wichtigste Botschaft ist hierbei, dass Usa­bility in der Medizintechnik zu ­allererst zur Vermeidung von Bedienfehlern und zur Verbesserung der Sicherheit dient. Allen voran steht hier deshalb die enge Zusammenarbeit mit dem Riskomanager und die Dokumentation des gesamten Usability Engineering Prozesses. Dies wird in anderen Branchen für Usability ­Engineering bzw. UX Prozesse nicht benötigt und deshalb auch nicht bekannt. Wie wird der Leitfaden aufgebaut sein und was sind die Inhalte? Das bereits existierende quadratische Design der GermanUPA Broschüren (siehe Broschüre „Barrierefreiheit“ und „UX Professional“) wird für den Leitfaden des AK Usability in der Medizintechnik grundsätzlich übernommen und entsprechend


Usability Professionals 2013 Workshop

adaptiert. Neben einem Print-Format soll hier die PDF Variante interaktiv mit Navigation und Sprungmarken zur optimierten Benutzung bereitgestellt werden. Hierbei wird eine Seitenzahl von maximal 40 Seiten angestrebt. Damit diese für den Leser leicht und schnell erfassbar sind, sollen sie möglichst kompakte Texte, ergänzt durch Bilder und Skizzen enthalten. Oberstes Ziel ist es, einen schnellen Einstieg und einen guten Überblick über das Thema zu bekommen. Weiterführende und tiefergehende Inhalte sind ergänzend auf einer Internetseite denkbar. Die Idee ist hierbei ein breites und wachsendes Portfolio aus dem Erfahrungsschatz der Mitglieder des Arbeitskreises an Medizintechnik Projekten fiktiv abzubilden und als Download auf dieser Webseite bereitzustellen. Da auch bereits die Kapitel selbst merkfähig sein sollen, wurden die folgenden fünf festgelegt: [Tab. 1]

Tab. 1. Darstellung der Kapitelstruktur (mit freundlicher Genehmigung der chili mind GmbH)

Kapitel I – Vorteil und Nutzen Das erste Kapitel soll dem Leser zunächst das Ziel des Leitfadens erschließen. Hier wird ihm dessen Mehrwert aufgezeigt und wie er ihn als Impulsgeber für eine nutzerorientierte Denkweise in seinem Unternehmen einsetzen kann. Deshalb werden ihm weiterführend die Vorteile und der Nutzen der Anwendung eines nutzerzentrierten Gestaltungsprozesses in der Medizinprodukte-Entwicklung aufgezeigt. An oberster Stelle steht die Verbesserung der Sicherheit für Nutzer, Patienten und Dritte. Doch neben dieser normativen Anforderung gibt es zahlreiche weitere Vorteile wenn Nutzer miteinbezogen werden, die sich für Marketing und Vertrieb, aber zum Beispiel auch im Kundenservice umsatz- und kundenzufriedenheitssteigernd einsetzen lassen. Kapitel II – Ansatz und Vorgehen Das zweite Kapitel erläutert zunächst kurz die geforderten Inhalte der Norm DIN EN 62366 als theoretischen Hintergrund und als „Usability Pflichtprogramm“ für die Zulassung eines Medizinproduktes im europäischen Raum.

Kernstück dieses Kapitels bildet eine grafische Darstellung eines idealtypischen Entwicklungsprozesses eines Medizinproduktes aus Sicht von Usability Experten ab. Diese baut auf der von der Norm geforderten Vorgehensweise auf, ergänzt Sie aber durch in der Praxis bewährte Meilensteine und Methoden. Weiterhin soll der Prozess auch die bei einer Entwicklung beteiligten Rollen und deren Aufgaben aufzeigen. Während diese Prozessgrafik im Leitfaden eher kompakt und fokussiert gezeigt wird, soll sie in einer Webseiten-Variante detaillierter und tiefgängiger dargestellt werden.

dass die vier Cases diese Vielfalt wider spiegeln. Dadurch können verschiedenste Zielgruppen der Medizinproduktebranche angesprochen werden und es ist möglich Die Komplexität der Produkte spiegeln verschiedene Anwendungsfelder und Individualisierung des Prozesses wieder. Durch die Vielfalt der vorgestellten Produkte sollen verschiedene Zielgruppen angesprochen werden, die in mindestens einem der Cases die Komplexität ihrer eigenen Medizinprodukte wiedererkennen können. Die erstellten Cases sollen möglichst generisch anwendbar und auch keinem Hersteller zuordenbar sein.

Kapitel III – 4 Top Cases Im dritten Kapitel bilden Entwicklungsbeispiele von Medizinprodukten, sogenannte „Cases“ den Hauptteil des Leitfadens. Damit der Leser auch hier wieder sich schnell durch die Inhalte arbeiten kann, wird die Anzahl dieser Cases auf vier begrenzt. Da Produkte in der Medizintechnik in Ihren Anwendungsfeldern, ihrer Komplexität und in ihrem Technisierungsgrad völlig unterschiedlich sein können, ist es wichtig,

Geplant ist, einen Case auf zwei Doppelseiten der Broschüre darzustellen und mit Illustrationen, Skizzen oder auch Realbildern zu versehen. Dies und die Verwendung einer einfachen Sprache, die möglichst ohne Fachbegriffe auskommt sollen dem Leser ein leichtes Erfassen der dargestellten Problematik und deren Lösung verdeutlichen.

39


Kapitel IV – Rollen und Handlungsempfehlungen Im vierten Kapitel wird auf die Rollen im Entwicklungsprozess eingegangen. Die Idee hierbei ist, dass sich der Leser mit mindestens einer dieser Rollen identifizieren kann. Er erfährt dann was seine Aufgaben sind und mit welchen anderen Rollen er zusammen arbeiten muss, um ein möglichst nutzerfreundliches Medizinprodukt zu

40

entwickeln. Zusätzlich sollen für die einzelnen Rollen praktische Handlungsempfehlungen der Usability Experten die Umsetzung des Prozesses im Alltag erleichtern.

gegeben werden. Denkbar ist hier beispielsweise die Verlinkung via QR Codes auf eine Webseite mit weiteren Inhalten und Ergänzungen.

Kapitel V – Verfasser & Weiterführende Infos

Was ist der aktuelle Stand?

Im letzten Kapitel werden die Verfasser des Leitfadens vorgestellt und es soll ein Zugang zu weiterführenden Medien

In verschiedenen Workshops und Telefonkonferenzen wurden von den Mitgliedern des Arbeitskreises bislang die folgenden Inhalte erarbeitet.


Usability Professionals 2013 Workshop

Einen Prozess entwickelt Um den Entwicklungsprozess aus der Norm zu veranschaulichen, teilten die Mitglieder das Vorgehen aus der Norm in die jeweiligen Phasen, Ergebnisse aus einem Prozessschritt, Handelnde innerhalb einer Phase und das entsprechende Kapitel in der Norm ein. Die Phasen des Entwicklungsprozesses sind: Recherche/Analyse,

Konzeption I+II, Umsetzung, Validierung, Markeinführung. Häufig werden innerhalb einer Phase mehrere Handelnde aktiv und müssen zusammenarbeiten. Im Prozess müssen auch die Iterationen zwischen Konzeption und Validierung beachtet werden. Am Ende steht ein Prototyp, eine BetaVersion oder Nulllinie. Der Prozess soll in einer anschaulichen Form in den Leitfaden einfließen. Bei der Arbeit in der Gruppe

stellte sich unter den Mitgliedern eine Differenz zwischen dem Vorgehen und der verschiedenen Bezeichnungen für Dokumente und Prozessschritte bei Hardund Software heraus. Ein Ziel muss deshalb sein einen möglichst generischen, idealtypischen Zustand zu zeigen, den jeder Leser für sich als Basis nutzen, den er aber auch auf seine im Unternehmen geltenden Begriffe und Verfahren anpassen kann. [Tab. 2]

Tab. 2. Darstellung des Prozesses (mit freundlicher Genehmigung der Phoenix Design Phoenix Design GmbH + Co. KG)

41


Erste Struktur für Cases definiert Ein Vorschlag für die Grundstruktur eines Cases kann wie folgt aussehen: 1. Ziel der Entwicklung 2. Beschreibung inkl. Nutzen 3. Nutzer 4. an der Entwicklung beteiligte Rollen laut Leitfaden 5. Typische Risiken 6. Vorgehensweise, Anwendungsfälle, Szenarien, Hauptbedienfunktionen, … 7. Bilder in Form von möglichst neutralen Illustrationen 8. Fazit – was hat Usability Engineering bewirkt Diese wird nun in den weiteren Treffen unter den Mitgliedern definiert und dann verabschiedet. Für die vier Cases wurden bereits unterschiedliche Komplexitätsgrade festgelegt: XS, S, M, und L. Inhaltlich soll ein Case dabei sein, der eine reine Software behandelt, ein weiterer soll sich um den Homecare Bereich drehen (Patient als Nutzer) und der L Case soll ein sehr komplexes Gerät abbilden, mit umfangreichen Hard- und Software Anteilen.

Ziele –– Umsatz und Gewinn erwirtschaften –– wirtschaftliche Entwicklung voran treiben –– Innovation fördern Aufgaben –– Nachfragen, Budget und Deliverables kontrollieren –– Kommunikation, Zusammenfassungen lesen, Entscheidungen treffen –– Projektergebnisse und Learnings auf andere Projekte übertragen –– Verbesserungen weitertragen / umsetzen –– Geld und gute Stimmung verbreiten –– Motivation fördern

2. Marketing und Vertrieb Marketing und Vertrieb haben die Notwendigkeit von Usability Engineering erkannt und möchten diese als Verkaufsargument für ihre Produkte verwenden. Bekannt ist bei dieser Gruppe gängige Methoden aus der Marktforschung, die sie auch für Usability Engineering einsetzen möchte. Ziele –– Produkt & Image verkaufen –– Benchmarking & Marktwissen einbringen

Zukünftige Rollen Der aktuelle Stand der identifzierten Rollen definiert. wurde von den Arbeitskreis Mitgliedern wie folgt definiert: 1. Management Das Management muss zulassungsrelevante Normen kennen, die verschiedenen Disziplinen Entwicklung, Marketing, Usability Engineering, Design und Risikomanagement zusammenbringen und den Überblick behalten. Das Management weiß, dass es Usability Engineering braucht, was aber nicht wie und mit wem es dieses umsetzen soll und mit wem. Oftmals werden hierfür zunächst vorhandene Ressourcen als Usability Verantwortliche eingesetzt wie beispielsweise Entwickler oder Qualitätsmanager oder Regulatory Affairs Manager.

42

Aufgaben –– Kundenwissen einholen (dies muss noch kein Benutzerwissen sein und muss erst in Anforderungen interpretiert werden) –– Kundenbedürfnisse einholen

3. Produktmanagement Für das Produktmanagement ist Usability Engineering zunächst ein zusätzlicher Budget- und Zeitfaktor. Werden aber erste Erfahrungen mit der Optimierung des Produkts durch Usability Engineering Methoden gesammelt, wird sehr oft deren Nutzen erkannt und deren Akzeptanz erhöht. Ziele –– Geplante Anforderungen im aktuellen Produkt termingerecht umsetzen.

Aufgaben –– Steakholder moderieren, koordinieren, zusammen bringen –– Anforderungen pflegen und managen –– (Rapid-) Prototyping einplanen / managen –– Schnelle Test einplanen (UX-Aktivitäten einplanen) –– Gewerke und Stakeholder zusammenführen –– Entscheidungen treffen – Diskussionen leiten –– Eskalationsmanagement (zur nächst höheren Ebene)

4. UX-Design / Usability Experte Der Usability Experte arbeitet Inhouse, oftmals aber auch als Externer. Er ist mit Usability Engineering Prozessen vertraut, neu ist allerdings, dass er einer Norm folgen muss, die von ihm verlangt seine ganze Arbeit zu dokumentieren. Neu ist für ihn auch die Zusammenarbeit mit dem Risikomanagement. Ziel –– Anwalt (Vormund) des Nutzers –– Produktqualität im Sinne der Ergonomie sicherstellen Aufgaben –– Bedienfehler minimieren / eliminieren –– Nutzer- und Kontextwissen aufbauen –– Lösungen zu Nutzern-Anforderungen finden –– Prototypen / Wireframes bauen –– Konzept evaluieren (Tests / verifizieren) –– Mit dem Entwickler abstimmen –– Anforderungen prüfen / LösungenAlternativen finden –– Szenarien / Varianten erstellen –– Risiko- Maßnahmen in Anforderungen umsetzen –– Fertiges Produkt validieren

5. Entwickler Der Entwickler arbeitet als Techniker, Ingenieur, Software-Entwickler, Medizintechniker oder Biologe in der Produktentwicklung. Er ist technisch versiert, denkt analytisch und hätte am liebsten


Usability Professionals 2013 Workshop

eine Checkliste bei der er alle Punkte des Usabiliy Engineering Prozesses abhaken könnte. Ziel –– Produkt (technisch) umsetzen. Aufgaben –– mit UX abstimmen –– Technische Umsetzbarkeit aufzeigen –– Lösungsalternativen mit UX abstimmen –– Lösungen für Anforderungen erfüllen / umsetzen –– Aufwand an Produktmanagement kommunizieren –– Eskalationsmanagement

6. Risiko Manager Der Risikomanager: muss Gefährdungen erkennen, daraus Risiken ableiten und Maßnahmen zur Reduzierung dieser Risiken definieren. Er weiß, dass ihm bei der Umsetzung dieser Maßnahmen das Usability Engineering zur Seite stehen kann, kennt aber sich aber nicht unbedingt in den dafür geeigneten Methoden aus. Ziel –– Risiken zum Produkt identifizieren und managen > Oberstes Gebot dabei: das Produkt muss sicher sein.

Ziel –– Visuelle Identität sicherstellen Aufgaben –– für UX Anforderungen offen sein –– aus Projekten / Produkten / Technologien lernen und Guidelines adaptieren –– allgemeine Corporate Usability Guidelines aufsetzen und pflegen

8. Nutzer Der Nutzer kommt mit Benutzer­freundlich­ keit vor allem über seine alltäglichen Consumer Produke, sowie Webseiten in Kontakt. Die dort gemachten Erfahrungen projiziert er auch auf Medizinprodukte, die er beruflich oder als Patient anwenden muss. Seine Toleranz gegenüber schlecht bedienbaren Produkten sinkt immer weiter. Ziel –– Produkt sicher, effektiv, effizient benutzen (und mit Spaß) Aufgaben –– Mehrfache Mitwirkung bei der Entwicklung –– Gespür für die Notwendigkeit seines Feedbacks entwickeln

Aufgaben –– Wissen über Nutzer und Kontext von UX einfordern –– Gefahren erkennen und recherchieren –– Risiken abschätzen; –– Maßnahmen an UX weitergeben –– Maßnahmen verifizieren

Für den Usability Experten gilt hier in Bezug auf den Nutzer –– Nach Kriterium von Usability Consultant rekrutieren –– Zum richtigen Zeitpunkt –– Am richtigen Ort –– Wertschätzung der Nutzer entgegenbringen

7. Guidelines / Corporate Design

Wie geht es weiter?

Der Corporate Communications Manager ist für die Einhaltung der Corporate Design Richtlininen verantwortlich, für ihn haben diese in Sachen Look&Feel eher Vorrang gegenüber den Vorschlägen aus dem Usability Engineering.

Die Mitglieder des Arbeitskreises „Usability in der Medizintechnik“ werden im Rahmen der UP13 Konferenz die oben genannten Ergebnisse vorstellen und in einen Dialog mit Interessierten treten. Die Ergebnisse fließen als Inhalte in den Leitfaden mit ein.

43


Interviewleitfaden Usability Prozessreife Ein Instrument des German UPA Arbeitskreises ­„In-house Usability“ zur Bewertung der Usability-Prozessreife in Unternehmen Jan-Hendrik Spieth, Audials AG Karl-Wilhelm-Str. 24 76131 Karlsruhe jh.spieth@gmail.com

Nicole Charlier akquinet AG Bülowstr. 66 10783 Berlin nicole.charlier@akquinet.de

Dr. Natalie Woletz T-Systems International Landgrabenweg 151 53227 Bonn natalie.woletz@telekom.de

Charlene Beavers STRATO AG Pascalstraße 10 10587 Berlin beavers@strato.de

Desdemona Strauß AVM GmbH Alt-Moabit 95 10559 Berlin d.strauss@avm.de

Berit Leiking NEMETSCHEK Allplan Systems GmbH Konrad-Zuse-Platz 1 81829 München bleiking@nemetschek.com

Abstract Der Interviewleitfaden Usability Prozessreife wurde vom Arbeitskreis In-house Usability der German UPA entwickelt. Er bietet erfahrenen Usability Professionals die Möglichkeit, den Usability Engineering Prozess in ihrem Unternehmen zu bewerten. Die Bewertung zeigt die Stärken und Schwächen des Prozesses auf und ermöglicht durch die Ableitung konkreter Maßnahmen seine gezielte Verbesserung. Die Bewertung des Prozesses findet anhand von Interviews mit Prozessbeteiligten statt. Der Leitfaden gibt die Struktur der Interviews vor und ermöglicht es, mit mehreren Personen eines Unternehmens vergleichbare Interviews zu führen. Auf diese Weise ist es möglich, die Interviewergebnisse zu einer Gesamtbewertung zusammenzuführen. Aufgrund der Unterschiedlichkeit von Unternehmen, ihrer Prozesse und Produkte, ist eine Vergleichbarkeit von Ergebnissen über Unternehmen hinweg allerdings nicht gegeben und auch nicht Ziel dieses Leitfadens. Der Interviewleitfaden wurde auf der Fachtagung Usability Professionals 2012 vorgestellt und steht demnächst als Download auf der Webseite der German UPA zur Verfügung. Für die diesjährige Fachtagung wurde nun eine Anleitung zum Leitfaden erstellt, die Hinweise zur Vorbereitung, Durchführung und Auswertung der Interviews gibt.

1. Motivation In vielen Unternehmen leisten Usability Professionals Pionierarbeit. Sie stehen vor der Aufgabe, Usability Engineering (UE) in ihrem Unternehmen zu etablieren. Der Wunsch und die Anforderung, gebrauchstaugliche Produkte und Dienstleistungen zu entwickeln sind vorhanden, aber es fehlt vielerorts das Wissen darüber, wie das genau vonstatten gehen soll. Welche Aktivitäten und Methoden des Usability Engineerings bzw. des User Centered Designs sind erforderlich? Welche Voraussetzungen müssen erfüllt sein? Welche Personen und

44

welche Abteilungen müssen in die Usability Engineering-Aktivitäten einbezogen werden und zu welchem Zeitpunkt? Im UPA-Arbeitskreis „In-house Usability Professionals“ sind wir zu der Überzeugung gelangt, dass es sinnvoll ist, vor der Beantwortung all dieser Fragen zunächst zu bewerten, wie gut (oder schlecht) das eigene Unternehmen bereits in Sachen Usability Engineering unterwegs ist. Fragen in diesem Zusammenhang sind zum Beispiel: Werden Usability Engineering-Aktivitäten regelmäßig durchgeführt oder sporadisch immer nur dann, wenn im

Peer Dierolf Carl Zeiss SMS GmbH Rudolf-Eber-Straße 2 73447 Oberkochen peer.dierolf@zeiss.com

Keywords: /// Usability Engineering Prozess /// Prozessreife /// Qualitätsstandard /// In-house Usability /// Prozessbewertung

Projekt noch Zeit und Geld dafür da sind? Gibt es Regeln, wie und wann bestimmte Methoden im Unternehmen einzusetzen sind? Wer ist für die Durchführung von UEAktivitäten zuständig? Sind UE-Aktivitäten im Budget- und Ressourcenplan verankert? Diese Fragen zielen also darauf ab, wie „reif“ der Usability-Engineering-Prozess im eigenen Unternehmen ist. Insbesondere in kleinen und mittelständischen Unternehmen stehen jedoch im Allgemeinen weder ausreichend Zeit noch genügend Geld zur Verfügung, um eine Reifegradstudie durchzuführen. Hier wollen wir ansetzen und In-house Usability Professionals ein


Usability Professionals 2013 Workshop

Instrument an die Hand geben, mit dem sie schnell und einfach ein Stärken-Schwächen-Profil ihres Unternehmens erstellen und Handlungsempfehlungen ableiten können.

menschenzentrierten Gestaltung: Verstehen und Beschreiben des Nutzungskontexts, Spezifizieren der Nutzungsanforderungen, Entwerfen der Gestaltungslösungen sowie Testen und Bewerten der Gestaltung.

Der Interviewleitfaden selbst wird voraussichtlich zum Ende des Jahres auf der Webseite der German UPA im Bereich des Arbeitskreises In-house Professionals zum Download zur Verfügung gestellt werden.

Zu den in der ISO beschriebenen ProzessSchritten werden im „German UPA Qualitätsstandard für Usability Engineering“ dazugehörige Aktivitäten beschrieben.

2. Wie kann die Reife eines Usability Engineering Prozesses bewertet werden? Bei der Bewertung der Prozessreife geht es darum, festzustellen, wie gut ein Prozess geeignet ist, ein bestimmtes Ergebnis zu erreichen. Im Falle des Usability Engineering Prozesses ist das Ergebnis die Usability bzw. User Experience, die ein interaktives Produkt (Software, Hardware, App, Website etc.) aufweist. Je besser der Usability Engineering Prozess ist, desto besser sollte auch die Usability / User Experience des Produktes sein. Wir folgen mit dieser Annahme der prozessorientierten Sicht des Qualitätsmanagements, die davon ausgeht, dass bestimmte Merkmale des Herstellungsprozesses die Qualität des Produktes bestimmen ( Woletz, 2006). Um die Prozessreife festzustellen, wird der zu bewertende Prozess mit einem idealen Prozess – dem Referenzprozess – verglichen. Der Referenzprozess legt den Zweck und die erwarteten Resultate fest. Je mehr der bewertete Prozess dem Referenzprozess entspricht, desto besser ist er. Die ermittelten Abweichungen zeigen die Verbesserungspotenziale für den bewerteten Prozess auf. Um die Reife des Usability Engineering Prozesses zu bewerten, wird also ein Referenzprozess benötigt. Für den vorliegenden Interviewleitfaden wurde der Usability Engineering Prozess der DIN EN ISO 9241–210 als Referenzprozess gewählt. Die ISO definiert vier Prozess-Schritte der

Die Prozess-Schritte der ISO und die Aktivitäten des Qualitätsstandards bilden das Referenzmodell eines reifen Usability Engineering Prozesses. Mit diesem kann ein in der Praxis durchgeführter Prozess verglichen werden. Weder die ISO noch der Qualitätsstandard geben dabei eine starre Reihenfolge der Aktivitäten vor. Eine gewisse logische Abfolge ist allerdings selbstverständlich, so müssen zum Beispiel Anforderungen erst erhoben werden, bevor sie während der Lösungsgestaltung berücksichtigt werden können und Gestaltungslösungen können erst evaluiert werden, nachdem sie entworfen wurden. Generell können Aktivitäten aber in verschiedenen Phasen eines Entwicklungsprozesses durchgeführt und wiederholt werden. Sowohl in der ISO als auch im Qualitätsstandard wird sogar explizit darauf hingewiesen, dass die Aktivitäten der menschenzentrierten Gestaltung zu iterieren sind. Wichtig: Weder die Reihenfolge noch der Zeitpunkt der Durchführung bestimmter Aktivitäten werden daher überprüft. Bewertet wird lediglich, ob eine möglichst vollständige Durchführung der Aktivitäten stattfindet und dass die jeweils für eine Aktivität benötigten Eingangsinformationen vorhanden sind.

Die Aktivitäten der menschenzentrierten Gestaltung sollen in allen Phasen eines Produktentwicklungsprozesses – von der Idee über die Nutzung bis zur Außerbetriebsetzung – eingesetzt werden, unabhängig davon, ob wasserfallartig, nach V-Modell, nach agilen oder anderen Vorgehensmodellen entwickelt wird. Aus diesem Grund ist auch der vorliegende Interviewleitfaden

nicht an eine bestimmte Vorgehensweise gebunden. Er kann unabhängig von einer bestimmten Entwicklungsmethodik angewendet werden. 3. Der Interviewleitfaden und seine Anwendung Einführung in die Methode Die Bewertung der Reife des Usability Engineering Prozesses findet anhand eines leitfadengestützten Interviews statt. Der Interviewer sollte ein erfahrener Usability-Experte sein, dem die generellen Praktiken und Vorgehensweisen des Usability Engineerings gut bekannt sind. Auch die Kenntnis des Qualitätsstandards, auf dem dieser Leitfaden basiert, ist Voraussetzung für das Führen der Interviews. Der Usability-Experte muss in der Lage sein, die im Interview geschilderten Aktivitäten auf das Referenzmodell zu übertragen. Der Usability-Experte sollte außerdem umfassende Erfahrung mit der Durchführung von Interviews besitzen. Es kann vorkommen, dass der UsabilityExperte, der die Bewertung durchführen will, der einzige Usability-Experte im Unternehmen ist. In diesem Fall empfehlen wir, das Interview von einem externen Usability-Experten durchführen zu lassen. Es wird nicht empfohlen, sich selbst zu befragen, da eine objektive Einschätzung im Gespräch mit einem oder besser noch mit mehreren Gesprächspartnern eher gegeben ist. Für die Einschätzung des Usability Engineering Prozesses sollten mehrere Interviews geführt werden, so dass die einzelnen Prozess-Schritte mehrfach bewertet werden und so eine möglichst objektive Beurteilung entsteht. Die Interviewpartner sollten einen umfassenden Überblick über alle relevanten Prozessabschnitte haben, um den gesamten Prozess bewerten zu können. Alternativ ist es möglich, Interviewteilnehmer auszuwählen, die jeweils einen Teil des Gesamtprozesses gut beurteilen können. In

45


diesem Fall wird die Befragung in mehrere Interviews aufgeteilt und die Teilergebnisse werden anschließend zusammengeführt. Am Ende benötigt der Interviewer zu allen Abschnitten des Prozesses genügend belastbare Informationen, um eine objektive Einschätzung abgeben zu können. Ist ein Teil des Prozesses nach extern verlagert, zum Beispiel zu einem Dienstleister, sollte auch dieser Teilprozess anhand von Interviews mit Prozessbeteiligten bewertet werden. Ist dies nicht möglich, sollten zumindest die Ergebnisse des Teilprozesses daraufhin bewertet werden, ob sie für die nachfolgenden Prozessschritte in angemessenem Umfang und angemessener Qualität vorliegen.

Level [%]

Beschreibung / Kriterien

0 – 15 (nicht / kaum erfüllt)

–– Aktivität wird nicht ausgeführt –– Erforderliche Arbeitsergebnisse oder nötige Arbeitsmittel sind nicht definiert –– Arbeitsergebnisse sind inhaltlich nicht verwertbar, oder werden nicht angemessen oder nicht zeitgerecht übergeben

15 – 50 (teilweise erfüllt)

–– Aktivität wird teilweise ausgeführt –– Erforderliche Arbeitsergebnisse sind definiert, stehen nach Ausführung aber nicht alle zur Verfügung –– Grundsätzliche Arbeitsergebnisse liegen vor, sind aber in größeren Teilen unvollständig

50 – 85 (größtenteils erfüllt)

–– Aktivität wird größtenteils ausgeführt –– Aktivität wird zum richtigen Zeitpunkt ausgeführt –– Alle erforderlichen Arbeitsergebnisse stehen nach Ausführung zur Verfügung –– Wesentliche Arbeitsergebnisse liegen vor und sind bis auf kleinere Lücken und Mängel vollständig –– Es gibt einige Schwachpunkte in der Ausführung

85 – 100 (vollständig erfüllt)

–– Aktivität wird zum richtigen Zeitpunkt vollständig und systematisch ausgeführt –– Alle erforderlichen Arbeitsergebnisse stehen nach Ausführung in standardisierter Form zur Verfügung –– Es gibt keine, oder nur wenige, marginale Schwachpunkte in der Ausführung

Planung und Vorbereitung der Interviews Als Vorbereitung auf die Interviews sollten sich die Interviewteilnehmer mit dem Usability Engineering Prozess ihres Unternehmens vertraut machen. Dies kann bspw. anhand einer Prozessdokumentation geschehen. Dabei ist zu berücksichtigen, dass der dokumentierte Prozess und der tatsächlich gelebte Prozess in einem Unternehmen voneinander abweichen können. Der Interviewleitfaden umfasst sieben Prozess-Schritte, die ggf. nicht alle für das Unternehmen relevant sind. Beispielsweise wird der Prozess-Schritt „Long Term Monitoring“ in der Regel nicht von Herstellern von Consumer Produkten durchgeführt. Dieser Prozess-Schritt muss somit nicht in die Bewertung einbezogen werden. Es hat sich bewährt, den Usability Engineering Prozess für das Interview in groben Schritten zu skizzieren. Neben der Kenntnis der Prozess-Schritte ist es unbedingt notwendig, dass die Interviewteilnehmer mit den Begrifflichkeiten aus dem Usability Engineering vertraut sind. Die grafische Erarbeitung des Prozesses und die Klärung der Begriffswelt können auch im Vorhinein in einem gemeinsamen Workshop mit allen Interviewteilnehmern geschehen. Das hat den Vorteil, dass alle Teilnehmer

46

Tab. 1. Bewertungsskala

bei der Beschreibung des Prozesses die gleichen Begrifflichkeiten verwenden.

Missverständnisse beim Gebrauch be­stim­ mter Begrifflichkeiten zu vermeiden.

Durchführung des Interviews

Das strukturierte Interview wird auf Basis des vorliegenden Leitfadens durchgeführt (Leitfadeninterview). Dabei werden pro Prozess-Schritt mehrere Fragen gestellt. Mithilfe dieser Fragen wird die Vollständigkeit und Qualität der durchgeführten Aktivitäten beurteilt. Am Ende der Abfrage jedes Prozess-Abschnitts erfolgt die Einordnung in eine ordinale Bewertungsskala. Diese Einordnung nimmt der Interviewteilnehmer vor. Der Interviewer kann als Experte dabei Hilfestellung geben.

Zu Beginn schauen Interviewer und Interviewteilnehmer sich zunächst den Usability Engineering Prozess des Unternehmens an. Das kann zum Beispiel anhand der vorbereiteten Prozessdarstellung geschehen. Dabei sollten sich beide die ProzessSchritte vergegenwärtigen, so dass sie im Interview die Schritte des Referenzprozesses mit jenen des gelebten, zu bewertenden Prozesses gegenüberstellen können. Für den Interviewer kann es eine Erleichterung sein, das Glossar des Interviewleitfadens und den „German UPA Qualitätsstandard für Usability Engineerin“ zur Hand zu haben, um beispielsweise

Tabelle 1 zeigt die Bewertungsskala, zusammen mit Kriterien, die als Hilfestellung und Orientierung zur Bewertung dienen: [Tab. 1]


Usability Professionals 2013 Workshop

Tab. 2. Ausschnitt aus einem StärkenSchwächen-Profil

Auswertung Das Ziel der Auswertung ist das Zusammenführen der Ergebnisse aller Interviews sowie die Ableitung von Maßnahmen und Handlungsempfehlungen zur Verbesserung des Usability Engineering Prozesses. Als Grundlage der Auswertung dienen die Bewertungen der Prozess-Schritte aller Interviewpartner (Bewertungsskala). Es hat sich bewährt, die Auswertung und Interpretation der Ergebnisse gemeinsam mit allen Interviewpartnern, zum Beispiel in einem Workshop, durchzuführen. Das Ergebnis der Auswertung ist das StärkenSchwächen-Profil. [Tab. 2] Es kann vorkommen, dass die Interviewpartner aufgrund ihrer verschiedenen Aufgaben und Rollen im Usability Prozess zu unterschiedlichen Bewertungen einzelner ProzessSchritte kommen. Weichen die Bewertungen der verschiedenen Interviewpartner voneinander ab, werden zuerst die Gründe für die unterschiedlichen Bewertungen diskutiert. Dabei ist es wichtig, dass alle Beteiligten zu einer gemeinsamen Einschätzung der Prozessreife gelangen. In der Regel ergänzen sich die einzelnen Bewertungen zu einem

umfassenderen Bild. Die zusammengeführten Einschätzungen bilden dann die Basis für die weitere Auswertung.

Der Arbeitskreis „In-house Usability“ freut sich über Anfragen und Erfahrungsberichte aus der Anwendung des Leitfadens.

Als nächstes werden gezielt jene ProzessSchritte betrachtet, die als vergleichsweise schlecht bewertet werden. Hier werden die Ursachen untersucht, die zu einer schlechten Bewertung geführt haben, damit entsprechende Verbesserungsmaßnahmen abgeleitet werden können.

Literatur 1. DAkkS (2010). Leitfaden Usability, Version 1.3. DAkkS, Deutsche Akkreditierungsstelle GmbH. 2. DIN EN ISO 9241–210 (2010). „Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme“. Berlin: Beuth. 3. German UPA e.V. (2012). German UPA

Verbesserungsmaßnahmen sollten in erster Linie darin bestehen, diejenigen Aktivitäten einzuführen, die auf der Skalenstufe mit „0–15“ eingestuft wurden. Danach sollten solche Aktivitäten verbessert werden, die auf der Skala höher bewertet wurden.

Qualitätsstandard für Usability Engineering. http://www.germanupa.de/data/mediapool/ n070_qualitaetsstandard_der_german_upa. pdf zuletzt geprüft am 31.07.2013. 4. Woletz, Natalie (2006). Evaluation eines User-centred Design-Prozessassessments: empirische Untersuchung der Qualität

Schlussbemerkung

und Gebrauchstauglichkeit im praktischen Einsatz. Dissertation, Universität Paderborn.

Der vorliegende Artikel möchte Usability Professionals bei der Anwendung des Interviewleitfadens unterstützen und auch zur Anwendung motivieren. Der Interviewleitfaden steht voraussichtlich zum Ende des Jahres als Download auf der Webseite der German UPA zur Verfügung, kann aber auch schon vorher beim Arbeitskreis angefordert werden.

http://digital.ub.uni-paderborn.de/hs/ content/titleinfo/4128

47


48


Tutorials

49


User-Centered Design and Change Management Leading Organizational Change Towards ­User-­Centered Design Henning Brau User Interface Design GmbH Claudius-Keller-Straße 3c 81669 München henning.brau@uid.com

Abstract An important task of UX consultants and managers is to enable product developers to implement user-centered design (UCD) processes in their companies. Tragically a lot of change processes fail when progressing from functional engineering to UCD. R ­ esistance inside the organization is often the reason. Which mechanisms of organizational ­development cause resistance? How can we manage the change to UCD successfully and sustainably?

GOALS FOR THE SESSION Attendees at this session will: –– Understand the basic principles of organizational psychology and why implementing UCD processes is more about management than about UCD. –– Stop to fear resistance and start to use it as a great starting point for change management. –– Learn how to model acceptance, apply best practices of change management and build strategies for change processes. AUDIENCE PARTICIPATION –– The attendees will participate by audience votings and there will be sufficient time for questions and discussion. HANDOUTS OR OTHER SESSION MATERIAL –– The presentation slides including detailed reference list as PDF. PREVIOUS PUBLICATION OR USE OF THIS MATERIAL There was no publication in conference proceedings before. I held a compar­ able tutorial on change management

at the German language conference „Mensch & Computer 2011“, but the ­contents have been altered. YOUR BACKGROUND IN THIS MATERIAL –– Usability engineer: 12 years professional experience. Approximately 75 projects. –– UCD change manager: 7 years professional experience (inhouse:

5 years, external consultant: 2 years): Approximately 15 projects. One of them affecting 190.000 work places in an automotive environment. –– 5 years experience as academic researcher: technology acceptance and participative design –– 4 years experience as university lecturer for usability engineering, technology acceptance and participative design

Discussion

Objectives

Time

01. Introduction

Introduction of the speaker and scope

3 min

01. Audience Votings

raise audience attention

5 min

02. Why UX crusaders fail

Enable reflection of own positioning as UX consultant in a UCD change process

5 min

02. Organizational psychology insights into change processes

Understand that organizations are social constructions and what that implicates

10 min

02. Laws of physics and their Understand how change can be meaning for Change processes ­motivated and empowered

5 min

02. The Change Management Paradox

Understand reasons for resistance and how to deal with them

7 min

03. Modeling Acceptance

Learn how to analyze the stakeholders of change

5 min

03. Best Practices/ 7 Golden Rules

Learn how to work as change manager and how to save your skin from failing

10 min

04. Discussion/Questions Tab. 1. Session Schedule with Time Allocation

50

Keywords: /// UCD /// UX Professionals

10 min


Usability Professionals 2013 Tutorials

DETAILED DESCRIPTION OF PRESENTATION CONTENT 1. ‚Introduction‘ & ‚Audience Votings‘ I will start by explain the presentation scope: The implementation of UCD in organizations by changing the paradigm of product design towards user-centered design thinking. [Abb. 1] The audience will then be asked to vote if they agree in a couple of statements about change management to raise attention and draw the audience into the presentation. The statements will therefore be quite provocative, e.g.: „Design thinking cannot create a sustainable change.“

Abb. 1.

Consequently I am going to introduce 3 general hypotheses about change management: 1. UCD is not the only possible way to create products 2. Communication and documentation are important, but do not create change 3. Implementing UCD is a management not a design process

Abb. 2.

These hypotheses will be later on filled with life while wandering through different stages of the presentation. They build the framework of the presentation.

3. ‚Modeling Acceptance‘ to ‚Best Practices/7 Golden Rules‘

2. ‚Why UX Crusaders Fail‘ to ‚The Change Management Paradox‘ I am going to explain why UX professionals tend to fail in implementing UCD processes: Usually they are very emotional and ambitious about their user-centered paradigm of product creation – which is positive. They tend, however, to be too ambitious in trying to convince, lead or sometimes even force e.g. visual designer and sw engineers into predefined UCD processes. By doing so, they act more like crusaders than as partners, which means: they have a hard time to create acceptance – usually they cause even more resistance. [Abb. 2]

I will explain from an organizational psychologist perspective that management systems are social constructions as well as systems of power. These systems tend to stay in a stable position. The major dilemma of implementing new processes in such an environment is the ‚change management paradox‘: the system wants to remain in the stable state (=secure), but change means instability (=insecure). Resistance to change by the organizational structure is a ‚natural‘ occurrence and can hardly be avoided. It is important to understand the factors that drive resistance. I will also reflect the implications of a theory about individual resistance against mandatory changes in working environments (Brehm, 1972).

There are, however, levers that keep the system in motion all of the time: People trying to gain power by participating in topics that might raise their influence. Cooperation and participation therefore are the keys to give power to a new idea like implementing UCD. Stakeholders need to understand the benefit for themselves in their working environment in order to accept the instability of a change process. Ironically, Sir Isaac Newtons laws of physics give an good explanation of how to bring a system that wants to stay in a stable position into motion: you need a critical moving mass and a constant flow of energy, which is bigger than the energy of the reacting (resisting) body. I will use this analogy to explain that change management needs many more efforts than to create documentations and singular communication/qualification to be effective.

51


4. Manage the Change A model of acceptance (Brau, 2008 & 2011) will be introduced as an aid for finding facets of the change that will increase or decrease acceptance. This will enable participants to analyze their own or their clients organizational environment so that they can derive a strategic change management. [Abb. 3]

References 1. Brau, H. (2008). Mein System benutz’

Components of Attitudes. In: Rosenberg,

Nutzerakzeptanz zu messen und zu

M.J., Hovland, C.I., McGuire, W.J.,

verbessern. In: Brau, H. Diefenbach, S.,

Abelson, R.P., Brehm, J.W. (Eds.): Attitude

Hassenzahl, M., Koller, F. et al. (Hrsg.).

Organization and Change, pp. 1–14. New

Usability Professionals 2008. Fraunhofer: Stuttgart. 2. Brau, H. (2011). Acceptance Engineering

& Davis, F.D (2003). User Acceptance of Information Technology: Toward a Unified

Arbeitssystemen. In: Brandenburg,T.

View, MIS Quarterly, Vol. 27, No.3, pp.

& Thielsch, M. T. (Hrsg.). Praxis der

425–478.

Wissenschaft. of Freedom. A Theory of Psychological Reactance. Morristwon: General Learning Press. 4. Davis, F. D. (1986). A Technology Acceptance Model for Empirical Testing New End-User Information Systems: Theory and Results. Doctoral Dissertation, Sloan School of Management, Massachusetts Institute of technology. 5. Dickenberger, D., Gniech, G. & Grabitz, H.-J. (2001). Die Theorie der psychologischen Reaktanz. In: Dieter Frey & Martin Irle (Hrsg.) Theorien der Sozialpsychologie. Bd. I: Kognitive Theorien (S. 243–273). Bern: Huber. 6. Doppler, K. & Lauterburg, C. (1996). Change Management: Den Unternehmenswandel gestalten. Frankfurt/Main: Campus Verlag. 7. Eagly, A. H. & Chaiken, S. (1993). The Psychology of Attitudes. San Diego, CA and Fort Worth, TX: Harcourt Brace Jovanovich. 8. Fishbein, M. & Aijzen, I. (1975). Belief, Attitude, Intention and Behavior. Reading, MA: Addison-Wesley. 9. Hassenzahl, M. (2011). Encyclopedia entry on User Experience and Experience Design. Retrieved 26 February 2011 from InteractionDesign.org: http://www.interaction-design. org/encyclopedia/user_experience_and_ experience_design.html 10. ISO 9241–110: Ergonomics of human-system interaction Part 110: Dialogue principles 11. ISO 9241–210: Ergonomics of human–system interaction — Part 210: Human-centred design for interactive systems 12. Staehle, W. H. (1999). Management – Eine verhaltenswissenschaftliche Perspektive. Munich: Verlag Franz Vahlen.

52

Haven, CT: Yale University Press.Statista.org. 14. Venkatesh, V., Morris, M.G., Davis, G.B.

– Menschzentrierte Gestaltung von

3. Brehm, J. W. (1972). Responses to Loss

The presentation ends with the explanation of 7 golden rules for change managers: 1. Be neutral, do not be a crusader 2. Define a clear scope and stick to it 3. Quantify what you are doing 4. Know about and utilize quality management 5. Be competent and communicate competent 6. Participate managers by taking orders from them 7. Participate on all levels, but never rely on volunteers

Cognitive, Affective and Behavioral

ich nicht: Ein praxisorientierter Ansatz,

Wirtschaftspsychologie II. Münster: MV

Abb. 3.

13. Rosenberg, M. J. & Hovland, C. I. (1960).


Usability Professionals 2013 Tutorials

53


Von der Nutzungsanforderung zur formalen Softwarespezifikation Modellierung mit dem Werkzeug YAKINDU Requirements Florian Geyer itemis AG Am Brambusch 15–24 44536 Lünen florian.geyer@itemis.de

Jens Trompeter itemis AG Am Brambusch 15–24 44536 Lünen jens.trompeter@itemis.de

Abstract Die Analyse und Spezifikation von Software-Anforderungen ist eine komplexe Aufgabe, die als Grundlage jedes Softwareentwicklungsprojekts für den Erfolg oder Misserfolg maßgeblich ist. Oft bleiben jedoch Nutzungsanforderungen auf dem Weg zur Implementierung aufgrund einer mangelnden Integration in formale technische Spezifikationen auf der Strecke. Dieses Tutorial stellt einen werkzeugbasierten Ansatz zur Spezifikation komplexer interaktiver Systeme mit Hilfe des Werkzeugs YAKINDU Requirements vor. Das Werkzeug ermöglicht nicht nur eine Prozessunterstützung für die formale Spezifikation von SoftwareAnforderungen durch eine Verknüpfung verschiedener Prozessphasen und Modelle (Traceability), sondern bringt dabei interdisziplinäre Stakeholder wie Usability Professionals, Requirements Engineers, Systemarchitekten und Entwickler durch die Verwendung einer gemeinsamen Modellierungssprache zusammen. Das Tutorial demonstriert die Funktion und den Nutzen des Ansatzes an einfachen Beispielen und richtet sich dabei an Usability Professionals, die an einer formalen Integration von Nutzungsanforderungen, User-Interface-Entwürfen und Interaktionsabläufen in komplexe Softwareprojekte ­interessiert sind.

1. Motivation

1.1. Interdisziplinäre Spezifikation

Eine detaillierte und widerspruchsfreie Spe­zi­fikation von Anforderungen ist häufig die zentrale Grundlage erfolgreicher Soft­­ware­entwicklungsprojekte. Dabei sind nicht nur technische Anforderungen für den spä­teren Erfolg oder Misserfolg ­maßgeblich, sondern auch die konsequente Berücksichtigung von Anforderungen aus Anwenderperspektive (Hartson & Pyla, 2012). Effektives Anforderungsmanagement stellt daher das systematische Ermitteln, Dokumentieren, Prüfen und Verwalten von Nutzungsanforderungen im Zusammenspiel mit technischen Rahmenbedingungen sicher (Rupp, 2009; Robertson & Robertson, 2012). Auf Basis unserer Erfahrungen gibt es dabei zwei zentrale Hindernisse bei der Spezifikation und dem Management von Anforderungen: die Integration interdisziplinärer Zusammenarbeit und die kontinuierliche Änderung und Nachverfolgbarkeit von Anforderungen über inkrementelle Entwicklungsstufen.

Im Rahmen des Anforderungsmanagements üben Stakeholder aus unterschiedlichen Domänen Einfluss auf die Anforderungsspezifikation aus. Neben Requirements Engineers, Produktverantwortlichen und dem Management bringen auch Usability Engineers Nutzungsanforderungen ein oder übersetzen technische Anforderungen in Interaktionsabläufe und User-InterfaceEntwürfe. Schließlich sind auch Fachexperten oder Kaufleute genauso auf eine verständliche und konsistente Spezifikation angewiesen, wie Projektmanager, Systemarchitekten und Entwickler (Nyßen, 2009). Oft kommt es jedoch vor, dass die beteiligten Personen aus verschiedenen Domänen unterschiedliche „Sprachen“ sprechen, was zu Missverständnissen oder Fehldeutungen führen kann (Gross & Hess, 2011). Eine besondere Herausforderung dabei ist der Unterschied zwischen den Modellen und Sprachen, in denen Anforderungen von den Stakeholdern formuliert werden. So

54

Michael Jendryschik itemis AG Am Brambusch 15–24 44536 Lünen michael.jendryschik@itemis.de

Keywords: /// Anforderungsspezifikation /// Werkzeuge /// Requirements Engineering /// Usability Engineering /// Modellierung

erfordert eine formale technische Spezifikation eine exakte und eindeutige Formulierung von Anforderungen (z.B. Use Cases, Flowcharts oder UML-Diagramme). Dies steht oft im Kontrast zu vielen informelleren Artefakten, wie sie im Interaktionsdesign verwendet werden (z.B. Skizzen, Mockups oder Storyboards). Mangels Integration dieser verschiedenen Ausdrucksformen in formalen Spezifikationen bleiben wichtige Nutzungsanforderungen auf dem Weg zur Implementierung auf der Strecke. Um eine bessere Verknüpfung zu erreichen, ist daher eine gemeinsame, interdisziplinäre Basis für die Anforderungsspezifikation wünschenswert. 1.2. Spezifikationsdokumente Traditionelle Vorgehensmodelle wie das Wasserfallmodell und das V-Modell (Boehm, 1981) machen umfangreiche Vorgaben in Bezug auf die für das Requirements Engineering zu erstellenden Dokumente und Artefakte. Dies gilt ebenso für


Usability Professionals 2013 Tutorials

einige iterativ-inkrementelle Softwareentwicklungsprozesse wie den Rational Unified Process (RUP) (Jacobson et al., 1999). Agile Methoden unterscheiden sich hier deutlich vom klassischen Wasserfall-Modell und dessen Varianten. Statt in einer zu Beginn festgelegten Abfolge aus Spezifikation, Konstruktion und Umsetzung wird das Projekt in sehr enger, fortlaufender und direkter Zusammenarbeit mit dem Auftraggeber realisiert (Beck et al., 2001). Die Spezifikation erfolgt daher sukzessive während der Umsetzung (Paetsch et al., 2003). Das erlaubt zeitnahes Feedback und schnelle Reaktionen auf sich ergebende Veränderungen. Es gilt die Regel, dass neue und geänderte Anforderungen zu jeder Zeit willkommen sind. Diese Vorgehensweise erfordert jedoch Verzicht auf umfangreiche Spezifikationsdokumente oder deren kontinuierliche Anpassung und Erweiterung. Ein gänzlicher Verzicht bedeutet dabei jedoch auch die Aufgabe von Vorteilen formalisierter Vorgehensweisen, wie etwa Strukturierbarkeit,

Suchmöglichkeiten, Versionierung und Protokollierung von Änderungen sowie Auswertungsmöglichkeiten. Kontinuierliche Anpassung hingegen erfordert zusätzliche Aufwände, um eine Reihe auf sich aufbauende Anforderungen, Modelle und Gestaltungsartefakte anzupassen. Oft ist dies auch mit der Verwendung unterschiedlicher Werkzeuge verbunden (z.B. Requirements Management Tools, UML Tools, UI Mockup Tools), deren Ergebnisse schließlich in ein umfangreiches Dokument konsistent eingepflegt werden müssen. Diese Werkzeugketten erschweren die Nachverfolgbarkeit und eine zeitnahe und effiziente Änderung von Anforderungen. 2. Werkzeug-basierte Spezifikation mit YAKINDU Requirements Dieses Tutorial stellt einen Ansatz zur Spezifikation komplexer interaktiver Systeme mit Hilfe des Tools YAKINDU Requirements

(www.yakindu.de) vor. Das Spezifikationswerkzeug bietet eine, auch für agile Prozesse sinnvolle Formalisierung und ist damit eine Alternative zu schwergewichtigen und komplexen Werkzeugketten. Es erlaubt Anwendungsfälle (Use Cases), Abläufe, Masken/Maskenfolgen, Fachobjekte und Geschäftsregeln in textueller Notation formal zu beschreiben. Aus dem resultierenden konsistenten und prüfbaren Gesamtmodell lassen sich automatisch Dokumente wie Diagramme, Lasten- und Pflichtenhefte, Testfälle und Schätztabellen generieren. Der zentrale Vorteil dieses Ansatzes liegt darin, dass Nutzer einfach und schnell formale Anforderungsmodelle erstellen und diese auch in verteilten Teams effizient teilen und anpassen können. Durch die Verknüpfung verschiedener prozessübergreifender Modelle und Artefakte unterschiedlicher Domänen bringt das Werkzeug interdisziplinäre Stakeholder wie Usability Professionals, Requirements Engineers, Systemarchitekten und Entwickler

2

1

Abb. 1. Die integrierte Modellierungsumgebung YAKINDU Requirements.

3

55


zusammen. Die Verbindung der Anforderungen und Entwicklungsartefakte wird mit einer gemeinsamen Modellierungssprache ermöglicht, welche die Präzision und Eindeutigkeit formaler Spezifikationen mit einfach verständlichen, visuellen Repräsentationen kombiniert. Als einer der wichtigsten Bestandteile des Requirements Managements ermöglicht dies eine bidirektionale Navigierbarkeit, mit dem Ziel, Anforderungen verfolgen und nachvollziehen zu können. Jedes Entwicklungsartefakt lässt sich so auf Anforderungen und Modelle zurückführen und hilft eventuelle Wechselwirkungen von Änderungen zu verstehen. 2.1. Integrierte Modellierungsumgebung YAKINDU Requirements ist eine integrierte Modellierungsumgebung basierend auf der offenen Plattform Eclipse (www.eclipse.org). Es kombiniert eine textuelle Notation mit grafischen Modellen und Editoren (siehe Abb. 1). Die grundlegende Modellierungsumgebung ist aufgebaut auf einen Navigationsbereich (1), einen textueller Editor (2) und eine grafische Visualisierung (3). Ein hierarchischer Projektexplorer ermöglicht es dem Nutzer eine klare Struktur zu erstellen und zwischen Anforderungen, Modellen und Artefakten der Spezifikation zu navigieren (siehe Abb. 1, 1). Mittels des textuellen Editors (siehe Abb. 1, 2) können Modelle formal spezifiziert werden. YAKINDU Requirements verwendet hierfür eine einfache, schnell erlernbare Sprache,

die Vorteile wie Textvervollständigung, Textbausteine und Templates, sowie Fehlerkorrekturen und Konsistenzprüfungen integriert. Aufgrund des textbasierten Datenmodells ist es zudem möglich, durch Copy & Paste, Refactoring und der Verwendung von Diff- und Merge-Werkzeugen Änderungen oder Erweiterungen effizient zu verwalten. Zusätzlich bietet die Sprache eine durchgängige Referenzierung und bidirektionale Verknüpfung von Inhalten und kann um individuelle Konzepte und domänenspezifische Konzepte erweitert werden. Diese formale Spezifikation wird ergänzt durch eine grafische Aufbereitung der Modelle in einem Vorschau-Bereich (siehe Abb. 1, 3). Der Vorschaubereich stellt eine automatisch generierte grafische Repräsentation des textuell beschriebenen Modells dar und ermöglicht so dem Nutzer, einen Überblick über abstrakte Konzepte zu erhalten. Zusätzlich kann die grafische Darstellung ebenfalls zur Navigation innerhalb und zwischen Modellen und verknüpften Artefakten genutzt werden. [Abb. 1] YAKINDU unterstützt derzeit folgende, miteinander verknüpfte Modelle zur Spezifikation von Softwareprojekten: – Requirements-Modell – Anforderungen, deren Metadaten und Attribute – Use-Case-Modell – Anwendungsfälle, Akteure und deren Zusammenhänge – Entity-Modell – Objekte und deren Typisierungen und Relationen – Lifecycle-Modell – Prozessmodell der Anwendung und der Daten

Abb. 2. Beschreibung eines Use Cases in der YAKINDU Modellierungssprache.

56

Abb. 3. Aus der textuellen Beschreibung automatisch generiertes Use Case Diagramm.

– UI-Modell – Masken und Komponenten der Benutzerschnittstelle – UI-Flow-Modell – Verhalten der Benutzerschnittstelle und der Komponenten 2.2. Beispiel: Use­Case­Modellierung Abbildung 2 zeigt an einem Beispiel, wie mit Hilfe von einfachen Schlüsselwörtern Use Cases spezifiziert werden können. Der beispielhafte Anwendungsfall „submit app for leave“ enthält einen Ablauf (basic flow) mit mehreren Schritten und Alternativen, aus denen YAKINDU Requirements automatisch visuelle Diagramme erzeugt und im Vorschaubereich anzeigt (siehe Abb. 3). Zudem enthält das Beispiel eine Reihe von Verknüpfungen zu anderen Artefakten, wie zu verwandten Anwendungsfällen (requires, invokes), zu relevanten Anforderungen (requirements), Akteuren (actors), einem Datenmodell (entities) und zu Entwürfen der Benutzerschnittstelle (pages). Diese


Usability Professionals 2013 Tutorials

blau dargestellten, interaktiven Links ermöglichen dem Nutzer die Nachverfolgbarkeit von Veränderungen und erleichtern die Navigation zwischen den Modellen. YAKINDU Requirements nutzt diese Verknüpfungen jedoch auch, um die Konsistenz und Validität der Spezifikation sicher zu stellen. So wird der Nutzer beispielsweise benachrichtigt, falls ein bestimmter Akteur in keinem der spezifizierten Use Cases referenziert wurde. Das System unterstützt den Nutzer aktiv dabei, die formale Spezifikation auf Validität und Konsistenz zu prüfen – eine Aufgabe, die mit traditionellen Spezifikationsdokumenten nur sehr schwer zu realisieren ist. [Abb. 2], [Abb. 3] 2.3. Beispiel: User­Interface­Modellierung Die Definition der Benutzerschnittstelle einer Anwendung wird mit Ablaufdiagrammen unterstützt (vgl. Page Flows, Storyboards). Abbildung 4 zeigt beispielhaft die Modellierung eines Login-Vorgangs. YAKINDU Requirements verfolgt hier einen

Ansatz der visuellen Modellierung, der für Usability Engineers vertraut ist. Über einen grafischen Editor, der einem Ablaufdiagramm ähnelt, werden dynamische Veränderungen von Komponenten und Übergänge zwischen Masken modelliert (siehe Abb. 4, 1). So kann hier formal spezifiziert werden, wie das Verhalten der Anwendung durch Nutzerinteraktion und Programmlogik visualisiert wird. Der Editor verwendet hierfür das Konzept der „Screens“, um dynamische Veränderungen in Zustände abzubilden. Neben einer Verknüpfung zu dem dahinter liegenden Design Rationale (Use Cases, Nutzungsanforderungen), können diese Zustände zudem mit Skizzen oder Mockups verknüpft werden (siehe Abb. 4, 2). Durch die Möglichkeit, Bilddateien per Drag & Drop zu integrieren, können auf einfache Weise beliebige Prototyping oder Mockup-Tools für die Visualisierung von Screen-Designs verwendet werden (auch gescannte oder abfotografierte Handskizzen). Durch die konsistente Verlinkung der Modelle ist sicher gestellt, dass sich

Designentscheidungen vom User-Interface-Entwurf bis hin zu den Requirements zurückverfolgen lassen. Die potentiellen Auswirkungen von Änderungen sind daher jederzeit kontrollierbar, egal ob sie durch Feedback von Nutzertests (top-down) oder durch neue Produktanforderungen oder veränderte technische Rahmenbedingungen entstanden sind (bottom-up). [Abb. 4] 2.4. Automatische Generierung von Spezifikationsdokumenten Durch den Ansatz einer integrierten Modellierungsumgebung ermöglicht YAKINDU Requirements die Verknüpfung von Modellen zu einer umfassenden interaktiven Spezifikation, die während des Entwicklungsprozesses leicht aktualisiert und angepasst werden kann (Change Management & Traceability). Alle Stakeholder – seien es Entwickler, Software-Architekten oder Usability Engineers – können interaktiv durch die hierarchisch organisierte und durch Querverbindungen verdichtete

1

2

Abb. 4. Spezifikation einer Benutzerschnittstelle (UI Flow Modell).

57


Spezifikation Requirements Use Cases Entities

Fdf ggdf gdfg Sdfsdf ds sdf dsfd d dsf Dsfsdfd Sdf df dfsdf Dfsdf dfsdfdsf Dfsd fd d sf dsfsdfdsf

Lifecycles Actors User Interface

Projektstrukturplan

3. Ausblick

User Interface Flow

Abb. 5. Automatische Erzeugung von Dokumenten aus den Modellen der interaktiven Spezifikation.

Struktur der Spezifikation navigieren. Ein entscheidender Vorteil liegt dabei darin, dass alle am Spezifikationsprozess aktiv beteiligten Personen dasselbe Werkzeug und dieselbe konsistente Datenbasis verwenden. Schnittstellen auf der Ebene von Anforderungen (Requirements Interchange Format ReqIF, www.omg. org/spec/ReqIF/) und User-Interface-Entwürfen erlauben zudem eine Integration von domänenspezifischen Werkzeugen. Darüber hinaus bietet YAKINDU Requirements umfangreiche Exportfunktionen, die es ermöglichen, automatisiert zielgruppengerechte Dokumente zu erzeugen (siehe Abb. 5). [Abb. 5] Das Werkzeug lässt den Benutzer entscheiden, wie der Dokumentenexport aussehen soll und welchen Umfang und Vollständigkeit die erzeugten Dokumente besitzen. YAKINDU Requirements verwendet hierfür die Business-Intelligence Software BIRT, ein Projekt der Eclipse Foundation (www.eclipse.org/birt). So ist es möglich aus der Datenbasis für

58

beispielsweise wie viele Anwendungsfälle ein bestimmtes Objekt nutzen, werden automatisch erledigt. Diagramme und Visualisierungen wie Anwendungsfalldiagramme und Zustandsautomaten werden vollautomatisch aus den erfassten Beschreibungen erzeugt, sodass Änderungen über den gesamten Prozess gepflegt werden können – von der Architektur über Design, Implementierung bis hin zu den Tests und umgekehrt. Das Resultat ist eine, auf Knopfdruck erzeugte Spezifikation, die stets auf dem aktuellen Stand ist und dabei unterschiedliche Perspektiven berücksichtigt.

unterschiedliche Zielgruppen geeignete Dokumente zu erzeugen, wie beispielsweise ein ausführliches Lastenheft, das die Gesamtheit der Anforderungen eines Auftraggebers umfasst, oder einen Projektstrukturplan (Work Breakdown Structure), der einen Überblick über die Komplexität der zu entwickelnden Komponenten für das Projektmanagement bietet (McConnell, 2006). Individuelle ExportDefinitionen ermöglichen darüber hinaus viele weitere flexible Einsatzszenarien. Weitere Einstellungen für den Dokumentenexport umfassen unterschiedliche Sprachen (deutsch, englisch), Formate (PDF, HTML, Office) und individuelle Layout- und Formatierungsregeln (CSS Stylesheets). Zusätzlich lassen sich die erzeugten Dokumente auch manuell anpassen und erweitern, falls dies erforderlich ist. Automatisch erstellte Anforderungsspezifikationen haben einen entscheidenden Vorteil gegenüber traditionellen, dokumentenbasierten Spezifikationen: Bislang in Handarbeit durchgeführten Auswertungen,

YAKINDU Requirements hat seinen Ursprung in der Domäne des Requirements Engineering und orientierte sich dabei im Kern am Ansatz des „Use Case Modeling“ (Bittner & Spence, 2002). Die aus dem Software Engineering stammende Methode richtet sich vor allem an Stakeholder mit einem technischen Hintergrundwissen, deren primäre Aufgabe die Spezifikation und das Management von Software-Anforderungen ist. Von diesem Fundament aus wurde die Modellierungssprache von YAKINDU Requirements kontinuierlich erweitert, um auch Stakeholder aus anderen Domänen aktiv in den Spezifikationsprozess einzubinden. Das Ziel des Werkzeuges ist es die Probleme interdisziplinärer Zusammenarbeit und die Schwerfälligkeit von umfangreichen Dokumenten und Werkzeugketten zu adressieren. Mit dem Ansatz einer interdisziplinären Modellierungsumgebung unterstützt die Software eine inkrementell-iterative Spezifikation und erleichtert es damit auch effizient mit der kontinuierlichen Änderung von Anforderungen in einem kollaborativen Umfeld umzugehen. Deshalb bietet es gerade bei agilen Prozessen, die trotzdem formalen Ansprüchen genügen müssen, eine angemessene Methodik. Dabei ermöglicht es der Ansatz auch, nichtfunktionale Anforderungen mit einer formalen, funktionalen Spezifikation zu verknüpfen und deren Abhängigkeiten und Querbezüge sichtbar zu machen.


Usability Professionals 2013 Tutorials

Der Modellkatalog von YAKINDU Requirements kann auf einfache Weise mit domänenspezifischen Modellen erweitert werden. Momentan wird die Modellierungssprache auf Anforderungsbeschreibungsmodelle des Usability Engineerings ausdehnt. Unsere Erfahrungen haben gezeigt, dass es aufgrund einer fehlenden Verknüpfung von Usability Artefakten beispielsweise oft nicht möglich ist, Designentscheidungen bis zu den ursprünglich erhobenen Erfordernissen aus einer Kontextanalyse zurückzuverfolgen. So sollen in Zukunft Modelle wie Nutzungsszenarien (Rosson & Caroll, 2001), Personas (Cooper et al., 2007), und Essential Use Cases (Constantine & Lockwood, 1999) sowie allgemeine Gestaltungsrichtlinien und Standards (z.B. DIN EN ISO 9241–110) als Vorlagen und Templates in den Katalog aufgenommen werden. Durch eine Verknüpfung dieser Modelle mit der formalen funktionalen Spezifikation rücken die Disziplinen Usability Engineering und Software Engineering stärker zusammen. So werden sich etwa Nutzungsszenarien mit technischen Use Cases verbinden lassen, um den Kontext der Nutzung im Spezifikationsdokument abzubilden. Auf ähnliche Art und Weise soll es auch möglich sein Personas mit Akteuren zu verbinden, um den Einfluss von Nutzereigenschaften auf die Systemgestaltung festzuhalten. Schließlich soll eine Verknüpfung von allgemeinen oder systemspezifischen Richtlinien dafür sorgen, die Wahl einer bestimmten Gestaltungslösung für alle Stakeholder nachvollziehbar zu machen.

Literatur 1. 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. C., Mallor,

14. Rosson, M. B. und Caroll, J. M (2001). „Usability Engineering: Scenario-Based Development of Human-Computer Interaction“. Morgan Kaufmann. 15. Rupp, C. (2009). „Requirements-Engineering

S., Schwaber, K., und Sutherland, J. (2001)

und -Management: Professionelle, iterative

„The agile manifesto“. The Agile Alliance.

Anforderungsanalyse für die Praxis“. Carl

2. Bittner, K. und Spence, I. (2002). „Use Case

Hanser Verlag.

Modeling“. Addison-Wesley. 3. Boehm, B. W. (1981). „Software Engineering Economics“. Prentice-Hall. 4. Constantine, L. L. und Lockwood, L. D. (1999). „Software for Use: A Practical Guide to the Methods of Usage-Centered Design“. ACM Press. 5. Cooper, A., Reimann, R. und Cronin, D. (2007). „About Face 3. The Essentials of Interaction Design. John Wiley & Sons. 6. DIN EN ISO 9241–110 (2011). „Ergonomie der Mensch-System-Interaktion. Teil 110: Grundsätze der Dialoggestaltung“. International Organization for Standardization. 7. Gross A. und Hess S. (2011). „UX meets RE – Hohe User Experience durch bedarfsgerechte Anforderungsspezifikation“. Tagungsband Usability Professionals 2011, German UPA, 24–29. 8. Hartson, R. und Pyla, P. (2012). The UX Book: Process and Guidelines for Ensuring a Quality User Experience“. Morgan Kaufmann. 9. Jacobson, I., Booch, G., und Rumbaugh, J. (1999). „The Unified Software Development Process“. IBM. 10. McConnell, S. (2006). „Software Estimation: Demystifying the Black Art“. Microsoft Press. 11. Nyßen, A. (2009). „Model-based construction of embedded and real-time software: a methodology for small devices“. Dissertation. Universitätsbibliothek Aachen. 12. Paetsch, F., Eberlein, A. und Maurer, F. (2003) „Requirements Engineering and Agile Software Development“. Proceedings on the Twelth IEEE International Workshop on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE). pp. 308–313. 13. Robertson, S., und Robertson, J. (2012). „Mastering the Requirements Process: Getting Requirements Right“. AddisonWesley Longman.

59


Bummler und Schummler – wie effizient ist mein UI wirklich? Bearbeitungszeiten analysieren und verstehen mit Probability Plots Bernard Rummel SAP AG Dietmar-Hopp-Allee 16 69190 Walldorf bernard.rummel@sap.com

Abstract Bearbeitungszeiten gehören zum klassischen Instrumentarium von Usability Tests, um die Effizienz des UIs zu erfassen. Was nach objektiver Messung aussieht, hat aber einige Tücken. Was kann man tun, wenn nicht alle Benutzer die gestellte Aufgabe lösen? Rechnet man nur die erfolgreichen Benutzer ein – „survival of the fittest“ – erscheint das UI effizienter, als es in Wirklichkeit ist. Auch ein besonders schneller user könnte, besonders in unmoderierten Tests, immer auch geschummelt haben. Da Zeiten selten normalverteilt sind, geben Mittelwert und Standardabweichung ein schiefes Bild – überlange Zeiten sind oft keine Ausreißer, sondern statistisch zu erwarten. Probability Plotting, eine graphische Methode aus der technischen Zuverlässigkeitsanalyse, löst diese Probleme auf elegante Weise. Die Betrachtung verschiedener Verteilungstypen ermöglicht neue Einsichten – z.B. die getrennte Betrachtung von technischer Performance und Effizienz des UI-Designs. Die Plots erlauben ein schnelles Screening der Daten auf Auffälligkeiten; damit eignet sich die Methode besonders für unmoderierte Online-Tests.

1. Effizienz: „State of The Art“ – und Probleme damit Aufgaben-Bearbeitungszeiten werden in Usability-Tests typischerweise gemessen, um die Effizienz des UIs zu erfassen. Nach ISO9241–11:1998 beschreibt Effizienz eigentlich den Aufwand, den ein User zur Erreichung seiner Ziele betreiben muss, in Relation zur Genauigkeit und Vollständigkeit der Lösung – gemeint ist also nicht nur der zeitliche Aufwand. Trotzdem hat sich die Zeitmessung als „offensichtlich“ objektive Metrik soweit etabliert, dass sie auch im Common Industry Format for usability test reports (CIF, ISO/IEC 25062) explizit eingefordert wird. Üblich und standardkonform ist dabei die Angabe von Mittelwert, Standardabweichung, Minimum und Maximum der Bearbeitungszeit pro Aufgabe.

60

Was vernünftig und objektiv klingt, ist in der Praxis gar nicht so einfach: 1. Welche Daten sollen überhaupt in die Analyse eingehen? Was ist mit Personen, die die gestellte Aufgabe nicht lösen? Schließt man sie aus, überschätzt man die Effizienz des UIs. Aber was wäre die Alternative? Was ist mit Bummlern und Schummlern, also Personen, die ganz oder teilweise etwas anderes tun, als die Aufgabe zu bearbeiten? Wie kann man überhaupt „Ausreißer“ entdecken, die unge­ wöhnlich lange brauchen oder auffällig schnell sind – wann ist eine Bearbeitungszeit nicht mehr „normal“? 2. Was ist mit unterschiedlichen System­ antwortzeiten? Technische Antwortzeiten können einen mehr oder weniger großen Anteil der Bearbeitungszeit ausmachen. Wollen wir Vergleiche z.B. zwischen verschiedenen

Keywords: /// Usability-Testing /// Bearbeitungszeit /// Effizienz /// Analysemethoden

mobilen Plattformen anstellen, müssen wir technische Einflüsse von Design­ problemen sauber trennen. Gerade Smartphones lassen sich aber nicht so einfach für entsprechende Zeiter­ fassungen instrumentieren – und mit der nächsten Gerätegeneration oder OS-Version sähe wieder alles anders aus. 3. Sind Mittelwert und Standardab­wei­ch­ ung überhaupt geeignete Metriken? In der Literatur findet man immer wieder Hinweise, dass Bearbeitungs­ zeiten nicht normalverteilt seien (z.B. Sauro & Lewis, 2009, Sauro, 2011; ausführliche Behandlung bei Luce, 1986), kurioserweise aber kaum Angaben, welche Verteilungen denn nun vorliegen. Dabei kann diese Infor­ mation entscheidend sein: bei Expo­ nential- oder Lognormalver­tei­lun­gen sind überlange Bearbeitungszeiten


Usability Professionals 2013 Tutorials

keine Ausnahmen, sondern statistisch zu erwarten. Verwendet man statt des Mittelwerts Median oder geome­ trisches Mittel (wie z.B. Sauro, 2011 empfiehlt), erscheinen solche Zeiten noch exotischer, als sie sind, da das geometrische Mittel typischerweise kleiner als das arithmetische Mittel ist und der Unterschied dadurch noch krasser ausfällt. 4. Wie kann man Effizienz überhaupt parametrisieren? Natürlich hängt die Bearbeitungszeit für eine Aufgabe auch von deren Kom­ plexi­tät ab. Ein effizientes Design zeichnet sich dadurch aus, dass gerade komplexe Aufgaben schnell erledigt werden können. Wie kann man aber die Effizienz von Designs bei verschiedenen Aufgaben vergleichbar erfassen? Sauro (2011) schlägt verschiedene Stra­ tegien vor, die letztlich auf Vergleich mit „kritischen“ Bearbeitungszeiten beruhen. Solche Zeiten können z.B. maximal akzeptable Prozesszeiten,  Be­ar­beitungszeiten von vergleichbaren Produkten, Vielfache von „Ideal“oder „Experten“-Zeiten usw. sein. Die „bootstrapped specification limit“Zeit (Sauro & Kindlund, 2005) ist die maximale Zeit, die Benutzer mit einer minimalen definierten Benutzerzufrie­ denheit brauchten („Wie lange darf man brauchen, um nicht gar zu unzu­ frie­den zu sein?“). All diese Ansätze sind insofern problematisch, als sich Messfehler und zufällige Streuungen in der Zeitmessung durch den Vergleich erheblich aufaddieren können. 2. Probability Plotting Probability Plotting ist eine graphische Methode aus der technischen Zuverlässigkeitsanalyse, die einige der genannten Probleme elegant löst. Zuverlässigkeitsingenieure analysieren typischerweise Ausfallzeiten, also die Zeit bis zum Ver­sagen eines Teils. Wir hingegen betrachten die Zeit bis zum Erfolg des Benutzers, haben also genau die umgekehrte Perspektive.

Die Mathematik und einige zentrale Konzepte lassen sich trotzdem gut übertragen. Der Grundgedanke be­steht darin, die beobachteten Zeiten zu sortieren und gegen diejenigen Perzentilwerte zu plotten, bei denen man sie unter Vorliegen einer bestimmten Verteilungsannahme erwarten würde. Passen die beobachteten Daten zur erwarteten Verteilung, erscheinen die Datenpunkte als gerade Linie. Ausreisserwerte sind unmittelbar daran erkennbar, dass sie von einem ansonsten systematischen Muster abweichen. Hat man die zugrundeliegende Verteilung identifiziert, kann man aus dem entsprechenden Plot Verteilungsparameter ermitteln, die durchaus informativer sein können als Mittelwerte. 2.1. Probability Plots erstellen Das e-Handbook of Statistical Methods des US National Institute of Standards and Technology (NIST/SEMATECH 2012a) bietet eine frei zugängliche Schritt-fürSchritt- Beschreibung zur Erstellung von Probability Plots (NIST/SEMATECH 2012b), auf die hier daher verzichtet wird. Eine xls-Datei mit den für usability professionals wichtigsten Plots kann beim Autor angefragt werden. Die folgende Darstellung beschränkt sich auf konzeptionelle Aspekte. Betrachten wir eine Menge von Teilen bzw. Benutzern. Zu einem gegebenen Beobachtungszeitpunkt kann es vorkommen, dass das betreffende Teil noch nicht ausgefallen ist, bzw. der betrachtete Benutzer die Aufgabe noch nicht gelöst hat. Wann genau das passieren wird, weiß man nicht; jedoch ist sicher, dass es bis zum Beobachtungszeitpunkt noch nicht passiert ist. Derartige Daten werden in der Zuverlässigkeitsanalyse als censored bezeichnet. Bei Aufgaben ohne Zeitlimit kommt es oft vor, dass ein Benutzer zu einem bestimmten Zeitpunkt aufgibt oder aber eine falsche Lösung angibt. Da dies für jeden Benutzer zu einem individuell verschiedenen Zeitpunkt vorkommen

kann, müssen Usability-Testdaten als multiply censored betrachtet werden. Das Censoring-Konzept erlaubt uns, auch die Daten nicht erfolgreicher Benutzer in die Analyse einzubeziehen. Wir wissen ja, dass ein Benutzer bis zum Feststellen des Misserfolgs die Aufgabe nicht gelöst hat, und können diese Information nutzen. Die Zeiten, zu denen Benutzer eine Aufgabe gelöst oder eben nicht gelöst haben, werden dazu einfach sortiert, zusammen mit der Information, welche Benutzer erfolgreich waren. Die Rangnummern werden dann mit der Modified Kaplan-Meier (K-M) Product Limit procedure (NIST/SEMATECH 2012c) korrigiert, die im Wesentlichen darin besteht, jedem Benutzer i mit seiner individuellen Bearbeitungszeit ti einen Prozentrang R(ti) zuzuweisen, der seiner Position in einer theoretischen Gesamtpopulation aller Benutzer entspräche, und zwar inklusive der nicht erfolgreichen Benutzer. Vereinfacht gesprochen ist R(t) der Anteil Benutzer, von dem man erwartet, die Aufgabe nicht zu lösen. Die beobachteten Zeiten ti werden nun gegen die Prozentränge R(ti) geplottet. Die Achsen werden dabei spezifisch für jeden Verteilungstyp spezifisch transformiert (NIST/ SEMATECH 2012b): –– Für Exponentialverteilungen ist die R-Achse logarithmisch, die Zeitachse linear skaliert –– Für Weibull-Verteilungen sind beide Achsen logarithmisch skaliert –– Für Normal- und Lognormalverteilungen werden statt der Prozentränge R(t) die inversen Normalverteilungswerte des Komple­ ments z(1-R(t)) verwendet, bei der Lognormalverteilung wird zusätzlich die Zeitachse logarithmisch skaliert. Das Ergebnis sind im vorliegenden Fall vier Plots, jeweils einer für Exponential-, Weibull-, Normal- und Lognormalverteilung. Passen die Daten zu einer bestimmten Verteilung, erscheinen die Datenpunkte im entsprechenden Plot als gerade Linie¹. [Abb. 1]

61


Abb. 1. Probability Plots für ­Bearbeitungszeiten von 18 Benutzern einer SmartphoneAnwendung zur Reisekostenerfassung. Exponential- und Normalverteilungsplot deuten auf einen „Bummler“ hin, der jedoch nahezu perfekt in die Weibull- und Lognormalverteilung passt.

2.2. Probability Plots interpretieren Die Interpretation von Probability Plots hängt u.a. vom gefundenen Verteilungstyp ab. Die häufigsten Verteilungen in Usability Tests sind Lognormal-, Exponential- und Weibull-Verteilung, in dieser Reihenfolge. Welche Verteilung vorliegt, kann man an den entsprechenden Verteilungs-spezifischen Plots prüfen: sind die Datenpunkte hinreichend linear angeordnet, kommt die betreffende Verteilung infrage. Um das genauer zu prüfen, können wir im Plot jeweils eine Regressionsgerade hinzufügen. Der zugehörige R²-Wert (d.h. der Anteil der durch das Regressionsmodell erklärten Varianz) ermöglicht einen einfachen Signifikanztest: NIST/SEMATECH (2012d) gibt eine Tabelle mit kritischen Werten hierzu an. Ist das beobachtete R² kleiner als der kritische Wert, ist die Hypothese zu verwerfen, dass die beobachtete Verteilung der angenommenen entspräche.

62

Im nächsten Schritt kann der Plot auf Aus­ reisser inspiziert werden. Als Ausreisser kommen Datenpunkte infrage, die nicht in die Verteilung der übrigen Datenpunkte passen. Im Plot ist das unmittelbar sichtbar: die kritischen Punkte liegen deutlich abseits der Regressionsgeraden, und zwar deutlich mehr als die übrigen Punkte, die zufällig um die Regressionsgerade verstreut sind. Oft ist das bei besonders schnellen oder langsamen Benutzern der Fall – potenziellen „Schummlern“ oder „Bummlern“, bei denen man seine Aufzeichnungen genauer auf weitere Auffälligkeiten inspizieren sollte. Zur weiteren Interpretation und Parameterschätzung werden Ausreisser entfernt und die Plots neu berechnet. Hat man ein passendes Verteilungsmodell gefunden, kann der entsprechende Plot weiter ausgewertet werden. Die Regressionsgerade bietet ja ein einfaches lineares

Modell der gesamten Stichprobenverteilung! Da wir Zeiten und Prozentränge gegeneinander geplottet haben, können wir direkt ablesen, welcher Prozentsatz von Benutzern zu einer gegebenen Zeit die Aufgabe gelöst hat, bzw. welche Erfolgsquote wir zu einer bestimmten Zeit erwarten können. Weil dazu allerdings die Skalentransformationen der Achsen zurückgerechnet werden müssen, empfiehlt es sich, interessante R-Werte bzw. Perzentile (z.b. 0.05, 0.5 und 0.95, also 5, 50 und 95% der Benutzer) von vornherein in den Plot einzuzeichnen; die Schnittpunkte mit der Regressionsgeraden geben die entsprechenden Zeiten an. Die weitere Interpretation und Parameterschätzung hängt von der gefundenen Verteilung ab.


Usability Professionals 2013 Tutorials

2.2.1. Lognormalverteilung Findet man eine Lognormalverteilung, erhält man eine Normalverteilung, indem man seine Daten einfach logarithmiert. Mit diesen logarithmierten Bearbeitungszeiten kann man dann ohne weiteres parametrische statistische Tests wie t-Test und Varianzanalyse ausführen und auf Signifikanz prüfen, muss allerdings zur Beurteilung von Unterschieden auf die ursprüngliche lineare Skala zurückrechnen. In diesem Fall ist es auch völlig gerechtfertigt, wie von Sauro (2011) empfohlen das geometrische Mittel als Statistik zu verwenden, da es gleich dem arithmetischen Mittel der Logarithmen, zurücktransformiert auf die lineare Skala ist. Im Plot entspricht diese Zeit dem Schnittpunkt der Regressionsgeraden mit der Zeitachse, allerdings mit einem wichtigen Unterschied: durch das censoring berücksichtigt der Plot auch die Information von nicht erfolgreichen Benutzern, die man bei rein rechnerischer Bestimmung verwerfen müsste. Nur bei 100% Erfolgsquote sind beide Werte gleich; bei geringeren Erfolgsquoten ergibt der Plot eine längere Zeitdauer. 2.2.2. Exponentialverteilung Exponentialverteilungen sind typisch für Zeit-Intervalldaten. Sie sind charakteristisch für Prozesse wie z.B. radioaktiven Teilchenzerfall, Zeitintervalle zwischen Call Center-Anrufen etc., bei denen Ereignisse unabhängig voneinander und zufällig eintreten. Mathematisch lässt sich die Exponentialverteilung vollständig durch einen einzigen Parameter λ beschreiben. λ wird auch als Ausfallrate bezeichnet, da es in der Zuverlässigkeitsanalyse den Anteil der Teile beschreibt, die in einem gegebenen Zeitintervall ausfallen – und dieser Anteil ist bei Exponentialverteilungen konstant. Im Probability Plot von exponentialverteilten Usability-Testdaten (Beispiel: Abb. 2) findet man typischerweise eine Regressionsgerade, die die Zeitachse nicht im Ursprung schneidet, sondern zu einer Zeit

Abb. 2. Probability Plot für exponentialverteilte Bearbeitungszeiten mit λ=0,0645 und t0=25,7s. Die horizontalen Linien entsprechen dem 5., 50. und 95. Perzentil der erwarteten Verteilung. Die Konfidenzbänder der Regressionsgeraden stellen die Schätzungs- bzw. Vorhersagegenauigkeit dar. Das Exponentialmodell erklärt R²=97,5% der beobachteten Varianz.

t0. Die Exponentialverteilung ist daher nicht rein (und rechnerisch daher leicht zu übersehen), sondern um t0 verschoben. Erst nachdem die Zeit t0 verstrichen ist, beobachtet man eine konstante Lösungsrate λ, d.h. einen pro Zeiteinheit konstanten Anteil Benutzer, die die gestellte Aufgabe lösen. λ entspricht auch mathematisch der Steigung der Regressionsgeraden: ist sie steil, löst pro Zeiteinheit ein größerer Anteil der Benutzer die Aufgabe; ist sie flach, entsprechend weniger. Das Exponentialverteilungsmodell teilt die beobachteten Zeiten damit mathematisch in einen konstanten Anteil t0 und einen Zufallsprozess mit der Lösungsrate λ ein. Wenn dieses Modell die Daten korrekt abbildet, was in der Regel der Fall ist, was bedeuten dann t0 und λ in der Realität? t0 liegt typischerweise nahe an der minimalen Bearbeitungszeit, d.h. der Zeit der schnellsten Benutzer, die nicht geschummelt haben, bzw. der Zeit, die man braucht, um als Experte die Aufgabe auf dem Idealpfad einfach durchzuklicken. Es ist plausibel, dass sich diese Zeit nicht weiter minimieren lässt, sondern durch physikalische Grenzen wie Systemreaktionszeiten und motorische Abläufe

bestimmt wird, also die mechanische Effizienz der Benutzungsoberfläche beschreibt. [Abb. 2] Der zu t0 aufsetzende Zufallsprozess umfasst all die Zeitanteile, die zufälligen Schwankungen unterworfen sind. Zwar ist das auch bei motorischen Abläufen der Fall, doch ist dieser Varianzanteil vernachlässigbar gegenüber der Zeit, die Benutzer damit verbringen, Funktionen zu suchen, Fehler zu machen und zu korrigieren, und überhaupt die Benutzungsoberfläche zu verstehen. Dieser letztere Zeitanteil ist hoch variabel und entscheidend geprägt durch die Verständlichkeit der Benutzungsoberfläche. Die Lösungsrate λ ist damit ein direktes Maß für die kognitive Effizienz der Benutzungsoberfläche. Abbildung 3 zeigt schematisch überlagerte Probability Plots von drei Apps. Die Apps A und B weisen denselben Achsenschnittpunkt t0 auf, doch hat A eine deutlich höhere Lösungsrate λ. Würde man nur die Mittelwerte betrachten, würde A zwar besser abschneiden, der Unterschied würde jedoch nicht statistisch signifikant, da sich die beiden Verteilungen stark überlappen. Tatsächlich führt die geringere Lösungsrate von B zu einer größeren Streuung

63


und damit Standardabweichung der Zeiten. Anders ausgedrückt: je schlechter die Anwendung ist, desto schwerer ist es, diese Tatsache statistisch signifikant nachzuweisen! Betrachten wir die Apps B und C: hier würde man überhaupt keinen Unterschied der Mittelwerte feststellen, beide sind gleich. B hat jedoch eine deutlich geringe Lösungsrate, während C längere Klickpfade und/oder schlechtere Systemperformance aufweist. Die Apps B und C zeigen ein typisches Dilemma im UI Design: sind aufgeräumte, einfache Screens längere Klickpfade wert? Sollte man eher in die Performance von C oder in das Interaktionsdesign von B investieren? Da beide Faktoren hier getrennt visualisiert sind, kann das Designteam informierte Entscheidungen treffen. Performance-Verbesserungen von B, wie sie ein technologiefixiertes Team möglicherweise vorschlagen würde, können leicht als ungeeignet erkannt werden: sie wären teuer (B ist schon performant) und uneffektiv (weiterhin würden sehr lange Bearbeitungszeiten vorkommen, wie man in der unteren Hälfte des Plots sieht). [Abb. 3]

Abb. 3. Schematisch überlagerte Probability Plots (Exponentialverteilung) für drei Apps.

2.2.3. Weibull­Verteilung Während Exponentialverteilungen eine konstante Lösungsrate aufweisen, ist die Lösungsrate bei Weibull-Verteilungen einer systematischen Zu- oder Abnahme unterworfen. Typischerweise zeigen Weibull-verteilte Bearbeitungszeiten eine

64

stetige Abnahme der Lösungsrate, was sich im Exponentialplot als Abflachung der Datenkurve und im Weibull-Plot als gerade Linie zeigt. Eine mögliche Ursache sind bei überlangen Aufgaben zunehmende Ermüdung, Frustration und Konzentrationsverlust. Der Weibull-Plot ist besonders informativ, wenn überlange Bearbeitungszeiten auftreten und es nicht sicher ist, ob man es bei besonders langsamen Benutzern mit Ausreißern („Bummlern“) zu tun hat. Passen die Zeiten in ein Weibull-Modell, d.h. der Plot ist linear und auch die „Bummler“ liegen auf der Regressionsgeraden, deutet das auf eine systematische Abnahme der Lösungsrate hin, der alle Benutzer unterworfen sind. Ausreißer wären ein test-methodisches Problem; eine Weibull-Verteilung deutet vielmehr auf ein grundsätzlicheres Problem der getesteten Anwendung hin. 2.2.4. Verteilungsformen im Vergleich Erste interne Analysen deuten darauf hin, dass Lognormal- und Exponentialverteilungen in deutlich über 80% der Fälle anzutreffen sind; oft lassen sich beide Modelle innerhalb der Signifikanzgrenzen anpassen. Weibull-Verteilungen sind mit etwa 15% deutlich seltener. Dass es hier nicht nur um reine Statistik geht, wird deutlich, wenn man überlegt, welche Mechanismen denn zu der einen oder anderen Verteilung führen können. Die Exponentialverteilung setzt am wenigsten Annahmen voraus: man würde sie bei einem reinen Zufallsprozess erwarten, bei dem jeder Benutzer sozusagen eine Zufallsstichprobe an Usability-Problemen zieht, die mehr oder weniger viel Zeit kosten. Die Lösungsrate λ beschriebe die relative Häufigkeit und zeitlichen Kosten dieser Usability-Probleme, wie sie in der Gesamtheit der Aufgabe bei gegebener Oberfläche auftreten. Auch die Verschiebung um t0 wäre durch die technischen Gegebenheiten (Systemantwortzeit + „Durchklick“-Zeit) hinreichend erklärt.

Bei einer Weibull-Verteilung käme ein stetig zunehmender, negativer Einfluss auf die Bearbeitungszeit hinzu. In der Zuverlässigkeitsanalyse sind Weibull-Verteilungen ein Indikator für Materialermüdung, die zu einer stetigen Zunahme von Fehlern führt. In unserem Fall hätte Benutzerermüdung den mathematisch umgekehrten, aber konzeptionell völlig analogen Effekt, nämlich die stetige Abnahme der Lösungsrate. Bei der Lognormalverteilung sind die Verhältnisse weniger klar. In der Zuverlässigkeitsanalyse findet man Lognormalverteilungen bei Prozessen, in denen Fehlerquellen sich multiplikativ verhalten, sich also gegenseitig voraussetzen. Derartige Abhängigkeiten sind auch bei Teilaufgaben in einem Usability Test vorstellbar, aber schwierig zu analysieren. Für die Usability-Praxis hat das Exponentialverteilungsmodell gegenüber dem Lognormalverteilungs-modell entscheidende Vorteile. Die Modellparameter t0 und λ haben plausible Entsprechungen in der Realität und erlauben eine sehr einfache Berechnung von Erfolgsquoten bei gegebener Bearbeitungszeit bzw. umgekehrt den Zeiten, die man für eine gegebene Erfolgsquote veranschlagen muss. Zwar lassen sich auch im Lognormalverteilungsmodell statistische Tests und Parameter relativ leicht berechnen, doch kann die logarithmische Skala zu Fehlschlüssen führen. So entsprechen Differenzen in der logarithmischen Skala Proportionen in der linearen Skala – die Bedeutung einer Standardabweichung hängt also davon ab, wo auf der Skala sie abgetragen wird. Das Gleiche gilt für Unterschiede in der Bearbeitungszeit, die man z.B. bei verschiedenen Designalternativen misst. Besonders problematisch ist die Beurteilung langer Bearbeitungszeiten, der „Bummler“. Auch bei Lognormalverteilungen sind solche Daten statistisch zu erwarten; sie können leicht um ein Vielfaches über der mittleren Bearbeitungszeit liegen. Verwendet man – statistisch korrekt – das geometrische Mittel, das in Lognormalverteilungen noch kleiner als das arithmetische Mittel ist, sehen solche


Usability Professionals 2013 Tutorials

Bearbeitungszeiten für den Laien wie grotesk schlechte Leistungen aus, obwohl sie statistisch alles andere als auffällig sind. Da jede Zeitmessung auch eine Leistungsmessung beinhaltet, stellen sich hier gerade im Umfeld von Geschäftssoftware offensichtliche ethische Anforderungen an die korrekte Kommunikation von Testdaten. 3. Ein typischer Analyseablauf Probability Plots lassen sich mit Tabellenkalkulations-Software mit akzeptablem Aufwand soweit vorbereiten, dass der Analyseablauf weitgehend automatisiert wird. Eine xls-Datei kann beim Autor angefordert werden. Als Eingangsgrößen braucht man, für eine gegebene Aufgabe, für jeden Benutzer die Bearbeitungszeit der Aufgabe sowie einen binären Indikator, ob die Aufgabe erfolgreich gelöst wurde oder nicht. Diese Daten werden nach der Bearbeitungszeit aufsteigend sortiert und in separate Spalten der Tabelle einkopiert; Plots werden dann automatisch erzeugt. Empfohlen werden zwei separate Arbeitsblätter: ein Übersichtsblatt mit Plots für Exponential-, Lognormal- und WeibullVerteilung zur Identifikation der Verteilung, sowie ein weiteres mit einem detaillierten Exponential-Plot zur Parameterschätzung, der u.a. die Perzentile 5, 50 und 95 sowie Konfidenzgrenzen für die Regressionsgerade anzeigt.

schauen, welche Verteilung am besten passt – anhand der Krümmung der Datenpunkte sowie den R²-Werten der Regressionsgeraden in den jeweiligen Plots. Diese Verteilungsanalyse erlaubt uns, testbare Hypothesen über Ursachenmechanismen aufzustellen, sowie angemessene Parameter und weitere Analyseverfahren zu identifizieren.

5. Luce, R.D. (1986). Response times: their role in inferring elementary mental organization. Oxford psychology series. No.8 6. Sauro, J. & Kindlund, E. (2005): How Long Should a Task Take? Identifying Specification Limits for Task Times in Usability Tests. In Proceeding of the Human Computer Interaction International Conference (HCII 2005), Las Vegas, USA 7. NIST/SEMATECH (2012a). e-Handbook

Für vergleichende Analysen werden Plots zunächst separat erstellt und anschließend überlagert; bei Exponentialplots können t0 und λ so direkt verglichen werden. Wichtig ist hier auch die Prüfung auf Lognormalverteilung: kann ein Lognormal-Modell angepasst werden, sind parametrische Tests mit logarithmierten Daten statistisch korrekt durchführbar.

of Statistical Methods. Retrieved May 2013 from http://www.itl.nist.gov/div898/ handbook/. National Institute of Standards and Technology 8. NIST/SEMATECH (2012b). Probability Plotting. In: e-Handbook of Statistical Methods. Retrieved May 2013 from http:// www.itl.nist.gov/div898/handbook/apr/ section2/apr221.htm. National Institute of Standards and Technology

Wie alle statistischen Verfahren beschreiben Probability Plots die beobachtete Stichprobe, nicht die Grundgesamtheit. Alle Parameterschätzungen werden damit umso genauer, je größer die Stichprobe an Benutzerdaten ist. Probability Plots werden damit den größten Nutzen bei unmoderierten Online-Usability Tests sowie automatisch erfassten Verhaltensdaten entfalten. Da es dort auch auf effiziente Identifikation problematischer Daten ankommt, bietet die Datenvisualisierung mit Probability Plotting eine wirkungsvolle Unterstützung.

9. NIST/SEMATECH (2012c). Empirical model fitting – distribution free (Kaplan-Meier) approach. In e-Handbook of Statistical Methods. Retrieved May 2013 from http:// www.itl.nist.gov/div898/handbook/apr/ section2/apr215.htm#Modified K – M. National Institute of Standards and Technology 10. NIST/SEMATECH (2012 d) Critical Values of the Normal PPCC Distribution. In e-Handbook of Statistical Methods. Retrieved December 2012 from http://www. itl.nist.gov/div898/handbook/eda/section3/ eda3676.htm. National Institute of Standards and Technology

Literatur 1. ISO (1998). Ergonomic requirements for

Die Analyse beginnt mit dem detaillierten Exponential-Plot. Zunächst werden Ausreißer, Bummler oder Schummler identifiziert und ggfs. entfernt. Gibt es Bummler, prüfen wir auf dem Übersichtsblatt auf Weibull-Verteilung – passen die Bummler dort in die Verteilung, sind sie keine Ausreißer. Bei allen verdächtigen Datenpunkten werden die Aufzeichnungen genauer nach Auffälligkeiten durchsucht. Passt das Exponentialmodell, können in dem detaillierten Arbeitsblatt t0 und λ abgelesen werden, und es geht weiter mit der nächsten Aufgabe.

office work with visual display terminals (VDTs) Part 11: Guidance on Usability. ISO 9241–11:1998 (E) 2. ISO (2006). Software Engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Common Industry Format (CIF) for usability test reports. ISO/ IEC 25062:2006(E)

1

Da diese Linearität das entscheidende Kriterium ist, können die vertikale und horizontale Achsenzuordnung zur ­­­leich­ teren Interpretierbarkeit frei so ge­wählt werden, dass bestimmte Parameter einfacher abzulesen sind; z.B. kann statt R(t) auch das Komplement 1-R(t) geplottet werden.

3. Sauro, J. & Lewis, J.R. (2009). Correlations among Prototypical Usability Metrics: Evidence for the Construct of Usability. Proc. CHI 2009, ACM Press 4. Sauro, J. (2011): 10 Things to Know about Task Times. Retrieved May 2013 from http:// www.measuringusability.com/blog/task-

Passt das Exponentialmodell weniger gut, können wir auf dem Übersichtsblatt

times.php

65


Schätzen der User Experience Von der Möglichkeit die UX bereits im Produktplanungsprozess zu erheben Dominique Winter Buhl Data Service GmbH Am Siebertsweiher 3/5 57290 Neunkirchen dwinter@buhl-data.com

Jens Pietschmann cleverbridge AG Brabanter Straße 2–4 50674 Köln pietschmann@cleverbridge.com

Abstract Produkte ringen um die Gunst der Käufer und Nutzer. Ein Differenzierungsmerkmal zur Steigerung der Produktattraktivität ist die User Experience, weshalb der Wunsch, Produkte mit hervorragender User Experience zu gestalten, weitverbreitet ist. Zu diesem Zweck müssen die User Experience ermittelt und Mängel behoben werden. Dies gelingt durch Anpassungen und Erweiterungen des Produkts, welche jedoch keinesfalls ohne Evaluation der Handlungsoptionen erfolgen sollten; Wirtschaftlichkeit spielt weiterhin eine entscheidende Rolle. Um dieses Ziel zu erreichen, müssen Ideen und Grobkonzepte bereits sehr früh eingeschätzt werden können. Aufgrund der sehr abstrakten Grundlage bieten sich zu diesem Zweck Expertenschätzungen an. Für ein strukturiertes Vorgehen können bewährte Techniken wie die Delphi-Methode oder das Brainstorming eingesetzt werden. Das Dokumentieren der UX-Schätzungen kann im Ideenmanagement eingesetzt werden, um zu entscheiden, welche Ideen wann realisiert werden sollen.

Einleitung Eine positive User Experience kann einem Produkt im Wettbewerb helfen, sich zu differenzieren und durchzusetzen (Rauschenberger, Hinderks & Thomaschewski 2011). Daher erscheint es sinnvoll, die Gestaltung einer positiven User Experience bereits in der Produktplanung bewusst zu berücksichtigen und entsprechende Aufgaben und Maßnahmen einzuplanen. Um dies jedoch durchführen zu können, muss bekannt sein, welchen Einfluss die zu realisierende Idee später auf die User Experience des Produkts haben kann. Zumindest eine Schätzung des Einflusses der Ideen auf die User Experience muss als Basis vorliegen, um gezielt Entscheidungen im Ausgestaltungsprozess der Idee und des Produkts treffen zu können. Die Verwendung von statistischen Modellen ist jedoch meist sehr aufwändig und diesbezügliches Wissen zur Datenerhebung, Auswertung und zur statistischen Relevanz von Ergebnissen fehlt. Werden Prototypen für die Konstruktion und Evaluation der User Experience eingesetzt, werden diese bei einer großen Anzahl von Ideen in der Summe schnell

66

teuer, obwohl ein Prototyp pro Idee einzeln betrachtet günstig wäre. Daher scheuen Unternehmen meist entsprechende Mittel zur Evaluation innerhalb des Produktplanungsprozesses bereit zu stellen.

Keywords: /// Schätzmethoden /// Innovationsmanagement /// Ideenmanagement /// Produktplanung /// User Experience

werden können, um die Experten bei der Schätzung zu unterstützen und wie die Ergebnisse der Expertenschätzungen im Ideenmanagement Verwendung finden. Vorbereitung der Schätzung

Einfachere Methoden beruhen auf Expertenschätzungen, die im Produktplanungsprozess durchgeführt werden können. Expertenschätzungen sind gerade in Unternehmen eine geeignete Methode, da sie schnell und einfach durchzuführen sind. Erfahrene Experten des Produkts gelangen in Gruppenschätzungen zu belastbaren Ergebnissen (Hummel 2011), so dass eine verwendbare Erstbewertung zur Verfügung steht. Jedoch brauchen auch Expertenschätzungen eine strukturierte Durchführung, um die individuellen Schätzungen der jeweiligen Experten zu harmonisieren und so zu einem Gruppenkonsens zu gelangen. Im Folgenden sollen exemplarisch zwei Methoden für Expertenschätzungen vorgestellt werden, mit einem besonderen Blick auf Vorbereitung, Durchführung und Nachbereitung. Es soll geklärt werden, welche Prozesse und Artefakte genutzt

Vor Beginn einer Schätzung muss das Konzept der User Experience als Eigenschaft von Produkten für die Expertengruppe konsensfähig in messbare Elemente aufgeteilt werden. Dadurch wird das gemeinsame Verständnis des Begriffes User Experience geschärft und eine Ausgangsbasis für detaillierte Schätzungen erzeugt. Zum Aufbrechen der einzelnen Bestandteile der User Experience bieten sich unter anderem die Dimensionen des User Experience Questionnaires (Attraktivität, Effizienz, Durchschaubarkeit, Verlässlichkeit, Stimulation und Originalität) an (Laugwitz, Held & Schrepp 2008). Aber auch die Aufteilung in hedonische und pragmatische Qualitäten (Hassenzahl, Burmeister & Koller 2008) kann gezielt als Grundlage für eine Stichwortsuche und Themenclustering zur Schätzung der User Experience genutzt werden.


Usability Professionals 2013 Tutorials

Um die Zielgruppenorientierung der Schätzungen durch die Experten zu steigern, empfiehlt es sich, Personas als Ausgangspunkt heranziehen. Dies führt zu einer noch stärkeren Berücksichtigung der Bedürfnisse der Zielgruppe und verhindert, dass die Experten Lücken in der Betrachtung der User Experience im nutzerindividuellen Kontext durch eigene Eigenschaften ausfüllen (Cooper, Reimann & Cronin 2007). Des Weiteren können auch Erwartungen der Zielgruppe (zum Beispiel erhoben in Marktbefragungen) in den Personas beschrieben und berücksichtigt werden. Dies kann zusätzlich bei der späteren Produktkonzeption helfen, die auf Grundlage der Idee stattfindet (Holt, Winter & Thomaschewski 2011). Ergänzend zur textlichen Beschreibung der Idee können zur Unterstützung Sketches als visuelle Repräsentation einer Idee genutzt werden (Föhrenbach & Strebel 2011). So erhöht sich die Wahrscheinlichkeit, dass die Experten alle ein ähnliches mentales Modell der umzusetzenden Idee entwickeln. Ebenso können Storyboards die Experten unterstützen, die später umgesetzte Idee im richtigen Kontext zu bewerten (Holtzblatt, Wendell & Wood 2005).

gearbeitet werden. Eine fokussierte Diskussion und Ausarbeitung von Lösungen in der Gruppe sind das Ziel. Ist die Diskussion über die User Experience auf eine Aufteilung der pragmatischen und hedonischen Qualitäten eines Produkts ausgerichtet, können diese mittels des Brainstormings zielgerichtet geschätzt und weiterentwickelt werden. Beiden Qualitäten sprechen menschliche Bedürfnisse an, die pragmatische Produktqualität in der konkreten Nutzungssituation und die hedonische Produktqualität, die über die reine Nutzung hinausgeht (Benatallah et al. 2010). Da beide Qualitäten unabhängig voneinander betrachtet werden können, empfiehlt es sich, beide Qualitäten zunächst getrennt voneinander zu schätzen. Dies kann zu einer freieren Ideengenerierung führen, um hedonische Qualitäten wie den Prozess des Erwerbs, den Versand oder die Entsorgung des Produkts, die meist nicht im Produktplanungsprozess berücksichtigt werden, gezielt ausarbeiten und schätzen zu können.

Nachdem die Themencluster bestimmt wurden, generiert die Gruppe der Experten gezielt Ideen für einzelne Aspekte des Themenclusters. [Abb. 1] Dabei können Ideen entweder der pragmatischen oder der hedonische Qualität zugeordnet werden. Nicht differenzierbare Ideen werden soweit wie möglich in einzelne Ideen aufgebrochen, damit eine Zuordnung möglich wird. Zur Unterstützung der ­Gruppen werden die Ideen dokumentiert und der jeweiligen Qualität zugeordnet. Nach Abschluss der ersten Phase entstehen so zwei Qualitätscluster, die unterschiedliche Lösungen für Aspekte anbieten. In der nun anschließenden Phase müssen diese zusammen gebracht werden, um die Wechselwirkungen der einzelnen Ideen aufeinander besser abschätzen zu können. So kann beispielsweise eine Idee den Aspekt Originalität verstärken, jedoch die Effizienz reduzieren. Durch die Diskussion der Gruppe entstehen nun Cluster bezogen auf ihre Wirkung, die sowohl pragmatische als auch hedonische Qualitäten beinhalten.

Brainstorming mit anschließender Zusammenfassung Als eine einfache Methode zur Expertenschätzung der User Experience früh im Produktplanungsprozess bietet sich das Brainstorming an. Durch einen wenig formalen Prozess und einer diskussionsgetriebenen Ideengenerierung bietet das Verfahren eine offene Plattform für die Ideenerzeugung und -ableitung sowie anschließenden Schätzung des Einflusses auf das Produkt an. Um die Qualität der Methode zu erhöhen, sollte eine Bewertung der aktuellen Qualität des Produkts beispielsweise anhand des UEQ oder des AttrakDiff durchgeführt worden sein, da deren Ergebnisse für die Ideenfindung als Themencluster verwendet werden können. So kann gezielt an Handlungsfeldern zur Verbesserung der User Experience

Abb. 1. Beispielhafte Ideenclusterung mit Hilfe von pragmatischen und ­hedonischen Qualitäten

67


Aus den entstehenden Ideenclustern werden anschließend die Handlungsempfehlungen abgeleitet und in der Gruppe diskutiert. Als Ergebnis der Methode entsteht so eine Handlungsempfehlung unter Berücksichtigung der pragmatischen und hedonischen Qualitäten sowie der Wechselwirkung verschiedener Ideen untereinander und ihres Einflusses auf das Gesamtprodukt.

Auch für diese Methode ist es wichtig, die Ideengenerierung durch eine zuvor durchgeführte Evaluierung und Themenclusterung der Aktionsfelder (z.B. UEQ oder AttrakDiff) zu kanalisieren und die Bewertung iterativ in mehreren Phasen durchführen zu können. Dies ist notwendig, um einen Konsens und das Verständnis der Idee innerhalb der Expertengruppe herstellen zu können.

Der Vorteil des Brainstormings ergibt sich durch die Wechselwirkungen in der Diskussion unter den Experten. Durch den argumentativen Austausch werden unterschiedliche Ansichten berücksichtigt, was eine Konsensbildung beschleunigen kann. Als Nachteil ist hervorzuheben, dass die Meinungsbildung durch Gruppendynamik oder Gruppenzwang hoch ist, da durch die Diskussion soziale Situationen dieser Art meist nicht zu vermeiden sind. So ist nicht immer eindeutig, ob ein Konsens (oder ein Dissens) tatsächlich nur auf der intensiven Diskussion der Expertengruppe beruht oder die Meinungsführerschaft durch eine soziale oder organisatorische Hierarchie innerhalb der Gruppe begründet sein kann. Dies stellt besondere Anforderungen an den Moderator des Brainstormings, der nicht nur den Rahmen für die Diskussion vorgeben, sondern auch Konfliktsituationen innerhalb der Gruppe auflösen sollte.

In der ersten Phase wird eine Gruppe von Experten anonym zu einem Thema oder Handlungsfeld befragt. [Abb. 2] Anhand des Themenkatalogs werden Ideen für die einzelnen Handlungsfelder generiert, schriftlich festgehalten und durch den Befragten bewertet. Die Bewertung der Idee erfolgt dabei an den zuvor definierten Bewertungsdimensionen. Dieser Prozess wird für alle Mitglieder der Gruppe unabhängig voneinander durchgeführt. Die Ergebnisse werden anschließend katalogisiert, um eine Zusammenfassung von Ideen einschließlich einer Ersteinschätzung des Erstellers der Idee zu generieren. In der nun folgenden Phase wird den Experten anonymisiertes Feedback

Delphi-Methode zur Schätzung von weichen Faktoren Die Delphi-Methode (Dalkey & Helmer 1963) als qualitatives Schätzungsverfahren wird auf Basis von strukturierten Expertenbefragungen in der Gruppe durchgeführt und eignet sich auch für Schätzungsverfahren, die nicht nur den Einfluss von Produktideen auf die User Experience, sondern auch Faktoren wie technologisches Risiko und relativen Aufwand berücksichtigen sollen. Die Schätzung beruht dabei auf Wissen und Erfahrungen der Experten, weshalb sich das Einsatzgebiet innerhalb der erfahrbaren Wahrnehmung von Menschen bewegt, jedoch nicht ausschließlich auf diese beschränkt sein muss.

68

Abb. 2. Schematische Darstellung einer beispielhaften Anwendung der Delphi-Methode

gegeben, wie erstellte Ideen durch die anderen Gruppenmitglieder bewertet wurden und welches Feedback zu den einzelnen generierten Ideen abgegeben wurde. Dies dient dazu, in weiteren Phasen zusätzliche Diskussionen sowie eine Klärung und Verfeinerung der Idee und der zuvor abgegebenen Schätzungen zu erhalten. Dieses Vorgehen wird so lange wiederholt, bis allgemeiner Konsens über den Inhalt der Idee und der Schätzung des Einflusses auf die User Experience erreicht ist. Das abschließende Ergebnis der Expertenschätzung ist eine evaluierte Zusammenfassung von Handlungsempfehlungen aller Experten für einen Themenkatalog. Diese beinhaltet die definierte Idee der Gruppe je Handlungsfeld als auch einen geschätzten Einfluss der Idee auf das Produkt selbst. Der Vorteil der Delphi-Methode ist die Anonymisierung der Ergebnisse in den Phasen der Befragung und Schätzung. Hierdurch können störende Einflüsse der Gruppendynamik und der Meinungsdominanz einzelner Experten entgegen gewirkt werden (Corsten, Gössinger & Schneider 2006). Die


Usability Professionals 2013 Tutorials

Experten werden nicht mit der Abweichung ihrer Meinung konfrontiert, sondern mit der Schätzung als Gesamtmeinung der Experten. Jedoch besteht die Gefahr, dass Wissensdefizite einzelner Experten zu Fehleinschätzungen führen können. Ebenfalls besteht ein häufiges Problem darin, dass einmal geäußerte Meinungen der Experten in den folgenden Phasen nicht geändert werden, so dass der zeitliche Aufwand, einen Konsens über mehrere Iterationen hinweg zu finden, unnötig groß sein kann. Ergebnisse von Schätzmethoden und Ideenmanagement Die Ideengenerierung und argumentative Auseinandersetzung und Bewertung von Ideen führt oft zur Zurückstellung von Ideen, da diese entweder aus strategischen oder technischen Gründen als im Moment nicht lohnend erachtet werden. Jedoch dürfen zurückgestellte Ideen, welche bereits den Prozess der Expertenschätzung durchlaufen haben, nicht einfach verworfen werden. Die zurückgestellten Ideen können in einen Ideenpool überführt werden, um die Ideengenerierung nachhaltig zu entlasten, da gleiche Ideen

nicht immer und immer wieder erzeugt und bewertet werden müssen (Winter & Pietschmann 2012). Aus diesem Ideenpool können Ideen für Expertendiskussionen abgelegt oder für weitere Diskussionen herangezogen werden. Da die Ideen entsprechend der für den Innovationsprozess vereinbarten Vorgehensweise bewertet und dokumentiert wurden, können gezielt Ideen zur Beseitigung von Defiziten in einzelnen Bewertungsdimensionen der User Experience [Abb. 3] oder zur weiteren Ausprägung von bereits bestehenden Stärken des Produkts herangezogen werden. Insbesondere aufgrund der standardisierten Bewertungsdimensionen können Ideen zu bestimmten Handlungsfeldern gesucht, aufbereitet und erneut diskutiert werden. Beispielsweise kann bei einer summativen Evaluation der User Experience des Produkts mittels UEQ festgestellt werden, dass die Ausprägung im Bereich Originalität negativ ist. Aufgrund dieser Feststellung können nun die archivierten Ideen für eine Produktweiterentwicklung herangezogen werden, die eine positive Beeinflussung der Originalität versprechen.

Der Ideengenerierungsprozess muss dann nicht erneut von vorne beginnen. Zur Dokumentation der UX-Schätzung bieten sich für das Verwalten der Ideen spezielle Ideenkarten [Abb. 4] an, die entweder physisch oder digital vorliegen können (Winter & Pietschmann 2012). Für diese spielt es keine Rolle, nach wel­ chem Vorgehen die Einflüsse geschätzt wurden. Sie bieten einen kompakten Überblick der Parameter einer Idee, welche die Aus­wahl und das Priorisieren von Ideen in einem UX-getriebenen Innovationspro­zess vereinfachen. Auch User Storys können um UX-Schätzungen ergänzt werden, damit ihr Einfluss auf die User Experience des Produkts als Bewertungsmaßstab in der agilen Produktplanung genutzt werden kann. Wird eine verbesserte User Experience als Steigerung des Werts eines Produkts verstanden, beschreibt ihre Schätzung eine erwartete Wertsteigerung für das Produkt (Pichler 2010) und kann somit wie der Geschäftswert (Business Value) zur Priorisierung herangezogen werden. Zusammenfassung Die Verwendung von Expertenschätzungen kann ein geeignetes Mittel sein, um früh im Innovationsprozess die Handlungsempfehlungen für ein Produkt mit positiver User Experience zu erstellen. Durch wiederholtes Schätzen und anschließender Evaluation ist es den Experten möglich, die eigene Bewertung zu reflektieren und dadurch die eigene Expertise zu stärken, denn Gruppendiskussionen initiieren Lernprozesse und können implizites Wissen der Teilnehmer zu Tage fördern (Lamnek 2005). Werden Ideen entsprechend dokumentiert, können zukünftige Schätzungen, die sich auf einen ähnlichen Gegenstand beziehen, zu einem genaueren Ergebnis führen. Der Einsatz von Experten ist dabei im Vergleich zur ständigen Prototypenkonstruktion kosteneffizienter und einfacher in Unternehmen zu implementieren.

Abb. 3. Ideenpool als Grundlage von Ideengenerierung

Als nachteilig können sich jedoch überdominante Experten innerhalb der

69


Abb. 4. Beispielhafte Darstellung einer Ideenkarte mit den Bewertungsdimensionen des UEQ (Quelle: Winter & Pietschmann 2012)

Expertengruppe und ein Trend zur Gruppenkonformität herausstellen, auf die durch die jeweiligen Methoden oder Moderatoren eingegangen werden muss (Corsten, Gössinger & Schneider 2006). Dem entsprechend dürfen soziale Beziehungen der Experten untereinander nicht vernachlässigt werden, denn sie müssen in der Lage sein miteinander auf einer Augenhöhe zu kommunizieren und zu arbeiten. Außerdem müssen diese als Experten im Unternehmen auch außerhalb der Expertengruppe anerkannt sein, da sonst Schätzungen durch Entscheidungsinstanzen nicht akzeptiert werden könnten. Ohne diese Akzeptanz würden die Schätzungen an Relevanz und Nutzen im Innovationsprozess verlieren. Die Definition, was einen Experten ausmacht, kann nur teilweise bestimmt werden und nur innerhalb des iterativen Prozesses oder als Ergebnis des Erfolges der Handlungsempfehlung gesehen werden.

der Kenntnis um die Relevanz der User Experience im gesamten Unternehmen. Dadurch richtet sich das Humankapital des Unternehmens stärker auf den Nutzer aus und ermöglicht eine Berücksichtigung von Ideenfindungen im Rahmen des betrieblichen Vorschlagswesens oder des Ideenmanagements, die sich auf das Erleben der Software beziehen. Dadurch kann der Innovationsprozess in der Phase der Ideengenerierung vervollständigt werden, da nicht nur funktionale Verbesserungen von Mitarbeitern eingebracht werden. Voraussetzung dafür ist jedoch ein gutes Betriebsklima, das allen Mitarbeitern erlaubt Ideen auch in dieser Richtung einzubringen (Söffing 2010).

Literatur 1. Benatallah, B., Casati, F., Kappel, G. und Rossi, G. (Hrsg.) (2010). Web Engineering. 2. Cooper, A., Reimann, R. & Cronin, D. (2007). About face 3: The Essentials of Interaction Design, Indianapolis (Ind.): Wiley. 3. Corsten, H., Gössinger, R. & Schneider, H. (2006). Grundlagen des Innovationsmanagements, München: Vahlen. 4. Dalkey, N. & Helmer, O. (1963). An Experimental Application of the Delphi Method to the Use of Experts. In: Management Sience, Vol. 9, Nr. 3. 5. Föhrenbach, S. & Strebel, S. (2011). User Experience und Sketching:: Gute Software beginnt auf dem Papier. In: OBJEKTspektrum, 04/2011, S. 22–27. 6. Hassenzahl, M., Burmeister, M. & Koller, F. (2008). User Experience (UX) auf der Spur:: Zum Einsatz von www.attrakdiff.de, In Usability Professionals 2008. Berichtband des sechsten Workshops des German Chapters der Usability Professionals Association e.V. ; [7. bis 10. September 2008 in Lübeck

Ein Nebeneffekt beim Etablieren eines Schätzprozesses mittels Experten ist die Verbreitung des Verständnisses und

70

im Rahmen der Mensch und Computer Konferenz], H. Brau (Hrsg.), Stuttgart.


Usability Professionals 2013 Tutorials

7. Holt, E.-M., Winter, D. & Thomaschewski, J. (2011). Personas als Werkzeug in modernen Softwareprojekten: Die Humanisierung des Anwenders, In Usability Professionals 2011, H. Brau, A. Lehmann, K. Petrovic und M.C. Schroeder (Hrsg.), Stuttgart. 8. Holtzblatt, K., Wendell, J. & Wood, S. (2005). Rapid contextual design: A how-to guide to key techniques for user-centered design, San Francisco: Elsevier/Morgan Kaufmann. 9. Hummel, O. (2011). Aufwandsschätzungen in der Software- und Systementwicklung kompakt, Heidelberg: Spektrum. 10. Lamnek, S. (2005). Gruppendiskussion: Theorie und Praxis, 2. Auflage, Weinheim, Basel: Beltz. 11. Laugwitz, B., Held, T. & Schrepp, M. (2008). Construction and Evaluation of a User Experience Questionnaire. In: Lecture Notes in Computer Science, Nr. 5298, S. 63–76. 12. Pichler, R. (2010). Agile product management with Scrum: Creating products that customers love, Upper Saddle River, NJ: Addison-Wesley. 13. Rauschenberger, M., Hinderks, A. & Thomaschewski, J. (2011). Benutzererlebnis bei Unternehmenssoftware: Ein Praxisbericht über die Umsetzung attraktiver Unternehmenssoftware, In Usability Professionals 2011, H. Brau, A. Lehmann, K. Petrovic und M.C. Schroeder (Hrsg.), Stuttgart. 14. Söffing, R. (2010). Kiss your Ideas!: Ideen erfolgreich managen, 1. Auflage, Offenbach am Main: GABAL. 15. Winter, D. & Pietschmann, J. (2012). UX in den frühen Phasen des Innovationsprozesses: UX von Anfang an bedacht, In Usability Professionals 2012, H. Brau, A. Lehmann, K. Petrovic und M.C. Schroeder (Hrsg.), Stuttgart.

71


User Experience mit Fragebögen messen Durchführung und Auswertung am Beispiel des UEQ

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

Jörg Thomaschewski Hochschule Emden/Leer Constantiaplatz 4 26723 Emden jt@imut.de

Abstract Über Fragebögen kann die subjektive User Experience zu einem Produkt effizient gemes­ sen werden. Jedoch gibt es beim Einsatz und insbesondere bei der anschließenden Aus­ wertung einige „Fallstricke“, auf die dieser Artikel hinweist. Hierdurch können in konkreten Projekten Fehleinschätzungen bzgl. der gemessenen User Experience vermeiden werden. Am Beispiel des User Experience Questionnaire (UEQ) und dem UEQ-Excel-Tool zur Auswertung wird auf die Besonderheiten beim Einsatz eines Fragebogens eingegangen. Die Notwendigkeit dieser zusammenfassenden Darstellung ergibt sich aus der Tatsache, dass gerade erprobte Fragebögen oftmals „zu unbedacht“ eingesetzt werden, wie eine Reihe von Anfragen zum Einsatz des UEQ über die Webseite ­www.­ueq-online. org zeigte.

1. Einleitung Die User Experience (dt. Benutzererlebnis) ist laut der DIN EN ISO 9241–210 definiert als die „Wahrnehmungen und Reaktionen einer Person, die aus der tatsächlichen und/oder der erwarteten Benutzung eines Produktes, eines Systems oder einer Dienstleistung resultieren“ (ISO 9241–210:2010). Dabei handelt es sich um Empfindungen und jegliche Reaktion eines Benutzers vor, während und nach der Benutzung eines Produktes. Dies betrifft auch das Markenbild, die persönlichen Fähigkeiten des Benutzers oder die Erfahrung (ISO 9241–210:2010). Es gibt inzwischen zahlreiche Methoden für die Messung der User Experience, z.B. durch die Erhebung von Gesichts-Emotionen während der Nutzung, mit Hilfe von Befragungstechniken (vgl. Kim et al. 2012, Mahlke 2006, Burmester et al. 2010) oder mit Hilfe von Fragebögen (Hassenzahl et al. 2008, Laugwitz et al. 2006). Die Verwendung von Fragebögen bietet den Vorteil, dass umfangreiche Benutzergruppen schnell befragt werden können.

72

Eine Längsschnittuntersuchung ist dann bedeutend, wenn die zeitliche Veränderung des Benutzererlebnisses erfasst werden soll (vgl. Wilamowitz-Moellendorff et al. 2007) und sich in agilen Entwicklungsprozessen auch das interaktive System kontinuierlich weiterentwickelt. Bei Längsschnittstudien ist insbe­sondere darauf zu achten, dass die Methode zur Messung der User Experience möglichst identisch zu den verschiedenen Zeitpunkten eingesetzt werden kann. Hierfür sind Fragebögen wegen des geringen Aufwands und der Standardisierung der Datenerhebung besonders gut geeignet. Insgesamt hat der Einsatz von Fragebögen zur Ermittlung der User Experience folgende Vorteile –– einfach einsetzbar (online als auch offline) –– umfangreiche Benutzergruppen können befragt werden –– Einsatz in Längsschnittuntersuchungen möglich –– ermittelt das Benutzererlebnis nach der Benutzung

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

Keywords: /// User Experience /// Evaluation /// Fragebogen /// UEQ

Im deutschsprachigen Raum werden zwei Fragebögen zur Messung der User Experience oft eingesetzt: Der „AttrakDiff2“ von Hassenzahl et al. (2008) und der „User Experience Questionnaire: UEQ“ von Laugwitz et al. (2006). Beide Fragebögen verwenden semantische Differentiale um die Qualitäten unterschiedliche Testobjekte ermitteln zu können. 2. User Experience Questionnaire Das Ziel des UEQ ist die effiziente Messung der User Experience eines Produktes. Die User Experience wird dabei als subjektiv empfundener Eindruck verstanden, den der Benutzer in Bezug auf das Produkt entwickelt hat. Die Items und Dimensionen des UEQ sind über eine datenanalytische Vorgehensweise konstruiert. Im ersten Schritt ist eine Liste mit 229 potentiellen Items in mehreren Brainstorming-Sitzungen mit UsabilityExperten erstellt worden. Diese Liste ist in einem zweiten Schritt von den Experten auf eine Rohversion des Fragebogens mit 80


Usability Professionals 2013 Tutorials

Items reduziert. Diese Rohversion wurde dann in mehreren Studien zu interaktiven Produkten (z.B. Statistik-Software, Online Collaboration Software, betriebswirtschaftliche Produkte, Mobile Phone) von insgesamt 153 Teilnehmern ausgefüllt. Die Dimensionen des UEQ und die Items pro Dimension sind aus diesem Datensatz über eine Faktorenanalyse extrahiert. Dieser Prozess resultierte in folgende 6 Dimensionen (jeweils mit den Items): – Attraktivität (unerfreulich / erfreulich, gut / schlecht, abstoßend / anziehend, unangenehm / angenehm, attraktiv / unattraktiv, sympathisch / unsympathisch) – Effizienz (schnell / langsam, ineffizient / effizient, unpragmatisch / pragmatisch, aufgeräumt / überladen) – Durchschaubarkeit (unverständlich / verständlich, leicht zu lernen / schwer zu lernen, kompliziert/einfach, übersichtlich / verwirrend) – Steuerbarkeit (unberechenbar/voraussagbar, behindernd / unterstützend, sicher / unsicher, erwartungskonform / nicht erwartungskonform) – Stimulation (wertvoll / minderwertig, langweilig / spannend, uninteressant / interessant, aktivierend / einschläfernd) – Originalität (kreativ / phantasielos, originell / konventionell, herkömmlich / neuartig, konservativ / innovativ) Der UEQ besteht also aus 26 bipolaren Items, die sich auf sechs Dimensionen verteilen. Die Items sind als siebenstufige Lickert-Skalen realisiert, z.B.: Attraktiv

Unattraktiv

Details zur Konstruktion und zur Validierung des Fragebogens sind in Laugwitz, Schrepp & Held (2006) und Laugwitz, Held & Schrepp (2008) beschrieben. Zur effizienten Auswertung steht ein UEQExcel-Tool zur Verfügung (siehe Abbildung 1). Es genügt hier pro Teilnehmer die Bewertungen der 26 Items einzugeben. Die Dimensionsmittelwerte, deren Konfidenzintervalle und weitere statistische Kennwerte werden dann automatisch berechnet.

Abb. 1. Ergebnisse für ein hypothetisches Produkt (aus dem UEQ-Excel-Tool), d.h. Dimensionsmittelwerte und deren Konfidenzintervalle.

Der UEQ liefert als Ergebnis einer Befragung also die Werte der sechs Dimensionen (jeweils Mittelwert der Items pro Dimension), wie in Abbildung 1 dargestellt. [Abb. 1] Pro Dimension wurden in der Konstruktion vier Items gewählt, um einerseits die Messgenauigkeit (Reliabilität), d.h. die Robustheit gegenüber zufälligen Antwortfehlern, zu erhöhen und andererseits den Fragebogen nicht unnötig lang werden zu lassen. Die Items einer Dimension sollen identische Qualitätsaspekte messen, d.h. hoch korrelieren. Die Konsistenz einer Dimension kann durch Berechnung des Alpha-Coeffizienten α = n * r / 1 + (n – 1) * r, wobei r die durchschnittliche Korrelation der Dimensionen und n die Anzahl der Dimensionen beschreibt) auch numerisch ausgedrückt werden. Es gibt keine klar definierten Regeln, wie groß Alpha sein sollte. Einige verbreitete Faustregeln fassen Werte Alpha > 0,6 oder > 0,7 als Indikator für eine zufriedenstellende Konsistenz der

Dimension auf. Ist der Alpha-Wert einer Dimension zu klein, kann das darauf hindeuten, dass einige der Items in der konkreten Untersuchung nicht wie vorgesehen interpretiert wurden. Die Alpha-Werte werden vom UEQ-Excel-Tool je Dimension berechnet, so dass eine einfache Überprüfung dieser Werte erfolgen kann. Semantische Differentiale wie der UEQ können nicht einfach durch eine Übersetzung der Gegensatzpaare in andere Sprachen übertragen werden. Bei der Erstellung einer Sprachversion muss immer sichergestellt werden, dass durch die Übersetzung keine abweichenden Bedeutungen entstehen, die das Verhalten des Fragebogens beeinflussen. D.h. es ist auch notwendig, Daten mit der übersetzten Version zu erheben, um sicherzustellen, dass die Dimensionen in beiden Sprachen ähnliche Qualitäten messen. Für den UEQ stehen im Moment eine Reihe von geprüften Sprachversionen zur Verfügung, z.B. Englisch, Spanisch (s. Rauschenberger et al., 2012) und in

73


Kürze Portugiesisch. Zusätzlich sind Übersetzungen in Französisch und Italienisch vorhanden, bei denen aber bzgl. der Qualität der Dimensionen noch keine ausreichenden Erkenntnisse vorliegen. Die vorhandenen Sprachversionen können unter www.ueq-online.org heruntergeladen werden. Der UEQ eignet sich aufgrund seiner einfachen Struktur für den Einsatz in verschiedenen Szenarien, z.B. nach Usability Tests, als Online-Evaluation von Web-Seiten oder auch zur kontinuierlichen Prüfung größerer Anwendungspakete (siehe Laugwitz et al. 2009). 3. Typische Probleme bei der Anwendung von Fragebögen Wie bei jedem Instrument zur Messung bestimmter Eigenschaften, sind auch beim Einsatz von Fragebögen gewisse Fallstricke vorhanden. Eine sehr wichtige Rolle spielt die Auswahl der richtigen Zielgruppe für die Befragung. Idealerweise sollte hier eine möglichst repräsentative Gruppe von Endanwendern ausgewählt werden. In der Praxis ist dies je nach Projekt nicht immer möglich. Steht beispielsweise nur eine Gruppe von BetaTestern zur Verfügung kann es sinnvoll sein, deren Eindruck zur User Experience per Fragebogen zu erfassen und die Bewertung später ggf. bewusst von den wirklichen Endbenutzern zu trennen. Je nach Art des Fragebogens ist zu beachten, dass die adressierten Nutzer die Fragen richtig verstehen. Ein Beispiel für die Probleme dieser Art sind Teilnehmer, die keine Muttersprachler sind, d.h. evtl. Probleme haben sich Items wie usual –leading edge zu erschließen. Hier wurde bewusst ein Beispiel des englischen UEQ verwendet, um das Problem zu verdeutlichen. Ein weiteres Problem kann auftreten, wenn es sich zwar um Muttersprachler handelt, aber aufgrund anderer Umstände ein eingeschränktes Sprachverständnis vorhanden ist.

74

Beim Versuch ein Web-Portal für jugendliche Benutzer mit dem UEQ zu evaluieren, zeigten sich z.B. massive Verständnisprobleme bei einigen Items des UEQ („Was bedeutet konventionell?“). Aufgrund dieses Rückmeldung wurde eine spezielle Sprachversion für jugendliche Benutzer erstellt (Hinderks et al., 2012). Die Verständlichkeit der Items für die intendierte Zielgruppe sollte deshalb vor dem Einsatz eines Fragebogens geprüft werden. Enthält ein Fragebogen vollständig ausformulierte Sätze anstelle semantischer Differentiale, dann sind Probleme mit dem Sprachverständnis weniger wahrscheinlich. Bei semantischen Differentialen wie dem UEQ muss oft ein höheres Maß an Sprachverständnis voraussetzen werden, da der Benutzer hier nur zwei Gegensatzpaare zur Verfügung hat, um sich die Bedeutung der Fragestellung zu erschließen. Einzelne Items könnten je nach Testobjekt unterschiedlich interpretiert werden oder es könnte sich die Wertigkeit im Extremfall sogar umkehren. Ein Beispiel hierzu ist das Item-Paar „sicher – unsicher“ zur Dimension „Steuerbarkeit“. Im Kontext von sozia­len Netzwerken kann dieses ItemPaar anders interpretiert werden und der technischen Sicherheit von Daten zugeordnet werden. Somit ist je nach Testobjekt das Item unterschiedlich zu bewerten. Abhilfe kann ein Beta-Test schaffen, bei dem die Probanden im Nachgang zu den Items und den zugehörigen Assoziationen befragt werden. In bestimmten Szenarien stellt sich die Frage, zu welchem Zeitpunkt der Frage­ bogen eingesetzt werden soll. Gemäß Donald A. Norman „Memory is more important than actuality“ (Norman 2009), ist es rele­vant das Benutzererlebnis nach der Benutzung zu ermitteln. Ist es Ziel des UEQ den subjektiven Eindruck des Benutzers zu messen, wird der UEQ am Besten im Rahmen eines Usability Tests eingesetzt. Diskussionen mit dem Benutzer über z.B. Interaktionsprobleme beeinflussen die Meinung des Benutzers und verfälschen damit das Fragebogen-Ergebnis und sollten erst

nach dem Ausfüllen des Fragebogens z.B. mit einem Interview ermittelt werden. Beim Einsatz mit Endbenutzern einer be­triebs­wirtschaftlichen Software sollte man versuchen, die Befragung zur User Experience erst durchzuführen, nachdem die Benutzer eine gewisse Zeitspanne mit dem Produkt gearbeitet haben. Ansonsten be­­ steht die Gefahr einer Verfälschung der Ergebnisse durch mangelnde Erfahrung der Benutzer oder Probleme durch die Umstellung von einem alten Produkt auf eine neue Lösung (Rauschenberger et al., 2011). Zu vermeiden ist eine „Belohnungsstruktur“ für das Ausfüllen des Fragebogens, z.B. eine Teilnahme an einem Gewinnspiel mit attraktiven Gewinnen. Es zeigt sich, dass hierdurch zwar schnell eine hohe Teilnehmerzahl erreicht werden kann, aber die Motivation der Teilnahme bei vielen Teilnehmern zu sehr auf das Gewinnspiel gerichtet ist. Somit werden die Ergebnisse gegebenenfalls weniger valide ausfallen. Auch bei einem Abhängigkeitsverhältnis zu den Teilnehmern kann die Validität der Ergebnisse leiden, beispielsweise bei einer Verschickung des Fragebogens durch die Geschäftsleitung oder bei Fragebögen von Professoren an Studierende. 4. Typische Fehler bei der Interpretation der Ergebnisse Nach der erfolgreichen Erhebung von Daten müssen diese entsprechend analysiert und interpretiert werden. Bietet der Fragebogen ein Tool zur Berechnung an, müssen nur die Ergebnisse interpretiert werden. Der UEQ bietet genau diese Möglichkeit und es müssen zunächst nur die erhobenen Daten in ein UEQ-Excel-Tool eingetragen werden. Leider besteht durch die einfache Auswertung auch die Gefahr, dass Ergebnisse unreflektiert verwendet werden. Vor der Auswertung muss sichergestellt sein, so dass nur „ernsthaft ausgefüllte“ Fragebögen ausgewertet werden. Im UEQ


Usability Professionals 2013 Tutorials

wurden die bipolaren Items bezüglich der Polung und der Reihenfolge randomisiert, sodass die Zugehörigkeit zu den Dimensionen von den Probanden nicht erkannt werden kann. Wenn im gesamten Fragebogen alle Werte „ganz links“ (entspricht dem Wert „1“) oder “ganz rechts„ (entspricht dem Wert “7„) vom Probanden angekreuzt wurden, sollte der Fragebogen von der weiteren Auswertung als “nicht ernsthaft ausgefüllt“ ausgeschlossen werden. Dagegen sollten Items ohne Antwort von einem Probanden als eine Meinung gezählt werden (Höpflinger, 2010). Zu den typischen Fehlern gehört das „überinterpretieren“ der Ergebnisse, wenn beispielsweise Mittelwerte der Dimensionen verwendet werden, obwohl aufgrund von stark unterschiedlichen Einschätzungen der Teilnehmer die Konfidenzintervalle sehr groß sind. Große Konfidenzintervalle lassen entweder auf eine zu geringe Stichprobengröße schließen oder auf sehr unterschiedliche Antworten der Teilnehmer. Hierfür müssen die einzelnen Fragebögen gegenübergestellt und ggf. eine Abgleichung mit der Zielgruppe vorgenommen werden.

stark von den anderen Mittelwerten derselben Farben (und damit derselben Dimensionszugehörigkeit) unterscheidet. Somit sollten die Ergebnisse dieses Items und der zugehörigen Dimension kritisch hinterfragt werden.[Abb. 2] Beim UEQ ist zu berücksichtigen, dass die Items für die Berechnung des Mittelwerts der Dimensionen benötigt werden und keine Items aus dem Fragebogen entfernt werden dürfen. Je mehr Items eine Skale hat, desto höher ist ihre Messgenauigkeit, d.h. Reliabilität. Die Reliabilität der Dimension ist beim Entfernen von Items nicht mehr gegeben und zusätzlich ist eine Vergleichbarkeit mit anderen Untersuchungen nicht mehr möglich.

5. Zusammenfassung Fragebögen bieten sich zur Messung der User Experience in vielfältigen Situationen an. Empfohlen wird ein Pre-Test des Fragebogens mit der Zielgruppe und dem Testobjekt bei dem die Probanden

Oft besteht der Wunsch aus dem Management eine Kennzahl für die Softwareüberprüfung bereit zu stellen. Aufgrund der

Bewertung pro Item ­1

0

Beim Vergleich zweier Dimensionen sowie beim Vergleich zweier Produkte ist auf die Signifikanz von Unterschieden in den Mittelwerten zu achten. Das UEQ-Excel-Tool gibt hierzu Fehlerbalken an, welche eine mögliche Toleranz der Ergebnisse darstellt und Konfidenzintervalle von 95 Prozent angeben. Vor einer Betrachtung der Mittelwerte zu einer Dimension sind die Ergebnisse der einzelnen Items kritisch zu prüfen. Wenn einzelne Items einer Dimension stark voneinander abweichen, dann könnte dies auf eine Fehlinterpretation einzelner Items durch die Probanden hinweisen. In Abbildung 2 ist ein Ausschnitt aus Verteilung der Mittelwerte der einzelnen Items dargestellt. Die Farben zeigen die Zugehörigkeit der Items zu einer Dimension an, beispielsweise steht die Farbe Gelb für die Dimension „Stimulation“. In der Abbildung kann erkannt werden, dass sich der Mittelwert für das Item-Paar „uninteressant“ – „interessant“

Konstruktion des Fragebogens ist dies nicht möglich. Ein Verrechnen der einzelnen Dimensionsmittelwerte zu einer einzigen KPI wäre nur sinnvoll, wenn man davon ausgeht, dass alle Dimensionen den gleichen Einfluss auf das Gesamturteil der befragten Personen haben. Diese Annahme kann aber in konkreten Projekten in der Regel nicht treffen. Erfahrungen aus bisherigen Anwendungen zum UEQ zeigen auch, dass der Einfluss der Dimensionen auf das Gesamturteil abhängig von der Art des evaluierten Produkts durchaus stark variieren kann.

1

2

uninteressant

3

interessant

Abb. 2. Beispiel: Mittelwert für das Item-Paar „uninteressant“ – „interessant“ unterscheidet sich stark von den anderen Mittelwerten.

75


zur Interpretation der Items im Anschluss befragt werden. Dadurch kann eine korrekte Interpretation der Items durch die Zielgruppe und bezogen auf das Testobjekt erhöht werden.

Literatur 1. Burmester, M., Jäger, K., Mast, M., Peissner,

Sofern die Datenanalyse keine negativen Auffälligkeiten ergeben hat, können sowohl die Mittelwerte der einzelnen Dimensionen als auch der einzelnen Items eine gute Aussage über den Handlungsbedarf am Produkt oder über die Verbesserung nach einem Relaunch liefern. Die Ergebnisse sollten allerdings immer kritisch reflektiert und Auffälligkeiten hinterfragt werden z.B. bei großen Abweichungen einzelner Items vom Dimensionsmittelwert.

Usability Professionals 2006, 140–145.

Formative Evaluation der User Experience.

Stuttgart. German Chapter der Usability

In: Brau, H. (Hrsg.). Usability Professionals 2. Hassenzahl, M., Burmester, M. & Koller, F.

Professionals Assoc. 11. Rauschenberger, M., Hinderks, A. & Thomaschewski, T. (2011). Benutzererlebnis

(2008). Der User Experience (UX) auf der

bei Unternehmenssoftware: Ein

Spur: Zum Einsatz von www.attrakdiff.de.

Praxisbericht über die Umsetzung attraktiver

In: Brau, H. (Hrsg.). Usability Professionals

Unternehmenssoftware In: Brau, H. (Hrsg.).

2008, 78–82. Stuttgart: German Chapter der

Usability Professionals 2011, 158 – 163.

Usability Professionals Assoc. 3. Hinderks, A., Schrepp, M., Rauschenberger, M., Olschner, S. & Thomaschewski, J. (2012). Konstruktion eines Fragebogens für jugendliche Personen zur Messung der User

Stuttgart. German UPA e.V.. 12. Norman, Donald A. (2009). THE WAY I SEE IT: Memory is more important than actuality. In: interactions (2), S. 24. 13. Rauschenberger, M., Schrepp, M., Olschner,

Experience. In: Brau, H. (Hrsg.). Usability

S., Thomaschewski, J. & Cota, M.P. (2012).

Professionals 2012, 78 – 83. Stuttgart.

Measurement of User Experience. A Spanish

German UPA e.V.

Language Version of the User Experience

4. Höpflinger, F. (2010). Praktische Regeln zur Formulierung von Fragen für Fragebögen. online verfügbar unter http://arbeitsblaetter. stangl-taller.at/FORSCHUNGSMETHODEN/

Questionnaire (UEQ). In: Rocha, A. (Hrsg.). Sistemas y Tecnologías de Información 2 (2013), 39–45. Madrid. 14. Wilamowitz-Moellendorff, M. von;

FrageformulierungDetail.shtml, zuletzt

Hassenzahl, M. & Platz, A. (2007).

geprüft am 14.06.2013.

Veränderung in der Wahrnehmung und

5. ISO 9241–210:2010 (2011). Ergonomie

Bewertung interaktiver Produkte. In: Gross

der Mensch-System-Interaktion – Teil 210:

(Hrsg.). Mensch & Computer. 7, 49–58.

Prozess zur Gestaltung gebrauchstauglicher

München. Oldenbourg Verlag

interaktiver Systeme. 6. Kim, K., Kolbe, K. & Eisele, S. (2012). Es steht Dir ins Gesicht geschrieben! In: I-Com (1), 63–67. online verfügbar unter http://dx.doi. org/10.1524/icom.2012.0016. zuletzt geprüft am 29.06.2013. 7. Laugwitz, B., Schrepp, M. & Held, T. (2006). Konstruktion eines Fragebogens zur Messung der User Experience von Softwareprodukten. In: Heinecke, A.M (Hrsg.). Mensch & Computer 2006, 125–134. München. Oldenbourg Verlag S. 8. Laugwitz, B., Held, T. & Schrepp, M. (2008). Construction and Evaluation of a User Experience Questionnaire. In: Holzinger, A. (Hrsg.). Lecture Notes in Computer Science. Berlin Heidelberg. Springer Berlin Heidelberg. 9. 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 (Hrsg.). Usability Professionals 2009, 220 – 225. Stuttgart: Fraunhofer Verlag.

76

Nutzungserlebens. In: Bosenick, T. (Hrsg.).

M. & Sproll, S. (2010). Design verstehen –

2010, 206–211. Stuttgart. Fraunhofer Verlag.

Vor der Interpretation der Ergebnisse der Umfrage mittels Fragebogen ist eine Datenanalyse notwendig. Zur Berechnung liefert beim UEQ das UEQ-Excel-Tool alle hierfür notwendigen Algorithmen und Grundlagen (Cronbach-Alpha-Werte der einzelnen Dimensionen, Konfidenzintervalle je Item und Dimension, Varianz und Standardabweichung). Anhand der Bewertung der einzelnen Items können oftmals Interpretationsschwierigkeiten durch die Probanden vermutet oder erkannt werden.

10. Mahlke, S. (2006). Emotionen als Aspekt des


Usability Professionals 2013 Tutorials

77


Durch schnelles Scheitern zum Erfolg: Eine Frage des passenden Prototypen? Kirstin Kohler Hochschule Mannheim Paul-Wittsack-Straße 10 68163 Mannheim k.kohler@hs-mannheim.de

Sarah Diefenbach Folkwang Universität der Künste Universitätsstraße 12 45141 Essen sarah.diefenbach@folkwang-uni.de

Thorsten Hochreuter Hochschule Mannheim Paul-Wittsack-Straße 10 68163 Mannheim t.hochreuter@hs-mannheim.de

Eva Lenz Folkwang Universität der Künste Universitätsstraße 12 45141 Essen eva.lenz@folkwang-uni.de

Abstract Der vorliegende Beitrag beschäftigt sich mit dem systematischen Umgang mit Prototypen im Kontext der Gestaltung und Evaluation interaktiver Produkte. Wir stellen ein Modell vor, das es erlaubt Prototypen aus unterschiedlichen Materialien (z.B. Papier, Comic, Click-Dummy) entlang ihrer Inhaltselemente zu klassifizieren. Wir diskutieren unterschiedliche Zielsetzungen im Kontext der Prototypenerstellung und stellen Heuristiken vor, die die Identifikation des passenden Prototyps je nach Fragestellung und Zeitpunkt im Gestaltungsprozess erleichtern. Wir schließen mit einem Ausblick auf nächste Forschungsschritte.

1. Einleitung Trotz der generellen Akzeptanz von Proto­ typing als sinnvoller Methode des User Experience Designs besteht in vielen Projekten unerkanntes Verbesserungspotential, für das wir sensibilisieren möchten. Angeregt durch unsere Erfahrung in Projekten mit Studierenden und Industriepartnern haben wir uns der Frage angenommen, warum Konzeptfehler in Prototypen früher Projektphasen nicht auffallen und sich erst als schwerwiegend herausstellen, wenn das Produkt fertig implementiert ist und wie man Prototypen optimieren kann, um Schwachstellen möglichst frühzeitig und damit kostengünstig zu identifizieren. Der vorliegende Beitrag kann diese Fragen sicherlich nicht erschöpfend beantworten. Vielmehr möchten wir einen Rahmen schaffen, der es erlaubt, Erfahrungen aus verschiedenen Projekten zusammenzutragen und Ansatzpunkte für zielgerichtetes Prototyping zu erarbeiten. Ein zentrales Anliegen ist hierbei, Eigenschaften eines Prototypen (z.B. Material, Tiefe der Ausgestaltung) der

78

zu evaluierenden Fragestellung oder dem intendierten Zweck des Prototypen systematisch gegenüber zustellen. Kapitel 2 beschreibt unsere Sicht auf den Begriff des Prototyps und stellt ein Modell vor, das es erlaubt Prototypen zu charakte­ ri­sieren. Kapitel 3 diskutiert die ­Validität von Prototypen beziehungsweise die Fra­ge, über welche Eigenschaften Proto­typen verfügen müssen, um valide Ergeb­nisse beim Einsatz in Evaluationsstudien zu gewährleisten. Der Beitrag schließt mit einem Ausblick auf zukünftige For­schungsfragen.

Marc Hassenzahl Folkwang Universität der Künste Universitätsstraße 12 45141 Essen marc.hassenzahl@folkwang-uni.de

Keywords: /// Prototyping /// User Experience /// Gestaltung /// Evaluation /// Filter-Fidelity-Modell

einen bestimmten Einsatzzweck erstellt wurde und damit auch aus anderen Materialien oder mit einer anderen Technologie erstellt werden kann. Je nach Material kann der Prototyp anfassbar (z.B. aus Papier) oder erlebbar (z.B. ein Video) sein. Auch die Einsatzzwecke innerhalb des ­Ent­wicklungsprozesses können sehr unter­ schiedlich sein (Houde & Hill, 1997; vgl. auch Buxton, 2007, Lim et al., 2008), beispielsweise: –– Phase der Ausgestaltung: –– Neue Gestaltungsideen und Lösungsansätze generieren

2. Prototypen besser verstehen und charakterisieren 2.1. Begriffseinordnung und Einsatzzweck

–– Experimentieren mit Gestaltungsideen, Materialien, Technologien

–– Phase der Selektion: –– Gestaltungsideen, Materialien und Technologien evaluieren

–– Dokumentation von Ein Prototyp ist ein Artefakt, das innerhalb eines Gestaltungs- und Entwicklungsprozesses erzeugt wird und eine Annäherung an das Endprodukt darstellt. Ein Prototyp hat daher große Gemeinsamkeiten mit einem unfertigen Produkt, jedoch mit dem Unterschied, dass ein Prototyp gezielt für

Gestaltungsentscheidungen

Im Folgenden betrachten wir den gezielten Einsatz von Prototypen zur Ausgestaltung und Selektion von Gestaltungsideen. Auf Prototypen zum Zwecke der Dokumentation gehen wir nicht weiter ein.


Usability Professionals 2013 Tutorials

Unabhängig davon, welcher Einsatzzweck mit einem Prototyp verfolgt wird und aus welchem Material er besteht, ist ein Prototyp im Vergleich zum Endprodukt immer unvollständig bezüglich gewisser Aspekte. Diese Unvollständigkeit dient nicht nur der Einsparung von Zeit und Kosten bei der Erstellung eines Artefakts zwecks Testung in Nutzerstudien (Nielsen, 1994), sondern auch, um den Prototypen besser auf die erwähnten Einsatzzwecke fokussieren zu können. So lenken beispielsweise interaktive Aspekte (z.B. Übergänge zwischen Screens) bei der Evaluation von grafischen Gestaltungsideen (z.B. UI-Farben) ab und können daher unausgestaltet bleiben. Lim und Kollegen (2008) bringen diesen Sachverhalt als das „fundamental principle of prototyping“ auf den Punkt: „Prototyping is an activity with the purpose of creating a manifestation that, in its simplest form, filters the qualities in which designers are interested, without distorting the understanding of the whole“ (Lim et al., 2008). Lim und Kollegen betrachten einen Prototypen (und die damit verbundene Tätigkeit des „Prototyping“) als einen Filter auf einem nahezu beliebig großen Gestaltungsund Technologiespielraum. Es ist damit Aufgabe des Gestalters bzw. Entwicklers, die Qualitäten herauszufiltern, die im Fokus der Betrachtung stehen sollen. Aus dieser Sichtweise ergibt sich die Frage, welche Aspekte man im Prototyp herausfiltern sollte, um ein hinreichendes Verständnis der durch Prototyping adressierten Fragestellung zu ermöglichen. Wir nähern uns dieser Frage mit Hilfe eines Modells, das die gefilterten Aspekte beschreibt: das FilterFidelity Modell. Die folgenden Abschnitte erläutern das Modell am Beispiel zweier konkreter Prototypen. 2.2. Fidelity von Prototypen Zur Kategorisierung von Prototypen wird in der Regel der Begriff der „Fidelity“ (dt. Wiedergabetreue/Reichhaltigkeit) verwendet. Die Fidelity eines Prototyps beschreibt

dabei die Wiedergabetreue im Vergleich zum Endprodukt. Typischerweise wird hier eine Unterscheidung in Low-Fidelity (Lo-Fi) und High-Fidelity (Hi-Fi) getroffen (vgl. z.B. Rudd et al., 1996); wobei Lo-Fi Prototypen solche sind, die weit vom Endprodukt ent­ fernt sind und Hi-Fi solche, die nahe am Endprodukt sind. Im allgemeinen Verständnis sind die Begriffe Lo-Fi und Hi-Fi zusätzlich an das Material des Prototyps gekoppelt: Lo-Fi bezeichnet papierbasierte, Hi-Fi hingegen computer-basierte Prototypen. Unserer Ansicht nach ist diese vereinfachte eindimensionale Klassifizierung eines Prototyps nur bedingt aussagekräftig. Sie gelangt vor allem dann an ihre Grenzen, wenn Prototypen in einzelnen Aspekten sehr reichhaltig sind, in andern Punkten dagegen kaum (McCurdy et al., 2006). Wo ließe sich hier beispielsweise ein in Photoshop erstelltes, grafisch sehr detailliertes Screen-Design einordnen, das keinerlei Interaktivität besitzt? Hi-Fi, weil es die Farbe und Positionierung von UI-Elementen sehr produktnahe abbildet? Oder Lo-Fi, weil es nicht interaktiv ist? Lim et al. (2008) schlagen ausgehend von dieser Argumentation einen mehrdimen­ sionalen Ansatz vor, der es erlaubt Proto­ typen in unterschiedlichen Aspekten deutlich differenzierter zu betrachten. Der bereits erwähnten Idee des „Filterns von Qualitäten“ folgend, beschreiben Lim und Kollegen fünf Filter-Dimensionen: die Dimension der Erscheinung, der Daten, der Funktionalität, der Interaktivität und der räumlichen Struktur. Diese Filter-Dimensionen wiederrum bestehen selbst aus einer Reihe von Qualitätsattributen (sog. Variablen), die zusammenfassend das Produkt/ den Prototypen definieren. Eine Variable der Daten-Dimension ist z.B. die „Menge der Daten“. Durch die schrittweise Ausgestaltung dieser Variablen im zeitlichen Verlauf eines Konzeptionsprozesses werden Gestaltungsentscheidungen getroffen, die im Prototyp repräsentiert werden. So kann der Prototyp einer Datenverwaltungsanwendung basierend auf Tabellen, einzelne Zeilen und Spalten der Tabelle andeuten oder 2000 Dateneinträge darstellen. Im Rahmen des BMBF-Projekts proTACT

haben wir das beschriebene Filter-Modell verfeinert. Variablen, die Lim und Kollegen (2008) nur exemplarisch aufführen, haben wir für be-greifbare Interaktionen in Form einer aufzählbaren Liste beschrieben und ihre Bedeutung definiert. Unser so entstandenes Modell trägt die Bezeichnung FilterFidelity Modell. Die Menge der ausgewählten Variablen haben wir aus der Arbeit mit Prototypen verschiedener Projekte im Hochschulkontext und aus Anwendungsprojekten unserer Partner hergeleitet. Eine detaillierte Definition der Variablen findet sich in Hochreuter und Kollegen (2013). 2.3. Filter-Fidelity-Profile Ein sogenanntes Filter-Fidelity-Profil (kurz FFP, siehe Abbildung 1) ist eine grafische Darstellung der gefilterten Aspekte eines Prototypen. Es entsteht, indem jede Variable der Filter-Dimensionen auf einer Skala von 1 bis 5 definiert wird, wobei „1 = nicht festgelegt“ (Lo-Fi) und „5 = ausgestaltet“ (Hi-Fi) bedeutet. Die konkrete Bedeutung der Variablen und deren Skalierung ist eine Frage des Anwendungskontexts beziehungsweise des Projekttyps (z.B. (Weiter-) Entwicklung, Konzeption, etc.) und muss entsprechend von Fall zu Fall festgelegt werden. In Bezug auf die Realitätsnähe der Daten könnte beispielsweise der Wert „1“ bedeuten, dass es sich um einfache Platzhalter-Daten handelt, wohingegen der Wert “5„ signalisiert, dass die eingesetzten Daten Echtdaten aus dem Produktiveinsatz sind. Das vorgestellte Modell liefert in diesem Zusammenhang lediglich einen Rahmen, in den spezifische Überlegungen eingegliedert werden sollen und nicht das allumfassende Beschreibungsmodell für alle Prototypen. Es ist Aufgabe des Gestalters beziehungsweise Entwicklers zu entscheiden, wann eine Variable als “ausgestaltet (5)“ betrachtet wird. 2.4. Ein Beispiel für Filter-Fidelity-Profile Im Rahmen seiner Abschlussarbeit an der Hochschule Mannheim entwickelt Tommy Vinh Lam ein touch-basiertes Werkzeug für

79


die Befundung von radiologischen Bilddaten. Mittels einer physikalischen Linse) kann der Anwender auf einem zweigeteilten Multi-Touch-Tisch radiologische Aufnahmen digital vergrößern (vgl. z.B. Ullmer & Ishii, 1997. Zwei Prototypen aus dem Kontext dieser Arbeit werden im Folgenden mit Hilfe ihres Filter Fidelity Profils charakterisiert. Abbildung 2 zeigt einen ersten Papierprototyp zur Navigationsstruktur. Wie zu erkennen ist, beschränkt sich der Prototyp primär auf die Abfolge von Bildschirmseiten und ist daher unvollständig bezüglich der Erscheinung, der Funktionalität und der räumlichen Struktur. Lediglich einzelne UI-Elemente sind schon zu erkennen, ebenso einzelne Datenaspekte, wie beispielsweise die angedeuteten „radiologischen Bilddaten“ (Abb. 2, oben). Die konkrete Ausgestaltung einzelner Aktionen und Reaktionen fehlt (z.B. das Skalieren der Bilddaten durch Drehen der Linse). Die dargestellte Informationsarchitektur und Navigation ist weder vollständig, noch final ausgestaltet, entsprechend ist die Fidelity dieser Variable als eher „mittelmäßig“ anzusehen. [Abb. 1], [Abb. 2]

Abb. 1. Gegenüberstellung der Filter-Fidelity-Profile zweier Prototypen eines Konzepts zu unterschiedlichen Zeitpunkten im Entwicklungsprozess.

Abb. 2. Einfache UI-Skizze zur Verdeutlichung der Navigationsstruktur.

80

Abbildung 3 zeigt einen implementierten Prototyp der gleichen Anwendung. Der Fokus lag hier auf der tatsächlich spürbaren Interaktion mittels physikalischer Linse. Der Funktionsumfang ist entsprechend gering, die Funktionstiefe der Implementierung dagegen ist ein für die Evaluation entscheidendes Kriterium und entsprechend Hi-Fi. Die grafische Erscheinung ist sehr weit ausgestaltet und wird im Filter-Fidelity-Profil dementsprechend klassifiziert (siehe Abbildung 1). Besonders die physikalischen Aspekte der Benutzerschnittstelle (z.B. Härte) sind stark ausgestaltet, hier handelt es sich um das finale Modell der Linse. Gleiches gilt für die räumliche Struktur des Prototyps, hierzu zählen unter anderem die Konzeption von physikalischen Gegenständen (Tangibility) sowie die zweidimensionale Anordnung von UI-Elementen. Auch die DatenDimension ist deutlich stärker vertreten. Der Prototyp verwendet sehr realitätsnahe radiologische Aufnahmen (wenn auch keine Produktiv-Patientendaten). [Abb. 3]


Usability Professionals 2013 Tutorials

Im direkten Vergleich der Profile (Abbildung 1) lassen sich deutliche Unterschiede erkennen. Der Papierprototyp beschränkt sich auf konzeptionelle Inhalte (z.B. die Informations- und Navigationsarchitektur). Grafische, funktionale und interaktive Aspekte bleiben weitestgehend unbeachtet. Der implementierte Prototyp konzentriert sich hingegen genau auf diese Aspekte, wobei schon erarbeitete Punkte bezüglich der Daten-Dimension beibehalten werden. Der zweite Prototyp besitzt entsprechend eine größere Ähnlichkeit zum Endprodukt.

muss, um diese Evaluationsfrage beantworten zu können. Um tatsächlich „valide“ und hilfreiche Einsichten erwarten zu können, muss ein Prototyp die Konzeptidee ausreichend erfahrbar machen – trotz der reduzierten (weil gefilterten) Darstellung. Insbesondere diejenigen Aspekte, die im Zentrum noch zu treffender Gestaltungsentscheidungen

stehen, müssen durch die Repräsentation erfahrbar sein. Abbildung 4 zeigt die aus unserer Sicht relevanten Einflussfaktoren für die Frage nach dem passenden Prototyp im Überblick. Die „Validität“ von Prototypen ergibt sich durch die Passung von Motivation (Warum Prototyping? Wozu erhofft man sich Einsichten?) und dem Prototyp (das, was das Konzept erfahrbar macht). Neben dem inhaltlichen Fokus

3. Validität von Prototypen Das vorgestellte Modell liefert einen ersten Ansatz, um unterschiedliche Prototypen durch die dargestellten Aspekte näher charakterisieren und vergleichen zu können. Der systematische Vergleich wiederum bietet eine Basis für die Untersuchung und Optimierung des Einsatzes von Prototypen im Entwicklungsprozess. Die Wahl eines „unpassenden“ Prototyps kann dazu führen, dass man sich auf die „falschen“ Variablen fokussiert. Insbesondere beim Einsatz von Prototypen in Evaluationsstudien sind unzureichende Ergebnisse die Folge und die eigentliche Motivation des Prototypings wird nicht erfüllt – beispielsweise werden anstatt Usability-Schwächen lediglich grafische Ungereimtheiten aufgedeckt (z.B. eine von der CI abweichende Farbgebung). Eine Charakterisierung des Prototyps durch sein FFP liefert eine wichtige Grundlage für die Abwägung der Passung von Prototyp und Einsatzzweck. Im oben beschriebenen Linsenprojekt ist eine interessante Evaluationsfrage, welche kognitive Last die Interaktion mit der physikalischen Linse dem Anwender während einer Befundung abverlangt. Erkennt der Anwender das Mapping zwischen dem ausgewählten und vergrößerten Bildbereich auch bei unterschiedlichen Zoomfaktoren, wenn beispielsweise der vergrößerte Teil die Darstellungsfläche überschreitet und damit der Linsenausschnitt nicht mehr 1:1 zum Bildausschnitt passt? Seitens des Prototyps stellt sich wiederum die Frage, welche Reichhaltigkeit dieser mitbringen

Abb. 3. Implementierter Prototyp einer physikalischen Linse

81


(z.B. Emotionen, Usability etc.) muss seitens der Motivation auch die Phase der Produktentwicklung berücksichtigt werden: Wird Prototyping als ein Mittel eingesetzt, um mehr Ideen zu generieren (Phase der Ausgestaltung) oder geht es bereits um den Vergleich und die Bewertung alternativer Ideen (Phase der Selektion)? Seitens des Prototyps kommt es in erster Linie auf das eingesetzte Artefakt an, definiert durch das verwendete „Material“ (der Stoff der Erfahrbarkeit, z.B. Papier, Video) und der hierdurch realisierten Fidelity. Nicht jedes Material ist zur Darstellung aller Variablen des FFP geeignet. So lässt sich mit einem Papierprototyp kein Sound erfahrbar machen. Neben dem Artefakt spielt aber auch die spezifische „Konfrontationsmethode“ eine Rolle: Beispielsweise kann ich durch reales Ausprobieren eines Prototypen andere Einsichten generieren als wenn ich diesen nur präsentiert bekomme oder zusehe wie andere damit agieren. [Abb. 4] Unsere Einblicke zum Einsatz von Prototyping in der Unternehmenspraxis zeigen jedoch meist kein systematisches Vorgehen bezüglich der Wahl des Prototyps. Prototyping ist zwar etablierter Teil des Produktentwicklungszyklus, aber die dahinterliegenden Motivationen werden selten explizit formuliert und fließen somit nicht (oder zumindest nicht bewusst) in die Wahl des Prototyps ein. Stattdessen ergibt sich diese oft aus den im Unternehmen etablierten Werkzeugen oder Entwicklungsschritten. Dieses unbedarfte Vorgehen verwundert, da Ergebnisse aus einem Prototypentest die weitere Ausgestaltung oft maßgeblich beeinflussen. Im Extremfall könnten aus solchen Beurteilungen

Abb. 4. Erfolgreiches Prototyping erfordert eine Passung von Prototyp (das, was das Konzept erfahrbar macht) und Motivation (das, wozu man sich Einsichten erhofft).

82

folgende Gestaltungsentscheidungen (und damit das finale Produkt) stärker von der Art des Prototyps als vom Konzept selbst beeinflusst sein. Darüber hinaus fehlt es aber sicherlich auch an Richtlinien und Kriterien für eine systematische Wahl eines geeigneten Prototyps. Gerade im Bereich interaktiver Produkte ist die Beurteilung der Validität von Prototypen nicht leicht, denn die Grenzen der Vorstellungskraft und Urteilsfähigkeit von Testteilnehmern sind noch relativ unerforscht. Es ist beispielsweise nicht klar, inwieweit die Beurteilung interaktiver Produkte tatsächlich „Interaktion“ erfordert, oder ob sich das Potential eines Konzepts auch anhand einer rein textuellen Beschreibung abschätzen lässt. Insgesamt existieren bislang nur wenige Einsichten dazu, wie die Art des Prototyps das Evaluationsergebnis beeinflusst. Frühe Untersuchungen zur systematischen Gegenüberstellung verschiedener Repräsentationsformen konzentrieren sich meist auf den Zusammenhang zwischen Fidelity des Prototyps und Zahl/Art aufgedeckter Usability-Probleme (z.B. Virzi et al., 1996; Walker et al., 2002). Diese zeigen insgesamt geringe oder keine Effekte, das heißt ein höheres Maß an Fidelity zahlte sich nicht in umfangreicheren Erkenntnissen bzgl. der Usability aus. Neuere Studien gehen über die Hi-Fi/ Lo-Fi-Unterscheidung hinaus. Basierend auf dem in den vorherigen Abschnitten diskutierten Konzept der Mixed Fidelity (McCurdy et al., 2006) untersuchte beispielsweise Struckmeier (2011) die Dimension der visuellen Verfeinerung. Hier zeigten sich zumindest tendenzielle Unterschiede bezüglich der Art der gefundenen

Usability-Probleme. Ein Prototyp hoher visueller Verfeinerung regte zur intensiven Auseinandersetzung mit grafischen Elementen und möglichen UsabilityProblemen an, beim Prototyp geringer visueller Verfeinerung lag der Fokus hingegen eher auf (unnötig langen) Navigationspfaden. Die Art des Prototyps führte hier also zu einer Verschiebung des Fokus der Testteilnehmer. Eine höhere Fidelity kann sich also sogar ungünstig auswirken, wenn bestimmte Probleme nicht identifiziert werden, da die Aufmerksamkeit auf andere  Aspekte gerichtet wird. 4. Heuristiken zum Einsatz von Prototyping zur Konzeptevaluation Eigene Studien zur Bedeutsamkeit der Konzeptrepräsentation (Diefenbach et al., 2010; Diefenbach et al., 2013) verglichen die Beurteilung eines Produktkonzepts anhand verschiedener Prototypen bzw. Darstellungsformen (z.B. reales Ausprobieren eines Funktionsprototyps in einer Laborsituation, Repräsentation des Produktkonzepts mittels Video, Comic-Animation, Foto-Story, textueller Beschreibung). Auch wenn unsere Erfahrungen auf eine begrenzte Auswahl von Produktkonzepten und Darstellungsformen beschränkt sind, zeichnen sich bereits einige Tendenzen ab, die Hinweise zur Auswahl einer geeigneten Art des Prototyps sowie zur Einordnung von Evaluationsergebnissen bieten (für eine ausführliche Diskussion siehe Diefenbach et al., 2013): – Bewusste Fragestellung: Eine wichtige Voraussetzung für eine kluge Wahl des Prototypen ist zunächst die Definition einer Fragestellung: Zu welchen Aspekten erhofft man sich Einsichten, welche Aspekte sollen besondere Aufmerksamkeit erfahren? – Potential der Vorstellungskraft: Schon einfache Darstellungsformen wie textuelle Konzeptbeschreibungen bieten hilfreiche Einsichten für die weitere Ausgestaltung. Bereits auf Basis reduzierter Darstellungen können Personen eine gute Vorstellung des Konzepts entwickeln, verstehen, welche Bedürfnisse adressiert werden, und


Usability Professionals 2013 Tutorials

äußern ähnliche Überlegungen wie bei reichhaltigeren Darstellungsformen. Auch grundlegende Usability-Probleme können schon anhand von abstrakten Darstellungen überraschend gut antizipiert werden. Deutliche Unterschiede zeigen sich erst auf der Ebene konkreter motorischer Elemente. Der Einstieg in die Konzeptevaluation scheint also bereits im Ideenstadium sinnvoll und bietet die Möglichkeit mit vergleichsweise geringem Aufwand externe Rückmeldungen einzuholen. – Bewusste Reduktion: Eine valide Bewertungsgrundlage erfordert die bewusst reduzierte Darstellung von noch nicht ausgestalteten Aspekten. Prototypen müssen ausdrücken, was bereits ausgestalteter Teil des Konzepts und was noch Platzhalter für Unfertiges ist. Sonst kann es passieren, dass Teilnehmer ihre Aufmerksamkeit auf die „falschen“ Details richten, und die für die Beantwortung der zentralen Fragestellung relevanten Details außer Acht lassen. – Idealisierungstendenzen: Die in reduzierten Formen der Konzeptdarstellung enthaltenen Freiheitsgrade nutzen Testteilnehmer zur gedanklichen Ausgestaltung des Konzepts nach persönlichen Vorstellungen, was typischerweise in einer insgesamt positiveren Konzeptbewertung resultiert. Bei der Interpretation von Evaluationsergebnissen müssen diese Idealisierungstendenzen berücksichtigt werden. – Aktive Auseinandersetzung: Eine häufige Annahme ist, dass Prototypen alle Details möglichst ausführlich darstellen müssen, um ein Konzept für Testteilnehmer erschließbar zu machen. Tatsächlich können komplexe, detailreiche Darstellungen jedoch schnell erschlagend wirken, wohingegen reduzierte Darstellungen motivierender wirken und eher eigene Überlegungen und aktive Auseinandersetzung fördern. Es muss somit abgewogen werden zwischen der Notwendigkeit der Darstellung von Details für das Konzeptverständnis und der hieraus für den Rezipienten entstehenden „Belastung“.

Abb. 5. Produktmodelle wie das Filter-Fidelity-Modell beschreiben Funktionalitäten und Interaktion. Aus der User Experience Perspektive interessieren außerdem Bedürfnisse hinter der Produktnutzung und begleitende Emotionen.

5. Fazit und Ausblick Unsere bisherigen Arbeiten liefern bereits erste Ergebnisse zur Beantwortung der Frage des passenden Prototypen: Das Filter-Fidelity-Modell bietet eine Möglichkeit, die Reichhaltigkeit von Prototypen auf der Ebene des Artefakts zu beschreiben. Grenzen und Möglichkeiten des Prototyps werden somit bewusster und können mit der spezifischen Motivation abgeglichen werden. Darüberhinaus bieten unsere Einsichten aus bisherigen Studien allgemeine Hinweise zur Wirkung von Prototypen unterschiedlicher Reichhaltigkeit. Auch diese Meta-Informationen unterstützen die Beurteilung der Passung von Prototyp und Motivation sowie eine angemessene Einordnung von Evaluationsergebnissen. Ziel zukünftiger Forschung ist es jedoch, diese Teilaspekte genauer zu identifizieren, um die Entscheidung für eine bestimmte Art der Konzeptdarstellung noch besser unterstützen und anleiten zu können (beispielsweise in Form eines Entscheidungsbaumes). Das Filter-Fidelity-Modell bietet eine gute Grundlage zur Beschreibung der Reichhaltigkeit von Prototypen auf Produktebene (d.h. Funktionalitäten und Interaktion, im Ebenen-Modell der User Experience

nach Hassenzahl, 2010 bezeichnet als das „Was“ und „Wie“ der Interaktion). Für das Gesamtkonzept ist aber auch die Erlebnisebene wichtig: welche Bedürfnisse und Emotionen werden adressiert, welche „Geschichten“ werden durch das Produkt angelegt (das, was der Interaktion letztlich Bedeutung verleiht, das „Warum“ der Interaktion, siehe Abbildung 5). Zukünftige Forschung wird sich damit beschäftigen, wie auch die Erlebnisebene im Prototyping bewusst adressiert werden kann und welche sinnvollen Beschreibungsdimensionen sich hier identifizieren lassen. [Abb. 5] Darüberhinaus interessiert uns die Relation der Dimensionen des Filter-FidelityModells untereinander: Stehen die Dimensionen zu jedem Zeitpunkt des Entwicklungsprozesses als gleichberechtigt und gleich wichtig nebeneinander, oder gibt es eine „ideale“ Abfolge, in der die Dimensionen im Gestaltungsprozess adressiert werden sollten? Wie viele Dimensionen müssen ausgestaltet sein, um mit Hilfe des Prototyps aussagekräftige Ergebnisse erhalten zu können? Diese Fragestellungen sind gerade für die Anwendung in der Praxis von großer Bedeutsamkeit.

83


Literatur 1. Diefenbach, S., Hassenzahl, M., Eckoldt, K., & Laschke, M. (2010). The impact of concept (re) presentation on users‘ evaluation and perception. In Proceedings of the 6th Nordic Conference on Human-Computer Interaction: Extending Boundaries,. 631–634. ACM. 2. Diefenbach, S., Chien, W.-C., Lenz, E. & Hassenzahl, M. (2013). Prototypen auf dem Prüfstand. Bedeutsamkeit der Repräsentationsform im Rahmen der Konzeptevaluation. i-com. Zeitschrift für interaktive und kooperative Medien, 53–63. 3. Garrett, J. J. (2012). Die Elemente der User Experience. München: Addison-Wesley. 4. Hochreuter, T., Kohler, K. & Maurer, M. (2013). Prototypen im Kontext be-greifbarer Interaktion besser verstehen. Akzeptiert in: M&C 2013 Tagungsband. Bremen: Oldenbourg Verlag. 5. Lim, Y., Stolterman, E. & Tenenberg, J. (2008). The anatomy of prototypes: Prototypes as filters, prototypes as manifestations of design ideas. ACM Transactions on Computer-Human Interaction.15(2), Art. 7. 6. McCurdy, M., Connors, C., Pyrzak, G., Kanefsky, B. & Vera, A. (2006). Breaking the fidelity barrier: an examination of our current characterization of prototypes and an example of a mixedfidelity success. In Grinter, R., Rodden, T., Aoki, P., Cutrell, E., Jeffries, R. & Olson, G. (Hrsg.): Proc. of CHI ‚06. New York: ACM, 1233–1242. 7. Rudd, J., Stern, K., & Isensee, S. (1996). Low vs. high-fidelity prototyping debate. interactions Vol. 3 Issue 1 (January). New York: ACM, 76–85. 8. Struckmeier, A. (2011). Warum „gutes Aussehen“ nicht immer von Vorteil ist. Über den Einfluss der optischen Gestaltung von Prototypen auf das Nutzerverhalten im Usability-Test. In H. Brau, A. Lehmann, K. Petrovic, and M. C. Schroeder (Eds.) Usability Professionals 2011, 52–57. Stuttgart: German Chapter der Usability Professionals‘ Association e.V.

84

9. Ullmer, B. & Ishii, H. (1997). The metaDESK: Models and Prototypes for Tangible User Interfaces. In Proc. Of UIST’97. New York: ACM Press. 10. Virzi, R. A., Sokolov, J. L. & Karis, D. (1996). Usability problem identification using both low-and high-fidelity prototypes. In Proceedings of the SIGCHI conference on Human factors in computing systems: common ground, 236–243. ACM. 11. Walker, M., Takayama, L. & Landay, J. A. (2002). High-fidelity or lowfidelity, paper or computer? Choosing attributes when testing web prototypes. In Proceedings of the Human Factors and Ergonomics Society Annual Meeting 46(5), 661–665. SAGE Publications.

Förderung Die diesem Beitrag zugrunde liegenden Arbeiten entstanden im Forschungsverbundprojekt proTACT mit den Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) unter dem Förderkennzeichen 01 IS 12010 F.


Cross Plattform UX

85


Jenseits mobiler Anwendungen Telekommunikation trifft „Super-natural interaction“ – Von SMS bis M2M Sascha Wolter wolter.biz developergarden.com s.wolter@telekom.de

Abstract Eine SMS schickende Kuh, der Nachrichten austauschende Müllwagen und das telefonierende Projektmanagement-Werkzeug: Apps beschränken sich in naher Zukunft nicht mehr auf traditionelle PCs und mobile Geräte. Sowohl industrielle Lösungen als auch Alltagsgegenstände werden immer interaktiver und vernetzter, so dass der Nutzer nicht mehr nur mit einem einzelnen Gerät interagiert, sondern sich inmitten einer interaktiven Umwelt bewegt. Telekommunikationsunternehmen (kurz Telcos) müssen sich der Herausforderungen stellen, unterschiedlichste Geräteformen, Interaktionsformen und Netzwerke miteinander zu kombinieren. Dabei gibt es durchaus Szenarien in denen klassische Dienste wie SMS und Telefonie weiterhin eine entscheidende Rolle spielen. Anbieterübergreifend wird an weiteren Diensten gearbeitet, um neue Möglichkeiten zu bieten. Entwickler und Gestalter sind dabei zentrale Innovationstreiber, weshalb die Telekommunikationsanbieter ihre Dienste möglichst entwicklerfreundlich und standardisiert als APIs öffnen.

Super-natural interaction Schon jetzt durchdringen Navigationssystem, Smart Phone, Smart TV, Staubsaugerroboter und andere intelligente Systeme

unser Leben. Darüber hinaus schafft die Kombination dieser Geräte neue komplexe Systeme: Wo früher einzelne Haushaltsgeräte durch eingebettete Computer in unserer Umgebung lokal genutzt wurden,

Keywords: /// Telekommunikation /// SMS /// Prototyping /// Super-natural interaction /// Internet of Things

sind diese zukünftig global über das Internet vernetzt. Diese interaktiven Systeme dringen in immer unterschiedlicheren Geräteformen in immer mehr Lebensbereiche vor. [Abb. 1], [Abb. 2]

Abb. 1. Projekte rund um „Super-natural interaction“. Sketchnote der spielerischen Herangehensweise [Alt, 2013].

86


Usability Professionals 2013 Cross Plattform UX

Ein interaktives System setzt sich aus einer Vielzahl weiterer Systeme zusammen ([Stary, 1996, S. 14]). Dazu zählen der Anwender, die Anwendungs-Software, das Betriebssystem, das Hardware-System und das NetzwerkSystem. Die Schnittstelle zwischen Nutzer und Anwendung, die Interaktivität inkl. Sensoren und Aktuatoren (ein Aktuator wandelt elektrische Signale meist in mechanische Arbeit um und bildet somit das Gegenstück zum Sensor) werden dabei immer vielfältiger und „intelligenter“; vernetzte elektronische Geräte reagieren zunehmend auf Ihre Umgebung (Ambient intelligence, [Wikipedia, 2013]). Je nach Umgebung kommt der Wahl des Netzwerk-Systems ebenfalls eine wichtige Rolle zu – ob also z. B. ein GSMNetz oder DSL verfügbar sind, ob eine SMS geschickt oder IP-basierte Nachrichten übertragen werden. Das ist keine einfache Entscheidung, da die Verfügbarkeit, Vielfalt und Leistungsfähigkeit von Netzwerken regional variieren und sowohl Geschwindigkeit als auch Energieverbrauch von Bedeutung sind. Das Datenvolumen ist ebenfalls ein Aspekt, welcher nicht nur für die soziale Interaktion, sondern auch für industrielle Anwendungen von großer Bedeutung ist. Zum Vergleich: Die SMS hat ein Datenvolumen von gerade einmal 1/1000 gegenüber einer Gesprächsminute ([Wikipedia, 2013])! [Abb. 3] Die Durchdringung des Alltags mit Computern, die Vernetzung dieser Geräte untereinander und die Möglichkeiten in der MenschMaschine-Interaktion werden zunehmen und  immer mehr Kontexte bzw. Lebensbereiche betreffen. Dies forciert einen Paradigmenwechsel weg von der über Jahrzehnte erlernten 1:1 -Beziehung zwischen Mensch und Maschine hin zu komplexen 1:n Systemen aus vielen vernetzten Geräten in deren Mittelpunkt der Nutzer steht (ganz zu schweigen von kollaborativen Systemen mit mehreren Nutzern). Anders als bisher üblich interagiert der Nutzer nicht mehr mit einem einzelnen Gerät über dessen Bildschirm, sondern mit zahlreichen vernetzten Geräten die nicht zwangsläufig über einen Bildschirm verfügen (Headless System, [Wikipedia, 2013]). Unsere gesamte Umgebung wird laut [Wilson, 2012] zur Benutzungsschnittstelle („Super-natural interaction“).

Abb. 2. Interaktives System

Abb. 3. Kluft zwischen Mensch und Maschine nach [Norman, 1986, S. 111]

87


Diese Vielfalt erfordert neue Herangehensweisen, um frühzeitig deren Nutzen im Kontext evaluieren zu können. Andernfalls wird die Kluft zwischen Mensch und Maschine eher zunehmen als verringert ([Norman, 1986, S. 111]). Dabei ist nicht nur die Spezifizierung von Absichten durch den Nutzer sondern auch die Auswertung der Ergebnisse von Bedeutung – zumal eben nicht mehr nur mit einem einzelnen Gerät mit Bildschirm interagiert wird. Auch wenn laut [Reisinger, 2012] Smartphones und Tablets bis 2015 noch rund 80 % der Entwicklungstätigkeit bestimmen, gehen (nicht nur) Entwickler bereits jetzt davon aus, dass Anwendungen zukünftig für weitere Geräteformen erstellt werden ([Appcelerator, 2012]), darunter Smart TV, Connected Car, Spielkonsolen und Google Glass. Und immer mehr dieser Geräte sind miteinander verbunden: Die [OECD, 2012, S. 8] erwartet, dass die Anzahl der Geräte allein im Bereich der Maschine-mit-MaschineKommunikation (M2M) von heute rund 5 Milliarden auf 50 Milliarden im Jahr 2020 wächst. Der Umsatz soll laut Forrester Research bereits 2016 von heute 4,2 Milliarden auf dann 17 Milliarden US Dollar steigen [Forrester, 2011]. Und ein Ende dieses Wachstums ist nicht in Sicht. Eine wesentliche Rolle bei dieser Entwicklung könnte dem Notrufsystem eCall (kurz für

emergency call) zuteilwerden [Wikipedia, 2013]. Denn ab 2015 muss jedes in der Europäischen Union neu zugelassene Fahrzeug über eine Notruffunktion verfügen, wodurch sich jeder neue PKW in ein vernetztes und mobiles Endgerät verwandelt. Die Schlüssel zu neuen und erfolgreichen Anwendungen im Sinne der „Super-natural interaction“ sind die für die Umsetzung notwendigen Ressourcen (u. a. Entwickler) und damit einhergehend Vorgehensmodelle (z. B. Prototyping), die helfen in diesem doch häufig noch unbekannten Terrain der Benutzererlebnisse frühzeitig Ergebnisse zu liefern.

Entwickler und Reichweite Wenn man den Markt der Mobilfunkgeräte betrachtet, ist es offensichtlich, dass allein Endkunden (Konsumenten) nur noch geringes Wachstumspotential bieten,: Schließlich gab es 2012 z. B. allein in Deutschland laut der [Bundesnetzagentur, 2012] bereits mehr als 114 Millionen SIM-Karten bei nur gut 80 Millionen Einwohnern. Hier gilt es schon allein aus ökonomischer Sicht, neue Einsatzgebiete zu finden. Beispielsweise können auch Geräte und Tiere zu Mitgliedern einer vernetzten Gesellschaft werden und miteinander Informationen austauschen. [Abb. 4]

Telcos beschäftigen sich intensiv mit diesem Netzwerk bestehend aus vernetzten Geräten, dem sogenannten Internet der Dinge (Internet of Things) und suchen nach den nächsten Formen der Interaktion, Kommunikation und Vernetzung. Bestehende Dienste wie z  B. der Kurznachrichten SMS verfügen hier durchaus noch über eine tragende Rolle, um Innovationen zu schaffen. Doch ohne passend qualifizierte Entwickler in ausreichender Menge fehlt es an der Möglichkeit, diese Form der Innovationen überhaupt umzusetzen. Die Unternehmen realisieren außerdem zunehmend, dass Entwickler auch externe Investoren anziehen, die Innovation und Wachstum finanzieren ([Developer Economics, 2012, S. 4]). Der Entwickler wird zum Prosumer (Consumer und Producer): Sprich, der Entwickler konsumiert die Dienste eines Telcos und produzieren auf dieser Basis neue Lösungen. Der Wettbewerb um die Entwickler hat durch die Vielzahl der Ökosysteme mit ihren App-Stores zugenommen: Laut [Developer Economics, 2012, S. 5) haben Telcos massiv an Einfluss verloren und erreichen nur noch rund 3 Prozent der Entwickler. Die Entwicklung des Arbeitsmarktes tut ein Übriges dazu. Laut [BITKOM, 2012] ist die Anzahl offener Stellen in Deutschland im IT-Bereich allein in 2012 um 13 Prozent gestiegenen (75% der offenen Stellen richten sich an Softwareentwickler). Um für Entwickler an Attraktivität zu gewinnen, bieten die meisten Telcos speziell auf Entwickler zugeschnittene Portale und machen darüber APIs zugänglich. Telefonica bietet zwei APIs (SMS und MMS) über die Website https://bluevia.com/. AT&T stellt unter http://developer.att.com rund ein Dutzend APIs aus verschiedenen Bereichen zur Verfügung. Das Angebot von Vodafone umfasst http://developer. vodafone.com/ neben einem proprietären Bezahlverfahren noch APIs für RCS-e (Rich Communication Suite – Enhanced/joyn™).

Abb. 6. SMS sendende Tiere sind schon Realität [Medria, 2012].

88

Bei joyn™ handelt es sich um einen auch von der Deutschen Telekom unterstützen Messenger, mit dem man Chatten, Daten versenden und während eines Telefonates


Usability Professionals 2013 Cross Plattform UX

ein Video hinzuschalten kann. Dank RCS-e (Rich Communication Suite – Enhanced) steht dieser Kanal nicht nur Menschen sondern per API auch Programmen zur Verfügung, um z. B. mit einem Wetterdienst zu chatten oder Daten mit einem Gegenstand oder einer Maschine auszutauschen. Die Deutsche Telekom bietet unter http:// developergarden.com/ zahlreiche APIs und Services – darunter Empfang und Versandt von SMS, MMS, Spracherkennung/Telefonie und M2M. Dort finden sich auch ein Blog mit themenübergreifenden Inhalten und eine Community mit Events und Diskussionsforen (Englisch und Deutsch). Darüber hinaus verfolgt der Developer Garden eine Enabling-Strategie in Zusammenarbeit mit Inkubatoren wie hub:raum. Um den umworbenen Entwickler für sich zu gewinnen, müssen die Angebote laut [Developer Economics, 2012, S. 35) möglichst einfach zugänglich sein und die Opportunitätskosten gering gehalten werden. Einige Anbieter setzt hier wie der Developer Garden auf offene Standards (beispielsweise REST und JSON) und arbeitet mit der Vereinigung der Mobilfunkanbieter, kurz GSMA, zusammen. Außerdem hilfreich sind spezielle Entwickler, die als Sprachrohr zwischen dem Anbieter und den Nutzern der APIs und Services agieren. Diese im angelsächsischen Raum auch Ambassador oder Evangelist getauften Entwickler nutzen die Angebote in eigenen Projekten und arbeitet so bereits frühzeitig an einer stetigen Verbesserung mit. Sie tragen die Visionen und Begeisterung in der Sprache der Entwickler nach außen und kommunizieren die Erkenntnisse aus der ProjektPraxis zurück ins Team. Die Vielfalt im Angebot und die Transparenz in der Nutzung sind ebenfalls wichtig: Sprachdienste, Tonwahlverfahren, Kurznachrichten oder RCS-e/joyn™ müssen nicht nur einfach zu nutzen und kostenlos zu testen sein, sondern mit attraktiven Preismodellen daherkommen. Im Falle vom interaktiven Sprachdialogsystem Telekom Tropo ([Tropo, 2013]) wird

Abb. 6. Auswahlkriterium Reichweite [Developer Economics, 2012,S. 27].

beispielsweise ausschließlich Nutzungsabhängig abgerechnet. Der Empfang von SMS über die Global SMS API ([SMS, 2013]) erfordert nur eine Telefonnummer für rund 3 Euro netto pro Monat: So lässt sich ein Gerät auch noch im tiefsten Wald preiswert ans Internet anbinden, sofern wenigstens noch eine rudimentäre GSMVerbindung für den Transport von SMS möglich ist. Ein Anwendungsbeispiel sind Bienenstöcke, die durch eine elektronische Waage den Imker noch viele hundert Kilometer entfernt über den Zustand des Bienenvolkes informieren. [Abb. 5] Ein ganz wesentliches Auswahlkriterium gerade für eine Plattform im mobile Bereich ist laut [Developer Economics, 2012, S. 27] die „Reichweite“. Dabei verfügen jedoch nur rund 26% aller 5,2 Milliarden Mobilfunknutzer über ein internetfähiges Endgerät ([Ahonen, 2011]), so dass andere Kanäle für den Informationsaustausch durchaus Attraktivität sind. Kurznachrichten erreichen beispielsweise

79% bzw. 4,2 Milliarden Nutzer – SMS ist so nicht nur die meistgenutzte Datenanwendung weltweit, sondern verfügt auch über mehr aktive Nutzer als UKW-Radio. In der Praxis zeigen sich die Vorteile des Datenversands und -empfangs per Sprache oder SMS gerade bei Anwendungen, die hinsichtlich Konnektivität eher in unterversorgten Gebieten stattfinden. Sobald ein GSM-Netz funktioniert, lassen sich Daten senden und empfangen auch wenn eine stabile Internetverbindung lange noch nicht gewährleistet ist. Außerdem ist der Energieverbrauch in der Regel geringer. Die Landwirtschaft zeigt praktisch, wie es geht: Dort gibt es Kühe, die Ihre Empfängnisbereitschaft per SMS mitteilen und Bienenvölker, die täglich einen Statusbericht per Kurznachricht an einen Server übermitteln (siehe Abbildung 4). Und ein Sprachanruf ist nicht nur eine natürliche Interaktionsform sondern auch ein unmittelbarer Push-Dienst z. B. im Falle von Warnungen durch Sprachsynthese.

89


Abb. 6. LEGO-basierter Design Prozess nach [Gay, 2001].

Prototyping und Innovation Das reine Angebot von APIs und Services ist jedoch nicht ausreichend, um neue Ideen zu entwickeln und zu evaluieren. Letztendlich müssen Entwickler motiviert werden, sich damit aktiv zu beschäftigen. Der Softwareanbieter Atlassian hat mehre Möglichkeiten zur Entwickler-Motivation unter [Peters, 2011] zusammengefasst. Speziell zeitlich beschränkte Experimentierphasen haben sich etabliert. In Anlehnung an die Lieferzeit von Paketzustellern werden diese als FedEx Days bezeichnet. Das Konzept ähnelt sogenannten Hackathons. Diese haben jedoch meist einen Event-artigeren und offeneren Charakter

90

und werden vom Anbieter der APIs durch Evangelisten (siehe oben) betreut. Diese Idee der betreuten Projekte kann aber auch gemeinsam mit dem Kunden im Sinne der Ideenfindung und des Business Developments durchgeführt werden. [Abb. 6]

Auf Seiten der Hardware kann der Aufwand ebenfalls minimiert werden, indem man auf bereits existierende Produkte zurückgreift. Insbesondere Spielzeuge bieten sich für Prototypen an: Sie sind in der Regel kostengünstig und leicht zu modifizieren.

Um der Vielfalt der Möglichkeiten und Anforderungen gerecht zu werden, sollten auch iterative Vorgehensmodelle wie Prototyping beherrscht werden. Ganz im Sinne der Agilität müssen Individuen und Interaktionen mehr gelten als Prozesse und Werkzeuge. Ein Durchstich ist wichtiger als die Dokumentation. Der Anwender und der Nutzen befinden sich im Mittelpunkt. Und der Mut und die Offenheit für Änderungen stehen über dem Befolgen eines festgelegten Plans. Letztendlich ist diese Herangehensweise ein sehr natürlicher Prozess, der dem kindlichen Spielen mit Lego entsprich, so wie von Jonathan Gay beschrieben ([Gay, 2001]): 1. Choose a problem: Build a LEGO ship. 2. Develop a vision: What sort of ship will it be? How big will it be? What will it carry? 3. Build: Build the framework of the ship. 4. Fill in the details: Design and build the details of the ship, ramps, doors, etc. 5. Test: Drive the cars around the ship and sail the ship while exploring the house. 6. Refine: Take parts of the ship apart and make them better. 7. Learn: Take what you learned from building this ship and use it to build a better one next time. [Abb. 7]

Bedarf wecken

Doch auch für diese Herangehensweise müssen Rahmenbedingungen geschaffen werden, um zu einem befriedigenden Ergebnis zu kommen. Zum einen muss die Erwartungshaltung klar spezifiziert werden. Und die Bausteine für die Durchführung müssen vorbereitet sein: APIs und Services werden als einfach zu nutzenden Code-Blöcken vorbereitet. Je nach Projekt kann auch ein Modell-basiertes Entwurfsmuster wie MVC, MVVM oder das Presentation Model zum Einsatz kommen. Dies entspricht der Idee der Vorhangfassade aus der Architektur: Der Rohbau zur Nutzung der APIs ist vorbereitet und die eigentliche Anwendung wird wie eine Fassade nur noch an den Anschlusspunkten befestigt. [Abb. 8]

Die Zutaten für einen erfolgreichen Umgang mit „Super-natural interactions“ sind überschaubar. Motivierte und kompetente Entwickler, einfach zu verwendende Bausteine in Form von Software (APIs und Services), Konnektivität und leicht zugängliche Hardware für Interaktion und Sensorik (siehe Abbildung 2). Das gewürzt mit einer iterativen und prototypischen Herangehensweise erlaubt es auch in unbekanntem Terrain anhand von praktischen Beispielen zu forschen, ohne unnötig Ressourcen zu vergeuden und sich durch industrielle Zwänge zu beschränken. Dafür entsprechen die Ergebnisse nicht unbedingt den Anforderungen eines Produktes – es ist eher das Paretoprinzip, das hier zum Tragen kommt. Die Idee der spielerischen Herangehensweise auf Basis von vorgefertigten Bausteinen zeichnet sich aber nicht nur dadurch aus, dass man schnell zu Ergebnissen gelangt. Neben der eigentlichen Ideenfindung und schnellen Evaluierung hat dieses Vorgehen noch einen weiteren Vorteil: Während der aktiven Auseinandersetzung mit „Super-natural interactions“ werden Bedürfnisse überhaupt erst geweckt, die vorher noch gar nicht bewusst waren… Literatur 1. [Ahonen, 2011] Ahonen, T.: Time to Confirm some Mobile User Numbers: SMS, MMS, Mobile Internet, M-News http://communitiesdominate.blogs.com/brands/2011/01/timeto-confirm-some-mobile-user-numbers-smsmms-mobile-internet-m-news.html (Stand vom 13. Januar 2011) 2. [Alt, 2013] Alt, B.: UX Barcamp Europe 2013 – Toys are us, http://www.flickr.com/ photos/83052714@N05/9177425662/ (Stand vom 30. Juni 2013)


Usability Professionals 2013 Cross Plattform UX

Abb. 8. Es gibt zahlreiche interaktive Spielzeuge, die sich leicht und kostengünstig in Prorotypen verwenden lassen.

Abb. 7. Softwarearchitektur im Sinne einer Vorhangfassade.

3. [Appcelerator, 2012] Appcelerator /

8. [Gay, 2001] Gay, J.: The History of Flash,

IDC Q3 2012 Mobile Developer Report,

http://www.adobe.com/macromedia/events/

https://pages.appcelerator.com/

john_gay/ (Stand von 2001)

Q32012AppceleratorIDCSurveyReport.html (Stand von 2012) 4. [Bitcom, 2012] Bitcom: 43.000 offene Stellen

9. [Medria, 2012] Medria: http://www.medria.fr (Stand vom 8. November 2012) 10. [Norman, 1986] Donald A. Norman

14. [SMS, 2013] Global SMS API, http://www. developergarden.com/de/apis/apis-sdks/ global-sms-api/ (Stand vom 18. Juli 2013) 15. [Stary, 1996] Stary, C.: Interaktive Systeme. 2. Auflage, Vieweg, 1996. 16. [Tropo, 2013] Telekom Tropo API, http://

für IT-Experten, http://www.bitkom.org/de/

(Herausgeber), Stephen W. Draper

www.developergarden.com/de/apis/apis-

themen/54633_73892.aspx (Stand vom 30.

(Herausgeber), User Centered System

sdks/telekom-tropo-api/ (Stand vom 18. Juli

Oktober 2012)

Design: New Perspectives on Human-

5. [Bundesnetzagentur, 2012] Bundesnetzagentur: Wettbewerbsintensität

computer Interaction. CRC Press, 1986

2013) 17. [Wikipedia, 2013] Wikipedia: Ambient

11. [OECD, 2012] OECD: Machine-to-Machine

Intelligence, http://de.wikipedia.org/wiki/

im Mobilfunk nimmt weiter zu, http://

Communications: Connecting Billions of

Ambient_Intelligence (Stand vom 30. April

www.bundesnetzagentur.de/cln_1931/

Devices, OECD Digital Economy Papers,

SharedDocs/Pressemitteilungen/

No. 192, OECD Publishing. http://dx.doi.

DE/2012/120824_WettbewerbMobilfunk.

org/10.1787/5k9gsh2gp043-en (Stand vom

html (Stand vom 24. August 2012)

30. Januar 2012)

6. [Developer Economics, 2012], Developer

12. [Peters, 2011] Peters, S.: Motivation

Economics: The new mobile app economy,

für Softwareteams, http://svenpet.

http://www.developereconomics.com (Stand

com/2011/12/06/motivation_softwareteam/

vom Juni 2012)

(Stand vom 6. Dezember 2011)

7. [Forrester, 2011] Forrester Research, M2M

13. [Reisinger, 2012] Reisinger, D.: Gartner

2013) 18. [Wikipedia, 2013] Wikipedia: eCall, http:// de.wikipedia.org/wiki/ECall (Stand vom 17. Juli 2013) 19. [Wikipedia, 2013] Wikipedia: Headless system, http://en.wikipedia.org/wiki/ Headless_system (Stand vom 5. Juni 2013) 20. [Wikipedia, 2013] Wikipedia: Short Message Service, https://de.wikipedia.org/wiki/Short_

Connectivity Helps Telcos Offset Declining

Enterprise Apps Slideshow: Mobile

Traditional Services, http://www.forrester.

Application Development: A Top CIO

com/M2M+Connectivity+Helps+Telcos+Off

Priority, http://www.cioinsight.com/c/a/

natural interaction. Vortrag auf der Microsoft

set+Declining+Traditional+Services/fulltext/-

Enterprise-Apps/Mobile-Application-

Build Konferenz, Redmond USA, http://

/E-RES56893?docid=56893 (Stand vom 2.

Development-A-Top-CIO-Priority-895960/

channel9.msdn.com/Events/Build/2012/2–

Dezember 2011)

(Stand vom 18. Juli 2013)

007 (Stand vom 31. Oktober 2012)

Message_Service (Stand vom 12. Juli 2013) 21. [Wilson, 2012] Wilson, A.: Super-

91


Mobile User Experience Patterns Konsistente UX für Android, iOS und Windows Phone

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

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

Abstract Der vorliegende Beitrag zeigt, wie mit Hilfe eines Templates User Experience Patterns für Android, iOS und Windows Phone 8 erstellt wurden. Hierbei wurde ein methodisches Vorgehen angewendet, um existierende Interaktionspattern so zu erweitern, dass diese auch auf bestimmte User Experience Faktoren eingehen. Die erstellten Patterns wurden anschließend exemplarisch in Form von Interaktionskonzepten praktisch erprobt. Die Patterns ermöglichen die Erzeugung einer konsistenten User Experience über verschiedene Geräteklassen und Plattformen und können auch gerade dann angewendet werden, wenn eine bestehende App auf eine andere Plattform übertragen werden soll und dort ebenfalls eine native User Experience erzeugen soll.

Einleitung Es existieren in der Literatur sehr viele Ansätze zur Gestaltung von User Interfaces unter Verwendung von Interaction Design Patterns (siehe [1]-[7]). Diese beschränken sich in der Regel darauf, Gestaltungsrichtlinien für das Interaktionsdesign für eine bestimmte Plattform darzustellen. Daher können sie häufig nur eingesetzt werden, um eine Lösung für ein bestimmtes Problem einer bestimmten Plattform zu finden. Dies mag auch für Anwendungen genügen, die nur auf eine Plattform ausgerichtet sind. Sollen aber mehrere der momentan relevanten mobilen Plattformen (Android, iOS und Windows Phone 8) adressiert werden, bieten plattformspezifische Patterns keine konsistente plattformübergreifende Lösung. Viele der existierenden Ansätze gehen darüber hinaus nur sehr wenig oder gar nicht darauf ein, wie eine bestimmte, spezifische User Experience (UX) über verschiedene mobile Endgeräte hinweg erzeugt werden kann. Daher haben wir uns in unserer Arbeit das Ziel gesetzt, User Experience Pattern zu entwickeln, die es ermöglichen, für Android, iOS und Windows 8 Smartphones eine konsistente UX zu erzeugen. Dabei war es uns ein Anliegen, dass die Arbeiten auf bereits

92

existierenden Ansätzen aufbauen, sich jedoch darauf spezialisieren, wie eine spezifische UX im mobilen Umfeld über alle Plattformen hinweg erzeugt werden kann.

Abb. 1. Vorgehen zu Erstellung und Validation der UX Patterns

Keywords: /// User Experience /// Mobile /// Pattern /// Konsistenz /// Usability

Man könnte diese Fragestellung relativ pragmatisch lösen, indem man universelle User Interface Konzepte für alle Plattformen umsetzen würde. Beispielsweise


Usability Professionals 2013 Cross Plattform UX

könnte die App auf allen Plattformen das gleiche Interaktionskonzept/Design haben und die gleiche Experience bieten. Dies führt allerdings dazu, dass native Interaktionskonzepte und somit auch die native UX nicht auf allen Plattformen gewährleistet werden kann. Vielmehr wäre das Resultat eines solchen Ansatzes entweder eine Mischung aus verschiedenen plattformspezifischen Ansätzen oder ein Übertrag von Plattformspezifika auf eine fremde Plattform. Es ist jedoch zu erwarten, dass solche Mischkonzepte bei den Benutzern auf wenig Akzeptanz stoßen werden. Vielmehr bevorzugen Anwender native Interaktionskonzepte und native UX der eingesetzten Plattform. Unser Ansatz hat das Ziel, durch den Einsatz von Mobile User Experience Patterns UX Professionals zu unterstützen, eine native aber trotzdem konsistente UX über Android, iOS und Windows Phone 8 hinweg zu erzeugen. [Abb. 1]

Abb. 2. Mobile UX Pattern – Pattern Basics

Mobile User Experience Pattern Ansatz Abbildung 1 zeigt einen Überblick über das durchgeführte Vorgehen. Um einen Überblick zu erhalten, welche Patterns im Bereich mobiler Apps angewendet werden, haben wir existierende mobile Pattern Sammlungen analysiert (u.a. [8], [9]) und eine intensive Analyse der existieren User Interface Design Guidelines (siehe [10],[11],[12]) der angesprochenen Plattformen erstellt. Dabei wurde vor allem darauf geachtet, ob schon Pattern existieren, die nicht nur auf die Umsetzung einer bestimmten Interaktion (z.B. Darstellung und Interaktion mit einer Liste) fokussieren, sondern explizit auch die Erzeugung einer spezifischen UX (z.B. vertrauensvoller Login) in den Vordergrund stellen. Zusätzlich wurden zahlreiche Apps auf den verschiedenen Plattformen auf praktische Weise im Detail analysiert, indem die ver­­ wendeten Interaktionsparadigmen von mehr als 50 Apps durch Experten exploratorisch erforscht und miteinander verglichen wurden. Parallel wurde basierend auf existierenden Templates zur Beschreibung von UXPatterns [2] ein Template zur Beschreibung

der Mobile UX Pattern erstellt, welches auch die Grundlage für das im nächsten Kapitel folgende Beispiel bildete. Dieses Template dient dazu, eine einheitliche Beschreibung der Patterns zu haben und zu gewährleisten, dass alle notwendigen Punkte für die Umsetzung im mobilen Kontext adressiert sind. Die Beschreibung der Mobile UX Pattern ist in drei wesentliche Kategorien unterteilt: Pattern Basics, Pattern Experience und Pattern Example. Die Kategorie Pattern Basics enthält die grundlegenden Informationen, die für die Anwendung der Pattern notwendig sind. Der Bereich „Was“ enthält ein kurzes Statement darüber, was das Pattern bewirkt bzw. verbessert und unter welchen Bedingungen es anzuwenden ist. Hierbei soll dem Anwender schnell klar werden, welche Motivation hinter der Anwendung des jeweiligen Patterns steckt und ob dieses nützlich angewendet werden kann. Das „Wie“ konkretisiert das „Was“ mit Hilfe einer detaillierten Beschreibung der Aktionen des Benutzers und der zugehörigen Reaktionen der App. Außerdem sollten vor allem Besonderheiten, die bei der Gestaltung der Interaktion zu beachten

sind und zentrale Bestandteile der Interaktion (z.B. Animationen oder interaktive Elemente) hier zumindest in abstrakter Weise formuliert sein. Im Folgenden wird im Bereich „Wann“ erläutert, in welchen Situationen das Pattern angewendet werden sollte. Dies erleichtert vor allem auch das Mapping von Anwendungsfällen zu Pattern. Anschließend erfolgt im „Warum“ eine Begründung, warum das Pattern die zuvor beschriebene Wirkung auch erzielt. Dies können psychologische Begründungen aber auch ganz andere Gründe, die eher auf den Kontext in dem das Pattern genutzt werden soll eingehen. Abschließend werden noch die zugrundeliegenden Business Goals bzw. User Goals beschrieben, die vorhanden sein müssen, damit ein Einsatz des Patterns überhaupt Sinn hat. Dies ist insbesondere bei der Entwicklung von Geschäftssoftware sinn­ voll, da hier die beiden Zielkategorien durch die Software ideal verbunden wer­ den müssen. [Abb. 2] Der Bereich Pattern Experience geht nun sehr stark auf die intendierte UX des Patterns ein. Es wird dabei zunächst explizit beschrieben, welche UX-Faktoren durch

93


UX-Faktoren vorgenommen und eine Abschätzung gegeben, wie diese sich zur Umsetzung auf den verschiedenen Plattformen eignen. Diese Einschätzung wurde auf Basis von Expertenwissen durch Befragung von User Interface Designern der jeweiligen Plattform vorgenommen. Falls möglich wurde zusätzlich der Ursprung des Pattern angegeben (z.B. „das Pattern wurde erstmals in der iOS App von Facebook verwendet“). Das Pattern Template wurde entsprechend iterativ angepasst und wird auch künftig eine noch stärkere Fokussierung auf Aspekte des mobilen Interaktionsdesign erfahren. So ist beispielsweise die Mobile Checkliste einer ständigen Anpassung unterzogen und ändert sich dynamisch. Je nach Fokus der App-Entwicklung kann auch die Darstellung der Beispiele erweitert werden.

Abb. 3. Mobile UX Pattern Template – Pattern Experience

das Pattern adressiert werden können. Hierbei sollte auch eine kurze Erläuterung des Faktors erfolgen, so dass klar ist, was dieser Faktor bedeutet und wie dieser durch das Pattern erreicht wird. Außerdem sollte eine Begründung erfolgen, warum dieser Faktor im Kontext des Pat­ terns relevant ist. Der Bereich „Mobiler Kontext“ beschreibt nun explizit und ausführlich, in welchen Nutzungskontext das Pattern angewendet werden soll. Dabei wird geklärt, ob und in welcher Form das Pattern Kontextinformationen verwendet. Hierbei wird zwischen dem mobilen Kontext des Benutzers und dem mobilen Kontext des Gerätes unterschieden. Der Kontext des Benutzers gibt an, in welcher Situation er sich befindet wenn erwartungsgemäß das Pattern benutzt wird. Die Mentale Situation hat in der Regel einen starken Einfluss darauf, ob das Pattern verwendet werden kann und insbesondere darauf, wie das Pattern gestaltet sein muss. Der Kontext des Gerätes bezieht sich hingegen auf die Verwendung bzw. den Zustand von Sensoren im Gerät sowie auch Informationen von Gerät oder von Backend-Systemen, die relevant für das Pattern sind. Die „Mobile Checkliste“ unterstützt bei der Verwendung des Patterns und besteht

94

aus folgenden Kategorien: Plattformen bzw. Plattformunabhängigkeit, Gerätetyp, benötigter Grad an Aufmerksamkeit des Benutzers, Benutzbarkeit während der Bewegung, Benutzbarkeit mit einer Hand, Notwendigkeit nativer Implementierung und Notwendigkeit von Konnektivität. Das „Wo“ ist optional, falls das Pattern nur an einem bestimmten Ort (z.B. im Auto) ausgeführt werden kann. [Abb. 3] Das Pattern Beispiel zeigt die Verwendung des Patterns auf den Plattformen Android, iOS und Windows 8 in Form von Beispielen. Außerdem sollte eine allgemeine abstrakte Beschreibung der Interaktionsmechanismen hinzugefügt werden, die eine mögliche individuelle Anpassung des Patterns bei der Verwendung erleichtert.

Im folgenden Schritt wurden eine initiale Version der Pattern-Bibliothek für mobile UX Pattern mit 5 Pattern erstellt und exemplarisch in Form eines Interaktionskonzeptes der jeweiligen Plattformen umgesetzt. Hierzu wurde je ein konzeptioneller klickbarer Prototyp für die gleiche App erstellt, der für den Benutzer von einer finalen App nicht signifikant unterschieden werden kann. Das hier vorgestellte Pattern „Information Exploration“ soll den App-Anwender motivieren, den Inhalt einer bestimmten App zu erforschen. Abbildung 2 zeigt den Bereich der Pattern Basics und gibt einen guten Überblick über die Motivation für die Benutzung des Patterns. Abbildung 3 zeigt den Bereich Pattern Experience und Abbildung 4 zeigt schließlich die konkrete Ausprägung des Patterns auf den verschiedenen Plattformen.

Erstellung von Pattern Diskussion Bei der Erstellung der Patterns wurde ein starker Fokus darauf gelegt, in welchem Nutzungskontext die Interaktion stattfindet und wie konkrete Beispiele auf den jeweiligen Plattformen aussehen. Während der Erstellung der eigentlichen Patterns wurde außerdem eine Kategorisierung der Patterns bzgl. der adressierten

Die Erstellung und vor allem die Anwendung von mobilen User Experience Pattern erleichtern die konsistente App Entwicklung über verschiedene Plattformen und Geräteklassen hinweg. App Entwickler haben so die Möglichkeit, bewusst die gleiche UX über verschiedene Plattformen


Usability Professionals 2013 Cross Plattform UX

hinweg zu erzeugen oder aber auch eine bewusst unterschiedliche UX herzustellen. Während der Anwendung der Pattern durch verschiedene Interaktionsdesigner wurde festgestellt, dass vor allem dann, wenn die anwendende Person ggf. nicht in allen Betriebssystemen ein tiefes Hintergrundwissen hat, die Pattern bei der Interaktionsgestaltung in Hinblick auf Produktivität und Qualität des Ergebnisses unterstützen. Darüber hinaus bieten Mobile UX Pattern die Möglichkeit nicht nur eine generell positive UX zu erzeugen sondern eine spezifische aber trotzdem native UX (z.B. besonders vertrauensvolle Experience) über Plattformgrenzen hinweg zu erzeugen. Durch den Pattern Ansatz den wir gewählt haben fällt es UX Professionals zusätzlich einfacher, ein bestehendes Interaktionskonzept einer App auf eine andere Plattform zu übertragen. Die hier vorgestellten Mobile UX Pattern bieten zwar Unterstützung in der Generierung von spezifischer User Experience über die Grenzen heutiger mobiler Plattformen hinweg, sie können diese aber nicht garantieren. Einer der größten Einflussparameter auf die User Experience gerade im mobilen Umfeld liegt im Nutzungskontext der App. Zwar wird der Nutzungskontext im Patterntemplate berücksichtigt, es kann sich hierbei aber nur um eine Empfehlung handeln, in welchem Kontext das Pattern eingesetzt werden kann. Gerade bei mobilen Systemen ändert sich der Nutzungskontext häufig und ist nicht immer vorhersehbar. Somit kann während der Entwicklung von mobilen Systemen zwar ein gewisser Nutzungskontext angenommen werden, er lässt sich aber beim späteren Einsatz meist nicht vorschreiben. Daher kann es passieren, dass eine Anwendung innerhalb eines Nutzungskontextes verwendet wird, in dem das eingesetzte Pattern nicht die gewünschte UX erzeugen kann. Dies kann sogar dazu führen, dass durch den Einsatz des Patterns in einem nicht angemessenen Nutzungskontext eine negative User Experience beim Endanwender

Abb. 4. Exploration Pattern – Pattern Basics

erzeugt wird. Daher ist es wichtig, dass in späteren Iterationen des Patterntemplate noch stärker versucht wird, auf den Parameter Nutzungskontext einzugehen. Weitere künftige Arbeiten befassen sich mit der Erstellung weiterer Patterns und der Integration dieser Patterns in ein Tool, das den Interaktionsgestalter während

der Gestaltung der UX unterstützt. Dies kann entweder durch die Integration in ein Prototyping Tool oder aber auch durch die Erstellung einer App/Software zur Exploration der Patterns erfolgen. [Abb. 4], [Abb. 5], [Abb. 6]

95


Literatur 1. Neil, T.: Mobile Design Pattern Gallery. UI Patterns for iOS, Android, and More. O'Reilly Media, Inc., 2012. 2. Diefenbach, S., Klein, B., Klöckner, K., Schmitt, H., Bundesministerium für Bildung und Forschung (BMBF): Fun of use with natural interactions. Schlussbericht des Vorhabens, 2011. 3. Tidwell, J.: Designing Interfaces: Patterns for Effective Interaction Design, O’Reilly Media, Inc., 2009. 4. Nilsson, E.G.: Design Patterns for User Interface for Mobile Applications, Advances in Engineering Software, Volume 40, Issue 12, Pages 1318- 1328, Elsevier Science Ltd. Oxford, UK, 2009 5. Roth, J.: Patterns of Mobile Interaction, Personal and Ubiquitoues Computing, Volume 6, Issue 4, Pages 282–289, SpringerAbb. 5. Information Exploration – Pattern Experience

Verlag, London, UK, 2002 6. van Welie, M., van der Veer, G.C., Eliens, A.: Patterns as Tools for User Interface Design, International Workshop on Tools for Working with Guidelines, pp. 313–324, 7–8 October 2000, Biarritz, France 7. Tesoriero R., Gallud J.A., Lozano M.D., Penichet V.M.R: HCI Design Patterns for Mobile Applications Applied to Cultural Environments. International Chapter Book: Human-Computer Interaction, New Developments. I-Tech Publications. 2008. ISBN 978–953–7619–14–5. Pages: 257–287 8. http://pttrns.com/ letzter Zugriff 15.03.2013 9. http://www.mobile-patterns.com letzter Zugriff 15.03.2013 10. Google Android UI Guidelines: http:// developer.android.com/guide/practices/ ui_guidelines/index.html letzter Zugriff 15.03.2013 11. iOS human interface guidelines. http://developer.apple.com/library/ ios/#documentation/UserExperience/ Conceptual/MobileHIG/Introduction/ Introduction.html letzter Zugriff 15.03.2013 12. UI Design and Interaction Guide for

Abb.6. Information Exploration – Pattern Beispiele

Windows Phone http://dev.windowsphone. com/en-us/develop letzter Zugriff 15.03.2013

96


Inhouse und Zulieferer Kooperation

97


MMI, HCI, CHI and CAI – customer agency interaction Wer UX und Usability verkaufen will, muss dies auch im Pitch erlebbar machen Katja Busch katja.busch@web.de

Vicky Zander zander.vicky@gmail.com

Abstract Auf UX Kongressen geht es häufig um die besten UX Methoden und zukunftsweisende Bedienkonzepte, die damit erzielt werden. Viele Besucher freuen sich auf Erfahrungsaustausch mit Gleichgesinnten und Inspiration darüber, wie man den harten Alltag besser in den Griff bekommt. Dabei stellt man fest: Immer wieder scheinen tolle Ideen an Stakeholdern auf Kundenseite zu scheitern. Kunden-Bashing ist ein beliebtes Thema in den Kaffeepausen oder beim abendlichen Get Together. Man verlässt die Konferenz mit dem guten Gefühl, mit all seinen Projektproblemen wenigstens nicht alleine zu sein. Dabei wird oft vergessen: Wer Usability verkaufen will, muss diese beim Verkaufsgespräch und im Projekt selbst auch erlebbar machen. Genauso wie Firmen aus der Innensicht die Navigation für ihre Produkte gestalten, versuchen Usability Professionals oft voller Stolz ihre Methodenvielfalt anzupreisen. Alternativ könnten sie auch die Nutzerperspektive ihrer Auftraggeber einnehmen und eine Kommunikation anbieten, welche die User ihrer Services („Kunden“) vielleicht besser verstehen. Der Vortrag möchte für das eigene UX Interface zum Kunden sensibilisieren. Dazu werden Analogien aus dem Web Engineering mit den Erfahrungen aus diversen Pitches und Projekten aus Kundensicht gebildet.

Discover In der DIN EN ISO 9241–210 startet die Planung des menschlichen Gestaltungsprozesses damit, den Nutzungskontext zu verstehen und zu beschreiben. [Abb. 1] Klingt einfach. Die Erfahrung lehrt jedoch, dass genau wie manchmal mitten im Gestaltungsprozess die Spezifikation neu erfunden und die ein oder andere Anforderung aus pragmatischen Gründen vergessen wird. Genauso scheint es sich im Pitchkontext zu verhalten. Es beginnt mit dem Sichten und Verstehen der Ausschreibungsunterlagen, frei nach dem Motto „Wer lesen kann ist oftmals klar im Vorteil“. Im Idealfall hat sich ein potentieller Auftraggeber viel Arbeit mit seiner Ausschreibung gemacht und erwartet, dass diese auch aufmerksam gelesen wird. Das gilt auch für den Geschäftsführer oder die Sales Kollegen, die später mit in die Präsentation kommen. Fehlt

98

Abb. 1. Bild 1 aus DIN EN ISO 9241–10: Wechselseitige Abhängigkeit menschzentrierter Gestaltungsaktivitäten (http://blog.procontext. com/2010/03/)

Keywords: /// Usability-Methoden /// Pitch /// User Research /// Organisation /// Agentur /// Kunde /// Project Experience


Usability Professionals 2013 Inhouse & Zulieferer Kooperation

dieses Verständnis und finden sich diese Anforderungen in der Kommunikation während des Präsentationstermins nicht wieder, fühlt sich der Agenturauftritt für den Kunden an wie ein Suchergebnis, das eigentlich gar nicht zur Suchanfrage im entsprechenden Formular passt. Aus der Lektüre ergibt sich eine Reihe von Fragen: –– Für welchen Kontext soll gestaltet werden? –– Welche unternehmensinternen Ziel­ gruppen gilt es neben den Endkunden oder Nutzern anzusprechen und zu überzeugen? –– Wer hat die Pitchunterlagen geschrieben? –– In welcher Abteilung sitzen diese? –– Ist das Briefing klar strukturiert und auf den Punkt? Lassen sich aus einer ggf. mangelnden Struktur bereits Probleme heraus analysieren, die im späteren Projektverlauf gelöst werden müssen? –– Gibt es die Möglichkeit Interviews zu führen und Fragen zum Kontext zu stellen? –– Kennt man Leute, die einen der Stakeholder kennen oder zumindest selbst Mitarbeiter der Firma sind? –– Gibt es andere direkte Kontakte und dürfen diese zumindest für ein kurzes Telefonat genutzt werden? –– Welche Vorlieben, Erfahrungen und Ziele der Entscheider lassen sich aus Xing, LinkedIn oder Google ableiten? –– Wer gehört zum Verteiler der Pitch­ unterlagen und wird der Präsentation beiwohnen? Anhand der Analyse lässt sich ein Interviewleitfaden für das Pitchteam entwickeln, um ihren potentiellen Kunden und ihre Aufgabe besser zu verstehen: –– Welches Businessproblem gilt es zu lösen? –– Hat der Auftraggeber sein Problem verstanden oder möchte er nur eine App oder ein bisschen Social Media, weil es gerade in Mode ist? –– Wie hoch ist der digitale Reifegrad des Unternehmens – und der der Mitbewerber? –– Was steht zwischen den Zeilen?

–– Kämpfen vielleicht IT und Marketing um Innovationsführerschaft? –– Sind die Ziele und Business Requirements bereits klar definiert oder Teil der Ausschreibung? Dies kann sehr viel Auskunft sowohl über die richtige Fokussierung im Pitch als auch über die spätere Kommunikation und dem damit verbundenen Aufwand im Projekt geben. Genau wie Stellenausschreibungen sind auch Pitchunterlagen manchmal ein Wunschkonzert, das fernab der geplanten Budgets oder zeitlichen Vorstellungen liegen.

zu beschreiben und deren verschiedene Intentionen auf den Punkt zu bringen. Sie können aber auch helfen, eine Pitchpräsentation zu entwerfen, indem das Designer-, Entwickler- und Salesteam auf Agenturseite die Bedürfnisse dieser fiktiven Personen aufgreift und dementsprechend unterschiedliche „Bedienungsszenarien“ im „Kaufentscheidungsprozess“ durchspielt: –– Auf welche mentalen Modelle kann aufgebaut werden? –– Welche „Sprache“ versteht der Kunde?

Define: User Goals & Flows – Fast, Cheap, Great

So lässt sich zum Beispiel das magische Dreieck „Zeit, Kosten und Qualität“ aus dem Projektmanagement in „Fast, Cheap, Great“ für die Kundenperspektive übersetzen. [Abb. 2]

Nach der Kontextanalyse geht es im nächsten Schritt darum, die Nutzungsanfor­­ derungen zu spezifizieren. Personas dienen allgemein dazu, die wichtigsten Aufgaben typischer Vertreter einer Zielgruppe

Das Ziel dieser Phase der Anforderungsspezifikation sollte daraus bestehen, für die identifizierten internen Zielgruppen mithilfe der Personas die jeweiligen Interessensschwerpunkte und mentalen

Abb. 2. How Would You Like Your Graphic Design? (http://colinharman. com/how-would-youlike-your-graphicdesign/)

99


Modelle zu definieren. So setzen sich in komplexeren digitalen Projekten das PitchAuditorium und Entscheidungsgremium in Konzernen häufig aus Rollenvertretern mit folgenden beispielhaften Grundbedürfnissen zusammen (Ähnlichkeiten mit lebenden Personen und realen Handlungen sind rein zufällig). Marketing: – Fokus auf „Great“ – Interesse an: „Brand Experience“ & „Marke in Szene setzen“, bunte Bilder, Eye Candy – Kritische Fragen: Hat die Agentur die Marke verstanden? Helfen sie mir Awards zu gewinnen? Was können diese, was „meine“ Werbeagentur nicht kann? IT: – Fokus auf „Fast“ – Interesse an: Get it done, nicht zu viel Veränderung im „Technologiezoo“, gute Wartbarkeit – Kritische Fragen: Sprechen die auch Backend? Wie gestaltet sich die Zusammenarbeit während der Umsetzung? Verfügt der Dienstleister über die nötige Schnittstellenkompetenz? Mit welchen langfristigen technischen Aufwänden müssen wir rechnen (Total cost of ownership=TCO)?

Abb. 3. Abbildung 3: Die genormte Sicht auf Usability und User Experience (http://blog.procontext. com/2010/03/)

100

UX / E-Commerce / Online: – Fokus auf „Great“ – Interesse an: Methodenkoffer, Kreation von Mehrwert für den eigentlichen Endkunden im digitalen Kontext – Kritische Fragen: Erhalten wir Erfahrung und Hilfe beim Change Management? Wurden Zielgruppen und Briefing richtig verstanden? Einkauf: – Fokus auf „Cheap“ – Interesse an: Sicherheit, Vergleichskriterien zu anderen Dienstleistern – Kritische Fragen: Was sind die verhandelbaren Einheiten? Um welche Mengengerüste handelt es sich? Audit, externe Berater – Fokus auf „Fast, Cheap, Great“ – Interesse an: Vergleichbarkeit der eingeladenen Dienstleister – Kritische Fragen: Alles, was geht. Es muss bewiesen werden, dass der externe Berater sein Geld wert ist und kniffeligere Fragen an die Präsentatoren stellen kann, als sein Auftraggeber.

Je nach Auftragsschwerpunkt können noch eine Reihe von Fachabteilungen wie Corporate Communications, Produktmanagement, Sales, Service, CRM und bei

internationalen Konzernen auch Ländervertreter und andere mit im Boot sitzen, für die sich ebenfalls eine genauere Betrachtung lohnen kann. Allen Zielgruppen ist gemein: Sie wollen wissen, – ob der Dienstleister der richtige Partner ist, – wie sie mit diesem Partner effizient und effektiv zu Ihren Zielen kommen, – und ob sie sich vorstellen können, am Ende des Projektes glücklich und zufrieden zu sein. Der Experte Thomas Geis hat auf vergangen Mensch & Computer-Vorträgen die Unterschiede zwischen Usability und User Experience wie folgt anschaulich erklärt: „Usability“ betrachtet die tatsächliche Nutzungsituation selbst, während „User Experience“ darüber hinaus die antizipierte Nutzung und die Verarbeitung der Nutzungssituation nach der Nutzung mit einschließt. Im Sinne der User Experience geht es im Pitch also um den „anticipated use“ für die spätere Zusammenarbeit: [Abb. 3] Um besser antizipieren zu können, helfen Projekt- und Kundenreferenzen des Dienstleisters, die zeigen, dass dieser nicht nur weiß, wie man mit großen Marken zusammen arbeitet, sondern auch, wie in vergleichbaren Branchen und Aufgabenstellungen erfolgreich gearbeitet wurde. Folgendes sollte erkennbar sein: – Wo liegen bekannte Risiken bei vergleichbaren Vorhaben und wie wurden diese zielführend gemanaged? – Wie können typische „Probleme während der Nutzung“ à la Change Request vermieden werden? – Was wird getan, um diese Probleme zu lösen, sollten sie doch auftreten? Für die definierten Personas ergeben sich nicht nur unterschiedliche Interessenschwerpunkte und Ziele, sondern auch andere User Flows im Unternehmen. Wege der individuellen


Usability Professionals 2013 Inhouse & Zulieferer Kooperation

Entscheidungsfindung, sowohl im Pitch als auch für spätere Abnahmen und Freigaben, sehen oft für jede Zielgruppe unterschiedlich aus. In jedem dieser stereotypischen User Flows können zielgruppenspezifische Deliverables eine entscheidende Rolle spielen: Ein Marketingvertreter aus der „Klassik“ wird eher über Kreation angesprochen und braucht für seine Kollegen etwas emotional Ansprechendes zum Zeigen. Der Projektmanager erwartet hingegen Beispiele für eine transparente Planung und der Einkäufer fühlt sich in Rechenbeispielen einer „Total Cost of Ownership“-Betrachtung in seinem mentalen Modell abgeholt und wird damit zum potenziellen Fürsprecher. Wie bei digitalen Anwendungen kann die Gestaltung der Interaktion im Pitch mit ansprechenden Modulen das Sicherheitsund Vertrauensgefühl aufbauen. Spätestens zur Klärung der Frage nach einem geeigneten Projektvorgehen sollte man sich die existierenden Prozesse beim Kunden genauer anschauen. Insbesondere das Thema agile Softwareentwicklung stellt hier eine besondere Herausforderung dar und benötigt im Sales Prozess ein zielgruppenspezifisches „Skinning“. Agile Methoden verlangen bekanntlich „leider“ ebenso agile Kunden. Agilität erfordert ein hohes Maß an professioneller Kommunikationsfähigkeit – und zwar von allen Projektbeteiligten. Ist ein Unternehmen eher klassisch aufbauund ablauforientiert organisiert, erwartet es zunächst im mentalen Modell klassische Phasenmodelle mit Dokumentationen und Plänen („Das haben wir doch schon immer so gemacht!“). Build: Die Präsentation Für die Präsentation gilt es, neben der Be­­antwortung der gestellten Ausschreibungsaufgaben die in den vorangegangen Phasen gesammelten Informationen gezielt einzusetzen und somit die unterschiedlichen Stakeholder optimal anzusprechen. Im HCD-Prozess nach DIN EN ISO 9241 wäre nun der Schritt erreicht,

in dem Gestaltunglösungen entwickelt werden, welche die Nutzungsanforder­ ungen erfüllen. Neben den erstellten Unterlagen sollte der gesamte Auftritt vom ersten Klick bis zum letzten Handschlag durch Usability als Markenversprechen des Dienstleisters bestimmt sein. Die Grundsätze der Dialoggestaltung und die charakteristischen Eigenschaften dargestellter Information aus der DIN EN ISO 9241 können auch hier inspirieren: Aufgabenangemessenheit: –– Demonstration, dass die Aufgabe verstanden wurde: Weniger ist mehr und allgemeine Beratercharts langweilen. –– Genau wie bei der Gestaltung einer Website gehören überladene Präsen­ tation leider noch zum erlebten Präsentationsalltag: Welche Kompetenzen helfen dem Kunden, seine Aufgaben zu erledigen? –– Was ist bei den eingereichten Unterlagen wirklich relevant für die Zielgruppen und die Aufgabenstellung? Später werden die UX-Vertreter des Dienstleisters den Kunden davon überzeugen wollen, keinen sogenannten „Eh-da“ (also bereits im Unternehmen für andere Kontexte existierenden) Content auf die Website zu packen. Hier besteht die Chance, das Dienstleistungsversprechen erlebbar zu machen. Selbstbeschreibungsfähigkeit –– Dateinamen: Aus der Innensicht heraus neigen Dienstleister dazu „KundeDatum-Version-Final-Final-Kürzel“ als Dateinamen zu verwenden. Was hilft es jedoch dem Kunden, wenn er lauter Dateien mit seinem Namen auf der Festplatte im Pitchordner hat ohne den Absender auf einen Blick identifizieren zu können? –– Sprache: Werden Fachbegriffe erläutert, so dass sich jeder gut abgeholt fühlt und folgen kann? –– Wie können „verdauliche“ Visualisierungen helfen, das Gesagte erlebbar und verständlich zu machen?

–– The medium is the message: Was wird dem Kunden als Erinnerung zurück gelassen? Ein Booklet? Ein USB-Stick mit allen Unterlagen? Oder (zusätzlich) ein Zusammenfassung, mit der für die Beteiligten relevanten Fakten? Erwartungskonformität –– Es ist wichtig, herauszufinden, ob der Kunde sein Briefing selbst verstanden hat und es ernst meint. Wenn ja, kommen sollte der Dienstleister mit eigenen Ideen und Optimierungsvorschlägen erst später „um die Ecke“ kommen. Vorsicht gilt auch mit ungefragter Kritik an Bestehendem, auch wenn sie berechtigt ist. Solange nicht bekannt ist, wie die Standpunkte und Beziehungen der Anwesenden auf Kundenseite sind, kann dies zum Gesichtsverlust einzelner führen, die damit bestimmt nicht zum Fürsprecher für das Leistungsversprechen einer Agentur werden. –– Zeigen Sie Beispiele für Deliverables, wie die verschiedenen Anwendungsansichten auf einer Produktdetailseite. Wie kann die Zusammenarbeit angenehm gestaltet werden? Was bekomme der Kunde für sein Geld? Wie fühlt sich die Marke/die Agentur bei der Anwendung an? In unserem Fall als Mitarbeiter einer Heizungsfirma ließe sich das so beschreiben: Sucht der Kunde ein komplexes Heizsystem für den Neubau (neues CMS) oder nur ein Ersatzteil, weil was nicht so richtig funktioniert (mobile App) oder eine Bedienungsanleitung (Pilotprojekt oder Strategie zur Orchestrierung der verschiedeneren Dienstleister)? Lernförderlichkeit –– Strukturierte Deliverables: Wie auf einer Website gilt, dass Probleme mit der Navigation den Nutzer verwirren. In welchem Kapitel wird gerade präsentiert, über welche Anforderung wird gesprochen, was soll der Zuhörer als Kernaussage verstehen und sich merken? Welches Gefühl soll beim Kunden hinterlassen werden?

101


Steuerbarkeit –– Ist es deutlich spürbar, dass es sich um ein sympathisches, gut eingespieltes Präsentationteam handelt, das ein gemeinsames Ziel verfolgt und mit dem man gerne arbeiten möchte? Wer startet die Präsentation, wie werfen sich die Kollegen die Bälle zu? Kennt jeder seine Rolle und den richtigen Einsatz? –– Teilnehmer auf Augenhöhe mit dem Kunden können helfen, erste Beziehungen aufzubauen. Kunden wissen, dass sie die Sales Kollegen, Geschäftsführer und Bereichsleiter der Agentur bei der späteren Zusammenarbeit eher selten zu Gesicht bekommen werden. Ein Blick auf das „reale Interface“, also die Vertreter im Agenturteam, mit denen später operativ zusammengearbeitet wird, kann Zuversicht vermitteln, dass sich das Projekt mit allen Beteiligten steuern lässt. –– Wie wird mit Fragen umgegangen? Ehrlich, kompetent und hilfreich oder arrogant und ausweichend? Hat der Kunde das Gefühl, mit seinen Fragen und Anmerkungen den Dialog nach seinen Bedürfnissen steuern zu können? Fehlertoleranz –– Funktionieren der Beamer und das Präsentationsgerät? Wirklich? –– In welcher Sprache wird präsentiert, wenn Englisch bspw. die Projektsprache ist? –– Analog zu einem Bewerbungsgespräch ist der Dresscode vorher zu klären, um den gewünschten Eindruck zu hinterlassen. –– Eine positive Körpersprache gepaart mit einem authentischer Präsentationsstil und einem glaubhaften Einsatz mit Begeisterung sind viel wichtiger, als das Herunterspulen von Folien und Ergebnissen, auch wenn diese noch so gut & richtig sind. –– Vorsicht: Nicht erfüllbare Behauptungen funktionieren vielleicht kurzfristig, werden letztendlich aber zu Lasten der Agentur gehen, wenn Projektpläne und Designergebnisse nicht mit den

102

vereinbarten Vorgaben übereinstimmen. Top Entscheider, die bei der finalen Pitchpräsentation dabei waren, aber im operativen Projekt keine Berühungspunkte haben, werden sich immer (!) daran erinnern, was ihnen im Pitch versprochen wurde. Individualisierbarkeit –– Fast jeder größere Dienstleister verfügt irgendwann über sogenannte Sales Decks, die für die Neukundengewinnung wiederverwendet werden können. Die Individualisierung dieser Unterlagen auf den Kontext des Kun­ den ist im Vergleich zur Wirkung ein geringer Aufwand. Referenzen, die ähnlichen Problemen nennen oder Beispiele, die möglichst nah an der Industrie des Kunden liegen, sind für die mentalen Modelle der Kunden deutlich zugänglicher, als nur große Marken und Kreativawards. Besonders Kunden aus dem Mittelstand finden sich mit ihrer individuellen Situation und geringeren Budgets als große Retail- oder Telekommunikationsunternehmen nicht so ernst genommen und schnell als kleiner Kunde zweiter Klasse abgespeist. –– Es ist daher sehr wichtig zu demonstrieren, dass die Marke verstanden wurde und sich dies für den Kunden auch so anfühlt. Ein klitzekleiner Fehler, wie die Einbindung eines alten Logos kann hier die Befindlichkeit deutlich stören! –– Individuelle Fragen zum Kontext des Kunden, zur Meinung einzelner Teil­ neh­mer oder auch nach Feedback zu einzelnen Präsentationsteilen demonstrieren persönliches Interesse und vermitteln das Gefühl bei den Zuhörern, dass sich das Pitchteam ganz individuell mit den Anforderungen des Kunden auseinandergesetzt hat und nicht nur den Standardapproach von der Stange vorstellt.

Evolve In Anlehnung an Fußballweisheiten: Nach der Pitch Präsentation ist (im besten

Fall) vor der nächsten internen Runde. In diesem Fall sollten Sie die bereits gewonnenen Eindrücke und Informationen nutzen, um evtl. Schwachstellen zu beheben. Betrachten Sie die ersten Kontaktpunkte mit dem Kunden als Usability Tests und lassen Sie ihre Erkenntnisse in die nächsten Runden einfließen. –– Wie kann dem Auftraggeber geholfen werden, damit er das Projekt intern verkauft? –– Was sind die typischen User Scenarios nach der Pitch Präsentation? –– Welche Aufgaben müssen jetzt auf Kundenseite erledigt werden? –– Was hat gefallen und was ist nicht so gut angekommen? –– Was wird für interne Meetings noch benö­tigt? Was sind die wichtigsten Aus­ sagen und wie können diese dem Kunden mit auf den Weg gegeben werden? –– Die komplette 120-Seiten-­Präsentation wird sich im Nachgang keiner mehr an­­ sehen. Was sind also die „Quick Links“ zu den wichtigsten Informationen? –– Wer muss noch überzeugt werden und was wird dafür benötigt? –– Nach dem gewonnenen Pitch ist vor dem Projekt: Projekt-Usability hilft den Kunden zu verstehen und gemeinsam das Projekt erfolgreich zu machen. Hierzu können die Stakeholder-Personas nach und nach verfeinert werden, um bspw. wichtige Entscheidungen vorzubereiten. Es hilft wie im Usability Engineering mehr, zu verstehen, wie der Nutzer (also hier den Kunden im Projekt) entscheidet und interagiert, als auf ihn als „dummer Nutzer“ zu schimpfen. Wenn möglich, sollte über schon geknüpfte Kontakte Feedback zur Präsentation von internen Stakeholdern eingeholt werden, um evtl. Schwachstellen zu erkennen und an diesen für die weiteren Schritte zu arbeiten. Im Idealfall wird iterativ an der Schnittstelle Customer/Agency gearbeitet und die neu gewonnenen Informationen genutzt, um das Interface zwischen beiden an die sich permanent weiter entwickelnden Rahmenbedingungen anzupassen.


Usability Professionals 2013 Inhouse & Zulieferer Kooperation

Zusammenfassung: Kunden sind auch nur Menschen. Die Erkenntnis, dass Nutzer bestimmte men­ tale Modelle und Ziele zur Aufgabenerledigung haben, ist in UX-Fachkreisen inzwischen weit gereift. Obwohl sich vieles mit gesundem Menschenverstand an­gehen und in die Tat umsetzen lässt, soll dieser Beitrag die Augen über den fachlichen Tellerrand hinaus öffnen: UCD kann nicht nur als Methodenkoffer, sondern als Philo­ sophie der Zusammenarbeit verstanden werden. Mit dieser Einstellung lassen sich auf der beidseitigen Zusammenarbeit gemeinsam die erwünschten Schritte erzielen – und damit adäquate Rahmen­ bedingungen schaffen, bessere Interfaces für den Endnutzer zu gestalten. Grafiken/Quellen/Beispiele: 1. Bild 1 aus DIN EN ISO 9241–10: Wechselseitige Abhängigkeit menschzentrierter Gestaltungsaktivitäten: http://blog.procontext.com/2010/03/ 2. How Would You Like Your Graphic Design? http://colinharman.com/ how-would-you-like-your-graphic-design/ 3. Die genormte Sicht auf Usability und User Experience: http://blog.procontext. com/2010/03/

103


Customer-generated Prototypes Chancen und Herausforderungen von durch Kunden erstellte Prototypen für Usability Consultants Tim Schneidermeier small worlds GbR Bruderwöhrdstr. 15b 93055 Regensburg tim.schneidermeier@small-worlds.de

Markus Heckner Universität Regensburg, Lehrstuhl für Medieninformatik 93040 Regensburg markus.heckner@ur.de

Abstract Immer häufiger nimmt der Kunde in Usability Consulting-Projekten aktiv am Projektgeschehen teil: Bereits zu Projektbeginn wird dem Berater ein Prototyp des zu gestaltenden Systems präsentiert. Aus Kundensicht stellt dieser nicht selten das nahezu finale User-Interface-Konzept dar, an dem nur noch an einigen Ecken und Kanten gefeilt werden muss. Auf welchen Anforderungen der Prototyp basiert und wie diese erhoben wurden, ist im Regelfall nicht ersichtlich und wird bestenfalls partiell kommuniziert. Nichtsdestotrotz können vom Kunden erstellte Prototypen auch wichtige Informationen und Ansatzpunkte für den weiteren Gestaltungsprozess enthalten, die in das Projekt einfließen sollten. In diesem Beitrag werden konkrete Erfahrungen mit von Kunden erstellten Prototypen vorgestellt und deren Auswirkungen auf die Arbeit des Usability Professionals sowie auf den benutzerzentrierten Gestaltungsprozess diskutiert.

1. Ausgangslage Prototyping ist unserer Erfahrung nach eine der wichtigsten Aktivitäten im benutzerzentrierten Designprozess. Ideen möglicher Gestaltungslösungen für ein spezifisches Problem werden mit Hilfe von Prototyping bereits frühzeitig zu konkreten Artefakten. Diese dienen zum Beispiel als Testobjekt oder Kommunikationsmittel innerhalb des Teams. Während verbale Beschreibungen von Designkonzepten viel Raum für Missinterpretation bei Projektteam und Stakeholdern lassen und sich bei verschiedenen Beteiligten in verschiedene Richtungen entwickeln, bietet ein Prototyp eine konkrete und erlebbare Umsetzung der Idee. Prototyping kann deshalb Zeit, Aufwand und Geld sparen (vgl. Warfel 2009, p. 6f). Daher scheint es nicht verwunderlich, dass wir als Usability Consultants in zunehmenden Maße feststellen, dass sich nicht nur Usability Professionals oder User Interfaces Designer mit Prototyping beschäftigen, sondern dass das Konzept auch zunehmend bei unseren Kunden angekommen ist. Dies scheint mit dem allgemeinen Trend einherzugehen, dass Usability und User

104

Experience durch das steigende Bewusstsein für die Wichtigkeit einer einfachen und angenehmen Mensch-Maschine Schnittstelle immer stärker in den Fokus rücken. In vielen Projekten, in denen wir Anforderungen erheben und UI-Konzepte erstellen sollen, werden wir mittlerweile bereits zu Beginn mit einem vom Kunden selbst erstellten Prototypen begrüßt. Als Prototypen verstehen wir in diesem Zusammenhang unterschiedlich detailliert ausgearbeitete User Interface-Konzepte – vom statischen Wireframes bis hin zu interaktiven und klickbaren Dummys (erstellt z.B. mit Photoshop, PowerPoint, HTML oder auch spezialisierten Tools). Der Prototyp entstammt meist der Feder eines Entwicklers, eines Grafikdesigners oder von einem Mitarbeiter der entsprechenden Fachabteilung des Kunden. Im folgenden Erfahrungsbericht wollen wir unsere Erfahrungen mit von Kunden erstellten Prototypen, deren Eigenschaften, Vor- und Nachteile sowie Chancen und Herausforderungen, die sich für den eigenen Gestaltungsprozess als auch für den Projektverlauf insgesamt ergeben, diskutieren.

Keywords: /// Usability Engineering /// Prototyping /// Reengineering /// Unternehmenssoftware

2. Prototyping – Definition und Strategische Bedeutung Generell stellt ein Prototyp ein vereinfachtes Versuchsmodell eines geplanten Produkts oder Anwendung dar. Gleichzeitig ist Prototyping ein wesentlicher und unbedingt notwendiger Schritt im benutzerzentrierten Entwicklungsprozess. Auf vielschichtige Art und Weise unterstützen Prototypen den Gestaltungsprozess und helfen unterschiedliche Ziele zu erreichen (vgl. Warfel 2009, p. 2ff): –– Kommunikation eines Designkon­ zepts – Prototypen setzen Ideen in konkrete Artefakte um. Diese können genutzt werden, um ­unterschiedliche Gestaltungsideen erlebbar zu machen und verhindern so Miss­­interpretationen. –– Testen von Designkonzepten – Iteratives Design setzt auf häufiges und frühzeitiges Testen. So können mit Hilfe von prototypisch umgesetzten Designkonzepten bereits zu einem frühen Zeitpunkt im Gestaltungsprozess erste (Nutzer-) Tests durchgeführt und das Feedback


Usability Professionals 2013 Inhouse & Zulieferer Kooperation

unmittelbar wieder eingearbeitet werden (vgl. Krug 2010, p.43f). –– Treffen von Designentscheidungen – Auf Basis von Testergebnissen können fundierte Entscheidungen für oder wider ein Designkonzept getroffen werden. –– Prototyping als Lernprozess für das Design- und Entwicklerteam – Ein erster Prototyp stellt niemals das fertige Produkt dar – Scheitern ist Teil des Prozess. Designkonzepte werden im Laufe des Gestaltungsprozesses durch wiederholtes Feedback stets verfeinert und verbessert. –– Prototyping senkt Entwicklungs­ kosten – Die Entwicklung (Coding) der tatsächlichen Anwendung erfolgt im Optimalfall erst nachdem der Prototyp mehrmals getestet und so stets verbessert wurde. Änderungen im Prototypen können schnell und zeiteffizient durchgeführt werden – Änderung im bestehenden Quellcode verlangen ein Vielfaches an Aufwand: „For every dollar spent to resolve a problem during product design, $10 would be spent on the same problem during development and $100 or more if the problem had to be solved after the product‘s release.“ (IBM 2008)

–– Prototyping erhöht Kundenzufrieden­ heit – Durch das stete und wieder­ holte Einbeziehen der Nutzer bereits in frühen Phasen des Gestaltungs­ prozesses sinkt das Risiko an den Nutzeranforderungen „vorbei“ zu entwickeln. [Abb. 1] Prototyping als wichtiger Schritt im Gestaltungsprozess kann abhängig vom Fortschritt in der Projektphase in Low Fidelity und High Fidelity unterteilt werden (vgl. Abbildung 1). Unterschiedliche Methoden und Werkzeuge unterstützen die Gestalter in der Entwicklung der Prototypen: Je nach Stadium verfolgen Prototypen unterschiedliche Zielsetzungen: Im Sketching werden erste Ideen generiert und aufs Papier gebracht. Vielversprechende (statische) Wireframes werden weiter ausgearbeitet, getestet und können schließlich mit Hilfe spezialisierter Werkzeuge (z.B. Axure¹) in interaktive High Fidelity Prototypen ausgearbeitet und erneut getestet werden. 3. Vom Kunden erstellte Protototypen – Problemstellung und Rahmenbedingungen

Der übliche Ablauf bei Software (Re-) Design Projekten von small worlds entspricht dem benutzerzentrierten Designprozess nach DIN EN ISO 9241–210 (2010): Zunächst werden Anforderungen erhoben und spezifiziert. Auf deren Basis werden mit geeigneten Methoden unterschiedliche Designvorschläge und User InterfaceKonzepte entwickelt und im Team sowie mit den Auftraggebern diskutiert. Die Erkenntnisse von Usability-Tests mit repräsentativen Nutzern werden eingearbeitet und das Design so in mehreren Iterationen verbessert. Dieses „traditionelle“ Modell des Usability Engineering wird aus unserer Erfahrung immer häufiger um einen vom Kunden erstellten Prototyp ergänzt. Dieser zeigt bereits zu Projektbeginn eine aus Kundensicht mögliche Marschrichtung für das neue Konzept auf. Trotz natürlicher Heterogenität bei den von Kunden erstellten Prototypen können wir folgende Gemeinsamkeiten identifizieren: –– Blinde Flecken – Der Prototyp bildet einen gewissen Teilbereich der zu entwerfenden Software ab, klammert dabei aber bestimmte Bereiche aus, d.h. er verzichtet an wichtigen Stellen auf notwendige Details bzw. Teilschritte. Diese blinden Flecken

Abb. 1. Low Fidelity Prototyp auf Papier (links) und interaktiver High Fidelity Prototyp (rechts).

105


werden vom Kunden häufig als „nicht so wichtig“ abgetan oder einfach vergessen. Häufigster Grund dafür ist, dass das Konzept nicht komplett zu Ende gedacht wurde. Aus unserer Sicht stellen gerade diese blinden Flecken mitunter aber essentielle Designfragen mit hoher Komplexität dar. –– Komplexität der Gestaltung des UI wird von Kunden und Usability Consultants unterschiedlich eingeschätzt – Auch die Komplexität der durch die blinden Flecken nicht abgebildeten Funktionalitäten bzw. Interaktionsprobleme wird grundlegend anders eingeschätzt. Häufig werden Aussagen getroffen wie „Achso, klar, das fehlt, aber diese Funktion noch mitaufzunehmen sollte ja kein Problem mehr sein“. Gerade hier verstecken sich häufig die schwierigen Fragestellungen für das Projekt. –– Interaktion ja, aber mit Tendenz zum statischen Design Mock-Up – In den meisten Fällen werden so genannte narrative Prototypen (vgl. Warfel

Abb. 2. Vom Kunden erstellter Prototyp für das Kundenportal eines Telekommunikationsdienstleisters.

106

2009) vom Kunden erstellt, d.h. die Prototypen bestehen aus einzelnen Screens (meist mit PowerPoint oder Photoshop erstellt), die mit Microsoft PowerPoint oder mittels eines HTMLKlickdummies hintereinander geschaltet werden um so die Übergänge zwischen den einzelnen Screens zu simulieren. Die Interaktion wird so nur rudimentär und oberflächlich umgesetzt. Fragen zu Verhaltensweisen an zahlreichen mitunter essentiellen Stellen („Was soll passieren, wenn ich diesen Button klicke?“) bleiben zumeist ungeklärt. Zudem sind aussagekräftige UsabilityTests mit solch narrativen Prototypen und ihrer stark eingeschränkten Interaktion kaum umsetzbar. –– Im Prototyp umgesetzte Anforder­ ungen – In den meisten Fällen ist nicht klar ersichtlich auf welchen Anforderungen die Prototypen aufbauen: Der Kunde steigt direkt in die Designphase ein und über­springt die essentiellen Tätigkeiten einer nutzerzentrierten

Anforderungserhebung. Die Prototypen basieren so häufig auf Annahmen und „gefühlten“ Anforderungen. –– Auch Prototyping will gelernt sein – Der Fokus bei der Erstellung eines Prototypen sollte im Regelfall darauf beruhen Schlüsselaufgaben des zu gestaltenden Systems, die aus der zuvor durchgeführten Anforderungserhebung hervorgehen, umzusetzen, diese zu testen und so iterativ zu verbessern. Prototyping ist nur effizient, wenn das Notwendige vom Optionalen getrennt wird: Es sollte nur die Funktionalität umgesetzt werden, die für das erfolgreiche Erledigen der zu testenden Aufgabe relevant ist. Auch eine zu starke Konzentration auf das visuelle Design senkt die Effizienz. –– Beginn beim Problem, nicht beim Design – Prototypen sind nur Mittel zum Zweck: Sie erlauben es Lösungs­ strategien für Problem­stellungen in konkrete Artefakte umzusetzen. Erfolgreiches Prototyping beginnt aus unserer Erfahrung immer auf dem


Usability Professionals 2013 Inhouse & Zulieferer Kooperation

Papier. Wer unmittelbar mit dem „Design“ in einem Software-Tool beginnt (Photoshop, PowerPoint, etc.), läuft Gefahr den Fokus auf das Problem zu verlieren und sich zu sehr auf „Kleinigkeiten“ zu konzentrieren (Farbverläufe, detaillierte Icons, etc.). 4. Fallstudie: Vom Kunden erstellte Prototypen im Gestaltungs- und Reengineering Prozess Im folgenden Abschnitt sollen anhand zweier Projekte Eigenschaften, Gemeinsamkeiten und Unterschiede von vom Kunden erstellten Prototypen aufgezeigt werden. Zielsetzung beider Projekte war es auf Basis eines bereits vorhanden Systems – ein Webportal für Kunden eines Telekommunikationsdienstleisters (vgl. Abbildung 2) und eine bestehende unternehmensinterne Software (u.a. zur Verwaltung und Erstellung von Anschreiben)² – mit Hilfe eines nutzerzentrierten Redesign eine Verbesserung der Usability anzustreben. [Abb. 2] Zu Beginn der Projekte erhielten wir zusätzlich zu den allgemeinen Anforderungsdokumenten einen jeweils vom Auftraggeber vorab erstellten Prototypen als Ausgangspunkt für das Redesign der Produkte. Die Prototypen unterschieden sich vor allem in Zielsetzung und Ausarbeitung des visuellen Designs. Im Fall des Webportals sollte der Prototyp „nur noch auf Usability geprüft werden“, für die unternehmensinterne Software „könnte der Prototyp eine Marschrichtung vorgeben“. Tabelle 1 zeigt Unterschiede und Gemeinsamkeiten

Tab. 1. Charakteristika der vom Kunden erstellen Prototypen.

hinsichtlich Zielsetzung, Fidelity und Interaktivität der Prototypen. [Tab. 1] 5. Auswirkungen eines kunden­ generierten Prototyps auf die Arbeit von Usability Professionals Vom Kunden erstellte Prototypen haben unterschiedliche Auswirkungen auf die Arbeit von Usability Professionals: Zum einen werden Ziel und Funktion von Prototypen häufig unterschiedlich wahrgenommen (funktionale und interaktionsbezogene Ebene), zum anderen lassen sich auch Implikationen für die Kommunikation mit dem Kunden (persönliche Ebene) für den Projektverlauf feststellen. Funktionale Ebene – Unterschiedliche Wahrnehmung von Ziel und Funktion eines Prototypen Für den Kunden stellt der Prototyp häufig ein Dokument dar, mit dem er Anforderungen spezifizieren kann. Der Prototyp ergänzt weitere Dokumente, wie Lastenoder Pflichtenhefte. Häufig ist nicht klar ersichtlich, auf der Basis welcher Anforderungen die Prototypen entstehen bzw. ob im Sinne eines nutzerzentrieren Ansatzes überhaupt Anforderungen erhoben wurden. Vielmehr entsteht der Eindruck, dass es sich oftmals um subjektive Anforderungen und Umsetzungen des Erstellers des Prototypen handelt. Nichtsdestotrotz können vom Kunden erstellte Prototypen auch wichtige Informationen und Ansatzpunkte für den weiteren Gestaltungsprozess enthalten, die nicht per se unberücksichtigt bleiben sollten.

Prototyping als Tool für den Usability Professional dient dagegen als Werkzeug, um systematisch vom Benutzer erhobene Anforderungen in Gestaltungslösungen umzusetzen. Dies geschieht vom Sketching bis hin zum interaktiven Prototypen, der wiederholt getestet und verbessert wird. Ein erster Prototyp stellt dabei nie die endgültige Lösung dar, viel mehr sind Scheitern und Überarbeiten wichtiger Teil des Prozesses. Für den Kunden ist sein Prototyp in der Regel eine bereits fast fertige und nur noch im Detail zu überprüfende Lösung, bei der eventuell noch hier und da Kleinigkeiten geändert werden könnten (da kommen wir dann ins Spiel), das erstellte Interaktions- und Informationskonzept (falls vorhanden) wird jedoch nicht mehr hinterfragt. Während die Beziehung zum Prototypen beim Kunden eine sehr persönliche ist („eigenes Baby“, eigene kreative Leistung), stellt der Prototyp für den Usability Professional nur ein dynamisches, sich stets veränderndes Konstrukt dar, welches nur ein erster Schritt auf dem Weg zum neuen System ist: Der Usability Professional hat gelernt sich „emotional“ vom Prototyp zu distanzieren. Persönliche Ebene – Kommunikation mit dem Kunden Der Kunde neigt häufig dazu, den von ihm selbst erstellten Prototyp mit seinen Fähigkeiten als guter Gestalter gleichzusetzen, d.h. er pflegt eine sehr enge, teils emotionale Beziehung zu ihm. Berechtigte Kritik am Prototyp – egal ob vom Usability Professional oder tatsächlichen Nutzern

Webportal

Unternehmensinterne Software

Zielsetzung

Auf Usability testen, Änderungen einarbeiten, dann soll die Umsetzung analog dem finalen Prototypen erfolgen

Vorgabe einer möglichen Marschrichtung für das Redesign der Software

Fidelity

In Photoshop erstellter, visuell aufwendig aufbereiteter Prototyp à realistisches Look and Feel

In PowerPoint erstellter, funktionaler Prototyp (ohne aufwendigeres visuelles Design) à prototypische Anmutung

Interaktivität

Klickbarar, narrativer Prototyp

Klickbarar, narrativer Prototyp

107


(z.B. aus Fokusgruppen oder Nutzertests) – wird häufig persönlich genommen und als direkter Angriff gewertet. Bei vom Kunden als besonders wichtig eingestuften Features im Prototypen können daher auch Ressentiments und hohe BehaltensKräfte auftreten – trotz eindeutiger und berechtigter Anmerkungen („Ich hab das jetzt doch so drin gelassen“). Für den Usability Consultant hat dies zur Folge, dass man möglichst sensibel mit dem Kunden umgehen sollte, um das Verhältnis nicht zu beschädigen. Bei positiver Kritik und Lob hingegen fühlt der Kunde sich und seinen Prototyp bestätigt. Insgesamt stellt dies auf der persönlichen Ebene eine große Herausforderung dar, bei der die Stimmung schnell in die ein oder andere Richtung schwanken kann.

Abb. 3. Benutzerzentrierter Design-Prozess (eigene Darstellung nach DIN EN ISO 9241–210 2010).

108

6. Der vom Kunden erstellte Prototyp im benutzerzentrieren Design-Prozess Der vom Kunden erstellte Prototyp hat Auswirkungen unterschiedlicher Tragweite auf die verschiedenen Phasen des benutzerzentrierten Designprozesses (vgl. DIN EN ISO 9241–210 2010, siehe auch Abbildung 3). Im Folgenden sollen Bedeutung und Effekte für die Arbeit von Usability Professionals aufgezeigt und diskutiert werden. [Abb. 3] Planen des menschzentrierten Gestaltungsprozesses Bereits in der Planungsphase muss der vom Kunden erstellte Prototyp mitberücksichtigt

werden. Gerade bei Software Re-DesignProjekten bedeutet ein zusätzlicher Prototyp, dass die Einarbeitung in zwei Systeme erfolgen muss (Prototyp und abzulösendes System). Dementsprechend sind Ressourcen einzuplanen – entgegen der auch beim Kunden anzutreffenden Vermutung wird das Projekt durch den Kundenprototyp nicht zwangsweise weniger komplex oder umfangreich. Verstehen und Festlegen des Nutzungskontexts Die Erhebung des Nutzungskontexts und der angestrebten Zielgruppe erfolgt in der Regel beim Kunden vor Ort. Typischerweise können Methoden wie Wettbewerbsanalyse, Contextual Inquiry oder


Usability Professionals 2013 Inhouse & Zulieferer Kooperation

Fokusgruppen eingesetzt werden. Bei Reengineering-Projekten erhöht der vom Kunden erstellte Prototyp zunächst den Arbeitsaufwand, da man sich in zwei Systeme mit gleichen Zielen einarbeiten und verstehen muss. Auf der anderen Seite hat sich der Einsatz des Prototyps in Diskussionsrunden oder Fokusgruppen als brauchbares Werkzeug erwiesen. Dieser kann hier als Kommunikationsmittel bzw. bereites konkretes Artefakt für die Ziele mit dem überarbeiteten System eingesetzt werden und dient so als gemeinsame Sprache. Spezifizieren der Nutzeranforderungen Auch bei der Spezifizierung der Anforderungen erhöht der Prototyp zunächst den Arbeitsaufwand. Die in der vorherigen Phase erhobenen Anforderungen werden aufbereitet, ausgewertet und priorisiert. Da bereits ein bestehender Prototyp vorhanden ist, muss dieser zunächst gegen die erhobenen und spezifizierten Anforderungen abgeglichen werden. Zudem wird hier eine erste Entscheidung gefällt, was und wie viel von dem Prototypen weiter im Prozess (Gestaltungslösungen) verwendet werden kann. Dafür muss der Prototyp zunächst evaluiert werden. Da die wenigsten von Kunden erstellten Prototypen soweit ausgearbeitet sind, dass sie ad hoc mit Hilfe von Nutzern getestet werden können bietet sich zunächst eine Expertenevaluation an. Hier müssen insbesondere auch Normen und (plattformspezifische) Guidelines als Evaluationswerkzeug verwendet werden, da der Kunde meist nicht über genügend Usability-Knowhow verfügt, wichtige Standards bereits beim Erstellen des Prototypen mitzuberücksichtigen. Ziel in dieser Phase ist es zu überprüfen, ob der bestehende Prototyp als Basis für das weitere Vorgehen taugt bzw. welche Teile übernommen werden können. Erarbeitung von Gestaltungs­ lösungen zur Erfüllung der Nutzungsanforderungen Obwohl bereits ein Prototyp vorhanden ist, sollte beim Design „von vorne“ begonnen werden: Sketching bietet sich hier als erste Designaktivität an. Die intensive

Beschäftigung mit dem vom Kunden erstellten Prototypen stellt eine Herausforderung für die Erarbeitung von Gestaltungslösungen dar, da der Designraum bereits vorgeprägt ist. Hier bietet es sich deshalb an, einen Mitarbeiter mit in die Gestaltung einzubeziehen der bisher den Prototypen noch nicht zu Gesicht bekommen hat. Gerade beim Sketching geht es darum, viele unterschiedliche Gestaltungslösungen für die erhobenen Anforderungen umzusetzen, diese schnell zu testen und zu verbessern. Der Prototyp vom Kunden sollte auf keinen Fall den Designraum a priori einschränken. Nach unserer Erfahrung ist es schwer sich vollständig vom Prototyp zu lösen. Für uns bleibt aber die Frage, ob dies ein Problem darstellt, wenn Kunden und Nutzer am Ende mit dem Konzept zufrieden sind.

beobachtete Vorgehen die Frage auf, wie viel Aufwand der Kunde in die Erstellung des Prototypen steckt. Auf der Basis unserer Erfahrungen wäre es meist effizienter, effektiver und billiger für den Kunden, das Prototyping den Usability Professionals zu überlassen. Besteht erst mal eine persönliche Beziehung, lässt sich der Kunde zudem kaum oder nur schwer von der teils parallel geführten Weiterentwicklung abbringen. Literatur 1. DIN EN ISO 9241–210 (2010). Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme. Beuth Verlag GmbH. 2. IBM (2008). User-Centered Design. Cost justifying ease of use. (http://www-01.ibm. com/software/ucd/ucd.html [Zugriff 06/ 2013]). 3. Krug, S. (2010). Rocket surgery made easy. The do-it-yourself guide to finding and fixing

Evaluieren der Gestaltungslösungen anhand der Anforderungen

usability. 4. Warfel, T. Z. (2009). Prototyping: A Practitioner’s Guide. Rosenfeld Media.

In der Designphase wird ein eigener Prototyp erstellt. Die Evaluation findet anhand von Nutzertests mit diesem statt. Der vom Kunden erstellte Prototyp wird nicht mehr benötigt und hat keinerlei Auswirkungen mehr.

¹ http://www.axure.com ² Leider können wir aufgrund rechtlicher Bestimmungen an dieser Stelle keinen Screenshot des Prototypen der unternehmensinternen Software

7. Fazit und Lessons Learned

veröffentlichen.

Ein vom Kunden erstellter Prototyp im Entwicklungsprozess ist ein zweischneidiges Schwert: Zum einen erhöht der Prototyp zunächst den Einarbeitungsaufwand während der Analysephase des Usability Consultings, zum anderen lässt sich der Prototyp auch als low hanging fruit ansehen, d.h. die bereits vom Kunden in die Erstellung gesteckte Arbeit sollte prinzipiell nicht grundlos verworfen werden. Jedoch müssen stets die Anforderungen, auf denen der Prototyp basiert, hinterfragt werden. Grundsätzlich gilt aus unserer Sicht, dass der Usability Consultant einen Schritt im Entwicklungszyklus zurück gehen sollte, um Anforderungen mit geeigneter Methodik selbst zu erheben und zu spezifizieren. Hier kann der vom Kunden erstellte Prototyp als ein Tool in der Analysephase verwendet werden. Zudem wirft das

109


„Wir kaufen Usability ein“ –  Eine nutzerzentrierte Sichtweise Bedürfnisse eines Auftraggebers im Rahmen der Zusammenarbeit mit einem Usability-Dienstleister Dr. Markus Weber Centigrade GmbH Science Park 2 66123 Saarbrücken markus.weber@centigrade.de

Sandra Köpf Exact Software Deutschland GmbH Karl-Hammerschmidt-Straße 40 85609 München-Dornach sandra.koepf@exact.com

Abstract Häufig wird Usability als externe Dienstleistung „eingekauft“. Der Beitrag beleuchtet die „Nutzersicht“ bei der Zusammenarbeit zwischen einem Auftraggeber und einem Usability-Dienstleister, indem Bedürfnisse des Auftraggebers über den Verlauf eines Projekts dargestellt und in ihrer Relevanz erläutert werden. Für die Betrachtung werden die vier Bedürfnisse Interesse, Motivation, Bestätigung und Nachhaltigkeit vorgeschlagen. Anhand von Best Practices und Handlungsempfehlungen wird illustriert, auf welche Weise der Dienstleister den Bedürfnissen des Auftraggebers gerecht werden und auf diese Weise zu einem erfolgreichen Projektverlauf beitragen kann.

1. Einleitung Viele Usability Professionals sind als externe Dienstleister tätig, die von Auftraggebern hinzugezogen werden, wenn diese ein Usability-Projekt durchführen möchten. Insbesondere in größeren Projekten tragen sowohl Auftraggeber wie auch Dienstleister im Rahmen einer aktiven Kooperation zum Projektergebnis bei, wobei auf beiden Seiten mehr oder weniger große Projektteams gebildet werden. Die Konstellation geht also häufig über ein schlichtes „Outsourcing“ von Arbeiten an den Dienstleister hinaus. Vor dem Hintergrund eines Projekts, das in einer solchen Konstellation mit mehreren Beteiligten auf beiden Seiten durchgeführt wurde, wird im Folgenden eine „nutzerzentrierte“ Sicht auf den Kooperationsprozess eingenommen: Es geht also um die Perspektive des Auftraggebers, der Usability Dienstleistungen in Anspruch nimmt. Hierzu wird eine Unterscheidung von vier Bedürfnissen vorgeschlagen, die jeweils in unterschiedlichen Phasen des Kooperationsprozesses von besonderer Relevanz sind: Interesse, Motivation, Bestätigung und Nachhaltigkeit. Ist der Dienstleister für diese Bedürfnisse sensibilisiert, so bieten sich verschiedenste Möglichkeiten, diesen

110

zu entsprechen, was im Folgenden jeweils durch Best Practices und Handlungsempfehlungen illustriert wird. 2. Interesse am Dienstleister Gerade bei größeren Projekten ist es üblich, dass Auftraggeber im Vorfeld Kontakt mit mehreren potenziellen Dienstleistern aufnehmen, um schließlich eine informierte Auswahl treffen zu können. Da zu diesem Zeitpunkt häufig noch keine Erfahrungen bezüglich der Zusammenarbeit der beiden Partien existieren, muss der Auftraggeber auf andere Entscheidungskriterien zurückgreifen, um zu einem ersten Urteil zu kommen. Der Dienstleister muss das Interesse des Auftraggebers wecken und einen glaubhaften Eindruck davon vermitteln, dass er ein geeigneter Partner für eine auf längere Sicht angelegte Zusammenarbeit ist. 2.1. Einblicke in reale Projekterfahrung Beim ersten Kontakt mit dem Auftraggeber bzw. mit dem zukünftigen Projektteam kann es sich positiv auf das Interesse am Dienstleister auswirken, wenn dieser „aus dem Nähkästchen“ realer Projekterfahrung

Keywords: /// User Interface Design /// Usability Engineering /// Kooperation /// Dienstleister /// Auftraggeber

plaudert. Dies ist für den Auftraggeber insbesondere im Bezug auf Projektaspekte interessant, die nicht nach Lehrbuch verlaufen sind und bei denen auf kreative Art und Weise auf nicht vorhersehbare Probleme reagiert werden musste. Um dies fundiert und glaubwürdig tun zu können, sollte die Präsentation des Dienstleisters von Personen mit realer Projekterfahrung durchgeführt werden, anstatt reine Vertriebsmitarbeiter einzusetzen, die an der Durchführung von Projekten nicht beteiligt sind. 2.2. Lösungs-Highlights Derartige Einblicke in die Praxis des Dienstleisters können durch die fokussierte Darstellung von „Lösungs-Highlights“ ergänzt werden. Diese vermitteln dem Auftraggeber ein anschauliches Bild von Ergebnissen, die der Dienstleister in vergangenen Projekten erzielt hat. Um den optimalen Effekt entfalten zu können, sollten diese Beispiele für den Auftraggeber ohne umfassende Kontextinformationen aus dem betreffenden Projekt zu verstehen sein. Es kann sich beispielsweise um eine ästhetisch/emotional ansprechende Animation handeln, die in einem User Interface zum Einsatz kommt, und die beim Auftraggeber die Reaktion „So was hätten wir auch gerne“ hervorruft,


Usability Professionals 2013 Inhouse & Zulieferer Kooperation

auch ohne dass dieser die konkret im Beispiel dargestellten Inhalte verstehen muss. Dies kann auch hilfreich sein, um das Interesse von Personen zu gewinnen, die im Bereich Usability wenig Erfahrung und Hintergrundwissen besitzen und deren Wunsch an ein User Interface Design Projekt nicht zuletzt darin besteht, etwas zu gestalten, was „schick aussieht“ beziehungsweise das anders und neuartig ist. 2.3. Eingehen auf ein heterogenes Publikum Oft ist das Publikum, auf das der Dienstleister im Rahmen einer initialen Präsentation trifft, sehr heterogen. So müssen beispielsweise Entwickler, Produktmanager, Marketing und Vertreter des Projektmanagements angesprochen und einbezogen werden. In einem solchen Kontext muss der Dienstleister also unter anderem die unterschiedlichen Anforderungen und Wissensstände der Teilnehmer hinsichtlich der Durchführung von User Interface Design Projekten berücksichtigen. So ist zum Beispiel die Management-Ebene oft weniger an den Design-Prozessen interessiert, sondern an Aufwänden, Kosten und der pünktlichen Lieferung von Ergebnissen. Das engere (zukünftige) Projektteam dagegen hat unter anderem ein Interesse daran, dass die dargestellten Prozesse vom Dienstleister nicht starr vorgegeben werden, sondern sich gut innerhalb des Organisationskontexts einsetzen beziehungsweise auf diesen anpassen lassen. Der Dienstleister sollte die Fähigkeit haben, die unterschiedlichen Anforderungen und Erwartungen im Rahmen einer Präsentationssituation schnell erkennen zu können, um sich entsprechend darauf einzustellen. Dies kann es auch erforderlich machen, einen zuvor geplanten Präsentationsablauf situativ anzupassen. 2.4. Hinterfragen und Klären von Zielsetzungen Im Zuge des ersten Kontakts mit dem Auftraggeber kann es sich auch positiv auf dessen Interesse auswirken, wenn der Dienstleister Zielsetzungen kritisch

hinterfragt. Aufbauend auf zum Beispiel der Projektausschreibung kann der Dienstleister seine Interpretation rückmelden („Rebriefing“) und diese vor dem Hintergrund seiner Expertise kommentieren. Dies kann insbesondere dann wertvoll sein, wenn bestimmte vom Auftraggeber explizit formulierten Ziele eventuell gar nicht oder nur bedingt im Dienste seiner grundlegenden Anforderungen stehen. Der Dienstleister kann in diesem Fall alternative oder zusätzliche Möglichkeiten vorschlagen, wie Zielsetzungen effizient erreicht werden können. Die Beratungsleistung beginnt in diesem Sinne also bereits vor einer möglichen Auftragserteilung und bietet dem Dienstleister die Möglichkeit, sich als kritisch reflektierender Projektpartner zu präsentieren. 2.5. Soziale Aspekte Schließlich spielt neben allen inhaltlichen Aspekten auch der persönliche/soziale Eindruck eine Rolle, den der Dienstleister beim potenziellen Auftraggeber hinterlässt, da User Interface Design Projekte nicht zuletzt soziale Prozesse sind, die sich durch eine sehr intensive persönliche Zusammenarbeit der Beteiligten auszeichnen. In diesem Kontext sollte der Dienstleister darauf achten, sich nicht zu verstellen. Dies mag eventuell eine Taktik sein, die zum kurzfristigen Erfolg – im Sinne eines guten ersten Eindrucks – führt. Jedoch zeichnen sich viele User Interface Design Projekte durch eine enge und langfristige Zusammenarbeit zwischen Auftraggeber und Dienstleister aus. Daher muss auf Dauer die echte „Chemie“ zwischen den beiden Parteien stimmen. Es ist deshalb besser, wenn vor einem Projekt deutlich wird, dass dies nicht der Fall ist, als wenn dies erst während des Projektverlaufs offensichtlich wird. Dann kann es unter Umständen zu spät sein, das Projekt ohne erhebliche Kosten abzubrechen und Auftraggeber und Dienstleister müssen unter ungünstigen sozialen Rahmenbedingungen dauerhaft zusammenarbeiten. In einem solchen Kontext leidet dann auch die Motivation der Beteiligten, was wiederum negative Auswirkungen auf die Projektergebnisse hat.

3. Motivation der Projektbeteiligten User Interface Design Projekte erstrecken sich oft über einen längeren Zeitraum und nicht alle Teammitglieder auf beiden Seiten sind durchgängig und/oder mit gleicher Intensität involviert. Dies kann ein Risiko für die Motivation der Beteiligten darstellen. Hat ein Auftraggeber dazu noch wenig Erfahrung mit der Durchführung von User Interface Design Projekten, so kann dies das Risiko noch erhöhen, da die Einführung von neuen Prozessen und Aktivitäten in ein bestehendes Umfeld auf Widerstände stoßen kann – insbesondere wenn der entsprechende Nutzen nicht ausreichend verdeutlicht wird. Dies kann zum Beispiel die Durchführung von User Research Aktivitäten zu Beginn eines Projekts betreffen, die zunächst scheinbar keine unmittelbar relevanten Ergebnisse in Form von Vorschlägen bezüglich eines zukünftigen User Interface Design liefert. Stattdessen finden in einer solchen Projektphase viele Arbeiten – im wahrsten Sinne des Wortes – außerhalb der Organisation des Auftraggebers und damit „außer Sicht“ vieler Teammitglieder statt. Der Dienstleister sollte also durchgängig ein Auge auf die Motivation der Teammitglieder haben und die Möglichkeiten nutzen, die zur Verfügung stehen, um die Motivation hoch zu halten. Nicht zuletzt sind motivierte Teammitglieder glaubwürdige Multiplikatoren in der Organisation des Auftraggebers. 3.1. Aha-Erlebnisse aus der Nutzerforschung Motivierend können beispielsweise „AhaErlebnisse“ wirken, wenn Ergebnisse aus der Nutzerforschung (die etwa durch Besuche vor Ort bei Anwendern gewonnen wurden) an das Team berichtet werden und vermeintlich gesichertes Wissen beim Auftraggeber in Frage stellen. Überraschende Befunde aus der realen Welt können wie ein Weckruf auf ein Projektteam wirken und die Sinnhaftigkeit der entsprechenden Aktivitäten klar verdeutlichen. Wichtig ist in diesem Kontext, dass die überraschenden Befunde auf positive Weise vermittelt

111


werden, da sonst genau der gegenteilige Effekt die Folge sein kann und die Teammitglieder demotiviert werden oder sich den Erkenntnissen gegenüber sperren. Es sollte beispielsweise vermieden werden, einen pauschalen Gegensatz zwischen neuen „richtigen“ Erkenntnissen und bisherigem „falschen“ Wissen zu konstruieren. Vielmehr sollte eine Brücke geschlagen und zum Beispiel verdeutlicht werden, wie die existierende Wissensbasis als Ausgangspunkt für Aktivitäten genutzt wurde und auf welche Weise hierdurch neue Erkenntnisse gewonnen wurden. Der Dienstleister sollte die Befunde also einordnen und verdeutlichen, dass es nicht die Ausnahme, sondern die Regel ist, dass durch Anwenderbesuche Entdeckungen gemacht werden, mit denen auch erfahrene Domänenexperten beim Auftraggeber (beziehungsweise gerade diese) nicht gerechnet haben. 3.2. Direkte Einbeziehung des Teams auf Auftraggeberseite Besteht die Möglichkeit, Teammitglieder auf Auftraggeberseite in die neuartigen Aktivitäten im Rahmen des User Interface Design Projekts einzubeziehen, so sollte diese Motivationsquelle genutzt werden, beispielsweise durch die Teilnahme an Besuchen bei Anwendern. Es kann sich zum Beispiel als sinnvoll erweisen, Entwicklern des Auftraggebers die Teilnahme an solchen Besuchen zu ermöglichen, da Entwickler in „klassischen“ Konstellation von Software-Projekten oft maximal „weit“ von Endnutzern angesiedelt sind und weder direkten Kontakt noch Einblick in die reale Arbeitswelt haben. Auch Produktmanager des Auftraggebers können von der Teilnahme an Anwenderbesuchen profitieren – nicht zuletzt, weil sie auf diese Weise einen Einblick in die Arbeitsweise des Dienstleisters erhalten und ihnen verdeutlicht wird, dass die Ergebnisse der Arbeit ihr schon vorhandenes Wissen nicht ersetzen sollen, sondern eine erweiterte Perspektive eröffnen und damit das Wissen der Produktmanager sinnvoll ergänzen. Bei derartigen Motivationsmaßnahmen kommt es also nicht unbedingt – primär – darauf an, dass die betreffenden Teammitglieder

112

inhaltlich unmittelbar verwertbare Erkenntnisse gewinnen; die Motivation kann auch dadurch entstehen, dass sie zu einer erweiterten und tiefergehenden Sichtweise der Bedeutung ihrer eigenen Arbeit und Projektbeiträge gelangen. Diese Bedeutung der Arbeit besteht nicht zuletzt darin, das Leben der Anwender angenehmer und effizienter zu gestalten. Und wenn Mitglieder des Teams diese Möglichkeit ihrer Arbeit in der realen Welt erleben können, so kann dies eine extrem positive Erfahrung sein. 4. Bestätigung des Werts geleisteter Arbeiten Sowohl für das Projektteam wie auch für das Management beim Auftraggeber ist es wichtig, positive Bestätigung für geleistete Arbeiten zu erhalten. Da das (obere) Management häufig nicht unmittelbar in die Projektaktivitäten involviert ist, können Detailentscheidungen oft nur sehr subjektiv oder auch gar nicht bewertet werden. Umso bedeutsamer ist es daher, auch der Leitungsebene bestätigende Rückmeldungen glaubwürdig vermitteln zu können. Ein nutzerzentriertes Vorgehen ermöglicht es, derartige Bestätigungen nicht nur summarisch am Ende eines Projekts zu erhalten, sondern auch schon frühzeitig während des Prozesses zugänglich zu machen und weiterleiten zu können. Gerade für die obere Management-Ebene kann das Feedback aus einem nutzerzentrierten Prozess großes Gewicht haben, da die Zufriedenheit von Nutzern sich in den meisten Fällen auch in Umsatzzahlen niederschlägt. Der Dienstleister sollte sowohl bei der Gewinnung bestätigender Rückmeldungen wie auch bei deren Verteilung innerhalb der Organisation des Auftraggebers unterstützend tätig werden.

eine wesentliche Rolle. Dabei werden zum einen Optimierungspotenziale identifiziert, zum anderen wird die Aufmerksamkeit des Teams aber auch auf Aspekte gelenkt, die von Nutzern wertgeschätzt werden. Werden Usability Tests im Rahmen eines iterativen Vorgehens öfter durchgeführt, können auf diese Weise auch „Durststrecken“ in Projekten vermieden werden. Es empfiehlt sich, die Teammitglieder des Auftraggebers nicht erst bei der Präsentation von Usability Test Ergebnissen zu involvieren, sondern sie schon bei Planung und Durchführung mit einzubeziehen. So kann die persönliche Anwesenheit bei Usability Test Sitzungen den Effekt der Bestätigung noch verstärken, da das Feedback dann direkt vom Nutzer zu den Teammitgliedern gelangt. Der Dienstleister kann hierbei zusätzlich unterstützen, indem er dem Auftraggeber Informationen zur Be- und Verwertung von Nutzerfeedback zur Verfügung stellt. 4.2. Produktblog Eine weitere Quelle für Bestätigung kann das Anlegen eines öffentlichen Produktblogs sein, in dem Neuigkeiten aus dem Projekt kommuniziert und von Anwendern kommentiert werden können. Auf diese Weise steht auch ein weiterer Kanal zur Verfügung, auf dem Anwender sich in das Projekt einbringen können. Wird dieses Angebot aufgegriffen, so bestätigt dies sowohl die Auftraggeberseite wie auch den Dienstleister in ihren jeweiligen Bemühungen und erfüllt das Projekt allgemein mit Leben. Dies gilt umso mehr, da es vollständig in der Hand der Anwender liegt, ob und wann sie ihr Feedback geben, was den entsprechenden Rückmeldungen ein noch größeres Gewicht gibt.

4.1. Feedback von Endanwendern

4.3. Anwendertage

Eine der stärksten und eindrücklichsten Quellen für Bestätigung steht mit dem Feedback von Endanwendern des betreffenden User Interface zur Verfügung. Dieses kann in verschiedenen Kontexten erhoben werden. Während der Projektdurchführung spielen hier zum Beispiel Usability Tests

Ebenso bieten sich Anwendertage an, um Anwendern Informationen zum Projekt zu vermitteln und sich Feedback einzuholen. Derartige Veranstaltungen bieten über die Kommunikation von Ergebnissen hinaus auch die Möglichkeit, Anwender über den nutzerzentrierten Prozess zu informieren.


Usability Professionals 2013 Inhouse & Zulieferer Kooperation

Dies sorgt erfahrungsgemäß für Wertschätzung bei den Nutzern, da diese erkennen, dass sie maßgeblich in die Entwicklung eingebunden werden, was sich ebenfalls positiv auf das Projekt und die Beteiligten auswirkt. Der Dienstleister kann hierbei unterstützen, indem er dem Auftraggeber auf der Grundlage seiner Erfahrung allgemein und aus dem Projekt im Besonderen berät, welche Aspekte des User Interface bzw. des Prozesses besondere Beachtung verdienen und an Nutzer kommuniziert werden sollten. 5. Nachhaltigkeit von Maßnahmen über ein Projekt hinaus Idealerweise wirkt sich ein Usability-Projekt nachhaltig positiv für den Auftraggeber aus. Zunächst geht es natürlich darum, das betreffende User Interface benutzerfreundlich zu gestalten. Darüber hinaus besteht aber oft auch – explizit oder implizit – der Anspruch des Auftraggebers, seine eigenen Prozesse derart anzupassen oder so ergänzen, dass eine fruchtbare Grundlage für zukünftige nutzerfreundliche Entwicklungen gelegt wird. Es müssen also Wissen und Know-How in die Organisation des Auftraggebers getragen und nachhaltig verankert werden. Dies sollte vom Dienstleister mit den entsprechenden Informationen und Unterstützungsleistungen begleitet werden. 5.1. Institutionalisierung von Usability In Bezug auf Nachhaltigkeit ist die Institutionalisierung von Usability in Form von Personen essenziell, da eine rein passive Konkretisierung von Ergebnissen oder Vorgehensweisen, zum Beispiel in Form von Projektdokumentationen, keine Nachhaltigkeit gewährleisten kann. Die „Usability Personen“ beim Auftraggeber können Informationen und Feedback in Arbeitsprozesse einbringen und auf diese Weise für die dauerhafte Sichtbarkeit des Themas Usability beim Auftraggeber sorgen. Hierzu sollte der Dienstleister die entsprechenden Fertigkeiten vermitteln, indem er schon während der Durchführung des Projekts auf „Tipps und Tricks“ hinweist, die über das Wissen hinausgehen,

dass sich der Auftraggeber auch durch die entsprechende Literatur aneignen kann. Dies kann unter anderem die Fähigkeit betreffen, die richtigen Fragen zu stellen, beispielsweise wenn es darum geht, die Aussage „Der Nutzer möchte das Feature X in unserer Software“ zu hinterfragen in der Form: „Warum möchte der Nutzer das Feature? Welches Ziel möchte er erreichen?“ Das Denken in Features ist weit verbreitet, ebenso wie die Tendenz, von Nutzern verbal geäußerte Funktionswünsche nicht zu hinterfragen sondern sie unmittelbar in „Lösungen“ für ein User Interface zu übersetzen. Der Dienstleister sollte deshalb auf solche Tendenzen beim Auftraggeber achten und gegebenenfalls aufzeigen, welche Vorteile der Wechsel zu einer Denkweise hat, die sich an den grundlegenden Nutzeranforderungen im Bezug auf die realen Arbeitsprozesse orientiert. Durch die konsequente Übernahme dieser Perspektive während des Prozesses wird es den Beteiligten auf Auftraggeberseite dann erleichtert, die Sichtweise auch nach Abschluss des Projekts einzunehmen und durch konsequentes und richtiges Fragen zur kontinuierlichen Weiterentwicklung des betreffenden User Interface wie auch zum Erfolg zukünftiger Projekte beizutragen. Weiterhin können die Tipps des Dienstleisters zum Beispiel auch den Umgang mit unvorhergesehenen Projektsituationen oder sehr engen zeitlichen Rahmenbedingungen betreffen. Das Ziel der Unterstützung sollte es sein, den betreffenden Vertretern des Auftraggebers ein vom Dienstleister unabhängiges Handeln zu ermöglichen. 5.2. Veränderung von Denkweisen Damit Institutionalisierungen und Prozess­ anpassungen auf fruchtbaren Boden fallen, müssen auch Denkweisen in der Organisation des Auftraggebers angepasst und in Richtung Nutzerzentrierung ausgerichtet werden. Hierzu muss gegebenenfalls Skepsis bei einzelnen Personen überwunden werden, indem Vorteile des „neuen“ Vorgehens aufgezeigt werden. Dies kann erforderlich sein, da unter Umständen nicht alle relevanten Personen auf Auftraggeberseite Einblick in die praktische Durchführung

des Projekts nehmen können und daher nicht beurteilen können, wie essenziell bestimmte Aspekte des Prozesses für die Zielerreichung waren. In diesem Kontext ist es wichtig, dass die am Prozess beteiligten Personen auf Seiten des Auftraggebers den Prozess auch nach Abschluss des Projekts „leben“ und auf diese Weise innerhalb der Organisation als Beispiel dienen. Um dies zu unterstützen kann der Dienstleister punktuell als „Coach“ zur Verfügung stehen, um sicherzustellen, dass auch trotz zeitlichem Abstand und eventuell neuer Projektherausforderungen die wesentlichen Aspekte des nutzerzentrierten Prozesses weiterhin praktisch umgesetzt werden können. 6. Fazit Bei der Kooperation eines Usability-Dienstleisters mit einem Auftraggeber spielen verschiedene Bedürfnisse auf Auftraggeberseite eine Rolle. Die Praxiserfahrung aus einem Kooperationsprojekt zeigt, dass die Bedürfnisse Interesse, Motivation, Bestätigung und Nachhaltigkeit relevant sein können und vom Dienstleister bei seinen Aktivitäten durch geeignete Maßnahmen berücksichtigt werden sollten. Abhängig von den Projektphasen kann die Gewichtung der Bedürfnisse variieren. So steht etwa das Bedürfnis nach Nachhaltigkeit zu Beginn eines Projekts nicht unbedingt im Vordergrund, jedoch kann es während des erfolgreichen Verlaufs verstärkt zutage treten. Neben dem Wissen über verschiedene Bedürfnisse des Auftraggebers sollte der Usability Dienstleister also auch ein Gespür dafür entwickeln, wie sich Bedürfnisse über den Projektverlauf verändern, um gezielt darauf eingehen zu können und Informationen und Leistungen zu bieten, die den Auftraggeber und das Projekt optimal unterstützen. Der vorliegende Artikel soll in diesem Kontext einen Ausgangspunkt für Überlegungen von UX Professionals darstellen, die darauf abzielen, weitere relevante Bedürfnisse oder Bedürfnisklassen von Auftraggebern zu identifizieren. Auf dieser Grundlage können dann Maßnahmen diskutiert werden, die sich in der Praxis zur Befriedigung der verschiedenen Auftraggeber-Bedürfnisse bewährt haben.

113


114


Responsive UX

115


Responsive Design A whole new world?

Joachim Stalph elaboratum GmbH – New Commerce Consulting Kaflerstraße 2 81241 München stalph@elaboratum.de

Abstract „Smartphones, Tablets, Notebooks und PCs, POS-Systeme, Internet auf dem heimischen Fernseher oder auf der Playstation-Konsole – die Bandbreite der Endgeräte, über die auf Web-Angebote zugegriffen wird, wird ständig größer. Als Zauberwort, mit dem Designer, Konzeptioner und Entwickler diese Vielfalt in den Griff bekommen möchten, wird seit einiger Zeit immer öfter der Ansatz des “Responsive Design„ ins Feld geführt. Aber was genau bedeutet responsive Design überhaupt? Wo kommt der Begriff her? Was ist das Neue an diesem Ansatz, warum ist er relevant? Welche Methoden und Vorgehensweisen müssen berücksichtigt und erlernt werden, um hochwertige Responsive Design Lösungen erstellen zu können? Der Vortrag beschreibt die Entstehung von responsive Design Lösungen, und gibt einen Überblick über die Herausforderungen, die bei der Konzeption, der Entwicklung und dem Betrieb von responsiven Webseiten entstehen und liefert sowohl neue, als auch bekannte Ansätze zur praktischen Umsetzung und gibt einen Ausblick in die Zukunft des Webdesigns.“

„We are no rectangle artists“ Dieses ebenso plakative wie auch zutreffende Zitat prägte Vitaly Friedman von Smashing Magazine auf der uxmunichKonferenz im März diesen Jahres.

z.B. rechts und links der Webseite viel Freiraum angezeigt wurde. [Abb. 1] Die Evolution des mobilen Webs

Was hat er damit gemeint?

Betrachtet man sich die Entwicklung des Webdesigns, so haben Gestalter, Konzeptioner und Kreative viele Jahre lang vorwiegend für einen rechteckigen Viewport gearbeitet. Die wesentliche Fragestellung dabei war fast immer nur, mit welcher Bildschirmauflösung die meisten der Nutzer unterwegs sind. Nach den Anfängen mit 800x600 Pixels setzten sich dann irgendwann die 1024er Auflösungen durch. Aber nach wie vor wurden letztlich nur Rechtecke gestaltet – „rectangle artists“ eben. Mit der Verbreitung von Gridsystemen wie bspw. dem 960.gs nahmen viele Anbieter in Kauf, dass bei den Nutzern mit größeren Monitoren der zur Verfügung stehende Platz nicht sinnvoll ausgenutzt wurde und

116

Abb. 1. Ein ansprechendes Beispiel: Screenshot ltur.de bei einer Auflösung 1366 × 768

Keywords: /// Responsive Design /// Konzeption /// mobile first /// User Experience /// Webdesign

In 2007 stellte Steve Jobs das Apple iPhone vor und versprach den Nutzern in seiner Keynote Ihnen das „echte“ Internet auf das Smartphone zu bringen, mit Hilfe


Usability Professionals 2013 Responsive UX

von Safari, als ersten echten HTML Browser auf einem Mobiltelefon [4]. Das mobile Web war somit geboren.

Spätestens seit der Einführung des iPhones haben alle Smartphones einen eingebauten Browser, der vollständige Webseiten anzeigen kann. Dies bedeutet aber, dass ein mühevoll für den Desktop PC konzipiertes Layout zwar dargestellt werden kann, es in der Praxis aber keinen Spaß macht diese Webseite zu bedienen, da der Screen eines Smartphones, neben weiteren technischen Begrenzungen, im Vergleich zum Monitor zu Hause sehr eingeschränkt ist. Mobile Nutzer brauchen eine Lupe um das elementar Wichtige der Seite erkennen zu können, nämlich den Inhalt. Von Usability und User Experience (UX) braucht man hier nicht zu sprechen.

Konsequenz daraus sind beispielhafte Webanalytics Daten, die zeigen, dass Kunden mit mehr als 120 unterschiedlichen Auflösungen auf einen vergleichsweise kleinen Webshop zugreifen. [Abb. 2] Mehr als die Hälfte dieser Auflösungen zeigen nur einen einzigen Besuch pro Monat auf. Große Webseiten bringen es sogar auf über 1.000 unterschiedliche Auflösungen.

Auf diese Weise machen vor allem die Apps Smartphones zu Verkaufsschlagern.

Laut einer BITKOM Studie [1] haben Smartphones innerhalb von wenigen Jahren den deutschen Handymarkt komplett verändert. Erst 2007 kamen sie in die Läden, dieses Jahr werden voraussichtlich vier von fünf verkauften Handys in Deutschland Smartphones sein. Die mittlerweile große Konkurrenz im Smartphone Markt artet in einem PixelWettrüsten, und der Frage „wer bietet die beste Auflösung“ aus.

Bei Betrachtung der Verteilung der Vorund Nachteile der beiden Ansätze ist nicht offensichtlich welche Lösung grundsätzlich die Bessere ist. Festzuhalten ist jedoch, dass das Schlechte an beiden Ansätzen die strikte Trennung von der Mobil- und der Desktop-Version der Website ist. Webseiten oder Apps werden für einzelne Geräteklassen optimiert. Dadurch entsteht ein erhöhter Pflegeaufwand von redaktionellem Content, Bildmaterial und den unterschiedlichen Quellcodes. Erschwerend kommt hinzu, dass die Website unter Umständen für zukünftige Tablet- oder Smartphone-Formate mindestens eine dritte oder vierte Version des Layouts benötigt.

Mit dem iPhone stellte Apple auch den App Store vor, der die Möglichkeiten der Nutzung des Mobiltelefons von jetzt auf gleich vervielfachte. Der rasante Erfolg vieler Apps ist vor allem durch die gebotene Experience für den Nutzer zu erklären. Inhalte und Bedienung der App sind perfekt auf die technische Ausstattung und den Bildschirm des jeweiligen Smartphones abgestimmt. Die UX hängt hier sehr stark von der Bedienung und dem Erscheinungsbild der App ab. Somit war klar, Web-Inhalte können auch auf einem Smartphone Spaß machen.

Hier gibt es seit der Markteinführung von Smartphones verschiedene Strategien und Ansätze, die alle ihre Vor- und Nachteile mit sich bringen. Hier wird vorwiegend zwischen einer nativen App und einer WebApp (einer mobil optimierten Webseite) unterschieden.

Abb. 2. Screenshot der Analytics Daten „Bildschirmauflösung“ eines beispielhaften Kunden von elaboratum

Mit der schnellen Marktdurchdringung von Smartphones steigt auch der mobile Traffic. Die Beobachtung der Webseiten unserer Kunden zeigt, dass der Traffic über mobile Endgeräte im Durchschnitt um ca. 1% pro Monat steigt. Viele Webseitenbetreiber sind deshalb auf der Suche nach einer mobilen Strategie, und stellen sich die Frage wie sie die Webseiten-Inhalte Ihren Kunden mobil optimiert präsentieren können. Die meisten haben hier erkannt, dass die reine Anzeige Ihrer Webseite auf einem mobilen Endgerät aufgrund mangelnder Usability nicht ausreicht.

Dadurch dass es bis dato keine integrierte Strategie gab wie Web-Inhalte den Nutzern auf verschiedenen Endgeräten angezeigt werden soll, und gleichzeitig die Vielfalt an unterschiedlichen Ausgabemedien mit unterschiedlichen Displays und Auflösungen wächst, werden wir bald den Punkt erreichen, dass es schier unmöglich ist mit der unendlichen Anzahl an Endgeräten und Auflösungen Schritt zu halten, und Inhalte speziell zu optimieren. Woher kommt responsive Design und warum ist es relevant? Die Diversifikation der Ausgabemedien mit unterschiedlichen technischer Ausstattung und Auflösungen ist der erste Grund für das Aufkommen von responsive Design als neue Philosophie. Konzeptioner und Webdesigner haben sich die einfache Frage gestellt, wie man mit einem Konzept und einer Technologie alle Ausgabemöglichkeiten auf den verschiedenen Devices abdecken kann.

117


Diese logische Konsequenz in der Evolution des mobilen Webs ist aber nur die eine berühmte Seite der Medaille.

Dies wiederum führt uns zurück zu unserem einleitenden Zitat von Vitaly Friedman „We are no rectangle artists“ [2].

Laut Jeremy Keith erfordert eine sinnvolle Konzeption von responsive Lösungen ein grundlegendes Umdenken.

Was darüber hinaus bei der vollen Konzentration auf die App Entwicklung der letzten Jahre verloren gegangen ist, ist das Bewusstsein für den Nutzer und die inhärenten Eigenschaften des Webs, was der zweite Grund für responsive Design ist.

Was Vitaly Friedman mit dem Zitat meint, ist dass wir das Web nicht gekapselt für jedes Ausgabemedium sehen sollten, sondern als großes Ganzes betrachten müssen.

Weg vom Denken in „Seiten“ (Boxen und Rechtecken), hin zu einem ganzheitlichen Denken in Systemen, Modulen und Inhalten. Und damit hin zum Startpunkt für jede Situation, jeden Kontext und jedes Ausgabegerät: Welche Informationen/ Funktionen benötigt der Nutzer in dieser Situation/diesem Kontext und wie sollte die Information/Funktion dann idealerweise aufbereitet sein?

In Zeiten des Multichannel-Commerce interagieren Nutzer mit den Inhalten eines Anbieters über verschiedene Wege und mit diversen Ausgabemedien. So gibt es immer mehr Nutzungsszenarien bei denen sich Kunden mobil über das Smartphone den Weg zu einem Ladengeschäft anzeigen lassen, sich dort offline informieren und beraten lassen, und dann abends nach etwas Bedenkzeit auf der Couch das Produkt online mit dem Tablet oder Netbook bestellen. Nutzer möchten sich in diesen Use Cases nicht mit ihren unterschiedlichen Devices auf unterschiedliche Layouts einstellen, und Sorge haben, dass das vielleicht für den mobilen Kontext wichtige Feature erst gar nicht abgebildet ist, da es nicht in das überragende Layout-Konzept der Website passt. Viel mehr birgt jedes Ausgabemedium aufgrund seiner technischen Ausstattung unterschiedliches Potenzial die verschiedenen Use Cases anzureichern und somit eine übergreifende optimale User Experience zu schaffen. Auf diese Weise bewegen wir uns in der Konzeption weg von „Gleichheit/Gleichmachung“ hin zu „Customization“. Sowohl Konzeptioner als auch Nutzer waren es gewohnt, dass Inhalte in jedem Browser gleich aussahen und auch gleich funktioniert haben. Durch die enorme Vielfalt an Ausgabemedien wird aber immer klarer, dass gleicher Inhalt nicht die gleiche User Experience bedeutet. Vielmehr gibt es sogar das Bewusstsein, dass wenn Inhalte auf den verschiedenen Ausgabemedien gleich aussehen und funktionieren, man die Chance verpasst Inhalte speziell auf verschiedene Devices und die jeweils begleitenden Nutzungsszenarien anzupassen.

118

Das Web ist nicht nur ein Browser bzw. das, was in unserem Browser dargestellt wird. Das Web besteht nicht aus einer Menge von Web Pages, sondern das Web ist vielmehr eine Menge von Inhalten und Services, die in unterschiedlichster Form dargestellt und eingesetzt werden können. Sinnvoller ist vielmehr ein Perspektivwechsel, weg vom Webdesign aus der Perspektive des Seitenbetreibers hin zum Design für den Nutzer, um ihm eine optimierte UX zu bieten. Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. [7] Ethan Marcotte Dementsprechend muss eine Webseite so gebaut und gelayoutet werden, dass auch ein mobiler Nutzer die für ihn relevanten Inhalte einfach und intuitiv findet und bedienen kann. In anderen Worten, eine Webseite muss die Technologie beinhalten, dass sie sich automatisch den Präferenzen des Nutzers anpasst. Diese Technologie macht die Entwicklung und das Layouting unterschiedlicher Webseiten und Designs für die verschiedenen Geräte überflüssig und unnötig. Genau diese Technologie beschreibt der Konzeptansatz des responsive Designs. Stop thinking in pages, start thinking in systems. [5] Jeremy Keith

Dieses ganzheitliche Denken besteht nicht aus Browsern und festen Auflösungen, sondern aus verschiedenen Ausgabegeräten, auf denen der Inhalt angezeigt wird. Und dies nicht immer gleich, sondern kontext-sensitiv. Das kann so weit gehen, dass die Aufbereitung und Darstellung bestimmter Inhalte sich von Situation zu Situation völlig ändert. Einfach angewandt wird aus der großzügigen Primärnavigation ein Slide-Out-Menü, das nur noch über ein Icon angesteuert wird. Oder, etwas weiter gedacht, wird aus dem großen MarketingTeaser eine Audiospur, d.h. ein akustischer Teaser. Es geht also nicht nur darum, die Größe und Anordnung von Content-Elementen anzupassen, sondern entsprechend des Kontextes (= Nutzungsszenario + Ausgabemedium), nur relevante Funktionen und Inhalte anzuzeigen. Um dies greifbar zu machen nutzt Ethan Marcotte gerne den Usecase „RestaurantSuche“ als Beispiel [7]. Wenn man eine Webseite für ein Restaurant konzipiert, kann man davon ausgehen, dass mobile Nutzer der Seite und Desktop Nutzer unterschiedliche Anforderungen an die Seite haben. Desktop Nutzer möchten voraussichtlich Bilder des Restaurants sehen, die gesamte Speisekarte einsehen und sogar etwas über die Geschichte des Restaurants erfahren. Mobile Nutzer hingegen suchen vermutlich lediglich die Adresse, Öffnungszeiten und eine Telefonnummer um einen Tisch zu


Usability Professionals 2013 Responsive UX

reservieren. Das bedeutet nicht, dass ein mobiler Nutzer nie Bilder des Restaurants sehen möchte, er hat jedoch Anforderungen an die Webseite, die ihm im mobilen Kontext wichtiger sind, als die Bilder. Daher kann man sagen, dass mit Hilfe von responsive Design dem Nutzer inhaltliche Gleichheit geboten werden kann, durch Priorisierung der Inhalte jedoch gleichzeitig auf das jeweilige Ausgabemedium und das begleitende Nutzungsszenario eingegangen werden.

Abb. 3. Graceful Degradation

Welche Methoden und Vorgehensweisen müssen berücksichtigt und erlernt werden, um hochwertige, responsive Design-Lösungen erstellen zu können? Schaut man sich die Web Entwicklung und deren Konzeption heute an, so bemerkt man schnell, dass es vielen Webseiten an einem integrierten Konzept der Darstellung auf unterschiedlichen Ausgabemedien mangelt. Wir sind geblendet von Desktop Browsern, so dass wir beim Thema „Webdesign“ lediglich in Boxen und Content Elementen denken (wie ein Browser), die ins Layout passen müssen. Dies ist aber nicht die Realität des Webs. Neben unserem Desktop PC, falls wir diesen überhaupt noch haben, kommen weitere Ausgabemedien dazu, wie Smartphones, Tablets und Mini-Tablets, aber auch völlig neue Formen wie Smart-TV, Google Glass und Smart Watches. Was bedeutet dies für die Konzeption einer einheitlichen UX, die sich am Nutzungskontext orientiert und somit responsive ist? Graceful Degradation Der „traditionelle“ Webdesign Ansatz der graceful Degradation ist hinsichtlich responsive Design sicherlich nicht der Richtige. Bei diesem top-down Ansatz [Abb. 3] wird eine Webseite für die neueste Browser Technologie entwickelt und optimiert.

Abb. 3. Progressive Enhancement

Gleichermaßen werden verschiedene Features für ältere Browser oder schlechter ausgestattete Ausgabemedien einfach entfernt bzw. aufgrund der unterlegenden Technologie nicht berücksichtigt.

Wie bereits beschrieben, folgt responsive Design dem Nutzer, und nicht wie gegenwärtig, der Nutzer den meist starr konstruierten Layouts konventioneller Websites und Online-Shops.

Für die Entwicklung einer Webseite bedeutet dies konkret, dass diese für die DesktopNutzung optimiert wird. Das heißt, es gibt ein aufwändiges Design mit vielen Grafiken, eine komplexe Navigation, Scripte, Slideshows, Videos usw. Dies wiederum führt dazu, dass viel Bandbreite bzw. Performance notwendig ist. Beim Anpassen des Layouts für kleine Displays steht der Konzeptioner unter anderem dann einem Platzproblem gegenüber, dass durch Kompromisse gelöst wird in dem die Webseite „abgespeckt“ wird, und wichtige Elemente nicht optimiert oder gar nicht angezeigt werden.

Progressive Enhancement

Dementsprechend kann man bei graceful Degradation auch von einem Layout- bzw. Browser-first-Ansatz sprechen, mit dem ein „echtes“ responsive Webdesign nicht umsetzbar ist.

Damit eine Website nicht nur vom Layout auf das Device passt, sollte eine mobile Website deshalb entsprechende Funktionen bieten, welche die User Experience im jeweiligen Nutzungskontext verbessert. Um dies konzeptionell umsetzen zu können, ist der Konzeptansatz progressive Enhancement die modernere Antwort auf graceful Degradation. Wie sieht die ideale Vorgehensweise bei progressive Enhancement aus?

Progressive Enhancement folgt einem bottom-up Ansatz, d.h. einem mobile firstAnsatz. [Abb. 4]

119


CSS ist für die Präsentation der Inhalte verantwortlich, und Java Script für das Verhalten auf der Seite. Entscheidende Neuerung für die Entwicklung eines responsive Designs ist tatsächlich der Startpunkt der Konzeption, nämlich mobile first, wobei dieser Ansatz genauso die Prinzipien user first, content first, und functionality first umfasst. Um auf den sehr schnell wachsenden mobilen Traffic zu reagieren, der einhergeht mit einer schier unendlichen Zahl an Devices mit unterschiedlichen Auflösungen bietet responsive Design sowohl einen Konzeptansatz, als auch eine Technologie um sowohl auf das Web als auch die Nutzer einzugehen. Responsive Design zwingt dem Konzeptioner einen Nutzerzentrierten Ansatz auf, und in User Stories und Nutzungsszenarien zu denken (Was macht der Kunde ich auf welchem Ausgabemedium in welchem Kontext?), und nicht konzeptionell zwischen mobilen- und Desktop-Versionen zu trennen.

Abb. 5. Schematische Darstellung der Anzeige des Webseiten-Contents an drei verschiedenen Breakpoints

Responsive web design represents a fundamental shift in how we'll build websites for the decade to come [9]. Jeffrey Veen Fazit

Abb. 6. Screenshots entnommen aus einer Präsentation von Jeremy Keith[6.]

Für die Entwicklung einer Webseite bedeutet dies nun, dass der Konzeptioner eine lineare bzw. sequentielle Vorgehensweise wählt. Er geht zunächst davon aus, dass man alle Elemente (Contents, Services, Funktionalitäten) nur rein linear untereinander anordnen kann, und erst bei zunehmend größerer "Fläche" kann man dann (ab bestimmten Breakpoints) überlegen, ob man die Elemente auch anders anordnen kann bzw. ob die Elemente selbst auch eine andere Ausprägung (Form) annehmen können. [Abb. 5]

120

In anderen Worten, der Konzeptioner besinnt sich zunächst auf das Wesentliche. If you just make an html-Document and you put it on the web it’s already responsive [8] Jeremy Keith Oder wie Andy Hume die Aussage auf den Punkt bringt: „The web is responsive by default“ [3]. [Abb. 6] Die Technologie für das Vorgehen gibt es. HTML sorgt für die Struktur der Webseite,

Zusammenfassend lässt sich sagen, dass responsive Design zwar aus der mobilen Web-Entwicklung entstanden ist, da es die Problematik der strikten Trennung zwischen mobile und Desktop Nutzung aufzeigt, aber es bei responsive Design nicht um die Konzeption für mobile Endgeräte geht. Es geht aber auch nicht um die Konzeption für den Desktop. Vielmehr geht es bei responsive Design um einen flexiblen Webdesign-Ansatz unter Berücksichtigung der extrem gestiegenen Gerätevielfalt und das Bewusstsein für den Nutzer und die inhärenten Eigenschaften des Webs. Oder, wie Vitaly Friedman es sagen würde: „We are no rectangle artists“. Hierbei steht der Kontext pro Device und die jeweils begleitenden Use Cases im Vordergrund. Auch wenn dies nichts Neues ist, dass wir als Konzeptioner die


Usability Professionals 2013 Responsive UX

Use Case-Denke schon längst verinnerlicht haben sollten, haben wir mit responsive Design nun einen mächtigen Konzeptansatz der uns zwingt den Kontext zu betrachten, und somit die Mischung aus Nutzer, Nutzungsszenario und Ausgabemedium.

Literatur 1. BITKOM Presseinfo. (2013). SmartphoneMarkt. 13.02.2013, http://www.bitkom. org/files/documents/BITKOM_Presseinfo_ Smartphone-Markt_13_02_2013.pdf 2. Friedman, Vitaly. (2013). Zitat aus seinem Vortrag auf der uxmunich. 3. Hume, Andy. (2011). Responsive by

Hier sind die ersten Schritte in der Konzeption entscheidend. Wir müssen aufhören in „Ausgabeformen“ zu denken, sondern im ersten Schritt in Inhalten und Funktionalitäten denken, unabhängig davon, ob diese auf einem großen Screen, einem kleinen Screen oder einem Oakley-Headup-Display angezeigt werden.

Default. http://blog.andyhume.net/ responsive-by-default/ 4. Jobs, Steve. (2007). Keynote zur Einführung des iPhones. 5. Keith, Jeremy. (2011). Context. http:// adactio.com/journal/4443/ 6. Keith, Jeremy. (2012). Forbedringer gjennom responsiv design. Webdagene Conference 2012. http://de.slideshare.net/webdagene/

Neben der Konzeption hat responsive Design auch Auswirkungen auf andere Bereiche und wirft Fragen auf, über die man rechtzeitig nachdenken sollte. Ich denke hier vor allem an die Themen Testing, Tracking und Betrieb (Redaktion), für die es aus meiner Sicht bisher nur wenige Lösungsansätze gibt.

responsiveenhancement. Folien 51 ff. 7. Marcotte, Ethan. (2011). Responsive Webdesign. Eyrolles. 8. Reichenstein, Oliver. (2013). The good, the bad, the pretty and the ugly. http:// de.slideshare.net/reichenstein1/the-goodthe-bad-the-pretty-and-the-ugly. Folie 58. 9. Veen, Jeffrey. (2011). Vorwort zum Buch von Marcotte, Ethan. (2011). Responsive

Benötige ich für das Testing ein Testlab, in dem ich Zugriff auf all die verschiedenen Devices habe? Gibt es Alternativen? Wie unterscheide ich in meinem Webanalytics System die KPIs? Können Webanalytics Systeme trennscharf die verschiedenen Devices unterscheiden und mir somit die KPIs gesondert ausweisen? Und wie erstelle ich den Content für meine Seite? Eine Content-Version für jede Seite und jeden Breakpoint? Wie gehen CMS Systeme damit um?

Webdesign. http://www.abookapart.com/ products/responsive-web-design

Einhergehend mit den Fortschritten in der Konzeption responsiver Webseiten müssen wir uns verstärkt auch mit diesen Fragen auseinandersetzen, die den Betrieb dieser Webseiten betreffen.

121


Responsives UI Design Wirkungsvolles Mittel gegen zunehmende Gerätefragmentierung? Nicolas Leyking Ergosign GmbH Europaallee 12 66113 Saarbrücken leyking@ergosign.de

Jan Groenefeld Ergosign GmbH Europaallee 12 66113 Saarbrücken groenefeld@ergosign.de

Abstract Softwarehersteller sehen sich heute mit dem Problem einer fast unbeherrschbaren Fragmentierung von Geräten und Betriebssystemen konfrontiert. Der Ansatz, jeder Applikation ein natives Pendant zur Verfügung zu stellen, erscheint schlicht unwirtschaftlich. Im Gegensatz zu einem statischen Design, welches nur sehr beschränkt auf Veränderungen der eigentlichen Zielgröße reagieren kann, wird bei responsivem Design auf ein flexibles, programmtechnisches und konzeptuelles Regelwerk zurückgegriffen. Dabei ist es das Ziel, mit Hilfe dynamischer Platzausnutzung eines beliebigen Anzeigegerätes zu jedem Zeitpunkt eine optimale Präsentation der Inhalte zu gewährleisten. Somit ermöglicht responsives Design einen „Cross Platform“-Ansatz, mit welchem die Gerätefragmentierung beherrscht werden kann.

1. Motivation Das starke Interesse am Thema „responsives Webdesign“ ist in erster Linie der anhaltend starken Verbreitung von mobilen Geräten in unterschiedlichsten Ausprägungen geschuldet. Die seit ca. 2007 auf dem Markt existierenden mobilen Geräte, wie zum Beispiel das iPhone von Apple Inc., erlauben aufgrund ihres ausreichend großen Touch-Screens erstmals eine umfassende Internetnutzung mit einem nahezu vollwertigen Internetbrowser. Die seit Jahren und laut Prognosen auch in Zukunft noch stark wachsende Verbreitung von Smartphones und Tablets [5] erlaubt nicht nur Unternehmen im Bereich des „Casual Computing“, also im klassischen Consumer Segment, neue Einsatzfelder für sich zu erschließen, sondern lässt die mobilen Geräte auch für „Business Solutions“ immer interessanter werden. Unabhängig von ihrem konkreten Kontext wurden die Inhalte bis vor kurzem meistens nur in einem statischen Design angeboten. Das heißt, Inhalte wie z.B. Websites wurden in der Regel für eine Geräteklasse und teilweise auch Bildschirmauflösung optimiert und programmiert. Die Ursache hierfür liegt augenscheinlich häufig

122

im damit verbundenen Programmieraufwand. Mittels Zoom-Mechanismen können Inhalte dieser Art prinzipiell zwar ohne Probleme auch in mobilen Browsern angezeigt werden, ihre Bedienbarkeit leidet jedoch erheblich. Von einer guten User Experience kann erst recht keine Rede sein. Der daraus hervorgegangene gestalterische und technische Ansatz des responsiven Webdesigns erlaubt es, den grafischen Aufbau und die verwendeten Medien einer Website an ein (fast) beliebiges Ausgabemedium flexibel anzupassen und so eine größere Gerätekompabilität erreichen. Für viele Unternehmen, die neue Geschäftsfelder erschließen wollen oder an eigenen Prozessoptimierungen interessiert sind, bietet die Mobiliät der Smartphones und Tablets neue Möglichkeiten, innovative Lösungen zu entwickeln. Dabei liegt es auf der Hand, dass eine 1:1 Portierung einer Applikation nicht die bestmögliche Lösung darstellt und mehr Probleme schafft als löst. Probleme entstehen durch Platzmangel und Interaktionskonzepte, die ursprünglich für Maus und Tastatur ausgelegt waren. Die Vorstellung, eine komplexe Layout-Struktur, wie sie zum Beispiel bei klassischen CRMSystemen anzutreffen ist, 1:1 auf mobile

Markus Kühner Ergosign GmbH Europaallee 12 66113 Saarbrücken kuehner@ergosign.de

Keywords: /// Responsives Design /// Cross-Platform /// Layouts /// Flexibilität /// Mobile

Geräte zu übertragen, verdeutlicht dies. Eine Neu-Konzipierung für den mobilen Kontext bedeutet in der Regel eine komplexe Aufgabe für den Designer und erfordert viel Erfahrung im User Experience Design an sich und im Speziellen in der Domäne mobiler Endgeräte, funktional wie technologisch. Die folgenden Abschnitte sollen Führung und Hilfestellungen für Designer, Entwickler und Projektmanager geben, um eine bestmögliche User Experience für responsive Applikationen zu erzielen. 2. Begrifflichkeiten und ihre Ansätze Die folgenden Begriffsdifferenzierungen entstanden auf Basis persönlicher, praktischer Erfahrungen im Themengebiet und sollen durch die eigene Expertise die verwendeten Begriffsdefinitionen insbesondere im Rahmen dieses Papers schärfen. 2.1. Responsives und adaptives Design Grundsätzlich wird zwischen responsivem und adaptivem Design unterschieden. Die


Usability Professionals 2013 Responsive UX

Schlüsselaspekte sind Flexibilität in der Darstellung und Wirtschaftlichkeit in der Umsetzung, die unter anderem durch sogenannte „Media Queries“ und eine vorausschauende Projektierung erreicht werden. Bei responsivem Design, das sich insbesondere durch sein dynamisches Layout auszeichnet, werden textuelle und mediale Inhalte mittels „Media Queries“ in Größe, Platzierung und automatischen Umbrüchen variabel an den zur Verfügung gestellten Platz angepasst [1]. Wichtig ist, dass die Neusortierung nicht willkürlich erfolgt, sondern zu jedem Zeitpunkt eine für den Nutzer sinnvolle Anordnung darstellt. Eine wichtige technische Grundlage ist hierbei die Fähigkeit der „Media Queries“, bei allen gängigen Browsern die Breite und Höhe des Browserfensters und Bildschirms sowie die Ausrichtung (Porträt oder Landscape Mode) direkt im CSS Code abzufragen [2] und das Design entsprechend zur Laufzeit zu variieren. Adaptives Design verfolgt grundsätzlich ein sehr ähnliches Ziel wie responsives Design, baut jedoch ausschließlich auf ein fixes Layout auf, das abhängig von der aktuellen Gerätebreite programmtechnisch auf vordefinierte Darstellungen umstellt. Der Unterschied zwischen adaptivem und responsivem Design liegt vor allem in der unterschiedlichen Methodik und dem Grad der Anpassungsfähigkeit der Layout-Struktur. 2.1. Webapplikationen und native Applikationen

Responsives Design ist grundsätzlich keiner Technologie unterworfen. Dennoch spricht im Sinne der wirtschaftlichen Projektierbarkeit über viele Geräte und Betriebssysteme hinweg einiges für den Ansatz einer Webapplikation. Denn durch den Ausbau und die Professionalisierung von JavaScript und CSS Frameworks wurden Webapplikationen in den letzten Jahren verstärkt zu einer echten Alternative gegenüber nativ laufenden Applikationen. Webtechnologien wie HTML, CSS und JavaScript ermöglichen es, auf nur einer Codebasis eine dynamisch funktionierende Cross-PlatformStrategie zu verfolgen. Auch wenn Web-Technologien stark aufgeholt haben, bieten native Applikationen weiterhin die beste Performance und damit das beste Bedienerlebnis [8]. Durch ihre individuelle Entwicklung mit nativem Code erreichen sie auf dem jeweiligen Betriebssystem eine flüssige und stabile UI-Darstellung, die bei Webapplikationen kaum zu erreichen ist. Der Implementierung einer Applikation für mehrere unterschiedliche Plattformen wie zum Beispiel iOS, Android und Windows 8 steht hingegen ein sehr hoher Aufwand in der Entwicklung und Wartung gegenüber. 3. Responsive UI Patterns Im Folgenden werden einige Problemstellungen und Lösungen aus den Bereichen Layouting und Navigation behandelt und diese mit praktischen Beispielen näher erläutert.

Abb. 1. Dreispaltiges responsives Layoutkonstrukt [6]

3.1. Layouting – Patterns Um den Rahmen dieses Papers nicht zu sprengen, wird nun lediglich ein responsives Seitenlayout näher vorgestellt. Weitere Layout Patterns finden sich im Internet, zum Beispiel auf der Website von Luke Wroblewski [6]. Der sogenannte „Column Drop“ ist ein gängiges, responsives Layouting-Konstrukt, bei dem der Seitenaufbau von einem dreispaltigen Desktop-Layout über ein zweispaltiges Tablet-Layout zu einem einspaltigen Smartphone-Layout umgestaltet wird (8). [Abb. 1], [Abb. 2] Ein solches dynamisch gestaltetes Applikationslayout basiert im Wesentlichen auf Regeln des automatischen Umbruchs von Inhalten und begegnet den unterschiedlichen Bildschirmformaten effektiv und automatisiert. Das Regelwerk für eine solche Logik wird häufig auf nur einer

Abb. 2. Praktisches Beispiel für ein dreispaltiges Layoutkonstrukt [7]

123


gemeinsamen Code-Grundlage formuliert, sodass die Applikation selbst weiterhin als eine einzige Anwendung betreut werden kann. Dies sorgt für die gewünschte Wirtschaftlichkeit bei der Umsetzung und eine erweiterte Gerätekompatibilität. 3.2. Navigation-Patterns

Abb. 3. Listenartige Darstellung des Menüs in der Desktopvariante [9]

Abb. 4. Fast identische Menüstruktur im Vergleich zur Desktop-Version [9]

Ein weiteres Beispiel für ein responsives Konstrukt ist die bildschirmoptimierte Darstellung der Menüstruktur. Dabei sind u.a. folgende Lösungsansätze bei responsiven Applikationen weit verbreitet [4]. 3.2.1. Der „Es bleibt wie es ist“ Ansatz Dieser Ansatz stellt lediglich die Erreichbarkeit der Navigation sicher, ohne diese konkret für den Einsatz auf Touchgeräten zu optimieren und ist bereits mit wenigen CSS-Anpassungen umsetzbar. Leider geht dabei häufig viel Platz im Kopfbereich der Applikation verloren. [Abb. 3], [Abb. 4] 3.2.2. Footer-Navigation Um dem Inhalt mehr Platz einzuräumen, wird bei dieser Variante die Navigation in den Footer der Website verschoben. [Abb. 5] Problematisch bei dieser Variante ist die Tatsache, dass die Navigation sehr versteckt wirkt und u. U. lange „Scrollwege“ bis ans Ende der Seite erforderlich sind. Für ein zentrales Navigationselement ist dieser Ansatz daher eher weniger zu empfehlen.

Abb. 5. Footer-Navigation auf der mobilen Website von Unicef für Smartphones [10]

3.2.3. „Select“ Menü

Abb. 6. Horizontale Listendarstellung des Menüs für Tablets und Desktops [4]

124

Abb. 7. Select Menü für kleine Smartphone Bildschirme [4]

Diese Darstellung der Navigationseinträge in einem Dropdown-Menü ist durch ihre einfache Verwendbarkeit häufig anzutreffen. Die Realisierung geschieht durch das Einbinden eines JavaScript Plugins, das die Menüliste in Select und Option Elemente umwandelt. [Abb. 6], [Abb. 7] Nachteile dieser Visualisierungsform sind zum Einen das vom Betriebssystem gesteuerte visuelle Design des Select-Controls und zum Anderen die ungewohnte Darstellung in Form eines Dropdown-Menüs [4].


Usability Professionals 2013 Responsive UX

3.2.4 „Toggle“ Menü Für das „Toggle“ Menü Konzept gibt es viele verschiedene Darstellungsmöglichkeiten. Generell öffnet sich eine Menüstruktur, die beliebig auf dem Bildschirm positioniert werden kann. Nachfolgende Abbildungen zeigen mögliche Darstellungsvarianten: Einfacher „Toggle“ Die mobile Website der „Starbucks“Kette positioniert das Menü innerhalb des Contents im Zentrum des Bildschirms. [Abb. 8]

Abb. 8. Integrierte Menüdarstellung im Inhaltsbereich auf der Starbucks-Website [11]

Abb. 9. Von oben einfahrender Navigationsbereich [12]

Verdecktes Menü Die „dconstruct“ Website verfolgt den Ansatz, das Menü von oben auf der gleichen Ebene wie den Inhaltsbereich ­hineinfahren zu lassen und den Inhaltsbereich um die benötigte Platzmenge hinunterzuschieben. [Abb. 9] Einschub von links Die mobile Website der „Sycamore School“ schiebt das Menü als eine eigene Ebene von links nach rechts über den eigentlichen Content. [Abb. 10] Off-Canvas Die Off-Canvas-Technik schiebt den ­In­­halts­bereich der Webseite nach links oder rechts nahezu vollständig aus dem sicht­baren Bereich hinaus. [Abb. 11] Diese hochwertig wirkende „Toggle“ Menü-Variante ist z.B. auf der mobilen „Facebook“ Website anzutreffen.

Abb.10. Von links nach rechts einfahrende Navigationsebene [13]

4. Responsives UI Design in der Anwendung In diesem Kapitel wird die grundsätzliche Signifikanz sowie Strategien und Vorgehensweisen bei der Konzipierung responsiven Designs vorgestellt und dessen Besonderheiten in einem User-Centered Designprozess (kurz: UCD) verdeutlicht.

Abb. 11. Off-Canvas Navigationsansatz [3]

125


4.1. Der Designprozess Der im Folgenden vorgestellte responsive Designprozess setzt auf den klassischen UCD Prozess auf und unterteilt sich in seine typischen Phasen und deren Aufgaben. In diesem Abschnitt werden lediglich die Besonderheiten des responsiven Designprozesses herausgestellt und näher erläutert. Analyse Innerhalb der Analysephase gilt es, verstärkt umfassende Informationen über die primär zu unterstützenden Bildschirmgrößen und die zugrunde liegenden Gerätekonzepte zu sammeln. Dieses Wissen über Gerätetypen, Gerätehersteller, Ausgabegrößen und Betriebssystemkonzepte bietet die Grundlage jedes responsiven Designs und sollte, um über das gesamte Projekt hinweg den Überblick zu behalten, an zentraler Stelle dokumentiert und visualisiert werden, ähnlich wie es mit „Personas“ gehandhabt wird. Der Nutzungskontext ist hier ein zentraler Bestandteil der Analyse, da sich hier häufig Rückschlüsse auf die benötigten Geräteklassen ableiten lassen. Design Auf Grundlage des gewonnenen Verständnisses über technische Rahmenbedingungen und gerätespezifische Interaktionskonzepte aus der Analysephase beginnt der UI-Designer in dieser Phase mit seinen ersten Überlegungen zu einem passenden flexiblen UI-Konzept. Dabei lässt sich bei der Neukonzeption einer responsiven Applikation keine generelle Empfehlung für den „Mobile First“ oder „Desktop First“ Ansatz aussprechen. Nach dem „Desktop First“ Ansatz wird zunächst die maximale Zielgröße, meist die des Desktop-PCs, betrachtet. Durch die größere Fläche können hierbei mehrere Designelemente im Blick behalten und verschiedene Darstellungsvarianten ausprobiert werden. Mit dem „Mobile First“ Ansatz hingegen wird, beginnend mit der kleinsten anzunehmenden Geräteklasse, die Reduktion auf die wesentlichen Elemente gefördert. Es muss

126

aufgrund der kontextabhängigen Funktionen bei jedem responsiven Designprojekt neu zwischen „Mobile First“ und „Desktop First“ abgewägt werden. Beeinflussen zum Beispiel besondere Funktionen der mobilen Endgeräte, wie u.a. die Ausrichtung (Porträt oder Landscape-Modus) oder die Geo-Lokalisierung das UI, sollte eher der „Mobile First“ Ansatz verfolgt werden. Sind solche Funktionen eher unwichtig, ist es mit der „Desktop First“ Variante einfacher, Antworten auf Fragen wie „Wie ordne ich meine Inhalte an?“ oder „Welchen Gesamt­eindruck möchte ich erhalten?“ zu bekommen [4]. In manchen Fällen ist bereits eine Desktop-Lösung vorhanden, wodurch sich diese Fragestellung erübrigt. Prototyping In der Praxis hat sich außerdem gezeigt, dass Hilfsmittel wie Photoshop oder Fireworks aufgrund ihrer fixen Größenangaben bei responsiven Designs schnell an ihre Grenzen stoßen. Aus diesem Grund ist es zu empfehlen, dass der UI-Designer seine Ideen zu einer responsiven Layoutstruktur schon frühzeitig in leichtgewichtige HTML-Prototypen überführt. Diese sehr einfachen Prototypen dienen lediglich dem Zweck, das Layout und sein Verhalten auf mehreren unterschiedlichen Bildschirmgrößen zu testen. Dabei empfiehlt es sich, so viele unterschiedliche Bildschirmgrößen wie möglich, jedoch zumindest die typischen Größen genauer unter die Lupe zu nehmen. Das Testen der leichtgewichtigen HTMLPrototypen auf den verschiedenen Endgeräten gibt dabei dem UI-Designer unmittelbar Hinweise darauf, wie er das UI „umgestalten“ muss, um eine möglichst optimale Platzausnutzung und Bedienbarkeit zu gewährleisten. Die dabei gewonnenen Erkenntnisse sollten wiederum in den Prototypen eingearbeitet werden, um durch diese iterative Vorgehensweise zwischen Grobkonzeption und Testen ein stabiles Layoutkonzept zu entwickeln. Erst danach wird mit der Feinkonzeption, wie zum Beispiel dem Erstellen der benötigten Controls und ihrer Positionierung in den einzelnen Layoutmodellen begonnen. Auch

dabei gilt es, sich stets an ein frühes und kontinuierliches Testen zu halten, da nur so alle Bildschirmgrößen gleichermaßen berücksichtigt werden können. Das Ergebnis der Konzeption beinhaltet das flexible UI-Layout und die darin positionierten Controls, Media Daten und sonstige Inhalte. Validierung Die responsiven Besonderheiten der Validierungsphase sind in dem notwendigen erweiterten Testumfang wiederzufinden. Das Design sollte dabei auf möglichst allen unterschiedlichen Bildschirm- und Plattformtypen getestet werden, um ein möglichst allumfassendes Bild des responsiven UI zu erhalten. Es empfiehlt sich, die Validierungsergebnisse schriftlich zu dokumentieren und bei Bedarf in das bisher entstandene Applikationslayout zu überführen. Spezifizierung Für die Spezifizierung responsiven Designs bietet es sich an, die klassischen Spezifi­zie­ rungsdokumente mit den in der Design­ phase erstellten HTML-Prototypen anzu­ reichern, um so den Entwicklern die Mög­­lichkeit zu geben, das UI und sein Verhalten besser zu verstehen. Viele responsive UI-Besonderheiten sind schwierig textuell zu beschreiben und können besser anhand von Prototypen verdeutlicht werden. 4.2. Responsives Design anhand eines ­praktischen Beispiels Die im Folgenden demonstrierten praktischen Beispiele für responsive UI-Elemente entstammen einer Webapplikation der SAP AG, die Manager bei ihren Verwaltungs- und Planungsaufgaben unterstützt. Aufgrund der agilen Arbeitswelt der Manager eignet sich eine responsive Umsetzung der Applikation ganz besonders. Als primäre Zielplattformen galt es dabei, die mobilen iOS Geräte wie iPad und iPhone besonders im Auge zu behalten. Desweiteren sollten mobile Android- und WindowsGeräte unterstützt werden, allerdings mit einer geringeren Priorität.


Usability Professionals 2013 Responsive UX

Master-Detail-Konzept Das im Landscape Mode eines Tablets angewandte Master-Detail-Konzept mit einem feststehenden Master-Bereich auf der linken Seite des Screens und dem Detail-Bereich rechts davon funktioniert auf allen querformatigen Tabletausrichtungen als ein plattformübergreifendes Interaktionskonzept gleichermaßen gut. Dieses einfache, im mobilen Kontext sehr häufig vorkommende UI-Pattern kommt auch in dieser Web-Applikation zum Einsatz. [Abb. 12]

Abb. 12. Shopping Cart im ­Landscape Mode auf dem iPad [14]

Im Portrait Mode wird der Master-Bereich ausgeblendet und der Detail-Bereich zu einem Eintrag nimmt den vollständigen Bildschirm des Gerätes ein. [Abb. 13] Die „Shopping Cart“-Einträge lassen sich durch einen Button in der linken oberen Ecke ein- und ausblenden. [Abb. 14] Auf den kleineren Bildschirmen der Smartphones wäre eine analoge Transformation dieses Tablet-Layouts aufgrund des eingeschränkten verfügbaren Platzes nicht sinnvoll, weshalb dieses UI-Pattern eine separate Darstellungsvariante von Masterund Detail-Bereich erfordert. [Abb. 15], [Abb. 16] Für diese Darstellungsvariante ist jedoch eine neue Navigationsmöglichkeit im responsiven Design vorzusehen, um von dem Detail-Bereich wieder zurück in den Master-Bereich wechseln zu können. Fly-Out vs. Fullscreen-Konzept Eine Methode, detailliertere Informationen zu einem UI-Element anzuzeigen, ist die Verwendung eines Fly-Out Containers, der über dem Content-Bereich liegt. [Abb. 17], [Abb. 18] Dieses Konzept, das weitestgehend auf Geräten mit größeren Bildschirmen, wie Tablets und stationären Geräten zu finden ist, ist für die kleinen SmartphoneScreens nicht immer sinnvoll und es empfiehlt sich, ab einer bestimmten Informationsmenge einen eigenen Screen für die Informationen vorzusehen. [Abb. 19], [Abb. 20] Hierzu sind die oben erwähnten „Media Queries“ und flexiblen Größenangaben vonnöten, damit sich das Layout an alle Smartphone-Bildschirmgrößen anpasst.

Abb. 13. Shopping Cart Element-Detailansicht auf dem iPad im Portrait Mode [14]

Abb. 15. Shopping Cart Master-Screen auf dem iPhone [14]

Abb. 14. Shopping Cart im Portrait Mode auf dem iPad mit eingeblendetem Master-Bereich [14]

Abb. 16. Shopping Cart Detailseite auf dem iPhone [14]

127


4.3. „Dos and Don’ts“ in responsiven Designprojekten In diesem Abschnitt werden „Dos and Don'ts“ in responsiven Designprojekten aufgeführt, die durch die Projekterfahrungen entstanden sind. Die hier aufgelisteten Ratschläge sind als grundlegende praktische Empfehlungen für responsive Designprojekte zu verstehen. [Tab. 1] 5. Fazit Abb. 17. Kalenderdarstellung auf dem iPad [14]

Abb. 18. Kalenderdarstellung auf dem iPad mit geöffnetem Fly-Out [14]

Abb. 19. Kalenderdarstellung auf dem iPhone [14]

128

Abb. 20. Separater Screen zum Anlegen eines „Cost Assignments“ [14]

Wie das vorangegangene Kapitel 4 zeigt, ist der Gestaltungsprozess für ein responsives Design eine aufwendige, komplexe Aufgabe, die das gleichzeitige Konzipieren eines flexiblen Layouts für verschiedene Bildschirmgrößen erfordert. Die kontinuierliche Verbreitung [5] und der wachsende Einsatz mobiler Geräte in Unternehmen machen Cross-Platform-Lösungen jedoch unabdingbar. Der Trend, Mitarbeitern zu erlauben, ihr (privates) mobiles Gerät geschäftlich zu nutzen („Bring your own Device“) verschärft das Problem der Gerätefragmentierung zusätzlich. Die gemeinsame Codebasis eines responsiven Designs trägt hierfür zwar zum Einen zu einer wirtschaftlichen, also kostengünstigen Implementierungsphase bei und hält den zukünftigen Wartungsaufwand gering, erzeugt aber zum Anderen einen sehr hohen Aufwand in den oben genannten Designprozessen. Diese Balance aus Aufwänden in Design und Entwicklung erscheint symptomatisch für Projekte dieser Art und muss für jede Anwendung neu austariert werden. Abschließend lässt sich die Anfangsfrage „Responsives UI Design – Wirkungsvolles Mittel gegen zunehmende Gerätefragmentierung?“ zwar mit „Ja“ beantworten, allgemeingültig ist diese Antwort jedoch aufgrund des variablen Aufwand-NutzenVerhältnisses nicht. Bei Applikationen, die ein komplexes User Interface erfordern, muss genau zwischen diesem Verhältnis abgewogen werden, da die Kosten, die beim Umsetzen des Designs entstehen,


Usability Professionals 2013 Responsive UX

Dos

Don’ts

–– Sorge für ein teamweites Wissen und Verständnis

–– Einsatz von fixen Layouting-Tools

–– Durchdringe deine Zielplattformen und lerne

–– Entwicklungsbeginn vor Abschluss und

–– Teste dein Layout mit leichtgewichtigen Prototypen

–– 1:1 Übertragung des Designs von Desktop

–– Stelle die Prototypen den Entwicklern in der

–– Verzicht auf relevante Inhalte aufgrund von

über responsives Design.

ihre User Experience im Details kennen.

so früh und auf so vielen Plattformen wie möglich.

­anschließenden Entwicklungsphase zur Verfügung.

(z.B. Photoshop oder Fireworks) Abnahme des Designs auf Mobile

Platzmangel. Inhalte sollten in diesem Falle anderweitig zugänglich gemacht werden.

–– Sprich mit langjährigen Benutzern der

­Plattformen über deine Layout-Entwürfe.

Tab. 1. Dos and Don’ts

–– Dokumentiere das Verhalten des Layouts durch ­anschauliche Mittel.

das Verhältnis von Aufwand und Nutzen negativ beeinflussen. Um die ohnehin sehr umfangreiche Konzeptionsphase nicht ausufern zu lassen, ist zu empfehlen, responsives Design bei überschaubaren und nicht zu komplexen Applikationen anzuwenden, denn nur bei solchen Anwendungen können die Aufwendungen für die Designphase möglichst gering und die positiven Effekte, die durch die gemeinsame Codebasis in der Implementierung und Wartung auftreten, klein gehalten werden.

Literatur 1. Ethan Marcotte, Responsives Web Design, A Book Apart ,(2011) 2. W3C, Media Queries http://www.w3.org/ TR/2012/REC-css3-mediaqueries-20120619/ (27. Juni 2013) 3. Peter-Paul Koch, Stephanie Rieger et al, The Mobile Book, Smashing Magazine (2012) 4. Christoph Zillgens, Responsive Webdesign, Carl Hanser Fachbuchverlag, (2012) 5. Gartner, Inc., Worldwide PC, Tablet and Mobile Phone Combined Shipments, http:// www.gartner.com/newsroom/id/2408515 (27.

Wegen dieser Verlagerung ist für die gezielte Vorhersage der Darstellungsfaktoren und die sinnvolle automatische Anpassung der Applikation die enge Zusammenarbeit von Designern und Entwicklern zwingend vonnöten. Das hochgesteckte Ziel liegt in einer homogenen (Marken-) Darstellung des User Interface bei gleichzeitig größtmöglicher Gerätekompatibilität und Wirtschaftlichkeit.

Juni 2013) 6. Luke Wroblewski, Multi Device Layout Patterns, http://www.lukew.com/ff/entry. asp?1514 (27.Juni 2013) 7. Wee Nudge, http://weenudge.com/ (22. August 2013) 8. Tim Wendorff, Native Apps vs. Webapps, http://onlinemarketing.de/news/native-appsvs-webapps (8. Juli.2013) 9. Javier Lo, http://www.javierlo.com/ (27. Juni 2013) 10. Unicef Deutschland, http://m.unicef.de/ (27. Juni 2013) 11. Starbucks, http://www.starbucks.de/ (27. Juni 2013) 12. ClearLeft, http://2012.dconstruct.org/ (27. Juni 2013) 13. SycamoreSchool, http://sycamoreschool.org/ (27. Juni 2013) 14. SAP AG, https://experience.sap.com/fiori (17. Juli 2013)

129


Herausforderungen für UX-Teams in „Responsive Design“-Projekten im agilen Kontext Ein Beispiel für die Zusammenarbeit im Projektalltag von mobile.de Michael Fleck USEEDS° GmbH Friedrichstr. 209 10969 Berlin michael.fleck@useeds.de

Stephan Köpp mobile.international GmbH Marktplatz 1 14532 Europarc Dreilinden skoepp@team.mobile.de

Abstract Die Integration von User Experience in agilen Entwicklungsprozessen stellt sowohl das UX-Team als auch die IT vor Herausforderungen: Wie kann man in optimaler Weise zusammenarbeiten und die Nutzerbedürfnisse bestmöglich in den Prozess integrieren? Welche Anforderungen kommen hinzu, wenn es sich um die Umsetzung mittels Responsive Design handelt? Am Beispiel eines Projektes von mobile.de und USEEDS° wird verdeutlicht, wie dies durch enge Zusammenarbeit und frühzeitige Abstimmung der verschiedenen involvierten Disziplinen gelingen kann und worauf dabei geachtet werdensollte.

Einleitung

Das Projekt

Der Nutzer ist es mehr und mehr gewohnt, seine Wünsche, Ziele und Aufgaben auch mobil unterwegs realisieren zu können. Die Optimierung des Serviceangebotes für Smartphones ist daher die logische Konsequenz. Neben der Erstellung nativer Apps für iOS und Android gibt es dabei auch die Möglichkeit, losgelöst von bestimmten Plattformen eine sich an Bildschirmgrößen anpassende Webseite im Responsive Design zu erstellen.

Zu Beginn des Jahres 2012 entschied sich mobile.de, Deutschlands führender OnlineFahrzeughandelsplatz, den Ansatz der Plattformunabhängigkeit für den Bereich des innereuropäischen Fahrzeugmarktes zu realisieren. Im Projekt „Europäisches Schaufenster“ sollten insbesondere Käufer aus den Ländern Tschechien, den Niederlanden und Bulgarien in den Genuss einer sowohl für Desktop-Systeme als auch mobile Endgeräte optimierten Oberfläche kommen. Für den User Research, die Konzeption sowie das Visual Design holte man USEEDS°, eine nutzerzentrierte Design- und Usability-Agentur aus Berlin, mit an Bord.

Immer häufiger kommen dafür agile Ent­ wicklungsmethoden zum Einsatz. Im Kern geht es dabei um die Erstellung von Soft­ ware in transparenten und flexiblen Teil­ pro­zessen durch ein iteratives Vorgehen, bei dem sich Planungs- und Entwicklungsphasen abwechseln. Ist man als externer Dienstleister dafür verantwortlich, die User Experience (UX) in diesen Prozess zu integrieren, steigen die Anforderungen für beide involvierte Seiten. Dieser Artikel beschreibt die Herausforderungen in einem derartigen Projekt und stellt eine konkrete Herangehensweise vor, wie man diese meistern kann.

130

Die strategischen Ziele des Projektes waren: –– es sollte ein Portal generiert werden, welches die Nutzerströme aus dem nicht-deutschsprachigen europäischen Ausland kanalisiert –– auf Bedürfnisse speziell dieser Zielgruppe sollte in der Anwendung eingegangen werden –– für die Optimierung der Wartbarkeit und Kosteneffizienz sollte eine Web­ seite mittels Responsive Webdesign erstellt werden, da eine Ausarbeitung auf drei Plattformen und damit mit

Keywords: /// Responsive Design /// Agile /// User Experience

drei Entwicklungsteams (iOS, Android, Web) mit zu hohen Aufwänden verbunden gewesen wäre Insgesamt sollte das umfangreiche Fahr­ zeugangebot von mobile.de in den er­­wähn­ ten Ländern besser vermittelbar werden, zu stärkerem Absatz bei Fahrzeughändlern in Deutschland sowie zu erhöhter Zufriedenheit und einer ganzheitlichen Einkaufserfahrung bei den Anwendern führen. Mobile.de setzte in der Umsetzung auf eine Entwicklung in agilen SCRUM-Teams. Diese waren crossfunktional aufgestellt, d.h. neben Front- und Backend-Entwicklern waren auch ProductOwner und Quality Assurance im Team integriert. Herausforderungen Insbesondere für den UX-Dienstleister USEEDS° stellten sich dabei folgende Herausforderungen: –– Wie arbeitet man in diesem Setting als externer Partner bestmöglich mit Stakeholdern und dem Entwicklerteam auf Kundenseite zusammen? –– Wie integriert man UX in einen agilen Entwicklungsprozess? Wie können hierbei die Nutzerbedürfnisse best­ möglich berücksichtigt werden?


Usability Professionals 2013 Responsive UX

–– Wie konzipiert / designt man für Res­­pon­sive Design? Erstellt man ein Konzept, drei oder mehr Konzepte? Sind die Inhalte von mobile.de (kom­­ plexe Formulare und Ergebnis­listen) überhaupt für dieses Vorgehen taug­ lich? Wie sehen die Deliverables aus? Vorgehen In der Anbahnungs- und Angebotsphase wurden unter Zuhilfenahme der „Project Canvas“ (Kalbach 2012) der Kontext, alle Meilensteine, Verantwortlichkeiten und Risiken des Projekts ermittelt. Für die grundlegende Zusammenarbeit von mobile.de und USEEDS° wurde sich auf einen Prozess verständigt, der von beiden Parteien eine sehr enge Abstimmung verlangte. [Abb. 1] Das Projekt wurde in zwei Hauptphasen gegliedert, die Discovery- und die Sprint-Phase. In der

Discovery-Phase wurden Grundlagen der technischen und gestalterischen Umsetzung ermittelt und erprobt. Die SprintPhase hin­­gegen markierte den Zeitraum der eigent­­lichen technischen Umsetzung in agilen Entwicklungsteams. Für die sinnvolle Koor­di­nation der einzelnen Beteiligten und des zeitlichen Ablaufs wurde in Anlehnung an Cagan (2005) eine versetzt aufeinander aufbauende Kooperation verwendet. Das bedeutete, dass USEEDS° bereits am nächsten Themenpaket arbeitete, während mobile.de die im vorigen Sprint erarbeiteten Vorgaben aus Konzept und Design umsetzte. Dies erforderte gerade von bisher nicht agil arbeitenden Design- und Konzeptteams große Disziplin und Fokussierung, um die vorgegebene enge Taktung der Sprints auf Kundenseite (14 Tage Sprint­dauer) zu verinnerlichen und sich darin ein­zu­fügen. Das Prinzip der engen Abstimmung ermöglichte es, Redundanzen zu minimieren, schnell Feedback

einzuholen und darauf reagieren zu können und somit sich als UX-Dienstleister nahtlos in den Entwicklungsprozess zu integrieren. Dem Frontend-Entwickler auf Seiten von mobile.de kam in dieser Konstellation eine besondere Rolle zu, da er neben dem Product Owner der Hauptansprechpartner für das USEEDS-Team war. Er war bei allen Workshops sowie Feedback- und Abstimmungsrunden dabei, konnte so direkt mit dem Konzepter und Designer interagieren und frühzeitig Machbarkeiten klären sowie geplante Funktionalität modularisieren und in sein eigenes Entwicklerteam weitergeben. Discovery-Phase In der Discovery-Phase planten nach ­the­­matischer Absprache USEEDS° und mobile.de jeweils einzeln ihr Vorgehen und ihre Agenda und gaben sich regel­ mäßig Feedback.

Abb. 1. Arbeitsprozess und Zusammenarbeit von Development und UX

131


Im Schnitt wurden 350 Teilnehmer pro Land unter Anderem zu ihrer favorisierten Zahlungsart, den verwendeten Endgeräten, den wichtigsten Attributen bei der Fahrzeugauswahl sowie generellen Hürden beim Fahrzeugkauf im Ausland befragt. Eine Kernfrage war die nach der bisher verwendeten und zukünftig präferierten Sprache der Kontaktaufnahme. Der Wunsch nach Natürlichsprachlichkeit, d.h. ein Tscheche möchte in Tschechisch mit dem deutschen Fahrzeughändler in Kontakt treten, um seine Anfrage möglichst präzise und lückenlos übermitteln zu können, stellte sich neben vielen anderen bestätigten Annahmen (Kostentransparenz, Wunsch nach Dienstleisternetzwerk etc.) als ein wichtiges Nutzerbedürfnis heraus.

Abb. 2. Aufbereitung der Ergebnisse der Online-Umfrage (Erhebungsdauer: 7 Tage, Teilnehmer: ca. 350 pro Land)

Auf mobile.de Seite wurden vor allem Backendentscheidungen getroffen und erste Kandidaten für eine Frontend-Technologie erprobt. Ein Hauptaugenmerk lag dabei auf der Performance der Webseite, da mobile Endgeräte (3G) ebenso wie Desktop (DSL) bedient werden mussten. Gleiches galt für den Umgang mit Medieninhalten, vorrangig Bildern: Welche Technologien und Strategien sollten verwendet werden, um Ladezeiten möglichst kurz zu halten und dabei die User Experience nicht zu unterbrechen? Für USEEDS° bestand die Discovery-Phase aus User Research, ersten Uses Cases und Szenarien, Scribbles, Papierprototypen, einer Grobkonzeption und Designexploration. Da diese Etappe der eigentlichen agilen Zusammenarbeit vorgelagert war,

132

konnten aufwändigere Researchmethoden angewendet werden, als sie später in den engen zwei Wochen Zyklen möglich gewesen wären. Um für den Nutzer gestalten zu können, muss man den Nutzer verstehen. Daher galt es, eine möglichst umfassende Analyse des Anwenders und seines Nutzungskontextes vorzunehmen. Die Betrachtung der Google Analytics-Daten hatte ergeben, dass bei der mobilen Nutzung ein großer Bedarf an Optimierung bestand. Um möglichst viele echte Anwender der Seite befragen zu können, wurde eine Online-Umfrage direkt auf mobile.de in den jeweiligen Ländern (Tschechien, Niederlande, Bulgarien) als optimal passende Methode angewandt. [Abb. 2]

Diese Erkenntnisse wurden frühzeitig an die Verantwortlichen bei mobile.de zurückgespielt, um so bereits an technischen Lösungen arbeiten zu können, mit Drittanbietern (z.B. Google Translate, Microsoft Bing) in Kontakt zu treten oder dem Konzept weiter zuzuarbeiten. Dieses sah in diesem konkreten Fall vor, dass statt dem bisher für die Kontaktaufnahme mit dem Fahrzeughändler verwendeten Freitextfeld ein an ein Anschreiben angelehntes Formular dem Nutzer die initiale Kommunikation erleichtern sollte. Nur persönliche Daten, wie Name oder E-Mailadresse mussten noch eingegeben und aus einem vorbereiteten Fragenpool die gewünschten Fragen ausgewählt werden. Diese Fragen konnten mit Hilfe einer Analyse von Kundenserviceanfragen so durch mobile. de bereits vorbereitet werden. Konzipiert man für Responsive Design sind Entscheidungen über den „normalen“ Konzeptionsprozess hinaus zu treffen. Zum Einen muss man sich mit der Frage beschäftigen, welche Devices bedient werden sollen, zum Anderen welchen Inhalt man auf den jeweiligen Kanälen spielt, und ob Features im mobilen Kontext weggelassen werden können. Für die Geräteentscheidung halfen Business-Ziele und Analyticsdaten (Desktop 1024 px Breite, iPad portrait, iPhone portrait).


Usability Professionals 2013 Responsive UX

Abb. 3. Design-Entwürfe aus der Exploration

Die Ermittlung der Inhalte pro Seite und Geräteklasse gestaltete sich gerade bei mobile.de und dem Formular- und Ergebnislistenlastigen Content etwas anspruchsvoller. Dazu wurde sich im ersten Schritt mit dem Kunden auf eine bestimmte Keyscreen-Strecke verständigt (Homepage, Detailssuchseite, etc.). Anschließend musste festgelegt werden, in welcher Art die Wireframes zu erstellen sind. Um die User Experience auf jeder der drei definierten Geräteklassen sicherzustellen, wurde entschieden, dass für jede Klasse (Desktop, iPad, iPhone) ein eigenes Konzept erstellt wird, d.h. jeder Flow in jeder definierten Bildschirmgröße. Im nächsten Schritt war es sehr hilfreich, mit groben Blöcken zu skizzieren, wie und vor allem wo welcher Inhaltsbereich in den jeweiligen Seiten dargestellt werden würde. Begonnen wurde dabei von der kleinsten abzubildenden Screengröße bis hin zur Größten. Dieser „Mobile First“

Ansatz half bei der Kommunikation mit den Stakeholdern, um Content zu priorisieren und Features der Seite richtig bewerten zu können. Zeitgleich definierten die Designer bei USEEDS gemeinsam mit den FrontendEntwicklern bei mobile.de ein Grid, auf dessen Basis eine Spaltenaufteilung für die Webseite entstehen konnte. Darin war es nun möglich, die konkreten Inhalte, die auf Suchportalen üblichen komplexen Eingabemasken und Ergebnislisten auf ihre Machbarkeit in diesem Grid hin zu testen. Dies bestätigte sich, so dass sowohl in der Desktop als auch in der mobilen Variante der Webseite dem Nutzer dieselben Inhalte angeboten werden konnten. Für die konkrete Auswahl der optimalen Interaktionspattern pro Geräteklasse war es notwendig, stets sowohl Desktop als auch mobile Pattern im Blick zu haben, um auf der einen Seite eine möglichst

homogene Nutzererfahrung pro Device aber auch unter den Geräteklassen selbst erreichen zu können. Oft wurden Kandidaten für Interfaces mit den Entwicklern abgesprochen und durch ein schnelles Ausprobieren eine Entscheidung herbeigeführt. Dahingehend fungierte der Frontend-Entwickler als eine Art Schnittstelle zwischen Grob- und Feinkonzept. Weiterhin führte das Visual Design Team von USEEDS° in der Discovery-Phase eine Design Exploration durch. Damit konnte sich früh im Prozess auf die Anmutung der Seite verständigt werden und erste Gestaltungsentwürfe entstehen. [Abb. 3] Genauso wie in der Konzeption mussten im Design sämtliche definierte Geräteklassen gleichzeitig berücksichtigt werden, um einen Styleguide definieren zu können, der eine homogene User Experience über alle Devices hinweg entstehen lassen konnte.

133


Abb. 4. Finales Design der Anwendung auf www.mobile.de/cz

Sprint-Phase Die Sprint-Phase war ebenfalls geprägt von sehr enger Abstimmung. Durch die Kürze der agilen Sprints in der Entwicklung musste diese aber noch intensiver und kurzfristiger erfolgen, da sonst Verzögerungen in der Codeerstellung die Folge gewesen wären. Die Hauptaufgabe von mobile.de war nun die eigentliche Implementierung des aktuellen Sprint-Themas. USEEDS° erstellte in dieser Phase das Feinkonzept, d.h. die Ausformulierung der Wireframes und die Dokumentation des Verhaltens der dargestellten Elemente sowie das Design für das nächste Sprintthema. Dafür wurden vorrangig gängige Tools wie Fireworks oder AXURE verwendet. Mobile.de war in Diskussion, Ideation und Bewertung von

134

Features stark involviert. Dies garantierte konkretes und direktes Feedback der Entwickler und so eine spätere Umsetzbarkeit und Portierbarkeit auf alle definierten Devices. Oft kamen auch Prototypen zum Einsatz, um Haptik und Funktionalität besser erlebbar und einschätzbar zu machen. Abstimmungsrunden verliefen oft ad hoc, da der ProductOwner und Frontend-Developer an allen Workshops und Feedbackrunden teilnahmen und so die Entscheidungswege sehr kurz gehalten werden konnten. Die fertigen Designs wurden mobile.de als offene Grafikdateien (PNG, PSD) geliefert. So konnten sich die Entwickler ohne Abstimmung, Zusatzaufwand individuell und je nach Bedarf ihre Assets selbstständig erzeugen. Zusätzlich zur Designerstellung wurde darüberhinaus auch das Verhalten des Seiteninhalts bei Darstellung in Nicht-Key-Devices definiert.

Diese sogenannten „Wachstumsflächen“ beschreiben im Konzept und in der Gestaltung wie Content umbricht und wo Fluid Grids wirklich ihre variablen Eigenschaften offenbaren können. Diese Festlegungen halfen den Entwicklern dabei, ein Grundgerüst der Seitenanordnung zu erstellen, auch wenn das Design noch nicht final abgenommen war. In die aktuelle Entwicklung der Anwendung war USEEDS° dahingehend involviert, als dass Sprint-Support bereitgestellt wurde und so während der Erstellung Designunterstützung geleistet werden konnte. D.h. es konnte auf noch fehlende Assets oder erst in der Entwicklung aufgetretene Zustände oder andere Herausforderungen schnell reagiert werden. Weiterhin konnte man sich durch einen Zugang auf die Testumgebung von mobile.de über


Usability Professionals 2013 Responsive UX

die Fortschritte informieren aber auch qualitätssichernd agieren. Auf Nutzertests wurde in dieser Phase ob des straffen Zeitplans verzichtet. Durch häufige direkte Kommunikation, die Vor-Ort-Termine (in der Agentur oder beim Kunden) mit allen Beteiligten und die starke Einbindung des Kunden in die Konzeptionsprozesse konnte eine hohe Zufriedenheit auf beiden Seiten erreicht werden. Gemeinsame ad hoc Ideation half, auftretenden Problemen schnell und unkonventionell zu begegnen. Mittels Zugang zur Testumgebung und Mitspracherecht bei vielen technischen Entscheidungen war für USEEDS° die Integration der ermittelten Nutzerbedürfnisse, die rasche Reaktion und Lösungsgenerierung bei Barrieren sowie eine gute QA in hohem Maße gegeben. Projektergebnisse Resultat ist ein ansprechendes und funktionales Produkt, welches auf den besonderen Informationsbedarf seiner europäischen Zielgruppe eingeht und gleichzeitig Unsicherheiten während des Fahrzeugkaufs im Ausland reduziert, indem es Vertrauen schafft. [Abb. 4] Durch „Responsive Design“ werden der mögliche Nutzungskontext und damit die ständige Verfügbarkeit der Anwendung erweitert. Die dynamische Anpassung des Seiteninhalts an das jeweilige Endgerät verringert langfristig den Entwicklungs- und Wartungsaufwand der Seite. Der mobile Traffic konnte seit der Einführung von unter 1% (1. Quartal 2012) auf ca. 9% (aktueller Stand 1. Quartal 2013) gesteigert werden. Aufbauend auf die initiale Umsetzung für Tschechien sind weitere Portale im Ausland geplant. Erkenntnisse und Fazit Die Herausforderung in diesem Projekt bestand neben den individuellen Eigenschaften (z.B. ist der komplexe Inhalt von mobile.de abbildbar im mobilen Kontext – JA) vor allem darin, eine für beide Parteien nützliche und sinnvolle Art der

Zusammenarbeit zu finden, zu optimieren und zu leben. Es musste sich vom generellen Rahmen bis hin zu konkreten Fragen der Linkgestaltung und Patternauswahl sehr eng abgestimmt werden. Sämtliche Projektbeteiligte – damit sind neben Entwicklung, Design und Konzept auch Research und weitere kundenseitige Stakeholder gemeint – sollten sich so früh wie nur möglich persönlich treffen, um ein gemeinsames Gefühl für das Vorhaben zu entwickeln und sich einbringen zu können. Das Commitment bezüglich eines gemeinsamen Ziels ist umso stärker, je mehr die einzelnen Beteiligten ihre Ideen äußern können und gehört werden. Mindestens ein initialer Gesamt-Workshop ist in derartigen Projekten nötig, schon um das verschiedene Wissen (Kenntnisse) z.B. über Realisierbarkeit im Responsive Design gegenseitig abzuklären. Für die Integration von User Experience in ein (agiles) Projekt muss auf Kundenseite im Management eine Bereitschaft und Offenheit vorhanden sein, einen erhöhten Zeitaufwand für gemeinsame Ideation und Workshops zu akzeptieren. Im konzeptionellen Bereich ist eine Erkenntnis aus dem Projekt „Europäisches Schaufenster“, dass man sich so früh wie möglich im UX Team mit dem FrontendEntwickler auf ein Grid /Raster verständigt und das Verhalten der UI-Elemente (wie verhalten sich diese im Fluid Grid) beschreibt und abstimmt. Dadurch hat das Development die Möglichkeit, über grundlegende Strukturen nach zu denken und diese entwickeln zu können. Um den Arbeitsaufwand und Scope des Projektes beherrschbar zu halten ist es ratsam, die Key Devices und Keypages vor Arbeitsstart klar festzulegen.

Konzepter-Teampraktikable Vorgehen herausgestellt. Durch die für ein TouchInterface optimierten und damit oft räumlich großzügig gestalteten Schaltflächen war sowohl eine Portierung in das mobile Layout als auch in das breitere DesktopGrid relativ leicht möglich. Aus technischer Sicht war eine wichtige Erkenntnis, dass in agilen Prozessen in denen UX-Teams so stark involviert sind wie in diesem Projekt, die Entwicklung auch den Mut haben muss, Entscheidungen (vor allem technischer Natur, Frameworks etc.), die im Laufe des Projektes getroffen wurden, bei Erkennen von zu hohem Umsetzungsaufwand revidieren zu dürfen. Das Projekt „Europäisches Schaufenster“ bot durch seine Aufstellung und die Offenheit des Kunden die Möglichkeit, Methoden, Prozesse und Herangehensweisen zu erproben, um Responsive Design in einem agilen Team umzusetzen. Damit bildete es die Grundlage für viele folgende Projekte mit ähnlicher Ausrichtung und half auch diese zu einem erfolgreichen Abschluss zu führen. Literatur 1. Cagan, M., Agile Development Processes, Onlinequelle von: http://www.svproduct.com/agiledevelopment-processes/ (Zugriff: 28.06.2013) 2. Kalbach, J., The Project Canvas – Defining Your Project Visually,Onlinequelle von:http://uxtogo. useeds.de/2012/05/25/the-projectcanvas-defining-your-project-visually/ (Zugriff: 28.06.2013)

Der Ansatz „Mobile First“ hat sich in diesem Projekt vor allem in der Content- und Feature-Gewichtung bewährt. Klare Priorisierung half, Wichtiges von Entbehrlichem zu unterscheiden. Bezüglich der Ausarbeitung der Wireframes und der konkreten Auswahl der UIFeatures hat sich die Methode, mit der Tablet-Größe zu beginnen, als das für das

135


136


UX Best Practices

137


Best Practice „Tele-Medizintechnik“: User-Experience-Design eines gesamt­ heitlichen Blutzuckermesssystems Einblicke in die Prozessstandards bei der umfassenden Gestaltung von der Softwarearchitektur über Gerätefunktionen und Bedienoberflächen bis zur Anleitungs- und Verpackungskommunikation Oliver Gerstheimer chilli mind GmbH Königstor 23 34117 Kassel www.chilli-mind.com gerstheimer@chilli-mind.com

Steffen Wüst chilli mind GmbH Königstor 23 34117 Kassel www.chilli-mind.com wuest@chilli-mind.com

Abstract Die kundengerechte Gestaltung eines gesamtheitlichen Blutzuckermesssystems aus Messgerät, Online- und mobilem digitalen Tagebuch sowie Kommunikationsmitteln – auch „Cross-Channel-Usability“ genannt – beschreibt das integrative Design-Vorgehen im Rahmen von Konzeption und Ausgestaltung eines Diabetes-Management-Systems für die Zielgruppen B2C (Betroffene, Angehörige) und B2B (Ärzte, Fachpersonal) über alle Medien und Gestaltungsobjekte hinweg: von den Hardware-Funktionen über die SoftwareBedienoberflächen bis zum Entwurf des gedruckten Benutzerhandbuchs. Im Fokus des Beitrags steht die Darstellung der Notwendigkeit eines standardisierten Prozessvorgehens bei der übergreifenden und einheitlichen Ausgestaltung unterschiedlicher Kommunikations- und Interaktionskanäle im Gesamtsystem unter Berücksichtigung von User-Experience-Design und Usability-Aspekten. Zusätzlich werden Problem- und Fragestellungen zu Einzelaspekten des Entwurfsprozesses beleuchtet, z. B. dem User-Experience-Testing von Einzelelementen und des Gesamtsystems. Dies alles vor dem Hintergrund widerstrebender Anforderungen der Stakeholder in der Produktentwicklung. Vor allem die Gestaltung eines Produkt-Systems nach dem „End-to-End“-Prinzip schafft hierbei neue Herausforderungen und Schnittstellennotwendigkeiten, sowohl in der Standardisierung wie auch bei Projektkommunikation und -koordination.

1. Ausgangssituation und Zielsetzung 1.1. Systembeschreibung Diabetiker sind auf eine häufige, regelmäßige Kontrolle und Dokumentation der Blutzuckerwerte angewiesen, welche eine Grundlage zur Berechnung ihrer individuellen Medikation bilden. Blutzuckermesssysteme in der privaten Anwendung bestehen bislang zumeist aus einem portablen Messgerät mit entsprechendem Zubehör und einem analog zu führenden Diabetestagebuch. Die Notwendigkeit eines Tagebuchs ergibt sich aus der Zielsetzung, den Blutzuckerspiegel des Betroffenen wegen der gestörten Insulinproduktion bzw. -rezeption künstlich durch

138

medikamentöse Insulingabe, Nahrungsaufnahme und Aktivität möglichst stabil zu halten. Analoge Diabetestagebücher sind nicht in der Lage, Kurvenverläufe und Auswertungen über einen frei definierbaren Zeitraum darzustellen und so diese Zielsetzung zu unterstützen. Zudem ist die Eintragung zusätzlicher Werte (z. B. Nahrungsaufnahme, Medikamentengabe, Aktivität und Anmerkungen zur körperlichen Verfassung) aufwändig und wenig standardisiert. Die B. Braun Melsungen AG greift als Auftraggeber in der Entwicklung des Omnitest Blutzuckermesssystems die relevantesten Anforderungen zur Optimierung dieser Ausgangssituation auf und bildet ein gesamtheitliches Diabetes-Management-System

Dr. Michael Hartmann Director Marketing and Development CoE Diabetes Care B. Braun Melsungen AG 34212 Melsungen michael.hartmann@bbraun.com

Keywords: /// Medizintechnische Produkte /// Consumer Interfaces /// User-Experience-­ Management /// Nutzerzentrierter ­Entwicklungsansatz /// Agiles mehrstufiges Projektmanagement

aus Hardware (Omnitest 3D mit GSMModul zur automatisierten Übertragung von medizinischen Werten), medizintechnischer Analyse-Software, zentralem Datenbank-Server, browserbasiertem OnlineDiabetestagebuch (Omnitest Center) und mobiler Diabetestagebuch-Applikation (Arbeitstitel: Omnitest Mobile) zur optimierten Erfassung, Dokumentation, Auswertung und Visualisierung von medizinischen ­Messwerten. [Abb. 1] 1.2. Vorteile für den Nutzer Ziel des Projekts ist die Erhöhung der Lebensqualität für den an Diabetes Erkrankten. Diese resultiert einerseits aus Zeitgewinn und erhöhtem Komfort bei der teilweise automatisierten


Usability Professionals 2013 UX Best Practices

Dokumentation, Auswertung und Visualisierung der Vitalwerte. Andererseits werden durch das optimierte Management langfristig Begleit- und Folgeerkrankungen reduziert. Dies hat neben den individuellen Vorteilen für die Betroffenen selbstverständlich auch Auswirkungen auf die gesamtwirtschaftlichen Gesundheitskosten, da weltweit, zunehmend auch in Schwellenländern, die Zahl insulinpflichtiger Patienten stark zunimmt. 1.3. Herausforderung und Alleinstellungs­ merkmale des Systems Eine Reihe von Projekten und Produkten verfolgen das Ziel, das Management von Diabeteserkrankungen durch elektronische Hilfen zu optimieren. Bisherige Konzepte präferieren allerdings durchweg einen isolierten Ansatz, da zumeist lediglich die (manuelle) Übertragung von Blutzuckermesswerten auf ein digitales Diabetestagebuch im Fokus steht. Ein kundenfreundlich auszugestaltendes Diabetes-Management-System stellt die bedürfnis- und usabilitygerechte Nutzung für Patienten mit spezifischen Anforderungen, sowie optimierte

Kommunikationsprozesse in einem „End-to-End“-Konzept (vom Blutstropfen bis zur langfristigen Auswertung) in den Vordergrund. Betroffene, pflegende Angehörige und medizinisches Fachpersonal werden unterstützt durch: – Automatisierte Prozesse in der Erfassung und Dokumentation von Messwerten; – Spezifische Algorithmen für Analyseund Auswertungsfunktionen; – Individuelle Visualisierungen von Zeitabschnitten, Messwertreihen und kumulierten Tagesverläufen; – Automatisierte Benachrichtigungen bei abweichenden und kritischen Messwerten; – Vereinfachten und automatisierten Datenaustausch zwischen Patienten und betreuenden Ärzten oder medizinischem Fachpersonal. 2. Entwicklungsansatz und Projektschritte Die Durchführung des Projekts erfolgte in einem mehrstufigen Phasenmodell, dessen Ergebnisse nachfolgend in Form von „Lessons Learned“ aufgezeigt werden.

Welche Vorteile bietet dieser mehrstufige und iterative Entwicklungsansatz?

Durch die aufeinander aufbauenden, iterativen Entwicklungsschritte wurde die Beachtung nutzerspezifischer, technischer und rechtlicher Anforderungen und Vorgaben im Entwurfsprozess sichergestellt. Die detaillierte Dokumentation von Spezifikationen bildete hierbei die Grundlage zur Überprüfung der Milestones im Entwicklungs- und Umsetzungsprozess. Die in jedem Prozessschritt integrierte Qualitätssicherung der Einzelschritte, Teilergebnisse und des Gesamtergebnisses spielte, auch vor dem Hintergrund der ausdrücklichen Dokumentationspflichten medizintechnischer Entwicklungsprozesse, eine zentrale Rolle. So konnten frühzeitig Abweichungen und suboptimale Ergebnisse identifiziert werden. In der Folge wurden Spezifikationen und Entwürfe angepasst, überarbeitet, ergänzt und konnten als Änderungsanforderungen (Change Requests) in den Entwicklungsprozess integriert werden. Erst dieser schrittweise und integrative Entwicklungsprozess garantierte die Handhabbarkeit eines komplexen, letztendlich

Abb. 1. Omnitest Gesamtsystem

139


Abb. 2. Zwei Beispiele für Personas (Kurzbeschreibung)

auch agilen Entwicklungsprozesses und der darin auftretenden Abhängigkeiten und Seiteneffekte zwischen den Einzelelementen des Gesamtsystems. 2.1. Anforderungsanalyse 2.1.1. Persona Design Als Grundlage der Anforderungsanalyse wurden nach Briefing-Gesprächen mit dem Auftraggeber (Produktmanagement, Marketing & Sales) und weiteren Experten vier prototypische Patienten-Personas sowie eine professionelle Persona definiert. Zielsetzung war die Abbildung eines breiten Nutzerspektrums hinsichtlich Alter, Nutzungsverhalten und technischer Affinität in Abstimmung mit real existierenden Patienten- und Nutzertypen. Lesson Learned Die szenarisch zugspitzte Identifikation und Beschreibung von Nutzertypen in Form von prototypischen Personas ermöglicht es dem Gestalter, ein „Gefühl“ für die Zielgruppe zu entwickeln und bildet die

140

essenzielle Grundlage von Anforderungsund Funktionsspezifikationen. [Abb. 2] 2.1.2. Anforderungsdefinition Das Anforderungsprofil an ein Blutzuckermesssystem orientiert sich vorrangig an besonderen Erfordernissen und Einschränkungen, welche vor allem langjährige Diabeteserkrankungen mit sich bringen können. In Interviews auf Basis des Persona Designs wurden eine Reihe zentraler Akzeptanz-Kriterien identifiziert, welche allerdings in ihrer Ausprägung variieren. Einige dieser Kriterien sind z. B.: – Leichte Handhabung des Messgeräts und gute Ablesbarkeit des Displays wegen evtl. Einschränkung der taktilen Fähigkeiten und der Sehkraft; – Intuitive Nutzbarkeit aller Komponenten des Gesamtsystems, vor allem für ältere und technisch weniger affine Nutzergruppen; – Schnelle Messung und Dokumentation des Blutzuckerwerts da z. T. mehr als fünf mal pro Tag gemessen werden muss;

– Automatische Übernahme von Messwerten und optionaler Zusatzwerte in ein digitales Diabetestagebuch als Prozessoptimierung in der Dokumentation; – Optimierte Auswertung der Messwerte und Visualisierung in unterschiedlichen Formaten (Grafik, Liste, Statistische Auswertung …); – Automatischer Vorschlag der Insulin-Medikation als Erleichterung gegenüber dem manuellen Ausrechnen der Dosis. Lesson Learned Auf Basis der Personas und ergänzender Expertengespräche wird das Fachwissen des Auftraggebers durch spezifische Anforderungen von Betroffenen und professionellen Anwendern aus der Praxis ergänzt. 2.1.3. Definition Use Cases Nachfolgend wurden Use Cases für die drei geplanten Anwendungsfälle Blutzuckermessgerät (Omnitest 3D), digitales Diabetestagebuch (Omnitest Center) und


Usability Professionals 2013 UX Best Practices

mobile Applikation (zukünftig Omnitest Mobile) definiert. Die Dokumentation der Use Cases für das Blutzuckermessgerät in Form von Flowcharts bildete hierbei die Grundlage der Softwarespezifikationen des Hardwareherstellers, die definierten Use Cases des Diabetestagebuchs wurden direkt in die Software Requirement Specifications des programmiertechnischen Umsetzers übernommen. Beispielhafte Use Cases sind: – Blutzuckermessgerät: Messung vornehmen, Zusatzwerte eingeben, Medikationsvorschlag abfragen, nachträgliches Eingeben/Ändern von Zusatzwerten. – Diabetestagebuch/mobile Applikation: Manuelle Eingabe von Werten, Auswertung und Visualisierung von Werten, Freigabe von Daten für Dritte (z. B. medizinisches Fachpersonal, Familienangehörige). Lesson Learned Die iterative Definition der Use Cases bildet die Grundlage der nachfolgenden Konzeption und Spezifikation. In Abstimmung mit den Projektbeteiligten kann so zu einem frühen Zeitpunkt ein hoher Detaillierungsgrad erreicht werden, der spätere Anpassungen auf ein Minimum reduziert. 2.2. Konzeption Obwohl die Entwicklungsschritte bei der Konzeption von Produkten und Services (Identifikation – Spezifikation – Umsetzung) prinzipiell gleich sind, unterschieden sich diese in ihrer spezifischen Ausprägung und Schwerpunktsetzung für die „Produkte“ Blutzuckermessgerät, Diabetestagebuch und Printmaterialien. 2.2.1. Omnitest 3D Grundlagen des Nutzungskonzepts und der Funktionsspezifikation waren neben den Anforderungen und Use Cases vor allem die bidirektionale Interaktionsbeschreibung als Ergänzung der Flowcharts. Hierbei wurden sowohl Einzelschritte

Abb. 3. Flowchart Omnitest 3D

und Reihenfolge der Nutzereingaben, wie auch audio-visuelle Feedbackstrukturen des Messgeräts beschrieben. Ein besonderes Augenmerk lag bei der Entwicklung neben dem Verhalten des Messgeräts bei Standard-Interaktionen auch auf Feedbackstrukturen bei Benutzer- oder Systemfehlern. Maßgebliches Ziel der Konzeption war hier die Eineindeutigkeit aller Anzeigen und Reaktionen des Messgeräts, sowie eine hohe

Fehlertoleranz bzw. Datensicherheit bei Kommunikationsfehlern. Lesson Learned Die ergänzende Konzeption der Interaktions- und Feedbackmuster ermöglicht zu einem frühen Zeitpunkt die Beschreibung des „Look & Feel“ für das finale Produkt und somit die eigentliche Benutzerschnittstelle. [Abb. 3]

141


2.2.2. Omnitest Center Die Konzeption des digitalen Diabetestagebuchs orientierte sich an der erprobten Vorgehensweise bei Entwurf und Ausgestaltung von Websites oder Online-Portalen. Nach Festlegung der Seitenbereiche und des Systembaums wurden Funktionsbereiche und Einzelfunktionen definiert und in Form eines Anforderungsdokuments aus Nutzersicht (C-Requirements) beschrieben. Ergänzt durch die Anforderungen aus Entwicklersicht (D-Requirements) bildeten diese die Basis der Software Requirement Specifications (SRS). Dieses Konzeptdokument enthielt u. a. das GUI Design sowie die Spezifikation der technischen Architektur und war Grundlage sowohl der programmiertechnischen Umsetzung wie auch der Zertifizierung als medizintechnische Software durch die entsprechenden Zertifizierungsstellen. Lesson Learned Eine schriftliche Anforderungsdokumentation mit einem hohen Bildanteil, z. B. mit Design-Wireframes und Grafiken, ermöglicht eine effiziente Kommunikation zwischen Gestalter und Umsetzer – also den Autoren der C- und D-Requirements. 2.2.3. Produktverpackung und Printmaterialien An erster Stelle bei der Konzeption von Printmaterialien stand die Berücksichtigung der „Informationskaskade“, also der Informationstiefe in Abhängigkeit vom Informationskontext. Je nach Zielsetzung (z. B. erster Blick auf die Verpackung, kurzer Einstieg in die Nutzung, detaillierte Informationssuche), Zielgruppe und Nutzungskontext wurden sowohl Perzeptions-/Lesezeiten (z. B. 10 sec., 30 sec., 5 min., 15+ min.) wie auch Wording, Ansprache und Kommunikationsformat daraufhin angepasst. Ergebnisse waren auf den Nutzungszweck angepasste Kommunikationsformate, die von einem Infoaufkleber über gedruckte Anleitungsdokumente bis zu 1–3 Minuten langen Videos mit Produktschulungen reichen können. In einem ersten Schritt wurden drei eigenständige Formate mit individuellem Fokus definiert.

142

–– Kurzanleitung: Zweiseitiges Leporello mit Fokus auf internationale und intuitive Nutzbarkeit durch Verzicht auf Schrift, dafür mit verstärkter Nutzung von Abbildungen und Grafiken. Die Leporello-Faltung verdeutlicht zusätzlich das schrittweise Vorgehen bei Erstinstallation und Nutzung des Blutzuckermessgeräts. –– Benutzerhandbuch: 96-seitiges Produkthandbuch im A5+ Format mit Fokus auf ausführliche Information und Fehlerbehebung. Das bestehende Benutzerhandbuch wurde hinsichtlich der Informationsarchitektur durch Überarbeitung der Kapitel (Reihenfolge und Inhalte), Reduzierung von Redundanzen und Integration zusätzlicher Inhalte größtenteils neu konzipiert. –– Produktverpackung: Neukonzeption unter Berücksichtigung einer neuen Vertriebsstrategie mit Endverbraucherfokus („Over-theCounter“-Produkt) unter Beibehaltung des bestehenden Verpackungsformats. Lesson Learned Die Beachtung der Informationskaskade steigert die Akzeptanz der „ungeliebten und ungenutzten“ Anleitungsdokumente erheblich, wie auch im User-ExperienceTesting nachgewiesen werden konnte. 2.3. User-Interface-Design 2.3.1. Omnitest 3D Primäre Herausforderungen bei der Gestaltung des Blutzuckermessgerät-UIs waren Lesefähigkeit und intuitive Nutzbarkeit. Als Display wurde ein LCD-Segmentdisplay ausgewählt, das eine sehr hohe Abbildungsschärfe mit guter Ablesbarkeit garantiert. Eine Hintergrundbeleuchtung zur Nutzung auch unter schlechten Lichtverhältnissen wurde integriert. Da eine direkte Farbigkeit der Segmente technisch nicht möglich war, wurden zur Hervorhebung wichtiger Display-Elemente (z. B. Hinweise, Hauptanzeige) farbige Folien über einzelnen Bereichen integriert.

Beim Display-Layout wurden sowohl normative Vorgaben (z. B. minimale Buchstabenhöhe), wie auch technische Vorgaben des Hardwareproduzenten (z. B. Führung der Leiterbahnen) berücksichtigt. Ein spezielles Augenmerk lag auf der Anforderung, die Ablesbarkeit der Hauptanzeige „auf dem Kopf“ möglichst zu verhindern um die Ablesung falscher Messwerte (z. B. 521 statt 125) auszuschließen. Icons und Symbole wurden so gestaltet, dass diese in allen „Kanälen“ (Omnitest 3D, Omnitest Center, zukünftig auch Omnitest Mobile, Produktverpackung und Anleitungen) sowie in zukünftigen Produktentwicklungen (siehe 2.6 Ausblick: Omnitest 5) verwendet werden können. So wurde eine geräteübergreifende und nachhaltige Nutzung dieser Design-Elemente ermöglicht. Lesson Learned Die Verwendung von eindeutigen Begrifflichkeiten (z. B. zur nutzbaren Displayfläche) in der Kommunikation zwischen Auftraggeber, Hardwarehersteller und Gestalter, z. B. in Form eines Glossars als Anhang zum Spezifikationsdokument, verhindert evtl. Mehraufwand durch zusätzliche Iterationen und Anpassungen. [Abb. 4] 2.3.2. Omnitest Center Zielsetzung bei der Gestaltung des digitalen Diabetestagebuchs war, eine zielgruppengerechte „State-of-the-Art“-Anwendung im Consumer-Bereich zu gestalten. Dies be­­ deu­­tete einen Paradigmenwechsel in der UI-Gestaltung, da der Auftraggeber bislang nur digitale Anwendungen im Businessto-Business bzw. Business-to-EmployeeBereich umgesetzt hatte. Das Diabetestagebuch wurde somit die erste Umsetzung eines neuen Designs, bei dem chilli mind bereits in der Entwicklung und Spezifikation des Designguides maßgeblich beteiligt war. Der Gestaltungsschwerpunkt des digitalen Diabetestagebuchs lag in der nutzerorientierten Darstellung der beiden relevantesten Use Cases „Eingabe von Werten“ und „Visualisierung der Werte als Tagebuch“, wobei auch hier die Herausforderungen


Usability Professionals 2013 UX Best Practices

an Lesefähigkeit und intuitive Nutzbarkeit berücksichtigt wurden. Zentrales Element des Diabetestagebuchs ist, sowohl für Betroffene wie auch für medizinisches Fachpersonal, die Visualisierung von medizinischen Werten eines frei definierbaren Zeitraums als Grafik (Kurve), Tabelle (Listenansicht), Standardtag (Darstellung aller Messwerte eines ausgewählten Zeitraums in einem 24-StundenDiagramm) oder statistische Auswertung. Lesson Learned Durch klare Definitionen und Beachtung eines bestehenden Designguides konzentriert sich das UI-Design auf die Umsetzung dieser Vorgaben und Iterationen beschränken sich auf funktionale Aspekte. [Abb. 5]

Abb. 4. User Interface Omnitest 3D

2.3.4. Produktverpackung und Printmaterialien Entsprechend dem Kommunikationskonzept wurden drei eigenständige Formate zur Nutzerkommunikation entwickelt und designtechnisch umgesetzt. Als Größenmaster diente die Produktverpackung, die alle Elemente der Hardware (Blutzuckermessgerät, Zubehör, Printmaterialien) enthält. In den Anleitungsdokumenten wurde schwerpunktmäßig die Navigation innerhalb der Dokumente durch deutlichere Kennzeichnung der Kapitel bzw. der Einzelschritte optimiert. Generell wurden die visuellen Kommunikationsanteile durch den vermehrten Einsatz von Abbildungen und Grafiken in einer verbesserten Darstellungsqualität (Renderings und Fotos statt zweidimensionaler Zeichnungen) verstärkt. – Kurzanleitung: Beibehaltung des Leporello-Formats, da hier die manuelle Handhabung (kapitelweises Umblättern des langformatigen Dokuments) eine hohe Usability bietet. Das Format wurde von einem Quadrat zu einem schmalen Querformat verändert, um durch optimierte Platzausnutzung zusätzliche Informationen integrieren zu können. – Benutzerhandbuch: Leichte Größenanpassung von DIN A5 auf DIN A5+ um Handhabung, Lesbarkeit

Abb. 5. Omnitest Center – Grafische Auswertung

143


Lesson Learned Die frühzeitige Überprüfung von Einzelkomponenten erlaubt die Identifikation und Anpassung spezifischer Problemstellungen, z. B. von Darstellungsabweichungen auf unterschiedlichen Browsern und Betriebssystemen oder langen Laufweiten spezifischer Sprachversionen (z. B. Französisch). 2.4.3. Modellbau Produktverpackung und Printmaterialien

Abb. 6. Anleitungsdokumente (Kurzanleitung, Benutzerhandbuch)

(Schriftgrößen) und typografische Gestaltung (Weißraum und Textmengen) zu optimieren. –– Produktverpackung: Re-Design im Zuge der angepassten Marketing­stra­ tegie mit Fokus auf B2C bei unver­ änderten Dimensionen der Verpackung und unter Berücksichtigung der Vorgaben des Corporate Designs. Lesson Learned Durch die einheitliche Verwendung einer neuen Bildsprache und der neu gestalteten Icons entsteht ein harmonisches „Gesamtensemble“, welches die strategische Fokussierung auf den ConsumerBereich maßgeblich unterstützt. [Abb. 6] 2.4. Spezifikation und Programmierung/Umsetzung 2.4.1. Omnitest 3D In Absprache mit dem Hardwareproduzenten wurde zuerst das Austauschformat für die Spezifikationen in Form von Flowcharts mit eingebetteten UI-Screendesigns entwickelt. Dies ermöglichte den schnellen und agilen Austausch unter weitestgehendem Verzicht auf eine schriftliche Dokumentation. Auf Grundlage von Konzeption und UIDesign wurden anschließend die grafischen Flowcharts konzipiert und dokumentiert.

144

Lesson Learned Die Entwicklung eines individuellen Austauschformats beschleunigt und vereinfacht die Projektkommunikation, da im internationalen Kontext Sprachbarrieren minimiert werden und eine eigene „Projektsprache“ verwendet wird.

Sowohl für das User-Experience-Testing wie auch zur internen Projektkommunikation (z. B. in Richtung Marketing & Sales, Management und Vorstand) wurden eine Reihe von Modellen der vollständigen Hardwarekomponenten (Blutzuckermessgerät, Produktverpackung, Printmaterialien etc.) umgesetzt. Hierbei wurde speziell auf eine wirklichkeitsgetreue Umsetzung und hohe Qualität bei Druck, Papier/Pappe und Modellbau geachtet. Lesson Learned

2.4.2. Omnitest Center Aufgrund der kurzen Entwicklungszeit wurde ein agiler Entwicklungsprozess mit dem programmiertechnischen Umsetzer initiiert, in dem die Spezifikationen zur Umsetzung des Online-Diabetestagebuchs in Teilpaketen Top-Down definiert und dokumentiert wurden. Als Basis dienten die erstellten C-Requirements und Designspezifikationen in Form maßhaltiger UI-Screens. In engen Abstimmungen konnten häufige, kurze Iterationsschleifen mit kurzen Antwortzeiten realisiert werden. Dies ermöglichte es, funktionale und technische Probleme frühzeitig zu identifizieren und entsprechende Anpassungen und Optimierungen vorzunehmen. Im Rahmen der programmiertechnischen Umsetzung wurden frühzeitig Sicht- und Funktionsprüfungen durchgeführt um Abweichungen zu identifizieren und Detailanpassungen vorzunehmen.

„First Look & Feel“ sind bei internen Produktpräsentationen ein Killerkriterium für die Akzeptanz eines Projekts bei wichtigen Stakeholdern (z. B. Management, Vorstand). Anders als im agilen Entwurfsprozess ist hier eine möglichst wirklichkeitsnahe Visua­ lisierung mit hochwertigem Modellbau notwendig. 2.5. User-Experience-Testing von Omnitest 3D, Omnitest Center, Produkt­ verpackung und Printmaterialien Entsprechend den definierten Personas wurden Tester-Profile erstellt (differenziert z. B. nach Alter, Geschlecht, Betroffene/ medizinisches Fachpersonal, technische Affinität, Erfahrung mit Diabetes und analogen/digitalen Diabetestagebüchern) und entsprechende Personen aus dem TesterNetzwerk von chilli mind, sowie über den Außendienst des Auftraggebers akquiriert. Vorab wurden in Abstimmung mit dem Auftraggeber Testkriterien, der


Usability Professionals 2013 UX Best Practices

Bewertungsmaßstab sowie ein Interviewleitfaden ausgearbeitet.

Elemente wie z. B. Display-Layout, Icons und Ziffern der Displayanzeige.

Die eigentliche Durchführung des Testings erfolgte als aufgabenbezogenes LeitfadenInterview mit „empathisch-teilnehmender Beobachtung“ in Think-Aloud-Methodik mit ergänzendem Videoprotokoll.

Die Anforderungsprofile und Personas unterschieden sich nur geringfügig, wodurch Use Cases unverändert oder mit geringen Anpassungen übernommen werden konnten. Abweichende, spezifische Nutzungsfälle konnten auf Basis des abgestimmten Austauschformats und der aktuellen Dokumente schnell und passgenau mit dem Produzenten des neuen Blutzuckermessgeräts abgestimmt werden.

Die Auswertung der dokumentierten Interviews erfolgte entsprechend der vorab definierten Kriterien, die auch als Basis der Verifizierung und Validierung im Rahmen der medizintechnischen Gerätezulassung dienen werden. Identifizierte Fehlfunktionen, unklare Prozesse, unverständliche Darstellungen und generelle „Stolpersteine“ wurden anschließend in der Auswertung identifiziert, dokumentiert, in Absprache mit den Projektbeteiligten priorisiert und an den entsprechenden Stellen in die Anpassungs- und Überarbeitungsprozesse der einzelnen Komponenten als Change Requests integriert. Lesson Learned Durch den vorab klar definierten Fragenkatalog und entsprechende Bewertungskriterien wird die Identifikation, Priorisierung und Implementierung relevanter Optimierungsansätze im Verfeinerungsprozess objektiviert. 2.6. Ausblick Omnitest 5: Entwicklung ­weiterer Modelle auf Basis der ­definierten Spezifikationen Aufbauend auf den Ergebnissen des Projekts erfolgte parallel der Kick-Off zur Entwicklung der nächsten Generation von Blutzuckermessgeräten, die gegenüber dem relativ kostenintensiven Premiummodell Omnitest 3D als Low-Budget-Modell einen verringerten Funktionsumfang haben. Der Entwicklungsprozess dieser Modellreihe profitierte hierbei von der strukturierten Dokumentation der Schritte und Ergebnisse im aktuellen Entwurfsprojekt, so dass viele Elemente direkt bzw. angepasst in die Entwicklung übernommen werden konnten. Dies betraf u. a. grafische

Bei der neu zu entwickelnden Gerätegeneration ist die Übernahme von Messwerten über eine PC-Kabelverbindung möglich, so dass diese dann ebenfalls im Omnitest Center dargestellt und verwaltet werden können. Lesson Learned Die strukturierte Dokumentation von Spezifikationen und Ergebnissen ermöglicht aus Herstellersicht eine nachhaltige Nutzung im Sinne eines kontinuierlichen Entwicklungsprozesses. Aus Nutzersicht ist so eine Wiedererkennbarkeit auch über Gerätegenerationen hinweg möglich. 3. Fazit: Die Relevanz eines standardisierten Vorgehens in komplexen Entwurfsprozessen Insgesamt stellt das vielschichtige Ent­ wicklungsprojekt unter User-­ExperienceGesichtspunkten und auf Grund der pro­to­ typischen Vorgehensweise ein exzellentes Beispiel für einen standardisierten Entwicklungsprozess dar, der sowohl Usability-Gesichtspunkte, nutzerspezifische Anforderungen sowie technische und norma­tive Restriktionen in den Fokus stellt. So konnten im Projektverlauf durch die frühzeitige Einbeziehung aller Stakeholder (Auftraggeber, Nutzer, Provider, Hersteller von Hard- und Software …) auch widerstreitende oder widersprüchliche Anforderungen berücksichtigt werden.

die verzahnte Entwicklung aller analogen und digitalen Elemente eines komplexen Gesamtsystems mit einem qualitativ hochwertigen Endergebnis unter Berücksichtigung der zeitlich und finanziell eng gesteckten Rahmenbedingungen. Mit Fokus auf die „Lessons Learned“, die in der Projektanalyse identifiziert wurden, konnten auf operativer Seite zusätzlich folgende Einzelerkenntnisse erzielt werden: –– Durch den integrativen User-ExperienceAnsatz und die frühzeitige Einbeziehung von Nutzern (Anwender, Betroffene) konnte die hohe Kunden­freundlichkeit aller Elemente im Gesamt­­system von den Prozessen bis zur gestalterischen Umsetzung gewährleistet werden. –– Der Projektverlauf erlaubte vor allem auf Grund des User-Experience-Testings die Bestätigung der digitalen und analogen Entwurfsansätze durch die positiven Ergebnisse bei Merk- und Lesefähigkeit, sowie Perzeptionszeiten der Bedien­ oberflächen und Anleitungen. –– Die visuell unterstützte Kommunikation, bereits zu einem frühen Stadium des Entwurfsprozesses verkürzt Entwurfs­ zeiten durch Reduzierung der Iter­ ationen und Anpassungsaufwände. –– Ergebnisse der einzelnen Teilprojekte, Testings und Sicht-/Funktionsprüfungen konnten frühzeitig als Anforderungen, Optimierungsansätze bzw. Change Requests in die iterative Umsetzung und Optimierung der Hard- und Software-Elemente übernommen werden. –– Im Rahmen der agilen Projektierung wurden verschiedene Modellbau- und Interaktionsformen von „Quick and Dirty“ bis „Hochglanz“ kontext­spe­ zifisch zur Evaluation und Präsen­tation verwendet und mit Erfolg erprobt. Die Harmonisierung und konsequente Dokumentation der Entwurfselemente, z. B. als Flowchart, Softwarespezifikation oder Designguide, garantiert die nachhaltige Verwendbarkeit aller Ergebnisse auch bei zukünftigen Produktentwicklungen.

Der von chilli mind implementierte, integrative Ansatz ermöglichte innerhalb eines eng definierten Projektrahmens

145


Travel Experience Erlebniszentrierte Gestaltung neuer Medien für Reisende

Michael Burmester Hochschule der Medien, Wolframstr. 32 70191 Stuttgart burmester@hdm-stuttgart.de

Ralph Tille Hochschule der Medien, Wolframstr. 32 70191 Stuttgart tille@hdm-stuttgart.de

Abstract Im Rahmen des europäischen Forschungsprojekts IC-IC „Enhancing interconnectivity of short and long distance transport networks through passenger focused interlinked information-connectivity“ wurde eine Designstudie zur Entwicklung von Konzepten für interaktive Technologien zur Unterstützung positiver Erlebnisse während der Transportphase bei Flugreisen entwickelt. Dabei wurde angenommen, dass alle Informationsprobleme über verschiedene Transportmodalitäten hinweg (z.B. vom öffentlichen Nahverkehr zum Flughafen und dann innerhalb des Flughafens) gelöst sind, und somit keine Störungen des Reiseprozesses auftreten. Darauf aufbauend wurde ein erlebniszentrierter Gestaltungsprozess beschrieben, der auf emotions- und motivationspsychologischen Modellen basiert. Als Ausgangspunkt wurden existierende positive Reiseerlebnisse durch speziell konzipierte Tagebuchverfahren und Tiefeninterviews gesammelt und als Inspirationsquelle verwendet. Daraus wurden Erlebnisideen abgeleitet, aus denen dann 13 Konzepte ausgearbeitet wurden. Beispielsweise ergaben die Befragungen, dass spontane Gespräche unter Passagieren sehr positiv erlebt werden. Somit wurde ein Konzept entwickelt, in dem Passagiere in Wartesituationen unaufdringlich miteinander ins Gespräch gebracht werden sollen.

1. Einleitung Das europäische Forschungsprojekt IC-IC „Enhancing interconnectivity of short and long distance transport networks through passenger focused interlinked information-connectivity“ (FP7 GA 266250) hat das Ziel, Passagiere auf Reisen über die verschiedenen Transportmodalitäten und Informationsmedien hinweg mit den jeweils notwendigen Informationen umfassend zu versorgen und Informationsdefizite zu beheben. Da es dabei eher um die Lösung von Problemen geht, sprechen Desmet und Hassenzahl (2012) in diesem Fall von „problem-driven design“. Somit wird im Sinne eines Hygienefaktors vor allem versucht, negative Erlebnisse zu vermeiden, anstatt positive zu schaffen (Hassenzahl, Diefenbach & Göritz, 2010). Im Gegensatz dazu sollte es in der vorliegenden Designstudie um die Gestaltung von explizit positiven Erlebnissen in der Transportphase des Reisens gehen. Somit

146

wurde die Annahme getroffen, dass Informationsprobleme der Passagiere bereits gelöst sind. Zur Gestaltung für positive Erlebnisse wurden zwei User-ExperienceAnsätze verfolgt. Zum einen wurde die User-Experience-Definition von Hassenzahl (2008) zugrunde gelegt, wonach User Experience als ein Gefühl definiert wird, bei dem die Valenzdimension (sich gut fühlen, sich schlecht fühlen) im Zentrum der Betrachtung steht. Nach Hassenzahls Definition stellt sich ein positives Gefühl dann ein, wenn menschliche Bedürfnisse, wie Autonomie, Kompetenz, Stimulation, Verbundenheit und Popularität erfüllt werden. Diese fünf Bedürfnisse wurden in Hassenzahls Studien für Technologieerlebnisse als besonders relevant eingestuft. Zum anderen sollen explizit Situationen auf Reisen nach Möglichkeiten für positive und vielleicht bedeutungsvolle Erlebnisse hin untersucht werden, was von Desmet & Hassenzahl (2012) in Abhebung zum „problem-driven design“ als „possibilitydriven design“ bezeichnet wird.

Keywords: /// Travel Experience /// User Experience /// bedürfnisorientierter Gestaltungsprozess

Im Folgenden werden zunächst verwandte Ansätze zur Schaffung positiver Reiserlebnisse vorgestellt. Anschließend wird ein Gestaltungsprozess für die vorliegende Designstudie definiert und beschrieben. Dem folgend wurden 13 Konzepte zur Förderung positiver Reiseerlebnisse entwickelt, von denen drei näher vorgestellt werden. Zum Abschluss wird der Gestaltungsprozess reflektiert. 2. Verwandte Ansätze zu positiven Erlebnissen auf Reisen Ansätze, die Transportphase des Reisens zu einem schönen Erlebnis zu machen, gibt es bereits in der Forschung. So wurde für den Shannon Airport in Irland das „Portal Dolmen Project“ durchgeführt (Ciolfi et al., 2007). Diese öffentliche interaktive Installation ermöglicht es Passagieren vor­ gegebene oder eigene digitale Fotos mit Zeichnungen und Annotationen öffentlich auszustellen und die von anderen


Usability Professionals 2013 UX Best Practices

1. Definiton der Passagiertypen

2. Positive Erlebnisse sammeln

3. Integrierte Erlebnisgeschichten

4. Entwicklung von Erlebnisideen

5. Gestaltung der Erlebnisdynamik

7. Szenariooder VideoPrototyp

Abb. 1. Erlebnisorientierter Gestaltungsprozess zum Entwurf für positive Travel Experience in der Transportphase des Reisens

Passagieren anzuschauen. Desmet und Hassenzahl (2012) berichten vom Konzept „Daydream“, welches das Tagträumen aufgreift, das sich bei Zugreisenden einstellt, wenn sie während der Fahrt auf am Wagonfenster vorbeiziehende Landschaften schauen und ihren Eindrücken und Assoziationen nachhängen. Ein Kissen mit einer technischen Ausstattung erkennt die Position des Zuges und ergänzt den „Tagtraum“ durch Geräusche, die zu den Eigenschaften der passierten Landschaft passen, z.B. Wasserplätschern, wenn der Zug sich entlang eines Flusses bewegt. Van Hagen (2011) analysiert unter welchen farblichen, musikalischen und infotainmentartigen Gestaltungen an Bahnhöfen, sich wartende Zugreisende in Abhängigkeit von der Passagierdichte und der Reisemotivation möglichst positiv fühlen. Mittlerweile gibt es aber auch real existierende Dienstleistungen jenseits der Catering-, Shopping oder Wellness-Möglichkeiten an Flughäfen oder auf Zugreisen. Die Bundesbahn Nordrhein-Westfalen hat das Webportal „Momente“ (2013) eingerichtet über das flüchtige Bekanntschaften in Zügen wieder kontaktiert und weiter gepflegt werden können. Mit dem Service „MeetAtTheAirport“ (2011) können Treffen mit unterschiedlicher Ausrichtung von gemeinsamen Kaffee, Networking, Reisebegleitung oder sogar romantische Beziehungsanbahnung an Flughäfen vereinbart werden. Fluggesellschaften, wie Finnair, KLM oder Malaysia Airlines, bieten einen Social Seating Service (SeatID, 2013). Damit können Passagiere einen Sitznachbarn auswählen und diesen über Soziale Netzwerke bereits vor dem Flug kennenlernen, um dann während des Fluges bereits gute Voraussetzungen für angenehme Unterhaltungen zu haben.

3. Definition eines erlebnisorientierten Gestaltungsprozesses 3.1. Der Prozess im Überblick

etc.). Aus den 16 Passagiertypen des IC-ICProjektes wurden für diese Studie 13 ausgewählt für die dann Konzepte entwickelt wurden (z.B. älteres Ehepaar auf Urlaubsreise oder Reise von drei Geschäftsleuten).

Um positive Erlebnisse für Passagiere durch Gestaltung interaktiver Systeme für die Transportphase bei Flugreisen zu ermöglichen, wurde in Anlehnung an Hassenzahl (2010), Desmet und Hassenzahl (2012) sowie Wright und McCarthy (2010) ein erlebnisorientierter Gestaltungsprozess beschrieben, der auch Komponenten des szenariobasierten Gestaltungsansatzes von Rosson und Carroll (2002) enthält. Abbildung 1 zeigt den Prozess. Innerhalb dieser Designstudie verlief der Prozess linear. Bei der Entwicklung von Produkten würde der Prozess natürlich zusätzliche Phasen der Evaluation beinhalten, beispielsweise mit Methoden des Concept Testings (Sproll et al., 2010) oder der Valenzmethode (Burmester et al., 2010), so dass eine iterative Optimierung der Gestaltung (vgl. DIN EN ISO 9241–210, 2011) möglich wird. [Abb. 1]

3.3. Sammlung positiver Erlebnisse in der Transportphase von Flugreisen

In den folgenden Kapiteln wird genauer auf die einzelnen Aktivitäten des Gestaltungsprozesses eingegangen. 3.2. Definition der Passagiertypen Im Projekt IC-IC wurde eine Klassifikation von 16 Passagiertypen entwickelt. Diese Typologie wurde anhand folgender Kriterien erstellt: Spektrum unterschiedlicher Reiseanlässe (Urlaubsreise, Geschäftsreise, etc.), Anzahl von Reisenden (allein, Kleingruppe, Reisegruppe), Reiseerfahrung (gering, hoch), Entfernung des Zielortes (Inland, kontinental, interkontinental), Art des Gepäcks (Handgepäck, Koffer, Kinderwagen, etc.) und schließlich Art der Anreise (Öffentlicher Nahverkehr, Taxi, eigener PKW

Zur Identifikation von positiven Erlebnissen in der Transportphase des Reisens wurden 10 Tiefeninterviews (Laukenmann, 2012) durchgeführt und ausgewertet. Die Untersuchungsteilnehmer wurden nach Kriterien Reiseanlass, Reiseerfahrung und Entfernung des Zielortes ausgewählt (6 Personen weiblich und 4 männlich, Altersdurchschnitt 45,3 Jahre, 5 geben eine Flugreisehäufigkeit von 1–4 Reisen pro Jahr und die anderen 5 Befragten lagen noch darüber). Jedes Interview wurde semistrukturiert geführt indem in der Befragung zunächst emotionale Erlebnisse während einer konkreten erinnerten Reise identifiziert wurden. Jedes Erlebnis wurde dann nach folgendem Befragungsschema beschrieben und analysiert: 1. Klärung der Situation (Reiseabschnitt, Umgebungssituation, involvierte Personen, involvierte, Artefakte, emotionsauslösende Faktoren) 2. Persönliche Bedeutung der Situationseigenschaften und zugrundeliegendes Bedürfnisse durch Laddering (Reynolds & Gutman, 1988) Zudem wurde eine Tagebuchstudie (Käfer, 2012) über eine komplette Fernflugreise (Stuttgart nach USA, Israel, Ägypten, Zypern) von der Ticketbuchung zum Zielort und wieder zurück zum Heimatort mit 4 Teilnehmern durchgeführt (2 Personen weiblich und 2 männlich, Altersdurchschnitt 45,3 Jahre, eine Person flog 2x pro Jahr, die anderen 4–8x). Die Instruktion forderte, positive und negative Erlebnisse mit

147


Abb. 6. Abbildung 2: Ausschnitt aus dem Storyboard des Konzeptes Travel Tracker (mit Genehmigung von Katharina Clasen, Timo Gabel, David Galowy, Timo Göbel und Dürgül Gümüs)

Hilfe einer Notizsoftware (Evernote, 2013) auf dem Smartphone zu protokollieren und ggf. zu fotografieren. Im Anschluss an die Reise wurden die Erlebnisnotizen mit einem vergleichbaren Befragungsschema wie bei den Tiefeninterviews nachbefragt. Mit Hilfe der Tiefeninterviews wurden 167 Erlebnisse (106 positiv und 61 negativ) und im Rahmen der Tagebuchstudie 216 Erlebnisse (101 positiv und 115 negativ) identifiziert. Es wurden nur die positiven Erlebnisse verwendet, da negative Erlebnisse in der Designstudie nicht beachtet werden sollten. Aus der qualitativen Analyse beider Studien lassen folgende Themen positiver Erlebnisse extrahieren: – Stimulation durch Differenz zum Alltag (vor allem am Zielflughafen und Zielort): Unterschiede in Handlungsabläufen (z.B. angenehm „chaotische“ Abläufe am Flughafen), interkulturelle Unterschiede (z.B. Begrüßungsverhalten) sowie andere Umgebungseigenschaften (z.B. Flughafengröße) oder Erlebnisse mit sonst nicht genutzten Einrichtungen (z.B. Fahren auf Laufbändern, die eine ruhige und neue Perspektive auf die vorbei-ziehende Umgebung ermöglichten) erzeugten Neugier, ermöglichten Perspektivwechsel und lösten Reflexionen aus. – Wenn Personen mit nicht erwarteten Upgrades, Besuchen von exklusiven Lounges oder kleinen Geschenken bedacht wurden, stellte sich ein Gefühl persönlicher Wertschätzung und Popularität ein. – Möglichkeiten, selbst entscheiden zu können (z.B. Sitzplatz wählen) wurden positiv wahrgenommen.

148

– Positiv erlebt wurde Ruhe und auf sich bezogen sein, wenn die Umgebung entsprechend Ruhe ausstrahlte (z.B. wenig anwesende Passagiere). – Bewältigte Herausforderungen (z.B. Weg zum Anschlussflug gefunden) wurden positiv erlebt (Kompetenzerlebnis). – Berichtet wurde von Vorfreude auf die Reise und das Reiseziel (ausgelöst z.B. durch Wetterinformationen zum Zielort). – Freundliches und einfühlsames Personal war ein starker Auslöser positiver Erlebnisse (z.B. Busfahrer zum Startflughafen bis zur Taxifahrerin am Zielort). Hier wurden für kurze Momente positive Beziehungen aufgebaut sowie durch hilfreiche Unterstützung zusätzlich ein Gefühl der Sicherheit erzeugt. – Verbundenheit entstand beispielsweise durch spontane Gespräche mit Mitreisenden. Diese Gespräche hatten zudem einen stimulierenden Charakter, da interessante Einblicke in die Geschichten anderer Personen gewährt wurden. Das Gefühl, zu einer Gruppe Gleichgesinnter zu gehören, stellt sich durch Gemeinsamkeiten ein, wie ein gemeinsames Flugziel oder ein Merkmal zu einer Gruppe zu gehören (z.B. eine Blume von Thai Air für seine Fluggäste). Zusätzlich wurden alle Gestalter im Sinne einer „First Person Perspective“ (Hummels, 2012) bzw. Introspektion oder „Immersion“ (Jordan, 2000) aufgefordert, auch eigene Erlebnisse zu sammeln, um einen eigenen Einblick in Reiseerlebnisse zu bekommen. 3.4. Verfassen von Geschichten derzeitiger Erlebnisse auf Reisen Aus den gesammelten Erlebnissen wurden wichtige Erlebnisthemen und –aspekte

extrahiert und kategorisiert. Auf dieser Basis wurden Geschichten des derzeitigen Reiseerlebens geschrieben, die aus der jeweiligen Situation (Ort, Aktivität, Umgebung, anwesende Personen), der emotionalen Entwicklung sowie den zugrundeliegenden Bedürfnissen bestehen. Aus Sicht des Gestalters können auch einzelne Erlebnisaspekte hohes positives Erlebnispotenzial haben (z.B. Erlebnis auf den Laufbändern am Flughafen) und Ausgangspunkt für eine Erlebnisgeschichte sein. 3.5. Erlebnisideen Aus den Geschichten derzeitiger Erlebnisse konnten Konzepte für interaktive Technologien entwickelt werden, welche die derzeitigen positiven Erlebnisse in neuer Form aufgreifen „re-scripting“ oder diese erweitern „enhancing“ (vgl. Hassenzahl, 2010; Desmet und Hassenzahl, 2012). Neben den Geschichten derzeitiger Erlebnisse wurden Situationen auf Reisen auch einfach unter einem bestimmten Bedürfnis betrachtet. Beispielsweise kann die Frage gestellt werden, wie das Bedürfnis nach Verbundenheit am Gate erfüllt werden kann. So lassen sich auch ganz neue Erlebnisse entwerfen, die geeignet sind, in Reisesituationen positive Gefühle zu erzeugen (vgl. Konzept „Snack-O-Mat“). Wie neue technische Lösungen zu Erlebnissen beitragen wurde als Erlebnisszenarios beschrieben. 3.6. Gestalten der Erlebnisdynamik Erlebnisse entfalten sich in der Zeit. So kann die Erlebnisentwicklung über längere Zeiträume der Produktnutzung (z.B. gesamte Besitzdauer) hinweg


Usability Professionals 2013 UX Best Practices

betrachtet werden (Karapanos et al., 2009) oder die Erlebnisdynamik, die sich während der aktuellen Nutzung in spezifischen Situationen entfaltet. Diese Erlebnisdynamik beschreibt Gestaltungseigenschaften, welche die emotionale Entwicklung während der Nutzung beeinflussen können. Erlebnisideen fokussieren i.d.R. auf ein zentrales Bedürfnis. Während der aktuellen Nutzung sollten die erlebnisorientierten Produkte so gestaltet werden, dass eine Reihe positiver Einzelerlebnisse möglich wird (vgl. auch Hassenzahl et al., 2010; Burmester et al., 2010). Beispielsweise fokussiert das Konzept „Snack-O-Mat“ Verbundenheit, erzeugt aber zunächst einmal durch verschiedene gestalterische Maßnahmen Neugier. Die Erlebnisdynamik wurde als Szenario mit Hilfe von Storyboard-Darstellungen beschrieben. [Abb. 2] 3.7. Umsetzung in einen Szenario- oder Video-Prototypen Schließlich wurden die Erlebniskonzepte präsentationsfähig als Szenario-Prototypen dargestellt, d.h. Interaktionen und visuelle Darstellungen werden Schritt für Schritt entlang des Erlebnisszenarios erlebbar oder als Video-Prototyp simuliert (Interaktionen und visuelle Darstellungen werden in animierter Form entlang des Erlebnisszenarios audio-visuell präsentiert). 4. Ausgewählte Konzepte zur Förderung≈positiver Erlebnisse während der Transportphase des Reisens 4.1. Konzepte Es wurden insgesamt 13 Konzepte für tech­ no­logiebasierte Erlebnisse während der Transportphase des Reisens entworfen. Zwei Konzepte machen den Flughafen selbst zum Gegenstand. So werden bei einem der beiden Konzepte beispielsweise die faszinierenden Aspekte des Fliegens und der damit verbundenen Technik durch ein Augmented-Reality-Spiel für Tablets oder Smartphones näher gebracht. Weitere drei Konzepte beschäftigen sich mit der Vorfreude auf die Reise. Hier wird mit Aspekten

Abb. 3. Konzept Erlebnissäule (mit Genehmigung von Fabian Schöttle, Joschka Silzle, Eugenia Woltschek und Andreas Wünsch)

der Zielorte gespielt (vgl. Konzept „Erlebnissäule“). Zwei Konzepte haben Überraschungen zum Gegenstand, von denen eines als App „Geheimtipps“ zu erlebnisreichen Orten der Zielregion von Passagier zu Passagier weitergibt. Das Fliegen selbst wird zum Gegenstand von weiteren drei Konzepten. Bei einem Konzept bilden Passagiere in der Kabine eine Spielergruppe, um ein Ratespiel gegen die eines anderen Flugzeuges zu spielen. Schließlich beschäftigen sich drei Konzepte mit dem Kontakt zu den Passagieren untereinander (vgl. Konzept „Travel Tracker“ und „Snack-O-Mat“). 4.2. Die Erlebnissäule Wie die Befragungen ergeben haben, freuen sich Passagiere auf den Zielort und fantasieren positive Erlebnisse am Zielort. Die Erlebnissäule von Fabian Schöttle, Joschka Silzle, Eugenia Woltschek und Andreas Wünsch adressiert Vorfreude und das Bedürfnis nach Stimulation. Es macht Aspekte des Zielortes in 12 durch ein Türchen verschließbare Fächer einer Säule erlebbar (vgl. Abbildung 2). So wird beispielsweise das Wetter am Zielort erlebbar indem Passagiere die Hand in ein Fach halten: Temperatur wird durch Kühl- und Wärmetechnologien fühlbar, Regen durch tropfendes Wasser erlebbar und Wind durch Ventilatoren spürbar. In anderen Fächern sind Märchen oder Radiosender

der Zielregion zu hören oder es gibt typische Düfte. Diese Erlebnisse geeignet ggf. Erinnerungen an positive Erlebnisse am Zielort wach zu rufen. [Abb. 3] 4.3. Der Travel Tracker Katharina Clasen, Timo Gabel, David Galowy, Timo Göbel und Dürgül Gümüs haben die App „Travel Tracker“ konzipiert. Ziel ist es, das Gruppenerlebnis zu stärken in dem Gruppenaktivitäten während der Geschäftsreise aufgezeichnet und zwischen den Smartphones der Reisenden ausgetauscht werden. Durch die Rückmeldungen soll das Gruppenerlebnis und die Identität als Gruppe gestärkt werden: „Was wir alles gemeinsam erlebt und gemacht haben“. Genutzt werden alle technischen Einrichtungen (wie z.B. GPS, App-Aufrufe, Internetzugriffe, Telefon) und Sensoren (wie z.B. Mikrofon, Lagesensor). Aus den aufgezeichneten Daten werden Informationen zur Gruppenaktivität errechnet, wie z.B. gemeinsam besuchte Orte, Zeitpunkte gemeinsamer Gespräche, Gesprächslänge und Anzahl der Worte (vgl. Abbildung 3). Mit diesem Konzept werden Bedürfnisse wie Stimulation (neue Erkenntnisse über das Gruppenverhalten, z.B. Häufigkeit und Länge gemeinsamer Gespräche), Kompetenz (durch die Rückmeldung gemeinsam bewältigter Aufgaben: „wir waren gemeinsam in 6 Meetings auf unserer Reise und

149


Abb. 4. Beispielscreens des Travel Trackers (mit Genehmigung von Katharina Clasen, Timo Gabel, David Galowy, Timo Göbel und Dürgül Gümüs): Links: Angaben zur Gruppenzeit. Rechts: gemeinsam besuchte Orte

haben insgesamt 10 Stunden verhandelt“) und Verbundenheit (wir haben viel Zeit zusammen verbracht) adressiert. [Abb. 4] 4.4. Das Konzept Snack-O-Mat Als eine spezielle Technologie für Wartezonen an Flughäfen wurde von Hannah Lindemann, Annika Metzger, Kathrin Podlesny und Julia Roming der Snack-O-Mat entworfen. Inspiriert wurde diese Erlebnisidee durch Erhebungsergebnisse über positive Erlebnisse durch zufällig zustande kommende Gespräche mit Mitreisenden. Diese sozialen und positiven Erlebnisse sollen befördert werden durch einen Automat, der in Wartezonen im Flughafen (z.B. am Gate) aufgestellt wird, und kleine kostenlose Snacks den wartenden Passagieren anbietet. Gutes Essen gehört zu den menschlichen Bedürfnissen und bietet bereits die Möglichkeit zu positiven Erlebnissen. Der eigentliche Hintergrund aber ist, dass Passagieren die Möglichkeit zu spontanen Gesprächen geboten werden soll. Das Gerät kündigt akustisch an, dass es demnächst einen kostenlosen Snack geben wird und fordert die Passagiere auf, sich zum Automaten zu begeben. Ein Display zeigt den Snack als ein Schattenriss, so dass erraten werden kann, was es sein wird. Somit wird eine Stimulationssituation geschaffen, die Neugier erzeugen soll. Die vor dem Automaten versammelten Passagiere werden mit einer Personenerkennung identifiziert (z.B. MS Kinect, 2013) und ebenfalls als Schattenriss abgebildet. Bis der Snack ausgeworfen wird, besteht eine Wartezeit und der Schattenriss des Snacks wird langsam deutlicher. Intention der Designer war es, dass die vor dem Automaten wartenden Passagiere nun beginnen, sich über den Snack austauschen,

150

z.B. um was es sich dabei handeln könnte und wie dieser schmecken wird. Damit soll das Bedürfnis nach Verbundenheit erfüllt werden. Schließlich werden unterschiedlich verpackte Snacks genau in der Anzahl der vor dem Automaten stehenden Personen ausgeworfen. Da die Verpackungen unterschiedlich sind, entsteht weiterer Gesprächsstoff, z.B. ob der Geschmack sich von Snack zu Snack unterscheidet. Evtl. werden auch Snacks unter den Passagieren getauscht oder geteilt. Ziel wäre es, dass manche so begonnenen Gespräche fortgeführt werden und somit ein positives Reiseerlebnis entsteht. [Abb. 5] 5. Reflexion des Gestaltungsprozesses Der durchlaufene Gestaltungsprozess zeigt, dass in diesem Vorgehen tatsächlich Konzepte für Technologien zur Unterstützung positiver Erlebnisse entwickelt werden können. Als besonders nützlich erweisen sich Geschichten zu bereits gesammelten positiven Erlebnissen, da diese bereits Gestaltungsideen nahelegen und zu Erweiterungen positiver Erlebnisse oder ganz neuen Erlebnisideen inspirieren. Auch die Betrachtung von Situationen unter dem Fokus unterschiedlicher Bedürfnisse führt zu neuen Ideen der Erlebnisgestaltung. Zudem ist die Unterscheidung von Erlebnisideen und Ausarbeitung der Erlebnisdynamik sehr hilfreich. Die Erlebnisidee fokussiert in der Regel ein zentrales Bedürfnis, das erfüllt werden soll, wie z.B. Verbundenheit beim Snack-O-Mat, in dem Personen miteinander ins Gespräch gebracht werden sollen. In der Ausarbeitung der Erlebnisdynamik wird dann aber auch mit Bedürfnissen, wie z.B. Stimulation gearbeitet, indem beispielsweise der Snack als Schattenriss abgebildet

wird, um die Personen rätseln zu lassen, um was für einen Snack es sich handelt. Eine Erkenntnis aus dem Prozess des Entwerfens, die nicht explizit erfasst, aber bei der Reflexion des Gestaltungsprozesses offensichtlich wurde, ist die Notwendigkeit eines Umdenkens der Designer beim Entwurf von erlebnisbezogenen Technologien. Usability-orientierte Entwürfe gehen davon aus, dass Handlungen potenzieller Nutzer im Rahmen einer Nutzungskontextanalyse von Usability-Professionals beobachtet, analysiert und dann im Sinne der Werkzeuggestaltung unterstützt werden sollen. Beim Entwurf erlebnisorientierter Technologien muss ein Verständnis für das Aufdecken von Möglichkeiten der Bedürfniserfüllung in spezifischen Situationen entwickelt werden. Literatur 1. Burmester, M. Jäger, K., Mast, M., Peissner, M. & Sproll, S. (2010). Design verstehen – Formative Evaluation der User Experience. In: H. Brau, S. Diefenbach, K. Göring, M. Peissner & K. Petrovic (Hrsg.), Usability Professionals 2010 (S. 206–214). Stuttgart: Fraunhofer. 2. Ciolfi, L., Fernström, M., Bannon, L., Deshpande, P., Gallagher, P., McGettrick, C., Quinn, N. & Shirley, S. (2007). The Shannon Portal installation: Interaction design for public places, IEEE Computer, vol. 40, issue 7, pp. 65–72. 3. Desmet, P., & Hassenzahl, M. (2012). Towards happiness : Possibility-driven design. (M. Zacarias & J. V. De Oliveira, Eds.) Most, 1–27. Springer 4. DIN EN ISO 9241–210 (2011). Ergonomie der Mensch-System-Interaktion – Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme. Berlin Beuth. 5. Hassenzahl, M. (2008). User Experience (UX): Towards an experiential perspective


Usability Professionals 2013 UX Best Practices

Abb. 5. Ausschnitte aus dem Konzeptvideo zum Snack-O-Mat (mit Genehmigung von Hannah Lindemann, Annika Metzger, Kathrin Podlesny und Julia Roming). Links: der Snack-O-Mat kündigt einen Snack an, der undeutlich angezeigt wird. Rechts: Nach dem Genuss des Snacks entsteht ein Gespräch über seine Herkunft.

on product quality. In IHM '08: Proceedings

Time: An Initial Framework. In: Proc. of CHI

of the 20th French-speaking conference on

2009, April 4–9, 2009, Boston, Massachusetts,

Human-computer interaction (Conférence

USA (pp. 729–738). New York: ACM.

Francophone sur l'Interaction HommeMachine) (pp. 11–15). 6. Hassenzahl, M. (2010). Experience Design

13. Laukenmann, B. (2012). Qualitative Interviews

Centred Design .- Designers, Users, and Communities in Dialogue. San Rafael, CA,

Bedingungen und psychologischen Faktoren

USA: Morgan Claypool.

positiver Erlebnisse während der Transport­

Rafael, CA, USA: Morgan Claypool.

phase des Reisens. Unveröffentlichte Ab­schluss­­

K., Heidecker, S., Hillmann, U. & Laschke,

train stations. Delft: Eburon. 22. Wright, P. & McCarthy, J. (2010). Experience-

zum vertiefenden Verständnis der situativen

– Technology for All the Right Reasons. San 7. Hassenzahl, M., Diefenbach, S., Eckoldt,

21. van Hagen, M. (2011). Waiting experience at

arbeit. Stuttgart Hochschule der Medien. 14. MeetAtTheAirport“(2011). Web-Service.

Danksagung Ein besonderer Dank gilt dem Engagement

M. (2010). Technologie, die verbindet?

Zugriff am 29.06.2013 unter http://

aller Informationsdesignstudierenden,

Die bedürfniszentrierte Gestaltung von

meetattheairport.com

die im User Experience Seminar des

Kommunikationstechnologien für Liebende

15. Momente (2013). Web-Portal der Deutsche

Sommersemesters 2012 beteiligt waren:

(und andere die sich mögen). In: H. Brau,

Bahn AG. Zugriff am 29.06.2013 unter http://

Stefan Kurt Baumann, Ray Earl Biermann,

S. Diefenbach, K. Göring, M. Peissner & K.

www.bahn.de/regional/view/regionen/nrw/

Jacqueline Melissa Maria Bopp, Sarah

Petrovic (Hrsg.), Usability Professionals 2010

freizeit/momente-nrw.shtml

Brendecke, Pirmin Matthias Buchenberg,

(189–194). Stuttgart: Fraunhofer Verlag. 8. Hassenzahl, M., Diefenbach, S. & Göritz, A. (2010). Needs, affect, and interactive products – Facets of user experience. Interacting with Computers, 22, 353–362. 9. Hummels, C. (2012). Matter of transformation – Sculpting a valuable tomorrow. Inaugural lecture, September 28,

16. MS Kinect (2013). Microsoft X-Box Kinect.

Nadezda Chesnok, Katharina Helga Maria

Zugriff am 17.03.2013 unter http://www.

Clasen, Derya Doganc, Saskia Nadine

xbox.com/de-DE/Kinect/

Eberhardt, Sandra Maria Fohr, Lydia Friedrich,

17. Reynolds, T. J. & Gutman, J. (1988).

Katharina Michaela Fundaminski, Timo Gabel,

Laddering Theory, Method, Analysis, and

David Martin Galowy, Corina Chanchira

Interpretation. In: Journal of Advertising

Gehring, Timo Johannes Göbel, Dürgül

Research, 28, S. 11–31.

Gümüs, Verena Hassler, Lars Herrmann, Helvi

18. Rosson, M.B. & Carroll (2002). J.M. Usability

Oda Hertner, Birgit Laura Hettler, Melissa

2012. Eindhoven: University of Eindhoven.

Engineering – Scenario-based development

Kammerer, Nadine Kärcher, Franziska Kaus,

(Zugriff am 16.03.2013 unter http://alexandria.

of human-computer interaction. San

Anne Alexa Karoline Koch, Julia Kolski,

tue.nl/extra2/redes/hummels2012.pdf)

Francisco: Morgan Kaufmann.

Tatiana Kupreeva, Hannah Lindemann,

10. Jordan, P. (2000). Designing Pleasurable Products. London: Taylor & Francis. 11. Käfer, J. (2012). Tagebuchstudie zur Ana­lyse des Nutzungskontextes für ein Informations­

19. SeatID (2013). Social Seating & Booking.

Annika Metzger, Andrea Müller, Joel Morris

Web Service. Zugriff am 29.06.2013 unter

Müseler, Kathrin Podlesny, Pamela Sue

http://www.seatid.com

Reiche, Jonathan Markus Renz, Julia Roming,

20. Sproll, S., Peissner, M., Sturm, C. &

André Roth, Fabian Schöttle, Joschka Silzle,

system zur Verbesserung der Übergänge

Burmester, M. (2010). UX Concept Testing:

Alexander Elmar Springer, Carola Rebekka

zwischen Nah- und Fernverkehrsmitteln.

Integration von User Experience in frühen

Tischer, Alexander Marius Walther, Eugenia

Unveröffentlichte Abschlussarbeit. Stuttgart

Phasen der Produktentwicklung. In: H. Brau,

Woltschek, Andreas Wünsch, Lisa Würstle und

Hochschule der Medien.

S. Diefenbach, K. Göring, M. Peissner & K.

Anna Zolotareva.

12. Karapanos, E., Zimmerman, J., Forlizzi, J. & Martens, J. B. (2009). User Experience Over

Petrovic (Hrsg.), Usability Professionals 2010 (S. 195–200). Stuttgart: Fraunhofer.

151


Das Geheimnis der Hilfefunktion Möglichkeiten und Potenzial für sinnvolle Hilfe-Konzepte

Natalie Oster Ergosign GmbH Europaallee 12 66113 Saarbrücken oster@ergosign.de

Jan Groenefeld Ergosign GmbH Europaallee 12 66113 Saarbrücken groenefeld@ergosign.de

Abstract Intuitive Bedienung ist eines der Kernthemen in der User Experience. Schließlich sollen Benutzer das System bzw. Produkt ohne explizite Hilfe bedienen können. Nichtsdestotrotz verfügt nahezu jedes komplexere Produkt über eine Bedienungsanleitung und fast jedes Interface über einen Hilfe-Button, der in vielen Fällen lediglich mit der digitalen Version des Manuals verknüpft ist. Dabei sollte eine Suche durch ein endlos langes und nicht aufbereitetes Dokument vermieden werden. Das Potential einer durchdachten Hilfestellung wird jedoch kaum genutzt und hinterfragt. Letztlich kann eine gute Unterstützung durch das System in Problemfällen das Vertrauen des Benutzers in die Software verstärken und dessen Produktivität verbessern. Auf der anderen Seite werden, speziell im mobilen Kontext, neue Hilfemechanismen, wie beispielsweise das Onboarding, eingeführt, teilweise auch mit der Intention, auf die klassische Hilfe zu verzichten. Der Beitrag beleuchtet unterschiedliche Hilfe-Konzepte, die in unterschiedlichen Kontexten und Arbeitsbereichen eingesetzt werden können, um den Benutzer in seinen Tätigkeiten zu unterstützen. Die Möglichkeiten reichen dabei von leichtgewichtigen Schnell-Hilfe-Funktionen wie der Spotlight-Suche von Apple bis hin zu Augmented Reality-Ansätzen wie dem mobilen Benutzerhandbuch von Audi. Die Konzepte werden an Hand von konkreten Beispielen erläutert und veranschaulicht.

1. Motivation Der Bereich der User Experience dreht sich, wie der Name schon sagt, in erster Linie um den Benutzer und dessen Aufgaben und Erlebnisse mit einem digitalen Produkt. Dementsprechend ist das Ziel jeder Software die effektive, effiziente und zufriedenstellende Erfüllung dieser Aufgaben. Hilfekonzepte sind eines der möglichen Mittel, um Benutzer in ihrer Tätigkeit zu unterstützen. Dabei dürfen die Konzepte nicht zu aufdringlich sein und müssen trotzdem leicht zugänglich bleiben. Um diesen Mittelweg zu finden, muss der Kontext, in dem die Hilfe eingesetzt werden soll, analysiert und die nötige Tiefe und Komplexität bestimmt werden. Mit dieser Grundlage kann eine optimierte Hilfefunktion ebenfalls zur Produktivitätssteigerung beitragen und Vertrauen zum System aufbauen.

152

Der Beitrag geht auf verschiedene Formen der Hilfestellung ein und beleuchtet deren Einsatzmöglichkeiten. Dabei werden neben positiven Beispielen auch – aus unserer Sicht – negative Beispiele aufgezeigt. Des Weiteren werden unterschiedliche Interaktionsformen wie mobile Anwendungen oder Augmented Reality berücksichtigt. 2. Differenzierung von Hilfe-Konzepten Hilfe-Konzepte unterscheiden sich vor allem durch zwei Kriterien, die man bei der Auswahl einer geeigneten Lösung für sein System beachten sollte. Zum einen muss bekannt sein, welches Ziel mit der Hilfe erreicht werden soll und zum anderen, wie komplex das zu Grunde liegende System bzw. die zu erfüllenden Aufgaben sind. Liegt der Fokus auf einer kurzen Vorstellung der Software und ihrer Funktionen und

Markus Kühner Ergosign GmbH Europaallee 12 66113 Saarbrücken kuehner@ergosign.de

Keywords: /// Hilfe /// Onboarding /// Usability /// Augmented Reality

Bereiche, kommen beispielsweise erklärende Start Screens (siehe Abschnitt 3.1) oder Onboarding (siehe Abschnitt 3.4) in Frage. Handelt es sich um ein komplexes und sehr umfangreiches System, sollte eventuell eher auf einen Application Walkthrough bzw. eine Guided Tour (siehe Abschnitt 4.1) zurückgegriffen werden, um die Anwendung und ihre Vorzüge im Detail vorzustellen. Ein weiteres Ziel kann die Unterstützung des Benutzers während der Nutzung bzw. Ausführung einer Aufgabe sein. Auch hier spielt die Komplexität der Anwendung und der Tasks eine wichtige Rolle. Für einfachere Tätigkeiten können unter anderem Action Hints (siehe Abschnitt 3.2) oder Eingabehilfen (siehe Abschnitt 3.5) ausreichend sein, wohingegen komplexere Aufgaben wie die Wartung einer Maschine häufig mehr Führung und Unterstützung erfordern und somit eher mit Hilfe eines Assistenten bzw. Wizards (siehe Abschnitt 4.2) durchgeführt werden.


Usability Professionals 2013 UX Best Practices

Die Komplexität der Anwendung und der damit durchgeführten Aufgaben bildet somit das zweite Kriterium, das bei der Auswahl des Konzeptes berücksichtigt werden muss. Gleichzeitig eignet es sich, um die Hilfe-Konzepte in drei Kategorien zu unterteilen: –– Leichtgewichtige Hilfe-Konzepte für einfachere Aufgaben und schnelle Hilfestellung. –– Weiterführende Hilfe-Konzepte, die stärker ins Detail gehen und meist umfangreicher sind. –– Spezielle Hilfe-Lösungen, welche für einen bestimmten Anwendungsfall konzipiert sind. Neben diesen beiden Kernkriterien, Ziel und Komplexität, spielen weitere Punkte wie die Integration des Hilfe-Systems und dessen Pflege eine wichtige Rolle, da dies in der Regel ab einem bestimmten Grad sehr auf­ wendig werden kann. Jedoch sollte diese Entscheidung zugunsten des Benutzers und nicht der Entwickler getroffen werden.

Abb. 1. Start Screen der YBoard iPad App [1]

In den nachfolgenden Kapiteln werden diese unterschiedlichen Kategorien im Detail vorgestellt. 3. Leichtgewichtige Hilfe-Konzepte Leichtgewichtige Hilfe-Konzepte sollen dem Benutzer in erster Linie eine gewisse Starthilfe oder einen neuen Anstoß geben, um seine Aufgabe zu erfüllen. Von daher findet sich der größte Teil der Konzepte direkt nach dem Start der Applikation wieder, um den ersten Einstieg in das Produkt zu erleichtern. Zu dieser Kategorie zählen vor allem die aus dem Mobile-Umfeld bekannten Konzepte wie Onboarding (siehe Abschnitt 3.4), Action Hints (siehe Abschnitt 3.2) oder Coach Marks (siehe Abschnitt 3.3). Aber auch während der Nutzung können leichtgewichtige Hilfestellungen wie Eingabehilfen oder die Spotlight-Suche den Benutzer unterstützen. 3.1. Start Screens Start Screens sind einzelne Seiten, die die Bereiche, Funktionen oder Bedienung einer

Abb. 2. Überladener Start Screen der Project Magazine iPad App [2]

Anwendung auf einen Blick erklären sollen. Sie werden häufig im Mobile-Kontext ver­ wendet, um die Gestensteuerung der jeweiligen App zu erklären [Abb. 1] und nach erstmaligem Starten der App gezeigt. Das Augenmerk bei Start Screens sollte auf  der Menge der Inhalte liegen, da sie leicht überladen wirken können. [Abb. 2] Man sollte sich somit bei der ­Gestaltung für eine Thematik, die man erklären möch­te, entscheiden oder stattdessen beispielsweise das Onboarding-Konzept (siehe Abschnitt 3.4) wählen und Informationen auf mehrere Screens aufteilen.

3.2. Placeholder Content / Action Hints Platzhalterinhalte oder Action Hints geben dem Benutzer eine Hilfestellung für den ersten bzw. nächsten Schritt. Dabei wird der jeweils mögliche Schritt durch einen gra­ fischen Hinweis oder eine andere Beschaffenheit der Funktion hervorgehoben. Sie bieten dem Benutzer somit eine Starthilfe und verringern die anfängliche Hürde bei der Erstbedienung. Ein verwandtes und weiterführendes Konzept sind Coach Marks (siehe Abschnitt 3.3).

153


Abbildung 3 und 4 zeigen Beispiele für den Platzhalterinhalt. Die visuelle Gestaltung gibt einen Hinweis auf die StandardFunktion, die der Benutzer auswählen kann, um seine Aufgabe zu beginnen. [Abb. 3]

Abb. 3. Projektbeispiel SMS Siemag (Ergosign)

Die aktuelle Google Maps iPhone App in Abbildung 4 zeigt die Umsetzung eines Action Hints. Der Benutzer wird während der Erstbedienung nach jedem Schritt auf den nächstmöglichen hingewiesen, um den Gebrauch der App nach und nach zu erlernen. Diese Art der First User Experience kann auch häufig bei Spiele-Apps beobachtet werden, die den Benutzer bei den ersten Schritten unterstützen und somit die Spielweise erklären. [Abb. 4] 3.3. Coach Marks Coach Marks sind Hilfestellungen, die mögliche Aktionen des aktuellen Screens erklären. Ein häufiger Anwendungsfall ist die Einführung von neuen Funktionen oder speziellen Custom Controls. Durch das Konzept wird der Benutzer auf die Neuerungen hingewiesen und bekommt gleichzeitig eine Erklärung mitgeliefert. Im Gegensatz zu den speziellen Action Hints oder Platzhaltern liegt der Fokus auf dem gesamten Screen und seinen Funktionen.

Abb. 4. Placeholder Content und Action Hints Beispiele (Runkeeper / Wunderlist / Google Maps iPhone Apps)

Der linke Teil der Abbildung 5 liefert ein Beispiel für den Einsatz von Coach Marks als permanente Schnellhilfe. Der Benutzer kann durch Auswahl des Hilfe-Buttons in der Fußleiste den aktuellen Screen überlagern und sich die Erläuterungen zu den möglichen Aktionen anschauen. Ein Tap auf eine beliebige Stelle des Screens löst diesen Zustand wieder auf. Der rechte Teil zeigt den klassischen Einsatz von Coach Marks nach dem Start der YouTube Capture iPhone App zur Erklärung der Funktionen. [Abb. 5] 3.4. Onboarding

Abb. 5. Coach Mark-Beispiele

154

Onboarding ist ein beliebtes Konzept für die Vorstellung einer Applikation oder


Usability Professionals 2013 UX Best Practices

neuer Features. Dabei werden mehrere Screens mit jeweils einem Inhalt hintereinander geschaltet und ermöglichen es dem Benutzer somit, die Applikation Schritt für Schritt kennen zu lernen. Speziell für weniger technikaffine Nutzer ist dies ein leichter Weg, um sich mit einem Programm auseinanderzusetzen, wohingegen erfahrenere Benutzer solche vorgeschalteten Screens häufig als lästig und überflüssig empfinden. Generell sollte deshalb bei der Verwendung von Onboarding darauf geachtet werden, die Menge der Screens auf eine geringe Anzahl zu beschränken, pro Screen nur ein Thema abzubilden und stets eine Abbruchbzw. Auslassmöglichkeit anzubieten. In Abbildung 6 werden verschiedene Ausführungen und Einsatzmöglichkeiten des Onboarding-Konzepts vorgestellt. Die YouTube Capture iPhone App verwendet das Konzept gleichzeitig zur Vorstellung und Schnellkonfiguration der App, wohingegen Wunderlist beispielsweise gleich mit zwei unterschiedlichen Umsetzungen des Konzepts arbeitet. In der ersten wird auf die wichtigsten Inhalte der App eingegangen, die zweite soll neue Features in den Vordergrund stellen. [Abb. 6]

Abb. 6. Onboarding-Beispiele der YouTube Capture und Wunderlist iPhone Apps

3.5. Permanente/Dynamische Eingabehilfe Neben den vorgelagerten oder überlagernden Hilfe-Konzepten ist es natürlich ebenfalls wichtig, den Benutzer während seiner Handlungen zu unterstützen. Eine Möglichkeit, Nutzer bei Eingaben zu unterstützen, sind Eingabehilfen. Dies können zum Einen permanente oder dynamische Hinweistexte zu bestimmten Restriktionen sein [Abb. 7] oder zum Anderen auch spezielle Eingabe-Controls, wie beispielsweise ein Datepicker, welche einer falschen Eingabe direkt entgegen wirken. 3.6. Spotlight/ Hilfe­Menü­Suche Die Spotlight-Suche „ist eine von Apple entwickelte Desktopsuche für Max OS X. Sie ist darauf ausgelegt, möglichst schnell

Abb. 7. Beispiel für permanente und dynamische Eingabehilfe (Ergosign)

Dateien des Benutzers zu finden.“ [3] Dafür kann der Benutzer einen Suchbegriff in ein spezielles Suchfeld eingeben und erhält bereits während der Eingabe eine kategorisierte Ergebnisliste. Seit Mac OS X Leopard wurde eine weitere Funktionalität in das Hilfemenü jedes Programms integriert, mit der es möglich ist, das Programmmenü zu

durchsuchen. Die Ergebnisliste enthält zum einen Verweise zu entsprechenden Hilfekapiteln und zum anderen passende Menüobjekte, die bei Mouse-Over im geöffneten Menü hervorgehoben werden. [Abb. 8] Vor allem bei sehr komplexen und umfangreichen Applikationen ist diese

155


Art von Suche eine große Unterstützung für Benutzer, um selten genutzte Bereiche oder Funktionen schnell zu finden. Gleichzeitig schult die Verwendung der Suchfunktion das Wissen des Benutzers über die Software. 4. Weiterführende Hilfe-Konzepte In spezialisierten und komplexen Anwendungen, wie beispielsweise ERP- oder Leitstand-Anwendungen, wird häufig auf stärker ausgearbeitete Hilfe-Konzepte

Abb. 8. Mac OS X Hilfe-Menü-Suche

zurückgegriffen, um die Benutzer zu führen und die Masse an Informationen und Funktionen zu erfassen. Aber auch in diesem Bereich gibt es verschiedene Ausprägungen der Hilfestellung, die abhängig vom Kontext eingesetzt werden können. Die Unterschiede der Konzepte liegen hierbei zum einen in der Stärke der Benutzerführung und zum anderen in der Positionierung bzw. Einbindung innerhalb des User Interface. So bieten Assistenten und Wizards eine starke Benutzerführung innerhalb der zu erfüllenden Aufgabe und konzentrieren

sich auf einen Teilbereich der Anwendung, wohingegen globale Hilfebereiche die Handlungen des Benutzers nicht einschränken, sondern in erster Linie Hilfestellungen bieten. 4,1. Application Walkthrough / Guided Tour Der Application Walkthrough bzw. die Guided Tour ist, wie der Name es schon sagt, eine durch das System unterstützte Führung durch die Software und ist in gewisser Weise eine erweiterte Form des Onboardings (vgl. Abschnitt 3.4). Wie auch beim Onboarding können verschiedene Inhalte durch das Konzept abgedeckt werden. Insbesondere bei komplexen Systemen macht es unter Umständen Sinn, mehrere Touren mit unterschiedlichen Themen anzubieten, die der Benutzer bei Bedarf starten kann. So können neben einer Systemeinführung auch aufgabenspezifische Lösungen angeboten werden. Die Stärke der Benutzerführung kann bei dieser Lösung variiert und dem Kontext angepasst werden. Ebenso verhält es sich mit der Ausführlichkeit der Hilfestellung. Eine Tour kann sowohl detaillierte Schrittfür-Schritt Anweisungen beinhalten oder lediglich grobe Erläuterungen zu den einzelnen Handlungen bzw. Bereichen anbieten. Welcher Detailgrad der richtige ist, hängt von der Thematik der Tour und der Komplexität des Systems ab. Ein Beispiel für eine aufgabenspezifische Tour liefert Abbildung 9. Der Benutzer kann aus einem Set von definierten „Storyboards“ wählen und wird in der Durchführung seiner Aufgabe von dem System unterstützt, indem schrittweise Anleitungen und Erklärungen angezeigt werden. [Abb. 9] 4.2. Assistent / Wizard Assistenten und Wizards sind die wohl meistverbreitete Form der Benutzerunterstützung bzw. -führung. Sie beinhalten in erster Linie eine bestimmte Aufgabe, wie beispielsweise eine Installation oder

Abb. 9. Beispiel für die Verwendung einer aufgabenspezifischen Tour (Ergosign)

156


Usability Professionals 2013 UX Best Practices

Wartung, und begleiten den Benutzer durch die einzelnen Schritte. Der Nutzer wird somit bewusst vom Rest der Software abgeschottet, um sich vollständig auf seine Aufgabe zu konzentrieren. Auf Grund dessen muss bei Verwendung des Konzepts jedoch gewährleistet sein, dass alle für die Durchführung notwendigen Informationen innerhalb des Wizards bereitgestellt werden.

4.3. Freie kontextsensitive Hilfe Die freie kontextsensitive Hilfe liefert primär Hinweise zu aktuellen Inhalten oder Aktionen des Benutzers und wird frei auf der Oberfläche positioniert. Sie hat somit keine Benutzerführung, sondern gibt primär Hilfestellungen.

Ein bekanntes Beispiel für ein solches Konzept ist die frühere Hilfefunktion von Microsoft Office 97 „Karl Klammer“ [4], die bei fast jeder Aktion ungefragt erschien und den Benutzer vor allem in seinem Arbeitsfluss unterbrach, anstatt zu helfen. Dies war auch der Grund, weswegen Microsoft ab Office 2007 auf das Konzept innerhalb der Software verzichtete. Generell ist die Verwendung eines solchen Konzepts problematisch, da eine aufwendige Implementierung und ein intelligenter Algorithmus für einen sinnvollen Einsatz nötig sind und zusätzlich die Gefahr besteht, dass der Benutzer sich eher gestört als unterstützt fühlt. 4.4. Feste Hilfebereiche Die sinnvollere Alternative zur freien kontextsensitiven Hilfe sind feste, in die Oberfläche integrierte Hilfebereiche. Diese ermöglichen es ebenfalls, Hinweise, Zusatzinformationen oder Absprünge zum aktuellen Kontext, in dem sich der Benutzer befindet, zu geben. Durch die fixe Position wird der Benutzer nicht durch plötzliche UI-Änderungen irritiert und hat stets die Möglichkeit, die Informationen bei Bedarf zu Rate zu ziehen.

Abb. 10. Beispiel für einen festen Hilfebereich mit Arbeitsanweisungen (Ergosign)

Ein Nachteil einer solchen Hilfe ist jedoch der hohe Pflegeaufwand, da der Bereich mit Inhalt initial gefüllt und aktualisiert werden muss. Abbildung 10 zeigt ein Beispiel für einen Hilfebereich, der fest in das UI integriert wurde und dem Benutzer Arbeitsanweisungen zu den einzelnen Eingaben gibt, die durchgeführt werden müssen. Neben beschreibenden Texten werden auch Grafiken eingesetzt, um die Tätigkeit zu erläutern. [Abb. 10]

Abb. 11. Beispiel für einen Hilfebereich mit grafischer Hilfestellung (Ergosign)

Ein weiteres Beispiel für einen offener gestalteten Hilfebereich ist in Abbildung 11 zu sehen. Die Eingaben auf der linken Seite des Inhaltsbereichs werden zusätzlich grafisch abgebildet und bei Selektion hervorgehoben, so dass der Benutzer einen direkten Bezug und eine Vorstellung zu den Daten herstellen kann. [Abb. 11]

157


5. Spezialisierte Hilfe-Konzepte Neben den bisher systemübergreifend und universell einsetzbaren Konzepten, die eine eher klassische Bedienung mit

Maus oder Touch verfolgen, gibt es bereits Projekte und Forschungen, die mit Hilfe von Augmented Reality spezielle HilfeAnwendungen für die Automobil- und Industriebranche entwickeln und konkrete Use Cases abdecken.

5.1. Interaktive Bedienungsanleitung Eines dieser Projekte ist die interaktive Bedienungsanleitung „Audi A1 eKurzinfo“ der Audi AG, die als App umgesetzt wurde. Mit Hilfe der Kamera des iPhones können bestimmte Bedienelemente des Fahrzeugs fokussiert und erkannt werden, so dass anschließend Informationen zu dem Element angezeigt werden. [Abb. 12] Diese Lösung bietet eine gute Alternative zum eigentlichen und umfangreichen Handbuch, da der Benutzer direkt zu seinem gesuchten Inhalt geleitet wird, anstatt ein endlos langes Manual durchsuchen und studieren zu müssen. 5.3. Wartungskonzepte

Abb. 12. Beispiel für die Fokussierung und Informationsanzeige eines Bedienelements im Audi A1 [5]

Ein weiterer Anwendungsfall für Augmented Reality ist der Einsatz bei Wartungsarbeiten, da beispielsweise speziell im Industriebereich zuerst komplexe Manuale und Dokumentationen mit zahlreichen Anweisungen studiert werden müssen, bevor die Wartung beginnen kann, und zwar ungeachtet der Tatsache, dass der Umgang mit einer Dokumentation in Papierform in einer u.U. schmutzigen Fabrikumgebung und bei der Arbeit mit Handschuhen problematisch ist. Die Verwendung von Augmented Reality könnte somit für diesen Bereich eine enorme Verbesserung darstellen. Dieses Ziel verfolgt unter anderem ein Projekt des Instituts für Prozess- und Produktionsleittechnik (IPP) der TU Clausthal. Die Beteiligten beschäftigen sich mit der Frage „welche Probleme […] bei der Wartung komplexer Anlagen und Maschinen“ [6] auftauchen und wie diese mit Hilfe von Augmented Reality reduziert werden können. Hierzu wurde ein Unterstützungssystem entwickelt, welches basierend auf der Technik der erweiterten Realität und Zuhilfenahme eines Head Mounted Displays Reparaturhinweise und Erläuterungen zu erkannten Maschinenteilen anzeigt [Abb. 13].

Abb. 13. Beispiel-Projekt des IPP der TU Clausthal [6]

158


Usability Professionals 2013 UX Best Practices

Hilfe-Konzept

Beschreibung

Hinweis / Empfehlung

Start Screen

Einzelner Screen, der meist für die Erklärung der Gestensteuerung einer App verwendet wird.

+ Bietet einen schnellen Überblick. – Bietet wenig Raum für Inhalt. – Wirkt schnell überladen.

Placeholder Content/ Action Hints

Hilfestellung zum ersten bzw. nächsten Schritt, die textuell oder grafisch dargestellt werden kann.

+ Verringert die Hürde bei der Erstbedienung. – Problematisch bei komplexen Systemen, da häufig kein Standardvorgehen vorhersehbar ist.

Coach Marks

Erläuterungen zu Funktionen oder Inhalten des aktuellen Screens. Werden meistens durch ­Überlagerung des Screens dargestellt.

+ Hilfreich für Erläuterungen bei neuen Features. + Kann auch als Schnellhilfe fungieren. o Sollte nicht für die Erklärung jeder einzelnen Funktion von umfangreichen Bereichen verwendet werden (z.B. Toolbars).

Onboarding

Abfolge von mehreren Screens, die jeweils einen Inhalt (z.B. Applikationsbereich, Funktion, usw.) erläutern.

+ Geeignet für unerfahrene Benutzer. + Kann auch für Schnellkonfiguration genutzt werden o Einschränkung der Anzahl von Screens beachten (max. 5). – U. U. lästig für technikaffine Nutzer.

Permanente/ Dynamische Eingabehilfe

Unterschiedliche Eingabehilfen wie Zusatzinfos, Datepicker oder spezielle NumPads.

+ Beugen Fehleingaben vor. + In der Regel weit verbreitet. – Je nach Umsetzung evtl. platzintensiv.

Spotlight-Suche

Von Apple entwickelte Desktopsuche, die darauf ausgelegt ist, möglichst schnell Dateien des ­Benutzers zu finden. Mittlerweile mit Erweiterung zur Suche innerhalb eines Programmmenüs.

+ Vor allem bei komplexen und umfangreichen Applikation hilfreich. + Programmmenüsuche schult gleichzeitig das Wissen über die Anwendung. – U.U. aufwendig in der Implementierung.

Application Walkthrough / Guided Tour

Allgemeine oder aufgabenspezifische Führung durch das System oder einen Teilbereich.

+ Kann in der Stärke der Benutzerführung und dem Detailgrad an das System angepasst werden. – Detaillierte Touren sind meist zeitaufwendig in der Erstellung.

Assistent / Wizard

Ein strikter Ablauf, der Schritt für Schritt ­abgearbeitet wird.

+ Weit verbreitetes und bekanntes Konzept. o Bewusste Konzentration auf eine Aufgabe. o Alle notwendigen Informationen müssen bereitgestellt werden.

Kontextsensitive Hilfe

Frei platzierbares Element, das primär ­Hilfestellungen zum aktuellen Kontext gibt.

– Ständige und für den Benutzer unvorhersehbare Unterbrechung im Arbeitsfluss. – Implementierung für einen sinnvollen Einsatz problematisch.

Feste Hilfebereiche

In die Oberfläche fest integrierte Bereiche, die Hinweise, Zusatzinformation, usw. enthalten können.

+ Fester Orientierungspunkt für den Benutzer. Hoher initialer Aufwand für Inhaltgenerierung. – Hoher Pflegeaufwand.

Spezialisierte Hilfe-Konzepte

Für den jeweiligen Kontext speziell erstellte Hilfesysteme.

+ Bieten u.U. die meiste und optimale Unterstützung. – Aufwendig in der Umsetzung.

Tab. 1. Kurzbeschreibung der Hilfe-Konzepte

Ein weiteres Projekt mit dem Ziel, den Be­­ nutzer während der Wartung zu unter­­stützen, wurde im Deutschen Forschungs­zentrum für Künstliche Intelligenz Kaisers­lautern umgesetzt. Dieses beschäftigt sich mit der Unterstützung des

Benutzers beim Austausch der Festplatte eines Laptops [7]. Der Benutzer wird mit Hilfe von Überblendungen Schritt für Schritt angewiesen, wobei das System erkennt, wenn der Schritt durchgeführt wurde und automatisch den nächsten anzeigt.

6. Fazit Ein Hilfesystem ist für nahezu jedes Produkt unerlässlich und sollte somit als Bestandteil des Gesamtkonzepts und nicht als Zusatz

159


angesehen werden. Das ausgewählte HilfeKonzept muss folglich sinnvoll in das System integriert werden, ohne den Benutzer zu stören oder ihm das negative Gefühl zu geben, dass er auf die Hilfe angewiesen ist und es nicht „aus eigener Kraft“ schaffen kann. Auf der anderen Seite sollte die Hilfe nach Möglichkeit immer schnell und einfach erreichbar sein. Auf Grund dessen ist ein gut funktionierendes Hilfe-Konzept ebenfalls ein wichtiges Kriterium für den Erfolg und die Akzeptanz einer Anwendung beim Benutzer sowie die erlebte User Experience.

Literatur 1. Conduce Group (2012). V2 of YBoard for iPad hits the App Store. http://www. conduce.net/v2-of-YBoard-hits-the-AppStore/. (13. Juni 2013) 2. Clay, James (2010). Project – iPad App of the Week. http://elearningstuff.net/2010/12/14/ project-ipad-app-of-the-week/. (13. Juni 2013) 3. http://de.wikipedia.org/wiki/Spotlight_ (Software). (13. Juni 2013) 4. http://en.wikipedia.org/wiki/Office_Assistant. (18. Juni 2013) 5. AUDI AG (2012). Audi A1 eKurzinfo. https:// itunes.apple.com/de/app/audi-a1-ekurzinfo/

Insbesondere die speziellen Hilfesysteme mit der Kombination von Augmented Reality bergen ein hohes Potenzial und könnten einen enormen Fortschritt für den industriellen Bereich bedeuten und bisherige Handbücher sogar ablösen. Und spätestens seitdem sich Größen wie Google an das Thema Augmented Reality herantrauen, sind solche Überlegungen keine fernen Zukunftsträume mehr. [Tab. 1]

id436341817?mt=8. (14. Juni 2013) 6. Institut für Prozess- und Produktionsleit­­technik TU Clausthal (2013). Computer Augmented Reality für Wartungsunterstützung. http://www. ipp.tu-clausthal.de/forschung/projekte/ computer-augmented-reality-fuerwartungsunterstuetzung. (14. Juni 2013) 7. Deutsches Forschungszentrum für Künstliche Intelligenz, Forschungsabteilung Augmented Vision (2013). Automatic sequence tracking for Augmented Reality (AR) Handbooks. http://av.dfki.de/gallery/. (14. Juni 2013)

160


Industrie UX

161


Interfacekonzept für einen „Role-Based Client“ als Anwendung im gesamten Produktlebenszyklus Ralph Tille Hochschule der Medien Wolframstr. 32 70191 Stuttgart tille@hdm-stuttgart.de

Michael Burmester Hochschule der Medien Wolframstr. 32 70191 Stuttgart burmester@hdm-stuttgart.de

Abstract Für einen großen Automobilzulieferer soll das Software-Interface eines „Role-Based Client“ entwickelt werden. Dies soll maßgeschneidert für die verschiedenen Rollen und wesentlichen Aufgaben der Mitarbeiter entworfen und umgesetzt werden. Das Hauptziel eines rollenspezifischen Interfaces besteht darin, dass die Mitarbeiter ziel-, aufgaben- und effizienzorientierte Funktionsumfänge angeboten bekommen. Die dazugehörige Fragestellung war, wie die tatsächliche Rolle der Mitarbeiter im Unternehmen aussieht, da sich Themen und Aufgaben je nach Rolle und Nutzergruppe unterscheiden. Zunächst gilt es, die alltägliche Nutzung und den daraus resultierenden Funktionsumfang festzustellen, um danach ein nutzerorientiertes und aufgabenspezifisches Interfacekonzept zu erstellen. Für ein Role-Based Interface stand die Frage im Vordergrund, wie dies beschaffen sein muss. Um die Aufgabenstrukturen detailliert und genauer zu verstehen, wurde ein methodischer, teilweise partizipativer Ansatz gewählt, der es erlaubt, einen übergreifenden Blick auf den Ablauf eines vollständigen Projektes und den Alltag der Mitarbeiter zu werfen. Diese Methodenkombination hat sich sehr gut bewährt um einen Makro- und Mikroblick auf die Projektarbeit zu werfen und daraus entsprechende Anforderungen an die Konzeptentwicklung abzuleiten. Die Erkenntnisse aus der Nutzerstudie lieferten die Basis für die Modellierung einer Persona und einem Anwendungsszenario sowie einem Szenario-Mockup für ein maßgeschneidertes und konfigurierbares Interface.

1. Ausgangssituation Für einen großen Automobilzulieferer sollte ein für verschiedene Rollen und wesentliche Aufgaben maßgeschneidertes Software-Interface – einen „Role-Based Client“ – entwickelt werden. Die Mitarbeiter nutzen innerhalb der Software-Umgebung im Unternehmen verschiedene Anwendungen für spezifische Aufgaben innerhalb der technisch-kaufmännischen Entwicklungsprozesse im Automobilsektor. Das Spektrum der zu entwickelnden Anwendung erstreckt sich über den gesamten Produktlebenszyklus: von Akquisition und Pflichtenhefterstellung, Konzeptions- und Mustererstellungsphase sowie nachfolgenden Produkt- und Prozessentwicklungsphasen bis zur Überführung in Serienprozesse. Aufgrund umfangreicher und heterogener Aufgabenbereiche wurden als

erste Zielgruppe die technischen Teamleiter in der Entwicklung ausgewählt. Der Schwerpunkt liegt auf Produktplanung, der Produkt- und Prozessentwicklung sowie der Fertigungsvorbereitung. [Abb. 1]

Abb. 1. Produktentstehungsprozess nach Westkämper (2006)

162

Keywords: /// Interfacekonzeption /// Role-Based Interface /// Produktentwicklung /// PLM

Die technisch-kaufmännischen Teamleiter verantworten im Unternehmen umfangreiche Schlüsselfunktionen bis hin zum Kunden. Sie koordinieren Mitarbeiter, Prozesse und Ressourcen im Unternehmen


Usability Professionals 2013 Industrie UX

sowie bei Lieferanten und weltweit verteilten Produktionswerken. Eine erste Bestands­ aufnahme im Unternehmen zeigt, dass die Bandbreite der Software-Anwendungen ebenfalls sehr heterogen und umfangreich ist. Es werden bspw. ein E-Mail-Client mit Kalenderfunktion eingesetzt, übliche OfficeSoftwarepakete, diverse ToDo-Listen für die Teams auf der Basis unterschiedlicher Softwareprodukte, spezielle ­Anwendungen für die Abwicklung von Prüfaufträgen, Applikationen für interne und externe Bestellung und Beauftragungen, sowie Anwendungen für das Produktdaten­management im SAP-Umfeld und viele weitere spezialisierte Anwendungen. Zudem gibt es Zugänge zu weiteren Anwendungen im Intranet und zu kollaborativen Dateiplattformen. Im Rahmen der Softwareerneuerung des Produktdatenmanagements soll das RoleBased Client-Interface den Zugang zu Software-Anwendungen erleichtern und eine einfache, effektive und effiziente digitale Arbeitsumgebung bieten. 2. Referenzen und Vorüberlegungen Typische Probleme bei der Nutzung von Anwendungen für das Produktmanagement sind fundamental. Gundelsweiler&Reiterer (2008) identifizieren typische Usability-Fehler: Navigationsprobleme, Probleme bei Auswahl und Informationssuche sowie Fehler bei der Darstellung oder Verzögerungen beim Arbeiten mit Anwendungen. Während der R ­ echerche wurden typische Anwendungen mit rollen­ basiertem Interface wie bspw. Microsoft Dynamics NAV (2013) im Bereich des Customer Relation Managements (CRM) oder ABAS ERP (2013) im Bereich der Enterprise Ressource Planning (ERP) Software genauer betrachtet. Dabei ist wesentlich, dass die Systeme eine höchst umfangreiche und flexible Datenbank bzw. Datenbasis als Grundlage haben, um unterschiedlichen Nutzern für die vielfältigsten Anwendungsfälle die gewünschten Informationen liefern zu können. Problematisch sind daher eingeschränkte oder nicht vorhandene Schnittstellenzugänge sowie inhomogene Datenbasen. Dadurch dass unterschiedliche Nutzergruppen auf dieselben Daten

zugreifen können, ist eine freie Konfigurierbarkeit des Interfaces naheliegend und ermöglicht Flexibilität. Diese Parameter sind jedoch auch Faktoren für die Komplexität eines Interfaces und potentielle Fehlerquellen zugleich. Die Fokussierung und Auswahl auf wenige, wichtige Funktionen ist notwendig. Das Zusammenlegen von thematischen und aufgabenspezifischen Funktionen bietet eine weitere Reduktion der Komplexität, ohne dass auf Funktionen verzichtet werden muss. Die Anpassbarkeit und Flexibilität der o.g. Systeme ist so weitreichend, dass dies für bestimmte Nutzergruppen auch ein Hindernis bedeuten kann. Banovic et al. (2012) berichten mit Marathe&Sundar (2011) auch davon, dass die Konfigurationsfreudigkeit vom Leistungsniveau der Nutzer abhängen kann. Eine umfangreiche Liste förderlicher und hinderlicher Faktoren von Konfigurierbarkeit findet man nach wie vor bei Mackay (1991). Für Konfigurierbarkeit spricht, dass man in unterschiedlichen Projektphasen arbeitet, bestimmte Abläufe jedoch individuell abweichen und daher Nutzer selbst Einstellungen vornehmen müssen. Insofern kann Konfi­gurierbarkeit zwar hilfreich sein, aber eine Maßanfertigung für den Nutzer verspricht viele Fehlerquellen zu vermeiden. Vorab angepasste Interfaces haben Vorteile, für gleich ablaufende Tätigkeiten. Somit ist ein klares Verständnis der Rollen und Aufgaben der Nutzer notwendig (Findlater et al., 2008), was in der nachfolgend be­schrieben Studie beschrieben wird. 3. Ziele, Fragestellungen und Vorgehen Das Hauptziel dieses Projektes ist die Entwicklung eines rollenspezifischen Interfaces, um administrative Aufgaben im Produktentwicklungsprozess zu erleichtern und zu beschleunigen. Das Interface soll daher ziel-, aufgaben- und effizienzorientiert sein, d.h. es soll den Nutzern für spezifische Aufgaben die Informationen direkt, schnell und ohne Umwege bereitstellen. Die Aufgaben und Rollen betreffen laut den Angaben des Unternehmens einen großen Teil des Produktlebenszyklus. Die Herausforderung bestand darin, dass die Tätigkeiten im Tagesverlauf und über

den gesamten Projektablauf unterstützt werden sollen. Dabei ist es durchaus üblich von Projekt zu Projekt zu wechseln und situationsabhängig und zeitlich sehr fragmentiert zwischen unterschiedlichen Aufgaben und Tätigkeiten zu springen (z.B. Besprechungen mit Teammitgliedern, To-Do-Listen pflegen, etc.). Ineffizienzen in Detailinteraktionen (z.B, unnötige Mehrfacheingaben in unterschiedlichen Anwendungen) sollen vermieden werden. Zudem stand fest, dass die bisherigen Software-Anwendungen sehr unterschiedliche Usability-Qualitäten aufwiesen und teilweise nicht aufeinander abgestimmt waren. Die umfangreichen Tätigkeiten der Primärzielgruppe greifen in viele Unternehmensbereiche ein, was für einen Abgleich und die Übertragung der Erkenntnisse auf die Prozessmodelle anderer Nutzergruppen spricht. Basis ist ein für das gesamte Unternehmen gültiger, formalisierter Produktentstehungsprozess, der i.d.R. aus den Komponenten Prozesse, Phasen, Meilensteine, Aufgaben, Methoden und Reifegrade besteht (vgl. Ristic, 2011). Allerdings gibt es Unterschiede zwischen idealem Prozessmodell und „gelebten“ Abläufen. Die zentrale Fragestellung für diesen Teil war, aus welchen Komponenten sich die Rolle des Teamleiters zusammensetzt. Im ersten Schritt wurde mit den Teilnehmern deren mentales Modell der Unternehmensprozesse anhand eines oder mehrerer Projekte besprochen und visualisiert. Diese Informationen sollten den Interviewern Detailkenntnisse zu gelebten Prozessen und verwendeten Fachbegriffen liefern, um im nächsten Schritt gezielte Fragen zu konkreten Abläufen der täglichen Projektarbeit und zum Arbeitsplatz stellen zu können. Daraus lassen sich Funktionsumfang, Probleme, Wünsche und Bedürfnisse der Nutzer feststellen sowie etwaige Abweichungen zum formalen Prozessmodell identifizieren. Die anschließende Analyse der erhobenen Daten ergibt ein Anforderungsmodell für die Interface-Konzeptentwicklung und Prototypenerstellung und soll die Fragestellung beantworten, wie ein Role-Based Interface beschaffen sein soll, um die Rolle und deren Aufgaben zu unterstützen. Eine Persona soll als prototpisches

163


Entwicklungswerkzeug modelliert werden, welche die Eigenschaften, Wünsche und Bedürfnisse der Nutzer beinhaltet. Danach soll ein Aktivitäts-Szenario für typische Abläufe im Projektalltag entwickelt werden. Am Ende sollen dann Interfaceund Interaktionskonzepte entworfen werden. Dieses Vorgehen entspricht dem szenariobasierten Gestaltungsansatz von Rosson&Carroll (2002).

Abb. 2. Momentaufnahme einer CARD-Session für die Prozess-Sicht.

In einem Anschlussprojekt werden die späteren Prototypen bzw. Mock-Ups empirisch mit denselben Nutzern validiert (Tille et al., 2013), um das Interface weiter zu detaillieren und ein Gestaltungskonzept zu erstellen. Die daraus gewonnenen Erkenntnisse fließen als Anforderungen in ein Lastenheft für die Software-Entwicklung. Das Vorgehen in der Studie lässt sich wie folgt darstellen: – Anforderungs-Erhebung aus NutzerPerspektive – Sammlung von Hinweisen direkt von den Mitarbeitern – Verständnisaufbau der Arbeitsabläufe und Arbeitsweisen – Herstellen der Prozesssicht („was“) und Workflow-Sicht („wie“) – Meta-Analyse der Zusammenhänge für erste Konzepte – Anforderungen an das Interface für einen Role-Based Client – Persona- und Szenariomodellierung sowie Anwendungsszenario als Mock-Up 4. Methoden Das Verständnis der Rollen und Aufgaben der entsprechenden Zielgruppe zu erlangen, ist wesentlich um passende Interfacekonzepte zu erstellen. Die vom Unternehmen definierte Rolle der Teamleiter lässt sich anhand folgender Aufgabenschwerpunkte im administrativen und technisch-kaufmännischen Bereich charakterisieren: – Kontrolle von Aufwänden, Projektstand, Termine, Zeitbedarfe – Steuerung von Anpassungen im technischen Bereich (Produktauslegung etc.)

Abb. 3. Ausschnitt eines visualisierten Prozessmodells der Nutzer

164


Usability Professionals 2013 Industrie UX

Abb. 4. Ausschnitt aus der inhaltlichen Analyse der Interviews

– Überwachung der Kosten (Finanzcontrolling) – Dokumentation der Projektfortschritte – Ansprechpartner für alle technischen Fragestellungen im jeweiligen Bereich Diese Beschreibungen sind sehr generisch, da sie für eine große Anzahl von Mitarbeitern gelten sollen. Der gewählte methodische Ansatz erlaubt es, detaillierte Kenntnis der Aufgabenstrukturen und Abläufen der Teamleiter im Alltag zu erlangen und einen übergreifenden Blick auf ein vollständiges Projekt zu werfen. Dazu wurde eine angepasste Form der CARD-Methode (Tudor et al., 1993, Muller, 1993) eingesetzt. Die Methode hat stark partizipativen Charakter, da die Teilnehmer selbst ihre Sicht auf die Prozesse herstellen, bewerten oder verändern. Hier sollten die Teamleiter, die Aktivitäten, Abläufe und Verzweigungspunkte eines kürzlich bearbeiteten Projektes mit Hilfe von zu beschriftenden Karten auf einem Tisch visualisieren und im Detail erläutern. [Abb. 2] Dies wurde mit 3 erfahrenen Teamleitern durchgeführt. Die Visualisierungen können vom Teilnehmer selbst korrigiert werden, da Reihenfolgen, Lücken oder wichtige Aspekte schnell und einfach dargestellt

und verändert werden können. Für den detaillierten Blick in die alltägliche Arbeit in Projekten wurde eine Kombination aus Contextual Inquiry (Beyer&Holtzblatt, 1998) und der Methode „A Day in a Life“ (Gillen et al., 2007) bzw. „The Day Reconstruction Method“ (Kahneman et al., 2004) eingesetzt. Hier geht es darum, den Arbeitsplatz, die Arbeitseinflüsse, die tatsächlichen Bedingungen und Abläufe zu erfassen. Aus diesem Grund wurden weitere 3 Teamleiter in ihrer Arbeitsumgebung besucht. Sie erhielten die Aufgabe ihre aktuellen Arbeiten zu erläutern und den Arbeitstag des Besuches vor Ort von morgens bis abends genau zu beschreiben. Dabei nahm der Interviewer die Rolle des Lernenden im klassischen Master-Apprentice-Model des Contextual Inquiries ein. Der Interviewer verhält sich dabei als Beobachter, Zuhörer und Nachfragender. Die Teilnehmer erläutern die aktuelle, tatsächliche Arbeit und schildern zusätzlich möglichst präzise anhand ausgewählter Arbeitstage, wie die Arbeit verläuft. Durch die Konkretheit der eigenen Arbeitsumgebung reduzieren sich Abweichungen, Idealisierungen oder Verfälschungen. Diese Methodenkombination gab einen genauen Einblick in den Tagesablauf, beispielsweise den häufigen Wechsel von operativ-administrativer Arbeit

am Arbeitsplatz sowie Besprechungen an anderen Orten. Um die Erkenntnisse der empirischen Studie in ein Interfacekonzept zu überführen, wurde der zuvor beschriebene, nutzerzentrierte Prozess, bestehend aus der Persona-Modellierung nach Cooper (1999, 2004, 2007) sowie der szenariobasierten Gestaltung nach Rosson&Carroll (2002) bzw. adaptiert nach Goodwin (2009) gewählt. Das Anwendungsszenario, basiert auf dem Aktivitätsszenario, wurde detailliert und als verständliches Informations- und Interaktionsszenario erweitert. 5. Auswertung und Ergebnisse zu Projekt- und Tagesablauf Die 6 Interviewsitzungen wurden audiovisuell aufgezeichnet und anschließend transkribiert. Das gesamte Material wurde qualitativ ausgewertet, indem zunächst die Themen in den Äußerungen und Erläuterungen identifiziert und anschließend klassifiziert wurden. [Abb. 3] Zur Beantwortung der Frage nach dem Ablauf von Entwicklungsprojekten bei den Teamleitern lagen dann visualisierte Prozessmodelle [Abb. 4] des Workflows innerhalb kompletter Projekte vor.

165


Zur Klärung der täglichen Arbeitsabläufe wurden aus den Themen und den zugeordneten Aussagen, Vorgänge, Bedürfnisse sowie Probleme bei der täglichen Arbeit der Teamleiter extrahiert. Die Aussagen wurden in 27 Themen (Tätigkeiten, Werkzeuge, Strukturkomponenten usw.) eingeordnet, welche wiederum zu fünf nachfolgend aufgelisteten, übergreifenden Kategorien aggregiert wurden. Diese Komponenten bilden das Skelett eines Rollenmodells: 1. Arbeitsablauf 2. Arbeitswerkzeuge 3. Datenablage 4. Kommunikation 5. Kontrolle Auffällig geworden ist, dass bestimmte Werkzeuge und Aufgaben nur in bestimmten Projektphasen relevant sind und zudem nur für bestimmte Teamleiter von Bedeutung waren, was auf eine notwendige Anpassbarkeit auf Nutzerebene hindeutet. Des Weiteren wurde festgestellt, dass bestimmte Werkzeuge sehr wichtig sind und oft genutzt wurden, andere zwar wichtig sind aber selten genutzt wurden, und auch unwichtige und selten genutzte Werkzeuge genannt wurden. Für die Arbeitsstruktur der Teamleiter lassen sich folgende Erkenntnisse ableiten: – Je nach Produktkategorie wird ein komplexes Projekt oder mehrere parallele Projekte in unterschiedlichen Prozessphasen bearbeitet – Projektübergreifende wiederholende Verwaltungstätigkeiten – Zentrale Rolle der Teamleiter im Projekt – Hohes Fachwissen und hohe Verantwortung hinsichtlich Budget, Qualität, Termin, Kunde, Mitarbeiter – Die Tages- und Kommunikationsstrukturen sind höchst dynamisch und teilweise unplanbar – Rückmeldung zu komplexen Baugruppen und Prozessen müssen schnell erfolgen – Häufiger Zugriff auf Statusinformationen – Sehr heterogene, individuelle Datenstrukturen – Ständige Priorisierung von Aufgaben und Prozessen

166

Daraus lassen sich erste Anforderungen an die Konzeption eines Role-Based-Interfaces ableiten: – Individualisierbare Konfigurierbarkeit mit Vorkonfiguration (Templates) ermöglicht eine projekt- und aufgabenorientierte Einstellung ohne Nachteile der Konfigurierbarkeit – Klare Übersicht bestimmter, individueller Informationen aus den spezifischen Anwendungen („Dashboard-Charakter“) – Schneller Wechsel zur gewünschten Anwendung unter Berücksichtigung der aktuell ausgewählten Datensicht (bspw. Projektnummer, Teilenummer) – Applikations- und projektübergreifende Suchfunktion – Zusammenführung der heterogenen Datenstrukturen („Parallelwelten“ vermeiden) Ob und welche Komponenten für andere Rollen übertragen werden können, kann – neben verallgemeinerbaren Anforderungen wie bspw. Übersichtlichkeit oder schnelle Programmwechsel – abschließend nur vermutet werden und sollte daher mit den modellierten Prozessen im Unternehmen abgeglichen und über weitere Studien überprüft werden. Aus den Interviews konnten

Abb. 5. Scribble erster Konzeptideen

wir entnehmen, dass die Zusammenarbeit im Unternehmen sehr stark verzahnt ist, insofern liegt es nahe, dass bspw. die Projektarbeitsstruktur (mehrere niederkomplexe Produkte vs. ein komplexes Produkt), dynamische Tagesstruktur, dynamische Kommunikationsstruktur sowie die heterogenen, individuellen Datenstrukturen auch bei anderen Mitarbeitern von Relevanz sind. 6. Konzeptentwicklung Grundlage der Konzeption bildete ein Anwendungsszenario mit einer Persona namens Stefan Kessler. Während eines realistischen Tagesablaufes wurden Aufgaben eines typischen Teamleiters mit dem Behr Workspace beschrieben. Es wurden Konzeptideen entwickelt, als Scribbles bzw. Wireframes visualisiert [Abb. 5] sowie mit den Anforderungen aus den InterviewAnalysen harmonisiert und wiederum in das Anwendungsszenario überführt. Die Grundkonzeption zeigt hier schon wesentliche Merkmale des Workplace-Ansatzes: individuelle Konfigurierbarkeit und Anordnung von aufgaben- und projektorientierten Werkzeugen sowie programmspezifische und individuell einstellbare Informationssichten aktuell relevanter Datensätze.


Usability Professionals 2013 Industrie UX

Dieses Szenario zeigt und beschreibt konkrete Aktivitäten der Persona entlang eines Tagesablaufs: Arbeitsbeginn, Starten der letzten Sitzung, Konfiguration bestimmter Elemente, Suche neuer Aufträge, Prüfen anstehender Aufgaben etc. Das Interfacekonzept wurde als Wireframe-Darstellung mit einer hochwertigen, realistischen, aber nicht zu final wirkenden Anmutung entworfen, die zu Anmerkungen und Änderungsvorschlägen animiert. Der Arbeitsbereich oder Workspace [Abb. 6] ist eine Arbeitsfläche auf dem Bildschirm vergleichbar zu einem „Desktop-Dashboard“ und bietet für die verschiedenen Programme eine aktuelle Vorschau, die es dem Nutzer ermöglicht, Kontrollinformationen in unterschiedlichen Detailgraden einzusehen, bevor der Absprung in das weiterführende Programm (bspw. SAP) erfolgt. Es können mehrere Workspaces angelegt werden. Die Vorschau ist in drei verschiedenen Größen verfügbar (klein, mittel, groß). Der Nutzer kann seine Workspaces frei konfigurieren und dazwischen hin und her wechseln. Diese Konzepte sollen es ermöglichen, den Anforderungen paralleler, phasenübergreifender Projektarbeit und einem schnellen Wechsel zur entsprechenden Anwendung gerecht zu werden und eine möglichst einfache, vorkonfigurierte und trotzdem individuelle Anpassbarkeit abzubilden.

Abb. 6. Aufbau eines Workspace

Um einen neuen Workspace anzulegen, klickt der Nutzer auf den Bereich „Auswahl Spaces“ und bekommt alle vorhandenen Workspaces angezeigt, so wie ein Feld mit der Aufschrift „+“, über das ein neuer Workspace angelegt werden kann. [Abb. 7]

Den Nutzern können außerdem Mustervorlagen zur Verfügung gestellt werden, auf deren Basis sie ihren Workspace konfigurieren und wiederum als eigene Vorlage abspeichern können. Die Mustervorlagen könnten die in verschiedenen Phasen erforderlichen Programm-Informationen enthalten. Dadurch wird die Komplexität reduziert und auf wesentliche Aufgaben und deren Werkzeuge fokussiert. Über die Option „Auswahl Programme“ bekommt der Nutzer alle Vorschaumöglichkeiten angezeigt, die er auf seinem Workspace platzieren kann. [Abb. 8] Der Nutzer kann

Abb. 7. Auswahl Workspace

Abb. 8. Auswahl der Programmvorschau

frei wählen, welche Vorschau er sich wo anzeigen lässt und auf dem Workspace die Vorschaugröße ändern. Ein Hauptmerkmal des Konzeptes ist die Programmvorschau [Abb. 9] mit den Stati der aktuellen Projektsituation für einen Überblick, ohne dass weitere Anwendungen gestartet werden müssen. Die dreistufige Darstellungsgröße bietet entsprechende Detailansichten. Vorkonfigurierte Informationselemente können innerhalb eines Rasters positioniert werden. Prinzipiell dürfen sich Informationselemente

167


Die mittlere Vorschau zeigt einen Aus­ schnitt aus dem Programm, wie hier am Beispiel VAMAS zu sehen ist. [Abb. 11] VAMAS ist eine Anwendung für das Management von Validierungsaufträgen im Rahmen von Qualitätsmaßnahmen der Produktentwicklung. Über die Pfeilspitzen kann in die kleine oder große Darstellung gewechselt werden.

Abb. 11. Vorschau VAMAS mittel

Über das Zahnrad kann die Ansicht konfiguriert werden Beispielsweise können in VAMAS Tabellenspalten für die Vorschau gewählt werden. [Abb. 12]

Abb. 9. Basisansicht des Workspace

nicht überlappen, um dem Nutzer immer Zugriff auf sämtliche Informationskanäle zu liefern. Details zu den schmalen, einzeiligen Vorschau-Elementen (bspw. „3 anstehende Aufgaben“) können über ein einfaches „Mouse-Over“ bezogen werden. Das Konzept der mehrstufigen Ansichten in Verbindung mit einer ständigen Sichtbarkeit aller Komponenten verspricht den Vorteil, dass der Überblick nicht verloren geht – eine zentrale Anforderung aus der Studie. Zwar ist die aktuell ausgewählte Informationseinheit [Abb. 13] im Fokus, doch auch andere Statusinformationen sind parallel für Entscheidungen verfügbar – das entspricht der Anforderung, Auf­ gaben und Prozesse ständig priorisieren zu können. Die Programmvorschau ist das „Herzstück“ des Konzeptansatzes. Wesentlich ist dabei, dass die Nutzer aktuelle Informationen aus den von ihnen ausgewählten Datensätzen der Programme angezeigt bekommen, was eine ständige Kontrolle und Übersicht der wesentlichen Informationen ermöglicht und den Anforderungen nach Konfigurierbarkeit und individueller, aufgabenspezifischer Übersicht entspricht.

168

Der Absprung in das Programm erfolgt von jeder Größe aus über einen Doppel­ klick. Über der Vorschau stehen jeweils der Programmname und der Projektname, falls die Vorschau projekt­bezogen ist. Der „Landepunkt“ innerhalb der Ziel-Anwen­ dung sollte möglichst korres­pondierend zur Vorschau-Ansicht sein, damit sich der Nutzer schnell in der jeweiligen Anwendung und den entsprechenden Kennzahlen wiederfindet. Die kleine Vorschau zeigt nur den Programmnamen und eine Statusmeldung. Über die Pfeilspitze kann in die mittlere Größe gewechselt werden. Der hell orangene Vorschaubalken zeigt an, dass Aufgaben oder Meldungen im Programm ausstehen. [Abb. 10] Gibt es keine Statusmeldungen aus dem Programm, ist der Balken im Prototyp in einem dunkleren orange gestaltet. [Abb. 9] ­

Abb. 10. Vorschau EDM klein

Die größte Darstellung eines Programmes zeigt in der Detailansicht die gesamte Vorschau. [Abb. 13] Der Nutzer kann hier scrollen, um alle Informationen einzusehen. 7. Erkenntnisse und nächste Schritte Gerade die Methodenkombination hat sich sehr gut bewährt, um einen Makro- und Mikroblick auf Projektarbeit von Teamleitern zu werfen. Auf Basis dieser empirischen Erkenntnisse konnte eine Persona mo­­ delliert und ein umfangreiches Szenario entwickelt werden. Die Konzeptvorschläge basieren ebenfalls auf den nutzerzentrierten Befunden und ergaben ein stringentes und kompaktes Interface. Die nächsten Schritte sind die Validierung des aktuellen Konzeptes mit den Teamleitern sowie die Überprüfung, welche Aspekte auf andere Rollen und deren Anforderungen übertragen werden können, um danach in die Software-Entwicklung zu gehen und funktionsfähige Prototypen für Feldversuche zu entwickeln.


Usability Professionals 2013 Industrie UX

Care, 177 (2), S. 207–218. 8. Goodwin K. (2009). Designing for the Digital Age: How to Create Human-Centered Products and Services. Indianapolis: Wiley Publishing. 9. Gundelsweiler, F.; Reiterer, H. (2008). Advanced User Interfaces for Product Management Systems. Proceedings of the 3rd IASTED International Conference on Human Computer Interaction (IASTED-HCI

Abb. 12. Spaltenauswahl in VAMAS

08), Acta Press, Canada, p. 180–188, Jun 2008. 10. Kahneman, D., Krueger, A.B., Schkade, D.A., Schwarz, N. & Stone, A.A. (2004). A Survey Method for Characterizing Daily Life Experience: The Day Reconstruction Method. Science 3 December 2004: 306 (5702), 1776–1780. [DOI:10.1126/ science.1103572] 11. Mackay, W.E. (1991). Triggers and barriers to customizing software. In Proc. CHI ‘91. ACM, S. 153–160. 12. Marathe, S. &Sundar, S.S. (2011). What drives customization?: control or identity?. In Proc. CHI ‘11. ACM, S. 781–790. 13. Microsoft Dynamics NAV. (2013). Zugriff am 30.04.13 unter http:// www.microsoft.at/admp/70D3B4F4– 4BE9–4BD0–844C-F5462E2004EB/ NAV2009+Rollencenter+Uebersicht.pdf 14. Muller, M.J. (1992). Retrospective on a year of participatory design using the PICTIVE technique. In: Striking a Balance: Proceedings of CHI’92. Monterey CA: ACM, S.455–462.

Abb. 13. Große Vorschau

15. Ristic, S. (2011). An Overview of the Approaches for A PLM Application‘s Customization. XV International Scientific 5. Cooper, A. (2007). About Face 3: The

Literatur 1. ABAS ERP Software. (2013). Zugriff am 30.04.13 unter http://www.abas.de/de/download/ abas_erp/produktbroschuere_2013.pdf 2. Banovic, N., Chevalier, F., Grossman, T.,

Essentials of Interaction Design. Indianapolis: Wiley Publishing. 6. Findlater, L., McGrenere, J., Modjeska, D. (2008). Evaluation of a role-based approach for customizing a complex

Conference on Industrial Systems (IS’11). 16. Rosson, M.B. & Carroll (2002). J.M. Usability Engineering – Scenario-based development of human-computer interaction. San Francisco: Morgan Kaufmann. 17. Tille, R., Burmester, M., Schippert, K. (2013,

Fitzmaurice, G. (2012). Triggering Triggers

development environment. In Proceedings

akzeptiert). Role-Based-Client Workspace

and Burying Barriers to Customizing Software.

of the SIGCHI Conference on Human

– Entwicklung von Dashboard-Interfaces

In Proc. CHI’12.ACM, S. 2717–2726.

Factors in Computing Systems (CHI ‘08).

im Product Lifecycle Management (PLM).

ACM, New York, NY, USA, 1267–1270.

Im Tagungsband der 10. Berliner Werkstatt

3. Cooper, A. (1999). The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (1st Edition).

DOI=10.1145/1357054.1357251. 7. Gillen, J., Cameron, C. A., Tapanya, S.,

Mensch-Maschine-Systeme, Oktober 2013. 18. Tudor, L.G., Muller, M.J., Dayton, T.,

Pinto, G., Hancock, R., Young, S., &Accorti

Root, R.W. (1993). A participatory design

Gamannossi, B. (2007). ‘A Day in the Life’:

technique for high-level task analysis,

the Asylum: Why High Tech Products Drive

advancing a methodology for the cultural

critique, and redesign: The CARD method.

Us Crazy and How to Restore the Sanity (2nd

study of development and learning in early

In: Proceedings of the Human Factors and

Edition).

childhood. Early Child Development and

Ergonomics Society 1993 Meeting, Seattle

4. Cooper, A. (2004). The Inmates Are Running

WA, Oktober 1993, S.295–299

169


„Time = Money“: User-Interface-Konzept zur zeiteffizienten Auslegung komplexer Solaranlagen Einblicke in Gestaltungs-Muster und Usability-Parameter einer webbasierten Konfigurationssoftware im internationalen Kontext Oliver Gerstheimer chilli mind GmbH Königstor 23 34117 Kassel www.chilli-mind.com gerstheimer@chilli-mind.com

Simon Griwatz chilli mind GmbH Königstor 23 34117 Kassel www.chilli-mind.com griwatz@chilli-mind.com

Dr. Thomas Straub SMA Solar Technology AG Sonnenallee 1 34266 Niestetal www.SMA.de Thomas.Straub@SMA.de

Abstract „Sunny Design Web“ ist die erste webbasierte Planungs- und Auslegungs-Software der Solarbranche, die plattformübergreifend umgesetzt wurde. Ziele des Projekts waren die Entwicklung und das Re-Design einer zeit- und logikoptimierten Informationsarchitektur, sowie neuer Interaktionsstrukturen für Touch-Computing. Bestehende Konfigurationszeiten von zirka 10 Minuten für eine Solaranlagenauslegung wurden für den Bereich der „Solar-Professionals“ bei gleichem Umfang an Konfigurationsmöglichkeiten halbiert. Der Beitrag reflektiert den Design-Thinking-Prozess in der Projektierung von der UserExperience-Analyse bis zur programmiertechnischen Umsetzung und gibt dabei Einblicke in die identifizierten Gestaltungsmuster, die evaluierten Usability-Strukturen sowie die Restriktionen bei der Use-Case-Logik und der Dialogisierung zum Anwender. Fokuszielgruppe der Anwendung sind internationale Fachhandwerker und gewerbliche Anlagenplaner („Solarteure“), die weltweit wahlweise manuelle oder automatisierte Auslegungen von Solaranlagen im Alltag nutzen. Neben der Desktop-Browseranwendung liegt der Schwerpunkt auf einer optimierten Bedienbarkeit für die effiziente Anlagenplanung im mobilen Nutzungskontext mit Tablet-PCs.

1. Ausgangssituation und Zielsetzung Die SMA Solar Technology AG ist weltweit führend in der Entwicklung, der Produktion und dem Vertrieb von Solar-Wechselrichtern für Photovoltaik-Anlagen. Sie stellt Fachhandwerkern und Anlagenplanern die Windows-PC-Software „Sunny Design 2.2“ zur Auslegung, also der Berechnung netzgekoppelter Photovoltaik-Anlagen zur Verfügung. Darüber hinaus ist es mit dieser Software möglich, die Dimensionierung des Querschnitts der elektrischen Leitungen vorzunehmen und den Eigenverbrauch in die Berechnungen mit einzubeziehen. Umfangreiche Datenbanken zu standortabhängigen Klimadaten, Solarmodulen und SMA-Wechselrichtern unterstützen die Anlagenkonfiguration. Es ist sowohl die automatische wie auch manuelle Auslegung von Solaranlagen

170

möglich. Daneben existieren umfangreiche Konfigurationsmöglichkeiten, wie z. B. die Definition eigener Photovoltaik-Generatoren (Solar-Module) oder das Hinzufügen individueller Wetterdaten und elektrischer Verbrauchsprofile. Um neben Windows-PCs auch auf anderen Systemen lauffähig zu werden, sollte eine browserbasierte Web-Anwendung mit erweitertem Funktionsumfang erstellt werden. Insbesondere die touch-optimierte Bedienbarkeit auf iPads und weiteren Tablet-PCs sollte gewährleistet werden. 1.1 Herausforderung Die Herausforderungen bei der Entwicklung und Umsetzung des neuen User-InterfaceKonzepts für die Sunny-Design-Anwendung beziehen sich auf unterschiedliche Aspekte

Julian Mengel SMA Solar Technology AG Sonnenallee1 34266 Niestetal www.SMA.de Julian.Mengel@SMA.de

Keywords: /// Zeitoptimierung /// Industrie-Interfaces /// Touch-Computing-Interface /// Responsive Design /// Web-Applikation

der Informationsarchitektur mit Informationsgewichtung und Use-Case-orientierter Neustrukturierung der Inhalte und Funktionen, sowie auf die Usability-Anforderungen im Rahmen der zeiteffizienten Aufgabenbearbeitung bei der Anlagenauslegung. Nachfolgend sind die wesentlichen Anforderungen und Ziele aufgezeigt. –– Re-Design und Neuentwicklung der Informationsarchitektur von der be­ste­henden PC-Anwendung zur ersten internationalen Multi-Devicefähigen Web-Anwendung im Photovoltaik-Bereich. –– Optimierung des Time-to-ResultFaktors mit Halbierung der Benutzungszeiten bei einer Anla­gen­ auslegung mit gleichem Konfigura­tions­raum und Einstellungs­möglichkeiten. –– Entwicklung eines flexiblen Touch-Computing-Interfaces mit


Usability Professionals 2013 Industrie UX

3. Entwicklung und Definition von Gestaltungsmustern und Layouts sowie adaptive Design- und Tabletoptimierung als Grundlage des User-InterfaceDesigns („Skinning“); 4. Technischer Systemhintergrund mit teilautomatisierten Vorschlagsprozessen und -mechanismen sowie Personalisierungs-/Bibliotheksangeboten und Feedbackstrukturen. [Abb. 2]

Abb. 1. Ausgangspunkt Sunny Design Desktop-Anwendung 2.2

Responsive-Design-Struktur für den internationalen Anwendermarkt mit Fokus auf Anlagenplanung und Detailkonfiguration von Photovoltaikanlagen auf PC-, Mac-, iPad- bzw. Tablet-PC- und weiteren mobilen Frameworks (iOS, Android, Windows Phone). – Aufgabenbasierte Unterscheidung von zeitlichen, kontextuellen und zielkundenspezifischen Zugangsstrukturen: „Fast Track“ mit Verwendung systemseitiger DefaultEinstellungen und automatisierten Auslegungsvorschlägen und „Long Track“ mit manueller und detaillierter Anlagenauslegung inklusive individueller Anpassung lokaler und spezifischer Einstellungen. – Rollenbasierter Zugang mit Relevanzfokus für drei definierte Hauptnutzergruppen: Anonym/Gast, registrierte Nutzer, kostenpflichtige Zugänge mit Premiumdiensten. – Flexible Kunden-Nutzen-Fokussierung (Stakeholder) für gewerbliche Nutzer (Power-User) und interessierte Endkunden einerseits, sowie für „normale“ Hausanlagen und komplexe gewerbliche Solar-Anlagen (bis 30 kW) andererseits in allen relevanten Zielmärkten. 2. Entwicklungsansatz, Projektverlauf und Teilprojekte

Ausgangssituation des Projekts waren die bestehenden Sunny Design Desktop-Anwendungen 1.5 und 2.2 mit ihren vielfältigen und komplexen Möglichkeiten der Anlagenauslegung und Einstellungsmöglichkeiten.

Nachfolgend sind entwurfsrelevante Aktivitäten und Aspekte aus den vier Bereichen aufgezeigt, die unter anderem im Entwicklungsprozess bearbeitet wurden: – Systematische Analyse mit Hinterfragung der bestehenden Informationsarchitektur (IA) und User-InterfaceStrukturen (UI-Strukturen), sowie Evaluation der Zeitkontexte während der Nutzung; – Nutzerzentrierte Priorisierung neuer System-Anforderungen auf Basis

Auf dieser Grundlage sollte eine komplette Neustrukturierung entwickelt, überprüft und bewertet werden. Fokus war eine zielgerichtete Informationsgewichtung und -priorisierung entlang der Haupt-Use-Cases bei der Anlagenauslegung. Eine umfassende Systemanalyse mit Fokus auf Nutzer, Kontext und Aufgabenanforderung stellten die Basis für den grundlegenden Entwurf der neuen Informationsarchitektur und UseCase-Zusammenhänge dar. [Abb. 1] Das übergreifende Entwicklungsframework kann in vier Bereiche unterschieden werden, die relevanten Einfluss im Rahmen der technischen Möglichkeiten und Restriktionen sowie der nutzungsbezogenen Anforderungen auf den Entwurf des neuen „Sunny Design Web“ haben. 1. Systemanalyse Status quo und Anforderungsdefinition aus Nutzer-KontextSicht entlang priorisierter Use Cases mit Experten-Fokusgruppen zur Identifikation von Optimierungspotenzialen; 2. Informationsarchitektur und Usability mit Informationspriorisierung, Entwicklung von Wireframe-Strukturen und Clickflows sowie einer kontinuierlichen User-Experience-Evaluation;

Abb. 6. Entwicklungsframework

171


präferierten Nutzergruppen, eine systematische Sammlung, Strukturierung und Priorisierung von Use Cases und Anforderungen. 2.1.2. Use­Case­Definition: „Relevanz und Frequenz“

Abb. 3. Informationsarchitektur „Fast Track“, „Fast+ Track“ und „Long Track“

vorhandener Kundenfeedbacks mit Fokus auf Zeitoptimierung bei der Standard-Anlagenauslegung; – Nutzer-Kontextanalyse und Bewertung mit Experten zur Ableitung und Definition der Usability-und User-InterfaceAnforderungen bei den neuen webbasierten Bedienoberflächen; – Entwicklung und Simulation von alternativen Click-Prototypen der neuen Lösungsstrukturen für Tablet-PCs zur Überprüfung und Optimierung der User Experience (UX); – Qualitative Befragung/Evaluation der Lösungsstrukturen mit ExpertenAnwendern im Business-Bereich (B2B) und Endkunden im Consumer-Bereich (B2C) aus Europa und den USA auf Basis einer Prototyen-/Beta-Interaktion mit Think-Aloud-Protokoll. 2.1. Systemanalyse und Use Cases 2.1.1. Nutzer und Kontext: „Time = Money“ Als Grundlage für die Identifikation der Nutzeranforderungen und Use Cases wurden Nutzergruppen identifiziert und als Personas modelliert. Die entwickelten Personas stellten dabei keine real

172

existierenden Personen dar, sondern übernahmen eine Art „Stellvertreterfunktion“ für eine Gruppe ähnlicher Nutzertypen mit spezifischen Charaktereigenschaften und Verhaltensweisen. Neben der Sammlung, Strukturierung und Priorisierung der Nutzeranforderungen und Use Cases wurden die Personas auch genutzt, um zwischen den Projektbeteiligten ein gemeinsames Verständnis von den präferierten Zielgruppen zu erhalten. Die relevanten Nutzer lassen sich grob in die zwei Gruppen der gewerbliche Anwender und der privaten Endkunden unterteilen. Der Fokus bei der Optimierung der Informationsarchitektur lag auf den gewerblichen Nutzern, die in den „Solarteur“ (entspricht einem Installateur), den Anlagenplaner sowie den gewerblichen Nutzer in den USA weiter differenziert wurden. Für diese drei Benutzergruppen gilt das Prinzip „Time = Money“, also die zeitoptimierte, effiziente Durchführung der stark frequentierten Use Cases, als relevantestes Erfolgskriterium. Lesson Learned Personas ermöglichen, ausgehend von einem gemeinsamen Verständnis der

Ausgehend von den definierten Personas wurden typische Use Cases definiert und nach Nutzungsrelevanz und -frequenz bewertet und priorisiert. Der Use Case „Erstellung von Anlagenkonfigurationen“ bekam dabei die höchste Relevanz zugesprochen. Insbesondere die automatische Auslegung, also die systemseitige Unterstützung des Konfigurationsprozesses, wurde als besonders stark frequentiert beurteilt. Unter dem Gesichtspunkt „Time = Money“ sollte die Bearbeitungszeit bis zur erfolgreichen Auslegung einer Photovoltaik-Anlage verkürzt werden. Die Optimierung des Haupt-Use-Cases „FastTrack-Auslegung“ stand so im Fokus des Entwurfs, jedoch mit der flexiblen Möglichkeit den Konfigurationsprozess jederzeit individuell auszuweiten und den gesamten Umfang der Einstellungen zu nutzen. [Abb. 3] Lesson Learned Use Cases ermöglichen es, Aufgaben, Ziele und konkrete Abläufe aus der Perspektive der Nutzer zu definieren und mit allen Projektbeteiligten deckungsgleich zu diskutieren. 2.1.3. Experten­Evaluation: „Test the Best“ Auf Grundlage definierter Use Cases wurde das Vorgängersystem einer Evaluation durch Usability-Experten unterzogen und auf Kriterien wie z. B. Aufgabenangemessenheit, Erwartungskonformität und Fehlertoleranz (Zufriedenstellung), Effizienz und Effektivität hin untersucht. Die besonders relevanten und häufig frequentierten Use Cases wie z. B. automatische und manuelle Auslegung und die im Auslegungsprozess integrierten Use Cases wie


Usability Professionals 2013 Industrie UX

Abb. 4. Wireframe-Strukturen

Eingabe der Basisdaten, Leitungsdimensionierung und Eigenverbrauchsberechnung wurden gezielt unter dem Aspekt einer möglichen Optimierung hinsichtlich einer Zeiteinsparung während der Auslegung analysiert. Entwurfsrelevante Ergebnisse aus der UXEvaluation waren eine generelle Stärkenund Schwächenanalyse der bestehenden Anwendungen sowie die konkrete Identifikation von Optimierungspotenzialen und Ansatzpunkten für die neue Informationsgewichtung. Im Rahmen der Analyse wurden zudem mögliche Herausforderungen bei der Umsetzung der „Sunny Design Web“-Applikation als touch-optimierte Web-Anwendung identifiziert. Lesson Learned Durch die Experten-Evaluation ist es mit einfachen Mitteln schon in einer frühen Projektphase möglich, Optimierungspotenziale und Herausforderungen für den Entwurfsprozess zu identifizieren.

2.2. Informationsarchitektur und Usability 2.2.1. Wireframe, Clickflow und Experten-Evaluation Zur ersten Visualisierung der neuen Layout- und Bedienstrukturen wurden Wireframes entlang der Use Cases erstellt und zu Clickflows zusammengefasst. Dies ermöglichte die Diskussion des Layouts, der Strukturen und Einzelelemente ohne sich in „Geschmacksdiskussionen“ zu verlieren. Durch die schnelle und flexible Anpassbarkeit konnten unterschiedliche Alternativen präsentiert und bewertet werden. Außerdem waren Anpassungen und Änderungen schnell durchzuführen, so dass auf Anmerkungen und Hinweise aus dem Entwicklungs-Team in kurzer Zeit reagiert werden konnte.

priorisierter Sub-Use-Cases, wie zum Beispiel der Suche nach Solarmodulen innerhalb der Anlagenauslegung. [Abb. 4] Lesson Learned Aufgrund der schnellen Anpassbarkeit eigenen sich Wireframes sehr gut als visuelle Diskussionsgrundlage. Sie schärfen die gemeinsame Vorstellung des fertigen Produkts und ermöglichen die Bedien- und Informationsstrukturen zu detaillieren und zu konkretisieren. 2.2.2. Zielgruppenspezifische Workflowoptimie­ rung: „Fast Track“ vs. „Long Track“

Sunny Design ist im Hauptnutzungskontext ein Wizard, der den Nutzer durch den Prozess der Auslegung von Solaranlagen führt. Auf Grundlage von zusammengefassten Einerseits soll die Software einen ungeübten Wireframes als Clickflows wurden unterneh- Nutzer mit wenigen Fachkenntnissen intuitiv, mensinterne Experten und fachlich Veranteffizient und erfolgreich durch den Prozess wortliche schon früh in den Entwurfsprozess der Anlagenauslegung führen, andererintegriert. Die Experten-Workshops dienten seits müssen professionelle Anwender, wie dabei sowohl der Überprüfung der LayoutSolarinstallateure spezifische und teilweise und Bedienstrukturen als auch der Neubesehr detaillierte Konfigurationen und Auslewertung von Relevanz und Frequenz entlang gungen vornehmen können.

173


Abb. 5. Flow-Diagramme zum Fast-Track- und Long-Track-Szenario

Somit treffen hier zwei Nutzungsszenarien und Anwendungsziele mit sehr unterschiedlichen Anforderungen an die Informationsarchitektur und das User Interface aufeinander. Um dieser Anforderungsbreite zu begegnen wurden zwei Haupt-User-Stories mit gleichem Anfangsund Endpunkt entwickelt: –– „Fast Track“ für Effizienz und Geschwindigkeit in der Nutzung bei geringer Vorkenntnis; –– „Long Track“ für professionelle Auslegung mit hohem Detaillierungsgrad. Zwischen diesen beiden Polarisierungsszenarien ist jede beliebige Graduierung möglich. So lässt sich z. B. ein Auslegungsprojekt von einem professionellen Anwender im ersten Durchlauf schnell und grundlegend bearbeiten und kann im Anschluss schrittweise weiter ausgebaut und detailliert werden. [Abb. 5]

Fast Track: schnell und effizient ohne spezielle Vorkenntnisse Die prozedurale Nutzerführung teilt die komplexen Inhalte in verständliche Schritte auf, ohne den Nutzer mit der Gesamtheit zu überfordern. Der dargestellte Inhalt ist jeweils auf die für einen Schritt notwendigen Informationen reduziert, alle weiteren Informationen und Einstellungen können, müssen aber nicht eingeblendet werden. Die schnelle und fehlerfreie Grundauslegung einer Anlage für ungeübte Nutzer steht im Vordergrund. Kontextuell werden hilfreiche Hinweise und Tipps zum jeweiligen Arbeitsschritt eingeblendet.

Systemseitige Unterstützung erfährt der Anwender durch optimierte Voreinstellungen und optionale automatische Konfigurationen, wodurch eine schnelle und erfolgreiche Anlagenauslegung auch ohne besondere Vorkenntnisse ermöglicht wird. Long Track: detailliert und spezifisch für Profi-Nutzer Der professionelle und technisch affine

174

Nutzer kann an jeder Stelle im Auslegungsprozess projektspezifische Einstellungen vornehmen und durch manuelle Auslegung und Dimensionierung die Anlage optimal maßgeschneidert konfigurieren. Einzelne Einstellungen werden in Pop-over-Dialogen dargestellt, um auf die jeweilige Aufgabe zu fokussieren und spezielle technische Informationen kontextuell einzublenden. Teilaufgaben, die in sich bereits sehr komplex sind und eigene Muster bzw. zusätzliche Navigation erfordern, werden im Gesamtkontext zugänglich gemacht, jedoch gesondert in modalen Dialogfenstern bearbeitet um die Konzentration auf die Teilaufgabe zu lenken. Lesson Learned Eine klar definierte Minimallast ermöglicht die Fokussierung auf besonders relevante Funktionen und Eingaben. Die Zeit bis zu einem erfolgreichen Ergebnis kann so stark reduziert werden.


Usability Professionals 2013 Industrie UX

Abb. 6. Anzeige von Hinweisen und Fehlermeldungen am auslösenden Element und in den Detailinformationen

2.2.3. Ausgewählte effizienzsteigernde Features

Vorlagen zu definieren, um so mit wenig Änderungen auch komplexe Auslegungen in kürzester Zeit durchführen zu können.

Neben den bereits beschriebenen effizienzsteigernden Strukturen und Automatismen gibt es noch eine Reihe weiterer Features, die in erster Linie den professionellen Nutzungseinsatz unterstützen und eine deutliche Beschleunigung bei der Anlagenplanung und -auslegung ermöglichen.

Vermeidung von Konfigurationsfehlern Ein sehr wichtiger Aspekt innerhalb einer Planungssoftware mit komplexen Konfigurationen ist die Fehlervermeidung durch klare Feedbackstrukturen, insbesondere bei manuellen Konfigurationen, die bei ungeübten Anwendern leichter zu fehlerhafter Anlagenauslegung führen können.

Persönliche Voreinstellungen und Vorlagen Registrierte User haben weitreichende Vorteile durch die umfangreichen Optionen der accountspezifischen Voreinstellungen. So kann ein Solarteur/Installateur z. B. bestimmte Solarmodule und Geräte als Favoriten auswählen oder systemseitig angebotene Gerätelisten vorfiltern und so die Auswahl von Geräten innerhalb von manuellen Konfigurationen beschleunigen. Bei der Unterstützung der manuellen Auswahl durch systemseitige Auslegungsvorschläge und -vergleiche können unnötige Auslegungsvarianten schon im Vorfeld ausgegrenzt werden.

Das Anlegen von eigenen Anlagenstandorten mit individuellen Angaben zu Wetterdaten, Netzspannung oder Währung unterstützt z. B. Solarteure/Installateure, die überregional oder international arbeiten. Hat ein Installateur häufig ähnliche PV-Anlagen zu planen, profitiert er dabei durch die Möglichkeit, Projekte als

Die Software erkennt Konfigurationsfehler automatisch und zeigt diese direkt am auslösenden Element an. Im Kern der Solaranlagen-Konfiguration, bei der Auswahl und Zusammenstellung von Solarmodulen und Wechselrichtern, werden dem Anwender zum Beispiel die SystemFeedbacks priorisiert und kategorisiert mit Fehlern (z. B. Gefährdung von Wechselrichtern), Warnungen (z. B. energetische Verluste) und Hinweisen (z. B. geringfügige Kompatibilitätsprobleme von Wechselrichtern und Solar-Modulen) angezeigt. Zur Verstärkung der Fehlerkategorisierung werden die Fehlermeldungen mit eindeutigen Farb-Codes hinterlegt und zusätzlich mit Symbol-Icons versehen. Um die Fehler möglichst schnell beheben zu können und um ein unnötiges und zeitraubendes „Trial and Error“ zu vermeiden, werden dem User zusätzlich Lösungsvorschläge und detaillierte Informationen

angezeigt. Ein weiterer positiver Effekt ist die Entlastung der Service-Hotline durch die schnelle und intuitive Fehlererkennung mit möglichen Lösungsalternativen im Nutzungskontext. [Abb. 6] Erweiterte Kontrolle und Transparenz Im Verlauf einer Anlagenauslegung erfährt der Anwender an zahlreichen Stellen Un­ter­stützung durch generierte Diagram­me und Schaubilder um Konfigurationen visuell abzubilden und sie hinsichtlich Anlagenleistung (Performance) und Wirtschaftlichkeit (Wirkungsgrad) besser bewertbar zu machen. Das Ergebnis jedes Projekts (umgesetzte Anlagenauslegung) in „Sunny Design Web“ ist eine Projektdokumentation der Anlagenauslegung, welche als PDF ausgeleitet werden kann. Auch für diesen Bereich wurden Funktionen entwickelt, die den Nutzer hinsichtlich Zeitersparnis und Qualitätskontrolle unterstützen. So können in einer Zusammenfassung zuerst die gesamte Konfiguration und die eingestellten Parameter überprüft und anschließend die Projektdokumentation vor dem Herunterladen als PDF in einer Vorschau durchgeblättert werden.

Lesson Learned Textuelle und visuelle Feedbackstrukturen ermöglichen das schnelle Erfassen, Interpretieren und Bewerten einer Auslegung und ggf. bestehender Auslegungsfehler. Durch individuelle Voreinstellungen

175


Abb. 7. Layout-Framework für Multi-Device-Strukturen (1280 px Breite bzw. 768 px Breite)

können Ergebnisse detailliert und personalisiert werden, ohne den Auslegungsprozess zu verlängern. Gespeicherte Projektvorlagen reduzieren die durchzuführenden Aufgaben auf das Anpassen weniger relevanter Einstellungen. 2.3. Gestaltungsmuster und Layout 2.3.1. Framework und Grundmuster Die Gestaltungsmuster sind an jedem Punkt stark geprägt von der Informationsarchitektur und der inhaltlichen Gewichtung und Schichtung, sowie der prozeduralen Nutzerführung. Die bekannte Forderung an Interfaces „Möglichst alles auf einen Blick und auf einen Klick erreichbar“, weicht der Priorität „Reduzierung auf das Begreifbare mit Orientierung und Unterstützung in den Einzelschritten“. Die Komplexität der möglichen Einstellungen und technischen Informationen fordert ein Aufteilen in verständliche „Häppchen“ und einen geführten, dialogisierten Prozess. Die Herausforderung liegt in der Darstellung von komplexen Tabelleninhalten mit umfangreichen technischen Details. Bei einer Umsetzung im multilingualen Kontext und adaptiven Layout sind hier enge

176

Entwurfsgrenzen gesetzt und eine gute Gewichtung, Gliederung und Auslagerung komplexer Inhalte essenziell. Die Ausrichtung der Darstellung für verschiedene Endgeräte verlangt zudem einen flexiblen Umgang mit unterschiedlichen LayoutBereichen sowie festen, einklappbaren, modalen und adaptiven Bereichen. Das grundsätzliche Layout-Framework ist in die nachfolgend beschriebenen Bereiche gegliedert, wobei die reduzierte und klare Unterteilung in wenige große Funktions- und Navigationsbereiche eine schnelle, durchgängige Orientierung des Nutzers an jeder Stelle in der Anwendung unterstützen soll. [Abb. 7]

– Der Headerbereich (1) beinhaltet Angaben zu Nutzer, Login, ggf. Projekt und Einstellungen; darunter die Prozessnavigation (2) zur Hauptaufgabe „Auslegung einer Anlage“, die Orientierung im Prozess bietet. Je nach Detaillierungsgrad kann der Nutzer einige Punkte optional überspringen (Fast Track). Bereits erledigte Aufgabenbereiche werden als solche dargestellt, bleiben jedoch zugänglich. Der Headerbereich kann ausgeblendet werden.

– Kontextuelle Seitennavigation (3) zu Teilschritten und kontextuelle Hilfe zur Aufgabe (Sprungmarken). Die Seitennavigation wird bei zu geringer Fensterbreite eingeklappt, um den Content-Bereich zu vergrößern. Bei Bedarf kann sie wieder eingeblendet werden. Der sogenannte „Navigator“ stellt kontextuell entweder die Navigation über Projekte (Liste oder Suche), die Projektdaten als Übersicht oder den Anlagenbaum/Projektbaum einer Photovoltaik-Anlage in ihren Einzelkomponenten dar. – Der Content-Bereich (4) verhält sich adaptiv und wird vertikal in Informationsclustern dargestellt, die sich in der Seitennavigation wiederfinden und einzeln über Folding-Boxes aufund zugeklappt werden können. – Modale Funktions-Pop-over (5) dienen der Komplexitätsreduzierung und zur verbesserten Orientierung. Der Fokus liegt jeweils auf einer Teilaufgabe, die dann einzeln abgeschlossen wird. Lesson Learned Die Definition abgeschlossener Unteraufgaben ermöglicht eine Reduzierung der Komplexität durch die Aufteilung in klar strukturierte, aufgabenbezogene Bereiche. Durch den geführten, dialogisierten


Usability Professionals 2013 Industrie UX

Abb. 8. Beispiel für adaptive Bereiche – Header und Seitenleiste

Prozess kann das Zielergebnis in kürzester Zeit erreicht werden, obwohl Zugriff auf unterschiedliche Zusatzeinstellungen und -features besteht. 2.3.2. Responsive Design und Tablet-PCOptimierung (Transmedia-Usability) Für die Gewährleistung einer konsistenten Nutzerführung auf Desktop- oder TabletPC-Computern bei gleichbleibend hoher Usability wurde an dezidierten Stellen ein adaptives Verhalten von einzelnen User-Interface-Elementen und -Bereichen definiert. [Abb. 8] Abhängig vom jeweiligen Inhalt werden bestimmte Bereiche in Bezug auf die aktuelle Fensterbreite des Browser dynamisch skaliert, andere Elemente reagieren auf fixe Sprungmarken und werden stufenweise angepasst, bzw. ganz aus- oder eingeblendet. Bei beiden Prinzipien liegt die Prämisse hier auf einer optimierten Flächenbelegung und einer, der aktuellen Aufgabe angepassten Darstellung und Fokussierung, ohne den Zugriff auf andere wichtige Bereiche und Informationen zu verlieren. Gemäß dem Motto „mobile first“ wurden alle Klickbereiche, Buttons und Eingabefelder von Anfang an für die Anwendung auf Tablet-PCs ausgelegt. Dies betrifft einerseits die Vorbelegung

mit dynamischen, kontextuell sinnvollen Default-Werten und die Vorbelegung mit vorherigen oder häufig genutzten Eingaben/Auswahlen, wie z. B. dem Solarmodul-Typ. Andererseits wurden durchgängig touch-optimierte Interaktionsmuster zur Eingabe von Werten genutzt, um diese z. B. durch Up-/Down-Taps anzupassen statt sie manuell einzugeben. Auch die Notwendigkeit zur Eingabe individueller Texte über die virtuelle Tastatur wurde auf ein Minimum reduziert. Die „klassische“ Tastatureingabe für eine optimale PC-Nutzung bleibt hierbei parallel an allen Stellen erhalten. Um die Lesbarkeit in jeder verfügbaren Sprache zu gewährleisten, wurden Content-Felder mit hohem Textanteil für die Anforderung an eine multilinguale Umsetzung dynamisch und generell großzügig angelegt. Lesson Learned Durch die dynamische Anpassung an verschiedene Fensterbreiten sowie das Ein- und Ausblenden von Elementen ist eine optimale Flächenbelegung bei gleichzeitiger Fokussierung auf die relevanten Einstellungen und Features möglich. Zusätzliche touch-optimierte Eingabemethoden bieten Nutzern von Tablet-PCs komfortable Bedienung, ohne die Nutzung am PC zu behindern.

3. Resultat: Sunny Design Web „Sunny Design Web“ ist eine Software zur Planung von Photovoltaik-Anlagen und bietet Fachhandwerkern und Anlagenplanern eine benutzerfreundliche Bedienoberfläche. Sie schlägt dem Nutzer für eine vorgegebene PV-Anlage – definiert über Standort, verwendete PV-Module, Anlagengröße und ggf. weiteren Vorgaben – mögliche Kombinationen von Wechselrichtern und entsprechende Konfigurationen, insbesondere die Aufteilung in Strings (Reihenschaltung mehrerer PV-Module), vor. Die Auslegungsvorschläge werden über eine Anlagensimulation hinsichtlich Energieertrag und Wirtschaftlichkeit (Anteil der Wechselrichter an den Investitionskosten unter Berücksichtigung des Nennleistungsverhältnisses) bewertet. Manuell erstellte Auslegungen werden automatisch technisch geprüft und der Anwender wird zusätzlich mit zielgerichteten Hinweisen zur Optimierung unterstützt. Schließlich werden der prognostizierte Energieertrag sowie der mögliche Eigenverbrauch an Solarenergie errechnet. „Sunny Design Web“ bietet somit eine optimale Auslegung netzgekoppelter PV-Anlagen. Ergebnis für den Endkunden ist eine maßgeschneiderte PV-Anlage, Fachhandwerker profitieren von der Zeitersparnis im

177


Abb. 9. „Sunny Design Web“ – Touch-Computing-Interface mit Responsive-Design-Struktur

Planungs- und Beratungsprozess. Während der Planung besteht zudem die Möglichkeit, den potenziellen Eigenverbrauch an Strom des Solaranlagenbetreibers zu ermitteln und sukzessive über die erweiterten Konfigurationsmöglichkeiten zu optimieren. [Abb. 9] Die nachfolgend aufgezeigten Funktionsund Nutzungsmerkmale beschreiben wichtige Benefits der Anwendung „Sunny Design Web“ aus Anwendersicht. – Halbierung der Auslegungszeit für eine Anlage durch Optimierung der Benutzerlogik in den identifizierten Hauptanwendungsfällen, verbunden mit der Verbesserung des Zusammenspiels der hintergründigen Systemlogik von Relevanzbäumen; – Flexible Nutzung durch den Zugriff über Web-Browser sowohl am Desktop-Rechner als auch über TabletPCs (iPad und Android-Tablet-PCs);

178

– Zielgruppenspezifische WorkflowOptimierung für sowohl Experten mit umfangreichen Einstellungen und individuellen Vorkonfigurationen (z. B. eigene Wetterdaten und Verbrauchsprofile) als auch für Laien, die schnell und einfach eine Anlage erstellen wollen; – Kontextsensitive Dialogisierung zur besseren Benutzerführung mit eindeutiger Kommunikation der Folgeschritte mit effektiver Fehlervermeidung; – Schnellere Auslegung durch voreingestellte Default-Werte bei Pflichtangaben. 4. Fazit: Effizienz und Informationsarchitektur Das Entwicklungsvorgehen für die neue Informationsarchitektur der „Sunny Design

Web“-Anwendung zeigt, in welchem Maße ein systematischer Design-Thinking-Prozess den transparenten und zielgerichteten Entwurfsprozess unter aktiver Einbeziehung von Experten und Anwendern unterstützen kann. Neben den analytischen Methoden des Persona Designs und der Use-CaseDefinition ist insbesondere die Entwicklung von schnell begreif- und bewertbaren Wireframe-Strukturen essentiell für die gemeinsame Optimierung der grundlegenden Informationsarchitektur – aus fachlicher Experten- und aus UI-Sicht. Das Zusammenspiel von Informationsarchitektur und User-Interface-Design auf der einen Seite mit den systemtechnischen Automatismen und Funktionsmöglichkeiten auf der anderen Seite bilden dabei das ideale Framework für einen optimierten Neuentwurf. Allerdings: Die „Richtige Fragestellung“ zu Beginn zu identifizieren und die passende Antwort während des Projekts


Usability Professionals 2013 Industrie UX

systematisch und dauerwährend zu hinterfragen ist Trumpf. Dies vor allem unter den beiden Aspekten „Was sind die entscheidenden und wirkungsvollen neuen Erfolgskomponenten des Produkts?“ und „Was macht dieses neue digitale ServiceProdukt wirklich, wirklich aus?“. Gemeint sind hierbei sowohl radikal auffällige und damit in der Erstbenutzung kundenspürbare Faktoren einer Produktveränderung und -verbesserung, wie auch „Weitererzählungsfaktoren“ aus Kundensicht.

Denn es kann – neben vielen, ebenfalls relevanten Optimierungsansätzen – nur ein strategisches Masterziel geben.

Diese erfolgsstrategische Identifikation zu Beginn der Projektierung erfolgt über eine ergebnisoffene Fragestellung im Rahmen eines Design (Re-)Thinkings. Den identifizierten Strategie-Helden im vorgestellten Projekt „Time = Money“, also die ZeitErgebnis-Optimierung einer Anwendung, gilt es im Projektverlauf regelmäßig und objektiv auf seine offensichtliche, spürbare Wirksamkeit aus Kundensicht zu evaluieren. Um hierbei erfolgreich zu sein, muss diese Zielsetzung im Projektverlauf innerhalb des Teams wiederholt kommuniziert und re-positioniert werden. Auch Rekapitulations-Meetings auf die Vision der UrZielsetzung sind erfolgsversprechend für die „inhaltlich-strategische Spurhaltung“. Methodische Iterationsphasen mit Visualisierungs- und Modellbaustufen sind im Entwicklungsprozess elementarer Bestandteil und das „Pflichthandwerk“ für eine nutzerzentrierte Produktentwicklung im UX-Team. Die hieraus entstehenden, multiplen Evaluations- und Optimierungsergebnisse bergen für Projektteams allerdings die Gefahr, den eigentlichen strategischen Strategie-Helden „Time = Money“ zu vernachlässigen. Kleinoptimierungen und alternative Detaillösungen werden dann plötzliche situativ übergewichtet und können schnell zu kausalen Fehlentscheidungen und einer möglichen „Überoptimierung“ führen. Es gilt also, im Projektverlauf die Ur-Fragestellung und -Zielsetzung objektiv, aber hartnäckig fokussiert, bis zur kundengerechten Lösungen, den Launch im Markt, umzusetzen und nicht im Projekt- oder Diskussionsverlauf aus dem Blick zu verlieren.

179


Human Centered Design für Prozessleitsysteme in der Industrieautomation Peter Hartmann Schulz Systemtechnik GmbH peter.hartmann@schulz.st

Maike Petzold Schulz Systemtechnik GmbH maike.petzold@schulz.st

Abstract Die Nahrungs- und Futtermittelindustrie ist geprägt von höchsten Ansprüchen an Funktionalität und Zuverlässigkeit der Produktionsanlagen. Aufgrund der hohen Komplexität und Individualität einer Anlage ist eine Umstellung der Systeme stets kritisch. Mit komplizierten Fertigungsprozessen und zusätzlichen Ansprüchen an Überwachung und Nachverfolgbarkeit rückt die Benutzerfreundlichkeit der Software immer weiter in den Vordergrund. Um diesen Anforderungen gerecht zu werden, entwickelt die Schulz Systemtechnik GmbH ein Framework zur Projektierung der Prozessleitsysteme von den Produktionsanlagen. Die Entwicklung des Frameworks steht vor der Herausforderung der unterschiedlichen Nutzer und Nutzungskontexte. Bei der Projektierung wird das Framework von Entwicklern genutzt. Hier liegt der Fokus auf effizienten Werkzeugen zur Erstellung und Wartung einer Anlage. Die von dem Projektierer erstellte Endanwendung wird dann von geschulten Experten genutzt, kommt aber auch in Kontakt mit Lieferanten oder Zulieferern, die Teile des Programms ohne Einführung nutzen können müssen. Um den Ansprüchen dieser verschiedenen Nutzergruppen gerecht zu werden, sollte das Human Centered Design (HCD) schon im Entwicklungsprozess verankert sein. An praktischen Beispielen zeigen wir, die bei uns durchgeführten erfolgreichen und auch gescheiterten Ansätze. Mit unseren Erfahrungen wollen wir uns mit anderen Entwicklern und Projektleitern darüber austauschen, welches die für uns effizientesten Werkzeuge sind und worauf bei der Umsetzung geachtet werden muss.

Einleitung und Motivation Bei dem eingereichten Beitrag handelt es sich um einen Praxisbericht zu der Neuentwicklung eines Frameworks für die Projektierung von Prozessleitsystemen. Das Ziel der Entwicklung ist die Erstellung eines Prozessleitsystems für komplexe Großanlagen der Automatisierungstechnik. Die Herausforderung hierbei ist es, ein nutzerorientiertes System für Projektierer und Endanwender bereitzustellen. Das erfordert die Berücksichtigung verschiedenster Kontexte und Benutzergruppen.

mehr aktuellen Ansprüchen aus technologischer- und Anwendersicht. Aufgrund dessen entschied man sich ein von Grund auf neues System zu entwickeln. Dabei

Die Schulz Systemtechnik GmbH vertreibt bereits seit mehr als einem Jahrzehnt Steuerungssoftware für die Industrieautomatisierung. Sie hat sich funktional am Markt bewährt, entspricht jedoch nicht Abb. 6. Automatisierungpyramide (Ulrich 2007)

180

Keywords: /// Human Centered Design /// Entwicklungsprozesse /// Design Driven Development /// Prototypen /// HCD Tools und Werkzeuge

soll, unter Verwendung moderner Entwicklungsmethodiken und Technologien, die Qualität und Funktionalität aus dem alten Programm beibehalten werden.


Usability Professionals 2013 Industrie UX

Softwareumgebung von Prozessleitsystemen Das Aufgabengebiet eines Prozessleitsystems ist in Abbildung 1 dargestellt. Es umfasst enge Schnittstellen zu den Schichten der MES sowie SPS der Automatisierungspyramide. Das beinhaltet die Steuerung von Werksprozessen, die Erfassung und Modifikation von Betriebsdaten via ERP aus dem MES Bereich, sowie die Kommunikation zur SPS. [Abb. 1] Die angestrebte Software übernimmt alle Aufgaben von der Kommunikation zur SPS, über die Erfassung/ Steuerung aller Anlagenteile (Verladung, Annahme, Produktion usw.) bis hin zu der Steuerung einzelner Werksprozesse und stellt eine Schnittstelle zum betriebseigenen ERP System bereit. Mit dem Augenmerk auf Human Centered Design stellt besonders das Design der Oberflächen der unterschiedlichen Anlagenteile mit ihren divergenten Anwendern eine Herausforderung dar. Anwender sind: – unternehmensinterne Projektierer, die die Software zur Erstellung komplexer Kundenprojekte verwenden und über einen hohen Wissensgrad verfügen, – Anlagenfahrer, die auf Grund langjähriger Erfahrung die Werksprozesse und deren Abläufe sehr genau kennen, zur Steuerung und Störungsbehebung des Werks, – Kundenzulieferer die das System nicht kennen, aber Teile davon bedienen können müssen (Anlieferung, Protokolle und automatisierte Verladungen), – Anlagenbesitzer die Produktionskennzahlen und Berichte einsehen können müssen. Der Zusammenhang der verschiedenen Nutzergruppen wird in Abbildung 2 dargestellt. [Abb. 2]

Abb. 2. Zusammenhang der verschiedenen Nutzergruppen

Abb. 3. Prozessmodell (DIN EN ISO 9241–210)

genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.“ (ISO 9241) [Abb. 3]

Human Centered Design (HCD) „Usabilty ist […] das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext

Human Centered Design ist ein Vorgehensmodell welches die benutzerzentrierte Gestaltung eines Systems anstrebt. Hierbei soll vor allem der Nutzungskontext und

die konkreten Bedürfnisse der potentiellen Anwender berücksichtigt werden. Besonders bei vielschichtigen Anwendungen wie einem Prozessleitsystem ist Wert darauf zu legen, die Komplexität der Bedienung in der Oberfläche effizient nutzbar zu machen. Um eine spätere Unzufriedenheit

181


zu vermeiden sollen bereits im Gestaltungsprozess benutzerzentrierte Methoden zur Umsetzung eingesetzt werden. Die Nutzung von Human Centered Design ist in dem Entwicklungsprozess anzustreben um eine hohe Akzeptanz beim zukünftigen Nutzer zu erzielen. Die Verwendung soll bereits früh im Entwicklungsprozess manifestiert werden um ein konsistentes Produkt bereitzustellen. Die Möglichkeiten zur Einbindung von Human Centered Design Methoden werden in den folgenden Abschnitten erläutert. Umsetzung von HCD in der Entwicklung In den letzten Jahren ist das Bewusstsein für Usability stark gestiegen. Mit diesem Aufschwung gibt es auch eine steigende Anzahl an sehr guter Literatur in Form von Büchern, Beiträgen in Zeitschriften, Webinaren und Onlinebeiträgen. Mittlerweile befassen sich auch vor allem im industriellen Bereich internationale Normen mit dem Thema. Es gibt also zahlreiche Quellen um zu erfahren, was zur Erstellung eines benutzerfreundlichen Programms getan werden kann. Jedoch muss jedes Entwicklungsteam selbst herausfinden wie diese Ansätze umgesetzt werden können. Dies wird je nach Größe des Teams und des Produktes variieren. In den folgenden Abschnitten möchten wir kurz darlegen, wie bei Schulz Systemtechnik versucht wird Human Centered Design umzusetzen. Dies ist ein Konglomerat aus HCD Methoden unter anderem aus (Dahm 2006) und (Noyes 1999) sowie Prozessen und auch Werkzeugen. Wir möchten hier Ansätze zur praktischen Umsetzung sowie unsere Erfahrungen, Aufwände und Nutzen der Methoden zusammenfassen. Wir beschäftigen uns mit den folgenden Themen: –– HCD Methoden –– Benutzerbefragungen –– Feldstudien –– Prototypen –– Participatory Design Review –– Usability Evaluation –– Evaluation von Werkzeugen

182

–– Rapid Prototyping (Low Fidelity) mit Blatt und IndigoStudio –– Rapid Prototyping (High Fidelity) mit Blend –– Design mit Blend –– Wiki und Teamblog zur Kommunikation –– Prozesse –– Design Driven Development –– Wöchentliche Scrum Meetings –– Regelmäßige Sprint Reviews

Fachkräfte der einzelnen Prozesse hingegen besitzen detailliertes Fachwissen, aber beschreiben die Prozesse mit ihrem speziellen Domänenwissen. Für sie selbstverständliche Informationen die essentiell für das Produkt sind, können dabei verloren gehen.

Benutzerbefragung / Interviews

Wie in anderen wissenschaftlichen Disziplinen gibt es auch im Human Centered Design den Bereich von Feldstudien. Hierbei wird eine Untersuchung im „Feld“, also außerhalb der Entwicklungsumgebung und direkt beim Endnutzer durchgeführt. Angelehnt an Feldstudien in der Biologie geht es hier darum den Endnutzer lediglich zu beobachten und zu studieren. Es können Verhaltensmuster und Emotionen erkannt werden.

Interviews mit Anteilseignern an einer Soft­ware sind seit jeher ein elementarer Bestandteil der Softwareentwicklung um die Anforderungen an ein Produkt zu ermitteln. Es kann nach Sommerville (2007) dabei zwischen zwei unterschiedlichen Typen unterschieden werden: 1. „Closed interviews where the stakeholder answers a predefined set of questions.“ 2. „Open interviews where there is no predefined agenda. The requirements engineering team explores a wide range of issues with system stakeholders and hence develops a better understanding of their needs.“ Interviews wurden bei Schulz zu einem sehr frühen Projektstadium durchgeführt, um die ersten groben Anforderungen zu erheben. Dabei werden sowohl die Projektleiter als auch die Endnutzer befragt. Um die Anforderungen explorativ zu ermitteln, wurden stets offene Interviews durchgeführt. Die Interviews wurden in Formen von Lasten- bzw. Pflichtenheften dokumentiert. Es hat sich gezeigt, dass die aus Interviews erhobenen Anforderungen nicht genau genug sind für die Erstellung der Softwarearchitektur wie zum Beispiel dem Datenbankdesign. Wurde Software nach Kundenanforderung aus Interviews erstellt, mussten häufig mittlere bis komplizierte Änderungen vorgenommen werden, sobald der Kunde das Produkt das erste Mal im Echtbetrieb nutzte. Das Problem ist, dass die Projektleiter einen sehr guten Überblick über übergeordnete Prozesse, Abläufe und Integration haben, aber kein detailliertes Fachwissen über die Prozesse besitzen. Die

Um diese Lücke zu schließen wurden daher Feldstudien und Prototypen eingesetzt. Feldstudien

Feldstudien sind ein sehr einfaches Mittel, können aber nur mit einem fertigen oder vergleichbaren Produkt durchgeführt werden. Da sich unser Produkt noch in der Entwicklung befindet, haben wir die Feldstudien mit dem Vorgänger sowie mit vergleichbaren Produkten durchgeführt. Dies erfolgte schon früh in der Entwicklung mit allen Entwicklern. Uns war es wichtig die Feldstudien nicht anzukündigen und als solche anzumelden. Es sollte nicht eine Delegation von 4–8 Menschen gleichzeitig beim Kunden auftauchen und sich das Werk zeigen lassen. Ein solcher Termin wird sonst eher zu einer Demonstration seitens des Kunden. Unter solchen Umständen können normale, tagtägliche Handlungsabfolgen nicht beobachtet werden. Wir haben uns daher entschieden Einzelbegleitungen einzuführen. Dabei ist je ein Entwickler mit dem Ansprechpartner des Kunden vor Ort gefahren um kleine Wartungen durchzuführen. Unter Führung des Ansprechpartners und nicht des Kunden konnte so das ganze Werk und jeder Arbeitsplatz minimal invasiv beobachtet werden. Feldstudien stellen für uns ein sehr effizientes und finanziell wie zeitlich kostengünstiges Mittel dar. Sie benötigen kaum


Usability Professionals 2013 Industrie UX

Vorbereitungszeit, die Durchführung ist einfach und lediglich für die Dokumentation fällt Bearbeitungsaufwand an. Der Nutzen dieser Methode ist schwer quantitativ zu messen. Wir versprechen uns von ihr eine bessere Grundlage für grundlegende Designentscheidungen und besseres Verständnis für Use Cases. Die Entwickler bekommen ein besseres Gefühl für die Anwendungsumgebung in Form von Stress, Zeit, Anlagenumgebung, Prioritäten, PCErfahrung und Ziele der verschiedenartigen Nutzer. Prototypen Prototypen in der Softwareentwicklung können in vielen Formen vorkommen und verschiedene Ziele haben. Ein Prototyp kann ein gezeichnetes Storyboard, ein Video, eine funktionierende Teillösung oder ein interaktives Mockup sein. Für uns sollen Prototypen vor allem zur Ergänzung der Requirementsanalyse dienen. Dabei werden die für uns wichtigen Ziele nach Verhamme (2009) angestrebt: –– „Increases quality of requirements by helping correcting misunderstandings and ambiguities of requirements specifications.“ –– „Exploration and testing the product.“ –– „Identify shortcomings and design inconsistencies.“ –– „Prevention from requirements- and scope-creep.“ Die Ausrichtung auf das Ermitteln von Requirements drängt sogleich auch mehr in die Richtung von Low-Fidelity Prototypen, da diese in der frühen Entwicklungsphase angebracht sind. Sie stellen ein sehr gutes Mittel dar, um eine gemeinsame Grundlage für Diskussionen zu schaffen. Anhand von interaktiven Low-Fidelity Prototypen kann präziser innerhalb des Entwicklungsteams als auch mit dem Kunden kommuniziert werden. High-Fidelity Prototypen die wir mit Blend angelegt haben, stellten einen zu großen Aufwand und zu geringen Nutzen dar. Das bei einem High-Fidelity Prototypen erwartete Lookand-Feel der Anwendung anzulegen ist sehr komplex und konnte in unserem Fall

Abb. 3. Prototyping eines Low-Fidelity Prototypen mit Blend (Microsoft 2013

auch nicht in das Produktivsystem, wegen schlechter Performanz, übernommen werden. Wir haben auch die Erfahrung gemacht, dass einige Kunden bei einem gut aussehenden High-Fidelity Prototypen denken, dass die Applikation doch schon eigentlich fertig wäre und sich dann über die lange Entwicklungszeit wundern. Über die konkrete Nutzung von LowFidelity Prototypen wird in dem folgenden Abschnitt Indigo Studio sowie dem nächsten Kapitel Participatory Design weiter eingegangen. Blend (Low- und High-Fidelity Prototypen) Microsoft Expression Blend ist das Design Werkzeug von Microsoft für WPF und WinForms. Es war ursprünglich dazu gedacht den Designprozess einer Entwicklung auslagern zu können. Die Anwendung bietet folgende Möglichkeiten: –– Graphisches Anlegen von Controls –– Einfaches Anlegen und Ändern von Styles und Vorlagen

–– Automatisierte Generierung von Demodaten um Controls zu testen –– Vereinfachtes Erstellen von Animationen –– Erstellen von Prototypen, klickbar und animiert Für unsere Entwicklung hat sich Blend als enorme Zeitersparnis erwiesen um Controls zu Designen. Das Vorschaufenster für die Controls ist sehr viel robuster als das aus Visual Studio 2010. Durch das Füllen mit generierten Demodaten lassen sich die Controls auch schneller mit verschiedenen Inhalten validieren. Vor der Übernahme in das Produktivsystem wurden die Controls aber grundsätzlich noch einmal bereinigt, da der autogenerierte Code oft etwas aufgebläht ist. Blend bietet zusätzlich Möglichkeiten Prototypen zu erstellen. Dies kann mit skizzenhaften Controls als Low-Fidelity oder auch mit richtigen Designs und ausgearbeiteten Styles als High-Fidelity Prototyp erfolgen. [Abb. 4]

183


Ein großer Vorteil sollte dadurch entstehen, dass diese Prototypen schon vollständig in WPF angelegt werden. Somit sollte eine direkte Übernahme in das spätere Echtsystem möglich sein. Nach unseren Anforderungen zur Prototypenerstellung hat sich aber gerade das als Nachteil erwiesen. Man muss sich schon ziemlich gut mit WPF und seinen Strukturen auskennen um überhaupt einen Prototypen anzulegen. Viele Ideen können nicht direkt umgesetzt werden, da man sich immer nur im Rahmen der WPF Technologie bewegen kann. Soll beispielsweise eine einfache Animation von einem Fenster zum nächsten demonstriert werden, gestaltet sich das als überaus kompliziert, da dies nicht in WPF vorgesehen ist. An solchen Punkten muss dann Programmieraufwand angesetzt werden. Eine Erleichterung sollte auch eine Technologie zum Anlegen von Animationen sein: VisualStates. Ohne hier weiter auf die Technologie eingehen zu wollen, hat sich in unserem Projekt leider gezeigt, dass diese von der Performanz her noch nicht ausgereift ist. Wir mussten erhebliche Geschwindigkeitseinbußen auf der Oberfläche hinnehmen beim Einsatz dieser Technologie, die uns dabei helfen sollte kleine Animationen von Controls darzustellen.

Ingido Studio (Low-Fidelity Prototypen) Aufgrund des hohen Aufwands zum Erstellen von Prototypen, evaluierten wir weitere Alternativen. Letztendlich fiel die Wahl auf das Produkt Indigo Studio von Infragistics. Die Anwendung bietet eine extrem effiziente und zugängliche Handhabung. Mit ihr ist es möglich: –– Schnell komplette User Stories in einem Prototypen umzusetzen –– Unterstützung von Story Boards und Papierskizzen –– Veröffentlichen und Verteilen von Prototypen (HTML) –– Annotieren von Prototypen Die konkrete Nutzung des Tools wird in dem folgenden Abschnitt Participatory Design sowie dem Abschnitt Company 2.0 erläutert. Participatory Design Review Ein Participatory Design Review ist auch unter den Begriffen Pluralistic Walkthrough, Storyboarding, Table-Topping, User-Centered-Walkthrough oder Group Walkthrough bekannt. Bei diesem Vorgehen gehen Entwickler und Nutzer gemeinsam ein Szenario anhand eines Prototypen

in der Software durch. Der Nutzer soll das Szenario alleine und ohne jegliche Hilfestellung oder Einflussnahme lösen. Der Test hat den Vorteil, dass durch verschiedenartige Nutzer viele Probleme in kurzer Zeit und schon früh im Entwicklungsprozess sichtbar werden können. Klassischerweise wird dieser Test in Form eines Workshops mit Papierskizzen durchgeführt (Keld, Kensing, Simonsen 2004). Im Gegensatz zu der klassischen Herangehensweise mit Papierprototypen, haben wir uns für den Einsatz des kostenlosen Prototyping Tools Indigo Studio entschieden. Mit ihm können schnell interaktive und selbsterklärende Prototypen erstellt werden. [Abb. 5] Die detaillierten Workshops werden mit einer ausgewählten Anzahl an Nutzern durchgeführt und intensiv evaluiert. Zusätzlich werden die Prototypen in einem firmenweiten Wiki veröffentlicht. Dort können sie interaktiv im Browser ausgeführt werden. Durch diese Veröffentlichung können auch nicht berücksichtigte Personen, wie aus dem Vertrieb oder fachfremde, die Planung einsehen. Wir erhalten so mehr Feedback und erreichen auch ein firmenweites Einverständnis über den aktuellen Stand der Softwareplanung und einer gemeinsamen „Vision“ des Produktes. Durch die erhöhte und nicht zeitlich gebundene Verfügbarkeit steigt die Wahrscheinlichkeit die Requirements von allen Stakeholdern präzise zu erfassen. Da an dem Prototypen sich nichts „vorgestellt“ werden muss, wie bei einem Papierprototypen, wird das Feedback auch sehr viel konkreter. Usability Evaluation Die Usability Evaluation ist ein formaler Usability Test. Hierbei werden Probanden realistische Aufgaben gestellt, die mit der Applikation erfüllt werden sollen. Für eine unbeeinflusste Durchführung befindet sich der Proband dabei in einem separaten Raum. Häufig werden richtige „Labore“ genutzt, bei denen der Proband durch einseitige Spiegel und Videoaufzeichnungen bei der Durchführung beobachtet werden kann. Sprachaufnahmen und Eye-Tracking

Abb. 5. Rapid Prototyping mit Indigo Studio (Infragistics 2013)

184


Usability Professionals 2013 Industrie UX

können diesen Test vervollständigen. Dies ist einer der aufwändigsten Tests, der aber auch sehr umfangreiche empirische Ergebnisse liefert. Auf Grund des Aufwands, eignet sich dieser Test eher im späteren Entwicklungsverlauf eines Produktes. Er ist nicht nur zeitlich sondern auch finanziell sehr aufwändig. Wir wollen in naher Zukunft einen abgespeckten Usability Test durchführen. Das Motto dabei lautet ganz ähnlich zu den Ingenieuren ohne Grenzen: Low-Cost High-Efficiency. Dieser Test besteht dann aus einem speziell ausgerüsteten Laptop auf dem die zu testende Applikation läuft. Der Proband wird bei der Ausführung mit Hilfe einer Webcam aufgenommen (Audio + Video). Seine Interaktionen mit der Software werden mit einem Screen-Recording Tool aufgenommen. In Kombination mit der Think Aloud Technik (Nielsen 1993), bei der der Proband laut ausspricht was er sieht und denkt, sollen so ähnliche Daten wie zu einem formalen Usability Test gewonnen werden.

dass sie selbst aktiv mitgestalten können. Hierzu werden über das Wiki und das Blog Entwicklungsarbeiten nicht nur bekanntgegeben, sondern auch die Planungen schon in Form von interaktiven Prototypen veröffentlicht. Durch diese Öffnung und den verständlichen Zugriff auf die Planungsstände werden Entwicklungsvorhaben schon früh dezentral validiert. Wir erhalten so weiteren Input, wie die Nutzer Aufgaben verstehen oder welche Aufgaben von den vorhandenen Planungen so noch nicht oder nur schlecht möglich sind.

Participatory IT Design: Designing for Business and Workplace Realities. MIT Press. 2. Dahm, M. (2006). Grundlagen der MenschComputer-Interaktion. Pearson Studium. 3. EN ISO 9241–210:2011–01 (2011): Ergonomie der Mensch-System-Interaktion – Teil 210: Prozess zur Gestaltung gebrauchstauglicher interaktiver Systeme. ISO 9241–210:2010. 4. Infragistics (2013). Screenshot der Indigo Studio Demonstration. http://indigo. 24.06.2013. 5. Microsoft (2013). Microsoft Expression Blend Präsentation. http://blogs.msdn.com/cfsfilesystemfile.ashx/__key/communityserverblogs-components-weblogfiles/00–00–00– 53–15-metablogapi/2350.image_5F00_ 5880459B.png. Abgerufen am 13.06.2013 6. Moser, C., Suter, H. (2013). Interaktion gestalten. .Net Pro 4/2013, Seite 94 ff. 7. Nielsen, J. (1993). Usability Engineering. Interactive Technologies. Morgan Kaufmann Series in Interactive Technologies. Morgan Kaufmann. ISBN 0125184069 8. Noyes, J. M., & Baber, C. (1999). User-

Zusammenfassung und Ausblick

Human Centered Design befasst sich damit „wie die potenziellen Anwender denken und handeln, welche Aufgaben sie mit dem Produkt lösen wollen und in welchem Umfeld sie dies tun“ (Moser, Suter 2013). Mit Hilfe des Wikis und des Blogs aus dem kostenlosen Sharepoint 2013 wollen wir unser Entwicklungsteam mit aufwändigen Usability Tests entlasten. Anstelle auf die potenziellen Anwender zuzugehen, schaffen wir die Möglichkeit,

1. Bødker, K, Kensing, F., Simonsen, J. (2004).

infragistics.com/html/rove/. Abgerufen am

Ein weiterer und nicht zu vernachlässigender Punkt sind die praktisch von selbst und graduell erfolgenden Schulungen über das Wiki. Letztendlich wird die Applikation einen gewissen Komplexitätsgrad aufweisen, da sie auch sehr komplexe Aufgaben lösen muss. Durch die schrittweise Evaluation und konstante Dokumentation lernen die Anwender schon bei der Entstehung die Applikation zu bedienen. Durch die fortwährende Einflussnahme identifizieren sie sich besser und können die Anwendung am Ende besser ausnutzen.

Company 2.0 – Wiki und Team Blog Der Begriff Company 2.0 ist angelehnt an die Bewegung des Web 2.0. Er steht für die grundsätzliche Tendenz weg von starren, festgelegten Inhalten hin zu frei veränderbaren Inhalten und direkter Kommunikation. Letztendlich geht es um die engere Vernetzung aller Mitarbeiter in einer Firma und dem effizienten Bereitstellen von Informationen. Große Eckpfeiler dieser Bewegung sind Werkzeuge wie freie Blog-Dienste oder Wikis. Aber was haben diese Möglichkeiten mit Human Centered Design zu tun?

Literatur

centered design of systems. Springer Verlag. 9. Sommerville, I. (2007). Software Engineering.

Der vorliegende Beitrag zeigt die praktische Umsetzung von Human Centered Design Methoden im Entwicklungsprozess. Die wichtigsten umgesetzten Punkte sind: –– Planung mittels interaktiver Prototypen mit Indigo Studio –– Offenlegung aller Planungsstände im firmenweiten Wiki und Blog –– hierdurch Validierung aller Stakeholder –– Schulung aller Entwickler durch Feldstudien vor Ort –– Feldstudien werden nicht angekündigt und „verdeckt“ durchgeführt –– Durchführen von Usability Tests mit verschlankten Mitteln und Umfängen

Pearson Education. 10. Ulrich, AAB (2007). Automatisierungs­ pyramide MES, Bild zum Wikipedia Artikel MES, http://commons.wikimedia.org/wiki/ File:Automatisierungspyramide_MES.svg, abgerufen am 30.06.2013 unter Creative Commons 3.0 Share Alike Unported. 11. Usability.de (2013). Abbildung zum User Centered Design. http://www.usability. de/services/user-centered-design.html. Abgerufen am 30.06.2013 12. Verhamme, D. (2009). Effective prototyping in embedded systems – comparison of highand low-fidelity prototyping. Masters Thesis, University of Amsterdam. 13. Vredenburg, K., Mao, J. Y., Smith, P. W., & Carey, T. (2002, April). A survey of usercentered design practice. In Proceedings of

Wir konnten damit zeigen, dass auch kleine Entwicklungsteams mit einfachsten Mitteln Usability Engineering betreiben können. Human Centered Design kann also auch mit sehr geringem Zeit- und Kostenaufwand durchgeführt werden.

the SIGCHI conference on Human factors in computing systems: Changing our world, changing ourselves(pp. 471–478). ACM.

185


186


User Research

187


Feldstudien in der iterativen Anwendungsentwicklung Mobile User Experience Optimierung und nutzergetriebene Innovation am Beispiel der Neukonzeption des favor.it Mobile Payment Interface Dr. Markus Wienen eparo GmbH Stahltwiete 22 22761 Hamburg markus.wienen@eparo.de

Dr. Rolf Schulte Strathaus eparo GmbH Stahltwiete 22 22761 Hamburg rolf.schulte@eparo.de

Abstract „Der Beitrag schildert, wie Feldstudien in der iterativen Entwicklung mobiler Anwendungen zum Einsatz kommen und welche Rolle sie dabei übernehmen können. Am Beispiel der Neukonzeption der Mobile Payment Schnittstelle der favor.it-App stellt der Beitrag im Sinne eines Werkstattberichts die Teilschritte des Entwicklungsprozesses dar. Es wird dargestellt, wo und wie Feldstudien die Produkt- und Interface-Entwicklung als pragmatisch und schlank geschnittene Projektbausteine maßgeblich erweitern. Die konkreten Ergebnisse der Neukonzeption der Payment-Schnittstelle werden vorgestellt und diskutiert.“

1. Mobile Anwendungsentwicklung: (K)Ein Blick auf Kontext & Situation Wie entstehen überzeugende mobile An­­ wendungen? – Aus Nutzersicht sind kern­ mobile¹ Anwendungen situations- und kontextorientiert: Für Nutzer bieten Apps und mobile Websites Mehrwerte, wenn sie den gegebenen Kontext berücksichtigen und auf die Situation reagieren, in der Nutzer sich befinden, wenn sie die Anwendung verwenden. Wenn dem aber so ist, wenn ­kernmobile Anwendungen wesentlich auf ihre Nutzungs­­situation bezogen sein sollten, warum erfolgt dann ihre Konzeption, ihre Entwicklung und auch ihre Evaluation fast ausschließlich „vom Schreibtisch aus“ und ohne jeden Blick auf den letztendlichen Nutzungszusammenhang? In der Praxis stehen Unternehmen bei der Entwicklung digitaler Produkte immer mehr vor der Aufgabe, regelmäßiges Nutzer-Feedback schon von Beginn an in ihre Entwicklungsprozesse mit einzubinden. Das zentrale Entwicklungsparadigma heißt ‚Lean UX‘. Ein hier zunehmend verbreitetes und sehr wirkungsstarkes

188

Nutzer-Feedback-Instrument sind Tests im Usability-/User Experience-Labor. Für die Entwicklung und Evaluation kernmobiler Anwendungen allerdings können Labor-Tests schon methodisch nie 100% vollständig sein: denn während sich für Desktop- und Tablet-Anwendungen im Labor authentische Nutzungskontexte durchaus noch erzeugen lassen, können Labor-Studien diese Authentizität für An­wendungen, die explizit auf bestimmte Kontexte und Situationen bezogen sind, nicht herstellen. Für die Entwicklung mobiler Anwendungen heißt das: Allein durch Labor-Tests können wesentliche Erfolgsparameter dieser Services nicht abschließend evaluiert werden. Versteht man Nutzer-Tests darüber hinaus nicht allein als Evaluations-Instrumente, sondern auch als Ansatzpunkt für nutzergetriebene Innovationen, so bedeutet der „Verzicht“ auf eine Evaluation der Parameter ‚Situation‘ und ‚Kontext‘ zudem, dass wesentliche Innovationsmöglichkeiten systematisch übersehen werden können. Die für Apps und mobile Websites am Ende zentrale Frage lautet daher: Wie lassen sich die Nutzungssituation und der

Keywords: /// Feldstudien /// Digitale Produktentwicklung/ Service Design/// Usability Engineering /// Iterative Entwicklung /// Mobile Payment /// Mobile User Experience /// Nutzergetriebene Innovation

Nutzungskontext methodisch sauber in eine moderne, nutzer- und testorientierte Entwicklung digitaler Produkte einbinden? Und die Antwort lautet: Durch pragmatisch angelegte, schlanke und am iterativen Entwicklungsprozess orientierte Feldstudien. 2. Das Vorhaben: Integration von Feldstudien in die iterative Produktentwicklung Feldstudien sind kein neuer Forschungsansatz (Petermann 2004) und in ihrer klassischen, ethnographisch orientierten Form sind sie prinzipiell auch im Usability- und User Experience Research schon lange etabliert (Redish & Wixon 2003). In der überwiegenden Mehrzahl der Fälle werden Feldstudien hierbei als Field Research verstanden und sind primär beschreibend und analyseorientiert. In jüngerer Vergangenheit werden Feldstudien darüber hinaus jedoch auch bereits als Forschungsansatz für nutzergetriebene Innovation verstanden (Nielsen 2012). Prototypisch für den Einsatz von Feldstudien ist dabei die Idee, dass die Studien und ihre Ergebnisse eigenständig und für sich stehen. Demgegenüber soll im Folgenden in einer Art Werkstatt- und


Usability Professionals 2013 User Research

Erfahrungsbericht vorgestellt werden, wie wir aktuell bei eparo Feldstudien als Bausteine eines iterativen, nutzergetriebenen Produkt-Entwicklungsprozesses einsetzen und verstehen. Am Beispiel eines realen Falles soll dabei deutlich werden, 1. dass für die Entwicklung mobiler ­An­wen­dung zentrale Nutzungs- und Erfolgs­faktoren ohne Feldstudien nicht zu heben sind. 2. dass Feldstudien gerade aufgrund ­dieses Umstandes weitreichendes Innovationspotential heben können. 3. und dass Feldstudien dabei weder per se teuer, noch zeit- oder personalintensiv sein müssen und also problemlos in moderne, iterative Entwicklungsprozesse einzubinden sind.

auf  den Ergebnissen dieser ResearchPhase wurden das Interaktions- sowie das Interface-Konzept definiert und als Prototyp umgesetzt. Der Prototyp wiederum wurde sukzessive bis zur Funktionsvollständigkeit ausgebaut und durch Konzepttests bis zum Launch verfeinert.

3. Aus der Werkstatt: Entwicklung der favor.it-App

4. Im Detail: Optimierung eines Mobile Payment Interface

Die favor.it-App verbindet lokale Unternehmen mit ihren Kunden: Cafés und Restau­ rants, Friseure, Optiker sowie ­Ladenlokale und Betriebe aller Art können auf der Platt­ form Coupons für ihre Leistungen anbie­ ten, die interessierte Kunden dann aus der App heraus kaufen und am Point of Sale (PoS) einlösen können. Über einen Favoriten-Mechanismus können Kunden sich automatisch über die Angebote der Unternehmen informieren lassen oder über eine Suchfunktion neue Angebote in der Nähe ihres Standortes oder sortiert nach Kategorien entdecken.

Eine wesentliche Optimierungsschleife nach dem Launch der App betraf des Mobile Payment Interface. Für die App und den ganzen Service ist dieser ­Payment Mechanismus zentral, der bei favor.it, wie schon geschildert, auf Prepaid-Basis erfolgt: Nutzer erwerben Coupons, indem sie Geld von dem Konto, das sie in der App hinterlegt haben, an das Unternehmen, das die Coupons ausstellt, transferieren, und können für ihre Coupons dann später am PoS entsprechende Leistungen erwerben.

Die Entwicklung der favor.it-App erfolgte iterativ und von Beginn an nutzerzentriert. Im Falle von favor.it wurden dazu bereits im Rahmen der Business Case-Definition – die App entstand im Startup-Kontext – und noch weit vor jeder Arbeit an einem Interface erste Feldforschungen betrieben. So wurden mit Blick auf eine der Kernbranchen der Anwendung die Geschäftsführer, das Personal und die Kunden von lokalen Cafés in Einzelinterviews vor Ort befragt, um einerseits die Akzeptanz der Geschäftsidee zu evaluieren und andererseits die Bedürfnissen der verschiedenen Nutzergruppen zu erheben. Aufbauend

Seit dem Launch wird die App kontinuierlich in jeweils mehrstufigen, iterativen Entwicklungsschleifen optimiert. Aller professionellen Expertise folgend hätte zudem noch vor dem Launch mindestens ein Nutzer-Test im Usability-/User Experience-Labor durchgeführt werden müssen. Im Falle der favor.it-App allerdings wurden solchen Nutzer-Tests auf die Optimierungen nach dem Lauch verschoben.

Am Anfang der Neukonzeption der Schnitt­stelle stand dabei die These, dass dieser Prepaid-Mechanismus die Nutzungssituation massiv beeinflusst. Für die Optimierung der Schnittstelle wurde daher eine eigene, initiale Feldstudie angesetzt, an deren Ende eine konzeptionell sehr maßgebliche Einsicht stand: Im Falle von favor.it nämlich verstehen Nutzer nicht das Bezahlen der Coupons als Mobile Payment, sondern aus Nutzersicht erscheint ganz eindeutig das Einlösen der Coupons als das eigentliche mobile Bezahlmoment – und das, obschon das Einlösen zeitlich und funktional völlig getrennt vom eigentlichen Coupon-Kauf erfolgt.

Anders als zunächst vermutet, wird damit für die App – neben der Interaktion mit dem Device – noch eine zweite und übergeordnete Interaktionsebene relevant, nämlich die Interaktion am Ladentisch, in die die App und die Interaktion mit dem Interface passend integriert sein müssen. Und weil aus Nutzersicht weniger die Interface-Interaktion als vielmehr die übergeordnete Interaktionsebene erfolgskritisch ist, muss jede Optimierung der Interface-Ebene am Ende vor allem die Nutzung der App am Ladentisch adressieren und unterstützen. Insgesamt sah der Fahrplan für die Neukonzeption des favor.it Payment Interface demnach sieben Schritte vor: –– Field Research –– Interface-(Neu-)Konzeption –– Konzept-Test & Optimierung –– Prototyping –– Labor-Test & Optimierung –– Feldtest & Optimierung –– Umsetzung Methodisch war dabei klar: Aufgrund der besonderen Relevanz der Nutzungssituation am PoS würde eine finale Evaluation des neuen Interface nur durch einen Nutzer-Test im Feld evaluiert werden können. Ebenso wie zu Beginn der Optimierungsschleife wurde damit auch am Ende der erneute Weg ins Feld relevant. Gleichzeitig war klar, dass der finale Nutzer-Test im Feld die üblichen Test- und Optimierungsschritte – also Konzept- und Labor-Test – keinesfalls ersetzen konnte. Der Feldtest wurde daher als zusätzliche Testschleife angesetzt, um das Interface nach den „üblichen“ Optimierungsarbeiten auch in einem authentischen Nutzungszusammenhang und mit Blick auf die aus Nutzersicht zentrale Käufer-VerkäuferInteraktion evaluieren und optimieren zu können. Konzeptionell musste bei diesem Entwicklungs-Design sichergestellt werden, dass alle für die Nutzung relevanten Situationsparameter schon von Beginn an zumindest grundlegend bekannt waren, um in das neue Interface-Konzept, die

189


Konzept-Evaluation, den Prototypen und den Labor-Test einzugehen, obschon ja die Validierung der nutzungsrelevanten Situationsfaktoren erst am Ende der Entwicklungsschleife erfolgen würde. Wie allgemein üblich war dabei der gesamte Entwicklungsprozess iterativ angelegt: Zum einen bauen die verschiedenen Konzeptions- und Testschleifen aufeinander auf. Zum anderen wurde nach jeder Testschleife bewertet, ob eine weitere Entwicklungsrunde auf dem aktuellen Entwicklungsniveau erfolgt, oder ob die abgeleiteten Optimierungsoptionen auf der nächsten Entwicklungsstufe mit berücksichtigt und validiert werden. 5. Im Feld: Mobile Payment aus Nutzersicht 5.1. Das Situations­/Kontextmodell Methodisch konnte für die finale Evaluation des neuen favor.it Payment Interface nur ein Nutzer-Test im Feld maßgeblich werden. In der initialen Feldstudie, die der Neukonzeption vorgeschaltet wurde, wurden daher an zwei typischen PoS einer der Kernzielbranchen der App – lokale Cafès – Situations- und Payment-bezogene Analysen sowie Interviews mit Kunden und Bedienungen/Verkaufspersonal durchgeführt. Aus den Analysen wurde dann das für den favor.it Bezahlprozess maßgebliches Situations- und Kontextmodell abgeleitet, in dem der Neuentwurf sich würde bewähren müssen. Dabei wurde deutlich, dass für das Einlösen von Coupons am PoS, das aus Nutzersicht, wie gesagt, als der eigentliche Mobile Payment Prozess bewertet wurde, mehrere interaktionsrelevante Situationsund Kontextfaktoren als typisch anzunehmen sind. Dazu gehören auf der Verkäuferseite zum Beispiel hoher Zeitdruck nicht nur zu Stoßzeiten, besondere räumliche Begebenheiten, wie beispielsweise extrem breite Tresen, Lärm und weitreichende soziale Anforderungen an die Payment Interaktion selber.

190

Allem voran war dabei für die Payment Interaktion sowohl aus Sicht der CouponEinlöser wie auch aus Sicht des Verkaufspersonals insbesondere ein Kriterium essentiell: Der Einlöse- beziehungsweise Bezahlvorgang muss auch unter den teilweise schwierigen Situationsbedingungen maximal transparent sein. An erster Stelle heißt das, dass insbesondere für den Verkäufer immer und jederzeit erkennbar sein muss, welcher Coupon aktuell eingelöst wird, und dass der angezeigte Coupon auch genau im gegebenen Moment eingelöst wird. Für den Payment-Mechanismus liegt genau hier das maßgebliche Innovationsmoment: Denn wie die Nutzer-Interviews deutlich machten, wird beim Bezahlvorgang neben dem Coupon-Einlöser auch die Verkaufskraft zu einem Nutzer der App: Denn ebenso wie der Kunde muss auch die anwesende Bedienung die Auswahl und das Einlösen eines Coupons verfolgen können – und zwar auf dem Kunden-Smartphone und über breite Tresen hinweg, während unter Umständen die ersten Kunden weiter hinten in der Schlange schon hörbar über den Zeitverzug zu murren beginnen.

5.2. Das Mobile Payment Interface Die neu konzipierte Mobile Payment Schnittstelle setzt bei der Erkenntnis des Field Research an, demnach für den Erfolg und eine (positive) Experience der App neben der Interaktion auf dem Interface vor allem die Interaktion zwischen dem Coupon-Einlöser und dem Verkäufer kritisch ist – und zwar aus Sicht beider Nutzergruppen. [Abb. 1], [Abb. 2] Der konzeptionelle Ansatzpunkt für das favor.it Mobile Payment Interface ist das Handlungs- und Interaktionsmodell ‚(Print-) Coupon einlösen‘. Wie bei diesem OfflineProzess beruht auch das neue favor.it Payment Interface auf der Idee, dass der einzulösende Coupon, nachdem er ausgewählt wurde, primär und vor allem

Aus den Interviews wurden noch weitere Anforderungen an die Payment-Interaktion deutlich: Aus Käufersicht beispielsweise muss der Einlöseprozess maximal einfach und bis zuletzt unter der Kontrolle des Einlösenden sein. Gleichzeitig gilt es, das versehentliche Einlösen von Coupons zu verhindern. Für Verkäufer auf der anderen Seite musste durchweg völlig eindeutig sein, wann ein Coupon eingelöst und die betreffende Ware also bezahlt und auszuhändigen ist. Als besondere Anforderung wurde deutlich, dass das eigene Smartphone für fast alle interviewten Nutzer nicht durch fremde Personen bedient oder berührt werden soll, wodurch ein Entwerten des Coupons durch eine Verkaufskraft konzeptionell bereits von Grund auf auszuschließen war.

Abb. 1. Mobile Payment Interface für favor.it State „Push To Pay“ (eparo Axure-Prototyp, 2013)


Usability Professionals 2013 User Research

durch die Verkaufskraft hinter dem Tresen einzusehen sein muss. Die Entwicklung des Interface erfolgte ausgehend von dieser Grundidee über mehrere Paper Prototyping Iterationen bis zur Umsetzung eines voll funktionalen Prototypen in Axure. Anders als allgemein üblich, legt dabei das zweiteilige Interface kein Drehen des Smartphones um die vertikale Achse vom Käufer hin zur Verkaufskraft nahe. Vielmehr provoziert die Zweiteilung und „Über-Kopf“-Optik des Interface ein Neigen des Smartphones vom Käufer in Richtung der Verkaufskraft – quasi über den Tresen hinweg. So wird der Coupon für die Verkaufsseite schnell erkennbar und wie auch sein Offline-Äquivalent zum verbindenden Interaktionselement zwischen Käufer und Verkäufer.

Unterstützt wird die schnelle Identifizierbarkeit des Coupons durch eine ebenfalls am Print-Couponing orientierte Optik und durch auf das Minimum reduzierte Kerninhalte wie das Logo des CouponAusstellers, eine eindeutige Kennzeichnung des Coupon-Umfangs in Wort und Bild und ein Badge für den Coupon Typ (z.B. „50% Off“). Weil allerdings aus Sicht der Coupon-Einlöser das eigene Smartphone in keinem Fall durch fremde Personen bedient werden soll, muss das Entwerten des Coupons im digitalen Fall und anders als im analogen Szenario durch den CouponKäufer erfolgen und dennoch gleichzeitig, wie gesagt, für die Verkaufskraft maximal transparent sein. Entsprechend sieht das Interface neben dem Coupon-Teil einen zweiten, dem Käufer zugewandten Bereich vor, über den dieser den Coupon durch eine einfache, native Bediengeste – einen Swipe nach oben – quasi über den Tresen hinweg in Richtung der Verkaufskraft schiebt, um den Entwertungs-Mechanismus freizulegen und den Coupon zu entwerten. Ebenso wie die Entriegelung selber, die ein versehentliches Entwerten des Coupons verhindert, erfolgt dabei auch die Entwertung des Coupons über eine native Bediengeste und hält den Einlösenden, wie gefordert, in der Kontrolle über den Bezahlvorgang. Für die Verkaufskraft auf der anderen Seite wird die Entwertung durch ein mehrdimensionales optisches Feedback symbolisiert. 5.3. Der Feld­Test Bis zum finalen Feldtest wurde das neue favor.it Payment Interface bereits auf Konzeptbasis (als Paper Prototyp) und als elaborierter Klickdummy (als Axure Prototyp) getestet und durch Nutzer evaluiert. Jeweils ist der neue Ansatz dabei umfassend gescheitert.

Abb. 1. Mobile Payment Interface für favor.it State „Entwerten“ (eparo Axure-Prototyp, 2013)

So löste das Interface im Konzept- wie im Labortest bei Nutzern eher ernsthaftes

Unverständnis als erkennbare Begeisterung aus. Zwar konnten die Konzept- und Labor-Tests, wie vorgesehen, wichtige Usability- und Interaktions-Probleme aufdecken. Die grundlegende Interaktionsidee allerdings, die das neue Interface provoziert, blieb den Nutzern vollkommen fremd. Der abschließende Feldtest wurde als qualitativer Nutzer-Test mit 5 Probanden in einem Cafè durchgeführt, in dem die typischen situativen Rahmenbedingungen der App, wie sie im Situationsmodell verdichtet wurden, gegeben waren: Der Tresen war breit, die Schlange der Wartenden gerne mal länger, die Bedienungen eher jünger und weniger erfahren und neben den verschiedenen KaffeeKreationen waren permanent auch noch unterschiedliche Speisen anzurichten und auszuhändigen. Die Probanden erhielten ein kurzes Briefing mit einer konkreten Aufgabe: Sie sollten das ausgewählte Cafè besuchen und einen der Coupons einlösen, die Sie von dem betreffenden Lokal in ihrer App finden würden. Ein Ausprobieren des Einlösevorgangs wurde nicht erlaubt. Im Café wussten die Bedienungen, dass irgendwann Probanden vor ihnen stehen würden, die eine Bestellung mittels Smartphone bezahlen wollen, wussten aber ebenfalls nicht, wie genau dieser Vorgang erfolgen würde. Mit dem Einstieg in die Aufgabe erfolgte für den Testleiter der Wechsel in die Beobachterperspektive: Im ShadowingVerfahren verfolgte der Beobachter fortan die Aktionen der Probanden und hielt Ausschau nach Interaktionsmomenten, die für eine positive User Experience das Couponings erfolgskritisch schienen (Critical Incidents). Diese konnten entweder den Umgang mit dem Interface betreffen oder situations- bzw. kontextbezogen sein. Nach dem Test erfolgte eine Nachbefragung zu den beobachteten Critical Incidents und die Bearbeitung eines vorgefertigten Fragebogens zur Experience des neuen Interface.

191


Als Daten standen neben den Beobachternotizen, die Dokumentation der Critical Incidents sowie die Interview- und Fragebogen-Ergebnisse zur Verfügung.

6. Das Ergebnis: Nutzergetriebene ­Innovation durch mobile Anwendungsentwicklung im Feld

Im Ergebnis ließen sich so durch den Feldtest alle situationsbezogenen InterfaceElemente und -Prozesse validieren: Für alle Probanden und auch für die Bedienungen im Café war der neue Einlöseprozess direkt erfassbar und unproblematisch. Jeder Proband hat sein Smartphone nach der Coupon-Auswahl fast automatisch der Verkaufskraft zugeneigt oder es direkt auf den Tresen gelegt und entsprechend dem Coupon bestellt. Nach einer kurzen Bestätigung des Coupons durch die Bedienung, die mündlich oder nonverbal erfolgte, erfolgten auch die Entriegelung und das Bezahlen ohne Umwege. Der gesamte Vorgang dauerte jeweils nur wenige Sekunden und war damit auch in zeitkritischen Situationen problemlos einsetzbar.

Am Erfolg des neuen Payment Interface waren zwei Feldstudien maßgeblich beteiligt: Erst im finalen Feldtest konnte eine belastbare Validierung der neuen Mobile Payment Schnittstelle der favor.it-App erreicht werden. Voraussetzung dafür war die Ableitung eines belastbaren Situationsmodells im Rahmen einer initialen Feldstudie. Erst aus diesen Analysen konnte der Ansatz für das neuartige, konsequent nutzergetriebene und in mehrfacher Weise auf die Nutzungssituation bezogene Payment Interface gewonnen werden.

2. Nielsen, Jakob (2012): The Most Important

Allein über Konzept- und Labortests konnten Testnutzer die für die Interaktion mit dem neuen Interface zentralen Situationsund Kontextparameter nicht bewerten. Erst im Feldtest wurde erkennbar, ob das neue Interface angemessen auf die Anforderungen der Situation und der Interaktion zwischen Kunde und Verkaufskraft reagiert. Erst im Feldtest wurde die finale User Experience des Interface erlebbar. Gleichzeitig konnten Ansätze für eine weitere Optimierung der Schnittstelle in einer nächsten Entwicklungsrunde gehoben werden.

1 Als kernmobile Anwendungen sollen hier

Literatur 1. Jacko, Julie / Sears, Andrew (Hgg.) (2003): The human-computer interaction handbook: fundamentals, evolving technologies, and emerging applications.

Gleichzeitig ließen aus den Feldtests weitere Optimierungsoptionen ableiten: So war das Feedback für eingelöste Coupons in der getesteten Version aus Sicht der Verkaufskräfte noch zu schwach. Weiterhin war auffällig, dass immer zunächst der Couponing-Prozess abgeschlossen wurde und die bestellte Ware erst danach produziert und ausgehändigt wurde. Anders als beim Offline-Bezahlen wurde damit bei der Ausfertigung der Ware nochmals eine kurze Versicherung zwischen Verkaufskraft und Käufer erforderlich, dass die Ware bereits bezahlt war. Diese Unsicherheit in der Interaktion abzufangen, erscheint sinnvoll.

192

Die initiale Feldstudie und der abschließende Feldtest wurden als zusätzliche Bausteine in die Entwicklungsschleife des Payment Interface integriert. Beide Bausteine konnten dazu zeitlich und personell – und damit auch kostenseitig – schlank gehalten werden. Voraussetzung für den erfolgreichen Einsatz war die klare methodische Verschränkung aller Entwicklungsschritte und ihre Ausrichtung auf den finalen Feldtest von Anfang an.

Usability Activity. http://www.nngroup.com/ articles/the-most-important-usability-activity. Zitiert am 31.07.2013. 3. Petermann, Werner (2004): Die Geschichte der Ethnologie. 4. Redish, Janice / Wixon, Dennis (2003) Task Analysis. IN: Jacko, Julie / Sears, Andrew (Hgg.) (2003): The human-computer interaction handbook: fundamentals, evolving technologies, and emerging applications.

Anwendungen bezeichnet werden, deren Nutzung primär auf Smartphones erfolgt und die ggf. auch bereits konzeptionell auf die Nutzung in Unterwegs-Situationen ausgelegt sind.


Usability Professionals 2013 User Research

193


Experience Tagebücher Potentiale und Einschränkungen der Methode sowie Gesetzmäßigkeiten für den richtigen Einsatz Angelika Kunz USECON GmbH 1110 Wien Modecenterstraße 17/Objekt 2 kunz@usecon.com

Ulrike Gruber USECON GmbH 1110 Wien Modecenterstraße 17/Objekt 2 ulrike.gruber@usecon.com

Markus Murtinger USECON GmbH 1110 Wien Modecenterstraße 17/Objekt 2 murtinger@usecon.com

Abstract Um Produkte oder Services (weiter-)zu entwickeln, ist es oft notwendig und hilfreich, mehr über das tatsächliche Erleben und Verhalten der Benutzer zu erfahren. Dafür bietet der Einsatz von Experience Tagebüchern eine sinnvolle und praxistaugliche Erhebungsmethode. Durch eine systematische Aufzeichnung der Benutzer-Erlebnisse mit bestimmten Produkten, Services oder Interfaces in Abhängigkeit vom Nutzungskontext erhält man tiefere Einblicke in Wahrnehmung und Verhalten der Benutzer als es bei vielen anderen Methoden wie z.B. Befragungen der Fall ist. Experience Tagebücher können sehr flexibel an die Forschungsfrage, die Zielgruppe und die Studiengegebenheiten angepasst werden und bieten interessante weiterführende Anwendungsmöglichkeiten der Ergebnisse. Damit die Erhebung klappt und die Ergebnisse qualitativ hochwertig sind, gibt es eine Reihe von Punkten, die beachtet werden sollten. Welche Formen der Experience Tagebüchern es gibt, wie die Ergebnisse verwendet werden können und was an der Umsetzung zu beachten ist wurde nun analysiert und zusammengefasst. Praktische Erfahrung diesbezüglich konnten wir aus zahlreichen User Experience Projekten mit unterschiedlichsten Herangehensweisen in Forschung und Industrie sammeln.. In dem Beitrag werden Potentiale, wie z.B. eine mobile Erhebung, und Schwächen der Methode, wie die Abhängigkeit von der Zusammensetzung der Zielgruppe, aufgezeigt und Prinzipien für den Einsatz in der Praxis abgeleitet.

1. Einleitung Damit Produkte und Services ideal auf die Bedürfnisse der Benutzer abgestimmt werden können, ist es essentiell die Benutzer zu kennen und zu verstehen. Experience Tagebuch Studien sind eine effektive Methode, das Erleben der Benutzer möglichst unverfälscht und zeitnah zu erfassen. Dabei werden Wahrnehmungen, Einstellungen und Verhaltensweisen der Benutzer in Bezug auf ein Produkt oder Service unter Berücksichtigung der Charakteristiken von Person, Situation und Kontext untersucht. Anhand der Ergebnisse können konkrete Maßnahmen zur Entwicklung und Optimierung von Produkten und Services abgeleitet werden. Darüber hinaus bieten sie die Basis für vielfältige weitergehende Anwendungsmethoden in der Praxis, wie Personas oder Customer Journeys.

194

2. Hintergründe zur Methode 2.1. Methodenbeschreibung Tagebücher sind eine Methode zur Erhe­ bung von einzelnen Ereignissen des Lebens, die von den Teilnehmern selbst wiederholt dokumentiert werden (Bolger et al., 2003). Experience Tagebücher erheben das Erle­ ben und Verhalten der Benutzer in Bezug auf ein bestimmtes Produkt oder Service über einen längeren, vordefinierten Zeitraum. Im Vergleich zur herkömmlichen Tagebuchmethode zeichnen sich Experience Tagebücher vor allem dadurch aus, dass Experience Faktoren, die das Erleben und Verhalten der Benutzer prägen, eine wesentliche Bedeutung beigemessen wird. So werden zum Beispiel Vertrauen in

Manfred Tscheligi USECON GmbH 1110 Wien Modecenterstraße 17/Objekt 2 tscheligi@usecon.com

Keywords: /// Tagebucherhebung /// Benutzerkontext /// Produkt- und Serviceentwicklung /// User Experience /// Checkliste zur Durchführung

ein Service, Ästhetik eines Interface oder die soziale Komponente eines Produktes miterhoben. Aus diesem Grund spielt auch das Sammeln von Artefakten, wie zum Beispiel Bildern, Videos oder Dokumenten eine wichtige Rolle. Artefakte vermitteln neben den subjektiven Schilderungen der Teilnehmer noch viele zusätzliche Einblicke in das Erleben. Experience Tagebücher werden in Kombination mit anderen Erhebungsmethoden, wie zum Beispiel Usability Tests, Online Befragungen oder Workshops, oder nur für sich alleinstehend, im Rahmen von User Experience Studien angewendet. Ein weiteres Kennzeichen von Experience Tagebüchern ist, dass Erlebnisse auch herbeigeführt werden können, indem


Usability Professionals 2013 User Research

Benutzer durch konkrete Aufgabenstellungen in bestimmte Erlebnissituationen gebracht werden und so das Erleben dieser Situation erhoben wird.

Experience Studien. Grundvoraussetzung ist, dass ein ausgewählter Personenkreis über einen vordefinierten Zeitraum hinweg offen seine Erfahrungen teilt.

Ziel von Experience Studien ist es, das Erleben und Verhalten von Benutzern zu analysieren und in die Neu- oder Weiterentwicklung von Produkten und Services einfließen zu lassen.

Für valide und aussagekräftige Ergebnisse muss Wert auf das Studiendesign gelegt werden und folgende Fragen vorab genau geklärt werden: a) Zieldefinition b) Zielgruppe c) Dauer der Feldzeit d) Erhebung und Kommunikation e) Erhebungsmedium

2.2. Vorteile von Experience Tagebüchern Im Vergleich zu anderen Erhebungsmethoden zeichnen sich Experience Tagebücher durch die folgenden Eigenschaften aus: –– Keine Einschränkungen. Im Vergleich zu herkömmlichen Online Befragungen ermöglichen Experience Tagebücher den Benutzern ihr Erleben und Verhalten zu teilen, ohne dabei durch Antwortoptionen oder konkrete Fragestellungen eingeschränkt zu sein. –– Realitätsnähe. Im Vergleich zu Erhebungsmethoden die im Labor stattfinden, wie zum Beispiel bei User Tests, wird bei Experience Tagebüchern das Erleben der Benutzer im Kontext der Nutzung erfasst. –– Flexibel. Der Benutzer hat jederzeit und überall die Möglichkeit Feedback bzw. Input abzugeben. Er muss nicht wie bei Online Befragungen oder Telefoninterviews auf einen Fragebogen oder einen Anruf warten um seine Erfahrungen zu teilen. –– Bildsprache. Durch die über den Zeitraum der Studie gesammelten Artefakte (Fotos, Videos, Dokumente, etc.) erhält man einen noch klareren Einblick in die Erlebniswelt der Benutzer. –– Ereignisbezogen. Der ­Studienleiter kann durch Aufgaben bewusst Erlebnisse steuern, die Methode liefert jedoch auch Aufschluss über Ereignisse die nicht durch das Studiendesign vorgegeben werden. 3. Einsatz von Experience Tagebüchern Experience Tagebücher eignen sich für den Einsatz in verschiedensten User

3.1. Zieldefinition Das A und O einer erfolgreichen Tagebuchstudie ist die Definition von Ziel und Verwendungszweck. Ist erst klar, wofür die Ergebnisse verwendet werden und welche Art von Informationen aus der Tagebuchstudie gewonnen werden sollen, ergeben sich bereits viele der folgenden Entscheidungen daraus. Tagebuchstudien können verwendet werden, um –– Typische Einstellungen, Befindlich­ keiten und Verhaltensweisen im Alltag zu erheben, z.B. wo, wann und wie ein Tablet im Alltag genutzt wird; –– Veränderungen des Verhaltens oder Erlebens innerhalb der Zielgruppen über eine gewisse Zeit feststellen zu können (Langzeitstudie) , z.B. Veränderung des Nutzungsverhalten einer Social Media Plattform innerhalb eines Zeitraums; oder –– Unterschiede zwischen Zielgruppen herauszufinden, z.B. Unterschiede zwischen Power Usern und Einsteigern im Gaming Verhalten 3.2. Zielgruppe Die Zielgruppe will sorgfältig gewählt werden, denn die Aussagekraft der Ergebnisse wird maßgeblich von der Zusammensetzung der Teilnehmer beeinflusst.

Essentiell ist, dass sowohl das Erhebungsmedium als auch die gesamte Kommunikation an die Zielgruppe angepasst wird (z.B. Kommunikation bei Teilnehmern mit anderer Muttersprache). Sonst kommt es schnell zu Frustration der Teilnehmer oder nicht verwertbaren Ergebnissen. Es ist auch überlegenswert, den Begriff „Tagebuch“ den Teilnehmern gegenüber zu vermeiden um falsche Erwartungen oder den Eindruck der Intimität zu vermeiden. Die Anzahl der Teilnehmer an einer Tagebuchstudie kann sehr stark variieren und je nach Studiendesign von einer Handvoll in die Hunderte gehen. Scherbaum und Ferreter (2009) sprachen sich für eine Stichprobengröße über 30 Personen aus, da alles darunter die Ergebnisse verzerren könnte. Diese Empfehlungen richten sich jedoch verstärkt an den wissenschaftlichen Einsatz von Tagebuchstudien und die damit verbundenen Zielsetzungen. In industriellen Projekten, hat sich in vielen Fällen eine Stichprobengröße von um die 15 – 20 Personen bewährt, wenn eine sehr homogene Stichprobe unter denselben Bedingungen untersucht wurde. Sollen unterschiedliche Zielgruppen oder Bedingungen innerhalb einer Studie berücksichtigt werden, ist es wichtig eine Stichprobengröße so zu wählen, dass jede Gruppe entsprechend abgebildet wird. 3.3. Dauer der Feldzeit Die Dauer des Datensammelns einer Tagebuch Erhebung ergibt sich in der Praxis häufig aus äußeren Begebenheiten (Deadlines für die Ergebnispräsentation, Verfügbarkeit notwendiger Geräte, Dauer untersuchter Prozesse etc.). Mit Dauer der Studie steigen die potenziellen Gefahren, wie zum Beispiel eine erhöhte Dropout Quote. Diese kann jedoch beeinflusst werden, indem Incentivierung und Ausfüllfrequenz an die Dauer der Studie angepasst werden. So ist es bei länger angelegten Tagebucherhebungen für die Teilnehmer motivierend, nicht nur am Ende sondern auch während der

195


Studie, zur Halbzeit, monatlich oder nach Meilensteinen, Incentives zu erhalten. In der Praxis hat sich eine Studiendauer von 4 – 6 Wochen bewährt, da die Motivation mit der Zeit abnimmt und die Ausfallwahrscheinlichkeit durch Urlaube, Krankenstände etc. zunimmt. Bei längerdauernden Tagebuchstudien kann es mehrere Phasen geben, über die die Teilnehmer begleitet werden. Zum Beispiel kann ein Prozess ausgehend von der Bestellung über die Installation bis zur Nutzung dokumentiert werden. Wenn die einzelnen Phasen in ihrer Dauer über die Teilnehmer stark variieren (z.B. der erste Teilnehmer bestellt im Mai, der letzte im August) wird das Projektmanagement besonders komplex, da Aufgabenstellung und Kommunikation dann personenbezogen angepasst werden müssen. Hilfreich ist es in jedem Fall sowohl bei längeren wie kürzer dauernden Studien, eine genaue Dokumentation über die Anzahl der Einträge jedes Teilnehmers zu führen. Damit behält der Studienleiter den Überblick über die Aktivität der Teilnehmer und weiß, in welcher Phase der Studie sich der Teilnehmer befindet. 3.4. Erhebung und Kommunikation Die Teilnehmer können die Tagebucheinträge entweder ereignisbezogen oder zeitbezogen vornehmen. Meist ergibt sich die Form aus dem Studieninhalt. Möglich sind auch Mischformen daraus, was in der Praxis häufig eine empfehlenswerte Methode ist. Beim Ereignistagebuch (Kirchler, 1999) macht der Teilnehmer jedes Mal einen Eintrag, wenn ein Ereignis eintritt, das in eine zuvor definierte Kategorie fällt. Diese Methode wird eingesetzt, wenn Prozesse abgebildet werden sollen, wo jeder neue Prozessschritt Auslöser für einen neuen Eintrag ist. Jedoch auch für die Dokumentation von Ereignissen deren Auftreten und Frequenz nicht vorhersagbar und kontrollierbar sind, wie z.B. die Dokumentation von Problemen im Umgang mit einem Produkt.

196

Da das Ereignis der Auslöser des Eintrags ist, besteht der große Vorteil dieser Erhebungsart darin, dass das Ereignis zeitnah und ohne Verfälschung durch die Erinnerung dokumentiert wird. Beim Zeitstichprobentagebuch besteht die Möglichkeit, fixe oder variable Zeiten des Eintrags mit den Teilnehmern zu vereinbaren. Die geforderte Ausfüllfrequenz sollte sorgfältig gewählt sein, um die Teilnehmer weder zu überfordern noch zu langweilen. Geht die Studie über einen Zeitraum von 4 bis 6 Wochen empfiehlt es sich, durch eine gezielte Aufgabe mindestens einmal pro Woche die Aktivität der Teilnehmer aufrecht zu erhalten. Liegt ein Studiendesign vor, in welchem die Einträge in größerem zeitlichem Abstand erfolgen, sollte man Erinnerungsschreiben (Reminder) immer dann einsetzen, wenn wieder Aktivität seitens der Teilnehmer gefordert ist. (Solem et al., 2011) Eine gut geplante Kommunikation betrifft jedoch nicht nur Terminvereinbarungen. Es ist wichtig bereits vor Beginn der Studie die Teilnehmer umfassend über Inhalt, Ziele und Zeitplan der Studie zu informieren. Indem die Teilnehmer die Anforderungen kennen, lassen sich falsche Erwartungen vermeiden und die Dropout Quote damit minimieren. Auch eine Kommunikationsmöglichkeit der Studienteilnehmer an die Studienleiter sollte gewährleistet sein. Zu diesem Zweck sollte eine E-Mail Adresse und/oder eine Telefonnummer eingerichtet und den Teilnehmern kommuniziert werden. 3.5. Erhebungsmedium Es gibt vielfältige Formen der Erhebungstechnik. Die klassische Variante des Papier-Tagebuchs findet immer noch Anwendung, obwohl es in vielen Belangen aufwändiger ist als neuere Methoden wie Online Erhebungen. Es bietet jedoch für manche Fragestellungen maßgebliche Vorteile. Mit Papier-Tagebüchern können

auch wenig technisch affine Zielgruppen erreicht werden und es kann unmittelbar und von allen Zielgruppen in Situationen verwendet werden, in denen üblicherweise kein Computer verfügbar ist, z.B. unterwegs, abends im Bett oder bei der Arbeit außerhalb des Büros. Für ein einfacheres Sammeln von Artefakten werden PapierTagebücher häufig mit Wegwerfkameras kombiniert, mit welchen die Benutzer ihre Erlebnisse in Bildern festhalten. Online Tagebücher haben im Gegensatz zur Papiervariante den Vorteil, dass Ergebnisse schon während der Erhebung ausgewertet werden können und somit wertvolle Zeit gespart wird. Außerdem fällt das oft mühsame Entziffern von Handschriften weg und es gibt einfach und schnell die Möglichkeit, Fotos hochzuladen. Doch auch online gibt es unterschiedliche Möglichkeiten der Datenerhebung. Die Teilnehmer können einfach per E-Mail ihre Tagebucheinträge an eine festgelegte Adresse senden. Das erfordert praktisch keinerlei technische Vorbereitung, Teilnehmer und Zeitpunkt des Eintrags sind schnell ersichtlich, in der Auswertung müssen allerdings die Einträge pro Teilnehmer manuell zusammengesucht werden. Weitere Varianten sind Blogs, Foren oder Twitter Accounts, die für Einträge genutzt werden können. Bei all diesen Methoden ist es wichtig, auf Zugriffsbeschränkungen zu achten, damit Unberechtigte nicht Einblick in die Einträge erhalten. Von Vorteil ist, dass auf Einträge bei Bedarf geantwortet werden kann. Da Tweets auf 140 Zeichen pro Nachricht beschränkt sind, kann diese Methode zu einer reduzierten Informationsweitergabe durch die Teilnehmer führen. Es gibt auch eigene Tools die speziell für die Durchführung von Online Tagebuchstudien ausgerichtet sind, und durch ihre Gestaltung zahlreiche neue Möglichkeiten erschließen. So ist es, wie im Beispiel des USECON Experience Tagebuchs unten, immer häufiger der Fall, dass Tagebücher auch mit Foren kombiniert werden. So kann ein Austausch zwischen den Teilnehmern gefördert werden, was einerseits Einblick in


Usability Professionals 2013 User Research

Entwicklung zusätzlicher Services, die Weiterentwicklung von bestehenden Produkten oder die finale Entscheidung für die Art der Umsetzung eines neuen Produkts oder Services. Ergänzt werden können die Ergebnisse mit Kontextbeobachtungen, die oft ein gutes Bild jedoch nur einen punktuellen Ausschnitt vermitteln.

Abb. 1. Beispiel USECON Experience Tagebuch in Form eines Forums

eine Gruppenmeinung gibt, aber auch zur gegenseitigen Unterstützung der Teilnehmer dient. Für Fragen kann ein eigener FAQ-Bereich oder ein Online Kontaktformular eingerichtet werden. Die Einträge sind für die Teilnehmer jederzeit einsehbar und Medien können einfach und schnell hochgeladen werden. [Abb. 1] Bei den Online Varianten besteht zudem der große Vorteil, dass sie von Smart Phone Nutzern auch mobil verwendet werden können, was viele der Nachteile einer Online Erhebung, die sich durch die Notwendigkeit der Verfügbarkeit eines Computers ergeben, wieder aufhebt. Das Mobiltelefon wird von den meisten Menschen immer in Griffweite aufbewahrt. Laut Studien besitzt inzwischen jeder dritte Deutsche ein Smartphone, davon ist die Durchdringung allerdings bei den Jungen hoch (51% der unter 30 Jährigen) während ab einem Alter von 64 Jahren nur noch 6% ein Smartphone besitzen (linux-magazin. de, 2012). Mobil gibt es also starke Zielgruppeneinschränkungen.

4. Anwendung und Einschränkungen in der Praxis Die Ergebnisse einer Tagebuchstudie können vielfältigen praktischen Nutzen haben. Sie liefern einen entscheidenden Beitrag zum Kundenverständnis und zeigen in weiterer Folge Handlungspotentiale auf. Hier ein paar Beispiele aus der Praxis, wie mit Tagebuchergebnissen verfahren werden kann. –– Produkt- und Serviceentwicklung –– Customer Journey –– Personas 4.1. Produkt- und Serviceentwicklung Gut eigenen sich Tagebuchstudien für die Beobachtung bei der Verwendung eines Produkts oder Services. Aufgezeigt werden typische Anwendungsfälle und auftretende Probleme. Dieses Verständnis für das Erleben der Benutzer kann als Basis dienen für die

Im Rahmen einer großangelegten Studie eines Telekommunikationsanbieters wurde die Nutzung von Smart TV im Alltag untersucht. Bei der Testung dieser Beta-Version lag der Fokus auf Problemen bei der Benutzung des Interfaces. Die Teilnehmer erhielten Aufgaben, die sie innerhalb eines Monats mit dem Smart TV erfüllen sollten und ihr Feedback über ein Online Tool eingeben. Dabei wurden konkrete Fragen und Bewertungsskalen verwendet. Zusätzlich sollten die Teilnehmer ihr Feedback offen und ereignisbezogen geben. Im Zuge dieser Studie wurde eine Vielzahl an Benutzbarkeitsproblemen aufgedeckt, was bei der Weiterentwicklung des Services einen wertvollen Beitrag lieferte. 4.2. Customer Journey Mittels Tagebuch wird die Verwendung eines Produkts oder Services über einen bestimmten Zeitraum dokumentiert und damit auch Erfahrungen, die der Kunde zu bestimmten Zeitpunkten und an speziellen Touchpoints macht, nachvollziehbar. Die Ergebnisse können dazu verwendet werden, eine Customer Journey abzubilden, in der die entsprechenden Kundenerlebnisse anhand eines Prozesses dokumentiert und bewertet werden. Die Customer Journey bildet den gesamten Prozess ab, die der Kunde im Rahmen des Produkterwerbs und der Benutzung durchläuft und zeigt positive wie negative Erlebnisse auf. Dadurch wird dem Unternehmen Handlungsbedarf aufgezeigt. Ein Praxisbeispiel für eine Tagebuchstudie mit dem Ziel eine Customer Journey abzubilden stammt aus dem Finanzbereich. Im Rahmen der Studie „Kunde werden“ haben Neukunden verschiedenster

197


Abb. 2. Beispiel für eine Customer Journey. Sie zeigt den Prozess Kunde zu werden und ein Konto zu eröffnen bis hin zur Verwendung mit allen Pain und Pleasure Points

Bankinstitute ihre Erfahrungen von der Vorinformation über die Kontobedingung, über die Kontoeröffnung bis zur ersten Verwendung dokumentiert. Die 15 Teilnehmer füllten ein Online-Tagebuch ereignisbezogen über einen Zeitraum von 2 Wochen aus. Mittels einer Customer Journey wurden die Stärken und Schwächen in den einzelnen Bereichen und bei einzelnen Touchpoints übersichtlich abgebildet. [Abb. 2] 4.3. Personas Tagebuchergebnisse können auch für die Erstellung von Personas herangezogen werden. Personas sind prototypische Nutzer, die mit konkreten Eigenschaften versehen werden und spezifische Verhaltensweisen dem Produkt gegenüber abbilden. Personas werden auf Basis von tatsächlichen Nutzungsverhalten erstellt, sind aber fiktive Personen. Sie werden verwendet um Produkte und Services anhand der Nutzerbedürfnisse zu entwickeln. [Abb. 3] Ein Beispiel für eine solche Studie stammt aus dem Bereich der Automation. Über

198

einen Zeitraum von 2 Wochen führten die Servicetechniker täglich bei Wartungsarbeiten von bestimmten Automaten ein Tagebuch. Sie gaben Auskunft über typische Arbeitsabläufe, über ihren Arbeitskontext sowie über Probleme mit denen sie im Zuge der Arbeit konfrontiert sind. Das Tagebuch wurde in Papierform geführt und per Post geschickt. Auf Basis der Ergebnisse wurde das typische Verhalten der Servicetechniker analysiert und die Persona erstellt. 5. Experience Tagebuch Check Liste Die Checkliste soll eine Hilfestellung für die Planung und Durchführung von Tagebuchstudien darstellen und fasst die wichtigsten Punkte zusammen. 1. Zieldefinition. Wofür sollen die Ergebnisse verwendet werden und welche Art von Ergebnissen soll die Studie bringen? Aufbauend auf die Beantwortung dieser Fragen ergibt sich das Studiendesign. 2. Auswahl der Teilnehmer. Wer ist die ideale und bestmöglich erreichbare Zielgruppe für die Studie? Die

Teilnehmermotivation wirkt sich direkt auf die Qualität der Ergebnisse aus. Für die meisten Studien bringt eine Teilnehmerzahl von 15–20 Personen gute Ergebnisse. 3. Auswahl des Erhebungsmediums. Wie können die Teilnehmer am besten zeitnah und ohne große Umstände ihre Erfahrungen festhalten? Online Tagebücher ermöglichen eine schnellere und einfachere Auswertung als Papier-Tagebücher. 4. Erhebungsmix. Sollen Experience Tage­ bücher mit anderen Methoden kombi­niert werden? Eine Vernetzung mit anderen Erhebungsformen (z.B. UsabilityTest, Befragung) bringt oft noch tiefergehende Ergebnisse zu bestimmten Fragestellungen. 5. Ausfüllfrequenz. Wie viele Einträge der Teilnehmer sind sinnvoll? Zu viele Einträge können überfordern und zu Dropouts führen, mit zu wenig Aktivität besteht die Gefahr in Vergessenheit zu geraten. Ausfüllen ein- bis zweimal pro Woche ist in der Regel ein guter Rhythmus.


Usability Professionals 2013 User Research

Wichtig ist, dass das Studiendesign an die Zielsetzung, die Rahmenbedingungen und die Zielgruppe angepasst wird. Auf Basis der Tagebuchergebnisse können konkrete Maßnahmen für die Produkt- und Serviceentwicklung gesetzt werden. Dabei sind besonders die Entwicklung von Customer Journey und Personas zu nennen, die die Tagebuchergebnisse visualisieren und auf den Punkt bringen. Diese Beispiele dürften jedoch nicht die einzigen Anwendungsfelder für die Praxis sein. Einschränkungen zeigt die Methode, wenn es darum geht, völlig neue Produktideen zu entwickeln. Hier dürfte es schwierig sein, aus den Alltagseinträgen der Teilnehmer Innovationen abzuleiten. Einige Unternehmen werden nicht Ressourcen in die Durchführung von Tagebuchstudien investieren wollen, da sie länger dauern und aufwändiger sind als andere Erhebungsmethoden. Abb. 3. Beispiel für eine Persona-Darstellung mit Bild, den wichtigsten Eckdaten und einer Beschreibung der wichtigsten Informationen und Hintergründe zur Persona.

6. Kommunikationsplanung. Wie soll die Kommunikation mit den Teilnehmern aussehen? Die gesamte Kommunikation (Wording, Umfang, etc.) sollte an die Zielgruppe angepasst und die Anforderungen transparent kommuniziert werden. Es sollten regelmäßig und anlassbezogen Reminder verschickt werden, ein Übermaß an Kontaktaufnahmen sollte jedoch vermieden werden, da dann die Gefahr besteht, dass wichtige Nachrichten nicht gelesen werden. 7. Teilnehmer Support. Wie können die Teilnehmer die Studienleiter erreichen? Es sollte die Möglichkeit geben, sich bei Fragen an die Studienleiter wenden zu können, daher sollte eine E-Mail Adresse und/oder eine Telefonnummer für diese Fälle eingerichtet werden. 8. Incentives. Wie findet die Aufwandsentschädigung statt? Incentives nicht

nur am Ende sondern auch mehrfach bereits während der Studie einsetzen. 9. Teilnehmerdokumentation. Wie behalte ich die Teilnehmer im Überblick? Häufig­keit, Ausmaß und Zeitpunkt der Teilnehmeraktivitäten sollte festgehalten werden. 10. Weiterführende Analysen. Wie können die Ergebnisse weiter verwendet werden? Vorab die weitere Verwendung der Tagebuchergebnisse wie Customer Journeys oder Persona Erstellung planen, um alle dafür relevanten Informationen zu sammeln.

Auch dürfte es bei manchen Zielgruppen oder Produkten schwierig sein, das Instrument Tagebuch anzuwenden. So eigen sich z. B. für wenig schreibaffine Zielgruppen oder Produkte mit geringem Involvement herkömmliche Befragungen vermutlich besser.

Literatur 1. Bolger, N., Davis, A. & Rafaeli, E. (2003). Diary methods: Capturing Life as it is Lived. Annual Reviews 2. Sherbaum, C. A., & Ferreter, J. M. (2009). Estimating statistical power and required sample sizes for organizational research using multilevel modeling. Organizational Research Methods, 12, 347 – 367. 3. Kirchler, E. (1999). Wirtschaftspsychologie: Grundlagen und Anwendungsfelder der Ökonomischen Psychologie. Seattel: Hogrefe, Verl. Für Psychologie. 4. Solem, C., Gu, N., Pickard, A. (2011). Identification of diseases for EQ-5D bolt-on

6. Fazit und Diskussion

item development: An empirical approach. Value in Health, 14. 5. http://www.linux-magazin.de/NEWS/

Experience Tagebücher sind eine vielfältig einsetzbare Methode, die das Erleben und Verhalten von Benutzern im Alltag erfasst.

Bitkom-Smartphone-Durchdringung-steigend

199


Lean Experiments Die Rolle von Interaction Design und User Experience Research im Ansatz Lean Startup Sascha Mahlke USEEDS° GmbH Friedrichstrasse 209 10969 Berlin sascha.mahlke@useeds.de Lars Giere mobile.international GmbH Marktplatz 1 14532 Europarc Dreilinden

Sylvia Kleine Hörstkamp mobile.international GmbH Marktplatz 1 14532 Europarc Dreilinden Sebastian Hoos USEEDS° GmbH Friedrichstrasse 209 10969 Berlin

Abstract Produktentwicklungsprozesse haben sich in den letzten Jahren insbesondere im Software- und Web-Bereich stark verändert. Die Konzepte Agile Development und Lean Startup spielten dabei eine wichtige Rolle. Ansätze und Methoden aus dem Bereich der Nutzerzentrierten Gestaltung müssen für diese neuen Kontexte angepasst werden und dadurch verändert sich auch die Rolle von Interaction Designern und User Experience Researchern. Wir beschreiben in diesem Beitrag anhand eines Beispiels, welche Herausforderungen und welche neuen Anforderungen sich für den Bereich User Experience dadurch ergeben können. Mit einem Lean Startup Ansatz sollte innerhalb kürzester Zeit eine mobile Applikation für Fahrzeughändler konzipiert werden. Um Nutzeranforderungen und den Nutzungskontext ideal berücksichtigen zu können, wurde dafür ein temporärerer Projektstandort in der Nähe der Nutzer gewählt. Durch ein interdisziplinäres Team wurden in enger Kooperation mit den Nutzern und in kürzester Zeit Produktideen entwickelt. Aus den Ergebnissen lassen sich diverse Hinweise auf Best Practices zum Team Setup, den eingesetzten Methoden und zum Projektablauf ableiten.

1. Lean Startup Die Lean Startup Methode hat spätestens seit Erscheinen des Buches „The Lean Startup“ von Eric Ries (2011a) auch außerhalb der Startup-Szene an Bekanntheit gewonnen. Die darin beschriebene Lean Startup Methode bricht teilweise deutlich mit klassischen Methoden zur Unternehmensgründung und stellt beispielsweise Experimentieren vor Planen, Kundenfeedback vor Intuition und iteratives Vorgehen über die vollständige Entwicklung eines (vermeintlich) perfekten Produktes. Doch trotz dieser teils drastisch veränderten Sicht auf die Entwicklung eines tragfähigen Business Models integrieren Business Schools weltweit diese Methodik in ihren Lehrplan. Auch größere Unternehmen beginnen die Vorteile dieser Methode

200

Sirin Cepkenli USEEDS° GmbH Friedrichstrasse 209 10969 Berlin

zu entdecken und für sich zu nutzen und die Startup-Szene ist dabei immer neue Tools und Vorgehensweisen zu entdecken, um noch schneller zu lernen und das eigene Business Model entsprechend anzupassen. Zuletzt wurde die Methode dadurch geadelt, dass ein Artikel von Steve Blank, einem der gedanklichen Vorreiter der Methode, das Hauptthema des Harvard Business Manager Juli 2013 (Blank, 2013) wurde. Da es mittlerweile sehr viel gute Literatur zu fast allen Teilaspekten der Lean Startup Methode gibt (hervorzuheben ist hier insbesondere „The Lean Series“ von O'Reilly Media), werden wir uns im weiteren Verlauf dieses Abschnitts vor allem auf diejenigen Aspekte konzentrieren, die in der Produktentwicklung im Kontext eines „NichtStartups“ Verwendung finden können.

Keywords: /// Lean Startup /// Agile Development /// User Experience Research /// Interaction Design /// Vorgehensmodelle

1.1. Hypothesenbasiertes Arbeiten Einer der wichtigsten Aspekte der Lean Startup Methode ist das schnelle Lernen durch Kundenfeedback. Eine Grundvoraussetzung hierfür ist es, an zu erkennen, dass zu Beginn der Entwicklung eines neuen Produktes nicht für alle für das Produkt relevanten Fragen Antworten vorhanden sein können und daher unbelegte Hypothesen existieren. Da es nicht einfach ist diese Hypothesen zu erkennen (geschweige denn diese nach dem Risiko zu bewerten) genießt in der Welt der Lean Startups das sogenannte Business Model Canvas von Alexander Osterwalder und Yves Pigneur (Osterwalder & Pigneur, 2010) immer größere Beliebtheit. Dieses hilft auf einfache und übersichtliche Weise das gesamte Business Model und die Beziehungen der Teilbereiche zueinander


Usability Professionals 2013 User Research

Abb. 1. Product Canvas aus Picheler (2012)

darzustellen und hierdurch die zugrundeliegenden Hypothesen leichter zu erkennen.

1.2.1. Build

1.2.2. Measure

Da viele der dort vorhandenen Rubriken bei der Weiterentwicklung eines bestehenden Produktes innerhalb eines gewachsenen Unternehmens bereits feststehen wurden hieraus abgeleitet bereits alternative, besser für die uns interessierende Situation passende Modelle entwickelt wie z.B. das Product Canvas [Abb. 1] von Roman Pichler (Pichler, 2012).

Sind die zugrundeliegenden Hypothesen hinreichend bestätigt oder ist die beste Form der Validierung der offenen Hypothesen die Erstellung eines sogenannten „Minimum Viable Products“ (also das minimal funktionsfähige Produkt) oder eines Prototypen, so kann mit der Erstellung des Produktes gestartet werden.

Bereits vor der Erstellung (Build) des Produktes sollten die Zielmetriken und die gewünschten Ziele definiert sein. Ein guter Startpunkt zur Definition der Zielmetriken sind zum Beipiel die Pirate Metrics von Dave McClure (2012). Diese basieren auf dem typischen Funnel einer geldwerten Aktion eines Online-Kunden (Akquirierung, Aktivierung, Wiederkehrer, Weiterempfehlung, Geldwerte Aktion). Nach dem Launch des neuen Produktes sollten die gesetzten Zielmetriken beobachtet und ausgewertet werden.

Nach dem Aufstellen der Hypothesen und dessen Priorisierung ist der nächste Schritt die Hypothesenprüfung. Hierbei gilt es den jeweils für die Hypothese passenden Ansatz zu finden, um die Hypothese mit den vorhandenen Mitteln möglichst kostengünstig zu verifizieren bzw. falsifizieren.

1.2.3. Learn

1.2. Iteratives Vorgehen Ein Grundstein von Lean Startup ist der sogenannte „Build, Measure, Learn“ Zyklus. [Abb. 2] Dieser beschreibt eine iterative Vorgehensweise in kurzen Zyklen bei der Entwicklung eines neuen Produktes.

Abb. 2. „Build, Measure, Learn“ Zyklus aus Ries (2011a).

Im Anschluss an die Auswertung der definierten Metriken nach Launch des Produktes sollten hieraus Schlussfolgerungen für die weitere Produktentwicklung gezogen werden. Hieraus entstehen häufig neue Hypothesen, die wiederum validiert werden müssen. Hierauf basiert schließlich die Erstellung des nächsten Produktinkrements. Somit startet der „Build, Measure,

201


Learn“ Zyklus von Neuem. Diese Vorgehensweise wird häufig auch als „Validated Learning“ bezeichnet. Wichtige Prinzipien bei dieser Arbeitsweise basieren auch auf dem agilen Manifest, welches hier unkommentiert wiedergegeben werden soll (Beck et al., 2001): –– Individuals and interactions over processes and tools –– Working software over comprehensive documentation –– Customer collaboration over contract negotiation –– Responding to change over following a plan 1.3. Kundengetriebene Entwicklung In jeder Phase der Entstehung eines neuen Produktes ist es bei der Lean Startup Methode unerlässlich direkten Kontakt mit dem Kunden zu suchen, um möglichst schnell zu lernen. Einer der prägendsten Begriffe ist aus diesem Grund auch „GOOB“, was so viel heißt wie „Get Out Of the Building“, geh aus dem Gebäude. Damit greift die Lean Startup Methode die Grundidee des User-Centered Design auf. Generell lässt sich sagen, dass Lean Startup und Ansätze des User Experience Design viele Ähnlichkeiten aufweisen (Kundenfokus, iteratives Vorgehens. Im Projektalltag zeigen sich aber auch Heruasforderungen bei der Integration von Lean Startup und User Experience Design, die wir in Abschnitt 4 näher beleuchten wollen. 2. Lean Experiments Generell können die Grundprinzipien von Lean Startup im Arbeitsalltag sehr unterschiedlich eingesetzt werden. In einem „reinen“ Startup kann die gesamte Organisation auf die Grundprinzipien fokussieren. Doch erfahrungsgemäß ist dies ist nicht für jede Organisation – besonders ab einer bestimmten Größe – möglich. Für größere Organisatoren ist daher eine relvante Möglichkeit vom Lean Startup Prinzip zu profitieren, Freiräume für ausgewählte Projekte zu schaffen, um die Anwendung

202

von Ansätzen aus Lean Startup für diese konkreten Projekte zu ermöglichen. Ein Beispiel sind sogenannte „Inkubatoren“ wie zum Beispiel das Nordstrom Innovation Lab. Nordstrom ist eines der größten Handelsunternehmen der USA und sehr weit entfernt von der Kultur eines Startups. Um trotzdem die eigene Innovationskraft zu sichern und sich die Möglichkeit zu geben, neue Produktideen zu entwickeln, wurde vor enigen Jahren das Nordstrom Innovation Lab gegründet. Die Grundidee dabei ist, neue Produktideen für den Handel von morgen in einem geschützten Kontext außerhalb der Konzernstrukturen mit Prinzipien von Lean Startup zu entwickeln. Eric Ries (2011b) schrieb über das Nordstrom Innovation Lab, dass dieses das perfekte Modell für den Einsatz von Lean Startup in großen Unternehmen und Konzernen ist und beispielsweise die Sun Glass Case Study ideal den Einsatz verschiedener Lean Startup Prinzipien von „Rapid Experimentation“ über „Validated Learning“ bis zum „Minimum Viable Product“ repräsentiert. Wir nennen solche experimentellen Projekte innerhalb von größeren Organisationen, die nicht komplett nach dem Lean Startup Prinzip funktionieren, Lean Experiments. Ein solches Lean Experiment führte mobile.de – eine Tochter des eBay Konzerns – im letzten Jahr in Kooperation mit USEEDS° – einer User Experience Design Beratung – durch und im Folgenden wollen wir unsere Erfahrungen daraus berichten. 3. Case Study: mobile.de Dealer App Ein Grill, ein Wohnmobil, jede Menge Post-Its und eine Menge Spaß waren unser Reise-Set für das Lean Experiment bei den Autohändlern in der berühmten Mainzer Landstraße in Frankfurt am Main. Die Idee: Wir isolieren uns von allen Ablenkungen des Alltags und fokussieren all unsere Energie auf die Entwicklung einer App, die Autohändler in ihrer täglichen Arbeit

optimal unterstützt. Und wir schaffen mit einem kleinen Team und entsprechenden Methoden die Arbeit von 4 Wochen in 4 Tagen. Das Team bestand aus zwei Produktmanagern, einem User Experience Researcher, zwei Interaction Designern, und einem Tech Lead. 3.1. Vorbereitungs- und Planungsphase Klar war, dass alles schneller werden musste als wir es gewohnt sind, ohne dabei die Qualität unserer Arbeit zu gefährden. Will man mit dem Prozess an sich keine Zeit verlieren, sind Vorüberlegungen und Planung alles. So haben wir schon Wochen im Voraus überlegt, wie wir am effizientesten vorgehen können ohne uns den Raum für spontane Anpassungen des Plans zu nehmen. –– Was können wir vorbereiten, was müssen wir spontan erstellen? –– Wie sehen die Nutzer-Interviews aus? –– Wie können wir Nutzer-Interviews schnell auswerten? –– Wie können wir unsere Termine mit den Autohändlern für die Tests effizient planen? –– Wie schnell können wir Prototypen bauen und Feedback einarbeiten? –– Und wie viel Schlaf brauchen wir insgesamt? 3.2. Tag 1 An einem Montagmorgen war es dann soweit und wir parkten unser Wohnmobil in der Mainzer Landstraße in Frankfurt am Main. Der erste Tag sollte der Analyse der Händlerbedürfnisse und der anschließenden Ideenentwicklung dienen. Die Analysephase des Projekts ließ sich, wie bei anderen Projekten gut vorbereiten, sodass wir in zwei Teams gut ausgerüstet und bewaffnet mit interviewleitenden Fragen losziehen konnten. Die Termine hatten wir ebenfalls im Vorfeld organisiert, sodass es jetzt nur noch galt, sich möglichst tief in die Welt der Autohändler einzuarbeiten. Die Zweite Hälfte des Tages verbrachten wir im Wohnmobil und werteten die


Usability Professionals 2013 User Research

Interviews aus. Mittels Storytelling kondensierten wir die für uns relevanten Punkte heraus. Die Beengtheit des Wohnmobils hat dabei die Konzentration in der Gruppe auf ganz eigene Art gefördert und beisammen gehalten. Um unserer Kreativität wieder Raum und Komfort zur freien Entfaltung zu bieten, verlegten wir das anschließende Clustern der Erkenntnisse und die Ideation in einen Arbeitsraum ins nahegelegene Hotel. Mit den Eindrücken des Tages und den Ergebnissen der Interviews vor Augen sprühten wir nur so vor Ideen und die Wände waren schnell mit Post-Its gepflastert. Priorisierung ist alles und so gruppierten wir die Ideen, priorisierten diese zunächst nach Dringlichkeit der Nutzerbedürfnisse und zu letzt nach Durchführbarkeit in diesem Projekt. Zwei Produktideen wurden ausgewählt, um weiter bearbeitet zu werden. 3.3. Tag 2 Tag zwei sollte den Ideen des Vortages bei den ersten Gehversuchen helfen. Wir waren gespannt, ob die Geschwindigkeit des Vortages dennoch Qualität hervorgebracht hat, die unseren Ansprüchen genügt. Zwei Teams skizzierten fleißig jeweils eine der beiden ausgewählten Ideen und versuchten die noch groben Vorstellungen in konkrete Wireframe-Ideen auf Papier zu bringen. Als dann erste sinnvolle Screen-Abläufe fertig wurden, war es so weit: Die ersten Nutzerfeedbacks sollten her. Wie würden unsere Ideen bei den Autohändlern ankommen? Also raus, ins Auto, und los zum Autohändler. Leider war uns in dem intensiven Arbeitsfluss das Entwickeln von Interviewfragen nicht gelungen, sodass wir die Interviewplanung und grobe Umrisse von Fragestellungen erst im Auto auf der Fahrt zu den Händlern entwickeln konnten. Das etwas mulmige Gefühl der unvorbereiteten Interviews verflüchtigte sich bis zum Abend vollends. Beide Teams kamen mit guten Feedbacks und frischen Ideen wieder. Nun galt es, die Ergebnisse der Feedbacks der Händlerinterviews zusammenzutragen

und als Tagesziel zu entscheiden, welcher der beiden Ideen wir in den kommenden Tagen unsere gesamte Aufmerksamkeit legen wollten. Die Entscheidung wurde schließlich einstimmig gefällt. Jetzt war es zwar schon spät am Nachmittag, aber unser Tag war noch nicht vorbei. Wir hatten uns für Tag 2 als Ziel gesetzt, einen fertigen klickbaren Prototypen zu bauen, den wir am Tag 3 direkt in der natürlichen Umgebung der Nutzer direkt auf dem iPhone weiter testen konnten. In zwei Teams, in denen eine Person direkt am Protoyping-Tool arbeitet und eine weitere daneben sitzt und mitdenkt und diskutiert, wurde noch vor Mitternacht der AxurePrototyp fertiggestellt. 3.4. Tag 3 Mit dem ersten Schluck Kaffee am Frühstückstisch beginnen wieder die Gedanken und Gespräche um den Prototypen zu kreisen. Alle wollten dessen Entwicklung an diesem Tag möglichst weit voranzutreiben. Wir teilten uns wieder in zwei Teams auf, jedoch dieses Mal, um denselben Ausgangsprototyp zu testen. Durch die beiden unabhängig arbeitenden Teams erhofften wir uns mehr und differenzierteres Feedback für unsere Ideen, das wir am Abend zusammentragen und gegebenenfalls gegeneinander antreten lassen wollten. Beide Teams bestanden jeweils aus zwei „Interviewern“ und einem „Prototyper“. Nach jedem Interview wurden die Ergebnisse auf der Fahrt zurück zusammengefasst und dem Prototyper im Wohnmobil übergeben. So konnte der Prototyper im Wohnmobil parallel zu den Interviews die Ergebnisse in den Prototyp seines Teams einarbeiten und das Interviewteam stets auf aktuellem Stand Feedback einholen. Wir ermöglichten so viele Iterationen in kurzer Zeit. Wir nennen es „Contextual RITE“ (vgl. Rapid Iterative Testing and Evaluation von Medlock et al. (2002)). Ein intensiver Tag mit vielen Interviews und neuen Anregungen lag am Abend schon hinter uns als sich die beiden Teams wieder trafen, um ihre Ergebnisse abzugleichen. Viele Ergebnisse fanden sich in beiden

Teams bestätigt, manches nur in einem Team und so gut wie nichts war strittig. Es zeigte sich, dass wir in zwei Teams nicht nur mehr herausgefunden hatten, sondern uns durch die Bestätigung durch das jeweils andere Team auch sicherer waren, dass wir trotz unseres Arbeitstempos gute und valide Ergebnisse erarbeiteten. Der Tag endete, wie der letzte auch geendet hatte. Prototyping bis spät in die Nacht, um einen frisch überarbeiteten Stand am nächsten Morgen testen zu können. 3.5. Tag 4 Am vierten und letzten Tag konnten wir eine letzte Runde Feedback der Autohändler einholen. Mittlerweile geübt und eingespielt gingen die Teams los und feilten an den letzten Ecken des Prototyps. Gegen Nachmittag kamen wir wieder zusammen, evaluierten die Ergebnisse und aktulisierten den Prototpyen für unser Produkt ein letztes Mal, bevor er in die Entwicklung gehen sollte. Wir schlossen das Projekt mit einer gemeinsamen Retrospektive für uns ab. Zu Beginn des Projekts kamen wir ohne jegliches Wissen über die Bedürfnisse von Autohändler und wie wir sie mit einer App unterstützen könnten in Frankfurt an. Von da an haben wir es in nur dreieinhalb Tagen geschafft, einen funktionierenden Prototyp für eine Autohändler-App auf die Beine zu stellen und mehrfach zu testen. 4. Lessons Learnd Grundsätzlich hat das Lean Experiment für uns gut funktioniert. Wir haben unser Ziel erreicht in kurzer Zeit zu einer Produktidee verschiedene Lösungsvarianten auszutesten, mit Nutzern zu evaluieren und mit einem relevanten Produktkonzept abzuschließen. Trotzdem würden wir beim nächsten Mal folgendes besser bzw. anders machen: –– Noch stärker in Teams arbeiten. Die Gruppe teilen verdoppelt die Arbeitskraft.

203


–– Noch stärkeren Fokus auf das Validieren zugrundeliegender Hypothesen legen. –– Mehr strukturierende Diskussionsund Feedback-Methoden im Gepäck haben. –– Noch näher an der Zielgruppe sein. Idealerweise muss man nicht zu ihr hinfahren, sondern sitzt an einem Ort, an dem genügend Zielpersonen „vorbeikommen“. –– Mehr als vier Tage Zeit. Das Arbeitstempo hätte mit vielleicht noch zwei weiteren Tagen eine wirklich fertige App ergeben. –– Fragen im gesamten Prozess stetig sammeln. Interviews bereiten sich so fast von alleine vor. –– Eventuell analytische Interviews und Testiterationen in jeweils eigene „LeanSprints“ trennen. Für die Ideenfindung und das Scribbeln war der Stress der Arbeitssituation eher hinderlich.

Literatur

Für Interaction Designer und User Experience Researcher ergeben sich für Arbeiten in einem solchen Kontext vor allem folgende Anforderungen: –– Gewohnte Methoden schneller durchführen. –– Interaktions-Konzepte und ResearchVorbereitungen eher anwenden als perfekt auszudefinieren. –– Geschwindigkeit gewinnen, indem andere Disziplinen bei der eigenen Arbeit mit einbezogen werden.

8. Ries, E. (2011a). The Lean Startup. Penguin.

1. Beck et al. (2001). Manifesto for Agile Software Development. http:// agilemanifesto.org. 2. Blank, S. (2013). Why the Lean Start-Up Changes Everything. Harvard Business Manager, July 2013, 22–32. 3. Blank, S. & Dorf, B. (2012). The Startup Owner's Manual. K & S Ranch. 4. McClure, D. (2012). Startup Metric for Pirates. http://de.slideshare.net/dmc500hats/ startup-metrics-for-pirates-long-version. 5. Medlock, M.C., Wixon, D., Terrano, M., Romero, R. & Fulton, B. (2002). Using the RITE method to improve products: A definition and a case study. UPA Conference 2002. 6. Osterwalder, A. & Pigneur , Y. (2010). Business Model Generation. John Wiley & Sons. 7. Pichler, R. (2012). The Product Canvas. http://www.romanpichler. com/blog/agile-product-innovation/ the-product-canvas/.

Die hohe Geschwindigkeit der Weiter­ ent­wicklung innerhalb der Lean Startup Me­tho­de benötigt also vor allem sehr schlanke und direkte User Experience Re­search Methoden, um nicht zu einer Verlangsamung des Lernzyklus zu führen („Rapid Experimentation“). Hierfür gibt es mittlerweile eine Vielzahl an Methoden, welche in dem Buch „Lean UX“ (Seiden & Gothel, 2012) gut in den Kontext von Lean Startup gestellt werden. Zudem geht das Buch noch tiefer auf die neue Rolle von User Experience bei Lean Startup und agiler Entwicklung ein und beleuchtet noch zusätzlich Aspekte.

204

9. Ries, E. (2011b). Case Study: The Nordstrom Innovation Lab. http://www. startuplessonslearned.com/2011/10/casestudy-nordstrom-innovation-lab.html. 10. Seiden, J. & Gothelf, J. (2012). Lean UX. O'Reilly Media.


Usability Professionals 2013 User Research

205


206


UX Integration

207


Einführung von HumanCentered Design bei der adidas AG Ein Praxisbericht Lucie Grudno adidas Group Herzogenaurach Lucie.Grudno@adidas-group.com

Leo Glomann adidas Group Herzogenaurach Leo.Glomann@adidas-group.com

Abstract Auf der UP 2012 stellten wir in einem Kurzvortrag unsere Pläne vor, ein Rahmenwerk zur Etablierung von Human-Centered Design bei der adidas AG einzuführen. Im Januar 2013 führte adidas dieses Rahmenwerk ein. Das erklärte Ziel: interaktive Produkte mit hoher Usability und einer großartigen User Experience bereitzustellen und die Etablierung einer Mensch-zentrierten Herangehensweise in allen Prozessen der IT-Entwicklung. In diesem Beitrag berichten wir von der Einführung, der praktischen Umsetzung, Herausforderungen und Anpassungen am Rahmenwerk seit Anfang des Jahres. Eine besondere Herausforderung ist es, diese standardisierte Herangehensweise so flexibel an die Projektgegebenheiten anzupassen, dass sie in die bestehenden Prozesse perfekt integriert wird. Das Rahmenwerk wird zunächst im Bereich IT Marketing angewendet. Zu Marketing zählen die Aktivitäten von der Produktplanung, -konzeption bis hin zur Vermarktung. Die interaktiven Produkte richten sich sowohl an Mitarbeiter, wie z. B. Designer, als auch an Konsumenten. Die Ausweitung des Ansatzes auf weitere Fachbereiche wie z.B. Sales ist geplant.

Der Hintergrund Die adidas Group besteht aus verschiedenen Untermarken, u.a. adidas, Reebok und Taylormade-adidas Golf. Es werden Sportartikel wie Bekleidung, Schuhe, Hartwaren aber auch interaktive Produkte wie miCoach entwickelt, hergestellt und vertrieben. Die Mensch-zentrierte Herangehensweise ist in der Unternehmenskultur verankert. Einer der nach dem Unternehmensgründer benannten Adi Dassler Standards besagt beispielsweise: „Test, test, and test again!“ Diese Standards sind – wenn es um reale, physische Produkte geht – in der „DNA“ des Unternehmens verankert und lassen sich wie folgt zusammenfassen: –– Konsumenten und Athleten testen und bewerten Produkte –– Die Erstellung von Produktprototypen erfolgt iterativ –– Erkenntnisse werden dokumentiert und sorgen für kontinuierliche Verbesserung der Produkte –– Multidisziplinäre Teams aus Designern, Entwicklern, Ingenieuren und Produktmanagern arbeiten zusammen

208

Es mag daher überraschend sein, dass bei der Entwicklung von interaktiven Produkten lange Zeit nicht oder nur durch Zufall Mensch-zentriert vorgegangen wurde. User Requirements, abgegrenzt von z.B. Business Requirements, wurden nicht erhoben. Nutzer wurden erst zu Abnahmetests oder nach dem Launch eingebunden. Es wurden keine Prototypen erstellt, etc. Das Ziel von uns Usability Engineers ist es, Mensch-zentriertes Vorgehen in den ITEntwicklungsprozessen der adidas Group zu etablieren. Als erster Schritt wird das Vorgehen in der IT-Abteilung etabliert, die das Marketing unterstützt. Marketing umfasst dabei die Produktplanung, -konzeption, -gestaltung und -vermarktung. Die interaktiven Produkte, wie z.B. Anwendungen oder Websites, richten sich sowohl an interne Mitarbeiter (z.B. Produktmanager oder -designer) als auch an Konsumenten. Das dedizierte Usability Engineering Team besteht aus drei Mitarbeitern, einigen Studenten und freien Mitarbeitern. Weitere Rollen im Unternehmen beschäftigen sich mit dem Thema Usability und sind

Keywords: /// Inhouse Usability Engineering /// Rahmenwerk /// HCD /// Etablieren /// Nachhaltigkeit

in Kontakt mit dem Usability Engineering Team. Das Rahmenwerk als Modell Um das Mensch-zentrierte Vorgehen (Human-Centered Design) in den aktuell über 20 laufenden Projekten nachhaltig mit einem kleinen Team etablieren zu können, haben wir ein Rahmenwerk definiert. Es basiert auf ISO 9241–210 und wird im Folgenden als Vorgehensmodell vorgestellt. Im Anschluss daran wird auf Erkenntnisse eingegangen, die in der Praxis gewonnen wurden (siehe „Das Rahmenwerk in der Praxis“). In den Projekten wird gemäß der HumanCentered Design (HCD) Prinzipien vorgegangen: –– Einbindung von Nutzern in den gesamten Entwicklungsprozess –– Zusammenarbeit in einem multidisziplinären Team –– Iteratives Vorgehen –– Die Entwicklung basiert auf einem soli­ den Verständnis des Nutzungskontextes –– Eine großartige User Experience als Ziel


Usability Professionals 2013 UX Integration

Die Mensch-zentrierten Aktivitäten nach ISO 9241–210 werden in die bestehenden Entwicklungsprozesse (Wasserfall und Agil) integriert. Im „klassischen“ Wasserfall-Modell [Abb. 1] werden die Aktivitäten folgendermaßen zugeordnet: – Vorbereitungsphase: „plan HCD“ – Konzeptphase (iterativ): „understand & specify context of use“, „specify user requirements“, „produce design solutions“ (Prototypenerstellung), „evaluate design solutions“ (Evaluation der Prototypen)

– Entwicklungsphase: „produce design solutions“ (Implementierung), „evaluate design solutions“ (Evaluation der Implementierung) – Nutzungsphase: „evaluate design solutions“ (Evaluation der Implementierung nach Veröffentlichung) Dabei wird insgesamt iterativ vorgegangen, so wird, falls nötig, etwa von der Evaluierung in der Entwicklungsphase zurückgegangen zur Spezifizierung der Nutzeranforderungen. Die Zuordnung der HCD-Aktivitäten im agilen Entwicklungsmodell: [Abb. 2]

– Vorbereitungsphase: „plan HCD“ – Sprint (iterativ – je nach Sprintdauer in mehreren Iterationen pro Sprint): „understand & specify context of use“, „specify user requirements“, „produce design solutions“, „evaluate design solutions“ – Nutzungsphase: „evaluate design solutions“ Zur Ausübung der HCD-Aktivitäten in den Projekten werden passende Usability Engineering-Methoden ausgewählt. Je nach Bedingungen wie Projektbudget, Zeit, Nutzergruppe, Komplexität und

Abb. 1. HCD-Aktivitäten im Wasserfall-Entwicklungsmodell bei der adidas Group

Abb. 2. HCD-Aktivitäten im agilen Entwicklungsmodell bei der adidas Group

209


Projektstand unterscheidet sich die Auswahl und Durchführung der Methoden. [Abb. 3] Das Rahmenwerk umfasst also ein generisches sowie ein projektspezifisches Vorgehen: Generisch: – Alle Projekte müssen gemäß den Human-Centered Design Prinzipien vorgehen – Alle Projekte müssen die HCD-Aktivitäten in den Entwicklungsprozess einbinden Projektspezifisch: – Die passenden Usability EngineeringMethoden pro Aktivität werden individuell ausgewählt und durchgeführt

Wir als Usability Engineering-Team etablieren das Rahmenwerk auf drei Ebenen: – Informieren – Beraten – Ausführen Informieren: Wir informieren zum Thema Usability und machen das Rahmenwerk bekannt. Beraten: Wir beraten, wie die HCD-Aktivitäten in die Projekte integriert werden können (generischer Ansatz) und welche Usability Engineering-Methoden sich eignen (projektspezifischer Ansatz). Die Beratung ist der Hauptbestandteil unserer Arbeit. Entsprechend der Erfahrungen aus der Beratung entwickeln wir das Rahmenwerk weiter. Die Beratung umfasst auch die Betreuung und Kontrolle der Ausführung der Methoden sowie die Vermittlung und

Abb. 3. HCD-Aktivitäten im Wasserfall-Entwicklungsmodell bei der adidas Group, mit entsprechenden Aktivitätsbeschreibungen und Usability Engineering Methoden

210

Beratung bei der Auswahl von Ressourcen. Als weitere Beratungsleistung organisieren wir HCD-Trainings für Projektteams. Ausführen: Zum Teil führen wir Usability Engineering-Methoden selber aus. In Projektphasen, in denen es z.B. um ein Gesamtverständnis der internen Prozesse geht, können wir schneller Methoden ausführen als externe Ressourcen. In den meisten Fällen werden die Methoden jedoch durch geschulte Projektmitglieder oder von externen Mitarbeitern ausgeführt. Das Rahmenwerk in der Praxis Mit der Konzeption des Rahmenwerks haben wir Mitte 2012 begonnen, in Kraft ist es seit dem 1.1.2013. Im Folgenden berichten wir über unsere Erkenntnisse, die wir seit der Einführung gewinnen konnten.


Usability Professionals 2013 UX Integration

Aufgrund dieser Erkenntnisse wurde das Rahmenwerk seit der Einführung angepasst und besteht nun in der oben beschriebenen Form. Einführung des Rahmenwerks Eine generelle Ausrichtung auf den Nutzer ist in der Strategie der adidas Group IT verankert. Das Management im Bereich IT Marketing hat außerdem das beschriebene Rahmenwerk als für alle Projekte verpflichtend erklärt. Die Einführung des Rahmenwerks haben wir im Rahmen einer Abteilungsvollversammlung kommuniziert. Vorbereitend hatten wir Poster aufgehängt mit dem Slogan „We don’t create great user experience“ [Abb. 4], was für viel Aufmerksamkeit sorgte („Was macht ihr denn dann?“). In der Präsentation wurde dann aufgelöst, dass nicht wir alleine, sondern alle am Projektbeteiligten zu einer großartigen User Experience beitragen: Business Analysten, die Nutzeranforderungen aufnehmen und den Kontext analysieren, Projektleiter, die HCD in die Planung einbauen, Technische Architekten, die Technologien entsprechend der Nutzergruppen bestimmen, etc. [Abb. 5] Die Kommunikation des verpflichtenden Ansatzes sorgte für viel Diskussion: wie passt der Ansatz in das Projekt, wer soll dafür zahlen, etc. Im Anschluss an die Vollversammlung wurde mit den einzelnen Projekt- und Programmleitern das Rahmenwerk in Einzelgesprächen besprochen und die individuelle Anpassung des Rahmenwerks erörtert. Im Zuge dieser Gespräche wurde klar, dass wir bei an Konsumenten gerichteten Produkten das Rahmenwerk nicht auf die gleiche Art einführen können, wie bei internen Anwendungen (siehe nächster Punkt). Erkenntnisse: – Unterstützung durch das Management ist elementar wichtig – Ein Rahmenwerk muss generisch genug sein, um unterschiedliche Projekte individuell abdecken zu können

Abb. 4. Poster zur Einführung des HCD-Rahmenwerks – Teaser

Abb. 5. Poster zur Einführung des HCD-Rahmenwerks – Auflösung

– Eine unterhaltsame Kommunikationsstrategie macht auf das Thema neugierig

Vorgehen von den Dienstleistern und Agenturen zu verlangen, um qualitativ bessere Lösungen zu erhalten.

Zusammenarbeit zwischen den Abteilungen Da unser Team in der IT-Organisation der adidas Group verankert ist, ist eine Zusammenarbeit zwischen der IT und den Fachabteilungen Grundvoraussetzung für das Vorhaben, HCD in den Projekten zu etablieren. Wir mussten feststellen, dass es im Bereich der interaktiven Produkte für Konsumenten politisch schwierig ist, den Ansatz verpflichtend einzuführen. Die Fachabteilungen sieht die Konzeption bei Agenturen. Die IT wird erst zu einem späteren Zeitpunkt eingeschaltet. Eine Beeinflussung der Analyse, Spezifikation der Anforderungen sowie der Designs im multidisziplinären Team ist noch nicht möglich. Bei den konsumentengerichteten Produkten können wir in vielen Fällen zunächst nur durch Evaluation der produzierten Lösungen Einfluss nehmen. Dies war in der Vergangenheit ein „Türöffner“, um im weiteren Verlauf oder bei weiteren Projekten ein Mensch-zentriertes

Bei Anwendungen, die für Mitarbeiter oder B2B entwickelt werden, ist die IT meistens von Anfang an involviert. Hier ist es für ITProjektleiter möglich, schon in der Planung HCD zu berücksichtigen. Erkenntnisse: – Fachabteilungen können durch proaktive Ausführung von konkreten und schnellen Usability Engineering Methoden vom HCD Wert überzeugt werden – Usability Engineering kann durch ungünstige Organisationsstrukturen stark erschwert werden HCD als „Mehraufwand“ Human-Centered Design wurde als Mehraufwand wahrgenommen: zusätzliche Mitarbeiter, es wird mehr Zeit während der Konzeption benötigt, zusätzliche Aktivitäten kosten Zeit und Geld.

211


Diese Wahrnehmung ließ sich auch darauf zurückführen, dass wir am Anfang das Rahmenwerk nicht offen genug und recht kompliziert definiert hatten. Wir hatten Meilensteine definiert, zusätzlich haben wir von Human-Centered Design Aktivitäten gesprochen, Methoden, etc. [Abb. 6] Die Hauptaspekte sind nicht angekommen. In der Weiterentwicklung haben wir uns wieder auf die Grundlagen des ISO 9241–210 „zurückbesonnen“ und

klar zwischen dem generischen und dem projektspezifischen Ansatz unterschieden. Wichtig in jedem Fall ist, dass nach den HCD Prinzipien vorgegangen wird und dass die Aktivitäten ausgeführt werden. Individuell ausgestaltet werden kann, welche Methoden wie ausgeführt werden, um die Aktivitäten in den Projektplan zu integrieren. Dass mehr Zeit und Geld, vor allem in der Konzept-Phase, benötigt werden, trifft

anfänglich in den meisten Fällen zu. Es wird mehr Zeit als bislang benötigt, den Kontext zu verstehen und zu spezifizieren. Die Ableitung von Nutzeranforderungen verlangt neue Herangehensweisen. Prototypenerstellung benötigt entsprechende Ressourcen, die iterative Evaluation der Prototypen und entsprechende Anpassung der Anforderungen benötigen Zeit. Alleine die Veränderung, wie das Projektteam z.B. mit Hilfe von Prototypen zusammenarbeitet, verlangt Anstrengung und Zeit. Wir unterstützen diese Veränderungen, indem wir die Mitarbeiter selber schulen und begleiten, HCD-Trainings organisieren und bei der Auswahl von qualifizierten Mitarbeitern in den Projekten helfen. Wir sind stets in Kontakt mit den Projektleitern, um Schwierigkeiten zu adressieren und um Änderungen begleiten zu können. Durch eigene Erfahrungen konnten die Projektteams erkennen, dass sich anfänglicher Mehraufwand später im Projekt positiv auf die Qualität des Produkts und die Zufriedenheit des internen „Kunden“ und nach Launch auf die Zufriedenheit der Nutzer auswirkt. Diese erlebten Vorteile dienen dann dazu, auch bei weiteren Projekten Mensch-zentriert vorzugehen und sprechen sich zu anderen Projektleitern herum. Die „Evangelisierung“ geschieht daher durch die Ausführung von HCD-Aktivitäten.

Abb. 3. Rahmenwerk vor der Überarbeitung – unpraktisch und komplex

212

Ein großer Vorteil, den Projektleiter wahrgenommen haben, ist die Verwendung von Prototypen (Wireframes sowie Visual Prototypes), um die Kommunikation zwischen den Projektteammitgliedern zu verbessern. Die Anforderungen werden visualisiert und so viel verständlicher und transparenter für alle Beteiligten. Durch Evaluation im multidisziplinären Team, durch Experten und Nutzer können Veränderungen schnell und unkompliziert umgesetzt werden. Die Entwickler, die oft offshore arbeiten, können die Designs direkt umsetzen. Die Evaluation von Prototypen und Implementierungen wurde auch sehr positiv von den Projektteams aufgefasst, da so viele Usability-Probleme frühzeitig aufgedeckt und beseitigt werden konnten.


Usability Professionals 2013 UX Integration

Erkenntnisse: –– Das Rahmenwerk muss leicht verständlich aufbereitet werden, um nicht als Zusatzaufwand wahrge­ nommen zu werden –– Schulung der Mitarbeiter ist wichtig –– Evangelisierung durch Ausführung von HCD-Aktivitäten Bestehende Strukturen und Prozesse In einem bestehenden, produzierenden Unternehmen HCD in IT-Prozessen zu etablieren bedeutet, dass man nicht „auf der grünen Wiese“ anfangen kann. Zum einen gibt es Herangehensweisen und Prozesse, die etabliert sind, zum anderen werden viele Entwicklungsaufgaben durch externe Dienstleister ausgeführt, mit individuellen Herangehensweisen. Die Anforderung an das Rahmenwerk war also, dass es in die unterschiedlichen Konstellationen passen musste. Gleichzeitig müssen wir die Projekte individuell beraten können, um den unterschiedlichen Rahmenbedingen begegnen zu können. Die Anreizstruktur für Projekte war bislang verbreitet: „on time, in budget“. Diese Struktur ändert sich langsam zu mehr Nachhaltigkeit und Nutzerzufriedenheit, was notwendig ist, um HCD mit den individuellen Zielen zu koppeln. Erkenntnisse: –– „Schablonen-Vorgehen“ ist nicht möglich, individuelle Herangehens­ weisen sind nötig –– Anreize müssen Mensch-zentriertes Vorgehen unterstützen Abgrenzung zwischen Beratung und Ausführung Wir Usability Engineers sind jeweils für die Beratung verschiedener Projekte verantwortlich. Wir treffen uns mindestens einmal pro Woche in einem Gremium, um über den aktuellen Stand und eventuelle Probleme oder Vorgehensweisen zu sprechen. Bei der Arbeit mit den Projekten ist es teils nicht einfach, die Grenze zwischen einer Beratung und der Ausführung von Methoden

einzuhalten. Gerade diese Trennung ist aber nötig, um nicht in einen Ausführungsmodus zu verfallen, in dem wir vor ca. 1,5 Jahren waren und der es durch den Zeitaufwand nicht ermöglicht, die Breite der Projekte abzudecken. Ein typisches Beispiel: In einem Projekt wurde es versäumt, explizit User Requirements zu spezifizieren. Als Berater machen wir auf diese Lücke aufmerksam und verdeutlichen das Risiko, das durch diese Lücke entsteht. Wir stehen eventuell dem verantwortlichen Business Analysten oder der Usability Fachkraft zur Seite und leiten ihn an. Nur in gewissen Projekten und Situationen, die im Team als besonders relevant identifiziert wurden, führen wir die Methoden selber und verantwortlich aus. Erkenntnisse: –– Man kann nicht alles selber machen… auch wenn es verlockend ist –– Beratung und Befähigung von Projektteams helfen dabei, HCD zu etablieren

sehr deutlich zu erkennen: der Kontext wird analysiert, Prototypen werden angefertigt und evaluiert, entsprechend qualifizierte externe Mitarbeiter sind involviert, interne Projektteammitglieder werden geschult. Bei an Konsumenten gerichteten Produkten setzen wir wo immer möglich an, HCDAktivitäten zu integrieren und Usability Engineering-Methoden auszuführen. Das Verständnis und Wissen, was Usability und UX sind und wie man eine höhere Qualität mit Hilfe von HCD erreichen kann, ist stark gestiegen. Grundlage für eine erfolgreiche Einführung ist die Unterstützung durch das Management, die Motivation, eine hohe Qualität der Produkte anzustreben, ein klarer, gene­rischer Ansatz, sowie eine individuelle Beratung der Projekte. Durch erfolgreiche Beispiele und erlebte, Mensch-zentrierte Herangehensweisen wird HCD nachhaltig etabliert.

„Konkurrenz“ mit anderen Ansätzen Es ist eine Aufgabe, andere Rahmenwerke oder Ansätze wie Design Thinking mit unserem Rahmenwerk zu verknüpfen und nicht in Konkurrenz treten zu lassen. Die Kommunikation von externen Trainingsangeboten, etc. verheißt neuartige Herangehensweisen, jedoch beschreiben die Ansätze häufig ein Mensch-zentriertes Vorgehen, nur mit anderen Worten. Wir müssen die Begeisterung und das Interesse an diesen Themen einbinden und mit unserem Ansatz verbinden, um eine einheitliche Sprache zu sprechen. Erkenntnisse: –– Es geht nicht nur um Überzeugungs­ arbeit und Evangelisierung, sondern auch um die Zusammenführung von internen Strömungen Zusammenfassung Durch die Einführung des HCD-Rahmenwerks konnten wir Veränderungen hin zu einem Mensch-zentrierten Vorgehen bewirken. In den an Mitarbeiter gerichteten Projekten ist eine solche Veränderung schon

213


Die Benutzung des Styleguides für Software-Entwickler optimieren Herausforderungen und Perspektiven Maria Rauschenberger MSP Medien Systempartner GmbH & Co. KG Peterstraße 28–34 26121 Oldenburg Maria.Rauschenberger@medien-systempartner.de

Heike Sinning Hochschule Emden/Leer Constantiaplatz 4 26723 Emden heike.sinning@gmx.de

Abstract Der Styleguide ist als Artefakt in Software-Projekten etabliert, da er konkrete Vorgaben für die visuelle Gestaltung und das Layout bietet. In der Praxis ist zu beobachten, dass der am Anfang erstellte Styleguide nicht zwangsläufig mit dem finalen Produkt übereinstimmt. Doch wieso werden die Richtlinien aus dem Styleguide nicht übernommen? Eine genaue Problembetrachtung zeigt, dass der Styleguide ebenso wie der SoftwareEntwicklungsprozess iterativ zu erstellen und einfach zu nutzen sein sollte. Der hier dargestellte Lösungsansatz zeigt erste Ideen für ein optimiertes Vorgehen zu Erstellung und Benutzung des Styleguides.

Einleitung Von einer Idee bis zum fertigen Produkt ist es ein langer Weg. Um das Produktziel zu erreichen, werden in der Softwareentwicklung Prozesse, Artefakte und Maßnahmen zur Qualitätssicherung festgelegt. Für die Festlegung des Designs wird oftmals ein Styleguide erstellt. Dieser gehört für viele Unternehmen zur Standard-Dokumentation sowohl in der klassischen Softwareentwicklung als auch in agilen Prozessen. Ein Styleguide wird in der Literatur wie folgt beschrieben: –– „Styleguides: Sie bestehen aus einem Satz von sehr konkreten Richtlinien und/oder Spezifikationen mit dem Ziel der Vereinheitlichung von Systemen eines bestimmten Typs oder Herstellers. Sie beschreiben ein grundsätzliches Layout-Rahmenmodell, in das die Inhalte eingefügt werden“ (Sarodnick & Brau 2011). –– „Styleguides: konkrete Vorgaben für die visuelle Gestaltung und das Layout einer bestimmten Benutzeroberfläche. Styleguides beschreiben Aussehen und Verhalten (Look & Feel) von UserInterface-Elementen, abhängig von der eingesetzten Technologie “ (Richter & Flückiger 2010).

214

Die Vorteile liegen in der klaren Festlegung auf ein Grunddesign für ein Produkt bzw. ganze Produktreihen. Vorab definierte Farben, Formen, Anordnungen und Größen sollen nachträgliche Auseinandersetzungen über das grafische Design reduzieren. Dem Entwickler werden konsistente Designvorlagen für Funktionen und Designprobleme vorgeschlagen (Iconstorm 2010) und die Kunden bzw. Usability-Experten zur objektiven Bewertung befähigt (Sarodnick & Brau 2011). Aus der Sicht von Ortlieb ist der Styleguide auch ein Nachschlagwerk, welcher als Checkliste beim Design-Prozess verwendet werden kann (Ortlieb 2012). 1. Verwendung des Styleguides in der Praxis In unterschiedlichen Unternehmen haben die Autoren Erfahrung in der Anwendung mit dem Styleguide gesammelt und erkannt, dass der Styleguide nicht wie geplant eingesetzt oder verwendet wird. Unternehmen und Mitarbeiter profitieren damit nicht von den prinzipiellen Vorteilen des Styleguides. Der Umgang mit dem Styleguide wirft die folgenden Fragenstellungen auf:

Jörg Thomaschewski Hochschule Emden/Leer Constantiaplatz 4 26723 Emden jt@imut.de

Keywords: /// Styleguide /// Agiles Projektmanagement /// Dokumentation

–– Sind es die menschlichen und teilweise organisatorischen Eigenschaften, die einen Styleguide nicht funktionieren lassen? –– Ist die Vielfalt der anfallenden Artefakte, Dokumente, Ablageorte und Programme während des SoftwareEntwicklungsprozesses problematisch, die den Entwickler jeweils von seiner ursprünglichen Aufgabenstellung ablenken können? –– Ist ein Styleguide eine Voraussetzung oder eher ein Arbeitsdokument auf dem Weg zu einem passenden Design für das Produkt? In der praktischen Verwendung von Styleguides können zwei größere Problematiken den Vorzügen gegenübergestellt werden. Zum einen können Prozessprobleme und zum anderen Umsetzungsprobleme festgestellt werden. Fehler! Verweisquelle konnte nicht gefunden werden. soll verdeutlichen, dass Prozess- und Umsetzungsprobleme parallel zueinander existieren und damit die Benutzung des Styleguides erschweren oder sogar verhindern können. [Abb. 1] Der in einer Konzeptionsphase erstellte Styleguide ist an die initialen Anforderungen der Software angepasst. Die


Usability Professionals 2013 UX Integration

das Projektteam ist so auszurichten, dass die hohe Bedeutung des Styleguides vom Projektteam anerkannt wird. „Die besondere Herausforderung an eine erfolgreiche Kommunikation und Dokumentation liegt darin, trotz unterschiedlicher Fachsprachen, Perspektiven und Dokumentationsstilen, geeignete Werkzeuge zu wählen und ein gemeinsames Verständnis zu erzeugen“ (Herdle et al. 2010). Buxton (Buxton 2010) bestätigt, dass die Kommunikation unter den Projektbeteiligten wichtig ist, um ein Design erfolgreich umzusetzen.

Abb. 1. Abhängigkeit der Prozessund Umsetzungsprobleme

Prozessprobleme entstehen durch die sich im Entwicklungsprozess ändernden Anforderungen an eine Software. Besonders bei der Neuentwicklung von Produkten sind in der Anfangsphase nicht alle Funktionen oder Abläufe abschließend geklärt, insbesondere bei der Verwendung agiler Entwicklungsprozesse. Es werden während des gesamten Human-Centered Design Prozesses Anpassungen vorgenommen, auch nach einer Installation (Ortlieb 2012).

Gut wäre ein Styleguide für alle (ähnlichen) Produkte eines Unternehmens. Allerdings sind eventuell nicht alle Produkte eines Unternehmens durch die verschiedenen Ziele und Funktionen mit einem Styleguide vernünftig abzudecken. Dies führt in der Praxis dazu, dass innerhalb eines Unternehmens mehrere Styleguides zu verschiedenen Projekten, Produkten oder Bereichen erstellt werden müssen, die sich nicht widersprechen sollten. „Beispiele für diese typischen Probleme sind die Schwierigkeit,

relevante Informationen innerhalb des umfangreichen Materials aufzufinden oder Schwierigkeiten im Updaten und Warten der Informationen“ (Schrammel et al. 2010). Überdies ist die mangelnde Kommunikation der Aktualisierungen an die Projektteilnehmer problematisch und es bedarf einer Person, die die Dokumente auf den neuesten Stand hält, die Aktualität gewährleistet und die Kommunikation zum Projektteam vornimmt. Das Prozessproblem verhindert zusätzlich zum Auffinden eine schnelle Akzeptanz und Verbindlichkeit des Styleguides und verstärkt überdies das Umsetzungsproblem. Schubert et al. (Schubert et al. 2010) beschreiben, dass der Erfolg eines Styleguides abhängig ist von der inhaltlichen Qualität, der organisatorischen Verankerung in dem Entwicklungsprozess und der Sensibilität der Software-Entwicklers für konsistente Gestaltung der Oberflächen. Die Kommunikation des Styleguides an

Beim Umsetzungsproblem geht es um die Akzeptanz des Styleguides bei den Projektteilnehmern, besonders bei den Software-Entwicklern. Das Umsetzungsproblem gestaltet sich deutlich diffuser als das Prozessproblem. Die dokumentenbasierte Ablage und damit statische Form des Styleguides ist für eine einfache Weiterentwicklung ungeeignet. Dieses oftmals starre Vorgehen ähnelt dem eines Pflichtenhefts, welches ebenfalls am Anfang eines Projektes festgelegt wird. In beiden Dokumententypen sind größere Änderungen nur mit hohem Aufwand möglich und entsprechen nicht dem Projektalltag in kleineren IT-Abteilungen. Während die dokumentengetriebene Softwareentwicklung (mittels Pflichten- und Lastenheften) immer mehr von agilen Prozessmodellen (Scrum, Kanban) abgelöst wird (vgl. Begel & Nagappan 2007, Salo & Abrahamsson 2008), findet man bei den Styleguides weiterhin die eher statische Dokumentationsform vor. Um den Styleguide aktuell zu halten, kann es von Vorteil sein, wenn die laufenden Änderungen durch einen dynamischen (iterativen) Ansatz festgehalten werden. In diesem Zusammenhang hat die Agentur Iconstorm festgestellt, dass die Aktualität inkl. Erstellungsprozess auf 36 Monate begrenzt ist. „Überraschend ist die Tatsache, dass die langfristige Designstrategie nur noch bei der Minderheit der teilnehmenden Unternehmen, länger als drei Jahre gilt. Lediglich 20 Prozent geben eine Ausrichtung der Strategie auf mehr als zehn Jahre an. […] Die Halbwertszeit sinkt, zwischen Erstellungsprozess und Erneuerung liegen nur selten noch mehr

215


als 36 Monate. Berücksichtigt man eine durchschnittlich angegebene Dauer bei der Erstellung von sechs Monaten, gilt ein Styleguide heutzutage maximal 24 Monate“ (Iconstorm 2010). In vielen Unternehmen werden die Styleguides meist als Dokument auf Laufwerken, im Intranet oder in Wiki-Systemen abgelegt. Dieser dezentrale und von den Arbeitswerkzeugen des Entwicklers abgegrenzte Ablageort unterbricht den Arbeitsfluss und stört die Effektivität. Für den Entwickler bedeutet dies eine aktive Suche nach neu einzubindenden UI-Elementen außerhalb seiner Arbeitsumgebung und damit eine Störung seines Arbeitsflusses und des Implementierungsprozesses. Darüber hinaus ist eine gewisse Organisation der Inhalte des Styleguides notwendig. Hier wird von der Agentur Iconstorm empfohlen, „lieber eine Vorlage statt einem Beispiel“ (Iconstorm 2010) abzubilden. Darüber hinaus sind die Vorlagen an einer zentralen und kommunizierten Stelle abzulegen, um die Auffindbarkeit zu verbessern. „Oft ist Mitarbeitern, die neue Dokumente anlegen wollen, nicht klar, wo der Inhalt im Wiki am besten untergebracht ist. Oder aber sie sind sich unsicher, ob sie ein neues Dokument anlegen oder ein bereits bestehendes Dokument ergänzen sollen“ (Seibert et al. 2011). Dieser Umstand kann dafür sorgen, dass Redundanzen die Übersichtlichkeit verhindern. Die Größe des Entwicklerteams kann ein Problem darstellen. Es erfordert meist mehrere Abstimmungsmeetings, wenn alle Anforderungen eines Projektes in das Projektteam getragen werden. Laut Litke geht die Effektivität tendenziell ab einer Größe von 15 Mitarbeitern zurück (Litke 2007). Ändern sich nun zusätzlich während des Projektes die Anforderungen des Styleguides müssen diese Abstimmungsrunden häufiger durchlaufen werden. „Nur wenn die Teamgröße auf die genannte Mitarbeiterzahl [5–8] beschränkt wird, ist ein vollständiger Informationsaustausch möglich. Er erlaubt es, dass ein Projektteam mit einem geringen Verwaltungsaufwand arbeiten kann und den direkten Kontakt

216

zwischen den Mitarbeitern aufrechterhält. Bei steigender Teamgröße nimmt der Aufwand für die Informationsvermittlung überproportional zu“ (Litke 2007). Richter und Flückiger empfehlen den Styleguide mit guten Beispielen und Hilfsmitteln anzureichern, um ein „gemeinsames Verständnis und das sinnvolle Anwenden der Regeln zu fördern“ (Richter & Flückiger 2010). Diese Vorgehensweise wird auch von Ortlieb befürwortet (Ortlieb 2012). Überdies schlagen Richter und Flückiger eine Kategorisierung des Styleguides in verschiedene Bereiche vor. Folglich kann es einen hersteller- oder plattformabhängigen Styleguide geben, welcher „das vorgesehene Look&Feel der Applikationen eines bestimmten Betriebssystems mit dem Ziel einer konsistenten Anwendung aller GUI-Elemente wie Eingabefelder, Listboxen, Schaltflächen etc.“ beschreibt (Richter & Flückiger 2010). Zusätzlich wäre es möglich, einen UnternehmensStyleguide bereitzustellen, welcher die Vorgaben aus dem Corporate-Design in den Applikationen reflektiert. Weiter wird eine Differenzierung vorgenommen, „ob es sich um Richtlinien für die firmeninterne Applikationslandschaft handelt oder um Anwendungen bzw. Produkte für externe Kunden“ (Richter & Flückiger 2010). Die Verwendung eines Projekt-Styleguides stellt die Richtlinie für „die Konsistenz der Benutzerschnittstelle bei der Entwicklung einer Applikation (z.B. beim Einsatz verschiedener UI Designer) oder von Produkten für den Endkunden sicher“ (Richter & Flückiger 2010). 2. Ideen, wie ein Styleguide vom Projektteam genutzt werden kann Nachdem die Erwartungen an den Styleguide nicht mit der praktischen Erfahrung der Autoren übereinstimmen, soll eine Lösung für das Problem aufgezeigt werden. Ein möglicher Lösungsansatz für das Prozessproblem sind die organisatorischen Voraussetzungen des Styleguides. Wie

Schubert et al. (Schubert et al. 2010) erläutern, ist eine zugeordnete Verantwortlichkeit für das Erstellen und Kommunizieren des Styleguides relevant für den erfolgreichen Einsatz. Der Verantwortliche kümmert sich darum, dass der Styleguide kommuniziert wird und allen Projektteilnehmern die allgemeinen Richtlinien und der Umgang mit der Dokumentation verständlich sind. Relevant ist, dass sich Anforderungen über den Projektzeitraum ändern können. Der Styleguide sollte deshalb immer die aktuellsten Absprachen enthalten und damit ist eine schnelle und einfache Änderung im Styleguide erforderlich. Dies wird auch von Herdle et al. (Herdle et al. 2010) und (Schrammel et al. 2010) unterstützt. Der initiale Styleguide gilt damit als Grund­lage für Erweiterungen und die Entwickler sind verpflichtet, den Styleguide-Verantwortlichen auf bisher nicht festgehaltene Regelungen aufmerksam zu machen. Der Verantwortliche kümmert sich dann wie­derum um das Festlegen der neuen Richtlinien und die Kommunikation ins Projektteam. Dieses Verfahren orientiert sich maßgeblich an dem agilen Prozessgedanken von Scrum und soll das iterative Anpassen der Styleguide-Anforderung organisieren. In diesem Zusammenhang beschreiben Schubert et al. (Schubert et al. 2010), dass die „organisatorische Verankerung des Styleguides in den Entwicklungsprozess“ und die „Sensibilität der Entwickler für ansprechende und konsistente Gestaltung“ wichtige Erfolgsfaktoren für den Styleguide sind. Der Wirkungskreis des zukünftigen Styleguides sollte vor Erstellung festgelegt werden und es wird vorgeschlagen den Wirkungskreis einzugrenzen (Richter & Flückiger 2010). Wie bereits in dem Abschnitt der Einleitung genannt, könnte auch ein kundenspezifischer Styleguide pro Produkt etabliert werden. Hierbei ist darauf zu achten, um welche Unternehmensgröße und Produktpalette es sich handelt. Unternehmensgrößen von unter 200 oder über 7000 Mitarbeiter sind Rahmenbedingungen, welche sie auf die Anforderungen des Styleguides (Benutzergruppe,


Usability Professionals 2013 UX Integration

Produktvielfalt, Anzahl der Produkte,…) auswirkt. Dieser Ansatz bezieht sich im Gegensatz zu Schrammel auf mittelständische Unternehmen. Im Unternehmen sollte eindeutig festgelegt werden, wo die Styleguides von den Projektteilnehmern, für jeden Kunden, jedes Projekt oder andere Bereiche zu finden sind. Hierbei erscheint wichtig, dass ein zentraler Ablageort (physikalisch oder virtuell) festgehalten wird. Bothmer (Bothmer 2011) beschreibt einen dynamischen Styleguide, welcher über den gesamten Entwicklungsprozess besteht und iterativ angepasst wird. Zudem geht er davon aus, dass die Plattform Confluence von Atlassian Software Systems als Enterprise Wiki hervorragend die Anforderungen an einen dynamischen Styleguide regelt. Damit ist allerdings nicht die Problematik der aktiven Suche nach Styleguide Vorlagen der Entwickler geregelt. Hiermit verlagern sich die Lösungsansätze in die Richtung des Umsetzungsproblems, denn der Ablageort könnte direkt die Entwicklungsumgebung des Entwicklers selbst sein. Hintergrund ist die bereits

starke Suchbereitschaft der Entwickler nach Methoden oder Funktionen ihrer Programmiersprache im Internet oder innerhalb der Methodenbibliothek der Entwicklungsumgebung. Im Artikel von Kirstein et al. (Kirstein et al. 2012) wird beschrieben, dass eine Orientierung „an der Arbeitsweise der Entwickler und deren Entwicklungswerkzeuge“ bestehen sollte. Zudem schlagen Kowalik et al. (Kowalik et al. 2011) die Integration in die Entwicklungsumgebung vor. Ein österreichisches Technologieunternehmen hat seinen Styleguide „mit dem Einsatz eines strukturierten AuthoringProzesses basierend auf DITA-Maps“ konstruiert (Schrammel et al. 2010). Damit bieten sie eine anwenderorientierte Dokumentation des Styleguides, PDF-Dateien, die Integration in das Hilfesystem von Windows und die Integration in eine Entwicklungsumgebung an. Das von Schrammel et al. (Schrammel et al. 2010) dargestellte System verfügt über eine mächtige Struktur, eine hohe Flexibilität der Funktionen und Styleguide-Benutzergruppen, die jedoch mit einem hohen initialen Aufwand verbunden sind.

Das Unternehmen Apple erläutert in seinem Styleguide, dass das grundsätzliche Verständnis für ein Produkt und seine Gestaltung hilft, ein Produkt zu entwerfen, welches den Benutzer erfreut (Apple Inc. 2012). Apple hat Elemente seines Styleguides als Framework in seiner Entwicklungsumgebung Xcode integriert. Zudem bieten die Open-Source Produkte wie Eclipse oder kommerzielle Produkte wie Visual Studio von der Firma Microsoft die Möglichkeit Plug-Ins zu integrieren. Vorteilhaft wäre die Integration des Styleguides in die Entwicklungsumgebung, da der Entwickler diese Software jetzt schon täglich für seine Implementierung benutzt. Zunächst kann eine simple Darstellung in der Methodenbibliothek erfolgen, wie in Abbildung 2 dargestellt. [Abb. 2] Auch könnte die Idee der Firma Iconstorm (Iconstorm 2010) weiter interpretiert werden und eine Art Microsoft Word Formatvorlage für bestimmte Methoden der Programmierung in die Entwicklungsumgebung eingegliedert werden. Die Formatvorlage kann dann zum Beispiel für Formulare (Kontakt- und Bestellformulare), Buttons („Weiter“, „Abschicken“), AGBs,

Abb. 2. Bild von Visual Studio mit einer möglichen Darstellung einer Richtlinie aus dem Styleguide

217


„rechte Box“ im Webseitenauftritt, Detailseiten oder Fehlermeldungen gelten. Als Beispiel ist die Fehlermeldung in Abbildung 3 dargestellt. [Abb. 3] Diese Formatvorlagen können die heutigen UI-Patterns als Grundlage haben. Sinnvoll ist dabei eine Auswahl an zum Beispiel zwei UI-Pattern für den Entwickler und der zusätzlichen manuellen Änderbarkeit. Damit wäre ein schnellerer und integrierter Zugriff für den Entwickler gesichert und keine aktive Suche nach Styleguide Informationen nötig. Hilfestellung könnten auch die bereits bestehenden Frameworks wie Zend oder Microsoft Visual Studio LightSwitch geben, welche ein Grunddesign mitbringen. Eine Erweiterung durch Customizing der Methoden muss noch geprüft werden. Der Entwickler sollte an der Weiterentwicklung des Styleguides beteiligt werden und seine Ideen frühzeitig einbringen. Als weiterer Optimierungsansatz sollte die Versionierung der Artefakte (StyleguideDokumente/Texte/Formatvorlagen) über die bereits bestehende Versionsverwaltung (beispielsweise GIT, SVN oder TFS) der Entwicklungsumgebung nachvollziehbar abgebildet werden. Gesetzt den Fall, dass sich eine Designvorlage in der Praxis nicht

bewährt hat, ist ein Zurückkehren zu der vorherigen Version problemlos möglich. Natürlich ist es auch möglich, eine physikalische Abbildung als Poster im Büro der Entwickler aufzuhängen. Hierbei ist zu beachten, dass man diese aktuell halten muss. Das Ziel ist die einfache Verwendung und schnelle Verbreitung der Änderungen des Styleguides an die Softwareentwickler. 3. Fazit Der Styleguide ist als relevantes Artefakt in der Software-Entwicklung anerkannt. Nach der genaueren Betrachtung des Styleguides können die Ursachen für die praktische Benutzung aufgeführt werden. Es liegt an menschlichen und teilweise organisatorischen Eigenschaften, dass ein Styleguide oftmals nicht wie vorgesehen funktioniert. Hinzukommt, dass die Vielzahl an anfallenden Artefakten, Dokumenten und Programmen und der daraus resultierenden Medienbruch destruktiv für die Effektivität des Entwicklers und der Projektteilnehmer ist. Es wird deutlich, dass in Anlehnung an den agilen SoftwareEntwicklungsprozess der Styleguide in der Umsetzungsphase iterativ seine

Anforderungen spezifiziert, welche dann wiederum schnellstmöglich dem Projektteam zur Verfügung gestellt werden sollten. Die Probleme können in Prozess- und Umsetzungsprobleme eingeordnet und beschrieben werden. Zusätzlich zu einer Befragung und deren Auswertung soll in der nahen Zukunft verstärkt auf Lösungsansätze eingegangen werden, um diese auf ihre Realisierbarkeit zu überprüfen. Dafür eignen sich besonders die Open-Source Entwicklungsumgebung Java Sun Eclipse und die kommerzielle Entwicklungsumgebung Microsoft Visual Studio. Beide Produkte bieten Ansätze für eine Erweiterung mittels PlugIns innerhalb der Entwicklungsumgebung. Weitere langfristige Ziele sind die Erstellung eines ersten Prototyps und die Durchführung eines Probelaufs. Die Voraussetzung für das Erreichen der Ziele stellt eine Kooperation mit einem oder mehreren Unternehmen dar, die einzelne Produkte, Projekte und Entwickler für eine Überprüfung zur Verfügung stellen.

Abb. 2. Entwurf einer möglichen Designvorlage für die Fehlermeldung der Anmeldung

218


Usability Professionals 2013 UX Integration

Literatur 1. Apple Inc. (2012). Mac OS X Human

10. Ortlieb, W. (2012). Styleguides. Online verfügbar unter: http://www.se.uni-

Interface Guidelines. online verfügbar

hannover.de/pub/File/kurz-und-gut/ss2012-

unter http://developer.apple.com/library/

proseminar-inf-usabiliy/Ortlieb2012.pdf.

mac/#documentation/UserExperience/ Conceptual/AppleHIGuidelines/Intro/Intro. html, zuletzt geprüft am 02.07.2013. 2. Begel, A. & Nagappan, N. (2007). Usage and perceptions of agile software development

Zuletzt geprüft am 02.07.2013. 11. Richter, M. & Flückiger M. (2010). Usability Engineering Kompakt. Heidelberg: Spektrum Akademischer Verlag. 12. Salo, O. & Abrahamsson, P. (2008). Agile

in an industrial context: An exploratory study.

methods in European embedded software

In: IEEE Empirical Software Engineering and

development organisations. In: Software, IET

Measurement, 255–264.Los Alamitos. IEEE Computer Society. 3. Bothmer, J. (2011). Tools für die aktive Markenführung. Dynamischer Styleguide.

2. 58–64. 13. Sarodnick, F. & Brau, H. (2011). Methoden der Usability Evaluation. Bern: Huber. 14. Schrammel, J., Lugmayr, M., Hämmerle,

Iconstorm – Agentur für Markentechnik

F.,Murtinger, M. & Tscheligi, M. (2010).

GmbH & Co. KG. Online verfügbar unter:

Flexible und erfolgreiche Implementierung

http://www.style-guide.org/Kategorien/

eines User Interface Styleguides mittels

articles/Dynamischer_Styleguide.html.

eines strukturierten Authoring-Konzeptes

Zuletzt geprüft am 30.05.2013.

basierend auf DITA-Maps. In: Brau, H.

4. Buxton, Bill (2010). Sketching User Experiences. Amsterdam: Morgan Kaufmann. 5. Herdle, K., Kurzak, M., Kratzheller, J. & Bierkandt, J.(2010). Gemeinsames

(Hrsg.). Usability Professionals 2010, 141– 145. Stuttgart: German Chapter der Usability Professionals Association. 15. Schubert, U., Bonhag, W. & Groß, M. (2010).

Verständnis erzeugen bei der

Einsatz von User Interface Patterns bei der

interdisziplinären Gestaltung des neuen

Entwicklung von Business-Software. In: Brau,

Bahnautomaten. In: Brau, H. (Hrsg.): Usability

H. (Hrsg.). Usability Professionals 2010, 150 –

Professionals 2010, 108–113. Stuttgart:

156. Stuttgart: German Chapter der Usability

German Chapter der Usability Professionals Association. 6. Iconstorm (2010). Styleguide. Gestaltungsrichtlinien-Monitor 2010. Iconstorm – Agentur für Markentechnik

Professionals Association. 16. Seibert, M., Preuss, S. & Rauer, M. (2011): Enterprise Wikis. Wiesbaden: Betriebswirtschaftlicher Verlag Gabler. 17. Wilson, C. (2010). Guidance on Style Guides.

GmbH & Co. KG. Online verfügbar

online verfügbar unter http://www.stcsig.org/

unter: http://www.iconstorm.de/news/56/

usability/newsletter/0104-style.html, zuletzt

Iconstorm-verffentlicht-Bulletin-11–2010-

aktualisiert am 24.10.2010, zuletzt geprüft

zum-Thema-Styleguide. zuletzt geprüft am

am 24.06.2013.

13.02.2013. 7. Kirstein, E., Schoenherr, N. & Schubert, U. (2012). Icon Design im großen Stil. In: Brau, H. (Hrsg.). Usability Professionals 2012, 60–66. Stuttgart: German UPA e.V. . 8. Kowalik, P., Schrepp, M. & Erle, M. (2011). Eingeschränkt Sehen. Eingeschränkt Hören. In: Brau, H. (Hrsg.). Usability Professionals 2011, 66 -70. Stuttgart: German UPA e.V. 9. Litke, H. (2007). Projektmanagement: Methoden, Techniken, Verhaltensweisen. München: Hanser.

219


User Experience in Kanban Die UX-Karte ausspielen

Dominique Winter Buhl Data Service GmbH Am Siebertsweiher 3/5 57290 Neunkirchen dwinter@buhl-data.com

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

Jan Uhlenbrok basecom GmbH & Co. KG Hannoversche Straße 6–8 49084 Osnabrück jan@usability3000.de

Abstract Die agile Projektmanagementmethode „Kanban“ zielt auf geringe Durchlaufzeiten ab und richtet damit den Fokus der Entwicklung auf das Moment der aktuellen Aufgabe. Um Produkte mit einer positiven User Experience zu entwickeln, muss bereits der Gestaltungsprozess auf die Bedürfnisse des Menschen ausgelegt sein. Dadurch werden agile Projekte vor die Herausforderung gestellt, sowohl die einzelnen Aufgaben als auch das gesamte Produkt zielgerichtet und nutzerzentriert zu realisieren. Dieser Beitrag soll zeigen, wie trotz des eingeschränkten Gesamtüberblicks dennoch eine Nutzerzentrierung bei der Entwicklung realisiert werden kann. Hierzu wird vor allem die Frage geklärt, wie sich Human-Centered Design Aktivitäten in Kanban integrieren lassen und an welchen Stellen im Softwareentwicklungsprozess Evaluationen der User Experience durchgeführt werden können.

1. Einleitung Agile Projekte zeichnen sich dadurch aus, dass während des Entwicklungsprozesses schnell auf Änderungen der Anforderungen reagiert werden kann. Während die agilen Modelle die Softwareimplementierung optimieren, gibt es bei der Integration der nutzerzentrierten Gestaltung noch Handlungsbedarf. Agile Vorgehensmodelle wie beispielsweise Extreme Programming, Scrum und Kanban geben weder Vorgaben für die Integration von Human Centered Design-Methoden noch Hinweise darauf, wie Anforderungen für die Erstellung des Product Backlogs erhoben und priorisiert werden. Erste Ansätze existieren für Scrum, beispielsweise eine vorgelagerte Visioning Phase (Beyer 2010), (Winter, Holt & Thomaschewski 2012), (Holt, Winter & Thomaschewski 2012) oder eine parallel zum Entwicklungssprint verlaufende Konzeptionsphase in gleicher Organisation (Obendorf, Gibbert, Petersen & Memmel 2010), (Sy 2007). Abgeschlossene Entwicklungszeiträume, wie sie beispielsweise Scrum in Form von

220

Sprints vorsieht, fehlen bei Kanban. Es findet eine kontinuierliche Entwicklung statt. Während dieser kontinuierlichen Entwicklung betrachtet das Teammitglied nur seine eigene Aufgaben-Einheit im jeweiligen Fachgebiet. Eine wiederkehrende Zieldefinition über Aufgabengrenzen hinweg findet nicht statt. Somit kann die User Experience (UX) als Ergebnis vieler einzelner Eigenschaften eines Produkts ohne die Konzeption des Gesamtprodukts schwer berücksichtigt werden. Kanban ist eine Projektmanagementmethode, die in IT-Organisationen für die agile Softwareentwicklung eingesetzt wird. Im Vergleich zu Scrum existieren bei Kanban weniger Vorgaben. Während bei Scrum die Rollen Product Owner, Scrum Master und Team-Mitglieder beschrieben sind, sind bei Kanban keine Rollen definiert (Kniberg & Skarin 2010). Bei Scrum sind zudem multifunktionale Teams vorgeschrieben, denn ein Scrum-Team muss alle notwendigen Fertigkeiten besitzen, um ein Produkt zu entwickeln (Gloger 2011). Dazu sind neben Programmierern unter anderem auch Konzepter, Business-Analysten und Designer erforderlich. Im Vergleich hierzu sind bei

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

Keywords: /// Kanban /// User Experience /// Human Centered Design /// Agile Softwareentwicklung

Kanban multifunktionale und funktio­nale Teams, bestehend aus Experten, erlaubt (Kniberg & Skarin 2010). Da in vielen Unternehmen bereits funktionale Teams vorhanden sind, ist eine Einführung von Scrum im Hinblick auf die Anpassung der Unternehmensorganisation mit mehr Aufwand verbunden als eine Einführung von Kanban. 2. Prozessablauf Bei Kanban wird zur Visualisierung der Ar­beitsaufgaben das sogenannte „­KanbanBoard“ eingesetzt. Auf einer Art Tafel wer­ den zunächst in Form von Spalten die ein­ zelnen Aktivitäten (Implementierung, Tes­ ten, etc.) der Wertschöpfungskette benannt (Shalloway 2010), (Epping 2011). Die Anordnung der Spalten muss hierbei mit der Reihenfolge der Aktivitäten übereinstimmen, die zur korrekten Aufgabenerfüllung führen. Dies richtet sich nach den jeweiligen Prozessen des Unternehmens und kann sich daher von Fall zu Fall unterscheiden. Nicht jedes Unternehmen führt z.B. eine gesonderte, abschließende Qualitätssicherung durch, andere hingegen haben zwei Aktivitäten wie Oberflächen- und Performancetests.


Usability Professionals 2013 UX Integration

Abb. 1. Beispielhaftes elektronisches Kanban-Board

Die Aufgaben selbst werden in Kanban auf gedruckten Karten (oder elektronisch als Tickets in einem Ticketsystem, [Abb. 1]) dargestellt. Jede Karte beinhaltet eine Beschreibung der zu erledigenden Aufgabe. Wurde in einer Spalte die Bearbeitung der Aufgabe abgeschlossen, so wandert die Karte weiter zur nächsten, bis schließlich die letzte Spalte erreicht wird. Die Teammitglieder bearbeiten nur Aufgaben, die sich auf dem Board befinden. Das Ziel der Arbeit mit dem Kanban-Board ist, dass alle Aufgaben erfasst sind und sich im stetigen Fluss befinden. Hierzu dient die Limitierung der gleichzeitig platzierten Aufgaben pro Spalte, wodurch die laufende Arbeit einer Spalte beschränkt wird. Diese Limitierung wird als „Work in Progress“ bezeichnet und beschreibt die maximale Anzahl an gleichzeitig in Arbeit befindlichen Aufgaben (Epping 2011). Durch die Visualisierung am Kanban-Board werden Engpässe schnell sichtbar. Sobald eine Aufgabe den Fluss der Aufgaben im Prozess blockiert, werden alle verfügbaren Ressourcen eingesetzt, um diese Blockade zu lösen (Anderson 2011). Die weiteren Regeln zum erfolgreichen Einsatz von Kanban finden sich bei Anderson (Anderson 2011), Leopold & Kaltenecker (Leopold & Kaltenecker 2012) und Patton (Patton 2009).

Die Begrenzung der gleichzeitig in einer Spalte befindlichen Arbeitsaufgaben führt zu einem weiteren Effekt: In jeder Prozesskette stellt eine der Spalten zwangsweise einen Engpass dar. Auch in einem Kanban-Board sorgt dieser „Flaschenhals“ dafür, dass nicht mehr Aufgaben weitergereicht werden können, als es diese eine limitierende Spalte zulässt (Leopold & Kaltenecker 2012). Wenn sich daher die Anzahl der eingehenden Aufgaben nach der limitierenden Spalte richtet, um damit den Aufgabenfluss konstant zu halten, so entstehen bei allen anderen Aktivitäten zeitliche Freiräume, die für aufgabenfremde Zwecke genutzt werden können (Anderson 2011). Beispielsweise muss die Entwicklung nicht mehr Ergebnisse liefern, als mit den geplanten Testressourcen anschließend getestet werden können. Die gewonnene Zeit kann in die Erhöhung von Qualität an Produkten, Projekten oder Abläufen investiert werden. Im Gegensatz zu der in IT-Organisationen oftmals verwendeten Managementmethode Scrum werden weder gemeinsame Planungen noch größere Besprechungen zu inhaltlichen Themen eingeplant. Die Kanban-relevanten Besprechungen (z.B. Teamretrospektive oder Queue Replenishment Meeting) fokussieren die Optimierung des Prozesses (Leopold & Kaltenecker

2012). Inhaltliche Aspekte des Projektes bleiben dabei außen vor. Auch das tägliche Standup-Meeting, bei dem grob Aufgaben umrissen werden, wird auf aktuelle Aufgaben beschränkt. Dennoch ist Kanban ein flexibles Rahmenwerk und es bietet sich an, die aus Scrum bekannten Rituale auch in Kanban zu übernehmen. Somit kann der Kanban-Entwicklungsprozess auf die Bedürfnisse des Teams und des Produkts hin optimiert werden (Kniberg & Skarin 2010). Durch die Fokussierung auf die aktuelle Aufgabe fehlt die Möglichkeit für den einzelnen, sich den für die User Experience wichtigen Überblick über das den Aufgaben zugehörige Projekt zu verschaffen. Denn selbst wenn einzelne Teil-Aufgaben auf User Experience getestet werden, so bedeutet dies nicht automatisch eine gute User Experience für die zu lösende Gesamt-Aufgabe. Hierbei ist vielmehr das Zusammenspiel der einzelnen Bestandteile zu betrachten, die miteinander interagieren (Poppendieck & Poppendieck 2003). 3. Integration der nutzerzentrierten Gestaltung in Kanban Zur Integration nutzerzentrierter Gestaltungsansätze in den Kanban-Prozess

221


bieten sich neben einer Anpassung der in der Wertschöpfungskette befindlichen Aktivitäten (Release Evaluation, Erweiter­ ung um weitere Kanban-Boards) vor allem die Einführung von UX-relevanten Artefakten (Persona-driven User Storys, Verwendung von Prototypen) und Ritualen (Überwinden von Teamgrenzen) an, damit die Anforderungen des Human Centered Design (HCD) (Deutsches Institut für Normung 2011) abgebildet werden können. 3.1. Release Evaluation Da im Laufe der Prozessbewältigung immer mehr Aufgaben abgearbeitet werden, füllt sich nach und nach die letzte Spalte des Boards. Diese hat keine Begrenzung an Aufgabenzetteln. Um eine regelmäßige Evaluation bezüglich der nutzerbezogenen Eigenschaften eines Produkts durchzuführen, bietet es sich an, auch für die letzte Spalte eine Beschränkung einzuführen und beim Erreichen entsprechende UXEvaluationen vorzunehmen. Die Anzahl der zu sammelnden Aufgaben hängt von der jeweiligen Teamgröße und den Releasezyklen ab. Beim Sammeln der Aufgaben gilt zu beachten, dass besonders neue oder veränderte Funktionen getestet werden, obwohl Bugs mit zu den zu sammelnden Aufgaben gehören. Aus diesen Evaluationen resultieren Verbesserungen, welche als neue Aufgaben im Kanban-Prozess einzuplanen sind. So entsteht ein iterativer Kontrollmechanismus, der langfristig die Einhaltung einer User Experience – Strategie ermöglicht und gesetzte Ziele verfolgbar macht. 3.2. Überwinden von Teamgrenzen Aufgrund bestehender Unternehmensstrukturen bilden sich in vielen Organisationen funktionale „Silos“, die in sich geschlossene Gruppen von Experten beinhalten. Der Nachteil dieser funktionalen Silos besteht darin, dass sich Wissen an einer Stelle des Entwicklungsprozesses befindet und nicht ohne weiteres über die Teamgrenzen hinweg genutzt werden kann. Agile Entwicklungsprozesse leben

222

von der gemeinschaftlichen Zusammenarbeit verschiedener Disziplinen (Beck et al. 2001). Diese interdisziplinäre Zusammenarbeit innerhalb eines Projektes bietet den Vorteil, dass Ideen bereits in frühen Phasen des Softwareentwicklungsprozesses von unterschiedlichen Seiten betrachtet werden können (Gothelf & Seiden 2012). Beispielsweise kann ein UX-Experte bei der Konzeption eines neuen Features einen Frontend-Entwickler zur Beratung hinzuziehen. Der Frontend-Entwickler kann mit seinem Wissen die Ideen aus technologischer Sicht hinsichtlich Umsetzbarkeit und Aufwand bewerten. Darüber hinaus kann er Vorschläge zur Optimierung der Idee beisteuern. Da sich die Summe der Aufgaben in einem Kanban-Board nach dem Engpass richten sollte, können gewonnene Freiräume eingesetzt werden, um die für eine gute User Experience erforderliche Kommunikation und Zusammenarbeit zu ermöglichen. Die Freiräume bieten Gelegenheit, Silos aufzubrechen und gemeinschaftlich zu arbeiten. Schließlich führt die gemeinschaftliche Weiterentwicklung der Idee zu einer besseren Lösung, die sich positiv auf die User Experience des zu entwickelnden Produktes auswirkt. Dies resultiert vor allem aus einem flexibleren Team, das schneller auf Nutzerfeedback reagieren (Klein 2013) und Kommunikationsschwierigkeiten durch das „Stille Post“-Prinzip verhindern kann (Brown 2012). 3.3. Verwendung von Persona-driven Use Storys Zur Abgrenzung des Produktumfangs und zur Darstellung von Anforderungen werden in agilen Entwicklungsprozessen oftmals User Storys eingesetzt. Besonders in Verbindung mit Scrum (Wirdemann 2011) und Extreme Programming (Wells 1999) sind diese bekannt, können aber auch in Kanban eingesetzt werden. Eine User Story besteht aus drei Teilen (Cohn 2004). Zum einen handelt es sich hierbei um eine textuelle Beschreibung, die eine Definition der Anforderung darstellt und für die Projektplanung genutzt werden kann. Ein

weiterer Teil stellt die Diskussion um die User Story dar, die zu einem besseren Verständnis der eigentlichen Anforderung im Team beiträgt. Der dritte Teil besteht aus den Akzeptanzkriterien. Aus den Akzeptanzkriterien geht hervor, wann eine User Story abgenommen werden kann. Sogenannte Persona-driven User Storys (Holt, Winter & Thomaschewski 2012) können verwendet werden, wenn Personas entwickelt wurden. Diese speziellen User Storys stehen in direkter Verbindung mit einer speziellen Persona (Cooper 1999), (Pruitt & Adlin 2006), (Holt, Winter & Thomaschewski 2011). Sie bieten durch den Bezug auf eine konkrete Persona den Vorteil, dass der Nutzer nicht als anonymes Wesen angesehen wird. Werden Persona-driven User Storys in Kanban verwendet, werden die Personas nicht nur in der Konzeption genutzt, sondern explizit bis zu den Entwicklern transportiert. Sie können dadurch projektumfassend verwendet werden. 3.4. Verwendung von Prototypen Da Anzahl, Reihenfolge und Benennung der Spalten im Kanban-Prozess flexibel sind, ist es möglich, den Prozess durch neue oder andere Aktivitäten in Richtung Human Centered Design zu erweitern. So kann vor der Bearbeitung durch Software­ entwickler eine Umsetzungsspalte und eine Evaluationsspalte für Prototypen eingefügt werden. Dadurch werden diese Maßnahmen fest innerhalb des Prozesses vorgeschrieben und auf deren Einhaltung geachtet. Der Vorteil beim Einsatz von Prototypen ist die Möglichkeit, bei den Projektbeteiligten ein umfassendes Bild vom zu entwickelnden Produkt zu erzeugen (Beyer 2010). Prototypen zeigen komplexe Zusammenhänge einzelner Anforderungen und verdeutlichen, wie diese im Kontext des Produkts zu verstehen sind. Des Weiteren können komplexe Arbeitsabläufe der Nutzer visualisiert werden. Ein weiterer Vorteil von Prototypen ist, dass bereits vor der Entwicklung Nutzerfeedback eingeholt werden kann. Es besteht die Möglichkeit, erste Usability-Tests an


Usability Professionals 2013

3.5. Erweiterung um weitere Kanban­Boards Eine Integration eines HCD-Prozesses ist innerhalb eines einzelnen Kanban-Boards schwerlich umzusetzen, da dieses häufig auf die reine Umsetzung der Programmiertätigkeit und der Abnahme- und Auslieferungstätigkeiten beschränkt ist. Daher ist eine Erweiterung des Kanban-Prozesses nach „vorne“ am sinnvollsten, denn dadurch werden Konzeptionsarbeiten in gleicher Art und Weise organisiert wie die Realisierung durch die Programmierung und der Prozess der Wertschöpfungskette wird vereinheitlicht. Um unterschiedliche Teams abzubilden (z.B. Konzeptionsteam und Programmierteam) können auch zwei oder mehr Boards nebeneinander genutzt werden. Ergebnisse der Konzeption wandern dann vom Konzeptionsboard zum Entwicklungsboard und können anschließend durch ein Administrations- oder Technikteam ausgeliefert werden. [Abb. 2]

KanbanBoards

Prototypen durchzuführen und somit wichtige Erkenntnisse für die Optimierung des zu entwickelnden Produktes zu sammeln (Hamborg, Klassen & Volger 2009). Des Weiteren kann bereits in frühen Phasen des Entwicklungsprozesses überprüft werden, ob das konzeptuelle Modell des Produktes mit den Annahmen über das mentale Modell der Nutzer übereinstimmt. Diese Übereinstimmung ist grundlegend für eine intuitive User Experience (Weinschenk 2011).

Artefakte

UX Integration

Personas & Prototyp

Konzept

Betrieb

Software

Entwicklung

Admin/Te T chnik Te

Abb. 2. Teamübergreifender Kanban-Prozess

Gemeinsames Daily Standup

Dies ermöglicht auch Engstellen zwischen den Teams aufzudecken, wenn die Realisierung nicht schnell genug vorankommt, um die fertigen Konzepte zu entwickeln oder umgekehrt. Obwohl beim Einsatz von mehreren Kanban-Boards die Teams getrennt werden können, müssen Aufgaben gemeinsam geschätzt und auf technische Parameter wie Realisierbarkeit, Aufwand, etc. abgestimmt werden. Dies sollte durch Meetings einer teamübergreifenden Gruppe aus allen Kanban-Teams erfolgen. Die Ergebnisse der Beurteilung sind dann die Grundlage für die Einplanung auf dem Entwicklungsboard. Es ist sinnvoll, dass alle Teams gemeinsam an den Daily Standup-Meetings teilnehmen, so dass das Entwicklungsteam über zukünftige Aufgaben informiert ist und das Konzeptionsteam aktuelle Probleme der Realisierung kennt. Dies fördert den Austausch zwischen den beteiligten Teams. Des

Weiteren muss die langfristige Entwicklung für alle Teams zugänglich gemacht werden (Epping 2011). Ziel ist es, teamübergreifend eine langfristige Planung zu kommunizieren und somit eine Gesamtübersicht für alle Projektbeteiligten zu schaffen. In Abbildung 3 ist die Erweiterung der Wertschöpfungskette um Konzeptionsboard und Technikboard dargestellt. Nachdem eine Anforderung das Konzeptionsboard durchlaufen und die Spalte „Done“ erreicht hat, wird diese zu einer oder mehreren Aufgaben im Entwicklungsboard. Sobald die Aufgaben die Spalte „Done“ des Entwicklungsboards erreicht haben, können diese zu einem weiterführenden Technikboard verschoben werden, damit beispielsweise die umgesetzten Produktbestandteile auf verschiedenen Systemen installiert werden. [Abb. 3] Abschließend gilt zu beachten, dass nach dem gesamten Prozess ein Abgleich

Abb. 3. Beispielhafte Kombination mehrerer Kanban-Boards

223


zwischen den Planungen des Konzeptionsboards und der abgeschlossenen Entwicklung vorgenommen werden muss. Dies dient der Zielkontrolle und sichert eine gerichtete Produktentwicklung.

Literatur 1. Anderson, D. (2011). Kanban: Evolutionäres Change Management für IT-Organisationen, 1. Auflage, Heidelberg, Neckar: dpunkt. 2. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,

4. Zusammenfassung

Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R., Mellor, S., Schwaber, K., Sutherland, J. & Thomas,

Agile Prozesse können und müssen mit einigen Erweiterungen im Hinblick auf die nutzerzentrierte Gestaltung optimiert werden. Bei Scrum bietet sich hierfür eine vorgelagerte Visioning Phase an, in welcher die Vision des Produktes konkretisiert wird. Ebenso kann eine parallel zum Entwicklungssprint verlaufende Konzeptionsphase genutzt werden. Parallel kann bei der Projektmanagementmethode Kanban ein weiteres Kanban-Board für die Konzeption eingeführt werden. Dieses Board wird gleichzeitig mit dem in der Entwicklung eingesetzten Entwicklungsboard verwendet. Der Einsatz eines Konzeptionsboards bietet den Vorteil, dass konzeptionelle Aufgaben, die für das Design einer positiven User Experience wichtig sind, auf gleiche Art und Weise organisiert und im Fortschritt kommuniziert werden können wie die Entwicklungsaufgaben. Somit werden konzeptionelle Aufgaben im Entwicklungsprozess etabliert und erhalten den gleichen Stellenwert. Des Weiteren werden die Grenzen zwischen verschiedenen Teams wie beispielsweise Konzeption und Entwicklung ­aufgebrochen, was zu positiven Effekten analog denen eines multifunktionalen Teams führt. Dies wird nicht nur durch ein gemeinsames Daily Standup-Meeting erreicht, sondern insbesondere durch ein gleichgewichtiges Einbeziehen aller am Prozess beteiligten Teammitglieder.

D. (2001). Manifesto for Agile Software Development. 3. Beyer, H. (2010). User-centered agile

smarter user experience research and design, Sebastopol, CA: O'Reilly Media, Inc. 15. Kniberg, H. & Skarin, M. (2010). Kanban and Scrum: Making the most of both, [S.l.]: C4Media, Inc. 16. Leopold, K. & Kaltenecker, S. (2012). Kanban in der IT: Eine Kultur der kontinuierlichen Verbesserung schaffen, München: Hanser. 17. Obendorf, H., Gibbert, R., Petersen, I. & Memmel, T. (2010). Agile UX – Wege zur agilen nutzerzentrierten Entwicklung, In Brau

methods, San Francisco, Calif: Morgan &

H., Diefenbach S., Göring K., Peissner M.,

Claypool.

Petrovic K. (Hrsg.): Usability Professionals

4. Brown, D. (2012). Agile user experience design: A practitioner's guide to making

2010. 18. Patton, J. (2009). Kanban Development

it work, San Francisco, Calif: Morgan

Oversimplified, http://www.

Kaufmann.

agileproductdesign.com/blog/2009/

5. Cohn, M. (2004). User stories applied: For agile software development, Boston, Mass: Addison-Wesley. 6. Cooper, A. (1999). The inmates are running the asylum, Indianapolis, Ind: Sams. 7. Deutsches Institut für Normung (2011).

kanban_over_simplified.html, abgerufen am 16.03.2013. 19. Poppendieck, M. & Poppendieck, T. (2003). Lean software development: An agile toolkit, Boston, Mass: Addison-Wesley. 20. Pruitt, J. & Adlin, T. (2006). The persona

Ergonomie der Mensch-System-

lifecycle: Keeping people in mind

Interaktion – Teil 210: Prozess zur Gestaltung

throughout product design, Amsterdam

gebrauchstauglicher interaktiver Systeme.

;, Boston: Elsevier; Morgan Kaufmann

8. Epping, T. (2011). Kanban für die Softwareentwicklung, Berlin, Heidelberg: Springer Berlin Heidelberg. 9. Gloger, B. (2011). Scrum: Produkte zuverlässig und schnell entwickeln, 3. Auflage, München: Hanser, Carl. 10. Gothelf, J. & Seiden, J. (2012). Lean UX: Applying lean principles to improve user experience, 1. Auflage, Sebastopol, CA: O'Reilly Media, Inc. 11. Hamborg, K.-C., Klassen, A. & Volger, M. (2009). Zur Gestaltung und Effektivität von Prototypen im Usability-Engineering, In Mensch & Computer. 12. Holt, E.-M., Winter, D. & Thomaschewski, J. (2011). Personas als Werkzeug in modernen

Publishers, an imprint of Elsevier. 21. Shalloway, A. (2010). Common Myths of Kanban, http://www.netobjectives.com/ blogs/common-myths-kanban, abgerufen am 27.03.2013. 22. Sy, D. (2007). Adapting usability investigations for agile user-centered design. In: Journal of usability studies, Vol. 2, Nr. 3, S. 112–132. 23. Weinschenk, S. (2011). 100 things every designer needs to know about people, Berkeley, CA: New Riders. 24. Wells, D. (1999), User Stories, http://www. extremeprogramming.org/rules/userstories. html, abgerufen am 27.07.2013 25. Winter, D., Holt, E.-M. & Thomaschewski, J.

Softwareprojekten: Die Humanisierung des

(2012). Persona driven agile development:

Anwenders, In Usability Professionals 2011,

Build up a vision with personas, sketches and

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

persona driven user stories. In: Proceedings

Schroeder (Hrsg.), Stuttgart.

of the 7th Conference on Information

13. Holt, E.-M., Winter, D. & Thomaschewski, J. (2012). Von der Idee zum Prototypen: Werkzeuge für die agile Welt, In Usability Professionals 2012, H. Brau, A. Lehmann, K. Petrovic und M.C. Schroeder (Hrsg.), Stuttgart.

224

14. Klein, L. (2013). UX for lean startups: Faster,

Systems and Technologies (CISTI). 26. Wirdemann, R. (2011). Scrum mit User Stories, 2. Auflage, München: Hanser, Carl.


Spezielle Design足anforderungen

225


Voice Control um jeden Preis? Theoretische und praktische Grundlagen für erfolgreiche Sprachsteuerungs-Angebote aus User Experience-Sicht Sandra Schuster Facit Digital GmbH Neuhauser Straße 17 80331 München s.schuster@facit-digital.com

Abstract Als Technologie ist Sprachsteuerung seit SIRI fast schon zur Gewohnheit geworden. Doch nur weil etwas technisch machbar ist, heißt es noch nicht, dass es auch „sinnvoll“ ist. Eine zentrale Grundvoraussetzung ist die Passung von Usecase und Technologie (Sprachsteuerung). Zudem soll der Nutzer die Anwendung intuitiv in der intendierten Weise bedienen können (und wollen). Dies verlangt bei der Umsetzung die besondere Berücksichtigung von Nutzungssituation und Nutzungskontext sowie adäquater Prinzipien der Interface-Gestaltung. Ziel unseres Projektes war es demzufolge, sowohl theoretische als auch praktische Grundlagen für ein erfolgreiches Voice Control-Angebot zu erarbeiten. Dabei werden u.a. folgende Fragen beleuchtet: Welche inhaltlichen Konzepte eignen sich eigentlich für den Einsatz von Sprachsteuerung? Wann schafft Voice einen Mehrwert gegenüber Touch? Welche Anforderungen stellt das Medium Sprache an IA und UI-Design?

1. Ausgangslage und Erkenntnisziel „Among speech interface designers, there’s a credo: A good GUI and a good VUI are both a pleasure to use, a bad GUI is hard to use, but a bad VUI isn’t used at all.“ (Abbott, 2002) Wie wahr dieses Credo von Kenneth Abbott zu sein scheint, konnten wir Anfang des Jahres im Rahmen eines Forschungsprojektes für einen Automobilhersteller erfahren. Inspiriert durch steigende Nutzungszahlen von SIRI und Google Speech, sollte die Entwicklung eines mobilen, durch Sprache gesteuerten Fahrzeug-Konfigurators Innovationskraft und Technologiestärke der Marke belegen. Ein entsprechender Prototyp für die geplante Smartphone-App befand sich zu diesem Zeitpunkt bereits in der Konzeption und sollte durch einen User Experience-Test auf Bedienbarkeit, Nutzerakzeptanz und Optimierungspotenziale hin überprüft werden. Allerdings war schnell klar, dass vor der Überprüfung der

226

konkreten Ausgestaltung noch einmal die ganz grundsätzliche Frage beantwortet werden musste: Passt Voice Control hier eigentlich? Ist die Konfiguration eines Fahrzeugs (auf einem mobilen Endgerät) tatsächlich ein „sinnvoller“ Usecase für Sprachsteuerung? Und erst dann: Wie sieht die konkrete Ausgestaltung aus? Welche Parameter sind zu beachten, um eine möglichst optimale User Experience und damit auch Marktakzeptanz zu erreichen? Für unser Forschungsprojekt leiteten sich darauf folgende zentrale Fragestellungen ab: –– Welche technologischen und gestalterischen Aspekte sind zu berücksichtigen? Speziell: Wie sieht das optimale Zusammenspiel zwischen verschiedenen User Interfaces (z.B. GUI und VUI) aus? –– Trifft das Angebot überhaupt ein Nutzerbedürfnis und/oder eine potenzielle Nutzungssituation? Beziehungsweise: Für welche Usecases bietet sich Sprachsteuerung in besonderer Weise an, für welche gegebenenfalls eher nicht? –– Wann schafft Sprache einen („echten“) Mehrwert, z.B. gegenüber Touch?

Keywords: /// Voice Control /// GUI /// VUI /// MUI

Um diese Fragestellungen fundiert zu beantworten, wählten wir ein mehrdimensionales Vorgehen: Anhand einer umfassenden Desk Research wurden zunächst wesentliche (theoretische) Grundlagen für die Konzeption und Gestaltung von Anwendungen, die auf Sprachsteuerung basieren, erarbeitet. Durch eine ergänzende Best Practice-Recherche konnten dabei erste allgemeine Regeln und Prinzipien im Sinne von Dos and Don’ts formuliert werden, welche sich sowohl auf technologische und gestalterische als auch auf Usecase-basierte Aspekte beziehen. Darauf aufbauend wurde ein qualitativer Kriterienkatalog entwickelt, anhand dessen der aktuelle Konzeptstand (semi-funktionaler Prototyp der App) in Form einer heuristischen Evaluation überprüft werden sollte. Vertieft wurde diese Betrachtung durch einen (unabhängig voneinander durchgeführten) Cognitive Walkthrough durch zwei Usability Experten von facit digital. Dabei wurden typische Tasks und Konfigurationsprozesse des Voice Control-Konfigurators schrittweise durchgespielt und Optimierungsmöglichkeiten


Usability Professionals 2013 Spezielle Designanforderungen

identifiziert sowie konkrete Handlungsempfehlungen für unseren Auftraggeber formuliert. Der folgende Beitrag skizziert pointiert und beispielhaft einige zentrale Erkenntnisse aus dem Forschungsprojekt. Nach einer groben thematischen Einordnung und Begriffsklärung, werden relevante Aspekte für die Gestaltung von sprachgesteuerten (Marketing-) Angeboten aus verschiedenen theoretischen und praktischen Blickwinkeln beleuchtet. Den Abschluss bildet unser (leider wenig optimistisches) Fazit für eine sprachgesteuerte Fahrzeug-Konfigurator-App. 2. Thematische Einordnung und Begriffsdefinition Dass eine Fahrzeugkonfiguration nicht ohne visuelle Stützung auskommt, erklärt sich von selbst. Ein rein auf Sprache basierendes Angebot war demzufolge von vorneherein ausgeschlossen. Vielmehr galt es, das grafische User Interface (GUI) – an möglichst passender Stelle – mit Sprachsteuerung (VUI) zu verbinden. Werden wie in diesem Falle mehrere verschiedene Input-Methoden (z.B. Touch, Gesten, Sprache, etc.) miteinander kombiniert, ist in der Literatur die Rede von „Multimodalen Systemen“ bzw. „Multimodalen User Interfaces“ (MUI). „Multimodal User Interfaces (MUI) process two or more combined user input modes (such as speech, pen, touch, manual gesture, gaze, and head and body movements) in a coordinated manner with multimedia system output. They are a new class of interfaces that aim to recognize naturally occurring forms of human language and behavior, and which incorporate one or more recognition-based technologies (e.g. speech, pen, vision).“ (Dumas et al., 2009) Die Stärke multimodaler Systeme liegt in der Kombination der Stärken der individuellen Modalitäten, in unserem Falle: der Sprach-Ein-und Ausgabe sowie der GUIEin- und Ausgabe. Dafür gibt es gängigerweise drei Strategien (vgl. Schnelle-Walke und Döweling, 2011):

–– Substitutionsstrategie. Diese Strategie ist nützlich, wenn eine Modalität eine andere Modalität in einer Anwendung komplett ersetzt, die auf unterschiedlichen Endgeräten mit unterschiedlichen Eingabe- und Ausgabemöglichkeiten ausgestattet ist (Beispiel: Im Auto; reine Spracheingabe anstelle von manueller Eingabe). –– Redundanzstrategie. Wenn verschiedene Modalitäten in redundanter Art und Weise genutzt werden und damit letztendlich die gleiche Information zur gleichen Zeit übermitteln (Beispiel: Telefon: Klingelton und Vibrationsalarm) –– Komplementärstrategie. Gilt als bester Weg zur Umsetzung eines multimodalen Systems und ist dann gewährleistet, wenn jeweils die am besten geeignete individuelle Modalität eingesetzt wird, um die aktuelle anstehende Aufgabe zu lösen. Wie oben bereits angedeutet, liegt die Komplementärstrategie als bester Lösungsweg zur Kombination von GUI und VUI im speziellen Anwendungsfall eines mobilen Fahrzeug-Konfigurators quasi auf der Hand. Nicht jedoch die Antwort auf die Frage: In welchen Fällen ist Spracheingabe tatsächlich besser geeignet als die Eingabe per Touch? Und in welchen Fällen ist Sprachausgabe tatsächlich besser geeignet als die Anzeige über das GUI? 3. Grundlagen für Konzeption und Gestaltung sprachgesteuerter Anwendungen Unsere Annäherung an diese zentralen Fragen erfolgte unter Berücksichtigung folgender Leitfragen und Standpunkte: Was wissen wir über Sprache? Was sagen die (potenziellen) Nutzer? Was sagen die User Interface-Forscher? Was lehrt uns der Markt? Die folgenden Abschnitte beleuchten ausgewählte Aspekte dieser Standpunkte.

3.1. Was wissen wir über Sprache? Diese erste Leitfrage betrachtet die besonderen Spezifika der Sprache als Medium. Was sind eigentlich inhärente Eigenschaf­ ten der Sprache? Und was bedeuten diese für die Verwendung innerhalb eines multi­ modalen Systems und im Zusammenspiel mit einem grafischen User Interface? Schnelle-Walke und Döweling geben hier einige Anhaltspunkte (vgl. Schnelle-Walke und Döweling, 2011): Zunächst einmal ist Sprache eindimensional. Das heißt das Ohr kann eine Reihe von Aufnahmen nicht so schnell erfassen wie das Auge Text und Bilder scannen kann. Auch ist Sprache flüchtig – und damit nicht das ideale Medium, um große Mengen an Daten und Informationen zu vermitteln. Sprache ist außerdem unsichtbar. Das macht es schwer, dem Nutzer (schnell) zu vermitteln, welche Aktionen durchgeführt und welche Formulierungen verwendet werden müssen, um diese Aktionen durchzuführen. Nicht zuletzt ist Sprache zudem asymmetrisch. Das bedeutet: Menschen sprechen schneller als sie tippen können, aber sie können wesentlich langsamer zuhören als sie lesen können. Diese inhärenten Eigenschaften der Sprache lassen bereits erste Ableitungen zu, wenn es darum geht, welche Informationen eher über ein grafisches, und welche eher über ein sprachliches User Interface umgesetzt werden sollten. So lässt sich festhalten, dass große Datenmengen wie Text, Bilder und Videos quasi zwangsweise über GUI dargestellt werden müssen. Um das (langsame) Tippen von längeren Texten zu vermeiden, sollte der Fokus der GUI-Eingabe auf kurzen textlichen Eingaben liegen. Andersherum sollte auf das Vorlesen längerer Textpassagen verzichtet und der Fokus der Sprachausgabe auf kurzen Bestätigungen oder Anweisungen liegen. Implizit ist diesen (wie auch den folgenden) Ableitungen die Grundvoraussetzung, dass dem Nutzer klar

227


und präzise vermittelt werden muss, welche Spracheingaben er machen kann bzw. darf und welche er nicht machen kann bzw. darf. Zudem gibt es einige technische Faktoren der Sprachsteuerung, die aber – im Gegensatz zu den inhärenten Faktoren – beeinflusst werden können. Hierunter zählen vor allem die Qualität der Sprachsynthese, die Performance der Spracherkennung sowie der (individuell wählbare) Trade-Off zwischen Flexibilität und Genauigkeit. In puncto Sprachausgabe ist die Qualität moderner Text-To-Speech-Systeme (TTS) nach wie vor als eher niedrig einzustufen. Im Allgemeinen ziehen es die Nutzer deswegen (noch) vor, zuvor eingesprochene und aufgenommene Sprachsignale zu hören, da sie natürlicher klingen. Bei der Spracheingabe bzw. -erkennung ist zu berücksichtigen, dass Sprache nicht mit einer 100%-igen Genauigkeit erkannt wird, selbst von Menschen nicht. Dennoch werden in der Nutzung höchste Ansprüche an die Performanz der Spracherkennung gestellt. Dies betrifft unter anderem auch die Gewährleistung von Flexibilität: In der gesprochenen Sprache kann das gleiche Anliegen sehr unterschiedlich ausgedrückt werden, allein durch unterschiedliches Vokabular, vor allem aber durch Referenzierung auf aktuelle Kontexte. Ein (rein) sprachliches Interface muss demzufolge viele dieser Ausprägungen erkennen und unterstützen. Als gutes Beispiel dient die Datumsangabe: Ein flexibles System erkennt auch eine relationale Eingabe à la „Gestern“ oder „Mittwoch, der zweite“, ist in diesem Punkt jedoch gegebenenfalls anfälliger für Fehler. Dem gegenüber steht der Anspruch auf Genauigkeit, der (bis dato) eher durch die Eingabe einer starren Informationsabfolge erfüllt werden kann: „Bitte geben Sie das Jahr an… Bitte geben Sie den Monat an… Etc.“ Der optimale Trade-Off zwischen Flexibilität und Genauigkeit bleibt dabei in erster Linie Definitionssache (zumindest im Rahmen der technischen Möglichkeiten).

228

3.2. Was sagen die (potenziellen) Nutzer?

3.3. Was sagen die User Interface-Forscher?

Verschiedene Nutzerstudien haben ergeben, dass der tatsächliche Gebrauch einer Modalität vor allem von den Faktoren Vertrautheit bzw. Expertise und Effizienz abhängt (vgl. hier und im Folgenden: Wechsung et al., 2009).

Eng verwoben mit den Anforderungen der (potenziellen) Nutzer, lassen sich auch aus Perspektive der User Interface-Forschung einige Richtlinien für multimodale Anwendungen formulieren (vgl. hier und im Folgenden: Larson und Oviatt, 2004; Schaffer, Schleicher und Möller, 2011).

Speziell Touch stellte sich dabei wiederholt als die beliebtere Modalität im Vergleich zu Sprache heraus. Dies kann darin begründet sein, dass die Interaktionslogik bei grafischen Oberflächen weitgehend vertraut ist. Im Gegensatz müssen bei Sprachsteuerung noch viele interaktionsrelevante Kenntnisse erworben werden. Vor allem beim Lernen neuer Aufgaben kann man annehmen, dass zumeist gut bekannte Modalitäten eher zum Einsatz kommen (vgl. Seebode et al., 2009). Auch ergaben experimentelle Untersuchungen, dass die Wahrscheinlichkeit der Nutzung einer Modalität davon abhängt, wie viele Interaktionsschritte zur Erreichung der gewünschten Reaktion durchzuführen sind, letztendlich also: wie effizient die Modalität ist (vgl. Schaffer, 2008). Eingabemodalitäten, welche die Lösung einer Aufgabe mit weniger Interaktionsschritten erlaubten, wurden dementsprechend häufiger genutzt. Dies lässt den Umkehrschluss zu, dass eine wenig vertraute und gegebenenfalls anspruchsvolle(re) Modalität dann erhöhte Nutzungschancen hat, wenn für den Nutzer klar erkennbar ist, dass dadurch ein deutlicher Anteil an Interaktionsschritten eingespart werden kann. Die Kommunikation dieser Effizienz wird dabei in den meisten Fällen allerdings wieder dem GUI überlassen bleiben: Dessen initiale Aufgabe ist es dann, den Nutzer darauf hinzuweisen, dass durch die Verwendung der Spracheingabe eine schnellere Bedienung (insgesamt oder in bestimmten Teilbereichen der Anwendung) möglich ist.

Zunächst einmal gilt es, multimodale Systeme für eine möglichst große Bandbreite an Nutzern und Nutzungskontexten zu schaffen. UI-Designern ist also anzuraten, sich intensiv mit den psychologischen Charakteristika (kognitive Fähigkeiten, Motivation, etc.), dem Erfahrungsgrad der Nutzer sowie Fach- und Aufgaben-spezifischen Charakteristika befassen. Die empirische Identifikation von Personas und Usecases kann hier einen wichtigen Beitrag liefern. Gerade letzteres impliziert auch sich verändernde Umgebungen (z.B. Nutzung zuhause, im Büro, während der Fahrt, an einem öffentlichen Ort wie Haltestelle oder Warteraum, etc.) und damit die Notwendigkeit zur Auswahl der dortig jeweils besten Kombination von Modalitäten. In diesem Zusammenhang werden auch Aspekte der Privatsphäre sowie Sicherheitsbelange relevant. In Situationen, in denen Nutzer ihre Privatsphäre schützen wollen, sollte ein sprachfreier Modus angeboten werden Dies gilt auch und vor allem für die Eingabe privater Daten (Passwörter, Adressen, etc.). Die zentrale (und größte) Herausforderung bei der Gestaltung multimodaler User Interfaces stellt jedoch sicherlich die Optimierung der Interaktion auf die kognitiven und physischen Fähigkeiten der Nutzer hin. Für UI-Designer gilt es verlässlich herauszufinden, wie sie intuitive und effiziente Interaktionen schaffen können, welche auf primären menschlichen Wahrnehmungsund Verarbeitungsfähigkeiten basieren (Aufmerksamkeit, Kurzzeitgedächtnis, Entscheidungsfindung) – und damit die kognitive Last des Nutzers im Umgang mit dem


Usability Professionals 2013 Spezielle Designanforderungen

System bzw. Angebot möglichst gering halten (zum „cognitive load“-Konzept vgl. Wickens, 2002). In diesem Zusammenhang lassen sich (unter vielen anderen) zum Beispiel folgende Empfehlungen formulieren: –– Die visuelle Darstellung sollte mit manuellem Input gekoppelt sein, insbesondere für räumliche Informationen und parallele Verarbeitung; Sprachausgabe sollte an die Spracheingabe gekoppelt sein, insbesondere für Statusinformationen, serielle Verarbeitung, (Warn-) Hinweise oder Kommandoeingaben. –– Eine Dopplung von Sprach- bzw. Tonausgabe mit der visuellen Präsentation ist zu vermeiden, es sei denn, es müssen besonders wichtige Informationen übermittelt werden (Warnhinweise oder Systemmeldungen wie „Ich habe Sie nicht verstanden“, „Bitte sprechen“). –– Die Exploration von Inhalten sollte dem GUI und der Touch-Bedienung vorbehalten bleiben. Dies betrifft zum Beispiel folgende Interaktionsmöglichkeiten: Auswahl aus (längeren) Listen, Navigation (Wischen rechts/ links), Navigation in sichtbaren Elementen, Scrollen (hoch / runter), Vergrößern/ verkleinern, etc. –– Nutzung der Spracheingabe zur Abfrage des Systemstatus („Hilfe“) bzw. auch zur Steuerung von Dingen in der „Peripherie“ außerhalb des gerade sichtbaren GUIs/ „Area of Interest“ („Zum Motor“, „Wie hoch ist mein Preis?“) –– Nutzung von Sprachdialogen für kurze Frage- / Antwort-Dialoge (System ergreift Initiative, z.B. „Meinten Sie schwarz?“ „Ja.“ –– In der Sprachausgabe nur dann natürliche Sprache verwenden, wenn auch der Nutzer natürliche Sprache zur Steuerung des Systems verwenden kann. Falls die Spracheingabe nur einfache Befehle unterstützt, sollte auch die Sprachausgabe nur mit kurzen, klaren Hinweisen (Maschinensprache) erfolgen.

–– Kombination von Sprache und GUI zur Behebung von Fehleingaben. Der Nutzer sollte die Modalität selbst auswählen können, um für die jeweiligen Inhalte/Aufgaben eine weniger fehleranfällige Modalität nutzen zu können. Falls ein Fehler passiert, sollte es Nutzern erlaubt sein, zu einer anderen Modalität zu wechseln. 3.4. Was lehrt uns der Markt? Spätestens auf der Suche nach Best Practices lehrt uns der Markt, dass es kaum sprachgesteuerte bzw. multimodale Angebote gibt, die ähnlich komplexe Usecases abbilden wie es unser konkreter Anwendungsfall der mobilen FahrzeugKonfiguration tat bzw. tut.¹ Die im Gros etablierten sprachgesteuerten Systeme lassen sich grob wie folgt typisieren und zugleich chronologisch ordnen: –– Automatische Auskunftssysteme (seit 1980): Reine Voice-User-Interfaces zum Beschwerde-Management (Self-service). Starke Verbreitung liegt in erster Linie an möglichen Einsparungen im Call Center. –– Diktieren, Text-To-Speech (seit 1990er Jahren): Multimodale Systeme, die meist im professionellen Umfeld genutzt werden (Journalisten, Mediziner, etc.). Mehrwert: Spracherkennung (inzwischen) teilweise fünfmal schneller als Tippen. –– Sprachsteuerung im Automobil (seit 2010): Multimodale Systeme, die verschiedenste Aufgaben übernehmen. Meistgenutzte Funktionen: Telefongespräch starten, annehmen, beenden, Zielführung, POI-Selektion, Vorlesen von Nachrichten. Mehrwert: Aufgaben für den Fahrer „mit den Händen am Lenkrad“ ansonsten nicht bzw. nur schwer zu erfüllen. –– Smart TVS (seit 2011): Multimodale Interfaces, die von der Verbreitung der Smart TVs profitieren. Mehrwerte bislang für die breite Masse kaum erkennbar.

–– „Mobile Helfer" (seit 2011): Multimodale Interfaces, die von starker Verbreitung der Smartphones sowie protegierter Technologien (Siri, Google Voice Search) profitieren. Meist genutzte Funktionen: Telefonanrufe tätigen, Textnachrichten eingeben, VoiceBased Search. Mehrwerte: Ermöglicht Sprachsteuerung im mobilen Umfeld, erlaubt effiziente Nutzung für regelmäßige, alltägliche und überschaubare Aufgaben, insbesondere dann, wenn Nutzer Hände und Augen nur teilweise frei hat. Diese „mobilen Helfer“ können als aktueller Benchmark gelten, an dem sich ein mobiler sprachgesteuerter Fahrzeug-Konfigurator messen lassen muss. Ihr hoher Nutzwert liegt vor allem im Charakteristikum der alltäglichen Handlungen, welche mit kurzen, überschaubaren Befehlen angesteuert werden können (Telefonanruf, Aufruf einer App, etc.) und schnell zu erlernen sind. Hier zeigt sich bereits die erste Hürde zum „sinnvollen Usecase“ der Sprach­steuerung. 4. Fahrzeug-Konfiguration als sinnvoller Usecase für Sprachsteuerung? Bei der Fahrzeug-Konfiguration handelt es sich eben nicht um eine alltägliche Handlung, welche vom Nutzer regelmäßig durchgeführt. Allein dieser Umstand impliziert einige zentrale Nutzungsbarrieren: Es muss davon ausgegangen werden, dass bei den (potenziellen) Nutzern kaum Vorwissen aus der realen Welt über den Prozess-Ablauf der Konfiguration existiert, schon gar nicht im nötigen Detailgrad. Ein Lerneffekt durch häufige Wiederholung kann dadurch nicht einsetzen. Auch besteht – anders als im Bereich der „mobilen“ Helfer – in den seltensten Fällen bereits zu Anfang der Konfiguration eine klare Zielvorstellung (wie zum Beispiel für das Tätigen eines Anrufs: „Ich möchte

229


Max Mustermann anrufen“), welche mit Hilfe von Sprachsteuerung effizient bedient erreicht werden kann. Bei der Fahrzeugkonfiguration ist zwar klar, dass ein Auto, vermutlich auch das konkrete Modell, konfiguriert werden soll, Detailausprägungen und einzelne Bestandteile der Konfiguration sind zu Beginn jedoch (im Normalfall) nicht klar. Im Gegenteil, die Konfiguration lebt gerade von der (visuellen!) Exploration des Fahrzeugs. Nicht zuletzt deswegen ist auch ein Nutzungskontext „ohne Augen“ (ebenfalls ein Erfolgskriterium der „mobilen Helfer“) sehr unwahrscheinlich. In diesem Zusammenhang ist eher davon auszugehen, dass das GUI stets die bedeutendere Rolle spielen wird. Unter anderem aus oben genannten Gründen kann Sprachsteuerung hier allerdings nur bedingt unterstützen bzw. die Konfiguration tatsächlich effizienter (zum Beispiel als Touch) machen. Die meistgenutzten Funktionen der Sprachassistenten profitieren vor allem vom schnelleren Verfassen von Texten durch Spracheingabe (E-Mail verfassen, Diktieren). Die Herausforderungen für die Umsetzung eines Fahrzeug-Konfigurators liegen nicht so sehr in Spracherkennung und Darstellung des eingegeben Textes auf dem Display, sondern im Sprachverständnis. Je länger der Sprachbefehl des Nutzers und je natürlicher die Formulierung, desto geringer ist die Wahrscheinlichkeit, dass das System das Kommando korrekt erkennt. Unser Fazit? Die Fahrzeug-Konfiguration ist kein (sinnvoller) Anwendungsfall für Sprachsteuerung. Insbesondere, da sie aufgrund ihrer impliziten und implikativen Eigenschaften Konfigurationsprozess und -erlebnis eher behindert als fördert.

formulieren. Demnach schafft Sprache keinen Mehrwert (zum Beispiel gegenüber Touch): –– Für die Exploration von Inhalten und Elementen (z.B. in längeren Listen), die nicht a priori bekannt bzw. durch den Nutzer anzunehmen sind. –– Für die Exploration von (stark) visuellen Inhalten. –– Wenn sie für einmalige bzw. seltene Handlungen eingesetzt wird, für die kaum Vorwissen aus der realen Welt vorhanden ist (Nutzer haben keine Vorstellung über die vom System erwarteten Befehle und Eingabemöglichkeiten; Lerneffekt durch häufige Wiederholung kann nicht einsetzen). –– Wenn ein Nutzungsszenario einem festen Fahrplan folgt, der Schritt für Schritt durchgegangen werden muss – sondern erst dann, wenn durch Sprache Schritte übersprungen werden können.

230

eines Spracherkenners in ein Rauminformationssystem. In: Quality. 6. Schaffer, S., Schleicher, R. und Möller, S. (2011): Simulation von Benutzerverhalten im Umgang mit multimodalen Diensten. 9. Berliner Werkstatt Mensch-MaschineSysteme. VDI Verlag, S. 110–111. 7. Seebode, J., Schaffer, S., Wechsung, I., und Metze, F. (2009): Influence of User Characteristics on the Usage of Gesture and Speech in a Smart Office Environment. In: Proceedings of the 8th International Gesture Workshop 2009, Bielefeld. 8. Schnelle-Walka, D. und Döweling, S. (2011): Speech Augmented Multitouch Interaction Patterns. Darmstadt University of Technology. 9. Wechsung, I., Engelbrecht, K.-P., Schaffer, S., Seebode, J., Metze, F. und Möller, S. (2009): Usability-Evaluation multimodaler Schnittstellen: Ist das Ganze die Summe seiner Teile? In: Mensch & Computer 2009: Grenzenlos frei!?, München: Oldenbourg

Unserem Auftraggeber konnten wir die Weiterverfolgung des (damaligen) Konzeptansatzes nicht empfehlen. Allerdings leistete unsere Arbeit einen grundlegenden und wichtigen Beitrag dafür, weitere Ideen und Ansätze für sprachgesteuerte Angebote frühzeitig (das heißt vor allem: ohne „unnötige“ Konzeptionsaufwände) zu bewerten sowie neue Anwendungsfälle, die tatsächlich einen sinnvollen Usecase für Sprachsteuerung darstellen, zu definieren.

Verlag, S. 495–498. 10. Wickens C. D. (2002): Multiple resources and performance prediction. In: Theoretical Issues in Ergonomics Science, 3 (2), S. 159–177.

¹ Anmerkung: Seit Juli 2013 bietet AutoScout24 in der Android-Version der AS24-App eine sprachgesteuerte Fahrzeugsuche an und nähert sich damit dem Usecase „Fahrzeug-Konfiguration“ zumindest thema-

Literatur

tisch an. Diese war zum Projektzeitraum noch

1. Abbott, K.R. (2002): Voice Enabling Web

nicht verfügbar. Auch liegen aktuell noch

Applications: VoiceXML and Beyond. a!press,

keine Nutzungsdaten vor. Nach erster Eva-

2. Auflage.

luation beschränkt sich die App jedoch auf

2. Chandler, P. und Sweller, J. (1991). Cognitive

die initiale Suche bzw. Selektion (Ersteingabe

Load Theory and the Format of Instruction.

relevantes Modell, Farbe, Motorisierung,

In: Cognition and Instruction, 8 (4), S.

etc.). Systemrückmeldungen, Bestätigungen

293–332.

und Modifikationen der Suche werden weiter-

3. Dumas, B., Lalanne D. und Oviatt, Sh. (2009): Multimodal Interfaces: A Survey of Principles, Models and Frameworks. In: Human Machine

Dabei lässt sich das, was hier am Beispiel der Fahrzeug-Konfiguration dekliniert wurde, mühelos auf andere sprachgesteuerte Angebote übertragen und als beschränkende Bedingungen für die Usecase-Definition von Sprachsteuerung

5. Schaffer, S. (2008): Integration

Interaction, Heidelberg: Springer-Verlag Berlin, S. 3–26. 4. Larson, J.A. und Oviatt, S. (2004): Guidelines for Multimodal User Interface Design. In: Communications Of The ACM, Vol. 47, No.1, S.57–59.

hin über das GUI abgebildet.


Usability Professionals 2013 Spezielle Designanforderungen

231


„Ich würde jetzt anrufen.“ – Webshops aus Sicht älterer Nutzer Cornelia Schauber YOUSE GmbH Anzinger Straße 4 81671 München cornelia.schauber@youse.de

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

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

Tina Weisser YOUSE GmbH Anzinger Straße 4 81671 München weisser@feed-your-mind.org

Abstract Der demografische Wandel bringt es mit sich, dass Nutzer jenseits der 50 eine immer größere wirtschaftliche Rolle spielen und die größten Zuwachsraten im Bereich der neuen Medien aufweisen. Bei Webseiten-Tests ist diese Konsumentengruppe allerdings eher spärlich vertreten. In diesem Beitrag wird anhand eines Usability-Tests mit TicketProvidern gezeigt, worin die Unterschiede zwischen jüngeren und älteren InternetNutzern bestehen und wie die Generation 50plus als Tester sinnvoll in Usability-Tests berücksichtigt werden kann. Usability Experten erhalten konkrete Tipps, wie Webseiten für mehrere Generationen nutzerfreundlich gestaltet werden können, und worauf beim Arbeiten mit älteren Testern zu achten ist.

1. Warum die Generation 50plus so wichtig ist Bei der Gestaltung oder Evaluation von Webseiten wird meist mit derselben Ziel­­gruppe gearbeitet, die auch beim Marke­ting im Vordergrund steht: den 14- bis 49-Jährigen. Die Generation der über-50-Jährigen wird dabei in der Regel ignoriert: sei es, dass Unternehmen Be­rührungsängste haben und ungern mit dieser Nutzergruppe in Verbindung gebracht werden möchten, sei es, dass spontane Gestaltungs-Assoziationen wie große Schrift und reduziertes Design als unattraktiv gewertet werden, oder weil man dieser Nutzergruppe unterstellt, ohnehin am liebsten im Geschäft oder telefonisch Kontakt aufzunehmen – ein Fehler ist es in jedem Fall. Die statistischen Entwicklungen zeigen zweifelsfrei, dass die Generation 50plus in nicht einmal 10 Jahren in den meisten entwickelten Märkten der Erde die Hälfte der Bevölkerung (und damit der Konsumenten)

232

ausmachen wird. Und noch zwei weitere Fakten sind für Unternehmen (und damit auch für Usability Experten) von hoher Bedeutung: 1. Die Generation 50plus verfügt bereits heute über 47% der Kaufkraft in Deutschland (GFK Geo-Marketing, 2013) und sollte daher sowohl beim Marketing als auch bei der Ausgestaltung von Produkten und Services schon aufgrund wirtschaftlicher Interessen stärker berücksichtigt werden. Sehr wichtig ist dabei, auf die Besonderheiten dieser Zielgruppe Rücksicht zu nehmen, ohne jedoch Defizite in den Vordergrund zu stellen. 2. Die Generation 50plus ist laut einer aktuellen Studie von TNS Infratest (2013) die Bevölkerungsgruppe mit den größten Zuwachsraten bei der InternetNutzung (über 3% gegenüber dem Vorjahr). Rund 76% der 50–59-Jährigen und etwa 60% der 60–69-Jährigen sind inzwischen in Deutschland online. Dies liegt nicht nur an der allgemeinen Alterung der Gesellschaft (sprich einem Kohorteneffekt), sondern auch daran,

Christian Wedl YOUSE GmbH Anzinger Straße 4 81671 München christian.wedl@youse.de

Keywords: /// Generation 50plus /// Digital Natives /// Webshops /// Usability-Test

dass immer mehr ältere Nutzer das Internet erst spät für sich entdecken und dann als Novizen versuchen, ihre Bedürfnisse nach Information und Teilhabe damit zu befriedigen. Gerade die Personen, die sich erst nach dem Ausscheiden aus dem Arbeitsleben zum ersten Mal mit dem Internet befassen, müssen sich die Benutzung oft mühsam selbst beibringen und sind daher auf eine möglichst intuitive Gestaltung angewiesen. Für validere Ergebnisse wäre es daher zielführend, bei der Evaluation von Webseiten auch ältere Nutzer mit einzubeziehen. YOUSE befasst sich seit mehreren Jahren intensiv mit der Generation 50plus als Zielgruppe und möchte die Community der Usability Experten dazu ermuntern, das eigene Bewusstsein – und auch das der Auftraggeber – für die Belange der sogenannten „Silver Surfer“ zu schärfen. Eine ganze Bevölkerungsgruppe ist dabei, das Internet zu erobern, und es ist unsere Aufgabe, sie beim Webdesign entsprechend zu berücksichtigen.


Usability Professionals 2013 Spezielle Designanforderungen

Auch wenn es sehr starke individuelle Unterschiede gibt (Gregor et al., 2002), so lässt sich die Generation 50plus doch in zweierlei Hinsicht als besondere Nutzergruppe beschreiben: in Bezug auf ihre InternetExpertise und in Bezug auf physiologische bzw. mentale Alterserscheinungen. Was die Internet-Expertise betrifft, so verfügen die Über-50-Jährigen im Vergleich zu jüngeren Webnutzern über weniger Routine. Insbesondere denen, die erst im Ruhestand mit der Webnutzung starten, fehlen Ansprechpartner wie z.B. Arbeitskollegen, mit deren Hilfe Hürden schnell gelöst und praktisches Wissen erworben werden können. Unsere älteren Tester berichten auch, dass sie die Ungeduld der Angehörigen, die sie um Hilfe bitten, als unangenehm empfinden, und deshalb lieber selbst versuchen Probleme zu lösen – was nicht selten scheitert. Dies hängt damit zusammen, dass ihr mentales Modell von der Funktionsweise von Webseiten oder deren allgemeiner Grundstruktur unzureichend oder fehlerhaft ist, was wir auch in unserer Studie anhand der ineffektiven Problemlösestrategien aufzeigen. Auf der anderen Seite treten auch bei routinierten Internet-Nutzern im Laufe der Zeit bestimmte altersbedingte Veränderungen auf (Meyer et al, 1997; Rabbit, 2002; Smith et al., 1999; Zajicek, 2001), die zwar nicht dramatisch sein müssen, aber dennoch einen Einfluss auf die Bedienfreundlichkeit von Webseiten haben können: –– Die Gedächtnisspanne wird kleiner, so dass sich ältere Anwender z.B. schlechter an bereits besuchte Seiten erinnern. –– Die kognitiven Ressourcen sind schneller erschöpft, so dass das explorative Erlernen von neuen Programmen oder Befehlen schwieriger wird. –– Die Vulnerabilität gegenüber ablenkenden Reizen nimmt zu, so dass die Darbietung vieler Informationen oder Animationen leicht eine Überforderung darstellt. –– Die Sehkraft wird schlechter, so dass die Option einer individuellen Größenanpassung sehr hilfreich sein kann, sowie die Verwendung klarer Kontraste. –– Die Feinmotorik wird mühsamer und weniger präzise, so dass z.B. Doppelklicks oder das präzise Ansteuern kleiner Buttons erschwert wird.

Abb. 1. Anteil der Personen, die online Tickets für Theater, Kino oder andere Veranstaltungen kaufen, nach Altersgruppen in Deutschland (AGOF Internet Facts, 2013).

Abb. 2. Freiburg-Ticket wurde von beiden Testergruppen sehr positiv bewertet, aufgrund der guten Übersichtlichkeit und der Positionierung wichtiger Inhalte oben auf der Seite.

Um es mit Bernard und Phillips (2000) zu sagen, ist unsere „information society“ gleichzeitig auch eine „ageing society“. Diesem Umstand wird unserer Ansicht nach – auch in der Usability-Branche – noch zu wenig Rechnung getragen. Wel­che Konsequenzen das hat, wird im folgenden Abschnitt anhand eines Usability-Tests mit Webshops beschrieben.

2. Usability-Studie: Unterschiede zwischen älteren und jüngeren Webshop-Nutzern Auch wenn man bei manchen Webseiten argumentieren könnte, dass die Zielgruppe eindeutig jünger als 50 Jahre ist – für Ticketportale gilt dies sicher nicht. Aktuelle Zahlen zur Nutzung von Online-Portalen

233


für den Ticketkauf zeigen, dass Menschen über 50 nicht nur regelmäßige Konzertbesucher sind, sondern die Tickets auch zunehmend online erwerben. [Abb. 1] Daher ist die Frage berechtigt, ob solche Ticketportale für alle Altersgruppen von Nutzern gleichermaßen bedienbar sind, oder ob sich zwischen jüngeren und älteren Nutzern Unterschiede zeigen. Zum anderen ist es für Usability Experten interessant zu wissen, ob in einem UsabilityTest mit älteren Nutzern dieselbe Menge und dieselbe Art von Webseiten-Schwächen aufgedeckt werden wie von jüngeren Nutzern. Diesen beiden Fragen wollten wir mit der im Folgenden beschriebenen Studie nachgehen. 2.1. Studiendesign

Abb. 3. Berlin-Ticket kam besonders bei den älteren Nutzern gut an, die jüngeren Tester fanden die Seite etwas langweilig, wenngleich immer noch besser als München-Ticket.

Getestet wurden drei Ticketanbieter [Abb. 2], [Abb. 3], [Abb. 4] aus Freiburg (www.freiburg-ticket.de), Berlin (www. berlin-ticket.de) und München (www. muenchen-ticket.de). Für jeden Webshop wurden insgesamt drei Use Cases durchlaufen: – der Kauf eines frei einlösbaren Gutscheins in Höhe von 50 EUR – die Auswahl einer Klassikveranstaltung für ein bestimmtes Wochenende im August und der Kauf zweier Tickets mit möglichst mittigen Plätzen – die Suche nach einer Vorverkaufsstelle in der Nähe einer vorgegebenen Adresse Die Stichprobe umfasste neun jüngere Personen im Alter von 17–25 Jahren (MW 22,1) und neun ältere Personen im Alter von 56–82 Jahren (MW 69,1). Die Tests wurden teils bei den Testpersonen zuhause, teils in den Räumlichkeiten der YOUSE GmbH durchgeführt. Arbeitsgerät war in allen Fällen ein Laptop der YOUSE GmbH und je nach Wunsch bzw. Gewohnheit zusätzlich eine Maus und/oder ein Keyboard.

Abb. 3. München-Ticket wurde von beiden Nutzergruppen als zu voll und zu unübersichtlich bewertet.

234

Bildschirm und Ton wurden während des Tests aufgezeichnet und nachträglich bezüglich Anzahl der Aktionen (Klicks, Scrollen, Zoomen, Eingaben) sowie Art und Häufigkeit von Bedienproblemen


Usability Professionals 2013 Spezielle Designanforderungen

ausgewertet. Der Fokus lag einerseits auf Performanzwerten wie der Anzahl der gelösten Use Cases (Abstufung je nach Qualität des Ergebnisses 0.0, 0.5 oder 1), zum anderen auf qualitativen Aspekten des Vorgehens der beiden Testergruppen. Zu Beginn wurden in einem Übungsdurchgang (Wetter der nächsten drei Tage heraussuchen) der Umgang mit dem Browser (Safari) und die Methode des lauten Denkens eingeübt. Die Reihenfolge der Anbieter und der Use Cases wurde von Person zu Person variiert, um Einflüsse oder Lerneffekte durch bereits durchlaufene Use Cases auszubalancieren. Am Ende jedes Use Case wurde die Testperson gebeten eine subjektive Einschätzung der Schwierigkeit (1–7) und des empfundenen Ärgers (1–7) abzugeben. Nach dem Test nahm der Testleiter eine Wertung des Vorgehens der Person vor (z.B. geduldig-ungeduldig, Häufigkeit selbstkritischer Äußerungen), in Anlehnung an eine Webstudie von Pernice, Estes & Nielsen (2013). 2.2. Ergebnisse Zunächst einmal lässt sich feststellen, dass die schwerwiegendsten Usability-Probleme, auf die die Tester bei der Durchführung der Use Cases stießen, in beiden Nutzergruppen gleichermaßen auftraten: –– Rigide Suchmaschinen: Eine Suche war meist nur nach Veranstaltungen möglich, nicht nach Inhalten wie z.B. Gutscheinen. Dies war besonders bei der Freiburger Seite sehr problematisch, weil hier tatsächlich als „Veranstaltung“ Gutscheine für eine bestimmte Veranstaltung namens „Freistil“ angeboten wurden, was zu großer Verwirrung führte. –– Missverständliche Kategorien: Häufig wurde auf den Menüpunkt „Weiteres“ geklickt, um zu Service-Inhalten wie Vorverkaufsstellen zu gelangen. Tatsächlich fanden sich dort nur weitere Veranstaltungen. –– Missverständliche Action-Buttons wie z.B. „Weiter: Plätze aus Saalplan buchen“ wenn Plätze schon ausgewählt waren.

–– Klicken von nicht-klickbaren Elementen wie Symbolen, farbigen Markierungen oder Überschriften. –– Zu kleine/ungünstige Darstellung von Saalplänen, so dass die Auswahl von Plätzen Probleme bereitete. –– Öffnen neuer Tabs, so dass der ZurückButton im Browser nicht funktionierte. –– Das fälschliche Anklicken der Betreiber-Logos, um zu Service-Inhalten zu gelangen, was in Wirklichkeit zur Homepage führte bzw. zu Irritationen, wenn diese Seite bereits geöffnet war und vermeintlich nichts passierte. –– Das Nichtbeachten des Veranstaltungsorts, weil aufgrund des Webseiten-Betreibers automatisch davon ausgegangen wurde, dass nur Veranstaltungen aus der entsprechenden Stadt angeboten werden. Daher wurden vereinzelt Konzerte in Wedel, Basel oder Augsburg gebucht. –– Fehlende Filtermöglichkeit von Ergebnislisten, z.B. nach Ort oder Datum. Das bedeutet, dass eine Optimierung der Webseite anhand der Angaben von jüngeren oder älteren Nutzern gleichermaßen möglich ist und im Allgemeinen zu sehr ähnlichen Ergebnissen führt. Aber auch was die persönlichen Vorlieben anging, waren sich die beiden Generationen erstaunlich einig: Die Münchner Webseite [Abb. 4] wurde durchgängig als

zu unübersichtlich wahrgenommen und landete bei beiden Nutzergruppen auf dem letzten Platz. Dagegen empfanden die Tester den Ticketshop aus Freiburg [Abb. 2] als gute Mischung aus Bildern und Übersichtlichkeit, so dass er bei den jüngeren Testern eindeutig auf Platz 1 landete und sich diesen bei den älteren Testern mit der Berliner Seite [Abb. 3] teilen muss. Allerdings zeigte sich sehr deutlich, dass die jüngeren Nutzer mit auftretenden Bedienproblemen besser umgehen konnten und (zielführende) Alternativlösungen fanden, während die älteren Nutzer leichter aus dem Konzept kamen und sich in diversen Untermenüs oder irrelevanten Suchergebnissen verloren. Entsprechend dauerten die Usability-Tests mit den jüngeren Nutzern im Schnitt etwa 45 Minuten, mit den älteren Testern dagegen etwa 1,5 Stunden. Tabelle 1 zeigt eine Gegenüberstellung der beiden Nutzergruppen. Sehr deutlich zeigt sich die geringere Zahl der gelösten Use Cases (4 vs. 8,5) und die höhere Anzahl an Aktionen bzw. Klicks während der Tests, was die schlechtere Effizienz ihres Vorgehens verdeutlicht. Anders gesagt stellen Bedienschwächen der Webseiten für jüngere Nutzer einen eher leichten Fehler dar, der mit eigenen Mitteln meistens umgangen werden kann, wohingegen sie für ältere Nutzer einen schweren Fehler bedeuten, der die Zielerreichung in mehr als der Hälfte der Fälle tatsächlich verhindert. [Tab. 1]

Kennwerte

Teenager/Twens Generation 55plus Median (N=9) Median (N=9)

Alter (Range)

23 Jahre (17–25)

69 Jahre (56–82)

Computer-Nutzung pro Woche 30 Std.

10 Std.

Internet-Nutzung pro Woche

17 Std.

5 Std.

Gelöste Use Cases (max. 9)

8,0

4,3

Aktionen gesamt (ideal: 53)

121

135

Klicks gesamt (ideal: 29)

53