Usability Professionals 2013 - Tagungsband

UsabilityProfessionals2013

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

Usa

bilit

y Pr

ofes

siona

ls 20

13

German UPA e. V.Leitzstraße 45 | 70469 Stuttgart

www.germanupa.de

Konferenzsponsoren

Sponsoren

German UPA Förderkreis

u s e r s ́ ´

2

Workshop12 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

Inhaltsverzeichnis

3

Tutorial50 Qualitätsmanagement nach ISO 9001 im UX Engineering –

Ein Ansatz auf Basis des Qualitätsstandards der German UPA Henning Brau

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

Florian Geyer, Jens Trompeter, Michael Jendryschik

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

Bernard Rummel

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

Dominique Winter, Jens Pietschmann

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

Maria Rauschenberger, Martin Schrepp, Jörg Thomaschewski

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

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

Cross Plattform UX86 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

4


Inhalt

Inhouse & Zulieferer Kooperation98 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 UX116 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 Practices138 Best Practice Tele-Medizintechnik Total-User-Experience-

Design für ein gesamtheitliches Blutzuckermess-System Oliver Gerstheimer

5

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

Michael Burmester, Ralph Tille

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

Natalie Oster, Markus Kühner, Jan Groenefeld

Industrie UX 162 Interfacekonzept für einen „Role Based Client“

als Anwendung im gesamten Produktlebenszyklus Ralph Tille, Michael Burmester

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

Oliver Gerstenheimer

180 Human Centered Design für Prozessleitsysteme in der Industrieautomation

Peter Hartmann, Maike Petzold

User Research188 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

6

UX Integration208 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 Designanforderungen226 Voice Control um jeden Preis? Theoretische und praktische

Grund lagen für erfolgreiche Sprachsteuerungs-Angebote aus User Experience-Sicht

Sandra Schuster

232 „Ich würde jetzt anrufen.“ – Webshops aus Sicht älterer Nutzer Cornelia Schauber, Christoph Nedopil, Sebastian Glende, Tina Weisser, Christian Wedl

Enterprise / Government UX240 „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


Inhalt

7

Branchentrends264 Branchenreport UX/Usability 2013 Sarah Diefenbach, Nina Kolb, Daniel Ullrich

274 Mit Interface Design ein Markenprofil stärken Manfred Dorn

Kurzvorträge282 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

8

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

Referenten356 Referenten

Impressum385 Impressum


Inhalt

9

10

Workshops

11

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

Paul MüllerAgentur Siegmund GmbHLeuschnerstraße 370714 [email protected]

Benjamin LaukenmannAgentur Siegmund GmbHLeuschnerstraße 370714 [email protected]

Haltestellen im Testbetrieb laufenden „On the Go! Travel Station“. Das System in New York stellt allerdings nur eine zusätz-liche Informationsquelle zu den herkömm-lichen Aushängen dar. Die Zukunftsvision sieht dagegen vor, alle Informationen an Haltestellen, welche bisher auf Papier ver-fügbar waren, nur noch digital und eventu-ell 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 papier-lose Haltestelle vorgestellt. Diese war im Vorfeld unter der Anwendung verschiede-ner Methoden, darunter Fokusgruppen, Feldbefragungen und Nutzertests, durch-geführt worden. Die Anforderungsanalyse, der erste Schritt im User Centered Design Prozess, ist mittlerweile abgeschlossen. Als Ergebnis entstand ein Anforderungskata-log, der nun in Zusammenarbeit mit den Partnern der Studie, neben der SSB AG noch sechs weitere deutsche Verkehrsun-ternehmen, in eine offizielle Schrift des

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 Bushaltestel-len finden sich beispielsweise bereits in Dresden oder der Region der Salzburger Seenlandschaft. Dabei handelt es sich allerdings meist um ein passives Aufneh-men 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 mehre-ren 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

Verbands Deutscher Verkehrsunternehmen (VDV) münden wird. Nun steht Phase 2, die Konzeption eines Fahrgastinformations-systems an, welches die in Schritt 1 gesam-melten Anforderungen erfüllen soll.

Im Zentrum der durchgeführten Stu-die standen dabei Fragestellungen wie beispielsweise: – Wie stehen Fahrgäste grundsätzlich zu der Vision der papierlosen Information an Haltestellen?

– Welchen Mehrwert bieten digitale Infor mationssysteme für Fahrgäste und Verkehrsbetriebe?

– Wie sehen die gängigsten Nutzungsszenarien im Umgang mit Pa pieraushängen an Haltestellen aus und was bedeutet dies für zukünftige digitale Systeme?

– Welche Anforderungen und Erwartungen haben Fahrgäste an digitale Informationssysteme wie z.B. Touch-Displays?

– Wie gut sind bestehende Systeme und Prototypen digitaler Informationssysteme bedienbar?

AbstractDie Vision im modernen ÖPNV: Touch-Displays oder ähnliche Systeme ersetzen zukünftig die klassischen Papieraushänge an den Haltestellen – Fahrgastinformationen wie Fahr-plä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 Informations-vitrine dienen soll. Ziel des Workshops ist es, alternative oder ergänzende Informations- und Interaktionssysteme anzudenken und zu diskutieren. Hierzu werden die wichtigsten Erkenntnisse aus der Anforderungsanalyse als Grundlage in die Diskussion eingebracht.

Papierlose Fahrgastinformation im ÖPNV: Die Vision einer Haltestelle der ZukunftKonzeption neuer digitaler und interaktiver Informations systeme für Fahrgäste im ÖPNV

12


Workshop

Um diese Fragen zu beantworten, wur-den 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 Grup-pendiskussionen an die Vision der papier-losen 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 Stutt-gart wurden Feldbefragungen von Fahr-gästen durchgeführt, sowie Nutzungsdaten bestehender Livesysteme analysiert und ausgewertet. Um zu verstehen, welche Informationen durch ein digitales Informa-tionssystem an Haltestellen zur Verfügung gestellt werden müssen, wurde den Fahr-gästen bei der Suche nach Informationen an klassischen Papieraushängen über die Schulter geschaut. Durch anschließende Befragungen wurde ermittelt, welche Infor-mationen im Rahmen welcher Nutzungs-szenarien 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 elektro-nischen 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 Optimierungs-empfehlungen abzuleiten. Ergänzt wurden diese Ergebnisse außerdem durch ein Experten-Review, in welchem der Pro-totyp der elektronischen Vitrine anhand gängiger Usability-Prinzipien und typischer Handlungsabläufe evaluiert wurde.

Die Ergebnisse der Studie lieferten wert volle Erkenntnisse für die weitere

Entwicklung des Konzepts der papierlosen Information an Haltestellen. Die Optimie-rungsempfehlungen für die Gestaltung der elektronischen Vitrine werden aktuell in einem neuen Prototypen umgesetzt, der als Basis für zukünftige Nutzertests dienen wird. Beispielsweise könnte das Interface des überarbeiteten Touch-Sys tems im nächsten Schritt im Rahmen eines Pilottests an einer ausgewählten Haltestelle erstmals alle Fahrgastinforma tionen in Papierform komplett ersetzen, um wei tere Erkenntnisse zur Akzeptanz und Nutzungsbereitschaft solcher Systeme zu gewinnen.

Die im Verband Deutscher Verkehrsunter-nehmen (VDV) von den Projektpartnern gemeinsam erarbeitete VDV-Mitteilung zum Thema „Papierlose Aushanginforma-tion an ÖPNV-Haltestellen“ befindet sich momentan in Vorbereitung. Sie wird die ausführliche Dokumentation der Gemein-schaftsstudie und Empfehlungen für die Benutzeroberfläche, die Informationsin-halte und Nutzungsszenarien für die elekt-ronische Aushanginformation an Haltestel-len 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 Informati-onssystem aussehen, welches dort einge-setzt wird?“ Nach dem Input, den Erkennt-nissen aus der Studie, sollen anschließend im zweiten Teil anhand verschiedener Mög-lichkeiten (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ög-lichkeit 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 ein-stellen, intuitive und gebrauchstaugliche Interaktionskonzepte erarbeiten und die verschiedenen Nutzungskontexte sowie die definierten Anforderungen aus der Anfor-derungsanalyse 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ür-fen einsteigen – hier wird der spezielle Mix aus den Erfahrungen und dem Wissen von Experten und Nichtexperten verschiedens-ter Disziplinen voraussichtlich zu interessan-ten Ergebnissen führen. Die Motivation für die Teilnehmer des Workshops ergibt sich

13

dabei aus der persönlichen Betroffenheit: Da die digitale Haltestelle in absehbarer Zeit von diversen Verkehrsbetrieben reali-siert werden wird, haben sowohl Gelegen-heitsnutzer als auch Vielnutzer von Bus und Bahn ein berechtigtes Interesse daran, dass diese sowohl eine hohe Gebrauchstaug-lichkeit als auch ein modernes Design und nützliche Features aufweist.

Weiterführende Links1. http://www.agentursiegmund.de/

pdf/referenzen/die_haltestelle_der_

zukunft_2013.pdf

2. http://www.popsci.com/gadgets/

article/2011-09/hands-mtas-go-mobile-

station-47-inch-travellers-touchscreen

3. http://youtu.be/4z99zEbNvOw

4. http://youtu.be/jZkHpNnXLB0

14


Workshop

15

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

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

Eva RügenhagenSAP AGDietmar-Hopp-Allee 1669190 [email protected]

Dr. Theo HeldSAP AGDietmar-Hopp-Allee 1669190 [email protected]

Die Anwendung von Spielmechanismen im User Research – Level up oder Epic Fail?Workshop zur Relevanz und Anwendbarkeit von Spiel -mechanismen in User Research Methoden

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

1. Vorüberlegungen1.1 Problembeschreibung

Viele Usability Professionals haben – ne ben dem Abliefern von qualitativ hoch wertigen Services und belastbaren empirischen Daten – den Anspruch, ihre Leistungen in benutzerfreundlicher Art und Weise anzu-bieten. Frühes Einbeziehen des Projekt-teams und eine klare Formulierung von Research-Ziel, Vorgehensweise und Ab schluss bericht sind wichtige Bestand-teile in der Umsetzung dieses Anspruchs (siehe Tomer, 2012).

Diese Vorgehensweise erhöht die von den Mitgliedern des Projektteams

antizipierten Arbeitsaufwand führt, wenn das Feedback der Anwender dann tat-sächlich umgesetzt werden soll. Dies kann in der Summe dazu führen, dass die hohe Akzeptanz der Ergeb nisse, die durch die aktive Teilnahme der Projektteams zu Beginn des Tests ent standen ist, bereits bei der Ergebnispräsen tation stark gesunken ist. Dies führt gleichermaßen zur Frustration auf Seiten des Usability Professionals und des Projektteams.

Mehrere Ansätze sind denkbar, wie diese Situation verbessert werden könnte. Neben Modifikationen an der Methode kann eine Herangehensweise hierfür auch sein, das methodische Vorgehen inhaltlich so zu belassen wie es ist, aber die emo-tionale Bindung des Projektteams an die

16

Methode und deren Ergebnisse durch Ver änderungen in der Umsetzung zu stei-gern. 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 Gamification Design und Game Design

Der Begriff Gamification beschreibt die Anwendung von Spielattributen auf spiel-fremde Kontexte. Dieses Vorgehen wird nicht mehr nur im Bereich von Kunden-bindungsprogrammen genutzt, sondern gewinnt auch in der Softwareentwicklung stetig an Bedeutung. Die stärkere Verbrei-tung von Gamification und die breitere Fächerung möglicher Use Cases kommen nicht zuletzt durch das wachsende Ange-bot an Gamification-Plattformen zustande. Denn um Spielmechanismen in die Soft-wareentwicklung zu integrieren, ist es not-wendig, 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 Qualifikations-portfolio von Projektteams anzutreffen ist, gestaltet sich dies im Projektalltag schwie-rig (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 beispiels-weise Badgeville zur Aufgabe gemacht. Sie bieten an, Spielmechanismen in Pro dukte einzubinden, ohne dass eine zusätzliche Qualifikation ‚Game Design‘ im Projektteam vorhanden sein muss. Den Nutzern wird eine ‚User Experience der nächsten Generation‘ versprochen, die sich nicht nur auf Soziale Medien, sondern auch auf Lösungen für Produktentwicklung und Geschäftsprozesse erstreckt (siehe

Badgeville Inc., 2012). Mit derartigen Ver-sprechen stellen Gamification-Plattformen einen Bezug zum Tätigkeitsfeld des Usabi-lity Engineering her, so dass eine Prüfung deren Relevanz entsprechend sinnvoll erscheint.

Beleuchtet man die hier zur Anwendung kommenden Techniken jedoch näher aus der Perspektive des Game Designs wird deutlich, dass der Begriff der Gamification stark geprägt ist von Spielattributen wie Auszeichnungen und Punktesystemen. Zwar werden dem Spieler hier durch die verwendeten Techniken integrale Vortei le des Game Designs geboten, wie beispiels-weise klare Zielsetzung und transparente Feedback-Mechanismen; auch werden so ziale Aspekte gestärkt wie beispiels-weise 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ög-lichkeiten), „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 einge-schränkt befriedigt werden. Entsprechend heftig wird darüber diskutiert, inwieweit sich über haupt Techniken des Gamification Designs sinnvoll anwenden lassen können (siehe McGonigal, 2011 und Herger, 2013),

Im Kontext des eingangs beschriebenen Problems stellte sich also auch in unse-rem 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 Pro-zess 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 Erzeu-gung 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 Dis-kussion wird von Salen und Zimmermann (2004) sowie McGonigal (2012) ausführ-lich beleuch tet; basierend darauf hat sich für unsere Projektarbeit eine Reduktion auf die folgenden Komponenten als hilfreich und gut anwendbar erwiesen. Demnach bezeichnet ein Spiel einen Raum, den der Spieler freiwillig betritt und in dem es gilt den Weg zu einem bestimmten Ziel unter Anwendung der in diesem Raum gelten-den Regeln zu erreichen. Das Besondere dabei ist, dass das Ziel nicht auf direktem Weg erreicht werden kann, sondern es ein unnötiges Hindernis gibt, dessen Um gehung den Spielern kreative Problem-lösungsstrategien abfordert. Feedback-Mechanismen 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 errei-chen, weder zu leicht noch zu schwierig gestaltet ist.


Workshop

17

2. Anwendung von Spielmechanismen auf User Research Methoden:2.1. Möglichkeiten

Um eine Annährung von Spiel und User Research Methoden zu ermöglichen haben wir im Zuge unseres Projekts überprüft, ob die Anwendung von User Research Metho-den überhaupt dafür geeignet sein könnte, ein Spielerlebnis hervorzurufen. Diese Über-legungen 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 überarbei-ten und dadurch von einer Steigerung des Spaßfaktors profitieren zu können.

So ist beispielweise das abstrakte Ziel, eine Verbesserung der Usability eines User Inter face zu erreichen, den Teilnehmern zu Beginn häufig klar und meist Anlass dafür, den Raum ‚Usability Test‘ zu betreten. Dass dieser Weg nur über das Zwischenziel ‚Probleme werden identifiziert‘ und ‚Erar-beiten 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, letzte-res erhebt den Anspruch einer klaren Ziel-setzung. Eine Steigerung der hedonischen Qualität durch bessere Detaillierung der Zwischenziele und Spielregeln des Usa bi-lity Test scheint hier denkbar.

Auch gibt es für Usability Tests keinen leicht durchdringbaren Feedback-Mecha-nismus, der den Teilnehmern deutlich macht, wann sie das Meta-Ziel einer besse-ren Usability erreicht haben und der Raum des Usability Tests erfolgreich wieder verlassen werden kann. In Spielen wird der Spieler durch Punktzahlen, visuelle Anzei-gen oder akustische Signale über seinen Status informiert. In Usability Tests hinge-gen 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 viel fäl-tigen Ansatzpunkte, wo durch die An wen-dung von Spielkonzepten Inspiration für Ver besserungen gewonnen werden kann. Dies kann möglicherweise sogar erreicht werden, ohne dass ein spielerischer Ansatz im Projektteam Anwendung findet, da hier bereits ein Diskurs unter Usabi-lity Professionals neue Blickrichtungen ermöglichen kann.

Wendet man zusätzlich Lazzaros Ergeb-nisse zu den vier emotionalen Kompo-nenten 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 Erkenntnisge-winn durch einen Usability Test spieler isch transparent gemacht wird. Die Kompo-nente des ‚People Factor‘ kann gestärkt werden, indem das Projektteam stärker gemeinschaftlich auf das Ziel einer bes-seren Usability hinarbeitet indem es Usability Probleme besiegt – oder aber man fokussiert auf die Komponente ‚Hard Fun‘ und ermöglicht den Teilnehmern einen _Triumph über Kollegen durch eine möglichst genaue Hervorsage des Ergeb-nis des Usability Tests. 2.2. Risiken

Lässt man sich auf die Analogie des Usa-bility Tests als Spiel ein stellt man schnell fest, wie vielfältig die Möglichkeiten der Anwendung von Spielmechanismen auf existierende User Research Methoden

sind. Dies zeigte sich bereits in unserem Projekt, genauso birgt dieser Ansatz je doch auch Risiken. Nachfolgend wollen wir auf einige Schwierigkeiten eingehen, die es zu berücksichtigen gilt.

Ein Risiko bei der Anwendung von Spiel-mechanismen kann darin bestehen, das komplexe Zusammenspiel von Spielme-chanismen, Spieldynamik und emotiona-len 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 bei-spielsweise dazu auf, die Mechanismen einfacher Spiele systematisch zu verän-dern, um ein Gespür für die Auswirkungen der Modifikationen zu entwickeln (Fuller-ton, 2008). Hunicke, LeBlanc und Zubek (2004) schlagen einen formalen Ansatz zum Design von Spielen vor, der entgegenge-setzt zur Spielererfahrung verlaufen sollte. Demnach gestaltet sich die Spielerfah-rung des Spielers derart, dass zunächst die Spielmechanismen beispielsweise in Form einer Spielanleitung wahrgenommen werden, sich durch deren Anwendung eine Spieldynamik entwickelt und diese dann in einem ästhetischen Empfinden resultiert. Der Game Designer solle jedoch genau um gekehrt vorgehen, um gezielt eine Spiel erfahrung zu ermöglichen, die auf seine Spielergruppe ausgerichtet ist.

Dieser Ansatz erwies sich zunächst als hilf-reich, da es sich bei der ‚Spielergruppe‘ für User Research Methoden um Projektmit-glieder handelt, deren Kontexte und spe-zi fische Erwartungshaltungen an eine im professionellen Umfeld durchgeführten Test berücksichtigt werden müssen. Darü-ber hinaus ermöglicht ein Beginn bei der Spielästhetik eine Stärkung wünschenswer-ter emotionaler Qualitäten oder aber eine Schwächung negativer Emotionen. Nichts-destotrotz haben wir in unserem Pro jekt erfahren, dass dieser Ansatz nur bedingt vollständig umgesetzt werden kann. So haben wir die Idee, die emotio nale Qualität eines Fußballtippspiels nutzen zu wollen, als hilfreich empfunden, da ein Fußballtipp-spiel in vielen SAP- Büros durchgeführt wird

18


Workshop

und somit sicherge stellt ist, dass dies die Zielgruppe ansprechen könnte; auch liefert die Analogie viele Inspi rationen zur Detail-lierung 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 Spielme-chanismen konkret ausdetailliert werden müssen, wie beispielsweise die Gewichtun-gen der einzelnen Usability-Tipps festzu-legen, 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 Desig-nprozess 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 dahin-gehend 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 menschli-chen 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 Gewinnkom-ponente, 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öglich-keit, 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 Visuali-sierung verlockend ist.

Die beschriebene Nutzung eines Design-Themas 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öglich-keiten und Risiken birgt. Hilfreich ist ein Thema, um initiale Überlegungen anzustel-len 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 zwin-gend 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 entsprechen-den 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 thema-tische 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 hedoni-schen 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 Umset-zung vermitteln zu können, stellen wir die bis dahin vorliegenden Ergebnisse eines Projekts vor, das die SAP Inhouse User Research Abteilung im Juli 2012 begonnen hat. Im Rahmen dieses Projekts werden Spiele entworfen, die User Research Me tho den um eine Spielkomponente erwei tern sollen. Pilotprojekt war ein Tippspiel, das im Rahmen eines Usability Tests durchgeführt werden kann. Spieler-ziel ist es, einen möglichst treffenden Tipp darüber abzugeben, welche Usability-Test-Tasks von den Usern erfolgreich durchge-führt werden können, ob eine Hilfestellung durch Moderator-Assists nötig ist, und welche Funktionalitäten die größten Stol-persteine 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 Entwick-lungsteam-Mitglieder ihre Expertise im Bereich Usability in einem möglichst freund schaftlichen Wettstreit unter Beweis stellen können.

Darüber hinaus können aber auch Ziele verfolgt werden, die spielferne Kontexte betreffen: – der Usability-Professional kann ein besseres Bewusstsein des Projektteams für die Methode schaffen

– Projektteammitglieder, die an einzelnen Sessions teilnehmen, können

19

stärker motiviert sein, diese auch mit auszuwerten

– Projektteammitglieder, denen eine Teilnahme am Test nicht möglich ist, werden durch das Abgeben eines Tipps von Beginn an stärker in das Resultat involviert

– das komplette Team kann von einer Veränderung der Teamdynamik dahingehend profitieren, dass Stimmen von Projektteammitgliedern, die sonst weniger Gehör finden, durch eine gute Einschätzung des Anwenderverhaltens verstärkt als relevant wahrgenommen werden können

– nicht zuletzt kann die Gruppe der Endanwender profitieren, da nicht nur prägnante Zitate stärker verbalisierender Testteilnehmer beim Projektteam im Gedächtnis bleiben, sondern auch die summative Komponente qualitativer Methoden stärker ins Bewusstsein des Projektteams gerückt werden kann.

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

Im letzten Teil des Workshops soll erar-beitet werden, in welchen User Research Methoden die Anwendung von Spielme-chanismen noch denkbar und sinnvoll sein könnte.

Das Resultat des Workshops ist eine Ideen-sammlung, die zu einem weiteren Diskurs in der Community der Usability Professio-nals führen kann.

Literatur1. 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://enterprise-

gamification.com/index.php/de/

blog/4-blog/120-the-framing-problem-of-

gamification-criticism

6. Hunicke, R., LeBlanc, M. & Zubek, R. (2004).

MDA: A Formal Approach to Game Design

and Game Research. Game Design and

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_

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

without gamification. Presentation at GDC

2011. (http://goo.gl/9a6ka).

10. Tomer, S. (2012). It’s Our Research. Waltham,

MA, USA: Morgan Kaufmann.

11. Salen, K. & Zimmerman, E. (2004). Rules

of Play: Game Design Fundamentals.

Cambridge, MA, USA: Massachusetts

Institute of Technology.

12. Schell, J. (2008). The Art of Game Design:

A Book of Lenses. Burlington, MA, USA:

Elsevier.

20


Workshop

21

Keywords: /// Strategie/// Change/// Herausforderungen

der UX Integration

AbstractViele 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 Unterneh-men 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 Land-schaft 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.

Jana Löffl erartop – Institut an der Humboldt-Universität BerlinChristburger Str. 4, 10405 Berlinloeffl [email protected]

Knut Polkehnartop – Institut an der Humboldt-Universität BerlinChristburger Str. 4, 10405 [email protected]

Jens Hüttnerartop – Institut an der Humboldt-Universität BerlinChristburger Str. 4, 10405 [email protected]

Für die erfolgreiche Etablierung von UX Prozessen in Unternehmen sind Werkzeuge und Landkarten nötig

In Workshops, die wir mit UX-Verantwort-lichen 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 Zeit-spannen 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 unerreich-bare 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 UX-Verantwortliche, 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

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 prag-matischer 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 ein-takten zu können, führt in die Irre. Von ihr getrieben, erleben sich UX Professionals im „Hamsterrad“. UX- und agile Prozesse müssen synchroni-siert werden. [Abb. 1]

Erfolgreiche Usability & UX in UnternehmenThesen und Erfolgsfaktoren zu Usability/UX-Prozessen, Strategie und Change

Abb. 1. Synchronisation der Prozesse

22

Im Fallbeispiel ist dies jedoch noch nicht die einzige Schwierigkeit der Integration von UX.

Wie in vielen anderen eCommerce Unter-nehmen 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 Entwick-lung neuer Features seien „Ideen, die dem product owner unter der Dusche kom-men“. 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 UX-Perspektive hört man dann: „Wir müssen eben pragmatischer werden.“ Oder „Die sollten uns mehr fragen.“ Diese Perspek-tive greift zu kurz und mit reinen Auffor-derungen 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 Flug-hö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

Erfolgs kriterien z.B. Umsatzsteigerung, Kostenminimierung, Innovation, gesell-schaftliche 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 Ziel-größen wichtig ist, ist das Modell auch ein möglicher Kompass für die erfolgreiche Inte-gration von UX. So sollte das „Experimentie-ren 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 proble-matisch. Zwar sah der „blueprint“ des agilen Prozesses den Kundennutzen als wichtiges Element an. Jeder Entwicklungsschritt begann mit einer Phase, in der dieser ein-geschätzt werden sollte. Jedoch wurden im reellen Prozess kaum Ressourcen für Aktivitä-ten zur Erarbeitung des Kundennutzens allo-kalisiert, 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 Pro-jekten über diesen nachzudenken. Während der Produktentwicklung entfi el also ein Teil der Perspektive „Mensch“. Chancen wurden vertan. Zudem gab es beim Auf treten von Zielkonfl ikten aufgrund der Rollenverteil-ung keine tragfähige Instanz. Die Produkt-verantwortlichen verstanden sich eher als Erfi nder 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äl te“ – 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 unter -schiedlicher 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 Integra tion der drei Perspektiven Business, Tech no logie & Benutzer in Prozessen und Struk turen (Entscheidungen, Hierarchien) von Unter-nehmen 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 gemein-samen 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

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


Workshop

Abb. 2. Integration der Perspekti-ven Business, Technologie und Mensch für erfolgrei-che Produkte

23

Benutzermodelle ab. Der CEO berich-tete, ü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 hat-ten z.B. noch nie mit Mental Models und anderen Outputs gearbeitet, daneben gab es Vorbehalte über den Einsatz der Infor-mationen. Es gab keinen Prozessschritt und keine Methode, die intern halfen, die Informationen in den Entwicklungsprozess einzuarbeiten.

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

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 manch-mal aus der individuellen Initiative von Per-sonen 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 Aktivi-tä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.

TopDownIntegration

Bei der Top-Down-Integration hat das Top-Management UX als zentrales Handlungs feld

Unternehmen stellen sich oft gar nicht die Frage: „Wie bekommen wir den HCD Prozess systematisch integriert?“. Deshalb ist es ist aus unserer Erfahrung in Beratungs-projekten 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 beschrie-ben werden? Usw.“ In einem solchen aktivi-tätsbasierten Ansatz nähern sich Unterneh-men Schritt für Schritt der UX Integration. Sie lernen, dass UX ein Qualitätsmerkmal ist und sie einen Bedarf an solchen Prozesse haben.

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

Von internen UX Verantwortlichen und uns als externen Beratern erfordert das auch Ab grenzung und Geduld. Der Wunsch, mög-lichst zeitnah gute UX auf hohem Niveau zu machen, wird teilweise stark frustriert. Eine gute Auftragsklärung ist hilfreich, um UX-Pro-jekte, erst recht mit wenig Ressourcen, zum Erfolg zu führen: Geht es darum, eine Dienst-leistung zu erbringen (z.B. User Research)? Geht es darum, auf die nächste Entwick-lungsstufe 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 UBoote

In einem e-Commerce Unternehmen führten wir im Auftrag des CEO und mit dem UX Verantwortlichen eine initiale Kontextforschung durch und leiteten

erkannt und ruft einen Wandel aus. Hier gilt es, die Mitarbeiter zu gewinnen („wake-up“ nach unten) und in einem „Change“ mitzu-nehmen. 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 Unter-nehmensprozesse 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-Down-Integration schon geschehen.

Mit jeder UX Aktivität entsteht bei den Betei-ligten mehr Bewusstheit über das Thema. Ob sich diese auch organisational nieder-schlägt, hängt davon ab, ob UX Maßnahmen in die Sprache der Organisation übersetzt werden (Simon, 2011). Aus der organisatio-nalen Perspektive ist Guerilla UX nur „Rau-schen“. Erst mit der Formalisierung kommt UX in der Organisation an. Sonst läuft es wie bei dem Industrieunternehmen, dessen UX-Spezialisten 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. Usability-Rollen, Usability-Budget) die vom Ausmaß der Usability bzw. UX Integration künden (DAKKS Usability Leitfaden; Studie Usabi-lity 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 heran-ziehen“). Diese „Orte“ sind Voraussetzung, um andere Aspekte der Reife zu erreichen (zum Beispiel vorgelagerte Gestaltung).

24

Deshalb sollten die Reifegradmodelle das Ausmaß der Abstimmung der UX-Perspek-tive 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 Unterneh-men in Kontakt: Produkte, Personen und Prozesse. An Produkten selbst setzen wir durch unser Angebot an Dienstleistungen wie Kontext-Analysen, Anforderungsdefini-tion, 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, bemerk-ten 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 Pro-zesse (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 Ausgangs-punkt 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.

UX Integration braucht Macht – Ansatzpunkt Unternehmensstrategie

Geht es um bereichsübergreifende Pro-zesse in Unternehmen, wird es nötig, dass andere Stakeholder über UX nachdenken, nicht nur „ein paar UX-Verantwortliche“. Es geht um eine strategische Entschei-dung, über die „die Organisation“ nachdenken muss. Das bedeutet, dass an

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

Wie oben berichtet, besteht die Herausfor-derung darin, die Perspektive des Kunden-nutzens 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?“

Nach den Ergebnissen der Studie „Usability in Germany“ nehmen viele mittelständi-sche 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.

Wir haben gelernt, dass es Unternehmen hilft, neben den Zielen selbst auch deren Implementierung zu betrachten. Dann wer-den auch die Strukturen und Prozesse und die Personen und Beziehungen adressiert – wichtige Ebenen, auf denen Veränderun-gen 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.

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

Literatur1. Bundesministerium für Wirtschaft und

Techno logie (2011). Abschlussbericht des

Forschungsprojekts „Gebrauchstauglichkeit

von Anwendungssoftware als Wettbewerbs-

faktor für kleine und mittlere Unternehmen

(KMU)“. Quelle: http://www.usability-in-

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

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

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

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

Boston: Addison Wesley Pub Co. Inc.

10. Simon, F. (2011). Einführung in die

systemische Organisationstheorie (3.

Auflage). Heidelberg: Carl Auer Verlag.

11. Vahs, D., & Leiser, W. (2007). Change

Management in schwierigen Zeiten, Erfolgs-

faktoren und Handlungs empfehlungen für

die Gestaltung von Veränderungsprozessen

(mit CD-ROM, 2. Nachdruck). Wiesbaden:

Deutscher Universitäts-Verlag.


Workshop

25

GUPA-AK-ROI UX Papier zur UP13, Bremen 2013-Sept

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

AbstractDer 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-Kalkulatio-nen zu erstellen, um abzusichern, dass nur Vorhaben realisiert werden, die sich „rech-nen“. Projekte (u.a. auch UX-Aktivitäten) können analog zu sonstigen Investitionen dieser RoI-Logik unterzogen werden. (UX-)Projekte, die die notwendigen Investitio-nen (= Projekt-Kosten lt. Vorkalkulation) nicht innerhalb bestimmter Vorgabezeit-rä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, klei-nen Verschönerungsprojekte mit wenigen Resourcen mehr. Sie unterliegen daher analog zu anderen Vorhaben (= alternative Investitions-Optionen) einem Selektions-prozess der ein risikogewichtetes Portfolio generiert, da oft nur begrenzte Ressour-cen (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 auf-einander 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“ aufeinanderstos-sen, ohne die jeweils andere Sicht tief zu verstehen. Der Aufbau eines gegenseiti-gen Verständnisses für die Sicht der jeweils anderen Perspektive schien sich daher u.a. an Themen rund um RoI festmachen zu las-sen. Im Nov 2011 gründete sich der GUPA-AK-ROI UX (AK-Gründer: Boris Kneisel, Katharina Göring und Andreas Hinderks).

Zielsetzung des GUPA-AK-ROI UX

AK-Ziele sind „Erweiterung der Wissens-basis“ 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-UserRe-search – 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 Plan-RoI, 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 schei-nen 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 Entscheidungs-findung 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

Dr. Boris Oliver KneiselKarlsruher 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 [email protected]

Katharina GöringitCampus Software- und Systemhaus GmbH – a Software AG companyNonnenstrasse 37, DE-042229 [email protected]

26

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

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 Linien-organisation mit fallender Bedeutung. Die Aufstellung solcher Teams für R&D-Aktivitäten ist seit dem Übergang Agiler Entwicklungsmethoden in den Mainstream ein de-facto Standard und schliesst UX-Aktivitäten mit ein.

Unser Vorgehen

Seit AK-Gründung treffen wir uns regel-mässig ca. alle 6–8 Wochen in zentraler Lage im Rhein-Main-Gebiet.

Nächste Schritte

Der AK-ROI UX stellt basierend auf typi-schen Projekterfahrungen RoI-Argumen-tationshilfen 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 Bran-chenreport um ein Kapitel State-of-ROI UX erweitern sollte. Bei erkennbarem Bedarf sollte sich die Diskussion auf die

Generierung entsprechender Surveys und die Organisation bzgl. ROI UX-Erst-Erhe-bung fokussieren.

Literatur1. BIAS, R.G. & MAYHEW, D. J. (2005). Cost-

justifying 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,

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


Workshop

27

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

1. Herausforderungen und Ziele

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

Qualität und Kundenzufriedenheit sowie die Erfüllung industriespezifischer Stan-dards zur Dokumentation und Nachvoll-ziehbarkeit 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 not-wendig, um interaktive Systeme mit einer vorhersagbaren Gebrauchstauglichkeit zu entwickeln (DIN EN ISO 9241–210).Zwei dieser wesentlichen Herausforderun gen – bestätigt durch eine Studie im Auf trag des

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

AbstractSprechen wir Usability/UX Professionals wirklich „eine“ Sprache oder reden wir munter aneinander vorbei? Werden wir von unseren Kunden wirklich verstanden oder hören die-se 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 deutschsprachi-gen Raum und entwickelt dazu ein entsprechendes Glossar. Zudem wurde ein Curricu-lum 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 Kommunika-tionsgrundlage zur informierten Verständigung zwischen Usability-Einsteigern, Usability-Professionals, Projektverantwortlichen, Entwicklern etc.

Holger FischerUniversität Paderborn, C-LABFürstenallee 1133102 [email protected]

Thomas GeisProContext Consulting GmbHVon-Werth-Straße 33–3550670 Kö[email protected]

Rolf MolichDialogDesignSkovkrogen 33660 Stenløse, Dä[email protected]

Oliver KlugeVersicherungskammer BayernMaximilianstraße 5380538 Mü[email protected]

Rüdiger HeimgärtnerIntercultural User Interface ConsultingLindenstraße 993152 [email protected]

Peter HunkirchenFraunhofer FITSchloss Birlinghoven53754 Sankt [email protected]

Knut Polkehnartop GmbHChristburger Straße 410405 [email protected]

„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

28

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, Forde-rungen und Wünsche die Befragten stellen, antworteten 10% der Befragten, dass sie „[…] eine klare Definition des Berufs bildes, möglicherweise auch in Form einer Zertifi-zierung 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 Enginee-ring (Fischer et al., 2012) betrachtet. Dabei zeigte sich, dass Kompetenzen im Bereich Usability weitaus mehr als nur theoretisches Wissen umfassen. Insbeson dere auch prak-tische Fertigkeiten sowie personale und soziale Aspekte, bspw. empathische Kom-munikation oder Perspektivenübernahme, sind von Relevanz. Um einen ersten Schritt in Richtung Zerti fizierung zu ermöglichen, wurde zunächst ein Curriculum entwickelt, auf dessen Basis grundlegende Konzepte und Begriffe im Bereich Usability und User Experience geprüft werden können. Resultierend daraus wurden inzwischen erste Pilot-Zertifizierungen zum „Certified Professional for Usability/UX – Foundation Level (CPUX-F)“ durchgeführt. Struktur und Hintergrund dieser Zertifizierung werden im weiteren Verlauf dieses Beitrages näher erläutert. Dazu bedarf es zunächst der Betrachtung einiger Grundlagen, die als Basis der Zertifizierung dienen.

2. Grundlagen

Wesentliche Dokumente, auf denen das Curriculum als auch das Rahmenkonzept der Zertifizierung zum CPUX-F basieren, sind der German UPA „Qualitätsstandards für Usability Engineering“ (Behrenbruch et al., 2012), die German UPA Fachschrift „Berufsfeld Usability/UX“ (Bogner et al., 2011) sowie existierende Zertifizierungs-programme 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 Arbeits-kreis Qualitätsstandards veröffentlicht. Ziel dabei ist es den Zugang zu interna-tionalen Stan dards zu vereinfachen, so dass Produkt- und Prozessverantwortliche unterschiedlicher Herkunft den Entwick-lungsprozess ver stehen, ihn verankern, aber auch einen konkreten Prozess mit Aktivitä-ten und daraus resultierenden Arbeitspro-dukten beschreiben können. Die Ziel-gruppe des Qualitätsstandards ist divergent und erhebt unterschiedliche Ansprüche an die Durchführung eines menschzentrierten Ge staltungsprozesses. Neben Usability-Professionals, die sich konkrete Handlungs-anweisungen wünschen, gehören auch Auf-traggeber, Aus- und Weiterbildungsinstitute sowie Personen-Zertifizierungsstellen dazu, die Klarheit über benötigte Kenntnisse, Fertigkeiten und Kompetenzen fordern.

Alltägliche Einsatzszenarien aus dem Projekt-geschäft bieten einen leichten Einstieg zu den Inhalten des Qualitätsstandards, indem sie mit den zu berücksichtigenden Abschnit-ten im Dokument verknüpft wurden.

Kern des Dokumentes stellt eine Detail-lierung der einzelnen Prozessschritte dar. Dabei werden sowohl der „Zweck des Pro-zesses“ begründet, wie auch der „Zustand nach [erfolgreicher] Durchführung“ defi-niert. Zudem werden „Empfohlene Aktivi-täten zur Durchführung“ sowie „Arbeits-produkte“ 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 Verantwortlich-keiten besitzen, durchführende Positionen einnehmen oder zumindest informiert werden sollten. Dabei wird unter anderem auch auf das Rollenmodell gemäß der Ger-man UPA Fachschrift „Berufsfeld Usability“ (Bogner et al., 2011) zurückgegriffen.

2.2. Usability Professionals

Gemäß der Fachschrift „Berufsfeld Usa-bility“ (Bogner et al., 2011) ist ein Usa-bility Professional „[…] eine Person, die qualifiziert und methodisch die Anfor-derungen an die Gebrauchstauglichkeit (Usability) interaktiver Systeme (Hardware und Soft ware) herleitet, umsetzt oder deren Um setzung überprüft“. Verglichen mit anderen Berufsbildern ist der Beruf des Usability Professionals eher jung, so dass weder im deutschsprachigen noch im internationalen Raum ein kohärentes Bild der Tätigkeiten und Prozesse in Bezug auf die Themen Usability und User Experience (UX) besteht. In Anlehnung an die Kernak-tivitäten einer menschzentrierten Gestal-tung (DIN EN ISO 9241–210) entwickelten Bogner et al. (2011) ein Modell bestehend aus sechs Prozessrollen: – Usability Engineer: Verantwortet als Querschnittsrolle die Planung sowie Durchführung eines menschzentrierten Gestaltungsprozesses und integriert diesen in den Produktentwicklungs-prozess eines Unternehmens. Dabei definiert er Erfolgskriterien in Bezug auf die Gebrauchstauglichkeit, trainiert die beteiligten Projektteams und legt zu erbringende Arbeitsergebnisse, zu berücksichtigende Richtlinien und durchzuführende Methoden in Absprache mit den anderen Prozess-rollen fest.

– User Requirements Engineer: Analysiert und beschreibt den Nutzungs kontext inkl. der Benutzer, deren Aufgaben sowie der physi -kalischen und sozialen Umgebung. Auf Basis des Nutzungskontextes identifiziert er die Erfordernisse der Benutzer, leitet Nutzungsan -forderungen ab und priorisiert diese für die Berücksichtigung im Projekt.

– Interaktionsdesigner: Konzipiert die Interaktion zwischen den Benutzern und dem technischen System, wobei er die Nutzungsanforderungen berücksichtigt und die Ziele der Effektivität, Effizienz und Zufrieden-stellung bei der Aufgabenerledigung sicherstellt.


Workshop

29

unterschiedlicher Ausprägung. Die Grund-lagenprüfung wird mittels eines Fragebo-gens gemäß des Multiple-Choice-Prinzips durchgeführt. Diese umfasst 40–45 Fragen, die in jeder Prüfung variieren. Exempla-rische 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 wei-terfü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 Usabi-lity Engineering“, relevante ISO Standards (Geis et al., 2010) und der Fachschrift „Berufsfeld Usability“ sowie Erkenntnisse aus den etablierten Zertifizierungspro-grammen dienen somit sowohl als inhaltli-che 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 Kompetenz-rahmens 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 humanzen-trierten Gestaltungsprozesses.

3.1. Kompetenzrahmen „Usability Engineering“

Kompetenz wird als ein nicht direkt beob-achtbares Konstrukt verstanden, das durch die drei Dimensionen Struktur, Niveau und Erfassung beschrieben werden kann und durch definierte Handlungen, also nicht

– 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 beschriebe-nen Zertifizierungsmodells. 2.3. Zertifizierungsprogramme

Neben einer inhaltlichen Ausgestaltung ist ebenfalls das organisatorische Rah-menwerk einer Zertifizierung wesentlich. Daher wurden etablierte Zertifizierungs-programme aus den Bereichen Require-ments 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 grund-sätzliche strukturelle Einteilung der Zertifizierungsstufen in eine Grundla-genprüfung („Foundation Level“) sowie mehrere weiter führende Prüfungen („Advanced Level“ und „Expert Level“)

durch spezialisierte Methoden oder Techni-ken, konstituiert wird (PAS 1093, 2009).

Ein Usability Professional sollte daher in der Lage sein, definierte Handlungen durchzuführen sowie adäquate Metho-den 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 Quali-fizierung oder Zertifizierung von Personen keine bestimmten Methoden zwingend vorgeschrieben werden. Mit dem Kompe-tenzrahmen soll vielmehr eine verlässliche Basis geschaffen werden, anhand derer Usability Professionals geeignete Auswahl-kriterien erlernen können, um im jeweili-gen 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! Verweis-quelle konnte nicht gefunden werden.) ausgeübt werden:1. Planung der menschzentrierten

Gestaltung2. Den Nutzungskontext verstehen und

beschreiben3. Die Nutzungsanforderungen

spezifizieren4. Gestaltungslösungen entwerfen, die die

Nutzungsanforderungen erfüllen5. Gestaltungslösungen aus der Benutzer-

perspektive evaluieren und verwerten6. Das Produkt bei den Benutzern

einführen7. Langzeitbeobachtungen8. Den Usability Engineering Prozess orga-

nisieren (ü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 Theo-rie und/oder Faktenwissen sowie kognitiven und praktischen Fertigkeiten, wird auch die Kompetenz im Sinne der Übernahme von Verantwortung und Selbstständigkeit

30

berücksichtigt. Der deutsche als national angepasster Qualifikationsrahmen unter-scheidet zusätzlich zwischen personalen und sozialen Kompetenzen. Die Teilbereiche „Wissen“, „Fertigkeiten“ und „Kompeten-zen“ (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 „Nutzungskon-text verstehen und beschreiben“ (siehe Abbildung 1) wirksam zu sein, als Mindest-Kompetenzen unter anderem die Dimen-sionen des Nutzungskontextes nach ISO

9241–11 kennen (Kenntnisse), „aktives Zuhören“ beherrschen (Fertigkeiten) sowie die Fähigkeit zur empathischen Kommu-nikation 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 Enginee-ring 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 Curric-lum für eine Grundlagenzertifizierung inklu-sive 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 – Found-ation Level (CPUX-F)“ vor. Entsprechende Dokumente sind über die Internetseite zum Zertifizierungsprogramm der German UPA verfügbar (German UPA, 2013).


Workshop

Tab. 1. Handlungsfeld „Nutzungskontext verstehen und beschreiben“

Usabiliy-Engineer Spezialist (User Requirements Engineer)

Mindest-Kompetenzen, um als Usability-Engineer im Hand-lungsumfeld „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 voll-ständige Tätigkeiten (vgl. ISO 9241-2)

– Relevante Ansätze, um Nutzungskontexte zu erheben, zu beschreiben und zu kommunizieren

– Grundlegende Methoden zur Erhebung, Beschrei-bung Kommunikation des Nutzungskontextes

– Kriterien zur Auswahl geeigneter Methoden – Grundlagen der Kommunikation – Verhaltensregeln, Gesprächsregeln, Checklisten

– Vertieftes Wissen über Ziele, Aufbau und Wirkungs-weisen 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 (Fer-tigkeiten) 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 Erhe-bung, Beschreibung und Kommunikation der Kon-textanalyse an spezifische Fragestellungen angepasst bzw. weiterentwickelt werden müssen

– ggf. Identifikation alternativer Methoden – Anpassung oder Weiterentwicklung grundlegender Methoden zur Erhebung, Beschreibung und Kommu-nikation der Kontextanalyse

– Erhebung eines Nutzungskontextes eigenverantwort-lich durchführen

– Nutzungskontexte kommunizierbar beschreiben – Optimierungsbedarf im Nutzungskontext identifizieren

Personale und Soziale Aspekte

– Fähigkeit zur Perspektivenübernahme ohne Nutzungs-kontext offensiv zu beeinflussen (Interviewpartner nicht unterbrechen, nicht kritisieren, Lösungsvor-schlä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ösun-gen abweichen, neue Wege beschreiten

– Bei Bedarf offensives Verhalten, für eigenes Anliegen kämpfen, Durchsetzungsfähigkeit

– Hohe Selbstwirksamkeit bezogen auf projektbezo-gene eigene Ziele, Handlungen und Beiträge J

31

Betrachten wir exemplarisch den Begriff des „Szenario“, so lässt sich feststellen, dass der Begriff in unterschiedlichen Aus-prägungen verwendet wird. Somit existie-ren sowohl deskriptive Szenarien, welche auf empirischen Daten aus der Nutzungs-kontextanalyse beruhen, als auch präskrip-tive 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 zwei-ten Kategorie gehören demnach bspw. Aktivitätsszenarien und Interaktionsszena-rien (Rosson & Carroll, 2002) sowie User Stories (Cockburn, 2000).

Daher wurde ein Glossar erstellt, welches die im Curriculum und in den Zertifizie-rungsfragen 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 Beispie-len 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.

3.2.Curriculum CPUXF

Das Curriculum (Lehrplan) umfasst alle The men und Konzepte, auf welche die Prüfungs fragen Bezug nehmen. Es ist in Unterrichtseinheiten strukturiert, die je doch für Anbieter entsprechender Trainings nicht verpflichtend sind, d.h. die Reihenfolge der Themen und die Ausge-staltung von Übungen bleibt dem Anbieter überlassen. Folgende acht Unterrichtsein-heiten sind Inhalt des Curriculums:1.1. Grundlegende Begriffe und Konzepte1.2. Verstehen und Spezifizieren des

Nutzungskontextes 1.3. Spezifizieren der

Nutzungsanforderungen1.4. Entwickeln von Designlösungen 1 –

Usability Prinzipien und Richtlinien1.5. Entwickeln von Designlösungen 2 –

Spezifizieren der Interaktion1.6. Evaluierung des Designs 1

– Usability-Test1.7. Evaluierung des Designs 2 – Andere

Evaluierungsmethoden1.8. Prozessmanagement und Verwendung

von Methoden

So werden neben den „klassischen“ vier Kernaktivitäten rund um 1) den Nutzungs-kontext, 2) den Nutzungsanforderungen, 3) Entwickeln von Designlösungen sowie 4) Evaluationen auch grundlegende Begriffe und Konzepte (bspw. interaktives System, Benutzungsschnittstelle, Effektivität, Effizi-enz, Zufriedenstellung) sowie das Thema Prozessmanagement (u.a. Verantwortlich-keiten, Angemessenheit von Methoden) berücksichtigt.

3.3. Glossar CPUXF

Die Usability Begriffswelt ist sowohl im internationalen als auch im nationalen Raum innerhalb der Community divergent, so dass ein Glossar von essentieller Bedeu-tung ist, um eine gemeinsame Kommunika-tionsebene 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.

Zusammen mit dem Curriculum bildet das Glossar die inhaltliche Ausgestaltung der Zertifizierung zum CPUX-F. 3.4. Anforderungen CPUXF

Das aktuelle Zertifizierungsprogramm spie-gelt 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 Anwendbar-keit 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üh-

rers von Sixt?2. Teilen Sie mir bitte mit, was Sie über die

Homepage von Sixt denken.3. Nehmen wir an, Sie sind ein Firmen-

kunde. Wie kann Sixt Ihnen helfen zu sparen?

4. Mieten Sie einen Kleinwagen am Frankfurter Flughafen ab 15. Feb-ruar 9 Uhr. Sie planen den Wagen am gleichen Ort am 19. Februar um 11 Uhr zurückzugeben.

5. Worüber berichtete die letzte Pressemit-teilung von Sixt?

32

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 Antwor-ten 1, 3 und 5 sind von zu geringem Inte-resse für durchschnittliche Benutzer und sind zu unspezifisch formuliert. Antwort 2 ist ebenfalls falsch, da hier eine Meinung und nicht die Durchführung einer Testauf-gabe 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 internati-onaler Ebene am Rande des Konsortialtref-fens eines ISO Gremiums weitere Begut-achtungen 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 Perso-nen nahmen dabei am Vorbereitungssemi-nar teil, während weitere Personen sich im Selbststudium vorbereiteten. Die Grup-pengröß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 Reife-grad des Foundation Levels überschritten. Hiermit lässt sich wahrscheinlich auch erklären, dass zwischen der Seminar- und 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üfungseva-luation 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 ange-messen; 1x zu lang) und der allgemeine Schweregrad (14x angemessen, 3x zu schwer, 3x keine Angabe) wurden insge-samt 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üffra-gen besteht aus Sicht der Teilnehmer Verbesserungspotenzial.

Dieses Potenzial wird durch die Ergebnisse der anschließenden statistischen Bewer-tung der Items reflektiert: Hinsichtlich des Kriteriums Itemschwierigkeit zeigte sich,


Workshop

Abb. 1. Schematische Wieder-gabe der Prüfungs-ergebnisse der Pilot-zertifizierung CPUX-F (Brau, 2013)

33

Für die Zukunft sind aktuell noch fortge-schrittene Programme für – CPUX – Information Architect (CPUX-IA) und

– CPUX – Usability Engineer (CPUX-UE)

geplant.

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

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

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

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

& Zimmermann, D. (2012). German UPA

Qualitätsstandard für Usability Engineering,

Version 1.0. German UPA e.V., Arbeitskreis

Qualitätsstandards.

2. Bogner, C., Brau, H., Geis, T., Huber, P.,

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

(2011). Beschreibung des Berufsfelds

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

(DAkkS) (2010). Leitfaden Usability,

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

default/files/71-SD-2–007_Leitfaden%20

Usability%201.3.pdf

6. Diefenbach, S., Ullrich, D. & Kolb, N. (2012).

Branchenreport Usability 2012 – Ergebnisse

einer Befragung unter Usability Professionals

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

Tagungsband Usability Professionals 2012,

German UPA, S. 288–294.

7. DIN EN ISO 9241–11 (1999). Ergonomische

Anforderungen für Bürotätigkeiten mit

Bildschirmgeräten – Teil 11: Anforderungen

an die Gebrauchstauglichkeit – Leitsätze.




interaktiver Systeme.

dass vier Items hinsichtlich Schwierigkeits-index und Trennschärfekoeffizienten un -günstige Werte aufweisen. Dass nicht wenige Items sehr hohe Schwierigkeitsindi-zes 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 durchge-führten Prüfungen anschließen.

Die im Rahmen der Pilot-Zertifizierung gewonnen Erkenntnisse werden entspre-chend in das Curriculum, die Prüfungsfra-gen sowie das Glossar eingearbeitet.

4. Ausblick

Zusammengefasst ist die Realisierung einer Zertifizierung zum Thema Usability und UX mit dem Zweck einer Professiona-lisierung 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 diver-sen Evaluationsaktivitäten und einer ersten Pilot-Zertifizierung im Juni 2013 findet nun im Rahmen der Konferenz Mensch & Computer 2013 sowie Usability Professio-nals 2013 im September die erste offizielle Zertifizierungsrunde statt, bei der sich 100 Usability und User Experience interessierte Personen zertifizieren lassen können. Wei-tere Möglichkeiten werden später folgen.

Zudem rücken die Arbeiten am Kompe-tenzrahmen Usability Engineering (vgl. Abschnitt 3.1) nach Erstellung des Curricu-lums 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 Zertifizie-rungsprogramme für – CPUX – Usability Tester (CPUX-UT) sowie

– CPUX – User Requirements Engineer (CPUX-URE).

9. EQR Europäischer Qualifikationsrahmen

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

für Usability Engineering der German UPA

– Aktueller Stand der Arbeiten. In: Brau,

H. et al. (Hrsg.) Tagungsband Usability

Professionals 2012, German UPA, S.

160–165.

11. Geis, T., Hofmann, B., Bogner, C. &

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

Usability Professionals – welche sind das

eigentlich?. i-com Zeitschrift für interaktive

und kooperative Medien, Ausgabe 1–2010.

München: Oldenbourg Wissenschaftsverlag.

12. German UPA (2013). Dokumente zur

Zertifizierung CPUX-F. http://www.

germanupa.de/aktivitaeten/zertifizierung/

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

Development for Human-Computer

Interaction. San Francisco, CA, USA: Morgan

Kaufmann.

17. Seffah, A., Desmarais, M. C. & Metzker,

E. (2005). HCI, Usability and Software

Engineering Integration: Present and Future.

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

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

Engineering – Integrating Usability in the

Software Development Lifecycle (S. 37–58).

Heidelberg: Springer Verlag.

18. Woywode, M., Mädche, A., Wallach, D.

& Plach, M. (2012). Abschlussbericht des

Forschungsprojektes „Gebrauchstauglichkeit

von Anwendungssoftware als

Wettbewerbsfaktor für kleine und mittlere

Unternehmen“ im Auftrag des BMWi.

34


Workshop

35

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 einbrin-gen. Die Telefonkonferenzen werden abwechselnd vorbereitet. In ca. 45 Minuten kann ein Projekt, eine Methode, Fachlite-ratur, oder ein Konferenzbericht vorgestellt werden; im Anschluss daran ist Zeit für Fragen und Diskussionen.

Wir freuen uns auf Ihre Mitarbeit!

1. Einleitung

User Research ist ein zentraler Bestandteil der benutzerzentrierten Produktentwick-lung, durch den Benutzeranforderungen identifiziert und dokumentiert, und daraus abgeleitete Prototypen evaluiert (validiert) werden können.

Obwohl der User Research ein fundamen-taler Bestandteil der nutzerzentrierten Produktentwicklung ist, wird diese Disziplin bei Tagungen und Workshops noch zu wenig thematisiert.

Gemeinsam mit neuen AK-InteressentIn-nen möchten wir dieses wichtige Thema sowohl inhaltlich als auch organisatorisch diskutieren und die Visibilität dieses Be reiches stärken.

Sie sind dazu herzlich eingeladen!

2. Ziele des Arbeitskreises

Der Fokus des Arbeitskreises liegt auf dem Austausch über angewandte Research-Methoden – vom klassi-schen 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 an regen. Folgende Fragestellungen werden diskutiert: – Vor welchen Herausforderungen stehen

User Researcher derzeit? – Wie können Methoden an besondere

Umstände angepasst werden? – In welchen Zusammenhängen stehen

die unterschiedlichen Methoden und was kann mit ihnen erreicht werden?

Des Weiteren soll eine höhere Sichtbarkeit des User Research innerhalb des Fachberei-ches User Experience geschaffen werden. User Experience ist mehr als Interaktions- und Visuelles Design; ein gutes Design beruht stets auf einer fundierten Anforde-rungsanalyse sowie einer Evaluation des Designs mit repräsentativen Nutzern.

Des Weiteren ist eine umfassende Literatur-liste zum Thema User-Research-Methoden und deren Anwendung geplant; sowie lang-fristig eine Sammlung der angewandten Methoden mit Hinweisen, Tipps und Tricks.

3. Ziel des Workshops

In diesem ersten Workshop steht das Ken-nenlernen der Interessenten und der AK-Leitung im Vordergrund. Es soll Raum für

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

AbstractDer 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 vorge-stellt. 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 Re-searcher tätig sind, sind herzlich zur Mitarbeit eingeladen.

Anja EndmannitCampus GmbHNonnenstraße 3704229 [email protected]

Carolin FleschSAP AGDietmar-Hopp-Allee 1669190 [email protected]

Arbeitskreis User Research: Workshop zur Mensch & Computer 2013

36

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

37

EN 14971 durchführt und dokumentiert. Er kann mit Hilfe von Usability Engineering nutzergerechte Maßnahmen zur Risikokon-trolle definieren. Wie er dazu auf die Unter-stützung von Usability Experten zurückgrei-fen kann, zeigt ihm der Leitfaden auf.

Nicht zuletzt zeigt der Leitfaden aber auch Personen aus dem Usability und UX Um -feld auf, welche Besonderheiten sie bei Ent wicklung von Medizintechnik beachten müssen. Wichtigste Botschaft ist hierbei, dass Usa bility in der Medizintechnik zu allererst zur Vermeidung von Bedienfehlern und zur Verbesserung der Sicherheit dient. Allen voran steht hier deshalb die enge Zusammenarbeit mit dem Riskomanager und die Dokumentation des gesamten Usa-bility Engineering Prozesses. Dies wird in anderen Branchen für Usability Engineering bzw. UX Prozesse nicht benötigt und des-halb 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 grund-sätzlich übernommen und entsprechend

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 die-sem Grund haben sich Usability Experten von Medizingeräte-Herstellern, Dienst-leistern und Free Lancern im Arbeitskreis „Usability in der Medizintechnik“ zusam-men gefunden. In regelmäßigen Abstän-den treffen sie sich, um über Themen wie die Zusammenarbeit verschiedener Disziplinen in einem Entwicklungsprozess oder das Zusammenspiel zwischen Risiko-management und Usability Engineering zu diskutieren. Die Essenz dieser Treffen findet ihren Platz in einem Leitfaden.

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

Es ist dabei nicht das Ziel, die bestehen-den Normen zu wiederholen, sondern

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 unterschied-liche Management-Ebenen wie zum Beispiel Geschäftsführer, Projekt- und Pro-duktmanager, 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 Nor-men gibt, die Usability einfordern. Der Leitfaden soll sie dabei unterstützen, die richtigen Weichen stellen zu können.

Weiterhin soll er Mitarbeiter aus dem Qua-litätsmanagement oder Regulatory Affairs Umfeld, die auf die Usability Normen ges-tossen sind. Sie müssen andere Mitarbeiter im Unternehmen auf diese Normen auf-merksam 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 Enginee-ring File dokumentiert werden.

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

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

AbstractBei der Entwicklung von Medizinprodukten ist die Anwendung eines Usability Enginee-ring Prozesses per Normen vorgeschrieben. Dadurch sollen Gefährdungen, hervorge-rufen 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.

Tobias WalkeUser Interface Design [email protected]

Workshop des Arbeitskreises „Usability in der Medizintechnik“

38

adaptiert. Neben einem Print-Format soll hier die PDF Variante interaktiv mit Navi-gation 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, sol-len sie möglichst kompakte Texte, ergänzt durch Bilder und Skizzen enthalten. Obers-tes Ziel ist es, einen schnellen Einstieg und einen guten Überblick über das Thema zu bekommen. Weiterführende und tiefer-gehende 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 fi ktiv 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]

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 nutzer-orientierte Denkweise in seinem Unterneh-men einsetzen kann. Deshalb werden ihm weiterführend die Vorteile und der Nutzen der Anwendung eines nutzerzentrierten Gestaltungsprozesses in der Medizinpro-dukte-Entwicklung aufgezeigt. An oberster Stelle steht die Verbesserung der Sicher-heit für Nutzer, Patienten und Dritte. Doch neben dieser normativen Anforderung gibt es zahlreiche weitere Vorteile wenn Nutzer miteinbezogen werden, die sich für Marke-ting und Vertrieb, aber zum Beispiel auch im Kundenservice umsatz- und kundenzu-friedenheitssteigernd 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 Pfl ichtprogramm“ für die Zulassung eines Medizinproduktes im europäischen Raum.

Kernstück dieses Kapitels bildet eine grafi -sche Darstellung eines idealtypischen Ent-wicklungsprozesses 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 Prozessgrafi k im Leitfaden eher kompakt und fokussiert gezeigt wird, soll sie in einer Webseiten-Variante detail-lierter und tiefgängiger dargestellt werden.

Kapitel III – 4 Top Cases

Im dritten Kapitel bilden Entwicklungsbei-spiele 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,

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 ver-schiedene Anwendungsfelder und Individu-alisierung 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 Medizinpro-dukte wiedererkennen können.

Die erstellten Cases sollen möglichst generisch anwendbar und auch keinem Hersteller zuordenbar sein.

Geplant ist, einen Case auf zwei Doppel-seiten 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.


Workshop

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

39

entwickeln. Zusätzlich sollen für die einzel-nen Rollen praktische Handlungsempfeh-lungen der Usability Experten die Umset-zung des Prozesses im Alltag erleichtern.

Kapitel V – Verfasser & Weiterführende Infos

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

Kapitel IV – Rollen und Handlungsempfehlungen

Im vierten Kapitel wird auf die Rollen im Entwicklungsprozess eingegangen. Die Idee hierbei ist, dass sich der Leser mit min-destens einer dieser Rollen identifi zieren kann. Er erfährt dann was seine Aufgaben sind und mit welchen anderen Rollen er zusammen arbeiten muss, um ein mög-lichst nutzerfreundliches Medizinprodukt zu

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

Was ist der aktuelle Stand?

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

40

Einen Prozess entwickelt

Um den Entwicklungsprozess aus der Norm zu veranschaulichen, teilten die Mit-glieder 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 Entwick-lungsprozesses sind: Recherche/Analyse,

Konzeption I+II, Umsetzung, Validierung, Markeinführung. Häufi g werden innerhalb einer Phase mehrere Handelnde aktiv und müssen zusammenarbeiten. Im Prozess müssen auch die Iterationen zwischen Kon-zeption und Validierung beachtet werden.

Am Ende steht ein Prototyp, eine Beta-Version oder Nulllinie. Der Prozess soll in einer anschaulichen Form in den Leitfaden einfl ieß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 Hard- und Software heraus. Ein Ziel muss deshalb sein einen möglichst generischen, ideal-typischen 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]


Workshop

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

41

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 Notwen-digkeit 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 Usabi-lity Engineering einsetzen möchte.

Ziele – Produkt & Image verkaufen – Benchmarking & Marktwissen einbringen

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 Pro-dukts durch Usability Engineering Metho-den gesammelt, wird sehr oft deren Nutzen erkannt und deren Akzeptanz erhöht.

Ziele – Geplante Anforderungen im aktuellen Produkt termingerecht umsetzen.

Erste Struktur für Cases definiert

Ein Vorschlag für die Grundstruktur eines Cases kann wie folgt aussehen:1. Ziel der Entwicklung2. Beschreibung inkl. Nutzen3. Nutzer4. an der Entwicklung beteiligte Rollen laut

Leitfaden5. Typische Risiken6. Vorgehensweise, Anwendungsfälle,

Szenarien, Hauptbedienfunktionen, …7. Bilder in Form von möglichst neutralen

Illustrationen8. 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 unter-schiedliche 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 (Pati-ent als Nutzer) und der L Case soll ein sehr komplexes Gerät abbilden, mit umfangrei-chen Hard- und Software Anteilen.

Zukünftige Rollen

Der aktuelle Stand der identifzierten Rollen definiert. wurde von den Arbeitskreis Mit-gliedern wie folgt definiert:

1. Management

Das Management muss zulassungsrelevante Normen kennen, die verschiedenen Dis-ziplinen Entwicklung, Marketing, Usability Engineering, Design und Risikomanage-ment 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 Usabi-lity Verantwortliche eingesetzt wie beispiels-weise Entwickler oder Qualitätsmanager oder Regulatory Affairs Manager.

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. UXDesign / 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ösungen- Alternativen finden

– Szenarien / Varianten erstellen – Risiko- Maßnahmen in Anforderungen umsetzen

– Fertiges Produkt validieren

5. Entwickler

Der Entwickler arbeitet als Techniker, Ingenieur, Software-Entwickler, Medi-zintechniker oder Biologe in der Pro-duktentwicklung. Er ist technisch versiert, denkt analytisch und hätte am liebsten

42

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.

Aufgaben – Wissen über Nutzer und Kontext von UX einfordern

– Gefahren erkennen und recherchieren – Risiken abschätzen; – Maßnahmen an UX weitergeben – Maßnahmen verifizieren

7. Guidelines / Corporate Design

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.

Ziel – Visuelle Identität sicherstellen

Aufgaben – für UX Anforderungen offen sein – aus Projekten / Produkten / Technologien lernen und Guidelines adaptieren

– allgemeine Corporate Usability Guidelines aufsetzen und pflegen

8. Nutzer

Der Nutzer kommt mit Benutzer freundlich-keit vor allem über seine alltäglichen Consumer Produke, sowie Webseiten in Kontakt. Die dort gemachten Erfahrungen projiziert er auch auf Medizinprodukte, die er beruflich oder als Patient anwenden muss. Seine Toleranz gegenüber schlecht bedienbaren Produkten sinkt immer weiter.

Ziel – Produkt sicher, effektiv, effizient benutzen (und mit Spaß)

Aufgaben – Mehrfache Mitwirkung bei der Entwicklung

– Gespür für die Notwendigkeit seines Feedbacks entwickeln

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

Wie geht es weiter?

Die Mitglieder des Arbeitskreises „Usa-bility 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.


Workshop

43

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 UE-Aktivitä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 Unterneh-men 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

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, gebrauchs-taugliche Produkte und Dienstleistungen zu entwickeln sind vorhanden, aber es fehlt vielerorts das Wissen darüber, wie das genau vonstatten gehen soll. Welche Akti-vitäten und Methoden des Usability Engi-neerings bzw. des User Centered Designs sind erforderlich? Welche Voraussetzungen müssen erfüllt sein? Welche Personen und

welche Abteilungen müssen in die Usabi-lity Engineering-Aktivitäten einbezogen werden und zu welchem Zeitpunkt?

Im UPA-Arbeitskreis „In-house Usability Professionals“ sind wir zu der Überzeu-gung 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 Enginee-ring-Aktivitäten regelmäßig durchgeführt oder sporadisch immer nur dann, wenn im

Jan-Hendrik Spieth, Audials AGKarl-Wilhelm-Str. 2476131 [email protected]

Dr. Natalie WoletzT-Systems InternationalLandgrabenweg 15153227 [email protected]

Desdemona StraußAVM GmbHAlt-Moabit 9510559 [email protected]

Nicole Charlierakquinet AGBülowstr. 6610783 [email protected]

Charlene BeaversSTRATO AGPascalstraße 1010587 [email protected]

Berit LeikingNEMETSCHEK Allplan Systems GmbHKonrad-Zuse-Platz 181829 Mü[email protected]

Peer DierolfCarl Zeiss SMS GmbHRudolf-Eber-Straße 273447 [email protected]

Interviewleitfaden Usability ProzessreifeEin Instrument des German UPA Arbeitskreises „In-house Usability“ zur Bewertung der Usability-Prozessreife in Unternehmen

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

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

44

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.

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

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 Prozes-ses ist das Ergebnis die Usability bzw. User Experience, die ein interaktives Produkt (Software, Hardware, App, Website etc.) aufweist. Je besser der Usability Engi-neering 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 – vergli-chen. Der Referenzprozess legt den Zweck und die erwarteten Resultate fest. Je mehr der bewertete Prozess dem Referenzpro-zess entspricht, desto besser ist er. Die ermittelten Abweichungen zeigen die Verbesserungspotenziale für den bewerte-ten Prozess auf.

Um die Reife des Usability Engineering Prozesses zu bewerten, wird also ein Referenzprozess benötigt. Für den vor-liegenden Interviewleitfaden wurde der Usability Engineering Prozess der DIN EN ISO 9241–210 als Referenzprozess gewählt. Die ISO definiert vier Prozess-Schritte der

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

Zu den in der ISO beschriebenen Prozess-Schritten werden im „German UPA Qua-litätsstandard für Usability Engineering“ dazugehörige Aktivitäten beschrieben.

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ätsstan-dard 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 Aktivi-täten der menschenzentrierten Gestaltung zu iterieren sind.

Wichtig: Weder die Reihenfolge noch der Zeitpunkt der Durchführung bestimm-ter 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 Eingangsinformatio-nen vorhanden sind.

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

nicht an eine bestimmte Vorgehensweise gebunden. Er kann unabhängig von einer bestimmten Entwicklungsmethodik ange-wendet werden.

3. Der Interviewleitfaden und seine AnwendungEinfü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 Usa-bility Engineerings gut bekannt sind. Auch die Kenntnis des Qualitätsstandards, auf dem dieser Leitfaden basiert, ist Voraus-setzung 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 umfas-sende Erfahrung mit der Durchführung von Interviews besitzen.

Es kann vorkommen, dass der Usability-Experte, der die Bewertung durchführen will, der einzige Usability-Experte im Unternehmen ist. In diesem Fall empfeh-len 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 Enginee-ring 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 gesam-ten Prozess bewerten zu können.

Alternativ ist es möglich, Interviewteilneh-mer auszuwählen, die jeweils einen Teil des Gesamtprozesses gut beurteilen können. In


Workshop

45

bei der Beschreibung des Prozesses die gleichen Begrifflichkeiten verwenden.

Durchführung des Interviews

Zu Beginn schauen Interviewer und Inter-viewteilnehmer sich zunächst den Usability Engineering Prozess des Unternehmens an. Das kann zum Beispiel anhand der vorbereiteten Prozessdarstellung gesche-hen. Dabei sollten sich beide die Prozess-Schritte vergegenwärtigen, so dass sie im Interview die Schritte des Referenzprozes-ses mit jenen des gelebten, zu bewerten-den Prozesses gegenüberstellen können.

Für den Interviewer kann es eine Erleich-terung sein, das Glossar des Interview-leitfadens und den „German UPA Qua-litätsstandard für Usability Engineerin“ zur Hand zu haben, um beispielsweise

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 objek-tive Einschätzung abgeben zu können.

Ist ein Teil des Prozesses nach extern ver-lagert, zum Beispiel zu einem Dienstleister, sollte auch dieser Teilprozess anhand von Interviews mit Prozessbeteiligten bewer-tet werden. Ist dies nicht möglich, sollten zumindest die Ergebnisse des Teilprozes-ses daraufhin bewertet werden, ob sie für die nachfolgenden Prozessschritte in angemessenem Umfang und angemesse-ner Qualität vorliegen.

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 Unter-nehmen 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 Moni-toring“ 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 Enginee-ring 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

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

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än-digkeit und Qualität der durchgeführten Aktivitäten beurteilt. Am Ende der Abfrage jedes Prozess-Abschnitts erfolgt die Ein-ordnung in eine ordinale Bewertungsskala. Diese Einordnung nimmt der Interview-teilnehmer vor. Der Interviewer kann als Experte dabei Hilfestellung geben.

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

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

Tab. 1. Bewertungsskala

46

Auswertung

Das Ziel der Auswertung ist das Zusam-menführen der Ergebnisse aller Interviews sowie die Ableitung von Maßnahmen und Handlungsempfehlungen zur Verbesse-rung 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ärken-Schwächen-Profi l. [Tab. 2]

Es kann vorkommen, dass die Interviewpart-ner aufgrund ihrer verschiedenen Aufgaben und Rollen im Usability Prozess zu unter-schiedlichen Bewertungen einzelner Prozess-Schritte kommen. Weichen die Bewertungen der verschiedenen Interviewpartner vonein-ander 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 Pro-zessreife gelangen. In der Regel ergänzen sich die einzelnen Bewertungen zu einem

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

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

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

Schlussbemerkung

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

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

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

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

und Gebrauchstauglichkeit im praktischen

Einsatz. Dissertation, Universität Paderborn.

http://digital.ub.uni-paderborn.de/hs/

content/titleinfo/4128


Workshop

Tab. 2. Ausschnitt aus einem Stärken-Schwächen-Profi l

47

48

Tutorials

49

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

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:

Keywords: /// UCD/// UX Professionals

AbstractAn 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. Resistance 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?

Henning BrauUser Interface Design GmbHClaudius-Keller-Straße 3c81669 Mü[email protected]

User-Centered Design and Change ManagementLeading Organizational Change Towards User- Centered 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 meaning for Change processes

Understand how change can be 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 10 min

Tab. 1. Session Schedule with Time Allocation

50

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 presenta-tion. The statements will therefore be quite provocative, e.g.: „Design thinking cannot create a sustainable change.“

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

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

2.‚Why UX Crusaders Fail‘ to ‚The Change Management Paradox‘

I am going to explain why UX professi-onals 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 predefi ned 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]

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

I will explain from an organizational psy-chologist 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 under-stand the factors that drive resistance. I will also refl ect the implications of a theory about individual resistance against man-datory 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 infl uence. Cooperation and participation therefore are the keys to give power to a new idea like implementing UCD. Stakeholders need to understand the benefi t for themselves in their working environment in order to accept the insta bility 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 criti-cal moving mass and a constant fl ow of energy, which is bigger than the energy of the reacting (resisting) body. I will use this analogy to explain that change manage-ment needs many more efforts than to create documentations and singular com-munication/qualifi cation to be effective.


Tutorials

Abb. 1.

Abb. 2.

51

4.Manage the Change

A model of acceptance (Brau, 2008 & 2011) will be introduced as an aid for fi nding 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]

The presentation ends with the expla-nation of 7 golden rules for change managers:1. Be neutral, do not be a crusader2. Defi ne a clear scope and stick to it3. Quantify what you are doing4. Know about and utilize quality

management5. Be competent and communicate

competent6. Participate managers by taking orders

from them7. Participate on all levels, but never rely on

volunteers

References1. Brau, H. (2008). Mein System benutz’

ich nicht: Ein praxisorientierter Ansatz,

Nutzerakzeptanz zu messen und zu

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

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

Usability Professionals 2008. Fraunhofer:

Stuttgart.

2. Brau, H. (2011). Acceptance Engineering

– Menschzentrierte Gestaltung von

Arbeitssystemen. In: Brandenburg,T.

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

Wirtschaftspsychologie II. Münster: MV

Wissenschaft.

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

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

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

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

Cognitive, Affective and Behavioral

Components of Attitudes. In: Rosenberg,

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

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

Organization and Change, pp. 1–14. New

Haven, CT: Yale University Press.Statista.org.

14. Venkatesh, V., Morris, M.G., Davis, G.B.

& Davis, F.D (2003). User Acceptance of

Information Technology: Toward a Unifi ed

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

425–478.

Abb. 3.

52


Tutorials

53

erfordert eine formale technische Spezifi-kation eine exakte und eindeutige Formu-lierung 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 Require-ments Engineering zu erstellenden Doku-mente und Artefakte. Dies gilt ebenso für

1. Motivation

Eine detaillierte und widerspruchs-freie Spe zi fikation von Anforderungen ist häufig die zentrale Grundlage erfolgrei-cher Soft ware entwicklungsprojekte. Dabei sind nicht nur technische Anforderungen für den spä teren Erfolg oder Misserfolg maßgeblich, sondern auch die konse-quente Berücksichtigung von Anforderun-gen aus Anwenderperspektive (Hartson & Pyla, 2012). Effektives Anforderungsma-nagement stellt daher das systematische Ermitteln, Dokumentieren, Prüfen und Verwalten von Nutzungsanforderungen im Zusammenspiel mit technischen Rahmen-bedingungen sicher (Rupp, 2009; Robert-son & Robertson, 2012). Auf Basis unserer Erfahrungen gibt es dabei zwei zentrale Hindernisse bei der Spezifikation und dem Management von Anforderungen: die Integration interdisziplinärer Zusammenar-beit und die kontinuierliche Änderung und Nachverfolgbarkeit von Anforderungen über inkrementelle Entwicklungsstufen.

1.1. Interdisziplinäre Spezifikation

Im Rahmen des Anforderungsmanagements üben Stakeholder aus unterschiedlichen Domänen Einfluss auf die Anforderungs-spezifikation aus. Neben Requirements Engineers, Produktverantwortlichen und dem Management bringen auch Usability Engineers Nutzungsanforderungen ein oder übersetzen technische Anforderungen in Interaktionsabläufe und User-Interface-Entwürfe. Schließlich sind auch Fachex-perten oder Kaufleute genauso auf eine verständliche und konsistente Spezifikation angewiesen, wie Projektmanager, Syste-marchitekten und Entwickler (Nyßen, 2009). Oft kommt es jedoch vor, dass die beteilig-ten 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

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

AbstractDie Analyse und Spezifikation von Software-Anforderungen ist eine komplexe Aufgabe, die als Grundlage jedes Softwareentwicklungsprojekts für den Erfolg oder Misserfolg maßgeb-lich 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 Software-Anforderungen 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-Inter-face-Entwürfen und Interaktionsabläufen in komplexe Softwareprojekte interessiert sind.

Florian Geyeritemis AGAm Brambusch 15–2444536 Lü[email protected]

Jens Trompeteritemis AGAm Brambusch 15–2444536 Lü[email protected]

Michael Jendryschikitemis AGAm Brambusch 15–2444536 Lü[email protected]

Von der Nutzungsanforderung zur formalen SoftwarespezifikationModellierung mit dem Werkzeug YAKINDU Requirements

54

einige iterativ-inkrementelle Softwareent-wicklungsprozesse wie den Rational Unifi ed 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 Spezifi kation, Konstruktion und Umsetzung wird das Projekt in sehr enger, fortlaufender und direkter Zusammenarbeit mit dem Auftrag-geber realisiert (Beck et al., 2001). Die Spe-zifi kation erfolgt daher sukzessive während der Umsetzung (Paetsch et al., 2003). Das erlaubt zeitnahes Feedback und schnelle Reaktionen auf sich ergebende Veränderun-gen. Es gilt die Regel, dass neue und geän-derte Anforderungen zu jeder Zeit willkom-men sind. Diese Vorgehensweise erfordert jedoch Verzicht auf umfangreiche Spezifi ka-tionsdokumente oder deren kontinuierliche Anpassung und Erweiterung. Ein gänzlicher Verzicht bedeutet dabei jedoch auch die Aufgabe von Vorteilen formalisierter Vor-gehensweisen, 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 aufbau-ende Anforderungen, Modelle und Gestal-tungsartefakte 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 einge-pfl egt werden müssen. Diese Werkzeugket-ten erschweren die Nachverfolgbarkeit und eine zeitnahe und effi ziente Änderung von Anforderungen.

2.Werkzeug-basierte Spezifi kation mit YAKINDU Requirements

Dieses Tutorial stellt einen Ansatz zur Spe-zifi kation komplexer interaktiver Systeme mit Hilfe des Tools YAKINDU Requirements

(www.yakindu.de) vor. Das Spezifi kati-onswerkzeug bietet eine, auch für agile Prozesse sinnvolle Formalisierung und ist damit eine Alternative zu schwergewich-tigen und komplexen Werkzeugketten. Es erlaubt Anwendungsfälle (Use Cases), Abläufe, Masken/Maskenfolgen, Fachob-jekte 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 Pfl ichtenhefte, Testfälle und Schätztabel-len generieren. Der zentrale Vorteil dieses Ansatzes liegt darin, dass Nutzer einfach und schnell formale Anforderungsmodelle erstellen und diese auch in verteilten Teams effi zient teilen und anpassen können. Durch die Verknüpfung verschiedener pro-zessübergreifender Modelle und Artefakte unterschiedlicher Domänen bringt das Werkzeug interdisziplinäre Stakeholder wie Usability Professionals, Requirements Engi-neers, Systemarchitekten und Entwickler


Tutorials

Abb. 1. Die integrierte Model-lierungsumgebung YA-KINDU Requirements.

11

22

33

55

zusammen. Die Verbindung der Anforde-rungen und Entwicklungsartefakte wird mit einer gemeinsamen Modellierungsspra-che ermöglicht, welche die Präzision und Eindeutigkeit formaler Spezifi kationen mit einfach verständlichen, visuellen Repräsen-tationen kombiniert. Als einer der wich-tigsten Bestandteile des Requirements Managements ermöglicht dies eine bidirek-tionale Navigierbarkeit, mit dem Ziel, Anfor-derungen verfolgen und nachvollziehen zu können. Jedes Entwicklungsartefakt lässt sich so auf Anforderungen und Modelle zurückführen und hilft eventuelle Wechsel-wirkungen 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 grafi schen Modellen und Editoren (siehe Abb. 1). Die grundlegende Modellierungs-umgebung ist aufgebaut auf einen Naviga-tionsbereich (1), einen textueller Editor (2) und eine grafi sche Visualisierung (3).

Ein hierarchischer Projektexplorer ermög-licht es dem Nutzer eine klare Struktur zu erstellen und zwischen Anforderungen, Modellen und Artefakten der Spezifi kation zu navigieren (siehe Abb. 1, 1). Mittels des textuellen Editors (siehe Abb. 1, 2) kön-nen Modelle formal spezifi ziert werden. YAKINDU Requirements verwendet hierfür eine einfache, schnell erlernbare Sprache,

die Vorteile wie Textvervollständigung, Textbausteine und Templates, sowie Fehlerkorrekturen und Konsistenzprüfun-gen integriert. Aufgrund des textbasierten Datenmodells ist es zudem möglich, durch Copy & Paste, Refactoring und der Verwen-dung von Diff- und Merge-Werkzeugen Änderungen oder Erweiterungen effi zient zu verwalten. Zusätzlich bietet die Sprache eine durchgängige Referenzierung und bidirektionale Verknüpfung von Inhalten und kann um individuelle Konzepte und domänenspezifi sche Konzepte erweitert werden. Diese formale Spezifi kation wird ergänzt durch eine grafi sche Aufbereitung der Modelle in einem Vorschau-Bereich (siehe Abb. 1, 3). Der Vorschaubereich stellt eine automatisch generierte grafi sche Repräsentation des textuell beschriebenen Modells dar und ermöglicht so dem Nutzer, einen Überblick über abstrakte Konzepte zu erhalten. Zusätzlich kann die grafi sche Dar-stellung ebenfalls zur Navigation innerhalb und zwischen Modellen und verknüpften Artefakten genutzt werden. [Abb. 1]

YAKINDU unterstützt derzeit folgende, mit-einander verknüpfte Modelle zur Spezifi ka-tion 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

– 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 spezifi ziert werden können. Der beispielhafte Anwendungsfall „submit app for leave“ enthält einen Ablauf (basic fl ow) mit mehreren Schritten und Alternativen, aus denen YAKINDU Requirements auto-matisch 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

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

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

56

blau dargestellten, interaktiven Links ermöglichen dem Nutzer die Nachverfolg-barkeit von Veränderungen und erleichtern die Navigation zwischen den Modellen. YAKINDU Requirements nutzt diese Ver-knüpfungen jedoch auch, um die Konsi-stenz und Validität der Spezifi kation sicher zu stellen. So wird der Nutzer beispiels-weise benachrichtigt, falls ein bestimmter Akteur in keinem der spezifi zierten Use Cases referenziert wurde. Das System unter-stützt den Nutzer aktiv dabei, die formale Spezifi kation auf Validität und Konsistenz zu prüfen – eine Aufgabe, die mit traditio-nellen Spezifi kationsdokumenten nur sehr schwer zu realisieren ist. [Abb. 2], [Abb. 3]

2.3.Beispiel: UserInterfaceModellierung

Die Defi nition der Benutzerschnittstelle einer Anwendung wird mit Ablaufdiagram-men unterstützt (vgl. Page Flows, Story-boards). 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 grafi schen Editor, der einem Ablauf-diagramm ähnelt, werden dynamische Veränderungen von Komponenten und Übergänge zwischen Masken modelliert (siehe Abb. 4, 1). So kann hier formal spezifi ziert werden, wie das Verhalten der Anwendung durch Nutzerinteraktion und Programmlogik visualisiert wird. Der Editor verwendet hierfür das Konzept der „Screens“, um dynamische Veränderun-gen in Zustände abzubilden. Neben einer Verknüpfung zu dem dahinter liegenden Design Rationale (Use Cases, Nutzungs-anforderungen), können diese Zustände zudem mit Skizzen oder Mockups ver-knüpft werden (siehe Abb. 4, 2). Durch die Möglichkeit, Bilddateien per Drag & Drop zu integrieren, können auf einfa-che Weise beliebige Prototyping oder Mockup-Tools für die Visualisierung von Screen-Designs verwendet werden (auch gescannte oder abfotografi erte Hand-skizzen). Durch die konsistente Verlinkung der Modelle ist sicher gestellt, dass sich

Designentscheidungen vom User-Inter-face-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 Rahmenbedingun-gen entstanden sind (bottom-up). [Abb. 4]

2.4.Automatische Generierung von Spezifi kationsdokumenten

Durch den Ansatz einer integrierten Modellierungsumgebung ermöglicht YAKINDU Requirements die Verknüpfung von Modellen zu einer umfassenden inter-aktiven Spezifi kation, die während des Ent-wicklungsprozesses leicht aktualisiert und angepasst werden kann (Change Manage-ment & Traceability). Alle Stakeholder – seien es Entwickler, Software-Architekten oder Usability Engineers – können inter-aktiv durch die hierarchisch organisierte und durch Querverbindungen verdichtete


Tutorials

Abb. 4. Spezifi kation einer Benutzerschnittstelle (UI Flow Modell).

11

22

57

Struktur der Spezifi kation navigieren. Ein entscheidender Vorteil liegt dabei darin, dass alle am Spezifi kationsprozess 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-Ent-würfen erlauben zudem eine Integration von domänenspezifi schen Werkzeugen. Darüber hinaus bietet YAKINDU Require-ments umfangreiche Exportfunktio-nen, die es ermöglichen, automatisiert zielgruppengerechte Dokumente zu erzeugen (siehe Abb. 5). [Abb. 5]

Das Werkzeug lässt den Benutzer ent-scheiden, wie der Dokumentenexport aussehen soll und welchen Umfang und Vollständigkeit die erzeugten Dokumente besitzen. YAKINDU Requirements ver-wendet 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

unterschiedliche Zielgruppen geeignete Dokumente zu erzeugen, wie beispiels-weise 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 Kompo-nenten für das Projektmanagement bietet (McConnell, 2006). Individuelle Export-Defi nitionen ermöglichen darüber hinaus viele weitere fl exible Einsatzszenarien. Weitere Einstellungen für den Dokumen-tenexport umfassen unterschiedliche Spra-chen (deutsch, englisch), Formate (PDF, HTML, Offi ce) 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 Anforderungsspezifi -kationen haben einen entscheidenden Vor-teil gegenüber traditionellen, dokumen-tenbasierten Spezifi kationen: Bislang in Handarbeit durchgeführten Auswertungen,

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

3.Ausblick

YAKINDU Requirements hat seinen Ursprung in der Domäne des Require-ments 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 Sta-keholder mit einem technischen Hinter-grundwissen, deren primäre Aufgabe die Spezifi kation und das Management von Software-Anforderungen ist. Von diesem Fundament aus wurde die Modellierungs-sprache von YAKINDU Requirements kontinuierlich erweitert, um auch Stake-holder aus anderen Domänen aktiv in den Spezifi kationsprozess einzubinden. Das Ziel des Werkzeuges ist es die Probleme interdisziplinärer Zusammenarbeit und die Schwerfälligkeit von umfangreichen Doku-menten und Werkzeugketten zu adressie-ren. Mit dem Ansatz einer interdisziplinä-ren Modellierungsumgebung unterstützt die Software eine inkrementell-iterative Spezifi kation und erleichtert es damit auch effi zient mit der kontinuierlichen Änderung von Anforderungen in einem kollaborati-ven 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, nichtfunk-tionale Anforderungen mit einer formalen, funktionalen Spezifi kation zu verknüpfen und deren Abhängigkeiten und Querbe-züge sichtbar zu machen.

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

Projektstrukturplan

Spezifikation

Fdf ggdf gdfg

Sdfsdf ds sdf

dsfd d dsf

Dsfsdfd

Sdf df dfsdf

Dfsdf dfsdfdsf

Dfsd fd d sf

dsfsdfdsf

Use Cases

Requirements

Lifecycles

Actors

User Interface

User Interface Flow

Entities

58

Der Modellkatalog von YAKINDU Require-ments kann auf einfache Weise mit domänenspezifischen Modellen erweitert werden. Momentan wird die Modellie-rungssprache auf Anforderungsbeschrei-bungsmodelle des Usability Engineerings ausdehnt. Unsere Erfahrungen haben gezeigt, dass es aufgrund einer fehlenden Verknüpfung von Usability Artefakten beispielsweise oft nicht möglich ist, Desi-gnentscheidungen bis zu den ursprüng-lich erhobenen Erfordernissen aus einer Kontextanalyse zurückzuverfolgen. So sollen in Zukunft Modelle wie Nutzungs-szenarien (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 Ver-knüpfung dieser Modelle mit der formalen funktionalen Spezifikation rücken die Diszi-plinen Usability Engineering und Software Engineering stärker zusammen. So werden sich etwa Nutzungsszenarien mit techni-schen Use Cases verbinden lassen, um den Kontext der Nutzung im Spezifikationsdo-kument abzubilden. Auf ähnliche Art und Weise soll es auch möglich sein Perso-nas 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 Gestal-tungslösung für alle Stakeholder nachvoll-ziehbar zu machen.

Literatur1. 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,

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

„The agile manifesto“. The Agile Alliance.

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

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“. Addison-

Wesley Longman.

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

und -Management: Professionelle, iterative

Anforderungsanalyse für die Praxis“. Carl

Hanser Verlag.


Tutorials

59

mobilen Plattformen anstellen, müssen wir technische Einflüsse von Design-problemen sauber trennen. Gerade Smartphones lassen sich aber nicht so einfach für entsprechende Zeiter-fassungen instrumentieren – und mit der nächsten Gerätegeneration oder OS-Version sähe wieder alles anders aus.

3. Sind Mittelwert und Standardab wei ch-ung überhaupt geeignete Metriken? In der Literatur findet man immer wieder Hinweise, dass Bearbeitungs-zeiten nicht normalverteilt seien (z.B. Sauro & Lewis, 2009, Sauro, 2011; ausführliche Behandlung bei Luce, 1986), kurioserweise aber kaum Angaben, welche Verteilungen denn nun vorliegen. Dabei kann diese Infor-mation entscheidend sein: bei Expo-nential- oder Lognormalver tei lun gen sind überlange Bearbeitungszeiten

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än-digkeit 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 stan-dardkonform ist dabei die Angabe von Mittelwert, Standardabweichung, Mini-mum 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

AbstractBearbeitungszeiten 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? Rech-net 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ässigkeitsana-lyse, löst diese Probleme auf elegante Weise. Die Betrachtung verschiedener Vertei-lungstypen 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.

Bernard RummelSAP AGDietmar-Hopp-Allee 1669190 [email protected]

Bummler und Schummler – wie effizient ist mein UI wirklich?Bearbeitungszeiten analysieren und verstehen mit Probability Plots

60

keine Ausnahmen, sondern statistisch zu erwarten. Verwendet man statt des Mittelwerts Median oder geome-trisches Mittel (wie z.B. Sauro, 2011 empfiehlt), erscheinen solche Zeiten noch exotischer, als sie sind, da das geometrische Mittel typischerweise kleiner als das arithmetische Mittel ist und der Unterschied dadurch noch krasser ausfällt.

4. Wie kann man Effizienz überhaupt parametrisieren? Natürlich hängt die Bearbeitungszeit für eine Aufgabe auch von deren Kom-plexi tät ab. Ein effizientes Design zeichnet sich dadurch aus, dass gerade komplexe Aufgaben schnell erledigt werden können. Wie kann man aber die Effizienz von Designs bei verschiedenen Aufgaben vergleichbar erfassen? Sauro (2011) schlägt verschiedene Stra-tegien vor, die letztlich auf Vergleich mit „kritischen“ Bearbeitungszeiten beruhen. Solche Zeiten können z.B. maximal akzeptable Prozesszeiten, Be ar beitungszeiten von vergleichbaren Produkten, Vielfache von „Ideal“- oder „Experten“-Zeiten usw. sein. Die „bootstrapped specification limit“-Zeit (Sauro & Kindlund, 2005) ist die maximale Zeit, die Benutzer mit einer minimalen definierten Benutzerzufrie-denheit brauchten („Wie lange darf man brauchen, um nicht gar zu unzu-frie den zu sein?“). All diese Ansätze sind insofern problematisch, als sich Messfehler und zufällige Streuungen in der Zeitmessung durch den Vergleich erheblich aufaddieren können.

2. Probability Plotting

Probability Plotting ist eine graphische Methode aus der technischen Zuverläs-sigkeitsanalyse, die einige der genannten Probleme elegant löst. Zuverlässigkeitsin-genieure analysieren typischerweise Aus-fallzeiten, also die Zeit bis zum Ver sagen eines Teils. Wir hingegen betrachten die Zeit bis zum Erfolg des Benutzers, haben also genau die umgekehrte Perspektive.

Die Mathematik und einige zentrale Konzepte lassen sich trotzdem gut über-tragen. Der Grundgedanke be steht darin, die beobachteten Zeiten zu sortieren und gegen diejenigen Perzentilwerte zu plot-ten, bei denen man sie unter Vorliegen einer bestimmten Verteilungsannahme erwarten würde. Passen die beobachteten Daten zur erwarteten Verteilung, erschei-nen 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 ent-sprechenden 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ür-Schritt- Beschreibung zur Erstellung von Probability Plots (NIST/SEMATECH 2012b), auf die hier daher verzichtet wird. Eine xls-Datei mit den für usa-bility 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 vor-kommen, 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 mul-tiply 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 nut-zen. 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 Rang-nummern werden dann mit der Modified Kaplan-Meier (K-M) Product Limit pro-cedure (NIST/SEMATECH 2012c) korri-giert, 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. Ver-einfacht gesprochen ist R(t) der Anteil Benutzer, von dem man erwartet, die Aufgabe nicht zu lösen. Die beobach-teten Zeiten ti werden nun gegen die Prozentränge R(ti) geplottet. Die Achsen werden dabei spezifisch für jeden Vertei-lungstyp 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 Lognormal-verteilung. Passen die Daten zu einer bestimmten Verteilung, erscheinen die Datenpunkte im entsprechenden Plot als gerade Linie¹. [Abb. 1]


Tutorials

61

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-spezifi-schen 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är-ten 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 sicht-bar: 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 Auf-zeichnungen genauer auf weitere Auffällig-keiten inspizieren sollte.

Zur weiteren Interpretation und Parameter-schätzung werden Ausreisser entfernt und die Plots neu berechnet.

Hat man ein passendes Verteilungsmodell gefunden, kann der entsprechende Plot weiter ausgewertet werden. Die Regressi-onsgerade bietet ja ein einfaches lineares

Modell der gesamten Stichprobenver-teilung! 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, emp-fiehlt 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 Schnitt-punkte mit der Regressionsgeraden geben die entsprechenden Zeiten an.

Die weitere Interpretation und Parame-terschätzung hängt von der gefundenen Verteilung ab.

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

62

2.2.1.Lognormalverteilung

Findet man eine Lognormalverteilung, erhält man eine Normalverteilung, indem man seine Daten einfach logarithmiert. Mit diesen logarithmierten Bearbeitungs-zeiten kann man dann ohne weiteres parame trische statistische Tests wie t-Test und Varianzanalyse ausführen und auf Signi fi kanz prüfen, muss allerdings zur Beur teilung von Unterschieden auf die ursprüngliche lineare Skala zurückrechnen. In diesem Fall ist es auch völlig gerecht-fertigt, wie von Sauro (2011) empfohlen das geometrische Mittel als Statistik zu verwenden, da es gleich dem arithme-tischen Mittel der Logarithmen, zurück -transformiert auf die lineare Skala ist. Im Plot entspricht diese Zeit dem Schnitt-punkt der Regressionsgeraden mit der Zeitachse, allerdings mit einem wichtigen Unterschied: durch das censoring berück-sichtigt der Plot auch die Information von nicht erfolgreichen Benutzern, die man bei rein rechnerischer Bestimmung verwerfen müsste. Nur bei 100% Erfolgs-quote sind beide Werte gleich; bei geringeren Erfolgs quoten ergibt der Plot eine längere Zeitdauer.

2.2.2.Exponentialverteilung

Exponentialverteilungen sind typisch für Zeit-Intervalldaten. Sie sind charakteris-tisch für Prozesse wie z.B. radioaktiven Teilchenzerfall, Zeitintervalle zwischen Call Center-Anrufen etc., bei denen Ereignisse unabhängig voneinander und zufällig ein-treten. Mathematisch lässt sich die Expo-nentialverteilung 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 exponentialverteil-ten Usability-Testdaten (Beispiel: Abb. 2) fi ndet man typischerweise eine Regres-sionsgerade, die die Zeitachse nicht im Ursprung schneidet, sondern zu einer Zeit

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ösungs-rate λ, d.h. einen pro Zeiteinheit kons-tanten Anteil Benutzer, die die gestellte Aufgabe lösen. λ entspricht auch mathe-matisch der Steigung der Regressionsge-raden: ist sie steil, löst pro Zeiteinheit ein größerer Anteil der Benutzer die Aufgabe; ist sie fl ach, 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 durchzukli-cken. Es ist plausibel, dass sich diese Zeit nicht weiter minimieren lässt, sondern durch physikalische Grenzen wie System-reaktionszeiten und motorische Abläufe

bestimmt wird, also die mechanische Effi zi-enz 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 vernach-lä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 Benutzungs-oberfl äche. Die Lösungsrate λ ist damit ein direktes Maß für die kognitive Effi zienz der Benutzungsoberfl äche.

Abbildung 3 zeigt schematisch überlagerte Probability Plots von drei Apps. Die Apps A und B weisen denselben Achsenschnitt-punkt t0 auf, doch hat A eine deutlich höhere Lösungsrate λ. Würde man nur die Mittelwerte betrachten, würde A zwar bes-ser abschneiden, der Unterschied würde jedoch nicht statistisch signifi kant, da sich die beiden Verteilungen stark überlappen. Tatsächlich führt die geringere Lösungs-rate von B zu einer größeren Streuung


Tutorials

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 Konfi denzbänder der Regressionsgeraden stellen die Schätzungs- bzw. Vorhersagegenauigkeit dar. Das Exponentialmodell erklärt R²=97,5% der beobachteten Varianz.

63

und damit Standardabweichung der Zeiten. Anders ausgedrückt: je schlechter die Anwendung ist, desto schwerer ist es, diese Tatsache statistisch signifi kant 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 Klick-pfade und/oder schlechtere Systemperfor-mance 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 Design-team informierte Entscheidungen treffen. Performance-Verbesserungen von B, wie sie ein technologiefi xiertes Team mög-licherweise 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]

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 Abfl achung 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 informa-tiv, 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 Regressionsge-raden, 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 Exponentialverteilun-gen in deutlich über 80% der Fälle anzu-treffen sind; oft lassen sich beide Modelle innerhalb der Signifi kanzgrenzen anpas-sen. 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 erwar-ten, bei dem jeder Benutzer sozusagen eine Zufallsstichprobe an Usability-Proble-men zieht, die mehr oder weniger viel Zeit kosten. Die Lösungsrate λ beschriebe die relative Häufi gkeit und zeitlichen Kosten dieser Usability-Probleme, wie sie in der Gesamtheit der Aufgabe bei gegebener Oberfl äche auftreten. Auch die Verschie-bung um t0 wäre durch die technischen Gegebenheiten (Systemantwortzeit + „Durchklick“-Zeit) hinreichend erklärt.

Bei einer Weibull-Verteilung käme ein ste-tig zunehmender, negativer Einfl uss auf die Bearbeitungszeit hinzu. In der Zuverläs-sigkeitsanalyse 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äm-lich die stetige Abnahme der Lösungsrate.

Bei der Lognormalverteilung sind die Verhältnisse weniger klar. In der Zuverläs-sigkeitsanalyse fi ndet man Lognormalver-teilungen bei Prozessen, in denen Fehler-quellen sich multiplikativ verhalten, sich also gegenseitig voraussetzen. Derartige Abhängigkeiten sind auch bei Teilaufga-ben in einem Usability Test vorstellbar, aber schwierig zu analysieren.

Für die Usability-Praxis hat das Exponenti-alverteilungsmodell gegenüber dem Log-normalverteilungs-modell entscheidende Vorteile. Die Modellparameter t0 und λ haben plausible Entsprechungen in der Realität und erlauben eine sehr einfache Berechnung von Erfolgsquoten bei gege-bener Bearbeitungszeit bzw. umgekehrt den Zeiten, die man für eine gegebene Erfolgsquote veranschlagen muss. Zwar lassen sich auch im Lognormalverteilungs-modell 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 Bear-beitungszeit, die man z.B. bei verschiede-nen Designalternativen misst.

Besonders problematisch ist die Beur-teilung langer Bearbeitungszeiten, der „Bummler“. Auch bei Lognormalvertei-lungen sind solche Daten statistisch zu erwarten; sie können leicht um ein Viel-faches über der mittleren Bearbeitungs-zeit liegen. Verwendet man – statistisch korrekt – das geometrische Mittel, das in Lognormalverteilungen noch kleiner als das arithmetische Mittel ist, sehen solche

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

64

Bearbeitungszeiten für den Laien wie gro-tesk schlechte Leistungen aus, obwohl sie statistisch alles andere als auffällig sind. Da jede Zeitmessung auch eine Leistungsmes-sung beinhaltet, stellen sich hier gerade im Umfeld von Geschäftssoftware offen-sichtliche ethische Anforderungen an die korrekte Kommunikation von Testdaten.

3. Ein typischer Analyseablauf

Probability Plots lassen sich mit Tabellen-kalkulations-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 Arbeits-blätter: ein Übersichtsblatt mit Plots für Exponential-, Lognormal- und Weibull-Verteilung 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 Regressionsge-rade anzeigt.

Die Analyse beginnt mit dem detaillier-ten Exponential-Plot. Zunächst werden Ausreißer, Bummler oder Schummler identifiziert und ggfs. entfernt. Gibt es Bummler, prüfen wir auf dem Übersichts-blatt 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.

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

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

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 Lognormal-verteilung: kann ein Lognormal-Modell angepasst werden, sind parametrische Tests mit logarithmierten Daten statistisch korrekt durchführbar.

Wie alle statistischen Verfahren beschrei-ben 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 Verhaltensda-ten entfalten. Da es dort auch auf effizi-ente Identifikation problematischer Daten ankommt, bietet die Datenvisualisierung mit Probability Plotting eine wirkungsvolle Unterstützung.

Literatur1. ISO (1998). Ergonomic requirements for

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)

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-

times.php

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

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

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

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


Tutorials

65

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

Vor Beginn einer Schätzung muss das Konzept der User Experience als Eigen-schaft von Produkten für die Exper-tengruppe konsensfähig in messbare Elemente aufgeteilt werden. Dadurch wird das gemeinsame Verständnis des Begrif-fes 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 Origina-litä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.

Einleitung

Eine positive User Experience kann einem Produkt im Wettbewerb helfen, sich zu dif-ferenzieren und durchzusetzen (Rauschen-berger, Hinderks & Thomaschewski 2011). Daher erscheint es sinnvoll, die Gestaltung einer positiven User Experience bereits in der Produktplanung bewusst zu berücksich-tigen 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 Ausgestal-tungsprozess 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 Konstruk-tion 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 Produktpla-nungsprozesses bereit zu stellen.

Einfachere Methoden beruhen auf Exper-tenschätzungen, die im Produktplanungs-prozess 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 Experten-schätzungen eine strukturierte Durchfüh-rung, 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

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

AbstractProdukte ringen um die Gunst der Käufer und Nutzer. Ein Differenzierungsmerkmal zur Steigerung der Produktattraktivität ist die User Experience, weshalb der Wunsch, Produk-te 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 Evalu-ation der Handlungsoptionen erfolgen sollten; Wirtschaftlichkeit spielt weiterhin eine ent-scheidende 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.

Dominique WinterBuhl Data Service GmbH Am Siebertsweiher 3/557290 [email protected]

Jens Pietschmanncleverbridge AGBrabanter Straße 2–450674 Kö[email protected]

Schätzen der User ExperienceVon der Möglichkeit die UX bereits im Produktplanungsprozess zu erheben

66

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 Betrach-tung der User Experience im nutzerindi-viduellen Kontext durch eigene Eigen-schaften 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ücksich-tigt 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 Wahrscheinlich-keit, 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).

Brainstorming mit anschließender Zusammenfassung

Als eine einfache Methode zur Exper-tenschätzung der User Experience früh im Produktplanungsprozess bietet sich das Brainstorming an. Durch einen wenig formalen Prozess und einer diskussions-getriebenen 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 Bewer-tung 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

gearbeitet werden. Eine fokussierte Dis-kussion 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 Quali-tä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 unab-hängig voneinander betrachtet werden können, empfiehlt es sich, beide Qua-litä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 Pro-dukts, die meist nicht im Produktplanungs-prozess berücksichtigt werden, gezielt ausarbeiten und schätzen zu können.

Nachdem die Themencluster bestimmt wurden, generiert die Gruppe der Exper-ten gezielt Ideen für einzelne Aspekte des Themenclusters. [Abb. 1] Dabei können Ideen entweder der pragmatischen oder der hedonische Qualität zugeordnet wer-den. Nicht differenzierbare Ideen werden soweit wie möglich in einzelne Ideen auf-gebrochen, damit eine Zuordnung mög-lich 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 bezo-gen auf ihre Wirkung, die sowohl prag-matische als auch hedonische Qualitäten beinhalten.


Tutorials

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

67

Aus den entstehenden Ideenclustern werden anschließend die Handlungsemp-fehlungen 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.

Der Vorteil des Brainstormings ergibt sich durch die Wechselwirkungen in der Diskussion unter den Experten. Durch den argumentativen Austausch werden unter-schiedliche 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ün-det 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.

Delphi-Methode zur Schätzung von weichen Faktoren

Die Delphi-Methode (Dalkey & Helmer 1963) als qualitatives Schätzungsverfahren wird auf Basis von strukturierten Experten-befragungen in der Gruppe durchgeführt und eignet sich auch für Schätzungsverfah-ren, die nicht nur den Einfluss von Produk-tideen 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 Men-schen bewegt, jedoch nicht ausschließlich auf diese beschränkt sein muss.

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

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 unab-hängig voneinander durchgeführt. Die Ergebnisse werden anschließend katalo-gisiert, 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

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 Pha-sen 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 Experten-schätzung ist eine evaluierte Zusammen-fassung 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 Ano-nymisierung der Ergebnisse in den Phasen der Befragung und Schätzung. Hierdurch können störende Einflüsse der Gruppen-dynamik und der Meinungsdominanz ein-zelner Experten entgegen gewirkt werden (Corsten, Gössinger & Schneider 2006). Die

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

68

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 Fehl-einschä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 strategi-schen oder technischen Gründen als im Moment nicht lohnend erachtet werden. Jedoch dürfen zurückgestellte Ideen, wel-che bereits den Prozess der Expertenschät-zung durchlaufen haben, nicht einfach verworfen werden. Die zurückgestellten Ideen können in einen Ideenpool über-fü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 dokumen-tiert wurden, können gezielt Ideen zur Beseitigung von Defiziten in einzelnen Bewertungsdimensionen der User Expe-rience [Abb. 3] oder zur weiteren Ausprä-gung von bereits bestehenden Stärken des Produkts herangezogen werden. Insbesondere aufgrund der standardi-sierten Bewertungsdimensionen können Ideen zu bestimmten Handlungsfeldern gesucht, aufbereitet und erneut diskutiert werden. Beispielsweise kann bei einer summativen Evaluation der User Experi-ence des Produkts mittels UEQ festgestellt werden, dass die Ausprägung im Bereich Originalität negativ ist. Aufgrund dieser Feststellung können nun die archivierten Ideen für eine Produktweiterentwicklung herangezogen werden, die eine positive Beeinflussung der Originalität versprechen.

Der Ideengenerierungsprozess muss dann nicht erneut von vorne beginnen.

Zur Dokumentation der UX-Schätzung bieten sich für das Verwalten der Ideen spezielle Ideenkarten [Abb. 4] an, die entweder physisch oder digital vorliegen können (Winter & Pietschmann 2012). Für diese spielt es keine Rolle, nach wel-chem Vorgehen die Einflüsse geschätzt wurden. Sie bieten einen kompakten Überblick der Parameter einer Idee, welche die Aus wahl und das Priorisie-ren von Ideen in einem UX-getriebenen Innovationspro zess vereinfachen.

Auch User Storys können um UX-Schät-zungen ergänzt werden, damit ihr Einfluss auf die User Experience des Produkts als Bewertungsmaßstab in der agilen Produkt-planung genutzt werden kann. Wird eine verbesserte User Experience als Steige-rung des Werts eines Produkts verstanden, beschreibt ihre Schätzung eine erwartete Wertsteigerung für das Produkt (Pichler 2010) und kann somit wie der Geschäfts-wert (Business Value) zur Priorisierung herangezogen werden.

Zusammenfassung

Die Verwendung von Expertenschätzungen kann ein geeignetes Mittel sein, um früh im Innovationsprozess die Handlungsemp-fehlungen 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 Lern-prozesse und können implizites Wissen der Teilnehmer zu Tage fördern (Lamnek 2005). Werden Ideen entsprechend dokumen-tiert, 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 Prototypenkon-struktion kosteneffizienter und einfacher in Unternehmen zu implementieren.

Als nachteilig können sich jedoch über-dominante Experten innerhalb der


Tutorials

Abb. 3. Ideenpool als Grundlage von Ideengenerierung

69

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 Entscheidungs-instanzen nicht akzeptiert werden könn-ten. Ohne diese Akzeptanz würden die Schätzungen an Relevanz und Nutzen im Innovationsprozess verlieren. Die Defi ni-tion, was einen Experten ausmacht, kann nur teilweise bestimmt werden und nur innerhalb des iterativen Prozesses oder als Ergebnis des Erfolges der Handlungsemp-fehlung gesehen werden.

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

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ücksichti-gung von Ideenfi ndungen 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 Verbes-serungen von Mitarbeitern eingebracht werden. Voraussetzung dafür ist jedoch ein gutes Betriebsklima, das allen Mitarbei-tern erlaubt Ideen auch in dieser Richtung einzubringen (Söffi ng 2010).

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

im Rahmen der Mensch und Computer

Konferenz], H. Brau (Hrsg.), Stuttgart.

Abb. 4. Beispielhafte Darstel-lung einer Ideenkarte mit den Bewertungs-dimensionen des UEQ (Quelle: Winter & Pietschmann 2012)

70

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



Stuttgart.


Tutorials

71

Im deutschsprachigen Raum werden zwei Fragebögen zur Messung der User Expe-rience 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 Testob-jekte ermitteln zu können.

2. User Experience Questionnaire

Das Ziel des UEQ ist die effiziente Mes-sung der User Experience eines Produktes. Die User Experience wird dabei als sub-jektiv empfundener Eindruck verstanden, den der Benutzer in Bezug auf das Produkt entwickelt hat.

Die Items und Dimensionen des UEQ sind über eine datenanalytische Vorgehens-weise konstruiert. Im ersten Schritt ist eine Liste mit 229 potentiellen Items in mehre-ren Brainstorming-Sitzungen mit Usability-Experten erstellt worden. Diese Liste ist in einem zweiten Schritt von den Experten auf eine Rohversion des Fragebogens mit 80

1. Einleitung

Die User Experience (dt. Benutzererleb-nis) 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 Erfah-rung (ISO 9241–210:2010).

Es gibt inzwischen zahlreiche Methoden für die Messung der User Experience, z.B. durch die Erhebung von Gesichts-Emoti-onen 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 Verwen-dung von Fragebögen bietet den Vorteil, dass umfangreiche Benutzergruppen schnell befragt werden können.

Eine Längsschnittuntersuchung ist dann bedeutend, wenn die zeitliche Verän-derung des Benutzererlebnisses erfasst werden soll (vgl. Wilamowitz-Moellendorff et al. 2007) und sich in agilen Entwicklungs-prozessen auch das interaktive System kontinuierlich weiterentwickelt. Bei Längs-schnittstudien ist insbe sondere darauf zu achten, dass die Methode zur Messung der User Experience möglichst identisch zu den verschiedenen Zeitpunkten eingesetzt wer-den kann. Hierfür sind Fragebögen wegen des geringen Aufwands und der Standardi-sierung 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

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

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 kon-kreten 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 einge-gangen. 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.

Maria RauschenbergerMSP Medien Systempartner GmbH & Co. KGPeterstraße 28–3426121 [email protected]

Jörg ThomaschewskiHochschule Emden/LeerConstantiaplatz 426723 [email protected]

Martin SchreppSAP AG – User ExperienceDietmar-Hopp-Allee 1669190 [email protected]

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

72

Items reduziert. Diese Rohversion wurde dann in mehreren Studien zu interaktiven Produkten (z.B. Statistik-Software, Online Collaboration Software, betriebswirt-schaftliche 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 / anzie-hend, unangenehm / angenehm, attraktiv / unattraktiv, sympathisch / unsympathisch)

– Effi zienz (schnell / langsam, ineffi zient / effi zient, unpragmatisch / pragmatisch, aufgeräumt / überladen)

– Durchschaubarkeit (unverständlich / verständlich, leicht zu lernen / schwer zu lernen, kompliziert/einfach, über-sichtlich / verwirrend)

– Steuerbarkeit (unberechenbar/voraus-sagbar, 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 siebenstufi ge Lickert-Skalen realisiert, z.B.:

Attraktiv Unattraktiv

Details zur Konstruktion und zur Validie-rung des Fragebogens sind in Laugwitz, Schrepp & Held (2006) und Laugwitz, Held & Schrepp (2008) beschrieben.

Zur effi zienten Auswertung steht ein UEQ-Excel-Tool zur Verfügung (siehe Abbil-dung 1). Es genügt hier pro Teilnehmer die Be wertungen der 26 Items einzugeben. Die Dimensionsmittelwerte, deren Konfi denzin-tervalle und weitere statistische Kennwerte werden dann automatisch berechnet.

Der UEQ liefert als Ergebnis einer Befra-gung also die Werte der sechs Dimensio-nen (jeweils Mittelwert der Items pro Dimension), wie in Abbildung 1 dargestellt. [Abb. 1]

Pro Dimension wurden in der Konstruk-tion vier Items gewählt, um einerseits die Messgenauigkeit (Reliabilität), d.h. die Robustheit gegenüber zufälligen Antwort-fehlern, 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-Coeffi zien-ten α = n * r / 1 + (n – 1) * r, wobei r die durchschnittliche Korrelation der Dimen-sionen und n die Anzahl der Dimensionen beschreibt) auch numerisch ausgedrückt werden. Es gibt keine klar defi nierten 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 hin-deuten, dass einige der Items in der kon-kreten 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 Über-setzung der Gegensatzpaare in andere Sprachen übertragen werden. Bei der Er -stellung einer Sprachversion muss immer sichergestellt werden, dass durch die Übersetzung keine abweichenden Bedeu-tungen entstehen, die das Verhalten des Fragebogens beeinfl ussen. 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


Tutorials

Abb. 1. Ergebnisse für ein hypotheti sches Produkt (aus dem UEQ-Excel-Tool), d.h. Dimensionsmittelwerte und deren Konfi denzintervalle.

73

Kürze Portugiesisch. Zusätzlich sind Über-setzungen 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 heruntergela-den werden.

Der UEQ eignet sich aufgrund seiner ein-fachen Struktur für den Einsatz in verschie-denen 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 Fallstri-cke 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 Beta-Testern 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 beach-ten, dass die adressierten Nutzer die Fra-gen richtig verstehen. Ein Beispiel für die Probleme dieser Art sind Teilnehmer, die keine Muttersprachler sind, d.h. evtl. Prob-leme haben sich Items wie usual –leading edge zu erschließen. Hier wurde bewusst ein Beispiel des englischen UEQ verwen-det, um das Problem zu verdeutlichen.

Ein weiteres Problem kann auftreten, wenn es sich zwar um Muttersprachler handelt, aber aufgrund anderer Umstände ein einge-schränktes Sprachverständnis vorhanden ist.

Beim Versuch ein Web-Portal für jugendli-che Benutzer mit dem UEQ zu evaluieren, zeigten sich z.B. massive Verständnispro-bleme bei einigen Items des UEQ („Was bedeutet konventionell?“). Aufgrund dieses Rückmeldung wurde eine spezielle Sprach-version 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 Frage-bogens geprüft werden.

Enthält ein Fragebogen vollständig aus-formulierte 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 Sprach-verstä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 Extrem-fall sogar umkehren. Ein Beispiel hierzu ist das Item-Paar „sicher – unsicher“ zur Dimension „Steuerbarkeit“. Im Kontext von sozia len Netzwerken kann dieses Item-Paar anders interpretiert werden und der technischen Sicherheit von Daten zugeord-net werden. Somit ist je nach Testobjekt das Item unterschiedlich zu bewerten. Abhilfe kann ein Beta-Test schaffen, bei dem die Probanden im Nachgang zu den Items und den zugehörigen Assoziationen befragt werden.

In bestimmten Szenarien stellt sich die Frage, zu welchem Zeitpunkt der Frage-bogen eingesetzt werden soll. Gemäß Donald A. Norman „Memory is more important than actuality“ (Norman 2009), ist es rele vant das Benutzererlebnis nach der Benutzung zu ermitteln. Ist es Ziel des UEQ den subjektiven Eindruck des Benut-zers zu messen, wird der UEQ am Besten im Rahmen eines Usability Tests eingesetzt. Diskussionen mit dem Benutzer über z.B. Interaktionsprobleme beeinflussen die Mei-nung des Benutzers und verfälschen damit das Fragebogen-Ergebnis und sollten erst

nach dem Ausfüllen des Fragebogens z.B. mit einem Interview ermittelt werden.

Beim Einsatz mit Endbenutzern einer be triebs wirtschaftlichen Software sollte man versuchen, die Befragung zur User Expe-rience 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 Umstel-lung von einem alten Produkt auf eine neue Lösung (Rauschenberger et al., 2011).

Zu vermeiden ist eine „Belohnungsstruk-tur“ 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 analy-siert und interpretiert werden. Bietet der Fragebogen ein Tool zur Berechnung an, müssen nur die Ergebnisse interpretiert werden. Der UEQ bietet genau diese Mög-lichkeit 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

74

wurden die bipolaren Items bezüglich der Polung und der Reihenfolge rando-misiert, sodass die Zugehörigkeit zu den Dimensionen von den Probanden nicht erkannt werden kann. Wenn im gesamten Fragebogen alle Werte „ganz links“ (ent-spricht 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 wer-den. Dagegen sollten Items ohne Antwort von einem Probanden als eine Meinung gezählt werden (Höpfl inger, 2010).

Zu den typischen Fehlern gehört das „überinterpretieren“ der Ergebnisse, wenn beispielsweise Mittelwerte der Dimensio-nen verwendet werden, obwohl aufgrund von stark unterschiedlichen Einschätzungen der Teilnehmer die Konfi denzintervalle sehr groß sind. Große Konfi denzintervalle lassen entweder auf eine zu geringe Stichproben-größe schließen oder auf sehr unterschied-liche Antworten der Teilnehmer. Hierfür müssen die einzelnen Fragebögen gegen-übergestellt und ggf. eine Abgleichung mit der Zielgruppe vorgenommen werden.

Beim Vergleich zweier Dimensionen sowie beim Vergleich zweier Produkte ist auf die Signifi kanz von Unterschieden in den Mit-telwerten zu achten. Das UEQ-Excel-Tool gibt hierzu Fehlerbalken an, welche eine mögliche Toleranz der Ergebnisse darstellt und Konfi denzintervalle 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 Abbil-dung 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 „Sti-mulation“. In der Abbildung kann erkannt werden, dass sich der Mittelwert für das Item-Paar „uninteressant“ – „interessant“

stark von den anderen Mittelwerten dersel-ben Farben (und damit derselben Dimen-sionszugehö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 Messgenauig-keit, 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 Untersuchun-gen nicht mehr möglich.

Oft besteht der Wunsch aus dem Manage-ment eine Kennzahl für die Softwareüber-prüfung bereit zu stellen. Aufgrund der

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

5.Zusammenfassung

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


Tutorials

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

Bewertung pro Item1 0 1 2 3

uninteressant interessant

75

zur Interpretation der Items im Anschluss befragt werden. Dadurch kann eine kor-rekte Interpretation der Items durch die Zielgruppe und bezogen auf das Testob-jekt erhöht werden.

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, Konfidenzinter-valle je Item und Dimension, Varianz und Standardabweichung). Anhand der Bewer-tung der einzelnen Items können oftmals Interpretationsschwierigkeiten durch die Probanden vermutet oder erkannt werden.

Sofern die Datenanalyse keine negati-ven Auffälligkeiten ergeben hat, können sowohl die Mittelwerte der einzelnen Dimensionen als auch der einzelnen Items eine gute Aussage über den Handlungs-bedarf am Produkt oder über die Verbes-serung 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.

Literatur1. Burmester, M., Jäger, K., Mast, M., Peissner,

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

Formative Evaluation der User Experience.

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

2010, 206–211. Stuttgart. Fraunhofer Verlag.

2. Hassenzahl, M., Burmester, M. & Koller, F.

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

Spur: Zum Einsatz von www.attrakdiff.de.


2008, 78–82. Stuttgart: German Chapter der

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

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

Professionals 2012, 78 – 83. Stuttgart.

German UPA e.V.

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/

FrageformulierungDetail.shtml, zuletzt

geprüft am 14.06.2013.

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



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.

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

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

Usability Professionals 2006, 140–145.

Stuttgart. German Chapter der Usability

Professionals Assoc.

11. Rauschenberger, M., Hinderks, A. &

Thomaschewski, T. (2011). Benutzererlebnis

bei Unternehmenssoftware: Ein

Praxisbericht über die Umsetzung attraktiver

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

Usability Professionals 2011, 158 – 163.

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,

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

Measurement of User Experience. A Spanish

Language Version of the User Experience

Questionnaire (UEQ). In: Rocha, A. (Hrsg.).

Sistemas y Tecnologías de Información 2

(2013), 39–45. Madrid.

14. Wilamowitz-Moellendorff, M. von;

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

Veränderung in der Wahrnehmung und

Bewertung interaktiver Produkte. In: Gross

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

München. Oldenbourg Verlag

76


Tutorials

77

einen bestimmten Einsatzzweck erstellt wurde und damit auch aus anderen Mate-rialien oder mit einer anderen Technologie erstellt werden kann. Je nach Material kann der Prototyp anfassbar (z.B. aus Papier) oder erlebbar (z.B. ein Video) sein.

Auch die Einsatzzwecke innerhalb des Ent wicklungsprozesses können sehr unter-schiedlich sein (Houde & Hill, 1997; vgl. auch Buxton, 2007, Lim et al., 2008), beispielsweise: – Phase der Ausgestaltung:

– Neue Gestaltungsideen und

Lösungsansätze generieren

– Experimentieren mit Gestaltungsideen,

Materialien, Technologien

– Phase der Selektion:

– Gestaltungsideen, Materialien und

Technologien evaluieren

– Dokumentation von

Gestaltungsentscheidungen

Im Folgenden betrachten wir den geziel-ten Einsatz von Prototypen zur Ausgestal-tung und Selektion von Gestaltungsideen. Auf Prototypen zum Zwecke der Dokumen-tation gehen wir nicht weiter ein.

1. Einleitung

Trotz der generellen Akzeptanz von Proto-typing als sinnvoller Methode des User Experience Designs besteht in vielen Projekten unerkanntes Verbesserungspo-tential, für das wir sensibilisieren möchten. Angeregt durch unsere Erfahrung in Pro-jekten mit Studierenden und Industriepart-nern haben wir uns der Frage angenom-men, 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 schaf-fen, der es erlaubt, Erfahrungen aus ver-schiedenen Projekten zusammenzutragen und Ansatzpunkte für zielgerichtetes Proto-typing 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 syste-matisch gegenüber zustellen.

Kapitel 2 beschreibt unsere Sicht auf den Begriff des Prototyps und stellt ein Modell vor, das es erlaubt Prototypen zu charakte-ri sieren. Kapitel 3 diskutiert die Validität von Prototypen beziehungsweise die Fra ge, über welche Eigenschaften Proto typen ver-fügen müssen, um valide Ergeb nisse beim Einsatz in Evaluationsstudien zu gewähr-leisten. Der Beitrag schließt mit einem Ausblick auf zukünftige For schungsfragen.

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

Ein Prototyp ist ein Artefakt, das innerhalb eines Gestaltungs- und Entwicklungspro-zesses 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

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

AbstractDer vorliegende Beitrag beschäftigt sich mit dem systematischen Umgang mit Proto-typen 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 un-terschiedliche 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 For-schungsschritte.

Kirstin KohlerHochschule MannheimPaul-Wittsack-Straße 1068163 [email protected]

Thorsten HochreuterHochschule MannheimPaul-Wittsack-Straße 1068163 [email protected]

Sarah DiefenbachFolkwang Universität der KünsteUniversitätsstraße 1245141 [email protected]

Eva LenzFolkwang Universität der KünsteUniversitätsstraße 1245141 [email protected]

Marc HassenzahlFolkwang Universität der KünsteUniversitätsstraße 1245141 [email protected]

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

78

Unabhängig davon, welcher Einsatzzweck mit einem Prototyp verfolgt wird und aus welchem Material er besteht, ist ein Pro-totyp 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 inter-aktive 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 Proto-typen (und die damit verbundene Tätigkeit des „Prototyping“) als einen Filter auf einem nahezu beliebig großen Gestaltungs- und 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 Fragestel-lung zu ermöglichen. Wir nähern uns dieser Frage mit Hilfe eines Modells, das die gefilterten Aspekte beschreibt: das Filter-Fidelity 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) verwen-det. 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 Ver-ständnis sind die Begriffe Lo-Fi und Hi-Fi zusätzlich an das Material des Prototyps gekoppelt: Lo-Fi bezeichnet papierba-sierte, Hi-Fi hingegen computer-basierte Prototypen. Unserer Ansicht nach ist diese vereinfachte eindimensionale Klassifizie-rung eines Prototyps nur bedingt aussage-krä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-Ele-menten 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-Dimensi-onen wiederrum bestehen selbst aus einer Reihe von Qualitätsattributen (sog. Varia-blen), die zusammenfassend das Produkt/den Prototypen definieren. Eine Variable der Daten-Dimension ist z.B. die „Menge der Daten“. Durch die schrittweise Aus-gestaltung dieser Variablen im zeitlichen Verlauf eines Konzeptionsprozesses werden Gestaltungsentscheidungen getroffen, die im Prototyp repräsentiert werden. So kann der Prototyp einer Datenverwaltungsan-wendung 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 entstan-denes Modell trägt die Bezeichnung Filter-Fidelity Modell. Die Menge der ausge-wählten Variablen haben wir aus der Arbeit mit Prototypen verschiedener Projekte im Hochschulkontext und aus Anwendungs-projekten unserer Partner hergeleitet. Eine detaillierte Definition der Variablen findet sich in Hochreuter und Kollegen (2013).

2.3. FilterFidelityProfile

Ein sogenanntes Filter-Fidelity-Profil (kurz FFP, siehe Abbildung 1) ist eine grafische Darstellung der gefilterten Aspekte eines Prototypen. Es entsteht, indem jede Varia-ble 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 bezie-hungsweise 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 Produktivein-satz 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 FilterFidelityProfile

Im Rahmen seiner Abschlussarbeit an der Hochschule Mannheim entwickelt Tommy Vinh Lam ein touch-basiertes Werkzeug für


Tutorials

79

die Befundung von radiologischen Bildda-ten. Mittels einer physikalischen Linse) kann der Anwender auf einem zweigeteilten Multi-Touch-Tisch radiologische Aufnah-men digital vergrößern (vgl. z.B. Ullmer & Ishii, 1997. Zwei Prototypen aus dem Kontext dieser Arbeit werden im Folgen-den mit Hilfe ihres Filter Fidelity Profi ls charakterisiert. Abbildung 2 zeigt einen ers-ten Papierprototyp zur Navigationsstruktur. Wie zu erkennen ist, beschränkt sich der Prototyp primär auf die Abfolge von Bild-schirmseiten und ist daher unvollständig bezüglich der Erscheinung, der Funktiona-lität und der räumlichen Struktur. Lediglich einzelne UI-Elemente sind schon zu erken-nen, ebenso einzelne Datenaspekte, wie beispielsweise die angedeuteten „radio-logischen 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 fi nal ausgestaltet, entsprechend ist die Fidelity dieser Variable als eher „mittelmäßig“ anzusehen. [Abb. 1], [Abb. 2]

Abbildung 3 zeigt einen implementierten Prototyp der gleichen Anwendung. Der Fokus lag hier auf der tatsächlich spür-baren Interaktion mittels physikalischer Linse. Der Funktionsumfang ist entspre-chend gering, die Funktionstiefe der Implementierung dagegen ist ein für die Evaluation entscheidendes Kriterium und entsprechend Hi-Fi. Die grafi sche Erschei-nung ist sehr weit ausgestaltet und wird im Filter-Fidelity-Profi l dementsprechend klassifi ziert (siehe Abbildung 1). Besonders die physikalischen Aspekte der Benutzer-schnittstelle (z.B. Härte) sind stark ausge-staltet, hier handelt es sich um das fi nale 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 Daten-Dimension ist deutlich stärker vertreten. Der Prototyp verwendet sehr realitätsnahe radiologische Aufnahmen (wenn auch keine Produktiv-Patientendaten). [Abb. 3]

Abb. 1. Gegenüberstellung der Filter-Fidelity-Pro-fi le zweier Prototy-pen eines Konzepts zu unterschiedlichen Zeitpunkten im Entwicklungsprozess.

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

Einfache UI-Skizze zur Verdeutlichung der Navigationsstruktur.

80

Im direkten Vergleich der Profile (Abbil-dung 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 unbeach-tet. Der implementierte Prototyp kon-zentriert sich hingegen genau auf diese Aspekte, wobei schon erarbeitete Punkte bezüglich der Daten-Dimension beibehal-ten werden. Der zweite Prototyp besitzt entsprechend eine größere Ähnlichkeit zum Endprodukt.

3. Validität von Prototypen

Das vorgestellte Modell liefert einen ersten Ansatz, um unterschiedliche Prototypen durch die dargestellten Aspekte näher cha-rakterisieren und vergleichen zu können. Der systematische Vergleich wiederum bietet eine Basis für die Untersuchung und Optimierung des Einsatzes von Prototy-pen 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 Evaluationsstu-dien sind unzureichende Ergebnisse die Folge und die eigentliche Motivation des Prototypings wird nicht erfüllt – beispiels-weise werden anstatt Usability-Schwächen lediglich grafische Ungereimtheiten aufge-deckt (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 physi-kalischen Linse dem Anwender während einer Befundung abverlangt. Erkennt der Anwender das Mapping zwischen dem ausgewählten und vergrößerten Bildbe-reich auch bei unterschiedlichen Zoomfak-toren, 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

muss, um diese Evaluationsfrage beant-worten 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 Einflussfakto-ren 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


Tutorials

Abb. 3. Implementierter Prototyp einer physikalischen Linse

81

(z.B. Emotionen, Usability etc.) muss sei-tens 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 alterna-tiver Ideen (Phase der Selektion)? Seitens des Prototyps kommt es in erster Linie auf das eingesetzte Artefakt an, defi niert 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 spezifi sche „Konfrontationsme-thode“ eine Rolle: Beispielsweise kann ich durch reales Ausprobieren eines Prototy-pen andere Einsichten generieren als wenn ich diesen nur präsentiert bekomme oder zusehe wie andere damit agieren. [Abb. 4]

Unsere Einblicke zum Einsatz von Proto-typing in der Unternehmenspraxis zeigen jedoch meist kein systematisches Vorge-hen bezüglich der Wahl des Prototyps. Prototyping ist zwar etablierter Teil des Produktentwicklungszyklus, aber die dahinterliegenden Motivationen werden selten explizit formuliert und fl ieß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 Entwick-lungsschritten. Dieses unbedarfte Vorge-hen verwundert, da Ergebnisse aus einem Prototypentest die weitere Ausgestaltung oft maßgeblich beeinfl ussen. Im Extrem-fall könnten aus solchen Beurteilungen

folgende Gestaltungsentscheidungen (und damit das fi nale Produkt) stärker von der Art des Prototyps als vom Konzept selbst beeinfl usst 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 Prototy-pen nicht leicht, denn die Grenzen der Vor-stellungskraft und Urteilsfähigkeit von Test-teilnehmern sind noch relativ unerforscht. Es ist beispielsweise nicht klar, inwieweit die Beurteilung interaktiver Produkte tat-sä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 Evaluationser-gebnis beeinfl usst. Frühe Untersuchungen zur systematischen Gegenüberstellung verschiedener Repräsentationsformen kon-zentrieren sich meist auf den Zusammen-hang zwischen Fidelity des Prototyps und Zahl/Art aufgedeckter Usability-Probleme (z.B. Virzi et al., 1996; Walker et al., 2002). Diese zeigen insge samt geringe oder keine Effekte, das heißt ein höheres Maß an Fidelity zahlte sich nicht in umfangrei-cheren 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 bei-spielsweise Struckmeier (2011) die Dimen-sion der visuellen Verfeinerung. Hier zeigten sich zumindest tendenzielle Unter-schiede bezüglich der Art der gefundenen

Usability-Probleme. Ein Prototyp hoher visueller Verfeinerung regte zur intensi-ven Auseinandersetzung mit grafi schen Elementen und möglichen Usability-Problemen an, beim Prototyp geringer visuel ler Verfeinerung lag der Fokus hin-gegen eher auf (unnötig langen) Naviga-tionspfaden. 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 identifi -ziert 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 Auspro-bieren eines Funktionsprototyps in einer Laborsituation, Repräsentation des Pro-duktkonzepts mittels Video, Comic-Anima-tion, 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 Diefen-bach et al., 2013): – Bewusste Fragestellung: Eine wichtige Voraussetzung für eine kluge Wahl des Prototypen ist zunächst die Defi nition einer Fragestellung: Zu welchen Aspek-ten erhofft man sich Einsichten, welche Aspekte sollen besondere Aufmerk-sam keit 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

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

82

äußern ähnliche Überlegungen wie bei reichhaltigeren Darstellungsformen. Auch grundlegende Usability-Proble mekönnen schon anhand von abstrakten Darstellungen überraschend gut anti-zipiert werden. Deutliche Unterschiede zeigen sich erst auf der Ebene konkre-ter motorischer Elemente. Der Ein-stieg in die Konzeptevaluation scheint also bereits im Ideenstadium sinnvoll und bietet die Möglichkeit mit ver-gleichsweise 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 redu-zier ten Formen der Konzept dar stellung enthaltenen Freiheitsgrade nutzen Test-teilnehmer zur gedanklichen Ausgestal-tung des Konzepts nach persönlichen Vorstellungen, was typischerweise in einer insgesamt positiveren Konzept-bewertung resultiert. Bei der Inter-pretation von Evaluationsergeb nissen müssen diese Idealisierungstendenzen berücksichtigt werden.

– Aktive Auseinandersetzung: Eine häufi ge 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, wohin-gegen reduzierte Darstellungen moti vierender wirken und eher eigene Überlegungen und aktive Ausein-ander setzung fördern. Es muss somit abge wogen werden zwischen der Notwendig keit der Darstellung von Details für das Konzeptverständnis und der hieraus für den Rezipienten entstehenden „Belastung“.

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öglich-keit, 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 spezifi schen Motivation abgeglichen werden. Darüberhinaus bieten unsere Ein-sichten 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 identifi -zieren, 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 Reichhal-tigkeit 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 wel-che sinnvollen Beschreibungsdimensionen sich hier identifi zieren lassen. [Abb. 5]

Darüberhinaus interessiert uns die Relation der Dimensionen des Filter-Fidelity-Modells untereinander: Stehen die Dimen-sionen zu jedem Zeitpunkt des Entwick-lungsprozesses als gleichberechtigt und gleich wichtig nebeneinander, oder gibt es eine „ideale“ Abfolge, in der die Dimen-sionen 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 Fragestellun-gen sind gerade für die Anwendung in der Praxis von großer Bedeutsamkeit.


Tutorials

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.

83

Literatur1. 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 mixed-fidelity 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 low-fidelity, 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örderungDie diesem Beitrag zugrunde liegenden Arbeiten entstanden im Forschungsver-bundprojekt proTACT mit den Mitteln des Bundesministeriums für Bildung und Forschung (BMBF) unter dem Förderkenn-zeichen 01 IS 12010 F.

84

Cross Plattform UX

85

Sascha [email protected]

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

AbstractEine SMS schickende Kuh, der Nachrichten austauschende Müllwagen und das telefo-nierende 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 Telekommu-nikationsanbieter ihre Dienste möglichst entwicklerfreundlich und standardisiert als APIs öffnen.

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

Super-natural interaction

Schon jetzt durchdringen Navigationssys-tem, Smart Phone, Smart TV, Staubsauger-roboter und andere intelligente Systeme

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

Jenseits mobiler Anwendungen Telekommunikation trifft „Super-natural interaction“ – Von SMS bis M2M

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

86


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 Netzwerk-System. Die Schnittstelle zwischen Nutzer und Anwendung, die Interaktivität inkl. Sen-soren und Aktuatoren (ein Aktuator wandelt elektrische Signale meist in mechanische Arbeit um und bildet somit das Gegenstück zum Sensor) werden dabei immer vielfälti-ger und „intelligenter“; vernetzte elektroni-sche Geräte reagieren zunehmend auf Ihre Umgebung (Ambient intelligence, [Wikipe-dia, 2013]). Je nach Umgebung kommt der Wahl des Netzwerk-Systems ebenfalls eine wichtige Rolle zu – ob also z. B. ein GSM-Netz 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 Geschwindig-keit als auch Energieverbrauch von Bedeu-tung 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 Datenvolu-men von gerade einmal 1/1000 gegenüber einer Gesprächsminute ([Wikipedia, 2013])! [Abb. 3]

Die Durchdringung des Alltags mit Compu-tern, die Vernetzung dieser Geräte unterein-ander und die Möglichkeiten in der Mensch-Maschine-Interaktion werden zunehmen und immer mehr Kontexte bzw. Lebensbe-reiche betreffen. Dies forciert einen Para-digmenwechsel weg von der über Jahr-zehnte er lern ten 1:1 -Beziehung zwischen Mensch und Maschine hin zu komplexen 1:n Syste men 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äufi g über einen Bildschirm verfügen (Headless System, [Wikipedia, 2013]). Unsere gesamte Umgebung wird laut [Wilson, 2012] zur Benutzungsschnittstelle („Super-natural interaction“).

Abb. 2. Interaktives System

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

87

Diese Vielfalt erfordert neue Herangehens-weisen, um frühzeitig deren Nutzen im Kontext evaluieren zu können. Andern-falls wird die Kluft zwischen Mensch und Maschine eher zunehmen als verringert ([Norman, 1986, S. 111]). Dabei ist nicht nur die Spezifi zierung 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 Ent-wicklungstätigkeit bestimmen, gehen (nicht nur) Entwickler bereits jetzt davon aus, dass Anwendungen zukünftig für weitere Geräteformen erstellt werden ([Appcelera-tor, 2012]), darunter Smart TV, Connected Car, Spielkonsolen und Google Glass.

Und immer mehr dieser Geräte sind mitei-nander verbunden: Die [OECD, 2012, S. 8] erwartet, dass die Anzahl der Geräte allein im Bereich der Maschine-mit-Maschine-Kommunikation (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

Telcos beschäftigen sich intensiv mit die-sem Netzwerk bestehend aus vernetzten Geräten, dem sogenannten Internet der Dinge (Internet of Things) und suchen nach den nächsten Formen der Interaktion, Kom-munikation und Vernetzung. Bestehende Dienste wie z B. der Kurznachrichten SMS verfügen hier durchaus noch über eine tra-gende Rolle, um Innovationen zu schaffen.

Doch ohne passend qualifi zierte Entwickler in ausreichender Menge fehlt es an der Möglichkeit, diese Form der Innovationen überhaupt umzusetzen. Die Unternehmen realisieren außerdem zunehmend, dass Ent-wickler auch externe Investoren anziehen, die Innovation und Wachstum fi nanzieren ([Developer Economics, 2012, S. 4]). Der Entwickler wird zum Prosumer (Consumer und Producer): Sprich, der Entwickler kon-sumiert die Dienste eines Telcos und produ-zieren 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 Einfl uss verloren und errei-chen nur noch rund 3 Prozent der Entwick-ler. 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 rich-ten sich an Softwareentwickler).

Um für Entwickler an Attraktivität zu gewin-nen, bieten die meisten Telcos speziell auf Entwickler zugeschnittene Portale und machen darüber APIs zugänglich. Tele-fonica 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™).

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

emergency call) zuteilwerden [Wikipedia, 2013]. Denn ab 2015 muss jedes in der Europäischen Union neu zugelassene Fahr-zeug über eine Notruffunktion verfügen, wodurch sich jeder neue PKW in ein ver-netztes 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 Vorgehens-modelle (z. B. Prototyping), die helfen in diesem doch häufi g 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 gerin-ges 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 fi nden. Beispielsweise können auch Geräte und Tiere zu Mitglie-dern einer vernetzten Gesellschaft werden und miteinander Informationen austau-schen. [Abb. 4]

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

88


Cross Plattform UX

ein Video hinzuschalten kann. Dank RCS-e (Rich Communication Suite – Enhanced) steht dieser Kanal nicht nur Menschen son-dern 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/Tele-fonie und M2M. Dort fi nden 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 Zusam-menarbeit 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 Mobil-funkanbieter, kurz GSMA, zusammen.

Außerdem hilfreich sind spezielle Ent-wickler, die als Sprachrohr zwischen dem Anbieter und den Nutzern der APIs und Services agieren. Diese im angelsäch-sischen 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 kommu-nizieren die Erkenntnisse aus der Projekt-Praxis zurück ins Team.

Die Vielfalt im Angebot und die Trans-parenz in der Nutzung sind ebenfalls wichtig: Sprachdienste, Tonwahlverfah-ren, 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 Sprachdialog-system Telekom Tropo ([Tropo, 2013]) wird

beispielsweise ausschließlich Nutzungs-abhä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 GSM-Verbindung für den Transport von SMS möglich ist. Ein Anwendungsbeispiel sind Bienenstöcke, die durch eine elektroni-sche 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 Informati-onsaustausch durchaus Attraktivität sind. Kurznachrichten erreichen beispielsweise

79% bzw. 4,2 Milliarden Nutzer – SMS ist so nicht nur die meistgenutzte Datenan-wendung weltweit, sondern verfügt auch über mehr aktive Nutzer als UKW-Radio.

In der Praxis zeigen sich die Vorteile des Datenversands und -empfangs per Spra-che oder SMS gerade bei Anwendungen, die hinsichtlich Konnektivität eher in unter-versorgten Gebieten stattfi nden. 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 Emp-fängnisbereitschaft per SMS mitteilen und Bienenvölker, die täglich einen Statusbe-richt per Kurznachricht an einen Server übermitteln (siehe Abbildung 4). Und ein Sprachanruf ist nicht nur eine natürliche Interaktionsform sondern auch ein unmit-telbarer Push-Dienst z. B. im Falle von Warnungen durch Sprachsynthese.

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

89

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 Experimen-tierphasen haben sich etabliert. In Anleh-nung an die Lieferzeit von Paketzustellern werden diese als FedEx Days bezeichnet. Das Konzept ähnelt sogenannten Hacka-thons. Diese haben jedoch meist einen Event-artigeren und offeneren Charakter

Auf Seiten der Hardware kann der Aufwand ebenfalls minimiert werden, indem man auf bereits existierende Produkte zurück-greift. Insbesondere Spielzeuge bieten sich für Prototypen an: Sie sind in der Regel kosten günstig und leicht zu modifi zieren.

Bedarf wecken

Die Zutaten für einen erfolgreichen Um -gang mit „Super-natural interactions“ sind überschaubar. Motivierte und kompe-tente Entwickler, einfach zu verwendende Bausteine in Form von Software (APIs und Services), Konnektivität und leicht zugäng-liche Hardware für Interaktion und Sensorik (siehe Abbildung 2). Das gewürzt mit einer iterativen und prototypischen Herange-hensweise 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 entspre-chen die Ergebnisse nicht unbedingt den Anforderungen eines Produktes – es ist eher das Paretoprinzip, das hier zum Tragen kommt.

Die Idee der spielerischen Herangehens-weise auf Basis von vorgefertigten Baustei-nen zeichnet sich aber nicht nur dadurch aus, dass man schnell zu Ergebnissen gelangt. Neben der eigentlichen Ideenfi n-dung 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…

Literatur1. [Ahonen, 2011] Ahonen, T.: Time to Confi rm

some Mobile User Numbers: SMS, MMS,

Mobile Internet, M-News http://communities-

dominate.blogs.com/brands/2011/01/time-

to-confi rm-some-mobile-user-numbers-sms-

mms-mobile-internet-m-news.html (Stand

vom 13. Januar 2011)

2. [Alt, 2013] Alt, B.: UX Barcamp Europe

2013 – Toys are us, http://www.fl ickr.com/

photos/83052714@N05/9177425662/ (Stand

vom 30. Juni 2013)

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 Ideenfi ndung und des Business Develop-ments durchgeführt werden. [Abb. 6]

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 befi nden sich im Mittelpunkt. Und der Mut und die Offenheit für Ände-rungen 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. Refi ne: 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]

Doch auch für diese Herangehensweise müssen Rahmenbedingungen geschaffen werden, um zu einem befriedigenden Ergebnis zu kommen. Zum einen muss die Erwartungshaltung klar spezifi ziert 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 Archi-tektur: Der Rohbau zur Nutzung der APIs ist vorbereitet und die eigentliche Anwen-dung wird wie eine Fassade nur noch an den Anschlusspunkten befestigt. [Abb. 8]

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

90


Cross Plattform UX

3. [Appcelerator, 2012] Appcelerator /

IDC Q3 2012 Mobile Developer Report,

https://pages.appcelerator.com/

Q32012AppceleratorIDCSurveyReport.html

(Stand von 2012)

4. [Bitcom, 2012] Bitcom: 43.000 offene Stellen

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

themen/54633_73892.aspx (Stand vom 30.

Oktober 2012)

5. [Bundesnetzagentur, 2012]

Bundesnetzagentur: Wettbewerbsintensität

im Mobilfunk nimmt weiter zu, http://

www.bundesnetzagentur.de/cln_1931/

SharedDocs/Pressemitteilungen/

DE/2012/120824_WettbewerbMobilfunk.

html (Stand vom 24. August 2012)

6. [Developer Economics, 2012], Developer

Economics: The new mobile app economy,

http://www.developereconomics.com (Stand

vom Juni 2012)

7. [Forrester, 2011] Forrester Research, M2M

Connectivity Helps Telcos Offset Declining

Traditional Services, http://www.forrester.

com/M2M+Connectivity+Helps+Telcos+Off

set+Declining+Traditional+Services/fulltext/-

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

Dezember 2011)

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

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

john_gay/ (Stand von 2001)

9. [Medria, 2012] Medria: http://www.medria.fr

(Stand vom 8. November 2012)

10. [Norman, 1986] Donald A. Norman

(Herausgeber), Stephen W. Draper

(Herausgeber), User Centered System

Design: New Perspectives on Human-

computer Interaction. CRC Press, 1986

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

Communications: Connecting Billions of

Devices, OECD Digital Economy Papers,

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

org/10.1787/5k9gsh2gp043-en (Stand vom

30. Januar 2012)

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

für Softwareteams, http://svenpet.

com/2011/12/06/motivation_softwareteam/

(Stand vom 6. Dezember 2011)

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

Enterprise Apps Slideshow: Mobile

Application Development: A Top CIO

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

Enterprise-Apps/Mobile-Application-

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

(Stand vom 18. Juli 2013)

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.

Aufl age, Vieweg, 1996.

16. [Tropo, 2013] Telekom Tropo API, http://

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

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

2013)

17. [Wikipedia, 2013] Wikipedia: Ambient

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

Ambient_Intelligence (Stand vom 30. April

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_

Message_Service (Stand vom 12. Juli 2013)

21. [Wilson, 2012] Wilson, A.: Super-

natural interaction. Vortrag auf der Microsoft

Build Konferenz, Redmond USA, http://

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

007 (Stand vom 31. Oktober 2012)

Abb. 7. Softwarearchitektur im Sinne einer Vorhangfassade.

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

91

Steffen HessFraunhofer IESEFraunhofer-Platz 167663 [email protected]

Felix KieferFraunhofer IESEFraunhofer-Platz 167663 [email protected]

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

AbstractDer 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 Pat-terns 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.

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

Einleitung

Es existieren in der Literatur sehr viele An -sätze zur Gestaltung von User Interfaces unter Verwendung von Interaction Design Patterns (siehe [1]-[7]). Diese beschränken sich in der Regel darauf, Gestaltungsricht-linien für das Interaktionsdesign für eine bestimmte Plattform darzustellen. Daher können sie häufi g nur eingesetzt werden, um eine Lösung für ein bestimmtes Prob-lem einer bestimmten Plattform zu fi nden. 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 plattformspezifi sche Pat-terns keine konsistente plattformüber-greifende Lösung. Viele der existierenden Ansätze gehen darüber hinaus nur sehr wenig oder gar nicht darauf ein, wie eine bestimmte, spezifi sche 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

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

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

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

92


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 Interakti-onskonzepte 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 plattformspe-zifischen Ansätzen oder ein Übertrag von Plattformspezifika auf eine fremde Platt-form. Es ist jedoch zu erwarten, dass sol-che Mischkonzepte bei den Benutzern auf wenig Akzeptanz stoßen werden. Vielmehr bevorzugen Anwender native Interaktions-konzepte 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]

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 Plattfor-men 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) fokussie-ren, 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 explora-torisch erforscht und miteinander vergli-chen wurden.

Parallel wurde basierend auf existierenden Templates zur Beschreibung von UX-Patterns [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 wesentli-che 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öri-gen Reaktionen der App. Außerdem soll-ten vor allem Besonderheiten, die bei der Gestaltung der Interaktion zu beachten

sind und zentrale Bestandteile der Inter-aktion (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äl-len 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 zugrunde-liegenden 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 Pat-terns ein. Es wird dabei zunächst explizit beschrieben, welche UX-Faktoren durch

Abb. 2. Mobile UX Pattern – Pattern Basics

93

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 Beispie-len. Außerdem sollte eine allgemeine abstrakte Beschreibung der Interaktions-mechanismen hinzugefügt werden, die eine mögliche individuelle Anpassung des Patterns bei der Verwendung erleichtert.

Erstellung von Pattern

Bei der Erstellung der Patterns wurde ein starker Fokus darauf gelegt, in welchem Nutzungskontext die Interaktion stattfindet und wie konkrete Beispiele auf den jeweili-gen Plattformen aussehen.

Während der Erstellung der eigentlichen Patterns wurde außerdem eine Kategori-sierung der Patterns bzgl. der adressierten

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ßer-dem 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 unterschie-den. 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 Sen-soren 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

UX-Faktoren vorgenommen und eine Abschätzung gegeben, wie diese sich zur Umsetzung auf den verschiedenen Platt-formen eignen. Diese Einschätzung wurde auf Basis von Expertenwissen durch Befra-gung 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 Face-book 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 bei-spielsweise die Mobile Checkliste einer ständigen Anpassung unterzogen und ändert sich dynamisch. Je nach Fokus der App-Entwicklung kann auch die Darstel-lung der Beispiele erweitert werden.

Im folgenden Schritt wurden eine initiale Version der Pattern-Bibliothek für mobile UX Pattern mit 5 Pattern erstellt und exem-plarisch in Form eines Interaktionskon-zeptes der jeweiligen Plattformen umge-setzt. 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 verschie-denen Plattformen.

Diskussion

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

Abb. 3. Mobile UX Pattern Template – Pattern Experience

94


Cross Plattform UX

hinweg zu erzeugen oder aber auch eine bewusst unterschiedliche UX herzustellen.

Während der Anwendung der Pattern durch verschiedene Interaktionsdesig-ner 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 Ergebnis-ses 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 vertrauens-volle 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 Gene-rierung 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 Experi-ence 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 Sys-temen ä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 inner-halb 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 ange-messenen Nutzungskontext eine negative User Experience beim Endanwender

erzeugt wird. Daher ist es wichtig, dass in späteren Iterationen des Patterntemplate noch stärker versucht wird, auf den Para-meter 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 Explo-ration der Patterns erfolgen. [Abb. 4], [Abb. 5], [Abb. 6]

Abb. 4. Exploration Pattern – Pattern Basics

95

Literatur1. 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, Springer-

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

Windows Phone http://dev.windowsphone.

com/en-us/develop letzter Zugriff

15.03.2013

Abb. 5. Information Exploration – Pattern Experience

Abb.6. Information Exploration – Pattern Beispiele

96

Inhouse und Zulieferer Kooperation

97

Discover

In der DIN EN ISO 9241–210 startet die Planung des menschlichen Gestaltungs-prozesses damit, den Nutzungskontext zu verstehen und zu beschreiben. [Abb. 1]

Klingt einfach. Die Erfahrung lehrt jedoch, dass genau wie manchmal mitten im Ge -staltungsprozess die Spezifi kation neu erfunden und die ein oder andere Anfor-derung 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 er wartet, dass diese auch aufmerksam gele-sen wird. Das gilt auch für den Geschäfts-führer oder die Sales Kollegen, die später mit in die Präsentation kommen. Fehlt

MMI, HCI, CHI and CAI – customer agency interactionWer UX und Usability verkaufen will, muss dies auch im Pitch erlebbar machen

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

Katja [email protected]

Vicky [email protected]

AbstractAuf UX Kongressen geht es häufi g um die besten UX Methoden und zukunftsweisende Bedienkonzepte, die damit erzielt werden. Viele Besucher freuen sich auf Erfahrungsaus-tausch 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 Stake-holdern 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.

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

98


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 Inter-viewleitfaden 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.

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

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

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

– Welche „Sprache“ versteht der Kunde?

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 überset-zen. [Abb. 2]

Das Ziel dieser Phase der Anforderungs-spezifikation 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-you-like-your-graphic-design/)

99

Modelle zu defi nieren. So setzen sich in komplexeren digitalen Projekten das Pitch-Auditorium und Entscheidungsgremium in Konzernen häufi g aus Rollenvertretern mit folgenden beispielhaften Grundbedürfnis-sen zusammen (Ähnlichkeiten mit leben-den 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 Umset-zung? Verfügt der Dienst leister über die nötige Schnittstellenkompetenz? Mit welchen langfristigen technischen Aufwänden müssen wir rechnen (Total cost of ownership=TCO)?

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 Briefi ng 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 ein-geladenen Dienstleister

– Kritische Fragen: Alles, was geht. Es muss bewiesen werden, dass der externe Berater sein Geld wert ist und kniffeligere Fragen an die Präsentato-ren stellen kann, als sein Auftraggeber.

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

internationalen Konzernen auch Länder-vertreter 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 effi zient 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 vergan-gen 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 antizi-pierte 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 Mar-ken zusammen arbeitet, sondern auch, wie in vergleichbaren Branchen und Auf-gabenstellungen 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 defi nierten Personas erge-ben sich nicht nur unterschiedliche Interessenschwerpunkte und Ziele, sondern auch andere User Flows im Unternehmen. Wege der individuellen

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

100

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 Marke-tingvertreter aus der „Klassik“ wird eher über Kreation angesprochen und braucht für seine Kollegen etwas emotional Ansprechendes zum Zeigen. Der Projekt-manager erwartet hingegen Beispiele für eine transparente Planung und der Ein-kä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 Sicherheits- und Vertrauensgefühl aufbauen.

Spätestens zur Klärung der Frage nach einem geeigneten Projektvorgehen sollte man sich die existierenden Prozesse beim Kunden genauer anschauen. Insbeson-dere das Thema agile Softwareentwick-lung stellt hier eine besondere Herausfor-derung 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 professionel-ler Kommunikationsfähigkeit – und zwar von allen Projektbeteiligten.

Ist ein Unternehmen eher klassisch aufbau- und ablauforientiert organisiert, erwartet es zunächst im mentalen Modell klassische Phasenmodelle mit Dokumentationen und Plänen („Das haben wir doch schon immer so gemacht!“).

Build: Die Präsentation

Für die Präsentation gilt es, neben der Be antwortung der gestellten Ausschrei-bungsaufgaben die in den vorangegan-gen Phasen gesammelten Informatio-nen 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 Dia-loggestaltung und die charakteristischen Eigenschaften dargestellter Information aus der DIN EN ISO 9241 können auch hier inspirieren:

Aufgabenangemessenheit: – Demonstration, dass die Aufgabe ver-standen 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äsen-tationsalltag: Welche Kompetenzen helfen dem Kunden, seine Aufgaben zu erledigen?

– Was ist bei den eingereichten Unterla-gen wirklich relevant für die Zielgrup-pen und die Aufgabenstellung? Später werden die UX-Vertreter des Dienst-leisters den Kunden davon überzeugen wollen, keinen sogenannten „Eh-da“ (also bereits im Unternehmen für andere Kontexte existierenden) Con-tent auf die Website zu packen. Hier besteht die Chance, das Dienstleis-tungsversprechen erlebbar zu machen.

Selbstbeschreibungsfähigkeit – Dateinamen: Aus der Innensicht heraus neigen Dienstleister dazu „Kunde-Datum-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äu-tert, so dass sich jeder gut abgeholt fühlt und folgen kann?

– Wie können „verdauliche“ Visualisie-rungen 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 verstan-den hat und es ernst meint. Wenn ja, kommen sollte der Dienstleister mit eigenen Ideen und Optimierungs-vorschlä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 Anwendungs-ansichten auf einer Produktdetail-seite. 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 Beziehun-gen 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 Fra-gen 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 Projektspra-che 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äsentati-onsstil 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 Behauptun-gen funktionieren vielleicht kurzfristig, werden letztendlich aber zu Lasten der Agentur gehen, wenn Projektpläne und Designergebnisse nicht mit den

vereinbarten Vorgaben übereinstim-men. 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 Neukundenge-winnung 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 Telekommunikationsunter-nehmen nicht so ernst genommen und schnell als kleiner Kunde zweiter Klasse abgespeist.

– Es ist daher sehr wichtig zu demons-trieren, dass die Marke verstanden wurde und sich dies für den Kunden auch so anfühlt. Ein klitzekleiner Fehler, wie die Einbindung eines alten Logos kann hier die Befindlichkeit deutlich stören!

– Individuelle Fragen zum Kontext des Kunden, zur Meinung einzelner Teil-neh mer oder auch nach Feedback zu einzelnen Präsentationsteilen demons-trieren persönliches Interesse und ver-mitteln das Gefühl bei den Zuhörern, dass sich das Pitchteam ganz individu-ell 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 gewon-nenen Eindrücke und Informationen nut-zen, 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 Kun-den 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-Perso-nas 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 Pro-jekt) 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 Rahmen-bedingungen anzupassen.

102

Zusammenfassung:

Kunden sind auch nur Menschen. Die Erkenntnis, dass Nutzer bestimmte men-tale Modelle und Ziele zur Aufgabenerle-digung haben, ist in UX-Fachkreisen inzwi-schen weit gereift. Obwohl sich vieles mit gesundem Menschenverstand an gehen und in die Tat umsetzen lässt, soll dieser Beitrag die Augen über den fachlichen Tellerrand hinaus öffnen: UCD kann nicht nur als Methodenkoffer, sondern als Philo-sophie der Zusammenarbeit verstanden werden. Mit dieser Einstellung lassen sich auf der beidseitigen Zusammenarbeit gemeinsam die erwünschten Schritte erzielen – und damit adäquate Rahmen-bedingungen schaffen, bessere Interfaces für den Endnutzer zu gestalten.

Grafiken/Quellen/Beispiele:1. Bild 1 aus DIN EN ISO 9241–10:

Wechselseitige Abhängigkeit

menschzentrierter Gestaltungsaktivitäten:

http://blog.procontext.com/2010/03/

2. How Would You Like Your Graphic

Design? http://colinharman.com/

how-would-you-like-your-graphic-design/

3. Die genormte Sicht auf Usability und

User Experience: http://blog.procontext.

com/2010/03/



103

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

Experience durch das steigende Bewusst-sein für die Wichtigkeit einer einfachen und angenehmen Mensch-Maschine Schnitt-stelle immer stärker in den Fokus rücken.

In vielen Projekten, in denen wir Anforde-rungen erheben und UI-Konzepte erstellen sollen, werden wir mittlerweile bereits zu Beginn mit einem vom Kunden selbst erstellten Prototypen begrüßt. Als Proto-typen verstehen wir in diesem Zusammen-hang unterschiedlich detailliert ausgear-beitete User Interface-Konzepte – vom statischen Wireframes bis hin zu interakti-ven 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 entspre-chenden Fachabteilung des Kunden. Im fol-genden Erfahrungsbericht wollen wir unsere Erfahrungen mit von Kunden erstellten Prototypen, deren Eigenschaften, Vor- und Nachteile sowie Chancen und Herausforde-rungen, die sich für den eigenen Gestal-tungsprozess als auch für den Projektverlauf insgesamt ergeben, diskutieren.

1. Ausgangslage

Prototyping ist unserer Erfahrung nach eine der wichtigsten Aktivitäten im benutzerzen-trierten 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 Missin-terpretation bei Projektteam und Stake-holdern lassen und sich bei verschiedenen Beteiligten in verschiedene Richtungen entwickeln, bietet ein Prototyp eine kon-krete 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 zunehmen-den 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

2. Prototyping – Definition und Strategische Bedeutung

Generell stellt ein Prototyp ein verein-fachtes Versuchsmodell eines geplanten Produkts oder Anwendung dar. Gleichzei-tig ist Prototyping ein wesentlicher und unbedingt notwendiger Schritt im benutz-erzentrierten Entwicklungsprozess. Auf vielschichtige Art und Weise unterstützen Prototypen den Gestaltungsprozess und helfen unterschiedliche Ziele zu erreichen (vgl. Warfel 2009, p. 2ff): – Kommunikation eines Designkon-zepts – Prototypen setzen Ideen in konkrete Artefakte um. Diese können genutzt werden, um unterschiedliche Gestaltungsideen erlebbar zu machen und verhindern so Miss interpretationen.

– Testen von Designkonzepten – Iteratives Design setzt auf häufiges und frühzeitiges Testen. So können mit Hilfe von prototypisch umgesetzten Designkonzepten bereits zu einem frühen Zeitpunkt im Gestaltungsprozess erste (Nutzer-)Tests durchgeführt und das Feedback

Customer-generated PrototypesChancen und Herausforderungen von durch Kunden erstellte Prototypen für Usability Consultants

Tim Schneidermeiersmall worlds GbRBruderwöhrdstr. 15b93055 Regensburg [email protected]

Markus HecknerUniversität Regensburg, Lehrstuhl für Medieninformatik93040 [email protected]

AbstractImmer häufiger nimmt der Kunde in Usability Consulting-Projekten aktiv am Projektge-schehen 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-In-terface-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 Ansatzpunk-te 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.

104



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 Gestal-tungsprozess kann abhängig vom Fort-schritt 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 unterschied-liche 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 ausge-arbeitet und erneut getestet werden.

3. Vom Kunden erstellte Protototypen – Problemstellung und Rahmenbedingungen

Der übliche Ablauf bei Software (Re-) Design Projekten von small worlds ent-spricht dem benutzerzentrierten Design-prozess nach DIN EN ISO 9241–210 (2010): Zunächst werden Anforderungen erhoben und spezifiziert. Auf deren Basis werden mit geeigneten Methoden unterschiedli-che Designvorschläge und User Interface-Konzepte 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ürli-cher 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

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 HTML-Klickdummies 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 Usability-Tests mit solch narrativen Prototypen und ihrer stark eingeschränkten Interaktion kaum umsetzbar.

– Im Prototyp umgesetzte Anforder-ungen – In den meisten Fällen ist nicht klar ersichtlich auf welchen Anforderungen die Prototypen aufbauen: Der Kunde steigt direkt in die Designphase ein und über springt die essentiellen Tätigkeiten einer nutzerzentrierten

Anforderungserhebung. Die Prototypen basieren so häufig auf Annahmen und „gefühlten“ Anforderungen.

– Auch Prototyping will gelernt sein – Der Fokus bei der Erstellung eines Prototypen sollte im Regelfall darauf beruhen Schlüsselaufgaben des zu gestaltenden Systems, die aus der zuvor durchgeführten Anforderungserhebung hervorgehen, umzusetzen, diese zu testen und so iterativ zu verbessern. Prototyping ist nur effizient, wenn das Notwendige vom Optionalen getrennt wird: Es sollte nur die Funktionalität umgesetzt werden, die für das erfolgreiche Erledigen der zu testenden Aufgabe relevant ist. Auch eine zu starke Konzentration auf das visuelle Design senkt die Effizienz.

– Beginn beim Problem, nicht beim Design – Prototypen sind nur Mittel zum Zweck: Sie erlauben es Lösungs-strategien für Problem stellungen in konkrete Artefakte umzusetzen. Erfolgreiches Prototyping beginnt aus unserer Erfahrung immer auf dem

Abb. 2. Vom Kunden erstellter Prototyp für das Kundenportal eines Telekommunikations-dienstleisters.

106

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, Gemein-samkeiten 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 unter-nehmensinterne Software (u.a. zur Ver-waltung und Erstellung von Anschreiben)² – mit Hilfe eines nutzerzentrierten Redesign eine Verbesserung der Usability anzustre-ben. [Abb. 2]

Zu Beginn der Projekte erhielten wir zusätz-lich zu den allgemeinen Anforderungsdo-kumenten einen jeweils vom Auftraggeber vorab erstellten Prototypen als Ausgangs-punkt 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 unternehmensin-terne Software „könnte der Prototyp eine Marschrichtung vorgeben“. Tabelle 1 zeigt Unterschiede und Gemeinsamkeiten

hinsichtlich Zielsetzung, Fidelity und Inter-aktivitä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 Pro-totypen häufig unterschiedlich wahrge-nommen (funktionale und interaktionsbe-zogene 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 Anforde-rungen spezifizieren kann. Der Prototyp ergänzt weitere Dokumente, wie Lasten- oder Pflichtenhefte. Häufig ist nicht klar ersichtlich, auf der Basis welcher Anforde-rungen die Prototypen entstehen bzw. ob im Sinne eines nutzerzentrieren Ansatzes überhaupt Anforderungen erhoben wur-den. Vielmehr entsteht der Eindruck, dass es sich oftmals um subjektive Anforderun-gen und Umsetzungen des Erstellers des Prototypen handelt. Nichtsdestotrotz kön-nen vom Kunden erstellte Prototypen auch wichtige Informationen und Ansatzpunkte für den weiteren Gestaltungsprozess ent-halten, 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 Sket-ching 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 Informati-onskonzept (falls vorhanden) wird jedoch nicht mehr hinterfragt.

Während die Beziehung zum Prototypen beim Kunden eine sehr persönliche ist („eigenes Baby“, eigene kreative Leis-tung), 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 gleichzu-setzen, 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 aufbe-reiteter Prototyp à realistisches Look and Feel

In PowerPoint erstellter, funktionaler Prototyp (ohne aufwendigeres visuelles Design) à prototy-pische Anmutung

Interaktivität Klickbarar, narrativer Prototyp Klickbarar, narrativer Prototyp

Tab. 1. Charakteristika der vom Kunden erstellen Prototypen.

107

(z.B. aus Fokusgruppen oder Nutzer-tests) – wird häufi g persönlich genommen und als direkter Angriff gewertet. Bei vom Kunden als besonders wichtig eingestuf-ten Features im Prototypen können daher auch Ressentiments und hohe Behaltens-Krä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.

6.Der vom Kunden erstellte Prototyp im benutzerzentrieren Design-Prozess

Der vom Kunden erstellte Prototyp hat Auswirkungen unterschiedlicher Tragweite auf die verschiedenen Phasen des benutz-erzentrierten Designprozesses (vgl. DIN EN ISO 9241–210 2010, siehe auch Abbil-dung 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-Design-Projekten bedeutet ein zusätzlicher Proto-typ, dass die Einarbeitung in zwei Systeme erfolgen muss (Prototyp und abzulösendes System). Dementsprechend sind Ressour-cen 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. Typischer-weise können Methoden wie Wettbe-werbsanalyse, Contextual Inquiry oder

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

108

Fokusgruppen eingesetzt werden. Bei Reengineering-Projekten erhöht der vom Kunden erstellte Prototyp zunächst den Arbeitsaufwand, da man sich in zwei Sys-teme mit gleichen Zielen einarbeiten und verstehen muss. Auf der anderen Seite hat sich der Einsatz des Prototyps in Diskussi-onsrunden oder Fokusgruppen als brauch-bares 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 Anforde-rungen 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 Anforde-rungen 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 wenigs-ten von Kunden erstellten Prototypen soweit ausgearbeitet sind, dass sie ad hoc mit Hilfe von Nutzern getestet werden kön-nen bietet sich zunächst eine Experteneva-luation an. Hier müssen insbesondere auch Normen und (plattformspezifische) Guide-lines 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 Gestaltungslösungen zur Erfüllung der Nutzungsanforderungen

Obwohl bereits ein Prototyp vorhanden ist, sollte beim Design „von vorne“ begon-nen werden: Sketching bietet sich hier als erste Designaktivität an. Die intensive

Beschäftigung mit dem vom Kunden erstellten Prototypen stellt eine Herausfor-derung für die Erarbeitung von Gestal-tungslö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 bekom-men hat. Gerade beim Sketching geht es darum, viele unterschiedliche Gestaltungs-lösungen für die erhobenen Anforderun-gen umzusetzen, diese schnell zu testen und zu verbessern. Der Prototyp vom Kunden sollte auf keinen Fall den Design-raum 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.

Evaluieren der Gestaltungslösungen anhand der Anforderungen

In der Designphase wird ein eigener Pro-totyp 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.

7. Fazit und Lessons Learned

Ein vom Kunden erstellter Prototyp im Ent-wicklungsprozess 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 anse-hen, d.h. die bereits vom Kunden in die Erstellung gesteckte Arbeit sollte prin-zipiell 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 spezifi-zieren. Hier kann der vom Kunden erstellte Prototyp als ein Tool in der Analysephase verwendet werden. Zudem wirft das

beobachtete Vorgehen die Frage auf, wie viel Aufwand der Kunde in die Erstellung des Prototypen steckt. Auf der Basis unse-rer 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önli-che Beziehung, lässt sich der Kunde zudem kaum oder nur schwer von der teils parallel geführten Weiterentwicklung abbringen.

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

usability.

4. Warfel, T. Z. (2009). Prototyping: A

Practitioner’s Guide. Rosenfeld Media.

¹ http://www.axure.com

² Leider können wir aufgrund rechtlicher

Bestimmungen an dieser Stelle

keinen Screenshot des Prototypen

der unternehmensinternen Software

veröffentlichen.



109

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

zu entsprechen, was im Folgenden jeweils durch Best Practices und Handlungsemp-fehlungen illustriert wird.

2. Interesse am Dienstleister

Gerade bei größeren Projekten ist es üblich, dass Auftraggeber im Vorfeld Kontakt mit mehreren potenziellen Dienst-leistern aufnehmen, um schließlich eine informierte Auswahl treffen zu können. Da zu diesem Zeitpunkt häufig noch keine Erfahrungen bezüglich der Zusammenar-beit der beiden Partien existieren, muss der Auftraggeber auf andere Entschei-dungskriterien 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 ange-legte Zusammenarbeit ist.

2.1. Einblicke in reale Projekterfahrung

Beim ersten Kontakt mit dem Auftragge-ber 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

1. Einleitung

Viele Usability Professionals sind als externe Dienstleister tätig, die von Auf-traggebern 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 „nutzer-zentrierte“ Sicht auf den Kooperationspro-zess eingenommen: Es geht also um die Perspektive des Auftraggebers, der Usa-bility Dienstleistungen in Anspruch nimmt. Hierzu wird eine Unterscheidung von vier Bedürfnissen vorgeschlagen, die jeweils in unterschiedlichen Phasen des Koopera-tionsprozesses 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

plaudert. Dies ist für den Auftraggeber insbesondere im Bezug auf Projektaspekte interessant, die nicht nach Lehrbuch verlau-fen 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 Perso-nen mit realer Projekterfahrung durchge-führt werden, anstatt reine Vertriebsmitar-beiter einzusetzen, die an der Durchführung von Projekten nicht beteiligt sind.

2.2. LösungsHighlights

Derartige Einblicke in die Praxis des Dienst-leisters können durch die fokussierte Dar-stellung von „Lösungs-Highlights“ ergänzt werden. Diese vermitteln dem Auftragge-ber ein anschauliches Bild von Ergebnissen, die der Dienstleister in vergangenen Pro-jekten erzielt hat. Um den optimalen Effekt entfalten zu können, sollten diese Beispiele für den Auftraggeber ohne umfassende Kontextinformationen aus dem betreffen-den Projekt zu verstehen sein. Es kann sich beispielsweise um eine ästhetisch/emotio-nal 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,

Dr. Markus WeberCentigrade GmbHScience Park 266123 Saarbrü[email protected]

Sandra KöpfExact Software Deutschland GmbHKarl-Hammerschmidt-Straße 4085609 Mü[email protected]

AbstractHä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 vorgeschla-gen. 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.

„Wir kaufen Usability ein“ – Eine nutzerzentrierte SichtweiseBedürfnisse eines Auftraggebers im Rahmen der Zusammenarbeit mit einem Usability-Dienstleister

110



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 Hin-tergrundwissen 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 Dienst-leister im Rahmen einer initialen Präsenta-tion trifft, sehr heterogen. So müssen bei-spielsweise Entwickler, Produktmanager, Marketing und Vertreter des Projektma-nagements angesprochen und einbezogen werden. In einem solchen Kontext muss der Dienstleister also unter anderem die unterschiedlichen Anforderungen und Wissensstände der Teilnehmer hinsicht-lich der Durchführung von User Interface Design Projekten berücksichtigen. So ist zum Beispiel die Management-Ebene oft weniger an den Design-Prozessen interes-siert, sondern an Aufwänden, Kosten und der pünktlichen Lieferung von Ergebnis-sen. 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 bezie-hungsweise auf diesen anpassen lassen. Der Dienstleister sollte die Fähigkeit haben, die unterschiedlichen Anforderun-gen 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äsentati-onsablauf 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 Dienst-leister seine Interpretation rückmelden („Rebriefing“) und diese vor dem Hinter-grund 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 Beratungsleis-tung beginnt in diesem Sinne also bereits vor einer möglichen Auftragserteilung und bietet dem Dienstleister die Möglichkeit, sich als kritisch reflektierender Projektpart-ner 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 Zusam-menarbeit 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 Zusam-menarbeit 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 Kon-text leidet dann auch die Motivation der Beteiligten, was wiederum negative Auswir-kungen 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üh-rung 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 wahrs-ten 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 Team-mitglieder haben und die Möglichkeiten nutzen, die zur Verfügung stehen, um die Motivation hoch zu halten. Nicht zuletzt sind motivierte Teammitglieder glaubwür-dige Multiplikatoren in der Organisation des Auftraggebers.

3.1. AhaErlebnisse aus der Nutzerforschung

Motivierend können beispielsweise „Aha-Erlebnisse“ 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 Auf-traggeber 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 überraschen-den Befunde auf positive Weise vermittelt

111

werden, da sonst genau der gegenteilige Effekt die Folge sein kann und die Team-mitglieder demotiviert werden oder sich den Erkenntnissen gegenüber sperren. Es sollte beispielsweise vermieden werden, einen pauschalen Gegensatz zwischen neuen „richtigen“ Erkenntnissen und bis-herigem „falschen“ Wissen zu konstruieren. Vielmehr sollte eine Brücke geschlagen und zum Beispiel verdeutlicht werden, wie die existierende Wissensbasis als Ausgangs-punkt für Aktivitäten genutzt wurde und auf welche Weise hierdurch neue Erkenntnisse gewonnen wurden. Der Dienstleister sollte die Befunde also einordnen und verdeutli-chen, 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, Ent-wicklern 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 Pro-duktmanager 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

inhaltlich unmittelbar verwertbare Erkennt-nisse gewinnen; die Motivation kann auch dadurch entstehen, dass sie zu einer erwei-terten und tiefergehenden Sichtweise der Bedeutung ihrer eigenen Arbeit und Pro-jektbeiträge gelangen. Diese Bedeutung der Arbeit besteht nicht zuletzt darin, das Leben der Anwender angenehmer und effi-zienter 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 geleis-tete Arbeiten zu erhalten. Da das (obere) Management häufig nicht unmittelbar in die Projektaktivitäten involviert ist, können Detailentscheidungen oft nur sehr subjek-tiv oder auch gar nicht bewertet werden. Umso bedeutsamer ist es daher, auch der Leitungsebene bestätigende Rückmeldun-gen glaubwürdig vermitteln zu können. Ein nutzerzentriertes Vorgehen ermöglicht es, derartige Bestätigungen nicht nur summa-risch am Ende eines Projekts zu erhalten, sondern auch schon frühzeitig während des Prozesses zugänglich zu machen und wei-terleiten 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 Dienstleis-ter sollte sowohl bei der Gewinnung bestäti-gender Rückmeldungen wie auch bei deren Verteilung innerhalb der Organisation des Auftraggebers unterstützend tätig werden.

4.1. Feedback von Endanwendern

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

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. Wer-den Usability Tests im Rahmen eines iterati-ven 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är-ken, 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 Produkt-blogs 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 voll-stä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.3. Anwendertage

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.

112

Dies sorgt erfahrungsgemäß für Wertschät-zung bei den Nutzern, da diese erkennen, dass sie maßgeblich in die Entwicklung ein-gebunden werden, was sich ebenfalls positiv auf das Projekt und die Beteiligten auswirkt. Der Dienstleister kann hierbei unterstützen, indem er dem Auftraggeber auf der Grund-lage seiner Erfahrung allgemein und aus dem Projekt im Besonderen berät, welche Aspekte des User Interface bzw. des Prozes-ses 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 benutzerfreund-lich zu gestalten. Darüber hinaus besteht aber oft auch – explizit oder implizit – der Anspruch des Auftraggebers, seine eigenen Prozesse derart anzupassen oder so ergän-zen, dass eine fruchtbare Grundlage für zukünftige nutzerfreundliche Entwicklungen gelegt wird. Es müssen also Wissen und Know-How in die Organisation des Auftrag-gebers 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 Ins-titutionalisierung 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üh-rung 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 Nut-zer 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 Funktions-wü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 grund-legenden 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 Dienstleis-ters 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 unab-hä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 Organisa-tion des Auftraggebers angepasst und in Richtung Nutzerzentrierung ausgerichtet werden. Hierzu muss gegebenenfalls Skep-sis bei einzelnen Personen überwunden werden, indem Vorteile des „neuen“ Vor-gehens aufgezeigt werden. Dies kann erfor-derlich 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 punk-tuell als „Coach“ zur Verfügung stehen, um sicherzustellen, dass auch trotz zeitlichem Abstand und eventuell neuer Projekther-ausforderungen die wesentlichen Aspekte des nutzerzentrierten Prozesses weiterhin praktisch umgesetzt werden können.

6. Fazit

Bei der Kooperation eines Usability-Dienst-leisters mit einem Auftraggeber spielen verschiedene Bedürfnisse auf Auftragge-berseite 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 Gewich-tung 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 tre-ten. 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 Informa-tionen 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 darstel-len, 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 Auftragge-ber-Bedürfnisse bewährt haben.



113

114

Responsive UX

115

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

z.B. rechts und links der Webseite viel Freiraum angezeigt wurde. [Abb. 1]

Die Evolution des mobilen Webs

„We are no rectangle artists“

Dieses ebenso plakative wie auch zutref-fende Zitat prägte Vitaly Friedman von Smashing Magazine auf der uxmunich-Konferenz im März diesen Jahres.

Was hat er damit gemeint?

Betrachtet man sich die Entwicklung des Webdesigns, so haben Gestalter, Konzep-tioner und Kreative viele Jahre lang vor-wiegend für einen rechteckigen Viewport gearbeitet. Die wesentliche Fragestellung dabei war fast immer nur, mit welcher Bild-schirmauflösung die meisten der Nutzer unterwegs sind. Nach den Anfängen mit 800x600 Pixels setzten sich dann irgend-wann die 1024er Auflösungen durch. Aber nach wie vor wurden letztlich nur Recht-ecke 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

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

Responsive DesignA whole new world?

Joachim Stalphelaboratum GmbH – New Commerce ConsultingKaflerstraße 281241 Mü[email protected]

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ösun-gen erstellen zu können? Der Vortrag beschreibt die Entstehung von responsive Design Lösungen, und gibt einen Überblick über die Herausforderungen, die bei der Konzepti-on, 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.“

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

116


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 eingebau-ten Browser, der vollständige Webseiten anzeigen kann. Dies bedeutet aber, dass ein mühevoll für den Desktop PC konzipier-tes Layout zwar dargestellt werden kann, es in der Praxis aber keinen Spaß macht diese Webseite zu bedienen, da der Screen eines Smartphones, neben weiteren tech-nischen 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.

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 jewei-ligen 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.

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

Laut einer BITKOM Studie [1] haben Smart-phones innerhalb von wenigen Jahren den deutschen Handymarkt komplett verän-dert. 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 Pixel-Wettrüsten, und der Frage „wer bietet die beste Aufl ösung“ aus.

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.

Mit der schnellen Marktdurchdringung von Smartphones steigt auch der mobile Traffi c. Die Beobachtung der Webseiten unserer Kunden zeigt, dass der Traffi c über mobile Endgeräte im Durchschnitt um ca. 1% pro Monat steigt.

Viele Webseitenbetreiber sind deshalb auf der Suche nach einer mobilen Strate-gie, 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 Endge-rät aufgrund mangelnder Usability nicht ausreicht.

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 zwi-schen einer nativen App und einer Web-App (einer mobil optimierten Webseite) unterschieden.

Bei Betrachtung der Verteilung der Vor- und 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 wer-den für einzelne Geräteklassen optimiert. Dadurch entsteht ein erhöhter Pfl egeauf-wand von redaktionellem Content, Bildma-terial und den unterschiedlichen Quell-codes. Erschwerend kommt hinzu, dass die Website unter Umständen für zukünftige Tablet- oder Smartphone-Formate min-destens eine dritte oder vierte Version des Layouts benötigt.

Dadurch dass es bis dato keine integ-rierte Strategie gab wie Web-Inhalte den Nutzern auf verschiedenen Endgeräten angezeigt werden soll, und gleichzeitig die Vielfalt an unterschiedlichen Ausgabeme-dien 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 Diversifi kation 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ög-lichkeiten auf den verschiedenen Devices abdecken kann.

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

117

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

Was darüber hinaus bei der vollen Kon-zentration 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.

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 anzei-gen lassen, sich dort offline informieren und beraten lassen, und dann abends nach etwas Bedenkzeit auf der Couch das Pro-dukt 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 Aus-gabemedium 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 funktio-niert 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 ver-schiedene Devices und die jeweils beglei-tenden Nutzungsszenarien anzupassen.

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

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.

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 Perspektivwech-sel, weg vom Webdesign aus der Perspek-tive 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 unter-schiedlicher 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

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

Weg vom Denken in „Seiten“ (Boxen und Rechtecken), hin zu einem ganzheitli-chen 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 idealer-weise aufbereitet sein?

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 Auf-bereitung 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 Marketing-Teaser 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 + Ausga-bemedium), nur relevante Funktionen und Inhalte anzuzeigen.

Um dies greifbar zu machen nutzt Ethan Marcotte gerne den Usecase „Restaurant-Suche“ als Beispiel [7]. Wenn man eine Webseite für ein Restaurant konzipiert, kann man davon ausgehen, dass mobile Nutzer der Seite und Desktop Nutzer unterschied-liche 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

118

reservieren. Das bedeutet nicht, dass ein mobiler Nutzer nie Bilder des Restaurants sehen möchte, er hat jedoch Anforderun-gen 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 gleich-zeitig auf das jeweilige Ausgabemedium und das begleitende Nutzungsszenario eingegangen werden.

Welche Methoden und Vorgehens-wei sen müssen berücksichtigt und erlernt werden, um hochwertige, res-pon sive 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 Darstel-lung auf unterschiedlichen Ausgabeme-dien 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 Smart-phones, 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 Rich-tige. Bei diesem top-down Ansatz [Abb. 3] wird eine Webseite für die neueste Brow-ser Technologie entwickelt und optimiert.

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

Für die Entwicklung einer Webseite bedeu-tet dies konkret, dass diese für die Desktop-Nutzung optimiert wird. Das heißt, es gibt ein aufwändiges Design mit vielen Grafi ken, eine komplexe Navigation, Scripte, Slide-shows, 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.

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

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

Progressive Enhancement

Damit eine Website nicht nur vom Layout auf das Device passt, sollte eine mobile Website deshalb entsprechende Funktio-nen 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 fi rst-Ansatz. [Abb. 4]


Responsive UX

Abb. 3. Graceful Degradation

Abb. 3. Progressive EnhancementAbb. 3.

119

Für die Entwicklung einer Webseite bedeu-tet 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 untereinan-der anordnen kann, und erst bei zuneh-mend 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]

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 respon-sive [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,

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 Ent-wicklung eines responsive Designs ist tatsächlich der Startpunkt der Konzeption, nämlich mobile fi rst, wobei dieser Ansatz genauso die Prinzipien user fi rst, content fi rst, und functionality fi rst umfasst.

Um auf den sehr schnell wachsenden mobilen Traffi c zu reagieren, der einher-geht mit einer schier unendlichen Zahl an Devices mit unterschiedlichen Aufl ösungen bietet responsive Design sowohl einen Konzeptansatz, als auch eine Technolo-gie um sowohl auf das Web als auch die Nutzer einzugehen. Responsive Design zwingt dem Konzeptioner einen Nutzer-zentrierten Ansatz auf, und in User Stories und Nutzungsszenarien zu denken (Was macht der Kunde ich auf welchem Aus-gabemedium in welchem Kontext?), und nicht konzeptionell zwischen mobilen- und Desktop-Versionen zu trennen.

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

Fazit

Zusammenfassend lässt sich sagen, dass responsive Design zwar aus der mobilen Web-Entwicklung entstanden ist, da es die Problematik der strikten Trennung zwi-schen mobile und Desktop Nutzung auf-zeigt, aber es bei responsive Design nicht um die Konzeption für mobile Endgeräte geht. Es geht aber auch nicht um die Kon-zeption für den Desktop. Vielmehr geht es bei responsive Design um einen fl exiblen 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

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

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

120

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

Hier sind die ersten Schritte in der Konzep-tion 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-Dis-play angezeigt werden.

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 Tes-ting, Tracking und Betrieb (Redaktion), für die es aus meiner Sicht bisher nur wenige Lösungsansätze gibt.

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 Sys-teme damit um?

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.

Literatur1. BITKOM Presseinfo. (2013). Smartphone-

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

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/

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

the-bad-the-pretty-and-the-ugly. Folie 58.

9. Veen, Jeffrey. (2011). Vorwort zum Buch

von Marcotte, Ethan. (2011). Responsive

Webdesign. http://www.abookapart.com/

products/responsive-web-design


Responsive UX

121

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

im damit verbundenen Programmierauf-wand. Mittels Zoom-Mechanismen können Inhalte dieser Art prinzipiell zwar ohne Pro-bleme 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 tech-nische 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äte-kompabilität erreichen.

Für viele Unternehmen, die neue Geschäfts-felder 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 CRM-Systemen anzutreffen ist, 1:1 auf mobile

1. Motivation

Das starke Interesse am Thema „responsi-ves Webdesign“ ist in erster Linie der anhal-tend 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., erlau-ben aufgrund ihres ausreichend großen Touch-Screens erstmals eine umfassende Internetnutzung mit einem nahezu vollwer-tigen Internetbrowser. Die seit Jahren und laut Prognosen auch in Zukunft noch stark wachsende Verbreitung von Smartphones und Tablets [5] erlaubt nicht nur Unterneh-men 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 Bildschirm-auflösung optimiert und programmiert. Die Ursache hierfür liegt augenscheinlich häufig

Geräte zu übertragen, verdeutlicht dies. Eine Neu-Konzipierung für den mobi-len 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, Entwick-ler und Projektmanager geben, um eine bestmögliche User Experience für respon-sive Applikationen zu erzielen.

2. Begrifflichkeiten und ihre Ansätze

Die folgenden Begriffsdifferenzierungen entstanden auf Basis persönlicher, prakti-scher Erfahrungen im Themengebiet und sollen durch die eigene Expertise die ver-wendeten Begriffsdefinitionen insbeson-dere im Rahmen dieses Papers schärfen.

2.1. Responsives und adaptives Design

Grundsätzlich wird zwischen responsivem und adaptivem Design unterschieden. Die

Responsives UI DesignWirkungsvolles Mittel gegen zunehmende Gerätefragmentierung?

Nicolas LeykingErgosign GmbHEuropaallee 1266113 Saarbrü[email protected]

Jan GroenefeldErgosign GmbHEuropaallee 1266113 Saarbrü[email protected]

Markus KühnerErgosign GmbHEuropaallee 1266113 Saarbrü[email protected]

AbstractSoftwarehersteller sehen sich heute mit dem Problem einer fast unbeherrschbaren Frag-mentierung von Geräten und Betriebssystemen konfrontiert. Der Ansatz, jeder Applika-tion 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 res-ponsives Design einen „Cross Platform“-Ansatz, mit welchem die Gerätefragmentierung beherrscht werden kann.

122


Responsive UX

Schlüsselaspekte sind Flexibilität in der Darstellung und Wirtschaftlichkeit in der Umsetzung, die unter anderem durch soge-nannte „Media Queries“ und eine voraus-schauende Projektierung erreicht werden.

Bei responsivem Design, das sich insbe-sondere 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 Land-scape Mode) direkt im CSS Code abzufra-gen [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 fi xes Layout auf, das abhängig von der aktuellen Gerätebreite programmtechnisch auf vordefi nierte 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 Projektier-barkeit über viele Geräte und Betriebssys-teme hinweg einiges für den Ansatz einer Webapplikation. Denn durch den Ausbau und die Professionalisierung von JavaScript und CSS Frameworks wurden Webappli-kationen in den letzten Jahren verstärkt zu einer echten Alternative gegenüber nativ laufenden Applikationen. Webtechnolo-gien wie HTML, CSS und JavaScript ermög-lichen es, auf nur einer Codebasis eine dynamisch funktionierende Cross-Platform-Strategie zu verfolgen.

Auch wenn Web-Technologien stark auf-geholt 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 Betriebs-system eine fl üssige und stabile UI-Darstel-lung, 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 Problemstel-lungen und Lösungen aus den Bereichen Layouting und Navigation behandelt und diese mit praktischen Beispielen näher erläutert.

3.1.Layouting – Patterns

Um den Rahmen dieses Papers nicht zu sprengen, wird nun lediglich ein responsi-ves Seitenlayout näher vorgestellt. Weitere Layout Patterns fi nden sich im Internet, zum Beispiel auf der Website von Luke Wroblewski [6].

Der sogenannte „Column Drop“ ist ein gängiges, responsives Layouting-Konst-rukt, bei dem der Seitenaufbau von einem dreispaltigen Desktop-Layout über ein zweispaltiges Tablet-Layout zu einem ein-spaltigen Smartphone-Layout umgestaltet wird (8). [Abb. 1], [Abb. 2]

Ein solches dynamisch gestaltetes Appli-kationslayout basiert im Wesentlichen auf Regeln des automatischen Umbruchs von Inhalten und begegnet den unter-schiedlichen Bildschirmformaten effektiv und automatisiert. Das Regelwerk für eine solche Logik wird häufi g auf nur einer

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

Abb. 1. Dreispaltiges responsives Layoutkonstrukt [6]

123

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

3.2. NavigationPatterns

Ein weiteres Beispiel für ein responsives Konstrukt ist die bildschirmoptimierte Dar-stellung 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 Erreich-barkeit 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. FooterNavigation

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.

3.2.3. „Select“ Menü

Diese Darstellung der Navigationseinträge in einem Dropdown-Menü ist durch ihre einfache Verwendbarkeit häufig anzutref-fen. 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 visu-elle Design des Select-Controls und zum Anderen die ungewohnte Darstellung in Form eines Dropdown-Menüs [4].

Abb. 3. Listenartige Darstellung des Menüs in der Desk-topvariante [9]

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

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

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

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

124

3.2.4 „Toggle“ Menü

Für das „Toggle“ Menü Konzept gibt es viele verschiedene Darstellungs-möglichkeiten. Generell öffnet sich eine Menüstruktur, die beliebig auf dem Bild-schirm positioniert werden kann. Nach-folgende 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]

Verdecktes Menü

Die „dconstruct“ Website verfolgt den Ansatz, das Menü von oben auf der gleichen Ebene wie den Inhaltsbereich hineinfahren zu lassen und den Inhalts-bereich 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]

OffCanvas

Die Off-Canvas-Technik schiebt den In halts bereich der Webseite nach links oder rechts nahezu vollständig aus dem sicht baren Bereich hinaus. [Abb. 11] Diese hochwertig wirkende „Toggle“ Menü-Variante ist z.B. auf der mobilen „Facebook“ Website anzutreffen.

4. Responsives UI Design in der Anwendung

In diesem Kapitel wird die grundsätzliche Signifikanz sowie Strategien und Vorge-hensweisen bei der Konzipierung respon-siven Designs vorgestellt und dessen Besonderheiten in einem User-Centered Designprozess (kurz: UCD) verdeutlicht.


Responsive UX

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

Abb. 11. Off-Canvas Navigati-onsansatz [3]

Abb. 9. Von oben einfahrender Navigationsbereich [12]

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

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 Aufga-ben. In diesem Abschnitt werden lediglich die Besonderheiten des responsiven Designprozesses herausgestellt und näher erläutert.

Analyse

Innerhalb der Analysephase gilt es, ver-stärkt umfassende Informationen über die primär zu unterstützenden Bildschirmgrö-ßen und die zugrunde liegenden Geräte-konzepte zu sammeln. Dieses Wissen über Gerätetypen, Gerätehersteller, Ausgabe-größ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 visuali-siert 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änd-nisses über technische Rahmenbedingun-gen und gerätespezifische Interaktions-konzepte aus der Analysephase beginnt der UI-Designer in dieser Phase mit seinen ersten Überlegungen zu einem passen-den 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 Dar-stellungsvarianten ausprobiert werden. Mit dem „Mobile First“ Ansatz hingegen wird, beginnend mit der kleinsten anzunehmen-den Geräteklasse, die Reduktion auf die wesentlichen Elemente gefördert. Es muss

aufgrund der kontextabhängigen Funktio-nen 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 Ausrich-tung (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 „Wel-chen Gesamt eindruck möchte ich erhal-ten?“ 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ößenan-gaben 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 Lay-outstruktur schon frühzeitig in leichtge-wichtige HTML-Prototypen überführt. Diese sehr einfachen Prototypen dienen lediglich dem Zweck, das Layout und sein Verhalten auf mehreren unterschiedli-chen 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 HTML-Prototypen 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 Bedienbar-keit zu gewährleisten. Die dabei gewon-nenen 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 Ergeb-nis der Konzeption beinhaltet das flexible UI-Layout und die darin positionierten Con-trols, Media Daten und sonstige Inhalte.

Validierung

Die responsiven Besonderheiten der Vali-dierungsphase sind in dem notwendigen erweiterten Testumfang wiederzufinden. Das Design sollte dabei auf möglichst allen unterschiedlichen Bildschirm- und Plattformtypen getestet werden, um ein möglichst allumfassendes Bild des responsiven UI zu erhalten. Es empfiehlt sich, die Validierungsergebnisse schriftlich zu dokumentieren und bei Bedarf in das bisher entstandene Applikationslayout zu überführen.

Spezifizierung

Für die Spezifizierung responsiven Designs bietet es sich an, die klassischen Spezifi zie-rungsdokumente mit den in der Design-phase erstellten HTML-Prototypen anzu-reichern, um so den Entwicklern die Mög lichkeit zu geben, das UI und sein Ver-halten 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 prakti-schen Beispiele für responsive UI-Elemente entstammen einer Webapplikation der SAP AG, die Manager bei ihren Verwal-tungs- und Planungsaufgaben unterstützt. Aufgrund der agilen Arbeitswelt der Mana-ger eignet sich eine responsive Umset-zung 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. Desweite-ren sollten mobile Android- und Windows-Geräte unterstützt werden, allerdings mit einer geringeren Priorität.

126

MasterDetailKonzept

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 Tabletausrich-tungen 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 Ein-satz. [Abb. 12]

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 Transfor-mation dieses Tablet-Layouts aufgrund des eingeschränkten verfügbaren Platzes nicht sinnvoll, weshalb dieses UI-Pattern eine separate Darstellungsvariante von Master- und Detail-Bereich erfordert. [Abb. 15], [Abb. 16] Für diese Darstellungsvariante ist jedoch eine neue Navigationsmöglich-keit im responsiven Design vorzusehen, um von dem Detail-Bereich wieder zurück in den Master-Bereich wechseln zu können.

FlyOut vs. FullscreenKonzept

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 weitestge-hend auf Geräten mit größeren Bildschir-men, wie Tablets und stationären Geräten zu finden ist, ist für die kleinen Smartphone-Screens nicht immer sinnvoll und es empfiehlt sich, ab einer bestimmten Infor-mationsmenge einen eigenen Screen für die Informationen vorzusehen. [Abb. 19], [Abb. 20] Hierzu sind die oben erwähnten „Media Queries“ und flexiblen Größenan-gaben vonnöten, damit sich das Layout an alle Smartphone-Bildschirmgrößen anpasst.


Responsive UX

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

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

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

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

Abb. 14. Shopping Cart im Portrait Mode auf dem iPad mit eingeblendetem Master-Bereich [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 Projekterfahrun-gen entstanden sind. Die hier aufgelis-teten Ratschläge sind als grundlegende praktische Empfehlungen für responsive Designprojekte zu verstehen. [Tab. 1]

5. Fazit

Wie das vorangegangene Kapitel 4 zeigt, ist der Gestaltungsprozess für ein respon-sives Design eine aufwendige, komplexe Aufgabe, die das gleichzeitige Konzipieren eines flexiblen Layouts für verschiedene Bildschirmgrößen erfordert. Die kontinu-ierliche 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 respon-siven Designs trägt hierfür zwar zum Einen zu einer wirtschaftlichen, also kostengüns-tigen Implementierungsphase bei und hält den zukünftigen Wartungsaufwand gering, erzeugt aber zum Anderen einen sehr hohen Aufwand in den oben genann-ten Designprozessen. Diese Balance aus Aufwänden in Design und Entwicklung erscheint symptomatisch für Projekte die-ser 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ätefrag-mentierung?“ zwar mit „Ja“ beantworten, allgemeingültig ist diese Antwort jedoch aufgrund des variablen Aufwand-Nutzen-Verhä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,

Abb. 17. Kalenderdarstellung auf dem iPad [14]

Abb. 19. Kalenderdar- stellung auf dem iPhone [14]

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

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

128

das Verhältnis von Aufwand und Nutzen negativ beeinflussen. Um die ohnehin sehr umfangreiche Konzeptionsphase nicht aus-ufern zu lassen, ist zu empfehlen, responsi-ves Design bei überschaubaren und nicht zu komplexen Applikationen anzuwenden, denn nur bei solchen Anwendungen kön-nen die Aufwendungen für die Design-phase möglichst gering und die positiven Effekte, die durch die gemeinsame Code-basis in der Implementierung und Wartung auftreten, klein gehalten werden.

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

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

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

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


Responsive UX

Tab. 1. Dos and Don’ts

Dos Don’ts

– Sorge für ein teamweites Wissen und Verständnis über responsives Design.

– Einsatz von fixen Layouting-Tools (z.B. Photoshop oder Fireworks)

– Durchdringe deine Zielplattformen und lerne ihre User Experience im Details kennen.

– Entwicklungsbeginn vor Abschluss und Abnahme des Designs

– Teste dein Layout mit leichtgewichtigen Prototypen so früh und auf so vielen Plattformen wie möglich.

– 1:1 Übertragung des Designs von Desktop auf Mobile

– Stelle die Prototypen den Entwicklern in der anschließenden Entwicklungsphase zur Verfügung.

– Verzicht auf relevante Inhalte aufgrund von Platzmangel. Inhalte sollten in diesem Falle anderweitig zugänglich gemacht werden.

– Sprich mit langjährigen Benutzern der Plattformen über deine Layout-Entwürfe.

– Dokumentiere das Verhalten des Layouts durch anschauliche Mittel.

129

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

Das Projekt

Zu Beginn des Jahres 2012 entschied sich mobile.de, Deutschlands führender Online-Fahrzeughandelsplatz, 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 Nie-derlanden 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.

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

Einleitung

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 Konse-quenz. 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.

Immer häufiger kommen dafür agile Ent-wicklungsmethoden zum Einsatz. Im Kern geht es dabei um die Erstellung von Soft-ware in transparenten und flexiblen Teil-pro zessen durch ein iteratives Vorgehen, bei dem sich Planungs- und Entwicklungs-phasen 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 Herausfor-derungen in einem derartigen Projekt und stellt eine konkrete Herangehensweise vor, wie man diese meistern kann.

drei Entwicklungsteams (iOS, Android, Web) mit zu hohen Aufwänden verbunden gewesen wäre

Insgesamt sollte das umfangreiche Fahr-zeugangebot von mobile.de in den er wähn-ten Ländern besser vermittelbar werden, zu stärkerem Absatz bei Fahrzeughändlern in Deutschland sowie zu erhöhter Zufrieden-heit und einer ganzheitlichen Einkaufserfah-rung 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-Entwick-lern 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?

Herausforderungen für UX-Teams in „Responsive Design“-Projekten im agilen KontextEin Beispiel für die Zusammenarbeit im Projektalltag von mobile.deMichael FleckUSEEDS° GmbHFriedrichstr. 20910969 [email protected]

Stephan Köppmobile.international GmbHMarktplatz 114532 Europarc [email protected]

AbstractDie Integration von User Experience in agilen Entwicklungsprozessen stellt sowohl das UX-Team als auch die IT vor Herausforderungen: Wie kann man in optimaler Weise zusam-menarbeiten und die Nutzerbedürfnisse bestmöglich in den Prozess integrieren? Welche Anforderungen kommen hinzu, wenn es sich um die Umsetzung mittels Responsive De-sign 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.

130


Responsive UX

– Wie konzipiert / designt man für Res pon sive Design? Erstellt man ein Konzept, drei oder mehr Konzepte? Sind die Inhalte von mobile.de (kom -plexe Formulare und Ergebnis listen) überhaupt für dieses Vorgehen taug-lich? Wie sehen die Deliverables aus?

Vorgehen

In der Anbahnungs- und Angebotsphase wurden unter Zuhilfenahme der „Project Canvas“ (Kalbach 2012) der Kontext, alle Meilensteine, Verantwortlichkeiten und Risiken des Projekts ermittelt.

Für die grundlegende Zusammenarbeit von mobile.de und USEEDS° wurde sich auf einen Prozess verständigt, der von beiden Parteien eine sehr enge Abstim-mung 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 Umset-zung ermittelt und erprobt. Die Sprint-Phase hin gegen markierte den Zeitraum der eigent lichen technischen Umsetzung in agilen Entwicklungsteams. Für die sinn-volle Koor di nation der einzelnen Beteilig-ten 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 arbei-tete, während mobile.de die im vorigen Sprint erarbeiteten Vorgaben aus Konzept und Design umsetzte. Dies erforderte gerade von bisher nicht agil arbeitenden Design- und Konzeptteams große Disziplin und Fokussierung, um die vorgegebene enge Taktung der Sprints auf Kundenseite (14 Tage Sprint dauer) zu verinnerlichen und sich darin ein zu fügen. Das Prinzip der engen Abstimmung ermöglichte es, Red-undanzen 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 Abstim-mungsrunden dabei, konnte so direkt mit dem Konzepter und Designer interagieren und frühzeitig Machbarkeiten klären sowie geplante Funktionalität modularisieren und in sein eigenes Entwicklerteam weitergeben.

Discovery-Phase

In der Discovery-Phase planten nach the matischer Absprache USEEDS° und mobile.de jeweils einzeln ihr Vorgehen und ihre Agenda und gaben sich regel-mäßig Feedback.

Abb. 1. Arbeitsprozess und Zusammenarbeit von Development und UX

131

Auf mobile.de Seite wurden vor allem Back-endentscheidungen 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 Strate-gien sollten verwendet werden, um Lade-zeiten 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 Designexplo-ration. Da diese Etappe der eigentlichen agilen Zusammenarbeit vorgelagert war,

konnten aufwändigere Researchmetho-den 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 Ana-lyse des Anwenders und seines Nutzungs-kontextes vorzunehmen. Die Betrachtung der Google Analytics-Daten hatte erge-ben, 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 passen de Methode angewandt. [Abb. 2]

Im Schnitt wurden 350 Teilnehmer pro Land unter Anderem zu ihrer favorisierten Zahlungsart, den verwendeten Endge-rä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ög-lichst 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.

Diese Erkenntnisse wurden frühzeitig an die Verantwortlichen bei mobile.de zurück-gespielt, um so bereits an technischen Lösungen arbeiten zu können, mit Drittan-bietern (z.B. Google Translate, Microsoft Bing) in Kontakt zu treten oder dem Kon-zept weiter zuzuarbeiten. Dieses sah in diesem konkreten Fall vor, dass statt dem bisher für die Kontaktaufnahme mit dem Fahrzeughändler verwendeten Freitext-feld ein an ein Anschreiben angelehntes Formular dem Nutzer die initiale Kommu-nikation erleichtern sollte. Nur persönliche Daten, wie Name oder E-Mailadresse mussten noch eingegeben und aus einem vorbereiteten Fragenpool die gewünsch-ten 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 wer-den sollen, zum Anderen welchen Inhalt man auf den jeweiligen Kanälen spielt, und ob Features im mobilen Kontext wegge-lassen werden können. Für die Geräte-entscheidung halfen Business-Ziele und Analyticsdaten (Desktop 1024 px Breite, iPad portrait, iPhone portrait).

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

132

Die Ermittlung der Inhalte pro Seite und Geräteklasse gestaltete sich gerade bei mobile.de und dem Formular- und Ergeb-nislistenlastigen Content etwas anspruchs-voller. Dazu wurde sich im ersten Schritt mit dem Kunden auf eine bestimmte Keyscreen-Strecke verständigt (Home-page, Detailssuchseite, etc.). Anschließend musste festgelegt werden, in welcher Art die Wireframes zu erstellen sind. Um die User Experience auf jeder der drei defi nier-ten Geräteklassen sicherzustellen, wurde entschieden, dass für jede Klasse (Desktop, iPad, iPhone) ein eigenes Konzept erstellt wird, d.h. jeder Flow in jeder defi nierten Bildschirmgröße. Im nächsten Schritt war es sehr hilfreich, mit groben Blöcken zu skizzie-ren, wie und vor allem wo welcher Inhalts-bereich 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 defi nierten die Designer bei USEEDS gemeinsam mit den Frontend-Entwicklern 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 Kandi-daten für Interfaces mit den Entwicklern abgesprochen und durch ein schnelles Ausprobieren eine Entscheidung herbeige-führt. Dahingehend fungierte der Fron-tend-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 defi nierte Geräteklas-sen gleichzeitig berücksichtigt werden, um einen Styleguide defi nieren zu können, der eine homogene User Experience über alle Devices hinweg entstehen lassen konnte.


Responsive UX

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

133

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öge-rungen 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

Features stark involviert. Dies garantierte konkretes und direktes Feedback der Entwickler und so eine spätere Umsetzbar-keit und Portierbarkeit auf alle defi nierten Devices. Oft kamen auch Prototypen zum Einsatz, um Haptik und Funktionali-tä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 gehal-ten werden konnten. Die fertigen Designs wurden mobile.de als offene Grafi kdateien (PNG, PSD) geliefert. So konnten sich die Entwickler ohne Abstimmung, Zusatzauf-wand 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 defi niert.

Diese sogenannten „Wachstumsfl ächen“ beschreiben im Konzept und in der Gestal-tung wie Content umbricht und wo Fluid Grids wirklich ihre variablen Eigenschaften offenbaren können. Diese Festlegungen halfen den Entwicklern dabei, ein Grund-gerüst der Seitenanordnung zu erstellen, auch wenn das Design noch nicht fi nal abgenommen war.

In die aktuelle Entwicklung der Anwen-dung war USEEDS° dahingehend involviert, als dass Sprint-Support bereitgestellt wurde und so während der Erstellung Desi-gnunterstützung geleistet werden konnte. D.h. es konnte auf noch fehlende Assets oder erst in der Entwicklung aufgetretene Zustände oder andere Herausforderun-gen schnell reagiert werden. Weiterhin konnte man sich durch einen Zugang auf die Testumgebung von mobile.de über

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

134

die Fortschritte informieren aber auch qualitätssichernd agieren. Auf Nutzertests wurde in dieser Phase ob des straffen Zeit-plans 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 Mitspra-cherecht bei vielen technischen Entschei-dungen war für USEEDS° die Integration der ermittelten Nutzerbedürfnisse, die rasche Reaktion und Lösungsgenerie-rung bei Barrieren sowie eine gute QA in hohem Maße gegeben.

Projektergebnisse

Resultat ist ein ansprechendes und funktio-nales Produkt, welches auf den besonderen Informationsbedarf seiner europäischen Zielgruppe eingeht und gleichzeitig Unsi-cherheiten während des Fahrzeugkaufs im Ausland reduziert, indem es Vertrauen schafft. [Abb. 4] Durch „Responsive Design“ werden der mögliche Nutzungs-kontext und damit die ständige Verfügbar-keit der Anwendung erweitert. Die dynami-sche 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 Aus-land geplant.

Erkenntnisse und Fazit

Die Herausforderung in diesem Projekt bestand neben den individuellen Eigen-schaften (z.B. ist der komplexe Inhalt von mobile.de abbildbar im mobilen Kon-text – JA) vor allem darin, eine für beide Parteien nützliche und sinnvolle Art der

Zusammenarbeit zu finden, zu optimie-ren und zu leben. Es musste sich vom generellen Rahmen bis hin zu konkreten Fragen der Linkgestaltung und Pattern-auswahl 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 Vorha-ben 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 Frontend-Entwickler auf ein Grid /Raster verstän-digt 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.

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

Konzepter-Teampraktikable Vorgehen herausgestellt. Durch die für ein Touch-Interface optimierten und damit oft räum-lich großzügig gestalteten Schaltflächen war sowohl eine Portierung in das mobile Layout als auch in das breitere Desktop-Grid 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, Entscheidun-gen (vor allem technischer Natur, Frame-works 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 Offen-heit des Kunden die Möglichkeit, Metho-den, 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.

Literatur1. Cagan, M., Agile Development

Processes, Onlinequelle von: http://www.svproduct.com/agile-development-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-project-canvas-defining-your-project-visually/ (Zugriff: 28.06.2013)


Responsive UX

135

136

UX Best Practices

137

Keywords: /// Medizintechnische Produkte/// Consumer Interfaces/// User-Experience-

Management/// Nutzerzentrierter

Entwicklungsansatz/// Agiles mehrstufiges

Projektmanagement

medikamentöse Insulingabe, Nahrungs-aufnahme und Aktivität möglichst stabil zu halten.

Analoge Diabetestagebücher sind nicht in der Lage, Kurvenverläufe und Auswertun-gen über einen frei definierbaren Zeitraum darzustellen und so diese Zielsetzung zu unterstützen. Zudem ist die Eintragung zusätzlicher Werte (z. B. Nahrungsauf-nahme, Medikamentengabe, Aktivität und Anmerkungen zur körperlichen Verfassung) aufwändig und wenig standardisiert.

Die B. Braun Melsungen AG greift als Auf-traggeber in der Entwicklung des Omnitest Blutzuckermesssystems die relevantesten Anforderungen zur Optimierung dieser Aus-gangssituation auf und bildet ein gesamt-heitliches Diabetes-Management-System

1. Ausgangssituation und Zielsetzung1.1. Systembeschreibung

Diabetiker sind auf eine häufige, regelmä-ßige Kontrolle und Dokumentation der Blutzuckerwerte angewiesen, welche eine Grundlage zur Berechnung ihrer individu-ellen Medikation bilden.

Blutzuckermesssysteme in der privaten Anwendung bestehen bislang zumeist aus einem portablen Messgerät mit entspre-chendem Zubehör und einem analog zu führenden Diabetestagebuch. Die Not-wendigkeit eines Tagebuchs ergibt sich aus der Zielsetzung, den Blutzuckerspiegel des Betroffenen wegen der gestörten Insulin-produktion bzw. -rezeption künstlich durch

aus Hardware (Omnitest 3D mit GSM-Modul zur automatisierten Übertragung von medizinischen Werten), medizintechni-scher Analyse-Software, zentralem Daten-bank-Server, browserbasiertem Online-Diabetestagebuch (Omnitest Center) und mobiler Diabetestagebuch-Applikation (Arbeitstitel: Omnitest Mobile) zur optimier-ten 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 Kom-fort bei der teilweise automatisierten

Best Practice „Tele-Medizintechnik“:User-Experience-Design eines gesamt-heitlichen BlutzuckermesssystemsEinblicke in die Prozessstandards bei der umfassenden Gestaltung von der Softwarearchitektur über Gerätefunktionen und Bedienoberflächen bis zur Anleitungs- und VerpackungskommunikationOliver Gerstheimerchilli mind GmbHKönigstor 23 34117 [email protected]

Steffen Wüstchilli mind GmbHKönigstor 23 34117 [email protected]

Dr. Michael HartmannDirector Marketing and DevelopmentCoE Diabetes CareB. Braun Melsungen AG34212 [email protected]

AbstractDie 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 Software-Bedienoberflä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 unterschied-licher 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-Expe-rience-Testing von Einzelelementen und des Gesamtsystems. Dies alles vor dem Hinter-grund 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 Standardisie-rung wie auch bei Projektkommunikation und -koordination.

138


UX Best Practices

Dokumentation, Auswertung und Visu-alisierung der Vitalwerte. Andererseits werden durch das optimierte Manage-ment langfristig Begleit- und Folgeer-krankungen reduziert. Dies hat neben den individuellen Vorteilen für die Betroffenen selbstverständlich auch Auswirkungen auf die gesamtwirtschaftlichen Gesundheits-kosten, da weltweit, zunehmend auch in Schwellenländern, die Zahl insulinpfl ichti-ger Patienten stark zunimmt.

1.3.Herausforderung und Alleinstellungsmerkmale 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 Blutzucker-messwerten auf ein digitales Diabetesta-gebuch im Fokus steht.

Ein kundenfreundlich auszugestaltendes Diabetes-Management-System stellt die bedürfnis- und usabilitygerechte Nutzung für Patienten mit spezifi schen Anforderungen, sowie optimierte

Kommunikationsprozesse in einem „End-to-End“-Konzept (vom Blutstropfen bis zur langfristigen Auswertung) in den Vordergrund.

Betroffene, pfl egende Angehörige und medizinisches Fachpersonal werden unter-stützt durch: – Automatisierte Prozesse in der Erfassung und Dokumentation von Messwerten;

– Spezifi sche Algorithmen für Analyse- und 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 mehrstufi gen Phasenmodell, dessen Ergebnisse nachfolgend in Form von „Lessons Learned“ aufgezeigt werden.

Welche Vorteile bietet dieser mehrstufi ge und iterative Entwicklungsansatz?

Durch die aufeinander aufbauenden, iterativen Entwicklungsschritte wurde die Beachtung nutzerspezifi scher, technischer und rechtlicher Anforderungen und Vorga-ben im Entwurfsprozess sichergestellt. Die detaillierte Dokumentation von Spezifi ka-tionen bildete hierbei die Grundlage zur Überprüfung der Milestones im Entwick-lungs- und Umsetzungsprozess.

Die in jedem Prozessschritt integrierte Qualitätssicherung der Einzelschritte, Teil-ergebnisse und des Gesamtergebnisses spielte, auch vor dem Hintergrund der ausdrücklichen Dokumentationspfl ichten medizintechnischer Entwicklungsprozesse, eine zentrale Rolle. So konnten frühzeitig Abweichungen und suboptimale Ergeb-nisse identifi ziert werden. In der Folge wurden Spezifi kationen und Entwürfe an -gepasst, überarbeitet, ergänzt und konn-ten als Änderungsanforderungen (Change Requests) in den Entwicklungsprozess integriert werden.

Erst dieser schrittweise und integrative Entwicklungsprozess garantierte die Hand-habbarkeit eines komplexen, letztendlich

Abb. 1. Omnitest Gesamtsystem

139

auch agilen Entwicklungsprozesses und der darin auftretenden Abhängigkeiten und Seiteneffekte zwischen den Einzelele-menten des Gesamtsystems.

2.1.Anforderungsanalyse2.1.1.Persona Design

Als Grundlage der Anforderungsanalyse wurden nach Briefi ng-Gesprächen mit dem Auftraggeber (Produktmanagement, Marketing & Sales) und weiteren Experten vier prototypische Patienten-Personas sowie eine professionelle Persona defi -niert. Zielsetzung war die Abbildung eines breiten Nutzerspektrums hinsichtlich Alter, Nutzungsverhalten und technischer Affi ni-tät in Abstimmung mit real existierenden Patienten- und Nutzertypen.

Lesson Learned

Die szenarisch zugspitzte Identifi kation 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

essenzielle Grundlage von Anforderungs- und Funktionsspezifi kationen. [Abb. 2]

2.1.2.Anforderungsdefi nition

Das Anforderungsprofi l an ein Blutzucker-messsystem orientiert sich vorrangig an besonderen Erfordernissen und Einschrän-kungen, welche vor allem langjährige Dia beteserkrankungen mit sich bringen können. In Interviews auf Basis des Persona Designs wurden eine Reihe zentraler Akzeptanz-Kriterien identifi ziert, 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 affi ne Nutzergruppen;

– Schnelle Messung und Dokumentation des Blutzuckerwerts da z. T. mehr als fünf mal pro Tag gemessen werden muss;

– Automatische Übernahme von Mess-werten und optionaler Zusatzwerte in ein digitales Diabetestagebuch als Prozessoptimierung in der Doku men -tation;

– Optimierte Auswertung der Messwerte und Visualisierung in unterschiedlichen Formaten (Grafi k, 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 spezifi sche Anfor-derungen von Betroffenen und professio-nellen Anwendern aus der Praxis ergänzt.

2.1.3.Defi nition Use Cases

Nachfolgend wurden Use Cases für die drei geplanten Anwendungsfälle Blutzu-ckermessgerät (Omnitest 3D), digitales Diabetestagebuch (Omnitest Center) und

Abb. 2. Zwei Beispiele für Perso-nas (Kurzbeschreibung)

140

mobile Applikation (zukünftig Omnitest Mobile) defi niert. Die Dokumentation der Use Cases für das Blutzuckermessgerät in Form von Flowcharts bildete hierbei die Grundlage der Softwarespezifi kationen des Hardwareherstellers, die defi nierten Use Cases des Diabetestagebuchs wurden direkt in die Software Requirement Spe-cifi cations 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 Defi nition der Use Cases bildet die Grundlage der nachfolgenden Konzeption und Spezifi kation. In Abstim-mung mit den Projektbeteiligten kann so zu einem frühen Zeitpunkt ein hoher Detail-lierungsgrad erreicht werden, der spätere Anpassungen auf ein Minimum reduziert.

2.2.Konzeption

Obwohl die Entwicklungsschritte bei der Konzeption von Produkten und Services (Identifi kation – Spezifi kation – Umsetzung) prinzipiell gleich sind, unterschieden sich diese in ihrer spezifi schen Ausprägung und Schwerpunktsetzung für die „Produkte“ Blutzuckermessgerät, Diabetestagebuch und Printmaterialien.

2.2.1.Omnitest 3D

Grundlagen des Nutzungskonzepts und der Funktionsspezifi kation waren neben den Anforderungen und Use Cases vor allem die bidirektionale Interaktionsbe-schreibung als Ergänzung der Flowcharts. Hierbei wurden sowohl Einzelschritte

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

Fehlertoleranz bzw. Datensicherheit bei Kommunikationsfehlern.

Lesson Learned

Die ergänzende Konzeption der Interak-tions- und Feedbackmuster ermöglicht zu einem frühen Zeitpunkt die Beschreibung des „Look & Feel“ für das fi nale Produkt und somit die eigentliche Benutzerschnitt-stelle. [Abb. 3]


UX Best Practices

Abb. 3. Flowchart Omnitest 3D

141

2.2.2. Omnitest Center

Die Konzeption des digitalen Diabetesta-gebuchs orientierte sich an der erprobten Vorgehensweise bei Entwurf und Ausge-staltung von Websites oder Online-Porta-len. Nach Festlegung der Seitenbereiche und des Systembaums wurden Funktions-bereiche und Einzelfunktionen definiert und in Form eines Anforderungsdoku-ments aus Nutzersicht (C-Requirements) beschrieben. Ergänzt durch die Anfor-derungen aus Entwicklersicht (D-Requi-rements) 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 Grund-lage sowohl der programmiertechnischen Umsetzung wie auch der Zertifizierung als medizintechnische Software durch die entsprechenden Zertifizierungsstellen.

Lesson Learned

Eine schriftliche Anforderungsdokumen-tation 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 Infor-mationstiefe in Abhängigkeit vom Informati-onskontext. 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 Kommuni-kationsformate, die von einem Infoaufkleber über gedruckte Anleitungsdokumente bis zu 1–3 Minuten langen Videos mit Produktschu-lungen reichen können. In einem ersten Schritt wurden drei eigenständige Formate mit individuellem Fokus definiert.

– 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-the-Counter“-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-Experience-Testing nachgewiesen werden konnte.

2.3. UserInterfaceDesign 2.3.1. Omnitest 3D

Primäre Herausforderungen bei der Gestaltung des Blutzuckermessgerät-UIs waren Lesefähigkeit und intuitive Nutzbar-keit. Als Display wurde ein LCD-Segment-display ausgewählt, das eine sehr hohe Abbildungsschärfe mit guter Ablesbarkeit garantiert. Eine Hintergrundbeleuchtung zur Nutzung auch unter schlechten Licht-verhältnissen wurde integriert. Da eine direkte Farbigkeit der Segmente technisch nicht möglich war, wurden zur Hervorhe-bung wichtiger Display-Elemente (z. B. Hinweise, Hauptanzeige) farbige Folien über einzelnen Bereichen integriert.

Beim Display-Layout wurden sowohl nor-mative Vorgaben (z. B. minimale Buchsta-benhöhe), wie auch technische Vorgaben des Hardwareproduzenten (z. B. Führung der Leiterbahnen) berücksichtigt. Ein spezielles Augenmerk lag auf der Anforde-rung, 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 Anleitun-gen) sowie in zukünftigen Produktentwick-lungen (siehe 2.6 Ausblick: Omnitest 5) verwendet werden können. So wurde eine geräteübergreifende und nachhaltige Nut-zung dieser Design-Elemente ermöglicht.

Lesson Learned

Die Verwendung von eindeutigen Begriff-lichkeiten (z. B. zur nutzbaren Displayfläche) in der Kommunikation zwischen Auftrag-geber, Hardwarehersteller und Gestalter, z. B. in Form eines Glossars als Anhang zum Spezifikationsdokument, verhindert evtl. Mehraufwand durch zusätzliche Iterationen und Anpassungen. [Abb. 4]


Zielsetzung bei der Gestaltung des digitalen Diabetestagebuchs war, eine zielgruppen-gerechte „State-of-the-Art“-Anwendung im Consumer-Bereich zu gestalten. Dies be -deu tete einen Paradigmenwechsel in der UI-Gestaltung, da der Auftraggeber bislang nur digitale Anwendungen im Business-to-Business bzw. Business-to-Employee-Bereich umgesetzt hatte. Das Diabetesta-gebuch 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 nutzerorien-tierten Darstellung der beiden relevantes-ten Use Cases „Eingabe von Werten“ und „Visualisierung der Werte als Tagebuch“, wobei auch hier die Herausforderungen

142

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 Visualisie-rung von medizinischen Werten eines frei defi nierbaren Zeitraums als Grafi k (Kurve), Tabelle (Listenansicht), Standardtag (Darstellung aller Messwerte eines ausge-wählten Zeitraums in einem 24-Stunden-Diagramm) oder statistische Auswertung.

Lesson Learned

Durch klare Defi nitionen und Beachtung eines bestehenden Designguides konzent-riert sich das UI-Design auf die Umsetzung dieser Vorgaben und Iterationen beschrän-ken sich auf funktionale Aspekte. [Abb. 5]

2.3.4.Produktverpackung und Printmaterialien

Entsprechend dem Kommunikationskon-zept wurden drei eigenständige Formate zur Nutzerkommunikation entwickelt und design technisch umgesetzt. Als Größenmas-ter diente die Produktverpackung, die alle Elemente der Hardware (Blutzuckermess-gerät, Zubehör, Printmaterialien) enthält.

In den Anleitungsdokumenten wurde schwerpunktmäßig die Navigation inner-halb der Dokumente durch deutlichere Kennzeichnung der Kapitel bzw. der Einzelschritte optimiert. Generell wurden die visuellen Kommunikationsanteile durch den vermehrten Einsatz von Abbildungen und Grafi ken in einer verbesserten Darstel-lungsqualitä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


UX Best Practices

Abb. 4. User Interface Omnitest 3D

Abb. 5. Omnitest Center – Grafi sche Auswertung

143

(Schriftgrößen) und typografische Gestaltung (Weißraum und Textmengen) zu optimieren.

– Produktverpackung: Re-Design im Zuge der angepassten Marketing stra-tegie mit Fokus auf B2C bei unver-änderten Dimensionen der Verpackung und unter Berücksichtigung der Vorgaben des Corporate Designs.

Lesson Learned

Durch die einheitliche Verwendung einer neuen Bildsprache und der neu gestal-teten Icons entsteht ein harmonisches „Gesamtensemble“, welches die strate-gische Fokussierung auf den Consumer-Bereich maßgeblich unterstützt. [Abb. 6]

2.4. Spezifikation und Programmierung/Umsetzung 2.4.1. Omnitest 3D

In Absprache mit dem Hardwareproduzen-ten wurde zuerst das Austauschformat für die Spezifikationen in Form von Flowcharts mit eingebetteten UI-Screendesigns entwi-ckelt. Dies ermöglichte den schnellen und agilen Austausch unter weitestgehendem Verzicht auf eine schriftliche Dokumentation. Auf Grundlage von Konzeption und UI-Design wurden anschließend die grafischen Flowcharts konzipiert und dokumentiert.

Lesson Learned

Die Entwicklung eines individuellen Aus-tauschformats beschleunigt und verein-facht die Projektkommunikation, da im internationalen Kontext Sprachbarrieren minimiert werden und eine eigene „Pro-jektsprache“ verwendet wird.


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 dien-ten die erstellten C-Requirements und Designspezifikationen in Form maßhalti-ger UI-Screens. In engen Abstimmungen konnten häufige, kurze Iterationsschleifen mit kurzen Antwortzeiten realisiert werden. Dies ermöglichte es, funktionale und tech-nische 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 Detai-lanpassungen vorzunehmen.

Lesson Learned

Die frühzeitige Überprüfung von Einzel-komponenten erlaubt die Identifikation und Anpassung spezifischer Problemstellungen, z. B. von Darstellungsabweichungen auf unterschiedlichen Browsern und Betriebs-systemen oder langen Laufweiten spezifi-scher Sprachversionen (z. B. Französisch).

2.4.3. Modellbau Produktverpackung und Printmaterialien

Sowohl für das User-Experience-Testing wie auch zur internen Projektkommunika-tion (z. B. in Richtung Marketing & Sales, Management und Vorstand) wurden eine Reihe von Modellen der vollständigen Hardwarekomponenten (Blutzuckermess-gerä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

„First Look & Feel“ sind bei internen Pro-duktprä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. UserExperienceTesting von Omnitest 3D, Omnitest Center, Produktverpackung 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 ana-logen/digitalen Diabetestagebüchern) und entsprechende Personen aus dem Tester-Netzwerk von chilli mind, sowie über den Außendienst des Auftraggebers akquiriert.

Vorab wurden in Abstimmung mit dem Auftraggeber Testkriterien, der

Abb. 6. Anleitungsdokumente (Kurzanleitung, Benut-zerhandbuch)

144


UX Best Practices

Bewertungsmaßstab sowie ein Interview-leitfaden ausgearbeitet.

Die eigentliche Durchführung des Testings erfolgte als aufgabenbezogenes Leitfaden-Interview mit „empathisch-teilnehmender Beobachtung“ in Think-Aloud-Methodik mit ergänzendem Videoprotokoll.

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 Pro-zesse, unverständliche Darstellungen und generelle „Stolpersteine“ wurden anschlie-ßend in der Auswertung identifiziert, doku-mentiert, in Absprache mit den Projektbetei-ligten priorisiert und an den entsprechenden Stellen in die Anpassungs- und Überarbei-tungsprozesse der einzelnen Komponenten als Change Requests integriert.

Lesson Learned

Durch den vorab klar definierten Fragenkata-log und entsprechende Bewertungskriterien wird die Identifikation, Priorisierung und Implementierung relevanter Optimierungs-ansä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 Premiummo-dell Omnitest 3D als Low-Budget-Modell einen verringerten Funktionsumfang haben.

Der Entwicklungsprozess dieser Modell-reihe profitierte hierbei von der struktu-rierten Dokumentation der Schritte und Ergebnisse im aktuellen Entwurfsprojekt, so dass viele Elemente direkt bzw. ange-passt in die Entwicklung übernommen werden konnten. Dies betraf u. a. grafische

Elemente wie z. B. Display-Layout, Icons und Ziffern der Displayanzeige.

Die Anforderungsprofile und Personas unterschieden sich nur geringfügig, wodurch Use Cases unverändert oder mit geringen Anpassungen übernommen werden konnten. Abweichende, spezifi-sche Nutzungsfälle konnten auf Basis des abgestimmten Austauschformats und der aktuellen Dokumente schnell und pass-genau mit dem Produzenten des neuen Blutzuckermessgeräts abgestimmt werden.

Bei der neu zu entwickelnden Gerätegenera-tion 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ög-licht 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- Experience-Gesichtspunkten und auf Grund der pro to-typischen Vorgehensweise ein exzellentes Beispiel für einen standardisierten Ent-wicklungsprozess dar, der sowohl Usa-bility-Gesichtspunkte, nutzerspezifische Anforderungen sowie technische und norma tive Restriktionen in den Fokus stellt. So konnten im Projektverlauf durch die frühzeitige Einbeziehung aller Stakeholder (Auftraggeber, Nutzer, Provider, Hersteller von Hard- und Software …) auch wider-streitende oder widersprüchliche Anforde-rungen berücksichtigt werden.

Der von chilli mind implementierte, integrative Ansatz ermöglichte innerhalb eines eng definierten Projektrahmens

die verzahnte Entwicklung aller analogen und digitalen Elemente eines komple-xen Gesamtsystems mit einem qualitativ hochwertigen Endergebnis unter Berück-sichtigung 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 fol-gende Einzelerkenntnisse erzielt werden: – Durch den integrativen User-Experience-

Ansatz und die frühzeitige Einbeziehung von Nutzern (Anwender, Betroffene) konnte die hohe Kunden freundlichkeit aller Elemente im Gesamt system von den Prozessen bis zur gestalterischen Umsetzung gewährleistet werden.

– Der Projektverlauf erlaubte vor allem auf Grund des User-Experience-Testings die Bestätigung der digitalen und analogen Entwurfsansätze durch die positiven Ergebnisse bei Merk- und Lesefähigkeit, sowie Perzeptionszeiten der Bedien-oberflächen und Anleitungen.

– Die visuell unterstützte Kommunikation, bereits zu einem frühen Stadium des Entwurfsprozesses verkürzt Entwurfs-zeiten durch Reduzierung der Iter-ationen und Anpassungsaufwände.

– Ergebnisse der einzelnen Teilprojekte, Testings und Sicht-/Funktionsprüfungen konnten frühzeitig als Anforderungen, Optimierungsansätze bzw. Change Requests in die iterative Umsetzung und Optimierung der Hard- und Soft-ware-Elemente übernommen werden.

– Im Rahmen der agilen Projektierung wurden verschiedene Modellbau- und Interaktionsformen von „Quick and Dirty“ bis „Hochglanz“ kontext spe-zifisch zur Evaluation und Präsen tation verwendet und mit Erfolg erprobt.

Die Harmonisierung und konsequente Dokumentation der Entwurfselemente, z. B. als Flowchart, Softwarespezifikation oder Designguide, garantiert die nachhal-tige Verwendbarkeit aller Ergebnisse auch bei zukünftigen Produktentwicklungen.

145

Keywords: /// Travel Experience/// User Experience/// bedürfnisorientierter

Gestaltungsprozess

wurde die Annahme getroffen, dass Infor-mationsprobleme der Passagiere bereits gelöst sind. Zur Gestaltung für positive Erlebnisse wurden zwei User-Experience-Ansätze verfolgt. Zum einen wurde die User-Experience-Definition von Hassen-zahl (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 Technologieer-lebnisse 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 „possibility-driven design“ bezeichnet wird.

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 Informations-defizite 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 vorlie-genden Designstudie um die Gestaltung von explizit positiven Erlebnissen in der Transportphase des Reisens gehen. Somit

Im Folgenden werden zunächst verwandte Ansätze zur Schaffung positiver Reiserleb-nisse vorgestellt. Anschließend wird ein Gestaltungsprozess für die vorliegende Designstudie definiert und beschrieben. Dem folgend wurden 13 Konzepte zur Förderung positiver Reiseerlebnisse ent-wickelt, von denen drei näher vorgestellt werden. Zum Abschluss wird der Gestal-tungsprozess 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 öffent-lich auszustellen und die von anderen

Travel ExperienceErlebniszentrierte Gestaltung neuer Medien für Reisende

Michael BurmesterHochschule der Medien, Wolframstr. 3270191 [email protected]

Ralph TilleHochschule der Medien, Wolframstr. 3270191 [email protected]

AbstractIm 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 Transportpha-se 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 Gestaltungspro-zess 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 wur-den. Beispielsweise ergaben die Befragungen, dass spontane Gespräche unter Passagie-ren sehr positiv erlebt werden. Somit wurde ein Konzept entwickelt, in dem Passagiere in Wartesituationen unaufdringlich miteinander ins Gespräch gebracht werden sollen.

146


UX Best Practices

Passagieren anzuschauen. Desmet und Hassenzahl (2012) berichten vom Konzept „Daydream“, welches das Tagträumen aufgreift, das sich bei Zugreisenden ein-stellt, wenn sie während der Fahrt auf am Wagonfenster vorbeiziehende Landschaf-ten schauen und ihren Eindrücken und Assoziationen nachhängen. Ein Kissen mit einer technischen Ausstattung erkennt die Position des Zuges und ergänzt den „Tag-traum“ durch Geräusche, die zu den Eigen-schaften 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 infotain mentartigen Ge -staltungen an Bahnhöfen, sich wartende Zugreisende in Abhängig keit von der Passagierdichte und der Reisemotivation möglichst positiv fühlen.

Mittlerweile gibt es aber auch real exis-tierende Dienstleistungen jenseits der Catering-, Shopping oder Wellness-Mög-lichkeiten an Flughäfen oder auf Zugreisen. Die Bundesbahn Nordrhein-Westfalen hat das Webportal „Momente“ (2013) einge-richtet über das fl üchtige Bekanntschaften in Zügen wieder kontaktiert und weiter gepfl egt werden können. Mit dem Service „MeetAtTheAirport“ (2011) können Treffen mit unterschiedlicher Ausrichtung von gemeinsamen Kaffee, Networking, Reise-begleitung oder sogar romantische Bezie-hungsanbahnung 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 Netz-werke bereits vor dem Flug kennenlernen, um dann während des Fluges bereits gute Voraussetzungen für angenehme Unterhal-tungen zu haben.

3.Defi nition eines erlebnisorientierten Gestaltungsprozesses3.1.Der Prozess im Überblick

Um positive Erlebnisse für Passagiere durch Gestaltung interaktiver Systeme für die Transportphase bei Flugreisen zu ermög-lichen, wurde in Anlehnung an Hassenzahl (2010), Desmet und Hassenzahl (2012) sowie Wright und McCarthy (2010) ein erlebnisori-entierter Gestaltungsprozess beschrieben, der auch Komponenten des szenariobasier-ten Gestaltungsansatzes von Rosson und Carroll (2002) enthält. Abbildung 1 zeigt den Prozess. Innerhalb dieser Designstudie verlief der Prozess linear. Bei der Entwick-lung 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]

In den folgenden Kapiteln wird genauer auf die einzelnen Aktivitäten des Gestal-tungsprozesses eingegangen.

3.2.Defi nition der Passagiertypen

Im Projekt IC-IC wurde eine Klassifi kation von 16 Passagiertypen entwickelt. Diese Typologie wurde anhand folgender Krite-rien erstellt: Spektrum unterschiedlicher Reiseanlässe (Urlaubsreise, Geschäfts-reise, etc.), Anzahl von Reisenden (allein, Kleingruppe, Reisegruppe), Reiseerfahrung (gering, hoch), Entfernung des Zielortes (Inland, kontinental, interkontinental), Art des Gepäcks (Handgepäck, Koffer, Kinder-wagen, etc.) und schließlich Art der Anreise (Öffentlicher Nahverkehr, Taxi, eigener PKW

etc.). Aus den 16 Passagiertypen des IC-IC-Projektes wurden für diese Studie 13 aus-gewählt für die dann Konzepte entwickelt wurden (z.B. älteres Ehepaar auf Urlaubs-reise oder Reise von drei Geschäftsleuten).

3.3.Sammlung positiver Erlebnisse in der Transportphase von Flugreisen

Zur Identifi kation von positiven Erlebnissen in der Transportphase des Reisens wurden 10 Tiefeninterviews (Laukenmann, 2012) durchgeführt und ausgewertet. Die Unter-suchungsteilnehmer wurden nach Kriterien Reiseanlass, Reiseerfahrung und Entfernung des Zielortes ausgewählt (6 Personen weib-lich und 4 männlich, Altersdurchschnitt 45,3 Jahre, 5 geben eine Flugreisehäufi gkeit 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 emotio-nale Erlebnisse während einer konkreten erinnerten Reise identifi ziert wurden. Jedes Erlebnis wurde dann nach folgendem Befra-gungsschema beschrieben und analysiert:1. Klärung der Situation (Reiseabschnitt,

Umgebungssituation, involvierte Per-sonen, involvierte, Artefakte, emotions-auslösende Faktoren)

2. Persönliche Bedeutung der Situations-eigenschaften und zugrundeliegendes Bedürfnisse durch Laddering (Reynolds & Gutman, 1988)

Zudem wurde eine Tagebuchstudie (Käfer, 2012) über eine komplette Fernfl ugreise (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, Altersdurch-schnitt 45,3 Jahre, eine Person fl og 2x pro Jahr, die anderen 4–8x). Die Instruktion for-derte, positive und negative Erlebnisse mit

3. Integrierte Erlebnis-

geschichten geschichten

1. Definiton der Passagiertypen

4. Entwicklung von

Erlebnisideen

5. Gestaltung der Erlebnis-

dynamik dynamik

7. Szenario- oder Video-

Prototyp Prototyp

2. Positive Erlebnisse sammeln

Abb. 1. Erlebnisorientierter Gestaltungsprozess zum Entwurf für positive Travel Experience in der Transportphase des Reisens

147

Hilfe einer Notizsoftware (Evernote, 2013) auf dem Smartphone zu protokollieren und ggf. zu fotografi eren. 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 nega-tiv) und im Rahmen der Tagebuchstudie 216 Erlebnisse (101 positiv und 115 negativ) identifi ziert. Es wurden nur die positiven Erlebnisse verwendet, da negative Erleb-nisse 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 Zielfl ughafen und Ziel-ort): Unterschiede in Handlungsab -läufen (z.B. angenehm „chaotische“ Abläufe am Flughafen), interkultu relle Unterschiede (z.B. Begrüßungsver-halten) sowie andere Umgebungs eigen-schaften (z.B. Flughafengröße) oder Erlebnisse mit sonst nicht genutzten Einrichtungen (z.B. Fahren auf Laufbän-dern, die eine ruhige und neue Perspek-tive auf die vorbei-ziehen de Umgebung ermöglichten) er zeugten Neugier, ermöglichten Perspektivwechsel und lösten Refl exionen 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.

– 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 Anschlussfl ug gefunden) wur-den 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 Startfl ughafen 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 Mit-reisenden. 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, Umge-bung, anwesende Personen), der emo-tionalen Entwicklung sowie den zugrun-deliegenden Bedürfnissen bestehen. Aus Sicht des Gestalters können auch einzelne Erlebnisaspekte hohes positives Erlebnis-potenzial haben (z.B. Erlebnis auf den Lauf-bändern am Flughafen) und Ausgangs-punkt für eine Erlebnisgeschichte sein.

3.5.Erlebnisideen

Aus den Geschichten derzeitiger Erleb-nisse konnten Konzepte für interaktive Technologien entwickelt werden, welche die derzeitigen positiven Erlebnisse in neuer Form aufgreifen „re-scripting“ oder diese erweitern „enhancing“ (vgl. Hassen-zahl, 2010; Desmet und Hassenzahl, 2012).

Neben den Geschichten derzeitiger Erleb-nisse 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 Reisesitu-ationen positive Gefühle zu erzeugen (vgl. Konzept „Snack-O-Mat“). Wie neue tech-nische 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

Abb. 6. Abbildung 2: Ausschnitt aus dem Storyboard des Konzeptes Travel Tracker (mit Genehmi-gung von Katharina Cla-sen, Timo Gabel, David Galowy, Timo Göbel und Dürgül Gümüs)

148

betrachtet werden (Karapanos et al., 2009) oder die Erlebnisdynamik, die sich während der aktuellen Nutzung in spezifischen Situationen entfaltet. Diese Erlebnisdy-namik beschreibt Gestaltungseigenschaf-ten, 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“ Ver-bundenheit, erzeugt aber zunächst einmal durch verschiedene gestalterische Maßnah-men Neugier. Die Erlebnisdynamik wurde als Szenario mit Hilfe von Storyboard-Dar-stellungen beschrieben. [Abb. 2]

3.7. Umsetzung in einen Szenario oder VideoPrototypen

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 (Interakti-onen und visuelle Darstellungen werden in animierter Form entlang des Erlebnissze-narios audio-visuell präsentiert).

4. Ausgewählte Konzepte zur Förderung≈positiver Erlebnisse während der Transportphase des Reisens 4.1. Konzepte

Es wurden insgesamt 13 Konzepte für tech-no logiebasierte Erlebnisse während der Transportphase des Reisens entworfen. Zwei Konzepte machen den Flughafen selbst zum Gegenstand. So werden bei einem der beiden Konzepte beispielsweise die faszinierenden Aspekte des Fliegens und der damit verbundenen Technik durch ein Augmented-Reality-Spiel für Tablets oder Smartphones näher gebracht. Weitere drei Konzepte beschäftigen sich mit der Vor-freude auf die Reise. Hier wird mit Aspekten

der Zielorte gespielt (vgl. Konzept „Erlebnis-säule“). Zwei Konzepte haben Überraschun-gen zum Gegenstand, von denen eines als App „Geheimtipps“ zu erlebnisreichen Orten der Zielregion von Passagier zu Passa-gier weitergibt. Das Fliegen selbst wird zum Gegenstand von weiteren drei Konzepten. Bei einem Konzept bilden Passagiere in der Kabine eine Spielergruppe, um ein Rate-spiel gegen die eines anderen Flugzeuges zu spielen. Schließlich beschäftigen sich drei Konzepte mit dem Kontakt zu den Passa-gieren 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 erleb-bar 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 typi-sche 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 ausge-tauscht werden. Durch die Rückmeldungen soll das Gruppenerlebnis und die Iden-titä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 Informati-onen 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), Kompe-tenz (durch die Rückmeldung gemeinsam bewältigter Aufgaben: „wir waren gemein-sam in 6 Meetings auf unserer Reise und


UX Best Practices

Abb. 3. Konzept Erlebnissäule (mit Genehmigung von Fabian Schöttle, Joschka Silzle, Eugenia Woltschek und Andreas Wünsch)

149

haben insgesamt 10 Stunden verhandelt“) und Verbundenheit (wir haben viel Zeit zusammen verbracht) adressiert. [Abb. 4]

4.4. Das Konzept SnackOMat

Als eine spezielle Technologie für Warte-zonen an Flughäfen wurde von Hannah Lindemann, Annika Metzger, Kathrin Pod-lesny und Julia Roming der Snack-O-Mat entworfen. Inspiriert wurde diese Erleb-nisidee durch Erhebungsergebnisse über positive Erlebnisse durch zufällig zustande kommende Gespräche mit Mitreisenden. Diese sozialen und positiven Erlebnisse sol-len befördert werden durch einen Automat, der in Wartezonen im Flughafen (z.B. am Gate) aufgestellt wird, und kleine kostenlose Snacks den wartenden Passagieren anbie-tet. Gutes Essen gehört zu den mensch-lichen 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 Auto-maten 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 Auto-maten versammelten Passagiere werden mit einer Personenerkennung identifiziert (z.B. MS Kinect, 2013) und ebenfalls als Schatten-riss abgebildet. Bis der Snack ausgeworfen wird, besteht eine Wartezeit und der Schat-tenriss des Snacks wird langsam deutlicher. Intention der Designer war es, dass die vor dem Automaten wartenden Passagiere nun beginnen, sich über den Snack austauschen,

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 Perso-nen 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 Passagie-ren 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üt-zung 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 Erwei-terungen 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 beispiels-weise 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 Ent-wurf 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 Werkzeug-gestaltung 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.

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




interaktiver Systeme. Berlin Beuth.

5. Hassenzahl, M. (2008). User Experience

(UX): Towards an experiential perspective

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: Anga-ben zur Gruppenzeit. Rechts: gemeinsam besuchte Orte

150

on product quality. In IHM '08: Proceedings

of the 20th French-speaking conference on

Human-computer interaction (Conférence

Francophone sur l'Interaction Homme-

Machine) (pp. 11–15).

6. Hassenzahl, M. (2010). Experience Design

– Technology for All the Right Reasons. San

Rafael, CA, USA: Morgan Claypool.

7. Hassenzahl, M., Diefenbach, S., Eckoldt,

K., Heidecker, S., Hillmann, U. & Laschke,

M. (2010). Technologie, die verbindet?

Die bedürfniszentrierte Gestaltung von

Kommunikationstechnologien für Liebende

(und andere die sich mögen). In: H. Brau,

S. Diefenbach, K. Göring, M. Peissner & K.

Petrovic (Hrsg.), Usability Professionals 2010

(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,

2012. Eindhoven: University of Eindhoven.

(Zugriff am 16.03.2013 unter http://alexandria.

tue.nl/extra2/redes/hummels2012.pdf)

10. Jordan, P. (2000). Designing Pleasurable

Products. London: Taylor & Francis.

11. Käfer, J. (2012). Tagebuchstudie zur Ana lyse

des Nutzungskontextes für ein Informations-

system zur Verbesserung der Übergänge

zwischen Nah- und Fernverkehrsmitteln.

Unveröffentlichte Abschlussarbeit. Stuttgart

Hochschule der Medien.

12. Karapanos, E., Zimmerman, J., Forlizzi, J. &

Martens, J. B. (2009). User Experience Over

Time: An Initial Framework. In: Proc. of CHI

2009, April 4–9, 2009, Boston, Massachusetts,

USA (pp. 729–738). New York: ACM.13. Laukenmann, B. (2012). Qualitative Interviews

zum vertiefenden Verständnis der situativen

Bedingungen und psychologischen Faktoren

positiver Erlebnisse während der Transport-

phase des Reisens. Unveröffentlichte Ab schluss -

arbeit. Stuttgart Hochschule der Medien.

14. MeetAtTheAirport“(2011). Web-Service.

Zugriff am 29.06.2013 unter http://

meetattheairport.com

15. Momente (2013). Web-Portal der Deutsche

Bahn AG. Zugriff am 29.06.2013 unter http://

www.bahn.de/regional/view/regionen/nrw/

freizeit/momente-nrw.shtml

16. MS Kinect (2013). Microsoft X-Box Kinect.

Zugriff am 17.03.2013 unter http://www.

xbox.com/de-DE/Kinect/

17. Reynolds, T. J. & Gutman, J. (1988).

Laddering Theory, Method, Analysis, and

Interpretation. In: Journal of Advertising

Research, 28, S. 11–31.

18. Rosson, M.B. & Carroll (2002). J.M. Usability

Engineering – Scenario-based development

of human-computer interaction. San

Francisco: Morgan Kaufmann.

19. SeatID (2013). Social Seating & Booking.

Web Service. Zugriff am 29.06.2013 unter

http://www.seatid.com

20. Sproll, S., Peissner, M., Sturm, C. &

Burmester, M. (2010). UX Concept Testing:

Integration von User Experience in frühen

Phasen der Produktentwicklung. In: H. Brau,

S. Diefenbach, K. Göring, M. Peissner & K.

Petrovic (Hrsg.), Usability Professionals 2010

(S. 195–200). Stuttgart: Fraunhofer.

21. van Hagen, M. (2011). Waiting experience at

train stations. Delft: Eburon.

22. Wright, P. & McCarthy, J. (2010). Experience-

Centred Design .- Designers, Users, and

Communities in Dialogue. San Rafael, CA,

USA: Morgan Claypool.

Danksagung

Ein besonderer Dank gilt dem Engagement

aller Informationsdesignstudierenden,

die im User Experience Seminar des

Sommersemesters 2012 beteiligt waren:

Stefan Kurt Baumann, Ray Earl Biermann,

Jacqueline Melissa Maria Bopp, Sarah

Brendecke, Pirmin Matthias Buchenberg,

Nadezda Chesnok, Katharina Helga Maria

Clasen, Derya Doganc, Saskia Nadine

Eberhardt, Sandra Maria Fohr, Lydia Friedrich,

Katharina Michaela Fundaminski, Timo Gabel,

David Martin Galowy, Corina Chanchira

Gehring, Timo Johannes Göbel, Dürgül

Gümüs, Verena Hassler, Lars Herrmann, Helvi

Oda Hertner, Birgit Laura Hettler, Melissa

Kammerer, Nadine Kärcher, Franziska Kaus,

Anne Alexa Karoline Koch, Julia Kolski,

Tatiana Kupreeva, Hannah Lindemann,

Annika Metzger, Andrea Müller, Joel Morris

Müseler, Kathrin Podlesny, Pamela Sue

Reiche, Jonathan Markus Renz, Julia Roming,

André Roth, Fabian Schöttle, Joschka Silzle,

Alexander Elmar Springer, Carola Rebekka

Tischer, Alexander Marius Walther, Eugenia

Woltschek, Andreas Wünsch, Lisa Würstle und

Anna Zolotareva.


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.

151

Keywords: /// Hilfe/// Onboarding/// Usability/// Augmented Reality

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 Interakti-onsformen 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

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 Pro-dukt. Dementsprechend ist das Ziel jeder Software die effektive, effiziente und zufrie-denstellende 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 trotz-dem leicht zugänglich bleiben. Um diesen Mittelweg zu finden, muss der Kontext, in dem die Hilfe eingesetzt werden soll, analy-siert und die nötige Tiefe und Komplexität bestimmt werden. Mit dieser Grundlage kann eine optimierte Hilfefunktion eben-falls zur Produktivitätssteigerung beitragen und Vertrauen zum System aufbauen.

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ückge-griffen 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 Eingabehil-fen (siehe Abschnitt 3.5) ausreichend sein, wohingegen komplexere Aufgaben wie die Wartung einer Maschine häufig mehr Füh-rung und Unterstützung erfordern und somit eher mit Hilfe eines Assistenten bzw. Wizards (siehe Abschnitt 4.2) durchgeführt werden.

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

Natalie OsterErgosign GmbHEuropaallee 1266113 Saarbrü[email protected]

Jan GroenefeldErgosign GmbHEuropaallee 1266113 Saarbrü[email protected]

Markus KühnerErgosign GmbHEuropaallee 1266113 Saarbrü[email protected]

AbstractIntuitive Bedienung ist eines der Kernthemen in der User Experience. Schließlich sollen Benutzer das System bzw. Produkt ohne explizite Hilfe bedienen können. Nichtsdesto-trotz 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 Unter-stü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, einge-führt, teilweise auch mit der Intention, auf die klassische Hilfe zu verzichten. Der Beitrag beleuchtet unterschiedliche Hilfe-Konzepte, die in unterschiedlichen Kon-texten 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.

152


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-Kon-zepte 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.

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 wie-der, 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 Hilfestel-lungen wie Eingabehilfen oder die Spot-light-Suche den Benutzer unterstützen.

3.1. Start Screens

Start Screens sind einzelne Seiten, die die Bereiche, Funktionen oder Bedienung einer

Anwendung auf einen Blick erklären sollen. Sie werden häufig im Mobile-Kontext ver-wendet, um die Gestensteuerung der jewei-ligen App zu erklären [Abb. 1] und nach erstmaligem Starten der App gezeigt.

Das Augenmerk bei Start Screens sollte auf der Menge der Inhalte liegen, da sie leicht überladen wirken können. [Abb. 2] Man sollte sich somit bei der Gestaltung für eine Thematik, die man erklären möch te, entscheiden oder stattdessen beispielsweise das Onboarding-Konzept (siehe Abschnitt 3.4) wählen und Informati-onen 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 Beschaf-fenheit der Funktion hervorgehoben.

Sie bieten dem Benutzer somit eine Start-hilfe und verringern die anfängliche Hürde bei der Erstbedienung. Ein verwandtes und weiterführendes Konzept sind Coach Marks (siehe Abschnitt 3.3).

Abb. 1. Start Screen der YBoard iPad App [1]

Abb. 2. Überladener Start Screen der Project Magazine iPad App [2]

153

Abbildung 3 und 4 zeigen Beispiele für den Platzhalterinhalt. Die visuelle Gestal-tung gibt einen Hinweis auf die Standard-Funktion, die der Benutzer auswählen kann, um seine Aufgabe zu beginnen. [Abb. 3]

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 Expe-rience kann auch häufi g 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äufi ger 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.

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 über-lagern 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 Ein-satz von Coach Marks nach dem Start der YouTube Capture iPhone App zur Erklä-rung der Funktionen. [Abb. 5]

3.4.Onboarding

Onboarding ist ein beliebtes Konzept für die Vorstellung einer Applikation oder

Abb. 4. Placeholder Content und Action Hints Beispiele (Runkeeper / Wunderlist / Google Maps iPhone Apps)

Abb. 5. Coach Mark-Beispiele

Abb. 3. Projektbeispiel SMS Siemag (Ergosign)

154

neuer Features. Dabei werden mehrere Screens mit jeweils einem I nhalt hinterein-ander geschaltet und ermöglichen es dem Benutzer somit, die Applikation Schritt für Schritt kennen zu lernen. Speziell für w eni-ger technikaffi ne Nutzer ist dies ein leichter Weg, um sich mit einem Programm ausei-nanderzusetzen, wohingegen erfahrenere Benutzer solche vorgeschalteten Screens häufi g als lästig und überfl üssig empfi nden.

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 Abbruch- bzw. Auslassmöglichkeit anzubieten.

In Abbildung 6 werden verschiedene Aus-führungen und Einsatzmöglichkeiten des Onboarding-Konzepts vorgestellt. Die You-Tube Capture iPhone App verwendet das Konzept gleichzeitig zur Vorstellung und Schnellkonfi guration der App, wohinge-gen Wunderlist beispielsweise gleich mit zwei unterschiedlichen Umsetzungen des Konzepts arbeitet. In der ersten wird auf die wichtigsten Inhalte der App eingegan-gen, die zweite soll neue Features in den Vordergrund stellen. [Abb. 6]

3.5.Permanente/Dynamische Eingabehilfe

Neben den vorgelagerten oder überla-gernden 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ön-nen zum Einen permanente oder dynami-sche Hinweistexte zu bestimmten Restrikti-onen sein [Abb. 7] oder zum Anderen auch spezielle Eingabe-Controls, wie beispiels-weise 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

Dateien des Benutzers zu fi nden.“ [3] Dafür kann der Benutzer einen Suchbegriff in ein speziel les Suchfeld eingeben und erhält bereits während der Eingabe eine kategori-sierte Ergebnisliste. Seit Mac OS X Leopard wurde eine weitere Funktionalität in das Hil femenü jedes Programms integriert, mit der es möglich ist, das Programmmenü zu

durchsuchen. Die Ergebnisliste enthält zum einen Verweise zu entsprechenden Hilfeka-piteln und zum anderen passende Menüob-jekte, die bei Mouse-Over im geöffneten Menü hervorgehoben werden. [Abb. 8]

Vor allem bei sehr komplexen und umfangreichen Applikationen ist diese


UX Best Practices

Abb. 7. Beispiel für permanente und dynamische Eingabe-hilfe (Ergosign)

Abb. 6. Onboarding-Beispiele der YouTube Capture und Wun-derlist iPhone Apps

155

Art von Suche eine große Unterstützung für Benutzer, um selten genutzte Berei-che oder Funktionen schnell zu fi nden. Gleichzeitig schult die Verwendung der Suchfunktion das Wissen des Benutzers über die Software.

4.Weiterführende Hilfe-Konzepte

In spezialisierten und komplexen Anwen-dungen, wie beispielsweise ERP- oder Leitstand-Anwendungen, wird häufi g auf stärker ausgearbeitete Hilfe-Konzepte

zurückgegriffen, um die Benutzer zu führen und die Masse an Informationen und Funk-tionen zu erfassen. Aber auch in diesem Bereich gibt es verschiedene Ausprägungen der Hilfestellung, die abhängig vom Kontext eingesetzt werden können. Die Unter-schiede 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 ein-schränken, sondern in erster Linie Hilfestel-lungen bieten.

4,1.Application Walkthrough / Guided Tour

Der Application Walkthrough bzw. die Gui-ded Tour ist, wie der Name es schon sagt, eine durch das System unterstützte Füh-rung durch die Software und ist in gewisser Weise eine erweiterte F orm des Onboar-dings (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 Sys-temeinführung auch aufgabenspezifi sche 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 Schritt-fü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 aufgabenspezifi sche Tour liefert Abbildung 9. Der Benutzer kann aus einem Set von defi nierten „Story-boards“ wählen und wird in der Durchfüh-rung seiner Aufgabe von dem System unter-stützt, indem schrittweise Anleitungen und Erklärungen angezeigt werden. [Abb. 9]

4.2.Assistent / Wizard

Assistenten und Wizards sind die wohl meistverbreitete Form der Benutzerun-terstü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 aufgabenspezifi -schen Tour (Ergosign)

Abb. 8. Mac OS X Hilfe-Menü-Suche

156

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 Informatio-nen innerhalb des Wizards bereitgestellt werden.

4.3.Freie kontextsensitive Hilfe

Die freie kontextsensitive Hilfe l iefert primär Hinweise zu aktuellen Inhalten oder Aktionen des Ben utzers 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 Offi ce 97 „Karl Klammer“ [4], die bei fast jeder Aktion ungefragt erschien und den Benutzer vor allem in seinem Arbeits-fl uss unterbrach, anstatt zu helfen. Dies war auch der Grund, weswegen Microsoft ab Offi ce 2007 auf das Konzept innerhalb der Software verzichtete.

Generell ist die Verwendung eines solchen Konzepts problematisch, da eine aufwen-dige Implementierung und ein intelligenter Algorithmus für einen sinnvollen Einsatz nötig sind und zusätzlich die Gefahr be -steht, dass der Benutzer sich eher gestört als unterstützt füh lt.

4.4.Feste Hilfebereiche

Die sinnvollere Alternative zur freien kontext-sensitiven 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 befi ndet, zu geben. Durch die fi xe Position wird der Benutzer nicht durch plötzliche UI-Änderungen irritiert und hat stets die Möglichkeit, die Informati-onen bei Bedarf zu Rate zu ziehen.

Ein Nachteil einer solchen Hilfe ist jedoch der hohe Pfl egeaufwand, 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 Arbeitsanwei-sungen zu den einzelnen Eingaben gibt, die durchgeführt werden müssen. Neben beschreibenden Texten werden auch Grafi ken eingesetzt, um die Tätigkeit zu erläutern. [Abb. 10]

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 grafi sch abgebildet und bei Selektion her-vorgehoben, so dass der Benutzer einen direkten Bezug und eine Vorstellung zu den Daten herstellen kann. [Abb. 11]


UX Best Practices

Abb. 11. Beispiel für einen Hilfebereich mit grafi scher Hilfestellung (Ergosign)

Abb. 10. Beispiel für einen festen Hilfebereich mit Arbeitsanweisungen (Ergosign)

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 Hilfe-Anwendungen 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 Fahr zeugs fokussiert und erkannt werden, so dass anschließend Informationen zu dem Ele-ment angezeigt werden. [Abb. 12]

Diese Lösung bietet eine gute Alternative zum eigentlichen und umfangreichen Hand-buch, da der Benutzer direkt zu seinem gesuchten Inhalt geleitet wird, anstatt ein endlos langes Manual durchsuchen und studieren zu müssen.

5.3.Wartungskonzepte

Ein weiterer Anwendungsfall für Augmen-ted Reality ist der Einsatz bei Wartungs-arbeiten, 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 Ver-wendung von Augmented Reality könnte somit für diesen Bereich eine enorme Verbesserung darstellen.

Dieses Ziel verfolgt unter anderem ein Pro-jekt des Instituts für Prozess- und Produk-tionsleittechnik (IPP) der TU Clausthal. Die Beteiligten beschäftigen sich mit der Frage „welche Probleme […] bei der Wartung komplexer Anlagen und Maschinen“ [6] auf-tauchen und wie diese mit Hilfe von Aug-mented Reality reduziert werden können. Hierzu wurde ein Unterstützungssystem ent-wickelt, welches basierend auf der Technik der erweiterten Realität und Zuhilfenahme eines Head Mounted Displays Reparatur-hinweise und Erl äuterungen zu erkannten Maschinenteilen anzeigt [Abb. 13].

Abb. 12. Beispiel für die Fokus-sierung und Informa-tionsanzeige eines Bedienelements im Audi A1 [5]

Abb. 13. Beispiel-Projekt des IPP der TU Clausthal [6]

158


UX Best Practices

Ein weiteres Projekt mit dem Ziel, den Be -nutzer während der Wartung zu unter stützen, wurde im Deutschen Forschungs zentrum für Künstliche Intel-ligenz Kaisers lautern umgesetzt. Dieses beschäftigt sich mit der Unterstützung des

Benutzers beim Austausch der Festplatte eines Laptops [7]. Der Benutzer wird mit Hilfe von Überblendungen Schritt für Schritt angewiesen, wobei das System erkennt, wenn der Schritt durchgeführt wurde und automatisch den nächsten anzeigt.

6. Fazit

Ein Hilfesystem ist für nahezu jedes Produkt unerlässlich und sollte somit als Bestandteil des Gesamtkonzepts und nicht als Zusatz

Tab. 1. Kurzbeschreibung der Hilfe-Konzepte

159

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

dardvorgehen 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 werdeno Einschränkung der Anzahl von Screens beachten (max. 5).– U. U. lästig für technikaffine Nutzer.

Permanente/ Dynami-sche 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 Walkt-hrough / 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 Unterbre-chung 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.

angesehen werden. Das ausgewählte Hilfe-Konzept 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.

Insbesondere die speziellen Hilfesysteme mit der Kombination von Augmented Rea-lity bergen ein hohes Potenzial und könnten einen enormen Fortschritt für den indus-triellen 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]

Literatur1. Conduce Group (2012). V2 of YBoard

for iPad hits the App Store. http://www.

conduce.net/v2-of-YBoard-hits-the-App-

Store/. (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/

id436341817?mt=8. (14. Juni 2013)

6. Institut für Prozess- und

Produktionsleit technik TU Clausthal

(2013). Computer Augmented Reality

für Wartungsunterstützung. http://www.

ipp.tu-clausthal.de/forschung/projekte/

computer-augmented-reality-fuer-

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

Ralph TilleHochschule der MedienWolframstr. 3270191 [email protected]

Michael BurmesterHochschule der MedienWolframstr. 3270191 [email protected]

erste Zielgruppe die technischen Team-leiter in der Entwicklung ausgewählt. Der Schwerpunkt liegt auf Produktplanung, der Produkt- und Prozessentwicklung sowie der Fertigungsvorbereitung. [Abb. 1]

1.Ausgangssituation

Für einen großen Automobilzulieferer sollte ein für verschiedene Rollen und wesentliche Aufgaben maßgeschneidertes Software-Interface – einen „Role-Based Cli-ent“ – entwickelt werden. Die Mitarbeiter nutzen innerhalb der Software-Umgebung im Unternehmen verschiedene Anwendun-gen für spezifi sche Aufgaben innerhalb der technisch-kaufmännischen Entwick-lungsprozesse im Automobilsektor. Das Spektrum der zu entwickelnden Anwen-dung erstreckt sich über den gesamten Produktlebenszyklus: von Akquisition und Pfl ichtenhefterstellung, Konzeptions- und Mustererstellungsphase sowie nachfolgen-den Produkt- und Prozessentwicklungs-phasen bis zur Überführung in Serien-prozesse. Aufgrund umfangreicher und heterogener Aufgabenbereiche wurden als

Die technisch-kaufmännischen Teamleiter verantworten im Unternehmen umfan-greiche Schlüsselfunktionen bis hin zum Kunden. Sie koordinieren Mitarbeiter, Prozesse und Ressourcen im Unternehmen

Interfacekonzept für einen „Role-Based Client“ als Anwendung im gesamten Produktlebenszyklus

Keywords: /// Interfacekonzeption/// Role-Based Interface/// Produktentwicklung/// PLM

AbstractFür einen großen Automobilzulieferer soll das Software-Interface eines „Role-Based Cli-ent“ entwickelt werden. Dies soll maßgeschneidert für die verschiedenen Rollen und we-sentlichen Aufgaben der Mitarbeiter entworfen und umgesetzt werden. Das Hauptziel ei-nes rollenspezifi schen Interfaces besteht darin, dass die Mitarbeiter ziel-, aufgaben- und effi zienzorientierte Funktionsumfänge angeboten bekommen. Die dazugehörige Frage-stellung 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 aufgabenspezifi sches Interfacekonzept zu erstel-len. 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 übergreifen-den 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 konfi gurierbares Interface.

Abb. 1. Produktentstehungsprozess nach Westkämper (2006)

162


Industrie UX

sowie bei Lieferanten und weltweit verteil-ten 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 Office-Softwarepakete, diverse ToDo-Listen für die Teams auf der Basis unterschiedlicher Soft-wareprodukte, spezielle Anwendungen für die Abwicklung von Prüfaufträgen, Applika-tionen für interne und externe Bestellung und Beauftragungen, sowie Anwendungen für das Produktdaten management im SAP-Umfeld und viele weitere spezialisierte Anwendungen. Zudem gibt es Zugänge zu weiteren Anwendungen im Intranet und zu kollaborativen Dateiplattformen. Im Rahmen der Softwareerneuerung des Produktdatenmanagements soll das Role-Based Client-Interface den Zugang zu Soft-ware-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 Produktmanage-ment sind fundamental. Gundelswei-ler&Reiterer (2008) identifizieren typische Usability-Fehler: Navigationsprobleme, Probleme bei Auswahl und Information-ssuche sowie Fehler bei der Darstellung oder Verzögerungen beim Arbeiten mit Anwendungen. Während der Recherche wurden typische Anwendungen mit rollen-basiertem Interface wie bspw. Microsoft Dynamics NAV (2013) im Bereich des Cus-tomer 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 Anwend-ungsfälle die gewünschten Informationen liefern zu können. Problematisch sind daher eingeschränkte oder nicht vorhandene Schnittstellenzugänge sowie inhomogene Datenbasen. Dadurch dass unterschiedli-che Nutzergruppen auf dieselben Daten

zugreifen können, ist eine freie Konfiguri-erbarkeit des Interfaces naheliegend und ermöglicht Flexibilität. Diese Parameter sind jedoch auch Faktoren für die Kom-plexität eines Interfaces und potentielle Fehlerquellen zugleich. Die Fokussierung und Auswahl auf wenige, wichtige Funk-tionen ist notwendig. Das Zusammenlegen von thematischen und aufgabenspe-zifischen 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 Hin-dernis 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 Konfigurier-barkeit findet man nach wie vor bei Mackay (1991). Für Konfigurierbarkeit spricht, dass man in unterschiedlichen Projektphasen arbeitet, bestimmte Abläufe jedoch indiv-iduell abweichen und daher Nutzer selbst Einstellungen vornehmen müssen. Insofern kann Konfi gurierbarkeit zwar hilfreich sein, aber eine Maßanfertigung für den Nutzer verspricht viele Fehlerquellen zu vermei-den. Vorab angepasste Interfaces haben Vorteile, für gleich ablaufende Tätigkeiten. Somit ist ein klares Verständnis der Rollen und Aufgaben der Nutzer notwendig (Find-later et al., 2008), was in der nachfolgend be schrieben Studie beschrieben wird.

3. Ziele, Fragestellungen und Vorgehen

Das Hauptziel dieses Projektes ist die Entwicklung eines rollenspezifischen Interfaces, um administrative Aufgaben im Produktentwicklungsprozess zu erleichtern und zu beschleunigen. Das Interface soll daher ziel-, aufgaben- und effizienzori-entiert sein, d.h. es soll den Nutzern für spezifische Aufgaben die Informationen direkt, schnell und ohne Umwege bereit-stellen. 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.). Ineffizien-zen in Detailinteraktionen (z.B, unnötige Mehrfacheingaben in unterschiedlichen Anwendungen) sollen vermieden werden. Zudem stand fest, dass die bisherigen Software-Anwendungen sehr unterschiedli-che Usability-Qualitäten aufwiesen und teilweise nicht aufeinander abgestimmt waren. Die umfangreichen Tätigkeiten der Primärzielgruppe greifen in viele Unterneh-mensbereiche ein, was für einen Abgleich und die Übertragung der Erkenntnisse auf die Prozessmodelle anderer Nutzergrup-pen spricht. Basis ist ein für das gesamte Unternehmen gültiger, formalisierter Pro-duktentstehungsprozess, der i.d.R. aus den Komponenten Prozesse, Phasen, Meilen-steine, Aufgaben, Methoden und Reife-grade 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 Teilneh-mern deren mentales Modell der Unterneh-mensprozesse 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 Projek-tarbeit und zum Arbeitsplatz stellen zu kön-nen. Daraus lassen sich Funktionsumfang, Probleme, Wünsche und Bedürfnisse der Nutzer feststellen sowie etwaige Abwei-chungen zum formalen Prozessmodell identifizieren. Die anschließende Analyse der erhobenen Daten ergibt ein Anforder-ungsmodell für die Interface-Konzep-tentwicklung und Prototypenerstellung und soll die Fragestellung beantworten, wie ein Role-Based Interface beschaffen sein soll, um die Rolle und deren Aufgaben zu unter-stü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 ent wickelt werden. Am Ende sollen dann Interface- und Interaktionskonzepte entworfen werden. Dieses Vorgehen entspricht dem szenariobasierten Gestaltungsansatz von Rosson&Carroll (2002).

In einem Anschlussprojekt werden die späteren Prototypen bzw. Mock-Ups empirisch mit denselben Nutzern vali-diert (Tille et al., 2013), um das Interface weiter zu detaillieren und ein Gestal-tungskonzept zu erstellen. Die daraus gewonnenen Erkenntnisse fl ieß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 Nutzer-Perspektive

– Sammlung von Hinweisen direkt von den Mitarbeitern

– Verständnisaufbau der Arbeitsabläufe und Arbeitsweisen

– Herstellen der Prozesssicht („was“) und Workfl ow-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 Inter face konzepte zu erstellen. Die vom Unternehmen defi nierte Rolle der Team-leiter lässt sich anhand folgender Auf-gabenschwerpunkte im administrativen und technisch-kaufmännischen Bereich charakterisieren: – Kontrolle von Aufwänden, Projektstand, Termine, Zeitbedarfe

– Steuerung von Anpassungen im tech-nischen Bereich (Produktauslegung etc.)

Abb. 2. Momentaufnahme einer CARD-Session für die Prozess-Sicht.

Abb. 3. Ausschnitt eines visualisierten Prozessmodells der Nutzer

164


Industrie UX

– Überwachung der Kosten (Finanz- controlling)

– 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 Mitarbei-tern gelten sollen. Der gewählte methodi-sche 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 ange-passte Form der CARD-Methode (Tudor et al., 1993, Muller, 1993) eingesetzt. Die Methode hat stark partizipativen Charak-ter, da die Teilnehmer selbst ihre Sicht auf die Prozesse herstellen, bewerten oder verändern. Hier sollten die Teamleiter, die Aktivitäten, Abläufe und Verzweigungs-punkte eines kürzlich bearbeiteten Projek-tes 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) einge-setzt. Hier geht es darum, den Arbeitsplatz, die Arbeitseinfl üsse, die tatsächlichen Bedingungen und Abläufe zu erfassen. Aus diesem Grund wurden weitere 3 Team-leiter 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 Inter-viewer 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 Methodenkombi-nation gab einen genauen Einblick in den Tagesablauf, beispielsweise den häufi gen Wechsel von operativ-administrativer Arbeit

am Arbeitsplatz sowie Besprechungen an anderen Orten. Um die Erkenntnisse der empirischen Studie in ein Interface konzept zu überführen, wurde der zuvor beschrie-bene, nutzerzentrierte Prozess, bestehend aus der Persona- Modellierung nach Cooper (1999, 2004, 2007) sowie der szenario-basierten 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 audio- visuell aufgezeichnet und anschließend transkribiert. Das gesamte Material wurde qualitativ ausgewertet, indem zunächst die Themen in den Äußerungen und Erläuter-ungen identifi ziert und anschließend klass-ifi ziert wurden. [Abb. 3] Zur Beantwortung der Frage nach dem Ablauf von Entwick-lungsprojekten bei den Teamleitern lagen dann visualisierte Prozessmodelle [Abb. 4] des Workfl ows innerhalb kompletter Pro-jekte vor.

Abb. 4. Ausschnitt aus der inhaltlichen Analyse der Interviews

165

Zur Klärung der täglichen Arbeitsabläufe wurden aus den Themen und den zuge-ordneten Aussagen, Vorgänge, Bedürf-nisse sowie Probleme bei der täglichen Arbeit der Teamleiter extrahiert.

Die Aussagen wurden in 27 Themen (Tätig-keiten, Werkzeuge, Strukturkomponenten usw.) eingeordnet, welche wiederum zu fünf nachfolgend aufgelisteten, über-greifenden Kategorien aggregiert wurden. Diese Komponenten bilden das Skelett eines Rollenmodells:1. Arbeitsablauf2. Arbeitswerkzeuge3. Datenablage4. Kommunikation5. Kontrolle

Auffällig geworden ist, dass bestimmte Werkzeuge und Aufgaben nur in bestimm-ten Projektphasen relevant sind und zudem nur für bestimmte Teamleiter von Bedeutung waren, was auf eine notwen-dige Anpassbarkeit auf Nutzerebene hin-deutet. 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 Bau-gruppen und Prozessen müssen schnell erfolgen

– Häufi ger Zugriff auf Statusinformationen – Sehr heterogene, individuelle Datenstrukturen

– Ständige Priorisierung von Aufgaben und Prozessen

Daraus lassen sich erste Anforderungen an die Konzeption eines Role-Based-Inter-faces ableiten: – Individualisierbare Konfi gurierbarkeit mit Vorkonfi guration (Templates) ermöglicht eine projekt- und aufgabenorientierte Einstellung ohne Nachteile der Konfi gurierbarkeit

– Klare Übersicht bestimmter, individueller Informationen aus den spezifi schen Anwendungen („Dashboard-Charakter“)

– Schneller Wechsel zur gewünschten Anwendung unter Berücksichtigung der aktuell ausgewählten Datensicht (bspw. Projektnummer, Teilenummer)

– Applikations- und projektüber-greifende 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 über-prüft werden. Aus den Interviews konnten

wir entnehmen, dass die Zusammen arbeit im Unternehmen sehr stark verzahnt ist, insofern liegt es nahe, dass bspw. die Pro-jektarbeitsstruktur (mehrere niederkomplexe Produkte vs. ein komplexes Produkt), dyna-mische Tagesstruktur, dynamische Kommu-nikationsstruktur sowie die heterogenen, individuellen Datenstrukturen auch bei anderen Mitarbeitern von Relevanz sind.

6.Konzeptentwicklung

Grundlage der Konzeption bildete ein An wendungsszenario mit einer Persona namens Stefan Kessler. Während eines rea-listischen Tagesablaufes wurden Aufga ben eines typischen Teamleiters mit dem Behr Workspace beschrieben. Es wur den Kon-zept ideen entwickelt, als Scribbles bzw. Wireframes visualisiert [Abb. 5] sowie mit den Anforderungen aus den Interview- Analysen harmonisiert und wiederum in das Anwendungsszenario überführt. Die Grundkonzeption zeigt hier schon wesent-liche Merkmale des Workplace-Ansatzes: individuelle Kon fi gurierbarkeit und Anord-nung von aufgaben- und projektorientierten Werkzeugen sowie programmspezifi sche und individuell einstellbare Informations-sichten aktuell relevanter Datensätze.

Abb. 5. Scribble erster Konzeptideen

166


Industrie UX

Dieses Szenario zeigt und beschreibt kon-krete Aktivitäten der Persona entlang eines Tagesablaufs: Arbeitsbeginn, Starten der letzten Sitzung, Konfi guration bestimmter Elemente, Suche neuer Aufträge, Prüfen anstehender Aufgaben etc. Das Interface-konzept wurde als Wireframe-Darstellung mit einer hochwertigen, realistischen, aber nicht zu fi nal wirkenden Anmutung entwor-fen, die zu Anmerkungen und Änderungs-vorschlägen animiert.

Der Arbeitsbereich oder Workspace [Abb. 6] ist eine Arbeitsfl äche auf dem Bildschirm vergleichbar zu einem „Desk-top-Dashboard“ und bietet für die ver-schiedenen Programme eine aktuelle Vorschau, die es dem Nutzer ermöglicht, Kontrollinformationen in unterschiedli-chen 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 konfi gurieren und dazwis-chen hin und her wechseln. Diese Konzepte sollen es ermöglichen, den Anforderungen paralleler, phasenübergreifender Projek-tarbeit und einem schnellen Wechsel zur entsprechenden Anwendung gerecht zu werden und eine möglichst einfache, vorkonfi gurierte und trotzdem individuelle Anpassbarkeit abzubilden.

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 Work space angelegt werden kann. [Abb. 7]

Den Nutzern können außerdem Mustervor-lagen zur Verfügung gestellt werden, auf deren Basis sie ihren Workspace konfi gu-rieren 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

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 Anwendun-gen gestartet werden müssen. Die drei-stufi ge Darstellungsgröße bietet entspre-chende Detailansichten. Vorkonfi gurierte Informationselemente können innerhalb eines Rasters positioniert werden. Prin-zipiell dürfen sich Informationselemente

Abb. 6. Aufbau eines Workspace

Abb. 7. Auswahl Workspace

Abb. 8. Auswahl der Programmvorschau

167

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 Sicht-barkeit 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üg-bar – das entspricht der Anforderung, Auf-gaben und Prozesse ständig priorisieren zu können. Die Programmvorschau ist das „Herzstück“ des Konzeptansatzes. Wesent-lich ist dabei, dass die Nutzer aktuelle Infor-mationen aus den von ihnen ausgewählten Datensätzen der Programme angezeigt bekommen, was eine ständige Kontrolle und Übersicht der wesentlichen Informa-tionen ermöglicht und den Anforderungen nach Konfigurierbarkeit und individueller, aufgabenspezifischer Übersicht entspricht.

Der Absprung in das Programm erfolgt von jeder Größe aus über einen Doppel-klick. Über der Vorschau stehen jeweils der Programmname und der Projektname, falls die Vorschau projekt bezogen ist. Der „Landepunkt“ innerhalb der Ziel-Anwen-dung sollte möglichst korres pondierend zur Vorschau-Ansicht sein, damit sich der Nutzer schnell in der jeweiligen Anwend-ung und den entsprechenden Kennzahlen wiederfindet. Die kleine Vorschau zeigt nur den Programmnamen und eine Status-meldung. Über die Pfeilspitze kann in die mittlere Größe gewechselt werden. Der hell orangene Vorschaubalken zeigt an, dass Aufgaben oder Meldungen im Pro-gramm ausstehen. [Abb. 10] Gibt es keine Statusmeldungen aus dem Programm, ist der Balken im Prototyp in einem dunkleren orange gestaltet. [Abb. 9]

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.

Über das Zahnrad kann die Ansicht kon-figuriert werden Beispielsweise können in VAMAS Tabellenspalten für die Vorschau gewählt werden. [Abb. 12]

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 nutzerzentrier-ten 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 über-tragen werden können, um danach in die Software-Entwicklung zu gehen und funk-tionsfähige Prototypen für Feldversuche zu entwickeln.

Abb. 9. Basisansicht des Workspace

Abb. 10. Vorschau EDM klein

Abb. 11. Vorschau VAMAS mittel

168


Industrie UX

Literatur1. 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.,

Fitzmaurice, G. (2012). Triggering Triggers

and Burying Barriers to Customizing Software.

In Proc. CHI’12.ACM, S. 2717–2726.

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

4. Cooper, A. (2004). The Inmates Are Running

the Asylum: Why High Tech Products Drive

Us Crazy and How to Restore the Sanity (2nd

Edition).

5. Cooper, A. (2007). About Face 3: The

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

development environment. In Proceedings

of the SIGCHI Conference on Human

Factors in Computing Systems (CHI ‘08).

ACM, New York, NY, USA, 1267–1270.

DOI=10.1145/1357054.1357251.

7. Gillen, J., Cameron, C. A., Tapanya, S.,

Pinto, G., Hancock, R., Young, S., &Accorti

Gamannossi, B. (2007). ‘A Day in the Life’:

advancing a methodology for the cultural

study of development and learning in early

childhood. Early Child Development and

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

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.

15. Ristic, S. (2011). An Overview of the

Approaches for A PLM Application‘s

Customization. XV International Scientific

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,

akzeptiert). Role-Based-Client Workspace

– Entwicklung von Dashboard-Interfaces

im Product Lifecycle Management (PLM).

Im Tagungsband der 10. Berliner Werkstatt

Mensch-Maschine-Systeme, Oktober 2013.

18. Tudor, L.G., Muller, M.J., Dayton, T.,

Root, R.W. (1993). A participatory design

technique for high-level task analysis,

critique, and redesign: The CARD method.

In: Proceedings of the Human Factors and

Ergonomics Society 1993 Meeting, Seattle

WA, Oktober 1993, S.295–299

Abb. 12. Spaltenauswahl in VAMAS

Abb. 13. Große Vorschau

169

Keywords: /// Zeitoptimierung/// Industrie-Interfaces/// Touch-Computing-Interface/// Responsive Design/// Web-Applikation

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 Konfigurations-zeiten 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 User-Experience-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. Fokusziel-gruppe der Anwendung sind internationale Fachhandwerker und gewerbliche Anlagen-planer („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.

möglich. Daneben existieren umfangreiche Konfigurationsmöglichkeiten, wie z. B. die Definition eigener Photovoltaik-Genera-toren (Solar-Module) oder das Hinzufügen individueller Wetterdaten und elektrischer Verbrauchsprofile.

Um neben Windows-PCs auch auf ande-ren 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-Interface-Konzepts für die Sunny-Design-Anwendung beziehen sich auf unterschiedliche Aspekte

1. Ausgangssituation und Zielsetzung

Die SMA Solar Technology AG ist weltweit führend in der Entwicklung, der Produktion und dem Vertrieb von Solar-Wechselrich-tern 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 Dimensi-onierung des Querschnitts der elektri-schen Leitungen vorzunehmen und den Eigenverbrauch in die Berechnungen mit einzubeziehen. Umfangreiche Datenban-ken zu standortabhängigen Klimadaten, Solarmodulen und SMA-Wechselrichtern unterstützen die Anlagenkonfiguration. Es ist sowohl die automatische wie auch manuelle Auslegung von Solaranlagen

der Informationsarchitektur mit Informati-onsgewichtung und Use-Case-orientierter Neustrukturierung der Inhalte und Funktio-nen, sowie auf die Usability-Anforderungen im Rahmen der zeiteffizienten Aufgaben-bearbeitung bei der Anlagenauslegung. Nachfolgend sind die wesentlichen Anfor-derungen und Ziele aufgezeigt. – Re-Design und Neuentwicklung der Informationsarchitektur von der be ste henden PC-Anwendung zur ersten internationalen Multi-Device-fähigen Web-Anwendung im Photovoltaik-Bereich.

– Optimierung des Time-to-Result-Faktors mit Halbierung der Benutzungszeiten bei einer Anla gen-auslegung mit gleichem Konfigura - tions raum und Einstellungs möglich- keiten.

– Entwicklung eines flexiblen Touch-Computing-Interfaces mit

„Time = Money“: User-Interface-Konzept zur zeiteffizienten Auslegung komplexer Solaranlagen Einblicke in Gestaltungs-Muster und Usability-Parameter einer webbasierten Konfigurationssoftware im internationalen Kontext

Oliver Gerstheimerchilli mind GmbHKönigstor 2334117 [email protected]

Simon Griwatzchilli mind GmbHKönigstor 2334117 [email protected]

Dr. Thomas StraubSMA Solar Technology AGSonnenallee 134266 [email protected]

Julian MengelSMA Solar Technology AGSonnenallee134266 [email protected]

170


Industrie UX

Responsive-Design-Struktur für den internationalen Anwendermarkt mit Fokus auf Anlagenplanung und Detailkonfi guration von Photo voltaik-anlagen auf PC-, Mac-, iPad- bzw. Tablet-PC- und weiteren mobilen Frameworks (iOS, Android, Windows Phone).

– Aufgabenbasierte Unterscheidung von zeitlichen, kontextuellen und zielkundenspezifi schen Zugangs-struk turen: „Fast Track“ mit Verwen-dung systemseitiger Default-Einstellungen und automatisierten Auslegungsvorschlägen und „Long Track“ mit manueller und detaillierter Anlagenauslegung inklusive individueller Anpassung lokaler und spezifi scher Einstellungen.

– Rollenbasierter Zugang mit Relevanzfokus für drei defi nierte Hauptnutzergruppen: Anonym/Gast, registrierte Nutzer, kostenpfl ichtige Zugänge mit Premiumdiensten.

– Flexible Kunden-Nutzen-Fokussierung (Stakeholder) für gewerbliche Nutzer (Power-User) und interessierte End kun-den einerseits, sowie für „normale“ Hausanlagen und komplexe gewerb-liche Solar-Anlagen (bis 30 kW) ander-er seits in allen relevanten Zielmärkten.

2.Entwicklungsansatz, Projektverlauf und Teilprojekte

Ausgangssituation des Projekts waren die bestehenden Sunny Design Desktop-An-wen dungen 1.5 und 2.2 mit ihren viel fältigen und komplexen Möglichkeiten der Anlagen-auslegung und Einstellungs möglichkeiten.

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 umfas-sende Systemanalyse mit Fokus auf Nutzer, Kontext und Aufgabenanforderung stellten die Basis für den grundlegenden Entwurf der neuen Informationsarchitektur und Use-Case-Zusammenhänge dar. [Abb. 1]

Das übergreifende Entwicklungsframework kann in vier Bereiche unterschieden wer-den, die relevanten Einfl uss im Rahmen der technischen Möglichkeiten und Restrik-tionen sowie der nutzungsbezogenen Anforderungen auf den Entwurf des neuen „Sunny Design Web“ haben.1. Systemanalyse Status quo und Anfor der-

ungsdefi nition aus Nutzer-Kontext-Sicht entlang priorisierter Use Cases mit Experten-Fokusgruppen zur Identi-fi kation von Optimierungspotenzialen;

2. Informationsarchitektur und Usability mit Informationspriorisierung, Entwicklung von Wireframe-Strukturen und Click-fl ows sowie einer kontinuierlichen User-Experience-Evaluation;

3. Entwicklung und Defi nition von Gestaltungsmustern und Layouts sowie adaptive Design- und Tabletoptimierung als Grundlage des User-Interface-Designs („Skinning“);

4. Technischer Systemhintergrund mit teilautomatisierten Vorschlags pro-zes sen und -mechanismen sowie Personalisierungs-/Bibliotheks-angeboten und Feedbackstrukturen. [Abb. 2]

Nachfolgend sind entwurfsrelevante Aktivi-täten und Aspekte aus den vier Bereichen aufgezeigt, die unter anderem im Entwick-lungsprozess bearbeitet wurden: – Systematische Analyse mit Hinter-fragung der bestehenden Informations-architektur (IA) und User-Interface-Strukturen (UI-Strukturen), sowie Evaluation der Zeitkontexte während der Nutzung;

– Nutzerzentrierte Priorisierung neuer System-Anforderungen auf Basis

Abb. 1. Ausgangspunkt Sunny Design Desktop-Anwendung 2.2

Abb. 6. Entwicklungsframework

171

existierenden Personen dar, sondern über-nahmen eine Art „Stellvertreterfunktion“ für eine Gruppe ähnlicher Nutzertypen mit spezifi schen Charaktereigenschaften und Verhaltensweisen. Neben der Sammlung, Strukturierung und Priorisierung der Nut-zeranforderungen und Use Cases wurden die Personas auch genutzt, um zwischen den Projektbeteiligten ein gemeinsames Verständnis von den präferierten Zielgrup-pen zu erhalten.

Die relevanten Nutzer lassen sich grob in die zwei Gruppen der gewerbliche Anwen-der und der privaten Endkunden unter-teilen. Der Fokus bei der Optimierung der Informationsarchitektur lag auf den gewerblichen Nutzern, die in den „Solar-teur“ (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, effi ziente Durchführung der stark frequentierten Use Cases, als relevan-testes Erfolgskriterium.

Lesson Learned

Personas ermöglichen, ausgehend von einem gemeinsamen Verständnis der

vorhandener Kundenfeedbacks mit Fokus auf Zeitoptimierung bei der Standard-Anlagenauslegung;

– Nutzer-Kontextanalyse und Bewertung mit Experten zur Ableitung und Defi ni-tion der Usability-und User-Interface-Anforderungen bei den neuen webbasierten Bedienoberfl ächen;

– Entwicklung und Simulation von alter-nativen 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 Experten-Anwendern 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 Cases2.1.1.Nutzer und Kontext: „Time = Money“

Als Grundlage für die Identifi kation der Nutzeranforderungen und Use Cases wurden Nutzergruppen identifi ziert und als Personas modelliert. Die entwickel-ten Personas stellten dabei keine real

präferierten Nutzergruppen, eine sys-tematische Sammlung, Strukturierung und Priorisierung von Use Cases und Anforderungen.

2.1.2.UseCaseDefi nition: „Relevanz und Frequenz“

Ausgehend von den defi nierten Personas wurden typische Use Cases defi niert und nach Nutzungsrelevanz und -frequenz bewertet und priorisiert. Der Use Case „Erstellung von Anlagenkonfi guratio-nen“ bekam dabei die höchste Relevanz zugesprochen. Insbesondere die automa-tische Auslegung, also die systemseitige Unterstützung des Konfi gurationsprozes-ses, 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 „Fast-Track-Auslegung“ stand so im Fokus des Entwurfs, jedoch mit der fl exiblen Möglich-keit den Konfi gurationsprozess 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 Pers-pektive der Nutzer zu defi nieren und mit allen Projektbeteiligten deckungsgleich zu diskutieren.

2.1.3.ExpertenEvaluation: „Test the Best“

Auf Grundlage defi nierter Use Cases wurde das Vorgängersystem einer Evalua-tion durch Usability-Experten unterzogen und auf Kriterien wie z. B. Aufgabenange-messenheit, Erwartungskonformität und Fehlertoleranz (Zufriedenstellung), Effi zienz und Effektivität hin untersucht. Die beson-ders relevanten und häufi g frequentierten Use Cases wie z. B. automatische und manuelle Auslegung und die im Ausle-gungsprozess integrierten Use Cases wie

Abb. 3. Informationsarchitektur „Fast Track“, „Fast+ Track“ und „Long Track“

172


Industrie UX

Eingabe der Basisdaten, Leitungsdimensi-onierung und Eigenverbrauchsberechnung wurden gezielt unter dem Aspekt einer möglichen Optimierung hinsichtlich einer Zeiteinsparung während der Auslegung analysiert.

Entwurfsrelevante Ergebnisse aus der UX-Evaluation waren eine generelle Stärken- und Schwächenanalyse der bestehenden Anwendungen sowie die konkrete Iden-tifikation von Optimierungspotenzialen und Ansatzpunkten für die neue Informa-tionsgewichtung. Im Rahmen der Analyse wurden zudem mögliche Herausforderun-gen 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, Optimierungspo-tenziale und Herausforderungen für den Entwurfsprozess zu identifizieren.

2.2. Informationsarchitektur und Usability 2.2.1. Wireframe, Clickflow und ExpertenEvaluation

Zur ersten Visualisierung der neuen Lay-out- und Bedienstrukturen wurden Wire-frames 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 Anpassbar-keit 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.

Auf Grundlage von zusammengefassten Wireframes als Clickflows wurden unterneh-mensinterne Experten und fachlich Verant-wortliche schon früh in den Entwurfsprozess integriert. Die Experten-Workshops dienten dabei sowohl der Überprüfung der Layout- und Bedienstrukturen als auch der Neube-wertung von Relevanz und Frequenz entlang

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 Workflowoptimierung: „Fast Track“ vs. „Long Track“

Sunny Design ist im Hauptnutzungskontext ein Wizard, der den Nutzer durch den Pro-zess der Auslegung von Solaranlagen führt. Einerseits soll die Software einen ungeübten Nutzer mit wenigen Fachkenntnissen intuitiv, effizient und erfolgreich durch den Prozess der Anlagenauslegung führen, anderer-seits müssen professionelle Anwender, wie Solarinstallateure spezifische und teilweise sehr detaillierte Konfigurationen und Ausle-gungen vornehmen können.

Abb. 4. Wireframe-Strukturen

173

Somit treffen hier zwei Nutzungssze-narien und Anwendungsziele mit sehr unterschiedlichen Anforderungen an die Informationsarchitektur und das User Interface aufeinander. Um dieser Anfor-derungsbreite zu begegnen wurden zwei Haupt-User-Stories mit gleichem Anfangs- und 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 Polarisierungs-szenarien ist jede beliebige Graduierung möglich. So lässt sich z. B. ein Ausle-gungsprojekt 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 notwendi-gen Informationen reduziert, alle weiteren Informationen und Einstellungen können, müssen aber nicht eingeblendet werden. Die schnelle und fehlerfreie Grundausle-gung einer Anlage für ungeübte Nutzer steht im Vordergrund. Kontextuell werden hilfreiche Hinweise und Tipps zum jeweili-gen Arbeitsschritt eingeblendet.

Systemseitige Unterstützung erfährt der Anwender durch optimierte Voreinstellun-gen und optionale automatische Konfi-gurationen, 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

Nutzer kann an jeder Stelle im Auslegungs-prozess 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 Dialogfens-tern 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.

Abb. 5. Flow-Diagramme zum Fast-Track- und Long-Track-Szenario

174


Industrie UX

2.2.3. Ausgewählte effizienzsteigernde Features

Neben den bereits beschriebenen effizienz-steigernden 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 Anlagen-planung und -auslegung ermöglichen.

Persönliche Voreinstellungen und Vorlagen Registrierte User haben weitreichende Vorteile durch die umfangreichen Optio-nen der accountspezifischen Voreinstel-lungen. 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 Aus-wahl durch systemseitige Auslegungsvor-schläge und -vergleiche können unnötige Auslegungsvarianten schon im Vorfeld ausgegrenzt werden.

Das Anlegen von eigenen Anlagenstand-orten mit individuellen Angaben zu Wet-terdaten, Netzspannung oder Währung unterstützt z. B. Solarteure/Installateure, die überregional oder international arbei-ten. Hat ein Installateur häufig ähnliche PV-Anlagen zu planen, profitiert er dabei durch die Möglichkeit, Projekte als

Vorlagen zu definieren, um so mit wenig Änderungen auch komplexe Auslegungen in kürzester Zeit durchführen zu können.

Vermeidung von Konfigurationsfehlern Ein sehr wichtiger Aspekt innerhalb einer Planungssoftware mit komplexen Konfigu-rationen ist die Fehlervermeidung durch klare Feedbackstrukturen, insbesondere bei manuellen Konfigurationen, die bei ungeübten Anwendern leichter zu fehler-hafter Anlagenauslegung führen können.

Die Software erkennt Konfigurationsfeh-ler automatisch und zeigt diese direkt am auslösenden Element an. Im Kern der Solaranlagen-Konfiguration, bei der Auswahl und Zusammenstellung von Solar-modulen und Wechselrichtern, werden dem Anwender zum Beispiel die System-Feedbacks priorisiert und kategorisiert mit Fehlern (z. B. Gefährdung von Wechsel-richtern), Warnungen (z. B. energetische Verluste) und Hinweisen (z. B. geringfügige Kompatibilitätsprobleme von Wechsel-richtern und Solar-Modulen) angezeigt. Zur Verstärkung der Fehlerkategorisierung werden die Fehlermeldungen mit eindeu-tigen 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 zeit-raubendes „Trial and Error“ zu vermeiden, werden dem User zusätzlich Lösungsvor-schläge und detaillierte Informationen

angezeigt. Ein weiterer positiver Effekt ist die Entlastung der Service-Hotline durch die schnelle und intuitive Fehlererkennung mit möglichen Lösungsalternativen im Nutzungskontext. [Abb. 6]

Erweiterte Kontrolle und Transparenz Im Verlauf einer Anlagenauslegung erfährt der Anwender an zahlreichen Stellen Un ter stützung durch generierte Diagram me und Schaubilder um Kon-figurationen visuell abzubilden und sie hinsichtlich Anlagenleistung (Performance) und Wirtschaftlichkeit (Wirkungsgrad) besser bewertbar zu machen. Das Ergebnis jedes Projekts (umgesetzte Anlagenausle-gung) in „Sunny Design Web“ ist eine Pro-jektdokumentation der Anlagenauslegung, welche als PDF ausgeleitet werden kann. Auch für diesen Bereich wurden Funktio-nen entwickelt, die den Nutzer hinsichtlich Zeitersparnis und Qualitätskontrolle unter-stützen. So können in einer Zusammenfas-sung 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, Inter-pretieren und Bewerten einer Auslegung und ggf. bestehender Auslegungsfeh-ler. Durch individuelle Voreinstellungen

Abb. 6. Anzeige von Hinweisen und Fehlermeldungen am auslö-senden Element und in den Detailinformationen

175

können Ergebnisse detailliert und persona-lisiert werden, ohne den Auslegungspro-zess zu verlängern. Gespeicherte Projekt-vorlagen reduzieren die durchzuführenden Aufgaben auf das Anpassen weniger relevanter Einstellungen.

2.3.Gestaltungsmuster und Layout2.3.1.Framework und Grundmuster

Die Gestaltungsmuster sind an jedem Punkt stark geprägt von der Informationsar-chitektur 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 Unter-stü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 Darstel-lung von komplexen Tabelleninhalten mit umfangreichen technischen Details. Bei einer Umsetzung im multilingualen Kon-text und adaptiven Layout sind hier enge

Entwurfsgrenzen gesetzt und eine gute Gewichtung, Gliederung und Auslagerung komplexer Inhalte essenziell. Die Aus-richtung der Darstellung für verschiedene Endgeräte verlangt zudem einen fl exiblen Umgang mit unterschiedlichen Layout-Bereichen 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 Navi-gation über Projekte (Liste oder Suche), die Projektdaten als Übersicht oder den Anlagenbaum/Projektbaum einer Photovoltaik-Anlage in ihren Einzel-komponenten dar.

– Der Content-Bereich (4) verhält sich adaptiv und wird vertikal in Informa-tionsclustern dargestellt, die sich in der Seitennavigation wiederfi nden und einzeln über Folding-Boxes auf- und 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 Defi nition abgeschlossener Unterauf-gaben ermöglicht eine Reduzierung der Komplexität durch die Aufteilung in klar strukturierte, aufgabenbezogene Berei-che. Durch den geführten, dialogisierten

Abb. 7. Layout-Framework für Multi-Device-Strukturen (1280 px Breite bzw. 768 px Breite)

176


Industrie UX

Prozess kann das Zielergebnis in kürzester Zeit erreicht werden, obwohl Zugriff auf unterschiedliche Zusatzeinstellungen und -features besteht.

2.3.2. Responsive Design und TabletPC Optimierung (TransmediaUsability)

Für die Gewährleistung einer konsistenten Nutzerführung auf Desktop- oder Tablet-PC-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 aktu-elle Fensterbreite des Browser dynamisch skaliert, andere Elemente reagieren auf fixe Sprungmarken und werden stufen-weise 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 Einga-ben/Auswahlen, wie z. B. dem Solarmo-dul-Typ. Andererseits wurden durchgän-gig touch-optimierte Interaktionsmuster zur Eingabe von Werten genutzt, um diese z. B. durch Up-/Down-Taps anzupas-sen statt sie manuell einzugeben. Auch die Notwendigkeit zur Eingabe individuel-ler Texte über die virtuelle Tastatur wurde auf ein Minimum reduziert. Die „klassi-sche“ Tastatureingabe für eine optimale PC-Nutzung bleibt hierbei parallel an allen Stellen erhalten.

Um die Lesbarkeit in jeder verfügba-ren 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 gleich-zeitiger Fokussierung auf die relevanten Einstellungen und Features möglich. Zusätzliche touch-optimierte Eingabeme-thoden 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 Anlagenpla-nern eine benutzerfreundliche Bedienober-fläche. Sie schlägt dem Nutzer für eine vorgegebene PV-Anlage – definiert über Standort, verwendete PV-Module, Anla-gengröße und ggf. weiteren Vorgaben – mögliche Kombinationen von Wechsel-richtern und entsprechende Konfiguratio-nen, 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 Investitionskos-ten unter Berücksichtigung des Nennleis-tungsverhältnisses) bewertet.

Manuell erstellte Auslegungen werden automatisch technisch geprüft und der Anwender wird zusätzlich mit zielgerich-teten Hinweisen zur Optimierung unter-stützt. Schließlich werden der prognosti-zierte 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, Fachhand-werker profitieren von der Zeitersparnis im

Abb. 8. Beispiel für adaptive Bereiche – Header und Seitenleiste

177

Planungs- und Beratungsprozess. Während der Planung besteht zudem die Möglich-keit, den potenziellen Eigenverbrauch an Strom des Solaranlagenbetreibers zu ermitteln und sukzessive über die erwei-terten Konfi gurationsmöglichkeiten zu optimieren. [Abb. 9]

Die nachfolgend aufgezeigten Funktions- und Nutzungsmerkmale beschreiben wichtige Benefi ts der Anwendung „Sunny Design Web“ aus Anwendersicht. – Halbierung der Auslegungszeit für eine Anlage durch Optimierung der Benutzerlogik in den identifi zierten 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 Tablet-PCs (iPad und Android-Tablet-PCs);

– Zielgruppenspezifi sche Workfl ow-Optimierung für sowohl Experten mit umfangreichen Einstellungen und individuellen Vorkonfi gurationen (z. B. eigene Wetterdaten und Verbrauchsprofi le) 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 Pfl ichtangaben.

4.Fazit: Effi zienz 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-Case-Defi nition ist insbesondere die Entwicklung von schnell begreif- und bewertbaren Wireframe-Strukturen essentiell für die gemeinsame Optimierung der grundlegen-den Informationsarchitektur – aus fachlicher Experten- und aus UI-Sicht. Das Zusam-menspiel von Informationsarchitektur und User-Interface-Design auf der einen Seite mit den systemtechnischen Automatismen und Funktionsmöglichkeiten auf der ande-ren Seite bilden dabei das ideale Frame-work für einen optimierten Neuentwurf.

Allerdings: Die „Richtige Fragestel-lung“ zu Beginn zu identifi zieren und die passende Antwort während des Projekts

Abb. 9. „Sunny Design Web“ – Touch-Computing-Interface mit Responsive-Design-Struktur

178


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 Service-Produkt wirklich, wirklich aus?“. Gemeint sind hierbei sowohl radikal auffällige und damit in der Erstbenutzung kundenspür-bare Faktoren einer Produktveränderung und -verbesserung, wie auch „Weitererzäh-lungsfaktoren“ aus Kundensicht.

Diese erfolgsstrategische Identifikation zu Beginn der Projektierung erfolgt über eine ergebnisoffene Fragestellung im Rahmen eines Design (Re-)Thinkings. Den identifi-zierten Strategie-Helden im vorgestellten Projekt „Time = Money“, also die Zeit-Ergebnis-Optimierung einer Anwendung, gilt es im Projektverlauf regelmäßig und objektiv auf seine offensichtliche, spürbare Wirksamkeit aus Kundensicht zu evaluie-ren. Um hierbei erfolgreich zu sein, muss diese Zielsetzung im Projektverlauf inner-halb des Teams wiederholt kommuniziert und re-positioniert werden. Auch Rekapi-tulations-Meetings auf die Vision der Ur-Zielsetzung sind erfolgsversprechend für die „inhaltlich-strategische Spurhaltung“.

Methodische Iterationsphasen mit Visua-lisierungs- und Modellbaustufen sind im Entwicklungsprozess elementarer Bestand-teil und das „Pflichthandwerk“ für eine nutzerzentrierte Produktentwicklung im UX-Team. Die hieraus entstehenden, multi-plen Evaluations- und Optimierungsergeb-nisse 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 Fehlentschei-dungen und einer möglichen „Überopti-mierung“ führen.

Es gilt also, im Projektverlauf die Ur-Fra-gestellung und -Zielsetzung objektiv, aber hartnäckig fokussiert, bis zur kundenge-rechten Lösungen, den Launch im Markt, umzusetzen und nicht im Projekt- oder Dis-kussionsverlauf aus dem Blick zu verlieren.

Denn es kann – neben vielen, ebenfalls relevanten Optimierungsansätzen – nur ein strategisches Masterziel geben.

179

Peter HartmannSchulz Systemtechnik [email protected]

Maike PetzoldSchulz Systemtechnik [email protected]

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 Automatisierungstech-nik. Die Herausforderung hierbei ist es, ein nutzerorientiertes System für Projektierer und Endanwender bereitzustellen. Das erfordert die Berücksichtigung verschie-denster Kontexte und Benutzergruppen.

Die Schulz Systemtechnik GmbH vertreibt bereits seit mehr als einem Jahrzehnt Steuerungssoftware für die Industrieau-tomatisierung. Sie hat sich funktional am Markt bewährt, entspricht jedoch nicht

mehr aktuellen Ansprüchen aus techno-logischer- und Anwendersicht. Aufgrund dessen entschied man sich ein von Grund auf neues System zu entwickeln. Dabei

soll, unter Verwendung moderner Entwick-lungsmethodiken und Technologien, die Qualität und Funktionalität aus dem alten Programm beibehalten werden.

Keywords: /// Human Centered Design/// Entwicklungsprozesse/// Design Driven Development/// Prototypen/// HCD Tools und Werkzeuge

AbstractDie Nahrungs- und Futtermittelindustrie ist geprägt von höchsten Ansprüchen an Funktionalität und Zuverlässigkeit der Produktionsanlagen. Aufgrund der hohen Kom-plexitä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 Entwick-lern genutzt. Hier liegt der Fokus auf effi zienten Werkzeugen zur Erstellung und Wartung einer Anlage. Die von dem Projektierer erstellte Endanwendung wird dann von geschul-ten 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 effi zientesten Werkzeuge sind und worauf bei der Umsetzung geachtet werden muss.

Human Centered Design für Prozessleit-systeme in der Industrieautomation

Abb. 6. Automatisierungpyramide (Ulrich 2007)

180

Softwareumgebung von Prozessleitsystemen

Das Aufgabengebiet eines Prozessleitsys-tems ist in Abbildung 1 dargestellt. Es umfasst enge Schnittstellen zu den Schich ten der MES sowie SPS der Auto-matisierungspyramide. Das beinhaltet die Steuerung von Werksprozessen, die Erfas-sung und Modifi kation 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, Produk-tion usw.) bis hin zu der Steuerung einzelner Werksprozesse und stellt eine Schnittstelle zum betriebseigenen ERP System bereit.

Mit dem Augenmerk auf Human Cente-red Design stellt besonders das Design der Oberfl ächen der unterschiedlichen Anlagenteile mit ihren divergenten Anwen-dern 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 Werks-prozesse 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, Proto-kolle und automatisierte Verladungen),

– Anlagenbesitzer die Produktions-kennzahlen und Berichte einsehen können müssen.

Der Zusammenhang der verschiedenen Nutzergruppen wird in Abbildung 2 dar-gestellt. [Abb. 2]

Human Centered Design (HCD)

„Usabilty ist […] das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext

genutzt werden kann, um bestimmte Ziele effektiv, effi zient und zufriedenstellend zu erreichen.“ (ISO 9241) [Abb. 3]

Human Centered Design ist ein Vorge-hensmodell 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 Anwendun-gen wie einem Prozessleitsystem ist Wert darauf zu legen, die Komplexität der Bedie-nung in der Oberfl äche effi zient nutzbar zu machen. Um eine spätere Unzufriedenheit


Industrie UX

Abb. 2. Zusammenhang der verschiedenen Nutzer gruppen

Abb. 3. Prozessmodell (DIN EN ISO 9241–210)

181

zu vermeiden sollen bereits im Gestal-tungsprozess benutzerzentrierte Methoden zur Umsetzung eingesetzt werden. Die Nutzung von Human Centered Design ist in dem Entwicklungsprozess anzustreben um eine hohe Akzeptanz beim zukünfti-gen Nutzer zu erzielen. Die Verwendung soll bereits früh im Entwicklungsprozess manifestiert werden um ein konsistentes Produkt bereitzustellen. Die Möglichkei-ten zur Einbindung von Human Centered Design Methoden werden in den folgen-den 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, Webi-naren und Onlinebeiträgen. Mittlerweile befassen sich auch vor allem im indus-triellen 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 Systemtech-nik 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

– 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

Benutzerbefragung / Interviews

Interviews mit Anteilseignern an einer Soft ware sind seit jeher ein elementarer Bestandteil der Softwareentwicklung um die Anforderungen an ein Produkt zu ermitteln. Es kann nach Sommerville (2007) dabei zwischen zwei unterschiedlichen Typen unterschieden werden:1. „Closed interviews where the stakeholder

answers a predefined set of questions.“2. „Open interviews where there is no

predefined agenda. The requirements engineering team explores a wide range of issues with system stakeholders and hence develops a better understanding of their needs.“

Interviews wurden bei Schulz zu einem sehr frühen Projektstadium durchgeführt, um die ersten groben Anforderungen zu erheben. Dabei werden sowohl die Projekt-leiter als auch die Endnutzer befragt. Um die Anforderungen explorativ zu ermitteln, wurden stets offene Interviews durchge-führt. Die Interviews wurden in Formen von Lasten- bzw. Pflichtenheften dokumentiert.

Es hat sich gezeigt, dass die aus Inter-views 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

Fachkräfte der einzelnen Prozesse hinge-gen besitzen detailliertes Fachwissen, aber beschreiben die Prozesse mit ihrem speziel-len Domänenwissen. Für sie selbstverständ-liche Informationen die essentiell für das Produkt sind, können dabei verloren gehen.

Um diese Lücke zu schließen wurden daher Feldstudien und Prototypen eingesetzt.

Feldstudien

Wie in anderen wissenschaftlichen Diszi-plinen gibt es auch im Human Centered Design den Bereich von Feldstudien. Hier-bei 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 ledig-lich zu beobachten und zu studieren. Es können Verhaltensmuster und Emotionen erkannt werden.

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 Handlungsab-folgen 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üh-ren. 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 effi-zientes und finanziell wie zeitlich kosten-günstiges Mittel dar. Sie benötigen kaum

182

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, PC-Erfahrung 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 die-nen. 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 Prototy-pen, da diese in der frühen Entwicklungs-phase angebracht sind. Sie stellen ein sehr gutes Mittel dar, um eine gemeinsame Grundlage für Diskussionen zu schaffen. Anhand von interaktiven Low-Fidelity Pro-totypen kann präziser innerhalb des Ent-wicklungsteams als auch mit dem Kunden kommuniziert werden. High-Fidelity Pro-totypen die wir mit Blend angelegt haben, stellten einen zu großen Aufwand und zu geringen Nutzen dar. Das bei einem High-Fidelity Prototypen erwartete Look-and-Feel der Anwendung anzulegen ist sehr komplex und konnte in unserem Fall

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 Low-Fidelity Prototypen wird in dem folgenden Abschnitt Indigo Studio sowie dem nächs-ten Kapitel Participatory Design weiter eingegangen.

Blend (Low- und High-Fidelity Prototypen)

Microsoft Expression Blend ist das Design Werkzeug von Microsoft für WPF und Win-Forms. Es war ursprünglich dazu gedacht den Designprozess einer Entwicklung aus-lagern 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 Cont-rols 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 Pro-totypen zu erstellen. Dies kann mit skizzen-haften Controls als Low-Fidelity oder auch mit richtigen Designs und ausgearbeiteten Styles als High-Fidelity Prototyp erfolgen. [Abb. 4]


Industrie UX

Abb. 3. Prototyping eines Low-Fidelity Prototypen mit Blend (Microsoft 2013

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 Echtsys-tem möglich sein. Nach unseren Anforde-rungen 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 beispiels-weise 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 Programmier-aufwand angesetzt werden.

Eine Erleichterung sollte auch eine Tech-nologie 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 ausge-reift ist. Wir mussten erhebliche Geschwin-digkeitseinbußen auf der Oberfläche hin-nehmen beim Einsatz dieser Technologie, die uns dabei helfen sollte kleine Animatio-nen von Controls darzustellen.

Ingido Studio (Low-Fidelity Prototypen)

Aufgrund des hohen Aufwands zum Erstel-len von Prototypen, evaluierten wir weitere Alternativen. Letztendlich fiel die Wahl auf das Produkt Indigo Studio von Infragistics. Die Anwendung bietet eine extrem effizi-ente 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 Walkt-hrough, Storyboarding, Table-Topping, User-Centered-Walkthrough oder Group Walkthrough bekannt. Bei diesem Vorge-hen gehen Entwickler und Nutzer gemein-sam ein Szenario anhand eines Prototypen

in der Software durch. Der Nutzer soll das Szenario alleine und ohne jegliche Hilfe-stellung oder Einflussnahme lösen. Der Test hat den Vorteil, dass durch verschie-denartige Nutzer viele Probleme in kurzer Zeit und schon früh im Entwicklungs-prozess sichtbar werden können. Klassi-scherweise wird dieser Test in Form eines Workshops mit Papierskizzen durchgeführt (Keld, Kensing, Simonsen 2004).

Im Gegensatz zu der klassischen Herange-hensweise mit Papierprototypen, haben wir uns für den Einsatz des kostenlosen Prototyping Tools Indigo Studio entschie-den. 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ätz-lich werden die Prototypen in einem fir-menweiten Wiki veröffentlicht. Dort können sie interaktiv im Browser ausgeführt wer-den. Durch diese Veröffentlichung können auch nicht berücksichtigte Personen, wie aus dem Vertrieb oder fachfremde, die Pla-nung einsehen. Wir erhalten so mehr Feed-back und erreichen auch ein firmenweites Einverständnis über den aktuellen Stand der Softwareplanung und einer gemein-samen „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 ein-seitige Spiegel und Videoaufzeichnungen bei der Durchführung beobachtet werden kann. Sprachaufnahmen und Eye-Tracking

Abb. 5. Rapid Prototyping mit Indigo Studio (Infragistics 2013)

184

können diesen Test vervollständigen. Dies ist einer der aufwändigsten Tests, der aber auch sehr umfangreiche empirische Ergeb-nisse liefert.

Auf Grund des Aufwands, eignet sich die-ser Test eher im späteren Entwicklungsver-lauf eines Produktes. Er ist nicht nur zeitlich sondern auch finanziell sehr aufwändig. Wir wollen in naher Zukunft einen abgespeck-ten Usability Test durchführen. Das Motto dabei lautet ganz ähnlich zu den Ingenieu-ren ohne Grenzen: Low-Cost High-Effici-ency. 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.

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 Bereitstel-len 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?

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,

dass sie selbst aktiv mitgestalten können. Hierzu werden über das Wiki und das Blog Entwicklungsarbeiten nicht nur bekanntge-geben, sondern auch die Planungen schon in Form von interaktiven Prototypen ver-öffentlicht. Durch diese Öffnung und den verständlichen Zugriff auf die Planungs-stände werden Entwicklungsvorhaben schon früh dezentral validiert. Wir erhalten so weiteren Input, wie die Nutzer Aufga-ben verstehen oder welche Aufgaben von den vorhandenen Planungen so noch nicht oder nur schlecht möglich sind.

Ein weiterer und nicht zu vernachlässigen-der Punkt sind die praktisch von selbst und graduell erfolgenden Schulungen über das Wiki. Letztendlich wird die Applikation einen gewissen Komplexitätsgrad aufwei-sen, da sie auch sehr komplexe Aufgaben lösen muss. Durch die schrittweise Evalua-tion 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 Anwen-dung am Ende besser ausnutzen.

Zusammenfassung und Ausblick

Der vorliegende Beitrag zeigt die prak-tische 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

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.

Literatur1. Bødker, K, Kensing, F., Simonsen, J. (2004).

Participatory IT Design: Designing for

Business and Workplace Realities. MIT Press.

2. Dahm, M. (2006). Grundlagen der Mensch-

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

infragistics.com/html/rove/. Abgerufen am

24.06.2013.

5. Microsoft (2013). Microsoft Expression Blend

Präsentation. http://blogs.msdn.com/cfs-

filesystemfile.ashx/__key/communityserver-

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

centered design of systems. Springer Verlag.

9. Sommerville, I. (2007). Software Engineering.

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

and low-fidelity prototyping. Masters Thesis,

University of Amsterdam.

13. Vredenburg, K., Mao, J. Y., Smith, P. W., &

Carey, T. (2002, April). A survey of user-

centered design practice. In Proceedings of

the SIGCHI conference on Human factors

in computing systems: Changing our world,

changing ourselves(pp. 471–478). ACM.


Industrie UX

185

186

User Research

187

1. Mobile Anwendungsentwicklung: (K)Ein Blick auf Kontext & Situation

Wie entstehen überzeugende mobile An -wendungen? – Aus Nutzersicht sind kern-mobile¹ Anwendungen situations- und kontextorientiert: Für Nutzer bieten Apps und mobile Websites Mehrwerte, wenn sie den gegebenen Kontext berücksichtigen und auf die Situation reagieren, in der Nutzer sich befinden, wenn sie die Anwen-dung verwenden.

Wenn dem aber so ist, wenn kernmobile Anwendungen wesentlich auf ihre Nutzungs situation bezogen sein sollten, warum erfolgt dann ihre Konzeption, ihre Entwicklung und auch ihre Evaluation fast ausschließlich „vom Schreibtisch aus“ und ohne jeden Blick auf den letztendlichen Nutzungszusammenhang?

In der Praxis stehen Unternehmen bei der Entwicklung digitaler Produkte immer mehr vor der Aufgabe, regelmäßiges Nutzer-Feedback schon von Beginn an in ihre Entwicklungsprozesse mit einzubin-den. Das zentrale Entwicklungsparadigma heißt ‚Lean UX‘. Ein hier zunehmend verbreitetes und sehr wirkungsstarkes

Nutzer-Feedback-Instrument sind Tests im Usability-/User Experience-Labor.

Für die Entwicklung und Evaluation kern-mobiler Anwendungen allerdings können Labor-Tests schon methodisch nie 100% vollständig sein: denn während sich für Desktop- und Tablet-Anwendungen im Labor authentische Nutzungskontexte durchaus noch erzeugen lassen, können Labor-Studien diese Authentizität für An wendungen, die explizit auf bestimmte Kontexte und Situationen bezogen sind, nicht herstellen.

Für die Entwicklung mobiler Anwendun-gen heißt das: Allein durch Labor-Tests können wesentliche Erfolgsparameter die-ser Services nicht abschließend evaluiert werden. Versteht man Nutzer-Tests darüber hinaus nicht allein als Evaluations-Instru-mente, sondern auch als Ansatzpunkt für nutzergetriebene Innovationen, so bedeu-tet 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

Nutzungskontext methodisch sauber in eine moderne, nutzer- und testorientierte Entwicklung digitaler Produkte einbinden? Und die Antwort lautet: Durch pragmatisch angelegte, schlanke und am iterativen Ent-wicklungsprozess orientierte Feldstudien.

2. Das Vorhaben: Integration von Feldstu-dien in die iterative Produktentwicklung

Feldstudien sind kein neuer Forschungsan-satz (Petermann 2004) und in ihrer klassi-schen, 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 ver-standen und sind primär beschreibend und analyseorientiert. In jüngerer Vergangen-heit werden Feldstudien darüber hinaus jedoch auch bereits als Forschungsansatz für nutzergetriebene Innovation verstanden (Nielsen 2012).

Prototypisch für den Einsatz von Feldstu-dien 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

Feldstudien in der iterativen AnwendungsentwicklungMobile User Experience Optimierung und nutzergetriebene Innovation am Beispiel der Neukonzeption des favor.it Mobile Payment InterfaceDr. Markus Wieneneparo GmbHStahltwiete 2222761 [email protected]

Dr. Rolf Schulte Strathauseparo GmbHStahltwiete 2222761 [email protected]

Keywords: /// Feldstudien/// Digitale Produktentwicklung/

Service Design/// Usability Engineering

/// Iterative Entwicklung/// Mobile Payment/// Mobile User Experience/// Nutzergetriebene Innovation

Abstract„Der Beitrag schildert, wie Feldstudien in der iterativen Entwicklung mobiler Anwendun-gen 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 prag-matisch und schlank geschnittene Projektbausteine maßgeblich erweitern. Die konkre-ten Ergebnisse der Neukonzeption der Payment-Schnittstelle werden vorgestellt und diskutiert.“

188


User Research

Erfahrungsbericht vorgestellt werden, wie wir aktuell bei eparo Feldstudien als Bau-steine eines iterativen, nutzergetriebenen Produkt-Entwicklungsprozesses einsetzen und verstehen. Am Beispiel eines realen Falles soll dabei deutlich werden, 1. dass für die Entwicklung mobiler

An wen dung zentrale Nutzungs- und Erfolgs faktoren ohne Feldstudien nicht zu heben sind.

2. dass Feldstudien gerade aufgrund dieses Umstandes weitreichendes Inno-vationspotential heben können.

3. und dass Feldstudien dabei weder per se teuer, noch zeit- oder personalinten-siv sein müssen und also problemlos in moderne, iterative Entwicklungsprozesse einzubinden sind.

3. Aus der Werkstatt: Entwicklung der favor.it-App

Die favor.it-App verbindet lokale Unterneh-men 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.

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 Kern-branchen der Anwendung die Geschäfts-fü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 anderer-seits die Bedürfnissen der verschiedenen Nutzergruppen zu erheben. Aufbauend

auf den Ergebnissen dieser Research-Phase wurden das Interaktions- sowie das Interface-Konzept definiert und als Pro-totyp umgesetzt. Der Prototyp wiederum wurde sukzessive bis zur Funktionsvollstän-digkeit ausgebaut und durch Konzepttests bis zum Launch verfeinert.

Seit dem Launch wird die App kontinu-ierlich in jeweils mehrstufigen, iterativen Entwicklungsschleifen optimiert. Aller professionellen Expertise folgend hätte zudem noch vor dem Launch mindestens ein Nutzer-Test im Usability-/User Experi-ence-Labor durchgeführt werden müssen. Im Falle der favor.it-App allerdings wurden solchen Nutzer-Tests auf die Optimierun-gen nach dem Lauch verschoben.

4. Im Detail: Optimierung eines Mobile Payment Interface

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 Unterneh-men, das die Coupons ausstellt, transfe-rieren, und können für ihre Coupons dann später am PoS entsprechende Leistungen erwerben.

Am Anfang der Neukonzeption der Schnitt stelle stand dabei die These, dass dieser Prepaid-Mechanismus die Nut-zungssituation 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 Pay-ment, 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 eigent-lichen 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 weni-ger 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 adressie-ren und unterstützen.

Insgesamt sah der Fahrplan für die Neu-konzeption 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 Nutzungssitua-tion am PoS würde eine finale Evaluation des neuen Interface nur durch einen Nutzer-Test im Feld evaluiert werden kön-nen. Ebenso wie zu Beginn der Optimie-rungsschleife wurde damit auch am Ende der erneute Weg ins Feld relevant.

Gleichzeitig war klar, dass der finale Nut-zer-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“ Optimierungsarbei-ten auch in einem authentischen Nut-zungszusammenhang und mit Blick auf die aus Nutzersicht zentrale Käufer-Verkäufer-Interaktion evaluieren und optimieren zu können.

Konzeptionell musste bei diesem Ent-wicklungs-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 Situ-ationsfaktoren erst am Ende der Entwick-lungsschleife erfolgen würde.

Wie allgemein üblich war dabei der ge -samte Entwicklungsprozess iterativ ange-legt: Zum einen bauen die verschiedenen Konzeptions- und Testschleifen aufeinan-der auf. Zum anderen wurde nach jeder Testschleife bewertet, ob eine weitere Entwicklungsrunde auf dem aktuellen Ent wicklungsniveau erfolgt, oder ob die abgeleiteten Optimierungsoptionen auf der nächsten Entwicklungsstufe mit berücksichtigt und validiert werden.

5. Im Feld: Mobile Payment aus Nutzersicht5.1.Das Situations/Kontextmodell

Methodisch konnte für die fi nale Evalua-tion 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 durchge-führt. Aus den Analysen wurde dann das für den favor.it Bezahlprozess maßgeb-liches Situations- und Kontextmodell abge-leitet, 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 Nut-zer sicht, wie gesagt, als der eigentliche Mobile Payment Prozess bewertet wurde, mehrere interaktionsrelevante Situations- und Kontextfaktoren als typisch anzuneh-men sind. Dazu gehören auf der Verkäu-ferseite 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.

Allem voran war dabei für die Payment Interaktion sowohl aus Sicht der Coupon-Einlöser wie auch aus Sicht des Verkaufs-personals insbesondere ein Kriterium essentiell: Der Einlöse- beziehungsweise Bezahlvorgang muss auch unter den teil-weise schwierigen Situationsbedingungen maximal transparent sein. An erster Stelle heißt das, dass insbesondere für den Ver-käufer immer und jederzeit erkennbar sein muss, welcher Coupon aktuell eingelöst wird, und dass der angezeigte Coupon auch genau im gegebenen Moment ein gelöst wird.

Für den Payment-Mechanismus liegt genau hier das maßgebliche Innovations-moment: Denn wie die Nutzer-Interviews deutlich machten, wird beim Bezahlvor-gang neben dem Coupon-Einlöser auch die Verkaufskraft zu einem Nutzer der App: Denn ebenso wie der Kunde muss auch die anwesende Bedienung die Aus-wahl 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 Zeitver-zug zu murren beginnen.

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 auszu-händigen ist.

Als besondere Anforderung wurde deut-lich, 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.

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 Nut-zergruppen. [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 Offl ine-Prozess 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

Abb. 1. Mobile Payment Interface für favor.it State „Push To Pay“ (eparo Axure-Prototyp, 2013)

190

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 ver-tikale Achse vom Käufer hin zur Verkaufs-kraft nahe. Vielmehr provoziert die Zweitei-lung 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 Offl ine-Äquivalent zum ver-bindenden Interaktionselement zwischen Käufer und Verkäufer.

Unterstützt wird die schnelle Identifi zier-barkeit des Coupons durch eine ebenfalls am Print-Couponing orientierte Optik und durch auf das Minimum reduzierte Kerninhalte wie das Logo des Coupon-Ausstellers, eine eindeutige Kennzeich-nung 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-Ein-löser das eigene Smartphone in keinem Fall durch fremde Personen bedient wer-den soll, muss das Entwerten des Cou-pons im digitalen Fall und anders als im analogen Szenario durch den Coupon-Kä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-Mecha-nismus freizulegen und den Coupon zu entwerten.

Ebenso wie die Entriegelung selber, die ein versehentliches Entwerten des Cou-pons 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 fi nalen Feldtest wurde das neue favor.it Payment Interface bereits auf Konzeptbasis (als Paper Prototyp) und als elaborierter Klickdummy (als Axure Proto-typ) getestet und durch Nutzer evaluiert. Jeweils ist der neue Ansatz dabei umfas-send gescheitert.

So löste das Interface im Konzept- wie im Labortest bei Nutzern eher ernsthaftes

Unverständnis als erkennbare Begeiste-rung aus. Zwar konnten die Konzept- und Labor-Tests, wie vorgesehen, wichtige Usability- und Interaktions-Probleme aufdecken. Die grundlegende Interakti-onsidee 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 Rahmenbedingun-gen der App, wie sie im Situationsmo-dell verdichtet wurden, gegeben waren: Der Tresen war breit, die Schlange der Wartenden gerne mal länger, die Bedie-nungen eher jünger und weniger erfahren und neben den verschiedenen Kaffee-Kreationen waren permanent auch noch unterschiedliche Speisen anzurichten und auszuhändigen.

Die Probanden erhielten ein kurzes Briefi ng 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 fi nden würden. Ein Ausprobieren des Ein-lösevorgangs wurde nicht erlaubt. Im Café wussten die Bedienungen, dass irgend-wann 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 Shadowing-Verfahren verfolgte der Beobachter fortan die Aktionen der Probanden und hielt Ausschau nach Interaktionsmomenten, die für eine positive User Experience das Cou-ponings 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.


User Research

Abb. 1. Mobile Payment Interface für favor.it State „Entwerten“ (eparo Axure-Prototyp, 2013)

191

Als Daten standen neben den Beob-achternotizen, die Dokumentation der Critical Incidents sowie die Interview- und Fragebogen-Ergebnisse zur Verfügung.

Im Ergebnis ließen sich so durch den Feld-test alle situationsbezogenen Interface-Elemente 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 Vor-gang dauerte jeweils nur wenige Sekunden und war damit auch in zeitkritischen Situati-onen problemlos einsetzbar.

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 produ-ziert 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 Inter-aktion abzufangen, erscheint sinnvoll.

6. Das Ergebnis: Nutzergetriebene Innovation durch mobile Anwendungs-entwicklung im Feld

Am Erfolg des neuen Payment Interface waren zwei Feldstudien maßgeblich betei-ligt: 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 Situati-onsmodells im Rahmen einer initialen Feld-studie. Erst aus diesen Analysen konnte der Ansatz für das neuartige, konsequent nutzergetriebene und in mehrfacher Weise auf die Nutzungssituation bezogene Pay-ment Interface gewonnen werden.

Allein über Konzept- und Labortests konn-ten Testnutzer die für die Interaktion mit dem neuen Interface zentralen Situations- und Kontextparameter nicht bewerten. Erst im Feldtest wurde erkennbar, ob das neue Interface angemessen auf die Anforde-rungen der Situation und der Interaktion zwischen Kunde und Verkaufskraft reagiert. Erst im Feldtest wurde die finale User Expe-rience des Interface erlebbar. Gleichzeitig konnten Ansätze für eine weitere Optimie-rung der Schnittstelle in einer nächsten Entwicklungsrunde gehoben werden.

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 Entwick-lungsschritte und ihre Ausrichtung auf den finalen Feldtest von Anfang an.

Literatur1. Jacko, Julie / Sears, Andrew (Hgg.) (2003):

The human-computer interaction handbook:

fundamentals, evolving technologies, and

emerging applications.

2. Nielsen, Jakob (2012): The Most Important

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.

1 Als kernmobile Anwendungen sollen hier

Anwendungen bezeichnet werden, deren

Nutzung primär auf Smartphones erfolgt und

die ggf. auch bereits konzeptionell auf die

Nutzung in Unterwegs-Situationen ausgelegt

sind.

192


User Research

193

1. Einleitung

Damit Produkte und Services ideal auf die Bedürfnisse der Benutzer abgestimmt wer-den können, ist es essentiell die Benutzer zu kennen und zu verstehen. Experience Tagebuch Studien sind eine effektive Methode, das Erleben der Benutzer mög-lichst unverfälscht und zeitnah zu erfassen. Dabei werden Wahrnehmungen, Einstel-lungen und Verhaltensweisen der Benutzer in Bezug auf ein Produkt oder Service unter Berücksichtigung der Charakteris-tiken 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.

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 Ser-vice über einen längeren, vordefinierten Zeitraum. Im Vergleich zur herkömmlichen Tagebuchmethode zeichnen sich Experi-ence 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

ein Service, Ästhetik eines Interface oder die soziale Komponente eines Produktes miterhoben.

Aus diesem Grund spielt auch das Sam-meln von Artefakten, wie zum Beispiel Bildern, Videos oder Dokumenten eine wichtige Rolle. Artefakte vermitteln neben den subjektiven Schilderungen der Teil-nehmer noch viele zusätzliche Einblicke in das Erleben.

Experience Tagebücher werden in Kombi-nation 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

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

Keywords: /// Tagebucherhebung/// Benutzerkontext/// Produkt- und

Serviceentwicklung/// User Experience/// Checkliste zur Durchführung

AbstractUm 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 Erhebungs-methode. Durch eine systematische Aufzeichnung der Benutzer-Erlebnisse mit bestimm-ten 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 an-gepasst 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.

Angelika KunzUSECON GmbH1110 WienModecenterstraße 17/Objekt [email protected]

Ulrike GruberUSECON GmbH1110 WienModecenterstraße 17/Objekt [email protected]

Markus MurtingerUSECON GmbH1110 WienModecenterstraße 17/Objekt [email protected]

Manfred TscheligiUSECON GmbH1110 WienModecenterstraße 17/Objekt [email protected]

194


User Research

Benutzer durch konkrete Aufgabenstel-lungen in bestimmte Erlebnissituationen gebracht werden und so das Erleben dieser Situation erhoben wird.

Ziel von Experience Studien ist es, das Erleben und Verhalten von Benutzern zu analysieren und in die Neu- oder Weiter-entwicklung von Produkten und Services einfließen zu lassen.

2.2. Vorteile von Experience Tagebüchern

Im Vergleich zu anderen Erhebungsmetho-den zeichnen sich Experience Tagebücher durch die folgenden Eigenschaften aus: – Keine Einschränkungen. Im Vergleich zu herkömmlichen Online Befragun-gen ermöglichen Experience Tagebü-cher den Benutzern ihr Erleben und Verhalten zu teilen, ohne dabei durch Antwortoptionen oder konkrete Frage-stellungen eingeschränkt zu sein.

– Realitätsnähe. Im Vergleich zu Erhe-bungsmethoden die im Labor stattfin-den, 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 Fragebo-gen oder einen Anruf warten um seine Erfahrungen zu teilen.

– Bildsprache. Durch die über den Zeit-raum der Studie gesammelten Arte-fakte (Fotos, Videos, Dokumente, etc.) erhält man einen noch klareren Einblick in die Erlebniswelt der Benutzer.

– Ereignisbezogen. Der Studienleiter kann durch Aufgaben bewusst Erleb-nisse steuern, die Methode liefert jedoch auch Aufschluss über Ereig-nisse die nicht durch das Studien-design vorgegeben werden.

3. Einsatz von Experience Tagebüchern

Experience Tagebücher eignen sich für den Einsatz in verschiedensten User

Experience Studien. Grundvoraussetzung ist, dass ein ausgewählter Personenkreis über einen vordefinierten Zeitraum hinweg offen seine Erfahrungen teilt.

Für valide und aussagekräftige Ergebnisse muss Wert auf das Studiendesign gelegt werden und folgende Fragen vorab genau geklärt werden: a) Zieldefinitionb) Zielgruppe c) Dauer der Feldzeitd) Erhebung und Kommunikatione) Erhebungsmedium

3.1. Zieldefinition

Das A und O einer erfolgreichen Tage-buchstudie ist die Definition von Ziel und Verwendungszweck. Ist erst klar, wofür die Ergebnisse verwendet werden und welche Art von Informationen aus der Tagebuch-studie gewonnen werden sollen, ergeben sich bereits viele der folgenden Entschei-dungen 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 wer-den, denn die Aussagekraft der Ergebnisse wird maßgeblich von der Zusammenset-zung der Teilnehmer beeinflusst.

Essentiell ist, dass sowohl das Erhebungs-medium als auch die gesamte Kommuni-kation 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 Tage-buchstudie 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 Bedin-gungen innerhalb einer Studie berücksich-tigt werden, ist es wichtig eine Stichpro-bengröß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 poten-ziellen Gefahren, wie zum Beispiel eine erhöhte Dropout Quote. Diese kann jedoch beeinflusst werden, indem Incen-tivierung und Ausfüllfrequenz an die Dauer der Studie angepasst werden. So ist es bei länger angelegten Tagebucherhebun-gen 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 personenbezo-gen 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 Tagebuchein-träge entweder ereignisbezogen oder zeit-bezogen 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 Dokumen-tation von Ereignissen deren Auftreten und Frequenz nicht vorhersagbar und kontrol-lierbar sind, wie z.B. die Dokumentation von Problemen im Umgang mit einem Produkt.

Da das Ereignis der Auslöser des Eintrags ist, besteht der große Vorteil dieser Erhe-bungsart darin, dass das Ereignis zeitnah und ohne Verfälschung durch die Erinne-rung 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 auf-recht 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 sei-tens 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 informie-ren. Indem die Teilnehmer die Anforderun-gen kennen, lassen sich falsche Erwartun-gen 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 Erhe-bungstechnik. 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. unter-wegs, abends im Bett oder bei der Arbeit außerhalb des Büros. Für ein einfacheres Sammeln von Artefakten werden Papier-Tagebü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 Ergeb-nisse schon während der Erhebung ausge-wertet 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, Teil-nehmer und Zeitpunkt des Eintrags sind schnell ersichtlich, in der Auswertung müs-sen 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 Nach-richt beschränkt sind, kann diese Methode zu einer reduzierten Informationsweiter-gabe durch die Teilnehmer führen.

Es gibt auch eigene Tools die speziell für die Durchführung von Online Tagebuch-studien 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

196

eine Gruppenmeinung gibt, aber auch zur gegenseitigen Unterstützung der Teilneh-mer dient. Für Fragen kann ein eigener FAQ-Bereich oder ein Online Kontaktfor-mular 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ön-nen vielfältigen praktischen Nutzen haben. Sie liefern einen entscheidenden Beitrag zum Kundenverständnis und zeigen in wei-terer 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

Entwicklung zusätzlicher Services, die Wei-terentwicklung von bestehenden Produk-ten 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.

Im Rahmen einer großangelegten Studie eines Telekommunikationsanbieters wurde die Nutzung von Smart TV im Alltag unter-sucht. 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ätz-lich 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 wer-den, 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 aufge-zeigt. Ein Praxisbeispiel für eine Tagebuch-studie mit dem Ziel eine Customer Journey abzubilden stammt aus dem Finanzbereich. Im Rahmen der Studie „Kunde werden“ haben Neukunden verschiedenster


User Research

Abb. 1. Beispiel USECON Experience Tagebuch in Form eines Forums

197

Bankinstitute ihre Erfahrungen von der Vorinformation über die Kontobedingung, über die Kontoeröffnung bis zur ersten Ver-wendung dokumentiert. Die 15 Teilnehmer füllten ein Online-Tagebuch ereignisbezo-gen ü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 Nut-zer, die mit konkreten Eigenschaften ver-sehen werden und spezifische Verhaltens-weisen dem Produkt gegenüber abbilden. Personas werden auf Basis von tatsächli-chen Nutzungsverhalten erstellt, sind aber fiktive Personen. Sie werden verwendet um Produkte und Services anhand der Nutzer-bedürfnisse zu entwickeln. [Abb. 3]

Ein Beispiel für eine solche Studie stammt aus dem Bereich der Automation. Über

einen Zeitraum von 2 Wochen führten die Servicetechniker täglich bei Wartungsarbei-ten von bestimmten Automaten ein Tage-buch. 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 Ergeb-

nisse verwendet werden und welche Art von Ergebnissen soll die Studie bringen? Aufbauend auf die Beant-wortung dieser Fragen ergibt sich das Studiendesign.

2. Auswahl der Teilnehmer. Wer ist die ideale und bestmöglich erreich-bare 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 schnel-lere und einfachere Auswertung als Papier-Tagebücher.

4. Erhebungsmix. Sollen Experience Tage-bücher mit anderen Methoden kombi niert werden? Eine Vernetzung mit anderen Erhebungsformen (z.B. UsabilityTest, Befragung) bringt oft noch tiefergehende Ergebnisse zu bestimmten Fragestellungen.

5. Ausfüllfrequenz. Wie viele Einträge der Teilnehmer sind sinnvoll? Zu viele Einträge können überfordern und zu Dropouts führen, mit zu wenig Aktivität besteht die Gefahr in Vergessenheit zu geraten. Ausfüllen ein- bis zweimal pro Woche ist in der Regel ein guter Rhythmus.

Abb. 2. Beispiel für eine Custo-mer Journey. Sie zeigt den Prozess Kunde zu werden und ein Konto zu eröffnen bis hin zur Verwendung mit allen Pain und Pleasure Points

198

6. Kommunikationsplanung. Wie soll die Kommunikation mit den Teilnehmern aussehen? Die gesamte Kommunikation (Wording, Umfang, etc.) sollte an die Zielgruppe angepasst und die Anforde-rungen transparent kommuniziert wer-den. Es sollten regelmäßig und anlass-bezogen 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 Aufwands-entschädigung statt? Incentives nicht

nur am Ende sondern auch mehrfach bereits während der Studie einsetzen.

9. Teilnehmerdokumentation. Wie behalte ich die Teilnehmer im Über-blick? Häufig keit, Ausmaß und Zeit-punkt der Teilnehmeraktivitäten sollte festgehalten werden.

10. Weiterführende Analysen. Wie können die Ergebnisse weiter verwendet wer-den? Vorab die weitere Verwendung der Tagebuchergebnisse wie Customer Journeys oder Persona Erstellung pla-nen, um alle dafür relevanten Informati-onen zu sammeln.

6. Fazit und Diskussion

Experience Tagebücher sind eine vielfältig einsetzbare Methode, die das Erleben und Verhalten von Benutzern im Alltag erfasst.

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 Service-entwicklung 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 Anwendungsfel-der 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 Teilneh-mer Innovationen abzuleiten.

Einige Unternehmen werden nicht Res-sourcen in die Durchführung von Tage-buchstudien investieren wollen, da sie länger dauern und aufwändiger sind als andere Erhebungsmethoden.

Auch dürfte es bei manchen Zielgrup-pen 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.

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

item development: An empirical approach.

Value in Health, 14.

5. http://www.linux-magazin.de/NEWS/

Bitkom-Smartphone-Durchdringung-steigend


User Research

Abb. 3. Beispiel für eine Persona-Darstellung mit Bild, den wich-tigsten Eckdaten und einer Beschreibung der wichtigsten Informatio-nen und Hintergründe zur Persona.

199

Keywords: /// Lean Startup/// Agile Development/// User Experience Research/// Interaction Design/// Vorgehensmodelle

1. Lean Startup

Die Lean Startup Methode hat spätestens seit Erscheinen des Buches „The Lean Startup“ von Eric Ries (2011a) auch außer-halb der Startup-Szene an Bekanntheit gewonnen. Die darin beschriebene Lean Startup Methode bricht teilweise deutlich mit klassischen Methoden zur Unterneh-mensgründung und stellt beispielsweise Experimentieren vor Planen, Kundenfeed-back vor Intuition und iteratives Vorgehen über die vollständige Entwicklung eines (vermeintlich) perfekten Produktes.

Doch trotz dieser teils drastisch verän-derten Sicht auf die Entwicklung eines tragfähigen Business Models integrieren Business Schools weltweit diese Methodik in ihren Lehrplan. Auch größere Unterneh-men beginnen die Vorteile dieser Methode

zu entdecken und für sich zu nutzen und die Startup-Szene ist dabei immer neue Tools und Vorgehensweisen zu entde-cken, 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 Vor-reiter 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 ins-besondere „The Lean Series“ von O'Reilly Media), werden wir uns im weiteren Verlauf dieses Abschnitts vor allem auf diejenigen Aspekte konzentrieren, die in der Pro-duktentwicklung im Kontext eines „Nicht-Startups“ Verwendung finden können.

1.1. Hypothesenbasiertes Arbeiten

Einer der wichtigsten Aspekte der Lean Startup Methode ist das schnelle Lernen durch Kundenfeedback. Eine Grundvor-aussetzung 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 unbe-legte 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

Sascha MahlkeUSEEDS° GmbHFriedrichstrasse 20910969 [email protected]

Lars Gieremobile.international GmbH Marktplatz 114532 Europarc Dreilinden

Sylvia Kleine Hörstkampmobile.international GmbHMarktplatz 114532 Europarc Dreilinden

Sebastian HoosUSEEDS° GmbHFriedrichstrasse 20910969 Berlin

Sirin CepkenliUSEEDS° GmbHFriedrichstrasse 20910969 Berlin

AbstractProduktentwicklungsprozesse haben sich in den letzten Jahren insbesondere im Soft-ware- 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 Her-ausforderungen 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 Koopera-tion mit den Nutzern und in kürzester Zeit Produktideen entwickelt. Aus den Ergebnis-sen lassen sich diverse Hinweise auf Best Practices zum Team Setup, den eingesetzten Methoden und zum Projektablauf ableiten.

Lean Experiments Die Rolle von Interaction Design und User Experience Research im Ansatz Lean Startup

200


User Research

darzustellen und hierdurch die zugrundelie-genden Hypothesen leichter zu erkennen.

Da viele der dort vorhandenen Rubriken bei der Weiterentwicklung eines bestehen-den Produktes innerhalb eines gewach-senen Unternehmens bereits feststehen wurden hieraus abgeleitet bereits alter-native, besser für die uns interessierende Situation passende Modelle entwickelt wie z.B. das Product Canvas [Abb. 1] von Roman Pichler (Pichler, 2012).

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 fi nden, um die Hypothese mit den vorhandenen Mitteln möglichst kos-tengünstig zu verifi zieren bzw. falsifi zieren.

1.2.Iteratives Vorgehen

Ein Grundstein von Lean Startup ist der sogenannte „Build, Measure, Learn“ Zyklus. [Abb. 2] Dieser beschreibt eine ite-rative Vorgehensweise in kurzen Zyklen bei der Entwicklung eines neuen Produktes.

1.2.1. Build

Sind die zugrundeliegenden Hypothesen hinreichend bestätigt oder ist die beste Form der Validierung der offenen Hypo-thesen die Erstellung eines sogenannten „Minimum Viable Products“ (also das mini-mal funktionsfähige Produkt) oder eines Prototypen, so kann mit der Erstellung des Produktes gestartet werden.

1.2.2. Measure

Bereits vor der Erstellung (Build) des Pro-duktes sollten die Zielmetriken und die gewünschten Ziele defi niert sein. Ein guter Startpunkt zur Defi nition 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, Weiterempfeh-lung, Geldwerte Aktion). Nach dem Launch des neuen Produktes sollten die gesetzten Zielmetriken beobachtet und ausgewertet werden.

1.2.3. Learn

Im Anschluss an die Auswertung der defi -nierten Metriken nach Launch des Produk-tes sollten hieraus Schlussfolgerungen für die weitere Produktentwicklung gezogen werden. Hieraus entstehen häufi g neue Hypothesen, die wiederum validiert wer-den müssen. Hierauf basiert schließlich die Erstellung des nächsten Produktinkre-ments. Somit startet der „Build, Measure,

Abb. 1. Product Canvas aus Picheler (2012)

Abb. 2. „Build, Measure, Learn“ Zyklus aus Ries (2011a).

201

Learn“ Zyklus von Neuem. Diese Vorge-hensweise wird häufig auch als „Validated Learning“ bezeichnet.

Wichtige Prinzipien bei dieser Arbeitsweise basieren auch auf dem agilen Manifest, welches hier unkommentiert wiedergege-ben 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ägends-ten 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 Heruas-forderungen 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 unter-schiedlich eingesetzt werden. In einem „reinen“ Startup kann die gesamte Organi-sation 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

von Ansätzen aus Lean Startup für diese konkreten Projekte zu ermöglichen.

Ein Beispiel sind sogenannte „Inkuba-toren“ 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 Produk-tideen 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 Nord-strom 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 Pro-duct“ repräsentiert.

Wir nennen solche experimentellen Projekte innerhalb von größeren Orga-nisationen, 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 Folgen-den 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 entsprechen-den 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 effizientes-ten 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 Fra-gen 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 verbrach-ten wir im Wohnmobil und werteten die

202

Interviews aus. Mittels Storytelling konden-sierten 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 beisam-men 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 Ergeb-nissen der Interviews vor Augen sprühten wir nur so vor Ideen und die Wände waren schnell mit Post-Its gepflastert. Priorisie-rung 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 ausge-wä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 hervor-gebracht 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 Axure-Prototyp fertiggestellt.

3.4. Tag 3

Mit dem ersten Schluck Kaffee am Früh-stückstisch beginnen wieder die Gedanken und Gespräche um den Prototypen zu kreisen. Alle wollten dessen Entwicklung an diesem Tag möglichst weit voranzutrei-ben. Wir teilten uns wieder in zwei Teams auf, jedoch dieses Mal, um denselben Aus-gangsprototyp zu testen. Durch die beiden unabhängig arbeitenden Teams erhofften wir uns mehr und differenzierteres Feed-back 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 Ergeb-nisse auf der Fahrt zurück zusammenge-fasst 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, son-dern 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änd-ler einholen. Mittlerweile geübt und einge-spielt gingen die Teams los und feilten an den letzten Ecken des Prototyps. Gegen Nachmittag kamen wir wieder zusammen, evaluierten die Ergebnisse und aktulisier-ten 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 Produk-tidee 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.


User Research

203

– Noch stärkeren Fokus auf das Validieren zugrundeliegender Hypothesen legen.

– Mehr strukturierende Diskussions- und 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 „Lean-Sprints“ trennen. Für die Ideenfindung und das Scribbeln war der Stress der Arbeitssituation eher hinderlich.

Für Interaction Designer und User Experi-ence Researcher ergeben sich für Arbei-ten in einem solchen Kontext vor allem folgende Anforderungen: – Gewohnte Methoden schneller durchführen.

– Interaktions-Konzepte und Research-Vorbereitungen eher anwenden als perfekt auszudefinieren.

– Geschwindigkeit gewinnen, indem andere Disziplinen bei der eigenen Arbeit mit einbezogen werden.

Die hohe Geschwindigkeit der Weiter-ent wicklung innerhalb der Lean Startup Me tho de benötigt also vor allem sehr schlanke und direkte User Experience Re search Methoden, um nicht zu einer Verlangsamung des Lernzyklus zu führen („Rapid Experimentation“). Hierfür gibt es mittlerweile eine Vielzahl an Methoden, welche in dem Buch „Lean UX“ (Seiden & Gothel, 2012) gut in den Kontext von Lean Startup gestellt werden. Zudem geht das Buch noch tiefer auf die neue Rolle von User Experience bei Lean Startup und agiler Entwicklung ein und beleuchtet noch zusätzlich Aspekte.

Literatur1. 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/.

8. Ries, E. (2011a). The Lean Startup. Penguin.

9. Ries, E. (2011b). Case Study: The

Nordstrom Innovation Lab. http://www.

startuplessonslearned.com/2011/10/case-

study-nordstrom-innovation-lab.html.

10. Seiden, J. & Gothelf, J. (2012). Lean UX.

O'Reilly Media.

204


User Research

205

206

UX Integration

207

Lucie Grudnoadidas [email protected]

Leo Glomannadidas [email protected]

Keywords: /// Inhouse Usability Engineering/// Rahmenwerk/// HCD/// Etablieren/// Nachhaltigkeit

AbstractAuf 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 Herausfor-derung ist es, diese standardisierte Herangehensweise so flexibel an die Projektgege-benheiten 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.

Es mag daher überraschend sein, dass bei der Entwicklung von interaktiven Produk-ten lange Zeit nicht oder nur durch Zufall Mensch-zentriert vorgegangen wurde. User Requirements, abgegrenzt von z.B. Business Requirements, wurden nicht erho-ben. 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 IT-Entwicklungsprozessen 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, -kon-zeption, -gestaltung und -vermarktung. Die interaktiven Produkte, wie z.B. Anwendun-gen 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. Wei-tere Rollen im Unternehmen beschäftigen sich mit dem Thema Usability und sind

Der Hintergrund

Die adidas Group besteht aus verschiede-nen Untermarken, u.a. adidas, Reebok und Taylormade-adidas Golf. Es werden Sport-artikel 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

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 Fol-genden 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 Human-Centered 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

Einführung von Human- Centered Design bei der adidas AGEin Praxisbericht

208


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 folgender-maß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), „evalu-ate design solutions“ (Evaluation der Implementierung)

– Nutzungsphase: „evaluate design solutions“ (Evaluation der Implemen-tierung nach Veröffentlichung)

Dabei wird insgesamt iterativ vorgegan-gen, so wird, falls nötig, etwa von der Evaluierung in der Entwicklungsphase zurückgegangen zur Spezifi zierung 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-Entwick-lungsmodell bei der adidas Group

Abb. 2. HCD-Aktivitäten im agi-len Entwicklungsmodell bei der adidas Group

209

Projektstand unterscheidet sich die Aus-wahl und Durchführung der Methoden. [Abb. 3]

Das Rahmenwerk umfasst also ein gene risches sowie ein projektspezifi sches Vorgehen:

Generisch: – Alle Projekte müssen gemäß den Human-Centered Design Prinzipien vorgehen

– Alle Projekte müssen die HCD-Aktivi-täten in den Entwicklungsprozess einbinden

Projektspezifi sch: – Die passenden Usability Engineering-

Methoden pro Aktivität werden individuell ausgewählt und durchgeführt

Wir als Usability Engineering-Team etablie-ren 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-Akti-vitäten in die Projekte integriert werden können (generischer Ansatz) und welche Usability Engineering-Methoden sich eignen (projektspezifi scher Ansatz). Die Beratung ist der Hauptbestandteil unserer Arbeit. Entsprechend der Erfahrungen aus der Beratung entwickeln wir das Rahmen-werk weiter. Die Beratung umfasst auch die Betreuung und Kontrolle der Ausführung der Methoden sowie die Vermittlung und

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.

Abb. 3. HCD-Aktivitäten im Wasserfall-Entwicklungsmodell bei der adidas Group, mit entsprechenden Aktivitätsbeschrei-bungen und Usability Engineering Methoden

210

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 verpfl ich-tend erklärt.

Die Einführung des Rahmenwerks haben wir im Rahmen einer Abteilungsvollversamm-lung 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 Projekt-beteiligten zu einer großartigen User Expe-rience beitragen: Business Analysten, die Nutzeranforderungen aufnehmen und den Kontext analysieren, Projektleiter, die HCD in die Planung einbauen, Technische Archi-tekten, die Technologien entsprechend der Nutzergruppen bestimmen, etc. [Abb. 5]

Die Kommunikation des verpfl ichtenden 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 einzel-nen Projekt- und Programmleitern das Rahmenwerk in Einzelgesprächen bespro-chen und die individuelle Anpassung des Rahmenwerks erörtert.

Im Zuge dieser Gespräche wurde klar, dass wir bei an Konsumenten gerichteten Pro-dukten das Rahmenwerk nicht auf die glei-che 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 Pro-jekte individuell abdecken zu können

– Eine unterhaltsame Kommunikationsstra -tegie macht auf das Thema neugierig

Zusammenarbeit zwischen den Abteilungen

Da unser Team in der IT-Organisation der adidas Group verankert ist, ist eine Zusam-menarbeit zwischen der IT und den Fachab-teilungen Grundvoraussetzung für das Vor-haben, HCD in den Projekten zu etablieren. Wir mussten feststellen, dass es im Bereich der interaktiven Produkte für Konsumenten politisch schwierig ist, den Ansatz verpfl ich-tend einzuführen. Die Fachabteilungen sieht die Konzeption bei Agenturen. Die IT wird erst zu einem späteren Zeitpunkt eingeschaltet. Eine Beeinfl ussung der Ana-lyse, Spezifi kation der Anforderungen sowie der Designs im multidisziplinären Team ist noch nicht möglich. Bei den konsumenten-gerichteten Produkten können wir in vielen Fällen zunächst nur durch Evaluation der produzierten Lösungen Einfl uss nehmen. Dies war in der Vergangenheit ein „Tür-öffner“, um im weiteren Verlauf oder bei weiteren Projekten ein Mensch-zentriertes

Vorgehen von den Dienstleistern und Agen-turen zu verlangen, um qualitativ bessere Lösungen zu erhalten.

Bei Anwendungen, die für Mitarbeiter oder B2B entwickelt werden, ist die IT meistens von Anfang an involviert. Hier ist es für IT-Projektleiter 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.


UX Integration

Abb. 4. Poster zur Einführung des HCD-Rahmenwerks – Teaser

Abb. 5. Poster zur Einführung des HCD-Rahmenwerks – Aufl ösung

211

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

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 angekom-men. In der Weiterentwicklung haben wir uns wieder auf die Grundlagen des ISO 9241–210 „zurückbesonnen“ und

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. Proto-typenerstellung 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 zusammenarbei-tet, 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ängli-cher 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 Nut-zer 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.

Ein großer Vorteil, den Projektleiter wahr-genommen haben, ist die Verwendung von Prototypen (Wireframes sowie Visual Proto-types), 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 Implemen-tierungen wurde auch sehr positiv von den Projektteams aufgefasst, da so viele Usability-Probleme frühzeitig aufgedeckt und beseitigt werden konnten.

Abb. 3. Rahmenwerk vor der Überarbeitung – unpraktisch und komplex

212

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 eta-blieren 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. Gleich-zeitig 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 indivi-duellen 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 verant-wortlich. 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 Bera-tung und der Ausführung von Methoden


UX Integration

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

„Konkurrenz“ mit anderen Ansätzen

Es ist eine Aufgabe, andere Rahmen-werke oder Ansätze wie Design Thinking mit unserem Rahmenwerk zu verknüpfen und nicht in Konkurrenz treten zu lassen. Die Kommunikation von externen Trai-ningsangeboten, 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 Inte-resse 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-Rahmen-werks konnten wir Veränderungen hin zu einem Mensch-zentrierten Vorgehen bewir-ken. In den an Mitarbeiter gerichteten Pro-jekten ist eine solche Veränderung schon

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 Produk-ten setzen wir wo immer möglich an, HCD-Aktivitä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 Manage-ment, die Motivation, eine hohe Qualität der Produkte anzustreben, ein klarer, gene rischer Ansatz, sowie eine individuelle Beratung der Projekte. Durch erfolgreiche Beispiele und erlebte, Mensch-zentrierte Herangehensweisen wird HCD nachhaltig etabliert.

213

Einleitung

Von einer Idee bis zum fertigen Produkt ist es ein langer Weg. Um das Produktziel zu erreichen, werden in der Softwareentwick-lung 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-Dokumenta-tion sowohl in der klassischen Softwareent-wicklung 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 Herstel-lers. Sie beschreiben ein grundsätzli-ches 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 User-Interface-Elementen, abhängig von der eingesetzten Technologie “ (Richter & Flückiger 2010).

Die Benutzung des Styleguides für Software-Entwickler optimieren Herausforderungen und Perspektiven

Die Vorteile liegen in der klaren Festle-gung auf ein Grunddesign für ein Produkt bzw. ganze Produktreihen. Vorab defi-nierte Farben, Formen, Anordnungen und Größen sollen nachträgliche Aus-einandersetzungen über das grafische Design reduzieren. Dem Entwickler werden konsistente Designvorlagen für Funktionen und Designprobleme vorgeschlagen (Icon-storm 2010) und die Kunden bzw. Usabi-lity-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:

– 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 Software-Entwicklungsprozesses 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 Style-guides können zwei größere Problemati-ken den Vorzügen gegenübergestellt wer-den. Zum einen können Prozessprobleme und zum anderen Umsetzungsprobleme festgestellt werden. Fehler! Verweisquelle konnte nicht gefunden werden. soll ver-deutlichen, dass Prozess- und Umsetzungs-probleme 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 Anforde-rungen der Software angepasst. Die

Keywords: /// Styleguide/// Agiles Projektmanagement/// Dokumentation

AbstractDer 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 über-einstimmt. Doch wieso werden die Richtlinien aus dem Styleguide nicht übernommen? Eine genaue Problembetrachtung zeigt, dass der Styleguide ebenso wie der Software-Entwicklungsprozess 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.

Maria RauschenbergerMSP Medien Systempartner GmbH & Co. KGPeterstraße 28–3426121 [email protected]

Heike SinningHochschule Emden/LeerConstantiaplatz 426723 [email protected]


214


UX Integration

Prozessprobleme entstehen durch die sich im Entwicklungsprozess ändernden Anfor-derungen an eine Software. Besonders bei der Neuentwicklung von Produkten sind in der Anfangsphase nicht alle Funktio-nen 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 Unter-nehmens mehrere Styleguides zu verschie-denen Projekten, Produkten oder Berei-chen erstellt werden müssen, die sich nicht widersprechen sollten. „Beispiele für diese typischen Probleme sind die Schwierigkeit,

relevante Informationen innerhalb des umfangreichen Materials aufzufi nden 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 Prozesspro-blem verhindert zusätzlich zum Auffi nden eine schnelle Akzeptanz und Verbindlich-keit des Styleguides und verstärkt überdies das Umsetzungsproblem.

Schubert et al. (Schubert et al. 2010) beschreiben, dass der Erfolg eines Style-guides abhängig ist von der inhaltlichen Qualität, der organisatorischen Veranke-rung in dem Entwicklungsprozess und der Sensibilität der Software-Entwicklers für konsistente Gestaltung der Oberfl ächen. Die Kommunikation des Styleguides an

das Projektteam ist so auszurichten, dass die hohe Bedeutung des Styleguides vom Projektteam anerkannt wird. „Die beson-dere Herausforderung an eine erfolgreiche Kommunikation und Dokumentation liegt darin, trotz unterschiedlicher Fachspra-chen, Perspektiven und Dokumentations-stilen, geeignete Werkzeuge zu wählen und ein gemeinsames Verständnis zu erzeugen“ (Herdle et al. 2010). Buxton (Buxton 2010) bestätigt, dass die Kom-munikation unter den Projektbeteiligten wichtig ist, um ein Design erfolgreich umzusetzen.

Beim Umsetzungsproblem geht es um die Akzeptanz des Styleguides bei den Projektteilnehmern, besonders bei den Software-Entwicklern. Das Umsetzungspro-blem gestaltet sich deutlich diffuser als das Prozessproblem. Die dokumentenbasierte Ablage und damit statische Form des Styleguides ist für eine einfache Weiter-entwicklung ungeeignet. Dieses oftmals starre Vorgehen ähnelt dem eines Pfl ich-tenhefts, welches ebenfalls am Anfang eines Projektes festgelegt wird. In beiden Dokumententypen sind größere Ände-rungen nur mit hohem Aufwand möglich und entsprechen nicht dem Projektalltag in kleineren IT-Abteilungen. Während die dokumentengetriebene Softwareentwick-lung (mittels Pfl ichten- und Lastenheften) immer mehr von agilen Prozessmodellen (Scrum, Kanban) abgelöst wird (vgl. Begel & Nagappan 2007, Salo & Abrahamsson 2008), fi ndet man bei den Styleguides weiterhin die eher statische Dokumentati-onsform vor. Um den Styleguide aktuell zu halten, kann es von Vorteil sein, wenn die laufenden Änderungen durch einen dyna-mischen (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 Designstra-tegie 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

Abb. 1. Abhängigkeit der Prozess- und Umsetzungsprobleme

215

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 Sty-leguide mit guten Beispielen und Hilfsmit-teln 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än-gigen 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 Unternehmens-Styleguide 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 ver-schiedener UI Designer) oder von Produk-ten für den Endkunden sicher“ (Richter & Flückiger 2010).

2. Ideen, wie ein Styleguide vom Projektteam genutzt werden kann

Nachdem die Erwartungen an den Sty-leguide nicht mit der praktischen Erfah-rung 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

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 Style-guides meist als Dokument auf Laufwer-ken, im Intranet oder in Wiki-Systemen abgelegt. Dieser dezentrale und von den Arbeitswerkzeugen des Entwicklers abge-grenzte Ablageort unterbricht den Arbeits-fluss 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 emp-fohlen, „lieber eine Vorlage statt einem Beispiel“ (Iconstorm 2010) abzubilden. Darüber hinaus sind die Vorlagen an einer zentralen und kommunizierten Stelle abzu-legen, um die Auffindbarkeit zu verbes-sern. „Oft ist Mitarbeitern, die neue Doku-mente 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 Über-sichtlichkeit verhindern.

Die Größe des Entwicklerteams kann ein Problem darstellen. Es erfordert meist mehrere Abstimmungsmeetings, wenn alle Anforderungen eines Projektes in das Pro-jektteam 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 Stylegui-des müssen diese Abstimmungsrunden häufiger durchlaufen werden. „Nur wenn die Teamgröße auf die genannte Mitar-beiterzahl [5–8] beschränkt wird, ist ein vollständiger Informationsaustausch mög-lich. Er erlaubt es, dass ein Projektteam mit einem geringen Verwaltungsaufwand arbeiten kann und den direkten Kontakt

Schubert et al. (Schubert et al. 2010) erläu-tern, ist eine zugeordnete Verantwortlich-keit für das Erstellen und Kommunizieren des Styleguides relevant für den erfolgrei-chen Einsatz. Der Verantwortliche kümmert sich darum, dass der Styleguide kommuni-ziert 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 aktu-ellsten Absprachen enthalten und damit ist eine schnelle und einfache Änderung im Styleguide erforderlich. Dies wird auch von Herdle et al. (Herdle et al. 2010) und (Schrammel et al. 2010) unterstützt.

Der initiale Styleguide gilt damit als Grund lage für Erweiterungen und die Entwickler sind verpflichtet, den Style-guide-Verantwortlichen auf bisher nicht festgehaltene Regelungen aufmerksam zu machen. Der Verantwortliche kümmert sich dann wie derum um das Festlegen der neuen Richtlinien und die Kommunikation ins Projektteam. Dieses Verfahren orientiert sich maßgeblich an dem agilen Prozess-gedanken 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 Veran-kerung des Styleguides in den Entwick-lungsprozess“ und die „Sensibilität der Entwickler für ansprechende und konsis-tente Gestaltung“ wichtige Erfolgsfaktoren für den Styleguide sind.

Der Wirkungskreis des zukünftigen Sty-leguides 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 Rahmenbe-dingungen, welche sie auf die Anforde-rungen des Styleguides (Benutzergruppe,

216

Produktvielfalt, Anzahl der Produkte,…) auswirkt. Dieser Ansatz bezieht sich im Gegensatz zu Schrammel auf mittelständi-sche Unternehmen.

Im Unternehmen sollte eindeutig festge-legt werden, wo die Styleguides von den Projektteilnehmern, für jeden Kunden, jedes Projekt oder andere Bereiche zu fi nden 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 Confl u-ence von Atlassian Software Systems als Enterprise Wiki hervorragend die Anforde-rungen an einen dynamischen Styleguide regelt. Damit ist allerdings nicht die Prob-lematik 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 Entwick-lungsumgebung vor.

Ein österreichisches Technologieunter-nehmen hat seinen Styleguide „mit dem Einsatz eines strukturierten Authoring-Prozesses basierend auf DITA-Maps“ konstruiert (Schrammel et al. 2010). Damit bieten sie eine anwenderorientierte Doku-mentation des Styleguides, PDF-Dateien, die Integration in das Hilfesystem von Win-dows und die Integration in eine Entwick-lungsumgebung an. Das von Schrammel et al. (Schrammel et al. 2010) dargestellte System verfügt über eine mächtige Struk-tur, 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ätzli-che 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 Stylegui-des als Framework in seiner Entwicklungs-umgebung 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 Style-guides 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 Icon-storm (Iconstorm 2010) weiter int erpretiert werden und eine Art Microsoft Word Formatvorlage für bestimmte Methoden der Programmierung in die Entwicklungs-umgebung eingegliedert werden. Die Formatvorlage kann dann zum Beispiel für Formulare (Kontakt- und Bestellformulare), Buttons („Weiter“, „Abschicken“), AGBs,


UX Integration

Abb. 2. Bild von Visual Studio mit einer möglichen Darstellung einer Richtlinie aus dem Styleguide

217

bewährt hat, ist ein Zurückkehren zu der vorherigen Version problemlos möglich.

Natürlich ist es auch möglich, eine phy-sikalische 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 Stylegui-des 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 resul-tierenden Medienbruch destruktiv für die Effektivität des Entwicklers und der Projektteilnehmer ist. Es wird deutlich, dass in Anlehnung an den agilen Software-Entwicklungsprozess der Styleguide in der Umsetzungsphase iterativ seine

„rechte Box“ im Webseitenauftritt, Detail-seiten oder Fehlermeldungen gelten. Als Beispiel ist die Fehlermeldung in Abbil-dung 3 dargestellt. [Abb. 3]

Diese Formatvorlagen können die heu-tigen UI-Patterns als Grundlage haben. Sinnvoll ist dab ei eine Auswahl an zum Beispiel zwei UI-Pattern für den Ent-wickler und der zusätzlichen manuellen Änderbarkeit.

Damit wäre ein schnellerer und integrier-ter 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 Grundde-sign mitbringen. Eine Erweiterung durch Customizing der Methoden muss noch geprüft werden.

Der Entwickler sollte an der Weiterent-wicklung des Styleguides beteiligt werden und seine Ideen frühzeitig einbringen. Als weiterer Optimierungsansatz sollte die Versionierung der Artefakte (Styleguide-Dokumente/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

Anforderungen spezifi ziert, welche dann wiederum schnellstmöglich dem Projekt-team zur Verfügung gestellt werden soll-ten. 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 beson-ders die Open-Source Entwicklungsumge-bung Java Sun Eclipse und die kommer-zielle Entwicklungsumgebung Microsoft Visual Studio. Beide Produkte bieten Ansätze für eine Erweiterung mittels Plug-Ins innerhalb der Entwicklungsumgebung.

Weitere langfristige Ziele sind die Erstel-lung eines ersten Prototyps und die Durch-führung eines Probelaufs. Die Vorausset-zung 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ögli-chen Designvorlage für die Fehlermeldung der Anmeldung

Abb. 2. Entwurf einer mögli-chen Designvorlage für die Fehlermeldung der Anmeldung

218


UX Integration

Literatur1. Apple Inc. (2012). Mac OS X Human

Interface Guidelines. online verfügbar

unter http://developer.apple.com/library/

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

in an industrial context: An exploratory study.

In: IEEE Empirical Software Engineering and

Measurement, 255–264.Los Alamitos. IEEE

Computer Society.

3. Bothmer, J. (2011). Tools für die aktive

Markenführung. Dynamischer Styleguide.

Iconstorm – Agentur für Markentechnik

GmbH & Co. KG. Online verfügbar unter:

http://www.style-guide.org/Kategorien/

articles/Dynamischer_Styleguide.html.

Zuletzt geprüft am 30.05.2013.

4. Buxton, Bill (2010). Sketching User

Experiences. Amsterdam: Morgan Kaufmann.

5. Herdle, K., Kurzak, M., Kratzheller, J.

& Bierkandt, J.(2010). Gemeinsames

Verständnis erzeugen bei der

interdisziplinären Gestaltung des neuen

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

Professionals 2010, 108–113. Stuttgart:

German Chapter der Usability Professionals

Association.

6. Iconstorm (2010). Styleguide.

Gestaltungsrichtlinien-Monitor 2010.

Iconstorm – Agentur für Markentechnik

GmbH & Co. KG. Online verfügbar

unter: http://www.iconstorm.de/news/56/

Iconstorm-verffentlicht-Bulletin-11–2010-

zum-Thema-Styleguide. zuletzt geprüft am

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.


2011, 66 -70. Stuttgart: German UPA e.V.

9. Litke, H. (2007). Projektmanagement:

Methoden, Techniken, Verhaltensweisen.

München: Hanser.

10. Ortlieb, W. (2012). Styleguides. Online

verfügbar unter: http://www.se.uni-

hannover.de/pub/File/kurz-und-gut/ss2012-

proseminar-inf-usabiliy/Ortlieb2012.pdf.

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

methods in European embedded software

development organisations. In: Software, IET

2. 58–64.

13. Sarodnick, F. & Brau, H. (2011). Methoden

der Usability Evaluation. Bern: Huber.

14. Schrammel, J., Lugmayr, M., Hämmerle,

F.,Murtinger, M. & Tscheligi, M. (2010).

Flexible und erfolgreiche Implementierung

eines User Interface Styleguides mittels

eines strukturierten Authoring-Konzeptes

basierend auf DITA-Maps. In: Brau, H.

(Hrsg.). Usability Professionals 2010, 141–

145. Stuttgart: German Chapter der Usability

Professionals Association.

15. Schubert, U., Bonhag, W. & Groß, M. (2010).

Einsatz von User Interface Patterns bei der

Entwicklung von Business-Software. In: Brau,

H. (Hrsg.). Usability Professionals 2010, 150 –

156. Stuttgart: German Chapter der Usability

Professionals Association.

16. Seibert, M., Preuss, S. & Rauer, M.

(2011): Enterprise Wikis. Wiesbaden:

Betriebswirtschaftlicher Verlag Gabler.

17. Wilson, C. (2010). Guidance on Style Guides.

online verfügbar unter http://www.stcsig.org/

usability/newsletter/0104-style.html, zuletzt

aktualisiert am 24.10.2010, zuletzt geprüft

am 24.06.2013.

219

Keywords: /// Kanban/// User Experience/// Human Centered Design/// Agile Softwareentwicklung

AbstractDie agile Projektmanagementmethode „Kanban“ zielt auf geringe Durchlaufzeiten ab und richtet damit den Fokus der Entwicklung auf das Moment der aktuellen Aufga-be. 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 Hand-lungsbedarf. 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 priori-siert 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 paral-lel zum Entwicklungssprint verlaufende Konzeptionsphase in gleicher Organisation (Obendorf, Gibbert, Petersen & Memmel 2010), (Sy 2007).

Abgeschlossene Entwicklungszeiträume, wie sie beispielsweise Scrum in Form von

User Experience in KanbanDie UX-Karte ausspielen

Sprints vorsieht, fehlen bei Kanban. Es fin-det eine kontinuierliche Entwicklung statt. Während dieser kontinuierlichen Entwick-lung betrachtet das Teammitglied nur seine eigene Aufgaben-Einheit im jeweiligen Fachgebiet. Eine wiederkehrende Zieldefi-nition über Aufgabengrenzen hinweg findet nicht statt. Somit kann die User Experience (UX) als Ergebnis vieler einzelner Eigen-schaften eines Produkts ohne die Konzep-tion des Gesamtprodukts schwer berück-sichtigt werden.

Kanban ist eine Projektmanagementme-thode, 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 multi-funktionale 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 Kon-zepter, Business-Analysten und Designer erforderlich. Im Vergleich hierzu sind bei

Kanban multifunktionale und funktio nale Teams, bestehend aus Experten, erlaubt (Kniberg & Skarin 2010). Da in vielen Unter-nehmen bereits funktionale Teams vorhan-den sind, ist eine Einführung von Scrum im Hinblick auf die Anpassung der Unter-nehmensorganisation mit mehr Aufwand verbunden als eine Einführung von Kanban.

2. Prozessablauf

Bei Kanban wird zur Visualisierung der Ar beitsaufgaben das sogenannte „ Kanban- Board“ 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 Anord-nung der Spalten muss hierbei mit der Rei-henfolge der Aktivitäten übereinstimmen, die zur korrekten Aufgabenerfüllung führen. Dies richtet sich nach den jeweiligen Prozes-sen 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.

Dominique WinterBuhl Data Service GmbH Am Siebertsweiher 3/557290 [email protected]

Eva-Maria Schön7P Solutions & Consulting AGCalor-Emag-Straße 140878 [email protected]

Jan Uhlenbrokbasecom GmbH & Co. KGHannoversche Straße 6–849084 Osnabrü[email protected]


220


UX Integration

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 Auf-gabe. Wurde in einer Spalte die Bear-beitung der Aufgabe abgeschlossen, so wandert die Karte weiter zur nächsten, bis schließlich die letzte Spalte erreicht wird.

Die Teammitglieder bearbeiten nur Aufga-ben, 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 platzier-ten 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 Kan-ban 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 Pro-zesskette stellt eine der Spalten zwangs-weise einen Engpass dar. Auch in einem Kanban-Board sorgt dieser „Flaschenhals“ dafür, dass nicht mehr Aufgaben weiter-gereicht 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 aufgaben-fremde 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 Managementme-thode Scrum werden weder gemeinsame Planungen noch größere Besprechungen zu inhaltlichen Themen eingeplant. Die Kanban-relevanten Besprechungen (z.B. Teamretrospektive oder Queue Replenish-ment Meeting) fokussieren die Optimie-rung des Prozesses (Leopold & Kaltenecker

2012). Inhaltliche Aspekte des Projektes bleiben dabei außen vor. Auch das tägli-che Standup-Meeting, bei dem grob Auf-gaben 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 Aufga-ben 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 interagie-ren (Poppendieck & Poppendieck 2003).

3. Integration der nutzerzentrierten Gestaltung in Kanban

Zur Integration nutzerzentrierter Gestal-tungsansätze in den Kanban-Prozess

Abb. 1. Beispielhaftes elektroni-sches Kanban-Board

221

von der gemeinschaftlichen Zusammen-arbeit verschiedener Disziplinen (Beck et al. 2001). Diese interdisziplinäre Zusam-menarbeit innerhalb eines Projektes bietet den Vorteil, dass Ideen bereits in frühen Phasen des Softwareentwicklungsprozes-ses von unterschiedlichen Seiten betrach-tet 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 techno-logischer 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 ein-gesetzt werden, um die für eine gute User Experience erforderliche Kommunikation und Zusammenarbeit zu ermöglichen. Die Freiräume bieten Gelegenheit, Silos aufzu-brechen und gemeinschaftlich zu arbeiten. Schließlich führt die gemeinschaftliche Weiterentwicklung der Idee zu einer bes-seren Lösung, die sich positiv auf die User Experience des zu entwickelnden Produk-tes 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 Personadriven 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 Defini-tion der Anforderung darstellt und für die Projektplanung genutzt werden kann. Ein

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 Nor-mung 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üh-ren, bietet es sich an, auch für die letzte Spalte eine Beschränkung einzuführen und beim Erreichen entsprechende UX-Evaluationen vorzunehmen. Die Anzahl der zu sammelnden Aufgaben hängt von der jeweiligen Teamgröße und den Releasezy-klen 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 Evaluati-onen resultieren Verbesserungen, welche als neue Aufgaben im Kanban-Prozess einzuplanen sind. So entsteht ein iterativer Kontrollmechanismus, der langfristig die Einhaltung einer User Experience – Strate-gie ermöglicht und gesetzte Ziele verfolg-bar macht.

3.2. Überwinden von Teamgrenzen

Aufgrund bestehender Unternehmens-strukturen bilden sich in vielen Organi-sationen funktionale „Silos“, die in sich geschlossene Gruppen von Experten beinhalten. Der Nachteil dieser funktiona-len 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

weiterer Teil stellt die Diskussion um die User Story dar, die zu einem besseren Ver-ständnis der eigentlichen Anforderung im Team beiträgt. Der dritte Teil besteht aus den Akzeptanzkriterien. Aus den Akzep-tanzkriterien geht hervor, wann eine User Story abgenommen werden kann. Soge-nannte Persona-driven User Storys (Holt, Winter & Thomaschewski 2012) können verwendet werden, wenn Personas entwi-ckelt wurden. Diese speziellen User Storys stehen in direkter Verbindung mit einer speziellen Persona (Cooper 1999), (Pruitt & Adlin 2006), (Holt, Winter & Thomaschew-ski 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 Ent-wicklern 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 Projektbe-teiligten ein umfassendes Bild vom zu entwickelnden Produkt zu erzeugen (Beyer 2010). Prototypen zeigen kom-plexe Zusammenhänge einzelner Anfor-derungen und verdeutlichen, wie diese im Kontext des Produkts zu verstehen sind. Des Weiteren können komplexe Arbeits-abläufe der Nutzer visualisiert werden. Ein weiterer Vorteil von Prototypen ist, dass bereits vor der Entwicklung Nutzerfeed-back eingeholt werden kann. Es besteht die Möglichkeit, erste Usability-Tests an

222

Prototypen durchzuführen und somit wich-tige 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 (Wein-schenk 2011).

3.5.Erweiterung um weitere KanbanBoards

Eine Integration eines HCD-Prozesses ist innerhalb eines einzelnen Kanban-Boards schwerlich umzusetzen, da dieses häufi g auf die reine Umsetzung der Programmier-tätigkeit und der Abnahme- und Ausliefe-rungstä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 wan-dern dann vom Konzeptionsboard zum Entwicklungsboard und können anschlie-ßend durch ein Administrations- oder Technikteam ausgeliefert werden. [Abb. 2]

Dies ermöglicht auch Engstellen zwischen den Teams aufzudecken, wenn die Reali-sierung 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 teilneh-men, so dass das Entwicklungsteam über zukünftige Aufgaben informiert ist und das Konzeptionsteam aktuelle Probleme der Realisierung kennt. Dies fördert den Aus-tausch 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 Konzeptions-board und Technikboard dargestellt. Nachdem eine Anforderung das Konzep-tionsboard durchlaufen und die Spalte „Done“ erreicht hat, wird diese zu einer oder mehreren Aufgaben im Entwicklungs-board. Sobald die Aufgaben die Spalte „Done“ des Entwicklungsboards erreicht haben, können diese zu einem weiterfüh-renden 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


UX Integration

Abb. 2. Teamübergreifender Kanban-Prozess

Abb. 3. Beispielhafte Kombination mehrerer Kanban-Boards

Konzept Entwicklung Admin/TeTeT chnik

Gemeinsames Daily Standup

Personas &Prototyp Software Betrieb

Arte

fakt

eKa

nban

-Bo

ards

223

Literatur1. 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.,

Grenning, J., Highsmith, J., Hunt, A., Jeffries,

R., Kern, J., Marick, B., Martin, R., Mellor,

S., Schwaber, K., Sutherland, J. & Thomas,

D. (2001). Manifesto for Agile Software

Development.

3. Beyer, H. (2010). User-centered agile

methods, San Francisco, Calif: Morgan &

Claypool.

4. Brown, D. (2012). Agile user experience

design: A practitioner's guide to making

it work, San Francisco, Calif: Morgan

Kaufmann.

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

Ergonomie der Mensch-System-

Interaktion – Teil 210: Prozess zur Gestaltung

gebrauchstauglicher interaktiver Systeme.

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

Softwareprojekten: Die Humanisierung des

Anwenders, In Usability Professionals 2011,

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

Schroeder (Hrsg.), Stuttgart.

13. Holt, E.-M., Winter, D. & Thomaschewski,

J. (2012). Von der Idee zum Prototypen:

Werkzeuge für die agile Welt, In Usability



Stuttgart.

zwischen den Planungen des Konzeptions-boards und der abgeschlossenen Entwick-lung vorgenommen werden muss. Dies dient der Zielkontrolle und sichert eine gerichtete Produktentwicklung.

4. Zusammenfassung

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 konkre-tisiert wird. Ebenso kann eine parallel zum Entwicklungssprint verlaufende Konzep-tionsphase 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 Ent-wicklung eingesetzten Entwicklungsboard verwendet. Der Einsatz eines Konzeptions-boards bietet den Vorteil, dass konzepti-onelle 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 verschie-denen Teams wie beispielsweise Kon-zeption 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.

14. Klein, L. (2013). UX for lean startups: Faster,

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

H., Diefenbach S., Göring K., Peissner M.,

Petrovic K. (Hrsg.): Usability Professionals

2010.

18. Patton, J. (2009). Kanban Development

Oversimplified, http://www.

agileproductdesign.com/blog/2009/

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

lifecycle: Keeping people in mind

throughout product design, Amsterdam

;, Boston: Elsevier; Morgan Kaufmann

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.

(2012). Persona driven agile development:

Build up a vision with personas, sketches and

persona driven user stories. In: Proceedings

of the 7th Conference on Information

Systems and Technologies (CISTI).

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

Stories, 2. Auflage, München: Hanser, Carl.

224

SpezielleDesign anforderungen

225

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 Forschungs-projektes für einen Automobilhersteller erfahren. Inspiriert durch steigende Nut-zungszahlen von SIRI und Google Speech, sollte die Entwicklung eines mobilen, durch Sprache gesteuerten Fahrzeug-Kon-figurators Innovationskraft und Technolo-giestä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, Nut-zerakzeptanz und Optimierungspotenzi-ale hin überprüft werden. Allerdings war schnell klar, dass vor der Überprüfung der

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? Wel-che 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 gestalteri-schen Aspekte sind zu berücksichtigen? Speziell: Wie sieht das optimale Zusam-menspiel zwischen verschiedenen User Interfaces (z.B. GUI und VUI) aus?

– Trifft das Angebot überhaupt ein Nutz-erbedürfnis und/oder eine potenzielle Nutzungssituation? Beziehungsweise: Für welche Usecases bietet sich Sprach-steuerung in besonderer Weise an, für welche gegebenenfalls eher nicht?

– Wann schafft Sprache einen („echten“) Mehrwert, z.B. gegenüber Touch?

Um diese Fragestellungen fundiert zu beantworten, wählten wir ein mehrdimen-sionales Vorgehen: Anhand einer umfas-senden Desk Research wurden zunächst wesentliche (theoretische) Grundlagen für die Konzeption und Gestaltung von Anwendungen, die auf Sprachsteuerung basieren, erarbeitet. Durch eine ergän-zende 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 des-sen der aktuelle Konzeptstand (semi-funk-tionaler 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 durch-gespielt und Optimierungsmöglichkeiten

Keywords: /// Voice Control/// GUI/// VUI/// MUI

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 (Sprach-steuerung). Zudem soll der Nutzer die Anwendung intuitiv in der intendierten Weise bedienen können (und wollen). Dies verlangt bei der Umsetzung die besondere Berück-sichtigung 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?

Sandra SchusterFacit Digital GmbHNeuhauser Straße 1780331 Mü[email protected]

Voice Control um jeden Preis? Theoretische und praktische Grundlagen für erfolgreiche Sprachsteuerungs-Angebote aus User Experience-Sicht

226

identifiziert sowie konkrete Handlungs-empfehlungen für unseren Auftraggeber formuliert.

Der folgende Beitrag skizziert pointiert und beispielhaft einige zentrale Erkennt-nisse aus dem Forschungsprojekt. Nach einer groben thematischen Einordnung und Begriffsklärung, werden relevante Aspekte für die Gestaltung von sprach-gesteuerten (Marketing-) Angeboten aus verschiedenen theoretischen und praktischen Blickwinkeln beleuchtet. Den Abschluss bildet unser (leider wenig opti-mistisches) 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 gra-fische User Interface (GUI) – an möglichst passender Stelle – mit Sprachsteuerung (VUI) zu verbinden. Werden wie in diesem Falle mehrere verschiedene Input-Metho-den (z.B. Touch, Gesten, Sprache, etc.) mit-einander 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 move-ments) in a coordinated manner with multi-media 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 individu-ellen Modalitäten, in unserem Falle: der Sprach-Ein-und Ausgabe sowie der GUI-Ein- und Ausgabe. Dafür gibt es gängiger-weise drei Strategien (vgl. Schnelle-Walke und Döweling, 2011):


Spezielle Designanforderungen

– Substitutionsstrategie. Diese Strategie ist nützlich, wenn eine Modalität eine andere Modalität in einer Anwendung komplett ersetzt, die auf unterschiedli-chen Endgeräten mit unterschiedlichen Eingabe- und Ausgabemöglichkeiten ausgestattet ist (Beispiel: Im Auto; reine Spracheingabe anstelle von manueller Eingabe).

– Redundanzstrategie. Wenn verschie-dene Modalitäten in redundanter Art und Weise genutzt werden und damit letztendlich die gleiche Infor-mation zur gleichen Zeit übermitteln (Beispiel: Telefon: Klingelton und Vibrationsalarm)

– Komplementärstrategie. Gilt als bester Weg zur Umsetzung eines multimoda-len 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 Sprachaus-gabe 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 aus-gewählte Aspekte dieser Standpunkte.

3.1. Was wissen wir über Sprache?

Diese erste Leitfrage betrachtet die beson-deren 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 eindimensio-nal. 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 durch-zufü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 Spra-che lassen bereits erste Ableitungen zu, wenn es darum geht, welche Informationen eher über ein grafisches, und welche eher über ein sprachliches User Interface umge-setzt 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 Textpassa-gen verzichtet und der Fokus der Sprach-ausgabe 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 Fakto-ren der Sprachsteuerung, die aber – im Gegensatz zu den inhärenten Faktoren – beeinflusst werden können. Hierunter zählen vor allem die Qualität der Sprach-synthese, die Performance der Spracher-kennung 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 eingespro-chene 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 Referenzie-rung auf aktuelle Kontexte.

Ein (rein) sprachliches Interface muss demzufolge viele dieser Ausprägungen erkennen und unterstützen. Als gutes Beispiel dient die Datumsangabe: Ein flexi-bles 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).

3.2. Was sagen die (potenziellen) Nutzer?

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

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 interaktions-relevante 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 Untersu-chungen, 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). Einga-bemodalitäten, welche die Lösung einer Aufgabe mit weniger Interaktionsschritten erlaubten, wurden dementsprechend häufiger genutzt. Dies lässt den Umkehr-schluss 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 Inter-aktionsschritten 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 Anwen-dung) möglich ist.

3.3. Was sagen die User InterfaceForscher?

Eng verwoben mit den Anforderungen der (potenziellen) Nutzer, lassen sich auch aus Perspektive der User Interface-Forschung einige Richtlinien für multimodale Anwen-dungen formulieren (vgl. hier und im Fol-genden: Larson und Oviatt, 2004; Schaffer, Schleicher und Möller, 2011).

Zunächst einmal gilt es, multimodale Sys-teme für eine möglichst große Bandbreite an Nutzern und Nutzungskontexten zu schaffen. UI-Designern ist also anzuraten, sich intensiv mit den psychologischen Cha-rakteristika (kognitive Fähigkeiten, Motiva-tion, 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 Notwen-digkeit zur Auswahl der dortig jeweils besten Kombination von Modalitäten. In diesem Zusammenhang werden auch Aspekte der Privatsphäre sowie Sicher-heitsbelange relevant. In Situationen, in denen Nutzer ihre Privatsphäre schützen wollen, sollte ein sprachfreier Modus ange-boten 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 Opti-mierung der Interaktion auf die kognitiven und physischen Fähigkeiten der Nutzer hin. Für UI-Designer gilt es verlässlich her-auszufinden, wie sie intuitive und effiziente Interaktionen schaffen können, welche auf primären menschlichen Wahrnehmungs- und Verarbeitungsfähigkeiten basieren (Aufmerksamkeit, Kurzzeitgedächtnis, Ent-scheidungsfindung) – und damit die kogni-tive Last des Nutzers im Umgang mit dem

228

System bzw. Angebot möglichst gering halten (zum „cognitive load“-Konzept vgl. Wickens, 2002).

In diesem Zusammenhang lassen sich (unter vielen anderen) zum Beispiel fol-gende Empfehlungen formulieren: – Die visuelle Darstellung sollte mit manuellem Input gekoppelt sein, insbesondere für räumliche Informa-tionen und parallele Verarbeitung; Sprachausgabe sollte an die Sprach-eingabe gekoppelt sein, insbeson-dere 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öglich-keiten: 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 ein-fache 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 aus-wählen können, um für die jeweiligen Inhalte/Aufgaben eine weniger fehler-anfä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 Fahrzeug-Konfiguration tat bzw. tut.¹

Die im Gros etablierten sprachgesteuerten Systeme lassen sich grob wie folgt typisie-ren und zugleich chronologisch ordnen: – Automatische Auskunftssysteme (seit 1980): Reine Voice-User-Interfaces zum Beschwerde-Management (Self-ser-vice). 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, Medizi-ner, etc.). Mehrwert: Spracherkennung (inzwischen) teilweise fünfmal schneller als Tippen.

– Sprachsteuerung im Automobil (seit 2010): Multimodale Systeme, die ver-schiedenste Aufgaben übernehmen. Meistgenutzte Funktionen: Telefonge-sprä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): Multimo-dale Interfaces, die von starker Verbrei-tung der Smartphones sowie protegier-ter Technologien (Siri, Google Voice Search) profitieren. Meist genutzte Funktionen: Telefonanrufe tätigen, Textnachrichten eingeben, Voice-Based 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 aktu-eller Benchmark gelten, an dem sich ein mobiler sprachgesteuerter Fahrzeug-Kon-figurator messen lassen muss. Ihr hoher Nutzwert liegt vor allem im Charakteristi-kum der alltäglichen Handlungen, welche mit kurzen, überschaubaren Befehlen angesteuert werden können (Telefonan-ruf, Aufruf einer App, etc.) und schnell zu erlernen sind.

Hier zeigt sich bereits die erste Hürde zum „sinnvollen Usecase“ der Sprach steuerung.

4. Fahrzeug-Konfiguration als sinnvoller Usecase für Sprachsteuerung?

Bei der Fahrzeug-Konfiguration handelt es sich eben nicht um eine alltägliche Handlung, welche vom Nutzer regelmäßig durchgeführt. Allein dieser Umstand impli-ziert 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 Fahrzeug-konfiguration ist zwar klar, dass ein Auto, vermutlich auch das konkrete Modell, kon-figuriert werden soll, Detailausprägungen und einzelne Bestandteile der Konfigura-tion 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 unwahrschein-lich. 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 Konfigura-tion 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 Sprachver-ständnis. Je länger der Sprachbefehl des Nutzers und je natürlicher die Formulie-rung, desto geringer ist die Wahrschein-lichkeit, 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.

Dabei lässt sich das, was hier am Beispiel der Fahrzeug-Konfiguration dekliniert wurde, mühelos auf andere sprachge-steuerte Angebote übertragen und als beschränkende Bedingungen für die Usecase-Definition von Sprachsteuerung

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ög-lichkeiten; 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.

Unserem Auftraggeber konnten wir die Weiterverfolgung des (damaligen) Kon-zeptansatzes nicht empfehlen. Allerdings leistete unsere Arbeit einen grundlegen-den 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.

Literatur 1. Abbott, K.R. (2002): Voice Enabling Web

Applications: VoiceXML and Beyond. a!press,

2. Auflage.

2. Chandler, P. und Sweller, J. (1991). Cognitive

Load Theory and the Format of Instruction.

In: Cognition and Instruction, 8 (4), S.

293–332.

3. Dumas, B., Lalanne D. und Oviatt, Sh. (2009):

Multimodal Interfaces: A Survey of Principles,

Models and Frameworks. In: Human Machine

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.

5. Schaffer, S. (2008): Integration

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

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

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

suche an und nähert sich damit dem Usecase

„Fahrzeug-Konfiguration“ zumindest thema-

tisch an. Diese war zum Projektzeitraum noch

nicht verfügbar. Auch liegen aktuell noch

keine Nutzungsdaten vor. Nach erster Eva-

luation beschränkt sich die App jedoch auf

die initiale Suche bzw. Selektion (Ersteingabe

relevantes Modell, Farbe, Motorisierung,

etc.). Systemrückmeldungen, Bestätigungen

und Modifikationen der Suche werden weiter-

hin über das GUI abgebildet.

230



231

1. Warum die Generation 50plus so wichtig ist

Bei der Gestaltung oder Evaluation von Webseiten wird meist mit dersel-ben Ziel gruppe gearbeitet, die auch beim Marke ting im Vordergrund steht: den 14- bis 49-Jährigen. Die Generation der über-50-Jährigen wird dabei in der Regel ignoriert: sei es, dass Unternehmen Be rührungsängste haben und ungern mit dieser Nutzergruppe in Verbindung gebracht werden möchten, sei es, dass spontane Gestaltungs-Assoziationen wie große Schrift und reduziertes Design als unattraktiv gewertet werden, oder weil man dieser Nutzergruppe unterstellt, ohnehin am liebsten im Geschäft oder telefonisch Kontakt aufzunehmen – ein Fehler ist es in jedem Fall.

Die statistischen Entwicklungen zeigen zweifelsfrei, dass die Generation 50plus in nicht einmal 10 Jahren in den meisten ent-wickelten Märkten der Erde die Hälfte der Bevölkerung (und damit der Konsumenten)

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 Internet-Nutzung (ü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,

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 ziel-fü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 entspre-chend zu berücksichtigen.

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

Keywords: /// Generation 50plus/// Digital Natives/// Webshops/// Usability-Test

Cornelia SchauberYOUSE GmbHAnzinger Straße 481671 Mü[email protected]

Christoph NedopilYOUSE GmbHAnzinger Straße 481671 Mü[email protected]

Sebastian GlendeYOUSE GmbHWinsstraße 6210405 [email protected]

Tina WeisserYOUSE GmbHAnzinger Straße 481671 Mü[email protected]

Christian WedlYOUSE GmbHAnzinger Straße 481671 Mü[email protected]

AbstractDer 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 Ticket-Providern gezeigt, worin die Unterschiede zwischen jüngeren und älteren Internet-Nutzern 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.

232

Auch wenn es sehr starke individuelle Unter-schiede gibt (Gregor et al., 2002), so lässt sich die Generation 50plus doch in zwei-erlei Hinsicht als besondere Nutzergruppe beschreiben: in Bezug auf ihre Internet-Expertise 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. Insbe-sondere denen, die erst im Ruhestand mit der Webnutzung starten, fehlen Ansprech-partner 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 Websei-ten oder deren allgemeiner Grundstruktur unzureichend oder fehlerhaft ist, was wir auch in unserer Studie anhand der ineffek-tiven Problemlösestrategien aufzeigen. Auf der anderen Seite treten auch bei routi-nierten 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. schlech-ter an bereits besuchte Seiten erinnern.

– Die kognitiven Ressourcen sind schnel-ler erschöpft, so dass das explorative Erlernen von neuen Programmen oder Befehlen schwieriger wird.

– Die Vulnerabilität gegenüber ablen-kenden 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. Dop-pelklicks oder das präzise Ansteuern kleiner Buttons erschwert wird.



Um es mit Bernard und Phillips (2000) zu sagen, ist unsere „information society“ gleichzeitig auch eine „ageing society“. Diesem Umstand wird unserer Ansicht nach – auch in der Usability-Branche – noch zu wenig Rechnung getragen. Wel che Konsequenzen das hat, wird im folgenden Abschnitt anhand eines Usability-Tests mit Webshops beschrieben.

2. Usability-Studie: Unterschiede zwischen älteren und jüngeren Webshop-Nutzern

Auch wenn man bei manchen Webseiten argumentieren könnte, dass die Zielgruppe eindeutig jünger als 50 Jahre ist – für Ticketportale gilt dies sicher nicht. Aktuelle Zahlen zur Nutzung von Online-Portalen

Abb. 1. Anteil der Personen, die online Tickets für Theater, Kino oder andere Veranstaltungen kaufen, nach Alters-gruppen 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.

233

für den Ticketkauf zeigen, dass Menschen über 50 nicht nur regelmäßige Konzert-besucher 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 inte-ressant zu wissen, ob in einem Usability-Test 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

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 Webs-hop wurden insgesamt drei Use Cases durchlaufen: – der Kauf eines frei einlösbaren Gut-scheins 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 Per-sonen 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äl-len ein Laptop der YOUSE GmbH und je nach Wunsch bzw. Gewohnheit zusätzlich eine Maus und/oder ein Keyboard.

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äufi gkeit von Bedienproblemen

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.

Abb. 3. München-Ticket wurde von beiden Nutzergruppen als zu voll und zu unübersichtlich bewertet.

234

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 Übungsdurch-gang (Wetter der nächsten drei Tage her-aussuchen) der Umgang mit dem Browser (Safari) und die Methode des lauten Den-kens eingeübt. Die Reihenfolge der Anbie-ter 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 Schwie-rigkeit (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-Prob-leme, auf die die Tester bei der Durch-führung der Use Cases stießen, in beiden Nutzergruppen gleichermaßen auftraten: – Rigide Suchmaschinen: Eine Suche war meist nur nach Veranstaltungen mög-lich, nicht nach Inhalten wie z.B. Gut-scheinen. Dies war besonders bei der Freiburger Seite sehr problematisch, weil hier tatsächlich als „Veranstaltung“ Gutscheine für eine bestimmte Veran-staltung 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. Tat-sächlich fanden sich dort nur weitere Veranstaltungen.

– Missverständliche Action-Buttons wie z.B. „Weiter: Plätze aus Saalplan buchen“ wenn Plätze schon ausge-wä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ück-Button im Browser nicht funktionierte.

– Das fälschliche Anklicken der Betrei-ber-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 Veran-staltungsorts, weil aufgrund des Webseiten-Betreibers automatisch davon ausgegangen wurde, dass nur Veranstaltungen aus der entsprechen-den Stadt angeboten werden. Daher wurden vereinzelt Konzerte in Wedel, Basel oder Augsburg gebucht.

– Fehlende Filtermöglichkeit von Ergeb-nislisten, z.B. nach Ort oder Datum.

Das bedeutet, dass eine Optimierung der Webseite anhand der Angaben von jünge-ren 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 Genera-tionen 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 Tes-ter den Ticketshop aus Freiburg [Abb. 2] als gute Mischung aus Bildern und Über-sichtlichkeit, 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 konn-ten und (zielführende) Alternativlösungen fanden, während die älteren Nutzer leichter aus dem Konzept kamen und sich in diver-sen Untermenüs oder irrelevanten Sucher-gebnissen verloren. Entsprechend dauerten die Usability-Tests mit den jüngeren Nut-zern 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 Bedien-schwä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]



235

KennwerteTeenager/Twens Median (N=9)

Generation 55plus Median (N=9)

Alter (Range) 23 Jahre (17–25) 69 Jahre (56–82)

Computer-Nutzung pro Woche 30 Std. 10 Std.

Internet-Nutzung pro Woche 17 Std. 5 Std.

Gelöste Use Cases (max. 9) 8,0 4,3

Aktionen gesamt (ideal: 53) 121 135

Klicks gesamt (ideal: 29) 53 79

Bedienprobleme gesamt 18 31

Subjektiv: Schwierigkeit (1–7) 3,4 4,2

Subjektiv: Ärger (1–7) 2,2 3,9

Confidence-Score (1–10) 8 5

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

Eine qualitative Analyse der Testaufzeich-nungen ergab folgende typische Charak-teristika 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 Websei-ten trotz vieler Bedienprobleme eher gutmütig bewertet wurden. Zitat Tes-ter: „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. zwi-schen mehreren Tabs deutlich schlech-ter 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änd-liche Suchbegriffe inklusive Sonderzei-chen 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 ver-bessern („Gutschein“ > „Gutschein frei verwendbar“). Dies ist besonders tragisch, weil gerade die älteren Nutzer oft und von Anfang an mit Suchfeldern

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 wirt-schaftlichen 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 Hotline-Mitarbeiter deutlich entlasten.

3. Fazit: Die Generation 50plus einbinden

Die Generation 50plus sollte von Usability Experten stärker als potenzielle Nutzer-gruppe wahrgenommen werden. Einerseits stellt sie in nicht allzu ferner Zukunft die größte, zahlkräftige Kundengruppe, ande-rerseits 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. DesignTipps 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 pas-sende 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 überfor-dert und finden buchstäblich den Wald vor lauter Bäumen nicht mehr.

– Schon besuchte Seiten sollten unbe-dingt 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 altmo-disch, ist aber immer noch aktuell und erspart dem Nutzer unnötige Frustra-tion oder Verwirrung.

– Aktions-Buttons können eigentlich gar nicht groß genug sein, und sollten möglichst kurz und eindeutig beschrif-tet sein. Handlungsbeschreibungen („Kaufen“) in Kombination mit Symbo-len („Einkaufswagen“) helfen gerade

Abb. 5. Beispiele für Einga-ben älterer Tester in die Suchfelder der Webshops

236



ä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 Email-Adresse 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 Exper-tise 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 Nut-zer so gut wie möglich nachzubilden (Laptop, Tastatur, Maus, Browser), um keine zusätzlichen Fehler zu produ-zieren, die durch das ungewohnte Arbeitsumfeld entstehen. Bei Tests

zuhause können darüber hinaus sehr interessante Einblicke gewonnen wer-den, z.B. ob jemand Tasten zusätzlich beschriftet oder Vorgehensbeschrei-bungen zur Benutzung von Program-men 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 Vorverkaufs-stelle anstatt eines Gutscheins).

– Wegen des geringeren Selbstbewusst-seins 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 Neuentwick-lungen dabei zu sein. Für letztere Gruppe sind daher nett gestaltete, „persönliche“ Incentives (liebevoll ver-packtes Obst, eine Einladung für eine gemeinsame Veranstaltung etc.) als Anerkennung für die Zeit und die Rück-meldung besser geeignet als Geld.

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

ference 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: Gestaltungs-

empfehlungen für Suchfunktionen auf Basis

einer empirischen Benutzerbefragung. In:

Arend, U., Eberleh, E. & Pitschke, K. (Hrsg.),

Software-Ergonomie ‚99: Design von Infor-

mationswelten. Stuttgart: B.G.Teubner (S.

112–121).

4. Meyer, B., Sit, R.A., Spaulding, V.A., Mead,

S.E., Walker, N (1997). Age Group Diffe-

rences 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 Nor-

man 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 require-

ments for older adults. Proceedings of the

WUAUC’01, 2001 EC/NSF Workshop on

Universal Accessibility of Ubiquitous Com-

puting: Providing for the Elderly (Alcácer do

Sal, Portugal, May 22 – 25

237

238

Enterprise/ Government UX

239

Einleitung

„To the user the interface is the applica-tion“ Alan Kay

Bei der Entwicklung von Unternehmens-software stand früher die Robustheit und Verfügbarkeit der Anwendung im Vorder-grund. Viele Systeme entstanden in einem technikorientierten Umfeld, in dem die gestalterischen Möglichkeiten begrenzt waren und die Bedienoberfläche eine eher untergeordnete Rolle im Entwicklungs-prozess 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 zuneh-menden Einsatz mobiler Endgeräte in der Arbeitswelt. Um diesen Herausforderun-gen zu begegnen, investieren die Herstel-ler zunehmend in die Themen Usability und User Experience (UX).

Die Modernisierung der Bedienoberfläche steht bei solchen Projekten ganz oben auf

der Agenda. Um die Anwender dauerhaft zu befriedigen müssen neue Bedienkon-zepte 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 Herausforde-rungen. Das anfangs genannte Zitat von Alan Kay aus den Frühzeiten des Compu-ters bekommt so die Bedeutung, die es verdient.

Für die Entwicklungsabteilungen bedeuten diese Aktivitäten einen relativ drastischen Paradigmenwechsel, der die Bedienober-flä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 ver-feinert. Die Designs wurden parallel dazu

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 Ent-wicklungen einem interessierten Kunden-kreis vorgestellt werden. Aufgrund der posit iven Reaktionen wurde das Bedien-konzept auch auf andere Bereiche der Software angewandt. Neue Module ent-standen nach dem Vorbild der Pilotanwen-dung. Für die Zukunft ist eine komplette Umstellung der Bedienoberfläche geplant.

Damit die Erfolge eines solchen Pilot-projekts 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

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

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 moderni-sieren 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 Media-Anwendungen 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.

Reiner SchlenkerFreiberuflicher UsabilityberaterKirchstraße 4379100 Freiburg im [email protected]

Frank Patz-BrockmannContact Software GmbHWiener Straße 1–328359 [email protected]

„Pimp my GUI – Kosmetik allein genügt nicht“ Herausforderungen bei der Modernisierung einer Bedienoberfläche von Unternehmenssoftware

240

eingeführt werden. Solche Anpassungen brauchen ihre Zeit und orientieren sich am besten individuell an den Gegebenheiten des Unternehmens.

ProjektablaufProjekstart

Contact Software ist Hersteller des PDM-Systems 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 Schwer-punkt der zukünftigen Anstrengungen bil-det. Man entschloss sich zur Zusammenar-beit 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 Rahmen-bedingungen gegeben: – Es gab erste Ideen für eine Pilotanwen-dung, 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-Frame-work Bootstrap von Twitter sein (siehe Literatur).

– Die Erwartungen an das Projekt waren recht heterogen, es existierte zusätzlich eine umfangreiche Liste mit Verbes-serungswünschen an die Usability, die aus dem Bugtracking-System generiert wurde. Diese kamen aus unterschied-lichen Bereichen des Unternehmens und reichten von Detailverbesserungen der existierenden Oberfl äche bis zum kompletten Umbau.

Projektziele

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


Enterprise/Government UX

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 Pro-totyp, 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 effi zienter gestalten.

Vorgehensmodell nach OpenUP

Die Entwicklung orientierte sich weitge-hend an einem neu eingeführten Entwick-lungsprozess, der auf OpenUP basierte. Der Open Unifi ed Process ist ein „Lean Unifi ed Process“ und lehnt sich an den „Rational Unifi ed Process“ (RUP) an. Das agile, itera-tive Vorgehensmodell ist in die vier Phasen Inception, Elaboration, Construction und Transition aufgeteilt. In jeder Phase werden Iterationen und Arbeitspakete in den jewei-ligen Aktivitäten geplant, deren Intensität je nach Phase variieren. Die Aktivitäten überlappen sich zeitlich. [Abb. 1]

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

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 Pilotanwen-dung erarbeitet und an alle Stakeholder kommuniziert. Die Vision enthielt eine für alle Beteiligten verständliche Beschreibung der Ziele sowie Anforderungen, Nutzer-gruppen 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 Spezifi kationen 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 Entwick-lungsprozess und der Zusammenarbeit mit einem Usabilityexperten entstanden z.T. neue Aufgabenbereiche und wurden die Zuständigkeiten neu aufgeteilt.

Projektleiter

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

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

241

Projekts verantwortlich. Er hatte langjäh-rige Erfahrung in der Entwicklung und kannte aus verschiedenen Kundenprojek-ten die Bedürfnisse der Anwender.

Usabilityexperte

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

– Erstellen von Mockups

– Detaillierte GUI Designs – Erstellen von Use Case Modell und Spezifi kationen

– Interaktionsdesign – Erstellen eines Styleguides

Softwareentwickler

Die Entwickler implementierten den Proto-typ 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 PilotanwendungAusgangslage

Die Anwender nutzen CIM DATABASE hauptsächlich über einen klassischen Win-dows-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 Strukturdarstel-lungen organisiert. Die Webanwendung ist veraltet, sowohl unter technologischen Gesichtspunkten als auch aus der Bedien-perspektive. 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ön-nen. Diese Informationen waren zuvor in unterschiedlichen Bereichen der Software verteilt oder nicht vorhanden. Die Anwen-der sollten aus dieser Übersicht weiter navigieren können um weitere Detailinfor-mationen zu einem bestimmten Projekt abzurufen. Es wurden zwei neue Anwen-dungsbereiche entwickelt: Die Projekt-übersicht und die Projektdetails. Zusätzlich entstand ein neuer Kommunikationsbe-reich, die Aktivitäten, der sich konzeptionell und optisch an Social Media Anwendungen wie Facebook oder Yammer orientiert. Der Prototyp wurde als Webanwendung reali-siert, die auch in einem Tablet-Computer funktioniert. Die Anwendung wurde in den existierenden Desktop-Client integriert.

Abb. 2. Aktivitäten nach OpenUP im Pilotprojekt

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

242

Die Anwendung „Meine Projekte“

Die Projektübersicht war die erste Anwen-dung, die entwickelt wurde. Sie zeigt die Projekte, denen die Anwender zugeordnet sind und informiert sie über kritische Ent-wicklungen. Welche meiner Projekte sind auf einem kritischen Pfad? Wo steht das Projekt zeitlich? Gibt es überfällige Aufga-ben oder nicht abgeschlossene Meilen-steine? Von der Projektübersicht können die Anwender zu den Detailinformationen eines bestimmten Projekts oder in existie-rende Bereiche der Software navigieren.

Nachdem die Ziele & Anforderungen der Projektübersicht defi niert waren, entstand das Konzept in verschiedenen Mockup-Varianten, die zusammen mit den Stake-holdern bewertet wurden. Abb. 4 zeigt Mockup-Varianten aus denen das endgül-tige Design entstand. [Abb. 4]

Die fi nale Mockup-Variante wurde in einer prototypischen Umgebung in CIM DATA-BASE implementiert und intern getestet. Die Erkenntnisse daraus fl ossen 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 Projekt-bild dient der schnellen Identifi kation der Projekte, es hat zusätzlich für die Mitglie-der 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]

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 Projektaufga-ben und Dokumente. Sie können Kontakt-informationen zu den Projektmitgliedern



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

Abb. 5. Prototyp „Meine Projekte“

243

abrufen und die Aktivitäten im Projekt anzei-gen lassen. Die Projektdetails sind so konzi-piert, dass sich weitere Spezialbereiche hinzufügen lassen, ohne dass die Übersicht verloren geht.

Die Detailinformationen sind in aufklapp-bare Bereiche gegliedert, die von den Anwendern je nach Priorität vertikal ver-schoben werden können. Die Informatio-nen 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“

Ursprünglich waren die Aktivitäten nicht Teil des Pilotprojekts. Es gab jedoch schon Ideen für diese Anwendung, die sich kon-zeptionell an Social Media Anwendungen orientieren sollte. Während des Projekts entstanden die technologischen Grundla-gen, die es ermöglichten, die Aktivitäten in die Pilotanwendung für das User Meeting zu integrieren. Die Aktivitäten sind ein Kommunikationstool, das unternehmens-weit und projektspezifi sch genutzt werden kann. Die Anwender können ähnlich wie in Yammer oder Facebook Beiträge erstellen und Diskussionen starten. Sie bekom-men 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 Verhal-ten ist konfi gurierbar, so kann die Anzahl der automatischen Meldungen begrenzt werden. [Abb. 7]

Fortführung der Usabilityprojekts

Aufgrund der Erfahrungen im Pilotprojekt wurde die Zusammenarbeit fortgeführt und die Usabilityaktivitäten ausgewei-tet. 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äch-lich dem neuen GUI-Paradigma und

Abb. 6. Prototyp „Projektdetails“

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

244

existierende Anwendungen werden damit modernisiert. Es entstehen Module im Bereich des Innovationsmanagements, der Aufgabenverwaltung und des Kenn-zahlenmanagements. 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 Usabi-lity sensibilisiert.

Neues GUIParadigma

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 Detail-bereiche mit modernen Filter- und Suchmöglichkeiten

– Kommunikationspanels, die sich an Social Media Anwendungen wie Yammer und Facebook orientieren

– Visuell ansprechendes Design

Die Anwendungen sind plattformunab-hängig, basieren auf moderner Webtech-nologie 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 Vektorgra-fik 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 unter-schiedlichen 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 Bedienober-flä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 Inko-sistenzen 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ßun-gen der Elemente wurde verzichtet. Die Maße werden direkt in den GUI-Templates festgeschrieben und können zentral ange-passt werden, ohne dass der Styleguide angepasst werden muss.

Erfolgsfaktoren & Lessons Learned Übersicht

Zum Projekterfolg trugen recht unter-schiedliche Faktoren bei, die jedoch nicht alle zu Beginn eines solchen Projekts plan-bar 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 unterschied-lichen Erwartungen an das Projekt. Durch die umfangreiche Liste mit Verbesserungs-wünschen war die Priorisierung zu Beginn des Projekts aufwendiger als ursprünglich angenommen. Sich die Zeit dafür zu neh-men hat sich aber gelohnt.

Dass das Projekt nicht in den regulären Release-Zyklus eingebettet war, ließ dem Team gewisse Freiheiten. Es konnte inten-siv 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öglich-keiten eines benutzerzentrierten Vorge-hens zu. Interviews und Beobachtungen mit Anwendern wurden nicht durchgeführt. Stattdessen kamen die Daten hier von Mitarbeitern, die viel Erfahrung in Kunden-projekten hatten. Trotzdem blieb mitunter eine Unsicherheit über die tatsächlichen Bedürfnisse der Anwender. Eine Einpla-nung 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 Vision-Workshops an, die einen festen Platz im Projektplan haben sollten (Colville, 2012).

Mockups & Use Cases

Mit den Mockups konnten schon früh Ideen und Konzepte visualisiert werden, die noch nicht den Eindruck einer ferti-gen 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 Pro-jekt, als man versuchte eine Teilanwendung ausschließlich über Mockups zu realisie-ren. 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. Techni-sche Redakteure können daraus schon früh die relevanten Inhalte für ihre Dokumenta-tion ableiten.

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

4. Wikipedia: Rational Unified Process:

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

Rational_Unified_Process

246



247

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 Kommunikationstech-nologien (IKT) besondere Bedeutung im eGovernment Umfeld zugemessen. Der Aktionsplan 2011 – 2015 hat in der Malmö Erklärung dementsprechend vier Schwer-punkte gesetzt [European Comission 2010]: – „Stärkung der Bürger und Unterneh-men durch elektronische Behörden-dienste, die ganz auf die Bedürfnisse der Nutzer abgestimmt sind und in Zusammenarbeit mit Dritten entwickelt wurden, […]

– Erleichterung der Mobilität im Binnen-markt durch nahtlose elektronische Behördendienste, […];

– Effizienz und Effektivität durch das ste-tige Bemühen, mit Hilfe elektronischer Behördendienste die Verwaltungslas-ten zu verringern, […];

– Umsetzung der politischen Schwer-punkte durch Schaffung geeigneter Schlüsselvoraussetzungen sowie rechtli-cher und technischer Voraus setzungen.“

Aktuelle Zahlen zu den Zielen aus 2012 zeigen, dass Europa eine sehr positive Ent-wicklung nimmt: 44 % (Ziel 50% bist 2015) der europäischen Bevölkerung und 87 % (Ziel: 80% bis 2015) der Unternehmen nut-zen bereits elektronische Behördendienste [European Commission 2013b].

Seit 2007 führt die Europäische Kommis-sion 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 (Beobach-tungszeitraum 2012) ist, dass seit 2007 die

Verfügbarkeit von elektronischen Behör-dendiensten 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 embra-ced in Europe“. Die Kommission formuliert folgende Empfehlung für die EU-Länder: „Implement strategies to increase cus-tomer 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

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

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 eGovern-ment 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, Zu-sammenarbeit mit anderen Teams bzw. weiteren externen Partnern, Argumentation von Maßnahmen bzw. Methoden, interne Projektkommunikation mit unterschiedlichen Stake-holdern, „Verkauf“ von UX-Entscheidungen bzw. Behandlung von Widerständen, Kunden Coaching bzw. Nutzen aus Nachbetrachtung der Projekte. Die in zahlreichen eGovern-ment 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 Vor-gehen bei verschiedenen Projektdomänen (z.B. eGovernment, eHealth, Versicherungen, Arbeitsmarkt etc.) aufgezeigt bzw. diskutiert.

Michael BechinieUSECON GmbH1110 WienModecenterstraße 17,[email protected]

Peter StrasslUSECON GmbH1110 WienModecenterstraße 17,[email protected]

Markus MurtingerUSECON GmbH1110 WienModecenterstraße 17,[email protected]

Manfred TscheligiUSECON GmbH1110 WienModecenterstraße 17,[email protected]

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

248

kommerzieller Branchen“ gehen. Das erfor-dert ein Umdenken bei der Konzeption, Entwicklung und Pfl ege 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, durch-gä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 Stra-tegien 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ön-lichen Kommunikation fällt bei elektroni-schen 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ög-liche Rechtssicherheit in den Prozessen zu bieten. Rechtsgrundlagen machen die Entscheidungsfi ndung „Welche ist die rich-tige Vorgehensweise in meiner Ausgangs-situation?“ 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 Notwendig-keit vermehrter Abstimmungen zwischen Bund, Land und übergeordneten Struktu-ren. Teils widerstrebende Bedürfnisse müs-sen 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 Entscheidungsfi ndung ist meist komplex und von starken Kompromissen geprägt.

2.3.Budgetunsicherheit versus nachhaltige Maßnahmen

eGovernment ist per Defi nition ein poli-tisches Umfeld. Budgets für Projekte sind stark von der amtierenden Regierung abhängig. Die Planung von Maßnahmen wird durch etwaige Wechsel der Zustän-digkeiten erschwert. Zugesicherte Budgets werden gekürzt oder ganz gestrichen. Stra-tegische 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 wer-den, die verpfl ichtend im System umge-setzt werden müssen. Usability Optimierun-gen werden eventuell auf die Folgerelease verschoben, Rechtssicherheit hat Vorrang.

Abb. 1. Charakteristika des eGovernment Bera-tungsfeldes mit entspre-chenden Erfolgsfak-toren zur Lösung der Spannungsfelder

249

2.5.Vorgaben versus Innovationsspielraum

eGovernment wird durch ein starkes Regelwerk bestimmt: eGovernment Gesetz, Sicherheitsrichtlinien, Barrierefreiheit, ver-bindliche Style Guides für den Einsatz von Formularen, Datenstrukturen, Legacy IT-Systeme, unterschiedliche Datenprotokolle. Hier zeigt sich ein bedeutender Unter-schied 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 Kom-ponente. 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ätzli-che Arbeitsworkshops und Qualitätssiche-rungsaufgaben kommen hinzu. Gefühlte

„On Top“ Usability Themen, „mit denen man sich jetzt auch noch beschäftigen muss“, werden teilweise als Ballast emp-funden. Taktieren und Politik der Abgren-zung beherrschen die UX Arbeit, Formalis-men 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 Systementwick-lung dar. Durch die Multi-Stakeholder Per-spektive bei eGovernment Anwendungen fällt es oft schwer alle unterschiedlichen Zielgruppen einzubinden. Aus projektpoli-tischen Gründen wird es als Notwendigkeit gesehen, Vertreter aus allen (auch parteipo-litischen) 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äufi gen „No Go“, da die Vorbe-reitungszeit schnell auf Wochen anwachsen kann, bis alle Interessensvertreter organi-siert 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 Umfeld3.1.Analyse von Projekten als Ausgangspunkte

UX Berater sind „Lösungslieferanten auf Zeit“, die ihre Leistungen immer weiter optimieren wollen. Im Zentrum der Über-legungen stand daher die Frage, wie die UX Arbeit in einem speziellen Feld noch kundenorientierter werden kann.

Mit Hilfe von informalen „Projekt Retrospek-tiven“ [Kerth 2001] wurden Erfahrungswerte durchgeführter eGovernment Projekte gesammelt. Abläufe, Entscheidungsfi n-dung, „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]

Abb. 2. Komplexität der Pro-jektdomäne versus Komplexität der Projektorganisation

250

3.2.Die Erfolgsfaktoren

Die Autoren haben mögliche Faktoren für die erfolgreiche Umsetzung strate-gischer und taktischer UX Maßnahmen im eGovernment Bereich in folgenden Feldern identifi ziert: – 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. Nachbetrach-tung des Projekts

3.3.Ein maßgeschneidertes Projektsetup defi nieren

Dieser Faktor hat starken Bezug zu „Rechts-sicherheit vs. Usability“. Für die Entwicklung rechtskonformer, aber benutzbarer Lösun-gen liegt der Erfolgt darin, im Projekt-setup schon zu Beginn unterschiedliche

Kompetenzen in die Analyse miteinzube-ziehen. Durch die frühzeitige Einbindung von Fachlichkeit, Entwicklung, Design, und Usability profi tieren User Interface Design Entscheidungen wesentlich.

In diesem Zusammenhang hilft eine klare Defi nition bzw. Differenzierung notwen-diger Rollen. Damit wird der Verwechs-lung von Verantwortung mit Kompetenz vorgebeugt. Auch Verzögerungen in den Projektplänen durch Konfl ikte zu Verant-wortungen und Kompetenzen können so reduziert werden. In Abstimmung mit der fachlichen Betrachtung durch Exper-ten, 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 Konsoli-dierung 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 Fak-toren 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 Test- Phase 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



Abb. 3. Beispiel Setup mit Beteiligung unter-schiedlicher Kompe-tenzen schon ab der Analysephase

Abb. 3. Beispiel Setup mit Beteiligung unter-schiedlicher Kompe-tenzen schon ab der Analysephase

251

Änderung in der Dynamik entsteht, wenn das Hauptprojekt in Teilprojekte geteilt werden muss – im eGovernment Bereich ein häufi ger 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 fach-lichen 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 garan-tieren [Bechinie 2010]. Dies trifft besonders dann zu, wenn Teams in Teilprojekten arbeiten und gremiale Strukturen Ent-scheidungsprozesse langwierig gestalten. Besonders auf „Föderale Organisation vs. rasche Entscheidungen“ wirkt sich diese Taktik positiv aus.

3.5.Mit allen Stakeholder des Projekts vernetzen

Eng im Zusammenhang damit steht die interne Projektkommunikation mit unter-schiedlichen Stakeholdern. Um den Ball der Kommunikation im Dickicht einer kom-plexen Projektorganisation aus Behörde(n), weiteren externen Beratern und ausgela-gerten Entwicklungsressourcen fl ach zu halten, ist die Versuchung für UX Berater groß, nur mit dem direkten Umfeld zu sprechen. Für die Entscheidungsfi ndung braucht diese Strategie voraussichtlich weniger Iterationen, es wird aber gleichzei-tig die Qualität der Entscheidung gefähr-det. Fundierte UX Entscheidungen sind per Defi nitionem multidimensional.

Der Erfolg liegt darin, Maßnahmen mög-lichst 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.6.UX Maßnahmen und Methoden argumentieren

Der im Projektsetup defi nierte Katalog an möglichen UX Maßnahmen und Metho-den 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 amtieren-den Regierung mit großen Unsicherheits-faktoren 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“ proak-tiver, rascher, greifbarer, pragmatischer und mit höherer „CEO Sichtbarkeit“ geliefert werden. [Abb. 4]

3.7.UX Entscheidungen gewinn bringend verkaufen

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

Abb. 4. Elefant vs. Schmetter-ling – Agile UX Maß-nahmen bieten in un-sicheren Umwelten größere Erfolgschancen und rascher greifbare Ergebnisse

252

Um anstehende Usability Optimierungen trotzdem in der nächsten Release unterzu-bringen, 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 Sichtbar-keit von greifbaren Ergebnissen wirkt sich positiv auf die Aufmerksamkeit in der Pro-jektleitung aus. Im Sinne einer langfristigen Demonstration des Wertes von UX Maß-nahmen ist es wichtig, auch die kurzfristi-gen 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 anzuneh-men bedeutet oft große Veränderungen. Hier zieht „Arbeitssituation vs. Motiva-tion“. Zusätzlich spielt hier „Erschwerter Zugang zu Benutzern vs. benutzerzent-rierte 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 heraus fordern

– es zu Unsicherheit im Zusammenhang mit bestehenden Prozessen kommen kann

– sie von „kreativer Zerstörung“ beglei-tet 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 Promotoren-modell [Hauschildt 2003] eine praktikable Herangehensweise. [Abb. 5] Das Modell stammt aus dem Innovationsmanage-ment, 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 Alterna-tiven. Hat der UX Berater auch grundle-gendes 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 entwi-ckelt werden, die auch funktionieren.



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

253

3.9. Lernen durch Beobachtung

Ein wesentlicher Lernvorgang stellt das Beobachtungslernen dar [Badura 1962]. Ziel dabei ist es, bestehende Verhaltens-weisen zu modifizieren bzw. neue Verhal-tensweisen zu erlernen. Diese klassische Methode bietet die Möglichkeit Maßnah-men und Ergebnisse nach Abschluss eines Projekts systematisch zu analysieren. Die Projekt Retrospektive wird zu einem wichti-gen Werkzeug, um geplante UX Maßnah-men 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 Dimen-sionen bewertet: Projekt Rahmenbedin-gungen, Projektmanagement, Methoden / Projektinhalte, Kommunikation und Papier-korb (nicht durchgeführte Aktivitäten). Eine nach dem Plus / Minus Schema erfolgte Bewertung zeigt, welche Aktivitäten im

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 jeweili-gen eGovernment Domäne unabhängig wirksam. Es gibt eine Reihe zusätzlicher Aspekte, die starke Abhängigkeit von der betrachteten eGovernment Domäne zei-gen und als „Moderatoren“ der Erfolgsfak-toren 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

oder Hybride wie „Water-Scrum-Fall“ [West 2011])

– Teilweise sehr lange Änderungs-Zyklen (abseits der Aktualisierung der rechtli-chen Basis)

– „Design for All“ (nicht nur zurechtkom-men, sondern auch gute UX)

– Starke Unterschiede der Businesspro-zess Ebenen (Administration < > Admi-nistration, Administration < > Unter-nehmen, Administration < > Bürger)

– Starke Unterschiede in der Sensibilität der Rechtsmaterien (Gesundheitsdaten vs. Abfallbilanzen vs. Öffnungszeiten Besucherzentrum Parlament)

4. Fazit und Ausblick

eGovernment ist ein spannendes Feld für UX Beratung, das sich jedoch als „speziell“ präsentiert und einer Fahrt auf der Achter-bahn gleicht – mit verbundenen Augen. Die nachhaltige Umsetzung von UX Maß-nahmen im eGovernment Umfeld stellt Berater vor zwei große Herausforderun-gen: ständiger Wandel und kontinuierliche Adaption von Maßnahmen an wechselnde Projektumwelten. Im Rahmen einer Meta-analyse von Beratungsprojekten in sehr unterschiedlichen eGovernment Domänen konnten sieben übergreifende Faktoren aufgezeigt werden, die für die nachhaltige Umsetzung von UX Maßnahmen Anhalts-punkte 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 Bei-spiel die Relevanz der Erfolgsfaktoren in anderen UX Beratungsfeldern voneinander unterscheidet.

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

254

Literatur1. 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-ict-

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

1. Überblick

Anforderungen von Nutzern in die Umsetzung zu führen ist Bestandteil jedes UX-Projekts. Für den UX-Designer bedeu-tet 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 Doku-mentationsaufwand im Griff zu haben, über alle Themenfelder hinweg ein vergleichba-res Detailniveau zu erreichen und vom Kun-den eine Aussage dazu zu erhalten, welche Anforderungen wichtiger sind als andere.

Im Folgenden erläutere ich meine Erfahrungen als UX-Designer und Requi-rements Engineer aus zahlreichen kleinen und mittleren Projekten (vornehmlich

Industry-Bereich) sowie aus zwei mehrjäh-rigen Programmen bei Vor-Ort-Einsätzen in der Kundenorganisation. UX-Designern und Projektleitern gebe ich Argumente für die Budgetierung sowie Tipps zur Erhe-bung und Dokumentation von Anforderun-gen 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 Doku-mentieren von Anforderungen ist es, diese sich stark unterscheidenden Blickwinkel einzunehmen und zwischen ihnen zu ver-mitteln. Übliche Quellen für die Anforde-rungserhebung sind: – Interviews mit Projektbeteiligten sowie mit den Nutzern

– Dokumente aus dem Projekt selbst (Projektbeschreibung, Machbarkeits-studien, 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 Anforde-rungen 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.

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

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 Pro-jekten 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 entspre-chend 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 Do-kumentationsweise 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 unterschiedli-cher Abdeckungsniveaus einzelner Themenkomplexe - und was man von seinem Product Owner erwarten können sollte.

Thom ScheinerUser Interface Design GmbHClaudius-Keller-Straße 3c,81669 Mü[email protected]

(Über-) Leben mit Anforderungen

256

– Für eine Reihe von Produkt-Klassen verlangt der Gesetzgeber den Nach-weis, 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 Vereinba-rung dar zwischen PO und UX-Desig-ner, wodurch die Erwartungen besser geklärt werden können.

– Anforderungen zeigen allen Projektbe-teiligten, was überhaupt schon als Auf-gabenfeld erkannt ist: Was als Anfor-derung 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 – „Selbst-verständliches“ versteht sich nicht von selbst und führt schnell zu Missver-ständnissen oder Ärger – etwa dass in einer Software für Ingenieure neben SI-Einheiten (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 Work-shops 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 Marktforschungs-panels 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 Blick-winkel eingebracht und die Anforde-rung 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 Dis-kussionen 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 (irgend-was 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 Ergeb-nissen. Hier fehlte der Erfolgsfaktor der regelmäßigen (!) Teilnahme des UX-Desig-ners, denn dafür war kein Budget da.

Mein erstes mehrjähriges Vor-Ort Pro-gramm, für das ich zunächst 90% als Requi-rements Engineer arbeitete, bot bessere Möglichkeiten für die Arbeit mit Anforde-rungen. 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 Themenbe-reichen vor, um diese abnehmen zu lassen. Insgesamt war das viel, aber auch verein-barte Arbeit, und sie führte zu einer hohen Reife der Anforderungen.

Bei meinem zweiten mehrjährigen Vor-Ort 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, wenn-gleich 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 Kolle-gen 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 Nut-zeraufgaben 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 verur-sacht zwischen dem initialen Dokumentie-ren mit allen Attributen in einem professio-nellen Tool einerseits und dem Verknüpfen mit einer konzeptuellen Lösung anderer-seits (die Erhebung der Anforderung sowie

257

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 fest-gestellt wird, hat sie noch einige Bearbei-tungsschritte 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 erfas-sen und ggf. weitere noch zu erfor-schende Themen zu definieren.

– Präzisieren und Klären neuer Fragen: Die soeben definierten weiteren

Themen wirken auch zurück auf die vorliegende Anforderung; dadurch muss die Anforderung wieder über-arbeitet 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 ähn-licher 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 Aufga-ben, 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 Dop-pelungen von Anforderungen auftreten.

Diese sollten von Zeit zu Zeit identifi-ziert, 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 doku-mentiert 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 Auf-wand. 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 Anforde-rung 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 auskom-men; ausgleichend gibt es aber auch Anforderungen, die wesentlich aufwändi-ger handzuhaben sind.

4.2. Vergleich der Dokumentation per PostIts und digitaler Erfassung

Auf Papier generell geht die Dokumenta-tion 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

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

258

Prozessschritt Aufwand (digital)

Aufwand (Post-It)

Initiales Aufschreiben mit allen Attributen 5 min 1 min

Besprechung mit PO 3 min 3 min

Präzisieren und neue Fragen klären 15 min 15 min

Nivellieren 5 min 5 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 5 min


Lösung verknüpfen und Status im System aktualisieren 5 min 1 min

Verbleibenden Datensatz digitalisieren 2 min

Gesamtaufwand je Anforderung 49 min 40 min

Arbeitsfläche (thematische Grup-pierung, 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 kosten-lose 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 Anfor-derungen lassen sich hier Zusam-menhänge einfach abbilden und nachvollziehen.

– Potenziell riesige Arbeitsfläche: Je nach Platzverhältnissen kann man Wände, Fenster, die Decke oder auch mobile Raumteiler verwen-den – es wird sicher mehr Platz sein als ein 24-Zoll-Monitor.

– Gleichberechtigt und spontan: Neue Informationen lassen sich ohne spürbaren Aufwand hinzu-fü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än-gig“, „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 hinab-trudeln zu lassen.

– Lokal gebunden: Verteilt arbei-tende 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.



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

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 unterstützt

Soll die Abbildung der Anforderungen Diskussionen anregen?

(eher trist und technisch) (eher trist und technisch) diskussionfördernd

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

Stabilität Stabilität Flexibilität

Müssen die Anforderungen archiviert werden?

Archivierbar Archivierbar (nur per Foto oder spätere Digitalisierung archivierbar)

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

Wechselnde Nutzer Wechselnde Nutzer Feststehendes Team

Ist es wichtig, Anforderungen vollstän-dig definiert zu haben?

Vollständig definiert Vollständig definiert Quick & dirty

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

Verteilen möglich 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

259

Der wesentliche Erfolgsfaktor für mein ers-tes solches Projekt war, dass wir genau jene Phase der Anforderungsarbeit mit ökono-mischen Post-Its bewältigten, in welcher die Anforderungen am intensivsten bearbeitet wurden: Neue Informationen erforderten neue Formulierungen (Post-It neu schrei-ben), neue Informationen erforderten Ergänzungen (auf dem Post-It nachtragen), Anforderungen mussten neu gruppiert wer-den (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 meh-rere Iterationen in die fi nale Form hinein diskutiert worden und damit ziemlich stabil waren, zogen wir sie in einem Kraftakt um in die digitale Welt (siehe letzter Prozess-schritt in Tabelle 1). Für all jene Anforde-rungen, die der natürlichen Selektion zum Opfer gefallen waren, fi el 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 mehre-ren Kriterien. Kriterien für die Auswahl der Dokumentationsart2 zeigt, welche Kriterien man berücksichtigen muss und welche Dokumentationsart das Krite-rium unterstützt. Es empfi ehlt 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 Anfor-derungsmanagement bereits eine Software eingeführt wurde und man durch dieses

nicht zu sehr eingeschränkt wird im krea-tiven 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 ExcelF ormel 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 sche-matisiertes Arbeitsblatt an – und wie Dr. Jekyll war ich mir nicht bewusst was ich da erschuf. Je Informationsbaustein spen-dierte 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 Abbil-dung 2) baute ich eine Formel ein mit dem zentralen Befehl „Concatenate“ / „Verket-ten“. 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 Anfor-derungstext ä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 Anfor-derung 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 die-ses Schema bei bis zum Ende des Projekts, aber seither ist klar dass wir es so nicht wieder machen wollen.

4.6.Nivellieren

Bei den Nutze raufgaben eines bestimmten Produkts, an dem ich arbeitete, gab es drei

Abb. 1. A nforderungsschablone (schematisch, nach Rupp)

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

260

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 Anforde-rungen zu diesen drei Aufgaben zusam-men, analysierte sie und übertrug sie der Vergleichbarkeit halber in eine Matrix (siehe Matrix zum Niveau-Vergleich der Anforderungsabdeckung dreier Aufga-ben3). Die Analyse bezog sich auf diese Aspekte: – Gegenstand (Aufgabe vs. Akte) – Darstellung (Überblick, visueller Hin-weis, Push-Notification)

– Informationsbedarf (notwendige Informationen zur Beurteilung, ob man diese Akte öffnen will)

– Auslöser (selten oder besonders, not-weniger Input von anderen, Neugier)

– Methode (Push vs. Pull) – Zweck (Qualitätssicherung, Vollständig-keit, Neugier)

– Aktuell genutzte Tools und Prozesse

Dann prüften wir je Punkt, ob die drei Auf-gaben ähnlich präzise durch Anforderungen abgedeckt waren. War bisher z.B. bereits klar dass die Liste der Reminder Änderun-gen 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 wel-chen Aufgaben ein Aspekt zu ungenau oder unnötig detailliert dargestellt war. Wir konn-ten daraufhin die Anforderungen präzisieren bzw. entschlacken, so dass sie schlussend-lich 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 ver-pflichten die Projektbeteiligten. Deshalb sollte von Kundenseite geklärt werden welche Anforderungen tatsächlich relevant sind und wo für eine Entscheidung noch

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 wel-che Anforderungen wichtig und welche weniger wichtig sind. Andernfalls muss der UX Designer entweder glatt alle Anforde-rungen 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).

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

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 entwi-ckelt 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 Ins-tanzen diskutieren soll.

¹ Rupp, Chris; SOPHIST Group: „Requirements-

Engineering und -Management: Professi-

onelle, iterative Anforderungsanalyse für

die Praxis “, 5. Auflage; Carl Hanser Verlag

GmbH & Co. KG



Abb. 3. Matrix zum Niveau-Vergleich der Anforderungsab-deckung dreier Aufgaben

261

262

Branchentrends

263

1. Einleitung

Mit dem Branchenreport Usability infor-miert 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 Usability- bzw. User Experience-Bereich anstreben, erhalten so eine Übersicht über mögli-che 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 Aufga-ben des Berufsverbands. Fragen hierzu umfassen beispielsweise die wichtigsten Faktoren für Zufriedenheit und Unzufrie-denheit unter Arbeitnehmern, Schwierig-keiten 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

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 Profes-sionals an unserer jährlichen landesweiten Befragung. Bei allen Teilnehmern möchten wir uns an dieser Stelle herzlich bedanken!

Wie auch in den Vorjahren erfolgte die Erhebung mittels Online-Befragung im Zeit-raum von Februar bis Mai. Die Teilnehmer wurden über den German UPA Newsletter sowie durch Einladungen in Usability/User Experience-Gruppen in sozialen Netzwer-ken 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.

2. Aufbau der Befragung

Die Befragung umfasste insgesamt vier thematische Bereiche:

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 berufsbeglei-tende Aktivitäten zur Weiterbildung.

Momentane Position. Erfragt wurden Ar beitsbereiche, Aufgabenschwerpunkte, sowie weitere Angaben zur Charakterisie-rung typischer Projekte im Rahmen der momentanen Position (z.B. Projektdauer, beteiligte Berufsgruppen). Zusätzlich wur-den spezifische Fragen zur Arbeitssitua-tion an Angestellte und Selbstständige gerichtet: Unter den Angestellten wurden beispielsweise Jobtitel, Stellenumfang, Dauer der Unternehmenszugehörigkeit, Größe des Unternehmens, Bruttojahresge-halt sowie die Zufriedenheit beim aktu-ellen Arbeitgeber erfragt. Selbstständig Tätige hingegen wurden beispielsweise befragt zum Zeitpunkt der Unternehmens-gründung, ihrem üblichen Stunden- oder Tagessatz, ihrer Einschätzung der Auftrags-lage, sowie zu allgemeinen Herausforde-rungen bei der Unternehmensgründung im Bereich UX/Usability.

Branche. Erfragt wurden Meinungen zu Schwierigkeiten und notwendigen

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

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 Deutsch-land. Die Angaben von rund 350 Personen liefern Informationen zu Ausbildungs- und Karrierewegen, Arbeitsfeldern und Aufgabenbereichen, Verdienstmöglichkeiten, Heraus-forderungen bei der Unternehmensgründung sowie den wichtigsten Arbeitgebern der Branche.

Sarah DiefenbachFolkwang Universität der KünsteUniversitätsstraße 1245141 [email protected]

Nina KolbTechnische Universität DarmstadtAlexanderstraße 1064283 [email protected]

Daniel UllrichTechnische Universität DarmstadtAlexanderstraße 10 64283 [email protected]

Branchenreport UX/Usability 2013 Ergebnisse einer Befragung unter UX/Usability Professionals in Deutschland

264

Veränderungen der Branche, sowie die bekanntesten Unternehmen der Branche im deutsch sprachigen Raum. Zudem wurde in diesem Jahr ein Meinungsbild zur persönlichen Defi nition und Abgrenzung der Begriffe „User Experience“ und „Usa-bility“ erhoben.

Im Folgenden werden die wichtigsten Ergebnisse der Befragung zum Branchen-report Usability 2013 vorgestellt. Bei Fra-gen mit vorgegebenen Antwortkategorien basiert die Auswahl der Kategorien in der Regel auf den häufi gsten Nennungen der Vorjahre. Unterschiede werden als signifi -kant bezeichnet, wenn eine Irrtumswahr-scheinlichkeit von < 5% vorliegt (p < .05).

3.Demografi e

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 Durch-schnittsalter unter den männlichen Teil-neh mern (m=35,9) signifi kant 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. Spit-zenreiter mit der größten Zahl von Usability Professionals ist Bayern, hier arbeiten 21% der Befragten, gefolgt von Berlin/Branden-burg (14%) und Baden-Württemberg (14%). Ebenfalls stark vertreten sind Nordrhein-Westfalen und Hamburg/ Schleswig-Hol-stein mit jeweils 11% sowie Hessen mit 7%. In allen anderen Bundesländern arbeiten jeweils unter 6% der Befragten.

4.Aus- und Weiterbildung4.1.Ausbildung

Die große Mehrheit der Befragten (340 Personen, 96%) hat ein Studium absolviert,


Branchentrends

wobei 51% ihr Studium mit einem Diplom, 9% mit einem Bachelor of Science, 7% mit einem Bachelor of Arts, 7% mit einem Mas-ter 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 Psycho-logie (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 Medienge-stalter/innen am häufi gsten 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äu-fi gsten genannt wurden hier die Ausbil-dung 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). Bei-spiele weiterer Nennungen sind Certifi ed Usability Analyst beim Ausbildungsan-bieter Human Factors International oder die Ausbildung zum Usability Experte an der Usability Academy in Kaiserslautern (jeweils 2 Personen).

Abbildung 1 zeigt die Relevanz verschie-dener 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ünfstufi ge Skala, 1=sehr unwichtig, 5=sehr wichtig). [Abb. 1]

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

Abb. 1. Relevanz verschiedener Aktivitäten zum

265

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 beur-teilen unter den Informationsdesignern, gefolgt von den Psychologen sowie Absol-venten des Studiengangs Digitale Medien (Berücksichtigung von Studienfächern, für die Angaben von mindestens 5 Personen vorliegen).

5.Momentane Position5.1.Arbeitsbereiche

Basierend auf den in den Vorjahren am häufi gsten genannten Arbeitsbereichen, wurden die Teilnehmer um die Angabe der prozentualen Verteilung ihrer Projekte gebeten. Abbildung 3 zeigt die durch-schnittlichen 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]

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 Kon-zeption, 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äufi gsten arbeiten die befragten UX/Usability Professionals mit Software-Entwicklern (m=37%), Produktmanagern (m=25%) und Grafi k-/Produktdesignern (m=23%) zusammen, Abbildung 5 zeigt die relativen Häufi gkeiten für die abgefragten

Berufsgruppen. Beispiele für weitere Nen-nungen sind Game Designer, Architekten oder Professoren. [Abb. 5]

5.4.Anteil realisierter Maßnahmen

Di e Schätzungen bezüglich der Frage, welcher Anteil der eigenen vorgeschla-genen 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.

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

Abb. 3. Prozentuale Verteilung von Projekten auf verschie-dene Arbeitsbereic he

266

5.6.UsabilityZeit

Gemessen an der Gesamtarbeitszeit liegt der Anteil an Tätigkeiten im Bereich Usa-bility/User Experience unter den Befrag-ten bei durchschnittlich 73%, wobei sich die Gruppe der Angestellten signifi kant häufi ger mit Usability/User Experience beschäftigt (m=76%) als die Gruppe der Freiberufl er (m=63%).

5.7.Angestellte versus Selbstständige

Die große Mehrzahl der Usability Pro-fessionals befi ndet sich in einem Arbeit-nehmerverhältnis: 287 (81%) arbeiten als Angestellte, während die restlichen 69 Teilnehmer Inhaber eines Unternehmens oder freiberufl ich tätig sind.

Unter den Frauen liegt der Anteil der Selbstständigen mit 17% etwas niedri-ger als unter den Männern (21%), dieser Unterschied ist jedoch nicht signifi kant. Neben den bisher aufgeführten Anga-ben zur momentanen Situation wurden

zudem spezifi sche Fragen an Angestellte und Selbstständige gerichtet, im Folgen-den sind die entsprechenden Analysen aufgeführt.

6.Situation der Angestellten 6.1.Stellenbeschreibung

Der mit 43 Nennungen weiterhin häu-fi gste Jobtitel lautet „Usability Engineer“, Tabelle 1 zeigt die Zahl der Nennungen für

die meist genannten Jobtitel. Insgesamt ist der Begriff der „User Experience“ immer häufi ger 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).


Branchentrends

Rang Jobtitel Za hl der Nennungen

1 Usability Engineer 43

2 User Experience Consultant 38

3 User Experience Designer 34

4 Usability Consultant 19

5 User Interface Designer 16

6 Product Manager 11

7/8 User Researcher 6

7/8 Interaction Designer 6

Abb. 4. Prozentualer Anteil von Arbeitsaufgaben

Abb. 5. Zusammenarbeit mit anderen Berufsgruppen

Tab. 1. Häufi gste Jobtitel

267

26% der Angestellten haben derzeit Perso-nalverantwortung, 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äf-tigten 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]

6.3.Zufriedenheit beim aktuellen Arbeitgeber

Der Mittelwert für die Gesamtzufriedenheit beim aktuellen Arbeitgeber liegt bei 3,9 (sd=1,1; fünfstufi ge Skala von 1= sehr unzu-frieden bis 5= sehr zufrieden). Besonders zufrieden sind die teilnehmenden Usability und User Experience Professionals mit dem in ihrer Abteilung vorherrschenden Team-geist 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öglich-keiten für berufl ichen Aufstieg und Weiter-entwicklung (m=3,4), der Höhe ihres Gehalts (m=3,3) und der Integration von User Expe-rience und Usability in den Produktentwick-lungsprozess (m=3,2). Insgesamt liegen die Zufriedenheitswerte jedoch für alle abge-fragten Aspekte über dem Skalenmittel-punkt. Abbildung 7 zeigt die gemittelten Zufriedenheitswerte für alle abgefragten Zufriedenheitsaspekte. [Abb. 7]

Zudem ist die Gesamtzufriedenheit beim aktuellen Arbeitgeber unter Männern (m=4,01) signifi kant 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 Arbeitsplatzsicher-heit zeigen sich keine geschlechtsspezifi -schen Zufriedenheitsunterschiede).

6.4.Gehaltsspiegel

Das durchschnittliche Bruttojahresge-halt der Angestellten liegt in diesem Jahr bei 51.527 € (sd=18.245; min=21.720; max=150.000; Berücksichtigung von In ha-bern ganzer Stelle), und hat sich damit gegenüber dem Vorjahr nicht signifi -kant verändert (2012: 49.182 €). Männer (m=55.614 €) verdienen weiterhin signi-fi kant mehr als Frauen (m=45.845 €), der Zusammenhang zwischen Geschlecht und Höhe des Gehalts bleibt auch dann signi-fi kant, wenn man die Unterschiede in der Berufserfahrung berücksichtigt (partielle Korrelation r=.178**).

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

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

268

Wie auch in den Vorjahren ist der wich-tigste Gehaltsprädiktor die Berufserfah-rung (r=.56**), dieser Zusammenhang besteht für weibliche (r=.41*) und männ-liche 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 signifi -kanter Zusammenhang zwischen Gehalt und Unternehmensgröße (r=.35**), unter Männern ist dieser Zusammenhang nicht signifi kant (r=.05). [Abb. 8]

7.Situation der Selbstständigen7.1.Unternehmen

In diesem Jahr haben sich mit 69 Unter-nehmensinhabern wieder mehr Selbststän-dige an der Befragung zum Branchenre-port beteiligt (im Vorjahr waren es nur 38 Personen), an dieser Stelle nochmals spezi-ellen Dank. Die Unternehmensbezeichnun-gen 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 Perso-nen betreiben eine „Agentur“, jeweils 10 Personen bezeichnen ihr Unternehmen als „Beratung“ oder „Consulting“ und 8 Per-sonen betreiben ein Designstudio/-büro. Beispiele für weitere Unternehmensbe-zeichnungen sind „Testlabor“ oder „Engi-neering“. 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 Auf-traggebern die Relevanz von Usability zu vermitteln, 65% der Selbstständigen stim-men hier zu. Im Vergleich zum Vorjahr ist die Relevanz dieses Faktors wieder gestie-gen, 2012 waren es nur 50%, die diesen Aspekt als besondere Herausforderung erlebten. Eine weitere Herausforderung stellt die Kontaktaufnahme zu potentiel-len Auftraggebern dar (48% Zustimmung) sowie die Vermittlung der eigenen Profes-sionalität bzw. die Abgrenzung von „unse-riösen“ Konkurrenten (38%). 17% berichten von Schwierigkeiten, bei Entwicklern Anerkennung zu fi nden, weitere genannte Herausforderungen sind beispielsweise „Usability als Wort vermeiden und die Idee des nutzerzentrierten Gestaltens vermit-teln“ oder „die Festanstellung umgehen und den Job als Freelancer bekommen“. Die relative Wichtigkeit der Herausforde-rungen hat sich somit im Vergleich zum Vorjahr nicht geändert.


Branchentrends

Abb. 8. Durchschnittsgehälter der Angestellten in Abhängig keit der Berufserfahrung

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 Experi-ence 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. 8%

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 / Benutzbar-keit 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“

Tab. 2. Thesen zur Abgrenzung der Begriffe User Expe-rience und Usability und Anteil an Zustimmung

Tab. 3. Äußerungen der Be-fragten zur Abgrenzung der Begriffe User Expe-rience und Usability

270

7.3.Verdienst

Unter den Selbstständigen machten 37 Per-sonen Angaben zu ihrem üblichen Stunden-satz, 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 Durch-schnittswert 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 Usability-Begriff immer häufi ger abgelöst durch den Begriff der User Experience. Diese Entwick-lung hat die internationale UPA (Usability Professionals Association) bereits zu einer Namensänderung veranlasst, sie nennt sich seit 2012 nun UXPA (User Experience Pro-fessionals Association). Der Vorschlag einer entsprechenden Namensänderung für die German UPA wurde auf der Mitglieder-versammlung 2012 kontrovers diskutiert. Hierbei wurde deutlich, dass unter den in der Usability- und User Experience-Branche Tätigen recht unterschiedliche Assoziatio-nen zu den beiden Begriffen vorherrschen, und auch unterschiedliche Vorstellungen darüber bestehen, was die beiden Begriffe voneinander abgrenzt, bzw. ob es über-haupt einen inhaltlichen Unterschied zwi-schen den Begriffen gibt. Dies haben wir zum Anlass genommen, hierzu im Rahmen der Befragung zum diesjährigen Branchen-report ein breiteres Meinungsbild einzu-holen. Für die überwältigende Mehrheit der Befragten (97%) besteht ein konzep-tueller Unterschied zwischen Usability und User Experience, nur 12 der Befragten (3%) gaben an, die Begriffe synonym zu verwenden. Für eine nähere Spezifi kation 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

Einigkeit darüber, dass Usability als ein Teilaspekt von User Experience betrachtet werden kann, hier konnten 80% zustimmen. Die Frage jedoch, ob sich Usability objek-tiver 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 Begriffsdefi nitionen oder ihrer Mei-nung nach zentrale Unterschiede zwischen Usability und User Experience aufführen. Hierbei betonten die Befragten verschie-dene Perspektiven, wie beispielsweise die Relevanz für unterschiedliche Berufsgrup-pen („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 gesam-ten Prozess. Also auch davor und danach. Denn was der User vorab schon über den Prozess weiß, das beeinfl usst ihn auch bei der Nutzung.“). Einige verwiesen hier allein auf bestehende Versuche einer Begriffs-defi nition („Usability = Nutzungsqualität; User Experience = Nutzungserlebnis, DIN EN ISO 9241–210“), andere erklärten bestehende Defi nitionen als unzureichend („Es gibt noch keine zufriedenstellende, allgemein anerkannte Defi nition von User

Experience“). Schließlich brachten auch einige der Befragten ihre Unzufriedenheit mit den bestehenden Begriffl ichkeiten zum Ausdruck, wie beispielsweise „Beides verbrannte Worte, durch Leute die keinen blassen Schimmer haben und Reden aber nie Schaffen“. Insgesamt weisen die Nen-nungen jedoch auf eine Reihe von Aspekten hin, die bei einer Abgrenzung der beiden Begriffe hilfreich sein können oder zumin-dest eine wertvolle Diskussionsgrundlage im Rahmen eines weiteren Austauschs inner-halb 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 Pro-duktsparte. Bis auf den Bereich Consumer Software zeigten sich für alle abgefragten Domänen signifi kante Unterschiede: Wäh-rend im Bereich der Unterhaltungselekt-ronik 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 Usa-bility der höhere Stellenwert eingeräumt. Abbildung 9 zeigt die Mittelwerte für die verschiedenen Produktsparten. [Abb. 9]


Branchentrends

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

271

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älti-gen 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 Einbet-tung 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 Quali-tätsstandards, 30% fordern eine stärkere Vernetzung der Community.

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 deutsch-sprachigen Raum, die sich mit „Usability“ bzw. „User Experience“ beschäftigen. Spit-zenreiter 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]

Rang Unternehmen Zahl der Nennungen

1 UID 155

2 SirValUse 95

3 Ergosign 59

4 eResult 47

5 Artop 40

6 Fraunhofer Institut 34

7 SAP 30

8 USEEDS° 17

9/10 eye square 16

9/10 usability.de 16Tab. 4. Bekannteste Unternehmen der UX/Usability-Branche

272


Branchentrends

273

Das Markenversprechen

User Interfaces werden an den Bedürf-nissen der Nutzer ausgerichtet. Aus der Perspektive einer ganzheitlich arbeitenden Designagentur fokussieren wir zudem die Ebene des Produktdesign und des Corpo-rate Design. Auf Anhieb verständliche und intuitiv bedienbare Nutzeroberfl ächen las-sen 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 Markenprofi l – zu erzeu-gen. [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über-sehbaren Warenwelt Orientierung bei

der Kaufentscheidung und machen es einfacher, ein passendes Produkt zu fi nden. Marken sind zudem ein Qualitätsver-sprechen. 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 Mar-kenentwicklung und -führung wird leicht übersehen. In unserer Alltagswahrneh-mung scheint die omnipräsente Werbung

Keywords: /// Corporate, Interface und

Produkt Design/// Marke/// Qualität/// Bedienphilosophie/// Grafi cal User Interface, GUI

AbstractBei Premiumprodukten sind in vielen Branchen eine hohe Nutzerfreundlichkeit und ein grafi sch ansprechendes Erscheinungsbild der Bedienoberfl ächen unverzichtbar. Zu-dem 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 Konzer-nen 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 verschie-den 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 Anla-gensteuerungen, Touch-Regelungen und Fernbedienungen bis hin zu Apps für Smart-phones und Tablet PCs.

Manfred Dorn Phoenix Design, StuttgartKölnerstrasse 1670376 [email protected]

Mit Interface Design ein Markenprofi l stärken User Interfaces sind markenbildend und schaffen Vertrauen in Premiumprodukte – Erläuterungen am Fallbeispiel der Marke Viessmann

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

274

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 Pro-duktinformation geben. Ein Versprechen. Dass dieses nicht enttäuscht, sondern eingehalten wird, muss das Produkt selbst leisten. Erst wenn sich die Erwartungshal-tung 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 anspruchsvol-len 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 Marken-konto vermehrt werden. Widersprüchliche Maßnahmen – zum Beispiel ein nicht markenadäquates Design, minderwertige Qualität, ungenügender Service, sozial-schädliches Verhalten oder eine schlechte


Branchentrends

Bedienbarkeit heben vom „Markenkonto“ ab und schädigen langfristig das positive Image einer Marke. Meist dauert es deut-lich länger, ein gutes Markenbild aufzu-bauen als es zu ruinieren.

Aus der Praxis Corporate Design für die Marke Viessmann

Das Corporate Design der Marke Viess-mann 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 fi rmeninterne Corporate Design Abteilung notwendig. Nur so ist es möglich, produktübergrei-fend ein wiedererkennbares Markener-scheinungsbild bei Produkt Design und User Interface Design zu realisieren. Die Markenkernwerte, die Bedienphilosophie und die gestalterischen Markenelemente müssen klar defi niert sein. Das heißt nicht, dass diese Elemente unabänderlich sind, sondern dass diese einem ständigen, kontrollierten und evolutionären Wand-lungsprozess unterworfen sind. Dieser Erneuerungsprozess muss in regelmäßigen

Abständen mit der Unternehmensleitung des Herstellers refl ektiert und diskutiert werden. Regelhefte und Styleguides müs-sen so formuliert sein, dass diese eindeu-tige Vorgaben für die grafi sche Gestaltung geben – aber andererseits so fl exibel sind, dass sie diesen Wandel zulassen.

Vertrauen in Qualität

Bei vielen Konsumprodukten beeinfl usst das subjektive, reine Gefallen einer Form oder einer Bedienoberfl äche die Kaufent-scheidung. Dies ist bei Investitionsgütern grundsätzlich anders. Niemand investiert in eine Heizungsanlage, nur weil diese gut aussieht. Trotzdem spielt die Produktäs-thetik und das User Interface Design eine entscheidende Rolle bei der Kaufentschei-dung. Selbst Fachleute sind kaum noch in der Lage, auf Anhieb zu beurteilen ob ein Produkt wirklich nutzerfreundlich zu bedie-nen ist und ob die Technologie, die innen verbaut ist, tatsächlich effi zienter funktio-niert, 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öglich-keit, dieses Vertrauen zu schaffen. [Abb. 2]

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

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 beeinfl usst der Heizungsbauer die Kaufentscheidung für ein Heiz- oder Klimasystem in ganz erheblichem Maß. Er

hat meist mehrere Marken der Heiztech-nik 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 durch-geführt worden sind, konnte das Corporate Design Konzept und die User Interface Bedienphilosophie auf andere Viessmann Tochterfi rmen und Indus-trieanlagen übertragen werden. Da es sich bei den Viessmann Industriean-lagen 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 Touchsteue-rung bedient.

276

ihn gewährleisten – kurzum: wenn er mit Produkten positive Erfahrungen in dieser Richtung gemacht hat, wird er den Pro-dukten dieser Marke vertrauen und diese empfehlen. Außerdem ist davon auszuge-hen, 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 Auto-matikmodus betrieben wird und die Anzahl der Anzeigen im Grundbild deutlich reduziert werden kann. Erst wenn Abwei-chungen oder Störungen auftreten, ist es notwendig, detailliertere Informationen anzuzeigen und farblich hervorzuheben. So entstand die Idee mit den selbsterklären-den, grünen Haken für die „OK“ –Situa-tion, die bei Bedarf auf Skalen und Werte wechselt. Nur einzelne wichtige Werte wer-den permanent angezeigt. Um die Inter-pretation 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 Nutzerbefra-gung hat ergeben, dass es den meisten Anwendern wichtig ist, ein attraktives, visuelles Abbild der Anlage auf dem Dis-play wiederzufi nden. Das erleichtert ihnen

die Zuordnung der Anzeigen zu einem Anlagenteil. Da die Anlage erweiterbar sein sollte, erstreckt sich die Visualisierung nun auf mehrere Grundbilder nebenein-ander, auf die redundant durch Sliden und mit Pfeiltasten gewechselt werden kann. Durch Tippen auf die großzügig dimensio-nierten Bedienkacheln mit den Haken oder Grundanzeigen gelangt der Bediener auf die nächste Bedieneben. Dieses Grund-prinzip 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 befi ndet sich eine Statusleiste, die durch eine dünne Linie in der Viessmannfarbe Orange zum mittleren Bedienteil abge-trennt wird. Im unteren Teil des Panels ist eine Bedienleiste mit häufi g verwen-deten Funktionen für direkten Zugriff. Im mittleren Teil befi ndet sich eine grafi sche Darstellung der Anlage oder des Hauses.

Als Corporate Schrift wird die Arial in den Schriftschnitten regular und bold verwen-det. Grundsätzlich wird eine Kombina-tion aus einheitlich gestalteten, grafi sch reduzierten Ikons und Klartext in mehreren Sprachen verwendet.

Das Grundprinzip des dreigeteilten Bildschirmaufbaus mit dem dunklen Hintergrund fi ndet sich an allen Viess-mann Displays wieder. Die grafi sche Detailausführung variiert jedoch je nach verwendeter Displaytechnologie und nach Verwendungszweck.

Übertragbarkeit

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 Tochterfi rmen und Industrieanlagen übertragen werden. Da es sich bei den Viessmann Industrieanla-gen meist um Mess- und Regelprozesse handelt, gelang dies auch bei so andersar-tigen Strukturen einer Biogasanlage oder einem Blockheizkraftwerk.


Branchentrends

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

277

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

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

278

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äch-tige 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 ViessmannHeizsystemen

Früher gab es bei Heizungen nur die beiden Betriebszustände Ein oder Aus; heute dominieren Systeme, die dyna-misch auf den tatsächlichen Wärmebedarf reagieren – und das sogar mit so archaisch anmutendem Brennmaterialien wie Holz-scheiten. So hat der „Vitoligno 200-S“ ein Scheitholzkessel, der von Hand eingewor-fene 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ührungsempfind-lichen Displays am Kessel selbst und über ein Display im Wohnraum oder über eine App. Das Look and Feel ist bei allen die-sen 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ößenva-rianten 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 anpas-sen und geht daher nur mit strukturellen Veränderungen. Folglich unterscheidet

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 über-haupt abgebildet werden sollte, wird mit zielgruppenspezifischen und passwort-geschü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ück-meldung 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 Hausfunktio-nen wie Beleuchtung, Lüftung, Sicherheit, Funksteckdosen und natürlich die Raum-temperatur ansprechen lassen. Damit geht Viessmann als erster Heizungshersteller in Richtung Home Automation. Im Gegensatz zu anderen Systemen steht beim komforto-rientierten „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 Energiesparpo-tenzial. 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 Inter-faces eine Erleichterung. [Abb. 8]


Branchentrends

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.

279

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

1. User Experience und Grundbedürfnisse

User Experience und menschliche Grund-bedürfnisse stehen im direkten Zusammen-hang. 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“ vermit-teln kann, ist für die Qualität der User Expe-rience 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ürf-nissen befasst haben und eigene Modelle vorlegen. Während Reiss (1998, 2000) einen Bedürfniskatalog aus 16 Lebensmotiven

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, Diefen-bach und Göritz (2010b) zeigte sich, dass Stimulation, Verbundenheit, Kompetenz und Popularität die wichtigsten Bedürf-nisse 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 verdeut-lichen, wird jedes Bedürfnis durch eine Motivation angetrieben. Das Bedürfnis Sti-mulation, 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 understi-mulated by life

Hassenzahl (2003, S. 28) hingegen betrach-tet Stimulation noch differenzierter und postuliert: Menschen suchen Stimula-tion, 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 verbes-sern. Ü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 opportuni-ties for the perfection of knowledge and skills (hedonic)“. Bei seinen Ausführungen bezieht Hassenzahl sich sowohl auf Shel-don et al. (2001) als auch auf Reiss (1998, 2000). Als Motivation für das Bedürfnis Sti-mulation 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 Benut-zung eines Produkts ändern: Je länger ein Produkt genutzt wird, desto weniger

Keywords: /// User Experience/// Bedürfnis Stimulation

(Stimulationsfaktoren)/// Kinder/// „Seite mit der Maus“/// Erlebnisideen

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 Be-streben 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 nach-gegangen. 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.

Katrin SchlierkampHochschule der [email protected]

Michael BurmesterHochschule der MedienWolframstr. 3270191 [email protected]

User Experience für Kinder am Beispiel der „Seite mit der Maus“

282

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, verrin-gert sich seine Neugier und es stellt sich Gewöhnung ein.

Diese Erkenntnis ist allerdings nicht allge-meingültig. Es kann ebenfalls das Gegen-teil 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 fortlau-fender Zeit auf einmal stimulierend sein. Das hängt meistens von der subjektiven Wahrnehmung und den Vorerfahrungen einer Person ab.

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, wer-den 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 befi n-den, gehen sehr spielerisch und unbefan-gen an Aufgabenstellungen heran: „Ich


Kurzvorträge

mag das Mix-Spiel, weil der da so lustige Sachen macht!“ (Nils, 7) (Warth, Schnei-der & Lensch, 2009, S. 35). Da sie die Kom-plexität des Computers noch nicht begrei-fen 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 Her-ausforderung 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). Wissensbil-dung nimmt neben Spieleseiten einen höheren Stellenwert ein. Bevorzugt werden nun aber übersichtlichere Websites, da dies ihrem geordneten Vorgehen ent-spricht, 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 entwi-ckelt – 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 Chat-ten, 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.

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

283

Darüber hinaus sind Kinder aller Altersstu-fen 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 wichtigs-ten Unterscheidungen dieser Zielgruppen. [Tab. 1]

3.Stimulation

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) orien-tieren und somit für die Gestaltung eines erlebnisorientierten Ansatzes eine essenti-elle Grundlage darstellen. Durch ständige Veränderungen im Leben wächst das Bedürfnis nach Weiterentwicklung, Erfah-rung, Inspiration sowie nach der Bewälti-gung 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ürf-nis besitzen, nämlich den Erkundungs-drang. Angetrieben von ihrem „Reiz-hunger“ bzw. Wissensdurst (Schönpfl ug, 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önpfl ug, 1997, S. 105). Berlyne (1950; zitiert nach Izard, 1950, S. 219) bezeichnet den Drang nach Stimulierung als ein natürliches Phänomen.

Der Organismus neige dazu, Stimulierung aufzusuchen, so Berlyne (1950; zitiert nach Izard, 1994). Wenn dies dem Organismus allerdings nicht gelingt, entsteht Lange-weile, das Gegenteil von Stimulation. Dann ist die Rede von fehlenden Reizen, auch „Reizentzug“ genannt (Schönpfl ug, 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 vorhan-dener Information und erlernter Erfahrung vorliegt, wird das Interesse besonders erregt. Da Menschen sich meist auf ihre Erfahrungen berufen, können ungewöhn-liche 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 Harmo-nie“ streben. Daher versuchen sie auch Widersprüchlichkeiten zu reduzieren.

Berlyne (1965; zitiert nach Malone 1981, S. 338), spricht im Zusammenhang mit der Entstehung von Neugier von einem „conceptual confl ict“. 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 Konfl ikt, 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

entsteht. Nur das aktive Auseinandersetzen mit der Umwelt unterstützt den Lernpro-zess. So schreibt Schönpfl ug (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 Auf-merksamkeit fesselt. Dabei sollen Neugier und Wissensdurst gestillt werden – Fakto-ren, die Stimulation implizieren.

3.1.Stimulationsfaktoren

Berlyne konnte in seinen Untersuchungen nachweisen, dass Neuartigkeit, Komple-xität, Überraschung und Inkongruenz Neugier erregen (1960, 1965, 1968; zitiert nach Malone, 1981, p. 337). Aber auch Ungewissheit und Konfl ikt gehören zu den Stimulationsfaktoren. Er erwähnt: „Die vier Begriffe [Neuartigkeit, Ungewissheit, Kon-fl ikt 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.

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 identifi zieren. Aufgrund erlernten Wissens kollidiert die Wahrneh-mung mit den Erwartungen. Die Tiere, wel-chen 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önpfl ug 1997)

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

284

besitzen Eigenschaften die Widersprüch-lichkeiten 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 inkongru-ente 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 Überraschungs-momente aufzuzeigen. Der Beobachter ist zunächst verunsichert und in ihm wird ein Konfl ikt ausgelöst. Dabei wird sein Denken angeregt, indem er sich mit seinen Erfahrungen und seinem Wissen ausein-andersetzt (Schönpfl ug, 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 Stimulati-onsfaktoren in Tabelle 2: [Tab. 2]


Kurzvorträge

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

Abb. 4. Ein Bild von Picasso löst einen Konfl ikt aus (Berlyne, 1958; nach Schönpfl ug 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 grafi sch in Form von Storyboards näher erläutert. Die Idee unterliegt dabei einer eigenen Bewer-tung, 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 Maus-Inhalte basieren, jedoch nicht dem Corpo-rate Design der Maus entsprechen.

Dieses Kapitel widmet sich verstärkt dem konzeptionellen Teil. Exemplarisch wird eine Idee sowohl textlich als auch grafi sch in Form von Storyboards näher erläutert. Dabei unterliegt diese Idee einer eigenen Bewertung, wobei der Grad der Stimula-tion bewertet wird.

Da der Redakteur des Kinder- und Fami-lien programmes vom WDR während des Prozesses über die Ideen informiert wurde, tragen seine Bewertungskriterien in star-kem Maße zur Gesamtbewertung des Ex -per tenurteils 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

gewissen Uhrzeit (ca. 21 Uhr) schlafen und schaltet das Licht aus, so dass die Maus-inhalte 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 schla-fen 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 aus-schalten 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 Beat-boxen 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

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

286

Taschenlampe, die einen hellen Lichtkegel erzeugt. Neugierig wie Noa ist, klickt er auf diese und stellt fest, dass sich die Taschen-lampe bewegen lässt. Dann hört er ein leises Schnarchen und bewegt die Taschen-lampe in Richtung des Geräuschs – es ist der Elefant, der schläft. Ein kleines Lächeln zeigt sich auf Noas Gesicht. Nach einer kur-zen 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ön-nen. 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 Neuartig-keit und Abwechslung (Gaver & Martin, 2000) tragen im Besonderen zur Stimu-lierung 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.

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

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

5. Fazit

Das Bedürfnis Stimulation impliziert eine Vielzahl unterschiedlicher Stimulations-faktoren. 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 stimulie-rend wirken kann. Interessant für die Wei-terentwicklung des Stimulationspotentials wäre es nun zu überprüfen, von welchem Stimulationsfaktor die höchste Stimulie-rung ausgeht.

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

Neugier. Zur Psychologie der kognitiven

Motivation. Stuttgart: Ernst Klett Verlag.

2. Berlyne, D. E. (1950). Novelty and curiosity

as determinants of exploratory behaviour.

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

3. Edelmann, W. (2000). Lernpsychologie (6.,

überarb. Auflage). Weinheim: Beltz.

4. Hassenzahl, M. (2003). Attraktive Software –

Was Gestalter von Computerspielen

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

Burmester (Hrsg.), User Interface Tuning.

Benutzungsschnittstellen menschlich

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

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

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

des Menschen. Eine Einführung in die

Grundlagen der Emotionspsychologie.

Weinheim: Beltz.

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

intrinsically motivating instruction. Cognitive

Science 4, 333–369.

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

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

What Is Satisfying About Satisfying Events?

Testing 10 Candidate Psychological Needs.

Journal of Personality and Social Psychology,

80, (2), 325–339.

15. Warth, S., Schneider, S., Lensch. A. K. (2009).

Kinder im Internet – vom virtuellen Spielplatz

zum Alltagsbegleiter. Eine Qualitative Studie

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

Klick mich. Wie man die Herzen der jungen

User erobert! Erfolgreiche Emotionalisierung

im Online-Marketing für Kids & Teens.

Mönchengladbach: Elements of Art GmbH.


Kurzvorträge

287

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 digita-ler, zukunftsorientierter Service erschaffen werden, der für Lehrer/innen eine profes-sionelle Arbeitsumgebung, für Schüler/innen eine zentrale Lern- und Kommuni-kationsumgebung 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 Ser-vice die Nutzerbedürfnisse aller Zielgrup-pen 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

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

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

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 Produktent-wicklung das Serviceangebot zu definie-ren, 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 digi-tale Produkte abgedeckt), zum anderen orientiert sich die Mehrheit der Lehrer am gedruckten Schulbuch.

Weshalb sollten die Nutzer diesen Service lieben?

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 „Design-Prinzipien“ 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 man ein umfangreiches Projekt entwickeln, wenn Usability und User Experience weder im Projekt noch in der Organisation verankert sind?

Während die technische Produktentwick-lung 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 Produktentwick-lungen wurden bisher, vor allem aus der Perspektive des digitalen Produktdesigns, Methoden der Gebrauchstauglichkeit in die Projekte eingebracht.

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

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 berich-ten ü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 Problemstel-lungen zu meistern waren, welche Wege beschritten wurden und welche Maßnahmen sich bewährt haben.

Christiane SchmidtNiederbarnimstrasse 1510247 Berlinmail: [email protected]

Maria MoryKarl-Kunger-Strasse 1012435 Berlinmail: [email protected]

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

288

Der Projektauftrag: Bedingungen und Umfang klären

Im Rahmen der Produktentwicklung des neuen Services sollte die Abteilung Design einen Pitch zwischen mehreren Desig-nagenturen 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 Koope-ration mit einer User-Experience Agentur ein Nutzertest durchgeführt werden.


Kurzvorträge

Das Konzept für das neue Produkt war bereits verfasst. Es gab eine Projektpla-nung, die in einem engen Zeitplan den Start der Scrumprozesse vier Monate später vorsah, und in der festgelegt wor-den war, die Produktentwicklung mit der Lehrerschaft als Empfehler und Kaufent-scheider 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 Projek-tumfangs im Gegensatz zu den meisten

anderen Projekten mehr als ein Produktde-signer involviert werden müsste. Aus diesem Grund schlugen wir ein 3 köpfi ges 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 Ebenen-Modell 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 zwi-schen 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 visuali-sieren 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 vermit-teln, dass Gestaltungsprozesse nicht nur eine Frage der Oberflächengestaltung sind, sondern sich in jeder Phase der Projektent-wicklung wiederfinden.

Wir arbeiteten das Modell zu einem UX-Plan um, formulierten zu den ein-zelnen Ebenen des Modells Fragestel-lungen und beschrieben die möglichen

Vorgehensweisen. In Kombination mit der zeitlichen Dimension, entstand so unser visueller UX-Plan. In der Abbildung 1 wer-den die Ebenen des UX-Plans von der Kon-zeptbasis 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ßnah-men 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 Design-agenturen 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 Arbeitsmateri-alien durch und werteten anschließend die Arbeitsergebnisse aus.

Personas: Klärung der Nutzerbedürfnisse

Um die Bedürfnisse der Nutzer der Haupt-zielgruppe 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 Stellvertre-ter einer großen Zielgruppe mit bestimm-ten Hang zu einer Marke oder idealtypi-sche 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 unternom-men, um Personas zu erarbeiten1. Auswertung der Kontext-Daten und

Dokumentation der Ziele, Hürden und Aufgaben von Lehrern/innen aller Alters-gruppen, Fächer und Schulformen.

2. Einschätzung der Dimensionen des Verhaltens der Lehrer/innen durch die Teilnehmer des Workshops.

3. gemeinsame Clusterung und Auswer-tung der Dimensionen.

Folgende Erkenntnisse konnten wir in dem Personaworkshop gewinnen und in die Produktentwicklung einbringen:

Fast alle Lehrer (bis auf wenige Ausnah-men) verbindet ein relativ langes, gradlini-ges 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ülerorganisa-tion an, auf die sie dann in ihrem weiteren Berufsleben zurückgreifen. Sie aktuali-sieren ihre Daten je nach Änderung der Curricula.

In der Regel haben Lehrer die gleichen Kernaufgaben: – Organisation des Unterrichts nach Vorgabe der landesweiten Rah-menpläne und Verwaltung der Unterrichtsmaterialien

– Durchführung des Unterrichts – Diagnose, Überprüfung und Bewer-tung 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 Medi-enkompetenz und ihre Zugehörigkeit zu bestimmten Schulformen eine größere Rolle als ihr Lehrfach. Dementsprechend unterschiedlich sind die Anforderun-gen an unterstützende Materialien und Maßnahmen.

290

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 Profi vollzeitlehrerin an einer Gesamt-schule arbeitet gerne nur digital, ist aber gänzlich auf sich gestellt, während ihre Kollegin aus der Grundschule stark mit anderen Lehrern zusammen arbeitet, aller-dings 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 Gym-nasium gerne stärker kollaborativ vorgeht.

Wir haben 4 Personas entwickelt, die den Dimensionen innerhalb der Berufserfah-rung, der Medienkompetenz, der Schul-form entsprechen und zugleich beschrei-ben, wie die Personen arbeiten.

Mit den Personas konnten wir den Stake-holdern die Aufgaben und die Ziele der späteren Benutzer nahe bringen und im Projekt eine einheitliche, gemeinsam erar-beitete Vorstellung der Nutzungskontexte vermitteln. Mit Hilfe der Personas war es nun möglich, die ersten zeitgleich entstan-den Featurelisten zu priorisieren.

Design-Prinzipien:Defi nition der Produktziele

Nachdem wir die Personas entwickelt und die heterogene Lehrerschaft eingegrenzt hatten, organisierten wir einen Workshop, um die Produktziele mit Hilfe der Design-Prinzipien genauer zu defi nieren.

Was sind Design-Prinzipien und wofür?

Design-Prinzipien sind nicht mit Design-Pattern 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 Projektbeteilig-ten zu fi nden, 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 defi nieren und kommunizieren die wichtigsten Merk-male der Anwendung, an eine Vielzahl von Beteiligten, einschließlich der Kunden, Kollegen und Teammitglieder. Design-Prinzipien 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 Projek-ten gibt es oft viele Projektbeteiligte und genauso viele unterschiedliche Interpre-tationen des Projektziels. Oft ist nicht klar,


Kurzvorträge

Abb. 2. Bewertungskriterien durch Desig-nprinzipien und Personas

291

wie lange und in welcher Rolle jemand am Projekt beteiligt ist. Es sind unterschied-liche Erwartungen an die Qualität des Produktes vorhanden, unklare Grenzen und Visionen. Manchmal gibt es konkur-rierende 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 Voraus-setzungen für das hilfreiche Werkzeug „Design-Prinzipien“.

Wie entwickelt man Design-Prinzipien?

Am effektivsten ist es, sie in einem Work-shop 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 Aufgabenana-lyse sowie die Produktziele. Design-Prinzi-pien dürfen nicht zu allgemein formuliert sein. Sie sollten kurz, prägnant und für das Projektteam inspirierend sein.

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?

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

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.

3. Meine lebendige Komposition: Ermögli-che den Nutzern die maximale Flexibili-tät und Kreativität.

Diese Design-Prinzipien in Kombination mit den Personas lieferten eine gute Argu-mentationsbasis, um Konzeptverfeinerun-gen, Anforderungsbeschreibungen (Epic Stories) sowie Screendesigns zu bewerten und eine konsistente Markenführung auf-zubauen. [Abb. 2]

Low Fidelity Prototyp: Klärung der Struktur

Parallel zu den Workshops der Design-prinzipien 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 Proto-typentwicklung 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ög-lich. 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 herausfin-den, welche Bedarfe die Lehrer themati-sieren, 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 Verbes-serungspotentialen empfohlen. Wir haben jedoch diese Methode abgewandelt, um auf diesem Weg herauszufinden, wie Leh-rer im Detail arbeiten und vor allem welche Hürden sie zu überwinden haben.

Abb. 3. Customer Journey Map einer Lehrer-Projektgruppe

292

In Zusammenarbeit mit der Abteilung Marketing bereiteten wir eine Tagebuch-studie 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ützungsbe-darf bei allen Gruppen in unterschiedli-cher 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 Aktua-lisierung nimmt ihnen Zeit, die ihnen an anderer Stelle fehlt.

„Für 45 min Unterricht surfe ich 2 Stun-den und nehme am Ende Material, das ich schon hatte.“

Weiterhin thematisierten sie Probleme ihrer Arbeitsweisen und Arbeitsstruktu-ren. Da sie zum Großteil allein und nicht im Team arbeiten, entstehen wenig Syner-gien. „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 Proto-typen 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 herauszufin-den, 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.

Der Stand des User Experience Design im Verlag bezieht sich derzeit auf die Grundla-genarbeit 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.

Wir haben ein Basisbewusstsein für die Notwendigkeit des nutzerzentrierten Vorgehens geschaffen und den Stakehol-dern 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.

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

direk ten Kontakt die Bedarfe in all ihrer Varianz aufzunehmen. Wir haben gelernt, dass dieses erkenntnisreiche Zusammen-treffen schon in frühen Projektphasen hätte stattfinden sollen.

Wir haben projektplanbedingt bisher nur in Ansätzen die Schüler und Eltern berück-sichtigt, dennoch ist durch die Betrachtung der Lehrerschaft der Prozess definiert. Die beiden Nutzergruppen werden im nächs-ten Projektschritt bearbeitet.

Mehr UX in Bildung!

Literatur1. http://de.statista.com/statistik/daten/

studie/201496/umfrage/anzahl-der-lehrer-in-

deutschland-nach-bundeslaendern/

2. http://de.statista.com/statistik/daten/

studie/1321/umfrage/anzahl-der-schueler-an-

allgemeinbildenden-schulen/

3. (3) Jesse James Garrett, (2012), Die

Elemente der User Experience, Addison-

Wesley Verlag, München

4. (4) http://weblogit.net/2013/04/15/10-

designprinzipien-von-dieter-rams-und-

apple-35860/

5. (5) Luke Wroblewski http://www.lukew.com/

ff/entry.asp?854

Anmerkung 1Eine sehr gute Übersicht, wann und wie Alan

Coopers Idee der Personas adaptiert wurde,

gibt folgende Infografik

http://uxmag.com/sites/default/files/uploads/

moorman-edeker-personas/personas-

timeline.png

Anmerkung 2Näheres zu Verwendung von „Design-

Prinzipien“ im Kontext von User Experience

und Usability findet man z.B. in Lennart

Hennings Beiträgen unter

http://www.usercentered.de/design/

ueber-designprinzipien/


Kurzvorträge

293

1. Überblick 1.1. Strategische Ziele & Herausforderungen

Als erstes großes Nachrichtenportal in Deutschland startet DIE WELT kostenpflich-tige Angebote im Web und findet dabei eine Möglichkeit, bestehende zahlende User der App-Produkte und andere digitale Angebote, wie die mobile Website, zu inte-grieren. Eine besondere Herausforderung bestand darin, ein funktionierendes Modell für alle Plattformen zu finden und somit einheitliche Prozesse zu schaffen.

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.

Werden die strategischen Ziele im Span-nungsfeld zwischen Business, Technik und

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.

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 losge-löst von ihren persönlichen Interessen an einem Strang zogen.

Auch bei der Beteiligung aller internen Stakeholder stellte sich die Situation

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 ausrei-chend stark berücksichtigt, dass Scrum eigentlich nur ein Vorgehen zur Entwick-lung 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 Aufga-ben und der entsprechenden Arbeitsweise vertraut gemacht werden.

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

Abstract DIE WELT startete 2012 als erstes großes Nachrichtenportal in Deutschland mit kosten-pflichtigen Angeboten im Web. Als besondere Herausforderung galt es dabei, ein funk-tionierendes 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 kosten-pflichtige App-Angebote integrieren.Bereits sehr früh war klar, dass dieses Projekt nur mit agilen Methoden technisch erfolg-reich umgesetzt werden kann. Die Wahl fiel, dem Zeitgeist folgend, auf Scrum mit User-Stories. 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öglich-keiten bieten, bei einem nach Scrum mit User Stories geplanten Projekt Usability- bzw. UX-Aktivitäten durchzuführen.

Roland Andrus

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?

294

Dadurch entstand vor der eigentlichen Umsetzungsphase zunächst eine längere Vorbereitungsphase. In dieser Phase wur-den nicht nur die noch offenen strategi-schen 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 Herausfor-derungen lassen sich ohne Probleme noch weitere solcher Fragen und daraus sinn-volle Aktivitäten ableiten. Diese Fragen können ihrerseits mit Usability-Aktivitäten beantwortet werden, wobei deren Beant-wortung nicht zu den Kernkriterien für einen Projekterfolg zählt.

2.Strukturen und Teamorganisation2.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 strategi-schen Ziele bot es sich an, die Usability-Aktivitä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äte-ren Abschnitt noch genauer eingegangen.


Kurzvorträge

Wie lassen sich die Aktivitäten der beiden Bereiche so trennen, dass ein harmoni-sches Zusammenspiel zwischen beiden Bereichen trotzdem sichergestellt ist?

Zum einen ist eine Trennung auf techni-scher Ebene möglich, indem getrennte Technik-Teams eingesetzt werden. Zum anderen handelt es sich um eine Kernauf-gabe des Produktverantwortlichen (bei Scrum der Produkt Owner), in seiner Schnittstellenfunktion sicherzustellen, dass die vorhandenen Informationen, Fortschritte und Erkenntnisse des Kernbe-reichs jederzeit an das Team des Neben-bereichs kommuniziert werden.

2.2.TeamOrganisation

Insgesamt waren ca. 150 Personen aktiv am Projekt beteiligt. Aufgrund der Umset-zung 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 Vorbereitungs-phase wurde zunächst das Technik-Team rekrutiert und die technischen Möglichkei-ten 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

Abb. 1. Verteilung der Aufmerksamkeit bei unserem Projekt

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 UX-Aktivitäten verantwortlich war.

Durch einen sehr hohen Grad an Trans-parenz und Abstimmung innerhalb des Product Owner Teams waren sämtliche Proxies fähig, stellvertretend für den eigentlichen Product Owner Entschei-dungen 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-Aktivi-täten durchzuführen. Schwerpunkte bilde-ten 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 Projektvor-bereitungsphase noch fehlende Informa-tionen 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 Ergeb-nisse erzielt werden können.

3.1.1. Interne Quellen

Ein großer Teil der Nutzungsanforderungen konnte aus den im Unternehmen vorhande-nen Informationen abgeleitet werden.

Studien zur Kundenzufriedenheit

Die interne Marketing-Abteilung konnte Erkenntnisse aus öffentlichen Studien und früheren Forschungsergebnissen gewin-nen. 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 Kon-takt zu unseren Usern der iPad App WELT HD. Dort pflegen wir bereits seit Veröffent-lichung des iPad im Jahr 2010 den Kontakt zu unseren Usern und erhalten von diesen Feedback. Auch ein Blick in die Bewertun-gen der App Stores hat sich gelohnt.

Erkenntnisse aus der eigenen Vergangenheit

Die Rekapitulation der eigenen Historie fiel ebenfalls sehr aufschlussreich aus. Im regio-nalen 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 spe-ziell 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 techni-schen Projektstart im Juni 2012 durchge-führt. Dort wurde nicht nur nach einer mögli-chen Zahlungsbereitschaft, sondern zum Beispiel auch nach Inhalten, Features und Erwartungen an unsere Produkte gefragt.

Analyse von Mitbewerbern

Ein weiterer Schritt war die Analyse inter-nationaler Mitbewerber, welche bereits seit

längerer Zeit erfolgreich mit Bezahlmodel-len arbeiten. So lassen sich die größten Stolpersteine umgehen.

3.2. Zeitraum der Umsetzung und Entwicklung

Aus Usability-Sicht haben wir uns entschie-den, 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 durchge-führt werden sollten, welche eine positive Auswirkung auf die User Experience des gesamten Produktes zeigen. Unter Kernbe-reich ist dabei das zu verstehen, was zum eigentlichen Bezahlmodell gehört – also vom ersten Erscheinen der Bezahlaufforde-rung ü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 eigent-lichen 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 Vorbe-reitungsphase 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 Bezahl-modellen ermittelt werden: – Eine größere Informationstiefe und eine individuelle Präsentation bestimmter Themen

– Nutzbarkeit von Features über alle Produkte hinweg

296

– Direkter Draht zur Redaktion – Datenschutz und Sicherheit der per-sönlichen Daten

– Geringere Fehlertoleranz bei der Nut-zung der Produkte

– Exklusive Inhalte und Features gegen-über Nicht-Bezahlern

Es galt nun, diese Bedürfnisse mit ent-sprechenden Aktivitäten im Kern- und im Nebenbereich umzusetzen.

3.2.2. UsabilityAktivitäten im Kernbereich

Scrum-Prozess maßschneidern

Mitte Juni 2012 startete die technische Entwicklung mit dem ersten Sprint. Wäh-rend 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 Proto-typen. 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:

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

Wir entschieden uns zunächst, mit der Abbildung aller Prozesse in abstrakten Wireframes zu beginnen, daraufhin mit der Entwicklung von Clickdummies fortzufah-ren und mit der Produktion von Prototypen abzuschließen. So konnten alle gesammel-ten 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 verschie-dene Kollegen testen. Beim Paper-Prototy-ping 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 Anforderun-gen 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 Vollzeit-Job entwickelt hat.

Die Prototypen wurden auch für das Erwartungsmanagement gegenüber den Stakeholdern eingesetzt

Product-Owner-Proxy-Konzeption

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 klassi-schen Wasserfall-Modell produziert. Doch durch die ständigen Veränderungen an

den Prototypen war es auch hier notwen-dig, 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 Pro-zessschritte und Plattformen, Schnittstellen und Systeme. Um eine Testabdeckung von über 80 % im Unit-Test Bereich zu errei-chen, wurden deshalb explizit Ressourcen bereitgestellt, welche die ständige Ent-wicklung von ART überwachen. Dies sorgte auch für stärkeres Vertrauen der Stakehol-der 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. UsabilityAktivitäten – Nebenbereich

Aus Usability-Sicht scheint es zunächst so, als wären wir bei einer scrum-orien-tierten Entwicklung auf Guerilla-Aktionen beschränkt gewesen.

Im Gegensatz dazu gibt es jedoch auch Aktivitäten, welche wir ganz offensiv aus-führen konnten. Diese ziehen eine Verbes-serung des Produkterlebnisses außerhalb des Kernbereichs nach sich. Davon profi-tieren 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üh-rung entstanden größere Herausforderun-gen durch die ungeplante Einführung der Product Owner Proxies und die unerwar-tete Bindung von Ressourcen im Bereich der Konzeption. Diese Ressourcen waren


Kurzvorträge

297

eigentlich für die Durchführung der Pro-duktoffensive 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öglich-keiten 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 bewer-ten. Hierbei werden bei jeder Übertra-gung 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-Pro-filen der Autoren folgen und haben somit immer die neusten Artikel dieses Autors im Blick.

Besonders viel Zulauf erfahren die Live-Chats mit Autoren. Mehrmals pro Woche stellen sich unseren Lesern abwechselnd verschiedene Autoren in einem Live-Chat. Autoren beantworten dort selektiv die inte-ressantesten Fragen zu dem Thema.

Mit dem Tool „Interaktive Karten“ werden interaktive Karten mit tagesaktuellen Infor-mationen, wie zum Beispiel den aktuellen Arbeitslosenzahlen, für die User produziert.

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 auf-gebaut, welches jegliche Kundenanfragen beantworten und Probleme unkompli-ziert lösen kann. Das Support-Team stellt außerdem den wichtigsten Rückkanal für das Feedback der Kunden zur Produktent-wicklung 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 UBoot Taktik funktioniert, aber …

Am 12.12.2012 um 12:12 Uhr wurden inner-halb weniger Stunden Bezahlmodelle für welt.de und die mobile Website ausgerollt. Die Updates für die Tablet- und die Smart-phone Apps wurden veröffentlicht. Seitdem kaufen Leser Produkte, schalten ihre Print-Abos 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 ver-steckte 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 tech-nologischen Rahmenbedingungen zeigt jedoch, dass es besonders schwierig ist, den User gleichrangig zu vertreten.

4.2. Gibt es Raum für UsabilityAktivitäten bei einem agilen Vorgehen nach Scrum?

Ja, gibt es! Allerdings würden die Aktivitä-ten bei einem Vorgehen nach Scrum-Lehr-buch 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 Entwick-lung stattfinden. Besonders wichtig ist deshalb die Dokumentation der Aktivitäten und Entscheidungen, welche während der Projektdurchführung zu einer Verschlech-terung 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.

298


Kurzvorträge

299

1. Einleitung

Seit der nach wie vor viel zitierten Untersu-chung von Jakob Nielsen zur Verbreitung und Bewertung von Usability-Methoden im Jahr 1995 haben sich sowohl Usability-Evaluations- 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. Vorgehensmo-delle zur agilen Softwareentwicklung wie XP oder Scrum, die iterative Entwicklung,

schnelle Entwicklungszyklen und Prototy-ping 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. Diskus-sion und Fazit beschließen den Beitrag.

2. Die Untersuchung von Nielsen (1995)

Nielsen führte seine Untersuchung im Anschluss an einen Workshop zu Usability-Methoden durch, den er im Rahmen der INTERCHI’93-Konferenz in Amsterdam geleitet hatte. Er verschickte Fragebögen

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

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 Professio-nals 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 Herkunftsdiszip-lin der Usability-Experten (Informatik, Psychologie, Design etc.).

Monique JanneckFachhochschule Lübeck, Fachbereich Elektrotechnik und InformatikMönkhofer Weg 23923562 Lü[email protected]

Anika RöhrichFachhochschule Lübeck, Fachbereich Elektrotechnik und InformatikMönkhofer Weg 23923562 Lü[email protected]

Usability-Methoden in der PraxisErgebnisse einer Umfrage zu Einsatz und Bewertung von Usability-Engineering-Verfahren

Methode Prozentsatz der Teilnehmer, die diese Methode nach dem Work-shop einsetzten

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

Durch-schnittliche 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

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

300

an alle Teilnehmer des Workshops. 42 Fragebögen wurden ausgefüllt; dies ent-sprach 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-stufi gen Likert-Skala (von 1= völlig unbrauchbar bis 5 = sehr brauch-bar) erfolgen. Dabei sollten nur Metho-den 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 Ein-satzhäufi gkeit zeigten sich hingegen einige Unterschiede: Der klassische Usability-Test sowie die Heuristische Evaluation wurden sowohl am häufi gsten 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äufi gkeit sind wiederum der Pluralistische Walkt-hrough sowie die Feature Inspection die Schlusslichter.

Abbildung 1 zeigt das Verhältnis zwischen der Einsatzhäufi gkeit (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äufi gkeit von knapp 4 von 10 Punk-ten auf. [Abb. 1]

Abbildung 2 zeigt analog die Relation zwischen der Bewertung der Methoden und dem prozentualen Anteil der Befrag-ten, die die jeweilige Methode eingesetzt haben. Auch hier schneiden Pluralistischer Walkthrough sowie Feature Inspection am schlechtesten ab, hinzu kommt die Heuris-tic Estimation. [Abb. 2]


Kurzvorträge

Nielsen fragte weiterhin nach der Anzahl der Evaluatoren (beim Einsatz von Inspek-tionsmethoden) bzw. der Anzahl der Test-personen (beim Usability-Test). Abbildung 3 zeigt die Ergebnisse. [Abb. 3]

Demnach folgen lediglich 35% der Befrag-ten 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 Usability-Tests 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

Abb. 1. Relation von Brauchbar-keit und Einsatzhäufi g-keit (Nielsen, 1995

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

Abb. 3. Anzahl der einge-setzten Experten und Testpersonen (Nielsen, 1995)

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 – Spezifi sche Merkmale eines individuel-len 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 Eigen-schaft eines Usability-Verfahrens die Quali-tät der Daten ist, die es erzeugt. Benutzer-tests 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 Zeitauf-wand und Benötigte Expertise bewerteten die Befragten die Heuristische Evaluation am positivsten und äußerten Vorbehalte in Bezug auf Cognitive und Pluralistischen Walkthrough.

Erwähnenswert ist weiterhin, dass offenbar die Flexibilität einer Methode im Hinblick auf veränderte Bedingungen und spezi-fi sche 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 Modifi kati-onen vornehmen.

3.Usability-Methoden 2012: Ergebnisse der Befragung

Angelehnt an die Befragung Jakob Nielsens wurde im Frühsommer 2012 eine Online-Befragung unter Unternehmen und Usability-Experten in Deutschland durchgeführt, um herauszufi nden, welche Methoden diese heute bevorzugt verwen-den und warum. 150 Unternehmen und Experten, die anhand des Portals usabi-lity-in-germany.de identifi ziert wurden, wurden per E-Mail um ihre Teilnahme an der Befragung gebeten, weiterhin wurde der Fragebogen über soziale Medien wie Twitter und Facebook verbreitet. Insge-samt 82 Personen beteiligten sich an der Befragung.

Der Fragebogen umfasste die folgenden Bereiche: – Hintergrund des Befragten (Arbeits-situation, Fachdisziplin, Erfahrung im Bereich Usability, Tätigkeitsschwer-punkte, Branche),

– Einsatzzwecke und -Bereiche für Usability-Methoden,

– Bekanntheit verschiedener Methoden und Häufi gkeit 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

nach Branchen und Fachdisziplinen vor-genommen, da sich hier einige Unter-schiede zeigten. Ebenso erfolgte eine getrennte Auswertung der Antworten von Usability-Unternehmen und freiberufl ichen Experten.

3.1.Stichprobe und Hintergrund

Knapp 60% der Befragten arbeiteten als Angestellte in einem Unternehmen, gut 40% als Freiberufl er bzw. Inhaber. Die Befragten waren überwiegend erfahrene Usability-Experten: Ca. 35% sind bereits länger als 10 Jahre in diesem Bereich berufl ich 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 Fachdiszi-plinen Psychologie, Design sowie Infor-matik/Ingenieurswissenschaften; weiterhin wurden die Bereiche Marketing, Marktfor-schung, Kommunikations- und Sozialwis-senschaften 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äufi ger genannt.

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

302

3.2. Einsatz und Bewertung von UsabilityMethoden

Die Teilnehmer wurden zunächst gefragt, wann bzw. wofür sie in ihrem Unternehmen typischerweise Usability-Methoden einset-zen. Abb. 4 zeigt die Ergebnisse. Usability-Analysen werden demnach vor allem vor dem Launch eines neuen Angebotes sowie vor einer strukturellen Überarbeitung und zur Problemanalyse eingesetzt. Zum Ver-gleich des eigenen Produktes mit Konkur-renzprodukten 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 schnei-den Aufgabenanalyse, Heuristische Evalua-tion und Rapid Prototyping am besten ab. Usability-Tests liegen – etwas überraschend – nur im Mittelfeld, ebenso wie Fragebö-gen, Cognitive Walkthrough und Fokus-gruppen. 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 Letzte-res erscheint durchaus überraschend.

Interessanterweise gibt es einige Unter-schiede 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 Unter-nehmen zum Einsatz, ebenso wie auf-wändigere Aufzeichnungsmethoden (Eye Tracking, Attention Tracking). Hinsichtlich der insgesamt am häufigsten eingesetzten Methoden – Aufgabenanalyse, Heuristi-sche Evaluation und Rapid Prototyping – gibt es jedoch kaum Unterschiede.

Auch im Hinblick auf den fachlichen Hinter-grund der Befragten sind einige Unter-schiede erkennbar. [Abb. 6] So wird die Heuristische Evaluation in den Bereichen Psychologie und Marketing viel häufiger angewandt. Usability-Tests werden beson-ders 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 Prototy-ping besonders gut bewertet. Auch Auf-gaben- und Kontextanalyse, Usability-Test, Heuristische Evaluation sowie Cognitive Walkthrough schneiden gut ab. Die übri-gen Methoden liegen im Mittelfeld.

Erneut werden Unterschiede in der Bewertung durch freiberufliche Experten bzw. Unternehmen deutlich: So werden


Kurzvorträge

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

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. 5. Auswertung der Einsatzhäufigkeit (von 1 = sehr oft bis 6 = nie)

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

303

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

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

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

3.3. Rahmenbedingungen und Kosten

Weiterhin wurden die Teilnehmer nach ver-schiedenen Faktoren bei der Methoden-auswahl – angelehnt an die Auswertung von Nielsen (1995) – befragt. Abbildung 9 zeigt die Ergebnisse. Der Erkenntnis-gewinn sowie die zugrunde liegende Fragestellung spielen somit die größte

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

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 Erkenntnis-gewinn und Fragestellung. Im Hinblick auf die Fachdisziplin fällt auf, dass die Bedeut-samkeit sämtlicher Faktoren in den Berei-chen Psychologie und Marketing höher eingeschätzt wird als im Bereich Informatik. Besonders deutlich sind die Unterschiede bei den Faktoren Kundenwunsch, Erkennt-nisgewinn und Fragestellung.

Der Faktor „Kosten“ wurde in weiteren Fragen noch etwas genauer beleuchtet. Abb. 10 zeigt die Einschätzung der Bedeu-tung 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 (Entwick-lungs-) Projekts, typischerweise kosten darf. [Abb. 11] Die Kosten liegen demnach bei 10–15% des Gesamtetats oder weni-ger. 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 Pro-jektes (z.B. Grafiker, Programmierer, usw.).

4. Diskussion und Fazit

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

Methode Freiberufler Unternehmen Gesamt

Aufgabenanalyse 2,4 2,4 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 3,2 3,2

Behavior Tracking 3,1 3,3 3,2

Heuristische Evaluation 2,8 2,1 2,5

Cognitive Walkthrough 2,4 2,5 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

Methode Informatik Design Psychologie Marketing

Fokusgruppen 3,0 3,0 2,9 2,2

Usability-Test im Labor 2,7 2,4 1,6 2,5

Rapid Prototyping 1,6 1,7 1,7 2,2

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

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

304

Verfahren differenzierte, realistische und unmittelbare Einschätzungen von Nut-zererfahrungen 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 Informa-tik 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 ver-fügbare Ausstattung (Laborräumlichkeiten,

Hardware und Software für Aufzeichnung und Analyse) sowie die Expertise des Test-leiters sein.

Unter den „klassischen“ Verfahren hat weiterhin der Cognitive Walkthrough an Bedeutung verloren. Einzig die Heuris-tische Evaluation erfreut sich weiterhin größerer Verbreitung und Beliebtheit, wenngleich auch hier Unterschiede je


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 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,3 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

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% 0,0% 0,0% 0,0% 0,0% 0,0% 0,0%

Gemessen am Gesamtetat Informatik Design Psychologie Marketing Freibe-rufler

Unterneh-men 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% 0,0% 0,0% 0,0% 0,0% 0,0% 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. 9. Faktoren bei der Methodenauswahl (von 1 = sehr wichtig bis 6 = gar nicht wichtig)

Abb. 10. Bedeutung des Faktors „Kosten“

Abb. 10. Kosten einer Usability-Analyse

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 einge-setzt. 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 Fragebogenver-fahren, wenngleich hier mittlerweile eine große Zahl standardisierter und erprob-ter 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 Usability-Analysen aber möglicherweise häufig eine kleinere, klar umgrenzte Zielgruppe untersucht wird.

Im Gegensatz zu den „klassischen“ Evalu-ationsverfahren gewinnen Methoden aus dem Requirements- bzw. Usability-Engi-neering an Bedeutung, wie die Aufgaben- und 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 Optimie-ren, um bereits im Vorfeld potenzielle Usability-Probleme zu vermeiden und damit die Kosten im Entwicklungspro-zess 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 Benut-zerbeteiligung und somit eine Verflechtung des Software-Engineering-Prozesses mit Usability-Engineering-Methoden propa-gieren. Interessant ist in diesem Zusam-menhang, dass diese Methoden nicht nur

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, darun-ter insbesondere die Prüfung auf Barriere-freiheit, 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 Methodenwerkzeug-koffer der Usability-Professionals verändert sich. Dass vor allem Methoden mit hinein kommen, die einen starken Usability-Engi-neering-Bezug haben und somit Benutz-erbeteiligung vorantreiben, ist aus unserer Sicht positiv zu bewerten.

Literatur1. Nielsen, J. (1995). Technology Transfer of

Heuristic Evaluation and Usability Inspection.

Alertbox: June 27, 1995. http://www.

nngroup.com/articles/technology-transfer-of-

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

306


Kurzvorträge

307

Einleitung

Wäre es nicht angenehm, in der Zukunft nicht nur Bücher oder eBooks zu lesen, sondern die multimedialen Möglichkei-ten 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 statt-findet, 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. Vergli-chen 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.

Warum sollte das Nutzungserleben bei Serious Games gemessen werden?

Serious Games sind wie beschrieben Videospiele, in denen Spieler nicht aus-schließlich spielen, sondern sich gleich-zeitg weiterbilden. Die Spiele vermitteln die zu lernenden Inhalte beispielsweise über die Hintergrundgeschichte und ihre Handlungsabläufe, wodurch die Grenzen zwischen Lern- und Spielinhalten ver-schwimmen. In den Momenten, in denen im Spiel die Lernsituation für die Spielen-den 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

unbewusst bleiben und bei den Spielen den konzentrationsfördernder Flow ent steht (Fritz, 1997). Wird negative User Experience gemessen, ist der Flow folglich ein schwer zu erreichender Zustand. Ist es gegentei-lig doch möglich geworden, dass Spieler das Flow-Erlebnis erlangen, entsteht ein Entwicklungs- oder Lernprozess (Csíkszent-mihály, 1992, S.70f). Eine hohe gemessene UX kann also auf entstehenden Spielflow und damit auf einen erleichterten Lern-prozess in dem Serious Game hindeuten. Diese Hinweise bilden für die Entwicklung und für die kontinuierliche Verbesserung eines Serious Games eine fundierte Grund-lage 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 Benut-zen eines Produkts resultieren aus einem Gefühl, welches sich einstellt, sobald Frustration oder Erfüllung von Grundbe-dürfnissen erlebt wird. Dieses rangiert auf

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

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 Schwierigkeits-grad sowie Sound und mehr. Diese Valenzen wurden retrospektiv besprochen, indexiert und nach Häufigkeiten gewichtet ausgewertet. Der Einsatz von Valenzen für die UX-Mes-sung 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.

Insa WulfHochschule der Medien [email protected]

Dr. Huberta KritzenbergerHochschule der Medien [email protected]

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

308

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.

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 durf-ten 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 Spiel-raums verschieden verläuft. Diese Freiheit ist Teil des Spielerlebens.

Nach einer Einleitung wurde den Teilneh-mern von einem Moderator der Valenz-marker vorgestellt, mit dessen Hilfe die Teilnehmer bei einem positiv oder negativ erlebten Merkmal Wertigkeiten anzeigen können, dieser ist in Abbildung 1 darge-stellt. 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 Com-putersspiels, 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, Schrei-ben 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


Kurzvorträge

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 Blickbewe-gungen des Spielenden mittels Eyetracker sowie der Valenzmarker mit einer weiteren Videoaufnahme aufgenommen. [Abb. 1]

In einer anschließenden retrospektiven Befragungsphase betrachteten der Teil-nehmer 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 Videonachbespre-chung orientiert sich an dem Retrospecti ve 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 even-tuell 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 anwan-den, 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 aus-wirken könne. Während der retrospektiven Befragungsphase des Serious Games wur-den außerdem ausdrucksstarkes Verhalten und Mimik besprochen, wie zum Beispiel Lachen oder spontane Ausrufe der Spielen-den, welche der Moderator während der Spielphase notiert. Diese Stellen wurden bei der Videonachbesprechung zusätzlich zu den Markern thematisiert, um herauszu-finden, 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 Bewusst-sein verschmelzen und so ihre komplette Aufmerksamkeit auf das Spiel lenken, so dass sie sich nicht mehr selbst reflektie-ren 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ög-lichen Fall nicht durch eine Erinnerung

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

309

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

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

abzugleichen. Daher besprachen Modera-torin und Teilnehmer in der RTA die Eigen-schaften der Elemente des Serious Games, welche veranlasst hatten, den Valenzmar-ker zu drücken. Wenn es die Spielsituation zulaß, verglichen sie diese Spielelemente außerdem mit anderen bereits gespielten Computerspielen, aus denen die Spielen-den ihre Erfahrungswerte gebildet hatten.

Wie wurde ausgewertet?

Die Ergebnisse der retrospektiven Befra-gung wurden in Tabellen protokolliert. Diese wurden segmentiert, orientierend an den von den Teilnehmern gesetzten Markern. Um darzustellen, welche Seg-mente ä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 darge-stellt wird. Die Index-Nummern generie-ren 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 negati-ver 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

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

310

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 Spielsi-tuation 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 defi nieren 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.

Insgesamt war festzustellen, dass „Winter-fest“ 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), konn-ten von den Testpersonen überwiegend in dem Serious Game wiedergefunden werden. Allerdings identifi zierten sie einige Spielsituationen so, dass die Situationen als für Kinder passender wahrgenommen wurden. Weitere gesetzte Valenzen deute-ten darauf hin, dass die Geschichte nicht

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

Aus dieser Beobachtung kann geschlossen werden, dass es wichtig ist, die typischen Merkmale des jeweiligen Genres beson-ders stark in einem Serious Game aus-zuprä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 wer-den, wodurch die Lern- und Spielsituation bewusst und Flow unmöglich wird. [Tab. 1]


Kurzvorträge

Abb. 3. Tabelle mit thematisch geordneten Indizes

311

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 Dokumenta-tion wurde es möglich, diese UX-Merkmale nach Häufigkeiten auszuwerten, was eine Bewertung vereinfachte. Ebenso konnten die UX-Merkmale sowie ihre übergeord-neten Themen qualitativ evaluiert wer-den. Dies gab Aufschluss darauf, welche UX-Merkmale im Zusammenspiel mit den Erwartungen an das Genre die Entwick-lung des Spielflows bestimmten, sowie in welchem Maße gefördert oder gehindert haben.

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

M. (2011): Studien zur formativen Evaluation

der User Experience mit der Valenzmethode.

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

Visionen der Mensch-Maschine-Interaktion –

Aus der Vergangenheit lernen, Zukunft

gestalten. 9. Berliner Werkstatt Mensch-

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

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

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

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.

4. Fritz, J. (1997): Zwischen Transfer und

Transformation. Überlegungen zu einem

Wirkungsmodell der virtuellen Welt, . In J.

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

Computerspiele – Theorie, Forschung, Praxis

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

politische Bildung.

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

(UX): Towards an experiential perspective on

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

2008, Metz, France, 11–15.

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, 03290630, 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

312


Kurzvorträge

313

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 Geschichten-erzä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äh-ler 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 Ver mittlung von Inhalten über Geschich-ten kann auch für den UX Designer ein wichtiges und wirkungsvolles Instrument darstellen.

Geschichten, die von den Umständen und der Art und Weise erzählen, wie Nutzer mit einer geplanten Anwendung umge-hen, 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 Nut-zer einer Anwendung, Anforderungen und Anwendungsziele zu definieren und anderen zu vermitteln.

– Sie erklären und helfen dabei, Men-schen kennenzulernen und zu verste-hen, die nicht genauso sind wie wir.

– Sie geben analytischen Daten ein menschliches Gesicht.

– Sie können zu neuen Designkon-zepten ermutigen und Innovationen motivieren.

– Sie fördern ein gemeinsames Verständ-nis 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äg-ten Eigenschaften und einem konkreten Nutzungsverhalten detailliert beschrieben.

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

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 prak-tischen 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.

Kinga KujatSenior User Experience DesignFinowstr. 1112045 [email protected]

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

314

Um die Personas einer Anwendung zu defi -nieren, 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. (Wiki-pedia, 2013)

Da unterschiedliche Menschen die An wen-dung nutzen werden, steht eine Persona jeweils für für eine Gruppe von Nutzern. Alle Personas gemeinsam sollen die Gesamtheit aller möglichen Nutzer abde-cken. [Abb. 1]

Als Beispiel soll eine Nutzer-Persona für den Online-Shop eines Bekleidungsdar-stellers 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 verschrie-ben hat. Modisch ist sie sehr interessiert und möchte schon aus berufl ichen Grün-den 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


Kurzvorträge

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 Anwen-dungsschritt, die User Story ist somit kurz gehalten und umfasst in der Regel nicht mehr als zwei Sätze. (Wikipedia, 2013)

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-Mail-Adresse“ 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

eines fachlich relevanten Zieles ab. (Wiki-pedia, 2013)

Ein Use Case erzählt somit die Geschichte, in der der Nutzer mit einer konkreten Ausgangslage beginnt und ein bestimm-tes 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:

Karin ist berufl ich 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 bekom-men. Sie ändert die Lieferanschrift ihrer Bestellung entsprechend auf die Adresse ihres Hotels.

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 beschrie-ben und erste konkrete Beispiele für eine

Abb. 1. User Personas

Abb. 2. Use Case und User Stories

315

Persona, einen Use Case und eine User Story genannt.

Um den praktischen Einsatz von Story-telling 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 Auf-gabenstellung eine erste, grobe Software-Anforderung die im nachfolgenden verfeinert werden soll. Nach der Untersu-chung von Ziel-Nutzergruppen und der Definition von Personas werden Geschich-ten 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

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

Welche Funktionalitäten sind zu integrieren?

4.2. Die Persona

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.

4.3 Der Use Case

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

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 Soft-ware sind: – Mobiler Login in Kundenkonto – Aktuelle Bestellungen mit Status mobil einsehbar

– Abändern von Bestelldaten ermöglichen

– Versand von Bestätigungen per E-Mail

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

Ux: Design and Research in a Connected

World. Burlington, Massachusetts: Morgan

Kaufmann

3. User Story. In: Wikipedia, Die freie

Enzyklopädie (2013). Online in Internet:

URL: http://de.wikipedia.org/wiki/User_Story

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

Online in Internet: URL: http://de.wikipedia.

org/wiki/Persona_(Mensch-Computer-

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)

316


Kurzvorträge

317

1. Usability von Anwendungssoftware

Klassische Usability im Sinne der Optimie-rung von Bedienabläufen ist neben den Experience-Ansätzen der letzten Jahre eher in den Hintergrund getreten. Wer-den statt der Interaktion mit technischen Produkten, die in allen Lebensbereichen eingesetzt werden und vermehrt Unterhal-tungszwecken dienen, komplexe Anwen-dungen 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-Ressource-Planning) sind für diese betriebliche

Anwendungssoftware ein typisches Bei-spiel. Sind es kleine und mittlere Unter-nehmen, die diese Softwareprodukte entwickeln, ist die Abgrenzung zu konkur-rierenden, funktionsähnlichen Produkten durch Argumente wie Anwenderfreundlich-keit eine gute Möglichkeit, Kunden lang-fristig 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 vernach-lässigender Faktor. Ungenügende Usability hat einen starken Einfluss auf die Kosten der Einführung von Anwendungssoftware (Kneissl, 2006), was besonders Mittelständ-ler zu spüren bekommen. Die in Deutsch-land eingesetzte betriebliche Anwendungs-software entspricht allerdings zu einem Großteil (80%) nicht den Anforderungen,

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 Rei-fegrades 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, entspre-chende Tools und/oder Ressourcen zur Ver-ankerung dieses Themas vorhanden sind. Evaluationsmethoden, die zum Aufdecken von Fehlentwicklungen und der Produktop-timierung wichtig wären, kommen kaum zum Einsatz (Woywode et al., 2011).

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 Anwenderbefra-gung sowie eines Usability-Tests konnten die Hauptschwierigkeiten der Verfahren identifi-ziert werden. Zum einen bedarf es aufgrund der an spezifische Anwendungsbereiche angepassten und meist hoch komplexen Strukturen der Software eines erheblichen Ein-arbeitungsaufwandes für den Usability Professional. Zum anderen kann ohne Einbindung des Anwendungskontextes eine Beurteilung nur anhand von allgemeingültigen Richtlini-en 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 betriebli-cher 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 anwendungsspe-zifischen Verfahrens besser in die Software-Entwicklung einbeziehen lassen.

Nina BärTechnische Universität Chemnitz, Institut für Psychologie,Professur Allgemeine und Arbeitspsychologie09107 [email protected]

Susen DöbeltTechnische Universität Chemnitz, Institut für PsychologieProfessur Allgemeine und Arbeitspsychologie09107 [email protected]

Thomas SeelingTechnische Universität Chemnitz, Institut für MaschinenbauProfessur Arbeitswissenschaft und Innovationsmanagement09107 [email protected]

Frank DittrichTechnische Universität Chemnitz, Institut für MaschinenbauProfessur Arbeitswissenschaft und Innovationsmanagement09107 [email protected]

Zur Notwendigkeit anwendungs-spezifischer Usability-Verfahren für betriebliche Software

Keywords: /// Usability-Methoden/// betriebliche Anwendungs-

software/// ERP-System/// Experten-Evaluation

318

Betriebliche Anwendungssoftware ist oft durch überladene Oberflächen gekenn-zeichnet, in denen komplizierte Prozesse und Arbeitsaufgaben mit einer Vielzahl von Funktionen zusammentreffen. Damit treten verstärkt Probleme in den Bereichen Auf-gabenangemessenheit und Erlernbarkeit auf und sorgen für hohen Support- und Schulungsaufwand auf der Seite des Soft-wareherstellers. 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 Überarbei-tungen der Software zu akzeptieren.

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 Entwick-lungsprozess vollzogen. Das Angebot maßgeschneiderter Software-Lösungen für den Kunden stellt ein wichtiges Ver-kaufskriterium dar, birgt aber auch gewisse Gefahren für die Usability des Produktes. Jeder Kunde hat aufgrund firmeninter-ner Routinen und Arbeitsweisen andere Ansprüche an aufgabenangemessene Funktionsweisen der Software. Die Anpas-sung 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 Kunden-zufriedenheit sind. Oft entstehen so Ver-änderungen an Elementen der Software, die als einheitliches Grundgerüst für eine optimale Bedienbarkeit konsistent enthal-ten sein sollten.

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


Kurzvorträge

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

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

Als Ausgangsbasis zur Anpassung ein-schlägiger Usability-Methoden an spezifi-sche 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 umfangrei-che 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 Usabi-lity-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 Verbesse-rungspotentials der Software setzt (Molich & Dumas, 2008). Usability Professionals können nie sicher ausschließen, ob ein vermeintliches Usability-Problem in einer spezifischen Eigenheit des Anwendungs-kontextes 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 Software-Hersteller nur bedingt nutzbar. Molich & Dumas (2008) fordern diesbezüglich ein selektiveres Vorgehen von Usability-Profes-sionals bei der Rückmeldung von Evalua-tionsergebnissen aus Experten-Reviews, da nur so eine Verwertbarkeit von Ergeb-nissen auf Seiten der Entwickler gegeben ist. Für stark spezialisierte Anwendungen eignen sich Experten-Reviews eher weni-ger (Bias & Mayhew, 2005).

2.2. Anwenderbefragung

Als nächster Schritt wurde eine online-basierte 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 Erfordernis-sen der Arbeitsaufgaben zurückblicken und entwickeln kontextbezogene Strategien, wodurch sie von Usability-Experten iden-tifizierte Probleme unter Umständen nicht als solche ansehen. Andererseits lassen sich spezifische Probleme der jeweiligen Anwendergruppe von Usability-Professio-nals 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 Experten-Reviews konnte stärker auf unterschiedliche Usability-Probleme einzelner Anwender-gruppen eingegangen werden. Nach den bisherigen Erfahrungen erledigen viele Anwender – wenn auch minimale Aufgaben – in einer Vielzahl von Funkti-onsbereichen der betrieblichen Anwen-dungssoftware, was sich trotz geringer

319

Nutzungsintensität stark auf die Usability-Bewertung auswirken kann. Zusätzlich zu den angepassten Fragen wurde in der Anwenderbefragung eine Variante des standardisierten Fragebogens ISO-Metrics (Gediga, Hamborg & Düntsch, 1999) ver-wendet. So konnte sowohl eine standardi-sierte Bewertung des Gesamtsystems als auch eine spezifische Bewertung der vom Anwender hauptsächlich genutzten Funk-tionen 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 durch-schnittlichen Alter von 41 Jahren und einer Erfahrung mit der ERP-Software von im Mittel 4 Jahren. Es fielen vor allem Wech-selwirkungen zwischen den Bedingungen der Systemeinführung im Anwenderunter-nehmen 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 betriebli-che 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 Bewertungs-grundlagen zu den Einzelurteilen führten, aus denen sich die Gesamtbewertung zusammensetzt. Sonstige unbekannte Einflussfaktoren auf die Nutzerzufriedenheit im Unternehmen spielen für die Gesamt-Usability-Bewertung eventuell auch eine Rolle, sind aber in ihrer Vielzahl schlicht nicht ganzheitlich zu erfassen. Individuelle Faktoren, welche die Art der Aufgaben-bearbeitung beim Anwender beeinflussen können, wie beispielsweise Lernstrategien, lassen sich aufgrund ihrer Vielfältigkeit auf standardisiertem Wege ebenfalls kaum abfragen. Ein Vorteil von Anwenderbefra-gungen besteht in der Möglichkeit, die für die Anwender bekannte Sprache des Systems in standardisierter Form anzuwen-den und daher die Bewertung einzelner Funktionen konkret zu unterstützen.

2.3. UsabilityTest

In einem Usability-Test (N = 15) wurden gezielt typische Aufgaben mit Nutzern aus verschiedenen Unternehmen quali-tativ untersucht. Bei der Konzeption und Ausformulierung der Aufgabenstellungen ist aufgrund des umfassenden Funktions-angebots der ERP-Software und einer Vielzahl verschiedener firmeninterner und -übergreifender Anwendergruppen erneut umfassendes domänenspezifisches Wissen nötig. Durch die beiden voran-gegangenen Erhebungen und die starke Einbindung des Herstellers konnte ein Set von vier Pflichtaufgaben und vier optio-nalen Aufgaben erstellt werden. Jeder Nutzer hat spezifische, partielle Erfahrung mit dem System und kann somit nur zu einigen Funktionen eindeutige Usability-Einschä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 demografi-schen 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 unter-nehmensspezifischen 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. Zeit-ersparnis) 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 vor-gaukelt. 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 unternehmens- und/oder branchenspezifische Fachtermini verwendet werden. Für den Hersteller stel-len diese Kommentare aber eine reichhal-tige Informationsquelle dar.

3. Schlussfolgerungen und Future Work

Die beschriebenen Studien zur Usability-Evaluation lieferten erste Ergebnisse zur Anwendbarkeit herkömmlicher Usability-Methoden für spezifische Anwendungs-software. Um die Gebrauchstauglichkeit im Bereich betrieblicher Anwendersoftware wie ERP-Systemen zuverlässig zu beurtei-len, sind die etablierten Usability-Metho-den wenig effektiv. Eine Usability-Prüfung durch Professionals ohne Einbindung des spezifischen Anwendungskontextes, d.h. Hersteller- und Nutzersicht, kann letztendlich nur anhand von allgemeingül-tigen Richtlinien erfolgen. Dies hat eine geringere Güte der gewonnen Ergeb-nisse zur Folge und macht die Methode deutlich weniger effektiv. Eine Anpassung von Usability-Methoden an spezifische Anwendungsbereiche ist daher notwendig. Perspektiven von Usability-Experten, Her-stellern 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

320

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

Anhand der oben beschriebenen Schwie-rigkeiten bei der Anwendung etablierter Methoden, wird ein Online-Tool konzipiert. Es soll Usability-Expertenwissen mit dem Wissen der Anwender und Hersteller ver-knüpfen. Die Hersteller sollen dabei aktiv bei der Formulierung von Aufgabenstel-lungen und Testung ihrer Kundengruppen eingebunden werden. Dabei stellt sich die Notwendigkeit eines Ansprechpartners des Herstellers, der den jeweiligen Anwen-dungskontext genau kennt und umfassen-des 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 nied-rigschwellige Möglichkeit der Usability-Evaluierung für kleine- und mittlere Unter-nehmen darstellen. Es soll KMU zudem die Möglichkeit bieten, Usability verstärkt in ihren Entwicklungsprozess einzubin-den. 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 Pilotpart-nern langfristig zur Verfügung gestellt und getestet werden.

Literatur1. Bias R. & Karat C.M. (2005). Justifying cost-

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

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-

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


Kurzvorträge

321

1. Einleitung

Der Usability Test wird von manchen für die wichtigste aller Evaluierungsmetho-den 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 vonei-nander die selbe Webseite, Web-Anwen-dung 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.

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 Minimalan-spruch bei der Erstellung von Usability Reports hinweisen?

– Welche Merkmale machen einen Test-bericht 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, herauszufin-den, ob ein „Evaluator Effect“ existiert. Dieser besagt, dass auf der Grundlage derselben Daten mehrere Experten

unterschiedliche Usability Probleme imsel-ben System finden. Mehr Informationen zur CUE-Reihe sind auf der Webseite von DialogDesign zu finden (1).

Jeder der Teilnehmer erhielt im Vorfeld die-selben 5 Videos von Usability Test Sitzungen zur unabhängigen Auswertung. Grundlage der Studie war eine gemeinsame Evaluie-rung der Webseite der US-amerikanischen Firma U-Haul, www. 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

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

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 Ame-rika 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

Lisa DaskeAstrum IT GmbHAm Wolfsmantel 291052 [email protected]

Usability Testberichte gebrauchstauglicher machen Usability Testberichte aus der CUE-9 Studie im Vergleich

322

am 11. September 2011 in Chemnitz, Deutschland (CUE-9b). In Atlanta nahmen dabei 19 Usability Experten teil, in Chem-nitz waren es 16 Teilnehmer. In einem weite-ren Beitrag von Rolf Molich und Lisa Daske im vorliegenden Tagungsband fi nden sich Details zu den Ergebnissen der Studie

Die im Rahmen der Studie erstellten Test-berichte wurden veröffentlicht und können online eingesehen werden (2)(1). Für den vorliegenden Beitrag wurden diese Test-berichte verglichen, um nach Gemeinsam-keiten und Auffälligkeiten zu suchen. Der Fokus ist dabei weniger eine wissenschaft-liche Auswertung. Vielmehr wurde die seltene Chance genutzt, dass als „Neben-produkt“ der Studie vergleichbare Auswer-tungen 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.

3.Best practices

Dieser Abschnitt zeigt die gemeinsamen Eigenschaften eines Testberichts, die in allen oder den meisten Berichten vorhan-den waren.

3.1.Executive Summary

Der Testbericht zu einem Usability-Test hat zwei Zielgruppen: einerseits dient der Bericht als Arbeitsergebnis für den Auf-traggeber, andererseits als Arbeitsgrund-lage 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 Zusam-menfassung 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 fi nden, sondern zum Teil hinter einleitenden Abschnitten zur


Kurzvorträge

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

Abb. 2. Beispiel für eine be-sonders übersichtliche Zusammenfassung

323

Methodik und damit schwerer aufzufi nden. Eine solche Zusammenfassung gehört zu den „best practices“, die in CUE-9 beob-achtet werden konnten. Die Länge der Zusammenfassung variierte von wenigen Stichpunkten bis zu vier Seiten, der Durch-schnitt lag bei 1,5 Seiten. [Abb. 1] Abbil-dung 2 zeigt eine besonders übersichtliche Zusammenfassung. [Abb. 2]

Aus der Analyse der Testberichte konn-ten folgende Eigenschaften abgeleitet werden, die eine gute Executive Summary kennzeichnen: – Die Zusammenfassung sollte kurz sein; 69% der untersuchten Berichte enthiel-ten eine Zusammenfassung von einer Seite oder weniger Länge.

– Die wichtigsten Probleme sollten genannt werden.

– Das Ergebnis zählt – Ausführliche Infor-mationen zur Methode, den Teilneh-mern, etc. gehören nicht in die Zusam-menfassung und auch nicht davor

3.2.Visualisierung von Problemen mit Hilfe von Screenshots

Screenshots sind eine der wichtigsten Möglichkeiten, dem Nutzer Probleme

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 aufl istet. Im Gegenteil ist es wichtig, dass der Usability Professional die berichteten Probleme priorisiert und Unwichtiges ausfi ltert; denn gerade deswegen wird ein Experte engagiert.

Die höchste Zahl der berichteten Prob-leme 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 besei-tigt habe, können sie gerne zu mir kom-men um mehr Resultate zu bekommen.“

3.4.Beschreibung der Usability Probleme selbst

Entscheidender als die Anzahl der Prob-leme 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 Über-zeugungskraft des Berichts und damit die Wahrscheinlichkeit, dass Probleme auch beseitigt werden.

Wie die Diskussion im Rahmen der Work-shops zeigte, waren einige der in CUE-9 beschriebenen Usability Problemefür andere Teilnehmer schwer oder gar nicht verständlich odergespickt mit Recht-schreibfehlern. Ein Beispiel hierfür ist

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

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

324

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. Usabi-lity 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 CUE-9, siehe (3)).

Viele Berichte führten als Problembeschrei-bung nur Beobachtungen auf, beispiels-weise „participant is searching the faq“. Merkmal eines guten Berichts und Grund, einen Experten zu engagieren ist aber gerade, dass dieser das zugrundelie-gende Problem herausarbeitet, eventuell sogar mit einem Hinweis auf eine mögli-che Lösung. Ein Beispiel für eine solche Auswertung ist in Abbildung 7 zu sehen. [Abb. 7]

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 „Wor-ding and Text“

4.Weitere Gestaltungsmöglichkeiten – so begeistert ein Bericht

Es gibt viele weitere Möglichkeiten, einen Testbericht so zu gestalten, dass er


Kurzvorträge

Abb. 5. Anzahl gefundener Probleme

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

325

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: Nie-mand 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 bei-tragen, dass die Testergebnisse akzeptiert

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 Beobachtun-gen hervorhebt. [Abb. 8]

4.2.Aufbereitung der Resultate

Um das „Scannen“, also das Querlesen eines Berichts zu erleichtern, können die Beschreibungen der einzelnen Usability-Probleme strukturiert werden. Ein kurzer

Titel hilft dabei, das Problem zu identifi zie-ren. Bei der Beschreibung des Problems ist es wichtig, dass die Auswirkung auf den Nutzer klar wird. Abbildung 9 zeigt ein Bei-spiel für eine besonders gut strukturierte Problembeschreibung in tabellarischer Form. [Abb. 9]

In einigen Berichten wurde der Schwere-grad eines Problems darüber hinaus mit Hilfe von Icons und/oder Farben visuali-siert. [Abb. 10] Dies machte die Berichte übersichtlicher und sehr viel leichter zu überfl iegen.

Abb. 7. klare Beschreibung von Beobachtung, zugrunde-liegendem Problem und Empfehlung

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

Abb. 9. Ein gut strukturiertes Resultat mit Titel, Pro-blembeschreibung und durch Auswirkungen auf den Nutzer begrün-dete Klassifi zierung

326

4.3.Zitate

Einige Teilnehmer setzten Zitate der Teil-nehmer 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 fi elds for boxes are pre-fi lled? You are sneaky!“.

4.4.Ergebnislisten

Einige Berichte enthielten eine tabellari-sche 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 gestalte-tes Exemplar. [Abb. 12]

5.Fazit

Gerade als Usability Experte sollte man darauf bedacht sein, besonders die eige-nen 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 Testbe-richten 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 Auftragge-ber nützlich ist. Besonders visuelle Hilfsmit-tel wie Screenshots und Farbcodierungen spielen dabei eine große Rolle.Natürlich hat diese Untersuchung aufgrund der rein


Kurzvorträge

Abb. 10. Visualisierung des Schweregrads mit Icons

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

327

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.

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

Abb. 12. Eine besonders übersichtliche Arbeitsliste

328

Bewusst. Unter-bewusst. Unbewusst.

329

Einleitung

In dieser User Experience Studie mit Emo-tionsmessung wurden zwei Online Shops aus dem Bereich Mode und Tech nik anhand einer User Studie im Lab mit echtem Shop-ping 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

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

sollte eine Seite sein, auf der eher Frauen einkaufen und Saturn eine eher von Män-nern 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 Technik-Website surften. [Tab. 1]

Stichprobe

Die Probanden waren im Schnitt 39 Jahre alt (zwischen 25 und 50 Jahren) und größten-teils berufstätig. Sie sind im Schnitt seit 8 Jahren online und täglich oder mehrmals in der Woche im Internet. Sie kaufen mindes-tens einmal im Monat oder sogar wöchent-lich online etwas ein. Alle nutzen PayPal.

– 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, Cyber-port, 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.

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

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.

Sabrina Dudausers’ delight GmbHNeumagener Str. 2913088 [email protected]

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

Website Zalando (Mode): www.zalando.de

Website Saturn (Technik): www.saturn.de

N = 4 Frauen N = 4 Frauen

N = 4 Männer N = 4 MännerTab. 1. Versuchsdesign

330

Amazon wurde von einem User als über-sichtlicher 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 bes-ser, weil es lokal sei: „Ich brauche persönli-chen 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 Produk-ten 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 Web-site – Zalando oder Saturn – geöffnet wor-den 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 unbeein-flusst sein sollte, wurde kein Zeitdruck aus-geübt. Bei insgesamt drei Nutzern ist aus



Zeitgründen auf das gemeinsame Betrach-ten 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 lie-fern ließen (in zwei Fällen auch zur Abho-lung 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 Aus-nahme der Ratings – waren Beobachtungs-daten oder qualitative Daten wie Verhal-tensbeobachtung, Vor- und Nachinterview und Videokommentare.

Das EEG Gerät misst Excitement, Enga-gement, 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]

Website Zalando (Mode): www.zalando.de

Website Saturn (Technik): www.saturn.de

N = 4 Frauen N = 4 Frauen

N = 4 Männer N = 4 Männer

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.

Tab. 2. Untersuchungs ablauf

Abb. 1. EPOC Control Panel

Abb. 2. EEG Kurven Excite-ment, 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 soll-ten. 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.; Bornkessel-Schlesewsky, I.; Schlesewsky, M.; 2013, die Lesen auf klassischem Papier vs. digitalen Medien vergleicht und EEG und Eyetra-cking 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).

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 insge-samt etwas mehr Geld ausgegeben als auf Zalando. [Tab. 3]

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]

Wie wurde das Einkaufserlebnis bewertet?

Persönlicher Bezug Saturn polarisiert, Zalando scheint eher beide Geschlechter anzusprechen. [Abb. 6]

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

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

332

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

Bewertung WebsiteDie Frauen bewerten beide Websites bes-ser 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, Produkt-suche, Bestellprozess.

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 identifi ziert, welche „Persönlichkeit“ die Website hat und welche Zielgruppe aus Sicht der User angespro-chen 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 anzu-nehmen, 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.

SaturnDer Saturn Website Mensch wäre männ-lich, 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, technikaffi n, eher oberfl ächlich, aber eigentlich doch sym-pathisch. 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. 8. Bewertung Website (Rating von 1= sehr schlecht/sehr wenig bis 5 = sehr gut/sehr viel)

Tab. 4. Gesamtbewertung UX

Gesamtbewertung UX

Saturn ZalandoMänner 3,33 3,13

Frauen 4,13 4,17

Abb. 9. Website Saturn als Mensch

Abb. 10. Website Zalando als Mensch

333

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

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.

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

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

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

Fazit

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 glei-chermaß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

Emotional Shopper Diese Userin shoppt insgesamt ca. 12 Mi -nu ten. 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 Kurvenaus-schlä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 Son-nenbrille 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]

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 erfolg-los nach einem Parfum. Als sie wieder bei den Accessoires ist, sagt sie: „Also Acces-soires 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]

Sie ist nun wieder bei den Taschen und nach einer Zeit entdeck sie die Adidas-Umhängetasche: [Abb. 15]

Sie sieht sie sich kurz im Detail an und sagt: „Die nehm‘ ich“. Sie kauft eine

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

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 aus-sieht 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.“

Die Userin erzählt: „Internetbestellun-gen 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 empfun-den; 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 Formularfel-der 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 Passwortein-gabe 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: Aus-wahl der Zahlungsart

336

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 Abbil-dungen 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 Filterset-zen 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 Vor-gang durch ein Popup verhindert. Man sieht, dass das ein wenig Stress verursacht, da die Kurve in diesem Moment ansteigt: [Abb. 23]

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

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

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

von Bildern und Inspirationen beeinflus-sen. 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 Zalando: Merkwürdiges Suchergebnis

338

EEG Bild ist weniger bewegt. Die Engage-ment Kurve ist oben. Er ist engagiert bei der Sache, lässt sich aber emotional nicht mitreißen. Es gibt auch noch den Typ „rou-tinierter 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, Produktaus-wahl und Eingrenzung ist eine Herausfor-derung 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 Produkt-suche. Es sollte mehr Sortiermöglichkeiten geben in Form von Filtern oder Unterka-tegorien. Ein Preisregler ist an sich gut, wirft aber nicht immer Ergebnisse ab und wird meistens nicht sofort von den Usern entdeckt. Kategorien wie Sales, Neuigkei-ten 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 Produkt-bewertungen 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 Sor-tierfunktion. 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äte-ren 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än-gelten, 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 Expe-rience 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 ereignisbezo-gen 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 zeig-ten sich Unterschiede bei Männern und Frauen.

EEG sollte immer mit anderen Metho-den 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 Datener-hebung und verhindern, dass das EEG tatsächlich mit den interessierenden Ereig-nissen 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 Datenerhe-bung 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 mindes-tens 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.

Das EEG misst teilweise Daten, die auch mit anderen Neuromethoden wie Haut-leitwert 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 Folgeuntersu-chungen mit größeren Stichproben und unterschiedlichen Websites, um Unter-schiede 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 Heran-gehensweise haben, lassen sich oft sehr interessante Erkenntnisse gewinnen. Durch den Aufwertungsaufwand bei diesen Stu-dien sind der Stichprobengröße allerdings Grenzen gesetzt.

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

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

Testmethode. Unveröffentlichte

Diplomarbeit, Fachhochschule Technikum

Wien

340

Usability/ UX Testing

341

1. Einleitung

Um die Usability von Systemen zu verbes-sern, muss die Usability dieser Systeme zuerst bewertet werden können. Dafür wer-den verlässliche und robuste Evaluierungs-methoden 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 („Compa-rative Usability Evaluation“, zu deutsch „Vergleichende Usability Evaluierung“).

Bei jeder CUE-Studie evaluieren Teams aus Usability Professionals unabhängig voneinander die selbe Webseite, Web-Anwendung oder Software. Das Hauptziel der Studien ist es, genug Daten zu sam-meln, um unter anderem folgende Fragen zu beantworten:

– Ist das Ergebnis von Usability Evaluie-rungen 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, herauszufin-den, ob ein „Evaluator Effect“ existiert. Dieser besagt, dass auf der Grundlage der selben Daten mehrere Experten unter-schiedliche Usability Probleme im selben System finden. Mehr Informationen zu CUE-Reihe finden Sie auf der Webseite von DialogDesign (1).

Bei einem gemeinsamen Workshop trafen sich die Studienteilnehmer (getrennt in Deutschland und Amerika), um ihre Ergebnisse zu vergleichen und zu diskutie-ren. 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 Chem-nitz 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 Evaluie-rung der Webseite der US-amerikanischen Firma U-Haul, www.u-haul.com, die LKWs an Privatpersonen zu Umzugszwecken ver-mietet. Den Studienteilnehmern wurden folgende Aufgaben gestellt: – Fünf Videos zu je 30 Minuten aus Usa-bility Tests ansehen und bewerten

– Einen kurzen, anonymen Testbericht schreiben und einreichen

– Ähnliche Testberichte von anderen Studienteilnehmern lesen

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

Evaluation

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.

Molich, RolfDialogDesignSkovkrogen 3DK-3660 StenløseDä[email protected]

Daske, LisaAstrum IT GmbHAm Wolfsmantel 291052 [email protected]

Usability Test Ergebnisse – Eine sehr persönliche Angelegenheit

342

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 kata-strophal, 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 zusam-menzuführen. Im zweiten Teil des Work-shops 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 Haupt-grund für den Evaluator Effect der ist, dass die Usability Evaluierung eine interpre-tierende Tätigkeit ist. Die Tester müssen Ermessensentscheidungen treffen, indem sie von einer Abfolge von Benutzerinter-aktionen 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: Immer-hin 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]


Usability/UX Texting

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 [Work-shop] und dachte, es müsste mehr Überein-stimmung geben als es tatsächlich gab. (…)“ Ein anderer Teilnehmer drückte es so aus: „Ich finde, es gibt so viele Ermes-sensentscheidungen – 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 Beobach-tungen zu gemeinsamen Usability Erkennt-nissen 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 Beob-achtungen zu gemeinsamen Usability Erkenntnissen hat es sich darüber hinaus als wich tig herausgestellt, die Beobach-tungen sorgfältig zu formulieren. Einige Befunde beschrieben beispielsweise nur, was beo bachtet 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

CUE-9a CUE-9b Combined

Anzahl aller Probleme 134 93 169

Probleme, die nur ein Teilnehmer berichtete52/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%


Anzahl Prüfer 19 16 35

Anzahl aller Befunde 860 473 1,333

Anzahl Befunde nach Kombination ähnlicher Befunde

182 109 222

Anzahl positiver Befunde 48 16 53

Anzahl negativer Befunde (Probleme) 134 93 169

Tab. 1. Anzahl der von mehreren Teilnehmern berichteten Probleme

Tab. 2. Anzahl Befunde

343

von 1.333 Beobachtungen zu unklar, um verstanden und einem Problem zugeord-net werden zu können.

3.1.3. Gründe für den Evaluator Effect

Als Grund für den Evaluator Effect nann-ten einige Teilnehmer, dass das Ziel der Evaluierung unklar gewesen sei. Es war beispielsweise unklar, wie die Verkaufsab-sichten der Webseite abgewogen gegen das Interesse der Nutzer werden sollten.

Ein Beispiel dafür waren die vorselektier-ten Artikel im Warenkorb: Mindestens ein Teilnehmer wollte eine reine Nutzerpers-pektive einnehmen und war daher gegen vorselektierte Waren; andere argumentier-ten, 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

Rating Code Description

Critical problem A 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 B Delays test participants in their use of the website for some minutes, but eventually allows them to continue. Causes occasional „catastrophes“.

Minor problem C Causes test participants to hesitate for some seconds.

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

Positive finding P This approach is recommendable and should be preserved.

Bug X 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.

Rating Code Description

Devastating problem

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

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

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

Minor problem C Causes users to hesitate for some secondsThe task solution obtained is sub-optimal but acceptable

Positive finding P This approach is recommendable and should be preserved

Tab. 4. Skala aus Chemnitz – CUE9b).

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

344

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 bewer-ten wann ein Usability Problem auftrat.

3.2.Bewertungsskalen

Nur etwa die Hälfte der Teilnehmer in Atlanta gab an, bei ihrer Arbeit als Usabi-lity 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 Bewertungsska-len 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 Hypo-these 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 Schwierigkei-ten war dass der Bewertungsprozess ver-schiedene 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 Schwie-rigkeit 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 wur-den sogar von zwei oder mehr Teilnehmern

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 Teilneh-mern 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 Beschrei-bung 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 beho-ben werden sollten, unabhängig von der dramatischen Beschreibung der Kategorie („lebensbedrohend“ oder „ruinierend“).




Net problem fi ndings 134 93 169

At least one AA or A, and at least one C 23/8228%

30/5852%

42/10739%

At least two AA or A, and at least two C 12/4825%

7/3222%

23/6535%

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

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

345

4. Empfehlungen für die Praxis

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

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

Eine Konsolidierung der Schweregrad-Bewertungen 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 kon-sistenteren 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 Usability-Probleme nicht verlässlich sind. Verschie-dene erfahrene Prüfer kommen zu sehr unterschiedlichen Bewertungen für die sel-ben 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 Teil-nehmern ihre Befunde kritischer bewertet als nötig und die schwerwiegendste Kate-gorie missbraucht. Bessere Bewertungs-skalen werden benötigt – natürlich müssen diese weiterhin gebrauchstauglich bleiben.

3. Usability Probleme sollten mit beson-derer Sorgfalt formuliert werden

Bei der Überarbeitung eines Systems werden Usability Probleme oft einzeln und ohne den bei der Formulierung vorhan-denen 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.

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

Um bei der Bewertung von Benutzer-aktionen 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 beispiels-weise notwendig werden, um korrekt zu bewerten, ob im Test eine Aufgaben richtig gelöst wurde.

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

Ein Teilnehmer, der die Existenz eines Eva-luator 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

weniger als 20% der Probleme gefun-den. 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.

Literatur1. Rolf Molich, Webseite zu den CUE-Studien,

http://dialogdesign.dk/CUE.html

2. Rolf Molich, Meghan R. Ede, Klaus Kaasg-

aard, and Barbara Karyukin, „Comparative

Usability Evaluation“, Behaviour & Infor-

mation Technology, vol. 23, no. 1, January/

February 2004, pp. 65–74.

3. Joseph S. Dumas, Rolf Molich, and Robin

Jeffries, „Describing Usability Problems – Are

We Sending the Right Message“, Interac-

tions, July/August 2004, pp. 24–29

4. Molich and Joseph S. Dumas, „Comparative

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

.1080/0144929X.2013.783114

346



347

1. Einleitung

User Experience ist ein multidimensiona-les Konstrukt, das alle Qualitätsmerkmale zusammenfasst, die für die subjektive Bewertung eines Produkts durch seine Nut-zer 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 Mes-sung dieser Produkteigenschaft bieten sich daher Fragebögen als einfache und kostengünstige Methode an. Im deutsch-sprachigen Raum sind hier die Fragebögen UEQ – User Experience Questionnaire (Laugwitz, Schrepp & Held, 2006) und AttrakDiff (Hassenzahl, Burmester & Koller, 2003) verbreitet.

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-stufi-gen semantischen Differentials haben, z.B.:

kompliziert einfach

leicht schwer zu lernen zu lernen

attraktiv unattraktiv

Die Items sind den folgenden sechs Ska-len zugeordnet: Durchschaubarkeit, Effi-zienz, Steuerbarkeit, Stimulation, Origi-nalität (jeweils 4 Items) sowie Attraktivität (6 Items). Die Skalen Durchschaubarkeit, Effizienz, und Steuerbarkeit beschreiben aufgabenbezogene (pragmatische) Qua-litä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 Valenzdi-mension. [Abb. 1]

Die Konstruktion und Validierung des Frage bogens 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 Sprach-versionen stehen unter www.ueq-online.org kostenlos zur Verfügung.

2. Warum ein Benchmark?

Der UEQ liefert als Ergebnis die gemes-sene User Experience auf den 6 Skalen Effizienz, Durchschaubarkeit, Steuerbar-keit, Stimulation, Originalität und Attrakti-vität. Abbildung 2 zeigt Ergebnisse für ein hypothetisches Produkt. [Abb. 2]

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

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 Pro-dukt 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.

Martin SchreppSAP AG – User ExperienceDietmar-Hopp-Allee 1669190 [email protected]

Siegfried OlschnerDATEV eG90329 Nü[email protected]

Ulf SchubertDATEV eGFürther Straße 21290429 Nü[email protected]

User Experience Questionnaire Benchmark Praxiserfahrungen zum Einsatz im Business-Umfeld

348

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 notwen-dig, die in dieser Form nicht verfügbar sind.

Eine naheliegende Frage, die nach Auswer-tung des UEQ oft gestellt wird, lautet Wie gut ist denn mein Produkt jetzt eigentlich? Hier ist insbesondere auch der Aspekt inte-ressant, wie gut die Ergebnisse im Vergleich zu anderen Produkten sind.

Bisher konnte diese Frage nicht zufrieden-stellend beantwortet werden. Man musste sich hier mit groben heuristischen Aussagen begnügen, die auch im Analyse-Tool visu-alisiert wurden. Werte zwischen -0.8 und 0.8 entsprechen einer neutralen Beurtei-lung, Werte > 0,8 einer positiven Beur-teilung und Werte < -0,8 einer negativen Beurteilung.

Der vorgestellte Benchmark soll Anwendern des UEQ eine bessere Einschätzung erlau-ben, 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 Teilneh-mern analysiert. Bewertet wurden hierbei Produkte unterschiedlicher Kategorien, z.B. betriebswirtschaftliche Anwendungen, Web-Seiten, Web-Shops, Soziale Netz-werke, etc.

Die Anzahl der Teilnehmer pro Untersu-chung 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. 1. Skalenstruktur des User Experience Question-naire (UEQ).

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

Abb. 3. Verteilung der Teilneh-merzahlen.

349

Die folgende Abbildung 4 zeigt die Ver-teilung der Skalenmittelwerte der einzel-nen Skalen im Benchmark- Datensatz als Density-Plots. [Abb. 4]

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 Resul-tate waren besser als das Ergebnis des Produkts, 50% waren schlechter.

– Unterdurchschnittlich: 50% der Resul-tate waren besser als das Ergebnis des Produkts, 25% waren schlechter.

– Schlecht: Im Bereich der 25% schlech-testen Resultate.

Die folgende Tabelle zeigt den Zusammen-hang dieser Kategorien mit den beobach-teten 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.

4.Praktische Anwendung am Beispiel DATEV eG

Der UEQ als internes BenchmarkInstrument

Die DATEV eG verwendet seit mehre-ren 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.

Attraktivität Effi zienz Durchschau-barkeit Steuerbarkeit Stimulation Originalität

Exzellent ≥ 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

Überdurch-schnittlich

≥ 1,09 < 1,5 ≥ 0,84 < 1,31 ≥ 0,9 < 1,37 ≥ 1,06 < 1,4 ≥ 1,0 < 1,31 ≥ 0,63 < 0,96

Unterdurch-schnittlich

≥ 0,65 < 1,09 ≥ 0,5 < 0,84 ≥ 0,53 < 0,9 ≥ 0,7 < 1,06 ≥ 0,52 < 1,0 ≥ 0,24 < 0,63

Schlecht < 0,65 < 0,5 < 0,53 < 0,7 <0, 52 < 0,24

Abb. 5. Verteilung der Skalen-mittelwerte (Kernel-Density Plots).

Tab. 1. Benchmark-Intervalle pro Skala.

350

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 Programm-qualität verschiedener zusammengehö-riger Anwendungen untereinander und über einen Zeitverlauf von drei Jahren zu betrachten.

Ziel des Einsatzes des UEQ ist es, schnell und effi zient 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 Steu-erung von Produktgestaltungsentscheidun-gen verwendet. Hierbei stellt sich natürlich sehr häufi g die eingangs erwähnte Frage: Wie gut hat das von mir evaluierte Pro-dukt im Vergleich zu anderen Produkten abgeschnitten?

In der Vergangenheit wurde zur Beantwor-tung dieser Frage ein interner Benchmark eingeführt. Bei diesem werden Werte aus den aktuellen systematischen UEQ-Bewer-tungen 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 Auswertungsgrafi ken der Produkte aufgenommen und bei der Interpretation von IST-Situation und der Empfehlung von Handlungsmaßnahmen mit einbezogen.

Zur Steigerung und Steuerung der UX-Aktivitäten genügt es aber nicht nur die Frage nach der IST-Situation zu beant-worten. Zur nutzbringenden Verwendung der UEQ-Erkenntnisse bedarf es einer realistischen Zielvorgabe an die Entwick-lungsabteilungen. Die UEQ-Profi le der Produkte weisen für eine Produktfamilie in der Regel ein charakteristisches Profi l auf, bei dem die UEQ-Faktoren unterschiedli-che Minimal- und Maximalwerte erreichen. Dies muss bei der Festlegung von realisti-schen Zielvorgaben berücksichtigt 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 unter-schiedlichen 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 Ent-wicklungsabteilungen das Gefühl haben, die angestrebten Werte erreichen zu können. Aus diesem Grund leiten wir die Zielsetzung auf Basis des aktuellen DATEV-Benchmarks 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 fi ktive Benchmarklinie und die dazu ermittelte Zielvorgabe. [Abb. 5]

Zusätzlich zum internen DATEV UEQ-Benchmark 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 abge-schnitten hat. Da in der Regel mehrere DATEV Produkte gleichzeitig bzw. in Zusammenhang von den Anwendern eingesetzt werden, ist für uns die Bewer-tung 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 gesam-ten 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äufi gkeit und Nutzungskon-text 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 „Betriebswirt-schaftliche Software“ begnügen.



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

351

Praxiserfahrungen bei der Durchführung Auswertung und Interpretation von UEQBewertungen

Neben dem Einsatz von Benchmark-Ver-gleichen haben wir bei der Auswertung und Interpretation von UEQ-Bewertungen Praxi-serfahrungen 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 Online-Beantwortungszeit eines DATEV-UEQ (mit Ergänzungen wie Fragen zur Person, zur Nutzung der Software, zur Gesamtzufrie-denheit und Performance) ist 7,5 Minuten.

Wie läßt sich die Akzeptanz des UEQ innerhalb Entwicklungsabteilung erhöhen?

Der UEQ ist extrem schnell und kosten-gü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 stich-punktartig aufgelistet und es wird eine Handlungsempfehlung für das weitere Vor-gehen ausgesprochen. Um die Akzeptanz

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.

Unterscheiden sich die Bewertun-gen von Beta-Testern und normalen Endanwendern?

Im Rahmen der Softwareentwicklung setzen viele Unternehmen Beta-Tests ein, um eine hohe Qualität des Produktes zu gewährleisten. Es liegt nahe bei Beta-Tests nicht nur technische und fachliche, sondern auch ergonomische bzw. gestal-terische 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 bei-den 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 Unter-schiede zwischen den beiden Gruppen betrugen zwischen 0,35 (Faktor Stimula-tion) 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än-gig von der Nutzergruppe und von der

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

Da bei DATEV UEQ-Studien mit einer zusätzlichen Einzelfrage die Gesamtzufrie-denheit 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 Vor-hersage des Wertes Gesamtzufriedenheit bei unterschiedlichen Benutzergruppen und unterschiedlichen Zeiten.

Bei der Regressionsberechnung wurde die Variable Gesamtzufriedenheit vor-hergesagt und es wurde geprüft welche der UEQ-Faktoren bei unterschiedlichen Dateneingabemodellen noch eine signi-fikante Erhöhung der Vorhersagequalität erbringen. Nichtaufgelistete UEQ-Faktoren erbringen bei Eingabe in die Regressions-gleichung keinen signifikanten Mehrwert an Vorhersagequalität für die Gesamt-zufriedenheit. Dies bedeutet jedoch nicht, dass die anderen UEQ-Faktoren unbedeutend sind. Wir gehen davon aus, dass die anderen UEQ-Faktoren Hygiene-faktoren 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

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 Regressi-onsberechnungen

352

für die Gesamtzufriedenheit eines Nutzers in dem Rechenmodell von größerer Bedeutung sind, als die anderen Fakto-ren. 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 Ein-fluss 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-Perfor-mance ein mäßiger bis mittlerer Zusam-menhang besteht (korrigierte R2 = 50, N = 107). Sicherlich zeigt hier das UEQ-Item schnell – langsam eine Wirkung.

Macht es Sinn, UEQ-Werte bei Usability-Tests 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 Benutzerla-bor den UEQ vor. In der Regel funktioniert der UEQ auch hier relativ gut, da min-destens 10 Einzelbewertungen vorliegen. Einige der Faktoren, wie z.B. Durchschau-barkeit, sind sehr gut interpretierbar, andere wie z.B. Stimulation etwas weniger.

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

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

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.

Ist der UEQ sensibel bezüglich Änderun-gen in den Produkten?

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. Bei-spiele hierfür sind z.B. die Erhöhung des Faktors Originalität nach Verbesserungen bezüglich schnellerer Dateneingabe oder die Verringerung des Faktors Durchschau-barkeit nach Erhöhung der Funktionsviel-falt im zentralen Dialogabschnitt. Sicherlich muss man bei Interpretationen vorsichtig sein. Eine gute Hilfe in diesem Zusam-menhang sind die Freitextantworten der Beurteiler, die im UEQ-Fragebogen der DATEV miterhoben werden.

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

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

liche Personen zur Messung der User Experi-

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

sung der User Experience von Softwarepro-

dukten. In: A.M. Heinecke & H. Paul (Hrsg.):

Mensch & Computer 2006 – Mensch und

Computer im Strukturwandel, S. 125–134.

Oldenbourg Verlag.

5. Laugwitz, B.; Held, T. & Schrepp, M. (2008).

Construction and evaluation of a user experi-

ence 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 Multime-

dia and Artificial Intelligence, Vol. 2, Nr. 1,

S. 39–45.

8. Tractinsky, N. (1997). Aesthetics and Appa-

rent 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 visi-

ted: 20.06.2013).



353

354

Referenten

355

Andrus, RolandRoland Andrus studierte Wirtschaftsinformatik mit dem Schwerpunkt Multimedia an der Fach-hochschule 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, CharleneCharlene 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 Durch-fü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, MichaelMag. Michael Bechinie: Studium der Anthropologie an der Universität Wien mit dem Fokus Human Ethology. Bereichsleitung Experiences Design bei USECON. Mehr als 15 Jahre Erfah-rung 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, Durch-führung von Trainings.

356


Referenten

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 Stuttgart, 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 Gestaltungsdisziplin, 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, KatjaKatja Busch studierte nach einer Ausbildung zur Industriefotografin Medien-Planung, -Ent-wicklung 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 Marke-ting zur Vaillant GmbH auf die Kundenseite wechselte. Zum Austausch zwischen Wissenschaft und Wirtschaft dozierte sie über Informationsarchitektur, Qualität im Web und Online-Marke-ting an der Uni Siegen, der FH Bonn-Rhein-Sieg und der FH Köln.

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 Normenaus-schuss „Benutzungsschnittstellen“ des Deutschen Instituts für Normung (DIN) e.V.

357

Cepkenli, SirinSirin Cepkenli ist Senior Interaktion Architekt bei USEEDS° in Berlin. Sie erarbeitet und konzi-piert 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, NicoleNicole 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 Usabi-lity Projekte. Ein weiterer Schwerpunkt von Nicoles Arbeit ist Barrierefreiheit.

Daske, LisaLisa 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-Pro-jekte 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, SarahSarah Diefenbach ist wissenschaftliche Mitarbeiterin im Bereich Nutzerleben und Ergonomie an der Folkwang Universität der Künste Essen. Ihre Forschungsinteressen liegen in den Berei-chen User Experience, Experience Design, Ästhetik der Interaktion und erlebnisorientierte Interaktionsgestaltung. Sarah Diefenbach hat an der TU Darmstadt Psychologie mit Neben-fach Informatik studiert.

358


Referenten

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 Produktent-wicklung. Er führte zahlreiche Usability-Projekte mit kleinen und mittleren Unternehmen durch und ist zudem in Industrieprojekte mit Großunternehmen eingebunden.

Döbelt, SusenSusen 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, ManfredManfred 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.

Dierolf, PeerPeer 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 Verpackungsmaschinen-branche 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.

359

Duda, SabrinaSabrina 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, AnjaAnja Endmann, Diplom-Kommunikationspsychologin, arbeitet als User Experience Resear-cher 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äh-rend 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, HolgerHolger Fischer studierte Medieninformatik an der Fachhochschule Köln und ist wissenschaft-licher Mitarbeiter in der Gruppe Usability Engineering im Cooperative Computing & Com-munication 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 Human-Centred Design Aktivitäten in Produktentwicklungsprozessen. Im Rahmen seiner Promo-tion 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-Cen-tered-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


Referenten

Geis, ThomasThomas Geis ist seit 1993 im Arbeitsgebiet Usability Engineering tätig und seit 2003 Geschäftsführer der ProContext Consulting GmbH, einem Beratungshaus, das auf Require-ments Engineering aus Nutzersicht, Produktmanagement und Standardisierung im Usability Engineering spezialisiert ist. Er hat zahlreiche Anforderungsanalysen aus Nutzersicht, Interak-tionsdesignprojekte 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 bes-sere „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 Innovati-onsmanagement 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äf-tigt. Seine Arbeitsschwerpunkte umfassen seit 2006 die Analyse, Konzeption und Evaluation von interaktiven Systemen.

Flesch, CarolinCarolin 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.

361

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

Glende, SebastianDer promovierte Wirtschaftsingenieur Sebastian Glende beschäftigt sich mit innovativen Ansät-zen 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 Lehrbeauf-tragter 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 Innovati-onsprozessen 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 Lehrbe-auftragter 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, KatharinaKatharina 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äftsan-wendungen 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


Referenten

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, LucieLucie 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 Hoch-schule 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.

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 interdiszip-linäre Zusammenschluss von Dienstleistern aus den Bereichen Automatisierungstechnik und Design verfolgt das Ziel, Benutzerfreundlichkeit und Innovation in industrieller Anwendersoft-ware zu fördern.

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üdigerDr. 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, TheoDr. Theo Held studierte Psychologie an der Universität Regensburg (Schwerpunkt: experi-mentelle 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 Wissens-reprä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


Referenten

Hochreuter, Thorsten Thorsten Hochreuter ist seit Sommer 2012 wissenschaftlicher Mitarbeiter im Forschungspro-jekt ProTACT an der Hochschule Mannheim. Schon während seines Studiums der Informa-tik 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, SebastianSebastian 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ögli-chen User Experience zu erzielen.

Hüttner, JensJens Hüttner, Diplom-Psychologe ist Geschäftsführer, Berater und Partner bei artop – Insti-tut 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 weiterge-geben, 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“.

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 ver-schiedenen Anwendungsdomänen durchgeführt. Hierbei hat sich durch die Kombination von For-schungsprojekten im Bereich User Experience Pattern und Mobile, sowie die große Involvierung in praktischen Industrieprojekten ein spannender Mix aus Forschung und Anwendung ergeben.

365

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

Janneck, MoniqueMonique Janneck ist Professorin für Mensch-Computer-Interaktion an der FH Lübeck. For-schungs- und Arbeitsschwerpunkte u.a.: Soziotechnische Gestaltung und partizipative Techni-kentwicklungs- 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 Diplom-Informatiker, 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.

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

366


Referenten

Kneisel, BorisBoris Oliver Kneisel studierte Chemie in Göttingen, Newcastle u.T. (UK) und Karlsruhe. Nach Promotionsabschluss 1998 Eintritt in den SAP Konzern als System-Analytiker (Bera-tung), 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 Offshore-LeanSigma-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 Skalie-rungskonzepte 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, KirstinKirstin 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 Fraun-hofer IESE in der Beratung und Forschung auf dem Gebiet des User Experience Designs und Requirements Engineerings beschäftigt.

Kluge, OliverOliver 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.

367

Kolb, NinaNina 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 Medieninfor-matik 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 Kompo-nenten. Zu ihren Tätigkeiten gehören der Aufbau der Usability-Kompetenz sowie die Etablie-rung 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 Fron-tend 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, HubertaKinga Kujat ist seit 1999 planend, gestaltend und entwickelnd im digitalen Umfeld tätig. Nach Abschluß des Studiums Kommunikationsdesign, Schwerpunkt Design für Elektroni-sche 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 Anforderungsdefi nition, Informati-onsarchitektur 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-, Auto-motive- 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


Referenten

Kujat, KingaKinga Kujat ist seit 1999 planend, gestaltend und entwickelnd im digitalen Umfeld tätig. Nach Abschluß des Studiums Kommunikationsdesign, Schwerpunkt Design für Elektroni-sche 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 Universi-tät der Künste Berlin im Jahr 2007, legte sie Ihren Schwerpunkt auf konzeptionelle Arbeit und UX Design. Ihre Projektaufgaben bestehen im Speziellen aus Anforderungsdefi nition, Informationsarchitektur und Feinkonzeption/GUI Prototyping für Desktop und mobile Endgeräte. Kinga Kujat ist deutschlandweit für renommierte Digital-Agenturen und Unter-nehmen tätig und arbeitet in zumeist breit angelegten Projekten für Marken unterschiedli-cher 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 Custo-mer Journeys, User Research & Insights und User Innovation.

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.

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 Informations-design 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 Produktma-nagerin 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 Inter-action 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


Referenten

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

Molich, RolfRolf Molich ist selbstständiger Berater und Inhaber der kleinen dänischen Usabilityberater-firma 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ßer-dem 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 Usability-Teams 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, MariaMaria Mory, Dipl.-Designerin, studierte an der FHTW Berlin im Fachbereich Gestaltung. Seit 1998 gestaltet sie Webinhalte und digitale Produkte, unter anderem 10 Jahre bei Immobili-enScout24. 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.

Löffler, JanaJana Löffler ist Diplom-Psychologin und Mitinhaberin von artop – Institut an der Humboldt-Universitä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.

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, MarkusMag. 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, ChristophDr. 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, SiegfriedDr. 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


Referenten

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

Petzold, Maike Maike Petzold studierte Medien und angewandte Informationstechnologie (heute Medienin-formatik) an der Fachhochschule Düsseldorf. Anfang 2011 beendete sie ihre Bachelorarbeit mit dem Thema „Konzeption und Implementierung einer Kalkulationssoftware zur Opti-mierung 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 Gestal-tung und Realisierung moderner Software.

Pietschmann, JensProduktkonzeption 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 Schwer-punkten auf User Experience und Gamifi cation. Jens Pietschmann ist aktuell als Produktmana-ger bei der cleverbridge AG tätig.

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 Expe-rience Designerin bei der Ergosign GmbH vorwiegend in den Bereichen Industrie- und Offi ce-Anwendungen.

373

Polkehn, KnutKnut Polkehn, Diplom-Psychologe ist Berater und Partner bei artop – Institut an der Hum-boldt-Universität zu Berlin. Er berät zu Themen der Mensch-Technik-Interaktion von Anforde-rungsanalyse 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, MariaMaria Rauschenberger ist Projektleiterin (Online & SAP) bei der Firma Medien-Systempartner (MSP). Ihr derzeitiger Aufgabenbereich ist u.a. die anwendungsorientierte Oberflächenge-staltung, 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, AnikaAnika 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ätsmanage-ment im Mobilfunkumfeld.

Rügenhagen, EvaEva 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 Produktent-wicklungsteams 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 Kognitionswissen-schaft und Germanistik und fokussierte sich bereits während ihres Studiums auf den Bereich Mensch-Maschine-Interaktion.

374


Referenten

Schauber, CorneliaCornelia Schauber ist Diplom-Psychologin und interessiert sich besonders für Versuchspla-nung und -design, neurologische Korrelate psychischer Zustände und Robotik. Nach dem Stu-dium arbeitete sie als wissenschaftliche Mitarbeiterin des Instituts für Arbeitswissenschaft an der Universität der Bundeswehr im Rahmen des Exzellenzclusters „CoTeSys“ an der automa-tisierten 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, ThomThom 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, ReinerReiner 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.

Rummel, Bernard Bernard Rummel arbeitet seit mehr als 20 Jahren im Arbeitsfeld Ergonomie und Gebrauchs-tauglichkeit. Nach neun Jahren am Schiffahrtmedizinischen Institut der Marine kam er 2000 zu SAP. Als Diplom-Psychologe (Universität Kiel) mit Schwerpunkt auf Ingenieur- und Orga-nisationspsychologie 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 Designstan-dards 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.

375

Schlierkamp, KatrinKatrin 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 Nutzungssze-narien sowie Themenschwerpunkte aus dem Bereich User Requirements Engineering.

Schmidt, ChristianeChristiane Schmidt ist seit 1996 als GestalterIn komplexer digitaler Anwendungen in eduka-tiven und kulturellen Bereichen tätig. Seit 2002 arbeitet sie als Designberaterin und Usability-Consultant im Cornelsen Verlag. Sie befasst sich derzeit mit der Schaffung von Quality Gates im digitalen Bereich, führt haus-weite 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 Universi-tä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 Mensch-Maschine-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-MariaEva-Maria Schön ist als Consultant bei der 7P Solutions & Consulting AG tätig. Das Unter-nehmen ist Teil der SEVEN PRINCIPLES (7P) Group, einer international agierenden Unter-nehmensberatung 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


Referenten

Schubert, UlfUlf Schubert ist Leiter User Experience bei DATEV eG in Nürnberg. Zu seinen Aufgabenberei-chen 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 unbe-wussten Wahrnehmung. Gemeinsam mit Immonet hat Rolf die Immonet iPad App entwi-ckelt, 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 Spe-zialthemen und vermittelt in Workshops die Grundlagen von Usability und UX.

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 Dokumenta-tion, Software-Entwicklung, User Interface Design und Barrierefreiheit betriebswirtschaftlicher Anwendungen (Schwerpunkt CRM). Hauptinteressen sind die Anwendung kognitionswissen-schaftlicher Erkenntnisse auf das Design interaktiver Anwendungen, Barrierefreiheit und die Entwicklung von Methoden zur Evaluation und Datenanalyse.

377

Schuster, SandraNach 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 Marktfor-schungsagentur up2date und leitete diesen bis 2008 als Methoden- und Projektverantwortli-che. 2009 übernahm sie die Projektleitung für die Entwicklung standardisierter Qualitätssiche-rungssysteme 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 Positio-nierungsfelder „Mobile UX“ und „Lean Back UX“.

Seeling, ThomasThomas Seeling ist seit 2011 wissenschaftlicher Mitarbeiter an der Professur Arbeitswissen-schaft & Innovationsmanagements des Institutes für Betriebswissenschaften und Fabriksys-teme 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 Expe-rience 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 Mensch-Maschine-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 Mit-organisator 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


Referenten

Strassl, PeterPeter 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 Weban-wendung, 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 berufs-begleitend 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örgDr. 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-Kom-munikation“, 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.

Stalph, Joachim

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 Informa-tionsvisualisierungen 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, ManfredDr. 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 The-men: Kontextuelle User Experience, Methoden und Werkzeuge zur Erforschung der Interak-tion 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


Referenten

Walke, TobiasTobias 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 Engi-neering 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.

Ullrich, DanielDaniel 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.

381

Wienen, Markus Dr. Markus Wienen ist User Experience Stratege bei der eparo GmbH in Hamburg. Er stu-dierte Sprachwissenschaft, Kommunikationswissenschaft, Philosophie, Informatik und BWL an den Universitäten Düsseldorf und Greifswald. In seiner Promotion hat er sich mit den Bedin-gungen für erfolgreiche Kommunikation befasst. Seine erste berufliche Station war die Agen-tur 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.

Wedl, ChristianChristian 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 Sie-mens 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 einzubrin-gen und weiterzugeben.

Weisser, TinaWährend ihres Architekturstudiums gründete Tina Weisser eine Branding- und Konzeptions-agentur 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 Insight- und Designforschung.

Winter, DominiqueDominique 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 Softwarekon-zeption, Barrierefreiheit und Usability-Engineering. Zudem ist er Mitglied einer Forschungs-gruppe der HS Emden/Leer und beschäftigt sich hauptsächlich mit der Vereinbarung von User Experience, Innovationsmanagement und Produktmanagement.

382


Referenten

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 internatio-nale 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 bekann-ten 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äftsmodellent-wicklung 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.

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 besonde-ren Interessen gelten der Integration des User Centered Design Prozesses in die Software-Ent-wicklung 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.

383

Wulf, InsaInsa 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, VickyVicky 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 aufbauen-den gruppenweiten Standards, die Schulung der Kollegen in den jeweiligen Märkten und die Auswahl der dafür unterstützenden Dienstleister.

384

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

KontaktadressenGerman UPA e.V.

Leitzstraße 45

70469 Stuttgart

Telefon +49 (0)711 490 66 – 117

Telefax +49 (0)711 490 66 – 118

E-Mail: [email protected]

URL: www.germanupa.de

Layout und Gestaltunggenese Werbeagentur GmbH, Magdeburg

Herstellung und VerlagGerman 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.

Impressum

385


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

Usa

bilit

y Pr

ofes

siona

ls 20

13

German UPA e. V.Leitzstraße 45 | 70469 Stuttgart

www.germanupa.de

Documents

Usability Professionals 2013 - Tagungsband