Usability Professionals 2013 - Tagungsband by German UPA e.V.

2013 Usability Professionals German UPA e.â&#x20AC;&#x2030;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

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

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 Softwarespezifi 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

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

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

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 Grundlagen 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

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.

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

Workshops

Papierlose Fahrgastinformation im ÖPNV: Die Vision einer Haltestelle der Zukunft Konzeption neuer digitaler und interaktiver Informationssysteme 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

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 Informationssysteme für Fahrgäste und Verkehrsbetriebe? –– Wie sehen die gängigsten Nutzungsszenarien im Umgang mit Papieraushä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 wertvolle 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-Systems im nächsten Schritt im Rahmen eines P ilottests an einer ausgewählten Haltestelle erstmals alle Fahrgastinformationen in Papierform komplett ersetzen, um weitere 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

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

Usability Professionals 2013 Workshop

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 Projekt 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 – neben dem Abliefern von qualitativ hochwertigen 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 Abschlussbericht sind wichtige Bestandteile in der Umsetzung dieses Anspruchs (siehe Tomer, 2012). Diese Vorgehensweise erhöht die von den Mitgliedern des Projektteams

wahrgenommene 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 besseren 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 werden. Hinzu kommt die Ernüchterung über den Umstand, dass das aufgezeigte Verbesserungspotential 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 Ergebnisse, die durch die aktive Teilnahme der Projektteams zu Beginn des Tests entstanden ist, bereits bei der Ergebnispräsentation 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 Produkte 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 Vorteile des Game Designs geboten, wie beispielsweise klare Zielsetzung und transparente Feedback-Mechanismen; auch werden soziale 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 überhaupt 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 beleuchtet; 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 Umgehung 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.

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 Interface 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 Usabi 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;

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 vielfäl tigen Ansatzpunkte, wo durch die Anwen dung von Spielkonzepten Inspiration für Verbesserungen 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 spielerisch 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 jedoch 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 umgekehrt vorgehen, um gezielt eine Spielerfahrung 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 zifische 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 Projekt erfahren, dass dieser Ansatz nur bedingt vollständig umgesetzt werden kann. So haben wir die Idee, die emotionale 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 sichergestellt ist, dass dies die Zielgruppe ansprechen könnte; auch liefert die Analogie viele Inspirationen 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 Methoden um eine Spielkomponente erweitern 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 freundschaftlichen 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

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.

Usability Professionals 2013 Workshop

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,

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?

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 Industrieunternehmen – 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 Abgrenzung 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

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 Handlungsfeld

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 Zusammenspiel der Bereiche sehen kann und die genügend Macht für organisationale Veränderungen hat.

Literatur 1. Bundesministerium für Wirtschaft und Technologie (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 Unternehmen ü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 Handlungsempfehlungen für die Gestaltung von Veränderungsprozessen (mit CD-ROM, 2. Nachdruck). Wiesbaden: Deutscher Universitäts-Verlag.

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

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

„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 wesentlich 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 betriebswirtschaftlicher Ziele wie die Steigerung von Produktivität,

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 Herausforderungen – bestätigt durch eine Studie im Auftrag 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 „Professionalisierungs-Gap“ sowie eines „Lehre- und Forschung-Gap“. Diese bestehen darin, dass die Ausbildung zum Thema Gebrauchstauglichkeit 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 Berufsbildes, 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. Insbesondere auch praktische Fertigkeiten sowie personale und soziale Aspekte, bspw. empathische Kommunikation oder Perspektivenübernahme, sind von Relevanz. Um einen ersten Schritt in Richtung Zertifizierung 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 Standards zu vereinfachen, so dass Produkt- und Prozessverantwortliche unterschiedlicher Herkunft den Entwicklungsprozess verstehen, 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 Gestaltungsprozesses. 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 Software) herleitet, umsetzt oder deren Umsetzung ü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 Nutzungskontext 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.

–– 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 weiterführende Prüfungen („Advanced Level“ und „Expert Level“)

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“

3.2. Curriculum CPUX-F Das Curriculum (Lehrplan) umfasst alle Themen und Konzepte, auf welche die Prüfungsfragen Bezug nehmen. Es ist in Unterrichtseinheiten strukturiert, die jedoch 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.

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)

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).

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

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 Bereiches 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.

Der Workshop soll zur Gründung neuer Netz werke im User Research Bereich anregen. 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.

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 entstehen, das über 30–40 Seiten darüber informiert wie sich Usability Engineering in bestehende 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

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 Entwicklung von Medizintechnik beachten müssen. Wichtigste Botschaft ist hierbei, dass Usability 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.

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

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)

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.

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 Benutzerfreundlich 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.

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

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

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

Tab. 1. Bewertungsskala

bei der Beschreibung des Prozesses die gleichen Begrifflichkeiten verwenden.

Missverständnisse beim Gebrauch bestim 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

Tutorials

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

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.

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.

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

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 Spezifikation von Anforderungen ist häufig die zentrale Grundlage erfolgreicher Softwareentwicklungsprojekte. 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

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

Abb. 1. Die integrierte Modellierungsumgebung YAKINDU Requirements.

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.

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: UseCaseModellierung 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: UserInterfaceModellierung 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

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

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

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.

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.

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 Standardabweich 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 Lognormalverteilungen 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 plexitä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, Bearbeitungszeiten 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 frieden 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 Versagen 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 besteht 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]

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.

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

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. WeibullVerteilung 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

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)

Da diese Linearität das entscheidende Kriterium ist, können die vertikale und horizontale Achsenzuordnung zur leich teren Interpretierbarkeit frei so gewä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

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

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

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.

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 Auswahl und das Priorisieren von Ideen in einem UX-getriebenen Innovationsprozess 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

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

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.

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.

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 insbesondere 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

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.

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 sozialen 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 relevant 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 betriebswirtschaftlichen 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

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.

uninteressant

interessant

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

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.

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

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

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 risieren. Kapitel 3 diskutiert die Validität von Prototypen beziehungsweise die Frage, über welche Eigenschaften Prototypen verfügen müssen, um valide Ergebnisse beim Einsatz in Evaluationsstudien zu gewährleisten. Der Beitrag schließt mit einem Ausblick auf zukünftige Forschungsfragen.

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 Entwicklungsprozesses 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

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.

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

(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).

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.

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.

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

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].

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]

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].

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.

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

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-

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

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

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

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]

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

Inhouse und Zulieferer Kooperation

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

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/)

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 Beantwortung 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 nehmer 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 angehen 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 Missinterpretationen. –– 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 überspringt 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 Problemstellungen 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

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 Inhaltsbereich der Webseite nach links oder rechts nahezu vollständig aus dem sichtbaren 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 Gesamteindruck 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 Spezifizie rungsdokumente mit den in der Design phase erstellten HTML-Prototypen anzu reichern, um so den Entwicklern die Möglichkeit 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 prozessen 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 erwä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 Responsive Design? Erstellt man ein Konzept, drei oder mehr Konzepte? Sind die Inhalte von mobile.de (kom plexe Formulare und Ergebnislisten) ü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 hingegen markierte den Zeitraum der eigentlichen technischen Umsetzung in agilen Entwicklungsteams. Für die sinnvolle Koordination 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 Sprintdauer) zu verinnerlichen und sich darin einzufü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 thematischer 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 deutete 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 Marketingstra 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 proto typischen Vorgehensweise ein exzellentes Beispiel für einen standardisierten Entwicklungsprozess dar, der sowohl Usability-Gesichtspunkte, nutzerspezifische Anforderungen sowie technische und normative 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 Kundenfreundlichkeit aller Elemente im Gesamtsystem 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“ kontextspe zifisch zur Evaluation und Präsentation 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 nologiebasierte 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 Abschluss

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 Analyse 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öchte, 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/ HilfeMenü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 unterstützen, wurde im Deutschen Forschungszentrum für Künstliche Intelligenz Kaiserslautern 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 Produktionsleittechnik 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-, aufgabenund 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 Produktdatenmanagement 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 Konfigurierbarkeit 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 beschrieben 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-, aufgabenund 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 aufgabenund 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 projektbezogen ist. Der „Landepunkt“ innerhalb der Ziel-Anwen dung sollte möglichst korrespondierend 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 bestehenden PC-Anwendung zur ersten internationalen Multi-Devicefähigen Web-Anwendung im Photovoltaik-Bereich. –– Optimierung des Time-to-ResultFaktors mit Halbierung der Benutzungszeiten bei einer Anlagen auslegung mit gleichem Konfigurationsraum und Einstellungsmö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. UseCaseDefinition: „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. ExpertenEvaluation: „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 Unterstützung durch generierte Diagramme 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 Software 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 situationsund 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 Nutzungssituation 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 Anwendungen, 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 Anwendung zentrale Nutzungs- und Erfolgsfaktoren 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 Schnittstelle 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 FeldTest 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 kombiniert 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äufigkeit, 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 entwicklung innerhalb der Lean Startup Methode benötigt also vor allem sehr schlanke und direkte User Experience Research 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, generischer 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 Grundlage 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 wiederum 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 funktionale 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 Arbeitsaufgaben 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 KanbanBoards 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 Sprachsteuerung. 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 Zielgruppe gearbeitet, die auch beim Marketing 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 Berü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. Welche 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)

Bedienprobleme gesamt

Subjektiv: Schwierigkeit (1–7)

3,4

4,2

Subjektiv: Ärger (1–7)

2,2

3,9

Confidence-Score (1–10)

Tab. 1. Ergebnisse der Usability-Tests mit OnlineTicketshops für jüngere und ältere Nutzer.

235

Eine qualitative Analyse der Testaufzeichnungen ergab folgende typische Charakteristika im Vorgehen älterer Nutzer, durch die sie sich von jüngeren unterscheiden: –– Probleme beim Lösen der Aufgaben wurden meist auf das eigene Unvermögen zurückgeführt, so dass die Webseiten trotz vieler Bedienprobleme eher gutmütig bewertet wurden. Zitat Tester: „Ich ärgere mich nicht so schnell, weil ich weiß in dem Fall gehört eigene Dusseligkeit dazu.“ –– Mehrere ältere Nutzer in unserer Studie verloren sich häufig in einer Art Endlosschleife, d.h. sie pendelten auf der Suche nach einer Lösung zwischen zwei oder drei Seiten immer wieder hin und her, ohne es zu merken. Dies zeigt deutlich, dass sie sich nicht gut merken konnten, welche Seiten sie schon besucht hatten. –– Anstatt neue Wege auszuprobieren, wiederholten ältere Tester mehrmals dieselbe Prozedur, in der Annahme, dass es sich um den richtigen Lösungsweg handeln musste und sie möglicherweise eine falsche Eingabe gemacht hatten. Insgesamt konnten sie sich innerhalb der Webseite bzw. zwischen mehreren Tabs deutlich schlechter orientieren als die jüngeren Tester. –– Im Gegensatz zu den jüngeren Testern klickten sich die Älteren Seite für Seite durch die Trefferliste und kamen entweder spät (etwa ab Seite 4) oder überhaupt nicht auf die Idee, Seiten zu überspringen um schneller zum gewünschten Datum zu gelangen. –– Die Generation 50plus war nicht so geübt in der effektiven Nutzung von Suchfeldern. Oft wurden sehr umständliche Suchbegriffe inklusive Sonderzeichen eingegeben (siehe Beispiele aus den Videoaufzeichnungen in [Abb. 5]). Führte die Suche zu keinem Ergebnis, wurde entweder davon ausgegangen, dass es das entsprechende Produkt nicht gibt, oder der Suchbegriff wurde noch weiter ausformuliert um das Suchergebnis vermeintlich zu verbessern („Gutschein“ > „Gutschein frei verwendbar“). Dies ist besonders tragisch, weil gerade die älteren Nutzer oft und von Anfang an mit Suchfeldern

236

Abb. 5. Beispiele für Eingaben älterer Tester in die Suchfelder der Webshops

und seltener mit vorgegebenen Kate gorien wie „Kontakt“ oder „FAQ“ arbeiteten. –– Die älteren Nutzer klickten bei der Anzeige der Suchergebnisse oft unwissentlich auf Anzeigen anstatt auf der Webseite zugehörige Links. Einige Tester landeten so am Ende auf den Seiten anderer Anbieter und wählten dort z.B. eine Vorverkaufsstelle aus, was im tatsächlichen Anwendungsfall für den Shop-Betreiber einen wirtschaftlichen Verlust bedeutet hätte. –– Bei der Generation 50plus führten Bedienprobleme nicht nur zu Ärger und Frustration, sondern in vielen Fällen dazu, dass der Use Case nicht gelöst und damit z.B. ein Online-Kauf nicht abgeschlossen werden konnte. Die älteren Tester gaben sehr häufig an, in diesen Fällen die Service-Hotline zu kontaktieren. Umgekehrt würde also eine Verbesserung der Webseite gerade im Hinblick auf die Belange der Generation 50plus die HotlineMitarbeiter deutlich entlasten. 3. Fazit: Die Generation 50plus einbinden Die Generation 50plus sollte von Usability Experten stärker als potenzielle Nutzergruppe wahrgenommen werden. Einerseits stellt sie in nicht allzu ferner Zukunft die größte, zahlkräftige Kundengruppe, andererseits ist sie als Extremgruppe besonders sensibel für bestimmte Usability-Fehler, die rechtzeitig behoben werden sollten, wovon auch jüngere Nutzer profitieren. Übersetzt man die Usability-Ergebnisse in Geschäftsdaten, so lässt sich daraus schließen, dass sich mit der Generation 50plus bei einer Verbesserung der Webseite ein doppelt so hoher Umsatz erwirtschaften

ließe (legt man die Erfolgsrate zugrunde) bzw. Service-Hotlines deutlich entlastet werden könnten. 3.1. Design-Tipps für generationen übergreifende Webshops Folgende konkrete Gestaltungshinweise lassen sich aus unserer Studie ableiten, die besonders für ältere Nutzer eine enorme Verbesserung eines Webshops darstellen: –– Die Suchmaschinen sollten möglichst „breit“ suchen und mit Sonderzeichen umgehen können (auf diesen Umstand weisen übrigens schon Hassenzahl & Prümper in einem Artikel aus dem Jahr 1999 hin!). Gleichzeitig sollte stets eine intelligente Filtermöglichkeit für Suchergebnisse vorhanden sein, damit die Nutzer möglichst schnell eine passende Auswahl treffen können. –– Die Menge der dargebotenen Reize sollte – trotz Marketing-Ambitionen – in einem überschaubaren Rahmen bleiben. Auch jüngere Nutzer werden sonst von der Informationsflut überfordert und finden buchstäblich den Wald vor lauter Bäumen nicht mehr. –– Schon besuchte Seiten sollten unbedingt kenntlich gemacht werden, um zirkuläres Vorgehen zu vermeiden. Dies schließt auch Menüpunkte mit ein. –– Links sollten konstant gestaltet und deutlich erkennbar sein – klingt altmodisch, ist aber immer noch aktuell und erspart dem Nutzer unnötige Frustration oder Verwirrung. –– Aktions-Buttons können eigentlich gar nicht groß genug sein, und sollten möglichst kurz und eindeutig beschriftet sein. Handlungsbeschreibungen („Kaufen“) in Kombination mit Symbolen („Einkaufswagen“) helfen gerade

Usability Professionals 2013 Spezielle Designanforderungen

älteren Nutzern mit weniger Routine, sich spontan zurecht zu finden. –– Keine neuen Tabs öffnen – auch ältere Nutzer navigieren lieber mit dem Zurück-Button des Browsers. –– Und für alle Fälle: Immer gut sichtbar eine Telefonnummer und/oder EmailAdresse für Rückfragen anzeigen. Interessierte finden zum Beispiel in Pernice et al. (2013) eine ergänzende Auflistung von Charakteristika seniorenfreundlicher Webseiten. 3.2. Tipps zum Umgang mit Testern der Generation 50plus Wenn Sie sich als Usability Experten dazu entschließen, zukünftig in Ihrer Stichprobe auch ältere Nutzer mit einzubinden, sollten Sie aus unserer Erfahrung folgende Punkte beachten: –– Für Terminabsprachen ist bei älteren Nutzern (auch wenn sie im Ruhestand sind) oft viel Vorlauf notwendig, da Senioren – entgegen der landläufigen Meinung – sehr beschäftigt sind und häufig auch nur 1–2 Termine pro Tag wahrnehmen möchten. Optimal sind 3 Wochen. –– Bei der Aufgabenauswahl sollte man sich nicht von Klischees leiten lassen. Die Auswahl von Klassik-Konzerten in unserer Studie stieß bei einigen älteren Testern auf großen Widerstand, da sie sich lieber etwas Lustiges oder Modernes ausgesucht hätten (Alicia Keys oder Michael Mittermeier waren durchaus ein Begriff). –– Planen Sie mehr Zeit für die Tests ein als bei jüngeren Nutzern: zum einen, weil die Durchführung an sich länger dauert (je nach persönlicher Expertise bis zu doppelt so lang), und zum anderen, weil ältere Tester ein kleines „Schwätzchen“ zu schätzen wissen. –– Bei Labortests sollten Sie versuchen, den normalen Arbeitsplatz älterer Nutzer so gut wie möglich nachzubilden (Laptop, Tastatur, Maus, Browser), um keine zusätzlichen Fehler zu produzieren, die durch das ungewohnte Arbeitsumfeld entstehen. Bei Tests

zuhause können darüber hinaus sehr interessante Einblicke gewonnen werden, z.B. ob jemand Tasten zusätzlich beschriftet oder Vorgehensbeschreibungen zur Benutzung von Programmen verwendet. –– Tests sollten nicht zu lang dauern (maximal 1 Std.), weil die Konzentration sonst merklich nachlässt. Im Verlauf unseres Tests kam es häufiger vor, dass die Arbeitsaufgaben vermischt wurden, (z.B. Suchen nach einer Vorverkaufsstelle anstatt eines Gutscheins). –– Wegen des geringeren Selbstbewusstseins in Sachen Internet-Expertise ist es besonders wichtig darauf hinzuweisen, dass die Webseite getestet wird und nicht der Tester. –– Ältere Tester freuen sich am Ende des Tests über kleine Tipps zur besseren Benutzung. –– Das bevorzugte Incentive kommt auf die Person an: Manche unserer älteren Tester bessern sich mit den Studien ihre Rente auf und freuen sich daher über eine finanzielle Vergütung. Die Mehrheit treibt aber eher das Interesse und die Motivation, bei Neuentwicklungen dabei zu sein. Für letztere Gruppe sind daher nett gestaltete, „persönliche“ Incentives (liebevoll verpacktes Obst, eine Einladung für eine gemeinsame Veranstaltung etc.) als Anerkennung für die Zeit und die Rückmeldung besser geeignet als Geld.

Software-Ergonomie ‚99: Design von Informationswelten. Stuttgart: B.G.Teubner (S. 112–121). 4. Meyer, B., Sit, R.A., Spaulding, V.A., Mead, S.E., Walker, N (1997). Age Group Differences in World Wide Web Navigation. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems (CHI ’97) (Atlanta, GA, USA, March 1997), ACM Press, New York, NY (pp. 295–296). 5. Pernice, K., Estes, J., und Nielsen, J. (2013). Senior Citizens (Ages 65 and older) on the Web (2nd Edition). Fremond: Nielsen Norman Group. 6. Rabbitt, P. (1999). When age is in, the wit is out?, In: Sala, S. (Ed.), Mind Myths: Exploring Popular Assumptions about the Mind and Brain, Chapter 11, Wiley (pp. 165–186). 7. Smith, M.W., Sharit, J., and Czaja, S.J. (1999). Aging, motor control, and the performance of computer mouse tasks. Hum Factors, 41(3), pp. 389–96. 8. Zajicek M. (2001). Special interface requirements for older adults. Proceedings of the WUAUC’01, 2001 EC/NSF Workshop on Universal Accessibility of Ubiquitous Computing: Providing for the Elderly (Alcácer do Sal, Portugal, May 22 – 25

Literatur 1. Bernard, M. and Phillips, J. (2000.) The challenge of ageing in tomorrow’s Britain. Ageing and Society, 20, pp. 33–54. 2. Gregor, P., Newell, A.F. and Zajicek, M. (2002). Designing for dynamic diversity – interfaces for older people. Proceedings of the 5th International ACM SIGCAPH Conference on Assistive Technologies (ASSETS 2002) (Edinburgh, Scotland, July 8–10, 2002). ACM Press, New York, NY, USA, (pp. 151–156). 3. Hassenzahl, M. & Prümper, J. (1999). Benutzererwartung eingebaut: Gestaltungsempfehlungen für Suchfunktionen auf Basis einer empirischen Benutzerbefragung. In: Arend, U., Eberleh, E. & Pitschke, K. (Hrsg.),

237

238

Enterprise/ Government UX

239

„Pimp my GUI – Kosmetik allein genügt nicht“ Herausforderungen bei der Modernisierung einer Bedienoberfläche von Unternehmenssoftware Reiner Schlenker Freiberuflicher Usabilityberater Kirchstraße 43 79100 Freiburg im Breisgau reiner.schlenker@der-menschliche-faktor.com

Frank Patz-Brockmann Contact Software GmbH Wiener Straße 1–3 28359 Bremen fp@contact.de

Abstract Unternehmenssoftware ist eine langfristige Investition und wird nicht einfach mal eben ausgetauscht. Viele etablierte Systeme sind älter als 10 oder sogar 20 Jahre, die grafische Bedienoberfläche (GUI) ist häufig in die Jahre gekommen. Die Anbieter sehen sich heute vor die Herausforderung gestellt, dass sie diesen Teil der Software generell modernisieren müssen, um am Markt erfolgreich zu sein. Ein reines Facelifting reicht dazu nicht mehr aus. Die Anwender verlangen nach modernen ergonomischen Oberflächen, die sie aus ihrem privaten Umfeld kennen. Sie möchten die Software oder Teile davon auch in ihren mobilen Endgeräten einsetzen. Zunehmend halten Elemente aus Social MediaAnwendungen Einzug in Business-Applikationen. Tablets sind in Unternehmen in vielen Bereichen im Einsatz. Eine Modernisierung der Bedienoberfläche bringt oft tiefe Eingriffe in die Architektur mit sich. Prozesse und Methoden müssen von einem systemzentrierten auf ein benutzerzentriertes Vorgehen angepasst werden. Dabei sollen Release-Zyklen und bestehende Installationen nicht gefährdet werden. Unser Beitrag beschreibt ein Usability-Projekt in diesem Spannungsfeld.

Einleitung „To the user the interface is the application“ Alan Kay Bei der Entwicklung von Unternehmenssoftware stand früher die Robustheit und Verfügbarkeit der Anwendung im Vordergrund. Viele Systeme entstanden in einem technikorientierten Umfeld, in dem die gestalterischen Möglichkeiten begrenzt waren und die Bedienoberfläche eine eher untergeordnete Rolle im Entwicklungsprozess hatte. Mit diesem Ansatz wird es in der heutigen Zeit immer schwieriger, am Markt zu bestehen. Die Ansprüche der Anwender an die Bedienbarkeit sind stark gestiegen, nicht zuletzt mit dem zunehmenden Einsatz mobiler Endgeräte in der Arbeitswelt. Um diesen Herausforderungen zu begegnen, investieren die Hersteller zunehmend in die Themen Usability und User Experience (UX). Die Modernisierung der Bedienoberfläche steht bei solchen Projekten ganz oben auf

240

der Agenda. Um die Anwender dauerhaft zu befriedigen müssen neue Bedienkonzepte und GUI-Architekturen entwickelt werden, da die Anwendungsumgebungen immer heterogener werden. Ein Trend geht dabei vom klassischen Desktopclient hin zu Web- oder Cloudanwendungen. Hier spielen Endgerät und Betriebssystem eine untergeordnete Rolle und bei der Gestaltung der Bedienoberfläche ergeben sich neue Möglichkeiten und Herausforderungen. Das anfangs genannte Zitat von Alan Kay aus den Frühzeiten des Computers bekommt so die Bedeutung, die es verdient. Für die Entwicklungsabteilungen bedeuten diese Aktivitäten einen relativ drastischen Paradigmenwechsel, der die Bedienoberfläche und die Anwender in das Zentrum der Produktentwicklung rückt. Dieser Ansatz wurde bei dem hier beschriebenen Projekt verfolgt. Für eine Pilotanwendung wurden von Beginn an GUI-Mockups erstellt und im Verlauf immer weiter verfeinert. Die Designs wurden parallel dazu

Keywords: /// Usability /// Unternehmenssoftware /// GUI-Modernisierung /// User Centered Design

in einer Demoumgebung des Systems prototypisch umgesetzt. Andere Bereiche im Unternehmen wie Presales und Vertrieb hatten von Beginn an Zugang zu der Demoumgebung. Der Prototyp wurde auf dem User Meeting der Contact Software präsentiert. Das User Meeting ist eine zweijährige Veranstaltung, bei der die neuen und zukünftigen Entwicklungen einem interessierten Kundenkreis vorgestellt werden. Aufgrund der positiven Reaktionen wurde das Bedienkonzept auch auf andere Bereiche der Software angewandt. Neue Module entstanden nach dem Vorbild der Pilotanwendung. Für die Zukunft ist eine komplette Umstellung der Bedienoberfläche geplant. Damit die Erfolge eines solchen Pilotprojekts auch dauerhaft in das Produkt einfließen, müssen ebenso die Prozesse und die Unternehmensstrategie an die neuen Gegebenheiten angepasst werden. Dazu müssen entweder die bestehenden Prozesse angepasst oder komplett neue

Usability Professionals 2013 Enterprise/Government UX

eingeführt werden. Solche Anpassungen brauchen ihre Zeit und orientieren sich am besten individuell an den Gegebenheiten des Unternehmens. Projektablauf Projekstart Contact Software ist Hersteller des PDMSystems CIM DATABASE. Am Anfang des Projekts stand der Wunsch die existierende Bedienoberfläche zu modernisieren und die Usability des Produkts zu verbessern. Den Kunden wollte man auf dem nächsten User Meeting zeigen, dass das Thema Anwenderfreundlichkeit einen Schwerpunkt der zukünftigen Anstrengungen bildet. Man entschloss sich zur Zusammenarbeit mit einem externen Usabilityexperten und startete ein gemeinsames Pilotprojekt. Es wurde ein kleines Kernteam gebildet, das einen Prototyp entwickeln sollte. Beim Projektstart waren die folgenden Rahmenbedingungen gegeben: – Es gab erste Ideen für eine Pilotanwendung, die auf dem User Meeting sechs Monate nach Projektstart präsentiert werden sollte. – Technologische Basis sollte eine Webanwendung basierend auf HTML5, CSS, Javascript mit dem GUI-Framework Bootstrap von Twitter sein (siehe Literatur). – Die Erwartungen an das Projekt waren recht heterogen, es existierte zusätzlich eine umfangreiche Liste mit Verbesserungswünschen an die Usability, die aus dem Bugtracking-System generiert wurde. Diese kamen aus unterschiedlichen Bereichen des Unternehmens und reichten von Detailverbesserungen der existierenden Oberfläche bis zum kompletten Umbau.

nicht alle anfänglichen Erwartungen an das Usabilityprojekt berücksichtigt werden. Das Projekt wurde dann mit den folgenden Zielen gestartet: – Entwicklung eines neuen GUI-Konzepts. – Umsetzung des Konzepts in einen Prototyp, der auf dem User Meeting den Kunden präsentiert werden sollte. – Der Prototyp sollte bei den Kunden einen positiven Eindruck hinterlassen, sowohl durch die neuen Features als auch durch ein ansprechendes Design. – Weitere „kleinere“ Verbesserungen der bestehenden Software, die das Arbeiten effizienter gestalten. Vorgehensmodell nach OpenUP Die Entwicklung orientierte sich weitgehend an einem neu eingeführten Entwicklungsprozess, der auf OpenUP basierte. Der Open Unified Process ist ein „Lean Unified Process“ und lehnt sich an den „Rational Unified Process“ (RUP) an. Das agile, iterative Vorgehensmodell ist in die vier Phasen Inception, Elaboration, Construction und Transition aufgeteilt. In jeder Phase werden Iterationen und Arbeitspakete in den jeweiligen Aktivitäten geplant, deren Intensität je nach Phase variieren. Die Aktivitäten überlappen sich zeitlich. [Abb. 1]

OpenUP fordert nicht zwingend Methoden des User Centered Design, kann durch seine Offenheit aber mit diesen erweitert werden. In der Inception Phase wurde gemeinsam eine Vision für die Pilotanwendung erarbeitet und an alle Stakeholder kommuniziert. Die Vision enthielt eine für alle Beteiligten verständliche Beschreibung der Ziele sowie Anforderungen, Nutzergruppen und die wichtigsten Features. Von Beginn an stand die Bedienoberfläche im Zentrum der Entwicklung. Die Erstellung von Mockups und GUI Designs wurde deshalb als zusätzliche, sehr frühe Aktivität in den Prozess integriert. Sie entstanden hauptsächlich in der Elaboration-Phase und wurden nach jeder Iteration im Team bewertet. Basierend auf den Mockups wurden Use Case Spezifikationen erstellt und im Prototyp implementiert. Projektrollen Bisher waren für die Bedienoberfläche die Entwickler verantwortlich, der Input dazu kam aus verschiedenen Bereichen des Unternehmens. Mit dem neuen Entwicklungsprozess und der Zusammenarbeit mit einem Usabilityexperten entstanden z.T. neue Aufgabenbereiche und wurden die Zuständigkeiten neu aufgeteilt. Projektleiter

Die Aktivitäten des Pilotprojekts bewegten sich hauptsächlich in den beiden Phasen „Inception“ und „Elaboration“. Der

Der Projektleiter war für die zeitliche und inhaltliche Planung und den Ablauf des

Projektziele Nach dem Start wurden innerhalb des Projektteams die Projektziele formuliert. Dazu wurden auch maßgebliche Stakeholder aus Marketing und Entwicklung eingebunden. Da der Zeitrahmen bis zur Präsentation auf dem User Meeting eng begrenzt war, mussten die Verbesserungswünsche priorisiert werden. Hier konnten

Abb. 1. Phasen, Iterationen und Arbeitspakete (nach Rational Unified Process)

241

Projekts verantwortlich. Er hatte langjährige Erfahrung in der Entwicklung und kannte aus verschiedenen Kundenprojekten die Bedürfnisse der Anwender.

– Detaillierte GUI Designs – Erstellen von Use Case Modell und Spezifikationen – Interaktionsdesign – Erstellen eines Styleguides

Usabilityexperte Softwareentwickler Der Usabilityexperte war für die folgenden Bereiche zuständig: – Erstellen des Vision-Dokuments (gemeinsam mit dem Projektleiter) – Erstellen von Mockups

Abb. 2. Aktivitäten nach OpenUP im Pilotprojekt

Abb. 3. Bedienoberfläche Windows-Client CIM DATABASE

242

Die Entwickler implementierten den Prototyp aus den Mockups und Use Cases. Da die Entwicklung von der Bedienoberfläche

ausging, bedeutete dies eine Umstellung vom bisherigen systemzentrierten Vorgehen. Projektablauf Das Pilotprojekt wurde im Januar 2012 gestartet und für sechs Monate terminiert. Das User Meeting fand im Juni 2012 statt. Abb. 2 zeigt die Aktivitäten im Pilotprojekt nach dem Schema des OpenUP. [Abb. 2] Die Pilotanwendung Ausgangslage Die Anwender nutzen CIM DATABASE hauptsächlich über einen klassischen Windows-Client. [Abb. 3] Zusätzlich existiert eine ältere Webanwendung, die in etwa den gleichen Funktionsumfang liefert und das Look&Feel des Desktop Clients besitzt. Die Repräsentation der Daten ist in Listen, Datenblättern und Strukturdarstellungen organisiert. Die Webanwendung ist veraltet, sowohl unter technologischen Gesichtspunkten als auch aus der Bedienperspektive. Auch der Windows-Client ist in die Jahre gekommen. Er besitzt jedoch zahlreiche Features, die den Anwendern produktives Arbeiten ermöglichen. Für die Pilotanwendung existierten schon vor dem Start des Projekts erste Ideen. Es sollte eine neue Anwendung innerhalb des Projektmanagement-Moduls entwickelt werden, in der sich die Anwender schnell einen Überblick über den Verlauf und Zustand ihrer Projekte verschaffen können. Diese Informationen waren zuvor in unterschiedlichen Bereichen der Software verteilt oder nicht vorhanden. Die Anwender sollten aus dieser Übersicht weiter navigieren können um weitere Detailinformationen zu einem bestimmten Projekt abzurufen. Es wurden zwei neue Anwendungsbereiche entwickelt: Die Projektübersicht und die Projektdetails. Zusätzlich entstand ein neuer Kommunikationsbereich, die Aktivitäten, der sich konzeptionell und optisch an Social Media Anwendungen wie Facebook oder Yammer orientiert. Der Prototyp wurde als Webanwendung realisiert, die auch in einem Tablet-Computer funktioniert. Die Anwendung wurde in den existierenden Desktop-Client integriert.

Usability Professionals 2013 Enterprise/Government UX

Die Anwendung „Meine Projekte“ Die Projektübersicht war die erste Anwendung, die entwickelt wurde. Sie zeigt die Projekte, denen die Anwender zugeordnet sind und informiert sie über kritische Entwicklungen. Welche meiner Projekte sind auf einem kritischen Pfad? Wo steht das Projekt zeitlich? Gibt es überfällige Aufgaben oder nicht abgeschlossene Meilensteine? Von der Projektübersicht können die Anwender zu den Detailinformationen eines bestimmten Projekts oder in existierende Bereiche der Software navigieren. Nachdem die Ziele & Anforderungen der Projektübersicht definiert waren, entstand das Konzept in verschiedenen MockupVarianten, die zusammen mit den Stakeholdern bewertet wurden. Abb. 4 zeigt Mockup-Varianten aus denen das endgültige Design entstand. [Abb. 4] Die finale Mockup-Variante wurde in einer prototypischen Umgebung in CIM DATABASE implementiert und intern getestet. Die Erkenntnisse daraus flossen in das ursprüngliche Konzept ein, das in den Mockups weiter verfeinert wurde. Abb. 5 zeigt den Prototyp, der auf dem User Meeting vorgestellt wurde. Das Projektbild dient der schnellen Identifikation der Projekte, es hat zusätzlich für die Mitglieder einen identitätsstiftenden Charakter. Anhand der Ampel können die Anwender schnell erkennen, welche Projekte auf einem kritischen Pfad sind. Es werden die Anzahl der überfälligen Aufgaben und offenen Punkte angezeigt. Die produktive Entwicklung des Projekts spiegelt sich in der Anzahl von neuen Dokumenten und Artikeln. Auf einem normierten Zeitstrahl werden der aktuelle Zeitpunkt im Projekt und die vergangenen und anstehenden Meilensteine angezeigt. [Abb. 5]

Abb. 4. Mockup-Varianten der Anwendung „Meine Projekte“

Die Anwendung „Projektdetails“ Aus der Projektübersicht navigieren die Anwender zu den Projektdetails. Sie bieten Detailinformationen zu einzelnen Projekten, z.B. einen Überblick über die Projektaufgaben und Dokumente. Sie können Kontaktinformationen zu den Projektmitgliedern

Abb. 5. Prototyp „Meine Projekte“

243

abrufen und die Aktivitäten im Projekt anzeigen lassen. Die Projektdetails sind so konzipiert, dass sich weitere Spezialbereiche hinzufügen lassen, ohne dass die Übersicht verloren geht. Die Detailinformationen sind in aufklappbare Bereiche gegliedert, die von den Anwendern je nach Priorität vertikal verschoben werden können. Die Informationen der Projektübersicht sind hier ebenfalls vorhanden, damit die Anwender nicht zu der Projektübersicht zurücknavigieren müssen. Abb. 6 zeigt einen Screenshot des Prototyps. [Abb. 6] Die Anwendung „Aktivitäten“

Abb. 6. Prototyp „Projektdetails“

Ursprünglich waren die Aktivitäten nicht Teil des Pilotprojekts. Es gab jedoch schon Ideen für diese Anwendung, die sich konzeptionell an Social Media Anwendungen orientieren sollte. Während des Projekts entstanden die technologischen Grundlagen, die es ermöglichten, die Aktivitäten in die Pilotanwendung für das User Meeting zu integrieren. Die Aktivitäten sind ein Kommunikationstool, das unternehmensweit und projektspezifisch genutzt werden kann. Die Anwender können ähnlich wie in Yammer oder Facebook Beiträge erstellen und Diskussionen starten. Sie bekommen automatisch vom System generierte Meldungen über Objekte aus ihrem Arbeitskontext, wie z.B. die Fertigstellung von Aufgaben oder neue Dokumente, deren Bearbeiter sie sind. Dieses Verhalten ist konfigurierbar, so kann die Anzahl der automatischen Meldungen begrenzt werden. [Abb. 7] Fortführung der Usabilityprojekts

Abb. 7. Prototyp der Anwendung „Aktivitäten“

244

Aufgrund der Erfahrungen im Pilotprojekt wurde die Zusammenarbeit fortgeführt und die Usabilityaktivitäten ausgeweitet. Aus der Pilotanwendung wurde ein neues GUI-Konzept abgeleitet. Der Prototyp wurde weiterentwickelt und in die reguläre Software integriert. Neue Anwendungen folgen nun hauptsächlich dem neuen GUI-Paradigma und

Usability Professionals 2013 Enterprise/Government UX

existierende Anwendungen werden damit modernisiert. Es entstehen Module im Bereich des Innovationsmanagements, der Aufgabenverwaltung und des Kennzahlenmanagements. Für die Icons wurde ein einheitliches Designkonzept entwickelt und die Iconbibliothek wurde komplett neu gestaltet. Das GUI-Konzept und die Komponenten wurden in einem Styleguide dokumentiert. Die Mitarbeiter werden in regelmäßigen Talks für das Thema Usability sensibilisiert. Neues GUI-Paradigma Aus der Pilotanwendung entstand ein neues GUI-Paradigma, das maßgeblich für die Entwicklung neuer Anwendungen ist. Es besteht aus den folgenden Elementen: –– Ein „Drill Down“-Navigationskonzept, das die Anwender vom Groben ins Feine führt –– Aufklappbare Übersichts- und Detailbereiche mit modernen Filter- und Suchmöglichkeiten –– Kommunikationspanels, die sich an Social Media Anwendungen wie Yammer und Facebook orientieren –– Visuell ansprechendes Design Die Anwendungen sind plattformunabhängig, basieren auf moderner Webtechnologie und sollen möglichst leicht auf mobile Endgeräte wie Tablets adaptierbar sein. Die GUI-Elemente aus dem Prototyp wurden in einer Bibliothek standardisiert und können von den Entwicklern in ihren Anwendungen verwendet werden. Icon Redesign Im Prototyp wurden möglichst Icons aus der bestehenden Software verwendet. Zusätzlich mussten neue Icons erstellt werden. Die Icons wurden als Vektorgrafik komplett neu erstellt, als Basis diente eine kostenpflichtige Bibliothek, die monochrome Icons u.a. im Vektorformat enthielt und dadurch gut anpassbar war. Visuell orientierte sich das Design an der Bibliothek und dem Corporate Design des Unternehmens. Mindestens so wichtig war

ein semantisches Konzept, das von einem Beitrag der Mensch & Computer 2012 abgeleitet wurde (Kirstein, Schoenherr & Schubert, 2012). Dort wurde u.a. eine allgemeine Syntax für die Gestaltung von Icons präsentiert, die als Vorgabe für die inhaltliche Gestaltung der Icons dient und in den Styleguide übernommen wurde. Der Iconbestand setzte sich aus unterschiedlichen Bibliotheken zusammen und war heterogen in Design und Symbolik. Im Prototyp wurde die Inkonsistenz zusätzlich verstärkt, da die neuen Icons sich visuell deutlich abhoben und moderner wirkten. Es wurde entschieden, den Altbestand von ca. 500 Icons auf das neue Design umzustellen. Zu diesem Zeitpunkt war es unklar, ob die komplette Umstellung bis zum nächsten Release gelingen würde. In einem ersten Schritt wurden deshalb die Icons identifiziert, die in der Bedienoberfläche sehr präsent und für die normalen Endanwender sichtbar waren. In einem zweiten Schritt wurden die Icons neu erstellt, die sich in versteckteren Bereichen befanden. Die Umstellung der Icons durfte keine Auswirkungen auf den Zeitplan des regulären Releases haben und es wurden bewusst Kompromisse mit kleineren Inkosistenzen einkalkuliert. Dokumentation des Konzepts in einem Styleguide Das Konzept wurde in einem Styleguide dokumentiert, dessen Umfang bewusst kompakt gehalten ist und der regelmäßig aktualisiert wird. Auf detaillierte Vermaßungen der Elemente wurde verzichtet. Die Maße werden direkt in den GUI-Templates festgeschrieben und können zentral angepasst werden, ohne dass der Styleguide angepasst werden muss. Erfolgsfaktoren & Lessons Learned Übersicht Zum Projekterfolg trugen recht unterschiedliche Faktoren bei, die jedoch nicht alle zu Beginn eines solchen Projekts planbar sind. In einem relativ eng definierten

Pilotprojekt mit einem kleinen Kernteam die Zusammenarbeit zu beginnen und später auszuweiten dürfte wesentlich zum Gelingen beigetragen haben. Eine Herausforderung waren die unterschiedlichen Erwartungen an das Projekt. Durch die umfangreiche Liste mit Verbesserungswünschen war die Priorisierung zu Beginn des Projekts aufwendiger als ursprünglich angenommen. Sich die Zeit dafür zu nehmen hat sich aber gelohnt. Dass das Projekt nicht in den regulären Release-Zyklus eingebettet war, ließ dem Team gewisse Freiheiten. Es konnte intensiv mit Mockups gearbeitet werden und die Bedienoberfläche stand so von Beginn an im Zentrum der Entwicklung. Der Entwicklungsprozess unterstützte das Team einerseits bei dem ungewohnten Vorgehen, andererseits verlangsamte er aber besonders in der Startphase die konkrete Entwicklung der Anwendung. Als Ursachen sind die Unerfahrenheit des Teams mit dem Prozess zu nennen sowie ein genereller Effekt bei der Einführung neuer Vorgehensmodelle. Der enge Zeitplan ließ nicht alle Möglichkeiten eines benutzerzentrierten Vorgehens zu. Interviews und Beobachtungen mit Anwendern wurden nicht durchgeführt. Stattdessen kamen die Daten hier von Mitarbeitern, die viel Erfahrung in Kundenprojekten hatten. Trotzdem blieb mitunter eine Unsicherheit über die tatsächlichen Bedürfnisse der Anwender. Eine Einplanung von solchen Aktivitäten wäre aus Usabilitysicht wünschenswert. Vision Die Erarbeitung und Dokumentation einer gemeinsamen Vision war die Grundlage für das Gelingen des Projekts. Sie half dabei, dass alle Beteiligten eine gemeinsame Sicht auf das Projekt hatten und fokussiert auf die Ziele hinarbeiten konnten. Da das Team mit dem OpenUP-Prozess wenig bis keine Erfahrung hatte, nahm die Erstellung der Vision einen längeren Zeitraum als

245

geplant ein. Schwierig gestaltete sich auch die Beteiligung aller Stakeholder. Es waren nicht alle Stakeholder im gleichen Maße involviert und vom Nutzen einer solchen Vision überzeugt. Während die eigentliche Erstellung kaum Zeit in Anspruch nahm, waren die Diskussionen im Vorfeld zum Teil recht zeitaufwendig. Dies sollte möglichst in die Planung der Elaboration-Phase einbezogen werden, vor allem wenn der Prozess noch nicht eingeschliffen ist. Bei größeren Projekten bieten sich VisionWorkshops an, die einen festen Platz im Projektplan haben sollten (Colville, 2012).

Literatur

Mockups & Use Cases

4. Wikipedia: Rational Unified Process:

1. Bootstrap: Sleek, intuitive, and powerful front-end framework for faster and easier web development: http://twitter.github.io/ bootstrap/index.html 2. Colville, A. (2012). Creating A Shared Vision That Works. UX Magazine. http://uxmag.com/articles/ creating-a-shared-vision-that-works 3. Kirstein, E., Schoenherr, N. & Schubert, U. (2012). Icon Design im großen Stil – Erfahrungen zu Gestaltung und Einsatz von umfangreichen Icon-Bibliotheken. In: Brau, H., Lehmann, A., Petrovic K., Schroeder, M. (Hrsg.). Usability Professionals 2012 http://de.wikipedia.org/wiki/

Mit den Mockups konnten schon früh Ideen und Konzepte visualisiert werden, die noch nicht den Eindruck einer fertigen Lösungen vermittelten und damit Spielraum für Diskussionen und Feedback boten. Die Mockups wurden zu einem festen Bestandteil bei der Entwicklung der Pilotanwendung und haben sich auch in der Folge bewährt. Sie eignen sich sowohl zur Visualisierung der ersten Konzepte als auch für detaillierte Entwürfe. Das Interaktionsdesign wurde in Use Cases spezifiziert. Die textuelle Beschreibung einer Interaktion ist weitgehend präziser und effizienter als dies alleine mit Mockups zu lösen. Dies bestätigte sich auch im Projekt, als man versuchte eine Teilanwendung ausschließlich über Mockups zu realisieren. Der direkte Vergleich zeigte, dass Use Cases in Kombination mit Mockups effizienter und klarer in der Kommunikation zwischen Designer und Entwickler sind. Use Cases sind zusätzliche eine gute Grundlage für die Anwenderdokumentation. Technische Redakteure können daraus schon früh die relevanten Inhalte für ihre Dokumentation ableiten.

246

Rational_Unified_Process

Usability Professionals 2013 Enterprise/Government UX

247

Willkommen auf der Achterbahn Erfolgsfaktoren für UX Consulting im eGovernment

Michael Bechinie USECON GmbH 1110 Wien Modecenterstraße 17, bechinie@usecon.com

Peter Strassl USECON GmbH 1110 Wien Modecenterstraße 17, strassl@usecon.com

Markus Murtinger USECON GmbH 1110 Wien Modecenterstraße 17, murtinger@usecon.com

Abstract Im Rahmen einer Metaanalyse von zehn umfangreichen Langzeit-Beratungsprojekten werden sieben Erfolgsfaktoren, für die nachhaltige Umsetzung von User Experience (UX) Maßnahmen, vorgestellt. Diese werden exemplarisch für das fachlich komplexe eGovernment Umfeld präsentiert. Software Entwicklungsprojekte mit staatsnahen Institutionen stellen durch die ständig wechselnden Rahmenbedingungen und der großen Anzahl eingebundener Stakeholder besonders hohe Ansprüche an UX-Verantwortliche. Auf Basis von Erkenntnissen unterschiedlicher Projekte in diesem Umfeld werden konsolidierte Erfahrungswerte aus folgenden Feldern veranschaulicht: generelles Projektsetup, Zusammenarbeit mit anderen Teams bzw. weiteren externen Partnern, Argumentation von Maßnahmen bzw. Methoden, interne Projektkommunikation mit unterschiedlichen Stakeholdern, „Verkauf“ von UX-Entscheidungen bzw. Behandlung von Widerständen, Kunden Coaching bzw. Nutzen aus Nachbetrachtung der Projekte. Die in zahlreichen eGovernment Projekten erprobten Erfolgsfaktoren geben Einblicke für die ideale Einbindung von UX-Maßnahmen in bestehende Prozesse öffentlicher Organisationen. In den analysierten Projekten werden sowohl Gemeinsamkeiten als auch Unterschiede im strategischen Vorgehen bei verschiedenen Projektdomänen (z.B. eGovernment, eHealth, Versicherungen, Arbeitsmarkt etc.) aufgezeigt bzw. diskutiert.

1. eGovernment, ein spannendes Feld für User Experience (UX) Beratung Eine Hauptinitiative der Europa 2020 Strategie baut auf der „Digitalen Agenda für Europa (DAE)“ auf. In der siebenten Säule „ICT-enabled benefits for EU society“ [European Commission 2013a] wird den Informations- und Kommunikationstechnologien (IKT) besondere Bedeutung im eGovernment Umfeld zugemessen. Der Aktionsplan 2011 – 2015 hat in der Malmö Erklärung dementsprechend vier Schwerpunkte gesetzt [European Comission 2010]: –– „Stärkung der Bürger und Unternehmen durch elektronische Behördendienste, die ganz auf die Bedürfnisse der Nutzer abgestimmt sind und in Zusammenarbeit mit Dritten entwickelt wurden, […] –– Erleichterung der Mobilität im Binnenmarkt durch nahtlose elektronische Behördendienste, […];

248

–– Effizienz und Effektivität durch das stetige Bemühen, mit Hilfe elektronischer Behördendienste die Verwaltungslasten zu verringern, […]; –– Umsetzung der politischen Schwerpunkte durch Schaffung g eeigneter Schlüsselvoraussetzungen sowie rechtlicher und technischer Voraussetzungen.“ Aktuelle Zahlen zu den Zielen aus 2012 zeigen, dass Europa eine sehr positive Entwicklung nimmt: 44 % (Ziel 50% bist 2015) der europäischen Bevölkerung und 87 % (Ziel: 80% bis 2015) der Unternehmen nutzen bereits elektronische Behördendienste [European Commission 2013b]. Seit 2007 führt die Europäische Kommission Benchmarkingstudien durch, in denen der Status der Umsetzung elektronischer Behördendienste in den europäischen Ländern beobachtet wird. Ein wesentliches Ergebnis der aktuellen Studie (Beobachtungszeitraum 2012) ist, dass seit 2007 die

Manfred Tscheligi USECON GmbH 1110 Wien Modecenterstraße 17, tscheligi@usecon.com

Keywords: /// Usability /// Strategische User Experience /// Experience Management /// Erfolgsfaktoren /// eGovernment

Verfügbarkeit von elektronischen Behördendiensten ständig zunahm, aber die Zufriedenheit (Usability bzw. UX) signifikant abgenommen hat. Ein ähnlicher Trend zeigt sich auch bei Nicht-eGovernment Services wie eBanking und eCommerce. Als Top 1 Erkenntnis (von 3) stellt die Studie fest: „The shift in eGovernment thinking towards designing services around user needs is not yet fully embraced in Europe“. Die Kommission formuliert folgende Empfehlung für die EU-Länder: „Implement strategies to increase customer centricity, improve the design of public services, and thus increase online take-up.“ [European Commission 2013c]. 2. eGovernment, ein Umfeld das sich als „speziell“ präsentiert Der Nachholbedarf bei Usability und UX zeigt, dass die Vorgaben stark in Richtung einer „Industrialisierung nicht

Usability Professionals 2013 Enterprise/Government UX

kommerzieller Branchen“ gehen. Das erfordert ein Umdenken bei der Konzeption, Entwicklung und Pflege von eGovernment Services auf Anbieterseite. Bürger sehen sich zunehmend als Kunden der Behörde. Die Frage ist, wie sich UX Maßnahmen im Umfeld elektronischer Behördendienste nicht nur punktuell, sondern nachhaltig umsetzen lassen, um die geforderte, durchgängige UX erreichen zu können. Auf den ersten Blick präsentiert sich das eGovernment Umfeld als Branche „wie jede andere“ und scheint keine besonderen Strategien in der Beratungspraxis zu erfordern. Die Erfahrung der Autoren aus Projekten mit sehr unterschiedlichen Fachmaterien, mit wechselnder Konstellation und Dauer, zeigt jedoch eine Reihe von Eigenschaften, die das eGovernment Umfeld als „speziell“ charakterisieren. [Abb. 1] Zur Lösung der Spannungsfelder werden entsprechende Erfolgsfaktoren im Kapitel 3.2 vorgestellt. 2.1. Rechtssicherheit versus Usability Für Nichtexperten sind Rechtsmaterien schwer verständlich, die sich nicht beliebig vereinfachen lassen. Behördenwege im persönlichen Kontakt abzuwickeln haben für Antragsteller Vorteile: sie erhalten benötigte Zusatzinformationen auf

direktem Weg, und begehen im Prozess weniger Fehler. Der Rückhalt der persönlichen Kommunikation fällt bei elektronischen Behördenwegen nahezu weg. Bei der Abwicklung entsteht ein gewisses Unbehagen „Dinge falsch zu machen“. Das Interaktionsdesign behördlicher Prozesse erhält daher besondere Aufmerksamkeit. Behörden haben den Anspruch größtmögliche Rechtssicherheit in den Prozessen zu bieten. Rechtsgrundlagen machen die Entscheidungsfindung „Welche ist die richtige Vorgehensweise in meiner Ausgangssituation?“ für den Anwender meist nicht leichter. Für den Berater ergibt sich damit ein Spannungsfeld zwischen „Designing for Trust“ und rechtskonformer Abbildung von Prozessen. Das Argument „wir müssen das so abbilden“ wird zum Stehsatz. 2.2. Föderale Organisation versus rasche Entscheidungen Gesetze haben oft Aspekte, die sich auf Bundes- Landes- und Gemeinde- Ebene anders auswirken. Verschärft wird dieser Umstand durch eine EU-Zugehörigkeit. Dadurch ergibt sich meist die Notwendigkeit vermehrter Abstimmungen zwischen Bund, Land und übergeordneten Strukturen. Teils widerstrebende Bedürfnisse müssen in einer User Interface Lösung integriert

werden, sodass alle Interessen abgedeckt werden können. Berater sitzen daher vermehrt in grossen, gremialen Sitzungen, um passende Lösungen zu besprechen. Die Entscheidungsfindung ist meist komplex und von starken Kompromissen geprägt. 2.3. Budgetunsicherheit versus nachhaltige Maßnahmen eGovernment ist per Definition ein politisches Umfeld. Budgets für Projekte sind stark von der amtierenden Regierung abhängig. Die Planung von Maßnahmen wird durch etwaige Wechsel der Zuständigkeiten erschwert. Zugesicherte Budgets werden gekürzt oder ganz gestrichen. Strategische UX Arbeit, die auf längerfristige Maßnahmen ausgelegt ist, wird dadurch zur Wahrscheinlichkeitsrechnung. 2.4. Gesetzesnovelle versus Usability Optimierung Sind für die kommende Release Usability Optimierungen geplant, kann dieser Plan durch Gesetzesnovellen durchkreuzt werden, die verpflichtend im System umgesetzt werden müssen. Usability Optimierungen werden eventuell auf die Folgerelease verschoben, Rechtssicherheit hat Vorrang.

Abb. 1. Charakteristika des eGovernment Beratungsfeldes mit entsprechenden Erfolgsfaktoren zur Lösung der Spannungsfelder

249

Abb. 2. Komplexität der Projektdomäne versus Komplexität der Projektorganisation

2.5. Vorgaben versus Innovationsspielraum eGovernment wird durch ein starkes Regelwerk bestimmt: eGovernment Gesetz, Sicherheitsrichtlinien, Barrierefreiheit, verbindliche Style Guides für den Einsatz von Formularen, Datenstrukturen, Legacy ITSysteme, unterschiedliche Datenprotokolle. Hier zeigt sich ein bedeutender Unterschied zu anderen Branchen: der Spielraum für innovative Lösungen, besonders im User Interface Bereich, ist oft ein sehr kleiner. 2.6. Arbeitssituation versus Motivation Design Entscheidungen im eGovernment Umfeld haben eine starke, fachliche Komponente. Ohne intensive Einbindung von Mitarbeitern aus den Fachabteilungen von Ministerien und Landesorganisationen ist es nahezu unmöglich konforme Designlösungen zu entwickeln. Die Projekttätigkeit bedeutet oft Zusatzaufwände und eine erhöhte Arbeitsbelastung für bereits stark geforderte Vertragsbedienstete. Zusätzliche Arbeitsworkshops und Qualitätssicherungsaufgaben kommen hinzu. Gefühlte

250

„On Top“ Usability Themen, „mit denen man sich jetzt auch noch beschäftigen muss“, werden teilweise als Ballast empfunden. Taktieren und Politik der Abgrenzung beherrschen die UX Arbeit, Formalismen schränken die Motivation ein. 2.7. Erschwerter Zugang zu Benutzern versus benutzerzentrierte Entwicklung Für den UX Berater stellt die Einbindung von Anwendern einen wesentlichen Faktor in der benutzerzentrierten Systementwicklung dar. Durch die Multi-Stakeholder Perspektive bei eGovernment Anwendungen fällt es oft schwer alle unterschiedlichen Zielgruppen einzubinden. Aus projektpolitischen Gründen wird es als Notwendigkeit gesehen, Vertreter aus allen (auch parteipolitischen) Gruppen, bzw. allen betroffenen organisationalen Einheiten einzubeziehen. Ein agiler Usability Test wird so rasch zu einer großen Hürde, wenn nicht sogar zu einem vorläufigen „No Go“, da die Vorbereitungszeit schnell auf Wochen anwachsen kann, bis alle Interessensvertreter organisiert sind.

Wie wirken sich diese Charakteristika auf den Erfolg von UX Maßnahmen aus? Welche Erfolgsfaktoren leiten sich für die Beratungspraxis daraus ab? 3. Nachhaltige Umsetzung von UX Maßnahmen im eGovernment Umfeld 3.1. Analyse von Projekten als Ausgangspunkte UX Berater sind „Lösungslieferanten auf Zeit“, die ihre Leistungen immer weiter optimieren wollen. Im Zentrum der Überlegungen stand daher die Frage, wie die UX Arbeit in einem speziellen Feld noch kundenorientierter werden kann. Mit Hilfe von informalen „Projekt Retrospektiven“ [Kerth 2001] wurden Erfahrungswerte durchgeführter eGovernment Projekte gesammelt. Abläufe, Entscheidungsfindung, „Pain- und Pleasure Points“ wurden analysiert, Anekdoten gesammelt und mit Learnings anderer Branchen abgeglichen. Die analysierten Projekte hatten sehr unterschiedliche Komplexität in Bezug auf Domäne bzw. Projektorganisation [Abb. 2]

Usability Professionals 2013 Enterprise/Government UX

Abb. 3. Beispiel Setup mit Beteiligung unterschiedlicher Kompetenzen schon ab der Analysephase

3.2. Die Erfolgsfaktoren Die Autoren haben mögliche Faktoren für die erfolgreiche Umsetzung strategischer und taktischer UX Maßnahmen im eGovernment Bereich in folgenden Feldern identifiziert: – Projektorganisation – Zusammenarbeit im Team bzw. mit externen Partnern – Interne Projektkommunikation mit unterschiedlichen Stakeholdern – Argumentation von Maßnahmen bzw. Methoden – „Verkauf“ von UX Entscheidungen – Behandlung von Widerständen – Kunden Coaching bzw. Nachbetrachtung des Projekts 3.3. Ein maßgeschneidertes Projektsetup definieren Dieser Faktor hat starken Bezug zu „Rechtssicherheit vs. Usability“. Für die Entwicklung rechtskonformer, aber benutzbarer Lösungen liegt der Erfolgt darin, im Projektsetup schon zu Beginn unterschiedliche

Kompetenzen in die Analyse miteinzubeziehen. Durch die frühzeitige Einbindung von Fachlichkeit, Entwicklung, Design, und Usability profitieren User Interface Design Entscheidungen wesentlich. In diesem Zusammenhang hilft eine klare Definition bzw. Differenzierung notwendiger Rollen. Damit wird der Verwechslung von Verantwortung mit Kompetenz vorgebeugt. Auch Verzögerungen in den Projektplänen durch Konflikte zu Verantwortungen und Kompetenzen können so reduziert werden. In Abstimmung mit der fachlichen Betrachtung durch Experten, der funktionalen Betrachtung durch Software Architekten bzw. Entwickler und der User Interface Design Perspektive kann die Gesamtqualität der Softwarelösung gesteigert werden. Ein weiterer Faktor stellte die Konsolidierung bereits vorliegender (Usability) Ergebnisse aus Vorprojekten dar. Wertvolles Wissen, das bei der „Budgetunsicherheit vs. nachhaltige Maßnahmen“ Problematik hilft, ohne knappe Ressourcen weiter durch Doppelarbeiten zu gefährden. Daraus kann ein, auf das Projekt abgestimmter UX

Maßnahmen Katalog erstellt werden. Dieser baut auf vorhandenen Kompetenzen und Vorergebnissen auf, ohne einen weiteren Prozess auf bestehende Prozesse zu setzen. Der Einsatz und die Priorisierung von User Interface Design Prinzipien und UX Faktoren bietet eine zusätzliche Maßnahme, um Design Entscheidungen in der Analyse auf eine begründbare Basis zu stellen und Geschmacksdiskussionen zu vermeiden. Gerüstet mit klaren Rollen, konsolidiertem Vorwissen und Designrationalität wird das UX Mindset gute Überlebenschancen in der Analyse-, Entwicklung- und der TestPhase einer eGovernment Lösung haben. Abbildung 3 zeigt ein Beispiel für ein zuvor beschriebenes Projektsetup in der Domäne Arbeitsmarkt-Services. [Abb. 3] 3.4. Das Potential sozialer Intelligenz nutzen Je größer und komplexer ein Projekt, desto größer die Herausforderung „Dinge erledigt zu bekommen“, vor allem in Bezug auf UX Aufgaben. Mit steigender Anzahl der Projektmitglieder nimmt auch die soziale Komplexität zu. Eine wesentliche

251

Abb. 4. Elefant vs. Schmetterling – Agile UX Maßnahmen bieten in unsicheren Umwelten größere Erfolgschancen und rascher greifbare Ergebnisse

Änderung in der Dynamik entsteht, wenn das Hauptprojekt in Teilprojekte geteilt werden muss – im eGovernment Bereich ein häufiger Fall. Die Notwendigkeit für verstärkte Kommunikation erhöht sich vor allem dann, wenn Mitglieder des Vorstands Teil des Projekts sind. Um UX Ziele im Auge zu behalte und greifbare Ergebnisse zu erzielen liegt der Erfolg des Beraters neben seiner fachlichen Kompetenz in der Nutzung von „Machiavellistischer Intelligenz“. Wenn der UX Berater will, dass die Projektkollegen die eigene UX Sichtweise annehmen, ist es wichtig ihnen Argumente anzubieten mit denen Sie selbst punkten können. Mit anderen Worten muss der Berater „kooperative Spiele“ einsetzen und die Rolle des „Vermittlers und Integrators“ einnehmen, um die Qualität von Design Entscheidungen entsprechend zu garantieren [Bechinie 2010]. Dies trifft besonders dann zu, wenn Teams in Teilprojekten arbeiten und gremiale Strukturen Entscheidungsprozesse langwierig gestalten. Besonders auf „Föderale Organisation vs. rasche Entscheidungen“ wirkt sich diese Taktik positiv aus.

252

3.5. Mit allen Stakeholder des Projekts vernetzen

3.6. UX Maßnahmen und Methoden argumentieren

Eng im Zusammenhang damit steht die interne Projektkommunikation mit unterschiedlichen Stakeholdern. Um den Ball der Kommunikation im Dickicht einer komplexen Projektorganisation aus Behörde(n), weiteren externen Beratern und ausgelagerten Entwicklungsressourcen flach zu halten, ist die Versuchung für UX Berater groß, nur mit dem direkten Umfeld zu sprechen. Für die Entscheidungsfindung braucht diese Strategie voraussichtlich weniger Iterationen, es wird aber gleichzeitig die Qualität der Entscheidung gefährdet. Fundierte UX Entscheidungen sind per Definitionem multidimensional.

Der im Projektsetup definierte Katalog an möglichen UX Maßnahmen und Methoden ist im eGovernment Umfeld stark von „Budgetunsicherheit vs. nachhaltige Maßnahmen“ geprägt. Das für die Planung von UX Aktivitäten freigegebene Budget wird durch die Abhängigkeit von der amtierenden Regierung mit großen Unsicherheitsfaktoren belegt. Unter diesen Bedingungen bietet sich für die erfolgreiche Umsetzung längerfristiger Maßnahmen daher eine leichtgewichtige Vorgehensweise an – der „Schmetterlingsweg“. Ergebnisse können im Gegensatz zum „Elefanten Weg“ proaktiver, rascher, greifbarer, pragmatischer und mit höherer „CEO Sichtbarkeit“ geliefert werden. [Abb. 4]

Der Erfolg liegt darin, Maßnahmen möglichst früh zu ergreifen, die dieses Risiko minimieren. Der Berater tut gut daran, alles dafür zu tun, dass das UX Thema zum Verbündeten aller Projektbeteiligten wird und nicht zum Feindbild. Erfolgreich ist der, der eine kooperative Atmosphäre zwischen dem UX Team und "allen neuen Freunden" entstehen lässt.

3.7. UX Entscheidungen gewinnbringend verkaufen Zeigt sich die nächste Gesetzesänderung am Horizont, werden gute Argumente zum eigentlichen Erfolgsfaktor des Beraters.

Usability Professionals 2013 Enterprise/Government UX

Abb. 5. Promotoren für die erfolgreiche Überwindung von Widerständen gegen UX-Maßnahmen

Um anstehende Usability Optimierungen trotzdem in der nächsten Release unterzubringen, hilft der Weg der kleinen Schritte. Im Zusammenhang mit „Gesetzesnovelle vs. Usability Optimierung“ und „Vorgaben vs. Innovationsspielraum“ liegt der Erfolg darin UX Themen zu priorisieren, die sich mit beschränktem Budget umsetzen lassen und aus Benutzersicht dennoch fühlbare Verbesserungen bringen. Eine wesentliche Maßnahme auf dem Weg zum Erfolg liegt in der projekt- und organisationsinternen Vermarktung von Ergebnissen der UX Arbeit. Die Sichtbarkeit von greifbaren Ergebnissen wirkt sich positiv auf die Aufmerksamkeit in der Projektleitung aus. Im Sinne einer langfristigen Demonstration des Wertes von UX Maßnahmen ist es wichtig, auch die kurzfristigen Erfolge aufzuzeigen. Nur so wird es möglich sein, Mittel für weitere UX Aktivitäten in der nächsten Release zu sichern. Für die Kommunikation eignen sich besonders klassische Managementwerkzeuge wie formelle und informelle Präsentationen, Ergebnisse von Usability-Tests und die Aufbereitung von Best Cases.

3.8. Widerstände durch den Einsatz von Promotoren auflösen Generell entstehen Widerstände, wenn es um Veränderungen geht und/oder wenn zusätzliche Aufwände für die Beteiligten entstehen. Die UX Sichtweise anzunehmen bedeutet oft große Veränderungen. Hier zieht „Arbeitssituation vs. Motivation“. Zusätzlich spielt hier „Erschwerter Zugang zu Benutzern vs. benutzerzentrierte Entwicklung“ eine Rolle, der sich im eGovernment Umfeld sehr stark auswirkt. Widerstand gegen UX Maßnahmen wird geleistet weil … – sie das Tagesgeschäft unterbrechen – sie Veränderung verlangen – sie das jetzige Projektsetup herausfordern – es zu Unsicherheit im Zusammenhang mit bestehenden Prozessen kommen kann – sie von „kreativer Zerstörung“ begleitet werden – es „gut etablierte“ Mythen über UX gibt

Als „Sponsoren“ des Widerstands treten dabei die Projektmitglieder selbst, deren Vorgesetzte oder externe Projektpartner auf. Für die erfolgreiche Überwindung der Widerstände bietet das Promotorenmodell [Hauschildt 2003] eine praktikable Herangehensweise. [Abb. 5] Das Modell stammt aus dem Innovationsmanagement, wobei verschiedene Promotoren unterschiedliche Arten von Widerständen überwinden. Jedem Widerstand ist ein Promotor zugeordnet, den es im Projekt zu gewinnen gilt, um die jeweilige Blockade lösen zu können. Gibt es eine prinzipielle Übereinkunft im Projekt, Win-Win Lösungen zu erreichen, ist es hilfreich dem „Skeptiker“ die Rolle des „Fach-Promotors“ zuzuteilen. Dieser hat das Wissen über mögliche Alternativen. Hat der UX Berater auch grundlegendes Faktenwissen, kann dieser dazu beitragen. Wenn nicht, nimmt dieser die Rolle des „Prozess-Promotors“ ein. Ein Mitglied aus der Managementebene sollte den „Macht-Promotor“ einnehmen. Gemeinsam können so Lösungen entwickelt werden, die auch funktionieren.

253

oder Hybride wie „Water-Scrum-Fall“ [West 2011]) –– Teilweise sehr lange Änderungs-Zyklen (abseits der Aktualisierung der rechtlichen Basis) –– „Design for All“ (nicht nur zurechtkommen, sondern auch gute UX) –– Starke Unterschiede der Businessprozess Ebenen (Administration < > Administration, Administration < > Unternehmen, Administration < > Bürger) –– Starke Unterschiede in der Sensibilität der Rechtsmaterien (Gesundheitsdaten vs. Abfallbilanzen vs. Öffnungszeiten Besucherzentrum Parlament) 4. Fazit und Ausblick

Abb. 6. Projekt Retrospektive für die Optimierung der UX Maßnahmen im nächsten Projekt

3.9. Lernen durch Beobachtung Ein wesentlicher Lernvorgang stellt das Beobachtungslernen dar [Badura 1962]. Ziel dabei ist es, bestehende Verhaltensweisen zu modifizieren bzw. neue Verhaltensweisen zu erlernen. Diese klassische Methode bietet die Möglichkeit Maßnahmen und Ergebnisse nach Abschluss eines Projekts systematisch zu analysieren. Die Projekt Retrospektive wird zu einem wichtigen Werkzeug, um geplante UX Maßnahmen in einem Folgeprojekt zu optimieren. Im Rahmen der Retrospektive werden alle Phasen eines Projekts betrachtet. Die Aktivitäten bzw. deren Ergebnisse werden mit dem Projektteam in mehreren Dimensionen bewertet: Projekt Rahmenbedingungen, Projektmanagement, Methoden / Projektinhalte, Kommunikation und Papierkorb (nicht durchgeführte Aktivitäten). Eine nach dem Plus / Minus Schema erfolgte Bewertung zeigt, welche Aktivitäten im

254

nächsten Projekt beibehalten werden sollen, und welche Maßnahmen gestrichen oder zumindest geändert werden können. Diese Einsichten helfen die Qualität der UX Arbeit zu steigern. [Abb. 6] 3.10. Gleich und doch verschieden Die beschriebenen Erfolgsfaktoren sind aus Sicht der Autoren von der jeweiligen eGovernment Domäne unabhängig wirksam. Es gibt eine Reihe zusätzlicher Aspekte, die starke Abhängigkeit von der betrachteten eGovernment Domäne zeigen und als „Moderatoren“ der Erfolgsfaktoren wirken: –– UX Reifegrad einer Organisation (vorhandene Prozesse, gelebte Maßnahmen) –– Organisatorische Positionierung des Projekts (Ebene des Vorstandes, Bereichs, der Abteilung) –– Angewendete Vorgehensmodelle der Systementwicklung (Wasserfall, Agile

eGovernment ist ein spannendes Feld für UX Beratung, das sich jedoch als „speziell“ präsentiert und einer Fahrt auf der Achterbahn gleicht – mit verbundenen Augen. Die nachhaltige Umsetzung von UX Maßnahmen im eGovernment Umfeld stellt Berater vor zwei große Herausforderungen: ständiger Wandel und kontinuierliche Adaption von Maßnahmen an wechselnde Projektumwelten. Im Rahmen einer Metaanalyse von Beratungsprojekten in sehr unterschiedlichen eGovernment Domänen konnten sieben übergreifende Faktoren aufgezeigt werden, die für die nachhaltige Umsetzung von UX Maßnahmen Anhaltspunkte bieten. Zusammengefasst stellt die Kombination aus gut argumentiertem Nutzen von UX Maßnahmen und sozialem Geschick einen wesentlichen Beitrag für die erfolgreiche Arbeit von UX Beratern im hochpolitischen Umfeld elektronischer Behördendienste dar. Darauf aufbauend ergeben sich für die Zukunft weitere Fragestellungen, in wie weit sich zum Beispiel die Relevanz der Erfolgsfaktoren in anderen UX Beratungsfeldern voneinander unterscheidet.

Usability Professionals 2013 Enterprise/Government UX

Literatur 1. Bandura, A. (1962). Social Learning through Imitation. Lincoln, NE: University of Nebraska Press. 2. Bechinie, M., Murtinger, M, Tscheligi, M (2010). Social Skills for UX Consultants. Communication on the Job. User Experience, Volume 9, Issue 4, 26–28 3. European Commission (2010). The European eGovernment Action Plan 2011–2015. Harnessing ICT to promote smart, sustainable & innovative Government. Brussels. 4. http://eur-lex.europa.eu/ LexUriServ/LexUriServ. do?uri=COM:2010:0743:FIN:EN:PDF (abgerufen am 27.06.2013) 5. European Commission (2013a). Digital Agenda for Europe. Pillar VII: ICT-enabled benefits for EU society. https://ec.europa. eu/digital-agenda/en/our-goals/pillar-vii-ictenabled-benefits-eu-society (abgerufen am 27.06.2013) 6. European Commission (2013b). EU Scoreboard: Annual digital progress rankings. Brussels. http://europa.eu/rapid/ press-release_IP-13–528_en.htm (abgerufen am 27.06.2013) 7. European Commission (2013c). Public Services Online. Digital by Default or by Detour? Assessing User Centric eGovernment performance in Europe – eGovernment Benchmark 2012. Brussels. https://ec.europa. eu/digital-agenda/sites/digital-agenda/files/ eGov_Benchmark_2012%20background%20 report%20published%20version%200.1%20. pdf (abgerufen am 27.06.2013) 8. Hauschildt, J (2003). Promoters and champions in innovations: Development of a research paradigm. In L. V. Shavinina (Ed.), The international handbook on innovation (pp. 804–811). London, UK: Pergamon. 9. Kerth, N. L. (2001). Project retrospectives: a handbook for team reviews. New York: Dorset House Publishing. 10. West, D., Gilpin, M., Grant, T., Anderson, A. (2011). Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today. Cambridge (MA, USA): Forrester Research, Inc.

255

(Über-) Leben mit Anforderungen

Thom Scheiner User Interface Design GmbH Claudius-Keller-Straße 3c, 81669 München thom.scheiner@uid.com

Abstract Mit Anforderungen an Benutzungsschnittstellen hat jeder schon seine Erfahrungen gemacht. Das Zusammentragen von Anforderungen kann Spaß machen; sie dann zu dokumentieren, aktuell zu halten und immer wieder Überblick über den aktuellen Stand im Projekt zu geben erinnert aber schon den Verzehr von trocken' Brot. In kleineren Projekten und bei Kunden, für welche die Arbeit von User Experience Consultants Neuland ist, fällt es auch schwer, Begeisterung für diesen Teil der Arbeit zu wecken und entsprechend das Budget dafür bewilligt zu bekommen. Der Beitrag beschreibt Erfahrungen aus mehreren Projekten unterschiedlicher Komplexität: - Argumente für die Diskussion mit Kunden, warum Anforderungen überhaupt erhoben werden müssen - Vorschläge zur Dokumentationsweise von Anforderungen, abhängig von der Projektkomplexität - und mit "Wow"-Effekt - Pro und Con bezüglich der Dokumentation mittels Tabellenkalkulation (Excel) - und wie man's nicht machen sollte - Best practice zum Angleichen unterschiedlicher Abdeckungsniveaus einzelner Themenkomplexe - und was man von seinem Product Owner erwarten können sollte.

1. Überblick Anforderungen von Nutzern in die Umsetzung zu führen ist Bestandteil jedes UX-Projekts. Für den UX-Designer bedeutet dies, gut verargumentieren können zu müssen – denn das strukturierte Arbeiten mit Anforderungen kostet viel Zeit. Hat er ein Budget dafür bewilligt bekommen, müssen Anforderungen zunächst erhoben und dann auch – gerne mit Wow-Effekt – dokumentiert werden – egal ob auf Papier, mit Excel oder einem professionellen Anforderungs-Tool. Wichtig ist, den Dokumentationsaufwand im Griff zu haben, über alle Themenfelder hinweg ein vergleichbares Detailniveau zu erreichen und vom Kunden eine Aussage dazu zu erhalten, welche Anforderungen wichtiger sind als andere. Im Folgenden erläutere ich meine Erfahrungen als UX-Designer und Requirements Engineer aus zahlreichen kleinen und mittleren Projekten (vornehmlich

256

Industry-Bereich) sowie aus zwei mehrjährigen Programmen bei Vor-Ort-Einsätzen in der Kundenorganisation. UX-Designern und Projektleitern gebe ich Argumente für die Budgetierung sowie Tipps zur Erhebung und Dokumentation von Anforderungen an die Hand. 2. Anforderung als Bestandteil von UX – und Argumentation gegenüber dem Kunden Ob Projektleiter, Product Owner, User Expert/Endnutzer, Software-Entwickler oder UX-Designer: Jeder Stakeholder hat einen anderen Blickwinkel auf das Produkt. Eine Aufgabe beim Erheben und Dokumentieren von Anforderungen ist es, diese sich stark unterscheidenden Blickwinkel einzunehmen und zwischen ihnen zu vermitteln. Übliche Quellen für die Anforderungserhebung sind: –– Interviews mit Projektbeteiligten sowie mit den Nutzern

Keywords: /// Requirements /// Anforderungen /// Dokumentation /// Erfahrungsbericht /// Praxis

–– Dokumente aus dem Projekt selbst (Projektbeschreibung, Machbarkeitsstudien, etc.) –– Ergebnisse von Business Analysten –– Tools, die momentan zur Erledigung der Aufgaben herangezogen werden –– Infos über oder von Nutzer(n) – etwa von der Service-Hotline oder aus Nutzerforen Das strukturierte Erfassen von Anforderungen hilft, die Informationen trotz ihrer Vielzahl im Blick zu behalten. Der Aufwand dafür ist nicht zwangsläufig hoch, muss aber in jedem Fall einkalkuliert und im Projektbudget verankert werden. Mögliche Argumente dafür sind: –– Anforderungen geben Klarheit darüber, welche Themen umfassend und welche weniger/nicht bearbeitet werden (siehe Abschnitt 5). –– Anforderungen, die diesmal noch nicht berücksichtigt werden, können für den nächsten Release herangezogen werden.

Usability Professionals 2013 Enterprise/Government UX

–– Für eine Reihe von Produkt-Klassen verlangt der Gesetzgeber den Nachweis, dass Anforderungen strukturiert erhoben und im Projektverlauf erfüllt wurden (etwa im Medical-Bereich nach DIN EN 60601–1-6 und DIN EN 62366). –– Die Arbeit mit Anforderungen hilft, einen Themenkomplex rasch zu durchdringen – und auf neue Ideen zu kommen (siehe Abschnitt 4.6). –– Anforderungen stellen eine Vereinbarung dar zwischen PO und UX-Designer, wodurch die Erwartungen besser geklärt werden können. –– Anforderungen zeigen allen Projektbeteiligten, was überhaupt schon als Aufgabenfeld erkannt ist: Was als Anforderung beschrieben ist, kann auch bearbeitet werden; was nicht gelistet ist, hat niemand auf dem Schirm. –– Der Status von Anforderungen macht den Fortschritt der UX-Arbeit für den Kunden sichtbar. –– Anforderungen geben Sicherheit für Kunden und UX-Designer – „Selbstverständliches“ versteht sich nicht von selbst und führt schnell zu Missverständnissen oder Ärger – etwa dass in einer Software für Ingenieure neben SIEinheiten (metrisch) auch das imperiale Einheitensystem unterstützt wird. –– Wenn die Zeit knapp wird, gibt die Priorisierung von Anforderungen vor, was dem Kunden eventuell weniger wichtig ist –– Werden Anforderungen frühzeitig erhoben, ist man sicherer vor späteren grundsätzlichen Änderungen – je später sie kommen, desto härter schlagen Anforderungen zu. 3. Erheben von Anforderungen Je nach Produkt und Kunde stehen die o.g. Quellen in unterschiedlichem Maß zur Verfügung. Es ist aber auch stark vom Budget abhängig, wie lange man wo auf die Jagd geht. In den kürzeren meiner Projekte geschah die meiste Anforderungsarbeit in Workshops mit Kunden. Meine Erfahrungen daraus:

–– Zumindest im Industry-Bereich gibt es viele Produzenten, die viel über die Bedürfnisse ihrer Kunden zu wissen glauben und deshalb sich selbst als Quelle für Nutzeranforderungen empfehlen. Zudem ist der Zugang zu Kunden in dieser Branche tatsächlich schwieriger, da sie in Marktforschungspanels kaum auftauchen und für Feldstudien neben der Arbeitskraft oft auch gleich eine Maschine oder gar Produktionsteile blockiert wären. –– Je mehr Personen an Workshops teilnehmen und über Anforderungen diskutieren, desto intensiver wird eine jede Anforderung beleuchtet – wodurch meist mehr relevante Blickwinkel eingebracht und die Anforderung am Ende stabiler werden; und desto länger dauern die Diskussionen – das kann auch in die Stunden gehen. –– Für mich UX-Designer sind solche Workshops eher frustrierend: man kommt nur langsam voran, die Diskussionen driften teils stark ab, es ist viel Arbeit die Leute beim Thema zu halten. Das Ergebnis scheint dürftig – eine Liste mit einigen Einträgen. Und auf beiden Seiten bleibt das Gefühl, mit dem eigentlich Erwarteten (irgendwas das eher nach UI aussieht) nicht vorwärts gekommen zu sein. Die Kunden eigenständig Anforderungen dokumentieren zu lassen funktioniert nur, wenn sie genau instruiert werden und der UX-Designer regelmäßig reinschaut. In kleineren Projekten versuchte ich das einige Male – mit sehr gemischten Ergebnissen. Hier fehlte der Erfolgsfaktor der regelmäßigen (!) Teilnahme des UX-Designers, denn dafür war kein Budget da. Mein erstes mehrjähriges Vor-Ort Programm, für das ich zunächst 90% als Requirements Engineer arbeitete, bot bessere Möglichkeiten für die Arbeit mit Anforderungen. Es gab strukturierte Informationen von Business Analysten – etwa über die unterschiedlichen Abläufe in den einzelnen Unternehmen des Kunden sowie über die Herstellungsweise des jeweiligen Produkts. Daneben hatte ich einfachen Zugang zu User Experts sowie zu regelmäßigen

Besprechungen mit Software-Entwicklern/Architekten. Dem Product Owner (diese Rolle gab es in meinen kleineren Projekten nicht) legte ich regelmäßig Anforderungen zu nun komplett abgebildeten Themenbereichen vor, um diese abnehmen zu lassen. Insgesamt war das viel, aber auch vereinbarte Arbeit, und sie führte zu einer hohen Reife der Anforderungen. Bei meinem zweiten mehrjährigen VorOrt Programm drehten wir von Projekt zu Projekt Lernschleifen, ehe wir einen guten Modus Operandi gefunden hatten. Grundsätzlich wurde hier Wert gelegt auf dokumentierte Anforderungen, wenngleich der kalkulierte Aufwand dafür eher als hoch empfunden wurde. Stets standen uns sämtliche Quellen zur Verfügung, und Anforderungen wurden auch hier dem jeweiligen Product Owner vorgelegt. Im Sommer 2012 initiierten meine Kollegen der dortigen zentralen UX-Abteilung, dass sich eine zehnköpfige Gruppe von User Experts unter Leitung eines Product Owners für die nächsten neun Monate wöchentlich traf. Zunächst sollten die Nutzeraufgaben definiert werden (es wurden ca. 30), später dann in kleineren Gruppen zwischen den wöchentlichen Sitzungen alle einzelnen Aufgaben genau beschrieben werden. Bei den wöchentlichen Treffen waren stets ein Business Analyst sowie ein UX-Designer anwesend und lenkten die Diskussion, so dass am Ende die einzelnen Aufgaben vergleichbar detailliert beschrieben vorlagen. Beim Start eines Projekts im Frühjahr 2013 lag damit idealer Input für uns UX-Designer vor. 4. Dokumentieren von Anforderungen (und wie besser nicht) Für eines der Angebote bei meinem zweiten Programm überschlug ich, wie viel Aufwand eine einzelne Anforderung verursacht zwischen dem initialen Dokumentieren mit allen Attributen in einem professionellen Tool einerseits und dem Verknüpfen mit einer konzeptuellen Lösung andererseits (die Erhebung der Anforderung sowie

257

Aufwand (digital)

Prozessschritt

Aufwand (Post-It)

Initiales Aufschreiben mit allen Attributen

5 min

1 min

Besprechung mit PO

3 min

15 min

Nivellieren

5 min

Besprechung mit PO

4 min

Beziehungen und Status im System aktualisieren

3 min

1 min

Doubletten managen

2 min

1 min

Anhand einer Lösung präzisieren und neue Fragen klären

5 min

Besprechung mit PO

2 min

Lösung verknüpfen und Status im System aktualisieren

5 min

1 min

Präzisieren und neue Fragen klären

Verbleibenden Datensatz digitalisieren

2 min

Gesamtaufwand je Anforderung

49 min

40 min

Tab. 1. Kalkulation für den Aufwand, den eine einzelne Anforderung während ihres Lebenszyklus verursacht (kalkuliert für digitale Erfassung in einem professionellen Tool sowie für Erfassung mittels Post-Its und nachträglicher Digitalisierung

das Entwickeln einer konzeptuellen Lösung sind nicht enthalten); Ergebnis: 49 Minuten – je Anforderung, wohlgemerkt! Wir fanden aber auch einen Weg, ein Fünftel dieses Aufwands einzusparen – und leider auch einen anderen Weg, um die Arbeit mit Anforderungen ohne große Not ziemlich unhandlich zu machen. 4.1. Aufwand durch Prozessschritte Nachdem eine Anforderung initial festgestellt wird, hat sie noch einige Bearbeitungsschritte vor sich, ehe sie ihren finalen Stand erreicht: –– Erste Dokumentation: Die Anforderung sollte strukturiert festgehalten und damit für den weiteren Projektverlauf zuverlässig erreichbar sein. –– Abgleich mit User Experts und Product Owner: Diese Quellen helfen, die Bedeutung der Anforderung zu erfassen und ggf. weitere noch zu erforschende Themen zu definieren. –– Präzisieren und Klären neuer Fragen: Die soeben definierten weiteren

258

Themen wirken auch zurück auf die vorliegende Anforderung; dadurch muss die Anforderung wieder überarbeitet werden – etwa indem sie verknüpft wird mit anderen (neuen) Anforderungen. –– Nivellieren: Die Anforderung dringt in eine gewisse Tiefe eines Themas ein und hilft, dieses Thema besser zu beschreiben. Andere Themen mit ähnlicher Wichtigkeit sind möglicherweise viel präziser oder auch oberflächlicher durch Anforderungen abgedeckt. Es sollte also ein Prozess stattfinden, um die unterschiedlichen Themen auf ein vergleichbares Niveau zu bringen. Siehe Abschnitt 4.6. –– Ableich mit Product Owner und Aktualisieren des Status: Eine weitere Besprechung des aktuellen Stands der Anforderung mit dem Product Owner; eventuell folgen daraus weitere Aufgaben, ansonsten ist nur der neue Status der Anforderung festzuhalten. –– Doubletten managen: Mit zunehmender Zahl von Anforderungen und v.a. bei mehreren Autoren können auch Doppelungen von Anforderungen auftreten.

Diese sollten von Zeit zu Zeit identifiziert, markiert und entsorgt werden. –– Anhand einer Lösung präzisieren und neue Fragen klären: Eine mögliche Lösung für die Anforderung liegt vor – und diese Lösung mag zu völlig neuen Fragen führen, welche ihrerseits wieder zu klären und in der Anforderung dokumentiert werden sollten. –– Besprechung mit PO: Der Product Owner akzeptiert die präsentierte Lösung oder weist sie zurück. Diese Information wird bei der Anforderung vermerkt, und die akzeptierte Lösung wird mit der Anforderung verknüpft. –– Datensatz digitalisieren: Sofern noch nicht geschehen, wird die Anforderung schließlich digital erfasst. All diese Prozessschritte verursachen Aufwand. Da die Arbeit mit Anforderungen oft zwischen anderen Projektschritten erfolgt und sich dadurch zeitlich schwer fassen lässt, habe ich versucht einen „Stückpreis“ für die Anforderungen zu ermitteln – also den Aufwand, den eine einzelne Anforderung während ihres Lebenszyklus verursach. [Tab. 1] Die Kalkulation in Tabelle 1 enthält Posten, die nicht bei jeder Anforderung anfallen. So gibt es durchaus Anforderungen, die sofort klar und umfassend formuliert sind und ohne weitere Änderungen auskommen; ausgleichend gibt es aber auch Anforderungen, die wesentlich aufwändiger handzuhaben sind. 4.2. Vergleich der Dokumentation per Post-Its und digitaler Erfassung Auf Papier generell geht die Dokumentation schnell von der Hand und kann dazu beitragen, die Projektbeteiligten ins Boot zu holen und sie direkt in die Arbeit zu integrieren. Sie eignet sich aber nicht für jedes Szenario – etwa nur dann, wenn die Anforderungen mit anderen Standorten geteilt werden müssen. –– Stärken der Dokumentation mittels Post-Ist –– Bekannt: Jeder kennt die Tools, und die Organisation auf der

Usability Professionals 2013 Enterprise/Government UX

Kriterium

Digital (Excel)

Digital (Profi-Tool)

Post-It

Sollen mehrere Personen zugleich an den Anforderungen arbeiten?

(nur eingeschränkt; Gefahr von Datei-Wirrwarr)

unterstützt

Soll die Abbildung der Anforderungen Diskussionen anregen?

(eher trist und technisch)

diskussionfördernd

Was ist wichtiger: Stabilität oder Flexibilität?

Stabilität

Flexibilität

Müssen die Anforderungen archiviert werden?

Archivierbar

(nur per Foto oder spätere Digitalisierung archivierbar)

Wird für ein feststehendes Team dokumentiert, oder kommen später andere Nutzer hinzu?

Wechselnde Nutzer

Feststehendes Team

Ist es wichtig, Anforderungen vollständig definiert zu haben?

Vollständig definiert

Quick & dirty

Müssen die Anforderungen an andere Nutzer verteilt werden können?

Verteilen möglich

(nur per Foto oder spätere Digitalisierung verteilbar)

Ist Versionierung bedeutsam?

(nur eingeschränkt)

Versionierbar

(nur per Foto versionierbar)

Ist Zugriffskontrolle bedeutsam?

(nur eingeschränkt)

Kontrollierbar

nicht unterstützt

Tab. 2. Kriterien für die Auswahl der Dokumentationsart

Arbeitsfläche (thematische Gruppierung, ggf. Farbkodierung) ist leicht erklärt. Man muss also kein Computerprogramm beherrschen dafür. Außerdem stehen bei Post-Its – anders als bei Software – sicher auch immer genug kostenlose Lizenzen zur Verfügung;-) –– Alles im Blick: Auf einer großen Wand lassen sich die Post-Its nach Themenbereichen gruppiert anordnen. Man kann mit Fäden, Linien oder separaten Papierbögen arbeiten – und damit schnell den Fokus auf Überblick oder Detail einstellen. Auch bei vielen Anforderungen lassen sich hier Zusammenhänge einfach abbilden und nachvollziehen. –– Potenziell riesige Arbeitsfläche: Je nach Platzverhältnissen kann man Wände, Fenster, die Decke oder auch mobile Raumteiler verwenden – es wird sicher mehr Platz sein als ein 24-Zoll-Monitor.

–– Gleichberechtigt und spontan: Neue Informationen lassen sich ohne spürbaren Aufwand hinzufügen und verorten: einfach ein Post-It schreiben und aufkleben. Jeder hat dieselben Möglichkeiten und Rechte, man muss nicht um Tastatur und Maus bitten oder das Programmfenster wechseln. –– Erweiterbar: Eine Handskizze, ein ausgedrucktes Dokument, ein Foto, ein Workflow, irgendein anderes Artefakt – was hilft lässt sich i.d.R. mit dazu hängen und von allen nutzen. –– Schnell: Die Arbeit auf Papier geht sehr rasch vonstatten. –– Stärken der digitalen Dokumentation –– Typische Funktionen: „Rückgängig“, „Senden an“, „Copy&Paste“; bei der Papier-Variante hingegen bleibt eine gezogene Linie sichtbar. –– Versionierung und Tracking: Gelöschtes wiederherstellen oder auch nachvollziehen können, wer einen Status geändert hat. Gute

Tools bieten solche Funktionen – aber in meiner bisherigen Arbeit brauchte ich diese Funktionen noch nicht. –– Luftzug-resistent: Kein Windstoß bringt meine Anforderungen zum Wanken. Wenn Sticky Notes schon eine Weile hängen, muss man hingegen vielleicht nur schnell dran vorbeigegangen sein um sie hinabtrudeln zu lassen. –– Lokal gebunden: Verteilt arbeitende Teams brauchen einfachen Zugriff auf die Anforderungen. Als Datei oder Datenbank kann man sie einfach mit anderen Büros teilen, in der Papierform wird das schwierig. –– Informationstiefe: Digital kann man unheimlich viele Daten je Anforderung erfassen. Auf ein Post-It bekommt man hingegen nur wenige Informationen – vielleicht die Quelle noch auf die Rückseite, aber das erfordert schon viel Disziplin.

259

Der wesentliche Erfolgsfaktor für mein erstes solches Projekt war, dass wir genau jene Phase der Anforderungsarbeit mit ökonomischen Post-Its bewältigten, in welcher die Anforderungen am intensivsten bearbeitet wurden: Neue Informationen erforderten neue Formulierungen (Post-It neu schreiben), neue Informationen erforderten Ergänzungen (auf dem Post-It nachtragen), Anforderungen mussten neu gruppiert werden (Post-Its umhängen). Für die Arbeit an einem bestimmten GUI-Thema wollte man sich auf eine Gruppe von Anforderungen konzentrieren (Poster mit allen Post-Its eines Themas mitnehmen), Diskussionen mit dem Product Owner verwarfen eine Anforderung wieder, etc. Diese Aktionen kosteten mit Post-Its nur wenig Zeit, diese Phase der Anforderungsarbeit verursachte also kaum Aufwand, und sie signalisierte anderen Beteiligten Offenheit für neuen Input. Als dann die Anforderungen über mehrere Iterationen in die finale Form hinein diskutiert worden und damit ziemlich stabil waren, zogen wir sie in einem Kraftakt um in die digitale Welt (siehe letzter Prozessschritt in Tabelle 1). Für all jene Anforderungen, die der natürlichen Selektion zum Opfer gefallen waren, fiel dieser Aufwand schon nicht mehr an. 4.3. Kriterien für die Wahl der Dokumentationsart Ob man nun digital oder per Post-Its dokumentiert, hängt ab von mehreren Kriterien. Kriterien für die Auswahl der Dokumentationsart2 zeigt, welche Kriterien man berücksichtigen muss und welche Dokumentationsart das Kriterium unterstützt. Es empfiehlt sich, diese Kriterien vorab mit dem Kunden zu klären, denn ein späterer ungeplanter Wechsel der Dokumentationsart sorgt für Frust und zusätzlichen Aufwand. [Tab. 2] 4.4. Professionelle RETools vs. herkömmliche Tabellenkalkulationen Sofern in der Organisation für das Anforderungsmanagement bereits eine Software eingeführt wurde und man durch dieses

260

Abb. 1. Anforderungsschablone (schematisch, nach Rupp)

Abb. 2. Excel-Template für vollständige Anforderungstexte – leider kaum benutzbar

nicht zu sehr eingeschränkt wird im kreativen Arbeiten, sollte man diese Software natürlich unbedingt verwenden und dem Kunden damit die Nutzung der eigenen Arbeitsergebnisse sehr erleichtern. Hat ein Kunde noch keine Software hierfür im Einsatz, so kann man aus meiner Sicht mit den üblichen Tabellenkalkulationen (Excel und Co.) loslegen. 4.5. Eine ExcelFormel für mehr Chaos Die Qualität der Anforderung hängt ab vom Wissen des Autors; sind mehrere Autoren beteiligt, so schwankt mitunter die Qualität der Dokumentation. Ich wollte unter Berücksichtigung der Anforderungsschablone von Rupp¹ [Abb. 1] sicherstellen, dass alle Autoren gleich von Beginn an zu jeder Anforderung alle benötigten Informationen beitrügen. Hierzu legte ich in Excel ein stark schematisiertes Arbeitsblatt an – und wie Dr. Jekyll war ich mir nicht bewusst was ich da erschuf. Je Informationsbaustein spendierte ich eine Spalte – also etwa je für „Subject“, für „Prio“, für „Action“ (Spalten I bis O in Abbildung 2). Der Autor konnte anhand leerer Zellen leicht erkennen, ob er vielleicht wichtige Informationsbausteine noch nicht bereitgestellt hatte.

In einer separaten Spalte (Spalte F in Abbildung 2) baute ich eine Formel ein mit dem zentralen Befehl „Concatenate“ / „Verketten“. Diese Formel zog die Informationen aus den gerade genannten Spalten an (z.B. „The system“, „MUST“, „provide“, …) und verband sie zu einem flüssig lesbaren Text („The system MUST provide“ …). In dieser Spalte stand dann die Anforderung schön lesbar drin. [Abb. 2] Doch jedes Mal wenn man etwas am Anforderungstext ändern wollte, war man erst mal frustriert: Man wechselte in der Spalte mit der schön lesbaren Anforderung in den Bearbeitungsmodus – und das war Spalte F, die aber nur eine Formel enthielt. Man musste also erst nach der richtigen Spalte suchen (Spalte I bis O) und dort den Text ändern. Und startete bei der nächsten Anforderung sicher wieder in der falschen Spalte. Das Problem war wirklich groß – alle drei Autoren stolperten andauernd über diese Formel-Spalte. Die beiden Vorteile (Vollständigkeit der Anforderung und gute Lesbarkeit für den Leser) traten rasch, sehr rasch in den Hintergrund. Wir behielten dieses Schema bei bis zum Ende des Projekts, aber seither ist klar dass wir es so nicht wieder machen wollen. 4.6. Nivellieren Bei den Nutzeraufgaben eines bestimmten Produkts, an dem ich arbeitete, gab es drei

Usability Professionals 2013 Enterprise/Government UX

Aufgaben, die thematisch eng beisammen lagen: Anlegen von Reference Cases, von Remindern und von Subscriptions. Diese Aufgaben waren nun unterschiedlich tief mit Anforderungen abgedeckt, und wir wollten abklären, ob sich Teilaufgaben davon überschnitten. Eine Kollegin trug deshalb alle Anforderungen zu diesen drei Aufgaben zusammen, analysierte sie und übertrug sie der Vergleichbarkeit halber in eine Matrix (siehe Matrix zum Niveau-Vergleich der Anforderungsabdeckung dreier Aufgaben3). Die Analyse bezog sich auf diese Aspekte: –– Gegenstand (Aufgabe vs. Akte) –– Darstellung (Überblick, visueller Hinweis, Push-Notification) –– Informationsbedarf (notwendige Informationen zur Beurteilung, ob man diese Akte öffnen will) –– Auslöser (selten oder besonders, notweniger Input von anderen, Neugier) –– Methode (Push vs. Pull) –– Zweck (Qualitätssicherung, Vollständigkeit, Neugier) –– Aktuell genutzte Tools und Prozesse Dann prüften wir je Punkt, ob die drei Aufgaben ähnlich präzise durch Anforderungen abgedeckt waren. War bisher z.B. bereits klar dass die Liste der Reminder Änderungen hervorheben muss, so bemerkten wir dass der Bedarf für die Darstellung von Subscriptions noch unklar war und wir hier weitere Informationen benötigten. Anhand dieser Matrix erkannten wir, bei welchen Aufgaben ein Aspekt zu ungenau oder unnötig detailliert dargestellt war. Wir konnten daraufhin die Anforderungen präzisieren bzw. entschlacken, so dass sie schlussendlich die drei Aufgaben unter jedem Aspekt in vergleichbarer Qualität abdeckten.

5. Aufgaben für den Product Owner Anforderungen bestimmen maßgeblich das Endergebnis des Produkts und verpflichten die Projektbeteiligten. Deshalb sollte von Kundenseite geklärt werden welche Anforderungen tatsächlich relevant sind und wo für eine Entscheidung noch

Abb. 3. Matrix zum Niveau-Vergleich der Anforderungsabdeckung dreier Aufgaben

Informationen fehlen. Der Product Owner sollte diese Aufgabe wahrnehmen; doch manche verstehen gar nicht wie wichtig diese Aufgabe ist – so dass wir sie in diese Richtung leiten müssen. Priorisierung: Der PO muss klären welche Anforderungen wichtig und welche weniger wichtig sind. Andernfalls muss der UX Designer entweder glatt alle Anforderungen lösen, was häufig Zeit und Budget sprengen würde; oder er muss selbst priorisieren, wodurch aber das Produkt in eine andere Richtung gehen könnte als vom Kunden intendiert. In einem meiner Projekte hatte der PO auch nach neun Monaten noch keine einzige Anforderung priorisiert; in einem anderen Projekt ging ich mit dem PO gemeinsam alle Anforderungen durch – und hatte am Ende nahezu ausschließlich Anforderungen mit „MUST“-Einstufung (was nicht praktikabel ist, da man dann doch wieder selbst priorisieren muss).

nicht selbst beantworten kann, sollte er passende Ansprechpartner nennen können. Diskussionen zu bedeutenden Themen: Durch die Anforderungsarbeit stößt man immer wieder auf grundsätzliche Fragen, die sich dann nicht aus dem Projekt heraus schnell klären lassen. Oder man entwickelt weitreichende Vorschläge, die z.B. einen Umbau der Prozesse innerhalb des Unternehmens mit sich bringen könnten. Die hierzu nötigen Diskussionen kann man selbst führen, sofern der Kunde einen gewähren lässt; oder man gibt sie an den PO ab, der dann im Sinne des besseren Produkts diese Vorschläge durch die Instanzen diskutieren soll.

¹ Rupp, Chris; SOPHIST Group: „RequirementsEngineering und -Management: Professionelle, iterative Anforderungsanalyse für die Praxis “, 5. Auflage; Carl Hanser Verlag GmbH & Co. KG

Lücken und Fragen: Der PO sollte die Domäne kennen und Lücken in den Anforderungen identifizieren können (siehe auch Abschnitt 4.6). Sofern er offene Fragen

261

262

Branchentrends

263

Branchenreport UX/Usability 2013 Ergebnisse einer Befragung unter UX/Usability Professionals in Deutschland Sarah Diefenbach Folkwang Universität der Künste Universitätsstraße 12 45141 Essen sarah.diefenbach@folkwang-uni.de

Nina Kolb Technische Universität Darmstadt Alexanderstraße 10 64283 Darmstadt nina.kolb@stud.tu-darmstadt.de

Abstract Mit dem jährlichen Branchenreport User Experience/Usability dokumentiert die German UPA (Berufsverband der deutschen Usability und User Experience Professionals, www. germanupa.de) die Situation von Usability und User Experience Professionals in Deutschland. Die Angaben von rund 350 Personen liefern Informationen zu Ausbildungs- und Karrierewegen, Arbeitsfeldern und Aufgabenbereichen, Verdienstmöglichkeiten, Herausforderungen bei der Unternehmensgründung sowie den wichtigsten Arbeitgebern der Branche.

1. Einleitung Mit dem Branchenreport Usability informiert die German UPA (Berufsverband der deutschen Usability und User Experience Professionals, www.germanupa.de) über die aktuelle Situation und Entwicklungen im Arbeitsfeld Usability/User Experience. Personen, die eine Tätigkeit im Usabilitybzw. User Experience-Bereich anstreben, erhalten so eine Übersicht über mögliche Ausbildungswege, eine realistische Einschätzung des Berufsfelds sowie eine Übersicht über potentielle spätere Arbeitgeber. Bereits in der Branche Tätige erhalten Anhaltswerte zur Einordnung ihrer momentanen Situation im Vergleich zu Kollegen. Neben einer faktenbasierten Beschreibung schildert der Branchenreport die Arbeitssituation der Befragten auch aus deren subjektiver Perspektive und dokumentiert erlebte Herausforderungen und Meinungen zu zukünftigen Aufgaben des Berufsverbands. Fragen hierzu umfassen beispielsweise die wichtigsten Faktoren für Zufriedenheit und Unzufriedenheit unter Arbeitnehmern, Schwierigkeiten bei der Unternehmensgründung im Usability-Bereich unter Selbstständigen, Unterschiede zwischen „Usability“ und „User Experience“ oder die Frage nach zukünftigen Aufgaben der Branche. So bieten die im Branchenreport gebündelten

264

Informationen auch Anknüpfungspunkte für Diskussionen zur Weiterentwicklung und Professionalisierung des Berufsbilds und bilden eine wichtige Grundlage für die Arbeit des Berufsverbands. Ermöglicht wird der Branchenreport aber erst durch die regelmäßige Beteiligung von Usability und User Experience Professionals an unserer jährlichen landesweiten Befragung. Bei allen Teilnehmern möchten wir uns an dieser Stelle herzlich bedanken!

Daniel Ullrich Technische Universität Darmstadt Alexanderstraße 10 64283 Darmstadt ullrich@psychologie.tu-darmstadt.de

Keywords: /// Usability /// User Experience /// Ausbildung /// Weiterbildung /// Arbeitssituation /// Gehaltsspiegel /// Branche

Demografie. Erfragt wurden Alter, Geschlecht, Berufserfahrung sowie die Region des Arbeitsplatzes. Aus- und Weiterbildung. Erfragt wurden akademischer Abschluss, Studienfach und Universität, Informationen zu Berufs- und Zusatzausbildungen, sowie berufsbegleitende Aktivitäten zur Weiterbildung.

2. Aufbau der Befragung

Momentane Position. Erfragt wurden Arbeitsbereiche, Aufgabenschwerpunkte, sowie weitere Angaben zur Charakterisierung typischer Projekte im Rahmen der momentanen Position (z.B. Projektdauer, beteiligte Berufsgruppen). Zusätzlich wur den spezifische Fragen zur Arbeitssituation an Angestellte und Selbstständige gerichtet: Unter den Angestellten wurden beispielsweise Jobtitel, Stellenumfang, Dauer der Unternehmenszugehörigkeit, Größe des Unternehmens, Bruttojahresgehalt sowie die Zufriedenheit beim aktuellen Arbeitgeber erfragt. Selbstständig Tätige hingegen wurden beispielsweise befragt zum Zeitpunkt der Unternehmensgründung, ihrem üblichen Stunden- oder Tagessatz, ihrer Einschätzung der Auftragslage, sowie zu allgemeinen Herausforderungen bei der Unternehmensgründung im Bereich UX/Usability.

Die Befragung umfasste insgesamt vier thematische Bereiche:

Branche. Erfragt wurden Meinungen zu Schwierigkeiten und notwendigen

Wie auch in den Vorjahren erfolgte die Erhebung mittels Online-Befragung im Zeitraum von Februar bis Mai. Die Teilnehmer wurden über den German UPA Newsletter sowie durch Einladungen in Usability/User Experience-Gruppen in sozialen Netzwerken wie Xing oder Facebook gewonnen. Von insgesamt 513 Personen machten 356 Angaben zu der Mehrzahl der Fragen, diese bilden die Grundlage für die folgenden Auswertungen. Etwas mehr als die Hälfte (204/356; 57%) der Teilnehmer beteiligte sich dieses Jahr erstmalig an der Befragung zum Branchenreport Usability, die restlichen hatten bereits im Vorjahr teilgenommen.

Usability Professionals 2013 Branchentrends

Veränderungen der Branche, sowie die bekanntesten Unternehmen der Branche im deutschsprachigen Raum. Zudem wurde in diesem Jahr ein Meinungsbild zur persönlichen Definition und Abgrenzung der Begriffe „User Experience“ und „Usability“ erhoben. Im Folgenden werden die wichtigsten Ergebnisse der Befragung zum Branchenreport Usability 2013 vorgestellt. Bei Fragen mit vorgegebenen Antwortkategorien basiert die Auswahl der Kategorien in der Regel auf den häufigsten Nennungen der Vorjahre. Unterschiede werden als signifikant bezeichnet, wenn eine Irrtumswahrscheinlichkeit von < 5% vorliegt (p < .05). 3. Demografie 57% der Teilnehmer sind männlich, 43% weiblich. Das Durchschnittsalter der Befragten liegt bei 35 Jahren (sd=7,4; min=21; max=67), wobei das Durchschnittsalter unter den männlichen Teilnehmern (m=35,9) signifikant höher ist als unter den weiblichen Teilnehmern (m=33,6). Die Berufserfahrung im Bereich UX/Usability variiert zwischen 0 und 35 Jahren, beim Großteil der Befragten (79%) sind es allerdings nicht mehr als 10 Jahre (med=5). Der Durchschnittswert liegt bei 6,8 Jahren Berufserfahrung (sd=5,3). Die Region des Arbeitsplatzes wurde mittels Angabe des Bundeslandes abgefragt. Spitzenreiter mit der größten Zahl von Usability Professionals ist Bayern, hier arbeiten 21% der Befragten, gefolgt von Berlin/Brandenburg (14%) und Baden-Württemberg (14%). Ebenfalls stark vertreten sind NordrheinWestfalen und Hamburg/ Schleswig-Holstein mit jeweils 11% sowie Hessen mit 7%. In allen anderen Bundesländern arbeiten jeweils unter 6% der Befragten. 4. Aus- und Weiterbildung 4.1. Ausbildung Die große Mehrheit der Befragten (340 Personen, 96%) hat ein Studium absolviert,

Abb. 1. Relevanz verschiedener Aktivitäten zum Wissenserwerb im Bereich UX/Usability

wobei 51% ihr Studium mit einem Diplom, 9% mit einem Bachelor of Science, 7% mit einem Bachelor of Arts, 7% mit einem Master of Science und 5% mit einem Master of Arts abschlossen; 6% haben anschließend promoviert (Angaben zum höchsten akademischen Abschluss). Wie auch im Vorjahr ist das meist studierte Fach Psychologie (51 Personen), auf den zweiten Platz gerückt ist dieses Jahr die Informatik (40 Personen), gefolgt von Medieninformatik (39 Personen) sowie Digitale Medien (21 Personen). Der meistgenannte Studienort ist in diesem Jahr erneut Berlin, vertreten durch die TU Berlin (10 Personen), die Humboldt Universität (8 Personen), sowie die FU Berlin (5 Personen). Die insgesamt meistbesuchten Universitäten sind die FH Kaiserslautern sowie die Universität Hamburg (jeweils 14 Personen), gefolgt von der Hochschule der Medien Stuttgart (12 Personen). Unter den insgesamt 107 Personen (30%), die anstelle oder zusätzlich zum Studium einen Ausbildungsberuf erlernt haben, sind mit 23 Personen die Mediengestalter/innen am häufigsten vertreten. Danach folgen mit 9 Nennungen die Fachinformatiker/innen.

4.2. Aktivitäten zur Weiterbildung 79 Personen (22%) haben eine speziell auf den Bereich UX/Usability ausgerichtete Zusatzausbildung absolviert. Am häufigsten genannt wurden hier die Ausbildung zum Usability Consultant am artop Institut der HU Berlin (31 Personen) sowie die Ausbildung zum Usability Engineer am Fraunhofer-Institut für Angewandte Informationstechnik (FIT, 22 Personen). Beispiele weiterer Nennungen sind Certified Usability Analyst beim Ausbildungsanbieter Human Factors International oder die Ausbildung zum Usability Experte an der Usability Academy in Kaiserslautern (jeweils 2 Personen). Abbildung 1 zeigt die Relevanz verschiedener Informationsquellen und Aktivität zum Erwerb von UX/Usability-Wissen im Berufsalltag. Angegeben ist jeweils der Anteil der Befragten, der eine Aktivität/ Informationsquelle als eher oder sehr wichtig beurteilt (fünfstufige Skala, 1=sehr unwichtig, 5=sehr wichtig). [Abb. 1]

265

Abb. 2. Beurteilung der Relevanz des Studiums in Hinblick auf UX-/Usability-Wissen unter Absolventen verschiedener Fachrichtungen

Die Einstufung der Relevanz des Studiums variiert je nach Studienfach [Abb. 2]: am höchsten liegt der Anteil der Personen, die ihr Studium als eher/sehr wichtig beurteilen unter den Informationsdesignern, gefolgt von den Psychologen sowie Absolventen des Studiengangs Digitale Medien (Berücksichtigung von Studienfächern, für die Angaben von mindestens 5 Personen vorliegen). 5. Momentane Position 5.1. Arbeitsbereiche Basierend auf den in den Vorjahren am häufigsten genannten Arbeitsbereichen, wurden die Teilnehmer um die Angabe der prozentualen Verteilung ihrer Projekte gebeten. Abbildung 3 zeigt die durchschnittlichen Prozentangaben für die verschiedenen Bereiche. Der größte Anteil der Projekte liegt demnach im Bereich Web (m=45%), gefolgt von den Bereichen Industrie (m=33%), Büro (m=25%) und Mobile (m=22%). [Abb. 3]

266

Abb. 3. Prozentuale Verteilung von Projekten auf verschiedene Arbeitsbereiche

5.2. Aufgabenschwerpunkte Unabhängig vom Anwendungsbereich wurden die Teilnehmer außerdem um die Angabe der prozentualen Verteilung ihres Arbeitspensums auf verschiedene Aufgabenbereiche (z.B. User Interface Konzeption, Usability Testing, Requirements Engineering) gebeten. Abbildung 4 zeigt die durchschnittlichen Prozentangaben für die verschiedenen Aufgabenbereiche. Beispiele für unter „Anderes“ genannte Aufgaben sind „(Projekt)Management“ oder „Visual Design“. [Abb. 4] 5.3. Zusammenarbeit mit anderen Berufsgruppen Am häufigsten arbeiten die befragten UX/Usability Professionals mit SoftwareEntwicklern (m=37%), Produktmanagern (m=25%) und Grafik-/Produktdesignern (m=23%) zusammen, Abbildung 5 zeigt die relativen Häufigkeiten für die abgefragten

Berufsgruppen. Beispiele für weitere Nennungen sind Game Designer, Architekten oder Professoren. [Abb. 5] 5.4. Anteil realisierter Maßnahmen Die Schätzungen bezüglich der Frage, welcher Anteil der eigenen vorgeschlagenen Maßnahmen zur Verbesserung der Usability/User Experience letztendlich tatsächlich realisiert wird, reichen von 0 bis 100%, der Mittelwert liegt bei 55%, der Median bei optimistischeren 60%. 5.5. Projektdauer Die Projekte, in denen die Befragten arbeiten, haben eine durchschnittliche Dauer von rund 6,5 Monaten. Der Median liegt allerdings nur bei 4 Monaten, bei 26% beträgt die Projektdauer meist nur 1–2 Monate. Längere Projekte mit einer Laufzeit von 18 Monaten und mehr bilden mit 9% die Ausnahme.

Usability Professionals 2013 Branchentrends

Abb. 4. Prozentualer Anteil von Arbeitsaufgaben

5.6. UsabilityZeit Gemessen an der Gesamtarbeitszeit liegt der Anteil an Tätigkeiten im Bereich Usability/User Experience unter den Befragten bei durchschnittlich 73%, wobei sich die Gruppe der Angestellten signifikant häufiger mit Usability/User Experience beschäftigt (m=76%) als die Gruppe der Freiberufler (m=63%). 5.7. Angestellte versus Selbstständige

zudem spezifische Fragen an Angestellte und Selbstständige gerichtet, im Folgenden sind die entsprechenden Analysen aufgeführt. 6. Situation der Angestellten 6.1. Stellenbeschreibung Der mit 43 Nennungen weiterhin häufigste Jobtitel lautet „Usability Engineer“, Tabelle 1 zeigt die Zahl der Nennungen für

Die große Mehrzahl der Usability Professionals befindet sich in einem Arbeitnehmerverhältnis: 287 (81%) arbeiten als Angestellte, während die restlichen 69 Teilnehmer Inhaber eines Unternehmens oder freiberuflich tätig sind. Unter den Frauen liegt der Anteil der Selbstständigen mit 17% etwas niedriger als unter den Männern (21%), dieser Unterschied ist jedoch nicht signifikant. Neben den bisher aufgeführten Angaben zur momentanen Situation wurden

Abb. 5. Zusammenarbeit mit anderen Berufsgruppen

Tab. 1. Häufigste Jobtitel

die meist genannten Jobtitel. Insgesamt ist der Begriff der „User Experience“ immer häufiger auch Bestandteil des Jobtitels, insgesamt 99 Teilnehmer tragen einen entsprechenden Jobtitel. „Usability“ ist hingegen nur noch bei 68 der Befragten Teil des Titels. [Tab. 1] Die große Mehrheit der Angestellten (96%) arbeitet auf einer Vollzeitstelle. Bei ihrem aktuellen Arbeitgeber angestellt sind die Befragten im Schnitt seit 4 Jahren (sd=3,9; min=0; max=24; med=3).

Rang

Jobtitel

Zahl der Nennungen

Usability Engineer

User Experience Consultant

User Experience Designer

Usability Consultant

User Interface Designer

Product Manager

7/8

User Researcher

7/8

Interaction Designer

267

Abb. 6. Verteilung der Angestellten auf Unternehmen unterschiedlicher Größe von 2008–2013

26% der Angestellten haben derzeit Personalverantwortung, wobei die Übertragung von Personalverantwortung mit steigender Unternehmenszugehörigkeit zunehmend wahrscheinlicher wird (r=.32**). 6.2. Unternehmen Etwa die Hälfte der Angestellten (54%) ist bei einem Unternehmen beschäftigt, das UX/Usability als Dienstleistung anbietet, die andere Hälfte arbeitet unternehmensintern an der Verbesserung der UX/Usability der „eigenen“ Produkte des Unternehmens. Die Angaben zur Größe des Unternehmens variieren von 3 Beschäftigten bis zu 400.000 Beschäftigten (m=10.441; sd=43.207; med=120). Die größte Gruppe bilden Angestellte, die in Unternehmen mit 100 – 1000 Beschäftigten arbeiten. Im Vergleich zum Vorjahr sind aber auch sehr große Unternehmen mit über 10.000 Beschäftigten sowie Unternehmen mit 51–100 Beschäftigten wieder etwas stärker repräsentiert. Abbildung 6 zeigt die Verteilung der Angestellten auf die unterschiedlichen Unternehmensgrößen. [Abb. 6]

268

6.3. Zufriedenheit beim aktuellen Arbeitgeber Der Mittelwert für die Gesamtzufriedenheit beim aktuellen Arbeitgeber liegt bei 3,9 (sd=1,1; fünfstufige Skala von 1= sehr unzufrieden bis 5= sehr zufrieden). Besonders zufrieden sind die teilnehmenden Usability und User Experience Professionals mit dem in ihrer Abteilung vorherrschenden Teamgeist und den netten Kollegen (m=4,4), der ihnen aufgetragenen Eigenverantwortung und den vorhandenen Freiräumen (m=4,1) sowie mit den inhaltlich interessanten und vielfältigen Arbeitsaufgaben (m=4,0). Im Vergleich dazu weniger zufrieden sind die Teilnehmer mit den vorhandenen Möglichkeiten für beruflichen Aufstieg und Weiterentwicklung (m=3,4), der Höhe ihres Gehalts (m=3,3) und der Integration von User Experience und Usability in den Produktentwicklungsprozess (m=3,2). Insgesamt liegen die Zufriedenheitswerte jedoch für alle abgefragten Aspekte über dem Skalenmittelpunkt. Abbildung 7 zeigt die gemittelten Zufriedenheitswerte für alle abgefragten Zufriedenheitsaspekte. [Abb. 7]

Abb. 7. Zufriedenheit beim aktuellen Arbeitgeber hinsichtlich verschiedener Aspekte (1= sehr unzufrieden bis 5= sehr zufrieden)

Zudem ist die Gesamtzufriedenheit beim aktuellen Arbeitgeber unter Männern (m=4,01) signifikant höher als unter Frauen (m=3,64), der gleiche Unterschied zeigt sich für die meisten Einzelaspekte (nur für Aufstiegsmöglichkeiten, Integration von UX/Usability in Unternehmensprozesse, Arbeitsbelastung und Arbeitsplatzsicherheit zeigen sich keine geschlechtsspezifischen Zufriedenheitsunterschiede). 6.4. Gehaltsspiegel Das durchschnittliche Bruttojahresgehalt der Angestellten liegt in diesem Jahr bei 51.527 € (sd=18.245; min=21.720; max=150.000; Berücksichtigung von Inhabern ganzer Stelle), und hat sich damit gegenüber dem Vorjahr nicht signifikant verändert (2012: 49.182 €). Männer (m=55.614 €) verdienen weiterhin signifikant mehr als Frauen (m=45.845 €), der Zusammenhang zwischen Geschlecht und Höhe des Gehalts bleibt auch dann signifikant, wenn man die Unterschiede in der Berufserfahrung berücksichtigt (partielle Korrelation r=.178**).

Usability Professionals 2013 Branchentrends

Abb. 8. Durchschnittsgehälter der Angestellten in Abhängigkeit der Berufserfahrung

Wie auch in den Vorjahren ist der wichtigste Gehaltsprädiktor die Berufserfahrung (r=.56**), dieser Zusammenhang besteht für weibliche (r=.41*) und männliche UX/Usability Professionals (r=.57**) gleichermaßen. Abbildung 8 zeigt die Durchschnittsgehälter der Angestellten in Abhängigkeit der Berufserfahrung. Unter Frauen besteht außerdem ein signifikanter Zusammenhang zwischen Gehalt und Unternehmensgröße (r=.35**), unter Männern ist dieser Zusammenhang nicht signifikant (r=.05). [Abb. 8] 7. Situation der Selbstständigen 7.1. Unternehmen In diesem Jahr haben sich mit 69 Unternehmensinhabern wieder mehr Selbstständige an der Befragung zum Branchenreport beteiligt (im Vorjahr waren es nur 38 Personen), an dieser Stelle nochmals speziellen Dank. Die Unternehmensbezeichnungen wurden dieses Jahr über vorgegebene Kategorien abgefragt, die sich jeweils aus den meistgenannten Bezeichnungen

der entsprechenden offenen Frage des letzten Jahres ergaben. Unter den 69 Unternehmensinhabern bezeichnen sich 21 Personen als „Freelancer“, 13 Personen betreiben eine „Agentur“, jeweils 10 Personen bezeichnen ihr Unternehmen als „Beratung“ oder „Consulting“ und 8 Personen betreiben ein Designstudio/-büro. Beispiele für weitere Unternehmensbezeichnungen sind „Testlabor“ oder „Engineering“. Die Unternehmensgründung liegt im Schnitt 6 Jahre zurück, allerdings sind auch Inhaber ganz frisch gegründeter Unternehmen vertreten (sd=5,2; min=0; max=25). 19% der Selbstständigen arbeiten allein, der Großteil beschäftigt Angestellte. In vielen Fällen (46%) ist es allerdings nur einer. Selbständige mit 10 Angestellten und mehr bilden in diesem Jahr erneut mit 12% eher die Ausnahme, Inhaber größerer Unternehmen mit über 40 Angestellten haben sich dieses Jahr leider nicht an der Befragung beteiligt. Im Durchschnitt brauchen die Unternehmensinhaber 3 Monate (sd=2,8; min=0, max=12) bis sie eine offene Stelle besetzen können.

7.2. Herausforderungen Die nach wie vor größte Herausforderung bei der Unternehmensgründung besteht für Unternehmer darin, potentiellen Auftraggebern die Relevanz von Usability zu vermitteln, 65% der Selbstständigen stimmen hier zu. Im Vergleich zum Vorjahr ist die Relevanz dieses Faktors wieder gestiegen, 2012 waren es nur 50%, die diesen Aspekt als besondere Herausforderung erlebten. Eine weitere Herausforderung stellt die Kontaktaufnahme zu potentiellen Auftraggebern dar (48% Zustimmung) sowie die Vermittlung der eigenen Professionalität bzw. die Abgrenzung von „unseriösen“ Konkurrenten (38%). 17% berichten von Schwierigkeiten, bei Entwicklern Anerkennung zu finden, weitere genannte Herausforderungen sind beispielsweise „Usability als Wort vermeiden und die Idee des nutzerzentrierten Gestaltens vermitteln“ oder „die Festanstellung umgehen und den Job als Freelancer bekommen“. Die relative Wichtigkeit der Herausforderungen hat sich somit im Vergleich zum Vorjahr nicht geändert.

269

These

Anteil an Zustimmung

User Experience ist der weitere Begriff. Usability ist ein Teilaspekt von User Experience.

80%

Gute Usability ist eine Voraussetzung für gute User Experience.

70%

Usability lässt sich objektiver beurteilen als User Experience.

55%

Usability beschäftigt sich mit aufgabenbezogenen Qualitätsaspekten, User Experience mit aufgabenunabhängigen Qualitätsaspekten (z.B. emotionale Wirkung)

54%

User Experience ist wichtiger für die Vermarktung eines Produkts als Usability.

29%

Mit dem Begriff User Experience lässt sich besser Geld verdienen.

18%

Usability ist ernsthafter/seriöser als User Experience.

User Experience…

Usability…

„Schließt das gesamte Produkterlebnis mit ein – von der Verpackung bis hin zum After-Sales Service“

„Ist nur ein Teilaspekt der User Experience“

„Hat viel mit Ästhetik für alle beteiligten Sinne zu tun (optisch, ggf. auch haptisch, akustisch)“

„Ist ein Zustand (Benutzerfreundlichkeit) … lässt sich jedoch nicht mit Normen durchsetzen!!“

„Umfasst auch andere Emotionen“

„Umfasst nur Zufriedenheit“

„Ist das Sahnehäubchen auf einer guten Usability“

„Wirkt mittlerweile fast altbacken, zumindest im Cosumer Goods Bereich“

„Beschreibt das Erlebnis des Besuchers über den gesamten Prozess“

„Beschreibt die Nutzung mit dem Artefakt an sich“

„Betrachtet die Kontakt- und Interaktionsphasen insgesamt, vom ersten Kontakt über die Benutzung bis zum letzten Kontakt“

„Betrachtet die Gebrauchstauglichkeit / Benutzbarkeit eines Systems im Handlungsprozess“

„Ist die ganze Erfahrung mit dem Produkt (also das “WIE“)“

„Ist das ‚WAS‘ der Nutzer bedient“

„Geschieht“

„Kann ich aktiv gestalten“

„Nützt der Gestaltung und der Interaktion“

„Nützt dem Verständnis“

„Betont zusätzlich Joy of use“

„Steht für Ease of use“

„Ist häufig ein Modewort, das häufig synonym mit schickem visuellem Design verwendet wird“

„Wird in UX-lastigen Unternehmen/Abteilungen oft vernachlässigt“

„Kann gut oder schlecht sein“

„Enthält das Gütekriterium“

„Beinhaltet den Wert / Wertversprechen (für Nutzer), Emotionale Bindung / Wirkung“

„Wird heute erwartet. Effizienz und Effektivität sind verbrauchte Begriffe fürs Marketing, Zufriedenheit ist nicht mehr genug. Ein Produkt muss heute ‚geil‘ sein“

„… hedonische Qualität“

„… pragmatische Qualität“

„Führt nachweislich zu höherer Konversion, Digital Branding und Engagement“

„Ist nur eine Voraussetzung zur Nutzbarkeit“

„Klingt derzeit moderner“

„Klingt eher ein wenig verstaubt“

270

Tab. 2. Thesen zur Abgrenzung der Begriffe User Experience und Usability und Anteil an Zustimmung

Tab. 3. Äußerungen der Befragten zur Abgrenzung der Begriffe User Experience und Usability

Usability Professionals 2013 Branchentrends

7.3. Verdienst Unter den Selbstständigen machten 37 Personen Angaben zu ihrem üblichen Stundensatz, dieser liegt 2013 bei durchschnittlich 77€ (sd=19; min=40; max=120; med=80). 33 der Selbstständigen machten Angaben zu ihrem üblichen Tagessatz, dieser bewegt sich zwischen 300€ und 2.400€, der Durchschnittswert liegt bei 737€ (sd=375; med=640). Die durchschnittliche Auslastung der Selbstständigen liegt bei 152 Tagen pro Jahr (sd=77; min=20; max=340; med=152). 8. Selbstverständnis Wie in den Branchenreports der letzten Jahre bereits berichtet, wird der UsabilityBegriff immer häufiger abgelöst durch den Begriff der User Experience. Diese Entwicklung hat die internationale UPA (Usability Professionals Association) bereits zu einer Namensänderung veranlasst, sie nennt sich seit 2012 nun UXPA (User Experience Professionals Association). Der Vorschlag einer entsprechenden Namensänderung für die German UPA wurde auf der Mitgliederversammlung 2012 kontrovers diskutiert. Hierbei wurde deutlich, dass unter den in der Usability- und User Experience-Branche Tätigen recht unterschiedliche Assoziationen zu den beiden Begriffen vorherrschen, und auch unterschiedliche Vorstellungen darüber bestehen, was die beiden Begriffe voneinander abgrenzt, bzw. ob es überhaupt einen inhaltlichen Unterschied zwischen den Begriffen gibt. Dies haben wir zum Anlass genommen, hierzu im Rahmen der Befragung zum diesjährigen Branchenreport ein breiteres Meinungsbild einzuholen. Für die überwältigende Mehrheit der Befragten (97%) besteht ein konzeptueller Unterschied zwischen Usability und User Experience, nur 12 der Befragten (3%) gaben an, die Begriffe synonym zu verwenden. Für eine nähere Spezifikation der Begriffe haben wir für eine Reihe (teils provokanter) Thesen, die im Rahmen besagter Mitgliederversammlung diskutiert wurden, den Grad an Zustimmung unter den Branchenreport-Teilnehmer erhoben. Es zeigte sich beispielsweise weitgehende

Abb. 9. Einschätzungen zur Wichtigkeit von Usability und UX für verschiedene Produktsparten

Einigkeit darüber, dass Usability als ein Teilaspekt von User Experience betrachtet werden kann, hier konnten 80% zustimmen. Die Frage jedoch, ob sich Usability objektiver beurteilen lässt als User Experience spaltete die Gruppe in zwei Lager, nur 55% stimmten dieser Aussage zu. [Tab. 2] Darüber hinaus konnten die Befragten eigene Begriffsdefinitionen oder ihrer Meinung nach zentrale Unterschiede zwischen Usability und User Experience aufführen. Hierbei betonten die Befragten verschiedene Perspektiven, wie beispielsweise die Relevanz für unterschiedliche Berufsgruppen („Usability ist für Entwickler wichtig, User Experience für Produktmanager“) oder die unterschiedliche zeitliche Komponente („Usability beschreibt die Nutzung mit dem Artefakt an sich und UX beschreibt das Erlebnis des Besuchers über den gesamten Prozess. Also auch davor und danach. Denn was der User vorab schon über den Prozess weiß, das beeinflusst ihn auch bei der Nutzung.“). Einige verwiesen hier allein auf bestehende Versuche einer Begriffsdefinition („Usability = Nutzungsqualität; User Experience = Nutzungserlebnis, DIN EN ISO 9241–210“), andere erklärten bestehende Definitionen als unzureichend („Es gibt noch keine zufriedenstellende, allgemein anerkannte Definition von User

Experience“). Schließlich brachten auch einige der Befragten ihre Unzufriedenheit mit den bestehenden Begrifflichkeiten zum Ausdruck, wie beispielsweise „Beides verbrannte Worte, durch Leute die keinen blassen Schimmer haben und Reden aber nie Schaffen“. Insgesamt weisen die Nennungen jedoch auf eine Reihe von Aspekten hin, die bei einer Abgrenzung der beiden Begriffe hilfreich sein können oder zumindest eine wertvolle Diskussionsgrundlage im Rahmen eines weiteren Austauschs innerhalb der Community sein können. Tabelle 3 gibt eine Übersicht über Nennungen der Befragten zu den beiden Begriffen. [Tab. 3] Zudem variieren die Einschätzungen zur jeweiligen Relevanz (1=weniger wichtig, 5=sehr wichtig) von Usability und User Experience in Abhängigkeit von der Produktsparte. Bis auf den Bereich Consumer Software zeigten sich für alle abgefragten Domänen signifikante Unterschiede: Während im Bereich der Unterhaltungselektronik gute User Experience als wichtiger eingeschätzt wird als gute Usability, wird in den Bereichen Business-Software, Industriegüter, Haushaltsgeräte, Medizin, Automobil und Telekommunikation Usability der höhere Stellenwert eingeräumt. Abbildung 9 zeigt die Mittelwerte für die verschiedenen Produktsparten. [Abb. 9]

271

Rang

Unternehmen

UID

155

SirValUse

Ergosign

eResult

Artop

Fraunhofer Institut

SAP

USEEDS°

9/10

eye square

9/10

usability.de

9. Branche 9.1. Herausforderungen und notwendige Änderungen Welche Änderungen in der Branche die Teilnehmer für nötig erachten, um aktuelle Herausforderungen erfolgreicher bewältigen zu können, wurde dieses Jahr anhand vorgegebener Kategorien abgefragt, die anhand der häufigsten Nennungen zu der entsprechenden offenen Frage des letzten Jahres gebildet wurden. Von der Mehrzahl der Teilnehmer wird eine stärkere Einbettung von Usability und User Experience in die Entwicklungsprozesse gewünscht (94%). Auch eine Stärkung der Lobby bzw. eine größere Anerkennung der Relevanz von Usability und User Experience werden als dringende Notwendigkeit angeführt (70%). Jeweils 43% wünschen sich mehr Aus- und Weiterbildungsmöglichkeiten sowie eine Zertifizierung des Berufsbildes und die Festsetzung einheitlicher Qualitätsstandards, 30% fordern eine stärkere Vernetzung der Community.

272

Zahl der Nennungen

9.2. Unternehmen der Branche Für einen Überblick über die bekanntesten Unternehmen der Branche nannten die Teilnehmer die ihrer Meinung nach drei bekanntesten Unternehmen im deutschsprachigen Raum, die sich mit „Usability“ bzw. „User Experience“ beschäftigen. Spitzenreiter ist hier wie auch in den Vorjahren UID, gefolgt von SirValUse und Ergosign. Tabelle 4 gibt einen Überblick über die bekanntesten Unternehmen der Branche sowie die jeweilige Zahl der Nennungen. [Tab. 4]

Tab. 4. Bekannteste Unternehmen der UX/Usability-Branche

Usability Professionals 2013 Branchentrends

273

Mit Interface Design ein Markenprofil stärken User Interfaces sind markenbildend und schaffen Vertrauen in Premiumprodukte – Erläuterungen am Fallbeispiel der Marke Viessmann Manfred Dorn Phoenix Design, Stuttgart Kölnerstrasse 16 70376 Stuttgart manfred.dorn@phoenixdesign.com

Abstract Bei Premiumprodukten sind in vielen Branchen eine hohe Nutzerfreundlichkeit und ein grafisch ansprechendes Erscheinungsbild der Bedienoberflächen unverzichtbar. Zudem sollte ein hochwertiges Design ein Qualitätserlebnis erzeugen und sich mit einem eigenständigen Erscheinungsbild vom Wettbewerb abgrenzen. Eine übergeordnete und integrierende Rolle spielt in Unternehmen das Corporate Design – vor allem in Konzernen mit einer Vielzahl an Produkten und unterschiedlichen Bedienoberflächen. Es ist die Kernaufgabe des Corporate Design, eine Marke mit Ihren Werten wiedererkennbar zu machen und zu stärken. Ein sorgfältig entwickeltes Corporate Design für Bedienoberflächen führt auf verschieden Ebenen zu größerer Klarheit und Verständlichkeit. So erleichtert beispielsweise eine produkt- und sortimentsübergreifende Bedienphilosophie mit einem stimmigen Design dem Servicepersonal die Arbeit. Sie trägt dazu bei, dass Nutzer Vertrauen in eine Marke entwickeln. Zahlreiche Beispiele aus dem Viessmann-Konzern belegen, wie sich gutes Corporate Design auswirkt und worauf es dabei ankommt – von Produkten über Anlagensteuerungen, Touch-Regelungen und Fernbedienungen bis hin zu Apps für Smartphones und Tablet PCs.

Das Markenversprechen User Interfaces werden an den Bedürfnissen der Nutzer ausgerichtet. Aus der Perspektive einer ganzheitlich arbeitenden Designagentur fokussieren wir zudem die Ebene des Produktdesign und des Corporate Design. Auf Anhieb verständliche und intuitiv bedienbare Nutzeroberflächen lassen beim Nutzer Vertrauen in das Produkt und damit in die Marke entstehen; User Interface Design ist daher ein elementares

Werkzeug, um Premiumdesign – und damit ein klares Markenprofil – zu erzeugen. [Abb. 1] Marken im heutigen Sinn gibt es bereits seit 120 Jahren. Coca Cola ist eine der ersten Marken, die erfunden wurde, und bis heute eine der wertvollsten auf der Welt. Der ursprüngliche Sinn einer Marke war das Werben für Produktvorteile. Heute geben Marken in einer nahezu unübersehbaren Warenwelt Orientierung bei

Keywords: /// Corporate, Interface und Produkt Design /// Marke /// Qualität /// Bedienphilosophie /// Grafical User Interface, GUI

der Kaufentscheidung und machen es einfacher, ein passendes Produkt zu finden. Marken sind zudem ein Qualitätsversprechen. Der Käufer nimmt an, dass das Markenprodukt nach dem Kauf und in der Benutzung dieses Versprechen einlöst. „Die Bedeutung des Produktdesigns und des User Interface Designs für die Markenentwicklung und -führung wird leicht übersehen. In unserer Alltagswahrnehmung scheint die omnipräsente Werbung

Abb. 1. Durchgängiges Coporate Design bei Viessmann. Die Bedienung befindet sich in den orangen Aufsätzen.

274

Usability Professionals 2013 Branchentrends

Abb. 2. Vorher-Nachher: Das neue Touchpanel zeigt ein deutlich übersichtlicheres Grundbild.

der Ausschlag gebende Markenfaktor zu sein. Im Grunde aber ist das Produkt selbst Kern der Marke. Werbung kann nur den ersten emotionalen Anreiz und die Produktinformation geben. Ein Versprechen. Dass dieses nicht enttäuscht, sondern eingehalten wird, muss das Produkt selbst leisten. Erst wenn sich die Erwartungshaltung im Produkt bestätigt, kann Vertrauen in eine Marke und langfristige Markentreue entstehen.“ Mit positiven Werten auf das Markenkonto einzahlen Die entscheidenden Faktoren für ein positives Markenbild im anspruchsvollen Premium-Bereich sind: Produkt- und Gestaltungsqualität, Kommunikation, Nutzerfreundlichkeit und Innovation. Damit eine Marke glaubhaft wirkt, müssen alle auf eine Marke einwirkenden Maßnahmen zusammenpassen und eine eindeutige Botschaft senden. Nur wenn das gelingt, kann auf das „Markenkonto“ eingezahlt und das Guthaben auf diesem Markenkonto vermehrt werden. Widersprüchliche Maßnahmen – zum Beispiel ein nicht markenadäquates Design, minderwertige Qualität, ungenügender Service, sozialschädliches Verhalten oder eine schlechte

Bedienbarkeit heben vom „Markenkonto“ ab und schädigen langfristig das positive Image einer Marke. Meist dauert es deutlich länger, ein gutes Markenbild aufzubauen als es zu ruinieren. Aus der Praxis Corporate Design für die Marke Viessmann Das Corporate Design der Marke Viessmann wird seit vielen Jahren von der Agentur Phoenix Design aus Stuttgart aufgebaut. Um ein Corporate Design über viele Konzerntöchter und eine riesige Produktvielfalt realisieren zu können, ist aus unserer Erfahrung eine langjährige Lead Agentur oder eine firmeninterne Corporate Design Abteilung notwendig. Nur so ist es möglich, produktübergreifend ein wiedererkennbares Markenerscheinungsbild bei Produkt Design und User Interface Design zu realisieren. Die Markenkernwerte, die Bedienphilosophie und die gestalterischen Markenelemente müssen klar definiert sein. Das heißt nicht, dass diese Elemente unabänderlich sind, sondern dass diese einem ständigen, kontrollierten und evolutionären Wandlungsprozess unterworfen sind. Dieser Erneuerungsprozess muss in regelmäßigen

Abständen mit der Unternehmensleitung des Herstellers reflektiert und diskutiert werden. Regelhefte und Styleguides müssen so formuliert sein, dass diese eindeutige Vorgaben für die grafische Gestaltung geben – aber andererseits so flexibel sind, dass sie diesen Wandel zulassen. Vertrauen in Qualität Bei vielen Konsumprodukten beeinflusst das subjektive, reine Gefallen einer Form oder einer Bedienoberfläche die Kaufentscheidung. Dies ist bei Investitionsgütern grundsätzlich anders. Niemand investiert in eine Heizungsanlage, nur weil diese gut aussieht. Trotzdem spielt die Produktästhetik und das User Interface Design eine entscheidende Rolle bei der Kaufentscheidung. Selbst Fachleute sind kaum noch in der Lage, auf Anhieb zu beurteilen ob ein Produkt wirklich nutzerfreundlich zu bedienen ist und ob die Technologie, die innen verbaut ist, tatsächlich effizienter funktioniert, als bei einem Wettbewerbsprodukt. An genau diesem Punkt muss Vertrauen entstehen: Ein durchgängiges Design und eine gute Funktionalität, zu der essentiell die Handhabung gehört, ist eine Möglichkeit, dieses Vertrauen zu schaffen. [Abb. 2]

275

Zielgruppen gewinnen In der Sanitär- und Heizungsindustrie hat die Zielgruppe der Heizungsbauer eine wichtige Mittlerrolle. Diese Zielgruppe

soll überzeugt und für die Produkte einer Marke gewonnen werden; schließlich beeinflusst der Heizungsbauer die Kaufentscheidung für ein Heiz- oder Klimasystem in ganz erheblichem Maß. Er

hat meist mehrere Marken der Heiztechnik im Programm – und er wird seinem Endkunden nur solche Systeme anbieten, die eine einfache und schnelle Montage sowie eine gute Bedienbarkeit auch für

Abb. 3. Nach dem Pilotprojekt für den Industrie- Dampfkessel, bei dem schon kurz nach der Konzeptionsphase erste Usability-Tests mit Anwendern durchgeführt worden sind, konnte das Corporate Design Konzept und die User Interface Bedienphilosophie auf andere Viessmann Tochterfirmen und Industrieanlagen übertragen werden. Da es sich bei den Viessmann Industrieanlagen meist um Mess- und Regelprozesse handelt, gelang dies auch bei so andersartigen Strukturen einer Biogasanlage oder einem Blockheizkraftwerk.

Abb. 4. Blick in ein Kesselhaus. Die Dampfkessel von Viessmann werden mit der neuen Touchsteuerung bedient.

276

Usability Professionals 2013 Branchentrends

ihn gewährleisten – kurzum: wenn er mit Produkten positive Erfahrungen in dieser Richtung gemacht hat, wird er den Produkten dieser Marke vertrauen und diese empfehlen. Außerdem ist davon auszugehen, dass er sich nicht bei jedem Produkt neu in die Bedienlogik hineindenken möchte. Wenn zum Beispiel ein Hersteller wie Viessmann eine Vielzahl an Maschinen, Anlagen und Heizsystemen anbietet, sollte die Bedienlogik von einem Gerät auf das nächste übertragbar sein. [Abb. 3] Zudem machen wir die Erfahrung, dass die Ausbildungsstandards in der Sanitär- und Heizungsindustrie sinken und die Systeme zunehmend komplexer werden. Das User Interface Design hat dabei die Funktion, auch bei geringer Erfahrung und Kenntnis sicher und zuverlässig durch das System zu navigieren. Corporate Bedienphilosophie– stimmiges Interaktionskonzept Am Anfang unserer User Interface Design Entwicklungen für Viessmann stand ein Pilotprojekt: Eine komplexe Industrie Dampfkesselanlage mit einem 10-Zoll Touchpanel. In einer Nutzungsanalyse stellte sich heraus, dass die Anlage nach der Einregulierung weitgehend im Automatikmodus betrieben wird und die Anzahl der Anzeigen im Grundbild deutlich reduziert werden kann. Erst wenn Abweichungen oder Störungen auftreten, ist es notwendig, detailliertere Informationen anzuzeigen und farblich hervorzuheben. So entstand die Idee mit den selbsterklärenden, grünen Haken für die „OK“ –Situation, die bei Bedarf auf Skalen und Werte wechselt. Nur einzelne wichtige Werte werden permanent angezeigt. Um die Interpretation der Werte im Industriebereich zu erleichtern, werden Ziffernwerte möglichst durch einen Bargraphen mit einem gelben und roten Warnbereich ergänzt. [Abb. 4] Eine von uns durchgeführte Nutzerbefragung hat ergeben, dass es den meisten Anwendern wichtig ist, ein attraktives, visuelles Abbild der Anlage auf dem Display wiederzufinden. Das erleichtert ihnen

Abb. 5. Gliederung des Bedienkonzepts in die verschiedenen Hierarchieebenen.

die Zuordnung der Anzeigen zu einem Anlagenteil. Da die Anlage erweiterbar sein sollte, erstreckt sich die Visualisierung nun auf mehrere Grundbilder nebeneinander, auf die redundant durch Sliden und mit Pfeiltasten gewechselt werden kann. Durch Tippen auf die großzügig dimensionierten Bedienkacheln mit den Haken oder Grundanzeigen gelangt der Bediener auf die nächste Bedieneben. Dieses Grundprinzip der Einfachheit und der Interaktion wird bei allen Viessmann Anlagenpanels beibehalten. [Abb. 5] Corporate Design – Details prägen die Marke Alle Viessmann Bedienpanels haben einen dunklen Hintergrund mit weißer Schrift. Diese Farbwahl soll Intelligenz und Ernsthaftigkeit ausdrücken. Im oberen Teil befindet sich eine Statusleiste, die durch eine dünne Linie in der Viessmannfarbe Orange zum mittleren Bedienteil abgetrennt wird. Im unteren Teil des Panels ist eine Bedienleiste mit häufig verwendeten Funktionen für direkten Zugriff. Im mittleren Teil befindet sich eine grafische Darstellung der Anlage oder des Hauses.

Als Corporate Schrift wird die Arial in den Schriftschnitten regular und bold verwendet. Grundsätzlich wird eine Kombination aus einheitlich gestalteten, grafisch reduzierten Ikons und Klartext in mehreren Sprachen verwendet. Das Grundprinzip des dreigeteilten Bildschirmaufbaus mit dem dunklen Hintergrund findet sich an allen Viessmann Displays wieder. Die grafische Detailausführung variiert jedoch je nach verwendeter Displaytechnologie und nach Verwendungszweck. Übertragbarkeit Nach dem Pilotprojekt für den IndustrieDampfkessel, bei dem schon kurz nach der Konzeptionsphase erste Usability-Tests mit Anwendern durchgeführt worden sind, konnte das Corporate Design Konzept und die User Interface Bedienphilosophie auf andere Viessmann Tochterfirmen und Industrieanlagen übertragen werden. Da es sich bei den Viessmann Industrieanlagen meist um Mess- und Regelprozesse handelt, gelang dies auch bei so andersartigen Strukturen einer Biogasanlage oder einem Blockheizkraftwerk.

277

Abb. 6. Holzvergaserkessel Vitoligno 200-S, einschließlich der Fernbedienung Vitotrol 350. Das übersichtliche 5-ZollDisplay wird zentral im Wohnbereich installiert und ermöglicht es, das Gerät zu überwachen. So sieht man beispielsweise, ob der Kessel im Keller wieder befeuert werden muss.

Abb. 7. Weiterentwicklung einer App für Smartphones und Tablet PCs speziell zur vereinfachten Heizungssteuerung

278

Usability Professionals 2013 Branchentrends

User Interfaces werden zum eigentlichen Produkt Dass das Design den Umgang mit den Dingen – und damit die Schnittstelle zum Nutzer gestaltet, ist nicht neu – bekommt jedoch eine neue Bedeutung, weil die User Interfaces zum eigentlichen Produkt werden. Heizungssysteme, einst als mächtige Kessel präsent, reduzieren sich in der Wahrnehmung heute auf ein Display für die Bedienung, das die unterschiedlichsten Parameter einbezieht. Durchgängiges Look and Feel bei Viessmann-Heizsystemen Früher gab es bei Heizungen nur die beiden Betriebszustände Ein oder Aus; heute dominieren Systeme, die dynamisch auf den tatsächlichen Wärmebedarf reagieren – und das sogar mit so archaisch anmutendem Brennmaterialien wie Holzscheiten. So hat der „Vitoligno 200-S“ ein Scheitholzkessel, der von Hand eingeworfene Holzstücke von bis zu 50 Zentimetern Länge aufnimmt und emissionsarm bei einem Wirkungsgrad von bis zu 92 Prozent in Wärme umsetzt ein intelligentes Display. Hier trifft archaische Handbedienung und High Tech zusammen. Die Feuerung erfolgt vollautomatisch, bedient wird das System mittels eines berührungsempfindlichen Displays am Kessel selbst und über ein Display im Wohnraum oder über eine App. Das Look and Feel ist bei allen diesen Viessmann Interfaces gleich, egal ob es sich um eine Industrieanlage oder einen Einzelkessel handelt. [Abb. 6] Bedienelemente müssen an Größenvarianten angepasst werden Das hört sich selbstverständlich an, ist es aber nicht, da allein schon die Größenvarianten eine spezifische Umsetzung der Bedienelemente verlangen: Ein 10-Zoll Display kann die Informationen ganz anders präsentieren als ein halb so großer 5-Zoll Screen oder ein iphone. Das lässt sich nicht einfach durch Skalierung anpassen und geht daher nur mit strukturellen Veränderungen. Folglich unterscheidet

Abb. 8. Ein Home Automation System mit einer selbsterklärenden Touchsteuerung: Über das Viessmann Home Automation System lassen sich sehr bequem sämtliche Funktionen in einem Haus regeln – von der Heizung über die Beleuchtung bis hin zur Kontrolle von Fenstern, Türen und Elektrogeräten. Die Bedienung erfolgt entweder direkt an der Hauszentrale oder über Apps auf Smartphones und Tablet PCs.

sich der Screenaufbau und -inhalt auf einem 15-Zoll-Display vom 10-Zoll und von dem 5-Zoll-Raumdisplay des funkbasierten „Vitotrol 300“. Und dennoch sollte die Zusammengehörigkeit klar erkennbar sein. Die Bedienoberfläche muss klar zeigen, dass es sich um ein Viessmann-Produkt handelt, auch wenn der zugehörige Kessel nicht daneben steht. Verschiedene Aktionsebenen Die Frage, wie viel Komplexität einer modernen Heizungssteuerung überhaupt abgebildet werden sollte, wird mit zielgruppenspezifischen und passwortgeschützten Zugriffsebenen beantwortet – eine allgemeine Ebene für Endkunden sowie eine für Heizungsbauer und eine für den Hersteller, die tiefere Zugriffe auf die Kesselparameter verlangen. Wichtig ist, dass stets die exakten Werte wie auch einfache, aber eindeutige „ok“-Statusrückmeldung immer gleich dargestellt werden. [Abb. 7]

Interfaces erschließen Energiepotenzial Parallel zu den Industrie-Panels entstand die App „Vitocomfort“ für Android und iOS, mit der sich via Internet Hausfunktionen wie Beleuchtung, Lüftung, Sicherheit, Funksteckdosen und natürlich die Raumtemperatur ansprechen lassen. Damit geht Viessmann als erster Heizungshersteller in Richtung Home Automation. Im Gegensatz zu anderen Systemen steht beim komfortorientierten „Vitocomfort“ aber die Heizung im Mittelpunkt. Die technische Lösung ist das eine, die Bedienbarkeit eine andere – sprich: erst das schlüssig gestaltete und intuitiv nutzbare Interface erschließt ein bislang brach gelegenes Energiesparpotenzial. Sinnvolle, aber umständlich zu bedienende Funktionen werden ansonsten einfach nicht benutzt. Einfachheit ist hier ein Schlüsselfaktor, und das schätzt nicht nur der Endkunde: Auch im Profibereich sind selbsterklärende und bildhafte Interfaces eine Erleichterung. [Abb. 8]

279

Literatur 1. Phoenix Design GmbH &Co KG, Stuttgart, www.phoenixdesign.com 2. Viessmann GmbH, Allendorf (Eder), www.viessmann.com 3. Wally Olins, „Marke, Marke, Marke Den Brand stärken“, 2004 Campus Verlag

280

Kurzvortr채ge

281

User Experience für Kinder am Beispiel der „Seite mit der Maus“ Katrin Schlierkamp Hochschule der Medien Stuttgart katis@gmx.net

Michael Burmester Hochschule der Medien Wolframstr. 32 70191 Stuttgart burmester@hdm-stuttgart.de

Abstract Wie lassen sich Kinder durch die Interaktion im Sinne einer verbesserten User Experience stimulieren? Was ist Stimulation überhaupt und warum hat der Mensch ein ständiges Bestreben nach Veränderung? Wie kann „Die Seite mit der Maus" so aufbereitet sein, dass Kinder ständig etwas Neues entdecken – Langeweile und Monotonie also vermieden werden? Diesen Fragen und noch weiteren bin ich während meiner Abschlussarbeit nachgegangen. Ausgehend vom User-Experience-Modell von Hassenzahl (2010) wurde ein Konzept erstellt, welches einen Pool an Ideen aufzeigt und ein positives Nutzungserleben für Kinder im Alter von sechs bis 13 Jahren auf der “Seite mit der Maus" ermöglicht.

1. User Experience und Grundbedürfnisse User Experience und menschliche Grundbedürfnisse stehen im direkten Zusammenhang. Eine positive User Experience bedarf der Erfüllung von Bedürfnissen. Ein Produkt, das aufgrund der Interaktion ein Gefühl von beispielsweise „being stimulated“, „being competent“ oder „being admired“ vermitteln kann, ist für die Qualität der User Experience entscheidend (Hassenzahl 2010a, p.13). An einem Beispiel von Stimulation lässt sich dies wie folgt erläutern: Fühlt sich ein Nutzer durch die Interaktion mit einem Produkt stimuliert, erlebt er das Produkt tendenziell positiv. Ist das Produkt allerdings weitestgehend erforscht und der Nutzer entdeckt keine weiteren Elemente mehr, die ihn stimulieren, so kann das Bedürfnis Stimulation in diesem Fall nicht mehr erfüllt werden. Der Nutzer könnte sich aufgrund dessen langweilen. Ein mögliches Resultat ist Frustration, die sich beim Nutzer einstellt, und ein negatives Gefühl könnte entstehen. Erst durch die Erfüllung der Bedürfnisse können positive Erlebnisse erzeugt werden. Es gibt einige Autoren, die sich mit Bedürfnissen befasst haben und eigene Modelle vorlegen. Während Reiss (1998, 2000) einen Bedürfniskatalog aus 16 Lebensmotiven

282

erstellte (z.B. Ordnung, der Wunsch nach Organisation oder – Neugier, der Wunsch nach Wissen), kamen Sheldon, Elliot & Kim (2001) zu folgenden zehn Bedürfnissen: Autonomie, Kompetenz, Verbundenheit, Stimulation, Gesundheit und Fitness, Sicherheit, Popularität und Einfluss sowie Selbstwert, Geld und Luxus. In neueren Untersuchungen von Hassenzahl, Diefenbach und Göritz (2010b) zeigte sich, dass Stimulation, Verbundenheit, Kompetenz und Popularität die wichtigsten Bedürfnisse sind, die bei interaktiven Produkten eine Rolle spielen. Auch Gaver und Martin (2000) entwickelten Alternativkonzepte, die auf Bedürfnissen basieren. Einer ihrer fünf Werte heißt Abwechslung. 1.1. Bedürfnis Stimulation und User Experience Wie die vorgestellten Modelle verdeutlichen, wird jedes Bedürfnis durch eine Motivation angetrieben. Das Bedürfnis Stimulation, auch Pleasure genannt, hat nach Sheldon et al. (2001) folgende Bedeutung: –– Pleasure-Stimulation: Feeling that you get plenty of enjoyment and pleasure rather than feeling bored and understimulated by life

Keywords: /// User Experience /// Bedürfnis Stimulation (Stimulationsfaktoren) /// Kinder /// „Seite mit der Maus“ /// Erlebnisideen

Hassenzahl (2003, S. 28) hingegen betrachtet Stimulation noch differenzierter und postuliert: Menschen suchen Stimulation, d.h. Neuartigkeit, Veränderung und Herausforderung. Sie haben auch das Bedürfnis nach persönlichem Wachstum und bemühen sich daher, ihre eigenen Kenntnisse und Fertigkeiten zu verbessern. Überdies ermöglicht Stimulation, der Neugier verstärkt nachzugehen, um sich u.a. Wissen anzueignen. Hassenzahl (2010a, p. 24) bekräftigt, Stimulation steht für: „the ability of a product to surprise, to foster curiosity and to provide opportunities for the perfection of knowledge and skills (hedonic)“. Bei seinen Ausführungen bezieht Hassenzahl sich sowohl auf Sheldon et al. (2001) als auch auf Reiss (1998, 2000). Als Motivation für das Bedürfnis Stimulation nennt er (2010a, 2010b) folgende: –– Stimulation: seinen Wissensdurst stillen, seine Neugier befriedigen, Neues kennenlernen und ausprobieren wollen, auf Entdeckungsreise gehen 1.2. Stimulation und Zeitfaktor Wie schon angedeutet, kann sich der Grad der Stimulation mit der Dauer der Benutzung eines Produkts ändern: Je länger ein Produkt genutzt wird, desto weniger

Usability Professionals 2013 Kurzvorträge

stimulierend wird es wahrgenommen. Hassenzahl konnte dies anhand einer Studie mit Mobiltelefonen belegen. In seinen Untersuchungen stellte er fest, dass Mobiltelefone anfangs faszinierend und auf eine Art fesselnd zugleich sind: „In the beginning, a mobile phone is stimulating, beautiful, something to be proud of […] (Hassenzahl, 2010a, p. 26 ). Mit der Zeit legt sich jedoch die Faszination, da das Handy weitestgehend erprobt ist und keine neuen Erfahrungen mehr mit dem Handy gemacht werden können. Hassenzahl (2010a) postuliert: “Over time, it becomes easier to master, but loses it fascination“. Hassenzahls These lässt sich mit Berlynes (1950; zitiert nach Inzard, 1994, S. 228 ff.) These unterstreichen. Ist der Nutzer einer Stimulation pausenlos ausgesetzt, verringert sich seine Neugier und es stellt sich Gewöhnung ein. Diese Erkenntnis ist allerdings nicht allgemeingültig. Es kann ebenfalls das Gegenteil der Fall sein. So kann ein Produkt sich über die Zeit entfalten und ferner Interesse wecken. Hassenzahl spricht hierbei von einem „Entfaltungsprozess“ (2006, S. 152 f.). Ein langweiliges Produkt kann mit fortlaufender Zeit auf einmal stimulierend sein. Das hängt meistens von der subjektiven Wahrnehmung und den Vorerfahrungen einer Person ab.

mag das Mix-Spiel, weil der da so lustige Sachen macht!“ (Nils, 7) (Warth, Schneider & Lensch, 2009, S. 35). Da sie die Komplexität des Computers noch nicht begreifen und in diesem Stadium das Schreiben und Lesen erst erlernen, ist der Computer demnach mehr Spiel- als Arbeitsgerät. Primär sind sie auf die Hilfe ihrer Eltern im Umgang mit dem PC angewiesen. Auch das Internet stellt eine besondere Herausforderung für sie dar, sie surfen nicht, sondern verbleiben eher auf einer Seite. Websites mit vielen Bildern werden von ihnen als sehr lebendig wahrgenommen und sorgen für erhöhte Aufmerksamkeit (Warth, Schneider & Lensch, 2009). Acht bis zehnJährige Diese Kinder sind bereits selbständiger im Umgang mit dem Computer. Sie suchen Herausforderungen im Netz und sind im Vergleich zu den Jüngeren sehr motiviert, eigenständig die Anwendung mit dem Computer zu erlernen. Gerne messen sie sich mit anderen und versuchen auch ihre eigene Leistung ständig zu verbessern. Sie entwickeln Ansprüche an sich selbst. „Ich möchte beim ‚Flöhetreiben‘ der Beste in der Familie sein“ (Daniel, 9 Jahre alt) (Warth, Schneider & Lensch, 2009, S. 40).

Hilfe durch die Eltern benötigen Kinder nur noch in Ausnahmefällen. Beliebt sind unter anderem Lern- und Wissensseiten (Warth, Schneider & Lensch, 2009). Wissensbildung nimmt neben Spieleseiten einen höheren Stellenwert ein. Bevorzugt werden nun aber übersichtlichere Websites, da dies ihrem geordneten Vorgehen entspricht, so die Studie (Warth, Schneider & Lensch, 2009). Elf bis 13Jährige Diese Altersgruppe bildet den Übergang zur Adoleszenz und ist stark heterogen. Ihr zuvor erworbenes Wissen wird durch viele Interaktionen gefestigt. So gehören einige Internetabläufe bereits zur Routine. Das Internet hat sich unter Freunden zu einem wichtigen Kommunikationstool entwickelt – Communitys nehmen einen immer stärkeren Part ein: „Bilder von anderen angucken, selbst was hochladen, chatten.“ (weiblich, 13 Jahre alt) (Warth, Schneider & Erbslöh, 2011, S. 20). Auch das parallele Surfen auf mehreren Seiten nimmt zu. So können sie gleichzeitig Spielen und Chatten, während im Hintergrund Musik auf YouTube läuft (Warth, Schneider & Lensch, 2009, S. 47). Die Komplexität des Internets erschließt sich ihnen sukzessiv.

2. Zielgruppe Kinder Um die besonderen Interessen und Bedürfnisse von Kindern herauszustellen, erfolgt eine Analyse der Zielgruppe Kinder, bei der die Entwicklung der sechs- bis 13-Jährigen im Vordergrund steht. Da die Zielgruppe der „Seite mit der Maus“ im Bezug zum Alter sehr heterogen ist, werden ihre Bedürfnisse und Fähigkeiten im direkten Vergleich gegenübergestellt. Die folgenden Ausführungen basieren auf der Elements of Art-Studie von 2009 und 2011. Sechs bis siebenJährige Kinder, die sich in diesem Stadium befinden, gehen sehr spielerisch und unbefangen an Aufgabenstellungen heran: „Ich

Tab. 1. Nutzungsverhalten der unterschiedlichen Altersstufen (in Anlehnung an die Elements of Art-Studie 2009, 2011)

283

Darüber hinaus sind Kinder aller Altersstufen sehr humorvoll und können sich über groteske Inhalte amüsieren. Dazu gehören z.B. lustige Geschichten, komische Sprachen oder verkehrte Welten (Warth, Schneider & Erbslöh, 2011, S. 13). Tabelle 1 zeigt eine Zusammenfassung der wichtigsten Unterscheidungen dieser Zielgruppen. [Tab. 1] 3. Stimulation

Der Organismus neige dazu, Stimulierung aufzusuchen, so Berlyne (1950; zitiert nach Izard, 1994). Wenn dies dem Organismus allerdings nicht gelingt, entsteht Langeweile, das Gegenteil von Stimulation. Dann ist die Rede von fehlenden Reizen, auch „Reizentzug“ genannt (Schönpflug, 1997, S. 105 f). Es stellt sich die Frage, wodurch Neugier geweckt wird. Hierzu liefert Edelmann (2000, S. 246) eine Erklärung. Sobald eine Nicht-Übereinstimmung zwischen vorhandener Information und erlernter Erfahrung vorliegt, wird das Interesse besonders erregt. Da Menschen sich meist auf ihre Erfahrungen berufen, können ungewöhnliche Situationen zunächst Unsicherheit auslösen. Menschen sind somit bestrebt, die Situation zu analysieren, um zu einer gewohnten Form zurückzukehren. Edelmann (2000, S. 244 f.) postuliert, dass Menschen nach „Ausgleich und Harmonie“ streben. Daher versuchen sie auch Widersprüchlichkeiten zu reduzieren.

entsteht. Nur das aktive Auseinandersetzen mit der Umwelt unterstützt den Lernprozess. So schreibt Schönpflug (1997, S. 107), „wer viel erlebt, weiß viel“. Um diesen Prozess zu fördern, bietet sich eine Umwelt an, die zum Erkunden animiert und die Aufmerksamkeit fesselt. Dabei sollen Neugier und Wissensdurst gestillt werden – Faktoren, die Stimulation implizieren. 3.1. Stimulationsfaktoren Berlyne konnte in seinen Untersuchungen nachweisen, dass Neuartigkeit, Komplexität, Überraschung und Inkongruenz Neugier erregen (1960, 1965, 1968; zitiert nach Malone, 1981, p. 337). Aber auch Ungewissheit und Konflikt gehören zu den Stimulationsfaktoren. Er erwähnt: „Die vier Begriffe [Neuartigkeit, Ungewissheit, Konflikt und Komplexität] gehören zweifellos zu unseren wertvollsten Instrumenten für die Erforschung der Stimulusselektion“ (Berlyne, 1974, S.38). Diese Begriffe sind in Abschnitt 3.2 erklärt.

Zur weiteren thematischen Verdichtung des Begriffs der Stimulation werden in diesem Abschnitt Stimulationsfaktoren erstellt, die sich hauptsächlich an Berlynes (1974) und Malones Theorien (1981) orientieren und somit für die Gestaltung eines erlebnisorientierten Ansatzes eine essentielle Grundlage darstellen. Durch ständige Veränderungen im Leben wächst das Bedürfnis nach Weiterentwicklung, Erfahrung, Inspiration sowie nach der Bewältigung von Herausforderungen. Menschen sind es ganz allgemein gewohnt, sich ständig neu zu orientieren und sehnen sich nach Unterhaltung und Stimulierung. So stellt bereits der englische Psychologe McDougall (1908) heraus, dass Menschen wie auch Tiere ein grundlegendes Bedürfnis besitzen, nämlich den Erkundungsdrang. Angetrieben von ihrem „Reizhunger“ bzw. Wissensdurst (Schönpflug, 1997, S. 105 f.) erforschen und erkunden Menschen ihre Umwelt, weil sie neugierig sind. Auch Schaulustige eines Unfallorts erklären ihr wissbegieriges Verhalten mit ihrem Neugiertrieb (Schönpflug, 1997, S. 105). Berlyne (1950; zitiert nach Izard, 1950, S. 219) bezeichnet den Drang nach Stimulierung als ein natürliches Phänomen.

Berlyne (1965; zitiert nach Malone 1981, S. 338), spricht im Zusammenhang mit der Entstehung von Neugier von einem „conceptual conflict“. Folgendes Beispiel verdeutlicht seine These: Ist jemand davon überzeugt, dass Fische nicht an Land überleben können, so wird er überrascht sein, sobald er des Gegenteils belehrt wird. Neugier entsteht. Berlyne spricht in solch einem Fall von einem Konflikt, da es zu einem Widerspruch zwischen neuen und bereits gelernten Informationen kommt. In solch einem Fall werden bereits bestehende Wissensstrukturen mit neuen Wissenselementen verknüpft. Dadurch wird Aufmerksamkeit gefordert und Interesse

Des Weiteren konnte er feststellen, dass unregelmäßige und unstimmige Formen die Aufmerksamkeit erhöhen. Abbildung 1 demonstriert ein Experiment zum Thema Inkongruenz und repräsentiert, welche Objekte die höchste Aufmerksamkeit auf sich ziehen. Das Ergebnis zeigt, dass aus der Tier-Serie die Tiere 2 + 4 die höchste Erregung auslösten. Bei der Vogelserie (zweite Reihe) waren es die Vögel 3 + 5. Der Grund hierfür lag in der Schwierigkeit, diese Formen zu identifizieren. Aufgrund erlernten Wissens kollidiert die Wahrnehmung mit den Erwartungen. Die Tiere, welchen besondere Aufmerksamkeit zukommt,

Abb. 1. Inkongruente Bilder von Tieren und Vögeln (aus Berlyne 1957, S. 205)

Abb. 2. Inkongruentes Tier, vergrößert dargestellt (Berlyne, 1958; nach Schönpflug 1997)

Abb. 3. Eine Serie von Figuren zeigt ein Beispiel der Komplexität (aus Berlyne 1957, S. 205)

284

Usability Professionals 2013 Kurzvorträge

besitzen Eigenschaften die Widersprüchlichkeiten hervorrufen. So gibt es kein Tier, das die Hinterbeine eines Hundes und den Kopf eines Elefanten besitzt. Es lässt sich festhalten, dass Menschen aus diesem Grund längere Zeit für das Betrachten „inkongruenter“ Figuren aufbringen als

für andere Figuren (Berlyne, 1974, S. 205). Abbildung 2 stellt vergrößert das inkongruente Tier dar. [Abb. 1], [Abb. 2] Eine weitere Erkenntnis zeigt dasselbe Experiment im Zusammenhang mit der Komplexität. Die Entstehung einer Figur

verdeutlicht, dass mehr Details zu einer erhöhten Komplexität führen [Abb. 3]. Demnach ist Figur 6 komplexer als Figur 1 (Berlyne, 1974, S. 205). Auch hier zieht eine komplexe Figur die Aufmerksamkeit auf sich, weil sie zugleich die weniger vertraute Figur darstellt und daher erst interpretiert werden muss. Auch bringt Berlyne ein Beispiel aus der Kunst. Der spanische Maler Picasso hat es geschafft, durch die Komplexität in seinen abstrakten Bildern Überraschungsmomente aufzuzeigen. Der Beobachter ist zunächst verunsichert und in ihm wird ein Konflikt ausgelöst. Dabei wird sein Denken angeregt, indem er sich mit seinen Erfahrungen und seinem Wissen auseinandersetzt (Schönpflug, 1997, S. 130). Die Abbildung 4 visualisiert „Das Mädchen“ von Picasso. [Abb. 4] 3.2. Stimulationsfaktoren Um zu verstehen, wann Langeweile auf der einen und Neugier auf der anderen Seite eintritt, ist es wichtig zu wissen, welche Reize Aufmerksamkeit auf sich ziehen. Demzufolge eine Übersicht der Stimulationsfaktoren in Tabelle 2: [Tab. 2]

Tab. 2. Stimulationsfaktoren (in Anlehnung an Berlyne 1974, Malone, 1981)

Abb. 4. Ein Bild von Picasso löst einen Konflikt aus (Berlyne, 1958; nach Schönpflug 1997, S. 106)

285

4. Erlebnisideen Dieser Abschnitt widmet sich verstärkt dem konzeptionellen Teil. Exemplarisch wird eine von insgesamt 15 Erlebnisideen sowohl textlich als auch grafisch in Form von Storyboards näher erläutert. Die Idee unterliegt dabei einer eigenen Bewertung, wobei der Grad der Stimulation bewertet wird. „5“ stellt den höchsten Stimulationswert dar. Da der Redakteur des Kinder- und Familienprogrammes vom WDR während des Prozesses über die Ideen informiert wurde, tragen seine Bewertungskritierien in starkem Maße zur Gesamtbewertung des Expertenurteils bei. In Zusammenarbeit mit dem Kinder- und Familienprogramm des Westdeutschen Rundfunks und in enger Abstimmung mit Matthias Körnich, einem Redakteur des WDR, wurde ein Konzept für „Die Seite mit der Maus“ erarbeitet. Hierbei entstanden Ideen, die auf der Grundlage der MausInhalte basieren, jedoch nicht dem Corporate Design der Maus entsprechen.

gewissen Uhrzeit (ca. 21 Uhr) schlafen und schaltet das Licht aus, so dass die Mausinhalte nur noch im Dunkeln aufzurufen sind. Auf der Seite existiert jedoch eine Taschenlampe. Mittels Click & Drag kann der Nutzer die Taschenlampe aufnehmen und gezielt seiner Suche nachgehen. Maus und Elefant haben sich bereits schlafen gelegt. Um zu gewährleisten, dass ältere Kinder die Website zu später Stunde uneingeschränkt nutzen können, gibt es einen Lichtschalter, der sich an- und ausschalten lässt.

4.2. ExperienceSzenario: Noa entdeckt „Die Seite mit der Maus“ im Dunkeln Es ist kurz vor halb 10 Uhr abends. Noa kann nicht schlafen. Er steht auf und macht das Licht in seinem Zimmer an. Seine Freunde haben ihm erzählt, dass in der letzten Maus-Sendung das Thema Beatboxen in einer Sachgeschichte behandelt wurde. Das möchte er sich nun ansehen. Huch, warum ist es denn hier so dunkel, fragt er sich als die Website der Maus geladen ist. Sein Blick wandert zu einer

Dieses Kapitel widmet sich verstärkt dem konzeptionellen Teil. Exemplarisch wird eine Idee sowohl textlich als auch grafisch in Form von Storyboards näher erläutert. Dabei unterliegt diese Idee einer eigenen Bewertung, wobei der Grad der Stimulation bewertet wird. Da der Redakteur des Kinder- und Familienprogrammes vom WDR während des Prozesses über die Ideen informiert wurde, tragen seine Bewertungskriterien in starkem Maße zur Gesamtbewertung des Expertenurteils bei. „5“ stellt den höchsten Stimulationswert dar. Im Anschluss an die Ideendarstellung und -bewertung wurden die Ideen in Szenarien eingebettet, die an das Scenariobased Design von Rosson und Carroll (2002) angelehnt sind. 4.1. Idee „Adaptive Lichtverhältnisse“ Die Idee beruht auf der Imitation realer Tageszeiten. Die Maus legt sich ab einer

286

Abb. 5. Noa entdeckt „Die Seite mit der Maus“ im Dunkeln (eigene Zeichnung in Anlehnung an „Die Seite mit der Maus“)

Usability Professionals 2013 Kurzvorträge

Taschenlampe, die einen hellen Lichtkegel erzeugt. Neugierig wie Noa ist, klickt er auf diese und stellt fest, dass sich die Taschenlampe bewegen lässt. Dann hört er ein leises Schnarchen und bewegt die Taschenlampe in Richtung des Geräuschs – es ist der Elefant, der schläft. Ein kleines Lächeln zeigt sich auf Noas Gesicht. Nach einer kurzen Zeit entdeckt er einen Lichtschalter. Ein Klick darauf und „Die Seite mit der Maus“ ist wieder in ihrer gewohnten Helligkeit vorzufinden. Noa empfindet Freude daran, das Licht an – bzw. ausschalten zu können. Inzwischen ist der Elefant auch wach geworden. Das ist ja wie in der Realität, denkt Noa sich und sucht endlich weiter nach seiner Sachgeschichte. [Abb. 5] 4.3. Bewertung des Stimulationspotentials Insbesondere die Faktoren Veränderung (Hassenzahl, 2003) und Überraschung wirken stimulierend. Aber auch Neuartigkeit und Abwechslung (Gaver & Martin, 2000) tragen im Besonderen zur Stimulierung des Nutzers bei. Der Nutzer kann auf einfache und originelle Weise mit der Taschenlampe interagieren, was die Nutzererfahrung entsprechend erhöht. Vor allem die Imitation der Tageszeiten macht die Idee zu einer besonderen Erfahrung auf der Website. Des Weiteren animiert die neuartige Interaktionsform den Nutzer zur Nutzung der Website, da sie für ihn zunächst ungewöhnlich ist. Die Idee ist universell einsetzbar, denn auf jeder Seite kann sich ein Lichtschalter befinden. Für unerfahrene, unsichere Internetnutzer kann die Verdunklung der Website jedoch im ersten Moment irritierend sein.

5. Fazit

9. Malone, T.W. (1981).Toward a theory of

Das Bedürfnis Stimulation impliziert eine Vielzahl unterschiedlicher Stimulationsfaktoren. Wie sich im Verlauf dieser Arbeit herausstellte, unterliegt das Bedürfnis allerdings der Problematik, dass alles Neue mit der Zeit zur Gewöhnung werden kann. Daher ist es besonders wichtig, in der Gestaltung eines Erlebnisses möglichst viele Stimulationsfaktoren einzusetzen. So kann sichergestellt werden, dass eine Idee für längere Zeit auf den Nutzer stimulierend wirken kann. Interessant für die Weiterentwicklung des Stimulationspotentials wäre es nun zu überprüfen, von welchem Stimulationsfaktor die höchste Stimulierung ausgeht.

10. Reiss, S. & Haverkamp, S.M. (1998). Toward a

intrinsically motivating instruction. Cognitive Science 4, 333–369. Comprehensive Assessment of Fundamental Motivation: Factor Structure of the Reiss Profiles. Psychological Assessment, (10), 97–106. 11. Reiss, S. (2000). Who am I? The 16 Basic Desires That Motivate Our Actions and Define Our Personalities. Berkley Publishing Group: New York. 12. Rosson, M.B., Carroll, J.M. (2002). Usability Engineering. Scenario-Based Development of Human- Computer Interaction. San Francisco: Morgan Kaufmann Publishers. 13. Schönpflug, W. (1997). Psychologie. (4. überarb. Auflage). Weinheim: Psychologie Verlags Union. 14. Sheldon, K., M., Elliot, A.J., Kim, Y. (2001).

Literatur

What Is Satisfying About Satisfying Events?

1. Berlyne, D. E. (1974). Konflikt, Erregung,

Testing 10 Candidate Psychological Needs.

Neugier. Zur Psychologie der kognitiven Motivation. Stuttgart: Ernst Klett Verlag. 2. Berlyne, D. E. (1950). Novelty and curiosity

Journal of Personality and Social Psychology, 80, (2), 325–339. 15. Warth, S., Schneider, S., Lensch. A. K. (2009).

as determinants of exploratory behaviour.

Kinder im Internet – vom virtuellen Spielplatz

British Journal of Psychology, (41), 68–80.

zum Alltagsbegleiter. Eine Qualitative Studie

3. Edelmann, W. (2000). Lernpsychologie (6., überarb. Auflage). Weinheim: Beltz. 4. Hassenzahl, M. (2003). Attraktive Software – Was Gestalter von Computerspielen

über Erleben, Nutzung und Fähigkeiten von Kindern und Jugendlichen im Internet. Mönchengladbach: Elements of Art GmbH. 16. Warth, S., Schneider, S. Erbslöh, S. (2011).

lernen können. In J. Machate & M.

Klick mich. Wie man die Herzen der jungen

Burmester (Hrsg.), User Interface Tuning.

User erobert! Erfolgreiche Emotionalisierung

Benutzungsschnittstellen menschlich

im Online-Marketing für Kids & Teens.

gestalten (S. 27–45). Frankfurt: Software und

Mönchengladbach: Elements of Art GmbH.

Support. 5. Hassenzahl, M. (2006). Interaktive Produkte wahrnehmen, erleben, bewerten und gestalten. In M. Eibl, H. Reiterer, P. F. Stephan, & F. Thissen (Hrsg.), Knowledge Media Design – Grundlagen und Perspektiven einer neuen

Angesichts der aufgeführten Vorteile und Stimulationsfaktoren scheint diese Idee als gelungen bewertet werden zu können, da sie einen wesentlichen Part zur Unterstützung der Stimulation liefert. Auch der Redakteur des Kinder- und Familienprogrammes vom Westdeutschen Rundfunk (WDR) fand Gefallen und die Idee wurde somit von ihm positiv bewertet.

Gestaltungsdisziplin (S. 151–171). München: Oldenbourg. 6. Hassenzahl, M. (2010a). Experience Design. Technology for all the right reasons. o.O.: Morgan & Claypool. 7. Hassenzahl, M. Diefenbach, S., Göritz, A. (2010b). Needs, affect, and interactive products – Facets of user experience. Interaction with computers, 22, 353–362. 8. Izard, C. E. (1994). Die Emotionen

Laut des Expertenurteils wurde dieser Idee der höchste Stimulationsgrad (5) zugeordnet.

des Menschen. Eine Einführung in die Grundlagen der Emotionspsychologie. Weinheim: Beltz.

287

Eine Lernwelt für alle? Stand User Experience Design in einem Bildungsverlag Christiane Schmidt Niederbarnimstrasse 15 10247 Berlin mail: christiane.schmidt@online.de

Maria Mory Karl-Kunger-Strasse 10 12435 Berlin mail: blaukaro7@gmail.com

Abstract In diesem Beitrag geht es um die Erfahrungen mit der Integration von nutzerzentrierten Methoden und Prozessen in einem der größten deutschen Schulbuchverlage. Wir berichten über die Entwicklung eines neuen umfangreichen digitalen Services für alle Nutzer von Unterrichtsmaterialien rund um digitale Schulbücher. Der Umfang und die Wichtigkeit des Projektes war eine einmalige Chance für uns als Produktdesigner und Usability Consultants, nicht nur vereinzelte UX Maßnahmen zu platzieren, sondern zum ersten Mal in einem Projekt den HCD Prozess weitestgehend komplett zu durchlaufen. Wir beschreiben, welche Herausforderungen und Problemstellungen zu meistern waren, welche Wege beschritten wurden und welche Maßnahmen sich bewährt haben.

Einführung Ende 2012 erhielten die digitalen Produkt designer der Abteilung Design von den Geschäftsführern des Schulbuchverlages folgenden Auftrag: es soll ein neuer digitaler, zukunftsorientierter Service erschaffen werden, der für Lehrer/innen eine professionelle Arbeitsumgebung, für Schüler/ innen eine zentrale Lern- und Kommunikationsumgebung sowie für deren Eltern eine Partizipationsplattform ist und auf allen digitalen Geräten zur Verfügung steht. Eine Lernwelt für alle im Kontext Schule, auf allen Geräten und an jedem Ort. Wie kann man sichergehen, dass der Service die Nutzerbedürfnisse aller Zielgruppen beantwortet?

Die Zielgruppen der Verlagsprodukte erstrecken sich auf alle, die sich im Kontext vom curricularen Lernen und Lehren auf halten, vom Schulanfänger bis hin zur Lehrerin mit langjähriger Berufserfahrung. Das sind bundesweit maximal alle 562.400 Lehrer/innen an den allgemeinbildenden

288

Keywords: /// Lernen /// User Experience /// HCD Prozess /// Designprinzipien

Schulen(1) und dazu 8,17 Mill. Schüler (2) mit entsprechend vielen Eltern.

Weshalb sollten die Nutzer diesen Service lieben?

Bisher gibt es ein breites Spektrum an gedruckten Einzelprodukten (jährlich 18000 Titel aus 40 Fachrichtungen), das auf die verschiedenen Anforderungen und Bedürfnisse der Nutzergruppen eingeht. Der neue digitale Service soll aber allem gleichzeitig gerecht werden. Wie man diesem Ziel näher kommt, wird im Beitrag gezeigt.

Der Service soll sich aus der Menge ver gleichbarer Produkte hervorheben und gerne benutzt werden. Wir erklären, wie wir mit der Anwendung der Methode „DesignPrinzipien“ eine Vorarbeit erbracht haben, um eine neue starke Marke zu entwickeln. Unser Anspruch war, dass Markenerlebnis mit einem positiven Nutzungserlebnis zu verknüpfen.

Wie kann der neue Service alle Nutzer gewinnen und Reichweite erlangen?

Ein Service kann nur eine große Reichweite erlangen und Nutzer gewinnen, wenn sein Angebot den Nutzerbedürfnissen entspricht. Um innerhalb der Produktentwicklung das Serviceangebot zu definieren, ist es wichtig das gesamte Ökosystem nicht nur digitaler, sondern auch analoger Verlagsprodukte zu berücksichtigen. Zum einen liegt das Kerngeschäft bisher in der Entwicklung von Printprodukten (lediglich 10% des Verlagsportfolios sind durch digitale Produkte abgedeckt), zum anderen orientiert sich die Mehrheit der Lehrer am gedruckten Schulbuch.

Wie kann man ein umfangreiches Projekt entwickeln, wenn Usability und User Experience weder im Projekt noch in der Organisation verankert sind?

Während die technische Produktentwicklung bereits auf agile und flexible Prozesse des Scrum Verfahrens umgestellt wurden, sind bisher die Verfahren zur Sicherung der Usability und User Experience weder mit den Scrumprozessen synchronisiert noch in der Organisation stabil verortet. Nur im Rahmen von einzelnen Produktentwicklungen wurden bisher, vor allem aus der Perspektive des digitalen Produktdesigns, Methoden der Gebrauchstauglichkeit in die Projekte eingebracht.

Usability Professionals 2013 Kurzvorträge

Der Projektauftrag: Bedingungen und Umfang klären Im Rahmen der Produktentwicklung des neuen Services sollte die Abteilung Design einen Pitch zwischen mehreren Designagenturen organisieren und innerhalb von drei Monaten die Entwicklung des Interfaces sowie die Erstellung eines HTML-Dummies betreuen. Parallel dazu sollte die Entwicklung einer Produktmarke angestoßen und zum Abschluss in Kooperation mit einer User-Experience Agentur ein Nutzertest durchgeführt werden.

Das Konzept für das neue Produkt war bereits verfasst. Es gab eine Projektplanung, die in einem engen Zeitplan den Start der Scrumprozesse vier Monate später vorsah, und in der festgelegt worden war, die Produktentwicklung mit der Lehrerschaft als Empfehler und Kaufentscheider der Verlagsprodukte zu starten. Es gab viele verschiedene Stakeholder mit nicht geklärten Entscheidungsmandaten, ein sich aufbauendes starkes Technikteam und ein Berater-Team aus Lehrern. Es war klar, dass angesichts des Projektumfangs im Gegensatz zu den meisten

anderen Projekten mehr als ein Produktdesigner involviert werden müsste. Aus diesem Grund schlugen wir ein 3 köpfiges Team vor, das über den Zeitraum von einem halben Jahr den Start des Projektes betreuen sollte. Wir fanden an diesem Punkt die Zustimmung der Projektleitung. Die größere Herausforderung war es, die Projektleitung davon zu überzeugen, dass es nicht genügen würde, mit dem vorhandenen Konzept einen Agenturpitch zu organisieren, wenn man die angestrebte hohe Qualität erreichen wolle. Die Kunst war, die Projektverantwortlichen nicht zu

Abb. 1. UX-Plan in Anlehnung an das EbenenModell von Jesse James Garrett (3)

289

kritisieren, sondern den Weg zu öffnen für die Validierung der Konzeptideen durch mehr User Research und Analyse. Wir fuhren zweigleisig: Wir fanden im vorhandenen Konzept keine objektiven Bewertungskriterien für die geplanten Gestaltungslösungen. Aus diesem Grund war es unklar, wie ein Pitch zwischen mehreren Design-Agenturen zu bewerten gewesen wäre. Eine Bewertung auf rein visueller Basis hätte die Qualität der Benutzung nicht berücksichtigt. Zudem wäre das Risiko der Überarbeitung der Designs ohne vordefinierte Kriterien zu hoch gewesen. Wir schlugen daher vor, ein stärkeres Gewicht auf die Passung zwischen den Verlags- bzw. Produktzielen und den Nutzerbedürfnissen zu legen. Dazu sollte der Nutzungskontext analysiert und anschließend die Nutzungsanforderungen definiert werden. Diese sollten Grundlage sein für die geplanten Evaluationen, die Tests, die Gestaltungslösungen und die Markenentwicklung. Parallel empfahlen wir die Entwicklung eines Prototypen, der den Konzeptstand und die konzeptionellen Lücken visualisieren sollte. Auf den Agenturpitch sollte verzichtet werden. Der Prototyp und die Ergebnissen der Kontextanalyse sollten unsere Grundlage sein für die erste Phase der Scrumprozesse. Der UX-Plan: Unterstützung durch Visualisierung Um diese Argumente und unser Vorgehen verständlich zu kommunizieren, war eine starke Visualisierung nötig, ein normaler Projektplan in Excel-Listen-Form hätte dies nicht abbilden können. Wir entschieden uns für das Ebenen-Modell von Jesse James Garrett (3), da es sich gut eignet, zu vermitteln, dass Gestaltungsprozesse nicht nur eine Frage der Oberflächengestaltung sind, sondern sich in jeder Phase der Projektentwicklung wiederfinden. Wir arbeiteten das Modell zu einem UX-Plan um, formulierten zu den einzelnen Ebenen des Modells Fragestellungen und beschrieben die möglichen

290

Vorgehensweisen. In Kombination mit der zeitlichen Dimension, entstand so unser visueller UX-Plan. In der Abbildung 1 werden die Ebenen des UX-Plans von der Konzeptbasis unten bis zur visuellen Umsetzung oben beschrieben. [Abb. 1] Mit Hilfe dieses UX-Plans konnten wir den Stakeholdern Ebene für Ebene den qualitativen Mehrwert der nutzerzentrierten Maßnahmen für das Projekt kommunizieren und sie davon überzeugen, diese Maßnahmen durchführen zu dürfen. Im Folgenden werden 4 Maßnahmen des UX-Plans beschrieben. Wir haben sie in Workshops mit den Projektteilnehmern, der Projektleitung und externen Designagenturen durchgeführt. Dabei arbeiteten wir nach einem gleichen Muster: zu Beginn erklärten wir die Methode mit Handouts und Präsentationen, führten die Workshops mit Hilfe von vorbereiteten Arbeitsmaterialien durch und werteten anschließend die Arbeitsergebnisse aus. Personas: Klärung der Nutzerbedürfnisse Um die Bedürfnisse der Nutzer der Hauptzielgruppe Lehrer besser zu verstehen, organisierten wir zunächst einen Workshop zur Entwicklung von Personas. Hierbei hatten wir zwei Herausforderungen zu meistern: zum einen war die Idee der Personaentwicklung bereits seit einigen Jahren durch die Abteilung Marketing besetzt. Es war schwer, das Projektteam davon zu überzeugen, neue prototypische Nutzer zu erarbeiten, die nicht Stellvertreter einer großen Zielgruppe mit bestimmten Hang zu einer Marke oder idealtypische Nutzer waren (Anmerkung 1), sondern Stellvertreter der späteren Produktnutzer mit all ihren Nutzungsanforderungen. Zum anderen war keine Zeit vorgesehen, per Interviews die Personas qualitativ zu untermauern. Es blieb nur die Möglichkeit, auf bereits existierendes Material zurück zugreifen, um daraus Ad-Hoc-Personas zu entwickeln.

Folgende Schritte haben wir unternommen, um Personas zu erarbeiten 1. Auswertung der Kontext-Daten und Dokumentation der Ziele, Hürden und Aufgaben von Lehrern/innen aller Altersgruppen, Fächer und Schulformen. 2. Einschätzung der Dimensionen des Verhaltens der Lehrer/innen durch die Teilnehmer des Workshops. 3. gemeinsame Clusterung und Auswertung der Dimensionen. Folgende Erkenntnisse konnten wir in dem Personaworkshop gewinnen und in die Produktentwicklung einbringen: Fast alle Lehrer (bis auf wenige Ausnahmen) verbindet ein relativ langes, gradliniges Berufsleben: vom Referendariat, über eine mehrjährige Berufspraxis, Auszeit durch Elternzeit und Wiedereinstieg mit Teilzeit, bis hin zum langsamen Ausstieg aus dem Job. Alle legen sich bereits im Referendariat eigene analoge wie digitale Systeme zur Materialverwaltung und Schülerorganisation an, auf die sie dann in ihrem weiteren Berufsleben zurückgreifen. Sie aktualisieren ihre Daten je nach Änderung der Curricula. In der Regel haben Lehrer die gleichen Kernaufgaben: –– Organisation des Unterrichts nach Vorgabe der landesweiten Rahmenpläne und Verwaltung der Unterrichtsmaterialien –– Durchführung des Unterrichts –– Diagnose, Überprüfung und Bewertung von Lernständen der Schüler –– Kommunikation mit Schülern, Eltern und Kollegen. Diese Kernaufgaben werden von den Lehrern unterschiedlich ausgeführt, dabei spielt ihre Berufserfahrung, ihre Medienkompetenz und ihre Zugehörigkeit zu bestimmten Schulformen eine größere Rolle als ihr Lehrfach. Dementsprechend unterschiedlich sind die Anforderungen an unterstützende Materialien und Maßnahmen.

Usability Professionals 2013 Kurzvorträge

Berufserfahrung

Die Berufseinsteigerin braucht eine Fülle von neuen Materialien und die Sicherheit, daß das Material dem Rahmenlehrplan entspricht, während der ältere Kollege seit langem über einen ausreichend großen Materialfundus und die Sicherheit verfügt, sich aber ein Ordnungssystem wünscht, das ihm die Suche erleichtert. Medienkompetenz

Die Profivollzeitlehrerin an einer Gesamtschule arbeitet gerne nur digital, ist aber gänzlich auf sich gestellt, während ihre Kollegin aus der Grundschule stark mit anderen Lehrern zusammen arbeitet, allerdings nur analog. Schulform

Die Teilzeitlehrerin der Sekundarstufe 1 ist derzeit als Vertretungslehrerin beschäftigt, sie braucht starke fachliche Unterstützung in den ihr oft fremden Unterrichtsthemen, während die Oberstufenlehrerin am Gymnasium gerne stärker kollaborativ vorgeht.

Wir haben 4 Personas entwickelt, die den Dimensionen innerhalb der Berufserfahrung, der Medienkompetenz, der Schulform entsprechen und zugleich beschreiben, wie die Personen arbeiten. Mit den Personas konnten wir den Stakeholdern die Aufgaben und die Ziele der späteren Benutzer nahe bringen und im Projekt eine einheitliche, gemeinsam erarbeitete Vorstellung der Nutzungskontexte vermitteln. Mit Hilfe der Personas war es nun möglich, die ersten zeitgleich entstanden Featurelisten zu priorisieren. Design-Prinzipien: Definition der Produktziele Nachdem wir die Personas entwickelt und die heterogene Lehrerschaft eingegrenzt hatten, organisierten wir einen Workshop, um die Produktziele mit Hilfe der DesignPrinzipien genauer zu definieren. Was sind Design-Prinzipien und wofür?

Design-Prinzipien sind nicht mit DesignPattern oder universalen Designregeln

wie z.B. den 10 Designprinzipien von Dieter Rams (4) zu verwechseln. Sie sind ein strategisches Design-Tool. Sie helfen einen Konsens unter allen Projektbeteiligten zu finden, Entscheidungen nach festen Regeln zu treffen und ein gemeinsames Verständnis für die Bedürfnisse der Nutzer zu aufzubauen (Anmerkung 2). „Design-Prinzipien sind die Lichtgestalt für jede Software-Anwendung. Sie definieren und kommunizieren die wichtigsten Merkmale der Anwendung, an eine Vielzahl von Beteiligten, einschließlich der Kunden, Kollegen und Teammitglieder. DesignPrinzipien formulieren die grundlegenden Ziele, an denen alle Entscheidungen gemessen werden können und dadurch werden die Einzelteile eines Projektes in eine Richtung eines integrierten Ganzen bewegt.“(5) Warum Design-Prinzipien?

In sehr großen oder komplexen Projekten gibt es oft viele Projektbeteiligte und genauso viele unterschiedliche Interpretationen des Projektziels. Oft ist nicht klar,

Abb. 2. Bewertungskriterien durch Designprinzipien und Personas

291

3. Meine lebendige Komposition: Ermögliche den Nutzern die maximale Flexibilität und Kreativität. Diese Design-Prinzipien in Kombination mit den Personas lieferten eine gute Argumentationsbasis, um Konzeptverfeinerungen, Anforderungsbeschreibungen (Epic Stories) sowie Screendesigns zu bewerten und eine konsistente Markenführung aufzubauen. [Abb. 2] Low Fidelity Prototyp: Klärung der Struktur

Abb. 3. Customer Journey Map einer Lehrer-Projektgruppe

wie lange und in welcher Rolle jemand am Projekt beteiligt ist. Es sind unterschiedliche Erwartungen an die Qualität des Produktes vorhanden, unklare Grenzen und Visionen. Manchmal gibt es konkurrierende Anforderungen, oft überschreiten die Ambitionen die vorhandenen zeitlichen und personellen Ressourcen. Teilweise ist der Projektumfang zu weit gegriffen, in dem alle potentiellen Kunden auf einmal erreicht werden sollen. Beste Voraussetzungen für das hilfreiche Werkzeug „Design-Prinzipien“.

Um diesen Anforderungen gerecht zu werden, formulierten wir diese Fragestellungen: –– Weshalb sollten die Nutzer diesen digitalen Service lieben? –– Wo liegen die größten Probleme und Herausforderungen für die Nutzer? –– An welchen Stellen und wie kann die Anwendung die Lehrer unterstützen? –– An welchen Stellen und wie können die Eltern und Schüler unterstützt werden? –– Welche Handlungsmaximen könnten Gestaltungsregeln werden?

Wie entwickelt man Design-Prinzipien?

Mit jeder Fragestellung verdichteten sich die Ergebnisse. Wir gruppierten und sortierten die Ergebnisse und fanden gemeinsam Oberbegriffe. Die Anzahl der möglichen Design-Prinzipien sollte nicht zu hoch sein, da sie leicht kommunizierbar und verstanden werden sollten. Daher bewerteten wir am Ende des Workshops gemeinsam die Cluster, um eine Priorisierung zu finden.

Am effektivsten ist es, sie in einem Workshop im Projektteam zu entwickeln, um alle Beteiligten an den Designentscheidungen teilhaben lassen. Design-Prinzipien sind Statements zum Produkt aus der Sicht der Organisation. Das bedeutet, dass bei der Entwicklung der Design-Prinzipien nicht nur Designer und Konzepter beteiligt sein sollten, sondern auch Stakeholder und Vertreter der IT. Die Basis für Design-Prinzipien sind die Ergebnisse der Kontext- und Aufgabenanalyse sowie die Produktziele. Design-Prinzipien dürfen nicht zu allgemein formuliert sein. Sie sollten kurz, prägnant und für das Projektteam inspirierend sein.

292

Die Auswertung des Workshops ergab für uns 3 Design-Prinzipien, die in kurzer Zeit jeder der Projektteilnehmer auswendig kannte. 1. Content im Kontext: Biete dem Nutzer das, was für die jeweilige Situation und den Ort richtig ist. 2. Finden statt Ordnen: Ermögliche das schnelle Finden und leichte Organisieren für alle Nutzer.

Parallel zu den Workshops der Designprinzipien und Personas haben wir einen Low Fidelity Prototypen mit dem Tool Axure entwickelt. Das Ziel war, durch diese Maßnahme die Struktur des Services zu umreißen und Grundlagen zu schaffen für den beginnenden Scrumprozess. Relativ schnell zeigte sich, dass die Prototypentwicklung zusehends in Konflikt mit der beginnenden Phase der Konzeption der Epic-Stories kam. Die Verschränkung beider Entwicklungen war ohne vorher definierte Prozesse so gut wie nicht möglich. Während einerseits unsere Aufwände das Prototyping zu betreuen expandierten, konnten wir andererseits mit Hilfe des Prototyps unser Ziel, der Projektleitung die Lücken im Konzept auf zu zeigen, gut verfolgen. Customer Journey Map: Überprüfung des Umfangs Um alle vorab entwickelten Erkenntnisse zu überprüfen, führten wir einen Workshop mit Lehrern durch. Wir wollten herausfinden, welche Bedarfe die Lehrer thematisieren, und ermitteln, ob wir mit unserer Datenanalyse und Personaentwicklung richtig lagen. Das Entwickeln von Customer Journey Maps wird zur Überprüfung bestehender Produkte und zur Erabeitung von Verbesserungspotentialen empfohlen. Wir haben jedoch diese Methode abgewandelt, um auf diesem Weg herauszufinden, wie Lehrer im Detail arbeiten und vor allem welche Hürden sie zu überwinden haben.

Usability Professionals 2013 Kurzvorträge

In Zusammenarbeit mit der Abteilung Marketing bereiteten wir eine Tagebuchstudie vor. In den Tagebüchern dokumentierten die Lehrer ihre täglichen Arbeitsschritte. In Vorbereitung des Workshops werteten wir die ausgefüllten Tagebücher aus und filterten die häufigsten Aufgaben (nach Aufwand und Zeit) heraus. Im Workshop ließen wir die Teilnehmer in Kleingruppen Aufgaben aus ihrem Arbeitsalltag genauer betrachten und in Teilaufgaben zerlegen. Anschließend bewerteten sie die Teilaufgaben nach ihrem eigenen Erleben in gute oder schlechte Erfahrungen. Es ließ sich folgender Unterstützungsbedarf bei allen Gruppen in unterschiedlicher Schwere lokalisieren: alle Teilnehmer äußerten Probleme bei der Organisation ihrer Unterrichtsmaterialien. Die Suche nach geeignetem Material, aber auch das Archivieren über Jahre bis hin zur Aktualisierung nimmt ihnen Zeit, die ihnen an anderer Stelle fehlt. „Für 45 min Unterricht surfe ich 2 Stunden und nehme am Ende Material, das ich schon hatte.“

Weiterhin thematisierten sie Probleme ihrer Arbeitsweisen und Arbeitsstrukturen. Da sie zum Großteil allein und nicht im Team arbeiten, entstehen wenig Synergien. „Jeder erfindet das Rad einzeln neu, das kann nicht effizient sein.“ Die meisten Teilnehmer bemängelten die fehlende Unterstützung bei Problemen mit Schülern und Eltern sowie Kollegen, „Die Schüler sind undiszipliniert und stressen mich“, „Die Eltern sind mir das unangenehmste“, und Probleme bei der Arbeits-Organisation, „Die Klassen sind zu groß und ich habe keine Zeit, um auf jeden Schüler adäquat einzugehen“. „Dass meine Kollegen immer wieder krank sind und ich sie vertreten muss, belastet.“

Die Methode Customer Journey Map hat uns auf sehr effektive Art und Weise detail liertere Erkenntnisse zur Arbeitsweise der Lehrer geliefert. Wir haben Einsichten und authentische Beschreibungen zu ihren größten Hürden erhalten. Im nächsten Schritt erarbeiten wir mit Hilfe des Prototypen Gestaltungslösungen, die in Zukunft diese Hürden der Nutzer berücksichtigen. [Abb. 3] Fazit „Eine Lernwelt für alle“, einen Service für alle zu entwickeln, ist nur möglich, wenn man auf die Nutzer und deren genaue Bedarfe eingeht. Um diese herauszufinden, sollte man sukzessive und mit einer Serie von nutzerzentrierten Maßnahmen planvoll vorgehen. Das Fundament ist eine starke Anforderungsanalyse für die es eine besondere Überzeugungskraft braucht. Nutzerzentriert vorzugehen heißt eben nicht nur testen, sondern den Nutzer verstehen lernen.

direkten Kontakt die Bedarfe in all ihrer Varianz aufzunehmen. Wir haben gelernt, dass dieses erkenntnisreiche Zusammentreffen schon in frühen Projektphasen hätte stattfinden sollen. Wir haben projektplanbedingt bisher nur in Ansätzen die Schüler und Eltern berücksichtigt, dennoch ist durch die Betrachtung der Lehrerschaft der Prozess definiert. Die beiden Nutzergruppen werden im nächsten Projektschritt bearbeitet. Mehr UX in Bildung! Literatur 1. http://de.statista.com/statistik/daten/ studie/201496/umfrage/anzahl-der-lehrer-indeutschland-nach-bundeslaendern/ 2. http://de.statista.com/statistik/daten/ studie/1321/umfrage/anzahl-der-schueler-anallgemeinbildenden-schulen/ 3. (3) Jesse James Garrett, (2012), Die Elemente der User Experience, AddisonWesley Verlag, München 4. (4) http://weblogit.net/2013/04/15/10-

Der Stand des User Experience Design im Verlag bezieht sich derzeit auf die Grundlagenarbeit und Vermittlung der Methoden, was aber zählt, ist, diese auszuprobieren. Dabei hat sich gezeigt, dass bewährte Methoden wie die Personaentwicklung nicht unbedingt geeigneter sind als andere, weniger bekannte Methoden wie die Customer Journey Map. Alle Maßnahmen sollten auf die Konstellationen angepasst sein.

designprinzipien-von-dieter-rams-undapple-35860/ 5. (5) Luke Wroblewski http://www.lukew.com/ ff/entry.asp?854

Anmerkung 1 Eine sehr gute Übersicht, wann und wie Alan Coopers Idee der Personas adaptiert wurde, gibt folgende Infografik http://uxmag.com/sites/default/files/uploads/

Wir haben ein Basisbewusstsein für die Notwendigkeit des nutzerzentrierten Vorgehens geschaffen und den Stakeholdern verdeutlichen können, dass mehr Iterationen bei der Konzeptentwicklung nötig sind. Wir haben Einfluss auf die Pro duktentwicklung genommen, so dass jetzt das Produktmodularer aufgebaut sein wird. Unterschiedlichen Nutzern wird der digitale Service passgenaue Angebote liefern und je nach Nutzerbedarf flexibel einstellbar sein.

moorman-edeker-personas/personastimeline.png

Anmerkung 2 Näheres zu Verwendung von „DesignPrinzipien“ im Kontext von User Experience und Usability findet man z.B. in Lennart Hennings Beiträgen unter http://www.usercentered.de/design/ ueber-designprinzipien/

Die Erfahrungen mit der direkten Zusammenarbeit mit den Lehrern haben uns gezeigt, dass es sich lohnt, auch im

293

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

Abstract DIE WELT startete 2012 als erstes großes Nachrichtenportal in Deutschland mit kostenpflichtigen Angeboten im Web. Als besondere Herausforderung galt es dabei, ein funktionierendes Bezahlmodell für alle digitalen Plattformen von DIE WELT, wie zum Beispiel stationäres Web, mobiles Web, Apps für Tablets und Smartphones bei iOS und Android, zu finden. Es sollten Prozesse geschaffen werden, die bereits als Silo existierende kostenpflichtige App-Angebote integrieren. Bereits sehr früh war klar, dass dieses Projekt nur mit agilen Methoden technisch erfolgreich umgesetzt werden kann. Die Wahl fiel, dem Zeitgeist folgend, auf Scrum mit UserStories. Aufgrund der zu erreichenden Ziele und der bevorstehenden Aufgaben war die Befürchtung, es handele sich um ein rein technikgetriebenes Projekt, sehr groß. Trotzdem gelang es, Usability- bzw. User-Experience-(UX)-Aktivitäten durchzuführen, ohne den Entwicklungsprozess zu verzögern. Anhand unserer Erkenntnisse und anhand von Beispielen soll dabei die Frage beantwortet werden, wo sich Chancen und Möglichkeiten bieten, bei einem nach Scrum mit User Stories geplanten Projekt Usability- bzw. UX-Aktivitäten durchzuführen.

1. Überblick 1.1. Strategische Ziele & Herausforderungen Als erstes großes Nachrichtenportal in Deutschland startet DIE WELT kostenpflichtige Angebote im Web und findet dabei eine Möglichkeit, bestehende zahlende User der App-Produkte und andere digitale Angebote, wie die mobile Website, zu integrieren. Eine besondere Herausforderung bestand darin, ein funktionierendes Modell für alle Plattformen zu finden und somit einheitliche Prozesse zu schaffen.

User betrachtet, erhalten die Bedürfnisse der Technik- und Business-Seite also mehr Beachtung als die der User. [Abb. 1] Eine weitere Herausforderung zeigte sich in dem Vorgehen nach Scrum. Zwar wird bei WELT DIGITAL schon seit einiger Zeit mit agilen Methoden gearbeitet, Scrum stellte jedoch etwas wirklich Neues dar.

Als Modell wurde das „Metered Model“ mit Produkt-Bundles gewählt. Wir wollten also über alle Plattformen hinweg eine positive User Experience erzeugen. Jedoch wurde dies nicht explizit als strategisches Ziel definiert.

Zudem waren große organisatorische Herausforderungen zu meistern. Viele der Produkte von WELT DIGITAL waren über Jahre hinweg als Silos gewachsen. So gab es je Tablet- und Smartphone-App zum Beispiel unterschiedliche Dienstleister, so dass über die gesamte Projektlaufzeit ca. zwölf Dienstleister beteiligt waren. Hier galt es, die Bedürfnisse der Beteiligten so zu berücksichtigen, dass diese losgelöst von ihren persönlichen Interessen an einem Strang zogen.

Werden die strategischen Ziele im Spannungsfeld zwischen Business, Technik und

Auch bei der Beteiligung aller internen Stakeholder stellte sich die Situation

294

Keywords: /// Bezahlmodell /// Welt Digital /// Nachrichten /// Scrum

nicht anders dar. Deren Bedürfnisse galt es ebenfalls zu berücksichtigen. Schließlich mussten sich sämtliche Stakeholder der Konsequenzen von Entscheidungen bewusst sein. Leider wurde hier zu Beginn nicht ausreichend stark berücksichtigt, dass Scrum eigentlich nur ein Vorgehen zur Entwicklung von Software ist. Unsere komplette Organisationsstruktur ließ sich in diesem kurzen Zeitraum nicht auf diese Prozesse umstellen. Eine weitere Herausforderung besteht also darin, die Anforderungen weiterer nicht direkt am Scrum-Prozess beteiligter Stakeholder zu berücksichtigen. Ein großer Teil der internen und externen Mitarbeiter hatte zudem noch nie nach dem Scrum-Prinzip gearbeitet und musste zunächst mit den dazugehörigen Aufgaben und der entsprechenden Arbeitsweise vertraut gemacht werden.

Usability Professionals 2013 Kurzvorträge

Dadurch entstand vor der eigentlichen Umsetzungsphase zunächst eine längere Vorbereitungsphase. In dieser Phase wurden nicht nur die noch offenen strategischen Fragen geklärt, sondern auch die Grundlagen für die Usability-Aktivitäten geschaffen. 1.2. Entscheidende Fragen – „Was müssen wir bieten, damit User überhaupt bereit sind, für unsere Produkte zu bezahlen?“ – „Wie muss der Kaufprozess gestaltet sein?“ – „Welchen Service können wir zusätzlich bieten, um unsere Produkte noch attraktiver zu machen?“ – „Wie gehen wir mit den Fragen der User nach dem ‚Warum‘ um?“ Abgeleitet aus den Zielen und Herausforderungen lassen sich ohne Probleme noch weitere solcher Fragen und daraus sinnvolle Aktivitäten ableiten. Diese Fragen können ihrerseits mit Usability-Aktivitäten beantwortet werden, wobei deren Beantwortung nicht zu den Kernkriterien für einen Projekterfolg zählt. 2. Strukturen und Teamorganisation 2.1. Aufteilung auf zwei Bereiche Unsere Erfahrung bei der Umsetzung großer Softwareprodukte hat gezeigt, dass der Umsetzungsprozess möglichst gut geschützt sein muss. Auch in diesem Fall wurde deshalb als oberstes Gebot erlassen: „Der technische Projekterfolg darf nicht gefährdet werden.“ Unter Berücksichtigung unserer strategischen Ziele bot es sich an, die UsabilityAktivitäten in zwei Bereiche aufzuteilen. Der Kernbereich beinhaltet dabei Aktionen, welche direkt mit den Scrum-Prozessen verwoben sind. Zum Nebenbereich zählen Aktivitäten, welche die User Experience im gesamten Kontext des Produkts verbessern sollen. Auf die Details wird in einem späteren Abschnitt noch genauer eingegangen.

Abb. 1. Verteilung der Aufmerksamkeit bei unserem Projekt

Wie lassen sich die Aktivitäten der beiden Bereiche so trennen, dass ein harmonisches Zusammenspiel zwischen beiden Bereichen trotzdem sichergestellt ist? Zum einen ist eine Trennung auf technischer Ebene möglich, indem getrennte Technik-Teams eingesetzt werden. Zum anderen handelt es sich um eine Kernaufgabe des Produktverantwortlichen (bei Scrum der Produkt Owner), in seiner Schnittstellenfunktion sicherzustellen, dass die vorhandenen Informationen, Fortschritte und Erkenntnisse des Kernbereichs jederzeit an das Team des Nebenbereichs kommuniziert werden. 2.2. TeamOrganisation Insgesamt waren ca. 150 Personen aktiv am Projekt beteiligt. Aufgrund der Umsetzung mit Scrum erscheint das Team für Usability und UX mit einer bestimmten Person im Vergleich zum Rest des Teams

stark unterrepräsentiert zu sein. Wird der Product Owner jedoch aus dem Bereich Produkt Management gestellt und hat ein Gefühl für das Thema entwickelt, kann er Usability-Themen trotzdem platzieren. 4.2.1. TechnikTeam Die technische Umsetzung des Projektes startete im Juni 2012. In der Vorbereitungsphase wurde zunächst das Technik-Team rekrutiert und die technischen Möglichkeiten wurden evaluiert. Ab Juni 2012 blieben noch sechs Monate bis zum geplanten Start. Das Technik- Team konnte eine erfolgreiche Projektumsetzung nur zusichern, wenn das Produkt-Team einen Product Owner mit absoluter Entscheidungsfreiheit stellte. 4.2.2. ProduktTeam Um den Product Owner in der täglichen Arbeit zu unterstützen, wurden weitere

295

Product Owner Proxies berufen. Dadurch standen allen Stakeholdern Spezialisten als Ansprechpartner zur Seite. Zum Beispiel wurde ein kleines Team für Konzeption und Anforderungsmanagement gebildet, welches auch für die Usability- und UXAktivitäten verantwortlich war. Durch einen sehr hohen Grad an Transparenz und Abstimmung innerhalb des Product Owner Teams waren sämtliche Proxies fähig, stellvertretend für den eigentlichen Product Owner Entscheidungen zu treffen. Als besonders wichtig erwiesen sich hierbei die Dokumentation der Tätigkeiten sowie eine einheitliche Begriffsverwendung. 3, Projektverlauf 3.1. Zeitraum Vorbereitung Gerade in der Vorbereitungsphase bietet sich die Chance, einige wichtige UX-Aktivitäten durchzuführen. Schwerpunkte bildeten die Analyse des Nutzungskontexts und die Ableitung von Anforderungen. Der Sprint 0 hat bei uns zum Beispiel ca. 1/3 der Gesamtprojektlaufzeit in Anspruch genommen. Für die Analyse und das Festlegen des Nutzungskontexts gab es in unserem Projekt zwei Quellen. Zum einen lag in unserem Unternehmen bereits Wissen vor, zum anderen konnten in der Projektvorbereitungsphase noch fehlende Informationen aus externen Quellen gesammelt werden. Hier muss man natürlich je nach Zeitrahmen abwägen, welche Maßnahmen möglich sind. Unsere Erfahrung hat jedoch gezeigt, dass beispielsweise schon mit Interviews und Umfragen sehr gute Ergebnisse erzielt werden können. 3.1.1. Interne Quellen Ein großer Teil der Nutzungsanforderungen konnte aus den im Unternehmen vorhandenen Informationen abgeleitet werden.

296

Studien zur Kundenzufriedenheit

Die interne Marketing-Abteilung konnte Erkenntnisse aus öffentlichen Studien und früheren Forschungsergebnissen gewinnen. Neben quantitativen Befragungen wurden regelmäßig kleinere qualitative Usability-Interviews durchgeführt. Support-E-Mails, Kundenanfragen und Bewertungen aus App Stores

Als vorteilhaft erwies sich zudem der Kontakt zu unseren Usern der iPad App WELT HD. Dort pflegen wir bereits seit Veröffentlichung des iPad im Jahr 2010 den Kontakt zu unseren Usern und erhalten von diesen Feedback. Auch ein Blick in die Bewertungen der App Stores hat sich gelohnt. Erkenntnisse aus der eigenen Vergangenheit

Die Rekapitulation der eigenen Historie fiel ebenfalls sehr aufschlussreich aus. Im regionalen Umfeld konnten wir bereits Erfahrung mit der Einführung von Paid Content auf den Websites des Hamburger Abendblatt und der Berliner Morgenpost sammeln. Vor allem konnten hieraus Schlüsse gezogen werden, wie die Veränderungen am besten an die User zu kommunizieren sind. 3.1.2. Externe Quellen Spezielle Studien

Initiiert durch das Business-Team wurde speziell für die Einführung des Bezahlmodells eine Studie mit dem Ziel, die Erwartungen der Leser besser zu verstehen, in Auftrag gegeben. Diese Studie wurde im Zeitraum der Vorbereitungsphase bis zum technischen Projektstart im Juni 2012 durchgeführt. Dort wurde nicht nur nach einer möglichen Zahlungsbereitschaft, sondern zum Beispiel auch nach Inhalten, Features und Erwartungen an unsere Produkte gefragt. Analyse von Mitbewerbern

Ein weiterer Schritt war die Analyse internationaler Mitbewerber, welche bereits seit

längerer Zeit erfolgreich mit Bezahlmodellen arbeiten. So lassen sich die größten Stolpersteine umgehen. 3.2. Zeitraum der Umsetzung und Entwicklung Aus Usability-Sicht haben wir uns entschieden, während der Umsetzung zweigleisig zu fahren. Damit meinen wir, dass neben Usability-Aktivitäten, welche direkt auf den Kernbereich des Projektes einzahlen, auch Aktionen für den Nebenbereich durchgeführt werden sollten, welche eine positive Auswirkung auf die User Experience des gesamten Produktes zeigen. Unter Kernbereich ist dabei das zu verstehen, was zum eigentlichen Bezahlmodell gehört – also vom ersten Erscheinen der Bezahlaufforderung über die Registrierung und Eingabe der Zahlungsdaten bis zum eigentlichen Kaufabschluss. Als Nebenbereich haben wir alle anderen Aktivitäten bezeichnet, welche zu einer Verbesserung des eigentlichen Produktes, wie z. B. der stationären Website, Apps oder auch Bearbeitung von Supportanfragen, führen. 3.2.1. Bedürfnisse der User Vor der Erläuterung der eigentlichen Aktivitäten sollen im folgenden Abschnitt ganz grob die von uns ermittelten Bedürfnisse der User aufgezeigt werden. Die Ermittlung erfolgte durch die eigens durchgeführte Studie während der Vorbereitungsphase des Projektes. Interviews hatten zunächst zum Ziel, Benchmarks zu erheben. Um die Daten zu verstehen, wurden anschließend in Fokusgruppen die Bedürfnisse qualifiziert. Zuletzt wurden diese Erkenntnisse dann durch quantitative Online-Befragungen quantifiziert. Daraus konnten schließlich folgende Bedürfnisse an die Einführung von Bezahlmodellen ermittelt werden: –– Eine größere Informationstiefe und eine individuelle Präsentation bestimmter Themen –– Nutzbarkeit von Features über alle Produkte hinweg

Usability Professionals 2013 Kurzvorträge

–– Direkter Draht zur Redaktion –– Datenschutz und Sicherheit der persönlichen Daten –– Geringere Fehlertoleranz bei der Nutzung der Produkte –– Exklusive Inhalte und Features gegenüber Nicht-Bezahlern Es galt nun, diese Bedürfnisse mit entsprechenden Aktivitäten im Kern- und im Nebenbereich umzusetzen. 3.2.2. Usability-Aktivitäten im Kernbereich Scrum-Prozess maßschneidern

Mitte Juni 2012 startete die technische Entwicklung mit dem ersten Sprint. Während des zweiten Sprints konnte jedoch festgestellt werden, dass es trotz der sorgfältigen Erfassung der Requirements durch die hohe Komplexität der Prozesse problematisch war, diese Requirements abzubilden und daraus die notwendige Backlog-Priorisierung abzuleiten. Das Technik-Team bat die konzeptionelle Fachabteilung um die Visualisierung der Requirements. Dies geschah in Form von Wireframes, Clickdummies und Prototypen. Rückblickend hätte dies bereits in Sprint 0 erledigt werden müssen. So mussten diese Arbeiten von uns innerhalb kürzester Zeit nachgeholt werden. U-Boot-Taktik

Aufgrund des starken Fokus auf den technischen Projekterfolg erwies sich eine Art U-Boot-Taktik zur Durchführung von Usability-Aktivitäten in unserem Projekt als Chance. Diese Taktik lässt sich sich bildlich so vorstellen:

Wir entschieden uns zunächst, mit der Abbildung aller Prozesse in abstrakten Wireframes zu beginnen, daraufhin mit der Entwicklung von Clickdummies fortzufahren und mit der Produktion von Prototypen abzuschließen. So konnten alle gesammelten Erkenntnisse integriert werden. Echte Nutzer des Systems konnten nicht mit in die Erstellung der Prototypen einbezogen werden. In unserem Unternehmen konnten wir große Stolpersteine dennoch bereits frühzeitig erkennen, da es durch die heterogene Mitarbeiter-Struktur Kollegen gibt, die eine geringere Affinität zum Thema aufweisen. Wir bezeichnen dies als „Flur-Tests“, da wir mit unseren Prototypen quasi über die Flure laufen und verschiedene Kollegen testen. Beim Paper-Prototyping ist ein ähnliches Vorgehen bekannt. In unserem Projekt hatten wir nach ca. zwei Sprints gute Prototypen, welche zum größtmöglichen Maß die Anforderungen und Wünsche der Leser berücksichtigten. Aufgrund der ständig wachsenden tech nischen Erkenntnisse und Anforderungen durch andere Stakeholder, wie zum Beispiel die Rechtsabteilung, mussten die erzeugten Dokumente jedoch über die komplette Projektlaufzeit hinweg ständig geprüft und überarbeitet werden. Diese Änderungen über allen Entwicklungsstufen von Wireframe über Clickdummy bis hin zu den Prototypen einzupflegen war mühsam und musste so sorgfältig erledigt werden, dass sich diese Aufgabe zu einem VollzeitJob entwickelt hat. Die Prototypen wurden auch für das Erwartungsmanagement gegenüber den Stakeholdern eingesetzt Product-Owner-Proxy-Konzeption

Das Scrum-Team fährt als Ozeandampfer unbeirrt über das Meer, während das kleine, flinke Usability-U-Boot immer an den wichtigsten Stellen auftaucht und die Versorgung des Ozeandampfers sicherstellt. Die Usability-Aktivitäten liefen also stets außer Sichtweite. Immer dann, wenn wichtiger Input benötigt wurde, tauchte der Usability-Experte auf.

Anforderungen entstanden ebenfalls an externe Projektbeteiligte, so zum Beispiel die Design-Agentur. Ursprünglich war geplant, dass diese Agentur aus finalen Konzepten Designs und Sprache nach einem fest geplanten Ablauf und in einem zuvor definierten Umfang nach dem klassischen Wasserfall-Modell produziert. Doch durch die ständigen Veränderungen an

den Prototypen war es auch hier notwendig, innerhalb kürzerer Zyklen zu liefern, Feedback aus der Technik einzuarbeiten und die ständige Konsistenz aller Designs und Texte zu gewährleisten. Test Driven Development

Ein technisches Ziel, welches den Projekt erfolg sicherstellen sollte, bestand in der Einführung von „Automated Regression Testing (ART)“ zur Gewährleistung einer technischen Fehlerfreiheit über alle Prozessschritte und Plattformen, Schnittstellen und Systeme. Um eine Testabdeckung von über 80 % im Unit-Test Bereich zu erreichen, wurden deshalb explizit Ressourcen bereitgestellt, welche die ständige Entwicklung von ART überwachen. Dies sorgte auch für stärkeres Vertrauen der Stakeholder gegenüber der Technik. Ein Vorteil aus UX-Sicht zeigte sich dahingehend, dass am Ende des Projektes mit ziemlich großer Sicherheit bekannt ist, welche technischen Probleme nicht auftreten werden. Man kann sich hierdurch weitgehend auf die Behebung von Verständnisproblemen und das Abfangen von wenigen technischen Edge Cases konzentrieren. 3.2.3. Usability-Aktivitäten – Nebenbereich Aus Usability-Sicht scheint es zunächst so, als wären wir bei einer scrum-orientierten Entwicklung auf Guerilla-Aktionen beschränkt gewesen. Im Gegensatz dazu gibt es jedoch auch Aktivitäten, welche wir ganz offensiv ausführen konnten. Diese ziehen eine Verbesserung des Produkterlebnisses außerhalb des Kernbereichs nach sich. Davon profitieren nicht nur die User, welche mit dem Bezahlmodell in Kontakt kommen, sondern alle anderen User unseres Produkts. Konkret sprachen wir dabei von einer „Produktoffensive“. Bei deren Durchführung entstanden größere Herausforderungen durch die ungeplante Einführung der Product Owner Proxies und die unerwartete Bindung von Ressourcen im Bereich der Konzeption. Diese Ressourcen waren

297

eigentlich für die Durchführung der Produktoffensive vorgesehen. Unsere Erkenntnis für die Zukunft war es deshalb, ein speziell dafür vorgesehenes Team für diese Aktivitäten aufzubauen und die Aufgaben nicht aus dem normalen Tagesgeschäft heraus zu erledigen. Gerade bei einem stark aktualitätsgetriebenen Medium können aktuelle Ereignisse auch zu einer spontanen Umplanung führen. Produktoffensive

Die Durchführung der Produktoffensive beinhaltet vor allem neue Features, einzig artigen Content und Feedbackmöglichkeiten für die Leser. Hier folgen nun einige Beispiele. Mit der Leser-TV-Kritik wird den Usern die Möglichkeit gegeben, zum Beispiel bei TV-Übertragungen von Fußballspielen im Anschluss an die Ausstrahlung Moderator, Experten und Kommentatoren zu bewerten. Hierbei werden bei jeder Übertragung Schulnoten vom User vergeben und anschließend ausgewertet. User haben mit der Produktoffensive die Möglichkeit bekommen, ein Quiz mit verschiedenen Spielmodi zu spielen. Das Quiz bedient zum Beispiel das Bedürfnis nach Wissen. Zur Förderung der Identifikation mit unserem Produkt wurden Autorenseiten für jeden Autor geschaffen. User können diesen Seiten und den Social-Media-Profilen der Autoren folgen und haben somit immer die neusten Artikel dieses Autors im Blick. Besonders viel Zulauf erfahren die LiveChats mit Autoren. Mehrmals pro Woche stellen sich unseren Lesern abwechselnd verschiedene Autoren in einem Live-Chat. Autoren beantworten dort selektiv die interessantesten Fragen zu dem Thema. Mit dem Tool „Interaktive Karten“ werden interaktive Karten mit tagesaktuellen Informationen, wie zum Beispiel den aktuellen Arbeitslosenzahlen, für die User produziert.

298

Als besonderer Service für die Leser wurde der Geschichtskanal mit dem Sonderthema Zweiter Weltkrieg ins Leben gerufen. Dort stellen Leser täglich Fragen an unsere Experten. Diese wählen eine Frage aus und beantworten sie ausführlich. Es wurde ein eigenes Support-Team aufgebaut, welches jegliche Kundenanfragen beantworten und Probleme unkompliziert lösen kann. Das Support-Team stellt außerdem den wichtigsten Rückkanal für das Feedback der Kunden zur Produktentwicklung dar. Die Mitarbeiter dort wurden aufgrund des engen Timings auch nicht am fertigen Produkt, sondern mit Hilfe der Prototypen geschult. Zur Unterstützung des Support-Teams war in der Einführungsphase für die ersten Wochen ein Product Owner Proxy vor Ort anwesend. 4. Fazit 4.1. Die U-Boot Taktik funktioniert, aber … Am 12.12.2012 um 12:12 Uhr wurden innerhalb weniger Stunden Bezahlmodelle für welt.de und die mobile Website ausgerollt. Die Updates für die Tablet- und die Smartphone Apps wurden veröffentlicht. Seitdem kaufen Leser Produkte, schalten ihre PrintAbos frei und migrieren aus ihren alten App-Abonnements in die neuen Produkte. Vor allem im Bereich der Website kommt es nach Auswertung des User-Feedbacks kaum zu Usability Problemen. Auf alle auftretenden Schwierigkeiten im Bereich der Apps war das Support-Team gut vorbereitet. Ein Mindestmaß an Usability kann also auch durch die U-Boot-Taktik erreicht werden. Selbst wenn Usability nicht offiziell Bestandteil der Prozesse ist, müssen versteckte Kosten für Ressourcen eingeplant werden. Vor allem auf operativer Ebene muss mit aller Offenheit über das Thema kommuniziert werden, damit Usability die notwendige Anerkennung findet.

Auch wenn es in der Außenwirkung den Anschein macht, als hätten wir es geschafft, „Paid Content für Dummies“ einzuführen, sind wir uns bewusst, dass wir noch viel optimieren können. Bei der Betrachtung der erreichten Ergebnisse stellen wir fest, dass dennoch wichtige Bedürfnisse der User erfüllt werden konnten. Der Vergleich zu erfüllten Business-Interessen und technologischen Rahmenbedingungen zeigt jedoch, dass es besonders schwierig ist, den User gleichrangig zu vertreten. 4.2. Gibt es Raum für Usability-Aktivitäten bei einem agilen Vorgehen nach Scrum? Ja, gibt es! Allerdings würden die Aktivitäten bei einem Vorgehen nach Scrum-Lehrbuch auf der Strecke bleiben. Man muss sich also den Raum für Aktivitäten selbst schaffen. Aktivitäten können zum Beispiel in der Phase vor der eigentlichen Entwicklung stattfinden. Besonders wichtig ist deshalb die Dokumentation der Aktivitäten und Entscheidungen, welche während der Projektdurchführung zu einer Verschlechterung des Qualitätsmerkmals Usability führen können, um diese später durch zusätzliche UX-Aktivitäten auszugleichen. Im Vergleich von Aufwand zu Nutzen erweist sich die U-Boot Taktik nicht als ergiebig genug.

Usability Professionals 2013 Kurzvortr채ge

299

Usability-Methoden in der Praxis Ergebnisse einer Umfrage zu Einsatz und Bewertung von Usability-Engineering-Verfahren Monique Janneck Fachhochschule Lübeck, Fachbereich Elektrotechnik und Informatik Mönkhofer Weg 239 23562 Lübeck monique.janneck@fh-luebeck.de

Anika Röhrich Fachhochschule Lübeck, Fachbereich Elektrotechnik und Informatik Mönkhofer Weg 239 23562 Lübeck anika.roehrich@stud.fh-luebeck.de

Abstract Wann und wozu setzen Usability-Experten und Unternehmen aktuell Usability-Methoden ein, wie verbreitet sind die einzelnen Verfahren, und wie wird ihre Nützlichkeit bewertet? Um diese Fragen zu beantworten, wurde eine Online-Umfrage unter Usability Professionals und Unternehmen durchgeführt, an der sich 82 Personen beteiligten. Dabei wurden Faktoren wie der Zeitpunkt und Zweck des Einsatzes, notwendige Ressourcen, Budget, Kundenwünsche etc. mit erhoben. Die Ergebnisse zeigen einige Überraschungen: So haben der klassische Usability-Test sowie der Cognitive Walkthrough (etwa im Vergleich zur Erhebung von Nielsen, 1995) an Bedeutung verloren, während Verfahren aus dem Bereich des Requirements Engineering und Prototyping häufig zum Einsatz kommen und auch besonders positiv bewertet werden. Nach wie vor großer Beliebtheit erfreut sich zudem die Heuristische Evaluation. Sowohl hinsichtlich des Einsatzes der verschiedenen Methoden als auch ihrer Bewertung gibt es einige Unterschiede je nach Herkunftsdisziplin der Usability-Experten (Informatik, Psychologie, Design etc.).

1. Einleitung Seit der nach wie vor viel zitierten Untersuchung von Jakob Nielsen zur Verbreitung und Bewertung von Usability-Methoden im Jahr 1995 haben sich sowohl UsabilityEvaluations- und -Engineering-Methoden

als auch die entwickelten und evaluierten interaktiven Systeme und Anwendungen stark weiterentwickelt und verändert: Anwendungen für das Web und mobile Geräte stellen neue Anforderungen an die Evaluationsmethodik. Vorgehensmodelle zur agilen Softwareentwicklung wie XP oder Scrum, die iterative Entwicklung,

Prozentsatz der Teilnehmer, die diese Methode nach dem Workshop einsetzten

Angabe, wie oft die Methode bislang eingesetzt wurde (vor oder nach dem Workshop)

Durchschnittliche Bewertung

Nutzer-Tests

55%

9,3

4,8

Heuristische Evaluation

50%

9,1

4,5

Feature Inspection

31%

3,8

4,3

Heuristic Estimation

26%

8,3

4,4

Consistency Inspection

26%

7,0

4,2

Standards Inspection

26%

6,2

3,9

Pluralistischer Walkthrough

21%

3,9

4,0

Cognitive Walkthrough

19%

6,1

4,2

Methode

Tab. 1. Einsatzhäufigkeit und Bewertung der Methoden (Nielsen, 1995)

300

Keywords: /// Usability-Evaluation /// Methoden /// Usability Engineering /// Praxiseinsatz

schnelle Entwicklungszyklen und Prototyping betonen, bringen neue Methoden des Usability Engineering mit sich (vgl. Wolf & Bleek, 2011). Um zu untersuchen, wie sich seit der Untersuchung von Nielsen der Einsatz und die Bewertung von Usability-Methoden verändert haben, wurde im Frühsommer 2012 eine Online-Umfrage durchgeführt, deren Ergebnisse wir hier vorstellen. Der Beitrag ist wie folgt aufgebaut: Zunächst gehen wir auf die ursprüngliche Untersuchung von Nielsen (1995) ein. Anschließend stellen wir die Ergebnisse unserer eigenen Untersuchung vor. Diskussion und Fazit beschließen den Beitrag. 2. Die Untersuchung von Nielsen (1995) Nielsen führte seine Untersuchung im Anschluss an einen Workshop zu UsabilityMethoden durch, den er im Rahmen der INTERCHI’93-Konferenz in Amsterdam geleitet hatte. Er verschickte Fragebögen

Usability Professionals 2013 Kurzvorträge

an alle Teilnehmer des Workshops. 42 Fragebögen wurden ausgefüllt; dies entsprach einer Rücklaufquote von 52%. Die Teilnehmer wurden gefragt, welche Usability-Methoden sie vor und nach dem Workshop einsetzten und wie oft. Zudem sollte eine Bewertung der Methoden anhand einer 5-stufigen Likert-Skala (von 1= völlig unbrauchbar bis 5 = sehr brauchbar) erfolgen. Dabei sollten nur Methoden bewertet werden, die den Befragten tatsächlich bekannt waren. Tabelle 1 zeigt die Ergebnisse. [Tab. 1] Hinsichtlich der Bewertung schnitten alle Methoden gut bis sehr gut ab. Bei der Einsatzhäufigkeit zeigten sich hingegen einige Unterschiede: Der klassische Usability-Test sowie die Heuristische Evaluation wurden sowohl am häufigsten als auch von den meisten Teilnehmern eingesetzt und mit 4,8 bzw. 4,5 von 5 möglichen Punkten auch am besten bewertet. Der Cognitive Walkthrough sowie der Pluralistische Walkthrough wurden mit 19% bzw. 21% von den wenigsten Befragten eingesetzt, wenngleich auch diese beiden Methoden mit 4 von 5 Punkten sehr positiv bewertet wurden. Bezüglich der Einsatzhäufigkeit sind wiederum der Pluralistische Walkthrough sowie die Feature Inspection die Schlusslichter. Abbildung 1 zeigt das Verhältnis zwischen der Einsatzhäufigkeit (Angabe, wie oft eine Methode bislang eingesetzt wurde) der jeweiligen Methode und deren Bewertung. Dabei sind zwei „Verlierer“ zu erkennen – der Pluralistische Walkthrough, sowie die Feature Inspection. Zwar wurden beide Methoden mit mehr als 4 von 5 Punkten bewertet, jedoch weisen diese nur eine Einsatzhäufigkeit von knapp 4 von 10 Punkten auf. [Abb. 1] Abbildung 2 zeigt analog die Relation zwischen der Bewertung der Methoden und dem prozentualen Anteil der Befragten, die die jeweilige Methode eingesetzt haben. Auch hier schneiden Pluralistischer Walkthrough sowie Feature Inspection am schlechtesten ab, hinzu kommt die Heuristic Estimation. [Abb. 2]

Abb. 1. Relation von Brauchbarkeit und Einsatzhäufigkeit (Nielsen, 1995

Abb. 2. Relation von Brauchbarkeit und Anteil der≈Probanden, die die jeweilige Methode eingesetzt haben (Nielsen, 1995)

Abb. 3. Anzahl der eingesetzten Experten und Testpersonen (Nielsen, 1995)

Nielsen fragte weiterhin nach der Anzahl der Evaluatoren (beim Einsatz von Inspektionsmethoden) bzw. der Anzahl der Testpersonen (beim Usability-Test). Abbildung 3 zeigt die Ergebnisse. [Abb. 3] Demnach folgen lediglich 35% der Befragten der Empfehlung, dass mindestens drei unabhängige Evaluatoren zum Einsatz kommen sollen. Weitere 38% setzen auf

zwei Evaluatoren, während 15% lediglich einen Experten einsetzen. Auch die Anzahl der eingesetzten Testpersonen während eines UsabilityTests variiert. 35% der Befragten führen Usability-Tests mit durchschnittlich 3–6 Probanden durch. 50% setzen auf 10 oder mehr Testpersonen. Der sogenannte „Deluxe Usability-Test“ wird in großen

301

Maßen durchgeführt. Die Abbildung 3 zeigt die Anzahl der Testpersonen, die von den Befragten bei einem Usability-Test eingesetzt werden. In einer offenen Frage am Ende des Fragebogens wurden die Teilnehmer gebeten, ihre Gründe für die Nutzung bzw. Nichtnutzung einer Methode anzugeben. Die genannten Gründe wurden in sieben Kategorien unterteilt: – Methoden erbringen gute/schlechte Informationen – Benötigte Ressourcen und/oder Zeitaufwand – Benötigte Expertise und/oder Skills – Spezifische Merkmale eines individuellen Projekts – Kommunikation, Teambildung, Marketing – Methode durch das Management beauftragt – Interaktion zwischen mehreren Methoden Die Auswertung (siehe Nielsen, 1995 für Details) zeigt, dass die wichtigste Eigenschaft eines Usability-Verfahrens die Qualität der Daten ist, die es erzeugt. Benutzertests wurden in dieser Hinsicht am besten bewertet. Damit eine neue Methode erfolgreich ist, muss diese in der Lage sein nützliche Informationen zu generieren. In den beiden folgenden Kriterien Zeitaufwand und Benötigte Expertise bewerteten die Befragten die Heuristische Evaluation am positivsten und äußerten Vorbehalte in Bezug auf Cognitive und Pluralistischen Walkthrough.

Angelehnt an die Befragung Jakob Nielsens wurde im Frühsommer 2012 eine Online-Befragung unter Unternehmen und Usability-Experten in Deutschland durchgeführt, um herauszufinden, welche Methoden diese heute bevorzugt verwenden und warum. 150 Unternehmen und Experten, die anhand des Portals usability-in-germany.de identifiziert wurden, wurden per E-Mail um ihre Teilnahme an der Befragung gebeten, weiterhin wurde der Fragebogen über soziale Medien wie Twitter und Facebook verbreitet. Insgesamt 82 Personen beteiligten sich an der Befragung. Der Fragebogen umfasste die folgenden Bereiche: – Hintergrund des Befragten (Arbeitssituation, Fachdisziplin, Erfahrung im Bereich Usability, Tätigkeitsschwerpunkte, Branche), – Einsatzzwecke und -Bereiche für Usability-Methoden, – Bekanntheit verschiedener Methoden und Häufigkeit ihres Einsatzes, – Bewertung der Methoden, – Faktoren, die bei der Auswahl der Methoden eine Rolle spielen, – Kosten und Budgets. Im Folgenden werden die Ergebnisse zu den einzelnen Fragebereichen dargestellt. Insbesondere wird auch eine Auswertung

Erwähnenswert ist weiterhin, dass offenbar die Flexibilität einer Methode im Hinblick auf veränderte Bedingungen und spezifische Bedürfnisse einzelner Projekte ein wichtiges Kriterium darstellt. Dafür spricht, dass nur 18% der Befragten die Methoden „lehrbuchmäßig“ einsetzten, während 68% geringfügige und 15% größere Modifikationen vornehmen. 3. Usability-Methoden 2012: Ergebnisse der Befragung

Abb. 4. Einsatz einer Usability-Analyse (von 1 = sehr oft bis 6 = nie)

302

nach Branchen und Fachdisziplinen vorgenommen, da sich hier einige Unterschiede zeigten. Ebenso erfolgte eine getrennte Auswertung der Antworten von Usability-Unternehmen und freiberuflichen Experten. 3.1. Stichprobe und Hintergrund Knapp 60% der Befragten arbeiteten als Angestellte in einem Unternehmen, gut 40% als Freiberufler bzw. Inhaber. Die Befragten waren überwiegend erfahrene Usability-Experten: Ca. 35% sind bereits länger als 10 Jahre in diesem Bereich beruflich tätig, 25% zwischen fünf und 10 Jahren, 28% zwischen ein und fünf Jahren und nur 12% seit weniger als einem Jahr. Die Befragten stammten überwiegend und etwa zu gleichen Teilen aus den Fachdisziplinen Psychologie, Design sowie Informatik/Ingenieurswissenschaften; weiterhin wurden die Bereiche Marketing, Marktforschung, Kommunikations- und Sozialwissenschaften genannt. Die Unternehmen, in denen die Befragten arbeiten, sind überwiegend im Bereich Dienstleistungen, IT/Internet, Medien sowie Telekommunikation tätig, auch Forschung und Lehre wurden häufiger genannt.

Usability Professionals 2013 Kurzvorträge

3.2. Einsatz und Bewertung von Usability-Methoden Die Teilnehmer wurden zunächst gefragt, wann bzw. wofür sie in ihrem Unternehmen typischerweise Usability-Methoden einsetzen. Abb. 4 zeigt die Ergebnisse. UsabilityAnalysen werden demnach vor allem vor dem Launch eines neuen Angebotes sowie vor einer strukturellen Überarbeitung und zur Problemanalyse eingesetzt. Zum Vergleich des eigenen Produktes mit Konkurrenzprodukten kommen Usability-Analysen seltener zum Einsatz. Unterschiede nach Branche / Fachdisziplin zeigten sich hierbei nicht. [Abb. 4] Im Anschluss wurden die Teilnehmer gefragt, welche Methoden sie einsetzen und wie sie diese bewerten. [Abb. 5] Eine Bewertung wurde dabei nur abgegeben, sofern die Methode bekannt war. Bezogen auf die Einsatzhäufigkeit schneiden Aufgabenanalyse, Heuristische Evaluation und Rapid Prototyping am besten ab. Usability-Tests liegen – etwas überraschend – nur im Mittelfeld, ebenso wie Fragebögen, Cognitive Walkthrough und Fokusgruppen. Am seltensten eingesetzt werden der Soziotechnische Walkthrough (wobei dieses Verfahren auch 40% der Befragten nicht bekannt war), Eye- / Behavior- sowie Attention Tracking, Nutzertagebücher sowie Remote Usability Tests. Auch Letzteres erscheint durchaus überraschend. Interessanterweise gibt es einige Unterschiede im Hinblick auf den Einsatz der Methoden durch freiberufliche Experten bzw. Usability-Unternehmen. [Abb. 5] Usability-Tests (sowohl im Labor als auch Remote), Fragebögen sowie Fokusgrup pen kommen demnach häufiger in Unternehmen zum Einsatz, ebenso wie aufwändigere Aufzeichnungsmethoden (Eye Tracking, Attention Tracking). Hinsichtlich der insgesamt am häufigsten eingesetzten Methoden – Aufgabenanalyse, Heuristische Evaluation und Rapid Prototyping – gibt es jedoch kaum Unterschiede.

Methode

Freiberufler

Unternehmen

Gesamt

Aufgabenanalyse

2,6

2,5

2,6

Kontextanalyse

3,1

2,6

2,9

Fokusgruppen

3,8

2,8

3,3

Nutzertagebücher

4,8

3,5

4,2

Usability-Test im Labor

3,5

2,4

3,0

Remote Usability-Test

4,4

3,8

4,1

Eye Tracking

4,4

3,8

4,1

Attention Tracking

4,9

3,9

4,4

Behavior Tracking

4,1

3,7

3,9

Heuristische Evaluation

2,7

2,4

2,6

Cognitive Walkthrough

3,0

2,7

2,9

Soziotechnischer Walkthrough

4,1

3,7

4,1

Card Sorting

3,4

3,0

3,2

Rapid Prototyping

2,4

2,6

2,5

Fragebogen

3,5

2,3

2,9

Abb. 5. Auswertung der Einsatzhäufigkeit (von 1 = sehr oft bis 6 = nie)

Methode

Informatik

Design

Psychologie

Marketing

Heuristische Evaluation

3,0

2,8

1,4

2,0

Rapid Prototyping

2,5

2,0

2,7

3,0

Usability-Test im Labor

4,2

3,4

2,4

3,4

Abb. 6. Einsatzhäufigkeit nach Fach-Disziplin (von 1 = sehr oft bis 6 = nie)

Auch im Hinblick auf den fachlichen Hintergrund der Befragten sind einige Unterschiede erkennbar. [Abb. 6] So wird die Heuristische Evaluation in den Bereichen Psychologie und Marketing viel häufiger angewandt. Usability-Tests werden besonders häufig von Befragten mit fachlichem Hintergrund in der Psychologie genutzt. Rapid-Prototyping-Verfahren erfreuen sich insbesondere bei Designern großer Beliebtheit.

Abb. 7 zeigt die Bewertung der Methoden (auf einer Skala von 1 = sehr gut bis 6 = schlecht). Erneut wird das Rapid Prototyping besonders gut bewertet. Auch Aufgaben- und Kontextanalyse, Usability-Test, Heuristische Evaluation sowie Cognitive Walkthrough schneiden gut ab. Die übrigen Methoden liegen im Mittelfeld. Erneut werden Unterschiede in der Bewertung durch freiberufliche Experten bzw. Unternehmen deutlich: So werden

303

Fokusgruppen, Nutzertagebücher, Card Sorting und Fragebogen sehr unterschiedlich bewertet. Alle diese Methoden schneiden bei den Unternehmen mit der Note zwei ab, bei den Experten hingegen mit der Note drei. [Abb. 7]

Ähnlich wie in der Umfrage von Jakob Nielsen (1995) wird somit einer Vielzahl der Methoden eine sehr gute bis gute Bewertung zugesprochen, doch werden diese in der Praxis selten angewandt.

Auch im Hinblick auf die Fachdisziplin zeigen sich Unterschiede. [Abb. 8] So werden Fokusgruppen im Bereich Marketing am besten bewertet, bei Psychologen ist dies erneut der Usability-Test. Rapid Prototyping wird in allen Fachdisziplinen mit sehr gut bis gut bewertet. Diese Methode ist somit eine der am häufigsten genutzten und am besten bewerteten.

Methode

3.3. Rahmenbedingungen und Kosten Weiterhin wurden die Teilnehmer nach verschiedenen Faktoren bei der Methodenauswahl – angelehnt an die Auswertung von Nielsen (1995) – befragt. Abbildung 9 zeigt die Ergebnisse. Der Erkenntnisgewinn sowie die zugrunde liegende Fragestellung spielen somit die größte

Freiberufler

Unternehmen

Gesamt

Aufgabenanalyse

2,4

Kontextanalyse

2,6

2,3

2,5

Fokusgruppen

3,4

2,5

3,0

Nutzertagebücher

3,4

2,5

3,0

Usability-Test im Labor

2,5

2,0

2,3

Remote Usability-Test

3,4

3,0

3,2

Eye Tracking

3,2

2,9

3,1

Attention Tracking

3,2

Behavior Tracking

3,1

3,3

3,2

Heuristische Evaluation

2,8

2,1

2,5

Cognitive Walkthrough

2,4

2,5

Soziotechnischer Walkthrough

2,8

3,0

2,9

Card Sorting

3,1

2,0

2,6

Rapid Prototyping

2,2

1,9

2,1

Fragebogen

3,2

2,4

2,8

Abb. 7. Bewertung der Usability-Methoden (von 1 = sehr gut bis 6 = schlecht)

Methode

Erneut zeigen sich einige Unterschiede in der Bewertung durch freiberufliche Experten bzw. Unternehmen sowie nach Fachdisziplin. [Abb. 9] So ist der Zeitfaktor für die Unternehmen bedeutsamer als für die Freiberufler, ebenso wie Erkenntnisgewinn und Fragestellung. Im Hinblick auf die Fachdisziplin fällt auf, dass die Bedeutsamkeit sämtlicher Faktoren in den Bereichen Psychologie und Marketing höher eingeschätzt wird als im Bereich Informatik. Besonders deutlich sind die Unterschiede bei den Faktoren Kundenwunsch, Erkenntnisgewinn und Fragestellung. Der Faktor „Kosten“ wurde in weiteren Fragen noch etwas genauer beleuchtet. Abb. 10 zeigt die Einschätzung der Bedeutung der Kosten, wiederum unterteilt nach Fachdisziplinen bzw. Freiberufler / Unternehmen. Generell sind die Kosten einer Analyse ein wichtiges Thema, jedoch stehen diese überwiegend nicht an erster Stelle. Eine Ausnahme bilden dabei die Freiberufler sowie die Befragten aus dem Marketing-Bereich. [Abb. 10] Die Teilnehmer wurden zudem gebeten einzuschätzen was eine Usability-Analyse, gemessen am Gesamtetat des (Entwicklungs-) Projekts, typischerweise kosten darf. [Abb. 11] Die Kosten liegen demnach bei 10–15% des Gesamtetats oder weniger. Jedoch kann ein erheblicher Teil der Befragten die Kosten nicht beurteilen. Dies mag daran liegen, dass Usability-Experten oft lediglich „ihre“ Kosten kennen und nicht die Finanzplanung eines ganzen Projektes (z.B. Grafiker, Programmierer, usw.). 4. Diskussion und Fazit

Informatik

Design

Psychologie

Marketing

Fokusgruppen

3,0

2,9

2,2

Usability-Test im Labor

2,7

2,4

1,6

2,5

Rapid Prototyping

1,6

1,7

2,2

Abb. 8. Methodenbewertung gefiltert nach Fach-Disziplin (von 1 = sehr gut bis 6 = schlecht)

304

Rolle. Die benötigte Zeit und die anfallenden Kosten einer Usability-Analyse sind ebenfalls wichtige Faktoren, die über den Einsatz der Methoden entscheiden.

Während in Usability-Lehrbüchern und Fachpublikationen der Usability-Test oft nach wie vor als „Königsweg“ der UsabilityEvaluation beschrieben wird (vgl. z.B. Sarodnick & Brau, 2010; Shneiderman & Plaisant, 2010), der wie kaum ein anderes

Usability Professionals 2013 Kurzvorträge

Methode

Inf.

Design

Psychol.

Marketing

Freiberufl.

Untern.

Gesamt

Erfahrung d. Versuchsleiters

2,1

2,0

2,1

1,8

2,5

2,3

2,4

Kosten

2,5

2,1

2,2

1,8

2,1

2,0

2,1

Zeit

2,4

2,0

1,9

2,4

1,7

2,0

Aufwand

2,2

2,0

2,2

1,6

2,1

2,3

2,2

Kundenwunsch

3,0

2,3

2,2

2,5

2,3

Erkenntnisgewinn

2,0

1,6

1,4

1,2

1,9

1,3

1,6

Fragestellung

1,7

1,9

1,1

1,2

1,9

1,2

1,6

Abb. 9. Faktoren bei der Methodenauswahl (von 1 = sehr wichtig bis 6 = gar nicht wichtig)

Bewertung

Inform.

Design

Psychol.

Marketing

Freiberufl.

Untern.

Gesamt

sehr wichtig

47,4%

31,8%

37,5%

55,6%

56,5%

37,5%

44,6%

wichtig

47,4%

63,6%

54,2%

33,3%

43,5%

46,8%

46,4%

eher unwichtig

5,3%

4,6%

8,3%

11,1%

0,0%

15,6%

8,9%

unwichtig

0,0%

Informatik

Design

Psychologie

Marketing

Freiberufler

Unternehmen

Gesamt

Unter 10%

21,0%

22,7%

12,0%

11,1%

27,1%

17,6%

19,0%

10 – 15%

36,8%

36,4%

32,0%

22,2%

39,0%

35,3%

36,2%

16 – 20%

0,0%

Mehr als 20%

0,0%

4,5%

4,0%

0,0%

4,0%

2,9%

3,5%

Kann ich nicht beurteilen

36,8%

31,8%

36,0%

44,4%

21,7%

35,3%

31,0%

Abb. 10. Bedeutung des Faktors „Kosten“

Gemessen am Gesamtetat

Abb. 10. Kosten einer Usability-Analyse

Verfahren differenzierte, realistische und unmittelbare Einschätzungen von Nutzererfahrungen erlaubt, sieht die Praxis offenbar mittlerweile anders aus: Sowohl bei der Einsatzhäufigkeit als auch der Bewertung liegt das Verfahren unserer Befragung zufolge eher im Mittelfeld. Dabei offenbaren sich jedoch einige Unterschiede im Hinblick auf Fachdisziplin und Arbeitsumfeld: Sowohl Befragte mit

fachlichem Hintergrund in der Informatik als auch freiberuflich tätige Experten setzen Usability-Tests eher selten ein und bewerten das Verfahren auch schlechter als ihre angestellten Kollegen, insbesondere aus dem Bereich der Psychologie. Gründe hierfür könnten der vergleichsweise hohe Aufwand für Durchführung und Auswertung sowie die hohen Anforderungen an die verfügbare Ausstattung (Laborräumlichkeiten,

Hardware und Software für Aufzeichnung und Analyse) sowie die Expertise des Testleiters sein. Unter den „klassischen“ Verfahren hat weiterhin der Cognitive Walkthrough an Bedeutung verloren. Einzig die Heuristische Evaluation erfreut sich weiterhin größerer Verbreitung und Beliebtheit, wenngleich auch hier Unterschiede je

305

nach Fachdisziplin festzustellen sind: In der Psychologie wird dieses Verfahren weit häufiger angewandt als in Informatik oder Design. Fokusgruppen (eine Form der Gruppendiskussion) werden hingegen überwiegend im Bereich Marketing eingesetzt. Dieser Methode wäre eine weitere Verbreitung durchaus zu wünschen, erlaubt sie doch eine gute Nutzerbeteiligung sowie die Erhebung einer großen Bandbreite an Meinungen, Einstellungen und Reaktionen. Etwas überraschend sind auch der vergleichsweise geringe Einsatz und die mäßige Bewertung von Fragebogenverfahren, wenngleich hier mittlerweile eine große Zahl standardisierter und erprobter Verfahren für die unterschiedlichsten Schwerpunkte und Fragestellungen zur Verfügung stehen. Ein Grund hierfür könnte sein, dass Fragebögen eher für großzahlige Erhebungen geeignet sind, in UsabilityAnalysen aber möglicherweise häufig eine kleinere, klar umgrenzte Zielgruppe untersucht wird. Im Gegensatz zu den „klassischen“ Evaluationsverfahren gewinnen Methoden aus dem Requirements- bzw. Usability-Engineering an Bedeutung, wie die Aufgabenund Kontextanalyse sowie insbesondere das Rapid Prototyping, das unabhängig von Fachdisziplin und Arbeitskontext der Befragten häufig eingesetzt und positiv bewertet wird. Die Stärke dieser Methode liegt im frühzeitigen Testen und Optimieren, um bereits im Vorfeld potenzielle Usability-Probleme zu vermeiden und damit die Kosten im Entwicklungsprozess zu senken. Außerdem erlauben Prototyping-Methoden viel und intensive Nutzerbeteiligung (vgl. Richter & Flückiger, 2010). Das Aufkommen dieser Methoden ist möglicherweise eine Folge der oben schon angesprochenen zunehmenden Verbreitung agiler Methoden (vgl. Wolf & Bleek, 2011), die viel Wert auf echte Benutzerbeteiligung und somit eine Verflechtung des Software-Engineering-Prozesses mit Usability-Engineering-Methoden propagieren. Interessant ist in diesem Zusammenhang, dass diese Methoden nicht nur

306

bei Informatikern, sondern auch Designern und Psychologen auf Zustimmung stoßen. Die hier erfragten Usability-Methoden haben offenbar das eingesetzte Spektrum gut abgedeckt. Jedenfalls wurden nur wenige weitere Methoden genannt, darunter insbesondere die Prüfung auf Barrierefreiheit, Personas sowie das Laute Denken als Teil eines Usability-Tests. Auch waren die hier erfragten Methoden jeweils der großen Mehrheit der Befragten bekannt, nur vereinzelt waren Methoden nicht geläufig. Eine Ausnahme bildet lediglich der soziotechnische Walkthrough, der ca. 40% der Befragten kein Begriff war. Unser Resümee: Der Methodenwerkzeugkoffer der Usability-Professionals verändert sich. Dass vor allem Methoden mit hinein kommen, die einen starken Usability-Engineering-Bezug haben und somit Benutzerbeteiligung vorantreiben, ist aus unserer Sicht positiv zu bewerten. Literatur 1. Nielsen, J. (1995). Technology Transfer of Heuristic Evaluation and Usability Inspection. Alertbox: June 27, 1995. http://www. nngroup.com/articles/technology-transfer-ofheuristic-evaluation [Abruf am 3.6.2013] 2. Richter, M., Flückiger, M. (2010). Usability Engineering kompakt, 2. Auflage. Heidelberg: Spektrum Akademischer Verlag. 3. Sarodnick, F., Brau, H. (2010). Methoden der Usability Evaluation. Bern: Huber. 4. Shneiderman, B., Plaisant, C. (2010). Designing the user interface. Strategies for effective human-computer interaction. Boston: Addison-Wesley, 5th edition. 5. Wolf, H., Bleek, W.-G. (2011). Agile Softwareentwicklung: Werte, Konzepte, Methoden, 2. Aufl. Heidelberg: dpunkt.

Usability Professionals 2013 Kurzvortr채ge

307

Valenzen in Serious Games Spielerisch auf neuen Wegen der UX-Messung

Insa Wulf Hochschule der Medien Stuttgart insa.wulf@gmx.net

Dr. Huberta Kritzenberger Hochschule der Medien Stuttgart kritzenberger@hdm-stuttgart.de

Abstract Serious Games sind Videospiele, in denen Spieler nicht ausschließlich spielen, sondern gleichzeitig lernen. Warum ist es hier wichtig, die Ux messen zu können? User Experience kann darauf hindeuten, ob die Verknüpfung von Spiel- und Lerninhalt so erfolgreich ist, dass bei den Spielern konzentrationsfördernder Flow entsteht. Ein Zugang zur Bewertung von UX sind von den Nutzern erlebte Wertigkeiten (Valenzen) von UX-Merkmalen. In einer explorativen Studie wurden Valenzen erhoben, um die verschiedenen UX-Merkmale von Serious Games betrachten zu können. In dieser Studie setzten die Spieler selbst die Valenzen bei verschiedenartigen Merkmalen: von Grafik über Humor zu Schwierigkeitsgrad sowie Sound und mehr. Diese Valenzen wurden retrospektiv besprochen, indexiert und nach Häufigkeiten gewichtet ausgewertet. Der Einsatz von Valenzen für die UX-Messung in Serious Games ermöglicht es, diejenigen Merkmale zu dokumentieren, welche für die Spieler in Bezug auf ihre Erwartungen relevant waren und so die Entwicklung des Spielflows bestimmt haben.

Einleitung Wäre es nicht angenehm, in der Zukunft nicht nur Bücher oder eBooks zu lesen, sondern die multimedialen Möglichkeiten von Videospielen zu nutzen, um zu lernen? Dieser Artikel stellt eine Studie vor, dessen Ziel es war, das Nutzungserlebnis eines sogenannten „Serious Games“ zu validieren. Serious Games bieten sich als Medium an, in dem am Computer gespielt und gleichzeitig gelernt werden kann. Zu welchem Thema die Weiterbildung stattfindet, das hängt natürlich vom jeweiligen Spiel ab. Dieser Artikel befasst sich nun damit, wie das Nutzungserlebnis, also die UX, bei einem so lebendigen Produkt wie einem Computerspiel gemessen werden kann. In einer explorativen Studie wurde eine Messung anhand von Valenzen und einer Indizierung ebendieser durchgeführt. Der genaue Ablauf der Studie wird in den folgenden Absätzen dargestellt. Verglichen wurde diese empirisch erhobene UX zusätzlich mit der Vorerfahrung der Spieler und einer zuvor durchgeführten Umfrage zu dem Genre, welches in dem Serious Game bedient wird.

308

Warum sollte das Nutzungserleben bei Serious Games gemessen werden? Serious Games sind wie beschrieben Videospiele, in denen Spieler nicht ausschließlich spielen, sondern sich gleichzeitg weiterbilden. Die Spiele vermitteln die zu lernenden Inhalte beispielsweise über die Hintergrundgeschichte und ihre Handlungsabläufe, wodurch die Grenzen zwischen Lern- und Spielinhalten verschwimmen. In den Momenten, in denen im Spiel die Lernsituation für die Spielenden nicht offensichtlich, sondern primär das Spielen wahrgenommen wird, entsteht im Spielflow starke Konzentration (Fritz, 1997, S.212). Aufgrund dieser angenehmen Möglichkeit, spielerisch konzentriert zu lernen, erhält diese Art von Videospielen derzeit zunehmend Aufmerksamkeit. Welchen Mehrwert bietet an dieser Stelle nun die Messung von User Experience bei der Entwicklung von Serious Games? Kann positive User Experience nachgewiesen werden, ist das ein Hinweis darauf, dass die Verknüpfung von Spiel- und Lerninhalt so gelungen ist, dass die Lernsituationen

Keywords: /// Valenzen /// Serious Games /// User Experience Research /// User Experience

unbewusst bleiben und bei den Spielenden konzentrationsfördernder Flow entsteht (Fritz, 1997). Wird negative User Experience gemessen, ist der Flow folglich ein schwer zu erreichender Zustand. Ist es gegenteilig doch möglich geworden, dass Spieler das Flow-Erlebnis erlangen, entsteht ein Entwicklungs- oder Lernprozess (Csíkszentmihály, 1992, S.70f). Eine hohe gemessene UX kann also auf entstehenden Spielflow und damit auf einen erleichterten Lernprozess in dem Serious Game hindeuten. Diese Hinweise bilden für die Entwicklung und für die kontinuierliche Verbesserung eines Serious Games eine fundierte Grundlage für Optimierungsansätze. Wie sieht der Ansatz der explorativen Studie aus? Ein möglicher Zugang um die UX zu bewerten, sind Wertigkeiten (Valenzen) von UX-Merkmalen. Diese Wertigkeiten des Nutzungserlebens bei dem Benutzen eines Produkts resultieren aus einem Gefühl, welches sich einstellt, sobald Frustration oder Erfüllung von Grundbedürfnissen erlebt wird. Dieses rangiert auf

Usability Professionals 2013 Kurzvorträge

der Gefühlsdimension „positives Gefühl“ bis „negatives Gefühl“, der sogenannten Valenzdimension (Hassenzahl, 2008). Diese Valenzen erleben auch die Spielenden bei Serious Games und werden daher gemessen um die Wahrnehmung der UX zu ermitteln und dadurch auf den Spielflow schließen zu können.

Abb. 1. Valenzmarker zum Markieren positiver (+) oder negativer (-) Valenzen

Wie verlief die Studie? In der explorativen Studie wurde den 9 Teilnehmern kein Leitfaden mit speziellen Handlungsanweisungen und Aufgaben vorgegeben, wie es zum Beispiel in einem Usability Test üblich ist. Stattdessen durften die Spielenden das Serious Game frei explorieren. Die Studie wurde so angelegt, da die Unterhaltung, das Flow-Erleben, alltäglichem Computerspielen meistens als einzige Motivation zugrunde liegt. Freies Computerspielen kann nicht in einem linearen Handlungsablauf vorhergesagt werden, da jedes Explorieren des Spielraums verschieden verläuft. Diese Freiheit ist Teil des Spielerlebens. Nach einer Einleitung wurde den Teilnehmern von einem Moderator der Valenzmarker vorgestellt, mit dessen Hilfe die Teilnehmer bei einem positiv oder negativ erlebten Merkmal Wertigkeiten anzeigen können, dieser ist in Abbildung 1 dargestellt. Bei den Merkmalen kann es sich um verschiedenartige Spielelemente wie Grafik, Schwierigkeitsgrad, Humor und vieles mehr handeln. Im Anschluss spielten die 9 Teilnehmer je frei für 20 Minuten das Lernadventure „Winterfest“. Der Schauplatz dieses Computersspiels, welches den Serious Game Award in Gold im Jahr 2011 auf der CeBIT gewonnen hat, ist eine Stadt im Mittelalter. Von dort muss der Protagonist mit seinem Kumpanen, einer Ratte, den Weg zurück in unsere Gegenwart finden und viele Rätsel lösen. Das Spiel soll Erwachsenen die Möglichkeit bieten, Lesen, Schreiben und Rechnen zu üben. Hierfür kann „Winterfest“ auf der Website http://www. lernspiel-winterfest.de/ heruntergeladen und kostenlos gespielt werden. Während der Spielphase von „Winterfest“ setzten

die Spieler selbständig die Valenzen bei verschiedenartigen Merkmalen mithilfe des Valenzmarkers. Während dieser Spiel phase wurden der Bildschirm mit dem Computerspiel inklusive der Blickbewegungen des Spielenden mittels Eyetracker sowie der Valenzmarker mit einer weiteren Videoaufnahme aufgenommen. [Abb. 1] In einer anschließenden retrospektiven Befragungsphase betrachteten der Teilnehmer und der Moderator gemeinsam das Video der Spielaufzeichnung mit den Blickbewegungen und die Aufnahme des Valenzmarkers (siehe Abbildung 2). Hatte der Teilnehmer während des Spielens einen Marker gesetzt, wurde das Video gestoppt um die Spielsituation zu besprechen. Diese Videonachbesprechung orientiert sich an dem Retrospective Thinking Aloud (De Jong, Van den Haag, 2002), im Folgenden mit RTA abgekürzt, und der Valenzmethode (Burmester, Jäger, Festl, Mast, 2011). Bei der RTA geben die Teilnehmer retrospektiv wieder, was sie zum jeweils im Video wiedergegebenen Zeitpunkt gedacht haben. Eine alternative Möglichkeit hierzu wäre das Concurrent Thinking Aloud (De Jong, Van den Haag, 2002), im Folgenden CTA genannt, bei dem die Spielenden parallel zur Handlung ihre Gedanken erläutern. Das CTA wurde nicht angewandt, da es eventuell den natürlichen Spielprozess gestört hätte, welches in einer Studie zu erkennen ist, in der De Jong und Van den Haag (2002) RTA und CTA verglichen haben. Dabei haben die Teilnehmer, welche CTA anwanden, weniger erfolgreich Testaufgaben

bewältigt als die Teilnehmer, welche retros pektiv verbalisierten. De Jong und van den Haag verweisen darauf, dass dieser Unterschied in dem Arbeitsaufwand liegen könne, den das beim CTA erforderliche, laute Denken verursacht und sich damit negativ auf das Leistungsvermögen auswirken könne. Während der retrospektiven Befragungsphase des Serious Games wurden außerdem ausdrucksstarkes Verhalten und Mimik besprochen, wie zum Beispiel Lachen oder spontane Ausrufe der Spielenden, welche der Moderator während der Spielphase notiert. Diese Stellen wurden bei der Videonachbesprechung zusätzlich zu den Markern thematisiert, um herauszufinden, welche Elemente des Spiels diese Reaktionen hervorgerufen haben. Es fällt auf, dass ein Teilnehmer während der Spielphase wenig Marker setzte. Obwohl er bei einer vorhergehenden Übung normal viele Marker gesetzt hat, wird er nicht während der Spielphase dazu aufgefordert, mehr Marker zu setzen. Dies geschieht deshalb nicht, um ihn nicht im Spielfluss zu stören. Denn während des Computerspielens kann der Effekt eintreten, dass die Spielenden im Flow vollkommen ihre Aktivität und ihr Bewusstsein verschmelzen und so ihre komplette Aufmerksamkeit auf das Spiel lenken, so dass sie sich nicht mehr selbst reflektieren sowie nicht mehr über andere Dinge außerhalb der Spielwelt nachdenken (Fritz, 1997). Tritt dieser Effekt bei dem Serious Game ein und vergisst ein Teilnehmer dadurch Marker zu setzen, sollte der Moderator die Teilnehmer in dem möglichen Fall nicht durch eine Erinnerung

309

Abb. 2. Aufgezeichnete Minispiel-Szene mit Gaze Plots und Aufnahme des Valenzmarkers

an das Markersetzen aus diesem Zustand lösen. Stattdessen wird vermehrt das Verhalten, Mimik und Ausrufe beobachtet, sowie während der RTA vertieft Aufmerksamkeit darauf gelenkt, wie der Teilnehmer bestimmte neue Schauplätze, Rätsel oder Dialoge empfand. So kann auch ohne Marker noch hinreichend herausgefunden werden, wie das Erleben der Teilnehmer in der Spielphase war. [Abb. 2]

abzugleichen. Daher besprachen Moderatorin und Teilnehmer in der RTA die Eigenschaften der Elemente des Serious Games, welche veranlasst hatten, den Valenzmarker zu drücken. Wenn es die Spielsituation zulaß, verglichen sie diese Spielelemente außerdem mit anderen bereits gespielten Computerspielen, aus denen die Spielenden ihre Erfahrungswerte gebildet hatten. Wie wurde ausgewertet?

In der RTA wurde auf die Befragungstechnik des „Ladderings“, welche der Valenzmethode zugrunde liegt (Burmerster, Jäger, Festl, Mast, 2011), verzichtet. Diese Fragetechnik wurde dahingehend entwickelt, die unbewusst hinter einer positiv oder negativ empfundenen Eigenschaft stehenden Grundbedürfnisse zu ermitteln. In der Studie stand im Vordergrund, die positiven oder negativen UX-Merkmale zu dokumentieren und mit den Erwartungen

310

Die Ergebnisse der retrospektiven Befragung wurden in Tabellen protokolliert. Diese wurden segmentiert, orientierend an den von den Teilnehmern gesetzten Markern. Um darzustellen, welche Segmente ähnliche Merkmale thematisieren, wurden diese testpersonenübergreifend indexiert und anschließend nach Themen und Spielsituation sortiert. Eine spielübergreifende Zusammenfassung schloss

dies ab, wie beispielhaft in Abbildung 3 in einem Ausschnitt der Tabelle dargestellt wird. Die Index-Nummern generieren sich aus der Teilnehmer-ID und der jeweiligen Listen-Nummer des gesetzten Markers. Dies ermöglichte eine schnelle Identifizierung der jeweiligen Teilnehmer sowie eine grobe Einordnung der Indizes in den Ablauf des Serious Games. Bei einer Gesamtzahl von durchschnittlich 45 Indizes pro Teilnehmer wird empfohlen im Anschluss anhand der quantitativen Daten auffallende Indizes zu wählen und primär diese qualitativ nach positiver und negativer Valenz auszuwerten. [Abb. 3] Was galt als UX Merkmal? Die Teilnehmer setzten positive sowie negative Valenzen bei sehr verschiedenen Spielelementen. Diese Spielelemente konnten derart tiefe Wirkung bei den

Usability Professionals 2013 Kurzvorträge

Abb. 3. Tabelle mit thematisch geordneten Indizes

Spielenden auslösen, dass beispielsweise ein Lob nach dem erfolgreichen Abschließen eines Minispiels, das zwei Mal in derselben Art und Weise vom Sprecher vorgetragen wird, von den Spielenden nicht als glaubwürdig angenommen wurde. Sie konnten so „Winterfest“ nicht ernst nehmen und wurden sich der Spielsituation bewusst. Andere zu den Valenzen genannte Spielelemente unterstützten einfach die Spielwelt nicht in dem Maße wie es von den Spielenden erwünscht wurde. Hierzu zählt beispielhaft eine unpassende Schriftart in Sans-serif, die nicht die entsprechende Atmosphäre des Spiels wiedergibt. Ein kritischer Punkt an dieser Stelle war es, während der Auswertung die Segmente, welche die Spielwelt definieren oder die persönliche Beziehung zu dem Spiel prägen, nach entsprechenden Themen zu

ordnen. Hier halfen Tabellen, anhand derer eine Übersicht über die Indizes und die Themenschwerpunkte geschaffen wurde. Eine beispielhafte Auswahl genannter Merkmale ist in Tabelle 1 zu erkennen.

immersiv genug war, als dass die ungewünschte Assoziation zu Kinderspielen ausgeglichen werden konnte. Die Motivation für weiteres Spielen blieb insgesamt bei fast allen Spielenden aus.

Insgesamt war festzustellen, dass „Winterfest“ von 8 von 9 Testpersonen nicht als schlecht empfanden. Dennoch äußerten 6 von 9 Testpersonen, sie würden es nach der Besprechung nicht freiwillig zu Ende spielen. Die in der vorhergehenden Umfrage herausgestellten, wichtigen Merkmale für Adventure-Spiele (starke Geschichte, viel Witz und Rätsel), konnten von den Testpersonen überwiegend in dem Serious Game wiedergefunden werden. Allerdings identifizierten sie einige Spielsituationen so, dass die Situationen als für Kinder passender wahrgenommen wurden. Weitere gesetzte Valenzen deuteten darauf hin, dass die Geschichte nicht

Aus dieser Beobachtung kann geschlossen werden, dass es wichtig ist, die typischen Merkmale des jeweiligen Genres besonders stark in einem Serious Game auszuprägen, da dadurch Flow ermöglicht werden kann. Dennoch ist es wichtig, dies im für die Zielgruppe adäquaten Rahmen umzusetzen, da ansonsten Unter- oder Überforderung entstehen kann. Hierdurch kann das Spiel von den Spielenden einer unpassenden Zielgruppe zugeordnet werden, wodurch die Lern- und Spielsituation bewusst und Flow unmöglich wird. [Tab. 1]

311

Kategorie

Name

Beschreibung

Indiz

Design

Schriftart unpassend

Arial passt nicht; wirkt nicht wie von Hand geschrieben

0258, 0502

Geschichte

Unspektakuläre Story

Twist in der Geschichte ist gut, sonst eher mittelspannend; plausibel; weder superaufregend noch blöd; etwas Abgedrehtes fehlt; wirkt nicht stark genug, nimmt Motivation

0259, 0327, 0442, 0528, 0635, 0923

Minispiel

unglaubwürdiger Lob im Minispiel

Lob kann nicht ernst genommen werden, weil die Aufgabe zu einfach ist; weil 2 Mal hintereinander auf die selbe Art gelobt wird; zu oft gelobt

0158, 0258, 0314, 0329 0630, 0715

Spiel insgesamt

Offensichtlicher Spielverlauf

Keine Items sehr versteckt, nicht viel nachdenken, was als nächstes zu tun ist; im Dialog wird folgender Lernabschnitt zu offensichtlich; untypisch, dass Spieler immer wissen, was sie tun müssen

0259, 0313, 0517, 0620, 0734, 0916

Spiel insgesamt

Spiel für Kinder

Wirkt wie Spiel zum Lernen des Umgangs mit einem PC; einfache Rätsel; andauernde Tutorial-Erklärungen; 100 als Ergebnis simpel und unrealistisch; Lob für Kinder gut, weil die tatsächlich vielleich noch denken müssen; Kinderrechenaufgabe; „Grundrechnung“; klar was zu tun ist; Sätze zu klar ausformuliert wie eine ‚Heile Welt‘; kein hintergründiger Humor; wie von Eltern für ihre Kinder

0212, 0242, 0245, 0248, 0250, 0254, 0257, 0313, 0402, 0423, 0438, 0503, 0512, 0517, 0532, 0630, 0640, 0715, 0927

Witz

absurder Kommentar

Witzig, abgedreht

0239, 0241, 0245, 0250, 0308, 0311, 0316, 0415, 0420, 0427, 0515, 0616, 0710, 0713,0817

Witz

zu wenig Humor insgesamt

Humor würde zu mehr Langzeitmotivation führen; zu ernst, zu wenig Ironie; Geschichte kann so bleiben, aber zu wenig Humor; keine unpassenden Elemente wie ‚Schwarze‘ oder so im Spiel; fehlende Item-Kommentare wie bei Monkey Island;

0245, 0262, 0313, 0327, 0644

Tab. 1. beispielhafte Auswahl von 7 Indizes

Welchen Mehrwert erbrachte der Einsatz von Valenzen in der Studie? Durch den Einsatz von Valenzen konnten die einzelnen UX-Merkmale, welche für die Spieler in Bezug auf ihre Erwartungen relevant waren, in dem Serious Game markiert werden. Durch diese Dokumentation wurde es möglich, diese UX-Merkmale nach Häufigkeiten auszuwerten, was eine Bewertung vereinfachte. Ebenso konnten die UX-Merkmale sowie ihre übergeordneten Themen qualitativ evaluiert werden. Dies gab Aufschluss darauf, welche UX-Merkmale im Zusammenspiel mit den Erwartungen an das Genre die Entwicklung des Spielflows bestimmten, sowie in welchem Maße gefördert oder gehindert haben.

312

Literatur 1. Burmester, M., Jäger, K., Festl, L. & Mast,

4. Fritz, J. (1997): Zwischen Transfer und Transformation. Überlegungen zu einem

M. (2011): Studien zur formativen Evaluation

Wirkungsmodell der virtuellen Welt, . In J.

der User Experience mit der Valenzmethode.

Fritz & W. Fehr (Hrsg.), Handbuch Medien.

In S. Schmid et al. (Eds.), Reflexionen und

Computerspiele – Theorie, Forschung, Praxis

Visionen der Mensch-Maschine-Interaktion –

(S. 229–246). Bonn: Bundeszentrale für

Aus der Vergangenheit lernen, Zukunft gestalten. 9. Berliner Werkstatt Mensch-

politische Bildung. 5. Hassenzahl, M. (2008): User Experience

Maschine-Interaktion, 5. bis 7. Oktober 2011.

(UX): Towards an experiential perspective on

Fortschritt-Berichte VDI Reihe 22 Nr. 33. (pp.

product quality. In Proc. of IHM’08, 2–5 Sept.

567–572). Düsseldorf: VDI-Verlag.

2008, Metz, France, 11–15.

2. Csíkszentmihályi, M. (1992): Flow. Stuttgart: Klett-Cotta. 3. de Jong, M.D.T. & van den Haag, M.J. (2002). Exploring Two Methods of Usability Testing: Concurrent versus Retrospective Think-Aloud Protocols. Twente: University of Twente.

Usability Professionals 2013 Kurzvortr채ge

313

Storytelling für User Experience Designer Methoden und Beispiele für den Einsatz von User Stories im UX Design Prozess. Kinga Kujat Senior User Experience Design Finowstr. 11 12045 Berlin hello@kingakujat.com

Abstract Geschichten begeistern Menschen schon seit vielen Generationen und die Arten, wie Geschichten erzählt werden, sind vielfältig. Auch UX Designer können die Kraft des Geschichtenerzählens für ihre Arbeit nutzen. Der Beitrag zeigt, wie Geschichten den UX Prozess fördern und bereichern, Designideen bildlich vorstellbar machen und zu Innovationen ermutigen können. Anhand eines Schritt für Schritt aufgezeigten praktischen Beispiels wird aufgezeigt, wie aus Personas, User Stories und Use Cases eine nachvollziehbare und realitätsnahe Geschichte wird, aus der der UX Designer detaillierte Designanforderungen für seine Anwendung definiert.

1. Storytelling: Die Kunst des Geschichtenerzählens „Menschen brauchen Geschichten mehr als Brot und Wasser, sie sagen ihnen, wie sie leben sollen und warum.“ – 1001 Nacht

Die traditionelle Kunst des Geschichtenerzählens hat eine lange Historie und die Arten, wie Geschichten erzählt werden, sind vielfältig. Geschichten und Märchen sind in allen Kulturen der Welt vertreten. Sie dienen zumeist zur Unterhaltung, zur Lehre oder zur Vermittlung von kulturellen oder moralischen Werten. Eine Geschichte kann aufgeschrieben sein oder durch den Erzähler mündlich erzählt werden. Sie kann über Bilder, Bewegtbild oder Worte vermittelt werden. (Quesenbery und Brooks, 2010) 2. Storytelling im UX Design Prozess Die anschauliche und unterhaltende Vermittlung von Inhalten über Geschichten kann auch für den UX Designer ein wichtiges und wirkungsvolles Instrument darstellen.

314

Geschichten, die von den Umständen und der Art und Weise erzählen, wie Nutzer mit einer geplanten Anwendung umgehen, sind sehr hilfreich, um Informationen über die Nutzer sowie Anforderungen und Anwendungsziele vorstellbar zu machen und zu definieren. Geschichten beflügeln zudem nicht nur die Vorstellungskraft des UX Designers und lassen ihn wertvolle Erkenntnisse zu den Nutzern und zur selbst Anwendung ableiten, sie können auch Publikum wie Kunden, Entscheider und andere Stakeholder von Designkonzepten und –ideen überzeugen und ermutigen, auf Innovationen zu setzen. (Quesenbery und Brooks, 2010) Die wichtigsten Rollen von Geschichten im UX Design Prozess sind: –– Sie helfen, Informationen über die Nutzer einer Anwendung, Anforderungen und Anwendungsziele zu definieren und anderen zu vermitteln. –– Sie erklären und helfen dabei, Menschen kennenzulernen und zu verstehen, die nicht genauso sind wie wir. –– Sie geben analytischen Daten ein menschliches Gesicht. –– Sie können zu neuen Designkonzepten ermutigen und Innovationen motivieren.

Keywords: /// Storytelling /// User Stories /// User Szenarien /// Anforderungsaufnahme /// Produktdefinition

–– Sie fördern ein gemeinsames Verständnis der Ideen zwischen Erzähler und Publikum. –– Sie können nicht zuletzt andere von der Wichtigkeit und dem Wert der Designideen überzeugen. 3. Begriffsdefinitionen für UX Stories Wird im UX Design Prozess eine Geschich te entwickelt und erzählt, ist der Inhalt ein oder mehrere Szenarien, in denen Nutzer mit der geplanten Anwendung umgehen. (Quesenbery und Szuc, 2011) UX Stories bestehen aus –– User Personas –– User Szenarien (User Stories) –– Use Cases 3.1. User Personas Die Persona (lat. Maske) ist eine fiktive Person, die als Prototyp für eine Gruppe von Nutzern einer Anwendung dient. Jede Persona wird mit ihren konkret ausgeprägten Eigenschaften und einem konkreten Nutzungsverhalten detailliert beschrieben.

Usability Professionals 2013 Kurzvorträge

eines fachlich relevanten Zieles ab. (Wikipedia, 2013) Ein Use Case erzählt somit die Geschichte, in der der Nutzer mit einer konkreten Ausgangslage beginnt und ein bestimmtes Ziel verfolgt von Anfang bis Ende. Er bündelt hierbei mehrere User Stories bzw. Erfolgs- und Misserfolgsszenarien. [Abb. 2] Ein Beispiel für einen Use Case mit einer konkreten Ausgangslage und einem Ziel, das die Persona Karin verfolgt, kann sein: Abb. 1. User Personas

Um die Personas einer Anwendung zu definieren, wird bei deren Planung analysiert, wer diese Anwendung später nutzen wird. Anhand von Beobachtungen an realen Menschen, werden deren Eigenschaften und ihr Nutzungsverhalten festgehalten und dann die Personas geschaffen. (Wikipedia, 2013) Da unterschiedliche Menschen die Anwendung nutzen werden, steht eine Persona jeweils für für eine Gruppe von Nutzern. Alle Personas gemeinsam sollen die Gesamtheit aller möglichen Nutzer abdecken. [Abb. 1] Als Beispiel soll eine Nutzer-Persona für den Online-Shop eines Bekleidungsdarstellers dienen: Karin, 39, ist als Reporterin bei einem großen TV-Sender tätig. Sie ist ledig und hat keine Kinder da sie sich voll und ganz ihrem Beruf und ihrer Karriere verschrieben hat. Modisch ist sie sehr interessiert und möchte schon aus beruflichen Gründen immer chic und aktuell gekleidet sein. Da ihr Beruf ihr wenig Zeit lässt und sie viel unterwegs ist, kauft sie ihre Kleidung online ein, vorzugsweise mobil über ihr Smartphone.

3.2. User Szenarien (User Stories) Eine User Story („Anwendererzählung“) erzählt in der Alltagssprache ein einfaches

Szenario, in welchem der Nutzer die Anwendung oder Software gebraucht. Das kann eine Funktion sein, die der Nutzer ausführt oder eine Information oder ganze Seite die er abruft. Es handelt sich immer um einen einzelnen Anwendungsschritt, die User Story ist somit kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze. (Wikipedia, 2013)

Karin ist beruflich unterwegs und wacht morgens im Hotel auf. Am Tag zuvor hatte sie ein Paar Schuhe online bestellt. Sie ist länger als geplant unterwegs ist, möchte die Schuhe aber bald bekommen. Sie ändert die Lieferanschrift ihrer Bestellung entsprechend auf die Adresse ihres Hotels.

Ihr Inhalt des Szenarios kann kann ein Erfolg oder aber auch auch ein Misserfolg bzw ein Fehler sein. Als Beispiel dient wieder die Persona Karin, als Nutzerin des Online-Shop eines großen Bekleidungsherstellers. Eine User Story kann hier lauten: Karin sieht nach Klick des Buttons „Anmelden“ die Eingabemaske für die Anmeldung in ihr Kundenkonto. Die ihr angezeigten Eingabefelder sind „E-MailAdresse“ und „Passwort“.

3.3. Use Cases Use Cases stellen ebenfalls Anforderungen für eine Anwendung oder Software in der Alltagsprache des Anwenders dar. Während eine User Story kurz und knapp einen Anwendungsschritt beschreibt, erzählt der Use Case eine umfassendere Geschichte und zielt auf das Erreichen

Abb. 2. Use Case und User Stories

4. Design Ideen entwickeln mit Storytelling In den vorangegangenen Kapiteln wurde erklärt, wie Geschichten wirken und zu welchen Zwecken sie im UX Design Prozess eingesetzt werden. Es wurden die Bausteine von UX geschichten beschrieben und erste konkrete Beispiele für eine

315

Persona, einen Use Case und eine User Story genannt. Um den praktischen Einsatz von Storytelling im UX Design Prozess klarer zu machen, sollen nun Design-Aufgabe, UX Story und Ergebnis zu einem Schritt für Schritt Beispiel zusammengefügt werden. Zu Beginn erhält der UX Designer als Aufgabenstellung eine erste, grobe SoftwareAnforderung die im nachfolgenden verfeinert werden soll. Nach der Untersuchung von Ziel-Nutzergruppen und der Definition von Personas werden Geschichten bestehend aus Use Cases und User Stories entwickelt, in denen die Personas mit der Anwendung umgehen. Aus diesen Szenarien können einfach die benötigten Funktionalitäten der Software und somit genaue Anforderungen abgeleitet werden. 4.1. Die Design Aufgabe

4.4 Die User Stories Karin loggt sich über ihr iPhone auf der mobilen Version des Online Shops in Ihren Account ein. Sie ruft die Liste ihrer aktuellen Bestellungen auf. Sie wählt aus der Liste ihre aktuelle, offene Bestellung. In den Bestelldetails wählt sie die Option „Lieferadresse ändern“ und ändert die Daten. Sie speichert ab und bekommt per E-Mail eine Bestätigung über die Änderung. 4.5 Das Ergebnis Die spezifischen Anforderungen der Software sind: –– Mobiler Login in Kundenkonto –– Aktuelle Bestellungen mit Status mobil einsehbar –– Abändern von Bestelldaten ermöglichen –– Versand von Bestätigungen per E-Mail Literatur

Der Online Shop eines großen Bekleidungsherstellers möchte seinen Kunden ermöglichen, mobil Bestellungen zu verwalten.

1. Quesenbery, W. & Brooks, K. (2010). Storytelling for User Experience: Crafting Stories for Better Design. Brooklyn, New York: Rosenfeld Media 2. Quesenbery, W. & Szuc, D. (2011). Global

Welche Funktionalitäten sind zu integrieren?

Ux: Design and Research in a Connected World. Burlington, Massachusetts: Morgan Kaufmann

4.2. Die Persona

3. User Story. In: Wikipedia, Die freie Enzyklopädie (2013). Online in Internet: URL: http://de.wikipedia.org/wiki/User_Story

Karin, 39, ist als Reporterin bei einem großen TV-Sender tätig. Sie shoppt für Ihr Leben gerne online, da Sie wenig Zeit hat und viel auf Reisen ist. Sie ist bereits Kundin des Shops und hat kürzlich wieder dort bestellt.

(Stand 23.06.2013) 4. Anwendungsfall. In: Wikipedia, Die freie Enzyklopädie (2013). Online in Internet: URL: http://de.wikipedia.org/wiki/Use_Case (Stand 23.06.2013) 5. Persona (Mensch-Computer-Interaktion). In: Wikipedia, Die freie Enzyklopädie (2013).

4.3 Der Use Case

Online in Internet: URL: http://de.wikipedia. org/wiki/Persona_(Mensch-Computer-

Karin ist beruflich unterwegs und wacht morgens im Hotel auf. Sie hatte gestern ein Paar Schuhe online bestellt, als Lieferadresse Ihre Hausanschrift angegeben und möchte sie sich nun doch ins Hotel senden lassen.

316

Interaktion) (Stand 23.06.2013) 6. Storytelling. In: Wikipedia, the free encyclopedia (2013). Online in Internet: URL: http://en.wikipedia.org/wiki/Storytelling (Stand 29.06.2013)

Usability Professionals 2013 Kurzvortr채ge

317

Zur Notwendigkeit anwendungs spezifischer Usability-Verfahren für betriebliche Software Nina Bär Technische Universität Chemnitz, Institut für Psychologie, Professur Allgemeine und Arbeitspsychologie 09107 Chemnitz nina.baer@psychologie.tu-chemnitz.de

Thomas Seeling Technische Universität Chemnitz, Institut für Maschinenbau Professur Arbeitswissenschaft und Innovationsmanagement 09107 Chemnitz thomas.seeling@mb.tu-chemnitz.de

Susen Döbelt Technische Universität Chemnitz, Institut für Psychologie Professur Allgemeine und Arbeitspsychologie 09107 Chemnitz susen.doebelt@psychologie.tu-chemnitz.de

Frank Dittrich Technische Universität Chemnitz, Institut für Maschinenbau Professur Arbeitswissenschaft und Innovationsmanagement 09107 Chemnitz frank.dittrich@mb.tu-chemnitz.de

Abstract Dieser Beitrag beschreibt auf Basis einer Usability-Evaluation einer ERP-Software, welche Probleme beim Einsatz herkömmlicher Usability-Methoden im Bereich betrieblicher Anwendungssoftware auftreten. Mit Hilfe eines Experten-Reviews, einer Anwenderbefragung sowie eines Usability-Tests konnten die Hauptschwierigkeiten der Verfahren identifiziert werden. Zum einen bedarf es aufgrund der an spezifische Anwendungsbereiche angepassten und meist hoch komplexen Strukturen der Software eines erheblichen Einarbeitungsaufwandes für den Usability Professional. Zum anderen kann ohne Einbindung des Anwendungskontextes eine Beurteilung nur anhand von allgemeingültigen Richtlinien erfolgen, woraus eine geringere Güte der Ergebnisse folgt. Im Rahmen des Projekts „Kompetenzzentrum Usability für den Mittelstand“ (KUM) der Technischen Universität Chemnitz sollen Methoden entwickelt werden, die auf spezifische Bereiche betrieblicher Anwendungssoftware abgestimmt sind und durch einen geringen Aufwand sowie umsetzbare Verbesserungsvorschläge besonders von kleinen und mittleren Unternehmen effizient eingesetzt werden können. Davon profitieren neben den Usability Professionals auch die kleinen und mittleren Unternehmen, da sich Ergebnisse eines anwendungsspezifischen Verfahrens besser in die Software-Entwicklung einbeziehen lassen.

1. Usability von Anwendungssoftware Klassische Usability im Sinne der Optimierung von Bedienabläufen ist neben den Experience-Ansätzen der letzten Jahre eher in den Hintergrund getreten. Werden statt der Interaktion mit technischen Produkten, die in allen Lebensbereichen eingesetzt werden und vermehrt Unterhaltungszwecken dienen, komplexe Anwendungen aus dem Arbeitsalltag betrachtet, kommt Usability nach wie vor eine nicht zu unterschätzende Bedeutung zu. In der deutschen Softwarebranche bilden das Angebot von Unternehmenssoftware sowie unternehmensnahe Dienstleistungen den wirtschaftlichen Schwerpunkt (Leimbach, 2010). ERP- Systeme (Enterprise-RessourcePlanning) sind für diese betriebliche

318

Anwendungssoftware ein typisches Beispiel. Sind es kleine und mittlere Unternehmen, die diese Softwareprodukte entwickeln, ist die Abgrenzung zu konkurrierenden, funktionsähnlichen Produkten durch Argumente wie Anwenderfreundlichkeit eine gute Möglichkeit, Kunden langfristig zu binden (Woywode et al., 2011). Neben den viel zitierten Auswirkungen einer mangelnden Usability für den Nutzer ist diese auch in wirtschaftlicher Hinsicht für das Unternehmen ein nicht zu vernachlässigender Faktor. Ungenügende Usability hat einen starken Einfluss auf die Kosten der Einführung von Anwendungssoftware (Kneissl, 2006), was besonders Mittelständler zu spüren bekommen. Die in Deutschland eingesetzte betriebliche Anwendungssoftware entspricht allerdings zu einem Großteil (80%) nicht den Anforderungen,

Keywords: /// Usability-Methoden /// betriebliche Anwendungssoftware /// ERP-System /// Experten-Evaluation

die in Richtlinien zur Dialoggestaltung formuliert sind (Bräutigam, 2008). Speziell im ostdeutschen Mittelstand (Dittrich & Spanner-Ulmer, 2011) besteht derzeit aus Kundensicht eine Diskrepanz zwischen geforderter und bestehender Usability. Auch aus Unternehmenssicht selbst wurde Verbesserungsbedarf hinsichtlich des Reifegrades unternehmensinterner Strukturen und Praktiken festgestellt (Woywode et al., 2011). Diesem Bedarf an verbesserter Usability von Softwareprodukten steht entgegen, dass in kleinen und mittleren Unternehmen wenig Wissen, entsprechende Tools und/oder Ressourcen zur Verankerung dieses Themas vorhanden sind. Evaluationsmethoden, die zum Aufdecken von Fehlentwicklungen und der Produktoptimierung wichtig wären, kommen kaum zum Einsatz (Woywode et al., 2011).

Usability Professionals 2013 Kurzvorträge

Betriebliche Anwendungssoftware ist oft durch überladene Oberflächen gekennzeichnet, in denen komplizierte Prozesse und Arbeitsaufgaben mit einer Vielzahl von Funktionen zusammentreffen. Damit treten verstärkt Probleme in den Bereichen Aufgabenangemessenheit und Erlernbarkeit auf und sorgen für hohen Support- und Schulungsaufwand auf der Seite des Softwareherstellers. Von Herstellerseite wird vom Anwender Wissen vorausgesetzt, wo sich bestimmte Funktionalitäten verbergen und wie diese zielorientiert zu steuern sind. Ist dieses langfristig aufgebaute Wissen auf Anwenderseite vorhanden, verringert sich wiederrum die Bereitschaft Überarbeitungen der Software zu akzeptieren.

geprüft werden, inwiefern sich bestehen de Methoden für die Usability-Evaluation komplexer Software eignen und wie sie adaptiert werden können. Ein ExpertenReview, eine Anwenderbefragungen (N = 57) sowie ein Usablity-Test (N = 15) lieferten erste Ergebnisse zur Eingrenzung des Verbesserungspotentials eines ausgewählten Softwareprodukts aus dem ERP-Bereich. Zudem konnten bestimmte Schwierigkeiten bei der Anwendung etablierter Usability-Methoden im Bereich betrieblicher Anwendungssoftware festgestellt werden. Diese sollen im Folgenden am Beispiel dargestellt und erste Vorschläge für spezifizierte Methoden diskutiert werden.

Viele Produkte im Bereich betrieblicher Anwendersoftware haben den Anspruch, auf verschiedene Unternehmensgrößen flexibel anpassbar zu sein und alle potentiellen Abläufe in Funktionalitäten abzubilden. Zudem adressieren diese Softwareprodukte kleiner und mittlerer Unternehmen verschiedenste Branchen und haben einen mehrjährigen Entwicklungsprozess vollzogen. Das Angebot maßgeschneiderter Software-Lösungen für den Kunden stellt ein wichtiges Verkaufskriterium dar, birgt aber auch gewisse Gefahren für die Usability des Produktes. Jeder Kunde hat aufgrund firmeninterner Routinen und Arbeitsweisen andere Ansprüche an aufgabenangemessene Funktionsweisen der Software. Die Anpassung der Software an Kundenwünschen erfolgt vom Hersteller oft zu unkritisch, da vor allem kleine und mittelständische Software-Hersteller in ganz besonders hohem Maße abhängig von ihrer Kundenzufriedenheit sind. Oft entstehen so Veränderungen an Elementen der Software, die als einheitliches Grundgerüst für eine optimale Bedienbarkeit konsistent enthalten sein sollten.

2. Usability-Evaluation der ERP-Software eines mittelständischen Herstellers: Schwierigkeiten bei der Anwendung etablierter Usability-Methoden 2.1. Experten-Review

Im Projekt KUM (Kompetenzzentrum Usability Mittelstand; http://www.usabilityzentrum.de) steht die Unterstützung kleiner und mittlerer Unternehmen hinsichtlich der Usability ihrer Produkte im Vordergrund. Für drei verschiedene Anwendungsbereiche soll nach derselben Vorgehensweise

Als Ausgangsbasis zur Anpassung einschlägiger Usability-Methoden an spezifische Anwendungsbereiche wurde zunächst die ERP-Software eines mittelständischen Herstellers durch ein Experten-Review auf allgemeine Richtlinien (DIN EN ISO 9241, 2006) überprüft. Die Software wurde von sechs Experten unabhängig voneinander begutachtet. Aufgrund des komplexen Anwendungsfeldes war es zunächst nötig, dass die Begutachter eine umfangreiche Einführung ins Programm erhielten. Sonst stellt es aufgrund des mangelnden Domänenwissens des Usability-Experten eine große Schwierigkeit dar, kleinere von schwerwiegenden Usability-Problemen zu unterscheiden. Durch die aufwendige Vorbereitung lässt sich der normalerweise als „quick and dirty“-Variante beliebte Experten-Review allerdings kaum mehr als effizient einstufen. Die gefundenen Usability-Probleme konnten nur auf einer sehr allgemeinen Ebene rückgemeldet werden und mussten im Anschluss zur Einordnung mit dem Hersteller diskutiert werden. Es ergibt sich bei Experten-Reviews generell eine große Bandbreite an Informationen, die oftmals keine eindeutigen

Schwerpunkte hinsichtlich des Verbesserungspotentials der Software setzt (Molich & Dumas, 2008). Usability Professionals können nie sicher ausschließen, ob ein vermeintliches Usability-Problem in einer spezifischen Eigenheit des Anwendungskontextes begründet liegt. Ohne Kenntnis von charakteristischen Arbeitsabläufen, dem Zusammenwirken verschiedener Nutzergruppen und branchenspezifischen Anforderungen an Funktionalitäten lassen sich Usability-Probleme nur oberflächlich einordnen. Das macht sie für den SoftwareHersteller nur bedingt nutzbar. Molich & Dumas (2008) fordern diesbezüglich ein selektiveres Vorgehen von Usability-Professionals bei der Rückmeldung von Evaluationsergebnissen aus Experten-Reviews, da nur so eine Verwertbarkeit von Ergebnissen auf Seiten der Entwickler gegeben ist. Für stark spezialisierte Anwendungen eignen sich Experten-Reviews eher weniger (Bias & Mayhew, 2005). 2.2. Anwenderbefragung Als nächster Schritt wurde eine onlinebasierte Anwenderbefragung entworfen, um kontextspezifische Rückmeldung von den Nutzern (N = 57) der ERP-Software zu erhalten. Die Nutzer von betrieblicher Anwendungssoftware können meist auf langjährige Erfahrung mit den Erfordernissen der Arbeitsaufgaben zurückblicken und entwickeln kontextbezogene Strategien, wodurch sie von Usability-Experten identifizierte Probleme unter Umständen nicht als solche ansehen. Andererseits lassen sich spezifische Probleme der jeweiligen Anwendergruppe von Usability-Professionals unter Umständen schwer vorhersagen (Dimitrova, Sharp & Wilson, 2001). Daher enthielt die Anwenderbefragung speziell auf die ERP-Software abgestimmte Fragen. Durch die intensive vorarbeit des ExpertenReviews konnte stärker auf unterschiedliche Usability-Probleme einzelner Anwendergruppen eingegangen werden. Nach den bisherigen Erfahrungen erledigen viele Anwender – wenn auch minimale Aufgaben – in einer Vielzahl von Funktionsbereichen der betrieblichen Anwendungssoftware, was sich trotz geringer

319

Nutzungsintensität stark auf die UsabilityBewertung auswirken kann. Zusätzlich zu den angepassten Fragen wurde in der Anwenderbefragung eine Variante des standardisierten Fragebogens ISO-Metrics (Gediga, Hamborg & Düntsch, 1999) verwendet. So konnte sowohl eine standardisierte Bewertung des Gesamtsystems als auch eine spezifische Bewertung der vom Anwender hauptsächlich genutzten Funktionen abgedeckt werden. Es wurden 13 Anwenderunternehmen kontaktiert, deren Mitarbeiter durchweg eine hohe Motivation zur Teilnahme an der Studie aufwiesen. Die Nutzerstichprobe bildete die Gesamtheit der Anwender repräsentativ ab, mit einem ausgewogenen Geschlechterverhältnis (40% Frauen, 49% Männer), einem durchschnittlichen Alter von 41 Jahren und einer Erfahrung mit der ERP-Software von im Mittel 4 Jahren. Es fielen vor allem Wechselwirkungen zwischen den Bedingungen der Systemeinführung im Anwenderunternehmen und der empfundenen Usability der ERP-Software auf. Je nach Position und Aufgaben im Unternehmen treten in den verwendeten Teilbereichen der Software unterschiedliche Probleme auf. Derartige Sachverhalte sind typisch für betriebliche Anwendersoftware, können aber mit unspezifischen Usability-Methoden wie Experten-Reviews nicht abgedeckt werden. Bei einer allgemeinen Einschätzung des Gesamtsystems lässt sich am Ende nur schlecht beurteilen, welche Bewertungsgrundlagen zu den Einzelurteilen führten, aus denen sich die Gesamtbewertung zusammensetzt. Sonstige unbekannte Einflussfaktoren auf die Nutzerzufriedenheit im Unternehmen spielen für die GesamtUsability-Bewertung eventuell auch eine Rolle, sind aber in ihrer Vielzahl schlicht nicht ganzheitlich zu erfassen. Individuelle Faktoren, welche die Art der Aufgabenbearbeitung beim Anwender beeinflussen können, wie beispielsweise Lernstrategien, lassen sich aufgrund ihrer Vielfältigkeit auf standardisiertem Wege ebenfalls kaum abfragen. Ein Vorteil von Anwenderbefragungen besteht in der Möglichkeit, die für die Anwender bekannte Sprache des Systems in standardisierter Form anzuwenden und daher die Bewertung einzelner Funktionen konkret zu unterstützen.

320

2.3. Usability-Test In einem Usability-Test (N = 15) wurden gezielt typische Aufgaben mit Nutzern aus verschiedenen Unternehmen qualitativ untersucht. Bei der Konzeption und Ausformulierung der Aufgabenstellungen ist aufgrund des umfassenden Funktionsangebots der ERP-Software und einer Vielzahl verschiedener firmeninterner und -übergreifender Anwendergruppen erneut umfassendes domänenspezifisches Wissen nötig. Durch die beiden vorangegangenen Erhebungen und die starke Einbindung des Herstellers konnte ein Set von vier Pflichtaufgaben und vier optionalen Aufgaben erstellt werden. Jeder Nutzer hat spezifische, partielle Erfahrung mit dem System und kann somit nur zu einigen Funktionen eindeutige UsabilityEinschätzungen treffen. Daher wurden als Pflichtaufgaben diejenigen ausgewählt, die durchweg alle Nutzer bei der Arbeit mit der ERP-Software beherrschen müssen. Die Stichprobe glich in den meisten demografischen Merkmalen der Anwenderbefragung, wenngleich am Nutzertest nur 27% Frauen teilnahmen. Die Lösungsansätze der Test personen unterschieden sich innerhalb einer Aufgabe teilweise erheblich. Die im Laufe der Jahre gewachsene Struktur der ERP-Software in Verbindung mit unternehmensspezifischen Abläufen provoziert diverse Bearbeitungsstrategien, die aus theoretischer Sicht durchaus problematisch hinsichtlich Usability-Kriterien erscheinen, von den Anwendern selbst allerdings nicht als hinderlich empfunden werden. Bei den unterschiedlichen Strategien der Anwender für die Erfüllung einer Aufgabe stellen sich keine expliziten Vorteile (wie z. B. Zeitersparnis) einer Vorgehensweise heraus. Eine vergleichende Bewertung dieser Lösungswege ist aus Expertensicht nur schwer möglich, da aus unterschiedlichen Arbeitsaufgaben und –Erfahrungen heraus unterschiedliche Lösungen für den Nutzer naheliegend und zugänglich sind. Der wohl bedeutendste Vorzug eines Usability-Tests liegt in der Erfassung qualitativer Aussagen begründet. Durch die Äußerungen der Testpersonen kann

eindeutig bestimmt werden, in welchem Fall es sich um ein echtes Usability-Pro blem handelt und in welchem Fall die Komplexität der Anwendungssoftware dem Usability-Professional Hürden vorgaukelt. Bei der Auswertung qualitativer Kommentare der Anwender ist es für den auswertenden Usability-Experten häufig schwierig, die geschilderten Probleme zu verstehen, da hier meist unternehmensund/oder branchenspezifische Fachtermini verwendet werden. Für den Hersteller stel len diese Kommentare aber eine reichhaltige Informationsquelle dar. 3. Schlussfolgerungen und Future Work Die beschriebenen Studien zur UsabilityEvaluation lieferten erste Ergebnisse zur Anwendbarkeit herkömmlicher UsabilityMethoden für spezifische Anwendungssoftware. Um die Gebrauchstauglichkeit im Bereich betrieblicher Anwendersoftware wie ERP-Systemen zuverlässig zu beurteilen, sind die etablierten Usability-Methoden wenig effektiv. Eine Usability-Prüfung durch Professionals ohne Einbindung des spezifischen Anwendungskontextes, d.h. Hersteller- und Nutzersicht, kann letztendlich nur anhand von allgemeingültigen Richtlinien erfolgen. Dies hat eine geringere Güte der gewonnen Ergebnisse zur Folge und macht die Methode deutlich weniger effektiv. Eine Anpassung von Usability-Methoden an spezifische Anwendungsbereiche ist daher notwendig. Perspektiven von Usability-Experten, Herstellern und Anwendern sollten kombiniert werden, denn nur so sind aussagekräftige Hinweise zur Benutzerfreundlichkeit der Produkte möglich. Ziel des Projektes „Kompetenzzentrum Usability für den Mittelstand“ (KUM) der Technischen Universität Chemnitz ist es, innovative Methoden zu entwickeln, die durch ihren geringen Aufwand und durch umsetzbare Verbesserungsvorschläge effi zient eingesetzt werden können. Davon profitieren durch die Zeitersparnis während der Vorbereitung eines Reviews sowohl die Usability-Professionals als auch die kleinen und mittleren Unternehmen, da sich

Usability Professionals 2013 Kurzvorträge

anwendungsspezifische Experten-Reviews besser in die Software-Entwicklung einbeziehen lassen. Eine Rückführung der dabei entstandenen Ergebnisse in den Entwicklungsprozess wird vereinfacht (Propp, Buchholz & Forbrig, 2009).

3. DIN EN ISO 9241 (2006). Ergonomische Anforderungen für Bürotätigkeiten mit Bildschirmgeräten, seit 2006: Ergonomie der Mensch-System-Interaktion. Berlin: Beuth. 4. Dittrich, F. & Spanner-Ulmer, B. (2011). "Kompetenzinitiative Usability" (KiU). Mensch, Technik, Organisation-

Anhand der oben beschriebenen Schwierigkeiten bei der Anwendung etablierter Methoden, wird ein Online-Tool konzipiert. Es soll Usability-Expertenwissen mit dem Wissen der Anwender und Hersteller verknüpfen. Die Hersteller sollen dabei aktiv bei der Formulierung von Aufgabenstellungen und Testung ihrer Kundengruppen eingebunden werden. Dabei stellt sich die Notwendigkeit eines Ansprechpartners des Herstellers, der den jeweiligen Anwendungskontext genau kennt und umfassendes Wissen sowohl über die Software als auch den Anwender weitergeben kann. Expertenwissen fließt bei standardisierten Auswertungsmethoden ein und kann im Folgenden ebenfalls bei der Umsetzung der Kundenwünsche eingebunden werden. Der Einsatz dieses Tools sollte eine niedrigschwellige Möglichkeit der UsabilityEvaluierung für kleine- und mittlere Unternehmen darstellen. Es soll KMU zudem die Möglichkeit bieten, Usability verstärkt in ihren Entwicklungsprozess einzubinden. Die Entwicklung des Online-Tools wird ebenfalls durch das Einholen von Feedback potentieller zukünftiger Nutzer begleitet. In der finalen Projektphase soll das Online-Tool interessierten Pilotpartnern langfristig zur Verfügung gestellt und getestet werden.

Vernetzung im Produktentstehungs- und herstellungsprozess, Tagungsband GfA-Frühjahrskonferenz 2011. Zwischenergebnisse eines interdisziplinären Transferprojektes 23. März 2011 – 25. März 2011, Chemnitz, S. 371–374. 5. Kneissl, K. (2006). Enterprise Resource Planning Software: Der Einfluss der Usability auf die Total Cost of Ownership. Diplomarbeit, Leopold-Franzens-Universität Innsbruck. 6. Leimbach, T. (2010). Software und IT-Dienstleistungen: Kernkompetenzen der Wissensgesellschaft Deutschland. Karlsruhe: Fraunhofer ISI. 7. Molich, R. & Dumas, J. (2008). Comparative Usability Evaluation (CUE-4). Behaviour & Information Technology, 27, 263 – 281. 8. Propp, S., Buchholz, G. & Forbrig, P. (2009). Integration of usability evaluation and model-based software development. Advances In Engineering Software, 40(12), 1223–1230. doi:10.1016/j. advengsoft.2009.01

Literatur 1. Bias R. & Karat C.M. (2005). Justifying costjustifying usability. In Bias R. & Mayhew, D. (Hrsg.), Cost-Justifying Usability: an update for an Internet age . Morgan Kaufmann, 2nd edition. 2. Dimitrova, M., Sharp, H. & Wilson, S. (2001). Are Experts Able To Predict Learner Problems during Usability Evaluations?. Proceedings of 13th ED-MEDIA World Conference on Educational Multimedia, Hypermedia & Telecommunications.

321

Usability Testberichte gebrauchstauglicher machen Usability Testberichte aus der CUE-9 Studie im Vergleich Lisa Daske Astrum IT GmbH Am Wolfsmantel 2 91052 Erlangen Deutschland post@lisadaske.de

Abstract Der Usability Test ist durchgeführt, und viele Usability Probleme wurden gefunden. Jetzt müssen diese nur noch dem Kunden übergeben werden – oft in Form eines schriftlichen Testberichts. Doch wie schreibt man eigentlich einen guten Usability Testbericht? Im Rahmen der CUE-9 Studie bewerteten 35 erfahrene Usability Professionals aus Amerika und Deutschland unabhängig voneinander die gleichen Testvideos und erstellten schriftliche Berichte mit ihren Ergebnissen. Diese Berichte wurden in anonymisierter Form veröffentlicht und man kann viel aus ihnen lernen. Dieser Beitrag zeigt: –– Die „best practices“ für den Aufbau eines Usability Berichts, in denen sich alle untersuchten Berichte ähneln –– Mittel, mit denen der Bericht lesbarer gestaltet werden kann, wie beispielsweise das Kennzeichnen verschiedener Ergebnisarten mit Icons –– Besondere Berichte, die sich von allen anderen unterscheiden

1. Einleitung Der Usability Test wird von manchen für die wichtigste aller Evaluierungsmethoden im Usability Umfeld gehalten und er wurde bereits öfter als Maßstab für andere Evaluierungsmethoden verwendet. Diese prominente Stellung des Usability Tests ist ein guter Grund, die Methode genau zu untersuchen, um ihre Stärken und Schwächen kennenzulernen und die Methode innerhalb ihrer Grenzen einzusetzen. Das ist die Motivation hinter Rolf Molichs Studienreihe CUE („Comparative Usability Evaluation“, zu deutsch „Vergleichende Usability Evaluierung“) (1). Bei jeder CUE-Studie evaluieren Teams aus Usability Professionals unabhängig voneinander die selbe Webseite, Web-Anwendung oder Software. Die Studie CUE-9 ist bereits die neunte Studie in dieser Reihe. Sie wurde von Rolf Molich im Rahmen der „Mensch und Computer“-Konferenz in Chemnitz in 2011 mit 16 deutschen Usability Professionals sowie in Atlanta mit weiteren 19 Teilnehmern durchgeführt.

322

Der vorliegende Beitrag soll einen Einblick in die erstellten Testberichte geben und Gemeinsamkeiten sowie Besonderheiten vorstellen. Ziel des Beitrags ist es auch, Hinweise zu geben, mit welchen Mitteln man die Usability des Testberichts besser gestalten kann. Dabei stehen folgende Fragen im Mittelpunkt: –– Gibt es Übereinstimmungen zwischen den Testberichten, die auf einen „State of the Art“, also eine Art Minimalanspruch bei der Erstellung von Usability Reports hinweisen? –– Welche Merkmale machen einen Testbericht besonders „usable“? –– Gibt es ungewöhnliche Berichte, die sich von den anderen unterscheiden? –– Diese Fragen werden anhand von Screenshots und Auszügen aus den Berichten beantwortet. 2. Die CUE-9 Studie Der Fokus der CUE-9 war es, herauszufinden, ob ein „Evaluator Effect“ existiert. Dieser besagt, dass auf der Grundlage derselben Daten mehrere Experten

Keywords: /// CUE-9 /// Usability Testing /// Testberichte

unterschiedliche Usability Probleme imselben System finden. Mehr Informationen zur CUE-Reihe sind auf der Webseite von DialogDesign zu finden (1). Jeder der Teilnehmer erhielt im Vorfeld dieselben 5 Videos von Usability Test Sitzungen zur unabhängigen Auswertung. Grundlage der Studie war eine gemeinsame Evaluierung der Webseite der US-amerikanischen Firma U-Haul, w ww.u-haul.com, die LKWs an Privatpersonen zu Umzugszwecken ver mietet. Den Studienteilnehmern wurden folgende Aufgaben gestellt: –– Die fünf Videos zu je 30 Minuten aus Usability Tests ansehen und auswerten –– Einen kurzen, anonymen Testbericht über das Ergebnis der Bewertung schreiben und einreichen –– Ähnliche Testberichte von anderen Studienteilnehmern lesen Bei einem gemeinsamen Workshop trafen sich die Studienteilnehmer (getrennt in Deutschland und Amerika), um ihre Ergeb nisse zu vergleichen und zu diskutieren. Diese Workshops fanden am 20. Juni 2011 in Atlanta, GA, USA statt (CUE-9a), sowie

Usability Professionals 2013 Kurzvorträge

am 11. September 2011 in Chemnitz, Deutschland (CUE-9b). In Atlanta nahmen dabei 19 Usability Experten teil, in Chemnitz waren es 16 Teilnehmer. In einem weiteren Beitrag von Rolf Molich und Lisa Daske im vorliegenden Tagungsband finden sich Details zu den Ergebnissen der Studie Die im Rahmen der Studie erstellten Testberichte wurden veröffentlicht und können online eingesehen werden (2)(1). Für den vorliegenden Beitrag wurden diese Testberichte verglichen, um nach Gemeinsamkeiten und Auffälligkeiten zu suchen. Der Fokus ist dabei weniger eine wissenschaftliche Auswertung. Vielmehr wurde die seltene Chance genutzt, dass als „Nebenprodukt“ der Studie vergleichbare Auswertungen von vielen Usability Professionals zur Verfügung stehen, in die ein Einblick sonst nicht ohne weiteres möglich wäre. Die Berichte wurden von der Autorin analysiert und verglichen und die interessantesten Aspekte werden im Weiteren vorgestellt.

Abb. 1. Länge der Executive Summary in Seiten

3. Best practices Dieser Abschnitt zeigt die gemeinsamen Eigenschaften eines Testberichts, die in allen oder den meisten Berichten vorhanden waren. 3.1. Executive Summary Der Testbericht zu einem Usability-Test hat zwei Zielgruppen: einerseits dient der Bericht als Arbeitsergebnis für den Auftraggeber, andererseits als Arbeitsgrundlage für diejenigen Mitarbeiter, welche die gefundenen Probleme beseitigen sollen. Die erste Zielgruppe wird den Bericht typischerweise nicht vollständig lesen. Eine Executive Summary, also eine kurze Zusammenfassung der Testergebnisse am Anfang des Berichts, macht es dem Auftraggeber leicht, das Ergebnis des Tests zu erfassen. Alle Testberichte in der Studie enthielten eine Executive Summary; allerdings war sie nicht in allen Fällen auf der ersten Seite des Berichts zu finden, sondern zum Teil hinter einleitenden Abschnitten zur

Abb. 2. Beispiel für eine besonders übersichtliche Zusammenfassung

323

Abb. 3. Beispiel für Problembeschreibung direkt im Screenshot

Methodik und damit schwerer aufzufinden. Eine solche Zusammenfassung gehört zu den „best practices“, die in CUE-9 beobachtet werden konnten. Die Länge der Zusammenfassung variierte von wenigen Stichpunkten bis zu vier Seiten, der Durchschnitt lag bei 1,5 Seiten. [Abb. 1] Abbildung 2 zeigt eine besonders übersichtliche Zusammenfassung. [Abb. 2] Aus der Analyse der Testberichte konnten folgende Eigenschaften abgeleitet werden, die eine gute Executive Summary kennzeichnen: – Die Zusammenfassung sollte kurz sein; 69% der untersuchten Berichte enthielten eine Zusammenfassung von einer Seite oder weniger Länge. – Die wichtigsten Probleme sollten genannt werden. – Das Ergebnis zählt – Ausführliche Informationen zur Methode, den Teilnehmern, etc. gehören nicht in die Zusammenfassung und auch nicht davor 3.2. Visualisierung von Problemen mit Hilfe von Screenshots Screenshots sind eine der wichtigsten Möglichkeiten, dem Nutzer Probleme

324

Abb. 4. Fokus auf die visuelle Darstellung von Problemen in einem Powerpoint-Bericht

verständlich zu machen und sollten nach Möglichkeit Teil eines Berichts sein. 13 von 35 Berichten enthielten dennoch ausschließlich Text – einige Teilnehmer berichteten allerdings, dass ihnen lediglich die Zeit zur Erstellung von Screenshots fehlte. [Abb. 3] Besonders hilfreich für den Leser ist es, wenn im Screenshot der Bereich markiert ist, an dem das Problem auftrat. 25 Prozent der Teilnehmer verzichteten sogar ganz auf lange Word-Dokumente und legten mit Powerpoint-Präsentationen den Fokus klar auf die visuelle Darstellung von Problemen, wie in Abbildung 4 zu sehen. [Abb. 4] 3.3. Anzahl der genannten Probleme Ein Bericht ist nicht dann gut, wenn er möglichst viele Probleme auflistet. Im Gegenteil ist es wichtig, dass der Usability Professional die berichteten Probleme priorisiert und Unwichtiges ausfiltert; denn gerade deswegen wird ein Experte engagiert. Die höchste Zahl der berichteten Probleme war 85, der Durchschnitt lag bei 36. [Abb. 5] Fast drei Viertel (74 %) der

Teilnehmer beschränkten sich auf weniger als 40 Probleme. Ein Bericht enthielt sogar nur 5 Probleme auf einer Seite. [Abb. 6] Der Teilnehmer sagte dazu: „Ich gebe meinen Kunden nur die Probleme, die sie unbedingt beheben müssen. Wenn sie diese Probleme beseitigt habe, können sie gerne zu mir kommen um mehr Resultate zu bekommen.“ 3.4. Beschreibung der Usability Probleme selbst Entscheidender als die Anzahl der Probleme ist es, dass die gefundenen Probleme verständlich formuliert sind, und dass die Auswirkungen auf den Nutzer und das Geschäft des Kunden überzeugend beschrieben werden. Das erhöht die Überzeugungskraft des Berichts und damit die Wahrscheinlichkeit, dass Probleme auch beseitigt werden. Wie die Diskussion im Rahmen der Workshops zeigte, waren einige der in CUE-9 beschriebenen Usability Problemefür andere Teilnehmer schwer oder gar nicht verständlich odergespickt mit Rechtschreibfehlern. Ein Beispiel hierfür ist

Usability Professionals 2013 Kurzvorträge

folgender Befund: „to less notice about miles on the top of the page in step2 after ‚get rates‘ miles=city to city?“. Dieser Befund war für die Teilnehmer des Tests nicht nachvollziehbar, obwohl alle die selben Videos analysiert hatten. Usability Probleme sollte besonders sorgfältig formuliert werden, sonst kann leicht die Glaubwürdigkeit des gesamten Berichts in Frage gestellt werden. Insgesamt waren immerhin 55 von 1.333 Beobachtungen in CUE-9 zu unklar, um verstanden zu werden (Ergebnis der Auswertung der Studie CUE9, siehe (3)). Viele Berichte führten als Problembeschreibung nur Beobachtungen auf, beispielsweise „participant is searching the faq“. Merkmal eines guten Berichts und Grund, einen Experten zu engagieren ist aber gerade, dass dieser das zugrundeliegende Problem herausarbeitet, eventuell sogar mit einem Hinweis auf eine mögliche Lösung. Ein Beispiel für eine solche Auswertung ist in Abbildung 7 zu sehen. [Abb. 7]

Abb. 5. Anzahl gefundener Probleme

3.5. Priorisierung und Gruppierung der Ergebnisse Ein Teil der Berichte führte die Probleme in der Reihenfolge ihres Auftretens nach Test-Sitzung oder durchgeführter Aufgabe auf. Diese Gruppierung ist für den Leser wenig hilfreich. Ein Usability Professional sollte die Probleme in einer nützlicheren Gruppierung darstellen. Verwendete Kategorien in den untersuchten Berichten waren beispielsweise: – Betroffene Seiten oder Funktionalität des untersuchten Produkts – Schweregrad des Problems – Allgemeine Problemkategorien wie „Shopping Experience“ oder „Wording and Text“ 4. Weitere Gestaltungsmöglichkeiten – so begeistert ein Bericht Es gibt viele weitere Möglichkeiten, einen Testbericht so zu gestalten, dass er

Abb. 6. Der kürzeste Bericht in CUE-9 – mit nur 5 Ergebnissen

325

Abb. 7. klare Beschreibung von Beobachtung, zugrundeliegendem Problem und Empfehlung

Abb. 8. Beispiel für einen Bericht mit positiven Beobachtungen

Abb. 9. Ein gut strukturiertes Resultat mit Titel, Problembeschreibung und durch Auswirkungen auf den Nutzer begründete Klassifizierung

besonders verständlich und angenehm zu lesen ist. Die Highlights aus CUE-9 werden in diesem Abschnitt vorgestellt. 4.1. Positive Beobachtungen Auch positive Aspekte können und sollten in einem Testbericht genannt werden: Niemand hört gern nur Kritik, besonders, wenn sie wie bei Usability Tests üblich von außen kommt. Ein Lob der positiven Aspekte eines Produkts kann erheblich dazu beitragen, dass die Testergebnisse akzeptiert

326

und Usability Probleme behoben werden – und dass nicht bei der Überarbeitung des Produkts aus Versehen gelungene Features geändert werden. Abbildung 8 zeigt einen Bericht, der gezielt positive Beobachtungen hervorhebt. [Abb. 8] 4.2. Aufbereitung der Resultate Um das „Scannen“, also das Querlesen eines Berichts zu erleichtern, können die Beschreibungen der einzelnen UsabilityProbleme strukturiert werden. Ein kurzer

Titel hilft dabei, das Problem zu identifizieren. Bei der Beschreibung des Problems ist es wichtig, dass die Auswirkung auf den Nutzer klar wird. Abbildung 9 zeigt ein Beispiel für eine besonders gut strukturierte Problembeschreibung in tabellarischer Form. [Abb. 9] In einigen Berichten wurde der Schweregrad eines Problems darüber hinaus mit Hilfe von Icons und/oder Farben visualisiert. [Abb. 10] Dies machte die Berichte übersichtlicher und sehr viel leichter zu überfliegen.

Usability Professionals 2013 Kurzvorträge

4.3. Zitate Einige Teilnehmer setzten Zitate der Teilnehmer ein. [Abb. 11] Dadurch lässt sich die Glaubwürdigkeit des Berichts erhöhen und der Leser gewinnt einen Einblick in die Stimmung der Nutzer. Ein Beispiel für ein solches Zitat ist der Kommentar eines Testteilnehmers, der erkannte, dass die Webseite vorselektierte zusätzliche Artikel in seinem Warenkorb platziert hatte: „Oh the fields for boxes are pre-filled? You are sneaky!“. 4.4. Ergebnislisten Einige Berichte enthielten eine tabellarische Zusammenfassung der gefundenen Probleme als „Arbeitsliste“ im Anhang oder als separates Dokument, um den Kunden bei der Bearbeitung der Probleme bestmöglich zu unterstützen. Abbildung 12 zeigt ein besonders übersichtlich gestaltetes Exemplar. [Abb. 12]

Abb. 10. Visualisierung des Schweregrads mit Icons

5. Fazit Gerade als Usability Experte sollte man darauf bedacht sein, besonders die eigenen Arbeitsergebnisse immer wieder auf ihre Gebrauchstauglichkeit zu untersuchen. Im Rahmen der CUE-Studie stellten sich klare Gemeinsamkeiten heraus, die eine gute Basis für die Gestaltung von Testberichten zu Usability Tests darstellen: – Eine kurze Executive Summary am Anfang des Berichts – Ergebnisse mit Hilfe von Screenshots visualisieren – Die Anzahl der berichteten Probleme auf ein überschaubares Maß reduzieren – Ergebnisse sinnvoll gruppieren und priorisieren Darüber hinaus bleibt jedem Autor aber ein großer Gestaltungsspielraum, um einen Bericht zu verfassen, der für den Auftraggeber nützlich ist. Besonders visuelle Hilfsmittel wie Screenshots und Farbcodierungen spielen dabei eine große Rolle.Natürlich hat diese Untersuchung aufgrund der rein

Abb. 11. Beispiel für einen Bericht mit Zitaten der Testteilnehmer

327

Abb. 12. Eine besonders 체bersichtliche Arbeitsliste

qualitativen Auswertung der Berichte durch die Autorin eine begrenzte Aussagekraft. In weiteren Schritten ist es vorstellbar, die Ergebnisse mit quantitativen Methoden zu untersuchen oder mit der Einbeziehung weiterer Testberichte zu Systemen aus anderen Dom채nen auf eine breitere Basis zu stellen.

Literatur 1. Rolf Molich, Webseite zu den CUE-Studien, http://dialogdesign.dk/CUE.html 2. Im Beitrag analysierte Testberichte, http:// www.dialogdesign.dk/CUE-9.htm 3. Morten Hertzum , Niels Ebbe Jacobsen & Rolf Molich (2013): What You Get Is What You See: Revisiting the Evaluator Effect in Usability Tests, Behaviour & Information Technology, DOI:10.1080/01449 29X.2013.783114

328

Bewusst. Unter-bewusst. Unbewusst.

329

Online Shopping mit Emotionen Eine Usability Studie über Online-Shops mit EEG Messung

Sabrina Duda users’ delight GmbH Neumagener Str. 29 13088 Berlin duda@users-delight.com

Abstract In dieser Forschungsstudie wurden zwei Online Shops unterschiedlicher Branchen – Mode und Technik – untersucht. Insgesamt 16 Nutzer surften auf jeweils einer Website. Frauen und Männer wurden gleichmäßig auf beide Shops verteilt. Die Nutzer suchten ein Produkt ihrer Wahl aus und kauften es. Während des Online Shoppings wurden die Gehirnströme gemessen. So konnte die echte Shopping Erfahrung erhoben werden. In einem anschließenden Interview berichteten die Probanden über ihre Erfahrungen und beschrieben ihren Eindruck der Website. Mit einem qualitativen Verfahren wurde exploriert, wie die Websites auf emotionaler Ebene empfunden wurden. Das Video vom Shopping, mit Aufzeichnung der Website, einem Bild des Probanden und EEG Messung, wurde gemeinsam mit dem Probanden angeschaut und von diesem kommentiert. Auf diese Weise konnten Hintergrundinformationen über das Shopping gewonnen werden, ohne das Einkaufen selbst zu beeinträchtigen. Es kamen Beobachtung, Interview, Rating und EEG Messung zum Einsatz.

Einleitung In dieser User Experience Studie mit Emo tionsmessung wurden zwei Online Shops aus dem Bereich Mode und Technik anhand einer User Studie im Lab mit echtem Shopping und EEG Messung untersucht. Fragestellungen: –– Was geschieht beim Online Shopping? –– Welche Emotionen haben die Nutzer? –– Wie unterscheiden sich die Emotionen der Nutzer beim Surfen auf den unterschiedlichen Websites? –– Wie hängen Usability Probleme und Emotionen zusammen?

Methodik

sollte eine Seite sein, auf der eher Frauen einkaufen und Saturn eine eher von Männern bevorzugte Shopping Seite. Frauen und Männer wurden gleichmäßig auf beide Shops verteilt, so dass 4 Frauen und 4 Männer auf der Mode-Website und 4 Frauen und 4 Männer auf der TechnikWebsite surften. [Tab. 1] Stichprobe Die Probanden waren im Schnitt 39 Jahre alt (zwischen 25 und 50 Jahren) und größtenteils berufstätig. Sie sind im Schnitt seit 8 Jahren online und täglich oder mehrmals in der Woche im Internet. Sie kaufen mindestens einmal im Monat oder sogar wöchentlich online etwas ein. Alle nutzen PayPal.

Keywords: /// User Experience /// Shopping Experience /// E-Commerce /// EEG /// Emotionen /// Usability

–– Ein User: „Ich bin echt, glaube ich, so ein Opfer, ein Kaufopfer, ein Online Opfer.“ –– Ein anderer User, der seit 10 Jahren online shoppt: „Eine Sucht ist das. Ich geh schon gar nicht mehr in die Läden.“ Online Shopping Erfahrung Die User shoppten am häufigsten auf Amazon und eBay. Auch wurden genannt: Media Markt, Saturn, Conrad, Cyberport, Zalando, H&M, Zara, Baur, Bon Prix, Pizza.de, Dr. Who Shop, Poster Shop, deinetorte.de, Brands for Friends. ZVAB, Prêt-a-porter, Stylebob, DealDoktor, China Gadget, my DealZ, Mr. Specs. firefind.de, günstiger.de.

Versuchsdesign Zalando und Saturn wurden ausgewählt, weil beide Seiten sehr bekannt sind, sie ein großes Angebot haben und es einfache Bezahlmöglichkeiten gibt. So war sicher gestellt, dass die User auf diesen Seiten auch Produkte ihrer Wahl finden. Zalando

330

Tab. 1. Versuchsdesign

Website Zalando (Mode): www.zalando.de

Website Saturn (Technik): www.saturn.de

N = 4 Frauen

N = 4 Männer

Usability Professionals 2013 Bewusst. Unter-bewusst. Unbewusst.

Einführung

2 Min.

EEG Anpassung

10 Min.

Vorinterview

5 Min.

Lieblingswebsite

3 Min.

Website Online Shopping

20 Min.

Interview

10 Min.

Aufnahme angucken und kommentieren

30 Min.

Ratings

7 Min.

Verabschiedung

3 Min.

Gesamt

1 Std. 30 Min.

Zeitgründen auf das gemeinsame Betrachten und Kommentieren verzichtet worden. Es wurde als wichtiger erachtet, die Nutzer in Ruhe surfen zu lassen und ein Produkt nach eigenem Interesse auszuwählen. Das Besondere an dieser Studie ist, dass die Nutzer das Produkt auch tatsächlich kauften, bezahlten und an ihre Adresse liefern ließen (in zwei Fällen auch zur Abholung im Markt bestellten). Der Preis des Produktes sollte 15,- Euro betragen, die im Rahmen des Probandenhonorars erstattet worden sind; in vielen Fällen kauften die Probanden auch teurere Produkte. [Tab. 2]

Erhobene Daten Die meisten erhobenen Daten – mit Ausnahme der Ratings – waren Beobachtungsdaten oder qualitative Daten wie Verhaltensbeobachtung, Vor- und Nachinterview und Videokommentare. Das EEG Gerät misst Excitement, Engagement, Meditation. Wir haben uns auf die Interpretation der Kurven „Current“ beschränkt, die das EEG in Echtzeit misst (die Kurven „Long Term“ zeigen die Kurven im Zeitraffer). [Abb. 1], [Abb. 2], [Abb. 3], [Abb. 4]

Tab. 2. Untersuchungsablauf

Amazon wurde von einem User als übersichtlicher als eBay angesehen. Ein anderer User meinte, er fände eBay selbst nicht mehr interessant, da es zu groß geworden sei; ihm gefielen eBay Kleinanzeigen besser, weil es lokal sei: „Ich brauche persönlichen Kontakt“. Die User kaufen auch große und teure Produkte online: Kühlschrank, Fahrrad, TV, Computer – bis zu 2.800 Euro wurden schon ausgegeben. Bei sperrigen Produkten wie White Goods ist der kostenlose Versand ein großes Plus. Ablauf Nach einer kurzen Einführung wurde das EEG Gerät angepasst. Anschließend gab es ein Vorinterview zur Erfahrung beim Online Shopping; die User zeigten ihre Lieblingswebsite und nachdem die Website – Zalando oder Saturn – geöffnet worden war, verließ der Moderator den Raum. Der Nutzer konnte nun ganz ungestört ein Produkt seiner Wahl aussuchen und kaufen. Die meisten bewerkstelligten dies in ca. 15 Minuten, es gab aber auch einen Nutzer, der 45 Minuten benötigte. Weil die Shopping Experience möglichst unbeeinflusst sein sollte, wurde kein Zeitdruck ausgeübt. Bei insgesamt drei Nutzern ist aus

Abb. 1. EPOC Control Panel

Abb. 2. EEG Kurven Excitement, Engagement und Meditation

Abb. 3. & Abb. 4. Userin mit EEG Gerät

331

Auswertung Die Daten wurden hauptsächlich qualitativ ausgewertet. Wie von Pike, M.; Wilson, M. L.; Divoli, A; Medelyan, A.; 2012 (CUES: Cognitive Usability Evaluation System) berichtet, liegt der größte Nutzen der EEG Daten bei Usability Studien darin, in den EEG Daten Muster zu identifizieren und diese mit den Thinking Aloud Daten in Bezug zu setzen. In dieser Studie wurde allerdings auf Thinking Aloud verzichtet, da die EEG Daten möglichst unbeeinflusst von anderen kognitiven Aktivitäten wie dem Verbalisieren erhoben werden sollten. Sprechen, Bewegungen, etc. stören die EEG Aufzeichnung und produzieren Artefakte. Die EEG Daten haben den großen Vorteil, dass sie objektiver sind als Befragungen oder Präferenzurteile der Nutzer. Die Studie von Kretzschmar, F.; Pleimling, D.; Hosemann, J.; Füssel, S.; BornkesselSchlesewsky, I.; Schlesewsky, M.; 2013, die Lesen auf klassischem Papier vs. digitalen Medien vergleicht und EEG und Eyetracking einsetzt, zeigt, dass tatsächlicher kognitiver und neuraler Aufwand und subjektive Urteile und Präferenzen nicht übereinstimmen. Ergebnisse Was wurde geshoppt? Käufe auf Saturn Die Männer kauften Kopfhörer (9,99 Euro), DVD Rohlinge (9,99 Euro), Citruspresse (34,99 Euro), Lautsprecher (79,00 Euro). Die Frauen kauften USB-Stick (13,99 Euro), Lockenstab (29,99 Euro), Buch (14,99 Euro), 2 Bücher (19,98 Euro). Käufe auf Zalando

Die Männer kauften Duschvorhang (13,95 Euro), Gymnastikball & Griffband Tennisschläger (17,94 Euro), Schuhe (40,95 Euro), T-Shirt (15,95 Euro). Die Frauen kauften Schuhe (14,95 Euro), Schuhe (36,95 Euro), Tasche (14,95 Euro), Gesichtscreme (32,95≈Euro).

332

Saturn

Zalando

Mittelwerte

Männer

33,49 Euro

22,20 Euro

27,85 Euro

Frauen

19,74 Euro

24,95 Euro

22,34 Euro

Mittelwerte

26,62 Euro

23,57 Euro

Tab. 3. Mittelwerte der Käufe

Abb. 5. Shopping Dauer

Käufe insgesamt Die Männer gaben insgesamt mehr Geld aus! Die Männer gaben im Schnitt mehr Geld auf Saturn aus, die Frauen im Schnitt mehr auf Zalando. Auf Saturn wurde insgesamt etwas mehr Geld ausgegeben als auf Zalando. [Tab. 3]

Wie wurde das Einkaufserlebnis bewertet? Persönlicher Bezug Saturn polarisiert, Zalando scheint eher beide Geschlechter anzusprechen. [Abb. 6]

Wie lange wurde geshoppt? Der schnellste User brauchte insgesamt 9 Minuten, der langsamste 46 Minuten. Die Zeitdauer für die Produktsuche und -auswahl betrug zwischen 6 Minuten und bis zu 43 Minuten; der Checkout dauerte zwischen 1 Minute und 16 Minuten. In der Grafik sieht man, dass die Zeit für Produktsuche und -auswahl (Shopping; mit grün markiert) den größten Anteil ausmacht: [Abb. 5]

Abb. 6. Persönlicher Bezug zur Website (Rating von 1 = gar kein Bezug bis 5 = sehr viel Bezug)

Usability Professionals 2013 Bewusst. Unter-bewusst. Unbewusst.

Gefallen Online Shopping insgesamt Männern gefällt das Shopping auf Saturn und Zalando gleich gut; Frauen shoppen lieber auf Zalando. [Abb. 7], [Tab. 4] Gesamtbewertung UX

Männer

Saturn 3,33

Zalando 3,13

Frauen

4,13

4,17

Tab. 4. Gesamtbewertung UX

Was wäre wenn … die Website ein Mensch wäre Diese Methode funktionierte erstaunlich gut. Alle Testpersonen bis auf eine einzige entwickelten lebhafte Vorstellungen davon, wie dieser Mensch beschaffen wäre. Durch diese Methode erfährt man, wie stark sich der User mit der Website identifiziert, welche „Persönlichkeit“ die Website hat und welche Zielgruppe aus Sicht der User angesprochen wird. Wird der „Website-Mensch“ als unsympathisch beschrieben, heißt das, dass die Website dem User nicht sympathisch ist. Wird der „Website-Mensch“ als sehr abweichend vom User selbst beschrieben, zeigt dies, dass die Website auf emotionaler Ebene als entfernt erlebt wird. Es ist anzunehmen, dass die User eher auf Websites einkaufen werden oder dort zumindest eine

bessere Shopping Experience haben, wenn die Website als sympathische Persönlichkeit empfunden wird, die ihnen selbst ein wenig ähnlich ist. Hier geht es um die emotionale Wirkung von Websites. Saturn Der Saturn Website Mensch wäre männlich, würde Tim, Jens oder Dennis heißen, wäre ca. Mitte 30, im lockeren Business Stil gekleidet mit Jacket, blauem Hemd und Turnschuhen, ein Verkäufer und Managertyp, sportlich, technikaffin, eher oberflächlich, aber eigentlich doch sympathisch. Seine Interessen liegen in den Bereichen Technik und Reisen, er fährt einen Sportwagen, hat einen sehr großen Freundeskreis, ist vertrauenswürdig, aber auch etwas gestresst wegen der vielen Arbeit. [Abb. 9]

Abb. 7. Gefallen Online Shopping insgesamt (Rating von 1 = gefällt gar nicht bis 5 = gefällt sehr gut)

Abb. 9. Website Saturn als Mensch Abb. 8. Bewertung Website (Rating von 1= sehr schlecht/sehr wenig bis 5 = sehr gut/sehr viel)

Bewertung Website Die Frauen bewerten beide Websites besser als die Männer. In der Bewertung von Saturn und Zalando durch die Männern besteht kaum ein Unterschied. [Abb. 8]

Die Ratings bewerteten Gestaltung, Spaß, Vertrauen, Benutzerfreundlichkeit, Produktsuche, Bestellprozess.

Abb. 10. Website Zalando als Mensch

333

Zalando Der Zalando Website als Mensch attestieren einige User einen Mangel an Persönlichkeit. Die Person wäre konservativ, ohne eigene Meinung, dezent gekleidet, ‚halbtrendig‘ und könnte sowohl eine Frau als auch ein Mann sein.

Jahren, „die keine Ahnung mehr hat, die Sachen kompliziert macht“, ein Blümchenkleid trägt und Emma heißt.

Eine Userin sieht in der Zalando Website eine Frau namens Helga. Sie ist ca. Mitte 30, zwar modebewusst, aber kein Vorreiter, sondern eher konventionell gekleidet. Sie ist nett und hilfsbereit, aber ein bisschen aufdringlich. Sie ist eher gewöhnlich, ohne eigene Persönlichkeit. Helga ist Hausfrau, sie muss nicht arbeiten. Aus Langeweile begann sie mit Tupper Partys und jetzt ist Verkaufen ihr Steckenpferd. Helga wohnt im Berliner Umland oder in Bottrop.

Fazit

Ein anderer User sieht in der Seite eine unsympathische Frau, zwischen 60 und 70

Ein User sieht in Zalando einen Mann Mitte/Ende 30, eher sympathisch, legere Businesskleidung. [Abb. 10]

Saturn sollte seine Website „weiblicher“ gestalten. Saturn bietet viele Produkte für Frauen an. Von vielen Frauen aber wird die Website als unattraktiv („männlich, mir unähnlich“) wahrgenommen. Das ist bei den realen Märkten weniger der Fall als bei der Website. Interessanterweise wird die Zalando Website nicht von allen Usern als eindeutig weiblich wahrgenommen. Dies ist passend, wenn die Zielgruppe von Zalando nicht auf

Frauen beschränkt sein soll, sondern gleichermaßen Männer angesprochen werden sollen. Das Design erinnert in der Wirkung ein wenig an Amazon, das ja auch quasi „geschlechtsneutral“ ist. Ansonsten könnte die Website auch ein wenig „peppiger“ gestaltet werden, um mehr den sonstigen Werbemitteln (TV Spots) zu entsprechen. Einige User äußerten sich erstaunt darüber, dass sich die Website vom Stil der TV Spots so sehr unterscheidet. Ausgewählte Shopping Story Wir stellen Ihnen hier beispielhaft eine Shopping Story vor (für jeden einzelnen der 16 User existiert eine Story; in diesem Beitrag haben wir Ihnen aus Platzgründen nur die zusammengefassten Ergebnisse präsentiert).

Abb. 11. Userin auf Zalando: Tasche gefällt

Abb. 12. Userin auf Zalando: Morgenmantel gefällt

Abb. 13. Userin auf Zalando: Teelichter gefallen

334

Usability Professionals 2013 Bewusst. Unter-bewusst. Unbewusst.

Emotional Shopper Diese Userin shoppt insgesamt ca. 12 Mi nuten. Auf die Produktauswahl entfallen ca. 10 Minuten; auf den Bezahlvorgang ca. 2 Minuten.

Die Userin sieht sich unter „Accessoires“ Taschen an. Die Kosmetiktasche gefällt ihr: „Da seh‘ ich was Buntes, ich steh‘ auf bunt. Die fand ich auch echt schön, da hab‘ ich ‘nen Moment überlegt. Dacht‘ dann aber, ich brauch‘s eigentlich wirklich echt gar nicht.“ An den hohen Kurvenausschlägen der Excitement Kurve sieht man, dass ihr die Tasche richtig gut gefallen hat: [Abb. 11] Sie sieht sich eine Sonnenbrille an: „Ich denke so normale Brille, mach‘ auf groß und sehe… und denke Sternchen, toll!“. Sie öffnet einen neuen Tab, um die Sonnenbrille so quasi zu „speichern“ für einen

eventuellen Kauf. Sie sieht sich etliche weitere Produkte im Detail an und immer, wenn ihr etwas besonders gut gefällt, steigt das Excitement: [Abb. 12], [Abb. 13]

Adidas Originals AC Minibag Umhängetasche, black/metallic gold, für 14,95 Euro. Das war eine schnelle Entscheidung. Sie freut sich über die Bestellung: [Abb. 16]

Sie sieht sich in der Kategorie Bekleidung um und beschäftigt sich mit den Größen. Dabei hält sich ihr Excitement generell in Grenzen. Im Bereich Beauty sucht sie erfolglos nach einem Parfum. Als sie wieder bei den Accessoires ist, sagt sie: „Also Accessoires haben es mir irgendwie angetan […], weil man da […] sich am meisten inspirieren lassen kann.“ Sie findet den Preisregler und gibt ein Preislimit ein: [Abb. 14]

Nach dem Shopping befragt, wie sie sich fühlt, sagt sie: „Gut, ich hab‘ eine neue Tasche, yeah!“ Sie freut sich auf die Lieferung. „Bin gespannt, wie es aussieht in echt.“ Sie erzählt, sie hätte ein Freudeerlebnis gehabt, als sie die Tasche entdeckte: „Gleich so ein “Ja„- Gefühl gehabt, die ist es.“

Sie ist nun wieder bei den Taschen und nach einer Zeit entdeck sie die AdidasUmhängetasche: [Abb. 15] Sie sieht sie sich kurz im Detail an und sagt: „Die nehm‘ ich“. Sie kauft eine

Die Userin erzählt: „Internetbestellungen sind so ein Urding -- man bekommt Pakete, Kinder lieben Pakete.“ Pakete seien wie Geschenke; sie hätte zum Geburtstag für sich und ihre Tochter alles im Internet bestellt, die Pakete mitten im Zimmer stehen lassen und vier Wochen gewartet bis zum Auspacken.

Abb. 14. Userin auf Zalando: Preisregler

Abb. 15. Userin auf Zalando: Kaufentscheidung

Abb. 16. Userin auf Zalando: Kauf

335

Kritik der User und Usability Probleme Saturn Bei Saturn gefiel teilweise das Design der Seite nicht so, es wurde als kühl empfunden; auch die unübersichtliche Darstellung der Produkte (zu viel Ablenkung außen herum) wurde kritisiert. Es wurden bessere Sortier- und Filtermöglichkeiten gewünscht.

Die meisten Probleme traten bei der Registrierung auf: Grundsätzlich wurde

der Zwang zum Registrieren bemängelt, und auch beim Ausfüllen der Formularfelder traten Probleme auf (Anordnung der Felder nicht optimal; nicht klar, welche Felder optional sind, etc.). Ein User war sehr irritiert, dass bei Auswahl der Option Selbstabholung zunächst trotzdem die Versandkosten angezeigt werden. Manche User hatten Probleme bei der Passworteingabe oder beim PayPal Login.

Diese Userin ist insgesamt recht entspannt und hat keine größeren Excitement Ausschläge, außer beim Registrieren: [Abb. 17] Als bei diesem User bei der Adresseingabe Usability Probleme auftauchen, steigt die Kurve: [Abb. 18] Als bei der „Zahlartauswahl“ das PayPal Logo nicht direkt anklickbar ist, bedeutet das für den User erneut Stress: [Abb. 19]

Abb. 17. Userin auf Saturn: Registrieren

Abb. 18. User auf Saturn: Adresseingabe

Abb. 19. User auf Saturn: Auswahl der Zahlungsart

336

Usability Professionals 2013 Bewusst. Unter-bewusst. Unbewusst.

Diese Userin hat Probleme bei der E-Mail Eingabe bei PayPal und ist gestresst: [Abb. 20] Dieser User ist auf der Saturn Website und checkt auf Idealo Bewertungen, was ihn sehr beschäftigt: [Abb. 21] Zalando Das Design der Zalando Website wurde nicht so stark kritisiert, es fiel den Usern

höchstens auf, dass es sich im Stil von der Werbung unterscheidet. Ein User kritisierte, dass die Topseller zu viel Platz einnähmen. Eine Userin hätte gerne Abbildungen von den Produkten beim Tragen. Allerdings war der Suchprozess für die User schwierig: Die User kritisierten z.B., dass Warenkorb und Wunschzettel nicht so leicht auffindbar seien, dass das Filtersetzen nicht einfach sei und der Filter schnell wieder zur Voreinstellung zurückschaltet.

Der Checkout Vorgang bei Zalando bereitete weniger Probleme als bei Saturn. Einmal gab es ein Problem damit, ein Produkt in den Warenkorb zu legen; und ein User bemerkte zunächst nicht, dass bei der Zahlung die Option „auf Rechnung“ voreingestellt war. Beim Registrieren geht die Excitement Kurve hoch. Das scheint für diese Userin stressig zu sein: [Abb. 22]

Abb. 20. Userin auf Saturn: PayPal

Abb. 21. User auf Idealo

Abb. 22. Userin auf Zalando: Registrieren

337

Als die Userin ein Paar Schuhe in den Warenkorb legen möchte, wird der Vorgang durch ein Popup verhindert. Man sieht, dass das ein wenig Stress verursacht, da die Kurve in diesem Moment ansteigt: [Abb. 23]

Diese Userin gibt das Suchwort „Föhn“ in die Suche ein und zwei hohe Schuhe erscheinen. Ihre Excitement Kurve ist so weit oben wie nie zuvor; sie wundert sich offensichtlich: [Abb. 25] Fazit Shopping Stories

Hier meldet sich ein User an, um 5,- Euro Gutschrift zu erhalten; das Excitement steigt sehr stark: [Abb. 24]

Generell kann man sagen, dass es sehr unterschiedliche Shopping Typen gibt: Der emotionale Käufer lässt sich sehr stark

von Bildern und Inspirationen beeinflussen. Er kauft auch einmal etwas, was er eigentlich nicht braucht, und freut sich darüber. Das EEG Bild ist sehr bewegt; bei jedem Produkt, das ihn anspricht, geht die Excitement Kurve stark nach oben. Der pragmatische Shopper kauft meistens sehr zielgerichtet, er vergleicht systematisch und liest Bewertungen. Er kauft nur, was er braucht. Er lässt sich weniger beeinflussen von attraktiven Produktdarstellungen. Das

Abb. 23. Userin auf Zalando: Popup Problem

Abb. 24. User auf Zalando: Gutschrift

Abb. 25. Userin auf Z alando: Merkwürdiges Suchergebnis

338

Usability Professionals 2013 Bewusst. Unter-bewusst. Unbewusst.

EEG Bild ist weniger bewegt. Die Engagement Kurve ist oben. Er ist engagiert bei der Sache, lässt sich aber emotional nicht mitreißen. Es gibt auch noch den Typ „routinierter Shopper“, der sich sehr schnell durchklickt und sich viele Produkte ansieht. Der „überforderte Shopper“ kämpft mit der riesigen Auswahl und klickt ziellos umher. Er profitiert von einer geringeren Produktauswahl und Unterstützung in Form von Produktvorschlägen. Der Prozess der Produktsuche, Produktauswahl und Eingrenzung ist eine Herausforderung für die User und bereitet oft eher Probleme als der Checkout. Das Phänomen der Überforderung durch ein zu großes Produktangebot existiert in den realen Märken auch; genau aus diesem Grund kaufen manche User lieber online ein. Die Vorteile des Online Shoppings liegen darin, dass in Ruhe Produkte betrachtet und Infos gelesen werden können, und es mehr Möglichkeiten zur Produktselektion und Produkteingrenzung gibt. Manche User scheinen überfordert damit zu sein, sich ein Produkt frei nach Wahl auszusuchen. Das ist besonders dann der Fall, wenn sie zu den zielgerichteten Shoppern gehören, die normalerweise nur dann shoppen, wenn sie etwas ganz Bestimmtes suchen. Online Shopping Sites sollten den User noch mehr unterstützen bei der Produktsuche. Es sollte mehr Sortiermöglichkeiten geben in Form von Filtern oder Unterkategorien. Ein Preisregler ist an sich gut, wirft aber nicht immer Ergebnisse ab und wird meistens nicht sofort von den Usern entdeckt. Kategorien wie Sales, Neuigkeiten oder Inspirationen funktionieren sehr gut als Einstieg in die Seite. Nur sind die User enttäuscht, wenn sie dann dort nichts Spannendes entdecken. Bewertungen sind wichtig für viele User. Sie sortieren danach und geben an, diese auch zu lesen. Einige User verließen die Shopping Websites, um auf Google, Amazon und Idealo Produktbewertungen zu lesen. Ein User sagte: ,,Bin immer sehr leicht zu beeinflussen, was die Benutzerbewertung angeht.“ Es fällt auf, dass etliche Nutzer während der Produktsuche immer wieder auf die

Produktgruppe in der engeren Wahl zurückkommen; sie springen hin und her und häufig kaufen sie ein Produkt, das sie schon zu Beginn gesehen haben. Sie sind sich eigentlich schon recht sicher, aber wollen noch schnell etwas anderes nachsehen oder sich noch absichern; eine Art Bedenkpause vor dem Kauf findet hier statt. Deshalb könnte es neben dem Warenkorb noch eine Art unverbindlichen „Zwischenspeicher“/„Wunschliste“ für Produkte in der engeren Auswahl geben, vielleicht sogar mit Markier- oder Sortierfunktion. Vier User in dieser Studie lösten dieses Problem dadurch, in dem sie mehrere Tabs öffneten und in einem neuen Tab weitersurften, um sich so die Produkte aufzuheben für einen eventuellen späteren Kauf. Manche User nutzten für diesen Zweck auch das Navigieren mit Hilfe der Dokumentation ihrer bereits angesehenen Produkte. Wenn ein User sich ein Produkt im Detail ansieht, ist die Wahrscheinlichkeit hoch, dass er es auch kauft. Einige User bemängelten, dass sie sich zum Einkaufen bei den Shops registrieren mussten. Empfehlungen –– Produktsortiment übersichtlich halten (nicht zu viele Produkte einer Sorte; mehr Unterkategorien) –– Mehr Sortierfunktionen –– Preisregler anbieten, der leicht auffindbar und gut bedienbar ist –– Bewertungen anderer User –– Eine Art Wunschzettel als Zwischenspeicher –– Dokumentation der vom User bereits angesehen Produkte –– Inspiration durch Kategorien wie „Neuheiten“, „Sales“, „Inspiration“ oder durch Produktvorschläge –– Abbildungen von Bekleidung und Schuhen sollten Produkt am Menschen zeigen

Diskussion und Ausblick Generell erstaunte, dass der Kauf- und Bezahlprozess weniger Schwierigkeiten bereitete als erwartet, aber der Such- und Auswahlprozess einige User richtiggehend

überforderte. Entscheidend für eine gute Shopping Experience ist, wie gut die User bei diesem Kaufentscheidungsprozess unterstützt werden. Die Methode des EEG ist geeignet, um die User Experience und die Shopping Experience zu messen. Das EEG zeigt, wenn ein User bei Usability Problemen frustriert ist und es zeigt auch, wenn der User ein Produkt sehr attraktiv findet. Es wurden etliche Usability und Gestaltungsprobleme aufgedeckt und die emotionale Wirkung der zwei Websites konnte analysiert werden. Allerdings ist das EEG sehr vom Typ des Users abhängig. Es gibt emotional involvierte und eher pragmatische User. Die EEG Messung ist eher ereignisbezogen aufschlussreich und kann weniger gut Rückschlüsse auf die gesamte Usability Qualität einer Website liefern. Da die Shopping Experience doch sehr individuell bei den Usern war, zeigen sich zwar unterschiedliche Shopping Typen, eine Kategorisierung in typische Muster bei Männern und Frauen lässt sich aus den Daten allerdings nicht ableiten. Bezüglich der Preise der eingekauften Produkte und bezüglich der Gesamtbewertung zeigten sich Unterschiede bei Männern und Frauen. EEG sollte immer mit anderen Methoden kombiniert werden. Nur so können die Daten interpretiert werden. Bei der Methode des EEG sollten einige Dinge insbesondere beachtet werden: Der User sollte in Ruhe surfen; starke körperliche Bewegungen, Unterhaltungen oder Kommentieren stören die Datenerhebung und verhindern, dass das EEG tatsächlich mit den interessierenden Ereignissen bei der Interaktion oder mit dem Stimulus in Bezug gesetzt werden kann. Aus diesem Grund sollte der Moderator den Raum verlassen. Thinking Aloud ist hier nicht in Echtzeit einsetzbar. Interviews sollten immer nach der EEG Datenerhebung stattfinden. Sehr wichtig ist auch genügend Zeit und Ruhe für die Anpassung des EEG und für

339

das Einpendeln des EEG Systems auf den User. Der Nutzer sollte das Gerät mindestens 10 Minuten lang tragen, bevor die eigentliche Datenaufzeichnung beginnt. Darüber hinaus sind die Erfahrungen sehr positiv: die User fanden das EEG Gerät völlig unproblematisch, einige waren sogar regelrecht fasziniert von der Technologie.

Literatur 1. Carnea, D., Olch, P.S., Ebert, A. and Kerren, A., (2011). EEG-Based Measurement of Subjective Parameters in Evaluations. HCII’11, Posters, 279–283. 2. Kretschmar, F., Pleimling, D., Hosemann, J., Füssel, S., Bronkessel-Schlesewsky, I., & Schlesewsky, M. (2013). Subjective impressions do not mirror online reading

Das EEG misst teilweise Daten, die auch mit anderen Neuromethoden wie Hautleitwert oder Pupillometrie erhoben werden können. Hautleitwert misst den Erregungszustand des Probanden anhand der elektrischen Leitfähigkeit der Haut, bei der Pupillometrie deutet die Erweiterung der Pupille auf verstärktes Interesse hin. Von den drei gemessenen Dimensionen war Excitement die aussagekräftigste. Allerdings ist hier eine Interpretation im Kontext unverzichtbar: Excitement zeigte sich sowohl bei Frustration als auch bei Freude. Erstrebenswert wären Folgeuntersuchungen mit größeren Stichproben und unterschiedlichen Websites, um Unterschiede aussagekräftig untersuchen zu können. Aufgrund der kleinen Stichprobe handelt es sich in diesem Fall um eine eher qualitative, explorative Studie. Mit Studien dieser Art, die eine eher offene Herangehensweise haben, lassen sich oft sehr interessante Erkenntnisse gewinnen. Durch den Aufwertungsaufwand bei diesen Studien sind der Stichprobengröße allerdings Grenzen gesetzt.

340

effort: Concurrent EEG-Eyetracking evidence from the reading of books and digital media. PLoS ONE 8(2): e56178. doi:10.1371/journal. pone.0056178 3. Pike, M., Wilson, M., Divoli, A., & Medelyan, A. (2012). CUES: Cognitive Usability Evaluation System. EuroHCIR2012. 4. Silber, J. (2012). Evaluierung der Praxistauglichkeit von Emotions- und Bioparametermessung als UsabilityTestmethode. Unveröffentlichte Diplomarbeit, Fachhochschule Technikum Wien

Usability/ UX Testing

341

Usability Test Ergebnisse – Eine sehr persönliche Angelegenheit Molich, Rolf DialogDesign Skovkrogen 3 DK-3660 Stenløse Dänemark Molich@DialogDesign.dk

Daske, Lisa Astrum IT GmbH Am Wolfsmantel 2 91052 Erlangen Deutschland post@lisadaske.de

Abstract ADer Beitrag stellt einige der wichtigsten Ergebnisse der Usability Test Studie CUE-9 vor. In CUE-9 (Comparative Usability Evaluation-9) erhielten 35 Usability Professionals die selben 5 Usability Test Videos von einer Webseite zur unabhängigen Auswertung. Später haben die Teilnehmer ihre Auswertungen verglichen, gestaunt, und von den großen Unterschieden gelernt. Wichtige Ergebnisse sind: Auf der getesteten Webseite einer Autovermietungsfirma wurden mehr als 200 Usability Probleme gefunden.Die Teilnehmer fanden größtenteils unterschiedliche Probleme. Nur wenige Probleme wurden von mehr als der Hälfte der Teilnehmer gefunden. Der Schweregrad von Problemen wurde oft sehr unterschiedlich beurteilt.

1. Einleitung Um die Usability von Systemen zu verbessern, muss die Usability dieser Systeme zuerst bewertet werden können. Dafür werden verlässliche und robuste Evaluierungsmethoden benötigt. Der Usability Test wird von manchen für die wichtigste aller Evaluierungsmethoden gehalten und er wurde bereits öfter als Maßstab für andere Evaluierungsmethoden verwendet. Diese prominente Stellung des Usability Tests ist eine Motivation dafür, die Methode genau zu untersuchen, um ihre Stärken und Schwächen kennenzulernen und die Methode innerhalb ihrer Grenzen einzusetzen. Das ist die Motivation hinter Rolf Molichs Studienreihe CUE („Comparative Usability Evaluation“, zu deutsch „Vergleichende Usability Evaluierung“). Bei jeder CUE-Studie evaluieren Teams aus Usability Professionals unabhängig voneinander die selbe Webseite, WebAnwendung oder Software. Das Hauptziel der Studien ist es, genug Daten zu sammeln, um unter anderem folgende Fragen zu beantworten:

342

–– Ist das Ergebnis von Usability Evaluierungen reproduzierbar? –– Wie viele Usability Probleme hat das getestete Produkt tatsächlich? –– Wie viele Usability Probleme findet man auf einer typischen, nicht trivialen Webseite normalerweise? –– Was ist ein „kritisches“ oder „ernstes“ Usability Problem? Die neunte Studie in dieser Reihe, CUE-9, wurde im Rahmen der UPA-I Konferenz in Atlanta (USA) 2011 sowie im Rahmen der „Mensch und Computer“-Konferenz in Chemnitz 2011 mit insgesamt 35 Usability Professionals durchgeführt. Dieser Beitrag stellt einige der wichtigsten Ergebnisse der CUE-9-Studie vor. 2. Ablauf der Studie Der Fokus der Studie war es, herauszufinden, ob ein „Evaluator Effect“ existiert. Dieser besagt, dass auf der Grundlage der selben Daten mehrere Experten unterschiedliche Usability Probleme im selben System finden. Mehr Informationen zu CUE-Reihe finden Sie auf der Webseite von DialogDesign (1).

Keywords: /// CUE-9 /// Usability Testing /// Thinking-Aloud-Methode /// Comparative Usability Evaluation

Bei einem gemeinsamen Workshop trafen sich die Studienteilnehmer (getrennt in Deutschland und Amerika), um ihre Ergebnisse zu vergleichen und zu diskutieren. Diese Workshops fanden am 20. Juni 2011 in Atlanta, GA, USA statt (CUE-9a), sowie am 11. September 2011 in Chemnitz, Deutschland (CUE-9b). In Atlanta nahmen dabei 19 Usability Experten teil, in Chemnitz waren es 16 Teilnehmer. 2.1. Vorbereitung Jeder der Teilnehmer erhielt im Vorfeld 5 Videos von Usability Test Sitzungen zur unabhängigen Auswertung. Grundlage der Studie war eine gemeinsame Evaluierung der Webseite der US-amerikanischen Firma U-Haul, www.u-haul.com, die LKWs an Privatpersonen zu Umzugszwecken vermietet. Den Studienteilnehmern wurden folgende Aufgaben gestellt: –– Fünf Videos zu je 30 Minuten aus Usability Tests ansehen und bewerten –– Einen kurzen, anonymen Testbericht schreiben und einreichen –– Ähnliche Testberichte von anderen Studienteilnehmern lesen

Usability Professionals 2013 Usability/UX Texting

2.2. Workshop Während der Workshops wurden die Teilnehmer in Gruppen von 4–5 Personen geteilt. Die Gruppen erhielten einzelne Usability Probleme in gedruckter Form, die: –– Von den Teilnehmern der Gruppe in deren jeweils einzelner Evaluation gefunden worden waren –– In den einzelnen Evaluationen als katastrophal, kritisch, ernst, oder als Bug bewertet wurden (AA, A, B oder X auf den Bewertungsskalen) Die Gruppen wurden gebeten, die Ergeb nisse zu einer Gruppenevaluation zusammenzuführen. Im zweiten Teil des Workshops diskutierten die Teilnehmer über ihre Eindrücke. Gegenstand der Diskussion war, ob die Gruppenevaluation neue Erkenntnisse beigetragen hatte, und ob die Teilnehmer einen „Evaluator Effect“ wahrgenommen hatten. 3. Ergebnisse 3.1. Evaluator Effect Es wird angenommen, dass der Hauptgrund für den Evaluator Effect der ist, dass die Usability Evaluierung eine interpretierende Tätigkeit ist. Die Tester müssen Ermessensentscheidungen treffen, indem sie von einer Abfolge von Benutzerinteraktionen auf eine von Usability Problemen schließen. Es ist nicht überraschend, dass solche Entscheidungen bei verschiedenen Testern nicht immer zum selben Ergebnis führen. Was überraschen kann, ist das Ausmaß des Evaluator Effects. In vorherigen CUE-Studien war die Anzahl der Probleme, die nur von einem einzigen Tester gefunden wurden, deutlich größer als die Anzahl der Probleme, die von mehreren Testern gefunden wurden. Auch in CUE-9 konnte dieser Effekt gezeigt werden: Immerhin 37% der Probleme wurden nur von einem einzigen der Teilnehmer berichtet. Der Anteil derjenigen Probleme, die von 4 oder mehr Teilnehmern berichtet wurden, beträgt ebenfalls lediglich 38%. [Tab. 1]

CUE-9a

CUE-9b

Combined

Anzahl aller Probleme

134

169

Probleme, die nur ein Teilnehmer berichtete

52/134 39%

35/93 38%

62/169 37%

Probleme, die von 2 oder mehr Teilnehmern berichtet wurden

82/134 61%

58/93 62%

107/169 63%

Probleme, die von 4 oder mehr Teilnehmern berichtet wurden

48/134 36%

32/93 34%

65/169 38%

Tab. 1. Anzahl der von mehreren Teilnehmern berichteten Probleme

CUE-9a

CUE-9b

Combined

Anzahl Prüfer

Anzahl aller Befunde

860

473

1,333

Anzahl Befunde nach Kombination ähnlicher Befunde

182

109

222

Anzahl positiver Befunde

Anzahl negativer Befunde (Probleme)

134

169

Tab. 2. Anzahl Befunde

3.1.1. Wahrnehmung der Teilnehmer In Atlanta gaben 13 von 19 Teilnehmern an, kritische und ernste Probleme übersehen zu haben, die von anderen Teilnehmern in ihren Gruppen erkannt wurden. Dass die Mehrzahl der Teilnehmer einen Evaluator Effect wahrgenommen hatten, wurde in der Plenumsdiskussion klar ersichtlich. So sagte ein Teilnehmer: „Ich kam in diesen [Workshop] und dachte, es müsste mehr Übereinstimmung geben als es tatsächlich gab. (…)“ Ein anderer Teilnehmer drückte es so aus: „Ich finde, es gibt so viele Ermessensentscheidungen – ob etwas wirklich ein Problem ist, ob es kritisch ist … Es gibt hunderte solcher Entscheidungen.“ 3.1.2. Anzahl der Probleme Nach der Kombination einzelner Beobachtungen zu gemeinsamen Usability Erkenntnissen wurden auf der Webseite von U-Haul

169 Probleme berichtet. Die Webseite von U-Haul ist keineswegs besonders komplex, es kann also angenommen werden, dass diese Anzahl nicht untypisch hoch ist. Der Evaluator Effect kann auch auf diese große Anzahl von Einzelproblemen zurückgeführt werden. [Tab. 2] Bei der Kombination einzelner Beobachtungen zu gemeinsamen Usability Erkenntnissen hat es sich darüber hinaus als wichtig herausgestellt, die Beobachtungen sorgfältig zu formulieren. Einige Befunde beschrieben beispielsweise nur, was beobachtet wurde, erklärten aber nicht, warum ein Usability-Problem vorliegt, beispielsweise „participant is searching the faq“. Andere waren ohne Kontext oder weitere Erläuterung durch den Teilnehmer gar nicht verständlich. Ein Beispiel hierfür ist folgender Befund: „to less notice about miles on the top of the page in step2 after ‚get rates‘ miles=city to city?“. Insgesamt waren immerhin 55

343

Rating

Devastating problem

Code

Description

The problem has life-threatening or disabling consequences for users or other human beings The problem could cause severe financial damages to users, the owner of the website or other persons

Critical problem

The problem causes frequent catastrophes. A catastrophe is a situation where The website „wins“ over the user – that is, a situation where users cannot solve a reasonable task The website annoys users considerably Users obtain an inappropriate solution to the task

Serious problem

Delays users in their use of the website for some minutes, but eventually allows them to continue The task solution is sub-optimal and would not be accepted by users if they were informed of the „correct“ solution The problem causes occasional „catastrophes“

Minor problem

Causes users to hesitate for some seconds The task solution obtained is sub-optimal but acceptable

Positive finding

This approach is recommendable and should be preserved

Tab. 3. Bewertungsskala aus Atlanta (CUE-9a)

Rating

Code

Description

Critical problem

Causes frequent catastrophes. A catastrophe is a situation where the website „wins“ over the test participant – that is, a situation where the test participant cannot solve a reasonable task or where the website annoys the test participant considerably.

Serious problem

Delays test participants in their use of the website for some minutes, but eventually allows them to continue. Causes occasional „catastrophes“.

Minor problem

Causes test participants to hesitate for some seconds.

Good idea

A suggestion from a test participant that could lead to a significant improvement of the user experience.

Positive finding

This approach is recommendable and should be preserved.

Bug

The website works in a way that’s clearly not in accordance with the design specification. This includes spelling errors, dead links, scripting errors, etc.

Tab. 4. Skala aus Chemnitz – CUE9b).

von 1.333 Beobachtungen zu unklar, um verstanden und einem Problem zugeordnet werden zu können. 3.1.3. Gründe für den Evaluator Effect Als Grund für den Evaluator Effect nannten einige Teilnehmer, dass das Ziel der Evaluierung unklar gewesen sei. Es war beispielsweise unklar, wie die Verkaufsabsichten der Webseite abgewogen gegen das Interesse der Nutzer werden sollten.

344

Ein Beispiel dafür waren die vorselektierten Artikel im Warenkorb: Mindestens ein Teilnehmer wollte eine reine Nutzerperspektive einnehmen und war daher gegen vorselektierte Waren; andere argumentierten, dass das Ziel einer guten Evaluierung vom Kunden bestimmt werden sollte. Ein anderer Grund für den Effekt war die Uneinigkeit darüber, in welchem Ausmaß berichtete Usability Probleme am Video des Usability Tests belegbar sein sollten. Einige Teilnehmer berichteten ein Problem

nur dann, wenn die Videos dafür Belege boten, also wenn die Benutzer sich direkt beschwerten; andere berichteten auch Punkte, die sie für problematisch hielten, egal ob die Videos dafür direkte Beweise enthielten. Sie kombinierten also die Usability Evaluierung mit einer primitiven Expertenevaluierung. Ein dritter Grund war Unsicherheit über die richtige Lösung zu Testaufgaben. Ohne Ortskenntnisse war es beispielsweise schwierig, die Antwort zu einer Aufgabe

Usability Professionals 2013 Usability/UX Texting

zu kennen, bei der die nächstgelegene U-Haul-Station in der Nähe einer Adresse in der kalifornischen Stadt Fremont gefunden werden sollte. Das erschwerte es, zu bewerten wann ein Usability Problem auftrat. 3.2. Bewertungsskalen Nur etwa die Hälfte der Teilnehmer in Atlanta gab an, bei ihrer Arbeit als Usability Experten eine formale Bewertung des Schweregrads von Usability Problemen vorzunehmen. Der Rest der Teilnehmer unterscheidet lediglich zwischen den wichtigsten Problemen und dem Rest. Viele Teilnehmer berichteten, dass ihnen die Bewertung ihrer Erkenntnisse schwer gefallen sei und dass die Bewertungsskalen schwer zu benutzen gewesen seien (Tabelle 3 Skala aus Atlanta – CUE9a; [Tab. 3] Tabelle 4. Bewertungsskala aus Chemnitz (CUE-9b). Diese Bewertungsskala wurde erstellt weil die Ergebnisse aus Atlanta grosse Unterschiede bei den Bewertungen gleicher Probleme zeigten. Die Hypothese war dass es einfach sein würde eine bessere Bewertungsskala zu konstruieren. Diese Hypothese erwies sich als falsch. [Tab. 4] Ein wichtiger Grund für diese Schwierigkeiten war dass der Bewertungsprozess verschiedene voneinander abhängige Aspekte beinhaltete, beispielsweise die Anzahl der Nutzer, die das Problem betraf, ob Nutzer in ihrer Arbeit aufgehalten wurden, ob sie frustriert wurden, ob das Problem einfach zu beheben sei, und ob ein Problem für einen realen Anwender schwerwiegende Probleme verursachen würde, auch wenn es für Testnutzer nur eine kleinere Schwierigkeit darstellte. Tabelle 5 zeigt einige der Inkonsistenzen in Atlanta (CUE-9a). Beispielsweise wurden 28% der Probleme von einigen Teilnehmern mit AA („devastating“, zu deutsch etwa: katastrophal) oder A („critical“, kritisch) und von anderen mit C („Minor“, zu deutsch gering) bewertet. 25% der Probleme wurden sogar von zwei oder mehr Teilnehmern

CUE-9a

CUE-9b

Combined

Net problem findings

134

169

At least one AA or A, and at least one C

23/82 28%

30/58 52%

42/107 39%

At least two AA or A, and at least two C

12/48 25%

7/32 22%

23/65 35%

Tab. 5. Bewertungsskala aus Atlanta (CUE-9a)

Abb. 1. Bewertung des Problems „Auswahl der richtigen LKW-Größe“

als AA oder A und von zwei oder mehr anderen Teilnehmern als C eingestuft. Tabelle 5 zeigt, dass die Änderungen an der Skala von Atlanta zu Chemnitz die Bewertungen nicht konsistenter werden ließ. In Chemnitz (CUE-9b) wurden sogar 52% der Probleme von einigen Teilnehmern als AA oder A und von anderen als C bewertet, und immerhin noch 22% wurden von zwei oder mehr Teilnehmern als AA oder A und von zwei oder mehr anderen Teilnehmern als C eingestuft [Tab. 5] Ein Beispiel für ein inkonsistent bewertetes Problem war die Auswahl der richtigen LKW-Größe für den Umzug. Die Beschreibung eines LKWs auf der Webseite enthielt den Hinweis, dieser sei für ein „3-Room

Apartement“ geeignet. Einigen Nutzern erschien es nützlicher, die Anzahl aller Räume in der Wohnung anzugeben. Dieses Problem zeigt eine erhebliche Streuung in der Bewertung, zweimal wurde es sogar als „devastating“, also AA, bewertet. [Abb. 1] Die neue Skala führte also zu genauso schlechten Ergebnissen wie die erste. Darüber hinaus wurde mit der Kategorie AA ein neues Problem eingeführt. Einige Teilnehmer tendierten dazu, die höchste Bewertungsstufe für diejenigen Probleme zu wählen, die ihrer Meinung nach behoben werden sollten, unabhängig von der dramatischen Beschreibung der Kategorie („lebensbedrohend“ oder „ruinierend“).

345

4. Empfehlungen für die Praxis

3. Usability Probleme sollten mit besonderer Sorgfalt formuliert werden

Diese Studie ist für Usability Spezialisten im Arbeitsalltag in mehreren Punkten relevant. Wir geben folgende Empfehlungen für die Praxis:

Bei der Überarbeitung eines Systems werden Usability Probleme oft einzeln und ohne den bei der Formulierung vorhandenen Kontext betrachtet. Die Probleme waren so teils nur noch schwer oder nicht verständlich. Die Diskussion ergab, dass Usability Experten bei der Formulierung von Usability Problemen besonders darauf achten sollten, dass aus der Formulierung des einzelnen Problems klar erkennbar ist, was das Problem ist und wie es sich auf den Nutzer auswirkt.

1. Die Bewertung des Schweregrad von Usability Problemen sollte in einer Gruppe stattfinden

Eine Konsolidierung der SchweregradBewertungen in der Gruppe reduziert mit einiger Wahrscheinlichkeit die Anzahl hoch bewerteter Probleme und fokussiert so die folgende Überarbeitung eines Systems. Die gemeinsame Evaluierung in der Gruppe wurde von den Teilnehmern als eine Methode genannt, den Evaluator Effect einzugrenzen. Ein Teilnehmer fand dass „es gut ist, sich gegenseitig in einem Review-Prozess herauszufordern“ und gab an, dass die Gruppenevaluierung zu konsistenteren Ergebnissen führe. In Atlanta gaben fünf Teilnehmer an, in ihrer täglichen Arbeit als Usability Experten regelmäßig zwei Evaluatoren nutzten um Usability Tests zu bewerten; die meisten anderen der Teilnehmer fanden diese Arbeitsweise zu kostspielig. 2. Die heutigen Bewertungsskalen sind nicht verlässlich

Die Ergebnisse der Studie zeigen, dass die heutigen Bewertungsskalen für UsabilityProbleme nicht verlässlich sind. Verschiedene erfahrene Prüfer kommen zu sehr unterschiedlichen Bewertungen für die selben Probleme. Die Studie hat außerdem – unfreiwillig – gezeigt, dass es nicht einfach ist, Bewertungsskalen zu verbessern. Der Versuch, dies in CUE-9b zu tun, scheiterte. In CUE-9b haben mindestens 7 von 16 Teilnehmern ihre Befunde kritischer bewertet als nötig und die schwerwiegendste Kategorie missbraucht. Bessere Bewertungsskalen werden benötigt – natürlich müssen diese weiterhin gebrauchstauglich bleiben.

346

weniger als 20% der Probleme gefunden. Die Ergebnisse der Teilnehmer sind natürlich trotzdem wertvoll, aber sie zeigen dass man niemals behaupten sollte alle oder auch nur eine Mehrzahl der Usability Probleme gefunden zu haben. Literatur 1. Rolf Molich, Webseite zu den CUE-Studien, http://dialogdesign.dk/CUE.html 2. Rolf Molich, Meghan R. Ede, Klaus Kaasgaard, and Barbara Karyukin, „Comparative Usability Evaluation“, Behaviour & Information Technology, vol. 23, no. 1, January/ February 2004, pp. 65–74. 3. Joseph S. Dumas, Rolf Molich, and Robin

4. Personen mit Domänenwissen oder Ortskenntnissen sollten zur Verfügung stehen

Jeffries, „Describing Usability Problems – Are We Sending the Right Message“, Interactions, July/August 2004, pp. 24–29 4. Molich and Joseph S. Dumas, „Comparative

Um bei der Bewertung von Benutzeraktionen Unsicherheiten zu vermeiden, sollte das Testkonzept mit Personen mit Orts- bzw. Domänenwissen abgestimmt werden und diese sollten dem Usability Spezialisten während der Auswertung als Ansprechpartner zur Verfügung stehen. Orts- und Domänenwissen kann beispielsweise notwendig werden, um korrekt zu bewerten, ob im Test eine Aufgaben richtig gelöst wurde.

Usability Evaluation (CUE-4)“, Behaviour & Information Technology, Vol. 27, issue 3, 2008. 5. Rolf Molich, Robin Jeffries, and Joseph S. Dumas, „Making Usability Recommendations Useful and Usable“, Journal of Usability Studies, vol. 2, no. 4, August 2007. 6. Morten Hertzum, Niels Ebbe Jacobsen & Rolf Molich (2013): What You Get Is What You See: Revisiting the Evaluator Effect in Usability Tests, Accepted for publication in Behaviour & Information Technology, DOI:10

5. Usability Tests sind auch mit all ihren Schwierigkeiten sehr nützlich

Ein Teilnehmer, der die Existenz eines Evaluator Effects akzeptierte, betonte, dass der Evaluator Effect den Wert der Usability Evaluation nicht untergraben würde: „Wir [als Evaluatoren] sind unterschiedlich. Es gibt kein endgültiges Ergebnis aber wir bieten alle eine gute Dienstleistung [für unsere Kunden].“ 6. Die Anzahl von Usability Problemen in scheinbar unkomplizierten Websiten kann hoch sein

Unsere 35 Teilnehmer haben auf der Website von U-Haul insgesamt knapp 170 Probleme gefunden. Kein Teilnehmer hat mehr als die Hälfte dieser Probleme gefunden. Die meisten Teilnehmer haben

.1080/0144929X.2013.783114

Usability Professionals 2013 Usability/UX Texting

347

User Experience Questionnaire Benchmark Praxiserfahrungen zum Einsatz im Business-Umfeld Martin Schrepp SAP AG – User Experience Dietmar-Hopp-Allee 16 69190 Walldorf martin.schrepp@sap.com

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

Ulf Schubert DATEV eG Fürther Straße 212 90429 Nürnberg ulf.schubert@datev.de

Abstract Der User Experience Questionnaire (UEQ) ist ein etablierter Fragebogen zur Messung des Benutzererlebens interaktiver Produkte. Der Fragebogen misst User Experience auf den Dimensionen Effizienz, Durchschaubarkeit, Steuerbarkeit, Stimulation, Originalität sowie Attraktivität. Eine häufig gestellte Frage ist Wie gut hat das von mir evaluierte Produkt im Vergleich zu anderen Produkten abgeschnitten? Um diese Frage beantworten zu können, wurden 163 Studien mit dem UEQ in einem Benchmark zusammengefasst. Dies erlaubt eine detaillierte Aussage zur Qualität eines Produkts im Vergleich mit anderen Produkten. Zusätzlich werden Erkenntnisse zum Einsatz des UEQ-Benchmarks im Rahmen von größeren UEQ-Datenerhebungen sowie Praxiserfahrungen im Business Umfeld vorgestellt. Dabei gehen wir auf folgende Punkte ein: Unterschiede in der Bewertung durch unterschiedliche Nutzergruppen, Relevanz der UEQ-Faktoren für unterschiedliche Nutzergruppen, Bedeutung der UEQ-Faktoren für die Gesamtzufriedenheit.

1. Einleitung User Experience ist ein multidimensionales Konstrukt, das alle Qualitätsmerkmale zusammenfasst, die für die subjektive Bewertung eines Produkts durch seine Nutzer eine Rolle spielen. Dazu zählen natürlich die klassischen Usability-Aspekte, wie z.B. Effizienz, Effektivität, Fehlertoleranz, oder Erlernbarkeit. Aber auch nicht direkt an der Bearbeitung von Aufgaben mit dem Produkt orientierte Aspekte, wie z.B. Emotionen des Nutzers (Norman, 2003), Originalität, Stimulation oder ästhetisches Design (z.B. Tractinsky, 1997) spielen hier eine Rolle. Die wahrgenommene User Experience ist eine rein subjektive Einschätzung eines Produkts durch seine Nutzer. Zur Messung dieser Produkteigenschaft bieten sich daher Fragebögen als einfache und kostengünstige Methode an. Im deutschsprachigen Raum sind hier die Fragebögen UEQ – User Experience Questionnaire (Laugwitz, Schrepp & Held, 2006) und AttrakDiff (Hassenzahl, Burmester & Koller, 2003) verbreitet.

348

Ziel des UEQ ist eine effiziente Messung des Gesamteindrucks, den ein Benutzer in Bezug auf die Interaktion mit einem Produkt entwickelt hat. Der UEQ besteht aus 26 bipolaren Items, die die Form eines 7-stufigen semantischen Differentials haben, z.B.: kompliziert

einfach

leicht zu lernen

attraktiv

unattraktiv

schwer zu lernen

Die Items sind den folgenden sechs Ska len zugeordnet: Durchschaubarkeit, Effi zienz, Steuerbarkeit, Stimulation, Originalität (jeweils 4 Items) sowie Attraktivität (6 Items). Die Skalen Durchschaubarkeit, Effizienz, und Steuerbarkeit beschreiben aufgabenbezogene (pragmatische) Qualitätsmerkmale eines Produkts. Die Skalen Stimulation und Originalität beschreiben nicht aufgabenbezogene (hedonische) Qualitätsmerkmale (für die Unterscheidung in pragmatische vs. hedonische Qualitäts merkmale siehe Hassenzahl, 2001). Die Skala Attraktivität ist eine reine Valenzdimension. [Abb. 1]

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

Die Konstruktion und Validierung des Fragebogens sind in Laugwitz, Schrepp & Held (2006) und Laugwitz, Held & Schrepp (2008) beschrieben. Zusätzlich zur deutschen Originalversion des UEQ sind auch Versionen in englischer, spanischer (Rauschenberger et al., 2013), französischer und italienischer Sprache verfügbar. In Deutsch steht zusätzlich noch eine spezielle Version für den Einsatz bei jugendlichen Benutzern zur Verfügung (Hinderks et. al, 2012). Der Fragebogen selbst, ein Auswertungstool und die Sprachversionen stehen unter www.ueq-online.org kostenlos zur Verfügung. 2. Warum ein Benchmark? Der UEQ liefert als Ergebnis die gemessene User Experience auf den 6 Skalen Effizienz, Durchschaubarkeit, Steuerbarkeit, Stimulation, Originalität und Attraktivität. Abbildung 2 zeigt Ergebnisse für ein hypothetisches Produkt. [Abb. 2]

Usability Professionals 2013 Usability/UX Texting

Ein Gesamtwert für die User Experience im Sinne einer einzigen KPI ist aufgrund der faktorenanalytischen Konstruktion des Fragebogens nicht sinnvoll, da die Werte auf den einzelnen Dimensionen nicht direkt miteinander in Beziehung gesetzt werden können. Hierzu wären Informationen über die subjektive Wichtigkeit der einzelnen Dimensionen für das Gesamturteil notwendig, die in dieser Form nicht verfügbar sind. Eine naheliegende Frage, die nach Auswertung des UEQ oft gestellt wird, lautet Wie gut ist denn mein Produkt jetzt eigentlich? Hier ist insbesondere auch der Aspekt interessant, wie gut die Ergebnisse im Vergleich zu anderen Produkten sind. Bisher konnte diese Frage nicht zufriedenstellend beantwortet werden. Man musste sich hier mit groben heuristischen Aussagen begnügen, die auch im Analyse-Tool visualisiert wurden. Werte zwischen -0.8 und 0.8 entsprechen einer neutralen Beurteilung, Werte > 0,8 einer positiven Beurteilung und Werte < -0,8 einer negativen Beurteilung.

Abb. 1. Skalenstruktur des User Experience Questionnaire (UEQ).

Der vorgestellte Benchmark soll Anwendern des UEQ eine bessere Einschätzung erlauben, wo das von ihnen evaluierte Produkt bzgl. seiner User Experience wirklich steht. 3. UEQ Benchmark Für den Benchmark wurden Daten aus 163 UEQ-Studien mit insgesamt 4818 Teilnehmern analysiert. Bewertet wurden hierbei Produkte unterschiedlicher Kategorien, z.B. betriebswirtschaftliche Anwendungen, Web-Seiten, Web-Shops, Soziale Netzwerke, etc. Die Anzahl der Teilnehmer pro Untersuchung variierte dabei stark. Es gibt sehr kleine Stichproben (3) bis hin zu riesigen Stichproben (722). Da sich die Ergebnisse nicht wesentlich ändern, wenn man die kleinen Stichproben (<11 Teilnehmer) aus dem Datensatz eliminiert, wurden diese im Benchmark belassen. Im Mittel waren etwa 30 Teilnehmer an einer Untersuchung beteiligt. [Abb. 3]

Abb. 2. Analyse-Ergebnis eines hypothetischen Produkts (aus dem UEQ Analyse-Tool).

Abb. 3. Verteilung der Teilnehmerzahlen.

349

Die folgende Abbildung 4 zeigt die Verteilung der Skalenmittelwerte der einzelnen Skalen im Benchmark- Datensatz als Density-Plots. [Abb. 4]

4. Praktische Anwendung am Beispiel DATEV eG

– Unterdurchschnittlich: 50% der Resultate waren besser als das Ergebnis des Produkts, 25% waren schlechter. – Schlecht: Im Bereich der 25% schlechtesten Resultate.

Es wurde entschieden im Benchmark pro Skala eine grobe Rückmeldung im Rahmen von 5 Kategorien zu geben: – Exzellent: Im Bereich der 10% besten Resultate. – Gut: 10% der Resultate waren besser als das Ergebnis des Produkts, 75% waren schlechter. – Überdurchschnittlich: 25% der Resultate waren besser als das Ergebnis des Produkts, 50% waren schlechter.

Der UEQ als internes Benchmark Instrument

Die folgende Tabelle zeigt den Zusammenhang dieser Kategorien mit den beobachteten Skalenmittelwerten. [Tab. 1] Die entsprechenden Intervalle werden auch im Excel-Auswertungstool zum UEQ zur Verfügung gestellt, d.h. direkt mit den anderen Kennzahlen aus den Daten berechnet.

Die DATEV eG verwendet seit mehreren Jahren zur einfachen und schnellen Überprüfung der User Experience neuer Programmversionen den UEQ mit einigen Anpassungen, wie z.B. Einzelfragen nach der Aktualität, der Gesamtzufriedenheit und der Performance.

Abb. 5. Verteilung der Skalenmittelwerte (KernelDensity Plots).

Attraktivität

Effizienz

Durchschaubarkeit

Steuerbarkeit

Stimulation

Originalität

≥ 1,72

≥ 1,64

≥ 1,82

≥ 1,6

≥ 1,5

≥ 1,34

Gut

≥ 1,5 < 1,72

≥ 1,31 < 1,64

≥ 1,37 < 1,82

≥ 1,4 < 1,6

≥ 1,31 < 1,5

≥ 0,96 < 1,34

Überdurchschnittlich

≥ 1,09 < 1,5

≥ 0,84 < 1,31

≥ 0,9 < 1,37

≥ 1,06 < 1,4

≥ 1,0 < 1,31

≥ 0,63 < 0,96

Unterdurchschnittlich

≥ 0,65 < 1,09

≥ 0,5 < 0,84

≥ 0,53 < 0,9

≥ 0,7 < 1,06

≥ 0,52 < 1,0

≥ 0,24 < 0,63

< 0,65

< 0,5

< 0,53

< 0,7

<0, 52

< 0,24

Exzellent

Tab. 1. Benchmark-Intervalle pro Skala.

350

Schlecht

Usability Professionals 2013 Usability/UX Texting

Da es mehrere Hauptanwendungen und gut abgrenzbare Nebenprogramme gibt, liegt inzwischen ein großer Datensatz vor. Durch den mehrjährigen Einsatz ist es inzwischen möglich, die Programmqualität verschiedener zusammengehöriger Anwendungen untereinander und über einen Zeitverlauf von drei Jahren zu betrachten. Ziel des Einsatzes des UEQ ist es, schnell und effizient eine Einschätzung über die User Experience zu erhalten, die durch die Produkte vermittelt wird. Da eine möglichst positive User Experience zu den Zielen der DATEV gehört, werden die Ergebnisse aus den UEQ-Studien zur Steuerung von Produktgestaltungsentscheidungen verwendet. Hierbei stellt sich natürlich sehr häufig die eingangs erwähnte Frage: Wie gut hat das von mir evaluierte Produkt im Vergleich zu anderen Produkten abgeschnitten? In der Vergangenheit wurde zur Beantwortung dieser Frage ein interner Benchmark eingeführt. Bei diesem werden Werte aus den aktuellen systematischen UEQ-Bewertungen von unterschiedlichen Produkten zusammengefasst. Der zusammengefasste Mittelwert dient als Vergleichswert für die Einzelbewertung von Produkten und ermöglicht die Verlaufskontrolle für eine ausgewählte Produktfamilie. Der interne DATEV UEQ-Benchmark wird dazu in die Auswertungsgrafiken der Produkte aufgenommen und bei der Interpretation von IST-Situation und der Empfehlung von Handlungsmaßnahmen mit einbezogen. Zur Steigerung und Steuerung der UXAktivitäten genügt es aber nicht nur die Frage nach der IST-Situation zu beantworten. Zur nutzbringenden Verwendung der UEQ-Erkenntnisse bedarf es einer realistischen Zielvorgabe an die Entwicklungsabteilungen. Die UEQ-Profile der Produkte weisen für eine Produktfamilie in der Regel ein charakteristisches Profil auf, bei dem die UEQ-Faktoren unterschiedliche Minimal- und Maximalwerte erreichen. Dies muss bei der Festlegung von realistischen Zielvorgaben berücksichtigt werden.

Abb. 5. Fiktive Werte zur Darstellung der Zielvorgaben, die individuell für jeden UEQ-Faktor erstellt werden.

Zielvorgaben wie z.B. Alle Werte sollen mindestens 2,2 erreichen sind unserer Einschätzung nach nicht zielführend. Zum einen können theoretische Maximalwerte, aufgrund des charakteristischen Bildes, nicht bei allen UEQ-Faktoren in gleicher Weise erreicht werden und zum anderen liegt wahrscheinlich auch der theoretisch erreichbare Maximalwert bei komplexen Business-Anwendungen, die von unterschiedlichen Nutzern verwendet und bewertet werden, etwas niedriger als bei einfacheren Anwendungen. Bei der Vorgabe eines Ziels ist es wichtig, dass sowohl Management als auch die Entwicklungsabteilungen das Gefühl haben, die angestrebten Werte erreichen zu können. Aus diesem Grund leiten wir die Zielsetzung auf Basis des aktuellen DATEVBenchmarks ab und vereinbaren diese im Top Management. Die Vorgabe wird dabei so gewählt, dass im Durchschnitt bei allen Anwendern des Produktes eine positive User Experience erreicht wird. Die folgende Abbildung zeigt eine fiktive Benchmarklinie und die dazu ermittelte Zielvorgabe. [Abb. 5] Zusätzlich zum internen DATEV UEQBenchmark setzen wir auch den in diesem Papier vorgestellten UEQ-Benchmark ein.

Hierbei geht es uns jedoch weniger um die Frage, wie gut ein einzelnes Produkt im Vergleich zum UEQ-Benchmark abgeschnitten hat. Da in der Regel mehrere DATEV Produkte gleichzeitig bzw. in Zusammenhang von den Anwendern eingesetzt werden, ist für uns die Bewertung des Gesamterlebnisses von großer Bedeutung. Daher vergleichen wir den internen DATEV UEQ-Benchmark mit den Werten für Business-Software aus dem Gesamt-Benchmark. Dieser Vergleich liefert wertvolle Erkenntnisse zur gesamten IST-Situation sowie zu den zentralen Handlungsbedarfen für alle Produkte. Es ist anzumerken, dass bei diesem Vergleich einige Einschränkungen zu beachten sind. Bei den Daten des UEQ-Benchmark ist zwar ersichtlich, ob es sich um ein Produkt, einen Prototyp oder einen bestimmten Softwaretyp handelt. Es ist wird jedoch nicht deutlich, ob die Produkte des UEQ-Benchmarks und damit auch deren Bewertungen mit dem zu bewertenden Produkt hinsichtlich Anwenderschaft, Nutzungshäufigkeit und Nutzungskontext im Detail vergleichbar ist. Wir gehen zwar davon aus, dass bei einer gewissen Stichprobengröße die Daten des UEQ von hoher Qualität sind, aber wir müssen uns im Moment mit dem Etikett „Betriebswirtschaftliche Software“ begnügen.

351

Nutzergruppe

Wichtigster UEQ-Faktor

Zweitwichtigster UEQ-Faktor

Drittwichtigster UEQ-Faktor

Professionelle Beta-Tester

Steuerbarkeit

Durchschaubarkeit

Attraktivität

Normale Endanwender

Attraktivität

Steuerbarkeit (kürzere Verwendungszeit) Durchschaubarkeit (längere Verwendungszeit)

Effizienz

Tab. 2. Wertigkeit der UEQ-Faktoren bei der Vorhersage der Gesamtzufriedenheit ermittelt durch Regressionsberechnungen

Praxiserfahrungen bei der Durch führung Auswertung und Interpretation von UEQ-Bewertungen Neben dem Einsatz von Benchmark-Ver gleichen haben wir bei der Auswertung und Interpretation von UEQ-Bewertungen Praxiserfahrungen gesammelt, von denen einige an dieser Stelle beschrieben werden sollen. Wie ist die Akzeptanz des UEQ bei den Anwendern?

Die Akzeptanz bei den DATEV-Nutzern ist sehr hoch, bei ca. tausend Umfragen kommt es im Schnitt zu ein oder zwei direkten Rückmeldungen von Anwendern, die den Sinn und Zweck des Fragebogens anzweifeln. Die durchschnittliche OnlineBeantwortungszeit eines DATEV-UEQ (mit Ergänzungen wie Fragen zur Person, zur Nutzung der Software, zur Gesamtzufriedenheit und Performance) ist 7,5 Minuten. Wie läßt sich die Akzeptanz des UEQ innerhalb Entwicklungsabteilung erhöhen?

Der UEQ ist extrem schnell und kostengünstig einsetzbar. Öfter eingesetzt bieten die Verlaufsergebnisse eine gute Kontrolle über die subjektiv erlebte User Experience der Software. Für das DATEV-Management ist vor allem das Berichts-Summary und das ein- bis zweiseitige Faktenblatt der Einzelanwendung wichtig. In letzterem werden die wichtigsten Punkte stichpunktartig aufgelistet und es wird eine Handlungsempfehlung für das weitere Vorgehen ausgesprochen. Um die Akzeptanz

352

des UEQ zu erhöhen, empfiehlt es sich die originalen UEQ-Faktor-Benennungen dem Firmensprachgebrauch anzupassen. Bei DATEV heißt Durchschaubarkeit dann z.B. Verständlichkeit.

Phase des Softwareeinsatzes. Dies ist – im Nachhinein betrachtet – nicht überraschend. Überraschend hingegen ist die hohe Gewichtung des Faktors Attraktivität bei Business-Anwendungen.

Unterscheiden sich die Bewertungen von Beta-Testern und normalen Endanwendern?

Da bei DATEV UEQ-Studien mit einer zusätzlichen Einzelfrage die Gesamtzufriedenheit mit der Anwendung erhoben wird, kann mittels Regressionsberechnungen die Wertigkeit der einzelnen UEQ-Faktoren für Beta-Tester und Endanwender ermittelt werden. Die folgende Tabelle zeigt die Wertigkeit der UEQ-Faktoren für die Vorhersage des Wertes Gesamtzufriedenheit bei unterschiedlichen Benutzergruppen und unterschiedlichen Zeiten.

Im Rahmen der Softwareentwicklung setzen viele Unternehmen Beta-Tests ein, um eine hohe Qualität des Produktes zu gewährleisten. Es liegt nahe bei BetaTests nicht nur technische und fachliche, sondern auch ergonomische bzw. gestalterische Aspekte zu bewerten, da es sich hierbei in der Regel um ein nahezu fertiges Produkt handelt. Bei der Bewertung der User Experience stellt sich jedoch die Frage, ob Beta-Tester und Endanwender ein Produkt vergleichbar bewerten. Dazu konnten wir innerhalb von zwei größeren UEQ-Studien die Bewertungen dieser beiden Gruppen vergleichen. Beide Studien zeigten, bis auf eine Skala, signifikante Unterschiede zwischen Gruppen. Dabei gaben die Beta-Tester im Mittel immer bessere Bewertungen ab, als die zufällig ausgewählten Endanwender. Die Unterschiede zwischen den beiden Gruppen betrugen zwischen 0,35 (Faktor Stimulation) und 0,88 (Faktor Attraktivität) für die einzelnen UEQ-Faktoren. Ist die Relevanz der UEQ-Faktoren für Beta-Tester und Endanwender gleich?

Die Relevanz von UEQ-Faktoren ist abhängig von der Nutzergruppe und von der

Bei der Regressionsberechnung wurde die Variable Gesamtzufriedenheit vorhergesagt und es wurde geprüft welche der UEQ-Faktoren bei unterschiedlichen Dateneingabemodellen noch eine signifikante Erhöhung der Vorhersagequalität erbringen. Nichtaufgelistete UEQ-Faktoren erbringen bei Eingabe in die Regressionsgleichung keinen signifikanten Mehrwert an Vorhersagequalität für die Gesamtzufriedenheit. Dies bedeutet jedoch nicht, dass die anderen UEQ-Faktoren unbedeutend sind. Wir gehen davon aus, dass die anderen UEQ-Faktoren Hygienefaktoren sind, die zwar im Rechenmodell die Gesamtzufriedenheit nicht steigern können, aber bei schlechter Bewertung gegebenenfalls senken können. [Tab. 2] Zusammenfassend lässt sich sagen, dass die Faktoren Attraktivität, Verständlichkeit und Effizienz in einem normalen Setting

Usability Professionals 2013 Usability/UX Texting

für die Gesamtzufriedenheit eines Nutzers in dem Rechenmodell von größerer Bedeutung sind, als die anderen Faktoren. Betrachtet man die Zahlen, hebt sich der Faktor Attraktivität hierbei von den anderen Faktoren teilweise deutlich ab. Praktisch bedeutet dies, dass man durch eine Erhöhung der Attraktivität und der anderen wichtigen Faktoren gezielt die Gesamtzufriedenheit mit dem Produkt durchaus beeinflussen kann. Hat die Performance einer Software Einfluss auf die UEQ-Bewertungen?

Neben der Gesamtzufriedenheit wird im DATEV-UEQ auch nach der subjektiven Bewertung der Performance gefragt (schnell vs. langsam). Einzelregressionen, in denen die Werte der UEQ-Faktoren mit Hilfe der IST-Performance vorhergesagt wurden ergaben, dass nur zwischen dem UEQ-Faktor Effizienz und der IST-Performance ein mäßiger bis mittlerer Zusammenhang besteht (korrigierte R2 = 50, N = 107). Sicherlich zeigt hier das UEQ-Item schnell – langsam eine Wirkung. Macht es Sinn, UEQ-Werte bei UsabilityTests mit Prototypen zu erheben?

Diese Frage lässt sich mit einem klaren „Ja“ beantworten. Die Durchführung eines UEQ-Fragebogens dauert nur wenige Minuten. Wir legen – soweit möglich – bei jedem Prototypentest in einem Benutzerlabor den UEQ vor. In der Regel funktioniert der UEQ auch hier relativ gut, da mindestens 10 Einzelbewertungen vorliegen. Einige der Faktoren, wie z.B. Durchschaubarkeit, sind sehr gut interpretierbar, andere wie z.B. Stimulation etwas weniger.

Die UEQ-Analysen für Prototypen werden geschätzt, da sie innerhalb der Prototypen gut differenzieren. Eine sehr gute UEQ-Bewertung stimmt oft mit der verbal geäußerten Begehrlichkeit nach der neuen Software überein. Ergänzend zum UEQProfil wird i.d.R. trotz der geringen Anzahl der Teilnehmer ein Boxplot zur Darstellung der Quartilsverteilung der Werte erstellt.

Literatur 1. Hassenzahl (2001): The effect of perceived hedonic quality on product appealingness. International Journal of Human-Computer Interaction, 13, S. 479–497. 2. Hassenzahl, M., Burmester, M. & Koller, F. (2003). AttrakDiff: Ein Fragebogen zur Messung wahrgenommener hedonischer und pragmatischer Qualität. In: Ziegler, J., Szwillus, G. (Hrsg.) Mensch & Computer

Es ist verständlich, dass es schwierig ist, die Werte in der fertig entwickelten Software auf hohem Niveau zu halten. Aber auch hier ist es so, dass ein sehr gut bewerteter Prototyp bei guter Umsetzung als Anwendung oder Anwendungsteil später höhere UEQ-Werte erzielt als ein niedrig bewerteter Prototyp. Der UEQ ermöglicht somit – in Verbindung mit anderen Methoden – eine gute Prognose.

2003: Interaktion in Bewegung, S. 187—196. Teubner, Stuttgart. 3. Hinderks, A.; Schrepp, M.; Rauschenberger, M.; Olschner, S.; Thomaschewski, J. (2012). Konstruktion eines Fragebogens für jugendliche Personen zur Messung der User Experience. In: Brau, H.; Lehmann, A.; Petrovic, K.; Schroeder, M. (Hrsg.); Usability Professionals 2012, S. 78–83. 4. Laugwitz, B.; Schrepp, M. & Held, T. (2006). Konstruktion eines Fragebogens zur Mes-

Ist der UEQ sensibel bezüglich Änderungen in den Produkten?

sung der User Experience von Softwareprodukten. In: A.M. Heinecke & H. Paul (Hrsg.): Mensch & Computer 2006 – Mensch und

Da wir für einige DATEV-Anwendungen schon mehrere UEQ-Erhebungen mit ähnlichen Stichproben vorliegen haben, können wir im Zeitverlauf sehen, wie sich bestimmte Produktweiterentwicklungen in den UEQ-Zahlen bemerkbar machen. Beispiele hierfür sind z.B. die Erhöhung des Faktors Originalität nach Verbesserungen bezüglich schnellerer Dateneingabe oder die Verringerung des Faktors Durchschaubarkeit nach Erhöhung der Funktionsvielfalt im zentralen Dialogabschnitt. Sicherlich muss man bei Interpretationen vorsichtig sein. Eine gute Hilfe in diesem Zusammenhang sind die Freitextantworten der Beurteiler, die im UEQ-Fragebogen der DATEV miterhoben werden.

Computer im Strukturwandel, S. 125–134. Oldenbourg Verlag. 5. Laugwitz, B.; Held, T. & Schrepp, M. (2008). Construction and evaluation of a user experience questionnaire. In: Holzinger, A. (Hrsg.): USAB 2008, S. 63–76, LNCS 5298. Springer Verlag. 6. Norman, D. (2003). Emotional Design: Why We Love (Or Hate) Everyday Things. Basic Books, Boulder Colorado. 7. Rauschenberger, M., Schrepp, M., Cota, M.P., Olschner, S. & Thomaschewski, J. (2013). Efficient measurement of the user experience of interactive products – How to use the User Experence Questionnaire (UEQ). Example: Spanish Language Version. International Journal of Interactive Multimedia and Artificial Intelligence, Vol. 2, Nr. 1, S. 39–45.

Oft sind die UEQ-Werte von Prototypen höher als die Durchschnittsbeurteilung der Anwendungen, teilweise sogar etwas höher als die am besten beurteilte DATEVAnwendung. Dies ist jedoch in diesem Zusammenhang nicht überraschend, da zumeist eine eingeschränkte Funktionalität vorliegt.

8. Tractinsky, N. (1997). Aesthetics and Apparent Usability: Empirical Assessing Cultural and Methodological Issues. In: CHI’97 Electronic Publications http://www.acm.org/ sigchi/chi97/proceedings/paper/nt.htm. 9. UEQ Online: www.ueq-online.org (last visited: 20.06.2013).

353

354

Referenten

355

Andrus, Roland Roland Andrus studierte Wirtschaftsinformatik mit dem Schwerpunkt Multimedia an der Fachhochschule Ansbach. Ab 2007 war er zunächst als Online-Redakteur bei der ProSiebenSat.1 Media AG mit dem Schwerpunkt Community & Video beschäftigt. Von 2009 an arbeitete er als Senior-Projektleiter und Konzepter bei der Webfact Internet Concept GmbH. Seit August 2010 ist er als Senior-Manager Produktentwicklung im Bereich der Weiterentwicklung der Produkte von WELT DIGITAL tätig.

Bär, Nina Nina Bär ist seit 4 Jahren im Bereich Usability/User Experience an der TU Chemnitz tätig. Vor allem in der Beratung von kleinen und mittleren Unternehmen ist sie für die Durchführung von Usability-Tests und Experten-Reviews von Software, Web-Anwendungen und Websites sowie Industrieprodukten zuständig. Zudem befasst sie sich mit dem Forschungsschwerpunkt „Usability & Online-Trust“.

Beavers, Charlene Charlene Beavers ist User Experience Engineer bei der STRATO AG mit Sitz in Berlin. Dort trägt sie die Verantwortung als UX Experte in der agilen Produktentwicklung. Dazu gehören unter anderem die eigenverantwortliche Durchführung von User Research Methoden, wie auch die Erstellung von Wireframes, Funktionslayouts und Prototypen, aber auch die Durchführung und Auswertung von Usability Tests. Charlene hat langjährige Erfahrungen im Bereich von User Centered Design gesammelt und ist seit 2009 Mitglied der UPA. Bei ihrem jetzigen Arbeitgeber war sie maßgeblich an dem Aufbau der UX Abteilung von Beginn an beteiligt.

Bechinie, Michael Mag. Michael Bechinie: Studium der Anthropologie an der Universität Wien mit dem Fokus Human Ethology. Bereichsleitung Experiences Design bei USECON. Mehr als 15 Jahre Erfahrung im Bereich Usability / User Experience. Beschäftigt sich mit den Themen: Management und Durchführung von Projekten im Umfeld Webanwendung (eGov, eHealth, Versicherungen etc.), User Interface Style Guide Entwicklung, Strategisches Experience Management, Durchführung von Trainings.

356

Usability Professionals 2013 Referenten

Brau, Henning Henning Brau ist als „Director User Experience Design“ bei der User Interface Design GmbH in München tätig. Zuvor war er bis 2010 bei der Daimler AG verantwortlich für das Themenfeld „User-Centered Technologies“. Seit 2007 ist er Mitglied des Vorstands der German UPA und war von 2008 bis 2010 Präsident des Verbandes. 2011 war er „Regional Coordinator Europe“ der UPA international. Weiterhin ist er Mitarbeiter im Normenausschuss „Benutzungsschnittstellen“ des Deutschen Instituts für Normung (DIN) e.V.

Burmester, Michael Dr. Michael Burmester ist Professor für Ergonomie und Usability an der Hochschule der Medien (HdM) in Stuttgart. Seit 2002 lehrt er im Studiengang Informationsdesign. Zuvor arbeitete er für das Fraunhofer-Institut Arbeitswirtschaft und Organisation (IAO) in S tuttgart, Siemens Corporate Technology in München und die User Interface Design GmbH als Usability Forscher, Usability Professional und Manager. An der HdM leitet er das User Experience Research Lab (UXL und ist Sprecher der Information Experience and Design Research Group IXD der HdM. Seit Oktober 2010 ist er Prodekan für Forschung an der Fakultät für Information und Kommunikation. Seine Forschungsinteressen liegen in der Weiterentwicklung des Usability Engineerings zu einer umfassenden G estaltungsdisziplin, die die Mensch-Technik-Interaktion zu einem für Menschen positiven Erlebnis macht. Aktuelle Forschungsarbeiten beschäftigen sich mit der Entwicklung von Gestaltungs prozessen und Methoden zur systematischen erlebnisorientierten Gestaltung sowie der Mensch-Roboter-Interaktion für Serviceroboter zur Unterstützung älterer Menschen mit einem Schwerpunkt im Bereich der Teleoperation

Busch, Katja Katja Busch studierte nach einer Ausbildung zur Industriefotografin Medien-Planung, -Entwicklung und -Beratung in einer Zeit als „Multimedia“ zum Wort des Jahres gekürt wurde. Mit der aufkommenden New Economy immigrierte sie in die digitale Welt und schrieb ihre Diplomarbeit über Usability & Informationsarchitektur als Google noch ein Geheimtipp war. Sie arbeitete u.a. als Projektmanagerin, Strategic Planner, Informationsarchitektin und Content Strategist für mittelständische Unternehmen sowie für internationale Großkonzerne. Ab 2007 leitete sie den Bereich User Experience bei Sapient, bevor sie 2010 als Head of Digital Marketing zur Vaillant GmbH auf die Kundenseite wechselte. Zum Austausch zwischen Wissenschaft und Wirtschaft dozierte sie über Informationsarchitektur, Qualität im Web und Online-Marketing an der Uni Siegen, der FH Bonn-Rhein-Sieg und der FH Köln.

357

Cepkenli, Sirin Sirin Cepkenli ist Senior Interaktion Architekt bei USEEDS° in Berlin. Sie erarbeitet und konzipiert seit mehr als 4 Jahre nutzerzentrierte Lösungen hauptsächlich im Web Bereich. Es macht ihr Spaß, sich in Kunden und Endnutzer hineinzuversetzen und Lösungen und Konzepte zu entwickeln, die einfach zu nutzen sind und begeistern.

Charlier, Nicole Nicole Charlier ist User Experience Engineer und leitet das Competence Center für User Experience bei der akquinet AG in Berlin. Sie ist als Beraterin tätig und leitet In-house Usability Projekte. Ein weiterer Schwerpunkt von Nicoles Arbeit ist Barrierefreiheit.

Daske, Lisa Lisa Daske arbeitet seit 2009 als Usability Engineer bei der Astrum IT in Erlangen. Im Rahmen des User Centered Design Prozesses betreut sie sowohl interne Software-Entwicklungs-Projekte als auch Kundenprojekte. Im Rahmen dieser Tätigkeit hat sie bereits viele Usability Tests geplant und durchgeführt. Lisa hielt auf der Konferenz Medconf von 2010 bis 2012 mehrere Workshops und Vorträge zu Themen rund um Usability in Deutschland und der Schweiz, unter anderem 2011 und 2012 zum Thema Usability Tests. Lisa Daske hat an der CUE-9-Studie auf der „Mensch und Computer“-Konferenz 2011 in Chemnitz teilgenommen.

Diefenbach, Sarah Sarah Diefenbach ist wissenschaftliche Mitarbeiterin im Bereich Nutzerleben und Ergonomie an der Folkwang Universität der Künste Essen. Ihre Forschungsinteressen liegen in den Bereichen User Experience, Experience Design, Ästhetik der Interaktion und erlebnisorientierte Interaktionsgestaltung. Sarah Diefenbach hat an der TU Darmstadt Psychologie mit Nebenfach Informatik studiert.

358

Usability Professionals 2013 Referenten

Dierolf, Peer Peer Dierolf ist bei der Carl Zeiss SMS GmbH in Oberkochen in der Forschung und Entwicklung tätig und dort verantwortlich für Human Centered Design und Usability. Er hat an der Hochschule für Technik und Wirtschaft in Aalen Informatik mit Schwerpunkt Medieninformatik und an der Swinburne University of Technology in Melbourne Design, 3D Visualisierung und Audiovisuelle Medien studiert. Nach seinem Studium war er beim Marktführer der Verpackungsmaschinenbranche als Software-Ingenieur unter anderem verantwortlich für das Usability Engineering einer Softwarefamilie zur Überwachung und Steuerung von Maschinenparks. Er ist seit mehreren Jahren Mitglied der German UPA und absolviert 2013 berufsbegleitend die Ausbildung zum Usability Consultant bei der artop GmbH in Berlin. Neben seiner Familie ist User Experience & Usability ebenso sein Lebensinhalt wie sein großes Hobby als Band-Drummer.

Dittrich, Frank Frank Dittrich ist seit 2009 wissenschaftlicher Mitarbeiter an der Professur Arbeitswissenschaft & Innovationsmanagements des Institutes für Betriebswissenschaften und Fabriksysteme der TU Chemnitz. Seine Arbeitsschwerpunkte liegen im Bereich der nutzerzentrierten Produktentwicklung. Er führte zahlreiche Usability-Projekte mit kleinen und mittleren Unternehmen durch und ist zudem in Industrieprojekte mit Großunternehmen eingebunden.

Döbelt, Susen Susen Döbelt ist seit 4 Jahren im Bereich Human Computer Interaction und seit 2013 an der TU Chemnitz tätig. Sie war bereits in nationalen und internationalen Forschungsprojekten mit der Erfassung nutzerzentrierter Anforderungen und Evaluation technischer Systeme betraut. Ihr Forschungsschwerpunkt liegt im Bereich persuasive Technologiegestaltung, insbesondere Smart Grid Anwendungen im Hinblick auf Privatsphärenaspekte.

Dorn, Manfred Manfred Dorn (1962), Diplom-Designer, lebt und arbeitet in Stuttgart. An das Studium an der Staatlichen Akademie der Bildenden Künste in Stuttgart unter Sapper und Lehmann, schloss sich das Stipendium „Les Ateliers“ in Paris an. 1990 war Manfred Dorn ein Jahr in Mailand bei Michele De Lucchi und Carlo Forcolini. Danach kamen die Jahre bei Mercedes-Benz. 1991 bis 1996 Fachbereich Corporate Design,von 1997 bis 1998 der Bereich Interieur Design. Von 1999 bis Ende 2005 war Manfred Dorn Leiter des Teams Mercedes-Benz Interface Design. Seit 2006 ist Manfred Dorn Director Interface Design bei Phoenix Design Stuttgart/Suzhou und wurde im Januar 2011 zusammen mit Harald Lutz in den Kreis der Mitgesellschafter von Phoenix Design aufgenommen. Neben der Juryarbeit engagiert sich Manfred Dorn in der Nachwuchsförderung u. a. im Rahmen von Hochschulvorträgen sowie in der Phoenix Design Academy. Er ist begeisterter Skiläufer und Triathlet auf der Ironman Langdistanz.

359

Duda, Sabrina Sabrina Duda ist seit 1998 in der User Experience Forschung tätig. Sie studierte Psychologie mit Nebenfach Ingenieurpsychologie und Informatik an der Humboldt Universität zu Berlin. 1999 gründete sie die User & Brand Research Agentur eye square. Seit 2012 ist sie Inhaberin von users‘ delight, einer User Experience Agentur mit Fokus auf Emotional Usability. Sie ist im World Usability Day Berlin Orgateam.

Endmann, Anja Anja Endmann, Diplom-Kommunikationspsychologin, arbeitet als User Experience Researcher bei der itCampus GmbH. Ihr Aufgabenspektrum umfasst die Bereiche User Research & Requirements Engineering, Evaluation von Softwarelösungen mit Experten und realen Nutzern, User-Centered Design, Design Thinking, Projektmanagement und Trainings. Während des Studiums an der Hochschule Zittau/Görlitz und ihrer darauffolgenden Tätigkeit an der TU Chemnitz beschäftigt sie sich intensiv mit verschiedenen Methoden zur Erhebung von Anforderungen und Evaluation. Seit 2012 arbeitet Sie als Dozentin an der HTWK Leipzig und der HTW Dresden. Darüber hinaus ist sie Mitbegründerin und Leiterin des Arbeitskreises User Research der German UPA.

Fischer, Holger Holger Fischer studierte Medieninformatik an der Fachhochschule Köln und ist wissenschaftlicher Mitarbeiter in der Gruppe Usability Engineering im Cooperative Computing & Communication Laboratory (C-LAB), dem gemeinsamen Forschungs- und Entwicklungslabor der Universität Paderborn und der Atos IT Solutions and Services GmbH. Er arbeitet als Usability Engineer in diversen Projekten und unterstützt die Einführung und Durchführung von HumanCentred Design Aktivitäten in Produktentwicklungsprozessen. Im Rahmen seiner Promotion forscht er im Themenbereich der Integration von Usability Engineering. Des Weiteren beschäftigt er sich in der Lehre mit Themen der Mensch-Computer Interaktion und der (be-) greifbaren Interaktion.

Fleck, Michael Michael Fleck studierte Medieninformatik, Psychologie und Medienwissenschaften in Dresden und Kapstadt, Südafrika. Danach arbeitete er als Konzepter und Flashentwickler in diversen Agenturen. Seit 2011 arbeitet er als Senior Interaction Architect bei USEEDS°, einer User-Centered-Design- und Usability-Agentur in Berlin. Seinen Schwerpunkt hat er in der Konzeption von interaktiven Anwendungen gesetzt – in mobilem wie stationärem Kontext. Dabei liegt ihm vor allem die frühestmögliche Integration des Nutzers in den Erstellungsprozess des Produkts am Herzen. Neben der Beschäftigung mit Informationsarchitekturen und Nutzerbedürfnissen gibt er auch Workshops in den Bereichen Ideation und Innovation.

360

Usability Professionals 2013 Referenten

Flesch, Carolin Carolin Flesch, Dipl.-Psychologin, arbeitet als User Researcher bei der SAP AG in Walldorf. Derzeitige Schwerpunkte sind Customer und User Experience Research im Mobile Bereich. Hier ist sie verantwortlich für die Integration von Field Research und Usability Tests in den Produktentwicklungsprozess sowie Methodentrainings zu benutzerzentriertem Design. Carolin Flesch hat an der TU Darmstadt Psychologie studiert und wurde während ihres Studiums zur Trainerin ausgebildet. Darüber hinaus ist sie Mitbegründerin und Leiterin des Arbeitskreises User Research der German UPA.

Geis, Thomas Thomas Geis ist seit 1993 im Arbeitsgebiet Usability Engineering tätig und seit 2003 Geschäftsführer der ProContext Consulting GmbH, einem Beratungshaus, das auf Requirements Engineering aus Nutzersicht, Produktmanagement und Standardisierung im Usability Engineering spezialisiert ist. Er hat zahlreiche Anforderungsanalysen aus Nutzersicht, Interaktionsdesignprojekte und Usability-Tests sowie Schulungen für Software-Entwicklungsteams durchgeführt. Thomas Geis verfügt über profundes Wissen im Bereich Usability Engineering und in der konsequenten Umsetzung theoretischer Ansätze in die Praxis. Thomas Geis leitet den DIN-Ausschuss „Benutzungsschnittstellen“ und den ISO-Ausschuss „Common Industry Formats for usability-related information“, kurz CIF.

Gerstheimer, Oliver Oliver Gerstheimer ist seit 15 Jahren unterwegs als Entwerfer und Fährtensucher im „Land of Digital Business“ und dabei ein passionierter Evangelist für ein „Design Thinking“ und bessere „Digitale Produkte von Morgen“. 2001 gründete er die chilli mind GmbH – ein scharfer Think Tank für Digitale Innovation, User-Experience-Design und Informationsarchitektur. Von 2002–2008 war Oliver zudem Leiter des Postgraduiertenstudiengangs „Executive Master of Mobile Application Design“ (MAD) an der Zürcher Hochschule der Künste sowie Dozent an der Kunsthochschule Kassel (2004–05) und an der HAWK Hildesheim für Design-Management (2009–2011). Oliver studierte Systemdesign (Produktdesign) sowie Technologie- und Innovationsmanagement an der Universität Kassel.

Geyer, Florian Florian Geyer ist Usability Engineer bei der itemis AG. Er hat Informatik mit dem Schwerpunkt Mensch-Computer Interaktion studiert und promoviert. In seinen international publizierten und mehrfach ausgezeichneten Forschungsarbeiten hat er sich mit Designtheorie, kreativen Methoden für das Interaktionsdesign und neuen, natürlichen Interaktionstechniken beschäftigt. Seine Arbeitsschwerpunkte umfassen seit 2006 die Analyse, Konzeption und Evaluation von interaktiven Systemen.

361

Giere, Lars Lars Giere ist Product Manager für mobile.de.

Glende, Sebastian Der promovierte Wirtschaftsingenieur Sebastian Glende beschäftigt sich mit innovativen Ansätzen der User Integration. Vor der Gründung der YOUSE GmbH forschte und arbeitete er an der TU Berlin und an der Victoria University of Wellington, New Zealand. Als externer Lehrbeauftragter hielt Sebastian an der TU Berlin die Vorlesung „Ergonomic Design and User Integration“ und leitete die Senior Research Group – eine Gruppe von 20 Senioren, die sich an Innovationsprozessen für Produkte und Dienstleistungen beteiligt. Sebastian war und ist in mehreren Institutionen und Funktionen aktiv, z.B. am Innovationszentrum Gesundheit & Ernährung in den Bereichen Gesundheitsmonitoring und User Integration, als ehemaliger Sprecher des vom Bundesfamilienministerium geförderten „Transferzentrum Generation Plus“ sowie im Standing Committee „Ergonomics Quality In Design“ der International Ergonomics Association.

Glomann, Leo Leo Glomann studierte Interaktionsdesign und ist seit 2007 als Usability Engineer tätig. Seit 2010 arbeitet er nebenberuflich an der Georg-Simon-Ohm Hochschule Nürnberg als Lehrbeauftragter im Fachbereich Interaktionsdesign und behandelt die Themen Gamedesign und Human Centered Design. Seit 2012 leitet er das Usability Engineering Team im Bereich IT Marketing der adidas Group.

Goering, Katharina Katharina Göring, Dipl. Designerin, arbeitet seit 2012 als Director User Experience bei der Software AG Konzerntochter itCampus GmbH. Sie ist für den User Experience Bereich der Software AG internen Produktentwicklung und das Global Consulting Competence Center User Experience für Kunden verantwortlich. Davor war sie als User Experience Expert bei der SAP AG federführend für die nutzerzentrierte Entwicklung zahlreicher innovativer Geschäftsanwendungen u.a. auch in den Bereichen Mobile und Cloud. In den letzten Jahren arbeitete sie zunehmend als Design Thinking Coach, begleitete und trainierte Teams bei der Entwicklung innovativer Produktvisionen und deren Umsetzung. Seit 2009 ist sie zudem als Dozentin für User Experience Design tätig.

362

Usability Professionals 2013 Referenten

Groenefeld, Jan Jan Groenefeld ist Senior User Experience Designer bei der Ergosign GmbH und leitet den Bereich "Industry Solutions". Der fachliche Schwerpunkt liegt hierbei auf dem HMI-Design für Maschinen- und Anlagensteuerungen. Unter dem Motto "Next Generation HMI Design" ist Jan Groenefeld Anprechpartner für den Bereich Design in der HMI Alliance. Der interdisziplinäre Zusammenschluss von Dienstleistern aus den Bereichen Automatisierungstechnik und Design verfolgt das Ziel, Benutzerfreundlichkeit und Innovation in industrieller Anwendersoftware zu fördern.

Gruber, Ulrike Ulrike Gruber studierte Psychologie an der Universität Graz. Sie ist Consultant und Head of Experience Consulting bei USECON. Ihre Verantwortungsgebiete umfassen User Innovation, qualitative und quantitative Methoden, User Research & Insights sowie Customer Experience Projekte.

Grudno, Lucie Lucie Grudno arbeitet seit 2011 als Usability Engineer bei der adidas Group im Bereich IT Marketing. Ihr Studium der BWL mit Schwerpunkt Wirtschaftsinformatik schloss sie zuvor mit einer ausgezeichneten praktischen Diplomarbeit zum Thema Usability ab.

Hartmann, Peter Peter Hartmann studierte Informatik und Ingenieurswissenschaften an der Technischen Hochschule Hamburg-Harburg. Zum Januar 2012 beendete er seine Diplomarbeit bei der Group Research & Advanced Engineering der Daimler AG zum Thema Natural User Interfaces. Seitdem arbeitet Herr Hartmann an der Gestaltung und Realisierung von moderner Software für die Anlagen- und Automatisierungstechnik bei der Schulz Systemtechnik GmbH.

363

Hassenzahl, Marc Marc Hassenzahl ist Professor für Nutzererleben und Ergonomie im Fachbereich Gestaltung an der Folkwang Universität der Künste in Essen.

Heckner, Markus Dr. Markus Heckner ist Akademischer Rat am Lehrstuhl für Medieninformatik an der Universität Regensburg. Bis Ende 2010 war er Consultant bei der Unternehmensberatung Accenture und hat dort mehrere Projekte im Bereich User Experience bei großen deutschen Unternehmen umgesetzt. Markus Heckner ist Mitgründer der small worlds GbR und berät Kunden dabei, die Usability Ihrer Produkte zu verbessern.

Heimgärtner, Rüdiger Dr. Rüdiger Heimgärtner konzentriert sich seit 2003 auf die stetige Eruierung des aktuellen Forschungsstandes im Bereich der Entwicklung interkultureller Benutzungsschnittstellen. Als Gründer und Inhaber der Firma Intercultural User Interface Consulting (IUIC) gibt er seit 2008 sein kompiliertes Wissen in Form von Schulung, Coaching und Beratung an Industrie und Forschung weiter und entwickelt Werkzeuge und Methoden zur Unterstützung der Einführung und Durchführung von Usability-Engineering-Prozessen auch im interkulturellen Kontext.

Held, Theo Dr. Theo Held studierte Psychologie an der Universität Regensburg (Schwerpunkt: experimentelle Wahrnehmungspsychologie). Nach der Promotion (Universität Heidelberg) war er in Forschung und Lehre an den Universitäten Heidelberg, Graz und Halle/Saale tätig. Seine hauptsächlichen Forschungsinteressen liegen in den Bereichen Wahrnehmung und Wissensrepräsentation, sowie der Evaluation von Softwareprodukten. Seit 2001 gehört er dem User Experience Team der SAP an. Bis Ende 2010 war er für eine Reihe zentraler Designkonzepte der SAP Customer Relationship Management Lösung verantwortlich. Seit 2011 ist er als User Experience Research Expert für die (Weiter-)Entwicklung von Evaluationsmethoden zuständig.

364

Usability Professionals 2013 Referenten

Hess, Steffen Steffen Hess ist Teamleiter für User Experience am Fraunhofer IESE in Kaiserslautern. Er studierte Diplom-Wirtschaftsingenieurswesen und ist seit 2004 in den Bereich Usability-, User Experience-, und Requirements Engineering tätig. In dieser Zeit hat er zunächst stark das Thema Usability Testing bearbeitet und hat sich im weiteren Verlauf seiner Tätigkeit intensiv mit Requirements Engineering und Interaktionsdesign auseinandergesetzt. Seit 2009 hat er viele Projekte im Bereich Interaktionsdesign, UX Prototyping und Customizing von mobilen Geschäftsanwendungen in verschiedenen Anwendungsdomänen durchgeführt. Hierbei hat sich durch die Kombination von Forschungsprojekten im Bereich User Experience Pattern und Mobile, sowie die große Involvierung in praktischen Industrieprojekten ein spannender Mix aus Forschung und Anwendung ergeben.

Hochreuter, Thorsten Thorsten Hochreuter ist seit Sommer 2012 wissenschaftlicher Mitarbeiter im Forschungsprojekt ProTACT an der Hochschule Mannheim. Schon während seines Studiums der Informatik beschäftigte er sich mit der Konzeption und Entwicklung von Multi-Touch-Systemen. Sein derzeitiges Tätigkeitsfeld liegt im Bereich des Prototypings für Multi-Touch- und Tangible-Interaktionen.

Hoos, Sebastian Sebastian Hoos ist User Experience Researcher bei USEEDS° in Berlin. Er ist die Stimme des Nutzers im User Centred Design Prozess. Dafür definiert er Anforderungen an die Projekte, begleitet die Entwicklung und hilft mit kreativen Methoden, das Ergebnis mit der bestmöglichen User Experience zu erzielen.

Hüttner, Jens Jens Hüttner, Diplom-Psychologe ist Geschäftsführer, Berater und Partner bei artop – Institut an der Humboldt-Universität zu Berlin. Er arbeitet seit über 20 Jahren in den Bereichen Usability und Ausbildung/Training. Die Verbindung von Analyse, Entwicklungsbegleitung und Evaluation von Systemen und Projekten in enger Zusammenarbeit mit den Mitarbeitern der Kunden kennzeichnet seine Vorgehensweise. Er verfügt über umfangreiche Erfahrungen bei der Moderation der Umsetzung von Usability-Standards in Produkte und Dienstleistungen. Jens Hüttner hat seine Projekterfahrungen in vielfältiger Weise an die Öffentlichkeit weitergegeben, unter anderem als Dozent an der Humboldt-Universität zu Berlin. Er ist Mitbegründer von artop und zusammen mit Knut Polkehn Ausbildungsleiter der artop-Ausbildung „Usability Consultant“.

365

Janneck, Monique Monique Janneck ist Professorin für Mensch-Computer-Interaktion an der FH Lübeck. Forschungs- und Arbeitsschwerpunkte u.a.: Soziotechnische Gestaltung und partizipative Technikentwicklungs- und Einführungsprozesse, Gender-Aspekte bei der Gestaltung und Nutzung von Informationstechnologie.

Jendryschik, Michael Michael Jendryschik leitet seit 2008 den Bereich Usability bei der itemis AG. Er ist DiplomInformatiker, zertifizierter Usability Engineer und Spezialist für die Konzeption und Entwicklung von Webseiten und Benutzeroberflächen. Über seine Arbeits- und Interessensschwerpunkte Usability und Webstandards spricht er regelmäßig auf verschiedenen Veranstaltungen und Kongressen.

Kiefer, Felix Felix Kiefer ist Diplom-Informatiker (FH) und seit 2006 im Bereich Usability / User Experience tätig. Im Zeitraum von 2006–2009 war er am Fraunhofer IESE in der Abteilung Requirements und Usability Engineering angestellt. In dieser Zeit lagen die Schwerpunkte seiner Aufgaben in den Bereichen Usability Testing und Erstellung von Prototypen. In seiner Diplomarbeit beschäftigte er sich mit der prototypischen Umsetzung einer mobilen Applikation für iOS-Geräte. Von 2010–2011 arbeitete er beim Mediendienstleister Meyle+Müller GmbH+Co. KG in der Abteilung ‚New Media‘. Schwerpunkte der Arbeit waren im Umfeld mobiler Applikationen angesiedelt. Zu den Tätigkeiten zählten in erster Linie die Erstellung von Konzept, Interaktionsdesign und visuellen Design sowie die Umsetzung von Apps für iOS. Seit Ende 2011 ist er wieder am Fraunhofer IESE und arbeitet dort in den Themengebieten ‚User Experience‘ und ‚Mobile Business Apps‘.

Kleine Hörstkamp, Silvia Sylvia Kleine Hörstkamp ist Product Manager für mobile.de.

366

Usability Professionals 2013 Referenten

Kluge, Oliver Oliver Kluge hat Elektro- und Informationstechnik an der TU München studiert. Nach dem Studium arbeitete er viele Jahre als Software-Ingenieur in der Anwendungsentwicklung. Seit 2008 beschäftigt er sich als Usability Engineer mit Fragen zur Gebrauchstauglichkeit von Anwendungen und Produkten bei der Versicherungskammer Bayern (VKB). Er verantwortet alle Usability Engineering Aktivitäten für die Anwendungen, die den Vertriebspartnern der VKB am Point of Sale zur Verfügung gestellt werden.

Kneisel, Boris Boris Oliver Kneisel studierte Chemie in Göttingen, Newcastle u.T. (UK) und Karlsruhe. Nach Promotionsabschluss 1998 Eintritt in den SAP Konzern als System-Analytiker (Beratung), dann D-A-CH-Vertrieb. 2004 Wechsel ins Produktmanagement und MBA-Studium. Über Tätigkeiten in Global-Service-Strategie & Portfoliomanagement, wo er u.a. den UX-Prototypenbau mittels DesignThinking leitete, Programmkoordination für OffshoreLeanSigma-Pilotierung im Outsourcing und COO-Operations im SAP-Research-Bereich entwickelte er sich in die aktuelle Rolle im Lean Core Team der SAP AG, wo er Skalierungskonzepte für Agile Teams verantwortet und deren Verlinkung mit Design Thinking optimiert. Seit 2009 ist er nebenberuflich selbständig als Berater Trainer & Coach, 2010 schloss er die Artop-UX-Ausbildung ab. In Q4–2011 gründete er mit K.Goering und A.Hinderks den GUPA Arbeitskreis "Business Case Usability – RoI-UX", den er aktuell leitet. In 2012 wurde er als Lehrbeauftragter für Innovationsmanagement mit Design Thinking ans KIT-EnTechnon gerufen und baut nun dort eine d.school auf.

Kohler, Kirstin Kirstin Kohler wurde 2008 an die Hochschule Mannheim auf das Lehrgebiet Mensch-Maschine Interaktion berufen. Sie war im Anschluss an ihr Studium der Informatik vier Jahre für die Firma Hewlett-Packard im Bereich User-Centered Design tätig. Danach war sie 9 Jahre bei Fraunhofer IESE in der Beratung und Forschung auf dem Gebiet des User Experience Designs und Requirements Engineerings beschäftigt.

367

Kolb, Nina Nina Kolb studiert Psychologie an der Technischen Universität Darmstadt. Seit 2010 ist sie dort als studentische Hilfskraft in der Arbeitsgruppe für Arbeits- und Ingenieurpsychologie tätig. 2012 verfasste sie ihre Bachelorthesis zum Thema intuitiver Interaktion im Kontext der Produktnutzung

Köpf, Sandra Sandra Köpf ist Usability Expertin bei Exact Software Deutschland. Sie studierte Medieninformatik an der Universität Ulm. Bereits im Studium wie auch in ihrer Diplomarbeit setzte sie ihren Schwerpunkt auf Usability Engineering. In ihrer Rolle als Usability Expertin ist sie verantwortlich für die ständige Optimierung der Lohn- und Gehaltssoftware Exact Lohn und dessen Komponenten. Zu ihren Tätigkeiten gehören der Aufbau der Usability-Kompetenz sowie die Etablierung des Usability-Themas bei Exact, Dienstleister, Projektteams und Nutzer zu koordinieren sowie Anforderungsanalysen, Usability Tests und Interaktionsdesign durchzuführen.

Köpp, Stephan Stephan Köpp ist Fachinformatiker Anwendungsentwicklung und arbeitet seit 2008 als Frontend Engineer bei der mobile.international GmbH. Seit 2012 arbeitet er im Bereich mobile Applikationen. Er plant und setzt webbasierte Projekte mit Responsive Design und Web-Apps mit JavaScript im agilen Umfeld um. Die integration der Umsetzung eines anpassungsfähigen Websitelayouts in allen Ebenen der Produktplanung und Umsetzung in agilen Projektteams sind Kernelemente seiner Tätigkeit.

Kritzenberger, Huberta Kinga Kujat ist seit 1999 planend, gestaltend und entwickelnd im digitalen Umfeld tätig. Nach Abschluß des Studiums Kommunikationsdesign, Schwerpunkt Design für Elektronische Medien an der FH Nürnberg im Jahr 2002 war sie als Flash Entwicklerin und Interface Designerin tätig. Nach Abschluß des Aufbaustudiums Electronic Business an der Universität der Künste Berlin im Jahr 2007, legte sie Ihren Schwerpunkt auf konzeptionelle Arbeit und UX Design. Ihre Projektaufgaben bestehen im Speziellen aus Anforderungsdefinition, Informationsarchitektur und Feinkonzeption/GUI Prototyping für Desktop und mobile Endgeräte. Kinga Kujat ist deutschlandweit für renommierte Digital-Agenturen und Unternehmen tätig und arbeitet in zumeist breit angelegten Projekten für Marken unterschiedlicher Sektoren. Einen Schwerpunkt bilden hier Portale und E-Commerce Projekte aus dem Immobilien-, Automotive- und Bankensektor. Seit 2011 ist Kinga Kujat in Projekten als UX Lead Designer und seit 2013 als Head of Frontend / UX Design beschäftigt.

368

Usability Professionals 2013 Referenten

Kühner, Markus Markus Kühner studierte Digitale Medien an der Fachhochschule Kaiserslautern mit den Schwerpunkten eLearning, Human Computer Interaction und Usability Engineering. Zusätzlich erwarb er den Master of Business Administration (FH) an der Fachhochschule Ludwigshafen am Rhein im Bereich Unternehmensführung.Er arbeitet als Senior User Experience Manager bei der Ergosign GmbH und leitet dort den Bereich User Research and Evaluation.

Kujat, Kinga Kinga Kujat ist seit 1999 planend, gestaltend und entwickelnd im digitalen Umfeld tätig. Nach Abschluß des Studiums Kommunikationsdesign, Schwerpunkt Design für Elektronische Medien an der FH Nürnberg im Jahr 2002 war sie als Flash Entwicklerin und Interface Designerin tätig. Nach Abschluß des Aufbaustudiums Electronic Business an der Universität der Künste Berlin im Jahr 2007, legte sie Ihren Schwerpunkt auf konzeptionelle Arbeit und UX Design. Ihre Projektaufgaben bestehen im Speziellen aus Anforderungsdefinition, Informationsarchitektur und Feinkonzeption/GUI Prototyping für Desktop und mobile Endgeräte. Kinga Kujat ist deutschlandweit für renommierte Digital-Agenturen und Unternehmen tätig und arbeitet in zumeist breit angelegten Projekten für Marken unterschiedlicher Sektoren. Einen Schwerpunkt bilden hier Portale und E-Commerce Projekte aus dem Immobilien-, Automotive- und Bankensektor. Seit 2011 ist Kinga Kujat in Projekten als UX Lead Designer und seit 2013 als Head of Frontend / UX Design beschäftigt.

Kunz, Angelika Angelika Kunz studierte Psychologie an der Universität Wien. Sie ist als Consultant und Team Lead Experience Consulting bei USECON tätig. Sie hat jahrelange Erfahrung im Bereich Marktforschung und der Erhebung von Kundenbedürfnissen. Ihr Spezialgebiet umfasst Customer Journeys, User Research & Insights und User Innovation.

369

Laukenmann, Benjamin Benjamin Laukenmann nahm im Jahr 2008 ein Studium im Studiengang Informationsdesign an der Hochschule der Medien in Stuttgart auf. Im Rahmen dieses Studiums absolvierte er ein Praxissemester bei der SAP AG im Bereich User Experience, wo er praktische Erfahrungen in verschiedenen Bereichen, von der Gestaltung bis zur Testkonzeption und –auswertung, sammelte. Anschließend beschäftigte er sich begleitend zum Studium als wissenschaftliche Hilfskraft im Usability-Labor der Hochschule der Medien ausführlich mit den Themen Usability und User Experience. Seit seinem Abschluss (Bachelor of Arts) im Studiengang Informationsdesign ist er bei der Agentur Siegmund GmbH in Stuttgart angestellt und beschäftigt sich dort als Experte für Usability und User Experience weiterhin mit diesen Themen.

Leiking, Berit Berit F. Leiking studierte Architektur und Städtebau an der Universität Dortmund, wo sie studienbegleitend vier Jahre in der CAD-Lehre beschäftigt war. Sie stieg 2005 als Produktmanagerin für Bau-Softwareentwicklungen bei der Nemetschek Allplan GmbH ein. Anfang 2009 wurde sie dort zur Leiterin des User Experience Teams ernannt und ist verantwortlich für die User Centered Design Maßnahmen. Sie absolvierte berufsbegleitend die Ausbildung zum Usability Consultant bei artop in 2009 und ist seitdem nebenberuflich im Arbeitskreis In-house Usability Professionals der German UPA als stellvertretende Leiterin tätig

Lenz, Eva Eva Lenz ist wissenschaftliche Mitarbeiterin im Studiengang Industrial Design, Nutzererleben und Ergonomie an der Folkwang Universität der Künste Essen. Sie hat Industrial Design an Universität Duisburg-Essen studiert. Nach ihrer Tätigkeit in der Entwicklungsabteilung der Dräger Safety AG & Co. KGaA, Lübeck, gehört sie nun zum Team des BMBF-Projektes proTACT und promoviert im Themenfeld User Experience (Nutzererleben).

Leyking, Nicolas Nicolas Leyking studierte Digitale Medien mit dem Schwerpunkt Human-Computer Inter action an der Fachhochschule Kaiserslautern und vertiefte sein Studium im Bereich des Interaction Design an der Queensland University of Technology in Brisbane, Australien. Seit 2010 arbeitet er als User Experience Designer bei der Ergosign GmbH vorwiegend im Bereich der Business Anwendungen.

370

Usability Professionals 2013 Referenten

Löffler, Jana Jana Löffler ist Diplom-Psychologin und Mitinhaberin von artop – Institut an der HumboldtUniversität zu Berlin. Sie arbeitet seit 2004 als Beraterin bei artop. Ihre Schwerpunkte liegen in der Organisationsentwicklung und im Coaching. Sie ist außerdem als Trainerin sowie als Ausbilderin für beraterische Professionen tätig.

Mahlke, Sascha Sascha Mahlke ist Managing Director User Experience bei USEEDS°.

Molich, Rolf Rolf Molich ist selbstständiger Berater und Inhaber der kleinen dänischen Usabilityberaterfirma DialogDesign. Er arbeitet seit 1984 im Usability-Umfeld und ist Autor des dänischen Bestsellers „User Friendly Computer Systems“, von dem etwa 30.000 Exemplare verkauft wurden. Das Buch ist unter dem englischen Titel Usable Web Design erhältlich. Rolf ist außerdem Mit-Erfinder der Methode der Heuristischen Evaluation, gemeinsam mit Jakob Nielsen. Rolf hat die Studien zur Comparative Usability Evaluation konzipiert und neun Studienreihen (CUE-1 bis CUE-9) organisiert, bei denen insgesamt mehr als 120 professionelle UsabilityTeams jeweils die gleichen Anwendungen getestet bzw. beurteilt haben. Rolf Molich ist externer Dozent am DIKU, dem Informatik-Lehrstuhl der Universität von Kopenhagen, wo er eine Vorlesungsreihe zum Thema Mensch-Maschine-Interaktion hält.

Mory, Maria Maria Mory, Dipl.-Designerin, studierte an der FHTW Berlin im Fachbereich Gestaltung. Seit 1998 gestaltet sie Webinhalte und digitale Produkte, unter anderem 10 Jahre bei ImmobilienScout24. Ihre Schwerpunkte liegen in der Definition von nutzerfreundlichen, ästhetischen und umsatzorientierten Gestaltungszielen. Seit 2011 arbeitet sie als Design-Beraterin und Usability-Consultant für digitale Lernmedien beim Cornelsen-Verlag. Derzeit unterrichtet sie Studenten des Mediendesign an der Hochschule der populären Künste, Berlin, im Fach Usability.

371

Müller, Paul Paul Müller beschäftigt sich seit sechs Jahren mit nutzerzentrierter Gestaltung und Usability. Während seines Fernstudiums zum Web Designer 2005 setzte er sich sowohl theoretisch als auch praktisch schwerpunktmäßig mit den Themen Usability und Barrierefreiheit im Web auseinander. 2008 begann Paul Müller ein Studium im Fachbereich Informationsdesign an der Hochschule der Medien in Stuttgart, wo sich sein Schwerpunkt in Richtung Usability und User Experience in und außerhalb des Webs verlagerte. Seit 2010 unterstützt Paul Müller das Team der Agentur Siegmund GmbH auf den Gebieten Usability und User Experience bei der Konzeption, Durchführung und Auswertung von Nutzertests und ist auch beratend in diesen Bereichen tätig.

Murtinger, Markus Mag. Markus Murtinger: Studium der Betriebswirtschaft an der Wirtschaftsuniversität Wien mit dem Fokus Entrepreneurship & Innovation. Director Consulting, Sales & Marketing bei USECON. Mehr als 10 Jahre Erfahrung im Bereich Usability / User Experience. Beschäftigt sich mit den Themen: Strategisches Experience Management sowie Experience Innovation.

Nedopil, Christoph Dr. Christoph Nedopil begeisterte sich schon während seines Studiums an der TU Berlin für die kundenfreundliche Produktgestaltung. Um diesem Thema auf den Grund zu gehen, schrieb er ein Buch über Komplexität und erforschte bei der Unternehmensberatung Oliver Wyman und zahlreichen Fahrzeugherstellern die User Integration in der Automobilindustrie. Während seiner Arbeit an der Schweizer Business School IMD International und als Berater für die Weltbank erlernte er zahlreiche Unterrichts- und Kreativitätstechniken. Um das gesammelte Wissen in die Praxis umzusetzen, gründete Christoph (zusammen mit Sebastian Glende) die YOUSE GmbH. Sein erklärtes Ziel ist es, eine Brücke zwischen Entwicklern, Produkt und Anwendern zu schlagen, damit am Ende sowohl die Nutzer als auch die Entwickler begeistert vom fertigen Produkt sind.

Olschner, Siegfried Dr. Siegfried Olschner ist Mitglied des User Experience Design -Teams der DATEV eG Nürnberg. Neben allgemeinen Beratungsthemen und Workflow- bzw. Dialoggestaltung innerhalb des User Centered Design-Prozesses führt er auch User Research-Projekte durch. Dabei beschäftigt er sich mit Fragen zur Methodik von Datenerhebungen, wie z. B. dem Testen neuer Methoden oder der Verbesserung des innerhalb der DATEV eingesetzten User Experience Questionnaire.

372

Usability Professionals 2013 Referenten

Oster, Natalie Natalie Oster studierte Digitale Medien an der Fachhochschule Kaiserslautern und vertiefte ihr Studium im Bereich Human-Computer Interaction. Seit 2010 arbeitet sie als User Experience Designerin bei der Ergosign GmbH vorwiegend in den Bereichen Industrie- und Office-Anwendungen.

Patz-Brockmann, Frank Frank Patz-Brockmann ist Director R&D bei Contact Software.

Petzold, Maike Maike Petzold studierte Medien und angewandte Informationstechnologie (heute Medieninformatik) an der Fachhochschule Düsseldorf. Anfang 2011 beendete sie ihre Bachelorarbeit mit dem Thema „Konzeption und Implementierung einer Kalkulationssoftware zur Optimierung von Stalleinrichtungen“ in der Entwicklungsabteilung der Big Dutchman AG. Im Anschluss daran nahm Frau Petzold ihre Tätigkeit bei der Schulz Systemtechnik GmbH im Bereich Anlagen- und Automatisierungstechnik auf. Sie beschäftigt sich hier mit der Gestaltung und Realisierung moderner Software.

Pietschmann, Jens Produktkonzeption und -management seit 2009 für diverse Projekte im Online-Bereich und Business Applikationen. Seit 2009 ebenfalls mit der Verantwortung als Product Owner und Business Analyst gemäß Scrum für unterschiedliche Produkte und Projekte mit den Schwerpunkten auf User Experience und Gamification. Jens Pietschmann ist aktuell als Produktmanager bei der cleverbridge AG tätig.

373

Polkehn, Knut Knut Polkehn, Diplom-Psychologe ist Berater und Partner bei artop – Institut an der Humboldt-Universität zu Berlin. Er berät zu Themen der Mensch-Technik-Interaktion von Anforderungsanalyse bis Evaluation sowie zur Integration von Usability Engineering Aktivitäten in die Produktentwicklung. Seine umfangreichen Erfahrungen gibt er als Dozent in der erfolgreichen artop-Ausbildung „Usability Consultant“ sowie in in-house Seminaren weiter.

Rauschenberger, Maria Maria Rauschenberger ist Projektleiterin (Online & SAP) bei der Firma Medien-Systempartner (MSP). Ihr derzeitiger Aufgabenbereich ist u.a. die anwendungsorientierte Oberflächengestaltung, Erfassung innovativer Produktideen und deren Umsetzung. Zuvor studierte Maria Rauschenberger Medientechnik und schloss ihr Studium mit dem Bachelor of Engineering ab. Ihren Schwerpunkt legte sie auf Usability und User-Experience basierte Software-Entwicklung. Um ihren Horizont zu erweitern, studiert Sie berufsbegleitend an der Hochschule Emden/Leer den Online-Master Medieninformatik.

Röhrich, Anika Anika Röhrich ist Absolventin des Bachelorstudiengangs Medieninformatik Online und studiert derzeit im Masterstudiengang Medieninformatik Online mit Schwerpunkt Human Computer Interaction an der FH Lübeck. Beruflich tätig ist sie im Bereich Qualitätsmanagement im Mobilfunkumfeld.

Rügenhagen, Eva Eva Rügenhagen arbeitet seit 2007 im Bereich User Experience bei der SAP AG in Walldorf. Zu ihren Tätigkeiten als Senior User Researcher gehören das Coaching von Produktentwicklungsteams zur Anwendung von User Research Methoden sowie Methodentrainings zu benutzerzentriertem Design. Durch ihre Erfahrung in unterschiedlichen Produktbereichen liegt ihr Schwerpunkt auf Research Projekten im Umfeld komplexer Businessprozesse. Eva Rügenhagen studierte an der Albert-Ludwigs-Universität Freiburg Kognitionswissenschaft und Germanistik und fokussierte sich bereits während ihres Studiums auf den Bereich Mensch-Maschine-Interaktion.

374

Usability Professionals 2013 Referenten

Rummel, Bernard Bernard Rummel arbeitet seit mehr als 20 Jahren im Arbeitsfeld Ergonomie und Gebrauchstauglichkeit. Nach neun Jahren am Schiffahrtmedizinischen Institut der Marine kam er 2000 zu SAP. Als Diplom-Psychologe (Universität Kiel) mit Schwerpunkt auf Ingenieur- und Organisationspsychologie hat er kontinuierlich zu Themen an der Schnittstelle zwischen Usability Engineering und Organisation gearbeitet und publiziert, so zu Weiterbildung, Etablierung von Usability Engineering und Praxis der betrieblichen Standardisierung im Design. Er arbeitet weiterhin im DIN-Normenausschuss Ergonomie – Benutzungsschnittstellen an Designstandards wie z.B. der Normenreihe DIN EN ISO 9241. Seit 2011 beschäftigt er sich bei SAP mit der Quantifizierung von Gebrauchstauglichkeit und Usability Benchmarking.

Schauber, Cornelia Cornelia Schauber ist Diplom-Psychologin und interessiert sich besonders für Versuchsplanung und -design, neurologische Korrelate psychischer Zustände und Robotik. Nach dem Studium arbeitete sie als wissenschaftliche Mitarbeiterin des Instituts für Arbeitswissenschaft an der Universität der Bundeswehr im Rahmen des Exzellenzclusters „CoTeSys“ an der automatisierten Emotionserkennung in der Mensch-Maschine-Interaktion. Seit 2010 gehört Cornelia zum Team der YOUSE GmbH München und ist dort für die Planung und Durchführung von Nutzerstudien und die statistische Datenanalyse zuständig.

Scheiner, Thom Thom Scheiner ist Kommunikationspsychologe (FH) und Senior Usability Engineer in der Münchner Geschäftsstelle der User Interface Design GmbH (UID). Seit 2005 leitete und bearbeitete er vornehmlich Projekte aus der Industry-Branche in In- und Ausland, seit 2011 ist er in einem Enterprise-Web-Programm tätig. Des Themas Anforderungen nimmt er sich bei UID seit etwa sechs Jahren an.

Schlenker, Reiner Reiner Schlenker ist freiberuflicher Usabilityberater. Seit Ende der 90er Jahre beschäftigt ihn das Thema Benutzungfreundlichkeit in unterschiedlichen Positionen. Zuerst als Technischer Redakteur, später kamen die Bereiche Softwarelokalisierung und Produktdesign hinzu. Er hat an der Hochschule Rapperswil berufsbegleitend einen Master in Human Computer Interaction Design erworben und ist Lehrkraft für Usability an der Hochschule Furtwangen im Schwarzwald.

375

Schlierkamp, Katrin Katrin Schlierkamp ist ausgebildete Mediengestalterin und studierte Informationsdesign (Bachelor of Arts) an der Hochschule der Medien in Stuttgart mit den Schwerpunkten Usability und User Experience. Schon während ihres Studiums arbeitete sie zunächst als Werkstudentin und später dann als Freelancerin. Ihr Praxissemester absolvierte sie bei der Ravensburger GmbH, wo sie unter anderem Spiele im Online-Bereich konzipieren durfte. Seit 2013 ist sie als Interaktionsdesignerin bei der User Interface Design GmbH (UID) tätig. Zu ihren aktuellen Tätigkeiten gehören die Erstellung interaktiver Prototypen, das Generieren von Nutzungsszenarien sowie Themenschwerpunkte aus dem Bereich User Requirements Engineering.

Schmidt, Christiane Christiane Schmidt ist seit 1996 als GestalterIn komplexer digitaler Anwendungen in edukativen und kulturellen Bereichen tätig. Seit 2002 arbeitet sie als Designberaterin und UsabilityConsultant im Cornelsen Verlag. Sie befasst sich derzeit mit der Schaffung von Quality Gates im digitalen Bereich, führt hausweite Schulungen zu digitalen Design- und Usabilitythemen durch und implementiert die Sicht der Nutzer in die Produktentwicklungen.

Schneidermeier, Tim Tim Schneidermeier studierte Informationswissenschaft in Regensburg und Helsinki. Seit 2009 arbeitet er als Wissenschaftlicher Mitarbeiter am Lehrstuhl für Medieninformatik der Universität Regensburg. Zunächst im vom IUK Bayern geförderten Forschungsprojekt moDino tätig, hat er ab 2011 universitäre Lehrtätigkeiten in den Bereichen Usability Engineering und User Experience übernommen. Seit 2010 promoviert er über Variabilitätsmanagement im MenschMaschine-Interaktionsdesign. Tim Schneidermeier ist Mitgründer der small worlds GbR, einem Spin-Off der Medieninformatik der Universität Regensburg. Dort betätigt er sich hauptsächlich in den Feldern Usability Engineering und User Interface Design.

Schön, Eva-Maria Eva-Maria Schön ist als Consultant bei der 7P Solutions & Consulting AG tätig. Das Unternehmen ist Teil der SEVEN PRINCIPLES (7P) Group, einer international agierenden Unternehmensberatung mit IT-Fokus. Ihr Schwerpunkt bildet das User Experience Design in agilen Entwicklungsprozessen. Dabei übernimmt sie die Rolle des Product Owners. Zudem ist sie Mitglied einer Forschungsgruppe der HS Emden/Leer und beschäftigt sich mit Methoden aus den Bereichen User Experience und Usability.

376

Usability Professionals 2013 Referenten

Schrepp, Martin Dr. Martin Schrepp studierte Mathematik und Psychologie an der Universität Heidelberg. 1990 Abschluss als Diplom-Mathematiker. 1990 – 1993 Promotion in Psychologie. Seit 1994 bei der SAP AG tätig. Bisherige Tätigkeitsfelder waren hier die Konzeption technischer Dokumentation, Software-Entwicklung, User Interface Design und Barrierefreiheit betriebswirtschaftlicher Anwendungen (Schwerpunkt CRM). Hauptinteressen sind die Anwendung kognitionswissenschaftlicher Erkenntnisse auf das Design interaktiver Anwendungen, Barrierefreiheit und die Entwicklung von Methoden zur Evaluation und Datenanalyse.

Schubert, Ulf Ulf Schubert ist Leiter User Experience bei DATEV eG in Nürnberg. Zu seinen Aufgabenbereichen gehören u. a. die anwenderorientierte Oberflächengestaltung und die User Experience der DATEV-Produkte. Zuvor arbeitete er mehrere Jahre als Usability Consultant und User Experience Designer u. a. bei SirValUse Consulting in Hamburg. Er berichtet in seinem User Experience Blog über Neuigkeiten der Branche und den Erfahrungen aus seiner täglichen Arbeit (www.ux-blog.de).

Schulte Strathaus, Rolf Dr. Rolf Schulte Strathaus ist Gründer und Geschäftsführer der eparo GmbH in Hamburg. Er studierte Schiffbau in Hamburg und hat dazu in Berkeley, USA, promoviert. Vor der Gründung von eparo war Rolf Creative Director bei Interone. Weitere Stationen: Key Account Manager für Kabel New Media und Abteilungsleiter bei der Germanischer Lloyd AG. Bei eparo entwickelt Rolf nutzerzentrierte Produktkonzepte für Webservices, Software und mobile Applikationen. Darüber hinaus ist er einer von weltweit sechs zertifizierten Schulungsleitern der Profi-Prototyping-Software Axure. Rolfs professionelles Interesse gilt der Entwicklung erfolgreicher digitaler Produkte und Services und der Rolle der unbewussten Wahrnehmung. Gemeinsam mit Immonet hat Rolf die Immonet iPad App entwickelt, die 2012 von Apple zur zweitbesten iPad-App gekürt wurde. Ein wichtiges Anliegen ist ihm von Beginn an die Einbindung der Nutzer in den Entwicklungsprozess. Mit eparo ist Rolf Mit-Organisator des Hamburger WUD. Er hält regelmäßig Vorträge zu seinen Spezialthemen und vermittelt in Workshops die Grundlagen von Usability und UX.

377

Schuster, Sandra Nach Ausbildung zum IT-Professional an der it akademie bayern, studierte Sandra Schuster Soziologie und Markt-und Werbepsychologie an der LMU München. Schon während des Studiums etablierte sie den Forschungsschwerpunkt „Usability“ in der Münchner Marktforschungsagentur up2date und leitete diesen bis 2008 als Methoden- und Projektverantwortliche. 2009 übernahm sie die Projektleitung für die Entwicklung standardisierter Qualitätssicherungssysteme im Gesundheitswesen bei der medicaltex GmbH. Seit 2010 ist sie bei der facit digital GmbH in München tätig und betreut dort schwerpunktmäßig Kunden aus dem Bereich Gesundheit und Automobil. Außerdem verantwortet sie inhaltlich und strategisch die Positionierungsfelder „Mobile UX“ und „Lean Back UX“.

Seeling, Thomas Thomas Seeling ist seit 2011 wissenschaftlicher Mitarbeiter an der Professur Arbeitswissenschaft & Innovationsmanagements des Institutes für Betriebswissenschaften und Fabriksysteme der TU Chemnitz. Sein Arbeitsschwerpunkt liegt im Bereich der Expertenevaluation.

Sinning, Heike Heike Sinning verfügt über 10 Jahre Berufserfahrung als Software-Entwicklerin und hat berufsbegleitend an der Hochschule Emden/Leer Medieninformatik studiert. Sie schloss das Studium mit dem Bachelor of Science ab. Seit 2011 ist sie im Bereich Usability/User Experience tätig und studiert derzeit weiterhin berufsbegleitend im Masterstudiengang Online Medieninformatik.

Spieth, Jan-Hendrik Jan-Hendrik Spieth arbeitet als Usablity Engineer bei der Audials AG in Karlsruhe. Zu seinen Arbeitsbereichen zählen neben Usability Engineering und User Research auch UI Design, Lokalisierung und Technische Redaktion. Er studierte Informatik mit Schwerpunkt MenschMaschine-Schnittstellen an der Universität Karlsruhe (TH), und sammelte schon während des Studiums erste praktische Erfahrungen als Usability-Experte. Jan-Hendrik Spieth ist Mitglied der German UPA, arbeitet in den AKs "In-house Usability" und "User Research", und ist Mitorganisator der Regionalgruppe Karlsruhe. Wenn er gerade mal offline ist, dann ist er auf zwei Rädern oder zu Fuß irgendwo in der Natur unterwegs.

378

Usability Professionals 2013 Referenten

Stalph, Joachim

Strassl, Peter Peter Strassl, BSc: Studium der Informatik an der Technischen Universität Wien. Senior Interaction Designer bei USECON. Mehr als 7 Jahre Erfahrung im Bereich Usability / User Experience. Beschäftigt sich mit den Themen: User Interface Konzeption im Umfeld Webanwendung, Mobile Eye Tracking, Usability, Durchführung von Trainings.

Strauß, Desdemona Desdemona Strauß ist User Interface Engineer bei der AVM GmbH in Berlin. Sie ist dort für die Konzeption und Gestaltung von benutzungsfreundlichen User Interfaces verantwortlich. In ihrer langjährigen Tätigkeit als Technische Redakteurin entstand und wuchs das Interesse an Usability und User Centered Design – was sie im Jahr 2007 zu artop führte, wo sie berufsbegleitend die Ausbildung zum Usability Consultant absolvierte. Seit 2006 ist Desdemona Mitglied der German UPA und war im gleichen Jahr Gründungsmitglied des Arbeitskreises In-house Usability Professionals.

Thomaschewski, Jörg Dr. Jörg Thomaschewski ist Professor für „Internetanwendungen“ an der Hochschule Emden/ Leer mit den Lehr- und Forschungsschwerpunkten Human Computer Interaction, E-Learning, Softwaretechnik. Er ist Autor verschiedener Online-Module, u.a. „Mensch-Computer-Kommunikation“, das im Rahmen der Virtuellen Hochschule (VFH) an sechs Hochschul-Standorten eingesetzt wird. Er verfügt über umfangreiche Erfahrungen in Usability-Schulungen, Analysen und Beratungen.

379

Tille, Ralph Prof. Ralph Tille studierte Industrial Design an der HfG Pforzheim und ist seit 1997 als selbständiger Designer tätig. Ab 2002 Forschungstätigkeit am Institut für Ergonomie und Designforschung (IED) der Univ. Duisburg-Essen. Für die Daimler AG konzipierte, gestaltete und erforschte er ab 2004 Mensch-Maschine-Interfaces. 2006 Professur für Design an der FH Oberösterreich in Wels. Seit 2007 Professur für Design interaktiver Medien an der Hochschule der Medien (HdM) Stuttgart. Die Lehr- und Forschungsschwerpunkte sind Interaktive Informationsvisualisierungen und Information-Experience.

Trompeter, Jens Jens Trompeter ist Diplom-Kaufmann und Mitglied des Vorstands bei der itemis AG. Als zertifizierter Scrum Master und Scrum Product Owner hat er über viele Jahre agile Projekte in verschiedenen nationalen und internationalen Kundenumfeldern geleitet. Darüber hinaus verantwortet er als Produktmanager die Entwicklung von YAKINDU Requirements und ist als Vorstand bei itemis für die Personalentwicklung und Einsatzplanung verantwortlich.

Tscheligi, Manfred Dr. Manfred Tscheligi: Doktorat der Sozial- und Wirtschaftswissenschaften. Gründer, Eigentümer und Geschäftsführer von USECON. Gründer und Leiter des Forschungszentrums CURE (Center for Usability Research & Engineering). Seit 2004 Professor für Human Computer Interaction & Usability an der Universität Salzburg. Mehr als 25 Jahren Erfahrung im Bereich Usability / User Experience und Human Computer Interaction. Beschäftigt sich mit den Themen: Kontextuelle User Experience, Methoden und Werkzeuge zur Erforschung der Interaktion zwischen Mensch und Maschine

Uhlenbrok, Jan Jan Uhlenbrok schloss nach seinem Studium der Medieninformatik 2010 die Weiterbildung zum zertifizierten Usability Engineer am Fraunhofer Institut erfolgreich ab. Seit Anfang 2011 Teamleiter der Qualitätssicherung- und Usability-Abteilung in einem regionalen Medienhaus, wo er in allen Bereichen nach der Kanban-Methode arbeitet. Schreibt ansonsten in seinem Blog über gute und schlechte Usability, wo immer sie ihm begegnet.

380

Usability Professionals 2013 Referenten

Ullrich, Daniel Daniel Ullrich ist wissenschaftlicher Mitarbeiter im Bereich Arbeits- und Ingenieurpsychologie an der Technischen Universität Darmstadt. Seine Forschungsinteressen liegen im Bereich User Experience, hier der Wahrnehmung intuitiver Interaktion und deren Komponenten sowie in der intuitiven Entscheidungsforschung. Daniel Ullrich hat an der Technischen Universität Darmstadt Psychologie mit Nebenfach Informatik studiert.

Walke, Tobias Tobias Walke ist seit Februar 2008 Usability Engineer bei der User Interface Design GmbH (UID). Seine Haupttätigkeiten liegen in den Branchen Consumer, Automotive, Medical & Pharma und Industry. UID bietet unter dem Markennamen "Medical Safety Design" nicht nur die notwendigen Methoden eines Usability-Engineering-Prozesses an, sondern betreut Hersteller von technischen Medizinprodukten auch bei der Erstellung des Usability Engineering Files. Tobias Walke ist hauptverantwortlich für die kontinuierliche Weiterentwicklung dieser Dokumentation, für die Prozessberatung und übernimmt auch Autorentätigkeiten für Kunden.Tobias Walke ist Mitglied im Tekom, dem deutschen Fachverband für Technische Kommunikation und Informationsentwicklung. Er wirkte als Autor am "CE-Routenplaner" mit, ein Handbuch des TÜV Media Verlags über "Planung, Entwicklung und Realisierung von Medizinprodukten". Als Leiter des Arbeitskreises "Usability in der Medizintechnik" beim Berufsverband German UPA e.V. wirkt Tobias Walke an einer Austauschplattform für Hersteller und Dienstleister dieser Branche mit.

Weber, Markus Dr. Markus Weber leitet den Bereich Usability Engineering der Centigrade GmbH. Er studierte Psychologie an der Universität des Saarlandes, wo er auch mit einer Arbeit zum Thema Eye Tracking im eLearning Kontext promovierte. In seiner Rolle als Usability Engineer befasst er sich unter anderem mit agilen Usability Prozessen und der effizienten Kooperation von Usability Engineers, User Interface Designern und Entwicklern. Seine Tätigkeiten beinhalten die strategische Planung und Durchführung von Anforderungsanalysen, Usability Evaluationen und Interaktionsdesigns, die er in einer Vielzahl von Projekten in verschiedensten Branchen durchführte.

381

Wedl, Christian Christian Wedl ist Student der Technologie-und Managementorientierten BWL an der TU München und Studentischer Mitarbeiter der YOUSE GmbH. In seinem Studium legte er einen starken Fokus auf die Bereiche Technologiemanagement und Produktentwicklung und hat während längeren Praxistätigkeiten in den Entwicklungsabteilungen der EWE AG und der Siemens AG einige Einblicke in die Bereiche Projektmanagement, Produkt- und Business Model Entwicklung gewinnen können. Seit März 2013 ist Christian Teil des YOUSE Teams und freut sich das Thema Produktentwicklung aus Nutzersicht kennen zu lernen. Neben seiner Tätigkeit bei YOUSE versucht er sein Wissen auch in Projekten der Ingenieure ohne Grenzen einzubringen und weiterzugeben.

Weisser, Tina Während ihres Architekturstudiums gründete Tina Weisser eine Branding- und Konzeptionsagentur mit Sitz in München (Starshot GmbH & Co. KG), die sie 10 Jahre leitete. Seit einem zweijährigen Sabbatical ist sie u.a. Lehrbeauftragte an der Gestaltungshochschule Darmstadt (Industrie- und Kommunikationsdesign) und beschäftigt sich mit strategischer User Insightund Designforschung.

Wienen, Markus Dr. Markus Wienen ist User Experience Stratege bei der eparo GmbH in Hamburg. Er studierte Sprachwissenschaft, Kommunikationswissenschaft, Philosophie, Informatik und BWL an den Universitäten Düsseldorf und Greifswald. In seiner Promotion hat er sich mit den Bedingungen für erfolgreiche Kommunikation befasst. Seine erste berufliche Station war die Agentur G16 Media, wo er für Webservices und den Aufgabenbereich Konzeption und Analyse zuständig war. Bei eparo ist Markus verantwortlich für die Usability- und User Experience Tests und für die Entwicklung neuer Analyse- und Testverfahren zur Implizit UX. Darüber hinaus ist er in den Bereichen Konzeption und Service Design aktiv. Ein besonderes Anliegen ist ihm die enge Verbindung von User und Brand Experience. Für eparo hält Markus regelmäßig Vorträge und richtet Workshops aus.

Winter, Dominique Dominique Winter arbeitet als Senior Produktmanager bei der Buhl Data Service GmbH. Seine derzeitigen Schwerpunkte sind User Experience Design und Softwarekonzeption im Bereich Vereinsmanagement. Zuvor war er bei der GreenPocket GmbH verantwortlich für die Haushaltskundenprodukte im Bereich Smart Metering und Smart Home. Davor war er an der Universität zu Köln in verschiedenen DFG- und EU-Projekten verantwortlich für Softwarekonzeption, Barrierefreiheit und Usability-Engineering. Zudem ist er Mitglied einer Forschungsgruppe der HS Emden/Leer und beschäftigt sich hauptsächlich mit der Vereinbarung von User Experience, Innovationsmanagement und Produktmanagement.

382

Usability Professionals 2013 Referenten

Woletz, Natalie Dr. Natalie Woletz arbeitet als Programmleiterin User Centred Design bei der T-Systems International. Sie ist dort für die Usability verschiedener IT-Anwendungen aus dem Bereich Customer Relationship Management, Sales, Marketing und Finance zuständig. Ihre besonderen Interessen gelten der Integration des User Centered Design Prozesses in die Software-Entwicklung sowie der Bewertung und Verbesserung der Usability Reife von Organisationen. Zu diesen Themen hat sie 2006 auch ihre Doktorarbeit verfasst. Dr. Natalie Woletz ist seit vielen Jahren Mitglied der German UPA und leitet seit September 2010 den Arbeitskreis In-house Usability Professionals.

Wolter, Sascha Sascha Wolter (http://wolter.biz) studierte Informatik und Psychologie mit dem Schwerpunkt Benutzungsschnittstellen an der Universität Paderborn und hielt anschließend Gastvorträge und Lehraufträge an Hochschulen sowohl im Bereich der Informatik als auch zu Themen rund um Vorgehensmodelle (Prototyping) und dem Benutzererlebnis. Er ist Experte für die Planung und Umsetzung von reichhaltigen und plattformunabhängigen sowie geräteübergreifenden Anwendungen (Desktop, Mobil, Web und M2M). Seit 1995 arbeitet er als Berater, Autor, Trainer, Entwickler und Software-Architekt für zahlreiche Firmen. Darunter Adobe, Deutsche Telekom, Microsoft, SAP und Vodafone. Sascha ist ebenfalls durch zahlreiche internationale Vorträge, Bücher, Artikel und Lernvideos bekannt. Als Gründer der Adobe User Group flashforum.de mit mehr als 100.000 Mitgliedern und als Mitgründer der international bekannten Konferenz beyond tellerrand engagiert sich Sascha auch für die Belange der Anwender. Seine Arbeit wurde von zahlreichen Magazinen und Fernsehsendern erwähnt, darunter wired. com, SPIEGEL ONLINE, Discovery Channel und ZDF. Wenn er nicht gerade als Developer Evangelist neue technische Möglichkeiten für den Developer Garden der Deutschen Telekom (Products & Innovation) erkundet, dann spielt er in seiner Freizeit mit seinen Kindern Lego.

Wüst Steffen Steffen Wüst ist seit 2006 Senior Consultant und Projektleiter der chilli mind GmbH in Kassel und dort schwerpunktmäßig für die Bereiche Strategie-, Produkt- und Geschäftsmodellentwicklung sowie Usability und User Experience zuständig. Der Projektfokus liegt hierbei auf den Bereichen Health Care, Erneuerbare Energien, Telekommunikation und Elektronische Haustechnik. Nach seiner Ausbildung als Goldschmied und mehreren Jahren Berufserfahrung im In- und Ausland studierte Steffen Produktdesign mit Schwerpunkt Systemdesign an der Universität Kassel.

383

Wulf, Insa Insa Wulf setzt sich seit Ihrem Studium 2008 im Fachbereich Informationsdesign an der Hochschule der Medien Stuttgart verstärkt mit dem vielfältigen Einsatz von Medien im Bereich Informationsvermittlung, Usability und Computerspielen auseinander. Seit 2012 arbeitet sie als Trainee Interaktionsdesign im Bereich Medical Usability Engineering bei der User Interface Design GmbH.

Zander, Vicky Vicky Zander studierte Kommunikations-Psychologie an der FH Zittau/Görlitz. Im Anschluss arbeitete sie in verschiedenen Agenturen als Informationsarchitektin an der Konzeption digitaler Anwendungen. Aktuell ist sie bei der Vaillant GmbH in der Zentrale als „Manager for Digital Marketing & User Experience“ tätig. Zu Ihren Hauptaufgaben zählen die Sammlung der internationalen Business- und Nutzeranforderungen, die Schaffung der darauf aufbauenden gruppenweiten Standards, die Schulung der Kollegen in den jeweiligen Märkten und die Auswahl der dafür unterstützenden Dienstleister.

384

Impressum

Herausgeber: Henning Brau, User Interface Design GmbH Andreas Lehmann, lemisoft Kostanija Petrovic, Nokia Matthias C. Schroeder, UCDplus GmbH

Programmkomitee: Henning Brau, User Interface Design GmbH Dr. Sarah Diefenbach, Folkwang Universität der Künste Carolin Flesch, SAP AG Susanne Hanst, proALPHA Software AG Dr. Rüdiger Heimgärtner, Intercultural User Interface Consulting (IUIC) Jochen Heyden, artop GmbH – Institut an der Humboldt-Universität zu Berlin Jana Hinze, German UPA Oliver Kluge, Versicherungskammer Bayern Dr. Dennis Krannich, TZI, Universität Bremen Malte Krökel, User Interface Design GmbH Andreas Lehmann, lemisoft Malte Sönksen, artop GmbH – Institut an der Humboldt-Universität zu Berlin

Inhaltliche Betreuung der Artikel: Henning Brau, User Interface Design GmbH Dr. Sarah Diefenbach, Folkwang Universität der Künste Carolin Flesch, SAP AG Susanne Hanst, proALPHA Software AG Dr. Rüdiger Heimgärtner, Intercultural User Interface Consulting (IUIC) Steffen Hess, Fraunhofer Institut für Experimentelles Software Engineering IESE Jochen Heyden, artop GmbH – Institut an der Humboldt-Universität zu Berlin Oliver Kluge, Versicherungskammer Bayern Kostanija Petrovic, Nokia Malte Sönksen, artop GmbH – Institut an der Humboldt-Universität zu Berlin Natalie Woletz, Deutsche Telekom AG

Kontaktadressen German UPA e.V. Leitzstraße 45 70469 Stuttgart Telefon +49 (0)711 490 66 – 117 Telefax +49 (0)711 490 66 – 118 E-Mail: info@germanupa.de URL: www.germanupa.de

Layout und Gestaltung genese Werbeagentur GmbH, Magdeburg

Herstellung und Verlag German UPA e.V., Stuttgart copyright by German UPA e.V., 2013 Alle Rechte vorbehalten Dieses Werk ist einschließlich aller seiner Teile urheberrechtlich geschützt. Jede Verwertung, die über die engen Grenzen des Urheberrechtsgesetzes hinausgeht, ist ohne schriftliche Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen sowie die Speicherung in elektronischen Systemen. Die Wiedergabe von Warenbezeichnungen und Handelsnamen in diesem Buch berechtigt nicht zu der Annahme, dass solche Bezeichnungen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und deshalb von jedermann benutzt werden dürften. Soweit in diesem Werk direkt oder indirekt auf Gesetze, Vorschriften oder Richtlinien (z. B. DIN, VDI) Bezug genommen oder aus ihnen zitiert worden ist, kann der Verlag keine Gewähr für Richtigkeit, Vollständigkeit oder Aktualität übernehmen.

385

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

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

Usability Professionals 2013